Hi Alvaro, thank you for your comments and suggestions. I will work on updating the draft and share the working version.
Regards, Greg On Mon, Dec 2, 2024 at 2:12 PM Alvaro Retana <aretana.i...@gmail.com> wrote: > [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
