[MBONED] Roman Danyliw's Discuss on draft-ietf-mboned-ieee802-mcast-problems-11: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-mboned-ieee802-mcast-problems-11: Discuss

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-mboned-ieee802-mcast-problems/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 9.  Section 7 appears to recommend using an ARP sponge per Section
5.1.  Please provide some general caution about ARP poisoning/false advertising
that could undermine (DoS) this approach (that is being deployed to save
battery power).


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

I support Alissa’s DISCUSS.  My related comments on Section 5.1 are:

-- Section 5.1  Firewall unused space.  Per “… The distribution of users on
wireless networks/subnets changes from one IETF meeting to the next …”, this
text seems unnecessary and it strikes me as odd to base guidance on a single
network.

-- Section 5.1. NAT.  Per “To NAT the entire … attendee networks”, what is the
“attendee network” in this context?

-- Section 5.1.  Stateful firewalls.  Per “But this conflicts with the need and
desire of the IETF and other organizations to have the network as open as
possible and to honor the end-to-end principle.  An attendee on the meeting
network should be an Internet host …”, this text appears to be written about
the IETF meeting network. Honoring the end-to-end principle and network nodes
between Internet hosts is not universal architecture for all organizations. 
Recommend rewording or removing these two sentences.

** Section 5. This section states that it is describing optimizations to
address the issue discussion in Section 3.  It would be clearer if this section
notes which items from Section 3 are addressed.

** Section 5.1. Per “… and sometimes the daemons just seem to stop” seems to be
an implementation issue, not a reflection on the technique or associated
architecture.  If this is the case, I recommend removing this text.

** Section 7. This section would be clearer if the explicitly activities in
Section 4 and 5 being recommended were referenced.

** Section 9.  The first paragraph makes references to RFC4601 and RFC5796
which is helpful -- thanks.  I wasn’t sure what this meant in the context of
this document which discusses multicast over wireless. This guidance doesn’t
appear to be wireless specific.  Assuming you meant that “all the usual
multicast security guidance applies whether you are using wireless or not”,
please include clarifying text of the rough form (edit as required):

OLD: Multicast is made more secure in a variety of ways.

NEW: Multicast deployed on wired or wireless networks as discussed in this
document can be made more secure in a variety of ways.

** Editorial Nits:
-- Section 3.1.2.  Typo. s/techiques/techniques/

-- Section 3.2.1.  Typo.  s/utlize/utilize/

-- Section 4.7. s/AP has do the/AP has to do the/

-- Section 5.1. Typo. s/listen for ARP requests/listens for ARP requests/

-- Section 5.1. Typo. s/to an machine/to a machine/

-- IdNits reports:
  -- Obsolete informational reference (is this intentional?): RFC 2461
     (Obsoleted by RFC 4861)
  -- Obsolete informational reference (is this intentional?): RFC 4601
     (Obsoleted by RFC 7761)