Re: [auth48] AUTH48: RFC-to-be 9492 <draft-ietf-lsr-rfc8920bis-06> for your review

[Acee Lindem <[e-mail]>]

This looks good to me. Most of the AUTH48 changes are related to use of acronyms where they’d be previously defined and references. I noted that since TE is considered well-known (i.e., asterick'ed in the list), it is not expanded in this document. That is fine with me if that is to be the convention for future documents. 

Thanks,
Acee

> On Sep 27, 2023, at 17:14, Madison Church <[e-mail]> wrote:
> 
> Hi Les,
> 
> Thank you for your reply! We have updated the document per your responses. We have a few followup questions/comments.
> 
> 1) Regarding this requested change:
> 
>> 1)Section 5
>> 
>> "Standard Application Identifier Bit Mask:  Optional set of bits,
>>     where each bit represents a single standard application.  Bits are
>>     defined in the "Link Attribute Application Identifiers" registry,
>>     which is defined in [RFC8919]."
>> 
>> The reference should be updated to be the new RFC9479.
> 
> We have updated instances of [RFC8919] to [RFC9479]. Note that RFC-to-be 9479 is in AUTH48; we will publish this document at the same time as RFC-to-be 9479.
> 
> 
> 2) Regarding this requested change:
> 
>> 2)Section 5
>> 
>> "Bit 1 (S-bit):  Segment Routing Policy.  This is data plane
>>       independent."
>> 
>> This format does not match the same text in RFC9479(to be) which is currently shown as:
>> 
>> " S-bit:  Set to specify SR Policy (this is data plane independent)."
>> 
>> My personal preference is to keep the parentheses.
> 
> We have updated the S-bit definition as you suggest above to keep the parentheses; as you note, this matches the format in RFC-to-be 9479. Would you also like to use parentheses for the F-bit definition to match RFC 9479?
> 
> Current in this document:
> Bit 2 (F-bit):  LFA.  Includes all LFA types.
> 
> Current in RFC 9479:
> F-bit:  Set to specify an LFA (includes all LFA types).
> 
> 
> 3) Regarding Question 7:
> 
>> 7) <!-- [rfced] The following expansions are defined more than once
>> throughout the
>> document. May we use the abbreviated form for the following expansions
>> upon
>> first use per Section 3.6 of RFC 7322 ("RFC Style Guide")?
>> 
>> Loop-Free Alternates (LFAs)
>> Standard Application Bit Mask (SABM)
>> Segment Routing (SR)
>> traffic engineering (TE)
>> User Defined Application Bit Mask (UDABM) -->
> 
> Within the definition list in Section 5, we left the expanded forms of “Standard Application Identifier Bit Mask” and “User-Defined Application Identifier Bit Mask” as is to match the field names in the figure directly above.  If you prefer to use the abbreviated forms in the definition list, please let us know. Also, would it be correct to add “field” to the following entries for clarity as shown below?
> 
> Original:
> SABM Length:  Standard Application Identifier Bit Mask Length in octets. 
> 
> UDABM Length:  User-Defined Application Identifier Bit Mask Length in
>    octets. 
> 
> Perhaps:
> SABM Length:  Length of the Standard Application Identifier Bit Mask field in
>    octets. 
> 
> UDABM Length:  Length of the User-Defined Application Identifier Bit Mask 
>    field in octets. 
> 
> 
> Updated XML file:
>   https://www.rfc-editor.org/authors/rfc9492.xml
> 
> Updated output files:
>   https://www.rfc-editor.org/authors/rfc9492.txt
>   https://www.rfc-editor.org/authors/rfc9492.pdf
>   https://www.rfc-editor.org/authors/rfc9492.html
> 
> Diff file showing all changes made during AUTH48:
>   https://www.rfc-editor.org/authors/rfc9492-auth48diff.html
> 
> Diff files showing all changes:
>   https://www.rfc-editor.org/authors/rfc9492-diff.html
>   https://www.rfc-editor.org/authors/rfc9492-rfcdiff.html (side-by-side diff)
> 
> Note that it may be necessary for you to refresh your browser to view the most recent version. 
> 
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9492
> 
> Thank you,
> RFC Editor/mc
> 
>