On June 19, 2020 at 11:49:51 AM, Les Ginsberg wrote:
Les: Hi! Just a couple of in-line answers. We should be ready to move forward once you submit the update. Thanks!! Alvaro. ... > > I'm writing all this here to have a record of this decision and to > > give anyone in the WG the opportunity to raise concerns, if any. > > [Les:] Just to be sure I understand, you are documenting that we need do > nothing in this regard? Correct. ... > > [major] s/5304/5305 Is §3.2 intended to update rfc5304? > > [Les:] 3.2 updates RFC 5304 to the extent that it recommends controls for > behaviors that might not be backwards compatible. (Similar for RFC 6233) > > Section 3.3 clearly updates RFC 5305, so I have added that here. > > But it is a fair question to ask if RFC 5304 should be added to the list of > documents updated? It currently is NOT listed - which makes me wonder why > we include RFC 6233 in the list of updated documents. > > I am inclined to not include either in the list of updated documents. > > Please comment. I agree that it is not necessary to formally Update either. ... > > [major] An important clarification, which I don't think is explicitly > > made, is that the behavior for unknown is being applied to disallowed. > > Not knowing and not expecting (= disallowed) are different things, but > > this document is saying that the document treats them the same: > > ignore. I think adding a sentence about that relationship would help > > a lot, and it may help us cover any cases that may have been missed (I > > don't think there are any, but just in case)...maybe something like > > this (I'm sure you can come up with much better words): > > > > This document extends the concept of unknown to disallowed. > > > > > > [major] Related to the last comment... The title of the document > > mentions "Invalid" TLVs. (1) there is no other mention of an invalid > > TLV in the text, and (2) there is no connection made between "invalid" > > (in the title) and "disallowed" (in the text). > > > [Les:] It seems to me that Section 3.1 is very clear on this point. I > prefer not to change/add text as you have suggested. > > I did add some examples of "invalid". As long as it is clear to other reviewers that invalid, disallowed and unknown have the same behavior...we can go ahead with no changes. ... > [Les:] It isn’t clear to me that we have updated RFC3563 - unless you > presume that anything that alters the registries in any way is considered > an update to RFC 3563. > > RFC3563 created the registry based on RFC 3359 - which had the columns in > there. > > The description of the columns is present in this document to provide > context for the rest of the document. I don’t believe this description > represents any change to the registry. > > Specifically, we are not proposing that the registry be altered to include > the description. > > If you agree, should we then remove RFC 3563 from the list of RFCs updated > by this document?? Yes, I agree. BTW, this request.. "IANA is requested to update the TLV Codepoints Registry to reference this document." ...is to add a reference to this document, and not to remove the others, right? If so, then maybe "IANA is requested to add this document as a reference for the TLV Codepoints Registry." might be better. ... > > 215 "The additional values for this TLV should be IIH:n, LSP:y, SNP:n, > > 216 and Purge:y. " > > > > [nit] s/y. "/y." > > [Les:] This is a direct quote from RFC6232. > > Sorry, you don’t get to edit it. 😊 Not editing the quote...just the extra space after the period. ;-) _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
