From exim@www1.ietf.org  Wed Jan  7 15:44:48 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00090
	for <iptel-archive@odin.ietf.org>; Wed, 7 Jan 2004 15:44:48 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKXM-0008IW-EC
	for iptel-archive@odin.ietf.org; Wed, 07 Jan 2004 15:44:20 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i07KiKY0031892
	for iptel-archive@odin.ietf.org; Wed, 7 Jan 2004 15:44:20 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKXM-0008IJ-A9
	for iptel-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 15:44:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00081
	for <iptel-web-archive@ietf.org>; Wed, 7 Jan 2004 15:44:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKXK-0002TA-00
	for iptel-web-archive@ietf.org; Wed, 07 Jan 2004 15:44:18 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKVY-0002Oc-00
	for iptel-web-archive@ietf.org; Wed, 07 Jan 2004 15:42:29 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKUG-0002Il-00
	for iptel-web-archive@ietf.org; Wed, 07 Jan 2004 15:41:08 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AeKUF-0007EK-IQ
	for iptel-web-archive@ietf.org; Wed, 07 Jan 2004 15:41:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKUB-00083D-8x; Wed, 07 Jan 2004 15:41:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeKTe-00080r-Eu
	for iptel@optimus.ietf.org; Wed, 07 Jan 2004 15:40:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29710
	for <iptel@ietf.org>; Wed, 7 Jan 2004 15:40:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKTZ-0002ET-00
	for iptel@ietf.org; Wed, 07 Jan 2004 15:40:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeKS2-00024r-00
	for iptel@ietf.org; Wed, 07 Jan 2004 15:38:52 -0500
Received: from cypress.neustar.com ([209.173.57.84])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeKNW-0001pw-00
	for iptel@ietf.org; Wed, 07 Jan 2004 15:34:10 -0500
Received: from chiimc01.npac.com (chiimc01.neustar.com [10.32.90.4])
	by cypress.neustar.com (8.12.8/8.11.6) with ESMTP id i07KX54P030520;
	Wed, 7 Jan 2004 20:33:08 GMT
Received: by chiimc01.cis.neustar.com with Internet Mail Service (5.5.2653.19)
	id <CNZMT4BF>; Wed, 7 Jan 2004 14:33:15 -0600
Message-ID: <4F29BE4689992A4B994A440C3EC924DB012D4FF6@stntexch01.cis.neustar.com>
From: "Yu, James" <james.yu@neustar.biz>
To: "'Flemming Andreasen'" <fandreas@cisco.com>
Cc: list iptel <iptel@ietf.org>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Iptel] RE: Comments on draft-yu-tel-url-08
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Wed, 7 Jan 2004 14:33:05 -0600
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

Flemming,

Thanks for the comments.  Please see the responses below.  I'll wait for a
few days to see if there are additional comments before issuing the
revision.

Jonathan, I assume that the next version would be
draft-ietf-iptel-tel-parameters-00.txt.  

James

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Friday, December 12, 2003 9:16 PM
> To: Yu, James; list iptel
> Subject: Comments on draft-yu-tel-url-08
> 
> 
> I've taken a closer look at the draft-yu-tel-url-08.txt and have some
> questions and comments on it.
> 
> Non-Editorial Comments:
> - The document is fairly focused on how you can use the tel-URL
> extensions defined here in SIP. At least in the Abstract and 
> Section 1,
> I'd suggest loosening this coupling a bit as the subject of 
> the document
> is the tel-URL extensions rather than how to use them with 
> SIP. Also, it
> might be worthwhile making it clear, that these extensions can be used
> with any protocol that happens to make use of the tel-URL, 
> e.g. H.323 as
> well. In line with this, I'd suggest removing Section 8.

[YU] Will modify so that the document is not too SIP-specific.

> 
> - Lack of requirements: While reading through the document, I 
> felt that
> the document was a bit "loose" in some places and relied on the reader
> just knowing how these things work. It then occurred to me, that there
> is not a single RFC 2119 requirements word to be found in the document
> which doesn't seem quite right. I'd suggest taking another pass and
> adding some RFC 2119 requirement words throughout (or at least in
> Section 5 where firmer language and additional detail is generally
> needed).

[YU] Will use appropriate requirement language when discussing the
preference in using the parameters for routing decisions.

> 
> - JIP Parameter: It is listed in the Abbreviations section but not
> referenced in the doc. That's of course a minor issue but there is a
> bigger issue of whether we should have support for the JIP 
> parameter as
> I don't believe you have full support for LNP without it (billing
> problem when originator has been ported if I understand correctly).

[YU] Will remove.

> 
> - Section 5, second last paragraph states that:
>    "The "CIC" can be expanded to include VoIP carriers and other types
>    of carriers in the same country or under the same country code so
>    that all carriers can be identified in the IP domain for routing
>    purpose."
> I don't quite understand what this means. Is this something 
> the document
> defines and if so how ? Either way, this should be clarified.

[YU] Will clarify.  "CICs" in the U.S. are only assigned to certain PSTN
carriers.  This paragraph indicates that other types of carriers may be
assigned the CICs for routing in the IP domain.

> 
> - Section 6.1, last paragraph:    I don't follow the 
> recommendation. The
> example just above the text that talks about "the example described
> above" does not show the "rn" parameter, and if the "rn" parameter is
> not included in the previous example, I'm not sure how it would work.
> Please elaborate.

[YU] Will clarify.  The example does not show "rn."   But technically, it
could include "rn" that carries the called party number.  The recommendation
is not to include it.

> 
> - Section 9: The security considerations should provide guidelines for
> how to remedy the threats identified.

[YU] Will add texts to clarify that the applications/protocols that carry
the tel URL with those parameters may need to support data integrity to
prevent those parameters from being modified.

> 
> 
> General editorial comments:
> - There are numerous format/conversion problems throughout 
> the document
> (doesn't look like pure ASCII).

[YU] Please be more specific (e.g., point out a few problems).

> - Use of commas and periods inside or outside double-quotes. This is
> clearly a style issue with no universally agreed upon rules, 
> but clarity
> argues for placing them outside the quotes when you are referencing a
> literal value rather than quoting a piece of text, i.e. "rn," should
> rather be "rn", IMO.

[YU] I'll leave it to the group to decide the format to use.  I've been
following this rule  (e.g., "rn." instead of "rn". when the sentence ends
with "rn") from a book/an article that I don't remember its name now.

> - Should probably also reference Security Considerations 
> section at the
> end of Section 1.

[YU] Will add.

> - The document treats POTS and free-phone numbers as two different
> things; are they ? See for example, Section 1, 2nd paragraph.

[YU] POTS numbers usually refer to the geographic numbers (e.g., Plain Old
Telephone Service or POTS does not include freephone service).  I can change
"POTS numbers" to "geographical E.164 numbers" if there is no objection.

> - The document talks about the extensions as being 
> "proposed". May want
> to reword to "defined" or something like that.
> 

[YU] Will change.

> 
> Detailed editorial comments:
> 
> p. 1
> OLD: ABTRACT
> NEW: ABSTRACT
> 

[YU] Will change.

> Section 1, 3rd paragraph
> OLD: associate
> NEW: associated
> 

[YU] Will change.

> Abbreviations:
> OLD: Telephony Routing Information Protocol
> NEW: Telephony Routing over IP
> 

[YU] Will change (also in the reference section).

> OLD: Uniform Resource Locators
> NEW: Uniform Resource Locator
> 

[YU] Will change.

> Section 4, 2nd and 3rd paragraph (i.e. twice)
> 
> OLD: POT number
> NEW: POTS number
> 

[YU] Will change unless "POTS number" is changed to "geographical E.164
number."

> Section 5, ABNF
> OLD: ";rn"
> NEW: "rn"
> 

[YU] Will change.

> Section 5, 2nd paragraph after ABNF:
> OLD: identify a country code
> NEW: identify an E.164 country code
> 

[YU] Will change.

> Section 5, 4th paragraph after ABNF:
> The sentence:
>    "It is also possible that the SIP protocol can be used for the NP
> query.
>    In that case, the response (e.g., 302 Moved) to the SIP message may
>    carry the NP related information in the "tel" or "sip" URL format
>    with the parameters proposed in this document."
> doesn't belong in this document IMO (unless you want to define that
> mechanism here as well).

[YU] Will delete.

> 
> Section 5, 5th paragraph after ABNF:
>    "A new address family in the Telephony Routing Information Protocol
> (TRIP)[7] has
>    been defined for cic."
> Where is this defined - is there a reference ?
>

[YU] Will change to refer to 
http://www.ietf.org/internet-drafts/draft-ietf-iptel-tgrep-02.txt.
 
> Regards
> 
>        Flemming
> 
> 

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Wed Jan  7 17:27:27 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09693
	for <iptel-archive@odin.ietf.org>; Wed, 7 Jan 2004 17:27:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeM8i-0005gf-Fr
	for iptel-archive@odin.ietf.org; Wed, 07 Jan 2004 17:27:00 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i07MR0qm021860
	for iptel-archive@odin.ietf.org; Wed, 7 Jan 2004 17:27:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeM8g-0005gV-TZ
	for iptel-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 17:26:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09685
	for <iptel-web-archive@ietf.org>; Wed, 7 Jan 2004 17:26:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeM8Z-0004d4-00
	for iptel-web-archive@ietf.org; Wed, 07 Jan 2004 17:26:51 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeM36-0004Qt-00
	for iptel-web-archive@ietf.org; Wed, 07 Jan 2004 17:21:13 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeLzN-0004Gp-00
	for iptel-web-archive@ietf.org; Wed, 07 Jan 2004 17:17:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeLz3-0005OA-1A; Wed, 07 Jan 2004 17:17:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AeBTp-0003jR-J3
	for iptel@optimus.ietf.org; Wed, 07 Jan 2004 06:04:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02722
	for <iptel@ietf.org>; Wed, 7 Jan 2004 06:04:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeBTl-0001Ic-00
	for iptel@ietf.org; Wed, 07 Jan 2004 06:04:01 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AeBSA-0001Ed-00
	for iptel@ietf.org; Wed, 07 Jan 2004 06:02:22 -0500
Received: from smtp6.clb.oleane.net ([213.56.31.26])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeBRf-00017y-00
	for iptel@ietf.org; Wed, 07 Jan 2004 06:01:51 -0500
Received: from oleane ([194.206.151.59]) 
	by smtp6.clb.oleane.net with SMTP id i07B1MO0028369
	for <iptel@ietf.org>; Wed, 7 Jan 2004 12:01:22 +0100
Message-ID: <026401c3d50e$9268b560$0601a8c0@www.oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <iptel@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0261_01C3D516.F3F321A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Subject: [Iptel] WiFi Voice Conference - Paris
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Wed, 7 Jan 2004 12:08:25 +0100
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE 
	autolearn=no version=2.60

C'est un message de format MIME en plusieurs parties.

------=_NextPart_000_0261_01C3D516.F3F321A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The WiFi Voice Conference will stand in Paris next May 25 to 28, 2004.
QoS, security, roaming, interoperability, architectures : distinguished =
experts=20
and key players in the field will address these questions with detailed =
and=20
technical explanations.=20
=20
More details at:
http://www.upperside.fr/wifivoice04/wifivoice04intro.htm

------=_NextPart_000_0261_01C3D516.F3F321A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>The WiFi Voice Conference will stand in Paris next =
May 25 to=20
28, 2004.<BR>QoS, security, roaming, interoperability, architectures :=20
distinguished experts <BR>and key players in the field will address =
these=20
questions with detailed and <BR>technical explanations. =
<BR>&nbsp;<BR>More=20
details at:<BR></FONT><A=20
href=3D"http://www.upperside.fr/wifivoice04/wifivoice04intro.htm"><FONT=20
size=3D2>http://www.upperside.fr/wifivoice04/wifivoice04intro.htm</FONT><=
/A></DIV></BODY></HTML>

------=_NextPart_000_0261_01C3D516.F3F321A0--


_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Thu Jan  8 11:45:18 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02343
	for <iptel-archive@odin.ietf.org>; Thu, 8 Jan 2004 11:45:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AedH8-00023i-DR
	for iptel-archive@odin.ietf.org; Thu, 08 Jan 2004 11:44:50 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i08GioWA007909
	for iptel-archive@odin.ietf.org; Thu, 8 Jan 2004 11:44:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AedH8-00023T-2J
	for iptel-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 11:44:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02312
	for <iptel-web-archive@ietf.org>; Thu, 8 Jan 2004 11:44:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AedH6-0007Pk-00
	for iptel-web-archive@ietf.org; Thu, 08 Jan 2004 11:44:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AedFW-0007JO-00
	for iptel-web-archive@ietf.org; Thu, 08 Jan 2004 11:43:11 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AedER-0007BL-00
	for iptel-web-archive@ietf.org; Thu, 08 Jan 2004 11:42:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AedEP-0001wq-1R; Thu, 08 Jan 2004 11:42:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AedDU-0001qL-Ea
	for iptel@optimus.ietf.org; Thu, 08 Jan 2004 11:41:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02006
	for <iptel@ietf.org>; Thu, 8 Jan 2004 11:41:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AedDT-00079G-00
	for iptel@ietf.org; Thu, 08 Jan 2004 11:41:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AedCQ-0006sc-00
	for iptel@ietf.org; Thu, 08 Jan 2004 11:40:00 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aed5M-0006BY-00
	for iptel@ietf.org; Thu, 08 Jan 2004 11:32:40 -0500
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i08GVfLE021024;
	Thu, 8 Jan 2004 11:31:42 -0500 (EST)
Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166])
	by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AWB64252;
	Thu, 8 Jan 2004 08:31:37 -0800 (PST)
Message-Id: <4.3.2.7.2.20040108105834.00b22ba8@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: "Yu, James" <james.yu@neustar.biz>
From: Michael Hammer <mhammer@cisco.com>
Subject: Re: [Iptel] RE: Comments on draft-yu-tel-url-08
Cc: "'Flemming Andreasen'" <fandreas@cisco.com>, list iptel <iptel@ietf.org>
In-Reply-To: <4F29BE4689992A4B994A440C3EC924DB012D4FF6@stntexch01.cis.ne
 ustar.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Thu, 08 Jan 2004 11:31:36 -0500
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

James,

I have a couple editorial comments:

It might be useful to mention the new parameters created by name in the 
Abstract to enable someone searching on a parameter name to quickly 
identify this as the relevant document.

It might be useful to fully separate the syntax definitions from the 
procedural definitions.  Many other documents have a section heading that 
is simply X Syntax.

It may help the reader if the procedures are divided into separate sections 
for each parameter or by each type of action that may be rendered on a 
parameter.  E.g. what does an initiator (UAC) v. modifier/user (Proxy) v. 
recipient (UAS) do with each parameter?  Much of this is already there, 
just suggesting a little more structure to help reader locate relevant text 
more quickly.  Currently, this material is spread over section 1, 3, 4, 5, 
6, and 7, with normative rules being perhaps spread across all of those 
sections.  I would suggest:
Section 1 introduction
Section 3 syntax definition
Section 4 normative rules
Section 5 service examples

Section 10: Provide a specific URL reference to the IANA registry 
location.  I browsed through there recently and did not see anything, so 
presumable this will create it?

Section 12: It seemed odd that this draft would make a normative 
modification to the syntax of another document, yet list that other 
document as informative (ref [4]).  Also, could these be renumbered?

Thanks,
Mike


At 02:33 PM 1/7/2004 -0600, Yu, James wrote:
>Flemming,
>
>Thanks for the comments.  Please see the responses below.  I'll wait for a
>few days to see if there are additional comments before issuing the
>revision.
>
>Jonathan, I assume that the next version would be
>draft-ietf-iptel-tel-parameters-00.txt.
>
>James
>
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Friday, December 12, 2003 9:16 PM
> > To: Yu, James; list iptel
> > Subject: Comments on draft-yu-tel-url-08
> >
> >
> > I've taken a closer look at the draft-yu-tel-url-08.txt and have some
> > questions and comments on it.
> >
> > Non-Editorial Comments:
> > - The document is fairly focused on how you can use the tel-URL
> > extensions defined here in SIP. At least in the Abstract and
> > Section 1,
> > I'd suggest loosening this coupling a bit as the subject of
> > the document
> > is the tel-URL extensions rather than how to use them with
> > SIP. Also, it
> > might be worthwhile making it clear, that these extensions can be used
> > with any protocol that happens to make use of the tel-URL,
> > e.g. H.323 as
> > well. In line with this, I'd suggest removing Section 8.
>
>[YU] Will modify so that the document is not too SIP-specific.
>
> >
> > - Lack of requirements: While reading through the document, I
> > felt that
> > the document was a bit "loose" in some places and relied on the reader
> > just knowing how these things work. It then occurred to me, that there
> > is not a single RFC 2119 requirements word to be found in the document
> > which doesn't seem quite right. I'd suggest taking another pass and
> > adding some RFC 2119 requirement words throughout (or at least in
> > Section 5 where firmer language and additional detail is generally
> > needed).
>
>[YU] Will use appropriate requirement language when discussing the
>preference in using the parameters for routing decisions.
>
> >
> > - JIP Parameter: It is listed in the Abbreviations section but not
> > referenced in the doc. That's of course a minor issue but there is a
> > bigger issue of whether we should have support for the JIP
> > parameter as
> > I don't believe you have full support for LNP without it (billing
> > problem when originator has been ported if I understand correctly).
>
>[YU] Will remove.
>
> >
> > - Section 5, second last paragraph states that:
> >    "The "CIC" can be expanded to include VoIP carriers and other types
> >    of carriers in the same country or under the same country code so
> >    that all carriers can be identified in the IP domain for routing
> >    purpose."
> > I don't quite understand what this means. Is this something
> > the document
> > defines and if so how ? Either way, this should be clarified.
>
>[YU] Will clarify.  "CICs" in the U.S. are only assigned to certain PSTN
>carriers.  This paragraph indicates that other types of carriers may be
>assigned the CICs for routing in the IP domain.
>
> >
> > - Section 6.1, last paragraph:    I don't follow the
> > recommendation. The
> > example just above the text that talks about "the example described
> > above" does not show the "rn" parameter, and if the "rn" parameter is
> > not included in the previous example, I'm not sure how it would work.
> > Please elaborate.
>
>[YU] Will clarify.  The example does not show "rn."   But technically, it
>could include "rn" that carries the called party number.  The recommendation
>is not to include it.
>
> >
> > - Section 9: The security considerations should provide guidelines for
> > how to remedy the threats identified.
>
>[YU] Will add texts to clarify that the applications/protocols that carry
>the tel URL with those parameters may need to support data integrity to
>prevent those parameters from being modified.
>
> >
> >
> > General editorial comments:
> > - There are numerous format/conversion problems throughout
> > the document
> > (doesn't look like pure ASCII).
>
>[YU] Please be more specific (e.g., point out a few problems).
>
> > - Use of commas and periods inside or outside double-quotes. This is
> > clearly a style issue with no universally agreed upon rules,
> > but clarity
> > argues for placing them outside the quotes when you are referencing a
> > literal value rather than quoting a piece of text, i.e. "rn," should
> > rather be "rn", IMO.
>
>[YU] I'll leave it to the group to decide the format to use.  I've been
>following this rule  (e.g., "rn." instead of "rn". when the sentence ends
>with "rn") from a book/an article that I don't remember its name now.
>
> > - Should probably also reference Security Considerations
> > section at the
> > end of Section 1.
>
>[YU] Will add.
>
> > - The document treats POTS and free-phone numbers as two different
> > things; are they ? See for example, Section 1, 2nd paragraph.
>
>[YU] POTS numbers usually refer to the geographic numbers (e.g., Plain Old
>Telephone Service or POTS does not include freephone service).  I can change
>"POTS numbers" to "geographical E.164 numbers" if there is no objection.
>
> > - The document talks about the extensions as being
> > "proposed". May want
> > to reword to "defined" or something like that.
> >
>
>[YU] Will change.
>
> >
> > Detailed editorial comments:
> >
> > p. 1
> > OLD: ABTRACT
> > NEW: ABSTRACT
> >
>
>[YU] Will change.
>
> > Section 1, 3rd paragraph
> > OLD: associate
> > NEW: associated
> >
>
>[YU] Will change.
>
> > Abbreviations:
> > OLD: Telephony Routing Information Protocol
> > NEW: Telephony Routing over IP
> >
>
>[YU] Will change (also in the reference section).
>
> > OLD: Uniform Resource Locators
> > NEW: Uniform Resource Locator
> >
>
>[YU] Will change.
>
> > Section 4, 2nd and 3rd paragraph (i.e. twice)
> >
> > OLD: POT number
> > NEW: POTS number
> >
>
>[YU] Will change unless "POTS number" is changed to "geographical E.164
>number."
>
> > Section 5, ABNF
> > OLD: ";rn"
> > NEW: "rn"
> >
>
>[YU] Will change.
>
> > Section 5, 2nd paragraph after ABNF:
> > OLD: identify a country code
> > NEW: identify an E.164 country code
> >
>
>[YU] Will change.
>
> > Section 5, 4th paragraph after ABNF:
> > The sentence:
> >    "It is also possible that the SIP protocol can be used for the NP
> > query.
> >    In that case, the response (e.g., 302 Moved) to the SIP message may
> >    carry the NP related information in the "tel" or "sip" URL format
> >    with the parameters proposed in this document."
> > doesn't belong in this document IMO (unless you want to define that
> > mechanism here as well).
>
>[YU] Will delete.
>
> >
> > Section 5, 5th paragraph after ABNF:
> >    "A new address family in the Telephony Routing Information Protocol
> > (TRIP)[7] has
> >    been defined for cic."
> > Where is this defined - is there a reference ?
> >
>
>[YU] Will change to refer to
>http://www.ietf.org/internet-drafts/draft-ietf-iptel-tgrep-02.txt.
>
> > Regards
> >
> >        Flemming
> >
> >
>
>_______________________________________________
>Iptel mailing list
>Iptel@ietf.org
>https://www.ietf.org/mailman/listinfo/iptel


_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Thu Jan  8 12:35:43 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03325
	for <iptel-archive@odin.ietf.org>; Thu, 8 Jan 2004 12:35:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aee3w-0004Mo-K5
	for iptel-archive@odin.ietf.org; Thu, 08 Jan 2004 12:35:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i08HZGx3016780
	for iptel-archive@odin.ietf.org; Thu, 8 Jan 2004 12:35:16 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aee3w-0004MZ-El
	for iptel-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 12:35:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03304
	for <iptel-web-archive@ietf.org>; Thu, 8 Jan 2004 12:35:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aee3f-0001vx-00
	for iptel-web-archive@ietf.org; Thu, 08 Jan 2004 12:34:59 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AedwV-0001eh-00
	for iptel-web-archive@ietf.org; Thu, 08 Jan 2004 12:27:36 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AeduM-0001UU-00
	for iptel-web-archive@ietf.org; Thu, 08 Jan 2004 12:25:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aedu2-0003vm-KR; Thu, 08 Jan 2004 12:25:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aedtn-0003vH-5c
	for iptel@optimus.ietf.org; Thu, 08 Jan 2004 12:24:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03118
	for <iptel@ietf.org>; Thu, 8 Jan 2004 12:24:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aedtf-0001Tm-00
	for iptel@ietf.org; Thu, 08 Jan 2004 12:24:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aednp-0001IG-00
	for iptel@ietf.org; Thu, 08 Jan 2004 12:18:38 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aedl5-00017j-00
	for iptel@ietf.org; Thu, 08 Jan 2004 12:15:47 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i08HF3e26925
	for <iptel@ietf.org>; Thu, 8 Jan 2004 11:15:04 -0600 (CST)
Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2)
	id i08HF3K27802; Thu, 8 Jan 2004 11:15:03 -0600 (CST)
Message-ID: <3FFD900A.3040502@lucent.com>
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Wireless Networks Research and Development
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: list iptel <iptel@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Iptel] Trunk-group I-D
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Thu, 08 Jan 2004 11:14:50 -0600
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Folks:

I have just submitted the trunk-group I-D to the I-D editor.
Until it becomes available in the archives, you can get a
copy from:

http://www.iit.edu/~gurbvij/I-D/draft-ietf-iptel-trunk-group-01.html
http://www.iit.edu/~gurbvij/I-D/draft-ietf-iptel-trunk-group-01.txt

Comments/feedback sought.

Thanks,

- 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



_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Fri Jan  9 14:58:09 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29996
	for <iptel-archive@odin.ietf.org>; Fri, 9 Jan 2004 14:58:09 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Af2Vu-0003B5-2p
	for iptel-archive@odin.ietf.org; Fri, 09 Jan 2004 14:41:46 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i09JfkwJ012209
	for iptel-archive@odin.ietf.org; Fri, 9 Jan 2004 14:41:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Af2Vt-0003Aq-TI
	for iptel-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 14:41:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28602
	for <iptel-web-archive@ietf.org>; Fri, 9 Jan 2004 14:41:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Af2Uq-0006eO-00
	for iptel-web-archive@ietf.org; Fri, 09 Jan 2004 14:40:40 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Af1dD-0004yS-00
	for iptel-web-archive@ietf.org; Fri, 09 Jan 2004 13:45:18 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Af1Ft-0007Ld-01
	for iptel-web-archive@ietf.org; Fri, 09 Jan 2004 13:21:09 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1Af0pM-00075S-JN
	for iptel-web-archive@ietf.org; Fri, 09 Jan 2004 12:53:44 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Af0pB-0003HP-G7
	for iptel-web-archive@ietf.org; Fri, 09 Jan 2004 12:53:33 -0500
Date: Fri, 09 Jan 2004 12:53:33 -0500
Message-ID: <20040109175333.9164.31337.Mailman@www1.ietf.org>
Subject: ietf.org mailing list memberships reminder
From: mailman-owner@www1.ietf.org
To: iptel-web-archive@ietf.org
X-No-Archive: yes
X-Ack: no
Sender: mailman-admin@ietf.org
Errors-To: mailman-admin@ietf.org
X-BeenThere: mailman@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no 
	version=2.60

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, iptel-request@ietf.org) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

***************************************************************************


                              Note Well

All statements related to the activities of the IETF and addressed to
the IETF are subject to all provisions of Section 10 of RFC 2026,
which grants to the IETF and its participants certain licenses and
rights in such statements. Such statements include verbal statements
in IETF meetings, as well as written and electronic communications
made at any time or place, which are addressed to

        * the IETF plenary session,
        * any IETF working group or portion thereof,
        * the IESG, or any member thereof on behalf of the IESG,
        * the IAB or any member thereof on behalf of the IAB,
        * any IETF mailing list, including the IETF list itself, any
working
            group or design team list, or any other list functioning
under IETF
            auspices,
        * the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not subject to these provisions.

   
***************************************************************************


If you have questions, problems, comments, etc, send them to
mailman-owner@www1.ietf.org.  Thanks!

Passwords for iptel-web-archive@ietf.org:

List                                     Password // URL
----                                     --------  
iptel@ietf.org                           aroxgu    
https://www.ietf.org/mailman/options/iptel/iptel-web-archive%40ietf.org



From exim@www1.ietf.org  Mon Jan 12 16:12:27 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20101
	for <iptel-archive@odin.ietf.org>; Mon, 12 Jan 2004 16:12:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ag9Lr-0005fH-2n
	for iptel-archive@odin.ietf.org; Mon, 12 Jan 2004 16:11:59 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CLBxPf021769
	for iptel-archive@odin.ietf.org; Mon, 12 Jan 2004 16:11:59 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ag9Lq-0005f2-Vc
	for iptel-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 16:11:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19991
	for <iptel-web-archive@ietf.org>; Mon, 12 Jan 2004 16:11:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ag9Lp-0000R5-00
	for iptel-web-archive@ietf.org; Mon, 12 Jan 2004 16:11:57 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ag9Jz-0000Dd-00
	for iptel-web-archive@ietf.org; Mon, 12 Jan 2004 16:10:04 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ag9I5-0007le-00
	for iptel-web-archive@ietf.org; Mon, 12 Jan 2004 16:08:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ag9I0-0005KD-QH; Mon, 12 Jan 2004 16:08:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ag9H9-0004zu-Qp
	for iptel@optimus.ietf.org; Mon, 12 Jan 2004 16:07:07 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19297;
	Mon, 12 Jan 2004 16:07:05 -0500 (EST)
Message-Id: <200401122107.QAA19297@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: iptel@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [Iptel] I-D ACTION:draft-ietf-iptel-trunk-group-01.txt
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Mon, 12 Jan 2004 16:07:05 -0500
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART,
	NO_REAL_NAME autolearn=no version=2.60

--NextPart

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 URIs
	Author(s)	: V. Gurbani
	Filename	: draft-ietf-iptel-trunk-group-01.txt
	Pages		: 13
	Date		: 2004-1-12
	
This document describes a standardized mechanism to convey trunk
group- related information in SIP and TEL 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-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-01.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-iptel-trunk-group-01.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-1-12154427.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-iptel-trunk-group-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-iptel-trunk-group-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-1-12154427.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Wed Jan 14 09:07:06 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18479
	for <iptel-archive@odin.ietf.org>; Wed, 14 Jan 2004 09:07:06 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AglfK-0000D3-AE
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 09:06:38 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EE6ce3000805
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 09:06:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AglfK-0000Ct-4q
	for iptel-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 09:06:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18458
	for <iptel-web-archive@ietf.org>; Wed, 14 Jan 2004 09:06:35 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AglfI-0004Dg-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 09:06:36 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgldT-0004B3-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 09:04:44 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aglbs-000497-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 09:03:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aglbp-0008Lh-Cr; Wed, 14 Jan 2004 09:03:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AglbZ-0008LQ-S6
	for iptel@optimus.ietf.org; Wed, 14 Jan 2004 09:02:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18216
	for <iptel@ietf.org>; Wed, 14 Jan 2004 09:02:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AglbY-00047M-00
	for iptel@ietf.org; Wed, 14 Jan 2004 09:02:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AglZh-000458-00
	for iptel@ietf.org; Wed, 14 Jan 2004 09:00:49 -0500
Received: from fep04-mail.bloor.is.net.cable.rogers.com ([66.185.86.74])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AglZL-00042D-00
	for iptel@ietf.org; Wed, 14 Jan 2004 09:00:27 -0500
Received: from dizzy2 ([63.139.41.35])
          by fep04-mail.bloor.is.net.cable.rogers.com
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20040114135720.STWA430912.fep04-mail.bloor.is.net.cable.rogers.com@dizzy2>
          for <iptel@ietf.org>; Wed, 14 Jan 2004 08:57:20 -0500
Message-ID: <004e01c3daa6$ca54fea0$6401a8c0@rogers.com>
From: "David Zinman" <dzinman@rogers.com>
To: <iptel@ietf.org>
References: <200311061426.JAA10141@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep04-mail.bloor.is.net.cable.rogers.com from [63.139.41.35] using ID <dzinman@rogers.com> at Wed, 14 Jan 2004 08:57:19 -0500
Content-Transfer-Encoding: 7bit
Subject: [Iptel] read-only compliance for TRIP MIB
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Wed, 14 Jan 2004 09:00:38 -0500
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

There has been a request to include a "read-only" compliance
section in the TRIP MIB. If most implementations plan on 
doing read-write support then it might not useful. 
However, if there is enough support for read-only compliance,
another draft will be issued to support it.

Comments, preferences??

The decision will be made by Tuesday Jan 20.

DZ



_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Wed Jan 14 10:16:30 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22751
	for <iptel-archive@odin.ietf.org>; Wed, 14 Jan 2004 10:16:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgmkU-0004eB-Lj
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 10:16:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EFG2Fw017862
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 10:16:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgmkU-0004e1-He
	for iptel-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 10:16:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22705
	for <iptel-web-archive@ietf.org>; Wed, 14 Jan 2004 10:15:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgmkS-0007Xi-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 10:16:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgmjS-0007Ud-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 10:14:58 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgmiY-0007Rr-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 10:14:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgmiX-0004Ya-D8; Wed, 14 Jan 2004 10:14:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgmiL-0004Sl-TD
	for iptel@optimus.ietf.org; Wed, 14 Jan 2004 10:13:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22442
	for <iptel@ietf.org>; Wed, 14 Jan 2004 10:13:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgmiJ-0007Qc-00
	for iptel@ietf.org; Wed, 14 Jan 2004 10:13:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgmhR-0007PK-00
	for iptel@ietf.org; Wed, 14 Jan 2004 10:12:53 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agmgj-0007Lh-00
	for iptel@ietf.org; Wed, 14 Jan 2004 10:12:09 -0500
Received: from rtp-core-1.cisco.com (64.102.124.12)
  by sj-iport-5.cisco.com with ESMTP; 14 Jan 2004 07:11:40 -0800
Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0EFBYLE026270;
	Wed, 14 Jan 2004 10:11:34 -0500 (EST)
Received: from cisco.com (dhcp-64-102-93-177.cisco.com [64.102.93.177])
	by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AWF23360;
	Wed, 14 Jan 2004 07:11:33 -0800 (PST)
