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

From: Spencer Dawkins <[email-masked]>
Date: Wed, 24 Jan 2018 15:31:13 -0800

Spencer Dawkins 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 really like this document. I learned a lot.

I'm not gonna argue, but could this have been a BCP?

I have a couple of comments.

ISTM that

   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.

should be either

   When protocols that
   make use of broadcast/multicast need to make use of IDs, frequent
   rotations of these IDs MUST be considered to make user tracking
   more difficult.

or

   When protocols that
   make use of broadcast/multicast need to make use of IDs,
   these IDs SHOULD be rotated frequently to make user tracking
   more difficult.

assuming that frequent rotation is the goal, not considering frequent rotation.

I'm not surprised that

   A feature not uncommonly found on access points e.g. is to filter
   broadcast and multicast traffic.  This will potentially break certain
   applications or some of their functionality but will also protect the
   users from potentially leaking sensitive information.

is the only action listed that network administrators/operators can take to
limit problems, but I note that the paragraph above it says there are things,
plural, that network administrators/operators can do to limit problems, and
this action can be paraphrased as "you can filter broadcast and multicast
traffic, but then the applications stop working, so make good choices". If
that's the only action you can think of, you may want to make the first
paragraph sound a bit less hopeful!