From extest-admin@lists.bell-labs.com Sat Sep 1 06:12:39 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11607 for ; Sat, 1 Sep 2001 06:12:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BA66244703 for ; Sat, 1 Sep 2001 05:11:21 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20010901091121.BA66244703@lists.bell-labs.com> Date: Sat, 1 Sep 2001 05:11:21 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com 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@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com Gfcn http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From iptel-admin@lists.bell-labs.com Sat Sep 1 14:03:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16703 for ; Sat, 1 Sep 2001 14:03:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DBA864433D; Sat, 1 Sep 2001 13:06:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id D6EBB44339 for ; Sat, 1 Sep 2001 13:05:47 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f81I56p21385; Sat, 1 Sep 2001 11:05:06 -0700 (PDT) Received: from cisco.com ([10.19.104.244]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABD07149 (AUTH hsalama); Sat, 1 Sep 2001 11:04:54 -0700 (PDT) Message-ID: <3B912334.DA9120BC@cisco.com> From: "Hussein F. Salama" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] FW: I-D ACTION:draft-ietf-iptel-trip-mib-00.txt References: Content-Type: multipart/alternative; boundary="------------BEF3435E196A9712EFA7FBBD" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 01 Sep 2001 11:04:36 -0700 --------------BEF3435E196A9712EFA7FBBD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A few comments on the MIB: - The MIB currently only tracks the incoming routes and the route selected routes. Shouldn't it also track the outgoing routes. These could differ from the selected routes due to aggregation, changes to some attributes, or the effects of communities. - The word "TRIP Identifier" is used throughout the document. Wouldn't it be more accurate to use "TRIP LS Identifier?" - Page 8. The TripCfgEntry. Why does it only include 4 timer values instead of all seven timers? - A few basic questions for me to better understand the different objects. What does TripCfgEntry represent? Is it global or per LS? How does it differ from the TripPeerEntry defined later in the document? - On page 11, the tripSendReceiveMode capability is defined. Why not define an object for the tripRouteTypesSupported capability as well? - On Page 21, shouldn't TripRouteEntry also include a fied for when this route was received, a timestamp? On Page 27, TripItadTopologyEntry ::= SEQUENCE { tripItadTopologyOrigId TripItad tripItadTopologySeqNum Integer32 } tripItadTopologyOrigId OBJECT-TYPE SYNTAX TripItad MAX-ACCESS not-accessible Shouldn't both occurences of "TripItad" be changed to a TRIP LS Identifier. The orginiator of TRIP topology information is a TRIP LS not an ITAD. Thanks. Hussein Jonathan Rosenberg wrote: > Folks, > > As we discussed in the meeting, the iptel group is currently chartered to > complete a TRIP MIB for submission to IESG in September of 2001. I am > committed to NOT missing the dates in our current charter, as we did an > awful job of meeting our deadlines for our initial deliverables. > > So, I would now like to open a two week working group last call for > draft-ietf-iptel-trip-mib-00.txt. Please send comments on this document to > the list within the next two weeks. I also want this document formally > reviewed, in detail, by a TRIP expert and a MIB expert. Thus, I am > requesting two volunteers (one TRIP expert, one MIB expert) to perform a > detailed review during the last call period. If I do not get two volunteers > by Monday Aug 27, I will tap people explicitly for the review, and use > excessive amounts of guilt and other forms of persuasion to convince them to > review it. > > Please email me privately if you wish to do a detailed review. > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, August 21, 2001 7:25 AM > Cc: iptel@lists.bell-labs.com > Subject: I-D ACTION:draft-ietf-iptel-trip-mib-00.txt > > 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 : Management Information Base for Telephony Routing > over > IP (TRIP) > Author(s) : J. Jiang, D. Walker, D. Zinman > Filename : draft-ietf-iptel-trip-mib-00.txt > Pages : 40 > Date : 20-Aug-01 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes a set of managed objects that are used > to manage for Telephony Routing over IP (TRIP) [2] devices. > Since TRIP [2] is modelled after the Border Gateway Protocol (BGP-4) > [3], the managed objects for TRIP are also modelled after RFC1657 - > Definitions of Managed Objects for the Fourth Version of the Border > Gateway Protocol (BGP-4) using SMIv2 [4]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-00.txt > > 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-trip-mib-00.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-trip-mib-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Hussein F. Salama Cisco Systems Mail Stop SJC-24/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 --------------BEF3435E196A9712EFA7FBBD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit A few comments on the MIB:

- The MIB currently only tracks the incoming routes and the route selected routes. Shouldn't it also track the outgoing routes. These could differ from the selected routes due to aggregation, changes to some attributes, or the effects of communities.
- The word "TRIP Identifier" is used throughout the document. Wouldn't it be more accurate to use "TRIP LS Identifier?"
- Page 8. The TripCfgEntry. Why does it only include 4 timer values instead of all seven timers?
- A few basic questions for me to better understand the different objects. What does TripCfgEntry represent? Is it global or per LS? How does it differ from the TripPeerEntry defined later in the document?
- On page 11, the tripSendReceiveMode capability is defined. Why not define an object for the tripRouteTypesSupported capability as well?
- On Page 21, shouldn't TripRouteEntry also include a fied for when this route was received, a timestamp?
On Page 27,

TripItadTopologyEntry ::= SEQUENCE {
               tripItadTopologyOrigId    TripItad
               tripItadTopologySeqNum    Integer32
           }

   tripItadTopologyOrigId OBJECT-TYPE
       SYNTAX      TripItad
       MAX-ACCESS  not-accessible

Shouldn't both occurences of "TripItad" be changed to a TRIP LS Identifier. The orginiator of TRIP topology information is a TRIP LS not an ITAD.

Thanks.

Hussein
 
 

Jonathan Rosenberg wrote:

Folks,

As we discussed in the meeting, the iptel group is currently chartered to
complete a TRIP MIB for submission to IESG in September of 2001. I am
committed to NOT missing the dates in our current charter, as we did an
awful job of meeting our deadlines for our initial deliverables.

So, I would now like to open a two week working group last call for
draft-ietf-iptel-trip-mib-00.txt. Please send comments on this document to
the list within the next two weeks. I also want this document formally
reviewed, in detail, by a TRIP expert and a MIB expert. Thus, I am
requesting two volunteers (one TRIP expert, one MIB expert) to perform a
detailed review during the last call period. If I do not get two volunteers
by Monday Aug 27, I will tap people explicitly for the review, and use
excessive amounts of guilt and other forms of persuasion to convince them to
review it.

Please email me privately if you wish to do a detailed review.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, August 21, 2001 7:25 AM
Cc: iptel@lists.bell-labs.com
Subject: I-D ACTION:draft-ietf-iptel-trip-mib-00.txt

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           : Management Information Base for Telephony Routing
over
                          IP (TRIP)
        Author(s)       : J. Jiang, D. Walker, D. Zinman
        Filename        : draft-ietf-iptel-trip-mib-00.txt
        Pages           : 40
        Date            : 20-Aug-01

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that are used
to manage for Telephony Routing over IP (TRIP) [2] devices.
Since TRIP [2] is modelled after the Border Gateway Protocol (BGP-4)
[3], the managed objects for TRIP are also modelled after RFC1657 -
Definitions of Managed Objects for the Fourth Version of the Border
Gateway Protocol (BGP-4) using SMIv2 [4].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-00.txt

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-trip-mib-00.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-trip-mib-00.txt".

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

