Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)
draft-ietf-iptel-trunk-group-10

[Ballot comment]
6.  Normative behavior of SIP entities using trunk groups

  In order to satisfy REQ 3, the placement of the trunk group
  parameters in a SIP Contact header or a R-URI, respectively,
  signifies the intent.

I had to read that sentence, and REQ 3, and the following sentence,
several times before I could understand it. But having understood
it, I think it's redundant and confusing.

[Ballot discuss]
This documen suffers from the same problem as the number portability
tel URI extension.  A URI excepted from an untrusted source may change
the routing of calls.  On the PSTN this could have DOS and billing
implications.  On other networks, it could have confidentiality
implications.  The same solution should fix the problem here: add te
xt to the security considerations section noting that when trunk
groups cross trust boundaries, agents should consider whether the
trunk group is still appropriate and if not, remove before forwarding
or procesing.

[Ballot discuss]
The document says:

  For equivalency purposes, two URIs containing trunk group parameters
  are equivalent according to the base comparison rules of the URIs AND
  the values of their "tgrp" and "trunk-context" parameters MUST match.

based on this text above:

  The "trunk-context" and "tgrp" parameter SHOULD use lower-case
  characters as tel URIs may be used within contexts where comparisons
  are case sensitive.

I assume that "MUST match" might be a match using case insensitive string comparison or
a case-sensitive string comparison for the parameter.  It's not clear to me, though, whether
the authors mean to imply that the value of the parameter MUST match according to some
other, stricter set of rules.

Could the authors provide a rational for this?  As it stands, it looks very much like
the normal URI matching rules would be enough for this, and that this extra MUST
repeats something that would already be checked. 

I also recognize that there are cases where a mismatch or perceived mismatch may
change the behavior (if a perceived mismatch occurs at a UAS,for example, the UAS
might proceed as if it were not responsible for the trunk group, as outlined in 6.2),
but I'm not sure that the URI is matching set out clearly for those cases.

[Ballot discuss]
No reply was sent to SecDir Review from Charlie Kaufman.  I'd like
  to see one.  Charlie said:
  >
  > This document standardizes the presentation of information that is
  > currently provided differently in different implementations of the
  > SIP protocol. As such, it doesn’t present any new security issues.
  > In security considerations, the authors note the security
  > implications of an attacker changing this information in transit,
  > and also note that the protocol should be cryptographically
  > protected to mitigate this problem. I would think that a more
  > important threat would be the implications of one participant in
  > the protocol specifying incorrect, invalid, or unauthorized values,
  > in that an implementation must validate received values rather than
  > using them blindly.
  >
  I am especially interested in the answer to the authorization question.

IANA Last call comment:


As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.

Note: this document depends on IANA actions in [draft-ietf-iptel-tel-reg-01.txt]

State Change Notice email list have been change to <jdrosen@cisco.com>, <fluffy@cisco.com>, <vkg@lucent.com> from <jdrosen@dynamicsoft.com>, <fluffy@cisco.com>, <vkg@lucent.com>

PROTO Write-up

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