From kcartwright@tnsi.com Tue May 3 08:59:50 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18267E062A for ; Tue, 3 May 2011 08:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b92aH-+pUxkW for ; Tue, 3 May 2011 08:59:49 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 574BAE06B5 for ; Tue, 3 May 2011 08:59:48 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.53889133; Tue, 03 May 2011 11:59:44 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 3 May 2011 11:59:44 -0400 From: "Cartwright, Ken" To: "drinks@ietf.org" Date: Tue, 3 May 2011 11:59:44 -0400 Thread-Topic: New Version Notification for draft-ietf-drinks-sppp-over-soap-03 Thread-Index: AcwJqwZybM6YtHakSQm4n4qJySex6wAAA9xw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA31133ED6EB@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [drinks] FW: New Version Notification for draft-ietf-drinks-sppp-over-soap-03 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 15:59:50 -0000 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, May 03, 2011 11:59 AM To: Cartwright, Ken Subject: New Version Notification for draft-ietf-drinks-sppp-over-soap-03 A new version of I-D, draft-ietf-drinks-sppp-over-soap-03.txt has been succ= essfully submitted by Kenneth Cartwright and posted to the IETF repository. Filename: draft-ietf-drinks-sppp-over-soap Revision: 03 Title: SPPP Over SOAP and HTTP Creation_date: 2011-05-03 WG ID: drinks Number_of_pages: 16 Abstract: The Session Peering Provisioning Protocol (SPPP) is an XML protocol that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport for SPPP is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPP XML structures over SOAP and HTTP(s). The IETF Secretariat. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From Internet-Drafts@ietf.org Tue May 3 09:00:03 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38B7E0713; Tue, 3 May 2011 09:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoex7DfEX4K3; Tue, 3 May 2011 09:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D3FE065F; Tue, 3 May 2011 09:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110503160002.23722.28580.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2011 09:00:02 -0700 Cc: drinks@ietf.org Subject: [drinks] I-D Action:draft-ietf-drinks-sppp-over-soap-03.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 16:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Data for Reachability of Inter/tra-NetworK SIP Working Group of the IETF. Title : SPPP Over SOAP and HTTP Author(s) : K. Cartwright Filename : draft-ietf-drinks-sppp-over-soap-03.txt Pages : 16 Date : 2011-05-03 The Session Peering Provisioning Protocol (SPPP) is an XML protocol that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport for SPPP is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPP XML structures over SOAP and HTTP(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-sppp-over-soap-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-drinks-sppp-over-soap-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-03085858.I-D@ietf.org> --NextPart-- From mickaelmarrache@gmail.com Wed May 4 06:35:37 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9448EE078F for ; Wed, 4 May 2011 06:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH3c+l4AO06C for ; Wed, 4 May 2011 06:35:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A524E0779 for ; Wed, 4 May 2011 06:35:36 -0700 (PDT) Received: by wyb29 with SMTP id 29so962192wyb.31 for ; Wed, 04 May 2011 06:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=qhbn8whos3Kxd+fnwp+CO/iW2jmxu68Lhgb1r6nKGhk=; b=KDheueGBCUsBsk5zGbKPgwGrBMdmXsy6a5MFzHRz3oVC9UE0qF+JSZXbSHnGFG7+Bh tMIhqCqN3F/C9xPQRR3B9AuuZUxgKAHZYC6DLEpZeKDJ2DGP0Y8AmVOiUsqNYh94qpAZ iuxDabj3zTRbLj9pkD3iOTxUqPBS2TxQJa4YM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Mkjm0/fM7agD2V33FD4mSn+DpMq+dyh2afLEnKnf56qdL1wlGIxHorlfoNhhp8qzMD j9M9uZWYZPmmpnYzTznXy1IC4coKDlzYHZ/pgp4gv/8OoOYpuJnehj4EXur6bLqyKvp3 eQ9sTFI2DpKcb7ekM1gXjK85yyUx3LIHiN3q4= MIME-Version: 1.0 Received: by 10.216.120.202 with SMTP id p52mr931341weh.54.1304516135088; Wed, 04 May 2011 06:35:35 -0700 (PDT) Received: by 10.216.29.203 with HTTP; Wed, 4 May 2011 06:35:35 -0700 (PDT) Date: Wed, 4 May 2011 16:35:35 +0300 Message-ID: From: Mickael MARRACHE To: drinks@ietf.org Content-Type: multipart/alternative; boundary=00261887666ad5f53304a27354be Subject: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 13:35:37 -0000 --00261887666ad5f53304a27354be Content-Type: text/plain; charset=ISO-8859-1 Hey, Some questions/suggestions: 1) Implementation difficulties due to multiple use of 'ext' element with inheritance (for example BasicObjType and RteGrpOfferType). 2) Why did you remove the rarId element of BasicObjType? I think we have to use a registrar ID to differentiate between proprietary of SEDs and operation caller? --00261887666ad5f53304a27354be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey,

Some questions/suggestions:

1) Implemen= tation difficulties due to multiple use of 'ext' element with inher= itance (for example BasicObjType and RteGrpOfferType).

2) Why did yo= u remove the rarId element of BasicObjType? I think we have to use a regist= rar ID to differentiate between proprietary of SEDs and operation caller?


--00261887666ad5f53304a27354be-- From kcartwright@tnsi.com Wed May 4 06:55:56 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3251FE06B0 for ; Wed, 4 May 2011 06:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe22iyoLb6sG for ; Wed, 4 May 2011 06:55:54 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89A1AE06A4 for ; Wed, 4 May 2011 06:55:54 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.53919543; Wed, 04 May 2011 09:55:46 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 4 May 2011 09:55:46 -0400 From: "Cartwright, Ken" To: Mickael MARRACHE , "drinks@ietf.org" Date: Wed, 4 May 2011 09:55:45 -0400 Thread-Topic: [drinks] Questions SPPP Thread-Index: AcwKYCyJ+0yVmfIrQ3+IblsTtI0+BQAAhMmQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA31133EDAF5@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA31133EDAF5TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 13:55:56 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA31133EDAF5TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Thanks for your comments: 1) Yes. Very good point. The name of the ext element in the base ty= pe should not be the same name of the ext element in the concrete type. Pl= ease go ahead and change the name in your local XSD so that you can move fo= rward and we will put this on the "To-Do" list for the document. 2) We removed the rarId element because there is no concrete use-case= that requires it to be in the protocol, and having it in there creates som= e additional work and some potential interoperability challenges for some o= f the authors. However, it is certainly true that any server implementatio= n of SPPP will need to _internally_ maintain an identifier of the registrar= that created each object. That identifier would, at a minimum, end up bei= ng used for authorization and reporting. Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Mickael MARRACHE Sent: Wednesday, May 04, 2011 9:36 AM To: drinks@ietf.org Subject: [drinks] Questions SPPP Hey, Some questions/suggestions: 1) Implementation difficulties due to multiple use of 'ext' element with in= heritance (for example BasicObjType and RteGrpOfferType). 2) Why did you remove the rarId element of BasicObjType? I think we have to= use a registrar ID to differentiate between proprietary of SEDs and operat= ion caller? ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA31133EDAF5TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Thanks for your comments:

 

1) &= nbsp;     Yes.  Very good point.  The name of the ext element i= n the base type should not be the same name of the ext element in the concrete type.  Please go ahead and change the name in your lo= cal XSD so that you can move forward and we will put this on the “To-= Do” list for the document.

2) &= nbsp;     We removed the rarId element because there is no concrete use-c= ase that requires it to be in the protocol, and having it in there creates some additional work and some potential interop= erability challenges for some of the authors.  However, it is certainl= y true that any server implementation of SPPP will need to _internally_ maintain an identifier of the registrar that created each object.  Th= at identifier would, at a minimum, end up being used for authorization and = reporting.

 

Ken

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael MARRACH= E
Sent: Wednesday, May 04, 201= 1 9:36 AM
To: drinks@ietf.org
Subject: [drinks] Questions = SPPP

 

Hey,

Some questions/suggestions:

1) Implementation difficulties due to multiple use of 'ext' element with in= heritance (for example BasicObjType and RteGrpOfferType).

2) Why did you remove the rarId element of BasicObjType? I think we have to= use a registrar ID to differentiate between proprietary of SEDs and operat= ion caller?



This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA31133EDAF5TNSMAILNAwin2_-- From mickaelmarrache@gmail.com Thu May 5 11:17:52 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B861E0901 for ; Thu, 5 May 2011 11:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOYNQs1je9KZ for ; Thu, 5 May 2011 11:17:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C913E08F8 for ; Thu, 5 May 2011 11:17:50 -0700 (PDT) Received: by wyb29 with SMTP id 29so2093167wyb.31 for ; Thu, 05 May 2011 11:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=207zglOfKVzVblLhsZxhgIebj/wK14mj+uVLhYVCjoc=; b=wPYwJNecFB8EeHS3jXXLZp5o42+odue1uAGiiWUHMBDyyZUPI9ujuAjqPeqXja4aWg oz3KQN6+cTImj5PLZ1syIuA88OqxLhVoxTOlxx9dNQdwLbbXL+pJ0ccku1DE20jy9KXm UHiP/p/+e9G50PeaEJ9fc+5xlvt4g6rAK7UP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=lfqaR2SMIf8pC57JywaOg6SxFahWqgfbcYGsD6oxAp1Nmyk0aEUZud2JqKcAAxJ1d4 iXOCafai9NSE3p497ZIc7q2zG0cs25jyauFv6Slnsx3Nr73sTVO4DdVjJ4JEqXCjsNqh OqNxzXqGHkLcOezR5QCmjEZ6FmaN5EEde0m2U= MIME-Version: 1.0 Received: by 10.216.65.203 with SMTP id f53mr2134008wed.54.1304619468486; Thu, 05 May 2011 11:17:48 -0700 (PDT) Received: by 10.216.29.203 with HTTP; Thu, 5 May 2011 11:17:48 -0700 (PDT) Date: Thu, 5 May 2011 21:17:48 +0300 Message-ID: From: Mickael MARRACHE To: drinks@ietf.org Content-Type: multipart/alternative; boundary=000e0ce0b4eafc77ea04a28b63a2 Subject: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:17:52 -0000 --000e0ce0b4eafc77ea04a28b63a2 Content-Type: text/plain; charset=ISO-8859-1 Hey, It is specified: "A telephone number is provisioned using the TNType, an extension of PubIDType. Each TNType object is uniquely identified by the combination of its tn element, and the unique key of its parent Destination Group (dgName and rantId)."(page 29) How a telephone number (TNType) is identified in the case it is directly associated to route records? I guess with registrant ID and tn? If yes, for a given registrant, there can't be two telephone number associated with two different sets of route records? Is that a problem? --000e0ce0b4eafc77ea04a28b63a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey,

