Alissa Cooper's Discuss on draft-ietf-mboned-ieee802-mcast-problems-11: (with DISCUSS and COMMENT)

Alissa Cooper 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 8: Are there plans for the IETF community to develop the guidelines
mentioned? I'm wary of publishing an RFC that says the IETF should do something
if there are in fact no plans for the IETF to do the thing. RFCs are not
necessarily good motivators.

Overall this is an interesting document, but it seems to be written in an
overly casual way and assumes readers have a lot of context that is not
included in the document itself. The Gen-ART review pointed out a number of
bits of text that left this impression. It was posted in October and never
responded to. I've picked out some bits of the review and added a few more of
my own -- collectively addressing these would get the document into publishable
shape for a wider audience I think.

General:  (1) On first use, please add citations for all the protocols
mentioned in the document, as well as a few words to describe what each
protocol does. For IETF readers, this will help them understand the
implications of various 802 specifications without having to go look them up
right away. (2) The IETF meeting network may be interesting as an example to
contemplate, but to make this document broadly valuable it would be better to
generalize the problem descriptions than to focus on the IETF meeting network.

Section 3.1.4 seems a little thin to this non-expert. It is certainly true that
"every station has to be configured to wake up to receive the multicast", but
it seems like only a poorly designed protocol would create the situation where
"the received packet may ultimately be discarded" on any kind of regular basis.
If there are a class of packets that the receiver will ultimately discard, that
sounds like they should be on a separate multicast address, or the sender
should be determining if the packet will be discarded before sending it.
Perhaps what this section is driving at is that multicast protocols are often
designed without taking power-saving considerations into account, but then
*that's* what this section should probably talk about. As it is, it sounds like
the old joke about saying to the doctor, "My arm hurts when I do this" and the
doctor replying, "The stop doing that".

In section 3.2.1, the last paragraph is missing a bunch of information:
"It's often the first service that operators drop": What is "it"?
"Multicast snooping" is not defined.
In what scenario are devices "registering"?

Section 5.1: "...and sometimes the daemons just seem to stop, requiring a
restart of the daemon and causing disruption." What a strange thing to say.
Does this simply mean "and the current implementations are buggy"?

Also section 5.1: "The distribution of users on wireless networks / subnets
changes from one IETF meeting to the next". This document doesn't seem to be
about the IETF meeting network. This sentence seems inappropriately specific.
The "NAT" and "Stateful firewalls" sections are also overly specific to the
IETF meeting network. Generalizing would help.

Section 8: The first paragraph has too little useful comment. There is no
reference for 802.1ak, the reference to 802.1Q is inline instead of in the
references section, and the content of neither of these standards is explained
in this document. The paragraph doesn't really lay out what the topic of
discussion is, at least for someone like myself who is not versed in the topic.


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

Please respond to the rest of the Gen-ART review.


_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned