Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)

[Susan Hares <[e-mail]>]

AlvaroThe author team will change to MUST per your comments.I know there is nothing in the text and I know there were problems.  Given the rush on the first version, I know things were down-played so the urgent problem could be fixed. My warning that the bit settings may be deep in code and current people may have trouble finding it.That said, it is the right thing to do.Did the iesg want by in same document?SueSent via the Samsung Galaxy S7 edge, an AT&T 4G LTE smartphone
-------- Original message --------From: Alvaro Retana <[e-mail]> Date: 4/24/20  1:00 PM  (GMT-05:00) To: Susan Hares <[e-mail]>, "Rob Wilton (rwilton)" <[e-mail]>, Jie Dong <[e-mail]> Cc: [e-mail], [e-mail], The IESG <[e-mail]>, [e-mail] Subject: Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT) Hi!As Rob mentioned, we talked about his DISCUSS during today’s IESG Telechat.We’re all in agreement that the last thing we want to do is to break any existing implementations, specially because this document is a bis.I looked at rfc5575, and I didn’t find the same text there — I found no specification of the setting of the bits, specially the reserved ones.[I also did a quick and unscientific search of other routing documents and found a mix of SHOULD/MUST and MUST/MUST constructs…]Note that there are two distinct cases (in rfc5575bis):(1) A bit is defined as 0, but the definition is: "0 -  SHOULD be set to 0…” (§4.2.1.1).  If it’s 0, then I see no reason for that not to be a MUST.  In fact, if always set to 0 we’re probably over specifying the field.   There are 3 occurrences of this in the document.(2) Unused (§7.3) or reserved (§7.5) defined as "SHOULD be set to 0...MUST be ignored”.  Again, if unused/reserved, I see no reason not to change to MUST.  I think Rob makes a good point about extensibility.Before any changes, and in the spirit of not breaking anything, we should check whether anyone has an implementation what would be impacted.  I assume/hope that the prototype implementations have already been fixed.Jie:  As Shepherd, can you please do a quick poll of the people who reported implementations to confirm that these changes won’t have an impact?   Thanks!Alvaro. On April 24, 2020 at 12:24:28 PM, Rob Wilton (rwilton) ([e-mail]) wrote: > Your question is a good one: > But I don't understand why that means the > sender is a "SHOULD be 0" not a "MUST be 0"? > > This text is inherited from RFC5575. > > Originally (which is not in any document) > this was set because prototype implementations of > RFC5575 had set it to a 1 during a rushed deployment. > > Whether these implementation still exist in the > smaller boxes boxes from major vendors - I do not know. > > One of the habits of IDR is not to break existing BGP. [RW] Yes, and I fully support that pragmatic aim.