It is specified: "A telephone number is p= rovisioned using the TNType, an extension of
=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PubIDType. Each TNType object is un= iquely identified by the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 combination of its tn element, and the unique key of = its parent
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destinat= ion Group (dgName and rantId)."(page 29)

How a telephone number= (TNType) is identified in the case it is directly associated to route reco= rds? I guess with registrant ID and tn? If yes, for a given registrant, the= re can't be two telephone number associated with two different sets of = route records? Is that a problem?
--000e0ce0b4eafc77ea04a28b63a2-- From kcartwright@tnsi.com Thu May 5 11:53:51 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47117E07E5 for ; Thu, 5 May 2011 11:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGZAnzjKXwZl for ; Thu, 5 May 2011 11:53:49 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id A7A07E07B3 for ; Thu, 5 May 2011 11:53:48 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.53966819; Thu, 05 May 2011 14:53:44 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 5 May 2011 14:53:44 -0400 From: "Cartwright, Ken" To: Mickael MARRACHE , "drinks@ietf.org" Date: Thu, 5 May 2011 14:53:43 -0400 Thread-Topic: [drinks] Questions SPPP Thread-Index: AcwLUXVuiU0gxvTGQWK+UtPT1hQYagAAVPdQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA31133EE432@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA31133EE432TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:53:51 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA31133EE432TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mickael, Having two TNTypes that reside within different DestGroups and that contain= the same telephone number does not create a problem, in fact the protocol = was designed, in part, to support that requirement. The spec statement "In= other words, a given telephone number string may exist within one or more = Destination Groups, but must not exist more than once within a Destination = Group." Your point about the spec failing to explicitly state how to uniquely ident= ify a TNType object that does not reside in a Destination Group, is a valid= one. We can add a sentence that speaks to that. But your assumption abou= t how to do it is accurate, use the combination of the TN string and the ra= ntID. Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Mickael MARRACHE Sent: Thursday, May 05, 2011 2:18 PM To: drinks@ietf.org Subject: [drinks] Questions SPPP Hey, It is specified: "A telephone number is provisioned using the TNType, an ex= tension of PubIDType. Each TNType object is uniquely identified= by the combination of its tn element, and the unique key of= its parent Destination Group (dgName and rantId)."(page 29) How a telephone number (TNType) is identified in the case it is directly as= sociated to route records? I guess with registrant ID and tn? If yes, for a= given registrant, there can't be two telephone number associated with two = different sets of route records? Is that a problem? ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA31133EE432TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mickael,

 

Having two TNTypes that reside within different DestGroups and = that contain the same telephone number does not create a problem, in fact the protocol was designed, in part, to suppo= rt that requirement.  The spec statement “In other words, a given telephone number string may exist within one or more = Destination Groups, but must not exist more than once within a Destination = Group.<= span style=3D"font-size:10.0pt;font-family:"Courier New"; color:black">”

 

Your point about the spec failing to e= xplicitly state how to uniquely identify a TNType object that does not resi= de in a Destination Group, is a valid one.  We can add a sentence that speaks to that.&nb= sp; But your assumption about how to do it is accurate, use the combination= of the TN string and the rantID.

 

Ken

 

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael MARRACH= E
Sent: Thursday, May 05, 2011= 2:18 PM
To: drinks@ietf.org
Subject: [drinks] Questions = SPPP

 

Hey,

It is specified: "A telephone number is provisioned using the TNType, = an extension of
            &nb= sp;          PubIDType. Each T= NType object is uniquely identified by the
            &nb= sp;          combination of it= s tn element, and the unique key of its parent
            &nb= sp;          Destination Group= (dgName and rantId)."(page 29)

How a telephone number (TNType) is identified in the case it is directly as= sociated to route records? I guess with registrant ID and tn? If yes, for a= given registrant, there can't be two telephone number associated with two = different sets of route records? Is that a problem?


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA31133EE432TNSMAILNAwin2_-- From mickaelmarrache@gmail.com Thu May 5 12:01:25 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9014E07E5 for ; Thu, 5 May 2011 12:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIznU6jZuy-6 for ; Thu, 5 May 2011 12:01:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91EB0E07BC for ; Thu, 5 May 2011 12:00:54 -0700 (PDT) Received: by wwa36 with SMTP id 36so1876816wwa.13 for ; Thu, 05 May 2011 12:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=egHu/LNbAUYOe8RnyxN9I241sr5tPhWk0WFuNzmeCR8=; b=a6N58poAEgyKI13TYnKM4jHuQftSHhq0i3Md88dJ0uHI7Wwza35mXetWWZzEHJOZJn p5lqczkFK+drctJ6euRrTRBsS3PxsJf2jeyooakx1HcV8PtfxgI3Ie//rXUx5lmX+hfe D4AouVyyimTha2xXgQisdZpGln0VR5ujP7yCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Lr5YY5pdkG1vYPPkPG7KzKqqAWgarSHpVGlrivIaZCO8NMbO3mMPblYGFDC+6qD2GI Zqkh7H2nuxqhnmbSv3D3BMXZMgWKNzp6dIIhCyv7C+/BevR6R5j/Cy+H9QtgxoaGKlwQ KKEYKhqrMQguC5yE6/VlSNZItCjjXW0Pb1Zzw= MIME-Version: 1.0 Received: by 10.216.152.170 with SMTP id d42mr3099350wek.39.1304622053536; Thu, 05 May 2011 12:00:53 -0700 (PDT) Received: by 10.216.29.203 with HTTP; Thu, 5 May 2011 12:00:53 -0700 (PDT) In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA31133EE432@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA31133EE432@TNS-MAIL-NA.win2k.corp.tnsi.com> Date: Thu, 5 May 2011 22:00:53 +0300 Message-ID: From: Mickael MARRACHE To: "Cartwright, Ken" , drinks@ietf.org Content-Type: multipart/alternative; boundary=000e0cd51aee11353004a28bfe04 Subject: Re: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 19:01:25 -0000 --000e0cd51aee11353004a28bfe04 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My question was about the second point, "how to uniquely identify a TNType object that does not reside in a Destination Group". If my assumption is valid, what about the question "If yes, for a given registrant, there can't be two telephone number associated with two different sets of route records= ? Is that a problem?" On Thu, May 5, 2011 at 9:53 PM, Cartwright, Ken wrote= : > Hi Mickael, > > > > Having two TNTypes that reside within different DestGroups and that conta= in > the same telephone number does not create a problem, in fact the protocol > was designed, in part, to support that requirement. The spec statement = =93In > other words, a given telephone number string may exist within one or more > Destination Groups, but must not exist more than once within a Destinatio= n > Group.=94 > > > > Your point about the spec failing to explicitly state how to uniquely > identify a TNType object that does not reside in a Destination Group, is = a > valid one. We can add a sentence that speaks to that. But your assumpti= on > about how to do it is accurate, use the combination of the TN string and = the > rantID. > > > > Ken > > > ------------------------------ > > *From:* drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] *On > Behalf Of *Mickael MARRACHE > *Sent:* Thursday, May 05, 2011 2:18 PM > *To:* drinks@ietf.org > *Subject:* [drinks] Questions SPPP > > > > Hey, > > It is specified: "A telephone number is provisioned using the TNType, an > extension of > PubIDType. Each TNType object is uniquely identifi= ed > by the > combination of its tn element, and the unique key = of > its parent > Destination Group (dgName and rantId)."(page 29) > > How a telephone number (TNType) is identified in the case it is directly > associated to route records? I guess with registrant ID and tn? If yes, f= or > a given registrant, there can't be two telephone number associated with t= wo > different sets of route records? Is that a problem? > > ------------------------------ > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network > Services. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f > you > are not the intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message. > > --000e0cd51aee11353004a28bfe04 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
My question was about the second point, "how to uniquely identify a TNType object that does = not reside in a Destination Group". If my assumption is valid, what about the question "If yes, for a given registrant, there can't = be two telephone number associated with two different sets of route records= ? Is that a problem?"


On Thu, May 5, 2011 at 9:53 PM, Cartwright, Ken <kcartwright@tnsi.com> w= rote:

Hi Mickael,

=A0

Having two TNTypes that reside within different DestGroups and = that contain the same telephone number does not create a problem, in fact the protocol was designed, in part, to suppo= rt that requirement.=A0 The spec statement =93In other words, a given telephone number string may exist within one or more = Destination Groups, but must not exist more than once within a Destination = Group.<= span style=3D"font-size:10.0pt;font-family:"Courier New";color:bl= ack">=94

=A0<= /p>

Your point about t= he spec failing to explicitly state how to uniquely identify a TNType objec= t that does not reside in a Destination Group, is a valid one.=A0 We can add a sentence that speaks to that.=A0 Bu= t your assumption about how to do it is accurate, use the combination of th= e TN string and the rantID.

=A0<= /p>

Ken<= /p>

=A0<= /p>

From: dr= inks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael MARRACH= E
Sent: Thursday, May 05, 2011= 2:18 PM
To: drinks@ietf.org
Subject: [drinks] Questions = SPPP

=A0

Hey,

It is specified: "A telephone number is provisioned using the TNType, = an extension of
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PubIDTyp= e. Each TNType object is uniquely identified by the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 combinat= ion of its tn element, and the unique key of its parent
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Destinat= ion Group (dgName and rantId)."(page 29)

How a telephone number (TNType) is identified in the case it is directly as= sociated to route records? I guess with registrant ID and tn? If yes, for a= given registrant, there can't be two telephone number associated with = two different sets of route records? Is that a problem?


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

