Re: [lisp] Do we need a 8113bis?

[Dino Farinacci <[e-mail]>]

Here is the proposed changes to rfc6833bis to reflect the enclosed comments. Please let me know if these changes are acceptable.

I am not sure if we should delete the Address Type Registry. Maybe it shoudl be stated that all address types use values from the AFI Registry. Comments?

Dino

> On May 4, 2017, at 11:55 PM, [e-mail] wrote:
> 
> Re-,
> 
> I checked the new version and do still think IANA section needs work. 
> 
> I won't reiterate those related to the type messages. Below some more comments: 
> 
> * LISP ACT values: there is mismatch between the values in the core text and those in the IANA registry. The bis document should make it clear what actions are required to align both.
> 
> Actions for the following are needed:
> 
>      (3) Drop/No-Reason:  A packet that matches this map-cache entry is
>          dropped.  An ICMP Destination Unreachable message SHOULD be
>          sent.
> 
>      (4) Drop/Policy-Denied:  A packet that matches this map-cache
>          entry is dropped.  The reason for the Drop action is that a
>          Map-Request for the target-EID is being policy denied by
>          either an xTR or the mapping system.
> 
>      (5) Drop/Authentication-Failure:  A packet that matches this map-
>          cache entry is dropped.  The reason for the Drop action is
>          that a Map-Request for the target-EID fails an authentication
>          verification-check by either an xTR or the mapping system.
> 
> * What is the point in adding flag bits into an IANA section (7.2) while no IANA action is required out there?
> 
> * Section "LISP Address Type Codes" discuses LCAF, which is managed in a distinct registry (and it is out of scope of this document). The current "LISP Address Type Codes" registry is empty, btw.
> 
> * "LISP Algorithm ID Numbers": There is no such registry. Are you referring to the old "LISP Key ID Numbers". In such case, the text should make it clear what action are you requiring from IANA.
> 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Dino Farinacci [mailto:[e-mail]]
>> Envoyé : vendredi 5 mai 2017 08:25
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : [e-mail] list
>> Objet : Re: [lisp] Do we need a 8113bis?
>> 
>> I am going to wait for direction from the chairs/AD before making anymore
>> changes. I have posted what I thought was a decent compromise that brought
>> in ideas from various commenters.
>> 
>> Dino
>> 
>>> On May 4, 2017, at 11:15 PM, <[e-mail]>
>> <[e-mail]> wrote:
>>> 
>>> Re-,
>>> 
>>> The bis document can update these entries and/or add new entries without
>> updating RFC8113. Otherwise we would need to update that RFC each time
>> there is a document asking for a new assignment (5-7 or 9-14)!
>>> 
>>> Please add a note to the IANA section to ask IANA to update the
>> references for these entries to the bis document.
>>> 
>>> Thank you.
>>> 
>>> Cheers,
>>> Med
>>> 
>>> De : lisp [mailto:[e-mail]] De la part de Dino Farinacci
>>> Envoyé : jeudi 4 mai 2017 20:57
>>> À : [e-mail] list
>>> Objet : [lisp] Do we need a 8113bis?
>>> 
>>> Since the reference in RFC8113 points to RFC6830 for Packet Type
>> definitions and we are moving them from RFC6830 to RFC6833bis for the
>> data-plane/control-plane document separation effort, should we not have a
>> RFC8113bis that points to RFC6883bis?
>>> 
>>> And then RFC8113bis can put in the updated list from RFC6833bis.
>> Comments?
>>> 
>>> Dino
>>> 
>>> 
>>> <image003.png>
>>> 
>>> 
>>> 
>>> <image004.png>
>