[spring] Re: Shepherd review for draft-ietf-spring-bfd-10

[Alvaro Retana <[e-mail]>]

 [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 ([e-mail])
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.