--000e0cd51aee11353004a28bfe04-- From mickaelmarrache@gmail.com Thu May 5 12:25:20 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826A0E096D for ; Thu, 5 May 2011 12:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLAQNmZC0dTc for ; Thu, 5 May 2011 12:25:19 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 645A0E0967 for ; Thu, 5 May 2011 12:25:18 -0700 (PDT) Received: by wwa36 with SMTP id 36so1893284wwa.13 for ; Thu, 05 May 2011 12:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=XcgdgNBN3n8E8K/T8m3hAd6VPLn2vChsV1K+ozuT30Q=; b=axVwrg2XP+njDWr516PwvgtFQ8qp3S2eODuV7gnC+DikraD6funj1nLM3BH/04i+ew p8tcF6/UVzz3cYdNY3OLUgyFcZOj9zfvO5pUJaMQOWLmxyHmA7sY8wcKHMEQUXJlVzT8 Kr/O8Ra/TvWpzjN8X26BKR2QXWzgHrn9kqwSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=F5ZChrCzJMSqUMn+QaPteShoo6QZrm/2dkxrwP5FhFFdqN4kQKy2wtsgJSYqqc+RNi Zdn9yU27N5mX8FX4dlbDVBTpIn7IRAK42WjdDtj1NGwGRlIfcsd4wTcL28X58pCwWbWx nDXv4riDFhN0knkcxKh0uYP0/UPDlaIe+PGP0= MIME-Version: 1.0 Received: by 10.216.255.206 with SMTP id j56mr2500768wes.39.1304623518116; Thu, 05 May 2011 12:25:18 -0700 (PDT) Received: by 10.216.29.203 with HTTP; Thu, 5 May 2011 12:25:18 -0700 (PDT) Date: Thu, 5 May 2011 22:25:18 +0300 Message-ID: From: Mickael MARRACHE To: drinks@ietf.org Content-Type: multipart/alternative; boundary=20cf301e31c35cecd204a28c55a8 Subject: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 19:25:20 -0000 --20cf301e31c35cecd204a28c55a8 Content-Type: text/plain; charset=ISO-8859-1 Hey, 1) Can a telephone number be associated directly to route records and associated to a destination group too? If no, I think it's better to precise it. 2) Which attributes a client can change using an update request on a telephone number object? Can he change the rant, the dgName and the telephone number (primary key attributes)? If there are some attributes that can't be changed, I think it's better to precise it too. Thanks --20cf301e31c35cecd204a28c55a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey,

1) Can a telephone number be associated direct= ly to route records and associated to a destination group too? If no, I thi= nk it's better to precise it.

2) Which attributes a client can c= hange using an update request on a telephone number object? Can he change t= he rant, the dgName and the telephone number (primary key attributes)? If t= here are some attributes that can't be changed, I think it's better= to precise it too.

Thanks
--20cf301e31c35cecd204a28c55a8-- From kcartwright@tnsi.com Thu May 5 12:57:08 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D256E08EC for ; Thu, 5 May 2011 12:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiC3-QuWvpWu for ; Thu, 5 May 2011 12:57:06 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02705E09E1 for ; Thu, 5 May 2011 12:56:59 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.53968595; Thu, 05 May 2011 15:56:54 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 5 May 2011 15:56:54 -0400 From: "Cartwright, Ken" To: Mickael MARRACHE , "drinks@ietf.org" Date: Thu, 5 May 2011 15:56:53 -0400 Thread-Topic: [drinks] Questions SPPP Thread-Index: AcwLVsV8hIG7cgViRHqF2dGPymCtQwAAGqNg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA31133EE4C7@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA31133EE432@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA31133EE4C7TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 19:57:08 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA31133EE4C7TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, I'd not quite state it that way. A given telephone number _can_ be a= ssociated with two separate sets of Route Records by having two TNType obje= cts and those two objects are in different Dest Groups. But of course for = a TNType that does not reside in a destination group, there is no way to as= sociate it with two different sets of Route Records. The protocol does not= support that feature. Ken ________________________________ From: Mickael MARRACHE [mailto:mickaelmarrache@gmail.com] Sent: Thursday, May 05, 2011 3:01 PM To: Cartwright, Ken; drinks@ietf.org Subject: Re: [drinks] Questions SPPP My question was about the second point, "how to uniquely identify a TNType = object that does not reside in a Destination Group". If my assumption is va= lid, what about the question "If yes, for a given registrant, there can't b= e two telephone number associated with two different sets of route records?= Is that a problem?" On Thu, May 5, 2011 at 9:53 PM, Cartwright, Ken > wrote: Hi Mickael, Having two TNTypes that reside within different DestGroups and that contain= the same telephone number does not create a problem, in fact the protocol = was designed, in part, to support that requirement. The spec statement "In= other words, a given telephone number string may exist within one or more = Destination Groups, but must not exist more than once within a Destination = Group." Your point about the spec failing to explicitly state how to uniquely ident= ify a TNType object that does not reside in a Destination Group, is a valid= one. We can add a sentence that speaks to that. But your assumption abou= t how to do it is accurate, use the combination of the TN string and the ra= ntID. Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drink= s-bounces@ietf.org] On Behalf Of Mickael MA= RRACHE Sent: Thursday, May 05, 2011 2:18 PM To: drinks@ietf.org Subject: [drinks] Questions SPPP Hey, It is specified: "A telephone number is provisioned using the TNType, an ex= tension of PubIDType. Each TNType object is uniquely identified= by the combination of its tn element, and the unique key of= its parent Destination Group (dgName and rantId)."(page 29) How a telephone number (TNType) is identified in the case it is directly as= sociated to route records? I guess with registrant ID and tn? If yes, for a= given registrant, there can't be two telephone number associated with two = different sets of route records? Is that a problem? ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA31133EE4C7TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, I’d not quite state it tha= t way.  A given telephone number _can_ be associated with two separate sets of Route Records by having two TNType objects and those = two objects are in different Dest Groups.  But of course for a TNType = that does not reside in a destination group, there is no way to associate i= t with two different sets of Route Records.  The protocol does not support that feature.

 

Ken

 

From: Mick= ael MARRACHE [mailto:mickaelmarrache@gmail.com]
Sent: Thursday, May 05, 2011= 3:01 PM
To: Cartwright, Ken; drinks@ietf.org
Subject: Re: [drinks] Questi= ons SPPP

 

My questi= on was about the second point, "how to uniquely identify a TNType object that does not reside in a Destination= Group". If my assumption is valid, what about the question "If yes, for a given registrant, there can't be two telephone number associated with two different sets of = route records? Is that a problem?"

On Thu, May 5, 2011 at 9:53 PM, Cartwright, Ken <kcartwright@tnsi.com> wrote:

Hi Mickael,

 

Having two TNTypes that reside within = different DestGroups and that contain the same telephone number does not cr= eate a problem, in fact the protocol was designed, in part, to support that requirement.  The spec statement &= #8220;<= span style=3D"font-size:10.0pt;font-family:"Courier New"; color:black;background:white">In other words, a given telephone number string may exist within one or more Destination Groups, but must not exist= more than once within a Destination Group.”

 

Your point about the spec failing to explicitly state how to un= iquely identify a TNType object that does not reside in a Destination Group, is a valid on= e.  We can add a sentence that speaks to that.  But your assumpti= on about how to do it is accurate, use the combination of the TN string and= the rantID.

 

Ken

 

From: drinks-bounces= @ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael MARRACH= E
Sent: Thursday, May 05, 2011= 2:18 PM
To: drinks@ietf.org
Subject: [drinks] Questions = SPPP

 

Hey,

It is specified: "A telephone number is provisioned using the TNType, = an extension of
            &nb= sp;          PubIDType. Each T= NType object is uniquely identified by the
            &nb= sp;          combination of it= s tn element, and the unique key of its parent
            &nb= sp;          Destination Group= (dgName and rantId)."(page 29)

How a telephone number (TNType) is identified in the case it is directly as= sociated to route records? I guess with registrant ID and tn? If yes, for a= given registrant, there can't be two telephone number associated with two = different sets of route records? Is that a problem?

 

This e-mail message is for the sole use of the intended recipie= nt(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA31133EE4C7TNSMAILNAwin2_-- From kcartwright@tnsi.com Thu May 5 13:08:17 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F96E06A4 for ; Thu, 5 May 2011 13:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsNMk3l6ywiO for ; Thu, 5 May 2011 13:08:16 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8D0E0705 for ; Thu, 5 May 2011 13:08:16 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.53968971; Thu, 05 May 2011 16:08:10 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 5 May 2011 16:08:09 -0400 From: "Cartwright, Ken" To: Mickael MARRACHE , "drinks@ietf.org" Date: Thu, 5 May 2011 16:08:08 -0400 Thread-Topic: [drinks] Questions SPPP Thread-Index: AcwLWnnwL3iUb8KBSo+0LXj4jV1vyAABJfBA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA31133EE4D8@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA31133EE4D8TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 20:08:17 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA31133EE4D8TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, 1) The protocol allows it. 2) Changing an object's _identity_ (i.e. the attributes of an object = that uniquely identify it) does not really make sense within the context of= SPPP. So the protocol does not have the data structres to support that. = So for each object type it is not possible to use SPPP to change the proper= ties of an object that _identify_ it. For example there is no protocol con= struct that enables changing the "tn" attribute of a TNType, because the "t= n" attribute is used (along with the dgName and rantId) to identify the spe= cific TNType object instance. So no need to state that fact. Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Mickael MARRACHE Sent: Thursday, May 05, 2011 3:25 PM To: drinks@ietf.org Subject: [drinks] Questions SPPP Hey, 1) Can a telephone number be associated directly to route records and assoc= iated to a destination group too? If no, I think it's better to precise it. 2) Which attributes a client can change using an update request on a teleph= one number object? Can he change the rant, the dgName and the telephone num= ber (primary key attributes)? If there are some attributes that can't be ch= anged, I think it's better to precise it too. Thanks ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA31133EE4D8TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

1) &= nbsp;     The protocol allows it.

2) &= nbsp;     Changing an object’s _identity_ (i.e. the attributes of an object that uniquely identify it) does not really make sense within the context o= f SPPP.  So the protocol does not have the data structres to support t= hat.  So for each object type it is not possible to use SPPP to change= the properties of an object that _identify_ it.  For example there is no protocol construct that enables changing= the “tn” attribute of a TNType, because the “tn” a= ttribute is used (along with the dgName and rantId) to identify the specifi= c TNType object instance.  So no need to state that fact.

 

Ken

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael MARRACH= E
Sent: Thursday, May 05, 2011= 3:25 PM
To: drinks@ietf.org
Subject: [drinks] Questions = SPPP

 

Hey,

1) Can a telephone number be associated directly to route records and assoc= iated to a destination group too? If no, I think it's better to precise it.=

2) Which attributes a client can change using an update request on a teleph= one number object? Can he change the rant, the dgName and the telephone num= ber (primary key attributes)? If there are some attributes that can't be ch= anged, I think it's better to precise it too.