Message-ID: <40055C25.8030300@cisco.com>
From: Kevin Lingle <klingle@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Zinman <dzinman@rogers.com>
CC: iptel@ietf.org
Subject: Re: [Iptel] read-only compliance for TRIP MIB
References: <200311061426.JAA10141@ietf.org> <004e01c3daa6$ca54fea0$6401a8c0@rogers.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Wed, 14 Jan 2004 10:11:33 -0500
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

david,

just as a data point to consider...

in the last call review of ietf sip-mib draft we have
taken a comment that the likelihood of configuration
being done via snmp may be questionable.  agents may
not wish to support those objects as read-write and the
current compliance would not allow them to claim conformance.
therefore, many of the read-write objects that are configuration
parameters will be reorganized alternate object-groups that will
go into an additional module-compliance that agents using
other means to provision the system can claim conformance with.

that sounds a lot like what you've referred to as "read-only"
compliance below, so i would agree that there is value in
the supporting this in the trip mib.

kevin

David Zinman wrote:
> There has been a request to include a "read-only" compliance
> section in the TRIP MIB. If most implementations plan on 
> doing read-write support then it might not useful. 
> However, if there is enough support for read-only compliance,
> another draft will be issued to support it.
> 
> Comments, preferences??
> 
> The decision will be made by Tuesday Jan 20.
> 
> DZ
> 
> 
> 
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel
> 



_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Wed Jan 14 11:08:21 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25213
	for <iptel-archive@odin.ietf.org>; Wed, 14 Jan 2004 11:08:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgnYg-000899-79
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 11:07:54 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EG7r0C031287
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 11:07:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgnYf-00088W-Aw
	for iptel-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 11:07:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25185
	for <iptel-web-archive@ietf.org>; Wed, 14 Jan 2004 11:07:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgnYc-00020W-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 11:07:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgnXi-0001xq-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 11:06:54 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgnWs-0001vS-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 11:06:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgnWt-0007ZE-NF; Wed, 14 Jan 2004 11:06:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgnWo-0007YR-H6
	for iptel@optimus.ietf.org; Wed, 14 Jan 2004 11:05:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25115
	for <iptel@ietf.org>; Wed, 14 Jan 2004 11:05:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgnWl-0001uC-00
	for iptel@ietf.org; Wed, 14 Jan 2004 11:05:56 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgnVo-0001s3-00
	for iptel@ietf.org; Wed, 14 Jan 2004 11:04:57 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgnV4-0001n9-00
	for iptel@ietf.org; Wed, 14 Jan 2004 11:04:10 -0500
Received: from dynamicsoft.com ([63.110.3.215])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i0EG3N9W002380;
	Wed, 14 Jan 2004 11:03:24 -0500 (EST)
Message-ID: <40056844.6030400@dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kevin Lingle <klingle@cisco.com>
CC: David Zinman <dzinman@rogers.com>, iptel@ietf.org
Subject: Re: [Iptel] read-only compliance for TRIP MIB
References: <200311061426.JAA10141@ietf.org> <004e01c3daa6$ca54fea0$6401a8c0@rogers.com> <40055C25.8030300@cisco.com>
In-Reply-To: <40055C25.8030300@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Wed, 14 Jan 2004 11:03:16 -0500
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I concur on this point.

Indeed, our policy for our products is that we do not do configuration 
through snmp; its only use for performance and fault management. As 
such, read-only compliance statements for MIBs would be good.

-Jonathan R.

Kevin Lingle wrote:

> david,
> 
> just as a data point to consider...
> 
> in the last call review of ietf sip-mib draft we have
> taken a comment that the likelihood of configuration
> being done via snmp may be questionable.  agents may
> not wish to support those objects as read-write and the
> current compliance would not allow them to claim conformance.
> therefore, many of the read-write objects that are configuration
> parameters will be reorganized alternate object-groups that will
> go into an additional module-compliance that agents using
> other means to provision the system can claim conformance with.
> 
> that sounds a lot like what you've referred to as "read-only"
> compliance below, so i would agree that there is value in
> the supporting this in the trip mib.
> 
> kevin
> 
> David Zinman wrote:
> 
>> There has been a request to include a "read-only" compliance
>> section in the TRIP MIB. If most implementations plan on doing 
>> read-write support then it might not useful. However, if there is 
>> enough support for read-only compliance,
>> another draft will be issued to support it.
>>
>> Comments, preferences??
>>
>> The decision will be made by Tuesday Jan 20.
>>
>> DZ
>>
>>
>>
>> _______________________________________________
>> Iptel mailing list
>> Iptel@ietf.org
>> https://www.ietf.org/mailman/listinfo/iptel
>>
> 
> 
> 
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Wed Jan 14 12:11:16 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28447
	for <iptel-archive@odin.ietf.org>; Wed, 14 Jan 2004 12:11:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgoXY-0003qA-UF
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 12:10:48 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EHAm5U014756
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 12:10:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgoXY-0003pv-Oa
	for iptel-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 12:10:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28434
	for <iptel-web-archive@ietf.org>; Wed, 14 Jan 2004 12:10:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgoXX-0005X4-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 12:10:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgoWd-0005Vl-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 12:09:52 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgoVo-0005Ua-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 12:09:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgoVo-0003YI-II; Wed, 14 Jan 2004 12:09:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgoVb-0003XW-0h
	for iptel@optimus.ietf.org; Wed, 14 Jan 2004 12:08:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28376
	for <iptel@ietf.org>; Wed, 14 Jan 2004 12:08:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgoVZ-0005TV-00
	for iptel@ietf.org; Wed, 14 Jan 2004 12:08:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgoUd-0005Rg-00
	for iptel@ietf.org; Wed, 14 Jan 2004 12:07:47 -0500
Received: from omrnat4.verisignmail.com ([216.168.230.163] helo=omr2.verisignmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgoTi-0005OX-00
	for iptel@ietf.org; Wed, 14 Jan 2004 12:06:50 -0500
Received: from ms1.verisignmail.com (IDENT:mirapoint@[216.168.230.167])
	by omr2.verisignmail.com (8.12.10/8.12.10) with ESMTP id i0EH2vXR010070;
	Wed, 14 Jan 2004 12:02:57 -0500 (EST)
Received: from BOB.AppliedSNMP.com (pcp07745400pcs.nrockv01.md.comcast.net [69.138.177.240])
	by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA)
	with ESMTP id AXZ27173;
	Wed, 14 Jan 2004 12:06:31 -0500 (EST)
Message-Id: <6.0.1.1.2.20040114121121.034cafb0@mail.appliedsnmp.com>
X-Sender: Bob.Natale@AppliedSNMP.com@mail.appliedsnmp.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
From: Bob Natale <Bob.Natale@AppliedSNMP.com>
Subject: Re: [Iptel] read-only compliance for TRIP MIB
Cc: iptel@ietf.org
In-Reply-To: <40056844.6030400@dynamicsoft.com>
References: <200311061426.JAA10141@ietf.org>
 <004e01c3daa6$ca54fea0$6401a8c0@rogers.com>
 <40055C25.8030300@cisco.com>
 <40056844.6030400@dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Wed, 14 Jan 2004 12:15:35 -0500
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

At 1/14/2004:11:03 AM, Jonathan Rosenberg wrote:

Hi Jonathan, everyone:

If you would care to elaborate on your policy, would you
comment on your view of the acceptability of SNMPv3 for
configuration support.

If that view is positive, does anyone think it might be
possible and desirable to do conformance groups based on
SNMPv3 operations?

Cheers,

BobN
- - - - -
>I concur on this point.
>
>Indeed, our policy for our products is that we do not do configuration through snmp; its only use for performance and fault management. As such, read-only compliance statements for MIBs would be good.
>
>-Jonathan R.
>
>Kevin Lingle wrote:
>
>>david,
>>just as a data point to consider...
>>in the last call review of ietf sip-mib draft we have
>>taken a comment that the likelihood of configuration
>>being done via snmp may be questionable.  agents may
>>not wish to support those objects as read-write and the
>>current compliance would not allow them to claim conformance.
>>therefore, many of the read-write objects that are configuration
>>parameters will be reorganized alternate object-groups that will
>>go into an additional module-compliance that agents using
>>other means to provision the system can claim conformance with.
>>that sounds a lot like what you've referred to as "read-only"
>>compliance below, so i would agree that there is value in
>>the supporting this in the trip mib.
>>kevin
>>David Zinman wrote:
>>
>>>There has been a request to include a "read-only" compliance
>>>section in the TRIP MIB. If most implementations plan on doing read-write support then it might not useful. However, if there is enough support for read-only compliance,
>>>another draft will be issued to support it.
>>>
>>>Comments, preferences??
>>>
>>>The decision will be made by Tuesday Jan 20.
>>>
>>>DZ
>>>
>>>
>>>
>>>_______________________________________________
>>>Iptel mailing list
>>>Iptel@ietf.org
>>>https://www.ietf.org/mailman/listinfo/iptel
>>
>>_______________________________________________
>>Iptel mailing list
>>Iptel@ietf.org
>>https://www.ietf.org/mailman/listinfo/iptel
>
>-- 
>Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>Chief Technology Officer                    Parsippany, NJ 07054-2711
>dynamicsoft
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com
>
>
>_______________________________________________
>Iptel mailing list
>Iptel@ietf.org
>https://www.ietf.org/mailman/listinfo/iptel


_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Wed Jan 14 13:05:21 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00764
	for <iptel-archive@odin.ietf.org>; Wed, 14 Jan 2004 13:05:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgpNq-0005zT-3f
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 13:04:54 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0EI4olY023026
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 13:04:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgpNp-0005zJ-W7
	for iptel-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 13:04:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00726
	for <iptel-web-archive@ietf.org>; Wed, 14 Jan 2004 13:04:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgpNn-0000AS-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 13:04:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgpMu-000090-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 13:03:53 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgpMA-00007k-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 13:03:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgpM5-0005uf-Gb; Wed, 14 Jan 2004 13:03:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AgpLv-0005uR-QA
	for iptel@optimus.ietf.org; Wed, 14 Jan 2004 13:02:52 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00632
	for <iptel@ietf.org>; Wed, 14 Jan 2004 13:02:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgpLt-00006i-00
	for iptel@ietf.org; Wed, 14 Jan 2004 13:02:49 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgpKz-00005u-00
	for iptel@ietf.org; Wed, 14 Jan 2004 13:01:54 -0500
Received: from tierw.net.avaya.com ([198.152.13.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgpKo-00004i-00
	for iptel@ietf.org; Wed, 14 Jan 2004 13:01:42 -0500
Received: from tierw.net.avaya.com (localhost [127.0.0.1])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0EHwMiv005518
	for <iptel@ietf.org>; Wed, 14 Jan 2004 12:58:22 -0500 (EST)
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0EHwJiv005458
	for <iptel@ietf.org>; Wed, 14 Jan 2004 12:58:20 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Iptel] read-only compliance for TRIP MIB
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F04259AB6@is0004avexu1.global.avaya.com>
Thread-Topic: [Iptel] read-only compliance for TRIP MIB
Thread-Index: AcPapy1M513aKXjwRyqDrJyliqsiCgAIIG/g
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "David Zinman" <dzinman@rogers.com>, <iptel@ietf.org>
Cc: <mreview@ops.ietf.org>
Content-Transfer-Encoding: quoted-printable
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Wed, 14 Jan 2004 20:01:38 +0200
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

David,

The TRIP MIB has RowStatus objects.  If you intent to provide a =
read-only compliance version, does this mean that the tables with row =
creation capabilities will have a fixed number of rows, without the =
manager being able to create or delete rows in this tables? Please have =
a look and confirm that this is your intention, and take care to clarify =
in the document what rows are supposed to be permanent in this situation =
for each table.

Thanks and Regards,

Dan



> -----Original Message-----
> From: iptel-admin@ietf.org [mailto:iptel-admin@ietf.org]On=20
> Behalf Of David Zinman
> Sent: 14 January, 2004 4:01 PM
> To: iptel@ietf.org
> Subject: [Iptel] read-only compliance for TRIP MIB
>=20
>=20
> There has been a request to include a "read-only" compliance
> section in the TRIP MIB. If most implementations plan on=20
> doing read-write support then it might not useful.=20
> However, if there is enough support for read-only compliance,
> another draft will be issued to support it.
>=20
> Comments, preferences??
>=20
> The decision will be made by Tuesday Jan 20.
>=20
> DZ
>=20
>=20
>=20
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel
>=20

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Wed Jan 14 22:19:37 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28394
	for <iptel-archive@odin.ietf.org>; Wed, 14 Jan 2004 22:19:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agy2I-0003br-4u
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 22:19:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F3JAjr013869
	for iptel-archive@odin.ietf.org; Wed, 14 Jan 2004 22:19:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agy2H-0003bc-Ve
	for iptel-web-archive@optimus.ietf.org; Wed, 14 Jan 2004 22:19:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28391
	for <iptel-web-archive@ietf.org>; Wed, 14 Jan 2004 22:19:06 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agy2E-0001jl-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 22:19:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Agy1R-0001iq-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 22:18:17 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agy18-0001ge-00
	for iptel-web-archive@ietf.org; Wed, 14 Jan 2004 22:17:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agy1A-0003W2-Ml; Wed, 14 Jan 2004 22:18:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Agy0L-0003Qp-4w
	for iptel@optimus.ietf.org; Wed, 14 Jan 2004 22:17:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28324
	for <iptel@ietf.org>; Wed, 14 Jan 2004 22:17:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Agy0G-0001eF-00
	for iptel@ietf.org; Wed, 14 Jan 2004 22:17:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AgxzN-0001co-00
	for iptel@ietf.org; Wed, 14 Jan 2004 22:16:09 -0500
Received: from fep03-mail.bloor.is.net.cable.rogers.com ([66.185.86.73])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AgxyW-0001Yg-00
	for iptel@ietf.org; Wed, 14 Jan 2004 22:15:16 -0500
Received: from dizzy2 ([63.139.41.35])
          by fep03-mail.bloor.is.net.cable.rogers.com
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20040115031349.ZCJM337742.fep03-mail.bloor.is.net.cable.rogers.com@dizzy2>;
          Wed, 14 Jan 2004 22:13:49 -0500
Message-ID: <003d01c3db15$d4451840$6401a8c0@rogers.com>
From: "David Zinman" <dzinman@rogers.com>
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>, <iptel@ietf.org>
References: <AAB4B3D3CF0F454F98272CBE187FDE2F04259AB6@is0004avexu1.global.avaya.com>
Subject: Re: [Iptel] read-only compliance for TRIP MIB
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [63.139.41.35] using ID <dzinman@rogers.com> at Wed, 14 Jan 2004 22:13:48 -0500
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Wed, 14 Jan 2004 22:15:29 -0500
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Dan,

I'm not sure I understand what you mean by "permanent". In a read-only
implementation of the MIB, even though the (SNMP) manager cannot add rows to
a table, this does not preclude the TRIP application or other source from
adding rows to the table.

For example, in a read-only MIB representing a routing table, even though
the manager may not add a route (a row), a route might possibly be added or
removed dynamically by the routing application. In such a case there may be
no permanent rows at all.

DZ

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "David Zinman" <dzinman@rogers.com>; <iptel@ietf.org>
Cc: <mreview@ops.ietf.org>
Sent: Wednesday, January 14, 2004 1:01 PM
Subject: RE: [Iptel] read-only compliance for TRIP MIB


David,

The TRIP MIB has RowStatus objects.  If you intent to provide a read-only
compliance version, does this mean that the tables with row creation
capabilities will have a fixed number of rows, without the manager being
able to create or delete rows in this tables? Please have a look and confirm
that this is your intention, and take care to clarify in the document what
rows are supposed to be permanent in this situation for each table.

Thanks and Regards,

Dan



> -----Original Message-----
> From: iptel-admin@ietf.org [mailto:iptel-admin@ietf.org]On
> Behalf Of David Zinman
> Sent: 14 January, 2004 4:01 PM
> To: iptel@ietf.org
> Subject: [Iptel] read-only compliance for TRIP MIB
>
>
> There has been a request to include a "read-only" compliance
> section in the TRIP MIB. If most implementations plan on
> doing read-write support then it might not useful.
> However, if there is enough support for read-only compliance,
> another draft will be issued to support it.
>
> Comments, preferences??
>
> The decision will be made by Tuesday Jan 20.
>
> DZ
>
>
>
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel
>

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Thu Jan 15 01:23:48 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02447
	for <iptel-archive@odin.ietf.org>; Thu, 15 Jan 2004 01:23:48 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah0uT-0002fN-5V
	for iptel-archive@odin.ietf.org; Thu, 15 Jan 2004 01:23:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0F6NH74010243
	for iptel-archive@odin.ietf.org; Thu, 15 Jan 2004 01:23:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah0uT-0002f8-1h
	for iptel-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 01:23:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02442
	for <iptel-web-archive@ietf.org>; Thu, 15 Jan 2004 01:23:15 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah0uP-0006tT-00
	for iptel-web-archive@ietf.org; Thu, 15 Jan 2004 01:23:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ah0tU-0006s7-00
	for iptel-web-archive@ietf.org; Thu, 15 Jan 2004 01:22:17 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah0tE-0006qk-00
	for iptel-web-archive@ietf.org; Thu, 15 Jan 2004 01:22:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah0tE-0002bm-Kd; Thu, 15 Jan 2004 01:22:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah0sS-0002bR-Ns
	for iptel@optimus.ietf.org; Thu, 15 Jan 2004 01:21:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02408
	for <iptel@ietf.org>; Thu, 15 Jan 2004 01:21:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah0sP-0006pO-00
	for iptel@ietf.org; Thu, 15 Jan 2004 01:21:09 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ah0rX-0006oN-00
	for iptel@ietf.org; Thu, 15 Jan 2004 01:20:15 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah0qn-0006lR-00
	for iptel@ietf.org; Thu, 15 Jan 2004 01:19:29 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0F6IUJ13409
	for <iptel@ietf.org>; Thu, 15 Jan 2004 00:18:38 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72)
	id <C6W67ZZX>; Thu, 15 Jan 2004 06:50:49 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503509E4C@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: David Zinman <dzinman@rogers.com>, iptel@ietf.org
Subject: RE: [Iptel] read-only compliance for TRIP MIB
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Thu, 15 Jan 2004 06:50:47 +0100
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60

So, you did not specify that MIN-ACCESS of read-only is OK in 
your MODULE COMPLIANCE. That is fine by me, but if you do
so, then of course read-only implementation cannot claim
compliance. I think I said this before.

So, my understanding of what you want to do is to add an extra 
MODULE-COMPLIANCE, and that seems a very easy and simple way 
to address this.

I sort of expect then two compliance statements:

    tripMibFullCompliance MODULE-COMPLIANCE
        STATUS       current
        DESCRIPTION "The compliance statement for TRIP entities
                     that implement this MIB module in read-write
                     mode, such that it can be used for both 
                     monitoring and configuring the TRIP entity.
                    "
    ... here the stuff that you currently have in 
      tripCompliance MODULE-COMPLIANCE

    tripMibReadOnlyCompliance MODULE-COMPLIANCE
        STATUS       current
        DESCRIPTION "The compliance statement for TRIP entities
                     that implement this MIB module in read only mode.
                     Such TRIP entities can then only be monitored, but 
                     not be configured via this MIB module.
                    "
     ... here the stuff that you currently have in 
      tripCompliance MODULE-COMPLIANCE
     plus of course the OBJECT CLAUSES with MIN-ACCESS read-only 
     plus for some of them also the SYNTAX clauses to indicate
     that not all values need to be supported.

Hope this helps
Bert

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Thu Jan 15 10:20:02 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11137
	for <iptel-archive@odin.ietf.org>; Thu, 15 Jan 2004 10:20:02 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah9HS-0005r2-Bf
	for iptel-archive@odin.ietf.org; Thu, 15 Jan 2004 10:19:34 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FFJYM3022505
	for iptel-archive@odin.ietf.org; Thu, 15 Jan 2004 10:19:34 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah9HS-0005qu-5Y
	for iptel-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 10:19:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11118
	for <iptel-web-archive@ietf.org>; Thu, 15 Jan 2004 10:19:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah9HP-00077x-00
	for iptel-web-archive@ietf.org; Thu, 15 Jan 2004 10:19:31 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ah9GU-00076q-00
	for iptel-web-archive@ietf.org; Thu, 15 Jan 2004 10:18:35 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah9GA-00075K-00
	for iptel-web-archive@ietf.org; Thu, 15 Jan 2004 10:18:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah9Fw-0005ld-Sw; Thu, 15 Jan 2004 10:18:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ah9FT-0005kI-18
	for iptel@optimus.ietf.org; Thu, 15 Jan 2004 10:17:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10910
	for <iptel@ietf.org>; Thu, 15 Jan 2004 10:17:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah9FQ-00073d-00
	for iptel@ietf.org; Thu, 15 Jan 2004 10:17:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ah9ET-00071f-00
	for iptel@ietf.org; Thu, 15 Jan 2004 10:16:30 -0500
