From dschwartz@xconnect.net Mon Jan 2 08:27:45 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251A921F84E5 for ; Mon, 2 Jan 2012 08:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9q5QSi4D2xZ for ; Mon, 2 Jan 2012 08:27:44 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id D32D421F84F5 for ; Mon, 2 Jan 2012 08:27:42 -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; Mon, 2 Jan 2012 18:27:37 +0200 From: David Schwartz To: "Bhatia, Vikas" Date: Mon, 2 Jan 2012 18:27:36 +0200 Thread-Topic: Some comments/nits on latest SPProv doc Thread-Index: AczJa2/pFy87svXQSjeb8zv3ru1Abw== Message-ID: References: <00DC9946-3629-43F1-BEAC-CBEEC5FC736C@xconnect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF79BCC57E6C46F8A3ADE971E5C44F21xconnectnet_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Some comments/nits on latest SPProv doc X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 16:27:45 -0000 --_000_CF79BCC57E6C46F8A3ADE971E5C44F21xconnectnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Vikas and thanks for responding. My comments are inline as well. I took = the liberty of removing all parts of the email on which I did not have comm= ents. 4.3 -> why isn't this a MUST? [VB:] My understanding on this is that this is more of a performance optimi= zation aspects for large datasets or constant small updates. Hence, it seem= s appropriate to be a SHOULD and not MUST. DS: Not sure I agree. There are use cases for both in the use case doc so I= still think it should be a MUST. Destination Groups 6.1 -> I think that DG should have priority field as well. This allows to d= ifferentiate based on a a parameter other than route (e.g. cost) [VB:] Can you please elaborate on this a bit more on what is the scenario? = I thought the =93priority=94 attribute on the RG determines the route to be= used in situations where same DG is associated with multiple RGs. DS: Sure. One of the things I argued for all along was the ability to prior= itize DGs. The current design has the priority field in the RG which is in = essence "passed onto" associated DG's. This assumes of course that the prim= e driver for prioritization is associated with routing information. I suppo= se the unfortunate use of the term "DestinationGroup" as opposed to a more = generic "IdentifierGroup" is at the root of this (due obviously to the prim= ary use for number lookups). What if I want to prioritize LUF data that is= associated only with a RantID and not necessarily with a route? Yes, I kno= w I can use the existing mechanism - my only question is why? Why not have = "priority" and "peering orgs" associated with the DG instead? What do you l= ose if you do it the way I propose? While on the topic I would also add tha= t peering org should probably be grouped as well into PeeringOrgGroup so th= at I can share with group and not have to enter each org multiple times. Ba= sically I am suggesting the following=85 RouteG | | V PeerG ----> DG (Priority) ^ | | PubID Page 40 - When DG removed - it says PIs removed -> not references by PIs (s= ee next comment about PIs) PIs Page 23 - why is a PI associated with only 1 DG? why not more? What if I ha= ve some TNRange and I want to have both "gold" and "silver" routes associat= ed with it - how would I do this without having this TNR referencing more t= han one DG? [VB:] A PIs association with its DG forms its primary key. There is a =93pr= iority=94 attribute in the RG definition. For =93gold=94 and =93silver=94 r= outes, same TNRange would be created in two DGs with one of the DG associa= ted to the =93gold=94 route (with a higher priority) and other to the =93si= lver=94 route (with a lower priority value). DS: I see this differently. For the same reason you wouldn't delete an RG w= hen a DG is deleted I would not delete a PI when a DG is deleted. The PI an= d the RG do not owe their existence to a DG. The DG is just a way to associ= ate the two. In fact a PI may be reference multiple DGs just like an RG may= reference multiple DGs. If you want to speak of deleting PIs I would sugge= st a reference count mechanism which would make sure that PIs are deleted w= hen a DG that is the ONLY one being referred to by the PI is deleted. I kno= w this is not the way it is currently implemented - I just don't like the A= symmetry. Page 24 -> isn't the idea of a RouteGroup to "group" route records"? Why th= en in the definition of a TN do we refer to an rrRef instead of an rgRef? T= he description does say "one or more" rrRefs which would imply to me that t= his could be a rgRef [VB:] Sorry, but two parts of this comment seem unrelated. Yes, the idea o= f RG is to associate a set of Pub Ids (DG) that share a common routing info= rmation, to the set of Route Records that form that routing information. T= N association to RG is via the DG. TN also refers to rrRef for situations w= here the routing information may be unique to a particular TN. We need to c= orrect the description however to say =93zero or more=94 and not =93one or = more=94. May be that caused the confusion. DS: I guess I never understood this use case anyway (unless we are talking = about an AOR identifier). Assuming a TN like it says - is it not possible t= o have a failover route for a single TN? Am I forced to create a DG for thi= s? Like I said - I don't get this use case. SourceID Page 30 - Why not simply a URI instead of enumeration as regex can deal wit= h parts of URI. We all know that in the end the source information will be = represented in the DNS request using a URI. [VB:] Source information match can be done via the IP where the request is = coming from (which may not be in the URI), root domain or the URI itself. I= n that sense having source identity scheme as one of =93uri=94, =93ipaddres= s=94, or =93rootDomain=94 seems valid. Can you elaborate further? Design Te= am? DS: I am fine with this. It was more of a comment that the "information" re= vealing who the "source" is will probably take the form of a URI. Page 38 - why isn't egrRte associated with RG? [VB:] It probably was just a design decision. Having egrRte associated with= a RG would mean that egrRte definition would also need to have an optional= =93svcs=94 element to defines the type of ENUM service(s) supported by the= route. For situations where many ingress routes share the same egress rout= e, right now there will be an association between egress route object and a= ll RRs that are part of the RG. Design Team? DS: My point exactly - seems kind of inefficient. RGs represent logical ing= ress points while the RRs are the actual IPs. It stands to reason that an e= gress route will apply to all RRs in an RG. --_000_CF79BCC57E6C46F8A3ADE971E5C44F21xconnectnet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Vikas and thanks for responding. My comments are inline as well. I took= the liberty of removing all parts of the email on which I did not have com= ments.

 
4.3 -> why isn= 't this a MUST?
[VB:] My understanding on this= is that this is more of a performance optimization aspects for large datas= ets or constant small updates. Hence, it seems appropriate to be a SHOULD a= nd not MUST.
<= br>
DS: Not sure I agree. There are use cases for both in the use case= doc so I still think it should be a MUST.

 
Destination Groups
6.1 -> I think that DG should = have priority field as well. This allows to differentiate based on a a para= meter other than route (e.g. cost)
[VB:] Can y= ou please elaborate on this a bit more on what is the scenario? I thought t= he =93priority=94 attribute on the RG determines the route to be used in si= tuations where same DG is associated with multiple RGs.
<= /div>

DS: Sure. One of the th= ings I argued for all along was the ability to prioritize DGs. The current = design has the priority field in the RG which is in essence "passed onto" a= ssociated DG's. This assumes of course that the prime driver for prioritiza= tion is associated with routing information. I suppose the unfortunate use = of the term "DestinationGroup" as opposed to a more generic "IdentifierGrou= p" is at the root of this (due obviously to the primary use for number look= ups).  What if I want to prioritize LUF data that is associated only w= ith a RantID and not necessarily with a route? Yes, I know I can use the ex= isting mechanism - my only question is why? Why not have "priority" and "pe= ering orgs" associated with the DG instead? What do you lose if you do it t= he way I propose? While on the topic I would also add that peering org shou= ld probably be grouped as well into PeeringOrgGroup so that I can share wit= h group and not have to enter each org multiple times. Basically I am sugge= sting the following=85

       =                     &nbs= p;RouteG
                =                     |
                   = ;                 |
 = ;                     &nb= sp;            V

&nb= sp;        PeerG ---->     DG (Priority)
            
  &= nbsp;                    =             ^
    &= nbsp;                    =           |
       =                     &nbs= p;       |
          &nbs= p;                   PubID
 
Page 40 - When DG removed - it says PIs removed -> not references= by PIs (see next comment about PIs)
 
PIs
Page 23 - why is a PI associated with only 1 DG? why= not more? What if I have some TNRange and I want to have both "gold" and "= silver" routes associated with it - how would I do this without having this= TNR referencing more than one DG?
[VB:] A PIs association with its DG forms its pr= imary key. There is a =93priority=94 attribute in the RG definition. For = =93gold=94 and =93silver=94 routes, same TNRange would be  created in = two DGs with one of the DG associated to the =93gold=94 route (with a highe= r priority) and other to the =93silver=94 route (with a lower priority valu= e).

= DS: I see this differently. For the same reason you wouldn't delete an RG w= hen a DG is deleted I would not delete a PI when a DG is deleted. The PI an= d the RG do not owe their existence to a DG. The DG is just a way to associ= ate the two. In fact a PI may be reference multiple DGs just like an RG may= reference multiple DGs. If you want to speak of deleting PIs I would sugge= st a reference count mechanism which would make sure that PIs are deleted w= hen a DG that is the ONLY one being referred to by the PI is deleted. I kno= w this is not the way it is currently implemented - I just don't like the A= symmetry.  

=  
Page 24 -> isn't the idea of a RouteGroup t= o "group" route records"? Why then in the definition of a TN do we refer to= an rrRef instead of an rgRef? The description does say "one or more" rrRef= s which would imply to me that this could be a rgRef
[VB:] Sorry, but two parts of this comment seem unrelated.  Yes= , the idea of RG is to associate a set of Pub Ids (DG) that share a common = routing information, to the set of Route Records that form that routing inf= ormation.  TN association to RG is via the DG. TN also refers to rrRef= for situations where the routing information may be unique to a particular= TN. We need to correct the description however to say =93zero or more=94 a= nd not =93one or more=94. May be that caused the confusion.

DS: I guess I never= understood this use case anyway (unless we are talking about an AOR identi= fier). Assuming a TN like it says - is it not possible to have a failover r= oute for a single TN? Am I forced to create a DG for this? Like I said - I = don't get this use case.
=
 
SourceID
Page 30 - Why not simply a URI = instead of enumeration as regex can deal with parts of URI. We all know tha= t in the end the source information will be represented in the DNS request = using a URI.
[VB:] Source information match ca= n be done via the IP where the request is coming from (which may not be in = the URI), root domain or the URI itself. In that sense having source identi= ty scheme as one of =93uri=94, =93ipaddress=94, or =93rootDomain=94 seems v= alid. Can you elaborate further? Design Team?