Thanks


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA31133EE4D8TNSMAILNAwin2_-- From mickaelmarrache@gmail.com Thu May 5 13:43:25 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9322E08D8 for ; Thu, 5 May 2011 13:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uwkrg2rR0R+y for ; Thu, 5 May 2011 13:43:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1A0E0778 for ; Thu, 5 May 2011 13:43:24 -0700 (PDT) Received: by wwa36 with SMTP id 36so1942465wwa.13 for ; Thu, 05 May 2011 13:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=xOCM1TbNcpHyqKaDcSysNE3sclFAEvqBrXYROzJRx3c=; b=vpsSzvsaQ1+OSbkwcr0l5Y+Rh+6M6h60K1rUkm8aYKRAMw3wIfngkhM624F4fBiZtm 47cqXNIT+ppsxcDm8JtYZ1phtVyoTORiEIVcAGoIiRWMRBYIJCGRXsWPREqAmEhkk3VQ GU6nesAiETOgImdgV46epsPN7qX1QeD65cz1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wmDKNlFuC8UN4bpO4mi7oRMyqIVQ/W5LoYLbGWI/ICc5c4d8p5UD9LbGXh2gtWcyHt ksumg5XYGYJHMKnp+MyfXQ28iz+xewjtqNDFr+xGEM7mZT+AAKxH/MqgmcKPtQR6qFmE pwL9UvSrZ0Ntp6etNWfcHMQwDvbfluabYe0wA= MIME-Version: 1.0 Received: by 10.216.81.203 with SMTP id m53mr7456319wee.9.1304628204057; Thu, 05 May 2011 13:43:24 -0700 (PDT) Received: by 10.216.29.203 with HTTP; Thu, 5 May 2011 13:43:23 -0700 (PDT) Date: Thu, 5 May 2011 23:43:23 +0300 Message-ID: From: Mickael MARRACHE To: drinks@ietf.org, "Cartwright, Ken" Content-Type: multipart/alternative; boundary=0016e6dd97e1aab43004a28d6c3b Subject: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 20:43:25 -0000 --0016e6dd97e1aab43004a28d6c3b Content-Type: text/plain; charset=ISO-8859-1 I understood for the previous questions. I have another question: When a SPPP client adds a public identifier to the registry, he can optionally claim to be a carrier-of-record by setting the element of to true. If he doesn't want to claim, he should not put in the request the element. So, when the element of takes the value false? --0016e6dd97e1aab43004a28d6c3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I understood for the previous questions.

I have ano= ther question: When a SPPP client adds a public identifier to the registry,= he can optionally claim to be a carrier-of-record by setting the <corCl= aim> element of <corInfo> to true. If he doesn't want to claim= , he should not put in the request the <corInfo> element. So, when th= e <corClaim> element of <corInfo> takes the value false?


--0016e6dd97e1aab43004a28d6c3b-- From kcartwright@tnsi.com Thu May 5 14:41:11 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A65DE074D for ; Thu, 5 May 2011 14:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X4bhl7x7NKx for ; Thu, 5 May 2011 14:41:10 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83F04E0593 for ; Thu, 5 May 2011 14:41:09 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.53971458; Thu, 05 May 2011 17:41:06 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 5 May 2011 17:41:06 -0400 From: "Cartwright, Ken" To: Mickael MARRACHE , "drinks@ietf.org" Date: Thu, 5 May 2011 17:41:04 -0400 Thread-Topic: Questions SPPP Thread-Index: AcwLZRZt2siBS4wxTG6gG5w+IOKbjAABxxrQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA31134A13F2@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA31134A13F2TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 21:41:11 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA31134A13F2TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When the client no longer wants to make a corClaim for that public identifi= er (i.e. for a modification). Ken ________________________________ From: Mickael MARRACHE [mailto:mickaelmarrache@gmail.com] Sent: Thursday, May 05, 2011 4:43 PM To: drinks@ietf.org; Cartwright, Ken Subject: Questions SPPP I understood for the previous questions. I have another question: When a SPPP client adds a public identifier to the= registry, he can optionally claim to be a carrier-of-record by setting the= element of to true. If he doesn't want to claim, he s= hould not put in the request the element. So, when the = element of takes the value false? ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA31134A13F2TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When the client no longer wants to mak= e a corClaim for that public identifier (i.e. for a modification).

 

Ken

 

From: Mick= ael MARRACHE [mailto:mickaelmarrache@gmail.com]
Sent: Thursday, May 05, 2011= 4:43 PM
To: drinks@ietf.org; Cartwright, Ken
Subject: Questions SPPP

 

I understood for the = previous questions.

I have another question: When a SPPP client adds a public identifier to the= registry, he can optionally claim to be a carrier-of-record by setting the= <corClaim> element of <corInfo> to true. If he doesn't want to= claim, he should not put in the request the <corInfo> element. So, when the <corClaim> element of <corI= nfo> takes the value false?


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA31134A13F2TNSMAILNAwin2_-- From mickaelmarrache@gmail.com Fri May 6 05:57:04 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACCFE069E for ; Fri, 6 May 2011 05:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lomuhh4hEUI2 for ; Fri, 6 May 2011 05:57:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20EDEE0694 for ; Fri, 6 May 2011 05:57:02 -0700 (PDT) Received: by wyb29 with SMTP id 29so2746763wyb.31 for ; Fri, 06 May 2011 05:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=CX9BhlGXcepdQXGjEYjd6CQDtvQdAZfJMBPcZEDtYY4=; b=IW6W4jJNqFoN1LqxP8TCYJxFgSMTl7J3Vy1cuFnODfZ//3b2XVjdk95kRKC7IilS9C NuKKGO8HQG0vN7BK9yB5u6kqBUKJC7bqZGpwgiWFe/PKO6KSphOIMHaQfYczT2cGETeI zyr2NjPW2t6nPcZrxuikFNIAv8lfb9ZBEjDGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Bg48o1tPnrxwzPkRKZ32/bubmo/inqsozLpDc9FVYsJt60vYXVTXKoK0jDgMKpvt45 df+6PZPNw9ulypUyX8E8lFaYIZDrcC+o1cCWB2LFPY15LTS0ZQt4R+SlUYWnocIl6MEl jrRqUV0IUaN6fGL6H2D7mf7gjO39aCQhG/m28= MIME-Version: 1.0 Received: by 10.216.81.203 with SMTP id m53mr8352361wee.9.1304686621988; Fri, 06 May 2011 05:57:01 -0700 (PDT) Received: by 10.216.29.203 with HTTP; Fri, 6 May 2011 05:57:01 -0700 (PDT) Date: Fri, 6 May 2011 15:57:01 +0300 Message-ID: From: Mickael MARRACHE To: drinks@ietf.org, "Cartwright, Ken" Content-Type: multipart/alternative; boundary=0016e6dd97e1a5965704a29b06a2 Subject: [drinks] Text precision SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 12:57:04 -0000 --0016e6dd97e1a5965704a29b06a2 Content-Type: text/plain; charset=ISO-8859-1 Hey, I propose to correct something in the text (page 29): ......A Public Identifier may provisioned as a member of a Destination Group > or > provisioned outside of a Destination Group. A Public Identifier that > is provisioned as a member of a Destionation Group is intended to be > associated with its SED through the Route Group(s) that are > associated with its containing Destination Group. A Public > Identifier that is not provisioned as a member of a Destionation > Group is intended to be associated with its SED through the Route > Records that are directly associated with the Public Identifier. > The text doesn't precise that only a telephone number may be associated directly to route records.(The rrRef list exists only for the TNType.) --0016e6dd97e1a5965704a29b06a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey,

I propose to correct something in the text (pa= ge 29):

..= ....A Public Identifier may provisioned as a member of a Destination Group = or
provisioned outside of a Destination Group. A Public Identifier that
is = provisioned as a member of a Destionation Group is intended to be
associ= ated with its SED through the Route Group(s) that are
associated with it= s containing Destination Group. A Public
Identifier that is not provisioned as a member of a Destionation
Group i= s intended to be associated with its SED through the Route
Records that = are directly associated with the Public Identifier.

The text doesn't precise that only a telephone number may be associ= ated directly to route records.(The rrRef list exists only for the TNType.)=

=A0
--0016e6dd97e1a5965704a29b06a2-- From mickaelmarrache@gmail.com Tue May 10 11:31:48 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCE6E0874 for ; Tue, 10 May 2011 11:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24a4fjiNoWKU for ; Tue, 10 May 2011 11:31:47 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83FE6E069C for ; Tue, 10 May 2011 11:31:47 -0700 (PDT) Received: by wwa36 with SMTP id 36so4957783wwa.13 for ; Tue, 10 May 2011 11:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=ivOYx+MACKybYsuYW+CkF1bW2MtSjPSUrJ5HtQCv7Ys=; b=X0JQXFCtSO+8RaFwyqjPBA32kIttdAgfgVeZwhV9cAO4wyRlTNY0y7DszDihsjcSs3 EkabrvZkaTP3tRETeAxsBOcAMsMtJX61/U+VZJC6ZE/vLFquhpBShWbuLSRcbGsDjQXw r5PutHY6SYUaOdwVB6HlcaFEHqev9DSTFWlgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AQeheZyXOMNv5PLi5wzcdhUJwU+OtzRiW1V0BMxBmKNQBhEnrn0nUp4CrPoSLNfF0X bervuYi3nFkAx96ZIXxkxAtKu8xnZten677+h8vrrc2YUcHudNmypiAyOwXFjHVXZ5dp RaQO6F7hha70Y2i6huwqlo6R16Db+fRWuVres= MIME-Version: 1.0 Received: by 10.216.65.203 with SMTP id f53mr4665775wed.54.1305050659606; Tue, 10 May 2011 11:04:19 -0700 (PDT) Received: by 10.216.29.203 with HTTP; Tue, 10 May 2011 11:04:19 -0700 (PDT) Date: Tue, 10 May 2011 21:04:19 +0300 Message-ID: From: Mickael MARRACHE To: drinks@ietf.org, "Cartwright, Ken" Content-Type: multipart/alternative; boundary=000e0ce0b4eafad09804a2efc85c Subject: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 18:31:48 -0000 --000e0ce0b4eafad09804a2efc85c Content-Type: text/plain; charset=ISO-8859-1 Hey, When a client wants to add a telephone number (for example) to the registry, and that he doesn't want to be the carrier of record, he doesn't send the corInfo element. Why not to set the corInfo element as mandatory? And when a client wants to add this telephone number, he sends the corInfo element with the corClaim element set to false. Thanks --000e0ce0b4eafad09804a2efc85c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey,

When a client wants to add a telephone number = (for example) to the registry, and that he doesn't want to be the carri= er of record, he doesn't send the corInfo element. Why not to set the c= orInfo element as mandatory? And when a client wants to add this telephone = number, he sends the corInfo element with the corClaim element set to false= .