Received: from tiere.net.avaya.com ([198.152.12.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ah9Dn-00070o-00
	for iptel@ietf.org; Thu, 15 Jan 2004 10:15:47 -0500
Received: from tiere.net.avaya.com (localhost [127.0.0.1])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0FFEs4G011420
	for <iptel@ietf.org>; Thu, 15 Jan 2004 10:14:54 -0500 (EST)
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0FFEp4G011357
	for <iptel@ietf.org>; Thu, 15 Jan 2004 10:14:53 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Iptel] read-only compliance for TRIP MIB
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F04259ADB@is0004avexu1.global.avaya.com>
Thread-Topic: [Iptel] read-only compliance for TRIP MIB
Thread-Index: AcPbFb0GIKuKqRLxTmS/vIsWXFjBlwAZHYVw
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "David Zinman" <dzinman@rogers.com>, <iptel@ietf.org>
Content-Transfer-Encoding: quoted-printable
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Thu, 15 Jan 2004 17:15:37 +0200
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

This needs to be explained. Also, is there an aging / flushing =
mechanism? Routes are added by the routing application, but are they =
also deleted?

Thanks and Regards,

Dan



> -----Original Message-----
> From: David Zinman [mailto:dzinman@rogers.com]
> Sent: 15 January, 2004 5:15 AM
> To: Romascanu, Dan (Dan); iptel@ietf.org
> Subject: Re: [Iptel] read-only compliance for TRIP MIB
>=20
>=20
> Dan,
>=20
> I'm not sure I understand what you mean by "permanent". In a read-only
> implementation of the MIB, even though the (SNMP) manager=20
> cannot add rows to
> a table, this does not preclude the TRIP application or other=20
> source from
> adding rows to the table.
>=20
> For example, in a read-only MIB representing a routing table,=20
> even though
> the manager may not add a route (a row), a route might=20
> possibly be added or
> removed dynamically by the routing application. In such a=20
> case there may be
> no permanent rows at all.
>=20
> DZ
>=20
> ----- Original Message -----=20
> From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
> To: "David Zinman" <dzinman@rogers.com>; <iptel@ietf.org>
> Cc: <mreview@ops.ietf.org>
> Sent: Wednesday, January 14, 2004 1:01 PM
> Subject: RE: [Iptel] read-only compliance for TRIP MIB
>=20
>=20
> David,
>=20
> The TRIP MIB has RowStatus objects.  If you intent to provide=20
> a read-only
> compliance version, does this mean that the tables with row creation
> capabilities will have a fixed number of rows, without the=20
> manager being
> able to create or delete rows in this tables? Please have a=20
> look and confirm
> that this is your intention, and take care to clarify in the=20
> document what
> rows are supposed to be permanent in this situation for each table.
>=20
> Thanks and Regards,
>=20
> Dan
>=20
>=20
>=20
> > -----Original Message-----
> > From: iptel-admin@ietf.org [mailto:iptel-admin@ietf.org]On
> > Behalf Of David Zinman
> > Sent: 14 January, 2004 4:01 PM
> > To: iptel@ietf.org
> > Subject: [Iptel] read-only compliance for TRIP MIB
> >
> >
> > There has been a request to include a "read-only" compliance
> > section in the TRIP MIB. If most implementations plan on
> > doing read-write support then it might not useful.
> > However, if there is enough support for read-only compliance,
> > another draft will be issued to support it.
> >
> > Comments, preferences??
> >
> > The decision will be made by Tuesday Jan 20.
> >
> > DZ
> >
> >
> >
> > _______________________________________________
> > Iptel mailing list
> > Iptel@ietf.org
> > https://www.ietf.org/mailman/listinfo/iptel
> >
>=20
> _______________________________________________
> Iptel mailing list
> Iptel@ietf.org
> https://www.ietf.org/mailman/listinfo/iptel
>=20
>=20
>=20

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Thu Jan 15 14:24:13 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21237
	for <iptel-archive@odin.ietf.org>; Thu, 15 Jan 2004 14:24:13 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhD5l-00031T-E6
	for iptel-archive@odin.ietf.org; Thu, 15 Jan 2004 14:23:45 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FJNjpo011615
	for iptel-archive@odin.ietf.org; Thu, 15 Jan 2004 14:23:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhD5l-000319-9q
	for iptel-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 14:23:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21226
	for <iptel-web-archive@ietf.org>; Thu, 15 Jan 2004 14:23:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhD5i-00037d-00
	for iptel-web-archive@ietf.org; Thu, 15 Jan 2004 14:23:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhD4t-00034t-00
	for iptel-web-archive@ietf.org; Thu, 15 Jan 2004 14:22:52 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhD46-000328-00
	for iptel-web-archive@ietf.org; Thu, 15 Jan 2004 14:22:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhD44-0002rH-MO; Thu, 15 Jan 2004 14:22:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AhD41-0002qm-2e
	for iptel@optimus.ietf.org; Thu, 15 Jan 2004 14:21:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21141
	for <iptel@ietf.org>; Thu, 15 Jan 2004 14:21:54 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhD3y-00030j-00
	for iptel@ietf.org; Thu, 15 Jan 2004 14:21:54 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AhD2q-0002xc-00
	for iptel@ietf.org; Thu, 15 Jan 2004 14:20:46 -0500
Received: from imo-r08.mx.aol.com ([152.163.225.104])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AhD2H-0002uF-00
	for iptel@ietf.org; Thu, 15 Jan 2004 14:20:09 -0500
Received: from Mpierce1@aol.com
	by imo-r08.mx.aol.com (mail_out_v36_r4.12.) id l.1aa.1ee455e3 (4539)
	 for <iptel@ietf.org>; Thu, 15 Jan 2004 14:19:31 -0500 (EST)
Message-ID: <1aa.1ee455e3.2d3841c3@aol.com>
To: iptel@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_1aa.1ee455e3.2d3841c3_boundary"
X-Mailer: 6.0 for Windows XP sub 10501
Subject: [Iptel] Comments on trunk group draft
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Thu, 15 Jan 2004 14:19:31 EST
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME 
	autolearn=no version=2.60


--part1_1aa.1ee455e3.2d3841c3_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Comments on draft-ietf-iptel-trunk groups-01

General:

As defined in the draft for tel:uri, the tel:uri is used to describe 
resources identifed by telephone numbers. Trunk groups can not be identified by 
telephone numbers, so this requirement for a standardized way to identify trunk 
groups should not be met by an extension to the tel:uri. (The logic in Section 4.1 
Req 1 is flawed.)

Section 4.2 states that "trunk groups have a meaning only within an 
administrative domain (i.e., local scope)". This is not true in the general sense. If 
it were, there would be no need for standard naming schemes, since each domain 
could make up their own. In fact, trunks can interconnect switches in 
different adminstrative domains, hence the need for standards.

For the purpose of this draft (proxy to GW), the trunk group identities have 
meaning only within an administrative domian only if it could be assumed that 
the proxy and GW are part of the same administrative domain. If, in fact, a GW 
could be controlled by different proxies in different domains, then the trunk 
group identity scheme is determined by the GW and all proxies with which it 
communicates must comply with that naming scheme. There is no ambiguity or 
"global" reach. Uniqueness exists for each GW.

This issue of standardized naming of trunk groups has been addressed by other 
standards bodies (ITU-T and T1 in the US.) The IETF does not need to define 
yet another system, but should limit itself to defining a local identity which 
can be included in SIP messages (or whatever messages might be used between a 
SIP proxy and a VoIP Gateway).

If one looks at the architecture for interfacing a SIP proxy, through a GW, 
to a PSTN switch (CO), we have:


 -----         -----                         -----
|     |   a   |     |           b           |     |
|Proxy|---/---| GW  |-----------/-----------| CO  |
|     |       |     |                       |     |
 -----         -----                         -----

We should assume that there is already a standardized way to identify trunk 
groups (and trunks) across interface "b". For the interface at "a", one of two 
methods can be used:

1. Use the existing standardized naming from "b" To simplify administrative 
tasks, this would be better, but not required.
2. Use a local definition, which only has significance between the proxy and 
the one GW

The requirement in this draft should be to support both cases.

The "Phone-context" parameter caused seemingly endless discussions with the 
tel:uri and will probably do so here. I have no idea what function it serves 
across interface "a" in the above. If interface "a" were to use the same 
standardized scheme as used at "b", there is no such thing as "phone context". If it 
is to use a local scheme, then it seems that it only needs to carry an 
arbitrary strings of characters for the "trunk group name", like "tg55" in the 
example. Nothing more, since, by definition, it only has a meaning within that one 
GW, that is, no global significance. (The logic in Section 4.2 is flawed.)

The example in Section 6 uses "phone-context=+1-555-555". It is unknown what 
this partial E.164 number could represent.


Specific comments:

In several places throughout the text, the reference to "trunk group" should 
read "identity of the trunk group" or similar wording. For example:

Section 2, first sentence and in Bullet item 1.
Last sentence of Section 5

Section 3, second paragraph:

The statement about calling a bundle of DS0s a "trunk" only adds confusion 
and is probably incorrect. This statement should be deleted.

Section 4.3

It is unclear why it would ever be necessary to include both originating and 
terminating trunk group (in a SIP message). As shown in 7.1 and 7.2, one is 
needed for an "outgoing" call and the other is needed for an "incoming" call. 
They may appear in different places for these two cases, but never both 
concurrently.

The second paragraph states that "routing entities can make informed routing 
decisions based on either the orginating or the terminating trunk groups". 
Since the purpose of routing is to determine the terminating trunk group, the 
decision can't be based on the terminating trunk group.

Section 4.4

In the fourth paragraph, the references to "UAS" should be "egress Gatway".
In the fifth paragaph, the reference to "UAC" should be ingress Gateway".

Although strictly speaking, the Gateway serves as a "UAS" and "UAC", the term 
"Gateway" here would match the same use of the term in other places such as 
the examples in Sections 71. and 7.2. (The "UAC" shown in 7.2 does not include 
the trunk group identifty as implied by the current text in the fifth 
paragraph.)

Section 7.1

The application that seems to be supported in this example is one in which 
the Proxy needs to know the trunk group on which the call came from the PSTN, 
since this often affects the dialing plan, or other handling of the call. But 
doesn't it also need to know which trunk in the group it is on, for example, to 
keep track of resources?

Section 7.2

The application that seems to be supported in this example could be one of 
the following:

1. The Proxy selects the GW and trunk group to use to send a call to the 
PSTN, but leaves it up to the GW to select a trunk within that trunk group.
2. The Proxy selects the actual trunk group and trunk to use.

In case 1, there should be a response from the GW back to the proxy to 
identify which trunk was used.
In case 2, the INVITE needs to include an identity of the trunk.

Mike Pierce
Artel



--part1_1aa.1ee455e3.2d3841c3_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2 PTSIZE=3D10 FAMILY=3D"SAN=
SSERIF" FACE=3D"Arial" LANG=3D"0">Comments on draft-ietf-iptel-trunk groups-=
01
<BR>
<BR>General:
<BR>
<BR>As defined in the draft for tel:uri, the tel:uri is used to describe res=
ources identifed by telephone numbers. Trunk groups can not be identified by=
 telephone numbers, so this requirement for a standardized way to identify t=
runk groups should not be met by an extension to the tel:uri. (The logic in=20=
Section 4.1 Req 1 is flawed.)
<BR>
<BR>Section 4.2 states that "trunk groups have a meaning only within an admi=
nistrative domain (i.e., local scope)". This is not true in the general sens=
e. If it were, there would be no need for standard naming schemes, since eac=
h domain could make up their own. In fact, trunks can interconnect switches=20=
in different adminstrative domains, hence the need for standards.
<BR>
<BR>For the purpose of this draft (proxy to GW), the trunk group identities=20=
have meaning only within an administrative domian only if it could be assume=
d that the proxy and GW are part of the same administrative domain. If, in f=
act, a GW could be controlled by different proxies in different domains, the=
n the trunk group identity scheme is determined by the GW and all proxies wi=
th which it communicates must comply with that naming scheme. There is no am=
biguity or "global" reach. Uniqueness exists for each GW.
<BR>
<BR>This issue of standardized naming of trunk groups has been addressed by=20=
other standards bodies (ITU-T and T1 in the US.) The IETF does not need to d=
efine yet another system, but should limit itself to defining a local identi=
ty which can be included in SIP messages (or whatever messages might be used=
 between a SIP proxy and a VoIP Gateway).
<BR>
<BR>If one looks at the architecture for interfacing a SIP proxy, through a=20=
GW, to a PSTN switch (CO), we have:
<BR>
<BR></FONT><FONT  COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COL=
OR: #ffffff" SIZE=3D2 PTSIZE=3D10 FAMILY=3D"FIXED" FACE=3D"Courier New" LANG=
=3D"0">
<BR> ----- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;----- &nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-----
<BR>| &nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;a &nbsp;&nbsp;| &nbsp;&nbsp;&nbs=
p;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b &nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;=
&nbsp;|
<BR>|Proxy|---/---| GW &nbsp;|-----------/-----------| CO &nbsp;|
<BR>| &nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;=
&nbsp;&nbsp;&nbsp;| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
| &nbsp;&nbsp;&nbsp;&nbsp;|
<BR> ----- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;----- &nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-----
<BR></FONT><FONT  COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COL=
OR: #ffffff" SIZE=3D2 PTSIZE=3D10 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=
=3D"0">
<BR>We should assume that there is already a standardized way to identify tr=
unk groups (and trunks) across interface "b". For the interface at "a", one=20=
of two methods can be used:
<BR>
<BR>1. Use the existing standardized naming from "b" To simplify administrat=
ive tasks, this would be better, but not required.
<BR>2. Use a local definition, which only has significance between the proxy=
 and the one GW
<BR>
<BR>The requirement in this draft should be to support both cases.
<BR>
<BR>The "Phone-context" parameter caused seemingly endless discussions with=20=
the tel:uri and will probably do so here. I have no idea what function it se=
rves across interface "a" in the above. If interface "a" were to use the sam=
e standardized scheme as used at "b", there is no such thing as "phone conte=
xt". If it is to use a local scheme, then it seems that it only needs to car=
ry an arbitrary strings of characters for the "trunk group name", like "tg55=
" in the example. Nothing more, since, by definition, it only has a meaning=20=
within that one GW, that is, no global significance. (The logic in Section 4=
.2 is flawed.)
<BR>
<BR>The example in Section 6 uses "phone-context=3D+1-555-555". It is unknow=
n what this partial E.164 number could represent.
<BR>
<BR>
<BR>Specific comments:
<BR>
<BR>In several places throughout the text, the reference to "trunk group" sh=
ould read "identity of the trunk group" or similar wording. For example:
<BR>
<BR>Section 2, first sentence and in Bullet item 1.
<BR>Last sentence of Section 5
<BR>
<BR>Section 3, second paragraph:
<BR>
<BR>The statement about calling a bundle of DS0s a "trunk" only adds confusi=
on and is probably incorrect. This statement should be deleted.
<BR>
<BR>Section 4.3
<BR>
<BR>It is unclear why it would ever be necessary to include both originating=
 and terminating trunk group (in a SIP message). As shown in 7.1 and 7.2, on=
e is needed for an "outgoing" call and the other is needed for an "incoming"=
 call. They may appear in different places for these two cases, but never bo=
th concurrently.
<BR>
<BR>The second paragraph states that "routing entities can make informed rou=
ting decisions based on either the orginating or the terminating trunk group=
s". Since the purpose of routing is to determine the terminating trunk group=
, the decision can't be based on the terminating trunk group.
<BR>
<BR>Section 4.4
<BR>
<BR>In the fourth paragraph, the references to "UAS" should be "egress Gatwa=
y".
<BR>In the fifth paragaph, the reference to "UAC" should be ingress Gateway"=
.
<BR>
<BR>Although strictly speaking, the Gateway serves as a "UAS" and "UAC", the=
 term "Gateway" here would match the same use of the term in other places su=
ch as the examples in Sections 71. and 7.2. (The "UAC" shown in 7.2 does not=
 include the trunk group identifty as implied by the current text in the fif=
th paragraph.)
<BR>
<BR>Section 7.1
<BR>
<BR>The application that seems to be supported in this example is one in whi=
ch the Proxy needs to know the trunk group on which the call came from the P=
STN, since this often affects the dialing plan, or other handling of the cal=
l. But doesn't it also need to know which trunk in the group it is on, for e=
xample, to keep track of resources?
<BR>
<BR>Section 7.2
<BR>
<BR>The application that seems to be supported in this example could be one=20=
of the following:
<BR>
<BR>1. The Proxy selects the GW and trunk group to use to send a call to the=
 PSTN, but leaves it up to the GW to select a trunk within that trunk group.
<BR>2. The Proxy selects the actual trunk group and trunk to use.
<BR>
<BR>In case 1, there should be a response from the GW back to the proxy to i=
dentify which trunk was used.
<BR>In case 2, the INVITE needs to include an identity of the trunk.
<BR>
<BR>Mike Pierce
<BR>Artel
<BR>
<BR></FONT></HTML>

--part1_1aa.1ee455e3.2d3841c3_boundary--

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Wed Jan 21 12:26:15 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00916
	for <iptel-archive@odin.ietf.org>; Wed, 21 Jan 2004 12:26:15 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjM6t-0006an-Tr
	for iptel-archive@odin.ietf.org; Wed, 21 Jan 2004 12:25:47 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LHPlmH025338
	for iptel-archive@odin.ietf.org; Wed, 21 Jan 2004 12:25:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjM6t-0006ab-Nw
	for iptel-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 12:25:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00803
	for <iptel-web-archive@ietf.org>; Wed, 21 Jan 2004 12:25:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjM6s-00016L-00
	for iptel-web-archive@ietf.org; Wed, 21 Jan 2004 12:25:46 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjM5o-0000va-00
	for iptel-web-archive@ietf.org; Wed, 21 Jan 2004 12:24:41 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjM4V-0000nt-02
	for iptel-web-archive@ietf.org; Wed, 21 Jan 2004 12:23:19 -0500
Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org)
	by mx2.foretec.com with esmtp (Exim 4.24)
	id 1AjLsj-0006s8-V6
	for iptel-web-archive@ietf.org; Wed, 21 Jan 2004 12:11:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjLsc-0005u3-Vi; Wed, 21 Jan 2004 12:11:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjLrx-0005qj-SB
	for iptel@optimus.ietf.org; Wed, 21 Jan 2004 12:10:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00445
	for <iptel@ietf.org>; Wed, 21 Jan 2004 12:10:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjLrw-0000Vf-00
	for iptel@ietf.org; Wed, 21 Jan 2004 12:10:20 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjLrD-0000RZ-00
	for iptel@ietf.org; Wed, 21 Jan 2004 12:09:36 -0500
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjLqP-0000HJ-00
	for iptel@ietf.org; Wed, 21 Jan 2004 12:08:45 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i0LH7wl06038;
	Wed, 21 Jan 2004 11:08:03 -0600 (CST)
Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2)
	id i0LH7vM21173; Wed, 21 Jan 2004 11:07:57 -0600 (CST)
