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
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
