Samuel Yes the comments at the end work for me
Tom Petch ________________________________________ From: Samuel Sidor (ssidor) <ssi...@cisco.com> Sent: 11 January 2024 12:50 To: tom petch; Dhruv Dhody Cc: pce@ietf.org Subject: RE: [Pce] Any missed comments for draft-ietf-pce-sid-algo Hi Tom, Since you responded to both mails (from me and from Dhruv) together, I'll respond here. Please see inline <S2>. Regards, Samuel -----Original Message----- From: tom petch <ie...@btconnect.com> Sent: Thursday, January 11, 2024 1:25 PM To: Dhruv Dhody <dhruv.i...@gmail.com> Cc: Samuel Sidor (ssidor) <ssi...@cisco.com>; pce@ietf.org Subject: Re: [Pce] Any missed comments for draft-ietf-pce-sid-algo inline <tp2> ________________________________________ From: Dhruv Dhody <dhruv.i...@gmail.com> Sent: 10 January 2024 13:06 Hi Tom, WG, Speaking as a WG member... On Wed, Jan 10, 2024 at 4:30 PM tom petch <ie...@btconnect.com<mailto:ie...@btconnect.com>> wrote: Sent: 10 January 2024 10:18 Hi PCE WG, I would like to ask for WG LC for draft-ietf-pce-sid-algo on behalf of authors. Are there any remaining issues/comments/questions which I (or co-authors) missed and which are not handled yet? URL: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/ <tp> Well new to the PCE list may be I fear but I have a basic problem about 'algorithm'. You reference RFC8665 and RFC 8667. In those it is always SR-Algorithm so I think that that should be the spelling here. Dhruv: The container is SR-ERO and SRv6-ERO where the field "Algorithm" is being added. To me it is clear it is an SR-Algorithm. You will find the similar usage in other RFC i.e.the TLV is called SR-Algorithm TLV but the field inside is just Algorithm. <tp2> You miss my point. in the two RFC it is always SR-Algorithm and never SR Algorithm. The I-D has 53 or so uses of SR Algorithm. I think that they all need changing to SR-Algorithm. This is not grammar; this is being consistent in terminology across the IETF. <S2> Ack, in my previous mail I confirmed that I can change it. I'm for consistency here as well (and especially since it does not cost us anything now). More fundamentally, 8665 sets up an IANA registry with two values, 0 and 1, which tells me that 8665 is out of date as soon as it is published and that all references should be to IANA and not the RFC. The update policy is Standards Action. ADs regard additions to IANA registries as not updating the RFC creating the registry so reading 8665 will not tell you that it is out of date unless you read between the lines of the IANA Considerations and go see what is current. Dhruv: It is usual for one to reference the RFC that created the registry, it is evident there will be future RFCs or documents that add more codepoints; the reference to the original RFC that created the registry is still valid. I don't recall anyone asking to explicitly reference the registry. That said, there is no harm in adding an additional reference to IANA. <tp2> Well I have been around long enough to see multiple IETF WG get into a tangle over IANA registries and then spend a lot of effort trying to clear the confusion. When this I-D is specifying the values that must appear in a protocol field from an IANA registry, e.g. s.3.2, then the reference must be to the IANA registry. The RFC setting up the registry will likeleyo contain additional information about the values and their uses so the RFC should be referenced, sometimes even after the RFC is obsoleted, but not for the protocol field; that way brings trouble in the future from those who are not thorough enough to spot the use of a IANA registry and understand the implications therof. <S2> In my previous response, I confirmed that I should add explicit reference to registry itself. I originally added reference to RFC8665/RFC8667 as those are describing purpose and details of SR-Algorithm, but I agree that finally any value from IANA registry can be used in PCEP as well, so we need to reference registry itself as well. It gets more problematic. The IANA registry was updated by RFC9350 which keeps the same update criteria but splits the range into two 0-127 and 128-255, the latter being flexible. s.4.2.1 talks of Flexible Algorithm with a Normative reference to RFC9350 which begs the question as to the relationship between SR Algorithm and Flexible Algorithm when used in this document. Either/or, Synonyms? Here and now it may all be obvious but in years to come with multiple algorithms in use it will likely be unclear what you are referencing in s.3.2, s.3.3, s.3.4; is it the range 0-127 or 0-255 or 128-255 or...? Dhruv: It is 0-255! Authors can make that explicit in the I-D. <tp2> Well yes and no. I think but am not sure that Flexible Algorithm is values 128-255 and s.3.4 supports that view, at least implicitly. I think that 4.2.1 should be explicit e.g. 'When the value of fthe Algorithm is in the range 128-255, i.e. Flexible Algorithm, ...' Tom Petch </tp2> <S2> This document is by default talking about complete SR-Algorithm range. Only exception is s.4.2.1, which is specified to 128-255 and that is already clarified in s.3.4 (which is explicitly excluding 0-127 and explicitly pointing to s.4.2.1). I can still add explicit statement to the beginning of s.4.2.1 to limit scope to Flexible Algorithms. To summarize - changes to be done to this draft: - replace "SR algorithm" with "SR-Algorithm" - add explicit reference to IANA registry on top of existing references to RFCs, which are defining values in that registry - add explicit statement to beginning of s.4.2.1 to clarify that it is applicable to 128-255 range only Would that work for you? </S2> Thanks! Dhruv Tom Petch Thanks a lot, Samuel _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
