Re: [lisp] I-D Action: draft-ietf-lisp-rfc6833bis-03.txt

[Dino Farinacci <[e-mail]>]

See comments inline. I am going to need help from the chairs and Deborah perhaps on some of these items.

>> standard track document as per RFC8113. Such considertaons are not covered
>> in the the bis document.
>> 
>> The type values that are listed are for messages that ARE ALREADY in the
>> protocol. So please tell me what part of the wording you don’t agree with.
>> 
> [Med] OK. Your proposed modification says "summarizes for IANA the LISP Type codes assigned by this document". 
> * Assignment are made by IANA not documents.
> * NEW assignment requests are to be included in a dedicated IANA sub-section. 

That is what Joel suggested.

> 
>>> RFC8113
>>>> is authoriative for Type 15 sub-type values.
>>> 
>>> [Med] Not only for that, but also for allocating future type values.
>> 
>> RFC8113 should not be used for future Type values.
> 
> [Med] I'm afraid there is a misunderstanding here. Please check https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-packet-types. The bis should follow RFC8113 for new assignment requests. 

Registries provide code-points and from the above URL you can see there is a refernece to RFC6830 which we are changing to RFC6833bis so we can have the most recent information documented.

>> Yes, and the registry points to an RFC. And it should be RFC6833bis which
>> is on standards track.
> 
> [Med] My point Dino is that we need to avoid including stale information in RFCs. We have other tools to better track assignments than RFC. 

RFC6833bis is a large effort to bring things current. We are removing stale information and updating with the latest information.

>> NAT-traversal is a critical part of the LISP architecture when IPv4 is
>> used as the underlay. And there are several implementations of NAT-
>> travesal, so this is a case where the Info-Request/Info-Reply is an
>> existing mechanism.
>> 
> 
> [Med] I'm aware of that, Dino. My comments are:
> 
> * Info-Request/Info-Reply is not defined in this document. 
> * There is no reference where Info-Request/Info-Reply.

I can add a refernce. We do have I-D.ermagan-lisp-nat-traversal in the Informative Reference section but no pointer to it. It got lost in the shuffle of doing the bis documents. Good catch.

> If you think that Info-Request/Info-Reply is a mechanism that should be in the base spec, then consider including that part of the spec in the bis document. Lacking that, I reiterate my comments. 

It depends on too much NAT-traversal machinery. It would make the base spec very large. 

I would like the chairs to comment about putting a reference in RFC6833bis to a non-working NAT-traversal document.

>> 
>> That is going to change in the coming weeks since LISP-DDT is about to
>> come to RFC 8111.
> 
> [Med] The RFC-to-be 8111 can't change that for the following reason:
> 
> 
> Internet Engineering Task Force (IETF)                         V. Fuller
> Request for Comments: 8111                   VAF.NET Internet Consulting
> Category: Experimental                                          D. Lewis
>          ^^^^^^^^^^^^
> ISSN: 2070-1721                                               V. Ermagan
>                                                           Cisco Systems
>                                                                 A. Jain
>                                                        Juniper Networks
>                                                              A. Smirnov
>                                                           Cisco Systems
>                                                              April 2017
> 
> 
>   Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)
> 
> Type assignments require "Standards Action”.

Chairs? Deborah? 

> 
> 
>> 
>> Your subsequent email said you have concerns with my update. So please be
>> more specific and include your comments in another email.
> 
> [Med] My pending comments are: 
> * Add a new IANA sub-section for new type assignment requests. This section should include a request for "Map-Notify-Ack" with a preferred value of 5.

Why call out a single message type. It will make the document look incremental and date it. The IANA request is for all types. They just need to be updated and point to RFC6833bis.

Chairs? Deborah?

> * Remove "For Future Assignment" entry from the table of Section 4.1

You have resolve this with Joel.

> * Remove LISP Info-Request/Reply from Section 4.1.

I would like to hear others comment about this.

> * Consider changing the "Current allocations are" wording as this may not be accurate in the future. 

I don’t think they can change to be honest. There are implementations out there. We have to be practical.

Thanks,
Dino