Thanks
--000e0ce0b4eafad09804a2efc85c-- From mickaelmarrache@gmail.com Tue May 10 13:24:18 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BF2E06E7 for ; Tue, 10 May 2011 13:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rinYFsmCk20l for ; Tue, 10 May 2011 13:24:13 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42233E06C3 for ; Tue, 10 May 2011 13:24:12 -0700 (PDT) Received: by wwa36 with SMTP id 36so5032246wwa.13 for ; Tue, 10 May 2011 13:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=+n8nJnwoSWlwpobBPvBtkUQ9NMNU1m+/09nwqblquYI=; b=HvDIAsOxy5Yimh3ydcVhteNdoJ546faOnDOYft9De6HNWbQdLWCjfW2C8bahHqgnCi uAY/rz+VIN6mIWOuciE3ET9CCiD5K+b9WtQGg0o5GJR+dYVALZHc8eoc1yhVj+jCnZZp aK6kpnG6XYaYDeGmXBj/rxPMhrlH2aiNqNF18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tBFCtFgNPNbb0u/6OLkGhw9Nh02LssGXiAKtwqt3pcfS2NZDp73ZAi8sMegtflBB7/ 0GJVY6diRm3z8yC7aYJhBXwvOtRW3ODAnCIumyGqt5LSajsNQJHoTLgDYC+l3RV23V7o yWwi+L0pNHOv6wSMH+RcqHHP+LRmz1ZjYerPw= MIME-Version: 1.0 Received: by 10.216.255.206 with SMTP id j56mr289921wes.39.1305059051716; Tue, 10 May 2011 13:24:11 -0700 (PDT) Received: by 10.216.29.203 with HTTP; Tue, 10 May 2011 13:24:11 -0700 (PDT) Date: Tue, 10 May 2011 23:24:11 +0300 Message-ID: From: Mickael MARRACHE To: drinks@ietf.org Content-Type: multipart/alternative; boundary=20cf301e31c330406604a2f1bd8b Subject: [drinks] Correction SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 20:24:18 -0000 --20cf301e31c330406604a2f1bd8b Content-Type: text/plain; charset=ISO-8859-1 Hey, The element "flags" of NAPTRType is not explained with the others in page 42. --20cf301e31c330406604a2f1bd8b Content-Type: text/html; charset=ISO-8859-1
Hey,

The element "flags" of NAPTRType is not explained with the others in page 42.
--20cf301e31c330406604a2f1bd8b-- From kcartwright@tnsi.com Tue May 10 14:07:54 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99CBE0790 for ; Tue, 10 May 2011 14:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNuhzlShPxdo for ; Tue, 10 May 2011 14:07:54 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18FF7E06DB for ; Tue, 10 May 2011 14:07:53 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.54106224; Tue, 10 May 2011 17:07:49 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 10 May 2011 17:07:48 -0400 From: "Cartwright, Ken" To: Mickael MARRACHE , "drinks@ietf.org" Date: Tue, 10 May 2011 17:07:48 -0400 Thread-Topic: Questions SPPP Thread-Index: AcwPPLLc6h8dWy65SCGP3dRS/NjSOgAGV2NA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA3113587B08@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA3113587B08TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Questions SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 21:07:54 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA3113587B08TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Mickael, That would just be extra data that is not necessary. Ken ________________________________ From: Mickael MARRACHE [mailto:mickaelmarrache@gmail.com] Sent: Tuesday, May 10, 2011 2:04 PM To: drinks@ietf.org; Cartwright, Ken Subject: Questions SPPP Hey, When a client wants to add a telephone number (for example) to the registry= , and that he doesn't want to be the carrier of record, he doesn't send the= corInfo element. Why not to set the corInfo element as mandatory? And when= a client wants to add this telephone number, he sends the corInfo element = with the corClaim element set to false. Thanks ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA3113587B08TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Mickael,

 

   That would just be extra = data that is not necessary.

 

Ken

 

From: Mick= ael MARRACHE [mailto:mickaelmarrache@gmail.com]
Sent: Tuesday, May 10, 2011 = 2:04 PM
To: drinks@ietf.org; Cartwright, Ken
Subject: Questions SPPP

 

Hey,

When a client wants to add a telephone number (for example) to the registry= , and that he doesn't want to be the carrier of record, he doesn't send the= corInfo element. Why not to set the corInfo element as mandatory? And when= a client wants to add this telephone number, he sends the corInfo element with the corClaim element set to fals= e.

Thanks


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA3113587B08TNSMAILNAwin2_-- From kcartwright@tnsi.com Tue May 10 14:09:04 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08048E07F4 for ; Tue, 10 May 2011 14:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OeyOHwNiIqc for ; Tue, 10 May 2011 14:09:03 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFBE3E06DB for ; Tue, 10 May 2011 14:09:02 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.54106271; Tue, 10 May 2011 17:08:56 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 10 May 2011 17:08:55 -0400 From: "Cartwright, Ken" To: Mickael MARRACHE , "drinks@ietf.org" Date: Tue, 10 May 2011 17:08:55 -0400 Thread-Topic: [drinks] Correction SPPP Thread-Index: AcwPUEJ19qPKsaaCQLi1SzI21CqNjgABh+vQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA3113587B0E@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA3113587B0ETNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Correction SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 21:09:04 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA3113587B0ETNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, We can add that explanation in. It is the field for NAPTR flags. Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Mickael MARRACHE Sent: Tuesday, May 10, 2011 4:24 PM To: drinks@ietf.org Subject: [drinks] Correction SPPP Hey, The element "flags" of NAPTRType is not explained with the others in page 4= 2. ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA3113587B0ETNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok,

 

We can add that explanation in.  = It is the field for NAPTR flags.

 

Ken

 

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael MARRACH= E
Sent: Tuesday, May 10, 2011 = 4:24 PM
To: drinks@ietf.org
Subject: [drinks] Correction= SPPP

 

Hey,

The element "flags" of NAPTRType is not explained with the others= in page 42.


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA3113587B0ETNSMAILNAwin2_-- From mickaelmarrache@gmail.com Mon May 16 05:29:03 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39B1E06BD for ; Mon, 16 May 2011 05:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaG4CjVrU4Wk for ; Mon, 16 May 2011 05:29:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21A73E06B8 for ; Mon, 16 May 2011 05:29:02 -0700 (PDT) Received: by wyb29 with SMTP id 29so3975219wyb.31 for ; Mon, 16 May 2011 05:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=72R97IzuH7Jk370e/QQK5iyQO+igD8mSTXknIgU8Wqc=; b=PvQPOubhb2/4cTRsxDKpiAFbRjolZBl+B4U+Scno6ECpoZYGsqi9qkL6xGV6ACBcxg k+KQEA+70hUdZffQirhcuE9bazV3CokzlpgKu4aXyZoQlV4U5pkB4saIuDaW3ZOZ8wyD eXFaN7NczalSuSU7X2JxBJTWf8pIvC5OQhaa4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jy5fQpdrll7JyPe74EHd68qwbXW8lZGOODKJSFSlsRY+FISCQGTS7DUuTvaYnq6DXU DG+1tnHLsOFv/isTGw38gbg7BiO6jehIsZxAkJlw2c7SgKLMUIc9XCnayT9bDtdtvTJy 3/cldjriTVumyLZuMgUlLnOtB4+ACVN5TeSnQ= MIME-Version: 1.0 Received: by 10.216.255.206 with SMTP id j56mr694831wes.39.1305548942229; Mon, 16 May 2011 05:29:02 -0700 (PDT) Received: by 10.216.24.136 with HTTP; Mon, 16 May 2011 05:29:02 -0700 (PDT) Date: Mon, 16 May 2011 15:29:02 +0300 Message-ID: From: Mickael MARRACHE To: drinks@ietf.org, "Cartwright, Ken" Content-Type: multipart/alternative; boundary=20cf301e31c3f03eef04a363ccb7 Subject: [drinks] Question SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 12:29:03 -0000 --20cf301e31c3f03eef04a363ccb7 Content-Type: text/plain; charset=ISO-8859-1 Hey, I have a question: the reject route group offer request gives the possibility to reject a route group offer and deletes it from the registry. What is the purpose of the DelRteGrpOfferRqstType (page 89)? Thanks --20cf301e31c3f03eef04a363ccb7 Content-Type: text/html; charset=ISO-8859-1
Hey,

I have a question: the reject route group offer request gives the possibility to reject a route group offer and deletes it from the registry. What is the purpose of the DelRteGrpOfferRqstType (page 89)?

Thanks
--20cf301e31c3f03eef04a363ccb7-- From mickaelmarrache@gmail.com Mon May 16 06:00:32 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9D2E067B for ; Mon, 16 May 2011 06:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X74VePJaiXip for ; Mon, 16 May 2011 06:00:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0077E0669 for ; Mon, 16 May 2011 06:00:31 -0700 (PDT) Received: by wwa36 with SMTP id 36so3455831wwa.13 for ; Mon, 16 May 2011 06:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=sUivdlCfuI6Ii8Du4FjiyrS6xJEtmAwLnDbF+VK4exs=; b=SDl1WONugSevxXlJl3yxR6AVFOg/bVI6jOqYqxXtr8ZJJ9vhaUItmtOuJBuQ1/tx1a irS+tPhRx4eUXnHVcQWqTy5Va0zD3hh2Lgqw47bNqLeCKrgMPiHfgv22icSNgKa9NGfp 0efFNhVg3yBY12la9nj2OWg1U9dYXbo0dKk7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LsmXHSQ3o4fjvhzDNgGXbccFX5v/xlfbNl6PULlTYUDkZ+8DFSq51CtqgTDYqkDqvK sK3MqWu2HewEmSYVHZj2pZL5sBgHwsvn6ScvW7su+zJB/BPKaY6HnF/4P+40QNtT21UE xjEvnDo7YK7+JyEzc+OE4L/YREM7sgmvVa+yc= MIME-Version: 1.0 Received: by 10.216.65.203 with SMTP id f53mr2459184wed.54.1305550831040; Mon, 16 May 2011 06:00:31 -0700 (PDT) Received: by 10.216.24.136 with HTTP; Mon, 16 May 2011 06:00:31 -0700 (PDT) Date: Mon, 16 May 2011 16:00:31 +0300 Message-ID: From: Mickael MARRACHE To: drinks@ietf.org Content-Type: multipart/alternative; boundary=000e0ce0b4ea853ad804a3643d4a Subject: [drinks] Suggestion SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 13:00:32 -0000 --000e0ce0b4ea853ad804a3643d4a Content-Type: text/plain; charset=ISO-8859-1 The draft says: Route Records: When a route record is deleted any references between that route record and any route group must be removed by the SPPP implementation as part of fulfilling the deletion request. But there may be a link between route records and telephone numbers too. So, when a route record is deleted, if there is a telephone number which references directly this route record, the reference has to be deleted. But there is a problem. If this telephone number is not associated to a destination group and this references only this route record, we get a telephone number which is not associated to a destination group and not associated to route records, so it must be deleted too? P.S: I didn't receive a response for the question : Is a telephone number the only public identifier which can be associated directly to route records? --000e0ce0b4ea853ad804a3643d4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The draft says:

