From alexander.mayrhofer@nic.at Mon Nov 1 12:30:36 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 211E128C112 for ; Mon, 1 Nov 2010 12:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.541 X-Spam-Level: X-Spam-Status: No, score=-5.541 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_32=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] 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 ZM0kn2fmJlps for ; Mon, 1 Nov 2010 12:30:32 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id CF4DD28C0DC for ; Mon, 1 Nov 2010 12:30:31 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.46 ; Mon, 1 Nov 2010 20:30:32 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.702.0; Mon, 1 Nov 2010 20:30:26 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 1 Nov 2010 20:30:24 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650973F3FC@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: use cases document: background info on -04 Thread-Index: Act5+zq3MxqhrpYZROyG2SkBVBn6rQ== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] use cases document: background info on -04 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: Mon, 01 Nov 2010 19:30:36 -0000 As you might know, we received very useful reviews of the use cases document from 3 contributors shortly after Maastricht (based on our call for volunteers). Sumanth as the document editor has modified the use cases draft based on the comments - the result of that work is version -04 of the use cases document (for which the WG chairs intend to issue WGLC shortly): https://datatracker.ietf.org/doc/draft-ietf-drinks-usecases-requirements / The text below is background information about the individual issues raised by the reviewers, and how they were addressed in -04.=20 Alex -------- Sohel's Review: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Some general comments: {=20 >=20 > Will it be addressed in a use case or say this is how it is done but=20 > outside of scope.=20 >=20 > 8xx-xxx-xxxx translation to NPA-Nxx-xxxx.=20 =3D=3D> Alex: If i understand correctly, this is about mapping "service" numbers (such as toll-free) to geographic numbers (it's done in a similar way in most countries, i guess). Honestly, i don't have enough insight into=20 whether there's any special case in *routing* those numbers - the "internal" translation in the carrier's destination network from 0800 to NPA number is IMHO out of scope - but i'm happy about feedback from anyone with=20 more insight into that. > 911-location-specific-information-(caller address, and emergency=20 > provider of the caller location).=20 =3D=3D> Alex: I think this must be out of scope, because it has little = to do with the actual session setup.=20 > (If Geo location related documents cover it, we may need to refer to=20 > those documents).=20 =3D=3D> Alex: It might very well be the other way around - GEOPRIV could define=20 extensions to the DRINKS protocol once everything's a bit clearer > The CNAME is another attribute that we use. Will there be a use case?=20 =3D=3D> Alex: CNAME is already mentioned in "UC INTERCONNECT #6". I do therefore=20 think this is covered. > Will mobility related use case be included? (e.g., home domain, visited=20 >domain)?=20 =3D=3D> Alex: I have no idea whether this is relevant or not. Again, a person with more insight could help? My rough guess is that this is supposed to be=20 some kind of dynamic mechanism where sessions get always routed to the=20 visited domain?=20 > Open numbering plan use case...=20 =3D=3D> Alex: This is covered in "UC MISC #2" > We do not have to say, "In this version of this document...", instead=20 > "This document..."=20 =3D=3D> Alex: This is right - corrected in draft -04. > Can we borrow Figure 1 of draft-mule-drinks-proto-02 to replace Figure 1=20 > of the use case draft?=20 =3D=3D> Alex: Figure 2 of the usecases draft already contains a "dotted registry". Since=20 we don't have any explicit inter-registry use cases in this document, i=20 think it might make sense to keep just the "primary" components in figure 1. Figure 2 contains an indication that registry-registry provisioning might=20 be possible. > For figure 2, some providers have another data repository in between LDR=20 > and Registry. I do not know whether you want to add it.=20 =3D=3D> Alex: I wouldn't. It complicates the picture, and is strictly an internal detail (and choice) of the respective SSP. > In UC PROV 1: In real time provisioning it is not mentioned whether it > is a single provisioning, multi provisioning, or bulk provisioning. It > is okay because in UC PROV 3 actually explains that provisioning can be=20 > multi-provisioning.=20 =3D=3D> Alex: I understand that UC PROV 1 is hence fine. > In UC PROV 2: it talks about non-realtime provisioning but in bulk=20 > sense.=20 > > Can Prov 1, 2, 3 be written as:=20 > > 1) Real-time single provisioning=20 >=20 > 2) Real time multi provisioning=20 >=20 > 3) Realtime bulk provisioning=20 > > 4) Non-Real-time single provisioning=20 > > 5) Non-Real time multi provisioning=20 > > 6) Non-Realtime bulkprovisioning=20 =3D=3D> Alex: Note that the use cases that we have are only examples. Nobody prevents an implementer to create a registry that=20 supports real-time bulk processing (even though it might be hard),=20 or even real-time multi bulk processing. I don't think that we should describe all combinations, though. The definition of "bulk" is a little weak, though.. > LUF and LRF referred from RFC 5486. These are neither re-defined in the=20 > draft nor shown in a figure. Thus, section (3.3) use cases become=20 > confusing. A figure in section 3.3 to show these functions will be=20 > helpful.=20 =3D=3D> Alex: They are not redefined by purpose. RFC 5486 contains all = the definitions, and is important to understand the proposed requirements. I have moved RFC 5486 from "Informative" to "Normative". I don't think it's a=20 downref problem when an informative document refers normatively to another=20 informative doc (skimmed through RFC 3967..) > Section 5 security needs to explain the need for integrity and privacy > of data. May suggest to use encryption on the interface between LDR and=20 > registry.=20 =3D=3D> Alex: Section 4 of the *protocol* document covers some = requirements for the=20 transport protocol, however, it's right that we don't have any=20 requirements on the security of the protocol itself.=20 I have therefore added a paragraph to the Security Considerations=20 section of the document. > Route Group (page 12-13): a small tree figure with root and branches=20 > will be helpful to clear up the definition.=20 =3D=3D> Alex: I am not convinced that a figure helps here. I have, = however=20 changed something else - we have "routING groups" and "routE groups",=20 i have now changed all into "routE groups", since that is what we've=20 been talking about all the time (and also what the protocol doc uses). Otmar's review =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > #1 > > > > This document reuses terms from [RFC3261] (e.g., SIP), [RFC5486] > > (e.g., LUF, LRF, SED) and [RFC5067] (carrier-of-record and transit > > provider). In addition, this document specifies the following > > additional terms. > > I'm missing a definition of RN (Routing Number?). > > =3D=3D=3D > [S] Hmmm, I guess we are missing a reference to RFC4694.=20 > =3D=3D=3D =3D=3D> Alex: I have added a definition for "RN", and included a = reference to RFC4694. > #2 > > Registry: The authoritative source for provisioned session > > establishment data (SED) and related information. >=20 > It is explained later, but at that stage it would have been helpful to > state whether that Regstry is=20 > part of a SSP or whether it is an independent body. > > =3D=3D=3D > [S] We can add the clarification. > =3D=3D=3D =3D=3D> Alex: I have added a note. > #3 > > Registrar An entity that provisions and manages data into the > > registry. >=20 > That term appears only once in the rest of the document, and in=20 > most cases its "SSP provisions...". >=20 > So perhaps junk it? >=20 > > Registrant An entity whose data is provisioned into the registry. > > The registrant can act as its own registrar or - additionally or > > alternatively - delegate this function to a third party who acts > > as its registrar. >=20 > Never appears in the document. > =3D=3D=3D > [S] This is probably my bad. We agreed to use registrar and=20 > registrant to the use cases (at the interim meeting), but=20 > it is not used as expected. > =3D=3D=3D =3D=3D> Alex: I have now left the definitions in the document - this is = an=20 open issue. [Sumanth] I left the term registrar in the document, and removed registrant. I did add the text contained in the term 'registrant' so that we don't lose sight of it. > #4 > > > > Local Data Repository: The data store component of an addressing > > server that provides resolution responses. >=20 > Is this run by the SSP it serves? >=20 > =3D=3D=3D > [S] Yes. See Figure 2. > =3D=3D=3D =3D=3D> Alex: I haven't changed anything, i consider this solved. > > #5 > >> Public Identifier: A public identifier refers to a telephone number > >> (TN), an email address, or other identity as deemed appropriate, > >> such as a globally routable URI of a user address (e.g., > >> mailto:john.doe at example.net). > >=20 > > Why an email address? Or is this just to a hint in the=20 > > direction of email-like sip URIs like sip:lendl at nic.at? > > =3D=3D=3D > > [S] The idea here was to allow for additional associations=20 > > with a public identity, outside of TNs. Email was referenced > > as an example (not as a look-up key).=20 > > =3D=3D=3D > > This is confusing. From the rest of the use-cases one would assume that the > PI is always the key to the lookup. While I can see the utility of > returning the email-address associated to a TN (e.g. for MMS or > voice-mail), IMHO that address should then be part of the Route-Set and not > part of the PI. >=20 > Perhaps the best way forward is to provide an example on where > email-addresses could appear in a use-case, and use SIP URIs as examples of > a PI. =3D=3D> Alex: I agree with Otmar. We need to be clear in distinguishing = the "input" data type from the "output" data type. Additionally, i'm sure the group=20 doesn't want to touch the politically sensitive topic of "email portability" at all.=20 I have now changed the text from "email" to "sip". > > #6 > >> TN Range: A numerically contiguous set of telephone numbers whose > >> SED can be looked up (resolved). >=20 > As per the Maastricht session: you should explicitly state both that this > could be a range in a closed numbering plan, or a prefix in an open > numbering plan setting. =3D=3D> Alex: i have changed the text accordingly. > > #7 > >> Destination Group: An aggregation of a set of public identifiers, > >> TN Ranges, or RNs that share common SED. > >=20 > > good. perhaps not just SED, but also the "who sees what" properties. > >=20 > > =3D=3D=3D ************ > > [S] Can you elaborate on this (as it applies to the description), please? > > =3D=3D=3D ************ >=20 > If I take a look at the overview diagram, then all the selective > peering/visibility features do not apply to a single TN/RN/PI, but are > connected to DG. so "..that share common SED" is just one part, a DG is > also atomic in respect to the selective peering features. IMHO that should > be part of the definition. =3D=3D> Alex: I'm appending "which is exposed to a common set of peers" = to the=20 sentence.=20 >=20 >=20 > #8 >> Routing Group: An aggregation that contains a related set of SED >> records, and is associated with a set of destination groups. >> Routing groups facilitate the management of SED records - which >> are common to a large number of public identifiers, TN Ranges or >> RNs - for one or more data recipients. >=20 > DGs are intuitively right and important, but for RGs I have more difficulties understanding the argument. I guess it makes sense, but this text does not convince me. >=20 > Please leave the PIs, TN ranges and RN out of the definition, RGs are only connected to Destination Groups. > =3D=3D=3D************ > [S] RGs associate DGs to SED. We discussed some of the rationale at the meeting. Do you still have questions about its applicability? > =3D=3D=3D************ As you say, RGs associate DGs to SED, so PIs, TN ranges and RN should not be in the definition. As I wrote, I don't think the idea is wrong. I just think that you don't make the case for the idea overall in this document. (Somehow this reminds me of file system permissions: The simple unix user-group-world system can do anything, but some settings are tricky to do. Other systems (e.g. windows), provide other abstractions as well, that can be helpful in simplifying some rules. But as you made the TN-DG relationship 0..n:1, you will probably need the ability to do route-groups.) So some more explanations or examples would be helpful. =3D=3D> Alex: I suppose Otmar and Sumanth discuss this? I haven't = touched the text. [Sumanth] I removed the terms from the explanation, in agreement with Otmar's comments. #9 > SED is typically created by the terminating SSP and consumed by the > originating SSP. To avoid a multitude of bilateral exchanges, SED=20 > is "terminating" is perhaps the wrong word for the transit case, as the it's the transit SSP, and not the final, terminating SSP that creates the SED entries. =3D=3D=3D************ [S] That's true. Design Team: any suggestions on how to word this better for direct and transit cases? =20 =3D=3D=3D************ =3D=3D> Alex: I have changed this to "... created by the terminating or next-hop SSP..." - Is this=20 a way forward? [Sumanth] Yes! :) #10 > often shared via intermediary systems - termed registries within this > document. Such registries receive SED via provisioning transactions > from other SSPs, and then distribute the received data into Local > Data Repositories. These local data repositories are used for call > routing by outgoing SBEs. This is depicted in Figure 1. I don't want to pick nits, but the SED alone are useless unless you also provision and distribute the TN-Ranges / PIs / .. to which these SED records apply. The diagram is fine und useful, just be a bit more careful about the terminology. =3D=3D=3D [S] Fair point. =3D=3D=3D =3D=3D> Alex: I have simply replaced "SED" with "data". I have also = removed the word "other". #11 > In this version of the document, we primarily address the use cases > and requirements for provisioning registries. Future revisions may > include data distribution to local data repositories. The resulting > provisioning protocol can be used to provision data into a registry, > or between registries. This is depicted in Figure 2. > > The fact that there could be multiple registries operating in parallel should be stressed somewhere else. The dotted lines make this diagram slightly confusing. Perhaps do a version with the current focus only, and then add a second one that explains what future revisions might do. =3D=3D=3D [S] K =3D=3D=3D=20 =3D=3D> Alex: I have changed this text slightly:=20 "The resulting provisioning protocol can be used to provision data into a registry, or between multiple registries operating in parallel. In , the case of multiple registries = is depicted in dotted lines." #12 > In addition, this document proposes the following aggregation groups > with regards to SED (refer to the use cases in Section 3.5 for the > rationale): > > o Aggregation of public Identifiers into a destination group. > > > o Aggregation of SED records into a Routing Group. As before, some more explanations on the RG, perhaps with some examples might be helpful. =3D=3D=3D************ [S] In addition to the use cases? =3D=3D************ =3D=3D> Alex: I think this one is related to #8 - i haven't changed = anything in the document.. >=20 >=20 > #13 >> >> The data model depicted in Figure 3 shows the various entities, >> aggregations and the relationships between them. >> >=20 > I think the direct PI-SED link should be removed. It just leads to endless special-cases in all the code. One idea on how one might simplify this: Perhaps provide for an RN/TN/PI -> RN/TN/PI mapping for these cases? The actual routing could then go via the normal way. =3D=3D> Alex: This was discussed at the interim meeting as a way to = include additional,=20 per-user specific SED (for example, email address?), when the remaining SED is=20 identical for a large number of PIs. I was convinced that this is needed.=20 Regarding Otmar's proposal, i don't think there's any difference whether this=20 "additional link" refers to the SED or the RN/TN/PI object. From the "input"/"output"=20 logic it seems useful to keep the SED object. One thing that i guess *could* help is that "directly linked" SED cannot be contained in a RG? However, this could=20 also be local server policy.. I have for now not changed anything in the document. Opinions on the above? [Sumanth] Based on the interim meeting, I am inclined to leave this as-is :). =3D=3D> Alex: I agree, i think this is useful in certain scenarios. > #14 >> UC INTERCONNECT #4 Selective Peering (a.k.a. per peer policies): >> SSPs create peering relationships with other SSPs >> in order to establish interconnects. However, >> SSPs peering relationships often result in >> different points of ingress or other SED for the >> same set of public identifiers. >=20 > Please clarify the level of selectiveness supported: > by PI, by TN-Range, by RN or just by Destination-Group. >=20 > =3D=3D=3D > [S] Destination Group is an internal structure, so it would be by PI, RN or TN Range. We can clarify. > =3D=3D=3D Hu? Do DG feature in the protocol? if yes, then it is better to tell users right here that DGs are atomic with respect to the selective peering features. =3D=3D> Alex: I agree with Otmar here - selective peering is "per-DG", = since there's no=20 relation between peers and individual TN/TN-Range. The "tool of the trade" to achieve=20 this is the relation between RG and Peer. However, looking at the overview diagram,=20 this could actually be achieved in two ways: - Either create one route group per group of peers that have seperate routing policy,=20 and then add the Destination Groups that shall be visible into that route group.=20 This would be the case where different groups of peers receive different SED=20 (different ingress points). - Or create a single route group, and only associate those peers to this route=20 group that shall have access (so just a single entrance point, probably the case=20 how smaller SSPs might handle it). I sense that we really need to describe this into greater detail to not confuse=20 people - opinions? [Sumanth] I agree with your explanation, but I don't know if we really need to specify this in the use case. The protocol document is where this may need to be explained, no? #15 > UC INTERCONNECT #5 Provisioning of a delegated name server: An SSP > maintains a Tier 2 name server that contains the > NAPTR records that constitute the terminal step > in the LUF. The SSP needs to provision a > registry to direct queries for the SSP's numbers > to the Tier 2 name server. Usually queries to > the registry should return NS records, but in > cases where the Tier 2 uses a different domain > suffix from that used in the registry, CNAME and > NS records may be employed instead. WTF? The rest of the draft talk about generic SED, does not specify a query protocol, and now, out-of-the-blue, we're on NAPTR, NS, CNAME level? This makes no sense at this level. If there is a use-case, describe it at the same abstraction level as the others. =3D=3D=3D [S] OK :)! I think we agreed to make this abstract at the meeting. =3D=3D=3D =3D=3D> Alex: See my proposal on Peter's comment below. #16 >3.3. Category: SED Exchange and Discovery Models > UC SED EXCHANGE #2 SED Exchange and Discovery using LUF's Domain > Name: When establishing peering relationships > some SSPs may not wish to communicate or receive > points of ingress and other SED using a registry. > They wish to only communicate or receive domain > names resolvable via [RFC3263], and this query > will then return the points of ingress or other > SED that form the LUF. I think this is ok, but the text confuses me. Please describe (perhaps using examples) what the query is and what the answer will be. (Examples would be helpful for all these 4 types.) =3D=3D=3D [S] We could add some small examples. =3D=3D=3D =3D=3D> Alex: I agree with Otmar - this does confuse me as well. Particularly, it's=20 the second sentence. I have now changed this as follows: "SED Exchange and Discovery using LUF's Domain Name: When establishing peering relationships some SSPs may not wish to communicate or receive points of ingress and other SED using a registry. They wish to only communicate or receive domain names (LUF only), and then independently resolvable those domain names via [RFC3263] to the final points of ingress data (and other SED)." Feel free to change - this is just a proposal. #17 >3.5. Category: Separation and Facilitation of Data Management > > UC DATA #1 Separation of Provisioning Responsibility: An SSP's > operational practices often separate the responsibility > of provisioning the points of ingress and other SED, from > the responsibility of provisioning public identifiers (or > TN ranges or RNs). For example, a network engineer can > establish a physical interconnect with a peering SSP's > network and provision the associated domain name, host, > and IP addressing information. Separately, for each new > subscriber, the SSP's provisioning systems provisions the > associated public identifiers. This is good. Perhaps clarifiy that one is the LUF data (PI/TN -> DG mapping) and that the other is the LRF data (DG -> SED). =3D=3D=3D************ [S] Do we really want to add LUF and LRF distinction within the use case? =3D=3D=3D************ =3D=3D> Alex: I don't think we should. It opens up a can of worms, and i think the use case is pretty clear already without mentioning LUF/LRF. #18 > > UC DATA #3 Route Groups: SSPs often provision identical SED for > large numbers of public identifiers, and then expose=20 > that ^^^ this is handled via the DG abstraction. =3D=3D=3D [S] Yes... =3D=3D=3D =3D=3D> Alex: I understand there's no change to text proposed? #19 > relationship between a group of SED records and a group > of public identifiers to one or more SSPs. This combined > grouping of SED records and Destination Groups > facilitates management of public identity SED > relationships and the list of peers (data recipients) > that can lookup those public identifiers and receive that > SED. This dual set of SED Records and Destination Groups > is termed as a Route Group. Once again, the idea is good, but the explanation for the RG rationale is more confusing than helpful. =3D=3D=3D************ [S] Any suggestions (Otmar or the design team)? =3D=3D=3D************ =3D=3D> Alex: Ah, ok. Well, honestly, i don't have any suggestions at = the moment to make the general approach clearer. However, i noticed some discrepancy between the usecases and protocol document: What's called "SED Record" in the usecases document is termed "Route Record" in the protocol document - should we change the term to "Route Record" in the usecases draft as well? [Sumanth] Good catch on the 'SED record' v/s 'Route Record'. We should go with the SED record in the protocol document. This may need to be a review comment. #20 >3.7. Category: Number Portability > > UC NP #1 EDITOR's NOTE: Need to clarify this further. > > > The SSP wishes to provide in query response to public > identifiers an associated routing number or RN. This is > the case when a set of public identifiers is no longer > associated with original SSP but have been ported to a > recipient SSP who provides access to these identifiers via > a switch on the SS7 network identified by the RN. In this > case a destination group containing all numbers that should > be routed to this RN needs to be created and the route > group associated with this DG needs to contain the RN I do not think this is a good idea. =3D=3D=3D [S] :) =3D=3D=3D =3D=3D> Alex: I'm pretty open about this. Important for me is that the = RN is *not* contained in the DG itself, but in a SED Record - otherwise we would breach the "input/output" object architecture. Otmar, what are your concerns? [Sumanth] Well, we do need number portability :). So I left this as-is. #21 >4. Requirements > > REQ13: Support for lookup keys having identical business keys (the > public identity string, the digits that comprise an RN, the > start and end point of a TN range's range) that concurrently > exist across multiple destination groups and where each > destination group may be managed by different SSPs. > > Editor's note: We need to simplify the above requirement. btw, one thing that is missing is the handling of overlapping information: e.g. SSP-A provisions: 123-1000 to 123-1999 to DG "foobar" SSP-B provisions: 123-1100 to 123-1149 to DG "funk" what would a query for 123-1120 yield? Both entries? Just the one from the closer match? =3D=3D=3D [S] I don't know if we speak about the resolution here. My personal take is that both of them should be returned (assuming the recipient is allowed to see either). =3D=3D=3D =3D=3D> Alex: We still need to work on the "Editor's note" above. We = can't last call the document with it.. I have now read a few times through the REQ, and i honestly don't think i've fully understood it. Regarding the overlapping issue - i don't think we should specify it. I think it might very well depend on the policy of the local registry. For example, a "least cost" type registry might very well have overlapping information. I'm for defining this as "local policy". #22 >5. Security Considerations > > Session establishment data allows for the routing of SIP sesions > within, and between, SIP Service Providers. Access to this data can > compromise the routing of sessions and expose a SIP Service Provider > to attacks such as service hijacking and denial of service. The data > can be compromised by vulnerable functional components and interfaces > identified within the use cases. This is a bit thin. Consider: * data-leaks * stale data in the registry * protection against a malicious SSP * re-routing of calls due to injection of wrong data =3D=3D> Alex: I've added "A provisioning protocol or interface that implements the described use cases MUST therefore provide confidentiality, and MUST ensure integrity of the provisioning data flow. Authentication and authorization are REQUIRED features of the protocol and interfaces." - Do you think this is enough? #23 > >7. Acknowledgments > > (AT&T Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey, > Nuestar; and Alexander Mayrhofer, enum.at GmbH), and the editors of Neustar. =3D=3D=3D [S] Thanks!=20 =3D=3D=3D =3D=3D> Alex: I have removed the affiliations, since it's uncommon, and = some people work for different companies already... Peter's comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <<< o UC INTERCONNECT #5 Provisioning of a delegated name server: An SSP maintains a Tier 2 name server that contains the NAPTR records that constitute the terminal step in the LUF. The SSP needs to provision a registry to direct queries for the SSP's numbers to the Tier 2 name server. Usually queries to the registry should return NS records, but in cases where the Tier 2 uses a different domain suffix from that used in the registry, CNAME and NS records may be employed instead. (also REQ5) The rest of the use cases is rqther high level, so the apperance of "Tier 2" and the DNS RR types comes a bit out of the blue. Also, from a DNS perspective, the wording could benefit from a rephrase. (e.g., RR's aren't contained in a name server but in a DNS zone; "queries to the registry": the draft does not state that DNS is _the_ lookup protocol; CNAME+NS doesn't suggest how these would interact) All in all, there are hidden assumptions here that would either need more explanation, more references - or maybe better even: an increased level of abstraction). <<< Alex: Yes, i agree this could benefit from more abstraction - and=20 it has been discussed at the interim meeting already. I have rewritten the use case. <<< o UC SED EXCHANGE #1 SED Exchange and Discovery using unified LUF/LRF: When establishing peering relationships some SSPs wish to communicate or receive points of ingress and other SED that contain LUF and LRF. What is meant by "points of ingress and other SED that contain LUF and LRF"? <<< Alex: I have rewritten this, so that it's clearer that the use case describes the "combined" approach. <<< o RN is not expanded in the draft (neither in RFC 5486. <<< Alex: I have added a definition. <<< o Capitalization of "destination group" is not consistent. <<< Alex: I agree. We need to do a nits review once we have solved the remaining issues outlined above. <<< o The text below figure 3 misses a description of the relation between "SED record" and "PI". <<< Alex: I have added a respective description. What we still need to think about is whether an SED record can be contained in one Route Group as well as in one Public Identifier (personally, i think it shouldn't). [Sumanth] The way the diagram depicts it, a SED Record can be *associated* with a public identifier, and *contained* in a Route Group. Would this cause issues? Alex: I think the basic requirement is that the relation is described. I don't mind whether it's an "association", or it is "contained". <<< o Page 9, 1st paragraph: to authorization. However, the act of authorization is considered to be out of scope within this document. maybe "out of the scope of"? (see below for security implications) <<< Alex: corrected. <<< o The term "lookup key", used in 3.6, is never defined. also: capitalization <<< Alex: I have changed this to "Public Identifiers", since those are the objects which are used as lookup keys. Design Team: Anything besides "Public Identifiers"? <<< o Routing Groups vs Route Groups (again: consistent capitalization) Routing Groups are defined under (1) Terminology and Route Groups are (re)defined under UC DATA #3. It is not clear to me that both definitions match 100%, but in any case terminology should be made consistent. <<< Alex: I have changed all occurences to "Route Group". It's the same thing. <<< o IANA considerations: the list of non-actions should contain both registration and the creation of a registry (the absence thereof, of course). <<< Alex: changed. <<< o Security Considerations: the draft says "access" to data could compromise security without being clear whether this is read or write access. The document rules questions of authorization (for the provisioning mechanism) out of scope, so one of the major topics of protecting a registry is not addressed in the requirements. Where are these aspects supposed to be covered? <<< Alex: There is now text that clarifies that a protocol or interface=20 that implements the describe use cases must be considered in the=20 respective specification. <<< o It is a bit unusual for an IETF document, albeit not completely without precedent, to list the affiliations in the Acknowledgements section. <<< Alex: I have removed the affiliations <<< o References: RFC 5486 (SPEERMINT terminology) should be a normative reference, since it is needed to understand this document. <<< Alex: RFC 5486 is now a normative reference. From alexander.mayrhofer@nic.at Mon Nov 1 12:54:05 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 77DAA28C101 for ; Mon, 1 Nov 2010 12:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.486 X-Spam-Level: X-Spam-Status: No, score=-7.486 tagged_above=-999 required=5 tests=[AWL=1.944, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] 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 rzlTuAYwuDix for ; Mon, 1 Nov 2010 12:54:04 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 0DEB428C103 for ; Mon, 1 Nov 2010 12:54:03 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.46 ; Mon, 1 Nov 2010 20:54:04 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.702.0; Mon, 1 Nov 2010 20:54:00 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 1 Nov 2010 20:53:57 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650973F3FF@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC: draft-ietf-drinks-usecases-requirements Thread-Index: Act5/l5shei/n3g6SJCgESjTvv4Fyg== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] WGLC: draft-ietf-drinks-usecases-requirements 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: Mon, 01 Nov 2010 19:54:05 -0000 [as WG chair] This is a DRINKS Working Group Last Call for comments on draft-ietf-drinks-usecases-requirements-04: "DRINKS Use cases and Protocol Requirements" The intended status of the document is "Informational". Please review the document thoroughly, and send comments to this=20 mailing list. The WGLC for the document will last for three=20 weeks, so please send your comments before 22 November 2010, 23:59 UTC. The Tools web page gives an excellent overview about the draft history: http://tools.ietf.org/html/draft-ietf-drinks-usecases-requirements-04 Please also note any messages on the mailing list about the changes=20 in response to the "post-Maastricht" review comments, and=20 their incorporation. thanks, Alex From sumanth@cablelabs.com Tue Nov 2 16:29:56 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 30C823A6A44 for ; Tue, 2 Nov 2010 16:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[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 KVZ7BdXaokSe for ; Tue, 2 Nov 2010 16:29:55 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 6483F3A6A41 for ; Tue, 2 Nov 2010 16:29:52 -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 oA2NTu3W028646 for ; Tue, 2 Nov 2010 17:29:56 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 2 Nov 2010 17:29:56 -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; Tue, 2 Nov 2010 17:29:57 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Tue, 2 Nov 2010 17:29:56 -0600 Thread-Topic: Rough Notes and AI list from the call on 10/28 Thread-Index: ActQMdwXrcsFb0LURMebPnHWJtIGmQQyesrgAVBYIVABXfP+AAFjMzQwAmjUwmA= Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D20315CFC@srvxchg> References: <76AC5FEF83F1E64491446437EA81A61F7D1FF40829@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7D201D8C3C@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7D201D9007@srvxchg> <76AC5FEF83F1E64491446437EA81A61F7D201D949B@srvxchg> <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 10/28 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: Tue, 02 Nov 2010 23:29:56 -0000 IETF DRINKS DESIGN TEAM CALL=20 =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 10/28/2010, 10:00a-10:30a (Eastern)/8:00a-8:30a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Ken Cartwright - Jean-Francois Mule - Manjul Maharishi - Sumanth Channabasappa=20 =20 ACTION ITEMS=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - [WG Chairs] Identify reviewers for the protocol I-D - [Authors] Prepare presentations for Beijing AGENDA =3D=3D=3D=3D=3D=3D 1. Next steps for the documents 2. What do we want to cover in Beijing? NOTES =3D=3D=3D=3D=3D 1. Next steps for the documents - Given that we have had 3 reviewers, whose comments have been incorporate= d, [Alex; in absentia] and Sumanth indicated that we (the WG chairs) will r= equest WGLC for the Use cases document. - In addition, we need need reviewers for the protocol document; The WG c= hairs will request volunteers 2. What do we want to cover in Beijing? - The draft agenda for Beijing is available at: http://www.ietf.org= /proceedings/79/agenda/drinks.txt 0/ Welcome and Administrivia (5 mts) - Note well - Blue Sheets - Scribes - Agenda bashing =20 1/ WG status review (5 mts, WG chairs) =20 2/ Use cases document - status, open issues (15 mts, Design Team) Link : http://tools.ietf.org/wg/drinks/draft-ietf-drinks-= usecases-requirements/ 3/ Protocol document - status, open issues, discussion (45 mts, D= ocument Authors) Link : http://tools.ietf.org/wg/drinks/draft-ietf-drinks-= spprov/ 4/ Proposed Next steps (10 mts) =20 5/ Open Mic (10 mts) - Sumanth requested the authors to start preparing presentations fo= r Beijing = From sumanth@cablelabs.com Tue Nov 2 16:36:18 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 1FC663A6A41 for ; Tue, 2 Nov 2010 16:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.001, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L4KBH8b3sQd for ; Tue, 2 Nov 2010 16:36:17 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 23A733A6A16 for ; Tue, 2 Nov 2010 16:36:17 -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 oA2NaLIe029232 for ; Tue, 2 Nov 2010 17:36:21 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 2 Nov 2010 17:36:21 -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; Tue, 2 Nov 2010 17:36:22 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Tue, 2 Nov 2010 17:36:21 -0600 Thread-Topic: Seeing volunteers for the protocol I-D Thread-Index: Act65sEDEYbBzB6FTmibXb7Ndjis8g== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D20315CFE@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_76AC5FEF83F1E64491446437EA81A61F7D20315CFEsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Seeing 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: Tue, 02 Nov 2010 23:36:18 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7D20315CFEsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The authors of the protocol I-D have indicated that they have addressed ope= n issues and comments (to the best of their knowledge) in the latest revisi= on of the document (draft-ietf-drinks-spprov-03). They have shared updates = along the way on this mailing list (or in design team notes), and will be p= roviding additional details at the DRINKS WG meeting next week. Given this, we would like to request expert reviewers who can help the WG m= ake progress on this I-D. If you are capable, willing, and interested, plea= se respond to this email, or let us know in Beijing next week. Thanks! Alex and Sumanth (as WG Chairs) --_000_76AC5FEF83F1E64491446437EA81A61F7D20315CFEsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
The authors of t= he=20 protocol I-D have indicated that they have addressed open issues and commen= ts=20 (to the best of their knowledge) in the latest revision of the=20 document (draft-ietf-drinks-spprov-03). They have shar= ed=20 updates along the way on this mailing list (or in design team notes), and w= ill=20 be providing additional details at the DRINKS WG meeting next week.=20
 
