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.