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

[Dino Farinacci <[e-mail]>]

> 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).

The latter, "LISP DDT Map-Referral".

>> 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?  

Yes, it is important that it is.

>>> 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.

Below? I not sure what text you are referencing?

>> 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.

Yes, you should point to this document.

> 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).  

Ack. Great.

> 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.

Great. Thanks.

Dino