= Given this,=20 we would like to request expert reviewers who can help the WG make progress= on=20 this I-D. If you are capable, willing, and interested, please respond to th= is=20 email, or let us know in Beijing next week.
 
Thanks!
= Alex and=20 Sumanth (as WG Chairs)
--_000_76AC5FEF83F1E64491446437EA81A61F7D20315CFEsrvxchg_-- From sumanth@cablelabs.com Mon Nov 8 02:51:51 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 79F2628C0F2 for ; Mon, 8 Nov 2010 02:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.000, 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 56yEh2v7Nj1Z for ; Mon, 8 Nov 2010 02:51:50 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id EBCBA28C132 for ; Mon, 8 Nov 2010 02:51:49 -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 oA8Aq9F7006891; Mon, 8 Nov 2010 03:52:09 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 8 Nov 2010 03:52:09 -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; Mon, 8 Nov 2010 03:52:09 -0700 From: Sumanth Channabasappa To: Alexander Mayrhofer , "drinks@ietf.org" Date: Mon, 8 Nov 2010 03:52:08 -0700 Thread-Topic: use cases document: background info on -04 Thread-Index: Act5+zq3MxqhrpYZROyG2SkBVBn6rQE1SdIA Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D20315FA3@srvxchg> References: <8BC845943058D844ABFC73D2220D46650973F3FC@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650973F3FC@nics-mail.sbg.nic.at> 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: Re: [drinks] use cases document: background info on -04 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: Mon, 08 Nov 2010 10:51:51 -0000 [As the document editor] I am enclosing some additional thoughts on the pre= vious email from Alex (sent on 11/2). They address how the final edits were= done for a few comments. Given the lengthy set of comments I have extracte= d the relevant ones and tagged my comments with [S, as editor]. > #3 > > Registrar An entity that provisions and manages data into the > > registry. >=20 > That term appears only once in the rest of the document, and in=20 > most cases its "SSP provisions...". >=20 > So perhaps junk it? >=20 > > Registrant An entity whose data is provisioned into the registry. > > The registrant can act as its own registrar or - additionally or > > alternatively - delegate this function to a third party who acts > > as its registrar. >=20 > Never appears in the document. > [S] This is probably my bad. We agreed to use registrar and=20 > registrant to the use cases (at the interim meeting), but=20 > it is not used as expected. =3D=3D> Alex: I have now left the definitions in the document - this is an= =20 open issue. ~~~~~~~~~~~~~~ [S, as editor] I removed the term 'registrant'. However, we do want to keep= the separation between the registrar and the registrant, so I left the ter= m registrar in there, with an explanation of the separation. This term is u= sed in one of the use cases, and I am hoping it will be used in the protoco= l document. We may want to discuss if we want to add a new use case for thi= s, instead of the explanation.=20 Alternatively we may want to consider adding a use case that separates the= registrar and the registrant. =20 ~~~~~~~~~~~~~~ >=20 >=20 >=20 > #13 >> >> The data model depicted in Figure 3 shows the various entities, >> aggregations and the relationships between them. >> >=20 > I think the direct PI-SED link should be removed. It just leads to endles= s special-cases in all the code. One idea on how one might simplify this: Perhaps provide for an RN/TN/PI -> RN/TN/PI mapping for these cases? The actual routing could then go via the normal way. =3D=3D> Alex: This was discussed at the interim meeting as a way to include= additional,=20 per-user specific SED (for example, email address?), when the remaining SED= is=20 identical for a large number of PIs. I was convinced that this is needed.=20 Regarding Otmar's proposal, i don't think there's any difference whether th= is=20 "additional link" refers to the SED or the RN/TN/PI object. From the "input= "/"output"=20 logic it seems useful to keep the SED object. One thing that i guess *could= * help is that "directly linked" SED cannot be contained in a RG? However, this co= uld=20 also be local server policy.. I have for now not changed anything in the document. Opinions on the above? ~~~~~~~~~~~~~~ [S, as editor] Based on the discussions at the interim meeting, I am inclin= ed to leave this as-is :). ~~~~~~~~~~~~~~ > #14 >> UC INTERCONNECT #4 Selective Peering (a.k.a. per peer policies): >> SSPs create peering relationships with other SSPs >> in order to establish interconnects. However, >> SSPs peering relationships often result in >> different points of ingress or other SED for the >> same set of public identifiers. >=20 > Please clarify the level of selectiveness supported: > by PI, by TN-Range, by RN or just by Destination-Group. >=20 > [S] Destination Group is an internal structure, so it would be by PI, RN = or TN Range. We can clarify. Hu? Do DG feature in the protocol? if yes, then it is better to tell users right here that DGs are atomic with respect to the selective peering featur= es. =3D=3D> Alex: I agree with Otmar here - selective peering is "per-DG", sinc= e there's no=20 relation between peers and individual TN/TN-Range. The "tool of the trade" = to achieve=20 this is the relation between RG and Peer. However, looking at the overview = diagram,=20 this could actually be achieved in two ways: - Either create one route group per group of peers that have seperate routi= ng policy,=20 and then add the Destination Groups that shall be visible into that route g= roup.=20 This would be the case where different groups of peers receive different SE= D=20 (different ingress points). - Or create a single route group, and only associate those peers to this ro= ute=20 group that shall have access (so just a single entrance point, probably the= case=20 how smaller SSPs might handle it). I sense that we really need to describe this into greater detail to not con= fuse=20 people - opinions? ~~~~~~~~~~~~~~ [S, as editor] I don't know if we really need to specify this level of deta= il in the use case document. Perhaps we should leave the use case (i.e., wh= at?) to this document and the way it's done (the how?) to the protocol docu= ment? ~~~~~~~~~~~~~~ =3D=3D> Alex: I understand there's no change to text proposed? #19 > relationship between a group of SED records and a group > of public identifiers to one or more SSPs. This combined > grouping of SED records and Destination Groups > facilitates management of public identity SED > relationships and the list of peers (data recipients) > that can lookup those public identifiers and receive that > SED. This dual set of SED Records and Destination Groups > is termed as a Route Group. Once again, the idea is good, but the explanation for the RG rationale is m= ore confusing than helpful. =3D=3D=3D [S] Any suggestions (Otmar or the design team)? =3D=3D=3D =3D=3D> Alex: Ah, ok. Well, honestly, i don't have any suggestions at the m= oment to make the general approach clearer. However, i noticed some discrep= ancy between the usecases and protocol document: What's called "SED Record"= in the usecases document is termed "Route Record" in the protocol document= - should we change the term to "Route Record" in the usecases draft as wel= l? ~~~~~~~~~~~~~~ [S, as editor] Good catch on the 'SED record' v/s 'Route Record'. We should= go with the SED record in the protocol document. This may need to be a rev= iew comment for the protocol document. ~~~~~~~~~~~~~~ #20 >3.7. Category: Number Portability > > UC NP #1 EDITOR's NOTE: Need to clarify this further. > > > The SSP wishes to provide in query response to public > identifiers an associated routing number or RN. This is > the case when a set of public identifiers is no longer > associated with original SSP but have been ported to a > recipient SSP who provides access to these identifiers via > a switch on the SS7 network identified by the RN. In this > case a destination group containing all numbers that should > be routed to this RN needs to be created and the route > group associated with this DG needs to contain the RN I do not think this is a good idea. [S] :) =3D=3D> Alex: I'm pretty open about this. Important for me is that the RN i= s *not* contained in the DG itself, but in a SED Record - otherwise we woul= d breach the "input/output" object architecture. Otmar, what are your conce= rns? ~~~~~~~~~~~~~~ [S, as editor] I believe we need support for number portability, based on = previous feedback :). However we don't need to specify how this is done. We= removed the last sentence. ~~~~~~~~~~~~~~ =20 From sumanth@cablelabs.com Tue Nov 9 05:11:51 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 6DA053A6973 for ; Tue, 9 Nov 2010 05:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.745 X-Spam-Level: X-Spam-Status: No, score=0.745 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 COqKdS1g7K2l for ; Tue, 9 Nov 2010 05:11:46 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id CCF933A69C0 for ; Tue, 9 Nov 2010 05:11:37 -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 oA9DC10U021897 for ; Tue, 9 Nov 2010 06:12:01 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 9 Nov 2010 06:12:01 -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; Tue, 9 Nov 2010 06:12:01 -0700 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Tue, 9 Nov 2010 06:09:34 -0700 Thread-Topic: FYI: DRINKS is meeting tomorrow, not on Friday Thread-Index: AcuAD1j9AhW/u+a9SH6/9cxWY+TfaQ== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D2031609E@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_76AC5FEF83F1E64491446437EA81A61F7D2031609Esrvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] FYI: DRINKS is meeting tomorrow, not on Friday 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: Tue, 09 Nov 2010 13:11:52 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7D2031609Esrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, For those at the IETF, it looks like the *printed* agenda does not state th= e scheduling change made a few weeks ago. The IETF DRINKS WG will be meetin= g tomorrow (WED) at 9a, and not on Friday (as originally scheduled). Thanks! - S --_000_76AC5FEF83F1E64491446437EA81A61F7D2031609Esrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
For those at the= IETF, it=20 looks like the *printed* agenda does not state the scheduling change made a= few=20 weeks ago. The IETF DRINKS WG will be meeting tomorrow (WED) at 9a, and not= on=20 Friday (as originally scheduled).
 