Route Records: When a route record = is deleted any references
between that route record and any route group = must be removed by
the SPPP implementation as part of fulfilling the del= etion
request.

But there may be a link between route records and telephone= numbers too. So, when a route record is deleted, if there is a telephone n= umber which references directly this route record, the reference has to be = deleted. But there is a problem.
If this telephone number is not associated to a destination group and this = references only this route record, we get a telephone number which is not a= ssociated to a destination group and not associated to route records, so it= must be deleted too?

P.S: I didn't receive a response for the question : Is a telephone = number the only public identifier which can be associated directly to route= records?
--000e0ce0b4ea853ad804a3643d4a-- From kcartwright@tnsi.com Mon May 16 06:56:07 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AE8E06E0 for ; Mon, 16 May 2011 06:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQsLtW7PQpoZ for ; Mon, 16 May 2011 06:56:06 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37AD1E067E for ; Mon, 16 May 2011 06:56:05 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.54253358; Mon, 16 May 2011 09:55:57 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 16 May 2011 09:55:57 -0400 From: "Cartwright, Ken" To: Mickael MARRACHE , "drinks@ietf.org" Date: Mon, 16 May 2011 09:55:57 -0400 Thread-Topic: Question SPPP Thread-Index: AcwTxNwRx8ZM2DufRpqhFewWE58BmwAC96+g Message-ID: <754963199212404AB8E9CFCA6C3D0CDA3113650E0A@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA3113650E0ATNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Question SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 13:56:07 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA3113650E0ATNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mickael, Yes, good question. You and David have asked related questions. Please re= fer to Syed's examples for the answer to your question. Grep on "SSP2 no = longer wants to share route group RTE_GRP_SSP2_1 with SSP1." Ken ________________________________ From: Mickael MARRACHE [mailto:mickaelmarrache@gmail.com] Sent: Monday, May 16, 2011 8:29 AM To: drinks@ietf.org; Cartwright, Ken Subject: Question SPPP Hey, I have a question: the reject route group offer request gives the possibili= ty to reject a route group offer and deletes it from the registry. What is = the purpose of the DelRteGrpOfferRqstType (page 89)? Thanks ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA3113650E0ATNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mickael,

 

Yes, good question.  You and Davi= d have asked related questions.  Please refer to Syed’s examples= for the answer to your question.  Grep on  “SSP2 no longer wants to share route group RTE= _GRP_SSP2_1 with SSP1.”

 

Ken

 

From: Mick= ael MARRACHE [mailto:mickaelmarrache@gmail.com]
Sent: Monday, May 16, 2011 8= :29 AM
To: drinks@ietf.org; Cartwright, Ken
Subject: Question SPPP

 

Hey,

I have a question: the reject route group offer request gives the possibili= ty to reject a route group offer and deletes it from the registry. What is = the purpose of the DelRteGrpOfferRqstType (page 89)?

Thanks


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA3113650E0ATNSMAILNAwin2_-- From kcartwright@tnsi.com Mon May 16 07:00:38 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EB6E073C for ; Mon, 16 May 2011 07:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAo0+Ta1i3L0 for ; Mon, 16 May 2011 07:00:36 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFD62E0713 for ; Mon, 16 May 2011 07:00:35 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.54253515; Mon, 16 May 2011 10:00:31 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 16 May 2011 10:00:31 -0400 From: "Cartwright, Ken" To: Mickael MARRACHE , "drinks@ietf.org" Date: Mon, 16 May 2011 10:00:30 -0400 Thread-Topic: [drinks] Suggestion SPPP Thread-Index: AcwTyULAj46keOFnSXW/teqSzwADeAAB9lrQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA3113650E23@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA3113650E23TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Suggestion SPPP X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 14:00:38 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA3113650E23TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Michael, The TN should not be deleted in this case. And yes, you are correct, under= those circumstances, that TN will not have any Route Recs associated with = it. And there is no problem with this. And the answer to your second question is Yes. Ken ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Mickael MARRACHE Sent: Monday, May 16, 2011 9:01 AM To: drinks@ietf.org Subject: [drinks] Suggestion SPPP The draft says: Route Records: When a route record is deleted any references between that route record and any route group must be removed by the SPPP implementation as part of fulfilling the deletion request. But there may be a link between route records and telephone numbers too. So= , when a route record is deleted, if there is a telephone number which refe= rences directly this route record, the reference has to be deleted. But the= re is a problem. If this telephone number is not associated to a destination group and this = references only this route record, we get a telephone number which is not a= ssociated to a destination group and not associated to route records, so it= must be deleted too? P.S: I didn't receive a response for the question : Is a telephone number t= he only public identifier which can be associated directly to route records= ? ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA3113650E23TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

The TN should not be deleted in this c= ase.  And yes, you are correct, under those circumstances, that TN wil= l not have any Route Recs associated with it.  And there is no problem with this.

 

And the answer to your second question= is Yes.

 

Ken

 

From: drin= ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Mickael MARRACH= E
Sent: Monday, May 16, 2011 9= :01 AM
To: drinks@ietf.org
Subject: [drinks] Suggestion= SPPP

 

The draft says:

Route Records: When a route record is deleted any references
between that route record and any route group must be removed by
the SPPP implementation as part of fulfilling the deletion
request.

But there may be a link between route records and telephone numbers too. So= , when a route record is deleted, if there is a telephone number which refe= rences directly this route record, the reference has to be deleted. But the= re is a problem.
If this telephone number is not associated to a destination group and this = references only this route record, we get a telephone number which is not a= ssociated to a destination group and not associated to route records, so it= must be deleted too?

P.S: I didn't receive a response for the question : Is a telephone number t= he only public identifier which can be associated directly to route records= ?


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA3113650E23TNSMAILNAwin2_-- From kcartwright@tnsi.com Wed May 18 08:14:50 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BDAE074B for ; Wed, 18 May 2011 08:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-+tVtgOu1sX for ; Wed, 18 May 2011 08:14:49 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60AE06B8 for ; Wed, 18 May 2011 08:14:48 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.54322228; Wed, 18 May 2011 11:14:45 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 18 May 2011 11:14:45 -0400 From: "Cartwright, Ken" To: "drinks@ietf.org" Date: Wed, 18 May 2011 11:14:44 -0400 Thread-Topic: New Version Notification for draft-ietf-drinks-sppp-over-soap-03 Thread-Index: AcwJqwZybM6YtHakSQm4n4qJySex6wLwr5Cg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA31137192B7@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [drinks] FW: New Version Notification for draft-ietf-drinks-sppp-over-soap-03 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 15:14:50 -0000 Just to summarize the changes made to this rev of the document: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-drinks-= sppp-over-soap-03.txt 1) Corrected the example SOAP operation name in figure 1. 2) Corrected a typo in one occurrence of the protocol acronym "SPPP". 3) Removed the empty examples section. Ken -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, May 03, 2011 11:59 AM To: Cartwright, Ken Subject: New Version Notification for draft-ietf-drinks-sppp-over-soap-03 A new version of I-D, draft-ietf-drinks-sppp-over-soap-03.txt has been succ= essfully submitted by Kenneth Cartwright and posted to the IETF repository. Filename: draft-ietf-drinks-sppp-over-soap Revision: 03 Title: SPPP Over SOAP and HTTP Creation_date: 2011-05-03 WG ID: drinks Number_of_pages: 16 Abstract: The Session Peering Provisioning Protocol (SPPP) is an XML protocol that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport for SPPP is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPP XML structures over SOAP and HTTP(s). The IETF Secretariat. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From S.mans@coin.nl Thu May 19 05:17:55 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD8BE07B6 for ; Thu, 19 May 2011 05:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHOzHUXHq0BY for ; Thu, 19 May 2011 05:17:54 -0700 (PDT) Received: from remote.coin.nl (mail.coin.nl [87.215.202.170]) by ietfa.amsl.com (Postfix) with ESMTP id 23CEDE075B for ; Thu, 19 May 2011 05:17:50 -0700 (PDT) Received: from SBS.verenigingcoin.local ([fe80::5fe6:89a9:f6ea:913c]) by SBS.verenigingcoin.local ([fe80::5fe6:89a9:f6ea:913c%10]) with mapi; Thu, 19 May 2011 14:28:02 +0200 From: Stefphen Mans To: "drinks@ietf.org" Date: Thu, 19 May 2011 14:28:02 +0200 Thread-Topic: drinks Digest, Vol 35, Issue 9 Thread-Index: AcwVj1WsOATo64XRQ3SIUrPVhR4/BwAj3F6g Message-ID: <6CAFC144D48CDF41B4FD68716A87159EA07632D23F@SBS.verenigingcoin.local> References: In-Reply-To: Accept-Language: nl-NL Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] drinks Digest, Vol 35, Issue 9 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 12:17:55 -0000 Tiemen, Dank. Groet, Stefphen Mans =A0 Vereniging COIN Tielweg 3 2803 PK Gouda=A0 Mobile: 06-21843581 Tel:=A00182-690074 Fax:=A00182-690075 E-mail: s.mans@coin.nl Web: www.coin.nl -----Oorspronkelijk bericht----- Van: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] Namens drinks= -request@ietf.org Verzonden: woensdag 18 mei 2011 21:00 Aan: drinks@ietf.org Onderwerp: drinks Digest, Vol 35, Issue 9 If you have received this digest without all the individual message attachm= ents you will need to update your digest options in your list subscription.= To do so, go to=20 https://www.ietf.org/mailman/listinfo/drinks Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME o= r Plain Text Digests?" to MIME. You can set this option globally for all t= he list digests you receive at this point. Send drinks mailing list submissions to drinks@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/drinks or, via email, send a message with subject or body 'help' to drinks-request@ietf.org You can reach the person managing the list at drinks-owner@ietf.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of drinks digest..." Today's Topics: 1. FW: New Version Notification for draft-ietf-drinks-sppp-over-soap-03 (Cartwright, Ken) ---------------------------------------------------------------------- Message: 1 Date: Wed, 18 May 2011 11:14:44 -0400 From: "Cartwright, Ken" To: "drinks@ietf.org" Subject: [drinks] FW: New Version Notification for draft-ietf-drinks-sppp-over-soap-03 Message-ID: <754963199212404AB8E9CFCA6C3D0CDA31137192B7@TNS-MAIL-NA.win2k.corp.tnsi.co= m> =09 Content-Type: text/plain; charset=3D"us-ascii" Just to summarize the changes made to this rev of the document: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-drinks-= sppp-over-soap-03.txt 1) Corrected the example SOAP operation name in figure 1. 2) Corrected a typo in one occurrence of the protocol acronym "SPPP". 3) Removed the empty examples section. Ken -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, May 03, 2011 11:59 AM To: Cartwright, Ken Subject: New Version Notification for draft-ietf-drinks-sppp-over-soap-03 A new version of I-D, draft-ietf-drinks-sppp-over-soap-03.txt has been succ= essfully submitted by Kenneth Cartwright and posted to the IETF repository. Filename: draft-ietf-drinks-sppp-over-soap Revision: 03 Title: SPPP Over SOAP and HTTP Creation_date: 2011-05-03 WG ID: drinks Number_of_pages: 16 Abstract: The Session Peering Provisioning Protocol (SPPP) is an XML protocol that ex= ists to enable the provisioning of session establishment data into Session = Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and H= TTP(s) is a widely used, de-facto standard for messaging between elements o= f provisioning systems. Therefore the combination of SOAP and HTTP(s) as a= transport for SPPP is a natural fit. The obvious benefits include leverag= ing existing industry expertise, leveraging existing standards, and a highe= r probability that existing provisioning systems can be more easily integra= ted with this protocol. This document describes the specification for tran= sporting SPPP XML structures over SOAP and HTTP(s). The IETF Secretariat. This e-mail message is for the sole use of the intended recipient(s)and may= contain confidential and privileged information of Transaction Network Ser= vices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-ma= il and destroy all copies of the original message. ------------------------------ _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks End of drinks Digest, Vol 35, Issue 9 ************************************* From sumanth@cablelabs.com Thu May 19 12:58:13 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E35E0756 for ; Thu, 19 May 2011 12:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bqiOrx1d3b4 for ; Thu, 19 May 2011 12:58:13 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 48808E06BB for ; Thu, 19 May 2011 12:58:13 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p4JJwCkY028340 for ; Thu, 19 May 2011 13:58:12 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 19 May 2011 13:58:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 19 May 2011 13:58:12 -0600 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Thu, 19 May 2011 13:58:09 -0600 Thread-Topic: WGLC Announcement: draft-ietf-drinks-spprov-over-soap Thread-Index: AcwWXwZQ7oJfQTMhRbq1bSd6KXgmCA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D36AF473E@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7D36AF473Esrvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] WGLC Announcement: draft-ietf-drinks-spprov-over-soap X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 19:58:14 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7D36AF473Esrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG Participants, This email is to announce the Working Group Last Call(WGLC) for comments on= : http://tools.ietf.org/html/draft-ietf-drinks-sppp-over-soap-03 Title : SPPP Over SOAP = and HTTP Intended status of the document : Standards Track -- Please review the document, and send comments to this mailing list. The WGLC for this document will last for three weeks, so please send your c= omments before: 9 June, 2011, 23:59 UTC. For an overview about the draft's history, please see: http://tools.ietf.org/html/draft-ietf-drinks-sppp-over-soap-03 For the most recent changes, please see the slide deck from the authors (as= presented at Prague): http://www.ietf.org/proceedings/80/slides/drinks-1.pdf You may also want to see the associated notes: http://www.ietf.org/proceedings/80/minutes/drinks.txt ;and the changes to rev -03 at: http://www.ietf.org/mail-archive/web/drinks/current/msg00912.html Historical changes to this draft, and the reason for the changes, can be ob= tained from mailing list discussions at: http://www.ietf.org/mail-archive/web/drinks/current/maillist.html Regards, Sumanth [As WG chair] --_000_76AC5FEF83F1E64491446437EA81A61F7D36AF473Esrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WG Participants,

 

This email is to announce the Work= ing Group Last Call(WGLC) for comments on:

http://tools.ietf.org/html/draft-ietf-drinks-sppp-over-soap-03<= /span>

 

Title   &nbs= p;            &= nbsp;            &nb= sp;            =            : SPPP Ov= er SOAP and HTTP

Intended status of the document=      : Standards Track

 <= /p>

--

 

Please r= eview the document, and send comments to this mailing list.

 

The WGL= C for this document will last for three weeks, so please send your comments= before: 9 June, 2011, 23:59 UTC.

 

For an overview about the draft's = history, please see:

http://tools.ietf.org/html/draft-ietf-drinks-sppp-ove= r-soap-03

 

For the most recent= changes, please see the slide deck from the authors (as presented at Pragu= e):

http://www.ietf.org/proceedings/80/slides/drinks-1.pdf

<= span style=3D'font-size:12.0pt;color:blue'> 

You may also want to see = the associated notes:

http://www.ietf.org/proceedings/80/minutes/drinks.txt

 

;and the changes to rev -03 at:

http://www.ietf.org/mail-= archive/web/drinks/current/msg00912.html

 

Historical changes to this draft, and the reason for the = changes, can be obtained from mailing list discussions at:

http://www.ie= tf.org/mail-archive/web/drinks/current/maillist.html<= /p>

 <= /span>

Regards,

Su= manth [As WG chair]

 

 