DS: I am fine with this. It was m= ore of a comment that the "information" revealing who the "source" is will = probably take the form of a URI.
=
 
Page 38 - why isn't egrRte associated with RG?
X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C250621F87DF for ; Wed, 4 Jan 2012 08:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg5fhT87GKrp for ; Wed, 4 Jan 2012 08:30:10 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFAB21F87D7 for ; Wed, 4 Jan 2012 08:30:10 -0800 (PST) Received: by ghbg18 with SMTP id g18so7080750ghb.31 for ; Wed, 04 Jan 2012 08:30:10 -0800 (PST) Received: by 10.101.137.4 with SMTP id p4mr18621976ann.52.1325694609872; Wed, 04 Jan 2012 08:30:09 -0800 (PST) Received: from [192.168.2.104] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id q33sm81718269anh.4.2012.01.04.08.30.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 08:30:08 -0800 (PST) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: Date: Wed, 4 Jan 2012 10:30:06 -0600 To: drinks@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [drinks] corInfo discussion in spprov-12 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 16:30:11 -0000 Based on comments I made about -11, the text relating to corInfo has = been heavily revised in -12. Specifically, in 6.2 we have: o corInfo: corInfo is an optional parameter of type CORInfoType that allows the registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067]). This is done by setting the value of element of the CORInfoType object structure to "true". The other two parameters of the CORInfoType, and are set by the registry to describe the outcome of the carrier-of-record claim by the registrant. In general, inclusion of parameter is useful if the registry has the authority information, such as, the number portability data, etc., in order to qualify whether the registrant claim can be satisfied. If the carrier-of-record claim disagrees with the authority data in the registry, whether the TN add operation fails or not is a matter of policy and it is beyond the scope of this document. This seems reasonably clear, but leaves me wondering: What are the = implications of the corInfo parameter should a registry policy allow a = registrar to claim COR responsibility for a registrant with respect to a = TN that cannot be verified by the registry? Does it actually impact = processing of anything in such a way that this could be a useful attack = vector that we should warn registrars or users of registrar data about = in Security Considerations? Or is it the corInfo status effectively = meaningless? If meaningless, why do we even have it in the database? If corInfo is important, then it's probably important that the registry = handle it appropriately, and provide the information-consumer with = knowledge about the registry's policy with respect to corInfo. = Consequently, it's also important for the information consumer to = understand the registry's policies in this regard, and take them into = consideration when deciding how much trust to place in the corInfo data. If this were the only such policy question, it could probably be dealt = with in Security Considerations: =3D=3D=3D=3D The telephone number data type "TNType" includes an optional parameter = "corInfo" that indicates whether or not the containing public identifier = is the "carrier of record" for this telephone number. Different = registries may have different definitions for "carrier of record" and = different mechanisms for authenticating this claim. Such definitions and = mechanisms are outside the scope of this protocol document. Therefore, = it is critical that a consumer of registry information be aware of the = specific policies applicable to a registry providing information to that = consumer, and consider those policies when making decisions based on = such registry data. =3D=3D=3D=3D Or, should we make authentication of corInfo mandatory for a registry = before allowing it to be registered? Does this mean we need to define an = authentication mechanism and document its use by a registry? However, I'm now wondering: Is this just the tip of the "policy" = iceberg? Remember, we've said that a lot of things are "local policy" = driven. Don't we actually have many data elements whose meaning or = authenticity is subject to variations in registry policy? Perhaps we = need a disclaimer like the above for many (or all) data elements. How = dhould a registry describe its policy for the consumer? Does this mean = we need a formal means of declaring registry policy with respect to = these data items? Or do we need to revisit the "policy-driven" aspect = and specify behavior for all the policy-driven data? If you think I ask too many questions now, you should have met me as a = child ... -- Dean From alexander.mayrhofer@nic.at Tue Jan 10 05:52:21 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6CD21F85F1 for ; Tue, 10 Jan 2012 05:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.198 X-Spam-Level: X-Spam-Status: No, score=-9.198 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIKAGit4rwTF for ; Tue, 10 Jan 2012 05:52:21 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8A70121F849D for ; Tue, 10 Jan 2012 05:52:19 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Tue, 10 Jan 2012 14:52:16 +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.1.355.2; Tue, 10 Jan 2012 14:52:13 +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: Tue, 10 Jan 2012 14:52:12 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B475E53@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Overlap between DRINKS and RTCWEB interims.. Thread-Index: AczPnfvxEwyYnANeS4OotgPcFgj3Lg== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] Overlap between DRINKS and RTCWEB interims.. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 13:52:21 -0000 We've been notified that the RTCWEB working group has scheduled an interim meeting that overlaps with our planned Virtual Interim meeting. The dates of the two meetings are as follows: DRINKS: Feb 01 2012, 9am-1pm ET (virtual) RTCWEB: Jan 31 2012 - Feb 01 2012 "first morning" (?), face-to-face in Mountain View, CA Assuming that the RTCWEB meeting concludes around 1pm local time latest, and considering the 3 hours time difference between Mountain View and ET, the two meetings would overlap for about an hour (since the DRINKS meeting would be a virtual one, it would be possible to attend it also from the RTCWEB meeting premises ;-) Could people please indicate whether that collision would affect their ability to attend the DRINKS meeting? We'd like to get a sense of the list to understand whether we need to consider reschduling. thanks, Alex (as a WG co-Chair) From vbhatia@tnsi.com Mon Jan 16 14:14:25 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4427421F869F for ; Mon, 16 Jan 2012 14:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE5HxnZpw8jC for ; Mon, 16 Jan 2012 14:14:24 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 300D321F8699 for ; Mon, 16 Jan 2012 14:14:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAAmhFE+sEQfn/2dsb2JhbABErDCCEYFyAQEBAwEBAQE3LQcQBwQCAQgRBAEBCxQJBycLFAkIAQEEARIIh3IItXoEiHcWARUHDAIJCQQBDgIBAW0BAgEBCAEBAQwWGBIfNRqCJRYBAQECgkdjBIg7nzU X-IronPort-AV: E=Sophos;i="4.71,520,1320624000"; d="scan'208";a="758865" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 16 Jan 2012 22:14:20 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 16 Jan 2012 17:14:20 -0500 From: "Bhatia, Vikas" To: Dean Willis , "drinks@ietf.org" Date: Mon, 16 Jan 2012 17:14:19 -0500 Thread-Topic: [drinks] corInfo discussion in spprov-12 Thread-Index: AczK/iY+ImELZaXuSYqQwKUgXGukBAFdV3LA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] corInfo discussion in spprov-12 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 22:14:25 -0000 Please see my thoughts below.. > This seems reasonably clear, but leaves me wondering: What are the > implications of the corInfo parameter should a registry policy allow a > registrar to claim COR responsibility for a registrant with respect to a > TN that cannot be verified by the registry? Does it actually impact > processing of anything in such a way that this could be a useful attack > vector that we should warn registrars or users of registrar data about > in Security Considerations? Or is it the corInfo status effectively > meaningless? If meaningless, why do we even have it in the database? > > If corInfo is important, then it's probably important that the registry > handle it appropriately, and provide the information-consumer with > knowledge about the registry's policy with respect to corInfo. > Consequently, it's also important for the information consumer to > understand the registry's policies in this regard, and take them into > consideration when deciding how much trust to place in the corInfo data. "corInfo" is type "CORInfoType" (pasted below for quick ref). As mentioned = in section 6.2, a registrant/registrar can claim being a COR by setting "co= rClaim" element in corInfo to true. If the registry policy is to allow this= to happen without having a way to verify this then the registry shall not = return "cor" and "corDate" elements in the response to the consumers of thi= s information. =3D=3D =3D=3D > However, I'm now wondering: Is this just the tip of the "policy" > iceberg? Remember, we've said that a lot of things are "local policy" > driven. Don't we actually have many data elements whose meaning or > authenticity is subject to variations in registry policy? Perhaps we > need a disclaimer like the above for many (or all) data elements. How > dhould a registry describe its policy for the consumer? Does this mean > we need a formal means of declaring registry policy with respect to > these data items? Or do we need to revisit the "policy-driven" aspect > and specify behavior for all the policy-driven data? As you also allude to, there are other items in the protocol/framework docu= ment that are a matter of policy (use of "priority" field on RG, allowable = values for ENUM Service(s) etc.). Not sure if the design team has considere= d this subject in past discussions. Imo, instead of listing each of them se= parately in the Security Considerations, a generic statement to that effect= in the Security Considerations section can be added to say that "There are= items in the document that are a matter of policy and are indicated as suc= h in the respective sections...Consumer of the registry information be awar= e.." (have not thought through the exact text). > > . . . > There were too many questions:-). Thanks, Vikas > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf > Of Dean Willis > Sent: Wednesday, January 04, 2012 11:30 AM > To: drinks@ietf.org > Subject: [drinks] corInfo discussion in spprov-12 > > > Based on comments I made about -11, the text relating to corInfo has > been heavily revised in -12. > > Specifically, in 6.2 we have: > > o corInfo: corInfo is an optional parameter of type CORInfoType > that allows the registrant organization to set forth a claim to > be the carrier-of-record (see [RFC5067]). This is done by > setting the value of element of the CORInfoType > object structure to "true". The other two parameters of the > CORInfoType, and are set by the registry to > describe the outcome of the carrier-of-record claim by the > registrant. In general, inclusion of parameter is > useful if the registry has the authority information, such as, > the number portability data, etc., in order to qualify whether > the registrant claim can be satisfied. If the carrier-of-record > claim disagrees with the authority data in the registry, whether > the TN add operation fails or not is a matter of policy and it > is beyond the scope of this document. > > This seems reasonably clear, but leaves me wondering: What are the > implications of the corInfo parameter should a registry policy allow a > registrar to claim COR responsibility for a registrant with respect to a > TN that cannot be verified by the registry? Does it actually impact > processing of anything in such a way that this could be a useful attack > vector that we should warn registrars or users of registrar data about > in Security Considerations? Or is it the corInfo status effectively > meaningless? If meaningless, why do we even have it in the database? > > If corInfo is important, then it's probably important that the registry > handle it appropriately, and provide the information-consumer with > knowledge about the registry's policy with respect to corInfo. > Consequently, it's also important for the information consumer to > understand the registry's policies in this regard, and take them into > consideration when deciding how much trust to place in the corInfo data. > > If this were the only such policy question, it could probably be dealt > with in Security Considerations: > > =3D=3D=3D=3D > The telephone number data type "TNType" includes an optional parameter > "corInfo" that indicates whether or not the containing public identifier > is the "carrier of record" for this telephone number. Different > registries may have different definitions for "carrier of record" and > different mechanisms for authenticating this claim. Such definitions and > mechanisms are outside the scope of this protocol document. Therefore, > it is critical that a consumer of registry information be aware of the > specific policies applicable to a registry providing information to that > consumer, and consider those policies when making decisions based on > such registry data. > =3D=3D=3D=3D > > > Or, should we make authentication of corInfo mandatory for a registry > before allowing it to be registered? Does this mean we need to define an > authentication mechanism and document its use by a registry? > > However, I'm now wondering: Is this just the tip of the "policy" > iceberg? Remember, we've said that a lot of things are "local policy" > driven. Don't we actually have many data elements whose meaning or > authenticity is subject to variations in registry policy? Perhaps we > need a disclaimer like the above for many (or all) data elements. How > dhould a registry describe its policy for the consumer? Does this mean > we need a formal means of declaring registry policy with respect to > these data items? Or do we need to revisit the "policy-driven" aspect > and specify behavior for all the policy-driven data? > > If you think I ask too many questions now, you should have met me as a > child ... > > -- > Dean > > > > _______________________________________________ > 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 vbhatia@tnsi.com Tue Jan 17 10:57:17 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB6511E8086 for ; Tue, 17 Jan 2012 10:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOHZzc3bHf40 for ; Tue, 17 Jan 2012 10:57:12 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFA5021F8619 for ; Tue, 17 Jan 2012 10:57:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAKrDFU+sEQfn/2dsb2JhbAA7CYJNqXMdgW6BcgEBAQQnBkUXAgEIDgMEAQELFgEGBzIUCQgBAQQBEgi/GYhbHBYBFToCAQFuAgEJAQEBDBYYEh81GhYUBgEHIAICBwsCAwICBAUDBwICAQMDEAECBAECAwQBAQEvCQEBAhABAgMBBgMCAwQBBIJkYwSIO581 X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208,217";a="762608" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 17 Jan 2012 18:57:06 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 17 Jan 2012 13:57:06 -0500 From: "Bhatia, Vikas" To: David Schwartz , "drinks@ietf.org" Date: Tue, 17 Jan 2012 13:57:05 -0500 Thread-Topic: Some comments/nits on latest SPProv doc Thread-Index: AczJa2/pFy87svXQSjeb8zv3ru1AbwLwjOKg Message-ID: References: <00DC9946-3629-43F1-BEAC-CBEEC5FC736C@xconnect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4254E341B54864B92D28BC2138A9DC3BBDB73TNSMAILNAwin2kcor_" MIME-Version: 1.0 Subject: Re: [drinks] Some comments/nits on latest SPProv doc X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:57:17 -0000 --_000_B4254E341B54864B92D28BC2138A9DC3BBDB73TNSMAILNAwin2kcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see comments inline. We should discuss some of these items in the ne= xt design team meeting. Thanks, Vikas From: David Schwartz [mailto:dschwartz@xconnect.net] Sent: Monday, January 02, 2012 11:28 AM To: Bhatia, Vikas Cc: drinks@ietf.org Subject: Re: Some comments/nits on latest SPProv doc Hi Vikas and thanks for responding. My comments are inline as well. I took = the liberty of removing all parts of the email on which I did not have comm= ents. 4.3 -> why isn't this a MUST? [VB:] My understanding on this is that this is more of a performance optimi= zation aspects for large datasets or constant small updates. Hence, it seem= s appropriate to be a SHOULD and not MUST. DS: Not sure I agree. There are use cases for both in the use case doc so I= still think it should be a MUST. [VB:] Yeah, both large datasets and constant small updates may occur via sp= pp. The use case for large sets (Non-real-time bulk provisioning) is listed= as an optional use case in the usecases document. W.r.t small constant upd= ates, for transport protocols that do not support long-lived connections, t= he implications are that such operations would have the associated cost of = less than optimal performance. Therefore I still think it is fine as a SHOU= LD. Let us discuss in the next design team meeting. Destination Groups 6.1 -> I think that DG should have priority field as well. This allows to d= ifferentiate based on a a parameter other than route (e.g. cost) [VB:] Can you please elaborate on this a bit more on what is the scenario? = I thought the "priority" attribute on the RG determines the route to be use= d in situations where same DG is associated with multiple RGs. DS: Sure. One of the things I argued for all along was the ability to prior= itize DGs. The current design has the priority field in the RG which is in = essence "passed onto" associated DG's. This assumes of course that the prim= e driver for prioritization is associated with routing information. I suppo= se the unfortunate use of the term "DestinationGroup" as opposed to a more = generic "IdentifierGroup" is at the root of this (due obviously to the prim= ary use for number lookups). What if I want to prioritize LUF data that is= associated only with a RantID and not necessarily with a route? Yes, I kno= w I can use the existing mechanism - my only question is why? Why not have = "priority" and "peering orgs" associated with the DG instead? What do you l= ose if you do it the way I propose? While on the topic I would also add tha= t peering org should probably be grouped as well into PeeringOrgGroup so th= at I can share with group and not have to enter each org multiple times. Ba= sically I am suggesting the following... RouteG | | V PeerG ----> DG (Priority) ^ | | PubID [VB:] How would we achieve LUF in this representation? We would have to add= an association between DG and RteRec in order to get the target domain for= the PIs in the DG. Imo, we achieve the same thing by having a RG that prov= ides linkage between one or many DGs and one or many RteRecs. Looking at th= e way it currently is (.i.e. RGs) it is better and more efficient since ma= ny DGs having the same LUF or LRF need not be associated to same RteRecs re= dundantly. The idea of PeeringOrgGroup has both pros and cons. You are righ= t, it may help in situations where there are many peering orgs to be associ= ated to RGs. But it will also require users to create PeeringOrgGroup when = they really have only one peering org to be associated. To me it seems more= like an implementation decision and I am not sure if this necessarily need= s to be built into the protocol. Page 40 - When DG removed - it says PIs removed -> not references by PIs (s= ee next comment about PIs) PIs Page 23 - why is a PI associated with only 1 DG? why not more? What if I ha= ve some TNRange and I want to have both "gold" and "silver" routes associat= ed with it - how would I do this without having this TNR referencing more t= han one DG? [VB:] A PIs association with its DG forms its primary key. There is a "prio= rity" attribute in the RG definition. For "gold" and "silver" routes, same = TNRange would be created in two DGs with one of the DG associated to the "= gold" route (with a higher priority) and other to the "silver" route (with = a lower priority value). DS: I see this differently. For the same reason you wouldn't delete an RG w= hen a DG is deleted I would not delete a PI when a DG is deleted. The PI an= d the RG do not owe their existence to a DG. The DG is just a way to associ= ate the two. In fact a PI may be reference multiple DGs just like an RG may= reference multiple DGs. If you want to speak of deleting PIs I would sugge= st a reference count mechanism which would make sure that PIs are deleted w= hen a DG that is the ONLY one being referred to by the PI is deleted. I kno= w this is not the way it is currently implemented - I just don't like the A= symmetry. [VB:] If I understand correctly, you are proposing to have the DGs to have = an 'association' type relationship to PIs instead of having the DG-PI prima= ry key. Again, imo, these is one of those things which was a design decisi= on that could have gone either way. Not sure if there were discussions arou= nd this in past. Seems what you are proposing would work as well. Page 24 -> isn't the idea of a RouteGroup to "group" route records"? Why th= en in the definition of a TN do we refer to an rrRef instead of an rgRef? T= he description does say "one or more" rrRefs which would imply to me that t= his could be a rgRef [VB:] Sorry, but two parts of this comment seem unrelated. Yes, the idea o= f RG is to associate a set of Pub Ids (DG) that share a common routing info= rmation, to the set of Route Records that form that routing information. T= N association to RG is via the DG. TN also refers to rrRef for situations w= here the routing information may be unique to a particular TN. We need to c= orrect the description however to say "zero or more" and not "one or more".= May be that caused the confusion. DS: I guess I never understood this use case anyway (unless we are talking = about an AOR identifier). Assuming a TN like it says - is it not possible t= o have a failover route for a single TN? Am I forced to create a DG for thi= s? Like I said - I don't get this use case. [VB:] Yeah, a single TN can be directly associated to a RteRec, without nee= ding to create a DG for that. I believe this is the user enum case. SourceID Page 30 - Why not simply a URI instead of enumeration as regex can deal wit= h parts of URI. We all know that in the end the source information will be = represented in the DNS request using a URI. [VB:] Source information match can be done via the IP where the request is = coming from (which may not be in the URI), root domain or the URI itself. I= n that sense having source identity scheme as one of "uri", "ipaddress", or= "rootDomain" seems valid. Can you elaborate further? Design Team? DS: I am fine with this. It was more of a comment that the "information" re= vealing who the "source" is will probably take the form of a URI [VB:] Ok. Page 38 - why isn't egrRte associated with RG? [VB:] It probably was just a design decision. Having egrRte associated with= a RG would mean that egrRte definition would also need to have an optional= "svcs" element to define the type of ENUM service(s) supported by the rout= e. For situations where many ingress routes share the same egress route, ri= ght now there will be an association between egress route object and all RR= s that are part of the RG. Design Team? DS: My point exactly - seems kind of inefficient. RGs represent logical ing= ress points while the RRs are the actual IPs. It stands to reason that an e= gress route will apply to all RRs in an RG. [VB:] RRs in a RG may be supporting different services (mms, sip etc), and= as such it is not necessary that an egress route applies to all RRs in the= RG. That is one advantage of a direct association between EgrRte and RR (s= ame EgrRte can be used for all associated RteRecs without worrying about th= e services those RteRecs are supporting). I am fine either way on this. ________________________________ 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_B4254E341B54864B92D28BC2138A9DC3BBDB73TNSMAILNAwin2kcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see comments inline. We should discuss some of these it= ems in the next design team meeting.

 