Message-ID: <400EB1DB.2060407@lucent.com>
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Wireless Networks Research and Development
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mpierce1@aol.com
CC: iptel@ietf.org
Subject: Re: [Iptel] Comments on trunk group draft
References: <1aa.1ee455e3.2d3841c3@aol.com>
In-Reply-To: <1aa.1ee455e3.2d3841c3@aol.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Wed, 21 Jan 2004 11:07:39 -0600
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Mpierce1@aol.com wrote:

> Comments on draft-ietf-iptel-trunk groups-01

Mike:

Thanks for your comments.  Responses inline.

> General:
> 
> As defined in the draft for tel:uri, the tel:uri is used to describe 
> resources identifed by telephone numbers. Trunk groups can not be 
> identified by telephone numbers, so this requirement for a standardized 
> way to identify trunk groups should not be met by an extension to the 
> tel:uri. (The logic in Section 4.1 Req 1 is flawed.)

Insofar as the tel URI has been used to describe dial strings,
Calling Party Category (CPC) parameter, number portability and
freephone, I don't see the disadvantage of using it to describe
other telephony-related machinations like trunk groups.

> For the purpose of this draft (proxy to GW), the trunk group identities 
> have meaning only within an administrative domian only if it could be 
> assumed that the proxy and GW are part of the same administrative 
> domain. 

In the deployments I have seen, the gateway and the proxy are
owned by the same administrative domain.  The problem arises, of
course, if the gateway vendor and proxy vendor are different.  Then,
under the current rules of the game, some customization is needed
to make the proxy and the GW communicate the trunk group information.
We are simply attempting to avoid that customization.

> This issue of standardized naming of trunk groups has been addressed by 
> other standards bodies (ITU-T and T1 in the US.) The IETF does not need 
> to define yet another system, but should limit itself to defining a 
> local identity which can be included in SIP messages (or whatever 
> messages might be used between a SIP proxy and a VoIP Gateway).

Agreed; we made a decision long time ago -- the emails I have for this
I-D date back to August 2002 -- specifically to not standardize
the names of the trunk groups.  Other bodies do it well.  All we
are interested in is, as mentioned above, standardize the mechanism
by which this name is communicated between the GW and proxy.

> If one looks at the architecture for interfacing a SIP proxy, through a 
> GW, to a PSTN switch (CO), we have:
> 
> 
> -----         -----                         -----
> |     |   a   |     |           b           |     |
> |Proxy|---/---| GW  |-----------/-----------| CO  |
> |     |       |     |                       |     |
> -----         -----                         -----
> 
> We should assume that there is already a standardized way to identify 
> trunk groups (and trunks) across interface "b". For the interface at 
> "a", one of two methods can be used:
> 
> 1. Use the existing standardized naming from "b" To simplify 
> administrative tasks, this would be better, but not required.
> 2. Use a local definition, which only has significance between the proxy 
> and the one GW
> 
> The requirement in this draft should be to support both cases.

I believe that they do.  The I-D does not make any assumption
about the representation of the token that follow tgrp= parameter.
They could be the trunk names from "b" or locally significant names.

> The "Phone-context" parameter caused seemingly endless 
> discussions with the tel:uri and will probably do so here. I have no 
> idea what function it serves across interface "a" in the above.

It probably serves little, if any, function in interface "a"; but
if it could serve a purpose if a proxy P1 sends a request to another
proxy P2 in a different domain using trunk groups pertinent to
P2's domain.  How P1 knows about these trunk groups is outside the
scope of this I-D.  I can add some of this discussion in the I-D if it
will help.

> The example in Section 6 uses "phone-context=+1-555-555". It is unknown 
> what this partial E.164 number could represent.

Sorry; my mistake -- the number needs one more digit.  I'll fix it.

> Specific comments:
> 
> In several places throughout the text, the reference to "trunk group" 
> should read "identity of the trunk group" or similar wording. For example:
> 
> Section 2, first sentence and in Bullet item 1.
> Last sentence of Section 5

Sounds reasonable.  Will change.

> Section 4.3
> 
> It is unclear why it would ever be necessary to include both originating 
> and terminating trunk group (in a SIP message). As shown in 7.1 and 7.2, 
> one is needed for an "outgoing" call and the other is needed for an 
> "incoming" call. They may appear in different places for these two 
> cases, but never both concurrently.

This is a result of agreements on the mailing list long time ago
where there was forseen a need to represent both the terminating
and originating trunk groups.  Section 4.3 imposes a SHOULD
strength, so it is not mandatory; but the convention does allow
for it.

> The second paragraph states that "routing entities can make informed 
> routing decisions based on either the orginating or the terminating 
> trunk groups". Since the purpose of routing is to determine the 
> terminating trunk group, the decision can't be based on the terminating 
> trunk group.