--
Hussein F. Salama
Cisco Systems
Mail Stop SJC-24/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147
  --------------BEF3435E196A9712EFA7FBBD-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Sep 4 10:16:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17044 for ; Tue, 4 Sep 2001 10:16:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82C0044338; Tue, 4 Sep 2001 09:18:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id 57C1144337 for ; Tue, 4 Sep 2001 09:17:50 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A26D442E0240; Tue, 04 Sep 2001 10:17:17 -0400 Message-ID: <005d01c1354c$2148f2a0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Jonathan Rosenberg" , "Hussein F. Salama" Cc: "IPTEL List" References: <3B912334.DA9120BC@cisco.com> Subject: Re: [IPTEL] FW: I-D ACTION:draft-ietf-iptel-trip-mib-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 4 Sep 2001 10:16:02 -0400 Content-Transfer-Encoding: 7bit see embedded comments ----- Original Message ----- From: "Hussein F. Salama" To: "Jonathan Rosenberg" Cc: Sent: Saturday, September 01, 2001 2:04 PM Subject: Re: [IPTEL] FW: I-D ACTION:draft-ietf-iptel-trip-mib-00.txt > A few comments on the MIB: > > - The MIB currently only tracks the incoming routes and the route selected > routes. Shouldn't it also track the outgoing routes. These could differ from the > selected routes due to aggregation, changes to some attributes, or the effects > of communities. > - The word "TRIP Identifier" is used throughout the document. Wouldn't it be > more accurate to use "TRIP LS Identifier?" The base spec uses "TRIP Identifier". Why should the MIB be different? > - Page 8. The TripCfgEntry. Why does it only include 4 timer values instead of > all seven timers? > - A few basic questions for me to better understand the different objects. What > does TripCfgEntry represent? Is it global or per LS? How does it differ from the > TripPeerEntry defined later in the document? TripCfgEntry is the local LS (i.e. us). TripPeerEntry is for the LSs we're talking to. Who "we" are is indicated by the applIndex. > - On page 11, the tripSendReceiveMode capability is defined. Why not define an > object for the tripRouteTypesSupported capability as well? > - On Page 21, shouldn't TripRouteEntry also include a fied for when this route > was received, a timestamp? > On Page 27, > > TripItadTopologyEntry ::= SEQUENCE { > tripItadTopologyOrigId TripItad > tripItadTopologySeqNum Integer32 > } > > tripItadTopologyOrigId OBJECT-TYPE > SYNTAX TripItad > MAX-ACCESS not-accessible > > Shouldn't both occurences of "TripItad" be changed to a TRIP LS Identifier. The > orginiator of TRIP topology information is a TRIP LS not an ITAD. > > Thanks. > > Hussein > > > > Jonathan Rosenberg wrote: > > > Folks, > > > > As we discussed in the meeting, the iptel group is currently chartered to > > complete a TRIP MIB for submission to IESG in September of 2001. I am > > committed to NOT missing the dates in our current charter, as we did an > > awful job of meeting our deadlines for our initial deliverables. > > > > So, I would now like to open a two week working group last call for > > draft-ietf-iptel-trip-mib-00.txt. Please send comments on this document to > > the list within the next two weeks. I also want this document formally > > reviewed, in detail, by a TRIP expert and a MIB expert. Thus, I am > > requesting two volunteers (one TRIP expert, one MIB expert) to perform a > > detailed review during the last call period. If I do not get two volunteers > > by Monday Aug 27, I will tap people explicitly for the review, and use > > excessive amounts of guilt and other forms of persuasion to convince them to > > review it. > > > > Please email me privately if you wish to do a detailed review. > > > > Thanks, > > Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, August 21, 2001 7:25 AM > > Cc: iptel@lists.bell-labs.com > > Subject: I-D ACTION:draft-ietf-iptel-trip-mib-00.txt > > > > 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 : Management Information Base for Telephony Routing > > over > > IP (TRIP) > > Author(s) : J. Jiang, D. Walker, D. Zinman > > Filename : draft-ietf-iptel-trip-mib-00.txt > > Pages : 40 > > Date : 20-Aug-01 > > > > This memo defines a portion of the Management Information Base (MIB) > > for use with network management protocols in the Internet community. > > In particular, it describes a set of managed objects that are used > > to manage for Telephony Routing over IP (TRIP) [2] devices. > > Since TRIP [2] is modelled after the Border Gateway Protocol (BGP-4) > > [3], the managed objects for TRIP are also modelled after RFC1657 - > > Definitions of Managed Objects for the Fourth Version of the Border > > Gateway Protocol (BGP-4) using SMIv2 [4]. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-00.txt > > > > 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-trip-mib-00.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-trip-mib-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > _______________________________________________ > > IPTEL mailing list > > IPTEL@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/iptel > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC-24/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Sep 6 05:13:27 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18206 for ; Thu, 6 Sep 2001 05:13:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 590194433C; Thu, 6 Sep 2001 04:15:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8A4A144337 for ; Thu, 6 Sep 2001 04:14:24 -0400 (EDT) Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2652.35) id ; Thu, 6 Sep 2001 10:12:49 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940B7613B3@mbtlipnt01.btlabs.bt.co.uk> From: gerry.simblett@bt.com To: iptel@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] A wee error in CPL draft 4 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 6 Sep 2001 10:11:21 +0100 According to the draft, nodes have a default setting for attribute recurse of "yes". In this case there should be no output on the node as the proxy handles redirections itself. The example in figure 20 on page 38 shows a node with no attributes and which contains and outputs. If my understanding is correct then the node will assume a default attribute setting of recurse="yes" and the output in the example is therefore invalid, or actually as the rule (on page 27 pp 3) is only a SHOULD NOT it is valid but never taken. Gerry _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 7 08:19:35 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09146 for ; Fri, 7 Sep 2001 08:19:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 357D144337; Fri, 7 Sep 2001 07:21:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from liffey.metamatrix.se (liffey.metamatrix.se [213.88.195.123]) by lists.bell-labs.com (Postfix) with ESMTP id B494544336 for ; Fri, 7 Sep 2001 06:59:44 -0400 (EDT) Received: from foo (unknown [213.88.195.114]) by liffey.metamatrix.se (Postfix) with SMTP id 90BB61FC8E; Fri, 7 Sep 2001 13:59:36 +0200 (CEST) From: "Greg FitzPatrick" To: Cc: , Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-reply-to: <030501c136f1$00384330$092e0165@in.steltor.com> Subject: [IPTEL] iCal - SkiCal - iptel Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 7 Sep 2001 13:59:57 +0200 Content-Transfer-Encoding: 7bit This was sent to us off-list but since the point made is quite relevant not only to SkiCal but to the iptel discussions that I will cite the question and answer it here. : I suppose it's a little late for major structural changes :) , but I :was wondering why you don't use some sort of VEVENT reference pointing :to a separate VEVENT describing the time (and other) details of the :property? The reference here is to the proposed SkiCal mechanism for qualifying particular aspects of an event (or as we say SkiSource). For example there might be a scheduled event: BEGIN:VCALENDAR ... BEGIN:VEVENT ORGANIZER:MAILTO:greg@skical.org DTSTART:20010907T113000 DTEND:20010907T160000 ... SUMMARY:Audition schedules for Commedy Hour ... END:VEVENT END:VCALENDAR With SkiCal you can make statements about particpants in the event as follows: ... SKiCal-PEOPLE;SKIROLE="Judge":Tom SKiCal-PEOPLE;SKIROLE="Auditioning":Alice SKiCal-PEOPLE;SKIROLE="Auditioning":Bob SKiCal-PEOPLE;SKIROLE="Auditioning":Carol and it might be expedient to include the individual times for the three participants which you can do in the proposed revision of SkiCal as follows: SKiCal-PEOPLE;SKIROLE="Judge":Tom SKiCal-PEOPLE;SKIROLE="Auditioning";OPREF="slot-1":Alice SKiCal-PEOPLE;SKIROLE="Auditioning";OPREF="slot-2":Bob SKiCal-PEOPLE;SKIROLE="Auditioning";OPREF="slot-3":Carol The opref value points to an OPENTIMES declaration that is made on the OPTIMES property OPTIMES: OPTIMES: OPTIMES: (actually you don't have to repeat the OPTERM on every slot - it can be IDREF:ed as well. When parsed this would result in something like this *** Audition schedules for Comedy Hour - September 7th - 2001 *** 1200 - 1245 Alice 1300 - 1345 Bob 1400 - 1445 Carol the rest of the question reads... > It seems this would be more consistent, from an engineering >point of view. Although it would require a little more text, recall >that VEVENTs don't need to be very large at all - having a UID, start, >and end time would be sufficient for most purposes. And having the >information as a separate VEVENT would allow consumers of the data to >choose portions of an event that they're interested in for incorporation >in their calendar (for example, some users might only be interested in >bar opening & closing times for an event, and not the main show ;) Which of course makes good sense, but still necessitates a new property parameter that accomplishes the reference to the appropriate VEVENTs. The existing RELATED-TO 2445 property cannot of course distinguish relationships to particular aspects of a calendar object. The advantages of VEVENTS for this purpose are evident. Among other versioning comes immediately to mind. And of course for SkiCal users this would give a choice of using DTSTART and its related properties or DTOPEN. http://www.skical.org/skical20010905.html#DTOPEN Of course this also points to possibilities for the IPTEL problems, since DTOPEN pointing to an optimeset is probably a much better solution for the IPTEL use-domain. (IMHO) Greg _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 7 10:36:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15760 for ; Fri, 7 Sep 2001 10:36:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5E01C4434B; Fri, 7 Sep 2001 09:38:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail1.dynamicsoft.com (unknown [63.113.40.10]) by lists.bell-labs.com (Postfix) with ESMTP id 3DC8044336 for ; Fri, 7 Sep 2001 09:37:01 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f87Ea4Cj026918 for ; Fri, 7 Sep 2001 10:36:05 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 10:36:57 -0400 Message-ID: From: Jonathan Rosenberg To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] TRIP approved as RFC! Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 7 Sep 2001 10:36:52 -0400 Folks, I am pleased to announce that draft-ietf-iptel-trip-09 has been formally approved by IESG for proposed standard. Great work! -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 7 14:44:36 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23745 for ; Fri, 7 Sep 2001 14:44:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 875A84434F; Fri, 7 Sep 2001 13:46:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id CB68E44336 for ; Fri, 7 Sep 2001 13:45:43 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A5D560EF0144; Fri, 07 Sep 2001 14:45:41 -0400 Message-ID: <00e501c137cd$157fb980$2300000a@acmepacket.com> From: "Bob Penfield" To: "IPTEL List" Cc: "Ping Zhou" , "Ephraim Dobbins" , "Peter Commerford" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [IPTEL] Review of draft-ietf-iptel-trip-mib-00.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 7 Sep 2001 14:44:06 -0400 Content-Transfer-Encoding: 7bit We have completed our review of the TRIP MIB and have a number of comments enumerated below. Special thanks to Ping Zhou, Ephraim Dobbins, and Peter Commerford for their assistance in this review. The most significant issue is that of the tripRouteTable. It is not clear which specific TRIBs it represents. Also, based on some of the information in the table, it seems to combine data from received and derived routes (e.g. tripRouteBest) which may prove problematic for implementers. If implementers follow the TRIB structure defined in the base spec, they may need to instantiate another derived/combined TRIB for SNMP reporting. Otherwise significant processing/combing of the TRIBs might be required to respond to a GET. I don't know whether the right thing to do is have a separate table for each TRIB or to only report specific sets of TRIBs. The closest thing to what the table defined represents is the Adj-TRIB-Ins of internal peers plus the Ext-TRIB derived from local routes and Adj-TRIB-Ins of external peers. Or am I missing something? 1) Section 4. change "with other TRIP gateways" to "between TRIP Location Servers". 2) Section 4. change "" to "[2]". 3) Section 5 & 5.1. suggest "TRIP LS" instead of "TRIP entity", or add "(a.k.a. TRIP LS)". 4) Several places use TripItad for community-id. Community ID is not an ITAD ID and should be its own type. Suggest adding CommunityId to Textual Conventions on page 6. 5) TripCfgEntry: Hussein said that the other timers (ConnectRetry, HoldTime, KeepAlive) belong here. The spec does not explicitly say whether these are configured for the LS (like SendReceiveMode) or on a per-peer basis. The MIB defines them as per-peer parameters (in TripPeerEntry). However, a given implementation might implement them as LS-wide parameters. Should they be defined in both places to support both kinds implementations? Or should the spec be interpreted as defining these as LS-wide parameters? 6) tripLocalAddr: The description should say this is the IP address of the local LS that peers connect to. 7) tripLocalPort: The description should say this is the port on the local LS that peers connect to. 8) tripSupportedCommunityId: A community ID is not an ITAD. suggest CommunityID (see issue 4 above). 9) tripPeerEntry: The key consists of only the peer's network type and address. The spec supports the idea of multiple TRIP instances on a single host. The tripPeerRemotePort needs to be included. However, this is defined as read-only, which indicates this port is learned when the connection is established. If the peer initiated the connection, this may not be the same port that the local LS would attempt to connect to. If the TripPeerIdentifier and TripPeerRemoteItad were configured parameters, they could be used as a unique key. However, the TripPeerIdentifier is read-only (indicating is learned during the connection), but the TripPeerRemoteItad is read-create (indicating it is configured). From reading the spec, these could be either configured or learned. I think what is needed is tripRemotePeerPortConfigured (the port this LS will try to connect to) to be added to the key. There is not currently a field for this. 10) tripPeerRemoteItad: Should this be "read-only" ? or should tripPeerIdentifier be "read-create". I think they should be the same. 11) tripPeerKeepAlive: The description should indicate that this is the negotiated value when a connection is established. 12) tripPeerRouteTypeTable: This table is the expansion table of tripPeerTable (base table). The DESCRIPTION clause should specify the relationship of the instances in the base table and expansion table, when elements in the expansion table should be added or removed due to the change of the base table. This kind of description will be very helpful in implementing this table, otherwise it will cause confusion and may be inconsistent with different implementations. Same issue for tripRouteCommunityEntry & tripRouteEntry, and tripItadTopogyIdTable & tripItadTopologyTable. 13) tripRouteTable: It is not totally clear which TRIBs this table contains. It says "received routes" which implies it is the Adj-TRIB-Ins of all peers (internal & external). However, the presence of tripRouteAddressOriginatorId without an originating ITAD would indicate that routes derived from external sources inserted into the Ext-TRIB should be included as opposed to the received Adj-TRIB-In of the external peer (as they would have the local LSs TripID as the OriginatorID). Hussein brought up the issue of whether we need a table with the routes that the LS will advertise. 14) tripRouteAddress: a size of 32 is certainly reasonable for just a telephone number, but I have heard talk of a number of different address families that might involve concatenating things like CIC-code, carrier-domain or any other kind of so called "routable element". Would it hurt to have this be 255 instead? 15) tripRouteEntry: tripRouteAddressOriginatorId should be in the key instead of tripRoutePeer. A given LS may "learn" several routes from a peer where the only distinguishing characteristic of the route is the Trip ID of the originating LS. same issue for tripRouteCommunityEntry 16) tripRouteEntry: you have tripRoutePeer which is the Trip ID of the LS that sent the route, but there is not tripRoutePeerITAD to identify the ITAD that the peer is in. 17) tripRouteAddressOriginatorId should be a TripId instead of a TripItad. 18) tripBestRoute: I'm not sure what this means. Maybe you need to identify the decision process phase in which this is determined. 19) tripRouteCommunityId: A community ID is not an ITAD. suggest CommunityID (see issue 4 above). 20) tripITADTopologyOrigId should be a TripId instead of a TripItad. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Sep 13 14:43:18 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12884 for ; Thu, 13 Sep 2001 14:43:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EA1A144337; Thu, 13 Sep 2001 13:42:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 1CCCF44336 for ; Thu, 13 Sep 2001 12:10:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09577; Thu, 13 Sep 2001 13:10:57 -0400 (EDT) Message-Id: <200109131710.NAA09577@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: iptel@lists.bell-labs.com From: The IESG Subject: [IPTEL] Protocol Action: Telephony Routing over IP (TRIP) to Proposed Standard Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 13 Sep 2001 13:10:57 -0400 The IESG has approved the Internet-Draft 'Telephony Routing over IP (TRIP)' as a Proposed Standard. This document is the product of the IP Telephony Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. TRIP is modeled after the Border Gateway Protocol 4 (BGP-4) and enhanced with some link state features as in the Open Shortest Path First (OSPF) protocol, IS-IS, and the Server Cache Synchronization Protocol (SCSP). TRIP uses BGP's inter-domain transport mechanism, BGP's peer communication, BGP's finite state machine, and similar formats and attributes as BGP. Unlike BGP however, TRIP permits generic intra-domain LS topologies, which simplifies configuration and increases scalability in contrast to BGP's full mesh requirement of internal BGP speakers. TRIP uses an intra-domain flooding mechanism similar to that used in OSPF, IS-IS, and SCSP. Working Group Summary The working group supports this protocol, no significant issues were raised during IETF Last-Call. Protocol Quality This document was reviewed for the IESG by Scott Bradner _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Sep 26 05:33:38 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11241 for ; Wed, 26 Sep 2001 05:33:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DF99544338; Wed, 26 Sep 2001 04:31:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from znsgs0ja.europe.nortel.com (unknown [47.165.25.40]) by lists.bell-labs.com (Postfix) with ESMTP id 96C2544337 for ; Wed, 26 Sep 2001 04:30:26 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f8Q9Wig07993 for ; Wed, 26 Sep 2001 10:32:44 +0100 (BST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Wed, 26 Sep 2001 10:32:32 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Sep 2001 10:32:27 +0100 Message-ID: <1FEA020C9C89D511B9C00008C71642C2106680@znsgy0k5.europe.nortel.com> From: "William Hern" To: "'iptel@lists.bell-labs.com'" Cc: "William Parton" , "Robert Ruth" , "Chris Bingham" , "Patrick Bradd" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1466E.262636B0" Subject: [IPTEL] TRIP byte/bit ordering Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 26 Sep 2001 10:32:24 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1466E.262636B0 Content-Type: text/plain; charset="iso-8859-1" [Apologies to anyone who has received this message twice.] I have studied the TRIP RFC and those that it references (as well the iptel mailing list) for a definitive statement on the bit/byte ordering to be used within TRIP messages (i.e. big/little endian) but have been unable to find any such statement. Looking at Version 09 of the draft TRIP spec, the bit ordering in the diagrams would suggest little-endian but the attribute flag section (S4.3.2) implies big-endian. Is this aspect of the protocol defined in the RFC(s) or is there a general RFC covering this low level aspect of protocol implementation? If so could someone please point me in its direction. Many thanks in advance. Will William Hern, Dept. CV06-M, Translations and Service Development Nortel Networks UK Ltd, Concorde Road, Maidenhead, UK. Email: whern@nortelnetworks.com ESN Tel: 590 4780 External Tel: +(44) 1628 434780 Fax: +(44) 1628 431105 Corporate Intranet Web page: http://47.96.0.203/home/whern Registered office: Maidenhead Office Park, Westacott Way, Maidenhead, Berkshire, SL6 3QH. Company number 3937799 ------_=_NextPart_001_01C1466E.262636B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TRIP byte/bit ordering