Thanks!
-=20 S
--_000_76AC5FEF83F1E64491446437EA81A61F7D2031609Esrvxchg_-- From sohel_khan@cable.comcast.com Tue Nov 9 22:16:55 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 654123A68CC for ; Tue, 9 Nov 2010 22:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 EH2m345K62L2 for ; Tue, 9 Nov 2010 22:16:54 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 59A883A6895 for ; Tue, 9 Nov 2010 22:16:54 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.104408209; Wed, 10 Nov 2010 01:17:19 -0500 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0255.000; Wed, 10 Nov 2010 01:17:19 -0500 From: "Khan, Sohel" To: "drinks@ietf.org" Thread-Topic: SMS Route and Calling Name Parameter in SPPP Thread-Index: AcuAnS4LN8MQRjjdQMuTcyR5cSySfA== Date: Wed, 10 Nov 2010 06:17:18 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF0175CA@PACDCEXMB02.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [drinks] SMS Route and Calling Name Parameter in SPPP 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: Wed, 10 Nov 2010 06:16:55 -0000 First, I do not have any intention to slow down the work of SPPP and I will= support my best to complete the SPPP standard development. My main intention is to include SMS route and Calling Name Parameter in SPP= P. In the following write up I will use "SPID" as SMS route parameter and "CNA= M" as Calling Name parameter. To stress my neuatrality of the paramters chosen, I would like to agree tha= t there are implementations apart from SPID and CNAM. >From today's IETF/DRINKS meeting in Beijing, I understand that current WG d= ocument SPPP includes fileds (either as opaque or transparent extensible fi= eld) that "may" be used to provision LRN/RN, SPID, and CNAM. For example, in the page 12 SPPP date model draft, it clearly identifies RN= /LRN as public Identifier. (See below). In the Figure 3, the draft depicts= RN (see below). However, no parameter clearly identifies SPID and CNAM. My request is to cl= early depict/exemplify/identity parameters that can be used for SPID and CN= AM. There can be three types of SPIDs used to route SMS today: SPID, Alt-= SPID, and Private-SPID. Please depict/exemplify/identity parameters that c= an be used for SPID, Alt-SPID, and Private-SPID. Again, I am using term SPID and CNAM to exemplify complex structure of each= parameter. We can chose different names. In conlcusion, if SMS and Calling Name parameters are not included, will it= be possible to include these parameters? From lendl@nic.at Wed Nov 10 01:26:15 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 4EB533A6A7F for ; Wed, 10 Nov 2010 01:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[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 0aPq7GlHy-Ir for ; Wed, 10 Nov 2010 01:26:14 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 4820D3A6A7A for ; Wed, 10 Nov 2010 01:26:13 -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 D5DF04C35C for ; Wed, 10 Nov 2010 10:26:37 +0100 (CET) Message-ID: <4CDA6551.5070407@nic.at> Date: Wed, 10 Nov 2010 10:26:41 +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: IETF DRINKS WG References: <4C46FA74.7030403@nic.at> In-Reply-To: <4C46FA74.7030403@nic.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [drinks] The NP use-case 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: Wed, 10 Nov 2010 09:26:15 -0000 Alex told me that this came up in yesterday's session, and asked me to elaborate: On 21.07.2010 15:47, Otmar Lendl wrote: > >> 3.7. Category: Number Portability >> >> UC NP #1 EDITOR's NOTE: Need to clarify this further. >> >> >> The SSP wishes to provide in query response to public >> identifiers an associated routing number or RN. This is >> the case when a set of public identifiers is no longer >> associated with original SSP but have been ported to a >> recipient SSP who provides access to these identifiers via >> a switch on the SS7 network identified by the RN. In this >> case a destination group containing all numbers that should >> be routed to this RN needs to be created and the route >> group associated with this DG needs to contain the RN > > I do not think this is a good idea. > [ I'm not 100% sure I know how RNs are assigend and used in the NANP, I only know how they operate under +43, so I might be completely off-base here. ] It's been I while, but if I remember correctly, I had the following problem with this: In my mind, the main feature of DGs is that of aggregation: I can group destinations together and can make routing decisions based on the DGs, and not individual numbers. This shrinks the routing-table down from O(#TNs in use) to O(#operators * #service-areas). That is a difference of several orders of magnitude. This makes a dynamic routing-protocol based on DGs possible. (Just imagine how BGP would just fall over and die if it had to deal with /32 routes for all hosts on the Internet.) The TN->RN mapping is a good use-case for the DRINKs protocol. But leave DGs and RGs out of it. The RN is an attribute of the TN, not of the DG. In my opinion, the TN->RN mapping is a simple querier-independent lookup process, not a routing decision. We thus don't need the selective visibility features that are built into RouteGroups. Pure overkill. Furthermore, RN are not SED. They do not immediately tell the switch what to do with the call: they are the INPUT to the PSTN call routing algorithm, not the result. In Drinks terms, I'd recommend the following: * Allow RNs as an attribute of the TN-Range object. (I have little clue whether it would be helpful to allow regex here to work on real ranges and not just individual numbers. Open numbering plans probably need this.) * Alternatively, allow a RN object to list the TN which it serves. * On the querying side, a query for a TN thus returns also the RN, which is then the input for the next query. HTH. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From dschwartz@xconnect.net Wed Nov 10 03:05:56 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 7E22328C0D6 for ; Wed, 10 Nov 2010 03:05:56 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzQ3+-UWetwv for ; Wed, 10 Nov 2010 03:05:52 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id BA8D03A6807 for ; Wed, 10 Nov 2010 03:05:48 -0800 (PST) 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; Wed, 10 Nov 2010 13:06:04 +0200 From: David Schwartz To: Otmar Lendl Date: Wed, 10 Nov 2010 13:06:02 +0200 Thread-Topic: [drinks] The NP use-case Thread-Index: AcuAx0Pyp4kUCKgtQFSb7dJ1So5MWA== Message-ID: References: <4C46FA74.7030403@nic.at> <4CDA6551.5070407@nic.at> In-Reply-To: <4CDA6551.5070407@nic.at> 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: IETF DRINKS WG Subject: Re: [drinks] The NP use-case 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: Wed, 10 Nov 2010 11:05:56 -0000 So first of all my apologies for missing the discussion - time zone differe= nce made it kind of hard to attend. Comments inline... :D On Nov 10, 2010, at 11:26 AM, Otmar Lendl wrote: >=20 > Alex told me that this came up in yesterday's session, and asked me to > elaborate: >=20 > On 21.07.2010 15:47, Otmar Lendl wrote: >>=20 >>> 3.7. Category: Number Portability >>>=20 >>> UC NP #1 EDITOR's NOTE: Need to clarify this further. >>>=20 >>>=20 >>> The SSP wishes to provide in query response to public >>> identifiers an associated routing number or RN. This is >>> the case when a set of public identifiers is no longer >>> associated with original SSP but have been ported to a >>> recipient SSP who provides access to these identifiers via >>> a switch on the SS7 network identified by the RN. In this >>> case a destination group containing all numbers that should >>> be routed to this RN needs to be created and the route >>> group associated with this DG needs to contain the RN >>=20 >> I do not think this is a good idea. >>=20 >=20 > [ I'm not 100% sure I know how RNs are assigend and used in the NANP, I > only know how they operate under +43, so I might be completely off-base h= ere. ] >=20 > It's been I while, but if I remember correctly, I had the following probl= em > with this: >=20 > In my mind, the main feature of DGs is that of aggregation: I can group > destinations together and can make routing decisions based on the DGs, an= d > not individual numbers. This shrinks the routing-table down from > O(#TNs in use) to O(#operators * #service-areas). That is a difference of > several orders of magnitude. >=20 DS: Agreed > This makes a dynamic routing-protocol based on DGs possible. (Just imagin= e > how BGP would just fall over and die if it had to deal with /32 routes fo= r > all hosts on the Internet.) >=20 > The TN->RN mapping is a good use-case for the DRINKs protocol. But leave > DGs and RGs out of it. The RN is an attribute of the TN, not of the DG. DS: imho this is only partially true. I completely agree that RNs are attri= butes of TNs (LUF), however, they are used as well in routing responses (ye= s LRF --> "just route via PSTN and here is the information you need") and a= s such do belong (at least the carrier prefix part of it) on the routing si= de. As for the scaling issue, the solution is to regroup ported numbers int= o new DGs that share the same RNs. In other words, it is true that the port= ing process is a 1-1 where an 11 digit number is associated with a routing = number, however, there are probably many ported numbers associated with any= one RN such that aggregation makes sense. >=20 > In my opinion, the TN->RN mapping is a simple querier-independent lookup > process, not a routing decision. We thus don't need the selective > visibility features that are built into RouteGroups. Pure overkill. DS: hummm. Not sure. In Europe, RNs are displayed as prefixes to the user i= nfo while in the US they are returned as "rn=3D..." tags so there is some l= evel of querier dependency. Since this is geography based more than origina= tor based I remian on the fence on this issue. Am OK leaving it as it is. >=20 > Furthermore, RN are not SED. They do not immediately tell the switch what > to do with the call: they are the INPUT to the PSTN call routing algorith= m, > not the result. DS: They do tell you what to do --> route via PSTN (an IP representing a PS= TN GW) which is no different than route to an IP representing a SIP based S= BC. >=20 > In Drinks terms, I'd recommend the following: >=20 > * Allow RNs as an attribute of the TN-Range object. (I have little clue > whether it would be helpful to allow regex here to work on real ranges an= d > not just individual numbers. Open numbering plans probably need this.) >=20 > * Alternatively, allow a RN object to list the TN which it serves. >=20 > * On the querying side, a query for a TN thus returns also the RN, which = is > then the input for the next query. >=20 > HTH. >=20 > otmar > --=20 > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks From pp3129@att.com Wed Nov 10 05:48:50 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 7D8993A697D for ; Wed, 10 Nov 2010 05:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 uHcklwGp0JVC for ; Wed, 10 Nov 2010 05:48:49 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 56C483A6975 for ; Wed, 10 Nov 2010 05:48:49 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-9.tower-167.messagelabs.com!1289396955!22962858!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 9704 invoked from network); 10 Nov 2010 13:49:15 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Nov 2010 13:49:15 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oAADmZqY019078; Wed, 10 Nov 2010 08:48:35 -0500 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oAADmNfZ018965; Wed, 10 Nov 2010 08:48:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 08:49:02 -0500 Message-ID: <35FE871E2B085542A35726420E29DA6B05331164@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] The NP use-case Thread-Index: AcuAx0Pyp4kUCKgtQFSb7dJ1So5MWAAFfUXw References: <4C46FA74.7030403@nic.at> <4CDA6551.5070407@nic.at> From: "PFAUTZ, PENN L (ATTCORP)" To: "David Schwartz" , "Otmar Lendl" Cc: IETF DRINKS WG Subject: Re: [drinks] The NP use-case 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: Wed, 10 Nov 2010 13:48:50 -0000 So in the US an NP rn is an LRN; it identifies a PSTN end office switch/ point of interface (some switches serve multiple Local Access and Transport Areas; they need an LRN per LATA). I suspect that there are probably many more LRNs than there will be ingress points in SIP interconnection. (There ought to be! If not we are missing the whole point of the evolution to IP interconnect). With this in mind I find myself coming out a little closer to Otmar's position.=20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of David Schwartz Sent: Wednesday, November 10, 2010 6:06 AM To: Otmar Lendl Cc: IETF DRINKS WG Subject: Re: [drinks] The NP use-case So first of all my apologies for missing the discussion - time zone difference made it kind of hard to attend. Comments inline... :D On Nov 10, 2010, at 11:26 AM, Otmar Lendl wrote: >=20 > Alex told me that this came up in yesterday's session, and asked me to > elaborate: >=20 > On 21.07.2010 15:47, Otmar Lendl wrote: >>=20 >>> 3.7. Category: Number Portability >>>=20 >>> UC NP #1 EDITOR's NOTE: Need to clarify this further. >>>=20 >>>=20 >>> The SSP wishes to provide in query response to public >>> identifiers an associated routing number or RN. This is >>> the case when a set of public identifiers is no longer >>> associated with original SSP but have been ported to a >>> recipient SSP who provides access to these identifiers via >>> a switch on the SS7 network identified by the RN. In this >>> case a destination group containing all numbers that should >>> be routed to this RN needs to be created and the route >>> group associated with this DG needs to contain the RN >>=20 >> I do not think this is a good idea. >>=20 >=20 > [ I'm not 100% sure I know how RNs are assigend and used in the NANP, I > only know how they operate under +43, so I might be completely off-base here. ] >=20 > It's been I while, but if I remember correctly, I had the following problem > with this: >=20 > In my mind, the main feature of DGs is that of aggregation: I can group > destinations together and can make routing decisions based on the DGs, and > not individual numbers. This shrinks the routing-table down from > O(#TNs in use) to O(#operators * #service-areas). That is a difference of > several orders of magnitude. >=20 DS: Agreed > This makes a dynamic routing-protocol based on DGs possible. (Just imagine > how BGP would just fall over and die if it had to deal with /32 routes for > all hosts on the Internet.) >=20 > The TN->RN mapping is a good use-case for the DRINKs protocol. But leave > DGs and RGs out of it. The RN is an attribute of the TN, not of the DG. DS: imho this is only partially true. I completely agree that RNs are attributes of TNs (LUF), however, they are used as well in routing responses (yes LRF --> "just route via PSTN and here is the information you need") and as such do belong (at least the carrier prefix part of it) on the routing side. As for the scaling issue, the solution is to regroup ported numbers into new DGs that share the same RNs. In other words, it is true that the porting process is a 1-1 where an 11 digit number is associated with a routing number, however, there are probably many ported numbers associated with any one RN such that aggregation makes sense. >=20 > In my opinion, the TN->RN mapping is a simple querier-independent lookup > process, not a routing decision. We thus don't need the selective > visibility features that are built into RouteGroups. Pure overkill. DS: hummm. Not sure. In Europe, RNs are displayed as prefixes to the user info while in the US they are returned as "rn=3D..." tags so there = is some level of querier dependency. Since this is geography based more than originator based I remian on the fence on this issue. Am OK leaving it as it is. >=20 > Furthermore, RN are not SED. They do not immediately tell the switch what > to do with the call: they are the INPUT to the PSTN call routing algorithm, > not the result. DS: They do tell you what to do --> route via PSTN (an IP representing a PSTN GW) which is no different than route to an IP representing a SIP based SBC. >=20 > In Drinks terms, I'd recommend the following: >=20 > * Allow RNs as an attribute of the TN-Range object. (I have little clue > whether it would be helpful to allow regex here to work on real ranges and > not just individual numbers. Open numbering plans probably need this.) >=20 > * Alternatively, allow a RN object to list the TN which it serves. >=20 > * On the querying side, a query for a TN thus returns also the RN, which is > then the input for the next query. >=20 > HTH. >=20 > otmar > --=20 > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From pp3129@att.com Wed Nov 10 05:52:34 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 EB8013A697F for ; Wed, 10 Nov 2010 05:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Rq8bfzWjxJGb for ; Wed, 10 Nov 2010 05:52:34 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 1AF363A6975 for ; Wed, 10 Nov 2010 05:52:34 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1289397179!64522229!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 18943 invoked from network); 10 Nov 2010 13:53:00 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Nov 2010 13:53:00 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oAADqJJ1022755 for ; Wed, 10 Nov 2010 08:52:19 -0500 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oAADqFaM022710 for ; Wed, 10 Nov 2010 08:52:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 08:52:54 -0500 Message-ID: <35FE871E2B085542A35726420E29DA6B0533116C@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <837E772D16C77141BFA5FEC3F30487FF0175CA@PACDCEXMB02.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] SMS Route and Calling Name Parameter in SPPP Thread-Index: AcuAnS4LN8MQRjjdQMuTcyR5cSySfAAQOvIQ References: <837E772D16C77141BFA5FEC3F30487FF0175CA@PACDCEXMB02.cable.comcast.com> From: "PFAUTZ, PENN L (ATTCORP)" To: "Khan, Sohel" , Subject: Re: [drinks] SMS Route and Calling Name Parameter in SPPP 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: Wed, 10 Nov 2010 13:52:35 -0000 Sohel: Let's be very careful in use of the term SPID. There are multiple efforts to define a global SPID in progress. Some may be more or less suitable for SMS routing. I would not want to identify the generic term SPID in drinks with the US NPAC SPID.=20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Khan, Sohel Sent: Wednesday, November 10, 2010 1:17 AM To: drinks@ietf.org Subject: [drinks] SMS Route and Calling Name Parameter in SPPP First, I do not have any intention to slow down the work of SPPP and I will support my best to complete the SPPP standard development. My main intention is to include SMS route and Calling Name Parameter in SPPP. In the following write up I will use "SPID" as SMS route parameter and "CNAM" as Calling Name parameter. To stress my neuatrality of the paramters chosen, I would like to agree that there are implementations apart from SPID and CNAM. >From today's IETF/DRINKS meeting in Beijing, I understand that current WG document SPPP includes fileds (either as opaque or transparent extensible field) that "may" be used to provision LRN/RN, SPID, and CNAM. For example, in the page 12 SPPP date model draft, it clearly identifies RN/LRN as public Identifier. (See below). In the Figure 3, the draft depicts RN (see below). However, no parameter clearly identifies SPID and CNAM. My request is to clearly depict/exemplify/identity parameters that can be used for SPID and CNAM. There can be three types of SPIDs used to route SMS today: SPID, Alt-SPID, and Private-SPID. Please depict/exemplify/identity parameters that can be used for SPID, Alt-SPID, and Private-SPID. Again, I am using term SPID and CNAM to exemplify complex structure of each parameter. We can chose different names. In conlcusion, if SMS and Calling Name parameters are not included, will it be possible to include these parameters? _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From kcartwright@tnsi.com Wed Nov 10 06:38:33 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 F3CDD3A69C5 for ; Wed, 10 Nov 2010 06:38:32 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ2ZH9cvkIOq for ; Wed, 10 Nov 2010 06:38:28 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 995753A6983 for ; Wed, 10 Nov 2010 06:38:27 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.49321911; Wed, 10 Nov 2010 09:38:51 -0500 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, 10 Nov 2010 09:38:51 -0500 From: "Cartwright, Ken" To: "drinks@ietf.org" Date: Wed, 10 Nov 2010 09:38:30 -0500 Thread-Topic: [drinks] The NP use-case Thread-Index: AcuAuWcKlXb1ShqJQ3KuXG9LiEFhTAAKmPw9AABJonk= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA260C2AAF4E@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4C46FA74.7030403@nic.at>, <4CDA6551.5070407@nic.at>, <754963199212404AB8E9CFCA6C3D0CDA260C2AAF4D@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA260C2AAF4D@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: The NP use-case 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: Wed, 10 Nov 2010 14:38:33 -0000 I'm not a fan of this use case. In fact I do not at all remember it being = in the document in this form the last time I reviewed the document from top= to bottom. The protocol certainly does not do anything to explicitly supp= ort this use case. What the protocol needs in terms of RNs is the ability = to provision RNs into DGs. The management of the relationship between an R= N and TNs is not directly in scope for SPPP. We decided this several month= s ago, and correctly so. In north america, for example, the relationship b= etween an RN and TNs is managed by the NPAC. Ken ________________________________________ From: drinks-bounces@ietf.org [drinks-bounces@ietf.org] On Behalf Of Otmar = Lendl [lendl@nic.at] Sent: Wednesday, November 10, 2010 4:26 AM To: IETF DRINKS WG Subject: [drinks] The NP use-case Alex told me that this came up in yesterday's session, and asked me to elaborate: On 21.07.2010 15:47, Otmar Lendl wrote: > >> 3.7. Category: Number Portability >> >> UC NP #1 EDITOR's NOTE: Need to clarify this further. >> >> >> The SSP wishes to provide in query response to public >> identifiers an associated routing number or RN. This is >> the case when a set of public identifiers is no longer >> associated with original SSP but have been ported to a >> recipient SSP who provides access to these identifiers via >> a switch on the SS7 network identified by the RN. In this >> case a destination group containing all numbers that should >> be routed to this RN needs to be created and the route >> group associated with this DG needs to contain the RN > > I do not think this is a good idea. > [ I'm not 100% sure I know how RNs are assigend and used in the NANP, I only know how they operate under +43, so I might be completely off-base her= e. ] It's been I while, but if I remember correctly, I had the following problem with this: In my mind, the main feature of DGs is that of aggregation: I can group destinations together and can make routing decisions based on the DGs, and not individual numbers. This shrinks the routing-table down from O(#TNs in use) to O(#operators * #service-areas). That is a difference of several orders of magnitude. This makes a dynamic routing-protocol based on DGs possible. (Just imagine how BGP would just fall over and die if it had to deal with /32 routes for all hosts on the Internet.) The TN->RN mapping is a good use-case for the DRINKs protocol. But leave DGs and RGs out of it. The RN is an attribute of the TN, not of the DG. In my opinion, the TN->RN mapping is a simple querier-independent lookup process, not a routing decision. We thus don't need the selective visibility features that are built into RouteGroups. Pure overkill. Furthermore, RN are not SED. They do not immediately tell the switch what to do with the call: they are the INPUT to the PSTN call routing algorithm, not the result. In Drinks terms, I'd recommend the following: * Allow RNs as an attribute of the TN-Range object. (I have little clue whether it would be helpful to allow regex here to work on real ranges and not just individual numbers. Open numbering plans probably need this.) * Alternatively, allow a RN object to list the TN which it serves. * On the querying side, a query for a TN thus returns also the RN, which is then the input for the next query. HTH. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks 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 sohel_khan@cable.comcast.com Wed Nov 10 17:42:13 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 A56B03A68C6 for ; Wed, 10 Nov 2010 17:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 pnO1WP7tOemM for ; Wed, 10 Nov 2010 17:42:12 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 211D53A6895 for ; Wed, 10 Nov 2010 17:42:09 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.104572063; Wed, 10 Nov 2010 20:42:34 -0500 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0255.000; Wed, 10 Nov 2010 20:42:34 -0500 From: "Khan, Sohel" To: "PFAUTZ, PENN L (ATTCORP)" , "drinks@ietf.org" Thread-Topic: [drinks] SMS Route and Calling Name Parameter in SPPP Thread-Index: AcuAnS4LN8MQRjjdQMuTcyR5cSySfAAQOvIQABe89cU= Date: Thu, 11 Nov 2010 01:42:33 +0000 Message-ID: <837E772D16C77141BFA5FEC3F30487FF0179F2@PACDCEXMB02.cable.comcast.com> References: <837E772D16C77141BFA5FEC3F30487FF0175CA@PACDCEXMB02.cable.comcast.com>, <35FE871E2B085542A35726420E29DA6B0533116C@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B0533116C@gaalpa1msgusr7a.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] SMS Route and Calling Name Parameter in SPPP 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, 11 Nov 2010 01:42:13 -0000 The term "SPID" is portrayed as a need for a parameter to indicate SMS rout= e aggegate. Whether the term is "SPID", "SMSURI", or "SMS-ROUTE_VECTOR", we will simpl= y need to add something for SMS. We can have any name or a generic name of = the attribute. Let us assume, we name it as "SMS-ROUTE-VECTOR" (!!! Again, we can chose so= me other name as per the IETF concensus). The "SMS-ROUTE_VECTOR" route vector needs to meet following use case (Pleas= e add more use cases if needed): Use case #1: A provider "Alpha" has two SMS networks: NtwkA and NtwkB. Each network has two SMS peering "gateway/smsc/aggegate": GtwyX and GtwyY A SMS-ROUTE-VECTOT tuple for a customer in GtwyY in NtwkB is as follows in = URI: {"TN", sms, gateway, network, provider} =3D {TN.sms.GtwyY.NtwkB.Alpha.com} Use case #2 A provider "2222"" has two SMS networks: "4444" and "5555" Each Network has two SMS peering "gateway/smsc/aggegate": "8888" and "9999" A SMS-ROUTE-VECTOR tuple for a customer in gateway "8888" in network "5555"= is as follows in "number set": {"TN", sms, gateway, network, provider} =3D {"TN", sms, 8888, 5555, 2222} I wrote this in a hurry so there may be some mistakes. So, please instead o= f debating my mistakes, please add more use case and solutions. Thanks, Sohel ________________________________________ From: drinks-bounces@ietf.org [drinks-bounces@ietf.org] on behalf of PFAUTZ= , PENN L (ATTCORP) [pp3129@att.com] Sent: Wednesday, November 10, 2010 6:52 AM To: Khan, Sohel; drinks@ietf.org Subject: Re: [drinks] SMS Route and Calling Name Parameter in SPPP Sohel: Let's be very careful in use of the term SPID. There are multiple efforts to define a global SPID in progress. Some may be more or less suitable for SMS routing. I would not want to identify the generic term SPID in drinks with the US NPAC SPID. Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Khan, Sohel Sent: Wednesday, November 10, 2010 1:17 AM To: drinks@ietf.org Subject: [drinks] SMS Route and Calling Name Parameter in SPPP First, I do not have any intention to slow down the work of SPPP and I will support my best to complete the SPPP standard development. My main intention is to include SMS route and Calling Name Parameter in SPPP. In the following write up I will use "SPID" as SMS route parameter and "CNAM" as Calling Name parameter. To stress my neuatrality of the paramters chosen, I would like to agree that there are implementations apart from SPID and CNAM. >From today's IETF/DRINKS meeting in Beijing, I understand that current WG document SPPP includes fileds (either as opaque or transparent extensible field) that "may" be used to provision LRN/RN, SPID, and CNAM. For example, in the page 12 SPPP date model draft, it clearly identifies RN/LRN as public Identifier. (See below). In the Figure 3, the draft depicts RN (see below). However, no parameter clearly identifies SPID and CNAM. My request is to clearly depict/exemplify/identity parameters that can be used for SPID and CNAM. There can be three types of SPIDs used to route SMS today: SPID, Alt-SPID, and Private-SPID. Please depict/exemplify/identity parameters that can be used for SPID, Alt-SPID, and Private-SPID. Again, I am using term SPID and CNAM to exemplify complex structure of each parameter. We can chose different names. In conlcusion, if SMS and Calling Name parameters are not included, will it be possible to include these parameters? _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks= From lendl@nic.at Mon Nov 22 02:11:39 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 3035E3A6ACF for ; Mon, 22 Nov 2010 02:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, 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 9SU81CTR0W-i for ; Mon, 22 Nov 2010 02:11:37 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 441B53A6A84 for ; Mon, 22 Nov 2010 02:11:36 -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 6766C4C3A9 for ; Mon, 22 Nov 2010 11:12:28 +0100 (CET) Message-ID: <4CEA420B.1080005@nic.at> Date: Mon, 22 Nov 2010 11:12:27 +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: <8BC845943058D844ABFC73D2220D46650973F3FC@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650973F3FC@nics-mail.sbg.nic.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [drinks] use cases document: background info on -04 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: Mon, 22 Nov 2010 10:11:39 -0000 I've been asked to have a look at the the protocol doc as well, and ... On 01.11.2010 20:30, Alexander Mayrhofer wrote: > > #9 >> SED is typically created by the terminating SSP and consumed by the >> originating SSP. To avoid a multitude of bilateral exchanges, SED >> is > > "terminating" is perhaps the wrong word for the transit case, as the > it's the transit SSP, and not the final, terminating SSP that creates > the SED entries. > > ===************ > [S] That's true. Design Team: any suggestions on how to word this better > for direct and transit cases? > ===************ > > ==> Alex: I have changed this to "... created by the terminating or > next-hop SSP..." - Is this > a way forward? > > [Sumanth] Yes! :) > this issue pops up a few times there as well. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From lendl@nic.at Mon Nov 22 02:26:43 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 77F6A3A6919 for ; Mon, 22 Nov 2010 02:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.465, 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 geNM48rKXHy8 for ; Mon, 22 Nov 2010 02:26:42 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id AAE0328C0D0 for ; Mon, 22 Nov 2010 02:26:41 -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 AC87B4C3A9 for ; Mon, 22 Nov 2010 11:27:36 +0100 (CET) Message-ID: <4CEA4598.1050807@nic.at> Date: Mon, 22 Nov 2010 11:27:36 +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: IETF DRINKS WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [drinks] Transport requirements in the protocol draft 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: Mon, 22 Nov 2010 10:26:43 -0000 One quick feedback to draft-ietf-drinks-spprov-03: ------ 4.9. Request Acknowledgement Data transported in the SPPP protocol is likely crucial for the operation of the communication network that is being provisioned. Failed transactions can lead to situations where a subset of public identifiers (or even SSPs) might not be reachable, or situations where the provisioning state of the network is inconsistent. 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. ------ There is no protocol which can guarantee that Registry and Client both know for sure that the transaction went through and that the other side also knows this. (cf. 2/3 phase commit, Two generals' problem, ...) On other words, there is little a transport protocol can resolve if it has to deal with sudden loss of connectivity. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From mmaharishi@tnsi.com Mon Nov 29 09:27:19 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 21CE228C18B for ; Mon, 29 Nov 2010 09:27:19 -0800 (PST) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 iVek8L7Wlvqv for ; Mon, 29 Nov 2010 09:27:10 -0800 (PST) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id B776428C1A1 for ; Mon, 29 Nov 2010 09:26:23 -0800 (PST) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.49800367; Mon, 29 Nov 2010 12:27:15 -0500 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, 29 Nov 2010 12:27:15 -0500 From: "Maharishi, Manjul" To: Sumanth Channabasappa , "Drinks@ietf.org" Date: Mon, 29 Nov 2010 12:27:13 -0500 Thread-Topic: Seeking volunteers for the protocol I-D Thread-Index: Act65sEDEYbBzB6FTmibXb7Ndjis8gU/35Zg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA260C7E9C57@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <76AC5FEF83F1E64491446437EA81A61F7D20315CFE@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7D20315CFE@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_754963199212404AB8E9CFCA6C3D0CDA260C7E9C57TNSMAILNAwin2_" MIME-Version: 1.0 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: Mon, 29 Nov 2010 17:27:19 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA260C7E9C57TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sumanth, Authors of Transport I-D, I have gone thru the doc and overall, it looks very nice!. I have some comments as detailed below: 1. Sect 3.2, page 12: Public Identifier: Text needs to be tightened u= p. It states Public Identifier is used as a key to perform lookup functions= . And then it states that RN and range could be used as a lookup key, which= is not quite correct. 2. Sect 3.2, page 12: Destination Group: Typo: Should be "named" inst= ead of "name", "their" instead of thier". 3. Sect 3.2, page 12: Route Group: Typo: "establishe" instead of "est= ablish". 4. Sect 4, page 14: Can we leave topics open for discussion, or we ne= ed to close these before this I-D gets thru for publication as RFC? 5. Sect 4.4, page 16: IMO, needs some explanation for allowing unauth= enticated connections. 6. Sect 6.1, page 28: last sentence...two occurrences of "the" togeth= er. 7. Sect 6.1, page 29: First para: Typo: missing "t" in Route Group. 8. Sect 6.9, page 41: Layout and description of the attributes in TNT= ype (such as corInfo) is inconsistent with the way it is defined in other p= laces. Rest of the doc has the XSD definition first, and then the explanati= on of the parameters/attributes. Accordingly, this definition should go aft= er the XSD specification on top of page 42. 9. Sect 6.9, page 43: There is mention of expansion of number ranges = in Open Number Plan section. There is no detail of what that means, and per= sonally, I am not sure we want to go that route. I would prefer to reword t= his and remove the word "expand". Additionally, I didn't quite follow the e= xplanation (and I admit that I haven't followed all of the discussion on th= e mailing list wrt this) of how the ONP stuff is supposed to work. IMO - so= me additional explanation would help to keep everything in the same place (= instead of some of it being on the mailing list, and not in the document it= self). 10. Sect 6.11, page 47: third line - typo, should be "serve" instead of "= server". 11. Sect 7.1, page 55: Mismatch in clientTransId values between the query= and response. 12. Sect 7.3, page 57: Namespace usage for the elements is shown inconsis= tently - it is not shown for rantId and rarId, but is shown for rrName, ete= and uri. 13. Sect 7.5, page 60: CorDateTime is shown as prior to the Creation date= time. Is this an oversight, or there is additional implication behind this= - ie the Registry can return back the Date Time when the Regulatory body a= ctually affirmed the COR claim of the Registrant? IMO, that imposes unneces= sary requirement on the Registry and so the COR date time should be at or a= fter the Creation date time. 14. Sect 7.6, page 61: "rantId0" and "rarId0" should be replaced with "ia= na-en:222". 15. Sect 7.6, page 61: IMO, the rn parameter should be in E.164 format. H= aving 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 sho= uld 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 simpl= y store everything as E.164 objects. 16. Sect 7.16, page 72: The example for GetRteGrpOffersRqstType brings up= a deficiency in the XSD definition. I think rantId and rarId need to be at= tributes that should be specifiable in the XSD for this "Get" operation. 17. Sect 7.16, page 72: Same example - should be "iana-en:111" instead of= "ssp1". 18. Sect 7.17, page 72: Typo in heading - should be "Egress". 19. Sect 8.1, page 79: Typo - should be "the" instead of "te". 20. Sect 12, page 95: States that this section explains how to extend the= protocol and procedures necessary etc, but there is no explanation!. Manjul From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Sumanth Channabasappa Sent: Tuesday, November 02, 2010 7:36 PM To: Drinks@ietf.org Subject: [drinks] Seeing volunteers for the protocol I-D Folks, The authors of the protocol I-D have indicated that they have addressed ope= n issues and comments (to the best of their knowledge) in the latest revisi= on of the document (draft-ietf-drinks-spprov-03). They have shared updates = along the way on this mailing list (or in design team notes), and will be p= roviding additional details at the DRINKS WG meeting next week. Given this, we would like to request expert reviewers who can help the WG m= ake progress on this I-D. If you are capable, willing, and interested, plea= se respond to this email, or let us know in Beijing next week. Thanks! Alex and Sumanth (as WG Chairs) ________________________________ 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_754963199212404AB8E9CFCA6C3D0CDA260C7E9C57TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sumanth, Authors of Transport I-D,

 

I have gone thru the doc and overall, it looks very nice!.

 

I have some comments as detailed below:

1. = ;      Sect 3.2, page 12: Public Identifier: Text needs to be tight= ened up. It states Public Identifier is used as a key to perform lookup fun= ctions. And then it states that RN and range could be used as a lookup key, which is n= ot quite correct.

2. = ;      Sect 3.2, page 12: Destination Group: Typo: Should be “= ;named” instead of “name”, “their” instead of= thier”.

3. = ;      Sect 3.2, page 12: Route Group: Typo: “establishe̶= 1; instead of “establish”.

4. = ;      Sect 4, page 14: Can we leave topics open for discussion, or= we need to close these before this I-D gets thru for publication as RFC?

5. = ;      Sect 4.4, page 16: IMO, needs some explanation for allowing = unauthenticated connections.

6. = ;      Sect 6.1, page 28: last sentence…two occurrences of &#= 8220;the” together.

7. = ;      Sect 6.1, page 29: First para: Typo: missing “t”= in Route Group.

8. = ;      Sect 6.9, page 41: Layout and description of the attributes = in TNType (such as corInfo) is inconsistent with the way it is defined in o= ther places. Rest of the doc has the XSD definition first, and then the explanation of = the parameters/attributes. Accordingly, this definition should go after the= XSD specification on top of page 42.

9. = ;      Sect 6.9, page 43: There is mention of expansion of number r= anges in Open Number Plan section. There is no detail of what that means, a= nd personally, I am not sure we want to go that route. I would prefer to reword this and = remove the word “expand”. Additionally, I didn’t quite fo= llow the explanation (and I admit that I haven’t followed all of the = discussion on the mailing list wrt this) of 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 being on the mail= ing list, and not in the document itself).

10.&nbs= p;  Sect 6.11, page 47: third line – typo, should be ̶= 0;serve” instead of “server”.

11.&nbs= p;  Sect 7.1, page 55: Mismatch in clientTransId values between = the query and response.

12.&nbs= p;  Sect 7.3, page 57: Namespace usage for the elements is shown= inconsistently – it is not shown for rantId and rarId, but is shown = for rrName, ete and uri.

13.&nbs= p;  Sect 7.5, page 60: CorDateTime is shown as prior to the Crea= tion date time. Is this an oversight, or there is additional implication be= hind this – ie the Registry can return back the Date Time when the Regulatory = body actually affirmed the COR claim of the Registrant? IMO, that imposes u= nnecessary requirement on the Registry and so the COR date time should be a= t or after the Creation date time.

14.&nbs= p;  Sect 7.6, page 61: “rantId0” and “rarId0&#= 8221; should be replaced with “iana-en:222”.<= /p>

15.&nbs= p;  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 wr= t E.164 nature of the TN/TNR/TNP/RN parameters – the question is should we? I think= it should 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 complicatio= ns, and it might be preferable to simply store everything as E.164 objects.=

16.&nbs= p;  Sect 7.16, page 72: The example for GetRteGrpOffersRqstType = brings up a deficiency in the XSD definition. I think rantId and rarId need= to be attributes that should be specifiable in the XSD for this “Get” operation= .

17.&nbs= p;  Sect 7.16, page 72: Same example – should be “ia= na-en:111” instead of “ssp1”.

18.&nbs= p;  Sect 7.17, page 72: Typo in heading – should be “= ;Egress”.

19.&nbs= p;  Sect 8.1, page 79: Typo – should be “the” = instead of “te”.

20.&nbs= p;  Sect 12, page 95: States that this section explains how to e= xtend the protocol and procedures necessary etc, but there is no explanatio= n!.

 

 

 

Manjul

 

From: drinks-b= ounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Sumanth Channabasappa
Sent: Tuesday, November 02, 2010 7:36 PM
To: Drinks@ietf.org
Subject: [drinks] Seeing volunteers for the protocol I-D<= /span>

 

Folks,

 

The authors of the protocol I-D have indicated that they= have addressed open issues and comments (to the best of their knowledge) i= n the latest revision of the document (draft-ietf-drin= ks-spprov-03). They have shared updates along the way on this mailing list (or in design = team notes), and will be providing additional details at the DRINKS WG meet= ing next week.

 

Given this, we would like to request expert = reviewers who can help the WG make progress on this I-D. If you are capable= , willing, and interested, please respond to this email, or let us know in Beijing next week.

 

Thanks!

Alex and Sumanth (as WG Chairs)<= /o:p>


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_754963199212404AB8E9CFCA6C3D0CDA260C7E9C57TNSMAILNAwin2_-- From sumanth@cablelabs.com Tue Nov 30 11:01:48 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 AE14128C0D9 for ; Tue, 30 Nov 2010 11:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.261 X-Spam-Level: X-Spam-Status: No, score=-0.261 tagged_above=-999 required=5 tests=[AWL=0.201, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU2ydMzQGQJc for ; Tue, 30 Nov 2010 11:01:48 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 12D7D3A6B9F for ; Tue, 30 Nov 2010 11:01:48 -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 oAUJ2xqI019956 for ; Tue, 30 Nov 2010 12:02:59 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 30 Nov 2010 12:02:59 -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; Tue, 30 Nov 2010 12:02:59 -0700 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Tue, 30 Nov 2010 12:02:58 -0700 Thread-Topic: Meeting Minutes from Beijing Thread-Index: AcuQwM/NYVvEyWJkSp+LecW2leS3+QAAEEVw Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D20452D4B@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_76AC5FEF83F1E64491446437EA81A61F7D20452D4Bsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Meeting Minutes from Beijing 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: Tue, 30 Nov 2010 19:01:48 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7D20452D4Bsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, You can find the meeting minutes from Beijing at: http://www.ietf.org/proceedings/79/minutes/drinks.txt If you have any comments, corrections or questions, please feel free to bri= ng it to our attention. Thanks to Dale Worley for the notes (with Alex M. a= s the backup) and Jean-Francois Mule for being the Jabber scribe. Thanks! Alex and Sumanth --_000_76AC5FEF83F1E64491446437EA81A61F7D20452D4Bsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
You can find the= meeting=20 minutes from Beijing at:
http://www.i= etf.org/proceedings/79/minutes/drinks.txt
 
If you have any = comments,=20 corrections or questions, please feel free to bring it to our attention. Th= anks=20 to Dale Worley for the notes (with Alex M. as the backup) and Jean-Francois= Mule=20 for being the Jabber scribe.
 
Thanks!
Alex and=20 Sumanth
 
 
--_000_76AC5FEF83F1E64491446437EA81A61F7D20452D4Bsrvxchg_--