Voice over IP (VoIP) SIP Peering Use Cases
draft-ietf-speermint-voip-consolidated-usecases-19

[Ballot comment]
The example SIP messages have one bug left in them:

Contact:

isn't valid. The line folding rules make this the same as

Contact:

and that space in the URI is not allowed.

Please either put a easy-to-see warning that this isn't valid, and is an artifact of the requirements RFCs put on formating, or use the  convention from section 2.1 of RFC4475.

[Ballot discuss]
Its not clear whether the call-flows used to depict some of the
use-cases in this document are intended to be one way the use case
could be realized or _the_ way the group is planning to realize the use
case. If it is the latter, the document is bordering on being normative
rather than just informative.  Could you add a short explanation
scoping the applicability of the examples early in the document?

Why does the B2BUA in section 5.2 reset Max-Forwards rather than
continuing to decrement it in step 7?

At step 9 of section 5.2, the T-SBE jumps straight to an A lookup. Why
isn't this going through full RFC3263 resolution?

There is at least one instance of a missing semicolon between
header field parameters when the header field is folded (see Contact in
message 8 on page 17). There are other places where there are spurious
;'s (the first Via at the top of page 10). I suggest a careful check,
if not automated review, of the syntax in the examples.

Some of the comments received (e.g., Ralph's) have not been addressed yet. The authors will submit a new revision addressing all the comments and discusses in the tracker.

[Ballot comment]
Section 5.6 is surprisingly lean as compared to the various static use cases. That may be because it is hard to describe in general terms, but I was expecting a lot more detail there.

[Ballot discuss]
(modified following the discussions in the IESG telechat)

One issue raised by Fred Baker in his OPS-DIR review is worth being considered before this document is approved.

The draft very carefully limits its scope to voice on IP ("VoIP"). The author's first question was how that related to presence and instant messaging. My first question is how that relates to video, which in some systems (Skype, iChat, Marratech, and others) is used in parallel with voice. IMHO, the work is not done unless it also applies to video - and I suspect the use cases are all the same.

I suggest to add explicit text addresses the issue of video or multiple sessions that include video - either by declaring them out of scope in the introduction section (as dome for IM and presence) or by pointing to the use cases that would apply also for video.

[Ballot comment]
Section 5.6 is surprisingly lean as compared to the various static use cases. That may be because it is hard to describe in general terms, but I was expecting a lot more detail there.

[Ballot discuss]
One issue raised by Fred Baker in his OPS-DIR review is worth being considered before this document is approved.

The draft very carefully limits its scope to voice on IP ("VoIP"). The author's first question was how that related to presence and instant messaging. My first question is how that relates to video, which in some systems (Skype, iChat, Marratech, and others) is used in parallel with voice. IMHO, the work is not done unless it also applies to video - and I suspect the use cases are all the same.

[Ballot comment]
Section 5.6 is surprisingly lean as compared to the various static use cases. That may be because it is hard to describe in general terms, but I was expecting a lot more detail there.

[Ballot discuss]
One issues raised by Fred Baker in his OPS-DIR review are worth being considered before this document is approved.

The draft very carefully limits its scope to voice on IP ("VoIP"). The author's first question was how that related to presence and instant messaging. My first question is how that relates to video, which in some systems (Skype, iChat, Marratech, and others) is used in parallel with voice. IMHO, the work is not done unless it also applies to video - and I suspect the use cases are all the same.

[Ballot discuss]
Its not clear whether the call-flows used to depict some of the
use-cases in this document are intended to be one way the use case
could be realized or _the_ way the group is planning to realize the use
case. If it is the latter, the document is bordering on being normative
rather than just informative.  Could you add a short explanation
scoping the applicability of the examples early in the document?

Why does the B2BUA in section 5.2 reset Max-Forwards rather than
continuing to decrement it in step 7?

At step 9 of section 5.2, the T-SBE jumps straight to an A lookup. Why
isn't this going through full RFC3263 resolution?

There is at least one instance of a missing semicolon between
header field parameters when the header field is folded (see Contact in
message 8 on page 17). There are other places where there are spurious
;'s (the first Via at the top of page 10). I suggest a careful check,
if not automated review, of the syntax in the examples.

[Ballot comment]
Is there a specific intended purpose for these use cases: requirements development, guidance to developers/deployers, ???

Sorry for the minor rant, but the phrase "attempts to 'do something useful'" is a hot button for me.  So, I'm going to indulge my inner pedant here.

In the Introduction:

  This document attempts to capture Voice over IP (VoIP) use cases for
  Session Initiation Protocol (SIP) [RFC3261] based peering.

"Attempts to capture" probably isn't a useful result.  How about "describes important Voice over IP (VoIP) use cases, as determined by the SPEERMINT working group, ..."

And, s/SPEERMING/SPEERMINT" in the header...

Draft Name: draft-ietf-speermint-voip-consolidated-usecases-11
Draft File Location:
http://tools.ietf.org/html/draft-ietf-speermint-voip-consolidated-usecas
es-11
Proposed Status: Informational RFC

================================================================
WG Name: Speermint
WG Area: RAI
WG Co-Chairs: Jason Livingood & Daryl Malas
Document Shepherd: Daryl Malas
Shepherding AD: Jon Peterson

================================================================
Document Shepherd Write-Up:
1A. Who is the Document Shepherd for this document?
--Daryl Malas

1B. 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

2A. Has the document had adequate review both from key WG members and
from key non-WG members?
--Yes

2B. Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
--No

3 - 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?
--No

4A. 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.
--No

4B. 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

5 - 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?
--Strong consensus, no outstanding objections. Any objections raised
have been resolved.

6 - 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.)
--No

7A. 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.
--Yes

7B. Has the document met all formal review criteria it needs to, such as
the MIB Doctor, media type, and URI type reviews?
--Yes

7C. If the document does not already indicate its intended status at the
top of the first page, please indicate the intended status here.
--Intended status is Informational RFC

8A. Has the document split its references into normative and
informative?
--Yes

8B. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?
--No

8C. If such normative references exist, what is the strategy for their
completion?
--N/A

8D. Are there normative references that are downward references, as
described in [RFC3967]?
--No

8E. If so, list these downward references to support the Area Director
in the Last Call procedure for them [RFC3967].
--N/A

9A. Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body of the
document?
--Yes

9B. If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries?
--N/A

9C. Are the IANA registries clearly identified?
--N/A

9D. If the document creates a new registry, does it define the proposed
initial contents of the registry and an allocation procedure for future
registrations?
--N/A

9E. Does it suggest a reasonable name for the new registry? See
[RFC2434].
--N/A

9F. 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?
--N/A

10 - 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?
--Yes, N/A in this document.

================================================================
Document Announcement Write-Up:

1 - Technical Summary
This document attempts to capture Voice over IP (VoIP) use cases for SIP
peering. These use cases will assist in identifying requirements and
other issues to be considered for future work in the working group.
This informational document is intended to support the development of
session peering requirements, architecture, and the message flows.

2 - Working Group Summary
There is consensus in the WG to publish this document. Several Working
Group Last Calls have been issued, and we have finally achieved
consensus and resolved all concerns. All changes suggested by the WG
have been made to this draft. A NITS review has also been performed by
our secretary, and those changes made as well.

3 - Document Quality
Good quality - no issues

4 - Personnel
Document Shepherd: Daryl Malas
Responsible AD: Jon Peterson
IANA Experts Required: No

================================================================
END WG PUBLICATION REQUEST
================================================================