We seem to be Done with the DTLS-SRTP Framework!
Here's the draft writeup for draft-ietf-sip-dtls-srtp-framework-03.
Please report any problems (like, maybe I cut-and-pasted the wrong
buffer again) to me and to the list. Thanks!
(1.a) Who is the Document Shepherd for this document?
SIP co-chair Dean Willis will act as the protocol 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?
Yes.
The SIP working group would like to request publication of the
standards-track document draft-ietf-sip-dtls-srtp-framework-03. Here's
the shepherd's writeup.
(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?
Yes. The document has been closely followed in several working groups,
and by several security-focused persons.
Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
The reviews appear to be adequate.
(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?
The reviews appear to be adequate.
(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.
There were some concerns about the level of authentication
provided by this document in the face of E.164 numbers and
damage to RFC 4474 Identity done by SBCs. This was extensively
discussed in the WG and the compromise that was reached was
that this document would include a carefully crafted description
of the security properties it provided.
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.
No.
(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?
The WG as a whole understands this document and the consensus
that it should move forward was reasonably strong.
(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?
There are several outdated references that can be corrected in the RFC
Editor process, but that do not otherwise impact this
specification. There are also some example IP addresses that are
inconsistent with current guidelines. An RFC Editor note will be
provided to correct these errors.
(1.h) Has the document split its references into normative and
informative?
Yes.
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].
There is a normative reference to the informational-track RFC 3325. AS
this document provides the most widely-implemented mechanism for
identity expression in SIP and the security provided by this
specification is greatly dependent on the identity mechanism, a full
understanding of the limitations of RFC 3325 is required in order to
understand the impact to this specification if used with RFC 3325.
1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document?
This document has no IANA considerations.
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?
N/A.
(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?
N/A.
(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
This document is part of a suite of documents that specify a
mechanism for keying the Secure Real-time Transport Protocol (SRTP)
using Datagram Transport Layer Security (DTLS). Together, these
protocols provide for in-band establishment of secure multimedia
sessions without dependencies on external authentication
infrastructures. This document specifies the SIP framework for
DTLS-SRTP. A companion document, draft-ietf-avt-dtls-srtp,
specifies the SRTP portion.
Working Group Summary
This document is a product of the Session Initiation Protocol
(SIP) Working Group. It was developed in response to coordinated
meetings held with several working groups, and in consideration of
several competing specifications.
Document Quality
There are at least two known implementations of earlier versions of
this draft, one Open Source and one commercial. Several
implementors have expressed interest in implementation and
deployment of the final version.
Personnel
The Document Shepherd for this document is Dean Willis, and the
responsible Area Director is Cullen Jennings.
RFC Editor Note to Accompany Pub Request:
RFC Editor:
Please replace all occurrences of the string "192.168.1" with "192.0.2".
Please replace references to RFC 3280 with references to RFC 5280.
Please replace references to RFC 3546 with references to RFC 4366.
Please update any -draft references as appropriate.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
