Subject: [pim] Opsdir last call review of draft-ietf-pim-reserved-bits-03

From: Susan Hares via Datatracker <[email-masked]>
Date: Fri, 13 Sep 2019 09:08:43 -0700

Reviewer: Susan Hares
Review result: Has Issues

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.

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 16 Sep 2019 16:56:55 +0000

On September 13, 2019 at 12:08:47 PM, Susan Hares via Datatracker ([email-masked]<mailto:[email-masked]>) wrote:

[Author hat on.]

Sue:

Hi!  Thanks for the review!

...

The Flag Bits are currently Reserved in rfc7761, which describes the field as: "Set to zero on transmission.  Ignored upon receipt.”  IOW, the behavior doesn’t change at all…really just the name of the field and the per-type applicability.

I’m not sure what you would like to see added, given that there is no change in the behavior specified in rfc7761.  Can you suggest something?

No.  PIM-DM (rfc3973) uses the packet formats (including the Header of course, §4.7.1) defined by PIM-SM…from §4.7: "All PIM-DM packets use the same format as PIM-SM packets.  In the event of a discrepancy, PIM-SM [4] should be considered the definitive specification.”  The reference is to rfc2362, the PIM-DM spec at the time, which has now been replaced by rfc7761.

Thanks!

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 17 Sep 2019 12:47:38 -0400

Alvaro: 

See comments below.    

You have hit a rabbit hole in the testing of the 

pim specifications that I’ve hit when I was in charge 

of running code.

I am providing you feedback on how to close the rabbit hole. 

Sue 

From: Alvaro Retana [mailto:[email-masked]] 
Sent: Monday, September 16, 2019 12:57 PM
To: Susan Hares; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Opsdir last call review of draft-ietf-pim-reserved-bits-03

On September 13, 2019 at 12:08:47 PM, Susan Hares via Datatracker ([email-masked]) wrote:

[Author hat on.]

Sue:

...

Alvaro ‘s comment: 

Ø  The Flag Bits are currently Reserved in rfc7761, which describes the field as: "Set to zero on transmission.  Ignored upon receipt.”  

Ø  IOW, the behavior doesn’t change at all…really just the name of the field and the per-type applicability.

Ø  I’m not sure what you would like to see added, given that there is no change in the behavior specified in rfc7761.  Can you suggest something?

What RFC 7761 states is :
Reserved: Set to zero on transmission.  Ignored upon receipt.

My comment on improving these specification: 

Ø  What happens if the implementations sends ones. Is it compliant or not?

Ø  Or should the protocols tester test this point.   

Ø  RFC7761 does not specify this point. 

If you are revising this specification, please consider stating something definite about this point.  I’ve hit this point on the PIM testing my code on the PIM specification. My feedback is fix it please.   I was not suggesting this in the text for the specification, but as manageability text for operations to suggest testing sequence.   Or perhaps you have a reference to some specification that states this type of advice.   

Remember - this was an OPS-DIR review.   

------------------------------
2) [RFC7761] and {RFC3973], but bogus error handling (depending how you do #1) 
may impact the security considerations. 

Ø  If someone sends random non-zero bits, it should not crash the router.  

Ø   

--------------------------

No.  PIM-DM (rfc3973) uses the packet formats (including the Header of course, §4.7.1) defined by PIM-SM…from §4.7: "All PIM-DM packets use the same format as PIM-SM packets.  In the event of a discrepancy, PIM-SM [4] should be considered the definitive specification.”  The reference is to rfc2362, the PIM-DM spec at the time, which has now been replaced by rfc7761

Ø  This logic should convince you it is hard to track down the complete state of rfc3973. 

Ø  However, BGP has some of these issues.  It’s a minor point. 

.Thanks!

Alvaro.