[Mtgvenue] comments on draft-rescorla-anonymous-network-00

[Stephen Farrell <[e-mail]>]

(oops, this is a re-tx, I sent from the wrong a/c first
time, and it's fine if the list admin discards that one)

Hiya,

I had another read of [1] and have the comments below. I do
think this is a good document and entirely suited for AD
sponsorship, so I hope that's what happens.

Eliot's suggestion that this document be considered as
setting out new "Important" requirements for venue
selection seems fine to me, but I'd suggest we punt on that
discussion until e.g. IETF LC time so haven't suggested
that below.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-rescorla-anonymous-network/


- I think the word 'anonymous' in the filename is
    unfortunate - I don't think we have a requirement that
everyone be anonymous in a strong sense when using the
IETF meeting n/w. I do think we have a strong
requirement that not everyone and everything done on the
meeting n/w be identifiable though. Probably not worth
changing the filename, but might be worth adding some
text like the previous sentence?

- Title: would this be better as "Additional Security
    and Privacy Requirements for the IETF Meeting
Network"? I don't think the goal here is to set out all
the security reqs, e.g.  'don't be a DoS accelerator'
is probably a requirement but doesn't belong here.
Similarly, I think mention of privacy in the title would
be good.

- General: I assume 'the IETF network' means the on-site
    meeting n/w, would it be better to be more precise
about that? We don't meet these requirements for on-line
interims for example (and that's ok).

- section 1, Intro: the quote from RFC8718 is good. I
    note that that includes meeting the 'day-to-day needs'
of meeting attendees, which includes personal use of the
meeting network, as well as doing work on IETF things
and e.g. for one's sponsor/employer.  Those personal
uses will commonly include managing one's home n/w from
the IETF meeting, making travel arrangements and
communicating with family etc. I think it'd be good to
call that out as a requirement as it IMO imposes a
higher bar for privacy than were the meeting n/w solely
provided for use for IETF work. That could be done as a
new bullet, in-between the current two perhaps.  (I'm
fine that the authors figure out good wording, but happy
to make a proposal if that's useful.)

- section 1, Intro: 2nd bullet, I'd suggest s/IETF
    attendees typically expect/ IETF attendees expect/

- section 1, Intro: 2nd bullet, maybe:

OLD:

If IETF users need to authenticate in a way that
their Internet traffic can be attributed to them by
local or upstream network operators,

NEW:

If IETF users need to authenticate in a way that their
Internet traffic can be attributed to them by local or
upstream network operators, or if meeting n/w logs are
shared with other parties,

- section 2, reqs: I'm not sure "These properties MUST
    also hold for upstream networks" is within our
control. Suggest s/MUST/SHOULD/ there, or maybe say that
"best efforts MUST be made to ensure these properties
hold for upstream networks" or something?

-  section 2, reqs: maybe a general s/security/security
     and privacy/ change would be good here:

OLD:

This text is intended to ensure that IETF participants
can continue to get the level of security that they
require when they use the IETF network.

NEW:

This text is intended to ensure that IETF participants
can continue to get the level of security and privacy
that they require when they use the IETF network.

- section 2, reqs: I sometimes use eduroam at IETF
    meetings, and can't get an arbitrary number of
credentials for that. Does the 'arbitrary number' text
need a tweak to allow for that or other SSIDs? I
wouldn't like if this document provided an argument to
not provide eduroam access and the term 'forbid' a bit
later might be used in such an argument.