Shepherd writeup
rfc8175-29

(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?

Proposed Standard is appropriate.  There are many years of experience with similar technologies within industry.  Much of the experience comes in the form of similar but non-standard stand-alone implementations (wi-fi drivers and radio waveforms drivers) but the IETF does have experience with similar drafts pppoe and LMP.

(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:

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions.  In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions.  A bidirectional, event-driven communication channel between the router and the modem is necessary. The DLEP protocol provides this channel by defining signals to be passed between a router and its attached modem devices, allowing the modem to communicate link characteristics as they change, and convergence events (acquisition and loss of potential routing destinations). The signals are used to communicate events that occur on the physical link(s) managed by the modem to the attached routers.

Working Group Summary:

Development of the DLEP document has taken quite some time with a few major revisions along the way.  DLEP has previously passed WGLC but was then sent back to the WG after an extensive RtgDir review.  As a result the document was split into two documents the base specification (this document) and one for a credit windowing extension.  There were also some minor technical changes were made, some major editorial changes were done.

Previous changes of note: the change between UDP based messaging format into a TCP based messaging paradigm, a change of messaging format from RFC5444 (MANET packet building block) to a newly developed DLEP specific packet format, and the change from stateless communication to state-full communication session.  

There is support within the working group on moving this document forward.  Previous areas of contention within DLEP were worked out within the working group with no serious objections regarding the final compromise decisions.

Document Quality:

There are multiple existing implementations of the protocol, the Shepherd knows of at least 4 independant ones.  There is broad support within industry and the Shepard fully expects many more implementations once standardized and well as demand on the customer side.  The document quality was addressed extensively in the RtgDir review and subsequent WG discussions.

Personnel:

Document Shepherd is Justin Dean
Area Director Alvaro Retana
Directorate Reviewer: Lou Burger

(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.

The Shepherd has read the draft document (and multiple previous versions).  Recent updates (after document was sent back to the WG) resolves the shepherds previous concerns about outstanding issues raised in the RgtDir review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(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.

A security review would be appropriate.

(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.

The Shepherd has apprehension about the current security approach but does not have expertise in the area. Regardless the documented security approach has been discussed in depth within the WG.

(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?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(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?

The WG as a whole understands and agrees with it moving forward. There is bimodal support:  Some strongly support moving it forward and others support moving it forward with various small issues (which have been discussed, addressed, and compromised on by the WG)

(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.)

No.

(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.

ID nits was run and there was one formatting error and 4 warnings which can be fixed in the next version.  The error provided was.

** There are 44 instances of too long lines in the document, the longest
     one being 3 characters in excess of 72.
     

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

A RtrDir review has been preformed.  A security review would be appropriate. 

(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?

No.

(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.

No.

(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.

No.

(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).

The document defines 5 new registry spaces and requests a well known port/multicast address.  These registries are clearly identified.  Reasonable names are provided for the new registries.  The newly created registries have a detailed list of initial valid entries.  

(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.

DLEP Signal Type Values
DLEP Message Type Values
DLEP Data Item Values
DLEP Status Code Values
DLEP Extension Type Values

Of the author team S. Ratliff and R. Taylor are most active and knowledgable regarding IETF procedures and would be good expert picks.  All members listed as part of the design team would be appropriate experts.  Lou Berger would also be an appropriate choice.

(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.

None.
Back