= --_000_76AC5FEF83F1E64491446437EA81A61F7D36AF473Esrvxchg_-- From dean.willis@softarmor.com Wed May 25 12:27:53 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020031300AE for ; Wed, 25 May 2011 12:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RspWj0JEnwJh for ; Wed, 25 May 2011 12:27:52 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBFF7E0658 for ; Wed, 25 May 2011 12:27:51 -0700 (PDT) Received: by gwb20 with SMTP id 20so4068295gwb.31 for ; Wed, 25 May 2011 12:27:51 -0700 (PDT) Received: by 10.236.157.229 with SMTP id o65mr6784358yhk.276.1306351670903; Wed, 25 May 2011 12:27:50 -0700 (PDT) Received: from [192.168.2.124] (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id e48sm91670yhk.30.2011.05.25.12.27.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2011 12:27:49 -0700 (PDT) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: <648D3997-FA3A-4FED-9855-2B4668D8809E@softarmor.com> Date: Wed, 25 May 2011 14:27:40 -0500 To: drinks@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [drinks] Review of draft-ietf-drinks-spprov-07 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 19:27:53 -0000 As I seem to recall Sumanth asking me to do so, I've just done a read = through of draft-ietf-drinks-spprov-07. It's a pretty solid document with a couple of nits that may need fixing. = I'm also thinking that the security considerations and related = discussion around authentication and authorization issues are a bit = light and are likely to draw fire from the IESG. I'll discuss my points in the order I noted them while going through the = document, since I'm too lazy to actually organize by priority or in any = more meaningful way. 4.1/4.2 NIT: We have some inconsistent capitalization oddities relating = to words like "client", "server", "request" and "response", which are = sometimes capitalized and sometimes aren't. There may be some sort of = not-obvious--to-me rule in play about where they are being used as = proper nouns vs. ordinary nouns, but it was a bit distracting and is = likely to get changed by the RFC editor anyhow. I suggest quoting the = word in its definition, then just using lower case everywhere else: For = example, a "special term" may be defined in the text, but once it has = been so defined, it's a just a special term. 4.4 Discusses authentication, which section 3.1 says is mostly out of = scope for this document. However, there are some subtleties that it = seems like the core spprov document needs to think about. Is there a = requirement for selective authorization? Given that SPPP intro and 3.2 = seems to describe a registry as being provisioned by multiple SSPs, this = could be important. Do we need the request to model to 1) carry a = subset specifier, or 2) provision selective access capabilities? Do we = need the response model to discuss authorization failures in a useful = way, for example saying "This part of your request failed, but that part = would have succeeded?" Indeed, spprov 4.4 talks about "authentication = of the Client by the Server is expected to be used to identify and = further authorize the Client to certain resources on the Server." Does = the protocol have a need to allow a client to specify which other = clients can change the data it submitted? What is the relationship, if any, of the of orgId data element to = authentication and authorization? 4.5 Confidentiality and Integrity. Requirement for confidentiality and = integrity protection is good, but "by providing encryption capabilities" = is an unsatisfying follow-on, either insufficient to assure the = requirements, or restrictive of techniques that might alternately assure = confidentiality and integrity protection. Easiest fix is to truncate the = sentence short of the quoted text. EKR has many times told me that = encryption is not a magic hammer and that, in a requirements sentence, = it's better to declare that which must be protected than to claim = everything is fixed by encryption. Related to both 4.4 and 4.5 as well as section 9 "Security = Consideration", we really haven't done our homework with respect to RFC = 3552 yet. We need a more detailed deployment and threat model. For = example, what are the possible consequences of a fraudulent route = insertion? Conflicting route submissions by different parties? Route = disclosures? For how long do we think that a given message will require = confidentiality (as this influences requirements on key size and = algorithm)? 4.8/4.9 deal with request/response correlation and acknowledgement. The = use cases discussed a commit/rollback requirement wherein related = sub-requests can be expected to either fail or succeed as a group. Do we = adequately address reporting of the failed sub-request? Do we need to? =20 4.10 Mandatory Transport says "As of this writing of this revision, one = transport protocol proposal has been provided in = [I-D.ietf-drinks-sppp-over-soap]. This section will define a mandatory = transport protocol to be compliant with this RFC." However, at this time, this section does not go on to define a mandatory = transport protocol. So there's something wrong with section 4.10.=20 Sections 5-7 discuss protocol data structures that appear to be defined = in a formal language (XMLSchema), but I haven't noticed anywhere in = section 5 where this is stated. Are the schema entries in this sections = simply excerpts from Section 11? Perhaps an additional introductory line = under 5 could clear this up. Note that 6.8 and some other sections with = this sort of text explicitly invoke XSD. Do we need a reference to XSD? = I validated the XML in section 11, but didn't check every snippet in = 5-7. has anybody done this? The XML gurus are rather unforgiving about = invalid XML. 5.2 Response Codes and Messages: Are we going to need an IANA registry = for response codes? If so, we should define one under IANA = Considerations. 6.1 DestGrpType discusses server-defined date/time values.Do we need = further discussion on time zones, relative vs. absolute times, and what = these time values mean to clients? This question persists through = several subsequent extensions of BasicObjType (6.5, 6.7, 6.9, 6.13). = Examples in section 7 are using Z-time. What are the consequences, if = any, of time-base mismatches? Do we need to say anything about this? 6.3 p4: s/Destionation/Destination/, several times. 6.9/6.10 I'm befuddled about the functionality of putting peeringOrg = elements into a Route Group Offer operation. Maybe I'm just being = normally dense. Are we trying to say that the registry should accept the = route group because the listed peeringOrgs already have? Is this subject = to some sort of "bullshit attack" like the chain-letter spam that claims = the reported virus was validated by Microsoft? Section 7: Anybody validated the XML herein? It looks good to my Mark 1 = eyeballs, but they're a bit out of date. Section 9, Security Considerations. See my earlier rant. If the IESG = lets the doc through without more flesh here, I'll buy an adequate = number of rounds for everybody in the working group. Additionally, Mickael had some questions on the list, some of which = seem to require modifications to the text. I'd not like to forget about = those. -- Dean From dschwartz@xconnect.net Thu May 26 01:23:50 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB85E06B7 for ; Thu, 26 May 2011 01:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acmaHponV1zT for ; Thu, 26 May 2011 01:23:49 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4AEE06B9 for ; Thu, 26 May 2011 01:23:48 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Thu, 26 May 2011 11:23:46 +0300 From: David Schwartz To: Dean Willis Date: Thu, 26 May 2011 11:23:45 +0300 Thread-Topic: [drinks] Review of draft-ietf-drinks-spprov-07 Thread-Index: AcwbfjsTep4ntw0DSmemNBWD/lJ//A== Message-ID: References: <648D3997-FA3A-4FED-9855-2B4668D8809E@softarmor.com> In-Reply-To: <648D3997-FA3A-4FED-9855-2B4668D8809E@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Review of draft-ietf-drinks-spprov-07 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 08:23:50 -0000 Hi Dean... some comments inline... On May 25, 2011, at 10:27 PM, Dean Willis wrote: >=20 > As I seem to recall Sumanth asking me to do so, I've just done a read thr= ough of draft-ietf-drinks-spprov-07. >=20 > It's a pretty solid document with a couple of nits that may need fixing. = I'm also thinking that the security considerations and related discussion a= round authentication and authorization issues are a bit light and are likel= y to draw fire from the IESG. >=20 > I'll discuss my points in the order I noted them while going through the = document, since I'm too lazy to actually organize by priority or in any mor= e meaningful way. >=20 > 4.1/4.2 NIT: We have some inconsistent capitalization oddities relating t= o words like "client", "server", "request" and "response", which are someti= mes capitalized and sometimes aren't. There may be some sort of not-obvious= --to-me rule in play about where they are being used as proper nouns vs. or= dinary nouns, but it was a bit distracting and is likely to get changed by = the RFC editor anyhow. I suggest quoting the word in its definition, then j= ust using lower case everywhere else: For example, a "special term" may be = defined in the text, but once it has been so defined, it's a just a special= term. >=20 > 4.4 Discusses authentication, which section 3.1 says is mostly out of sco= pe for this document. However, there are some subtleties that it seems like= the core spprov document needs to think about. Is there a requirement for= selective authorization? Given that SPPP intro and 3.2 seems to describe a= registry as being provisioned by multiple SSPs, this could be important. D= o we need the request to model to 1) carry a subset specifier, or 2) provi= sion selective access capabilities? Do we need the response model to discus= s authorization failures in a useful way, for example saying "This part of = your request failed, but that part would have succeeded?" Indeed, spprov 4= .4 talks about "authentication of the Client by the Server is expected to b= e used to identify and further authorize the Client to certain resources on= the Server." Does the protocol have a need to allow a client to specify wh= ich other clients can change the data it submitted? DS: This topic does indeed (imho) warrant additional discussion. While the = current thought process is that this topic is implementation specific, afte= r actually trying to implement this stuff and getting stuck with the now ab= sent rarID, I think this should be revisited. >=20 > What is the relationship, if any, of the of orgId data element to authent= ication and authorization? >=20 >=20 > 4.5 Confidentiality and Integrity. Requirement for confidentiality and i= ntegrity protection is good, but "by providing encryption capabilities" is = an unsatisfying follow-on, either insufficient to assure the requirements, = or restrictive of techniques that might alternately assure confidentiality = and integrity protection. Easiest fix is to truncate the sentence short of = the quoted text. EKR has many times told me that encryption is not a magic = hammer and that, in a requirements sentence, it's better to declare that wh= ich must be protected than to claim everything is fixed by encryption. >=20 >=20 > Related to both 4.4 and 4.5 as well as section 9 "Security Consideration"= , we really haven't done our homework with respect to RFC 3552 yet. We need= a more detailed deployment and threat model. For example, what are the pos= sible consequences of a fraudulent route insertion? Conflicting route submi= ssions by different parties? Route disclosures? For how long do we think th= at a given message will require confidentiality (as this influences require= ments on key size and algorithm)? >=20 > 4.8/4.9 deal with request/response correlation and acknowledgement. The u= se cases discussed a commit/rollback requirement wherein related sub-reques= ts can be expected to either fail or succeed as a group. Do we adequately a= ddress reporting of the failed sub-request? Do we need to? >=20 > 4.10 Mandatory Transport says "As of this writing of this revision, one = transport protocol proposal has been provided in [I-D.ietf-drinks-sppp-over= -soap]. This section will define a mandatory transport protocol to be compl= iant with this RFC." >=20 > However, at this time, this section does not go on to define a mandatory = transport protocol. So there's something wrong with section 4.10.=20 >=20 > Sections 5-7 discuss protocol data structures that appear to be defined i= n a formal language (XMLSchema), but I haven't noticed anywhere in section = 5 where this is stated. Are the schema entries in this sections simply exce= rpts from Section 11? Perhaps an additional introductory line under 5 could= clear this up. Note that 6.8 and some other sections with this sort of tex= t explicitly invoke XSD. Do we need a reference to XSD? I validated the XML= in section 11, but didn't check every snippet in 5-7. has anybody done thi= s? The XML gurus are rather unforgiving about invalid XML. DS: Yes, this is a good point. As much of the original work was culled from= the ESPP work done at CableLabs, I suspect that some parts of the XSD made= it over to SPPP without their accompanying textual descriptions. It should= be fairly easy I would think to regenerate the required text in SPPP for t= hese constructs. >=20 > 5.2 Response Codes and Messages: Are we going to need an IANA registry fo= r response codes? If so, we should define one under IANA Considerations. >=20 > 6.1 DestGrpType discusses server-defined date/time values.Do we need furt= her discussion on time zones, relative vs. absolute times, and what these t= ime values mean to clients? This question persists through several subseque= nt extensions of BasicObjType (6.5, 6.7, 6.9, 6.13). Examples in section 7 = are using Z-time. What are the consequences, if any, of time-base mismatche= s? Do we need to say anything about this? DS: I have always been a fan of just using UTC >=20 > 6.3 p4: s/Destionation/Destination/, several times. >=20 > 6.9/6.10 I'm befuddled about the functionality of putting peeringOrg elem= ents into a Route Group Offer operation. Maybe I'm just being normally den= se. Are we trying to say that the registry should accept the route group be= cause the listed peeringOrgs already have? Is this subject to some sort of = "bullshit attack" like the chain-letter spam that claims the reported virus= was validated by Microsoft? DS: The idea behind the peeringOrgs is the notion that I may want to share = information about a route with some and not with others. The idea behind so= urceID is the notion that I may want to give different egress points to dif= ferent requesting parties. Both these functionality are quite important for= managing peering relationships. The one comment I have on this is that whi= le I completely understand the sourceID binding to the RouteGroup, I think = the peeringOrgs should actually be tied to the DestinationGroup and not the= RouteGroup. >=20 > Section 7: Anybody validated the XML herein? It looks good to my Mark 1 e= yeballs, but they're a bit out of date. >=20 > Section 9, Security Considerations. See my earlier rant. If the IESG lets= the doc through without more flesh here, I'll buy an adequate number of ro= unds for everybody in the working group. >=20 > Additionally, Mickael had some questions on the list, some of which seem= to require modifications to the text. I'd not like to forget about those. >=20 > -- > Dean >=20 >=20 >=20 >=20 > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks From dean.willis@softarmor.com Thu May 26 07:33:32 2011 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DE1E06B2 for ; Thu, 26 May 2011 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmisNUO4Zbgk for ; Thu, 26 May 2011 07:33:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E960E0657 for ; Thu, 26 May 2011 07:33:28 -0700 (PDT) Received: by ywp31 with SMTP id 31so465659ywp.31 for ; Thu, 26 May 2011 07:33:27 -0700 (PDT) Received: by 10.236.139.231 with SMTP id c67mr1133562yhj.241.1306420407580; Thu, 26 May 2011 07:33:27 -0700 (PDT) Received: from [192.168.2.124] (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id v70sm1000510yhm.31.2011.05.26.07.33.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2011 07:33:26 -0700 (PDT) References: <648D3997-FA3A-4FED-9855-2B4668D8809E@softarmor.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <8D100F8A-BBC0-4A31-B7F8-B79C0A8F0F5A@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Thu, 26 May 2011 09:33:24 -0500 To: David Schwartz X-Mailer: Apple Mail (2.1084) Cc: "drinks@ietf.org" Subject: Re: [drinks] Review of draft-ietf-drinks-spprov-07 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:33:32 -0000 On May 26, 2011, at 3:23 AM, David Schwartz wrote: >>=20 >>=20 >> 6.1 DestGrpType discusses server-defined date/time values.Do we need = further discussion on time zones, relative vs. absolute times, and what = these time values mean to clients? This question persists through = several subsequent extensions of BasicObjType (6.5, 6.7, 6.9, 6.13). = Examples in section 7 are using Z-time. What are the consequences, if = any, of time-base mismatches? Do we need to say anything about this? >=20 > DS: I have always been a fan of just using UTC Can we include UTC in the specification? What happens if the client and the server have wildly different ideas of = the current value of UTC? Does anything break? >>=20 >> 6.3 p4: s/Destionation/Destination/, several times. >>=20 >> 6.9/6.10 I'm befuddled about the functionality of putting peeringOrg = elements into a Route Group Offer operation. Maybe I'm just being = normally dense. Are we trying to say that the registry should accept the = route group because the listed peeringOrgs already have? Is this subject = to some sort of "bullshit attack" like the chain-letter spam that claims = the reported virus was validated by Microsoft? >=20 > DS: The idea behind the peeringOrgs is the notion that I may want to = share information about a route with some and not with others. The idea = behind sourceID is the notion that I may want to give different egress = points to different requesting parties. Both these functionality are = quite important for managing peering relationships. The one comment I = have on this is that while I completely understand the sourceID binding = to the RouteGroup, I think the peeringOrgs should actually be tied to = the DestinationGroup and not the RouteGroup. Well, let's get that discussed on this list, then. If I understand what you said, then the peeringOrg element dictates to = whom one might make an object (DestinationGroup or RouteGroup, TBD) = available. This means it interacts with the authentication/authorization model in a = way that the current protocol spec does not elucidate, and probably = should. -- Dean