Thanks,

Vikas

 

From: David Sc= hwartz [mailto:dschwartz@xconnect.net]
Sent: Monday, January 02, 2012 11:28 AM
To: Bhatia, Vikas
Cc: drinks@ietf.org
Subject: Re: Some comments/nits on latest SPProv doc

 

Hi Vikas and thanks for responding. My comments are = inline as well. I took the liberty of removing all parts of the email on wh= ich I did not have comments.



 

4.3 -> why isn't this a MUST?

[VB:] My understanding on this is that this is more of a perfo= rmance optimization aspects for large datasets or constant small updates. H= ence, it seems appropriate to be a SHOULD and not MUST.

 

DS: Not sure I agree. There are use cases for both i= n the use case doc so I still think it should be a MUST.

 

[VB:] Yeah, both large datasets and constant small updates may occu= r via sppp. The use case for large sets (Non-real-time bulk provisioning) is= listed as an optional use case in the usecases document. W.r.t small const= ant updates, for transport protocols that do not support long-lived connect= ions, the implications are that such operations would have the associated cost of less than optimal perfor= mance. Therefore I still think it is fine as a SHOULD. Let us discuss in th= e next design team meeting.

 

 

Destination Groups

6.1 -> I think that DG should have prio= rity field as well. This allows to differentiate based on a a parameter oth= er than route (e.g. cost)

