draft-ietf-lisp-6833bis-27.txt Document Write-up
As required by RFC 4858, this is the current template for the Document Shepherd
Write-Up.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?
This draft is targeting Standard Track publication. It is the proper type of
RFC, since is the evolution of RFC 6833, which is experimental and is one of
items in the LISP WG charter. The RFC type is indicated in the page header.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary:
The document provides the specifications for the control-plane of LISP
(Locator/Id Separation Protocol). LISP defines two namespaces,
End-point Identifiers (EIDs) that identify end-hosts and Routing
Locators (RLOCs) that identify network attachment points. In this way,
LISP effectively separates control from data, and allows routers to
create overlay networks. LISP-capable routers exchange encapsulated
packets according to EID-to-RLOC mappings stored in a local Map-Cache.
Mappings are distributed using a mapping distribution service. This document
defines the front-end of such service, leveraging on the LISP Map-Server and
LISP-Map-Resolver elements.
Working Group Summary:
The current LISP WG charter has as main task porting the main LISP
specifications on Standard Track. The WG has decided to focus on two
main documents, one with the specifications of the data-plane and the
other with the specifications of the control-plane. This document
concerns the control-plane. The WG has showed support to the document
from its first submission as individual draft and adopted it right
away. On the technical side there was agreement in the WG and little
discussion took place, mainly related include some
features/improvements not present in RFC 6833 and adding text that
originally was in the LISP data-plane document. On the organisation of
the document, more specifically on what to put in the data-plane
document and what to put in the control-plane document there has been
quite some discussion. The current version is the trade-off the WG
achieved and for which clear consensus has been reached. The version of
the document that was approved during WG Last Call is -10. As a
shepherd I required a few editorial changes to the document to fix some
nits.
Post-Publication Request Summary:
After requesting publication the document went through IESG review. The
document raised several question from the Security and Transport Area ADs. In
order to solve the issues raised the document went through 16 revisions
(publication was requested for revision 11, now is 27). All revisions have
been also presented in the LISP WG so to be sure that the group was aware of
all changes and that there were no objections. No concerns were raised by the
LISP WG. All issues seem to be addressed. That is why a new Internet reviews
has been performed so to check whether there are concerns from the IETF
community.
Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?
There are at least three independent implementations of the LISP
control-plane.
Personnel:
Who is the Document Shepherd?
Luigi Iannone <ggx@gigix.net>
Who is the Responsible Area Director?
Deborah Brungard <db3546@att.com>.
(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
I closely followed the document while in the WG and afterwards as a shepherd
during IESG review. The document has improved a lot in quality thanks to the
IESG and the authors working together. As previously stated, document changes
have been always presented to the LISP WG to make sure that the updated do not
raise any concern. The output of the IDnits tool for the -27 version of the
document is provided on point 11. The following issues easily fixable have been
found:
- The draft header indicates that this document obsoletes RFC6833, but the
abstract doesn't seem to directly say this. It does mention RFC6833
though, so this could be OK.
==> Actually it obsoletes 6830 and 6833 as correctly written in
header+abstract+intro. It appears to be a limitation of the IDnitstool.
- Missing Reference: 'Key ID' is mentioned on line 1088, but not defined
=> Not actually a reference the IDnits tool is misled by the use of
brackets.
- 3 Unused references: Can be deleted while in the RFC Editor queue.
- 8 Outdated references, from which 3 are normative but are documents that
already past the WG Last Call, hence, the RFC Editor will fix it zith the
right RFC numbers.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
As the document shepherd I have no concerns.
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
No broader review is required for this document. It went under a through
reviewduring the last year.
(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.
I have no specific concerns or issues to point out.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?
All authors have made conforming IPR disclosure.
(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
No IPR disclosures have been filed concerning this specific document.
However, there is an IPR disclosure filled by Huawei on RFC 6833,
hence, because this document is based on that one, the same IPR
disclosure may relate to this document.
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
There has been clear strong consensus behind this document, showing that the
WG as a whole understand and agree with it and no objection have been raised
during the document review.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Nobody did show extreme discontent nor threatened an appeal.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.
idnits 2.16.04
/tmp/draft-ietf-lisp-rfc6833bis-27.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 3 characters in excess of 72.
-- The draft header indicates that this document obsoletes RFC6833, but the
abstract doesn't seem to directly say this. It does mention RFC6833
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document date (January 9, 2020) is 175 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'Key ID' is mentioned on line 1088, but not defined
== Unused Reference: 'I-D.meyer-loc-id-implications' is defined on line
2165, but no explicit reference was found in the text
== Unused Reference: 'RFC2104' is defined on line 2178, but no explicit
reference was found in the text
== Unused Reference: 'RFC6234' is defined on line 2192, but no explicit
reference was found in the text
== Outdated reference: A later version (-06) exists of
draft-ietf-lisp-6834bis-04
== Outdated reference: A later version (-32) exists of
draft-ietf-lisp-rfc6830bis-28
== Outdated reference: A later version (-20) exists of
draft-ietf-lisp-sec-19
== Outdated reference: A later version (-03) exists of
draft-ietf-lisp-ecdsa-auth-02
== Outdated reference: A later version (-06) exists of
draft-ietf-lisp-eid-mobility-05
== Outdated reference: A later version (-16) exists of
draft-ietf-lisp-gpe-14
== Outdated reference: A later version (-07) exists of draft-ietf-lisp-mn-06
== Outdated reference: A later version (-05) exists of
draft-ietf-lisp-pubsub-04
Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No formal review is required.
(13) Have all references within this document been identified as
either normative or informative?
Yes.
(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?
There are no normative references in unclear state. For clarification,
there is a normative reference to draft-ietf-lisp-rfc6830bis,
draft-ietf-lisp-rfc6834bis, draft-ietf-lisp-sec,
draft-ietf-lisp-rfc8113bis. These documents passed as well WG Last
Call. draft-ietf-lisp-rfc6830bis is in IESG hands.
draft-ietf-lisp-rfc6834bis and draft-ietf-lisp-sec are waiting for the
shepherd writeup, but they have been hold back to make sure that any
change due to modifications in 6830bis and 6833bis are included in the
documents before submitting them to the IESG.
draft-ietf-lisp-rfc8113bis is already in the RFC Editor queue.
The RFC Editor will put the right RFC number in all documents.
(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.
There are no downward normative references.
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.
This document will obsolete RFC 6833 and RFC 6830, as mentioned in the
header, abstract and introduction.
(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).
IANA already allocated UDP port number 4342 for the LISP Data-Plane. This
document just ask for the following change:
The IANA registry has allocated UDP port number 4342 for the LISP
Control-Plane. IANA has updated the description for UDP port 4342 as
follows:
Keyword Port Transport Layer Description
------- ---- --------------- -----------
lisp-control 4342 udp LISP Control Packets
This document ask IANA to the LISP Packet Type Codes by adding the
following entry:
Name Number Defined in
---- ------ -----------
LISP Map-Notify-Ack 5 RFC6833bis
This document ask IANA to create and populate the following registries:
- LISP Map-Reply EID-Record Action Codes
- LISP Bit Flags
This document demands IANA to remove the following registry:
- LISP Address Type Codes
This document demands IANA to modify the name of the registry "LISP Key ID
Numbers"; to be updated with "LISP Algorithm ID Numbers".
(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.
No expert review is required.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
The document does not contain anything written in a formal
language, hence, no validation and/or check has been
performed.