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

[Madison Church <[e-mail]>]

Hi Les,

Thank you for your reply! We have updated the document accordingly and noted your approval on the AUTH48 status page for this document (http://www.rfc-editor.org/auth48/rfc9492).

We will await approvals from each of the parties listed at the AUTH48 status page prior to moving this document forward in the publication process.

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 (comprehensive diff)
   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.

Thank you!
RFC Editor/mc

> On Sep 27, 2023, at 5:31 PM, Les Ginsberg (ginsberg) <[e-mail]> wrote:
> 
> Madison -
> 
> I have reviewed the changes since last revision - they have all been done to my satisfaction.
> Thanx.
> 
> This revision has my approval - pending the very minor changes discussed below.
> Responses inline.
> 
>> -----Original Message-----
>> From: Madison Church <[e-mail]>
>> Sent: Wednesday, September 27, 2023 2:14 PM
>> To: Les Ginsberg (ginsberg) <[e-mail]>; Peter Psenak (ppsenak)
>> <[e-mail]>; [e-mail]; [e-mail];
>> [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: AUTH48: RFC-to-be 9492 <draft-ietf-lsr-rfc8920bis-06> for your
>> review
>> 
>> 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?
>> 
> [LES:] Yes please.
> 
>> 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?
> 
> [LES:] No - please do NOT add "field". Leave the text as is.
> This is consistent with RFC 9479.
> 
>   Les
> 
>> 
>> 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
>> 
>