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

Top commenting on a few of the points, as co-chair.

1) With regard to LISP-DDT, the allocation issue has been resolved with 
the help of the document authors, IANA, our AD, and the RPC staff. 
Formally, we have made an early allocation for the code point DDT needs. 
  This gives us two years to get DDT onto the standards track.

2) My recommendation regarding the NAT Traversal would be to leave the 
Info_Request / Info_Reply to the NAT Traversal document.  We can use the 
early allocation approach there if we still deem NAT traversal as 
experimental when we finish it.

3) As far as I can tell, having this document update the references for 
the IANA table seems to be both appropriate and useful.

Yours,
Joel

PS: If we decide that the Standard track requirement for the registry is 
too onerous, we can relax it.  I would prefer not to do so, and it would 
take another RFC, but we can if we have to.

On 5/2/17 4:21 PM, Dino Farinacci wrote:
> 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
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>