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