[VB:] Can you please elaborate on this a bit more on what is t= he scenario? I thought the “priority” attribute on the RG deter= mines the route to be used in situations where same DG is associated with multiple RGs.

 

DS: Sure. One of the things I argued for all along w= as the ability to prioritize DGs. The current design has the priority field= in the RG which is in essence "passed onto" associated DG's. Thi= s assumes of course that the prime driver for prioritization is associated with routing information. I suppose the unfor= tunate use of the term "DestinationGroup" as opposed to a more ge= neric "IdentifierGroup" is at the root of this (due obviously to = the primary use for number lookups).  What if I want to prioritize LUF data that is associated only with a RantID and not neces= sarily with a route? Yes, I know I can use the existing mechanism - my only= question is why? Why not have "priority" and "peering orgs&= quot; associated with the DG instead? What do you lose if you do it the way I propose? While on the topic I would also add that p= eering org should probably be grouped as well into PeeringOrgGroup so that = I can share with group and not have to enter each org multiple times. Basic= ally I am suggesting the following…

 

              &nb= sp;              RouteG

              &nb= sp;                     |=

              &nb= sp;                     |=

              &nb= sp;                    V<= o:p>

 

         PeerG ----> &nb= sp;   DG (Priority)

            =

              &nb= sp;                     ^=

              &nb= sp;                     |=

              &nb= sp;                     |=

              &nb= sp;               PubID

 

[VB:] How would we achieve LUF in this representation? We would hav= e to add an association between DG and RteRec in order to get the target dom= ain for the PIs in the DG. Imo, we achieve the same thing by having a RG th= at provides linkage between one or many DGs and one or many RteRecs. Lookin= g at the way it currently is (.i.e.  RGs) it is better and more efficient since many DGs having the same = LUF or LRF need not be associated to same RteRecs redundantly. The idea of = PeeringOrgGroup has both pros and cons. You are right, it may help in situa= tions where there are many peering orgs to be associated to RGs. But it will also require users to create PeeringO= rgGroup when they really have only one peering org to be associated. To me = it seems more like an implementation decision and I am not sure if this nec= essarily needs to be built into the protocol.

 

Page 40 - When DG removed - it says PIs re= moved -> not references by PIs (see next comment about PIs)<= /o:p>

 

PIs

Page 23 - why is a PI associated with only= 1 DG? why not more? What if I have some TNRange and I want to have both &q= uot;gold" and "silver" routes associated with it - how would I do this without having this TNR referencing more than one DG?

[VB:] A PIs association with its DG forms its primary key. The= re is a “priority” attribute in the RG definition. For “g= old” and “silver” routes, same TNRange would be  created in two DGs with one of the DG associated to the = 220;gold” route (with a higher priority) and other to the “silv= er” route (with a lower priority value).

 

DS: I see this differently. For the same reason you = wouldn't delete an RG when a DG is deleted I would not delete a PI when a D= G is deleted. The PI and the RG do not owe their existence to a DG. The DG = is just a way to associate the two. In fact a PI may be reference multiple DGs just like an RG may reference m= ultiple DGs. If you want to speak of deleting PIs I would suggest a referen= ce count mechanism which would make sure that PIs are deleted when a DG tha= t is the ONLY one being referred to by the PI is deleted. I know this is not the way it is currently implem= ented - I just don't like the Asymmetry.

 

[VB:] If I understand correctly, you are proposing to have the DGs to have an ‘association’ type relationship to PIs instead of h= aving the DG-PI primary key.  Again, imo, these is one of those things= which was a design decision that could have gone either way. Not sure if t= here were discussions around this in past. Seems what you are proposing would work as well.



 

Page 24 -> isn't the idea of a RouteGro= up to "group" route records"? Why then in the definition of = a TN do we refer to an rrRef instead of an rgRef? The description does say "one or more" rrRefs which would imply to me that this could be = a rgRef

[VB:] Sorry, but two parts of this comment seem unrelated.&nbs= p; Yes, the idea of RG is to associate a set of Pub Ids (DG) that share a c= ommon routing information, to the set of Route Records that form that routing information.  TN a= ssociation to RG is via the DG. TN also refers to rrRef for situations wher= e the routing information may be unique to a particular TN. We need to corr= ect the description however to say “zero or more” and not “one or more”. May be that caused the c= onfusion.

 

DS: I guess I never understood this use case anyway = (unless we are talking about an AOR identifier). Assuming a TN like it says= - is it not possible to have a failover route for a single TN? Am I forced= to create a DG for this? Like I said - I don't get this use case.=

 

[VB:] Yeah, a single TN can be directly associated to a RteRec, wit= hout needing to create a DG for that. I believe this is the user enum case.



 

SourceID

Page 30 - Why not simply a URI instead of = enumeration as regex can deal with parts of URI. We all know that in the en= d the source information will be represented in the DNS request using a URI.

[VB:] Source information match can be done via the IP where th= e request is coming from (which may not be in the URI), root domain or the = URI itself. In that sense having source identity scheme as one of “uri”, “ipaddres= s”, or “rootDomain” seems valid. Can you elaborate furthe= r? Design Team?

 

DS: I am fine with this. It was more of a comment th= at the "information" revealing who the "source" is will= probably take the form of a URI

 

[VB:] Ok.



 

Page 38 - why isn't egrRte associated with= RG?

[VB:] It probably was just a design decision. Having egrRte as= sociated with a RG would mean that egrRte definition would also need to hav= e an optional “svcs” element to define the type of ENUM service(s) supported by the route. For = situations where many ingress routes share the same egress route, right now= there will be an association between egress route object and all RRs  = ;that are part of the RG. Design Team?

 

DS: My point exactly - seems kind of inefficient. RG= s represent logical ingress points while the RRs are the actual IPs. It sta= nds to reason that an egress route will apply to all RRs in an RG.

 

