[Int-area] Warren Kumari's No Objection on draft-ietf-intarea-broadcast-consider-08: (with COMMENT)

Warren Kumari <warren@kumari.net> Thu, 25 January 2018 14:36 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari <warren@kumari.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-intarea-broadcast-consider@ietf.org, Juan-Carlos Zuniga <juancarlos.zuniga@sigfox.com>, intarea-chairs@ietf.org, juancarlos.zuniga@sigfox.com, int-area@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151689097803.20274.6698596152488776478.idtracker@ietfa.amsl.com>
Date: Thu, 25 Jan 2018 06:36:18 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/Z-Gf1ngjnLIh-KJHR9hSYIImWoM>
Subject: [Int-area] Warren Kumari's No Objection on draft-ietf-intarea-broadcast-consider-08: (with COMMENT)

Warren Kumari has entered the following ballot position for
draft-ietf-intarea-broadcast-consider-08: No Objection

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 found this sentence very confusing:
" 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 know what it
is trying to say, but I don't think it accomplishes what it intends to.

[ This was originally a DISCUSS, emails with authors have addressed my
concerns. Old text below for posterity]: "Sorry for the late DISCUSS. I'm
likely to clear after discussions on the call tomorrow.

I'm somewhat surprised at how much this document glosses over the (sometimes
extensive) broadcast/multicast twiddling that Access Points and similar do (a
fair bit of discussion of which can be found in
draft-perkins-intarea-multicast-ieee802 (which I think will be expiring) or
draft-mcbride-mboned-wifi-mcast-problem-statement). Simply saying: "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." seems to be shrugging off all of the privacy benefits
(or possibly harms) that this might create. "

[Int-area] Warren Kumari's No Objection on draft-… Warren Kumari