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: [email protected] > 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
