Russ,
Thanks for your review!
Cheers,
Andy
On Fri, May 12, 2017 at 6:33 AM, Russ Housley <housley@xxxxxxxxxxxx> wrote:
Reviewer: Russ Housley
Review result: Has Nits
I reviewed this document as part of the Security Directorate's
ongoing
effort to review all IETF documents being processed by the IESG.
These
comments were written primarily for the benefit of the Security Area
Directors. Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.
Document: draft-ietf-pals-vpls-pim-snooping-05
Reviewer: Russ Housley
Review Date: 2016-05-11
IETF LC End Date: 2017-05-19
IESG Telechat date: Unknown
Summary: Has Nits
I did not review the state machines in detail. I assume that others
that are far more familiar with PIM have done s detailed review of
them.
No Major Concerns
Minor Concerns
Section 1 says:
In that case, the PW related concept/procedures are not
applicable and that's all.
I am not sure what you are trying to tell the implementer.
Please clarify.
Section 1.3 includes: "rpt : Rendezvous Point", and Section 2.3
includes: "Rendezvous Points (RP)". Please pick one and use it
throughout.
In Section 2.2, please add a reference for the "split-horizon rule
for mesh PWs" or add a pointer to the section where it is discussed
further in this document.
A better heading for Section 2.3.2 would be "IPv4 and IPv6".
Nits
Please change the language that makes reference to other "draft",
such
as: "As stated in the VPLS Multicast Requirements draft ...". This
wording leads to changes by the RFC Editor, so it is better to use a
word like "document".
Please change "J/P messages" to "Join/Prune messages" throughout the
document.
The document uses both "learned" and "learnt". If there is a
difference
to the reader, it was too subtle for me to figure out. If they are
the
same, please pick one.
In Section 1.1, rewording would add clarity:
Depending on how the control messages are handled
(transparently flooded, selectively forwarded, aggregated), the
procedure/process may be called Snooping or proxy in different
contexts.
I suggest:
Depending on whether the control messages are
transparently flooded, selectively forwarded, or aggregated, the
processing may be called Snooping or proxy in different contexts.
Section 2.3 says:
However, the PE does not need to have any routing tables like as
required in PIM multicast routing.
Please correct. I think you are trying to say:
However, the PE does not need any routing tables like those
required in PIM multicast routing.
Section 4.2.1 says:
Note that the differences apply only to PIM Join/Prune messages.
PIM
Hello messages are snooped and flooded in all cases.
Wouldn't it be more clear to consume the same number of lines and add
this information to the table.
In Section 2.7 the document uses PIM-BIDIR and BIDIR-PIM, and they
seem
have the same meaning. Please pick one.