Re: [Gen-art] Genart last call review of draft-ietf-mboned-ieee802-mcast-problems-09

[Alissa Cooper]

Pete, thanks for your review. I merged several of your comments into my DISCUSS 
ballot along with a couple others.

Alissa


> On Oct 14, 2019, at 4:44 PM, Pete Resnick via Datatracker  
> wrote:
> 
> Reviewer: Pete Resnick
> Review result: On the Right Track
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-mboned-ieee802-mcast-problems-09
> Reviewer: Pete Resnick
> Review Date: 2019-10-14
> IETF LC End Date: 2019-10-14
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> This document has good information and analysis of multicast problems and is
> certainly valuable. However, there are some things in the document which could
> use clarification or editing.
> 
> Major issues:
> 
> The first paragraph of section 8 really 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.
> I really think this needs to be addressed.
> 
> Minor issues:
> 
> (Some of these issues are more or less "minor".)
> 
> 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 3.2.2: "This intensifies the impact of multicast messages that are
> associated to the mobility of a node." I don't understand why. Are you simply
> saying that as the number of addresses goes up, more discovery packets must be
> sent?
> 
> Section 3.2.4: This seems like more of general problem than a
> multicast-specific one, and as described it sounds like an attack rather than 
> a
> poor outcome of a protocol design decision like the rest of the examples.
> Perhaps framing it that way would make the section clearer.
> 
> Section 4.4: Which problem in section 3 is 4.4 supposed to address?
> 
> 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.
> 
> 7: This section seems quite thin, and perhaps unnecessary. The recommendations
> are implicit in the previous sections.
> 
> Nits/editorial comments:
> 
> Section 3.2.4: The mention of the face-to-face (probably better: "plenary")
> meeting seems unnecessary.
> 
> Section 5.1: Numbering the subsections would probably be useful.
> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-mboned-ieee802-mcast-problems-09

[Eric Vyncke (evyncke)]

Thank you Pete for your extensive review. As the responsible AD for this 
document, I really appreciate them

-éric

On 14/10/2019, 22:44, "Pete Resnick via Datatracker"  wrote:

Reviewer: Pete Resnick
Review result: On the Right Track

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-mboned-ieee802-mcast-problems-09
Reviewer: Pete Resnick
Review Date: 2019-10-14
IETF LC End Date: 2019-10-14
IESG Telechat date: Not scheduled for a telechat

Summary:

This document has good information and analysis of multicast problems and is
certainly valuable. However, there are some things in the document which 
could
use clarification or editing.

Major issues:

The first paragraph of section 8 really 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.
I really think this needs to be addressed.

Minor issues:

(Some of these issues are more or less "minor".)

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 3.2.2: "This intensifies the impact of multicast messages that are
associated to the mobility of a node." I don't understand why. Are you 
simply
saying that as the number of addresses goes up, more discovery packets must 
be
sent?

Section 3.2.4: This seems like more of general problem than a
multicast-specific one, and as described it sounds like an attack rather 
than a
poor outcome of a protocol design decision like the rest of the examples.
Perhaps framing it that way would make the section clearer.

Section 4.4: Which problem in section 3 is 4.4 supposed to address?

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.

7: This section seems quite thin, and perhaps unnecessary. The 
recommendations
are implicit in the previous sections.

Nits/editorial comments:

Section 3.2.4: The mention of the face-to-face (probably better: "plenary")
meeting seems unnecessary.

Section 5.1: Numbering the subsections would probably be useful.




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art