[I recently updated my email client and the formatting seems to be broken…. <sigh>]
Greg/authors: ... > Since this document has not yet gone through a WGLC, I will leave some > of the open points below for the WG Chairs to determine which of those > are perhaps more appropriate to consider as part of the WGLC so as to > seek WG inputs. > > Please check inline below for responses with KT. > > One new concern (not previously reported): The document was turned > into experimental status because one part in there was using an > experimental BFD extension. However, the IANA section is asking for > creation of a new registry that has allocations from standards action. > Even the allocation from Return Codes registry is from the standards > action block - perhaps it should be from the other two blocks? I have several points triggered by this comment: (1) The new registry (Table 2) is created in §8.1 and the allocations are made in Table 3. Even though there are 3 values in Table 3, only one (TBD2) is an allocation, the other two are reservations (see §2.2/rfc8126). Table 2 should be updated to reflect the 2 "Reserved" values (which are not part of any other range). Table 3 should contain only the TBD2 value. Because this document creates the registry, IANA doesn't need to be asked to allocate a value; the document can allocate it itself. (2) Table 2 contains several Notes on how the values are to be assigned. Please keep in mind that IANA will be making the allocations and that it may not be obvious to them (as they may not be subject matter experts) if "optional TLVs...require an error message if not recognized", for example. Is there a technical reason for the "Standards Action" ranges to be divided like they are? The other two ranges (both "Specification Required") include a note that reads "Experimental RFC needed". However, that is not congruent with the definition of "Specification Required" [rfc8126]. This policy includes the review of the allocation by a designated expert, so any instructions should be included as instructions to the DEs, and not as notes in the registry. Why is an "Experimental RFC needed"? Note that the language is not related to rfc2119 -- is the expectation a requirement or a recommendation? Any instructions to the DEs should be clear. Note that the current ranges/Notes would leave Informational RFCs without the possibility of having a value assigned. Is that the intent? Why? "RFC Required" may be a more appropriate policy (instead of "Specification Required"). Given the registration policies and the notes, consider adding an Expert Review to all the allocations. (3) As Ketan points out, the TBD3 value (§8.2) cannot come from the "Standards Action" range. It should come from the "RFC Required" range instead. ... > > > 513 - The date when information about this particular implementation was > > > 514 last updated: 12/16/2019 > > > > < minor > The implementation reference is to a very old document version > > that has gone through several changes. Is the "complete" coverage accurate? > > Please consider polling the WG to get an updated implementation status for > > the various BFD flavors/sections in this document. > > > GIM>> The Implementation Status section conveys information about the > > deployment the Non-FEC TLV: > > - Implementation experience: Appreciate Early Allocation of values > > for Non-FEC TLV and SR Policy's Segment List sub-TLV (using Private > > Use code points). > > Other flavors of BFD are outside the scope of this section. > > KT> The implementation section should cover the entire document and > not specific sections. I would assume that the WG chairs will poll the > WG for implementation status of individual features and this gets > updated in the document per SPRING WG policy (even if it says - "no > known implementation"). Ketan is right, the policy is for the Implementation Description to cover the whole draft, including specifics about the MUST/SHOULD clauses. It is up to the authors to collect this information. https://wiki.ietf.org/en/group/spring/WG_Policies Thanks! Alvaro. On December 2, 2024 at 5:03:09 PM, Alvaro Retana (aretana.i...@gmail.com) wrote: On October 21, 2024 at 12:40:55 PM, Ketan Talaulikar wrote:Greg/authors:...> Since this document has not yet gone through a WGLC, I will leave some> of the open points below for the WG Chairs to determine which of those> are perhaps more appropriate to consider as part of the WGLC so as to> seek WG inputs.>> Please check inline below for responses with KT.>> One new concern (not previously reported): The document was turned> into experimental status because one part in there was using an> experimental BFD extension. However, the IANA section is asking for> creation of a new registry that has allocations from standards action.> Even the allocation from Return Codes registry is from the standards> action block - perhaps it should be from the other two blocks?I have several points triggered by this comment:(1)The new registry (Table 2) is created in §8.1, and the allocations are made in Table 3. Although Table 3 contains three values, only one (TBD2) is an allocation; the other two are reservations (see §2.2/rfc8126).Table 2 should be updated to reflect the 2 "Reserved" values (which are not part of any other range).Table 3 should contain only the TBD2 value. Because this document creates the registry, IANA doesn't need to be asked to allocate a value; the document can allocate it.(2)Table 2 contains several Notes on how the values are to be assigned. Please keep in mind that IANA will be making the allocations and that it may not be evident to them (as they may not be subject matter experts) if "optional TLVs...require an error message if not recognized", for example.Is there a technical reason to divide the “Standards Action" ranges like they are?The other two ranges (both "Specification Required") include a note that reads "Experimental RFC needed". However, that is not congruent with the definition of "Specification Required" [rfc8126]. This policy includes the allocation review by a designated expert, so any instructions should be included as instructions to the DEs and not as notes in the registry.Why is an "Experimental RFC needed"? Note that the language is not related to rfc2119 -- is the expectation a requirement or a recommendation? Any instructions to the DEs should be clear.Note that the current ranges/Notes would leave Informational RFCs without the possibility of having a value assigned. Is that the intent? Why?"RFC Required" may be a more appropriate policy (instead of "Specification Required").Given the registration policies and the notes, consider adding an Expert Review to all the allocations.(3)As Ketan points out, the TBD3 value (§8.2) cannot come from the "Standards Action" range. Instead, it should come from the "RFC Required" range....> > > 513 - The date when information about this particular implementation was> > > 514 last updated: 12/16/2019> >> > < minor > The implementation reference is to a very old document version> > that has gone through several changes. Is the "complete" coverage accurate?> > Please consider polling the WG to get an updated implementation status for> > the various BFD flavors/sections in this document.>> > GIM>> The Implementation Status section conveys information about the> > deployment the Non-FEC TLV:> > - Implementation experience: Appreciate Early Allocation of values> > for Non-FEC TLV and SR Policy's Segment List sub-TLV (using Private> > Use code points).> > Other flavors of BFD are outside the scope of this section.>> KT> The implementation section should cover the entire document and> not specific sections. I would assume that the WG chairs will poll the> WG for implementation status of individual features and this gets> updated in the document per SPRING WG policy (even if it says - "no> known implementation").Ketan is right. The policy is that the Implementation Description should cover the whole draft, including specifics about the MUST/SHOULD clauses. It is up to the authors to collect this information. https://wiki.ietf.org/en/group/spring/WG_Policies Thanks!Alvaro.
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