Agreed, but some other intermediary between the proxy that chose
the terminating trunk group and the GW may prioritize requests
coming into it with a certain trunk group.  Admittedly, I do not
have a specific scenario in mind right now.  Having the above
sentence doesn't hinder us in any shape or form.  So, I am
leaning more towards leaving it in for the sake of generality.

> Section 4.4
> 
> In the fourth paragraph, the references to "UAS" should be "egress Gatway".
> In the fifth paragaph, the reference to "UAC" should be ingress Gateway".

Sure; will change.

> Although strictly speaking, the Gateway serves as a "UAS" and "UAC", the 
> term "Gateway" here would match the same use of the term in other places 
> such as the examples in Sections 71. and 7.2. (The "UAC" shown in 7.2 
> does not include the trunk group identifty as implied by the current 
> text in the fifth paragraph.)

Ah, that may be my failing.  the UAC in the figure in Section 7.2
is supposed to be a native SIP UAC.  It is starting a session
which ends up on the PSTN.  Hence, the invitation from it to
the proxy (labeled "Call Request") will not contain any trunk
group information.  The signaling between the proxy and the
egress gateway does contain trunk group information.

I will re-word this in the I-D to make this more specific.

> Section 7.1
> 
> The application that seems to be supported in this example is one in 
> which the Proxy needs to know the trunk group on which the call came 
> from the PSTN, since this often affects the dialing plan, or other 
> handling of the call. But doesn't it also need to know which trunk in 
> the group it is on, for example, to keep track of resources?

Sure; but that will be outside of the scope of this particular
I-D.

> Section 7.2
> 
> The application that seems to be supported in this example could be one 
> of the following:
> 
> 1. The Proxy selects the GW and trunk group to use to send a call to the 
> PSTN, but leaves it up to the GW to select a trunk within that trunk group.
> 2. The Proxy selects the actual trunk group and trunk to use.
> 
> In case 1, there should be a response from the GW back to the proxy to 
> identify which trunk was used.
> In case 2, the INVITE needs to include an identity of the trunk.

Hmmm -- how deeply do we want to wade in the water?  The assumptions,
thus far, have been that we are interested in representing trunk
groups, not individual trunks themselves.  I note that TGREP also
works on trunk groups as an atomic unit.  Drilling down further
can be accomplished by having naming conventions to the trunk-
group parameter, but these will be outside the scope of this I-D.

Thanks for the comments, Mike.

- 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


_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel



From exim@www1.ietf.org  Thu Jan 22 12:18:27 2004
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00009
	for <iptel-archive@odin.ietf.org>; Thu, 22 Jan 2004 12:18:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjiSu-0007a7-38
	for iptel-archive@odin.ietf.org; Thu, 22 Jan 2004 12:18:00 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id i0MHI0le029139
	for iptel-archive@odin.ietf.org; Thu, 22 Jan 2004 12:18:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjiSt-0007Zu-UU
	for iptel-web-archive@optimus.ietf.org; Thu, 22 Jan 2004 12:17:59 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29996
	for <iptel-web-archive@ietf.org>; Thu, 22 Jan 2004 12:17:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjiSn-0006hq-00
	for iptel-web-archive@ietf.org; Thu, 22 Jan 2004 12:17:53 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjiPI-0006Xd-00
	for iptel-web-archive@ietf.org; Thu, 22 Jan 2004 12:14:18 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjiMR-0006NL-00
	for iptel-web-archive@ietf.org; Thu, 22 Jan 2004 12:11:19 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjiM8-0007CF-Mw; Thu, 22 Jan 2004 12:11:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AjiLu-00079y-BZ
	for iptel@optimus.ietf.org; Thu, 22 Jan 2004 12:10:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29772
	for <iptel@ietf.org>; Thu, 22 Jan 2004 12:10:43 -0500 (EST)
From: Mpierce1@aol.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjiLo-0006LY-00
	for iptel@ietf.org; Thu, 22 Jan 2004 12:10:40 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AjiIb-0006DE-00
	for iptel@ietf.org; Thu, 22 Jan 2004 12:07:23 -0500
Received: from imo-m05.mx.aol.com ([64.12.136.8])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AjiFw-00063K-00
	for iptel@ietf.org; Thu, 22 Jan 2004 12:04:36 -0500
Received: from Mpierce1@aol.com
	by imo-m05.mx.aol.com (mail_out_v36_r4.12.) id o.99.423497bd (3310);
	Thu, 22 Jan 2004 12:01:54 -0500 (EST)
Message-ID: <99.423497bd.2d415c01@aol.com>
Subject: Re: [Iptel] Comments on trunk group draft
To: vkg@lucent.com
CC: iptel@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_99.423497bd.2d415c01_boundary"
X-Mailer: 6.0 for Windows XP sub 10500
Sender: iptel-admin@ietf.org
Errors-To: iptel-admin@ietf.org
X-BeenThere: iptel@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=unsubscribe>
List-Id: IP Telephony <iptel.ietf.org>
List-Post: <mailto:iptel@ietf.org>
List-Help: <mailto:iptel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iptel>,
	<mailto:iptel-request@ietf.org?subject=subscribe>
List-Archive: <https://www.ietf.org/mail-archive/working-groups/iptel/>
Date: Thu, 22 Jan 2004 12:01:53 EST
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=HTML_MESSAGE,NO_REAL_NAME 
	autolearn=no version=2.60


--part1_99.423497bd.2d415c01_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 1/21/2004 6:09:22 PM Romance Standard Time, vkg@lucent.com 
writes:

Insofar as the tel URI has been used to describe dial strings,
Calling Party Category (CPC) parameter, number portability and
freephone, I don't see the disadvantage of using it to describe
other telephony-related machinations like trunk groups.

[MAP] Yes, that's true, which means that, before the tel:uri draft is 
approved, it should be renamed from "The tel URI for Telephone Numbers"
to something like "The tel URI for general purpose telephony-related 
information"


In a message dated 1/21/2004 6:09:22 PM Romance Standard Time, vkg@lucent.com 
writes:

[MAP] > The "Phone-context" parameter caused seemingly endless 
> discussions with the tel:uri and will probably do so here. I have no 
> idea what function it serves across interface "a" in the above.

[VKG] It probably serves little, if any, function in interface "a"; but
if it could serve a purpose if a proxy P1 sends a request to another
proxy P2 in a different domain using trunk groups pertinent to
P2's domain.  How P1 knows about these trunk groups is outside the
scope of this I-D.  I can add some of this discussion in the I-D if it
will help.

[MAP] The point of my diagram was that the only known use of any trunk group 
identifier is between the proxy and the gateway (interface "a" in the 
diagram). I don't see any application in which one proxy needs to pass a trunk group 
identity to another proxy. That was not in my diagram, nor is it explained in 
the draft as an application. Since the only need for an identifier is across 
interface "a", and, as you said, the Phone-context serves "little" purpose here, 
I propose it be deleted.

The only idea I could possibly come up with in which one proxy would send a 
trunk group identifier to another is when a trunk group directly connects two 
gateways which are controlled by those two proxies, and the signaling is 
directly between the proxies (via SIP). In this case, the two proxies should share a 
common trunk group identification scheme, so no additional information (e.g., 
"phone-context") would be needed to ensure that the identity is unique. In 
this case, P1 knows about the trunk groups at P2 because they are the same at 
both P1 and P2. Otherwise, P1 would have no reason to know about trunks group at 
P2.


In a message dated 1/21/2004 6:09:22 PM Romance Standard Time, vkg@lucent.com 
writes:

[MAP] > The example in Section 6 uses "phone-context=+1-555-555". It is 
unknown 
> what this partial E.164 number could represent.

[VKG] Sorry; my mistake -- the number needs one more digit.  I'll fix it.

[MAP] That doesn't answer my question. No matter how many digits it has, if 
it looks like part of an E.164 number, I don't know how it relates to a trunk 
group.


Mike Pierce


--part1_99.423497bd.2d415c01_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><FONT  SIZE=3D2 PTSIZE=3D10>In a message=20=
dated 1/21/2004 6:09:22 PM Romance Standard Time, vkg@lucent.com writes:
<BR>
<BR>Insofar as the tel URI has been used to describe dial strings,
<BR>Calling Party Category (CPC) parameter, number portability and
<BR>freephone, I don't see the disadvantage of using it to describe
<BR>other telephony-related machinations like trunk groups.
<BR>
<BR>[MAP] Yes, that's true, which means that, before the tel:uri draft is ap=
proved, it should be renamed from "The tel URI for Telephone Numbers"
<BR>to something like "The tel URI for general purpose telephony-related inf=
ormation"
<BR>
<BR>
<BR>In a message dated 1/21/2004 6:09:22 PM Romance Standard Time, vkg@lucen=
t.com writes:
<BR>
<BR>[MAP] &gt; The "Phone-context" parameter caused seemingly endless=20
<BR>&gt; discussions with the tel:uri and will probably do so here. I have n=
o=20
<BR>&gt; idea what function it serves across interface "a" in the above.
<BR>
<BR>[VKG] It probably serves little, if any, function in interface "a"; but
<BR>if it could serve a purpose if a proxy P1 sends a request to another
<BR>proxy P2 in a different domain using trunk groups pertinent to
<BR>P2's domain. &nbsp;How P1 knows about these trunk groups is outside the
<BR>scope of this I-D. &nbsp;I can add some of this discussion in the I-D if=
 it
<BR>will help.
<BR>
<BR>[MAP] The point of my diagram was that the only known use of any trunk g=
roup identifier is between the proxy and the gateway (interface "a" in the d=
iagram). I don't see any application in which one proxy needs to pass a trun=
k group identity to another proxy. That was not in my diagram, nor is it exp=
lained in the draft as an application. Since the only need for an identifier=
 is across interface "a", and, as you said, the Phone-context serves "little=
" purpose here, I propose it be deleted.
<BR>
<BR>The only idea I could possibly come up with in which one proxy would sen=
d a trunk group identifier to another is when a trunk group directly connect=
s two gateways which are controlled by those two proxies, and the signaling=20=
is directly between the proxies (via SIP). In this case, the two proxies sho=
uld share a common trunk group identification scheme, so no additional infor=
mation (e.g., "phone-context") would be needed to ensure that the identity i=
s unique. In this case, P1 knows about the trunk groups at P2 because they a=
re the same at both P1 and P2. Otherwise, P1 would have no reason to know ab=
out trunks group at P2.
<BR>
<BR>
<BR>In a message dated 1/21/2004 6:09:22 PM Romance Standard Time, vkg@lucen=
t.com writes:
<BR>
<BR>[MAP] &gt; The example in Section 6 uses "phone-context=3D+1-555-555". I=
t is unknown=20
<BR>&gt; what this partial E.164 number could represent.
<BR>
<BR>[VKG] Sorry; my mistake -- the number needs one more digit. &nbsp;I'll f=
ix it.
<BR>
<BR>[MAP] That doesn't answer my question. No matter how many digits it has,=
 if it looks like part of an E.164 number, I don't know how it relates to a=20=
trunk group.
<BR>
<BR>
<BR>Mike Pierce
<BR></FONT></HTML>

--part1_99.423497bd.2d415c01_boundary--

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel