[Sip] Publication request for draft-ietf-sip-answermode

["DRAGE, Keith \(Keith\)" <[e-mail]>]

(As WG chair)

I have just requested publication of:

http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-04.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-
answermode-04.txt: "Requesting Answering Modes for 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-allen-sipping-poc-p-headers-00 created November 2004,
expired 
May 2005.
-	draft-allen-sipping-poc-p-headers-01.txt created February 7th
2005, 
expired August 8th 2005 (split into two drafts, the one below and a 
separate P-header draft which remained in SIPPING).
-	draft-willis-sip-answeralert-00 created June 14th 2005, expired 
December 16th 2005. Discussed at IETF#63.
-	draft-willis-sip-answeralert-01 created August 31st 2005,
expired 
March 4th 2006. Discussed at IETF#64.
-	draft-ietf-sip-answermode-00 created December 14th 2005, expired
June 
17th 2006.
-	draft-ietf-sip-answermode-01 created April 3rd 2006, expired
October 
3rd 2006.
-	draft-ietf-sip-answermode-02 created March 4th 2007, expires 
September 5th 2007.
-	draft-ietf-sip-answermode-03 created May 10th 2007, expires
November 
11th 2007.
-	draft-ietf-sip-answermode-04 created June 12th 2007, expires
December 
14th 2007.

WGLC was initiated on draft-ietf-sip-answermode-00 on 23rd February 2006
with 
comments requested by 15th March 2006.

Reviews were conducted by and comments received from Hans Persson,
Jeroen 
van Bemmel, and Paul Kyzivat. At least 5 other people commented on
earlier 
versions of the document.

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

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

Section 1 of the document represents the background to the initiation of

this work, and details a strong requirement from OMA for a SIP solution
in 
this area. However uses in the SIP WG were found for a more general 
mechanism. Less generic parts of the original proposal form the basis of
a 
separate draft draft-allen-sipping-poc-p-answer-state-header-04 being 
progressed under the rules of RFC 3427 as a P-header.

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

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 new SIP headers and a new SIP option tag,
these 
have been performed as a SIP working group item, and therefore this
draft is 
in conformance with RFC 3427.

For ID-NITS (idnits 2.04.09) the checks report no errors.

   (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 split its references into normative and informative 
references. All the normative references are now published RFCs. There
are 
no downward references.

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

Section 8 of the document contains the IANA considerations.

Section 8.1 of the document registers the two new SIP header fields that
are 
defined elsewhere in the document. This registration is consistent with
RFC 
3968 which defines the registry and is also consistent with the current 
format of the registry.

Section 8.2 of the document registers two new header field parameters
for 
the new Answer-Mode header field, and which are defined elsewhere in the

document. Section 8.2 of the document also registers the same two new
header 
field parameters for the new Priv-Answer-Mode header field, and again
these 
are defined elsewhere in the document. This registration is consistent
with 
RFC 3968 which defines the registry and is also consistent with the
current 
format of the registry.

Section 8.3 of the document registers a new option-tag; the new
option-tag 
is defined elsewhere in the document. This registration is consistent
with 
RFC 3968 which defines the registry and is also consistent with the
current 
format of the registry.

It has been checked that there are no other protocol elements requiring 
registration.

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

Section 3 of the document specifies the new headers in ABNF. This ABNF 
passes the checks in http://rtg.ietf.org/~fenner/abnf.cgi.

   (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Writeup?  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?

          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

This document defines extends SIP with two header fields and associated 
option tags that can be used in INVITE requests to convey the
requester's 
preference for user-interface handling related to answering of that
request.  
The first header, "Answer-Mode", expresses a preference as to whether
the 
target node's user interface waits for user input before accepting the 
request or instead accepts the request without waiting on user input.
The 
second header, "Priv-Answer-Mode" is similar to the first, except that
it 
requests administrative-level access and has consequent additional 
authentication and authorization requirements.  These behaviors have 
applicability to applications such as Push-to-Talk and to diagnostics
like 
loop-back.  Usage of each header field in a response to indicate how the

request was handled is also defined.

Working Group Summary

There is consensus in the working group to publish this document. The 
proposal was originally submitted as a P-header, but it was decided that

this aspect should be brought out and made generally applicable to all
SIP 
implementations. Early concerns about the possibility to use the header
as a 
means of eavesdropping have been addressed in the security
considerations.

Document Quality

There has been no indication of implementation. The document has been 
required in support of the OMA PoC feature, and it can be assumed that
there 
have been implementations of the OMA work that have therefore used this 
feature.

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip