From sumanth@cablelabs.com Thu Dec 2 07:58:04 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9701528C0CE for ; Thu, 2 Dec 2010 07:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reTp3sXtvf04 for ; Thu, 2 Dec 2010 07:58:03 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id CD61228C13A for ; Thu, 2 Dec 2010 07:57:59 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id oB2FxEe6012933 for ; Thu, 2 Dec 2010 08:59:14 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 2 Dec 2010 08:59:14 -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, 2 Dec 2010 08:59:15 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Thu, 2 Dec 2010 08:59:13 -0700 Thread-Topic: Rough Notes and AI list from the call on 12/2 Thread-Index: ActQMdwXrcsFb0LURMebPnHWJtIGmQQyesrgAVBYIVABXfP+AAFjMzQwCD37uiA= Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D20452EC0@srvxchg> References: <76AC5FEF83F1E64491446437EA81A61F7D203155ED@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7D203155ED@srvxchg> 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 X-Approved: ondar Subject: [drinks] Rough Notes and AI list from the call on 12/2 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 15:58:04 -0000 IETF DRINKS DESIGN TEAM CALL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 12/02/2010, 10:00a-11:00a (Eastern)/8:00a-9:00a (Mountain) Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Ken Cartwright - Manjul Maharishi - Jean-Francois Mule (first half) - Sumanth Channabasappa =20 ACTION ITEMS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Syed, Ken] Verify the comments received so far and make updates to agreed-= upon sections. AGENDA =3D=3D=3D=3D=3D=3D 1. Comments against against the protocol document (http://tools.ietf.org/ht= ml/draft-ietf-drinks-spprov-03) 2. Next Steps NOTES =3D=3D=3D=3D=3D 1. Comments against against the protocol document - Link: http://tools.ietf.org/html/draft-ietf-drinks-spprov-03 - We discussed Manjul's comments in detail + Here are the specific comments from Manjul (http://www.ietf.org/mail-arch= ive/web/drinks/current/msg00841.html) that were considered non-editorial > Sect 3.2, page 12: Public Identifier: Text needs to be tightened up. It s= tates Public Identifier is used as a key to perform lookup functions. And t= hen it states that RN and range could be used as a lookup key, which is not= quite correct. [Design Team] Agree > Sect 4.4, page 16: IMO, needs some explanation for allowing unauthenticat= ed connections. [Design Team] We agreed to remove unauthenticated connections. > There is mention of expansion of number ranges in Open Number Plan sectio= n. There is no detail of what that means, and personally, I am not sure we = want to go that route. I would prefer to reword this and remove the word "e= xpand". Additionally, I didn't quite follow the explanation (and I admit th= at I haven't followed all of the discussion on the mailing list wrt this) o= f how the ONP stuff is supposed to work. IMO - some additional explanation = would help to keep everything in the same place (instead of some of it bein= g on the mailing list, and not in the document itself). [Design Team] We agreed that the text is not very clear, and recommend we u= pdate it. Perhaps we could use some of the description from the examples? > 13. Sect 7.5, page 60: CorDateTime is shown as prior to the Creation da= te time. Is this an oversight, or there is additional implication behind th= is - ie the Registry can return back the Date Time when the Regulatory body= actually affirmed the COR claim of the Registrant? IMO, that imposes unnec= essary requirement on the Registry and so the COR date time should be at or= after the Creation date time. [Design Team] We agreed that this needs to be clarified in the text > 5. Sect 7.6, page 61: IMO, the rn parameter should be in E.164 format. = Having said that, we haven't made any statement in the doc wrt E.164 nature= of the TN/TNR/TNP/RN parameters - the question is should we? I think it sh= ould be left to the local policy of the Registry on how to handle non-E.164= elements being provisioned (e.g.: use some other rules to determine how to= normalize such data prior to storage and/or further distribution). However= , that does add avoidable complications, and it might be preferable to simp= ly store everything as E.164 objects. [Design Team] We discussed this in some detail. [Manjul] recommended that, = for the sake of simplicity, we specify that all numbers be provisioned as E= .164 numbers. After some discussion we agreed to ask the WG. =20 + We also discussed comments from Otmar See: http://www.ietf.org/mail-archive/web/drinks/current/msg00840.html [Design Team] We agreed to modify the text. http://www.ietf.org/mail-archive/web/drinks/current/msg00839.html [Design Team] Agreed. + There were a few other comments raised by Ken, reproduced below: [Ken] I believe that we had agreed to remove the EmailType, but that never = got reflected in the XSD or the wsdl. Removing this would be an easy chang= e. [Ken] We should consider shortening a few of the element names, particularl= y those that are contained in the PubIDType base type and the concrete publ= ic identity types such as TN, TN Range, etc. This will lessen the number o= f characters going over the wire. This would be any easy search and replac= e activity. [Ken] The statements about expanding TN Ranges should probably be removed f= rom the doc. That is probably not an advisable approach, but in any case i= t would be an internal implementation decision of the server rather than so= mething for the protocol. [Ken] The "prefix" attribute in TNRType should be an element rather than an= attribute. Rather than having the properties of an object mixed between e= lements and attributes we've standardized on using elements. 2. Next Steps - The authors will be making updates based on the discussions today and any= resulting discussions from the mailing list. They will update the WG as up= dates are made. From lendl@nic.at Fri Dec 10 01:29:52 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800023A6C8F for ; Fri, 10 Dec 2010 01:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLyiDnJmIGhD for ; Fri, 10 Dec 2010 01:29:50 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 8D0F53A6C81 for ; Fri, 10 Dec 2010 01:29:48 -0800 (PST) Received: from [10.10.0.210] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id E78454C350 for ; Fri, 10 Dec 2010 10:31:16 +0100 (CET) Message-ID: <4D01F363.5020804@nic.at> Date: Fri, 10 Dec 2010 10:31:15 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: drinks@ietf.org References: <76AC5FEF83F1E64491446437EA81A61F7D20315CFE@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7D20315CFE@srvxchg> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [drinks] Seeking volunteers for the protocol I-D X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 09:29:53 -0000 On 03.11.2010 00:36, Sumanth Channabasappa wrote: > > Given this, we would like to request expert reviewers who can help the WG make progress on this I-D. Folks, I've been reading spprov-03 during some commutes and here is a quick recap of my notes. I haven't finished reading, but I thought it would be helpful for the WG to see even a partial review: Page 5: ---- The data provisioned for session establishment is typically used by various downstream SIP signaling systems to route a call to the next hop associated with the called domain. These systems typically use a local data store ("Local Data Repository") as their source of session routing information. More specifically, the SED data is the set of parameters that the outgoing signaling path border elements (SBEs) need to initiate the session. See [RFC5486] for more details. A "terminating" SIP Service Provider (SSP) provisions SED into the registry to be selectively shared with other peer SSPs. ---- We have the same issues with "next hop" versus "terminating" as we discussed in the use-case document. Page 6: ---- use other means to perform the Location Routing Function (LRF) which in turn helps determine the actual location of the Signaling Function in that domain. ---- "Signaling Function" is an IMS term that I think we should avoid here. ... domain or next hop". (this might be a transit ...) Page 11 ---- | | | | +------+ +-----+ +-----+ +-----+ | TN | | TNP | | TNR | | RN | +------+ +-----+ +-----+ +-----+ ---- There are explanations for TN, TNR, and RN, but not TNP on page 12. Page 12 ---- A TN Public Identifier may optionally be associated with zero or more individual Route Records. This ability for a Public Identifier to be directly associated with a set of Route Records (e.g. target URI), as opposed to being associated with a Destination Group, supports the use cases where the target URI contains data specifically tailored to an individual TN Public Identifier. ---- I still don't like this. Page 13 ---- o Organization: An Organization is an entity that may fulfill any combination of three roles: Registrant, Registrar, and Peering Organization. All SPPP objects are associated with two organization identifiers to identify each object's registrant and the registrar. A Route Group object is also associated with a set of zero or more organization identifiers that identify the peering organizations whose query responses may include the routing information (SED) defined in the Route Records within that Route Group. ---- We have a potential source for troubles here: Different registrars will provision entries into the registry that will have to reference objects provisioned by other registrars. Mainly this will involve the identity of registrants and peering organizations. This is in contrast to EPP, where objects created by one registrar will never ever come into contact with objects created by another registrar. Example: if Registrar A wants to make his routeGroups visible to "Carrier ABC", then it important that he uses the same identification of "Carrier ABC" as Registrar B is using when he is processing the routeGroupOffer request. As I read the document, there will be no stand-alone objects for "registrant" and "peering organization" in the registry, instead the OrgIdType will be used. This looks fine at first, see also page 26: ---- The identifiers used for registrants (rantId), registrars (rarId) and peering organizations (peeringOrg) are instances of OrgIdType. The OrgIdType is defined as a string and all OrgIdType instances SHOULD follow the textual convention: "namespace:value" (for example "iana- en:32473"). See the IANA Consideration section for more details. ---- I see the following caveats: A registry needs to clearly define which namespace should be used. If registrars mix them, the system breaks. Eg.: iana-en:12345 might refer to the same entity as itu-spid:0815 Carriers to merge / split. We will have the case where iana-en:11111 get bought up by iana-en:22222 and will want to merge their network. Is this something SPPP needs to directly support or are we sure that case could be handle with the existing protocol? Page 16: ---- 4.6. Near Real Time Many use cases require near real-time responses from the Server. Therefore, a DRINKS transport protocol MUST support near-real-time response to requests submitted by the Client. ---- This is pretty vague. What exactly is "near-real-time"? Page 17: ---- Therefore, a transport protocol for SPPP MUST provide a Response for each Request, so that a Client can identify whether a Request succeeded or failed. ---- As I wrote on Nov., 22th, this is impossible. Page 19: ---- included in the request. And with respect to handling error conditions, it is a matter of policy whether the objects are processed in a "stop and rollback" fashion or in a "stop and commit" fashion. ---- This is a cop-out. Go ahead and define it or make it a flag in the request what behavior is desired. Otherwise this will be a source of subtle interoperability problems. Page 27: ---- The AddRteGrpRqstType operation creates or overwrites a Route Group object. If a Route Group with the given name and registrant ID (which together comprise the unique key or a Route Group) does not exist, then the server MUST create the Route Group. ---- I had to read that sentence twice to make sense of it. Please simplify. A more generic note: The uniqueness constraints of various objects and the write permissions for them is either distributed throughout the document or not really clearly defined. e.g. in this case: is RGname/rantID unique over all registrars? If not, can another registrar also update this Route Group? What if a registrant is served by more than one registrar? Changes its registrar? Page 29: ---- o dgName: Set of zero or more names of DestGrpType object instances. ---- This is basically a foreign key. This leads to the obvious database design questions like: * Does this dgName need to exist when the RteGrp is created? * What happens if a referred to DG is deleted? Will that operation fail? Will it cascade? Page 30: ---- The RteGrpType object provides support for source-based routing via the peeringOrg data element and more granular source base routing via the source identity element. The source identity element provides the ability to specify zero or more of the following in association with a given Route Group: a regular expression that is matched against the resolution client IP address, a regular expression that is matched against the root domain name(s), and/or a regular expression that is matched against the calling party URI(s). The result will be that, after identifying the visible Route Groups whose associated Destination Group(s) contain the lookup key being queried and whose peeringOrg list contains the querying organizations organization ID, the resolution server will evaluate the characteristics of the Source URI, and Source IP address, and root domain of the lookup key being queried. ---- Phew. "resolution client IP address" How is the provisioning side supposed to know that? The resolution client need not be the peering element it sees, it could be some central IN-style call control element. Does this mean that any carrier-internal change in the call routing infrastructure needs to be communicated to all peering partners so that they can updated their RouteGroups? "root domain name" What the *that* supposed to mean? The root domain is "." Can you give an example? "calling party URI(s)" How is this supposed to work for TN-based calls? The regex is certainly helpful to specify a large number of potential call sources with a simple string. But I'm wondering why you are not re-using the DestinationGroup abstraction here. After all, they are supposed to aggregate numbers/URIs that are treated the same when routing towards them, making it pretty likely that they will also get the same treatment when calls originate within a DG. ------------------------ .... to be continued. HTH, otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 //