[VB:]  RRs in a RG may be supporting different services (mms, = sip etc), and as such it is not necessary that an egress route applies to all = RRs in the RG. That is one advantage of a direct association between EgrRte= and RR (same EgrRte can be used for all associated RteRecs without worryin= g about the services those RteRecs are supporting).  I am fine either way on this.

 


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_B4254E341B54864B92D28BC2138A9DC3BBDB73TNSMAILNAwin2kcor_-- From alexander.mayrhofer@nic.at Wed Jan 18 06:58:29 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3559A21F8642 for ; Wed, 18 Jan 2012 06:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.275 X-Spam-Level: X-Spam-Status: No, score=-9.275 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0ir40yjtnlS for ; Wed, 18 Jan 2012 06:58:28 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id DA33621F863F for ; Wed, 18 Jan 2012 06:58:27 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Wed, 18 Jan 2012 15:58:26 +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.1.355.2; Wed, 18 Jan 2012 15:58:21 +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: Wed, 18 Jan 2012 15:58:19 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B551F4A@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internationalization - proposed text Thread-Index: AczV7DWM20q7Mcy4T5yOJZiR5LQ5Iw== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] Internationalization - proposed text X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:58:29 -0000 We had a thread on internationalization issues a few weeks ago, and i've finally found time to draft some text. The basic assumptions are in this message: http://www.ietf.org/mail-archive/web/drinks/current/msg01070.html Regarding case sensitivity, we later agreed that we wanted identifiers to be case insensitive. We also talked about two different "classes" of elements, and agreed that "non-identifiers" would simply be considered "blobs" in eg. comparison operations. The more important class of elements would of course be "identifiers" (elements used to address objects, or to establish links between objects). Looking at our data model and identifier definitions, those would be:=20 rant rar dgName rrName rgName egrRteName Which, in turn, are based on either the "OrgIdType" or "ObjNameType". Therefore, in order to get proper normalization/comparison/i18n rules into our definitions, i would propose the following text (draft!): ----- snip ---- Internationalization ------------------------ The protocol contains two types of elements. The first type, called "blobs" for the purpose of this document, contains data that is moved by means of that protocol, but is neither used to identifier objects, or to refer between objects. The other type is called "identifier", and is either used to address an object, or to refer between objects. The following elements are "Identifiers": * rant * rar * dgName * rrName * rgName * egrRteName All other elements contained in the protocol fall under the "blobs" category. For "identifiers", the following rules apply: * Identifiers are case insensitive, and MUST use Unicode Normalization Form C (NFC) in comparison and mapping operations ..* Characters allowed in Identifierst MUST consist of Characters exclusively from those character classes: TODO * The Registry MUST store such identifiers in their lower case mapping, and MUST correctly map upper case representations of that identifier to their lower case equivalent in comparison operations. ..* Clients SHOULD lowercase such identifiers before sending them to the Registry If "blob" type elements are ever to be compared, byte-wise comparison MUST be used. ----- end of proposed text ---- Is this a basis to work from? I haven't yet identified the right "position" for this text to be added - any suggestions? Alex From alexander.mayrhofer@nic.at Tue Jan 24 04:30:17 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59FB21F8565 for ; Tue, 24 Jan 2012 04:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.297 X-Spam-Level: X-Spam-Status: No, score=-9.297 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVfMB21ZN8Ic for ; Tue, 24 Jan 2012 04:30:13 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id BE61821F8542 for ; Tue, 24 Jan 2012 04:30:11 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Tue, 24 Jan 2012 13:30:10 +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.1.355.2; Tue, 24 Jan 2012 13:30:07 +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: Tue, 24 Jan 2012 13:30:05 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B552554@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes of the DRINKS design team call Jan 18th 2012 Thread-Index: AczakMrVr2X0Q6PgROCv6OqPDp0gAw== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Cc: drinks-chairs@tools.ietf.org Subject: [drinks] Minutes of the DRINKS design team call Jan 18th 2012 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 12:30:17 -0000 Here are the minutes of last week's Design Team Call - sorry for the delay: DRINKS Design Team Call =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan 18th 2012, 10:00a - 11:10a Eastern Time Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D - Manjul Maharishi - Ken Cartwright - Dean Willis - Sumanth Channabasappa - Vikas Bhatia - David Schwartz - Alexander Mayrhofer Action Items Update =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - [Design Team] continue review of comments=20 - [Alex] Change proposed Internationalization text to reflect Ken's points - [WG Chairs] Modify the WG timelines - [WG Chairs] Find external reviewers for Security / WSDL/XSD - [Design Team] Nomenclature for drafts - still open? - [David] Provide WSDL update for inclusion of PeeringGroup, so that others can review and decide - [WG Chairs] Create agenda for the interim meeting Agenda =3D=3D=3D=3D=3D=3D=3D - Discuss progress so far (refer to mailing list emails) and next steps - Plan for the interim meeting (and are there any issues with the interim date?) Document Updates ------------------------ The use cases document was published as RFC6461 - thanks to Sumanth for addressing the AUTH48 stuff, and the AD comments! Internationalization ------------------------ Alex has sent some text about internationalization to the mailing list, however it was felt that the proposed text is more about comparison of identifiers. Ken comments that he sees 3 aspects in i18n that we need to cover: - Encoding: Recommend UTF-8 (require it, even?) - Language identification of human readable messages (see RFC 4646, and the EPP RFCs for examples) - Time Zones (Group strongly indicated preference to simply use UTC) The original text by Alex was still considered valuable, but text for the 3 aspects above is needed. Alex will create text, and post to the list. Draft reviewal updates ---------------------------- Vikas' response to David's email is discussed, particularly there's a lively discussion around the topic of a potential relation between a public identifier and a route group. It would probably also affect the already published use cases document, because it would require a new use case?=20 David also would love to see something like a "Peering group", and will propose respective text to the mailing list (Will create an updated WSDL that the design team will subsequently review). Interim Meeting -------------------- Sumanth asked whether anyone would have a problem with the limited RTCWEB overlap, and no one had objections. Also, no responses have been received to the mail Alex sent to the mailing list, so it is assumed that the overlap is not a problem. The meeting will be held as originally scheduled, no change. Dean couldn't respond, because he had to leave the call. Ken asked about the goal of the interim. Sumanth explained that it was a checkpoint to address the comments we have received thus far (by the deadline last week), to note down the open items, and to discuss and prioritize the open items so that we can prepare a plan to complete this work asap. If not, we may defer the work so much that we will miss it. Vikas asked about expectations in preparation for the interim. Sumaht told him that he should plan on addressing comments received by the deadline, and anything else he can. Based on the action items from today, the WG chairs can come up with the list of final items before the interim. Vikas offered to help with the list, if need be (WG Chairs will check with him offline).=20 Document nomenclature ------------------------------ Sumanth volunteered WG Chairs to finalize the document names, clear Vikas as an author, and work with Vikas to incorporate the changes. Sumanth asked him to contact the chairs prior to any formal document updates. Next call ---------- Wed, Jan 25 2012, 10:00a - 11:00a ET From richard@shockey.us Tue Jan 24 14:30:04 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EE111E8085 for ; Tue, 24 Jan 2012 14:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.064 X-Spam-Level: X-Spam-Status: No, score=-100.064 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXth-FF2Rgpb for ; Tue, 24 Jan 2012 14:30:04 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 3CE6C11E8079 for ; Tue, 24 Jan 2012 14:30:04 -0800 (PST) Received: (qmail 8579 invoked by uid 0); 24 Jan 2012 22:30:03 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 24 Jan 2012 22:30:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=vUrADjt3xDjjqk8F/W8ACjp92y6wSE2aBXI/CxAlXpA=; b=bg1no65jHCSbfG1M9fH6+jvdZawzR/Q6x+9T3lAlNjOkekfDhnZDkiPklc/qJw5IGqpLgoCz7y/0I3yWL1sqcns0lFvFTz4/y7rEVgWyUo/ynXK9hZAvkMReqtnorbOe; Received: from [173.66.41.162] (helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RposL-0005kJ-Mm; Tue, 24 Jan 2012 15:30:01 -0700 From: "Richard Shockey" To: "'Alexander Mayrhofer'" , References: <8BC845943058D844ABFC73D2220D46650B552554@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650B552554@nics-mail.sbg.nic.at> Date: Tue, 24 Jan 2012 17:30:00 -0500 Message-ID: <015d01ccdae7$b64668f0$22d33ad0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczakMrVr2X0Q6PgROCv6OqPDp0gAwAVrPkg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.41.162 authed with richard@shockey.us} Cc: drinks-chairs@tools.ietf.org Subject: Re: [drinks] Minutes of the DRINKS design team call Jan 18th 2012 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 22:30:05 -0000 Hey guys ..you have some new customers! http://www.crtc.gc.ca/eng/com100/2012/r120119.htm See Paragraph 69-70 -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Alexander Mayrhofer Sent: Tuesday, January 24, 2012 7:30 AM To: drinks@ietf.org Cc: drinks-chairs@tools.ietf.org Subject: [drinks] Minutes of the DRINKS design team call Jan 18th 2012 Here are the minutes of last week's Design Team Call - sorry for the delay: DRINKS Design Team Call =================== Jan 18th 2012, 10:00a - 11:10a Eastern Time Participants ========= - Manjul Maharishi - Ken Cartwright - Dean Willis - Sumanth Channabasappa - Vikas Bhatia - David Schwartz - Alexander Mayrhofer Action Items Update ================ - [Design Team] continue review of comments - [Alex] Change proposed Internationalization text to reflect Ken's points - [WG Chairs] Modify the WG timelines - [WG Chairs] Find external reviewers for Security / WSDL/XSD - [Design Team] Nomenclature for drafts - still open? - [David] Provide WSDL update for inclusion of PeeringGroup, so that others can review and decide - [WG Chairs] Create agenda for the interim meeting Agenda ======= - Discuss progress so far (refer to mailing list emails) and next steps - Plan for the interim meeting (and are there any issues with the interim date?) Document Updates ------------------------ The use cases document was published as RFC6461 - thanks to Sumanth for addressing the AUTH48 stuff, and the AD comments! Internationalization ------------------------ Alex has sent some text about internationalization to the mailing list, however it was felt that the proposed text is more about comparison of identifiers. Ken comments that he sees 3 aspects in i18n that we need to cover: - Encoding: Recommend UTF-8 (require it, even?) - Language identification of human readable messages (see RFC 4646, and the EPP RFCs for examples) - Time Zones (Group strongly indicated preference to simply use UTC) The original text by Alex was still considered valuable, but text for the 3 aspects above is needed. Alex will create text, and post to the list. Draft reviewal updates ---------------------------- Vikas' response to David's email is discussed, particularly there's a lively discussion around the topic of a potential relation between a public identifier and a route group. It would probably also affect the already published use cases document, because it would require a new use case? David also would love to see something like a "Peering group", and will propose respective text to the mailing list (Will create an updated WSDL that the design team will subsequently review). Interim Meeting -------------------- Sumanth asked whether anyone would have a problem with the limited RTCWEB overlap, and no one had objections. Also, no responses have been received to the mail Alex sent to the mailing list, so it is assumed that the overlap is not a problem. The meeting will be held as originally scheduled, no change. Dean couldn't respond, because he had to leave the call. Ken asked about the goal of the interim. Sumanth explained that it was a checkpoint to address the comments we have received thus far (by the deadline last week), to note down the open items, and to discuss and prioritize the open items so that we can prepare a plan to complete this work asap. If not, we may defer the work so much that we will miss it. Vikas asked about expectations in preparation for the interim. Sumaht told him that he should plan on addressing comments received by the deadline, and anything else he can. Based on the action items from today, the WG chairs can come up with the list of final items before the interim. Vikas offered to help with the list, if need be (WG Chairs will check with him offline). Document nomenclature ------------------------------ Sumanth volunteered WG Chairs to finalize the document names, clear Vikas as an author, and work with Vikas to incorporate the changes. Sumanth asked him to contact the chairs prior to any formal document updates. Next call ---------- Wed, Jan 25 2012, 10:00a - 11:00a ET _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From alexander.mayrhofer@nic.at Wed Jan 25 06:35:50 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4921F86D6 for ; Wed, 25 Jan 2012 06:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.314 X-Spam-Level: X-Spam-Status: No, score=-9.314 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th+pQIMp2TIg for ; Wed, 25 Jan 2012 06:35:49 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1043F21F86D3 for ; Wed, 25 Jan 2012 06:35:49 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Wed, 25 Jan 2012 15:35:47 +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.1.355.2; Wed, 25 Jan 2012 15:35:41 +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: Wed, 25 Jan 2012 15:35:39 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B552749@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internationalization & Comparison, 2nd try Thread-Index: Aczbbpc43MaUKTfBSKONByZXYVeIkA== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] Internationalization & Comparison, 2nd try X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 14:35:50 -0000 Based on the discussions during last week's Design Team call, i have drafted a new revision of the "Internationalization" Text - see below. I still haven't found a proper headline for the "comparison & case sensititivity" section, suggestions welcome. Thanks to Ken for the valuable comments on my initial text - very useful. Generally, comments on the text are very much appreciated. -- snip -- X. Internationalization ------------------------ X.1. Character Encoding ---------------------------- If elements contain non-ASCII characters, the UTF-8 [RFC3629] character encoding MUST be used. If the transport protocol allows for explicit declaration of the character encoding used, clients and servers SHOULD explicitely declare the content to be UTF-8, but MAY in turn assume that content that is received without such declaration is using UTF-8. X.2. Language identification --------------------------------- Where messages in human-readable languages are used in the protocol, those messages SHOULD be tagged according to RFC 4646, and the transport protocol MUST support a respective mechanism to transmit such tags together with those human readable messages. If absent, the language of the message defaults to "en" (English). X.3. Time zones ------------------- Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The actual date/time format=20 used MUST be specified by the respective transport protocol. Y. Comparison Operations ----------------------------- The protocol contains two types of elements. The first type, called "blobs" for the purpose of this document, contains data that is moved by means of that protocol, but is neither used to identifier objects, or to refer between objects. The other type is called "identifier", and is either used to address an object, or to refer between objects. The following elements are "Identifiers": * rant * rar * dgName * rrName * rgName * egrRteName All other elements contained in the protocol fall under the "blobs" category. For "identifiers", the following rules apply: * Identifiers are case insensitive, and MUST use Unicode Normalization Form C (NFC) in comparison and mapping operations ..* Characters allowed in Identifierst MUST consist of Characters exclusively from those character classes: TODO * The Registry MUST store such identifiers in their lower case mapping, and MUST correctly map upper case representations of that identifier to their lower case equivalent in comparison operations. ..* Clients SHOULD lowercase such identifiers before sending them to the Registry If "blob" type elements are ever to be compared, byte-wise comparison MUST be used. From shollenbeck@verisign.com Wed Jan 25 07:08:58 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB56421F8608 for ; Wed, 25 Jan 2012 07:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVOeedDDnenU for ; Wed, 25 Jan 2012 07:08:58 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id ED56021F85F3 for ; Wed, 25 Jan 2012 07:08:57 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKTyAbBY6xhE1TSqtqx0nkGFi3mWkqdvmT@postini.com; Wed, 25 Jan 2012 07:08:58 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0PF8rTI031381; Wed, 25 Jan 2012 10:08:53 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jan 2012 10:08:53 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 25 Jan 2012 10:08:52 -0500 From: "Hollenbeck, Scott" To: Alexander Mayrhofer , "drinks@ietf.org" Thread-Topic: Internationalization & Comparison, 2nd try Thread-Index: Aczbbpc43MaUKTfBSKONByZXYVeIkAAA4n0g Date: Wed, 25 Jan 2012 15:08:51 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D591A3B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <8BC845943058D844ABFC73D2220D46650B552749@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650B552749@nics-mail.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jan 2012 15:08:53.0616 (UTC) FILETIME=[4076EF00:01CCDB73] Subject: Re: [drinks] Internationalization & Comparison, 2nd try X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 15:08:59 -0000 > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of Alexander Mayrhofer > Sent: Wednesday, January 25, 2012 9:36 AM > To: drinks@ietf.org > Subject: [drinks] Internationalization & Comparison, 2nd try >=20 > Based on the discussions during last week's Design Team call, i have > drafted a new revision of the "Internationalization" Text - see below. > I > still haven't found a proper headline for the "comparison & case > sensititivity" section, suggestions welcome. >=20 > Thanks to Ken for the valuable comments on my initial text - very > useful. >=20 > Generally, comments on the text are very much appreciated. >=20 > -- snip -- >=20 > X. Internationalization > ------------------------ >=20 > X.1. Character Encoding > ---------------------------- >=20 > If elements contain non-ASCII characters, the UTF-8 [RFC3629] character > encoding MUST be used. If the transport protocol allows for explicit > declaration of the character encoding used, clients and servers SHOULD > explicitely declare the content to be UTF-8, but MAY in turn assume > that > content that is received without such declaration is using UTF-8. >=20 > X.2. Language identification > --------------------------------- >=20 > Where messages in human-readable languages are used in the protocol, > those messages SHOULD be tagged according to RFC 4646, and the > transport > protocol MUST support a respective mechanism to transmit such tags > together with those human readable messages. If absent, the language of > the message defaults to "en" (English). RFC 4646 has been obsolete by RFC 5646. 5646 would be the better reference. > X.3. Time zones > ------------------- >=20 > Date and time attribute values MUST be represented in Universal > Coordinated Time (UTC) using the Gregorian calendar. The actual > date/time format > used MUST be specified by the respective transport protocol. A suggested change using text from verified RFC 5730 errata: use 'Coordinat= ed Universal Time (UTC)' This is the rationale shared with the report: "Rationale: Use of established, official terminology. Note: There are other variants of "Universal Time" (mostly of historical in= terest now), and hence, the term initially had been written as "Universal T= ime, Coordinated", giving rise to the acronym "UTC" that parallels the prec= ursor "UT1"." Scott From sumanth@cablelabs.com Wed Jan 25 08:33:39 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D123621F857F for ; Wed, 25 Jan 2012 08:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+qEulbKfBQw for ; Wed, 25 Jan 2012 08:33:39 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCBE21F8574 for ; Wed, 25 Jan 2012 08:33:39 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0PGXKIt004758 for ; Wed, 25 Jan 2012 09:33:37 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 25 Jan 2012 09:33:20 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 25 Jan 2012 09:33:28 -0700 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Wed, 25 Jan 2012 09:33:26 -0700 Thread-Topic: Draft minutes from the DRINKS design team call (1/25) Thread-Index: AczbfvgZXNwPbhhtQ4uzC6w2H27jWA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DF4FC35F@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] Draft minutes from the DRINKS design team call (1/25) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 16:33:39 -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 1/25/2012, 10:00a-10:45a (Eastern)/8:00a-8:45a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Alexander Mayrhofer - Manjul Maharishi - Ken Cartwright - Dean Willis - Sumanth Channabasappa=20 Apologies: - Vikas Bhatia - David Schwartz ACTION ITEMS UPDATE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - [Design Team] Continue to review and post comments on the mailing list - [Alex] Follow-up on comments around the proposed text for Internationaliz= ation=20 - [David] Provide WSDL update for inclusion of PeeringGroup, so that others= can review and decide - [WG Chairs] Modify the WG timelines - [WG Chairs] Find external reviewers for Security / WSDL/XSD AGENDA =3D=3D=3D=3D=3D=3D 1. Continue to address comments around the I-Ds 2. Plan for the interim meeting NOTES =3D=3D=3D=3D=3D 0. Action Items Update - [Alex] Change proposed Internationalization text to reflect Ken's points > Alex presented a revised proposal on 1/25 - [WG Chairs] Modify the WG timelines > Alex and Sumanth discussed this offline and will propose April, 2012 f= or completion - [WG Chairs] Find external reviewers for Security / WSDL/XSD > WG Chairs are following up on this - [Design Team] Nomenclature for drafts - still open? > The suggestion is to stick to what was discussed at the last IETF "SPP Framework" and "SPP Protocol over SOAP" - [David] Provide WSDL update for inclusion of PeeringGroup, so that others= can review and decide > David plans to follow-up on this soon =20 - [WG Chairs] Create agenda for the interim meeting > Alex and Sumanth proposed the following: - Group review of the two open documents - Discussion around open items - Discuss and finalize open items that are considered in-scope and out= -of-scope (for completion of the I-Ds) 1. Continue to address comments around the I-Ds - The primary topic of discussion was internationalization - See email from Alex on 1/25 for the revised proposal > There was general agreement on the direction being proposed, and tha= t we should choose case-insensitive identifiers - We do, however, need to clarify what this affects and how (e.g., s= torage v/s representation); and perhaps follow-up further > There was some confusion on what the language-specific requirements = are: is it being negotiated, or indicated? - (Ken) recommended that we disallow changes mid-session - (Alex) indicated that we should probably clean-up the requirements= around this > There was general agreement that we should use UTC 2. Plan for the interim meeting - Interim is next week, from 9a-1p (EST)/2p-6p(UTC) - No objections again to the slight overlap with RTCWEB - WG Chairs will work with Vikas to have an update this week From sumanth@cablelabs.com Wed Jan 25 09:04:45 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7853121F85FF for ; Wed, 25 Jan 2012 09:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GXSuEtDnKMQ for ; Wed, 25 Jan 2012 09:04:44 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 16EDC21F8596 for ; Wed, 25 Jan 2012 09:04:41 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0PH4aFJ008644 for ; Wed, 25 Jan 2012 10:04:37 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 25 Jan 2012 10:04:36 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 25 Jan 2012 09:46:48 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Wed, 25 Jan 2012 09:46:47 -0700 Thread-Topic: DRINKS Interim Meeting - Details Thread-Index: Aczbf1FuJ0kU3V0ATOCWkMCzXiSL/Q== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DF4FC360@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_76AC5FEF83F1E64491446437EA81A61F81DF4FC360srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] DRINKS Interim Meeting - Details X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 17:04:45 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC360srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, As you are aware, the IETF DRINKS Interim meeting is next week (Feb 1, 2012= ). There is a partial overlap with the RTCWEB interim meeting, but we (the = chairs) haven't heard any objection from the WG participants or the design = team. Thus, there are no changes. Here are the details. Date & Time Feb 1, 2012 (Wednesday); 2p-6p UTC/9a-1p Eastern Call-in Information - Dial +1 (213) 493-0602 - Access Code: 905-408-840 - GoToMeeting: https://www1.gotomeeting.com/join/905408840 Overview - This interim will be focused on making progress on the current o= pen I-Ds with the proposed titles of 'SPP Framework' and 'SPP Protocol over= SOAP' o http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/ o http://tools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/ Note: The authors are planning an update this week, to address comments rec= eived by the requested deadline (1/13); please continue to provide comments= , if any. - The goal is to resolve currently known open issues, to identify = topics that need to be resolve prior to completion, and establish a plan fo= r the next steps Proposed, Draft, Agenda - Welcome and administrivia, note well - Agenda bashing - Group review of the two open I-Ds - Open items discussion - Discuss and finalize open items that are considered in-scope and= out-of-scope (for completion of the I-Ds) - Establish plan for completion prior to Paris - Open Mic --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC360srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

As you = are aware, the IETF DRINKS Interim meeting is next week (Feb 1, 2012). Ther= e is a partial overlap with the RTCWEB interim meeting, but we (the chairs)= haven’t heard any objection from the WG participants or the design t= eam. Thus, there are no changes.

&= nbsp;

Here are the details.

 

Date & T= ime

Feb 1, 2012 (Wednesday); 2p-6p U= TC/9a-1p Eastern

 

Ca= ll-in Information

-          Dial +1 (213) 493-0602

-        =   Access Code: 905-408-840

 

-     &nb= sp;    GoToMeeting: https://www1.gotomeeting.com/join/9= 05408840

 

 

Overview<= /o:p>

-     &n= bsp;    This interim will be focused= on making progress on the current open I-Ds with the proposed titles of &#= 8216;SPP Framework’ and ‘SPP Protocol over SOAP’

o   http://tools.ie= tf.org/wg/drinks/draft-ietf-drinks-spprov/

o   http://tools.ietf.org/wg/dr= inks/draft-ietf-drinks-sppp-over-soap/

Note: The authors are planning an update= this week, to address comments received by the requested deadline (1/13); = please continue to provide comments, if any.

 

-        =   The goal is to resolve currently known open = issues, to identify topics that need to be resolve prior to completion, and= establish a plan for the next steps

 

