Subject: [Iptel] I-D ACTION:draft-ietf-iptel-trunk-group-08.txt

From: [email-masked]
Date: Tue, 16 May 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Telephony Working Group of the IETF.

	Title		: Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs)
	Author(s)	: C. Jennings, V. Gurbani
	Filename	: draft-ietf-iptel-trunk-group-08.txt
	Pages		: 17
	Date		: 2006-5-16
	
This document describes a standardized mechanism to convey trunk
   group parameters in sip and tel Uniform Resource Identifiers (URIs).
   An extension to the tel URI is defined for this purpose.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-iptel-trunk-group-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-iptel-trunk-group-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 May 2006 03:10:49 -0400

I've just sent a note to IESG asking them to consider this version for 
PS. Folks may be familiar with the proto process 
(http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-06.txt), 
which requires the WG chair to help move the document along. As part of 
this, I do a writeup that describes the history of the document. Here is 
the writeup I sent, FYI.

Thanks,
Jonathan R.

[email-masked] wrote:

> ------------------------------------------------------------------------
> 
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com
  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?  Which chair is the WG
        Chair Shepherd for this document?

Yes, the chair (Jonathan Rosenberg) has personally reviewed this
version of the document. The chair believes the I-D is ready to
forward for publication. The sole chair is the shepherd.

 1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The document has had review from key WG members. Besides a detailed
review from the chair, the document was reviewed after IETF 61 from
Rohan Mahy and Tom Taylor. Between the three, this brings adequate
review of both telephony issues (Tom's speciality) along with general
SIP and URI issues (Jonathan and Rohan). There are no concerns
regarding lack of depth or breadth of reviews.

The document has not had a review from outside of the working group.

1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, internationalization,
        XML, etc.)?

No. The document needs reviews from experts in SIP and telephony, and
it has had those.

   1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

The primary source of discomfort for the chair is merely that the
document (and many of the others produced by the working group) serve
the purpose of 'leaking' various pieces of PSTN functionality into
SIP. However, there is no disagreement that the problem addressed by
this specification needs to be resolved, nor is there dispute that
this specification represents the best way to solve it at this
time. It would just be nice if we didn't have to address these kinds of
problems. Unfortunately we do.

  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?

Working group consensus is good. The group agreed to adopt the item in
early 2003. The group itself is relatively small with just a few
active participants. However, amongst those who do participate, the
draft has good support and it has not been contentious.

 1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.  (It should be
        separate email because this questionnaire will be entered into
        the tracker).

No.

   1.g) Have the chairs verified that the document checks out against
        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
        Boilerplate checks are not enough; this check needs to be
        thorough.

Yes.

  1.h) Has the document split its references into normative and
        informative? 

Yes.

        Are there normative references to IDs, where the
        IDs are not also ready for advancement or are otherwise in an
        unclear state? 

No. All normative references are to RFCs.

        The RFC Editor will not publish an RFC with
        normative references to IDs (will delay the publication until
        all such IDs are also ready for RFC publicatioin).  If the
        normative references are behind, what is the strategy for their
        completion?  On a related matter, are there normative references
        that are downward references, as described in BCP 97, RFC 3967
        RFC 3967 [RFC3967]? 

No.

        Listing these supports the Area Director in
        the Last Call downref procedure specified in RFC 3967.

   1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

The trunk group extension to the tel URI defines two new URI
parameters for use with the tel URI (defined in RFC 3966). These two
new URI parameters, "tgrp" and "trunk-context" indicate the name and
namespace scope for a trunk group. A trunk group is a collection of
circuits in the Public Switched Telephone Network (PSTN) which are
managed as a group. One trunk group, for example, can be used for toll
free calls, while another one used for calls to a certain carrier, and
another for calls to a certain local calling area. Consequently, when
connecting calls from the PSTN into a VoIP network, and connecting
calls from a VoIP network into the PSTN, it is necessary to convey
trunk group information in the VoIP domain. For example, a SIP proxy
may route a call towards a PSTN gateway, and need to indicate that a
specific trunk group should be used. As another example, a call from a
PSTN gateway towards a SIP proxy might need to indicate that the call
arrived from a specific trunk group, so that the SIP proxy might make
appropriate call routing decisions.

The specification defines the syntax for these parameters, matching
rules, and usage of them with SIP.

        *    Working Group Summary

The draft is a charter item of the IP Telephony (iptel) working group,
and is targeted for Proposed Standard. It was adopted as a working
group item in early 2003 and discussed on the mailing list and in many
meetings since its adoption.

        *    Protocol Quality

The specification has been implemented in many products and there are
known deployments of it. The specification itself has received reviews
from telephony experts as well as SIP experts. 
_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel