Subject: [Iptel] Review of draft-ietf-iptel-trunk-group-02

From: "Brian Rosen" <[email-masked]>
Date: Mon, 20 Dec 2004 19:23:31 -0500

I've reviewed this draft for readiness to advance to the IESG.

I don't find any substantive issues with the draft from a protocol point of
view.

As RFC text, the following changes would make a better document

1. Define trunk group, at least informally, at the beginning of the Problem
Statement.

2. The problem statement could use substantial rewording.  Pointing out the
need to specify a trunk group is sufficient.  At the very least, that point
should be ahead of where you put the parameter.  Think about how this reads
3 years from now as an RFC.

A self reference should use "this document", although I think the RFC editor
fixes things like that.

3. I think REQ1 would be better expressed as "A trunk group parameter MUST
be defined as an extension to the TEL uri".  That makes the second paragraph
make more sense.

4. The last paragraph in 4.2 is misplaced.  It's actually normative text for
the parameter itself.  You can discuss a solution here, but you can't make
it be the MUST language for the extension itself.  This might be the only
thing I think we have to fix.  This mistake is common to several of the
requirements, but this one is the only one I spotted that does not have
normative text elsewhere.

5. The local/global discussion is confusing, because "global" in this
context is not the "global" in a tel uri.  As best I can tell, you mean to
use "phone context" with some guaranteed globally unique name space, like a
domain name.  You can't just say "use phone-context" and get global out of
that.  More text is needed to explain what you are trying to accomplish with
global context.

6. Consider changing the language at the end of 4.2 to mirror that in the
tel uri.  RFC3966 says "If a recipient of
   the URI intends to place a call to the local number, it MUST
   understand the context and be able to place calls within that
   context."

It doesn't say you ignore phone context.  Actually, it's silent on what you
do when you get one that you don't understand.  I'm not really thrilled with
letting the call go through ignoring the parameter.

7. In the security section, it says if you don't want to reveal trunk group,
hide it.  This puzzles me.  How do you hide a parameter to a tel uri?  Did
you mean "not use it"?  

8. You can now update the reference to 2806bis as RFC3966 (YAY!)

9. Nits
Section 3, could use a spacer between the two definitions
	Also, might want to lose the subgroup exception since you didn't
		define subgroup
Section 4.1 lose the reference to RFC2806 (it gets deleted entirely from the
reference section), since 3966 obsoletes it.

Section 5  Missing comma:
GW3 has only one trunk group configured, TG3-1
                                       ^

The following text is awkward:
   On requests arriving to the proxy from GW1, the proxy will have
   access to the trunk group TG1-1 if the request arrived on that
   particular trunk

The proxy always has access to trunk group TG1-1.  If a call arrives on that
group and the proxy wants to let a downstream entity know that, then it puts
the parameter on the Contact header.

Section 8
Extra space in
   security concerns beyond those already enumerated in [3] .
                                                           ^

Section 11 should be dropped sometime

Brian

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 21 Dec 2004 09:18:13 -0600

Brian Rosen wrote:
> I don't find any substantive issues with the draft from a protocol 
> point of view.

Brian:

I very much appreciate your time on this.

Your review comments will be folded in the next rev.

Thank you for a thorough review!

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216