Subject: [Int-area] Ben Campbell's Yes on draft-ietf-intarea-broadcast-consider-08: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jan 2018 19:24:12 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-intarea-broadcast-consider-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting "Yes", but I do have a few comments:

Substantive Comments:

-2.2: "These IDs, which e.g. identify the installation of a
   certain application might not change across updates of the software
   and are therefore extremely long lived"

That seems to imply that they may be extremely long lived, not that they always
are.

-2.2, last paragraph: "When protocols that
   make use of broadcast/multicast need to make use of IDs, frequent
   rotations of these IDs SHOULD be considered to make user tracking
   more difficult."
Can this say something stronger than "... be considered..." Maybe "be required"?

-2.3, first paragraph: It seems worth noting that a host name can be a
persistent ID even if it contains no personally identifiable info.

-- Same paragraph: The last sentence gives a nod to device fingerprinting.
Would it be reasonable to offer some more general guidance around avoiding such
fingerprinting?

-2.3, last paragraph: It seems counterproductive to explain better ways of
creating persistent IDs after a whole section was dedicated to telling people
to avoid them.

-2.4: This section talks about how broadcast/multicast data might be used for
correlation.  Is there any reasonable guidance to give on how to avoid that?

-2.5: It seems the configurability discussion could go a bit further and
suggest that platforms avoid broadcast/multicast services for features that the
user is not actively using.

Editorial Comments and Nits:

-1, paragraph 6: While I like citations of the form of " 'document title' [ref]
" better than just "[ref]" , when that becomes "  RFC 7721 [RFC7721] or RFC
7819  [RFC7819]", it adds no information. Please consider replacing "RFC 7221"
and "RFC 7819" with something more descriptive.

-1, paragraph 7: " For one, non-standard
   protocols will likely not receive operational attention and support
   in making them more secure such as e.g.  DHCP snooping does for DHCP
   because they typically are not documented."

I find that hard to parse.

-- same paragraph: "... where a set of
   considerations to follow is useful in the absence of a larger
   community providing feedback. "

I don't understand the intent.

-1.1, first paragraph: "The same is true for directed broadcasts by
   default, but routers MAY provide an option to do this [RFC2644]"
That MAY seems like a statement of fact or an external requirement. Neither
should use the upper-case MAY.

-1.1, last paragraph: Please expand LLMNR and mDNS on first mention.
-- same paragraph: The last sentence seems out of place in this paragraph.
Perhaps it should go with one of the two previous paragraphs?

-1.2: I don't think the use of RFC 2119 keywords adds much value in this
document. The document mainly uses them to talk about thins people should
consider in protocol design, rather than requirements on the protocols
themselves. I suggest making the boilerplate more descriptive of that use, or
even better get rid of it (and the capitalized keywords) entirely.

-2.1, last sentence is hard to parse.

-2.2, 2nd to last paragraph: s/" did never " / " never did "
-- same paragraph: "allowed to track" is grammatically incorrect. It should say
"allowed <something> to track" or "allowed the tracking of"

-3, 2nd paragraph: By "not uncommonly", do you mean "commonly"?