Proposed, Draft, Agenda

-      =     Welcome and administrivia, note = well

-    &n= bsp;     Agenda bashing

-      &n= bsp;   Group review of the two open I-Ds<= o:p>

-<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;    Open items discussion<= /o:p>

-      =     Discuss and finalize open items = that are considered in-scope and out-of-scope (for completion of the I-Ds)<= o:p>

-<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;    Establish plan for completi= on prior to Paris

-  &= nbsp;       Open Mic<= o:p>

 

 

= --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC360srvxchg_-- From yoshiro.yoneya@jprs.co.jp Wed Jan 25 18:19:34 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5367A21F8567; Wed, 25 Jan 2012 18:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3Q7td4gScbq; Wed, 25 Jan 2012 18:19:33 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 41C4721F8566; Wed, 25 Jan 2012 18:19:33 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q0Q2JWRO002365; Thu, 26 Jan 2012 11:19:32 +0900 X-AuditID: ac120820-b7f826d000006983-08-4f20b83452b9 Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 26.96.27011.438B02F4; Thu, 26 Jan 2012 11:19:32 +0900 (JST) Date: Thu, 26 Jan 2012 11:19:31 +0900 From: Yoshiro YONEYA To: Message-Id: <20120126111931.b9ed97df.yoshiro.yoneya@jprs.co.jp> In-Reply-To: <8BC845943058D844ABFC73D2220D46650B552749@nics-mail.sbg.nic.at> References: <8BC845943058D844ABFC73D2220D46650B552749@nics-mail.sbg.nic.at> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsWyRoiFT9dkh4K/wZJ3zBYd71axWuz6/ofV gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZEzbmFMyXrrh/o5WtgbFdrIuRk0NCwETi8/z3bBC2 mMSFe+vBbCGB44wSby/UgNgsAqoS307sYwSx2QQMJH4t+80EYosIiEqs/riKFcRmFhCWuPOk C6xGWMBcYurmTrA5vAL2Ei3HIXo5BXwkGm50QM33luidOwsozgG010Ji6zpLEJNXQFDi7w5h iIlaEg9/3WKBsOUltr+dwzyBkX8WQtUsJFWzkFQtYGRexSiTn5amW5yal1Kcm25gqFdSma+X VVBUrJcMojcxggOPQ2EH44xTBocYBTgYlXh4FZwV/IVYE8uKK3MPMUpyMCmJ8m7YChTiS8pP qcxILM6ILyrNSS0+xCjBwawkwitmD5TjTUmsrEotyodJSXOwKInzHj+7w09IID2xJDU7NbUg tQgmK8PBoSTBq7sdqFGwKDU9tSItM6cEIc3EwQkynAdoeChIDW9xQWJucWY6RP4Uo6SUOK8y SEIAJJFRmgfX+4pRHOgFYV5bkCwPMInAdb0CGsgENHCprjzIwJJEhJRUA+PmF59UjqT/8l+9 MUPx5AkbjZK4HP2vVRXT5qp/7V2uOdNZXuvhlr8Jua/Vkjw0Jigai0ryOiY8Wm4Qy51rXvdy Q0jyoe9S7nJ3dPaLlr62jqxeb/V6z09dV/Hrs2R+q+Rt81T/MMn6QO6fdUu/26xiNbrHouGl tSk+feEEV+65lRbuf7zP7VFiKc5INNRiLipOBAB5FFk93wIAAA== Cc: precis@ietf.org Subject: Re: [drinks] Internationalization & Comparison, 2nd try X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 02:19:34 -0000 Hi, IETF precis WG (CC'ed) is discussing comparison of internationalized strings. Would you please see if precis framework (work on progress) is applicable? Regards, -- Yoshiro YONEYA On Wed, 25 Jan 2012 15:35:39 +0100 Alexander Mayrhofer wrote: > Based on the discussions during last week's Design Team call, i have > drafted a new revision of the "Internationalization" Text - see below. I > still haven't found a proper headline for the "comparison & case > sensititivity" section, suggestions welcome. > > Thanks to Ken for the valuable comments on my initial text - very > useful. > > Generally, comments on the text are very much appreciated. > > -- snip -- > > X. Internationalization > ------------------------ > > X.1. Character Encoding > ---------------------------- > > If elements contain non-ASCII characters, the UTF-8 [RFC3629] character > encoding MUST be used. If the transport protocol allows for explicit > declaration of the character encoding used, clients and servers SHOULD > explicitely declare the content to be UTF-8, but MAY in turn assume that > content that is received without such declaration is using UTF-8. > > X.2. Language identification > --------------------------------- > > Where messages in human-readable languages are used in the protocol, > those messages SHOULD be tagged according to RFC 4646, and the transport > protocol MUST support a respective mechanism to transmit such tags > together with those human readable messages. If absent, the language of > the message defaults to "en" (English). > > X.3. Time zones > ------------------- > > Date and time attribute values MUST be represented in Universal > Coordinated Time (UTC) using the Gregorian calendar. The actual > date/time format > used MUST be specified by the respective transport protocol. > > Y. Comparison Operations > ----------------------------- > > The protocol contains two types of elements. The first type, called > "blobs" for the purpose of this document, contains data that is moved by > means of that protocol, but is neither used to identifier objects, or to > refer between objects. The other type is called "identifier", and is > either used to address an object, or to refer between objects. > > The following elements are "Identifiers": > > * rant > * rar > * dgName > * rrName > * rgName > * egrRteName > > All other elements contained in the protocol fall under the "blobs" > category. For "identifiers", the following rules apply: > > * Identifiers are case insensitive, and MUST use Unicode Normalization > Form C (NFC) in comparison and mapping operations > ..* Characters allowed in Identifierst MUST consist of Characters > exclusively from those character classes: TODO > * The Registry MUST store such identifiers in their lower case > mapping, and MUST correctly map upper case representations of that > identifier to their lower case equivalent in comparison operations. > ..* Clients SHOULD lowercase such identifiers before sending them to the > Registry > > If "blob" type elements are ever to be compared, byte-wise comparison > MUST be used. > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks > > From internet-drafts@ietf.org Mon Jan 30 14:35:57 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D6E11E80C1; Mon, 30 Jan 2012 14:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxXA3oNIRGz6; Mon, 30 Jan 2012 14:35:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AFB21F8652; Mon, 30 Jan 2012 14:35:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120130223556.28670.26047.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 14:35:56 -0800 Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spp-protocol-over-soap-00.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:35:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : Session Peering Provisioning (SPP) Protocol over SOAP Author(s) : Kenneth Cartwright Vikas Bhatia Filename : draft-ietf-drinks-spp-protocol-over-soap-00.txt Pages : 87 Date : 2012-01-30 The Session Peering Provisioning Framework (SPPF) is an XML framework that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport protocol for SPPF is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPF XML structures over SOAP and HTTP(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spp-protocol-over-soa= p-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-spp-protocol-over-soap= -00.txt From internet-drafts@ietf.org Mon Jan 30 14:36:23 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6779A11E80C8; Mon, 30 Jan 2012 14:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUNY0XEVOcXn; Mon, 30 Jan 2012 14:36:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA26211E80C6; Mon, 30 Jan 2012 14:36:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120130223621.28965.41955.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2012 14:36:21 -0800 Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spp-framework-00.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:36:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : Session Peering Provisioning Framework (SPPF) Author(s) : Kenneth Cartwright Syed Wasim Ali Alexander Mayrhofer Vikas Bhatia Filename : draft-ietf-drinks-spp-framework-00.txt Pages : 59 Date : 2012-01-30 This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session peering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spp-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-spp-framework-00.txt From vbhatia@tnsi.com Mon Jan 30 17:15:14 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F8021F8621 for ; Mon, 30 Jan 2012 17:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mveTpcxR7ugr for ; Mon, 30 Jan 2012 17:15:14 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB0B21F85CD for ; Mon, 30 Jan 2012 17:15:06 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAIo/J0+sEQfn/2dsb2JhbABDr1yBcgEBAQQBAQE3NBcGAQgRBAEBCxQJLgsUBwEBBQQBBBMIAYd8uQSKbggCAQUKCREFAodqYwSIP59K X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="808021" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 31 Jan 2012 01:15:05 +0000 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, 30 Jan 2012 20:15:05 -0500 From: "Bhatia, Vikas" To: "drinks@ietf.org" Date: Mon, 30 Jan 2012 20:15:04 -0500 Thread-Topic: [drinks] I-D Action: draft-ietf-drinks-spp-framework-00.txt Thread-Index: Aczfn7XP7O05YzpfTw26pXmhkYeX4wAErXjw Message-ID: 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: I-D Action: draft-ietf-drinks-spp-framework-00.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 01:15:15 -0000 Hey All, Latest revisions of the documents were submitted today. Below is the list o= f modifications to the last revisions of the "protocol" and "transport" doc= ument (as they were referred to as of the last revision). 1. Title change of the documents: "draft-ietf-drinks-spprov" to "draft-ietf-drinks-spp-framework" "draft-ietf-drinks-sppp-over-soap" to "draft-ietf-drinks-spp-protoc= ol-over-soap" Hence new versions reflect as "00". 2. Cleanup of the document as a result of title change (some examples follo= w): -"SPPP" references changed to "SPPF" -The schema namespaces that had "spppb" (protocol) and "sppps" (soap) were = modified to "sppfb" and "sppfs" respectively. -Some of the sentences in the "framework" document where "protocol" was ref= erred - changed to "framework" -"SPPP over SOAP" references changed to "SPP Protocol over SOAP" -There were references earlier where it said "SPPP Protocol". I think that = was misnomer. It should have just said "SPPP" earlier. So any such referenc= es changed to "SPPF" 3. Addressed comments that were received and were agreed upon by Jan 13th d= eadline on the last versions of the drafts: -All nits that were commented on from the last drafts were correcte= d -"SourceIdentType" definition corrected in the framework to refer t= o "sourceIdentRegex" -Consistency in referring to "SPP Protocol over SOAP" to make disti= nction from the SPP Framework. 4. Per Sumanth's input, added Peter Saint-Andre to "Acknowledgements" secti= on in draft-ietf-drinks-spp-protocol-over-soap" and made the list in alphab= etical order. Thanks, Vikas -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: Monday, January 30, 2012 5:36 PM To: i-d-announce@ietf.org Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spp-framework-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : Session Peering Provisioning Framework (SPPF) Author(s) : Kenneth Cartwright Syed Wasim Ali Alexander Mayrhofer Vikas Bhatia Filename : draft-ietf-drinks-spp-framework-00.txt Pages : 59 Date : 2012-01-30 This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session peering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spp-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-spp-framework-00.txt _______________________________________________ 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 sumanth@CableLabs.com Mon Jan 30 18:39:11 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36D421F862A for ; Mon, 30 Jan 2012 18:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.706 X-Spam-Level: X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzRAzvVmsSg0 for ; Mon, 30 Jan 2012 18:39:10 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id D797621F85F9 for ; Mon, 30 Jan 2012 18:39:00 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0V1BPfM007874 for ; Mon, 30 Jan 2012 19:34:43 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 30 Jan 2012 18:11:25 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 30 Jan 2012 19:14:05 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Mon, 30 Jan 2012 19:14:00 -0700 Thread-Topic: REMINDER: DRINKS Interim Meeting (Feb 1, 2012) Thread-Index: Aczfvf7MvqbS/BToTAu976s7QXf4Lg== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DF4FC53B@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_76AC5FEF83F1E64491446437EA81A61F81DF4FC53Bsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] REMINDER: DRINKS Interim Meeting (Feb 1, 2012) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 02:39:11 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC53Bsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Just a reminder that we have the DRINKS interim meeting on Wednesday (Feb 1= , 2012). I am resending the details with this email. - S Date & Time Feb 1, 2012 (Wednesday); 2p-6p UTC/9a-1p Eastern Call-in Information - Dial +1 (213) 493-0602 - Access Code: 905-408-840 - GoToMeeting: https://www1.gotomeeting.com/join/905408840 Overview - This interim will be focused on making progress on the current o= pen I-Ds with the proposed titles of 'SPP Framework' and 'SPP Protocol over= SOAP' o http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/ o http://tools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/ Note: The authors are planning an update this week, to address comments rec= eived by the requested deadline (1/13); please continue to provide comments= , if any. - The goal is to resolve currently known open issues, to identify = topics that need to be resolve prior to completion, and establish a plan fo= r the next steps Proposed, Draft, Agenda - Welcome and administrivia, note well - Agenda bashing - Group review of the two open I-Ds - Open items discussion - Discuss and finalize open items that are considered in-scope and= out-of-scope (for completion of the I-Ds) - Establish plan for completion prior to Paris - Open Mic --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC53Bsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,=

 

Just a reminder t= hat we have the DRINKS interim meeting on Wednesday (Feb 1, 2012). I am res= ending the details with this email.

 

- S

 

 

Date & Time

= Feb 1, 2012 (Wednesday); 2p-6p UTC/9a-1p Eastern

 

Call-in Information

-     &n= bsp;    Dial +1 (213) 493-0602<= /o:p>

-  &nbs= p;       Access Code:= 905-408-840

 

-&= nbsp;         GoToMeeting: htt= ps://www1.gotomeeting.com/join/905408840

 

 

Overview

-=           This interim will be focused on making progress on the current open I-D= s with the proposed titles of ‘SPP Framework’ and ‘SPP Pr= otocol over SOAP’

o   http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/<= /a>

o   http://tools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/=

Note: T= he authors are planning an update this week, to address comments received b= y the requested deadline (1/13); please continue to provide comments, if an= y.

 

-  &nb= sp;       The goal is= to resolve currently known open issues, to identify topics that need to be= resolve prior to completion, and establish a plan for the next steps<= /o:p>

 

= Proposed, Draft, Agenda

-&nb= sp;         Welcome and administrivia, note well

-          Agenda bashing

-&nb= sp;         Group review of the two open I-Ds

-          Open items discussion

-&= nbsp;         Discuss and finalize open items that are considered in-scope and out-of-= scope (for completion of the I-Ds)

-          Establish plan for completion prior to Paris

-         = ; Open Mic

=  

 

= --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC53Bsrvxchg_-- From sumanth@cablelabs.com Tue Jan 31 05:40:03 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7CA21F854E for ; Tue, 31 Jan 2012 05:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VijeeZX3rar2 for ; Tue, 31 Jan 2012 05:40:01 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 74A7B21F8539 for ; Tue, 31 Jan 2012 05:40:01 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0VDe0QT026110 for ; Tue, 31 Jan 2012 06:40:00 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 31 Jan 2012 06:40:00 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 31 Jan 2012 06:40:00 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Tue, 31 Jan 2012 06:39:57 -0700 Thread-Topic: w/ updated I-D links: DRINKS Interim Meeting (Feb 1, 2012) Thread-Index: AczgHcpsMRykfZxPSCu+4ZQpdFEuDw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DF4FC548@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_76AC5FEF83F1E64491446437EA81A61F81DF4FC548srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] w/ updated I-D links: DRINKS Interim Meeting (Feb 1, 2012) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 13:40:03 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC548srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I forgot to update the links to the I-Ds that we plan to discuss, sorry. I = am enclosing them in this email. Please consider these in preparation for t= he interim. 1/ Session Peering Provisioning Framework http://www.ietf.org/id/draft-ietf-drinks-spp-framework-00.txt (Replaced its predecessor @ http://tools.ietf.org/wg/drinks/draft-ietf-drin= ks-spprov/ ) 2/ Session Peering Provisioning (SPP) Protocol over SOAP http://www.ietf.org/id/draft-ietf-drinks-spp-protocol-over-soap-00.txt (Replaced http://tools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/= ) Folks, Just a reminder that we have the DRINKS interim meeting on Wednesday (Feb 1= , 2012). I am resending the details with this email. - S Date & Time Feb 1, 2012 (Wednesday); 2p-6p UTC/9a-1p Eastern Call-in Information - Dial +1 (213) 493-0602 - Access Code: 905-408-840 - GoToMeeting: https://www1.gotomeeting.com/join/905408840 Overview - This interim will be focused on making progress on the current o= pen I-Ds with the proposed titles of 'SPP Framework' and 'SPP Protocol over= SOAP' o http://www.ietf.org/id/draft-ietf-drinks-spp-framework-00.txt o http://www.ietf.org/id/draft-ietf-drinks-spp-protocol-over-soap-00.txt - The goal is to resolve currently known open issues, to identify = topics that need to be resolve prior to completion, and establish a plan fo= r the next steps Proposed, Draft, Agenda - Welcome and administrivia, note well - Agenda bashing - Group review of the two open I-Ds - Open items discussion - Discuss and finalize open items that are considered in-scope and= out-of-scope (for completion of the I-Ds) - Establish plan for completion prior to Paris - Open Mic --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC548srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I forgot to update the links to the I-Ds that we plan to disc= uss, sorry. I am enclosing them in this email. Please consider these in pre= paration for the interim.

 

1/ Session Peering Provisioning Framework =

http://w= ww.ietf.org/id/draft-ietf-drinks-spp-framework-00.txt=

(Replaced its predec= essor @ http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/ )

 =

2/ Sess= ion Peering Provisioning (SPP) Protocol over SOAP

http://www.ietf.org= /id/draft-ietf-drinks-spp-protocol-over-soap-00.txt <= /p>

(Replaced http://t= ools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/ )<= /span>

 <= /o:p>

 

 

 

Folks,

 

Just a reminder that we = have the DRINKS interim meeting on Wednesday (Feb 1, 2012). I am resending = the details with this email.

 =

- S

 

 

Date & Time

Feb 1, 2= 012 (Wednesday); 2p-6p UTC/9a-1p Eastern

 

Call-in Information

-      &nbs= p;   Dial +1 (213) 493-0602

-    =       Access Code: 905-408= -840

=  

- &n= bsp;        GoTo= Meeting: https://ww= w1.gotomeeting.com/join/905408840

<= o:p> 

 

Overview

- &= nbsp;        Thi= s interim will be focused on making progress on the current open I-Ds with = the proposed titles of ‘SPP Framework’ and ‘SPP Protocol = over SOAP’

= o   http://www.ietf.org/id/draft-ie= tf-drinks-spp-framework-00.txt

o&nbs= p;  http://www.ietf.org/id/draft-ietf-drinks-spp-protocol-over-soap-00.txt

 

-  =         The goal= is to resolve currently known open issues, to identify topics that need to= be resolve prior to completion, and establish a plan for the next steps

 

= Proposed, Draft, Agenda

-=           Welcome and administrivia, note well

-          Agenda bashing

-&n= bsp;         Group review of the two open I-Ds

-          <= ![endif]>Open items discussion

-=           Discuss and finalize open items that are considered in-scope and out-of= -scope (for completion of the I-Ds)

-          <= ![endif]>Establish plan for completion prior to Paris

<= ![if !supportLists]>-        &nbs= p; Open Mic

 

 

= --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC548srvxchg_--