Forwarded mail - this one got stuck in an IPv6 mail queue to ietf.org,
which appears to be not currently working,
Best wishes,
gorry
-------- Original Message --------
Subject: DTLS over DCCP -05 (Intention to submit to IESG & Write-Up)
Date: Tue, 12 Feb 2008 09:53:22 +0000
From: Gorry Fairhurst <gorry@xxxxxxxxxxxxxx>
Reply-To: gorry@xxxxxxxxxxxxxx
Organization: University of Aberdeen, UK
To: 'dccp' working group <dccp@xxxxxxxx>
<div class="moz-text-flowed" style="font-family: -moz-fixed">Tom (as an
Author),
I'm happy with this new revision. It addresses my concerns,
and note that this also satisfies Pasi's concerned relating to DTLS.
Thanks Tom for taking this forward and writing this draft (!!!)
Thank you also to ALL who read and commented on this draft,
all feedback is very much appreciated by the working group!
I'm ready to forward this to the IESG, and enclose a copy of the
write-up that I intend to submit requesting publication.
Gorry
(DCCP WG Chair)
---
One Minor NiT that should be corrected when next the revision is made:
OLD:
/a DCCP connection could conceivable contain both/
^^^^^^^^^^^^^^^^^
NEW:
/it is conceivable that a DCCP connection could contain both/
^^^^^^^^^^^^^^^^^^^^^^
or (perhaps better?)
/a DCCP connection could contain both/
-----
As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding,
this is the current template for the Document Shepherd Write-Up.
Changes are expected over time. This version is dated February 1, 2007.
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
Gorry Fairhurst (gorry@xxxxxxxxxxxxxx) - DCCP WG Chair
(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?
Yes. Eric Rescorla assisted the original scope and content of this
work within the DCCP WG with a detailed review of issues relating
to use of DCCP by DTLS.
The WGLC revealed some issues with interactions between DCCP and
DTLS PMTUD that were addressed and a new rev. passed through a further
shortened WGLC and received further feedback. The people who made
these extra comments said that they were addressed in the revision
<draft-ietf-dccp-dtls-05.txt>.
The document was externally reviewed by Pasi Eronen during both
WGLCs, and inputs in the early stage were received from Eric Rescorla.
A copy of this write-up was sent to the list.
There are no known implementations of this specification at this time.
(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?
This document relates to security (i.e. DTLS).
(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.
One point of controversy was the recommendations for the use of
Service Codes, which is part of a wider discussion within the DCCP WG.
The text presented for the second WGLC reflected WG consensus on this.
(This debate related to correct use of DCCP, and not to correct
end-to-end operation of the DTLS protocol across DCCP.)
(1.e) 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 is strong support that this work is needed, and consensus that
the work is complete.
(1.f) 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
entered into the ID Tracker.)
No.
(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?
Yes.
(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].
The references have been verified.
(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?
The IANA considerations have been verified.
(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?
Not appropriate.
(1.k) 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
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.
Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?
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?
Technical Summary
This document specifies the use of Datagram Transport Layer Security
(DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS
provides communications privacy for datagram protocols and allows
client/server applications to communicate in a way that is designed
to prevent eavesdropping, tampering, or message forgery. DCCP is a
transport protocol that provides a congestion-controlled unreliable
datagram service.
Working Group Summary
This document is a product of the DCCP working group. The document is
expected to apply to the use of current and future versions of DTLS
over the DCCP transport service.
Document Quality
The DCCP WG has reached consensus that this document is ready for
publication, and recommends publication on the IETF Standards Track.
(end)
</div>
