draft-ietf-lisp-6830bis-32.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 6830, 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 data-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.
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 data-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 6830. 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 -12. 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 18 revisions
(publication was requested for revision 14, now is 32). 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 several independent implementations of the LISP data-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 -32 version of
the document is provided on point 11. There are three unused reference but
these can be deleted while the document is in the RFC Editor queue.
(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 has undergone a through
review in 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 6830,
hence, because this document is largely 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-rfc6830bis-32.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document date (March 5, 2020) is 119 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)
== Unused Reference: 'RFC7833' is defined on line 1753, but no explicit
reference was found in the text
== Unused Reference: 'RFC7835' is defined on line 1760, but no explicit
reference was found in the text
== Unused Reference: 'RFC8111' is defined on line 1778, but no explicit
reference was found in the text
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
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-rfc6833bis and one to
draft-ietf-lisp-6834bis, but these documents passed as well WG Last
Call. Worst case the RFC editor can hold this document in the queue
until there is a RFC number for them.
(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 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 4341 for the LISP Data-Plane. This
document just demands to update the description as follows:
The IANA registry has allocated UDP port number 4341 for the LISP
Data-Plane. IANA has updated the description for UDP port 4341 as
follows:
lisp-data 4341 udp LISP Data Packets
(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.