Skip to main content

Last Call Review of draft-ietf-pim-reserved-bits-03
review-ietf-pim-reserved-bits-03-opsdir-lc-hares-2019-09-13-00

Request Review of draft-ietf-pim-reserved-bits
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2019-09-03
Requested 2019-08-20
Authors Stig Venaas , Alvaro Retana
I-D last updated 2019-09-13
Completed reviews Secdir Last Call review of -03 by Dan Harkins (diff)
Genart Last Call review of -03 by Peter E. Yee (diff)
Opsdir Last Call review of -03 by Susan Hares (diff)
Assignment Reviewer Susan Hares
State Completed
Request Last Call review on draft-ietf-pim-reserved-bits by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/jvzsfID8ORdvzMEJWQ4AMr0KZMk
Reviewed revision 03 (document currently at 04)
Result Has issues
Completed 2019-09-13
review-ietf-pim-reserved-bits-03-opsdir-lc-hares-2019-09-13-00
OPS-DIR review

General comment: This is needed specification for PIM and clearly written.

Issue: Issue/Error in document 
However, this document does not specify the error handling if a PIM implementation does 
not abid by the MUSTs in section 4 defined as follows:  

   Unless otherwise specified, all the Flag Bits for each PIM type are
   Reserved [RFC8126].  They MUST be set to zero on transmission, and
   they MUST be ignored upon receipt.  The specification of a new PIM
   type, MUST indicate whether the bits should be treated differently.

This issues becomes a serious issue if it negates any error handling or changes
any existing error handling. 

I suspect this is not really a serious issue, but a flaw in the write-up. 
I suspect that because you set to zero on transmission, and 
ignored on receipt you will not engage in any error handling. 

However, it is necessary to state that so that machines testing 
the PIM and SM-PIM protocols will easily add this to their testing suite. 

2) Issue:  Security considerations in general are the same as 
[RFC7761] and {RFC3973], but bogus error handling (depending how you do #1) 
may impact the security considerations. 

3)  Minor Issue:  Should Section 3 include a change to RFC3973 - section 4.7.1 

Editorial Issues: 
It really help the reader trying to piece together the specifications to provide 
an example reference point. 

Since I looked each of these up: 

Section 3:  page 3, paragraph 1, RFC7761 - section 4.9 
Section 4:  page 3, paragraph 2.   RFC8126 - section 6 
Section 4.1: page 4, section 4.1, RFC5059, - section 5
Section 4.2: page 4, Section 4.2, RFC5015, - section 3.7.21
Section 4.3: page 4, section 5.3  RFC8364 - section 3.1

It would be helpful to the reader to provide sections numbers for the 
references.   If you would select other ref erences, it is further proof
that it would be useful to indicate which sections you are referring to.