Re: [auth48] [C381] AUTH48: RFC-to-be 9301 <draft-ietf-lisp-rfc6833bis-31> for your review

[Alanna Paloma <[e-mail]>]

Dino, Luigi, and *Alvaro,

Thank you for your replies.  We have updated as requested.

Luigi and *Alvaro (AD) - This query requires your review/approval: 

>> 14) <!-- [rfced] Section 5.4:  
>> 
>> [AD] Version 30 was approved; we were notified that version 31 was available 
>> earlier this year.  Please review and let us know if you approve the new text.
>> The update can easily be seen here: 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6833bis-31.txt
>> 
>> Authors, we could not locate the indicated procedures in draft-ietf-lisp-6834bis.
>> Please clarify for readers where in draft-ietf-lisp-6834bis (perhaps a section 
>> number) this information can be found.
>> 
>> Original:
>> Map-Version Number:  When this 12-bit value in an EID-record of a
>>   Map-Reply message is non-zero, follow the procedures in
>>   [I-D.ietf-lisp-6834bis] for details. -->
> 
> Luigi needs to answer this question.

Dino and authors, please see some follow-up queries and notes below:

1) Regarding the following, value 6 will stay in the spec. Please confirm which form should be used for the Message: “LISP Map-Referral” or “LISP DDT Map-Referral" (note that the IANA registry uses the latter with “DDT” included).

>> 11) <!-- [rfced] Section 5.1: We believe there may be a discrepancy in the 
>> Message name for code 6.  Specifically, should "DDT" be part of the Message?  
>> Please review and let us know if an update is needed. 
>> 
>> Current (document):
>>  | LISP Map-Referral                 | 6    | b'0110'          |
>> 
>> IANA:
>> 6 	LISP DDT Map-Referral (TEMPORARY - registered 2017-04-19, extension registered 2022-04-13, expires 2023-04-19) 	[RFC8111]
>> 
>> 
>> IANA registry: https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-packet-types
>> -->
> 
> Yes, this is very important that value 6 stay in this spec. The WG decided on this a long time ago when the control plane registry was created.

2) Please review the citation in the sentence below and let us know which section number should be included for clarity.

>> 21) <!-- [rfced] Section 5.8:  This sentence is difficult to follow, as
>> we only see one instance of the word "procedure" (used in the
>> singular) in draft-ietf-lisp-sec and could not find the relevant
>> information.  Please clarify for readers where in draft-ietf-lisp-sec
>> (perhaps a section number) this information can be found.
>> 
>> Original:
>> S:    This is the Security bit.  When set to 1, the field following
>>      the 'Reserved' field will have the following Authentication
>>      Data format and follow the procedures from [I-D.ietf-lisp-sec]. -->
> 
> Your change is fine.

3) Please clarify if the IANA registry should be updated to include both a reference to this document and RFC 6830.

>> 34) <!-- [rfced] This document says the the references to 6830 should be 
>> updated to point to this document and RFC 6830.  However, the IANA registry 
>> seems to only refer this document.  Please review and let us know if this 
>> document or the IANA site needs to be updated. 
>> 
>> Original: 
>>  IANA is                               
>>  requested to replace the [RFC6830] reference for this registry with                          
>>  the RFC number assigned to this document and [RFC6830].
>> 
>> IANA registry: https://www.iana.org/assignments/lisp-parameters
>> -->
> 
> Looks good.


4) FYI - Per your response to use “Drop/Auth-Failure”, we will ask IANA to update the description for value 5 accordingly.

> 35) <!-- [rfced] Section 12.3: The text describing the additions to the 
> ACT values refers to both "Drop/Authentication-Failure" and "Drop/Auth-Failure".  
> We see occurrences of both outside of the IANA Considerations as well.  Please 
> review and let us know which is correct.  Note that IANA has registered value 5 
> as "Drop/Authentication-Failure".  We will request that IANA update their 
> registry as needed. 
> 
> See https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-act-value
> 
> Original: 
> This                                
> specification changes the name of ACT type 3 value from "Drop" to                            
> "Drop/No-Reason" as well as adding two new ACT values, the "Drop/
> Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5).  

5) We have updated the sentence below as follows. Please review and let us know if the new text is correct or if further changes are needed. 

Current text: 
   In addition, LISP has a number of flag fields and reserved fields,
   such as the flags of the LISP header fields [RFC9300].

>> 36) <!-- [rfced] Section 12.3:  Does "LISP header flags field" mean
>> "LISP header 'Flags' field" as shown in the "OH" and "IH" portions
>> of the figure in Section 5.1 of draft-ietf-lisp-rfc6830bis (now
>> RFC-to-be 9300), or something else?  Please clarify.
>> 
>> Original:
>> In addition, LISP has a number of flag fields and reserved fields,
>> such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. -->
> 
> In 9300 there isn't a flags field. There are fields each with their own flag. They are labeled individually. We here are referring to all of them.

The files have been posted here (please refresh):
  https://www.rfc-editor.org/authors/rfc9301.xml
  https://www.rfc-editor.org/authors/rfc9301.txt
  https://www.rfc-editor.org/authors/rfc9301.html
  https://www.rfc-editor.org/authors/rfc9301.pdf

The relevant diff files have been posted here:
  https://www.rfc-editor.org/authors/rfc9301-diff.html (comprehensive diff)
  https://www.rfc-editor.org/authors/rfc9301-auth48diff.html (AUTH48 changes)

Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.

We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.

For the AUTH48 status of this document, please see:
  https://www.rfc-editor.org/auth48/rfc9301

Thank you,
RFC Editor/ap

> On Sep 16, 2022, at 11:00 AM, Dino Farinacci <[e-mail]> wrote:
> 
>> Authors,
>>> 
>>> While reviewing this document during AUTH48, please resolve (as necessary) 
>>> the following questions, which are also in the XML file.
>> 
>> Thanks for the effort and edits. See my comments inline.
> 
> I have looked over https://www.rfc-editor.org/authors/rfc9301-rfcdiff.html and here are
> my comments. Your text is in image form, indented, and my comments follow.
> 
>> <PastedGraphic-20.png>
> 
> "LISP encapsulated packet" does not need to be hypenated as you changed to "LISP-encapsulated". Can you put it back to the original?
> 
>> <PastedGraphic-21.png>
> 
> As mentioned in my previous reply, "Native-Forward" is okay to be used. And you can change
> everywhere. 
> 
> Thanks a lot,
> Dino