Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements
draft-ietf-drinks-usecases-requirements-06

[Ballot comment]
I would think that it would be much better if the requirements were complete sentences, but won't hold the document up over it ...

[Ballot comment]
- I was confused by this: "Any request to provision, modify or
delete data is subject to several security considerations (see
Section Section 5).  This document does not address these
considerations. " Section 5 does seem to address the security
considerations so I don't get it?

- Section 5 says that authorization is REQUIRED, which is fine,
but you're not clear on the intended granularity which will make
a huge difference. If you could state e.g. whether or not UC PI#6
(modification of authority) has to be authorized at the level of a
specific phone number that'd make it clear.  As is, you've punted
on this, so may have more trouble getting closure on the
protocol.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Data for Reachability of Inter/tra-NetworK SIP (DRINKS) Use cases and Protocol Requirements) to Informational RFC


The IESG has received a request from the Data for Reachability of
Inter/tra-NetworK SIP WG (drinks) to consider the following document:
- 'Data for Reachability of Inter/tra-NetworK SIP (DRINKS) Use cases and
  Protocol Requirements'
  as an Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document captures the use cases and associated requirements for
  interfaces that provision session establishment data into Session
  Initiation Protocol (SIP) Service Provider components, to assist with
  session routing.  Specifically, this document focuses on the
  provisioning of one such element, termed the registry.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-drinks-usecases-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-drinks-usecases-requirements/


No IPR declarations have been submitted directly on this I-D.

PROTO WRITEUP for draft-ietf-drinks-usecases-requirements-05
============================================================

http://tools.ietf.org/id/draft-ietf-drinks-usecases-requirements-05

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

The document shepherd is Alexander Mayrhofer (alexander.mayrhofer@nic.at).
I have personally reviewed the draft several times, including a final NITS
review, and i believe the document is ready for publication. Some minor
NITS were discovered, but those are editorial only, and will be fixed
asap.

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

The document has been reviewed and commented on by both working group
members and non-WG contributors. There are no concerns regarding the
depth or breath of the reviews. An ongoing implementation of the
related protocol document has not instigated any changes to the
usecases / requirements 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?

There are no concerns that more review is required. As this is an
informational document only that contains no protocol elements, no
"specialized" review is deemed 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.

There are no concerns, and no IPR disclosure has been filed.

  (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 solid concensus among the active participants of the
working group.


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

There is no opposition to this document.

  (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 was NITS reviewed by the Document shepherd, and some
mostly editorial nits were discovered. Those will be addresses asap
in a new revision. The report from the NITS review was posted to the
DRINKS mailing list:

http://www.ietf.org/mail-archive/web/drinks/current/msg00958.html

  (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 references split into normative and informative 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?

There are no IANA considerations.


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

There are no sections in the document that make use of formal language.

  (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 captures the use cases and associated requirements for
  interfaces that provision session establishment data into SIP Service
  Provider components, to assist with session routing.  Specifically,
  the current version of this document focuses on the provisioning of
  one such element, termed the registry.


Working Group Summary

  The WG agreed that for the development of the Session Peering
  Provisioning Protocol, an approach where use cases would drive
  requirements, and requirements in turn would then drive
  protocol development was the right approach. The use cases and
  requirements document has been developed over several (interim)
  meetings, and has not changed over the course of the last half
  year.

Document Quality

  The document is a product of the DRINKS working group.
  It has been reviewed thoroughly by the potential user
  community (telecommunications service providers) who
  are also developing an open source implmentation of
  the respective protocol that is driven by this use case
  document. 


Personnel

    Alexander Mayrhofer is the document shepherd for this document.

PROTO WRITEUP for draft-ietf-drinks-usecases-requirements-05
============================================================

http://tools.ietf.org/id/draft-ietf-drinks-usecases-requirements-05

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

The document shepherd is Alexander Mayrhofer (alexander.mayrhofer@nic.at).
I have personally reviewed the draft several times, including a final NITS
review, and i believe the document is ready for publication. Some minor
NITS were discovered, but those are editorial only, and will be fixed
asap.

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

The document has been reviewed and commented on by both working group
members and non-WG contributors. There are no concerns regarding the
depth or breath of the reviews. An ongoing implementation of the
related protocol document has not instigated any changes to the
usecases / requirements 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?

There are no concerns that more review is required. As this is an
informational document only that contains no protocol elements, no
"specialized" review is deemed 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.

There are no concerns, and no IPR disclosure has been filed.

  (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 solid concensus among the active participants of the
working group.


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

There is no opposition to this document.

  (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 was NITS reviewed by the Document shepherd, and some
mostly editorial nits were discovered. Those will be addresses asap
in a new revision. The report from the NITS review was posted to the
DRINKS mailing list:

http://www.ietf.org/mail-archive/web/drinks/current/msg00958.html

  (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 references split into normative and informative 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?

There are no IANA considerations.


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

There are no sections in the document that make use of formal language.

  (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 captures the use cases and associated requirements for
  interfaces that provision session establishment data into SIP Service
  Provider components, to assist with session routing.  Specifically,
  the current version of this document focuses on the provisioning of
  one such element, termed the registry.


Working Group Summary

  The WG agreed that for the development of the Session Peering
  Provisioning Protocol, an approach where use cases would drive
  requirements, and requirements in turn would then drive
  protocol development was the right approach. The use cases and
  requirements document has been developed over several (interim)
  meetings, and has not changed over the course of the last half
  year.

Document Quality

  The document is a product of the DRINKS working group.
  It has been reviewed thoroughly by the potential user
  community (telecommunications service providers) who
  are also developing an open source implmentation of
  the respective protocol that is driven by this use case
  document. 


Personnel

    Alexander Mayrhofer is the document shepherd for this document.