[Apologies to anyone who has received this message = twice.]

I have studied the TRIP RFC and those that it = references (as well the iptel mailing list) for a definitive statement = on the bit/byte ordering to be used within TRIP messages (i.e. = big/little endian) but have been unable to find any such statement. = Looking at Version 09 of the draft TRIP spec, the bit ordering in the = diagrams would suggest little-endian but the attribute flag section = (S4.3.2) implies big-endian.

Is this aspect of the protocol defined in the RFC(s) = or is there a general RFC covering this low level aspect of protocol = implementation? If so could someone please point me in its = direction.

Many thanks in advance.

Will

William Hern, Dept. CV06-M, Translations and Service = Development
Nortel Networks UK Ltd, Concorde Road, Maidenhead, = UK.
Email: whern@nortelnetworks.com
ESN Tel: 590 4780 External Tel: +(44) 1628 434780 = Fax: +(44) 1628 431105
Corporate Intranet Web page: http://47.96.0.203/home/whern
Registered office: Maidenhead Office Park, Westacott = Way, Maidenhead, Berkshire, SL6 3QH.
Company number 3937799

------_=_NextPart_001_01C1466E.262636B0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Sep 26 07:36:39 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13446 for ; Wed, 26 Sep 2001 07:36:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B41064433B; Wed, 26 Sep 2001 06:34:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by lists.bell-labs.com (Postfix) with ESMTP id 209FA44337 for ; Wed, 26 Sep 2001 06:33:10 -0400 (EDT) Received: from BobP (h-64-105-110-5.chcgilgm.covad.net [64.105.110.5]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with ESMTP id f8QBZew262216; Wed, 26 Sep 2001 07:35:40 -0400 Message-ID: <001801c1467f$1e7bb820$6401a8c0@acmepacket.com> From: "Bob Penfield" To: "William Hern" , References: <1FEA020C9C89D511B9C00008C71642C2106680@znsgy0k5.europe.nortel.com> Subject: Re: [IPTEL] TRIP byte/bit ordering MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 26 Sep 2001 07:33:51 -0400 Content-Transfer-Encoding: 7bit TRIP, like all IP related protocols uses big endian. See Appendix B of RFC 791. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "William Hern" To: Cc: "William Parton" ; "Robert Ruth" ; "Chris Bingham" ; "Patrick Bradd" Sent: Wednesday, September 26, 2001 5:32 AM Subject: [IPTEL] TRIP byte/bit ordering > [Apologies to anyone who has received this message twice.] > > I have studied the TRIP RFC and those that it references (as well the iptel > mailing list) for a definitive statement on the bit/byte ordering to be used > within TRIP messages (i.e. big/little endian) but have been unable to find > any such statement. Looking at Version 09 of the draft TRIP spec, the bit > ordering in the diagrams would suggest little-endian but the attribute flag > section (S4.3.2) implies big-endian. > > Is this aspect of the protocol defined in the RFC(s) or is there a general > RFC covering this low level aspect of protocol implementation? If so could > someone please point me in its direction. > > Many thanks in advance. > > Will > > William Hern, Dept. CV06-M, Translations and Service Development > Nortel Networks UK Ltd, Concorde Road, Maidenhead, UK. > Email: whern@nortelnetworks.com > ESN Tel: 590 4780 External Tel: +(44) 1628 434780 Fax: +(44) 1628 431105 > Corporate Intranet Web page: http://47.96.0.203/home/whern > Registered office: Maidenhead Office Park, Westacott Way, Maidenhead, > Berkshire, SL6 3QH. > Company number 3937799 > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Sep 26 15:15:42 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26771 for ; Wed, 26 Sep 2001 15:15:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7505E44353; Wed, 26 Sep 2001 14:11:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from znsgs0ja.europe.nortel.com (unknown [47.165.25.40]) by lists.bell-labs.com (Postfix) with ESMTP id A03CC44337 for ; Tue, 25 Sep 2001 04:35:40 -0400 (EDT) Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31]) by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f8P9bog02888 for ; Tue, 25 Sep 2001 10:37:50 +0100 (BST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Tue, 25 Sep 2001 10:37:20 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 10:36:41 +0100 Message-ID: <588B15E2E2B1D41180B800508BF934F251EC64@bmdhd6.europe.nortel.com> From: "William Parton" To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C145A5.8F764DE0" Subject: [IPTEL] TRIP byte/bit ordering Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 25 Sep 2001 10:36:32 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C145A5.8F764DE0 Content-Type: text/plain; charset="iso-8859-1" I have studied the TRIP RFC and those that it references (as well the iptel mailing list) for a definitive statement on the bit/byte ordering to be used within TRIP messages (i.e. big/little endian) but have been unable to find any such statement. Is this aspect of the protocol defined in the RFC(s) or is there a general RFC covering this low level aspect of protocol implementation? If so could someone please point me in its direction. regards Will ------_=_NextPart_001_01C145A5.8F764DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TRIP byte/bit ordering

I have studied the TRIP RFC and those that it = references (as well the iptel mailing list) for a definitive statement = on the bit/byte ordering to be used within TRIP messages (i.e. = big/little endian) but have been unable to find any such statement. Is = this aspect of the protocol defined in the RFC(s) or is there a general = RFC covering this low level aspect of protocol implementation? If so = could someone please point me in its direction.

regards
Will

------_=_NextPart_001_01C145A5.8F764DE0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Sep 27 07:54:46 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27108 for ; Thu, 27 Sep 2001 07:54:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9C28344338; Thu, 27 Sep 2001 06:52:03 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id 0CE3F44337 for ; Thu, 27 Sep 2001 06:51:11 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A348AA8602E8; Thu, 27 Sep 2001 07:53:44 -0400 Message-ID: <001a01c1474a$ae58ed20$2300000a@acmepacket.com> From: "Bob Penfield" To: "William Parton" , References: <588B15E2E2B1D41180B800508BF934F251EC64@bmdhd6.europe.nortel.com> Subject: Re: [IPTEL] TRIP byte/bit ordering MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 27 Sep 2001 07:51:01 -0400 Content-Transfer-Encoding: 7bit In general, everything over IP is big endian. See Appendix B of RFC 791. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "William Parton" To: Sent: Tuesday, September 25, 2001 5:36 AM Subject: [IPTEL] TRIP byte/bit ordering > I have studied the TRIP RFC and those that it references (as well the iptel > mailing list) for a definitive statement on the bit/byte ordering to be used > within TRIP messages (i.e. big/little endian) but have been unable to find > any such statement. Is this aspect of the protocol defined in the RFC(s) or > is there a general RFC covering this low level aspect of protocol > implementation? If so could someone please point me in its direction. > > regards > Will > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 28 22:36:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00947 for ; Fri, 28 Sep 2001 22:36:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E272944338; Fri, 28 Sep 2001 21:34:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from femail23.sdc1.sfba.home.com (femail23.sdc1.sfba.home.com [24.0.95.148]) by lists.bell-labs.com (Postfix) with ESMTP id 13D5E44337 for ; Fri, 28 Sep 2001 21:33:45 -0400 (EDT) Received: from cc1006702a ([24.3.208.68]) by femail23.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010929023635.RNEH29951.femail23.sdc1.sfba.home.com@cc1006702a> for ; Fri, 28 Sep 2001 19:36:35 -0700 Message-ID: <002901c1488f$993b7b60$777ba8c0@etntwn1.nj.home.com> From: "vrgr" To: Subject: [IPTEL] unsubscribe IPTEL MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C1486E.11770620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 28 Sep 2001 22:36:51 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C1486E.11770620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe IPTELunsubscribe IPTEL=20 ------=_NextPart_000_0026_01C1486E.11770620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe IPTEL
unsubscribe IPTEL =
------=_NextPart_000_0026_01C1486E.11770620-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel