[Sip] RE: Publication request for draft-ietf-sip-consent-framework-02.txt
"DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com> Fri, 13 July 2007 13:51 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LY7-0001XD-R2; Fri, 13 Jul 2007 09:51:11 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I9LY5-0001VS-OR for sip-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 09:51:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LY4-0001VF-T9 for sip@ietf.org; Fri, 13 Jul 2007 09:51:08 -0400
Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9LXz-00081P-Rg for sip@ietf.org; Fri, 13 Jul 2007 09:51:08 -0400
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6DDokh9012211 for <sip@ietf.org>; Fri, 13 Jul 2007 08:51:03 -0500 (CDT)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 08:50:34 -0500
Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 15:50:31 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 13 Jul 2007 15:50:31 +0200
Message-ID: <5D1A7985295922448D5550C94DE2918001435C93@DEEXC1U01.de.lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Publication request for draft-ietf-sip-consent-framework-02.txt
Thread-Index: AcfFPSAvaPNehEgOQAaiZexfgDp4VQAF5SvA
From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
To: sip@ietf.org
X-OriginalArrivalTime: 13 Jul 2007 13:50:31.0840 (UTC) FILETIME=[C7811A00:01C7C554]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608
Subject: [Sip] RE: Publication request for draft-ietf-sip-consent-framework-02.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
And before anyone else responds on the first bit of the message below, it should be: http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework-02. txt Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: Friday, July 13, 2007 12:01 PM > To: sip@ietf.org > Subject: Publication request for > draft-ietf-sip-consent-framework-02.txt > > (As WG chair) > > I have just requested publication of: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-14.txt > > The next stage for submitting comments is therefore the IESG > last call. > > The PROTO writeup submitted with the publication request is > as follows. > > Please feel free to respond if you consider any of the > information incorrect. > > Regards > > Keith > > > -------------------------------------------------------------- > ------------- > PROTO writeup for > http://www.ietf.org/internet-drafts/draft-ietf-sip-consent-framework- > 02.txt: "A Framework for Consent-Based Communications in the > Session Initiation Protocol (SIP)" > > (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? > > Keith Drage > > The document has been reviewed and is ready for forwarding to > IESG for publication. > > (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? > > Document history: > > - draft-rosenberg-sipping-consent-framework-00 was > submitted 8th July 2004 and > expired 6th January 2005. > - draft-ietf-sipping-consent-framework-00 was submitted > 18th October 2004 and > expired 18th April 2005. > - draft-ietf-sipping-consent-framework-01 was submitted > 20th February 2005 and > expired 21st August 2005. > - draft-ietf-sipping-consent-framework-02 was submitted > 18th July 2005 and expired > 19th January 2006. > - draft-ietf-sipping-consent-framework-03 was submitted > 5th October 2005 and > expired 8th April 2006. > - draft-ietf-sipping-consent-framework-04 was submitted > 25th February 2006 and > expired 29th August 2006. > - draft-ietf-sipping-consent-framework-05 was submitted > 12th June 2006 and expired > 14th December 2006. > - draft-ietf-sip-consent-framework-00 was submitted 17th > September 2006 and expired > 21st March 2007. > - draft-ietf-sip-consent-framework-01 was submitted 26th > November 2006 and expired > 30th May 2007. > - draft-ietf-sip-consent-framework-02 was submitted 5th > July 2007 and expires 6th > January 2007. > > WGLC was initiated in the SIP WG on > draft-ietf-sip-consent-framework-00 on 25th September > 2006 with comments requested by 17th October 2006. > > Review was made and comments were received from: Jeroen van > Bemmel, Shida Schubert, Ben Campbell, AC Mahendran, Mary > Barnes. During the course of the work comments have also been > made by: Dean Willis, Andrew Allen, Cullen Jennings, Paul > Kyzivat, Adam Roach, Geoffrey Dawirs, Miguel Garcia. > > The document was moved from the SIPPING WG to the SIP WG in > conformance with RFC 3427 because it defines new header > fields and a response code. Prior review and discussion > therefore took place in the SIPPING group. > > Key discussions have taken place about which methods to use > for various parts of the consent framework. > > The document is closely related with: > > - draft-ietf-sipping-consent-format-03; > - draft-ietf-sipping-pending-additions-02; > - draft-ietf-sipping-uri-services-06; > - draft-ietf-sip-uri-list-message-01; > - draft-ietf-sip-uri-list-subscribe-01; > - draft-ietf-sip-uri-list-conferencing-01; > - draft-ietf-sip-multiple-refer-01. > > Both OMA and 3GPP use the uri-list documents (as documented > in their PROTO writeups). As these documents have a mandatory > normative dependence on the consent framework, then they also > need the consent framework. > > (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 document defines mechanisms that are entirely internal to > the Session Initiation Protocol (SIP). The document shepherd > considers that no external review from an external specialist > is necessary, apart from as follows. > > While the document was generated as a result of a request > from security advisers concerning the original uri-list > documents (see above), the document has not had a separate > security review, and that should there occur. > > (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. > > The document defines a new SIP protocol extension for a > particular purpose in a form that has been used for many > other extensions. The document shepherd has no concerns with > the document. > > There have been no IPR disclosures on this document. > > (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? > > While the document has been reviewed by appropriate SIP > experts, the level of readership of the SIP working group has > apparently been low. This may lead one to assume that the > contents for this solution are correct, but potentially there > could have been other solutions out there that have been missed. > > (1.f) Has anyone threatened an appeal or otherwise > indicated extreme > discontent? If so, please summarize 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.) > > None indicated. > > (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? If the document > does not already indicate its intended status at the top of > the first page, please indicate the intended status here. > > The document has been reviewed against the guidelines in RFC > 4485 and it is believed that the document is conformant with > those guidelines. > > While the document defines a new SIP response code, and two > new SIP header fields, these have been performed as a SIP > working group item, and therefore this draft is in > conformance with RFC 3427. > > For ID-NITS the checks against idnits 2.04.09 report no NITS found. > > (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 document has separate sections for normative and > informative references. The normative references have been > checked and found to be normative. > > (1.i) Has the Document Shepherd verified that the document's IANA > Considerations 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 > the Document > Shepherd conferred with the Responsible Area > Director so that > the IESG can appoint the needed Expert during IESG > Evaluation? > > The document defines the following values that require registration: > > * Trigger-Consent header field > * Permission-Missing header field > * target-uri header field parameter to Trigger-Consent > header field > * 470 response code > > Section 6 of the document provides the IANA considerations > section, and this defines the above. > > (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? > > The document defines two items in ABNF (Trigger-Consent and > Permission-Missing). These augment the ABNF defined in RFC 3261. > > Both these items pass Bill Fenner's ABNF parser in the tools webpage. > > (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 the 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? > > Personnel > Who is the Document Shepherd for this document? > Who is the > Responsible Area Director? If the document requires IANA > experts(s), insert 'The IANA Expert(s) for the registries > in this document are <TO BE ADDED BY THE AD>.' > > Technical summary. > > The Session Initiation Protocol (SIP) supports communications > across many media types, including real-time audio, video, > text, instant messaging, and presence. In its current form, > it allows session invitations, instant messages, and other > requests to be delivered from one party to another without > requiring explicit consent of the recipient. > Without such consent, it is possible for SIP to be used for > malicious purposes, including amplification, and DoS (Denial > of Service) attacks. This document identifies a framework > for consent-based communications in SIP. > > Working group summary. > > There is consensus in the working group to publish this > document. The document came about due to security area > concerns about the need to protect against denial of service > attacks and amplification attacks when various relay and > uri-list mechanisms are used in SIP. > > Document Quality > > There has been no indication of implementation. > > Personnel > > The document shepherd for this document was Keith Drage. The > responsible Area Director was Cullen Jennings. 'The IANA > Expert(s) for the registries in this document are <TO BE > ADDED BY THE AD>. > -------------------------------------------------------------- > -------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Publication request for draft-ietf-sip-cons… DRAGE, Keith (Keith)
- [Sip] RE: Publication request for draft-ietf-sip-… DRAGE, Keith (Keith)