From alexander.mayrhofer@nic.at Mon Aug 2 07:22:45 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42B53A6A05 for ; Mon, 2 Aug 2010 07:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.222 X-Spam-Level: X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxfNKdTpS8h9 for ; Mon, 2 Aug 2010 07:22:45 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 839FA3A6B36 for ; Mon, 2 Aug 2010 07:22:43 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.45 ; Mon, 2 Aug 2010 16:23:09 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.702.0; Mon, 2 Aug 2010 16:23:07 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 2 Aug 2010 16:23:09 +0200 Message-ID: <8BC845943058D844ABFC73D2220D4665094CBF3D@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: minutes of the IETF78 WG session Thread-Index: AcsyTjubvXqCnOnwThCOlMxbgNp/LA== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] minutes of the IETF78 WG session X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 14:22:46 -0000 All, i've posted the minutes of our WG session in Maastricht to the Meetings Material site: http://www.ietf.org/proceedings/78/minutes/drinks.txt Please review and email me with corrections - thanks to Brian Rosen for taking the notes. Alex From sumanth@cablelabs.com Mon Aug 2 09:04:20 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47373A6BC2 for ; Mon, 2 Aug 2010 09:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.323 X-Spam-Level: * X-Spam-Status: No, score=1.323 tagged_above=-999 required=5 tests=[AWL=-1.414, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZMa4EGKANfZ for ; Mon, 2 Aug 2010 09:04:19 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id C6E953A6B42 for ; Mon, 2 Aug 2010 09:04:18 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o72G4jpp003131; Mon, 2 Aug 2010 10:04:46 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 2 Aug 2010 10:04:45 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 2 Aug 2010 10:04:46 -0600 From: Sumanth Channabasappa To: Otmar Lendl , IETF DRINKS WG Date: Mon, 2 Aug 2010 10:04:57 -0600 Thread-Topic: [drinks] Looking for 2-4 volunteers to review draft-ietf-drinks-usecases-requirements Thread-Index: Acso202jBmxNL2AfQciuHeB/gyawuAJgPLkw Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF5048495@srvxchg> References: <4C46FA74.7030403@nic.at> In-Reply-To: <4C46FA74.7030403@nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [drinks] Looking for 2-4 volunteers to review draft-ietf-drinks-usecases-requirements X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 16:04:20 -0000 Otmar, Thanks again for your comments. I am enclosing some responses, inline, tagg= ed with [S]. For items that I need additional clarification (from you or ot= hers on this list), I have tried to mark them with the following string '**= **********'. [FYI, I believe we discussed some of these at the meeting, so I tried to ke= ep it brief, although not diligently. I also added numbers so that we can r= eference them easily when we make I-D updates. ] =20 - S <...snip..> ---------------------- #1 > > This document reuses terms from [RFC3261] (e.g., SIP), [RFC5486] > (e.g., LUF, LRF, SED) and [RFC5067] (carrier-of-record and transit > provider). In addition, this document specifies the following > additional terms. I'm missing a definition of RN (Routing Number?). =3D=3D=3D [S] Hmmm, I guess we are missing a reference to RFC4694.=20 =3D=3D=3D #2 > Registry: The authoritative source for provisioned session > establishment data (SED) and related information. It is explained later, but at that stage it would have been helpful to stat= e whether that Regstry is part of a SSP or whether it is an independent bod= y. =3D=3D=3D [S] We can add the clarification. =3D=3D=3D #3 > Registrar An entity that provisions and manages data into the > registry. That term appears only once in the rest of the document, and in most cases = its "SSP provisions...". So perhaps junk it? > Registrant An entity whose data is provisioned into the registry. > The registrant can act as its own registrar or - additionally or > alternatively - delegate this function to a third party who acts > as its registrar. Never appears in the document. =3D=3D=3D [S] This is probably my bad. We agreed to use registrar and registrant to t= he use cases (at the interim meeting), but it is not used as expected. =3D=3D=3D #4 > > Local Data Repository: The data store component of an addressing > server that provides resolution responses. Is this run by the SSP it serves? =3D=3D=3D [S] Yes. See Figure 2. =3D=3D=3D #5 > Public Identifier: A public identifier refers to a telephone number > (TN), an email address, or other identity as deemed appropriate, > such as a globally routable URI of a user address (e.g., > mailto:john.doe@example.net). Why an email address? Or is this just to a hint in the direction of email-l= ike sip URIs like sip:lendl@nic.at? =3D=3D=3D [S] The idea here was to allow for additional associations with a public id= entity, outside of TNs. Email was referenced as an example (not as a look-u= p key).=20 =3D=3D=3D #6 > TN Range: A numerically contiguous set of telephone numbers whose > SED can be looked up (resolved). "whose" is a bit wrong here, as all the SSP-specific and data-policy- depen= dend features make the SED not a simple attribute of a TN range. So, I recommend either TN Range: A numerically contiguous set of telephone numbers or stress that all numbers in the range have the same routing data associat= ed with them: TN Range: A numerically contiguous set of telephone numbers for which the same data distribution policy and SED applies. =3D=3D=3D [S] I personally prefer the latter. =3D=3D=3D #7 > Destination Group: An aggregation of a set of public identifiers, > TN Ranges, or RNs that share common SED. good. perhaps not just SED, but also the "who sees what" properties. =3D=3D=3D ************ [S] Can you elaborate on this (as it applies to the description), please? =3D=3D=3D ************ #8 > Routing Group: An aggregation that contains a related set of SED > records, and is associated with a set of destination groups. > Routing groups facilitate the management of SED records - which > are common to a large number of public identifiers, TN Ranges or > RNs - for one or more data recipients. DGs are intuitively right and important, but for RGs I have more difficulti= es understanding the argument. I guess it makes sense, but this text does n= ot convince me. Please leave the PIs, TN ranges and RN out of the definition, RGs are only = connected to Destination Groups. =3D=3D=3D************ [S] RGs associate DGs to SED. We discussed some of the rationale at the mee= ting. Do you still have questions about its applicability? =3D=3D=3D************ #9 > SED is typically created by the terminating SSP and consumed by the > originating SSP. To avoid a multitude of bilateral exchanges, SED=20 > is "terminating" is perhaps the wrong word for the transit case, as the it's t= he transit SSP, and not the final, terminating SSP that creates the SED ent= ries. =3D=3D=3D************ [S] That's true. Design Team: any suggestions on how to word this better fo= r direct and transit cases? =20 =3D=3D=3D************ #10 > often shared via intermediary systems - termed registries within this > document. Such registries receive SED via provisioning transactions > from other SSPs, and then distribute the received data into Local > Data Repositories. These local data repositories are used for call > routing by outgoing SBEs. This is depicted in Figure 1. I don't want to pick nits, but the SED alone are useless unless you also pr= ovision and distribute the TN-Ranges / PIs / .. to which these SED records = apply. The diagram is fine und useful, just be a bit more careful about the termin= ology. =3D=3D=3D [S] Fair point. =3D=3D=3D #11 > In this version of the document, we primarily address the use cases > and requirements for provisioning registries. Future revisions may > include data distribution to local data repositories. The resulting > provisioning protocol can be used to provision data into a registry, > or between registries. This is depicted in Figure 2. > > The fact that there could be multiple registries operating in parallel shou= ld be stressed somewhere else. The dotted lines make this diagram slightly confusing. Perhaps do a version with the current focus only, and then add a second one= that explains what future revisions might do. =3D=3D=3D [S] K =3D=3D=3D=20 #12 > In addition, this document proposes the following aggregation groups > with regards to SED (refer to the use cases in Section 3.5 for the > rationale): > > o Aggregation of public Identifiers into a destination group. > > > o Aggregation of SED records into a Routing Group. As before, some more explanations on the RG, perhaps with some examples mig= ht be helpful. =3D=3D=3D************ [S] In addition to the use cases? =3D=3D************ #13 > > The data model depicted in Figure 3 shows the various entities, > aggregations and the relationships between them. > I think the direct PI-SED link should be removed. It just leads to endless = special-cases in all the code. > UC INTERCONNECT #3 Intra-SSP SED: SSPs support the establishment of > sessions between their own public identifiers, > not just to other SSPs public identifiers. > Enabling this involves, among other things, > communicating and enabling intra-SSP signaling > points and other SED that can differ from inter- > SSP signaling points and SED. This confused me a bit. Why would an SSP out-source their internal routing = to an external DB? But yes, it's done in the PSTN world and perhaps the drinks protocol might = be used internally to an SSP (think merger process of two SSPs), so ok, lea= ve it in. =3D=3D=3D [S] :) =3D=3D=3D #14 > UC INTERCONNECT #4 Selective Peering (a.k.a. per peer policies): > SSPs create peering relationships with other SSPs > in order to establish interconnects. However, > SSPs peering relationships often result in > different points of ingress or other SED for the > same set of public identifiers. Please clarify the level of selectiveness supported: by PI, by TN-Range, by RN or just by Destination-Group. =3D=3D=3D [S] Destination Group is an internal structure, so it would be by PI, RN or= TN Range. We can clarify. =3D=3D=3D #15 > UC INTERCONNECT #5 Provisioning of a delegated name server: An SSP > maintains a Tier 2 name server that contains the > NAPTR records that constitute the terminal step > in the LUF. The SSP needs to provision a > registry to direct queries for the SSP's numbers > to the Tier 2 name server. Usually queries to > the registry should return NS records, but in > cases where the Tier 2 uses a different domain > suffix from that used in the registry, CNAME and > NS records may be employed instead. WTF? The rest of the draft talk about generic SED, does not specify a query prot= ocol, and now, out-of-the-blue, we're on NAPTR, NS, CNAME level? This makes no sense at this level. If there is a use-case, describe it at t= he same abstraction level as the others. =3D=3D=3D [S] OK :)! I think we agreed to make this abstract at the meeting. =3D=3D=3D #16 >3.3. Category: SED Exchange and Discovery Models > UC SED EXCHANGE #2 SED Exchange and Discovery using LUF's Domain > Name: When establishing peering relationships > some SSPs may not wish to communicate or receive > points of ingress and other SED using a registry. > They wish to only communicate or receive domain > names resolvable via [RFC3263], and this query > will then return the points of ingress or other > SED that form the LUF. I think this is ok, but the text confuses me. Please describe (perhaps usin= g examples) what the query is and what the answer will be. (Examples would be helpful for all these 4 types.) =3D=3D=3D [S] We could add some small examples. =3D=3D=3D #17 >3.5. Category: Separation and Facilitation of Data Management > > UC DATA #1 Separation of Provisioning Responsibility: An SSP's > operational practices often separate the responsibility > of provisioning the points of ingress and other SED, from > the responsibility of provisioning public identifiers (or > TN ranges or RNs). For example, a network engineer can > establish a physical interconnect with a peering SSP's > network and provision the associated domain name, host, > and IP addressing information. Separately, for each new > subscriber, the SSP's provisioning systems provisions the > associated public identifiers. This is good. Perhaps clarifiy that one is the LUF data (PI/TN -> DG mapping) and that th= e other is the LRF data (DG -> SED). =3D=3D=3D************ [S] Do we really want to add LUF and LRF distinction within the use case? =3D=3D=3D************ #18 > > UC DATA #3 Route Groups: SSPs often provision identical SED for > large numbers of public identifiers, and then expose=20 > that ^^^ this is handled via the DG abstraction. =3D=3D=3D [S] Yes... =3D=3D=3D #19 > relationship between a group of SED records and a group > of public identifiers to one or more SSPs. This combined > grouping of SED records and Destination Groups > facilitates management of public identity SED > relationships and the list of peers (data recipients) > that can lookup those public identifiers and receive that > SED. This dual set of SED Records and Destination Groups > is termed as a Route Group. Once again, the idea is good, but the explanation for the RG rationale is m= ore confusing than helpful. =3D=3D=3D************ [S] Any suggestions (Otmar or the design team)? =3D=3D=3D************ #20 >3.7. Category: Number Portability > > UC NP #1 EDITOR's NOTE: Need to clarify this further. > > > The SSP wishes to provide in query response to public > identifiers an associated routing number or RN. This is > the case when a set of public identifiers is no longer > associated with original SSP but have been ported to a > recipient SSP who provides access to these identifiers via > a switch on the SS7 network identified by the RN. In this > case a destination group containing all numbers that should > be routed to this RN needs to be created and the route > group associated with this DG needs to contain the RN I do not think this is a good idea. =3D=3D=3D [S] :) =3D=3D=3D #21 >4. Requirements > > REQ13: Support for lookup keys having identical business keys (the > public identity string, the digits that comprise an RN, the > start and end point of a TN range's range) that concurrently > exist across multiple destination groups and where each > destination group may be managed by different SSPs. > > Editor's note: We need to simplify the above requirement. btw, one thing that is missing is the handling of overlapping information: e.g. SSP-A provisions: 123-1000 to 123-1999 to DG "foobar" SSP-B provisions: 123-1100 to 123-1149 to DG "funk" what would a query for 123-1120 yield? Both entries? Just the one from the = closer match? =3D=3D=3D [S] I don't know if we speak about the resolution here. My personal take is= that both of them should be returned (assuming the recipient is allowed to= see either). =3D=3D=3D #22 >5. Security Considerations > > Session establishment data allows for the routing of SIP sesions > within, and between, SIP Service Providers. Access to this data can > compromise the routing of sessions and expose a SIP Service Provider > to attacks such as service hijacking and denial of service. The data > can be compromised by vulnerable functional components and interfaces > identified within the use cases. This is a bit thin. Consider: * data-leaks * stale data in the registry * protection against a malicious SSP * re-routing of calls due to injection of wrong data =3D=3D=3D [S] OK =3D=3D=3D #23 > >7. Acknowledgments > > (AT&T Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey, > Nuestar; and Alexander Mayrhofer, enum.at GmbH), and the editors of Neustar. =3D=3D=3D [S] Thanks!=20 =3D=3D=3D = From lendl@nic.at Mon Aug 2 13:14:40 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3215B3A6C48 for ; Mon, 2 Aug 2010 13:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrFm5h4WMIik for ; Mon, 2 Aug 2010 13:14:32 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 382873A698C for ; Mon, 2 Aug 2010 13:14:27 -0700 (PDT) Received: from [10.0.0.1] (80-121-106-110.adsl.highway.telekom.at [80.121.106.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 3961E554001; Mon, 2 Aug 2010 22:14:53 +0200 (CEST) Message-ID: <4C57273A.9010901@nic.at> Date: Mon, 02 Aug 2010 22:14:50 +0200 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Sumanth Channabasappa References: <4C46FA74.7030403@nic.at> <76AC5FEF83F1E64491446437EA81A61F7CF5048495@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF5048495@srvxchg> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF DRINKS WG Subject: Re: [drinks] Looking for 2-4 volunteers to review draft-ietf-drinks-usecases-requirements X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:14:40 -0000 On 02.08.2010 18:04, Sumanth Channabasappa wrote: > > [FYI, I believe we discussed some of these at the meeting, ] Yes, some things got clarified during the meeting. A number of my comments were editorial comments, where I just think you need to improve the document. I'll skip over these now. > #5 >> Public Identifier: A public identifier refers to a telephone number >> (TN), an email address, or other identity as deemed appropriate, >> such as a globally routable URI of a user address (e.g., >> mailto:john.doe@example.net). > > Why an email address? Or is this just to a hint in the direction of email-like sip URIs like sip:lendl@nic.at? > === > [S] The idea here was to allow for additional associations with a public identity, outside of TNs. Email was referenced as an example (not as a look-up key). > === This is confusing. From the rest of the use-cases one would assume that the PI is always the key to the lookup. While I can see the utility of returning the email-address associated to a TN (e.g. for MMS or voice-mail), IMHO that address should then be part of the Route-Set and not part of the PI. Perhaps the best way forward is to provide an example on where email-addresses could appear in a use-case, and use SIP URIs as examples of a PI. > #6 >> TN Range: A numerically contiguous set of telephone numbers whose >> SED can be looked up (resolved). As per the Maastricht session: you should explicitly state both that this could be a range in a closed numbering plan, or a prefix in an open numbering plan setting. > #7 >> Destination Group: An aggregation of a set of public identifiers, >> TN Ranges, or RNs that share common SED. > > good. perhaps not just SED, but also the "who sees what" properties. > > === ************ > [S] Can you elaborate on this (as it applies to the description), please? > === ************ If I take a look at the overview diagram, then all the selective peering/visibility features do not apply to a single TN/RN/PI, but are connected to DG. so "..that share common SED" is just one part, a DG is also atomic in respect to the selective peering features. IMHO that should be part of the definition. > > > #8 >> Routing Group: An aggregation that contains a related set of SED >> records, and is associated with a set of destination groups. >> Routing groups facilitate the management of SED records - which >> are common to a large number of public identifiers, TN Ranges or >> RNs - for one or more data recipients. > > DGs are intuitively right and important, but for RGs I have more difficulties understanding the argument. I guess it makes sense, but this text does not convince me. > > Please leave the PIs, TN ranges and RN out of the definition, RGs are only connected to Destination Groups. > ===************ > [S] RGs associate DGs to SED. We discussed some of the rationale at the meeting. Do you still have questions about its applicability? > ===************ As you say, RGs associate DGs to SED, so PIs, TN ranges and RN should not be in the definition. As I wrote, I don't think the idea is wrong. I just think that you don't make the case for the idea overall in this document. (Somehow this reminds me of file system permissions: The simple unix user-group-world system can do anything, but some settings are tricky to do. Other systems (e.g. windows), provide other abstractions as well, that can be helpful in simplifying some rules. But as you made the TN-DG relationship 0..n:1, you will probably need the ability to do route-groups.) So some more explanations or examples would be helpful. > > #12 >> In addition, this document proposes the following aggregation groups >> with regards to SED (refer to the use cases in Section 3.5 for the >> rationale): >> >> o Aggregation of public Identifiers into a destination group. >> >> >> o Aggregation of SED records into a Routing Group. > > As before, some more explanations on the RG, perhaps with some examples might be helpful. > > ===************ > [S] In addition to the use cases? > ==************ Yes. > > > #13 >> >> The data model depicted in Figure 3 shows the various entities, >> aggregations and the relationships between them. >> > > I think the direct PI-SED link should be removed. It just leads to endless special-cases in all the code. One idea on how one might simplify this: Perhaps provide for an RN/TN/PI -> RN/TN/PI mapping for these cases? The actual routing could then go via the normal way. > #14 >> UC INTERCONNECT #4 Selective Peering (a.k.a. per peer policies): >> SSPs create peering relationships with other SSPs >> in order to establish interconnects. However, >> SSPs peering relationships often result in >> different points of ingress or other SED for the >> same set of public identifiers. > > Please clarify the level of selectiveness supported: > by PI, by TN-Range, by RN or just by Destination-Group. > > === > [S] Destination Group is an internal structure, so it would be by PI, RN or TN Range. We can clarify. > === Hu? Do DG feature in the protocol? if yes, then it is better to tell users right here that DGs are atomic with respect to the selective peering features. > > > #15 >> UC INTERCONNECT #5 Provisioning of a delegated name server: An SSP >> maintains a Tier 2 name server that contains the >> NAPTR records that constitute the terminal step >> in the LUF. The SSP needs to provision a [...] > === > [S] OK :)! I think we agreed to make this abstract at the meeting. > === I'll try to write up my suggestions later this week. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From gonzalo.camarillo@ericsson.com Tue Aug 3 02:27:55 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370F03A69F5 for ; Tue, 3 Aug 2010 02:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.722 X-Spam-Level: X-Spam-Status: No, score=-102.722 tagged_above=-999 required=5 tests=[AWL=-1.982, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvK0yp1xh90m for ; Tue, 3 Aug 2010 02:27:53 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4554A3A6A10 for ; Tue, 3 Aug 2010 02:27:53 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-6e-4c57e134f793 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 34.A4.06895.431E75C4; Tue, 3 Aug 2010 11:28:21 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Aug 2010 11:28:20 +0200 Received: from [131.160.126.136] ([131.160.126.136]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Aug 2010 11:28:20 +0200 Message-ID: <4C57E133.7090904@ericsson.com> Date: Tue, 03 Aug 2010 12:28:19 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "drinks@ietf.org" References: <021601cb2f81$00ce7c50$026b74f0$@us> In-Reply-To: <021601cb2f81$00ce7c50$026b74f0$@us> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Aug 2010 09:28:20.0461 (UTC) FILETIME=[3649E9D0:01CB32EE] X-Brightmail-Tracker: AAAAAA== Cc: Richard Shockey Subject: Re: [drinks] Resigning as WG Co-Chair X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 09:27:55 -0000 Hi, we would like to thank Richard for all his work chairing this working group during all these years. As Alex presented in Maastricht, the plan is to close down this WG by the spring IETF. Nevertheless, we would like to have two chairs until then. So, Sumanth will be cochairing this group with Alex from now until its closure. We would like to thank Sumanth for volunteering to do this. Cheers, Gonzalo On 30/07/2010 3:49 AM, Richard Shockey wrote: > Due to professional considerations I’ve decided I cannot properly > continue to act as DRINKS Co-Chair. > > > > I have informed the AD’s of this fact and they will announce a new > Co-Chair shortly. > > > > That does not mean that I do not have a ongoing interest in this work. I > will continue to monitor this work closely, if from afar. > > > > I remain convinced DRINKS is essential to the deployment of global > databases that can end the plague of SS7 on planet Earth. > > > > I thank all the members of this WG for their support and continuing work. > > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum > PSTN Mobile: +1 703.593.2683 > > skype: rshockey101 > LinkedIn : http://www.linkedin.com/in/rshockey101 > http//www.sipforum.org > > > From alexander.mayrhofer@nic.at Tue Aug 3 02:52:06 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6D83A68C1 for ; Tue, 3 Aug 2010 02:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.523 X-Spam-Level: X-Spam-Status: No, score=0.523 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuAs9lxBBRVP for ; Tue, 3 Aug 2010 02:52:05 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 40FA73A6827 for ; Tue, 3 Aug 2010 02:52:05 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.45 ; Tue, 3 Aug 2010 11:52:30 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.702.0; Tue, 3 Aug 2010 11:52:30 +0200 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, 3 Aug 2010 11:52:27 +0200 Message-ID: <8BC845943058D844ABFC73D2220D4665094CC019@nics-mail.sbg.nic.at> In-Reply-To: <021601cb2f81$00ce7c50$026b74f0$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Resigning as WG Co-Chair Thread-Index: AcsvgQAawAK0+3KvSiOLLRAU6Z4oawDb4BgA References: <021601cb2f81$00ce7c50$026b74f0$@us> From: Alexander Mayrhofer To: Richard Shockey , X-XWALL-BCKS: auto Subject: Re: [drinks] Resigning as WG Co-Chair X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 09:52:06 -0000 > I thank all the members of this WG for their support and=20 > continuing work. Richard, on behalf of the DRINKS WG, i want to say thank you for all the time & effort that you spent on that topic. I still remember very lively the PEPPERMINT BoFs (oh, wasn't a nickname coined there? ;), the subsequent charter discussions, and finally the first WG sessions - thanks for all that hard work that you spent on getting this done. Personally, i'd like to thank you for bringing me up to speed in chairing IETF working groups, for the hours of background discussions, and for providing me with insight about numbering and routing. I hope to see you continuing contributing to DRINKS. thanks, Alex From pk@DENIC.DE Tue Aug 3 03:59:54 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37CE23A696E for ; Tue, 3 Aug 2010 03:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.703 X-Spam-Level: X-Spam-Status: No, score=-4.703 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_20=-0.74, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od0-ZySp2KTK for ; Tue, 3 Aug 2010 03:59:53 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 00EB73A68E1 for ; Tue, 3 Aug 2010 03:59:52 -0700 (PDT) Received: from unknown.office.denic.de ([10.122.65.69]) by office.denic.de with esmtp id 1OgFEK-0001E4-5A; Tue, 03 Aug 2010 13:00:20 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 13A316B0F84; Tue, 3 Aug 2010 13:00:19 +0200 (CEST) Date: Tue, 3 Aug 2010 13:00:19 +0200 From: Peter Koch To: IETF DRINKS WG Message-ID: <20100803110019.GB2516@unknown.office.denic.de> Mail-Followup-To: IETF DRINKS WG References: <8BC845943058D844ABFC73D2220D4665093AC56D@nics-mail.sbg.nic.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8BC845943058D844ABFC73D2220D4665093AC56D@nics-mail.sbg.nic.at> User-Agent: Mutt/1.4.2.1i Subject: Re: [drinks] Looking for 2-4 volunteers to review draft-ietf-drinks-usecases-requirements X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 10:59:54 -0000 Alex, WG, > we're looking for 2-4 additional volunteers for > https://datatracker.ietf.org/doc/draft-ietf-drinks-usecases-requirements > (outside of the core contributor team of the document). The document is this is a coarse review of . Since I have (deliberately) not read the other comments on this version of the draft, I apologize for potential duplications. o UC INTERCONNECT #5 Provisioning of a delegated name server: An SSP maintains a Tier 2 name server that contains the NAPTR records that constitute the terminal step in the LUF. The SSP needs to provision a registry to direct queries for the SSP's numbers to the Tier 2 name server. Usually queries to the registry should return NS records, but in cases where the Tier 2 uses a different domain suffix from that used in the registry, CNAME and NS records may be employed instead. (also REQ5) The rest of the use cases is rqther high level, so the apperance of "Tier 2" and the DNS RR types comes a bit out of the blue. Also, from a DNS perspective, the wording could benefit from a rephrase. (e.g., RR's aren't contained in a name server but in a DNS zone; "queries to the registry": the draft does not state that DNS is _the_ lookup protocol; CNAME+NS doesn't suggest how these would interact) All in all, there are hidden assumptions here that would either need more explanation, more references - or maybe better even: an increased level of abstraction). o UC SED EXCHANGE #1 SED Exchange and Discovery using unified LUF/LRF: When establishing peering relationships some SSPs wish to communicate or receive points of ingress and other SED that contain LUF and LRF. What is meant by "points of ingress and other SED that contain LUF and LRF"? o RN is not expanded in the draft (neither in RFC 5486. o Capitalization of "destination group" is not consistent. o The text below figure 3 misses a description of the relation between "SED record" and "PI". o Page 9, 1st paragraph: to authorization. However, the act of authorization is considered to be out of scope within this document. maybe "out of the scope of"? (see below for security implications) o The term "lookup key", used in 3.6, is never defined. also: capitalization o Routing Groups vs Route Groups (again: consistent capitalization) Routing Groups are defined under (1) Terminology and Route Groups are (re)defined under UC DATA #3. It is not clear to me that both definitions match 100%, but in any case terminology should be made consistent. o IANA considerations: the list of non-actions should contain both registration and the creation of a registry (the absence thereof, of course). o Security Considerations: the draft says "access" to data could compromise security without being clear whether this is read or write access. The document rules questions of authorization (for the provisioning mechanism) out of scope, so one of the major topics of protecting a registry is not addressed in the requirements. Where are these aspects supposed to be covered? o It is a bit unusual for an IETF document, albeit not completely without precedent, to list the affiliations in the Acknowledgements section. o References: RFC 5486 (SPEERMINT terminology) should be a normative reference, since it is needed to understand this document. -Peter From lendl@nic.at Tue Aug 3 12:39:27 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9AA3A69C5 for ; Tue, 3 Aug 2010 12:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDMjb192jjhR for ; Tue, 3 Aug 2010 12:39:26 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 966D53A69B7 for ; Tue, 3 Aug 2010 12:39:25 -0700 (PDT) Received: from [10.0.0.1] (80-121-103-103.adsl.highway.telekom.at [80.121.103.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 746724C7E2 for ; Tue, 3 Aug 2010 21:39:53 +0200 (CEST) Message-ID: <4C587088.5080201@nic.at> Date: Tue, 03 Aug 2010 21:39:52 +0200 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: drinks@ietf.org References: <4C46FA74.7030403@nic.at> <76AC5FEF83F1E64491446437EA81A61F7CF5048495@srvxchg> <4C57273A.9010901@nic.at> In-Reply-To: <4C57273A.9010901@nic.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [drinks] Some ideas on the Route Records X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 19:39:28 -0000 On 02.08.2010 22:14, Otmar Lendl wrote: >> #15 >>> UC INTERCONNECT #5 Provisioning of a delegated name server: An SSP >>> maintains a Tier 2 name server that contains the >>> NAPTR records that constitute the terminal step >>> in the LUF. The SSP needs to provision a >> === >> [S] OK :)! I think we agreed to make this abstract at the meeting. >> === > > I'll try to write up my suggestions later this week. Here are my thoughts on how one might approach the data structures in the route records. This is based on http://tools.ietf.org/html/draft-ietf-drinks-spprov-01 There they are defined as: o Route Record (RteRecType): A Route Record is the data that the resolution systems return in response to a successful query with the Public Identifier as the query string. It is associated with a Route Group for routes that are not specific to a Public Identifier. To support the use cases defined in [I-D.ietf-drinks-usecases-requirements], SPPP protocol defines three type of Route Records: URIType, NAPTRType, and NSType. These Route Records extend the abstract type RteRecType and inherit the common attribute 'priority' that is meant for setting precedence across the route records defined within a Route Group in a protocol agnostic fashion. The NAPTRType is basically 1:1 the fields in a NAPTR, but the URIType is more interesting: This is quite nice and tails very closely what the NAPTRs are doing. But let's step back for a second and look at what's common to all these Route Records. We have: * Route Records that map from the PI to an URI + Terminal NAPTR + URIType * Route Records that only generate a referral, not a full resolution + NSType + non-terminal NAPTR So, if we would want to create a more resolution-protocol independent set of Route Records, we could do it in the following way: That record needs to contain: * A regex - Maybe allow in the XML an alternative to the /^.*$/whatever/ greedy match by stating "whatever. * What kind of PI it applies to? (what is the input to the regex?) - E.164 number - SIP uri - ... * What kind of service it applies to? - voice calling - message service (SMS, MMS) - voicemail - video calling * How to interpret the result of the regex? - A re-target operation (like ENUM, the result becomes the new request-URI) - A routing operation (The request-URI is not touched (e.g. can remain a tel: URI), the result just defines the next SIP hop.) - A referral This need not be limited to "go use ENUM to query the following Nameservers" but could also be something like "query the following SIP server for a redirect" or even a "go to a completely different resolution scheme" --- This way, we're completely independent of a resolution protocol. Some of these route records can be used to populate ENUM trees (if it's not a re-target operation, one would need something like http://www.ietf.org/mail-archive/web/sip/current/msg23298.html). Others might drive SIP redirect servers. Comments? otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From kcartwright@tnsi.com Wed Aug 4 07:27:19 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121713A67D1 for ; Wed, 4 Aug 2010 07:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[AWL=-2.614, BAYES_40=-0.185, FB_IOW=3.333] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yrpnja596ZC for ; Wed, 4 Aug 2010 07:27:18 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id D53F83A63D3 for ; Wed, 4 Aug 2010 07:27:17 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.46328001; Wed, 04 Aug 2010 10:27:43 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 4 Aug 2010 10:27:43 -0400 From: "Cartwright, Ken" To: IETF DRINKS WG Date: Wed, 4 Aug 2010 10:27:42 -0400 Thread-Topic: [drinks] Open Numbering Plan Thread-Index: Acso205AbmSBaG5cQqC7Gr1ZasdKWQLAx3jQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24490E47C9@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4C46FA74.7030403@nic.at> In-Reply-To: <4C46FA74.7030403@nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [drinks] Open Numbering Plan X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 14:27:19 -0000 I know that the question of an open numbering plan has come up a couple tim= es, however, it's not clear to me why this is not simply a matter of policy= and has no bearing on the SPPP protocol itself. 1) The resolution server can/should be aware of each of the country codes t= hat adhere to an open numbering plan. 2) The resolution server can/should, for country codes known to have an ope= n numbering plan, interpret an SPPP TNRange within such a country code as b= eing inclusive of TNs that may be longer than the start and end point of th= e range. As a result, the best match of the provisioned TNRanges will be s= elected, even of the queried TN is longer than the best matching TNRange. Iow, afaik, there is *not* the need for the following in SPPP: 1) For country codes that *do not* support an open numbering plan, allow pr= ovisioning of a TNRange in that country code and mark that TNRange as *an* = "open number plan TNRange". 2) For country codes that *do* support an open numbering plan, allow provis= ioning of a TNRange in that country code and mark that TNRange as *not an* = "open number plan TNRange". Sorry about the double negatives, etc, above, perhaps there is a more succi= nct way to state this, but I think you get the point. Making this a matter of policy would of course be superior to embedding it = in the protocol because the provisioning activities will be simpler on the = SPPP clients as well as the SPPP servers. Ken 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 alexander.mayrhofer@nic.at Wed Aug 4 07:55:29 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8633A6823 for ; Wed, 4 Aug 2010 07:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.374 X-Spam-Level: ** X-Spam-Status: No, score=2.374 tagged_above=-999 required=5 tests=[AWL=-2.129, BAYES_50=0.001, FB_IOW=3.333, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSfZl9ecdIWs for ; Wed, 4 Aug 2010 07:55:28 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 526613A687E for ; Wed, 4 Aug 2010 07:55:28 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.45 ; Wed, 4 Aug 2010 16:55:55 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.702.0; Wed, 4 Aug 2010 16:55:54 +0200 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, 4 Aug 2010 16:55:55 +0200 Message-ID: <8BC845943058D844ABFC73D2220D4665094CC245@nics-mail.sbg.nic.at> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA24490E47C9@TNS-MAIL-NA.win2k.corp.tnsi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Open Numbering Plan Thread-Index: Acso205AbmSBaG5cQqC7Gr1ZasdKWQLAx3jQAAEL51A= References: <4C46FA74.7030403@nic.at> <754963199212404AB8E9CFCA6C3D0CDA24490E47C9@TNS-MAIL-NA.win2k.corp.tnsi.com> From: Alexander Mayrhofer To: "Cartwright, Ken" , IETF DRINKS WG X-XWALL-BCKS: auto Subject: Re: [drinks] Open Numbering Plan X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 14:55:29 -0000 > 1) The resolution server can/should be aware of each of the=20 > country codes that adhere to an open numbering plan. It could. But i think this is out of scope of our work, since this would mean having to keep up to date with 200+ local regulators, and their actual policy (which, btw, might even vary by region). Plus, even in countries with an open numbering plan there might be specific number types that have an closed numbering plan. For example, it could be possible that geographic numbers follow an open numbering plan, while mobile numbers are of fixed lenght. Unfortunately, it's pretty complicated - don't get me started.=20 > 2) The resolution server can/should, for country codes known=20 > to have an open numbering plan, interpret an SPPP TNRange=20 > within such a country code as being inclusive of TNs that may=20 > be longer than the start and end point of the range. As a=20 > result, the best match of the provisioned TNRanges will be=20 > selected, even of the queried TN is longer than the best=20 > matching TNRange. I think this is very risky. Such interpretation might vary over time, as countries change their numbering plans. Which would mean that if a country (or region of a country) changes their administrative model, the semantics of an SPPP object would change - withount a change in the protocol. I don't want to require ITU-T driven (or local regulator driven) knowledge in network elements affect the semantics of objects in our protocol. That just does not work. > Iow, afaik, there is *not* the need for the following in SPPP: > 1) For country codes that *do not* support an open numbering=20 > plan, allow provisioning of a TNRange in that country code=20 > and mark that TNRange as *an* "open number plan TNRange". > 2) For country codes that *do* support an open numbering=20 > plan, allow provisioning of a TNRange in that country code=20 > and mark that TNRange as *not an* "open number plan TNRange". I think that there is definitely the need for distinguishing "prefix" style TNs and TN ranges from "non-prefix" style TNs or TN ranges. Particularly because as outlined above, a country could very well mix open and non-open numbering ranges. > Making this a matter of policy would of course be superior to=20 > embedding it in the protocol because the provisioning=20 > activities will be simpler on the SPPP clients as well as the=20 > SPPP servers. I think the contrary is true: Embedding a way to indicate whether a TN or TN range is of "prefix" style is superior to policy. Because the policy depends on external parties, which means that semantics of an object in SPPP could change over time, just because that external party changes the policy. Please please please make SPPP independent of ITU-T and regulatory policy. It's simple: +1813555666 - "plain" TN - does not include +18135556667 +4315056416 - "prefix" TN - *does* include +4315056416 (side note: have we defined tnrange yet?) "plain" TNRange - does not include +181355534377 +1813555000 +1813555999 "prefix" TNRange - *does* include +4315056416930 +4315056400 +4315056499 Alex From alexander.mayrhofer@nic.at Wed Aug 4 08:15:47 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFCE3A6B87 for ; Wed, 4 Aug 2010 08:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.885 X-Spam-Level: X-Spam-Status: No, score=0.885 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epGE8P541-Qr for ; Wed, 4 Aug 2010 08:15:45 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 102CD3A6BE0 for ; Wed, 4 Aug 2010 08:15:06 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.45 ; Wed, 4 Aug 2010 17:15:33 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.702.0; Wed, 4 Aug 2010 17:15:32 +0200 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, 4 Aug 2010 17:15:33 +0200 Message-ID: <8BC845943058D844ABFC73D2220D4665094CC248@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D4665094CC245@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Open Numbering Plan Thread-Index: Acso205AbmSBaG5cQqC7Gr1ZasdKWQLAx3jQAAEL51AAALggUA== References: <4C46FA74.7030403@nic.at><754963199212404AB8E9CFCA6C3D0CDA24490E47C9@TNS-MAIL-NA.win2k.corp.tnsi.com> <8BC845943058D844ABFC73D2220D4665094CC245@nics-mail.sbg.nic.at> From: Alexander Mayrhofer To: Alexander Mayrhofer , "Cartwright, Ken" , IETF DRINKS WG X-XWALL-BCKS: auto Subject: Re: [drinks] Open Numbering Plan X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:15:47 -0000 > I don't want to require ITU-T driven (or local regulator driven) > knowledge in network elements affect the semantics of objects in our > protocol. That just does not work. (WG chair hat still off, of course!) I'd like to go even one step further. I object to all "hidden" semantics in SPPP, based on external "background" information. SPPP should even be agnostic to the list of (currently) valid country codes.=20 For TNs in SPPP, everything should just be (E.164?) numbers. Hidden semantics should only be applied by local policy (for example, a registry could reject "prefix" type TN ranges in the NANP), but it should not be contained in the protocol. It's similar to how SMTP can be used to transport even emails using "invalid" top level domains. SMTP is agnostic to the root zone, and it's local policy of SMTP servers what to accept. Alex From kcartwright@tnsi.com Wed Aug 4 08:40:09 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565A53A6BFC for ; Wed, 4 Aug 2010 08:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.97 X-Spam-Level: X-Spam-Status: No, score=0.97 tagged_above=-999 required=5 tests=[AWL=-2.178, BAYES_40=-0.185, FB_IOW=3.333] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IYQ3En8zOWH for ; Wed, 4 Aug 2010 08:40:07 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 0477A3A6BF4 for ; Wed, 4 Aug 2010 08:39:41 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.46331311; Wed, 04 Aug 2010 11:39:45 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 4 Aug 2010 11:39:45 -0400 From: "Cartwright, Ken" To: Alexander Mayrhofer , IETF DRINKS WG Date: Wed, 4 Aug 2010 11:39:44 -0400 Thread-Topic: [drinks] Open Numbering Plan Thread-Index: Acso205AbmSBaG5cQqC7Gr1ZasdKWQLAx3jQAAEL51AAAgzp8A== Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24490E487D@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4C46FA74.7030403@nic.at> <754963199212404AB8E9CFCA6C3D0CDA24490E47C9@TNS-MAIL-NA.win2k.corp.tnsi.com> <8BC845943058D844ABFC73D2220D4665094CC245@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D4665094CC245@nics-mail.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] Open Numbering Plan X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:40:09 -0000 Ok. I'm sold. If there is a possible need to allow the "openness" of the = numbering plan to vary within a given country code, depending on who is pro= visioning the number(s), then we certainly need to move this out of policy = and into the protocol. Ken -----Original Message----- From: Alexander Mayrhofer [mailto:alexander.mayrhofer@nic.at] Sent: Wednesday, August 04, 2010 10:56 AM To: Cartwright, Ken; IETF DRINKS WG Subject: RE: [drinks] Open Numbering Plan > 1) The resolution server can/should be aware of each of the > country codes that adhere to an open numbering plan. It could. But i think this is out of scope of our work, since this would mean having to keep up to date with 200+ local regulators, and their actual policy (which, btw, might even vary by region). Plus, even in countries with an open numbering plan there might be specific number types that have an closed numbering plan. For example, it could be possible that geographic numbers follow an open numbering plan, while mobile numbers are of fixed lenght. Unfortunately, it's pretty complicated - don't get me started. > 2) The resolution server can/should, for country codes known > to have an open numbering plan, interpret an SPPP TNRange > within such a country code as being inclusive of TNs that may > be longer than the start and end point of the range. As a > result, the best match of the provisioned TNRanges will be > selected, even of the queried TN is longer than the best > matching TNRange. I think this is very risky. Such interpretation might vary over time, as countries change their numbering plans. Which would mean that if a country (or region of a country) changes their administrative model, the semantics of an SPPP object would change - withount a change in the protocol. I don't want to require ITU-T driven (or local regulator driven) knowledge in network elements affect the semantics of objects in our protocol. That just does not work. > Iow, afaik, there is *not* the need for the following in SPPP: > 1) For country codes that *do not* support an open numbering > plan, allow provisioning of a TNRange in that country code > and mark that TNRange as *an* "open number plan TNRange". > 2) For country codes that *do* support an open numbering > plan, allow provisioning of a TNRange in that country code > and mark that TNRange as *not an* "open number plan TNRange". I think that there is definitely the need for distinguishing "prefix" style TNs and TN ranges from "non-prefix" style TNs or TN ranges. Particularly because as outlined above, a country could very well mix open and non-open numbering ranges. > Making this a matter of policy would of course be superior to > embedding it in the protocol because the provisioning > activities will be simpler on the SPPP clients as well as the > SPPP servers. I think the contrary is true: Embedding a way to indicate whether a TN or TN range is of "prefix" style is superior to policy. Because the policy depends on external parties, which means that semantics of an object in SPPP could change over time, just because that external party changes the policy. Please please please make SPPP independent of ITU-T and regulatory policy. It's simple: +1813555666 - "plain" TN - does not include +18135556667 +4315056416 - "prefix" TN - *does* include +4315056416 (side note: have we defined tnrange yet?) "plain" TNRange - does not include +181355534377 +1813555000 +1813555999 "prefix" TNRange - *does* include +4315056416930 +4315056400 +4315056499 Alex 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 alexander.mayrhofer@nic.at Wed Aug 4 08:51:26 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC28A3A6892 for ; Wed, 4 Aug 2010 08:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.907 X-Spam-Level: X-Spam-Status: No, score=0.907 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWmF2mZ3yHh0 for ; Wed, 4 Aug 2010 08:51:24 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 3116D3A6872 for ; Wed, 4 Aug 2010 08:50:56 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.45 ; Wed, 4 Aug 2010 17:51:23 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.702.0; Wed, 4 Aug 2010 17:51:22 +0200 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, 4 Aug 2010 17:51:23 +0200 Message-ID: <8BC845943058D844ABFC73D2220D4665094CC252@nics-mail.sbg.nic.at> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA24490E487D@TNS-MAIL-NA.win2k.corp.tnsi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] Open Numbering Plan Thread-Index: Acso205AbmSBaG5cQqC7Gr1ZasdKWQLAx3jQAAEL51AAAgzp8AAAfkjw References: <4C46FA74.7030403@nic.at> <754963199212404AB8E9CFCA6C3D0CDA24490E47C9@TNS-MAIL-NA.win2k.corp.tnsi.com> <8BC845943058D844ABFC73D2220D4665094CC245@nics-mail.sbg.nic.at> <754963199212404AB8E9CFCA6C3D0CDA24490E487D@TNS-MAIL-NA.win2k.corp.tnsi.com> From: Alexander Mayrhofer To: "Cartwright, Ken" , IETF DRINKS WG X-XWALL-BCKS: auto Subject: Re: [drinks] Open Numbering Plan X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:51:27 -0000 > Ok. I'm sold.=20 That was quick. I actually prepared myself for multiple 100+ messages long thread ;) Alex From kcartwright@tnsi.com Wed Aug 4 08:52:40 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F3D3A688F for ; Wed, 4 Aug 2010 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmOyI3UuenGA for ; Wed, 4 Aug 2010 08:52:39 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 08FE828C0D6 for ; Wed, 4 Aug 2010 08:52:34 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.46331862; Wed, 04 Aug 2010 11:53:02 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 4 Aug 2010 11:53:02 -0400 From: "Cartwright, Ken" To: Alexander Mayrhofer , IETF DRINKS WG Date: Wed, 4 Aug 2010 11:53:02 -0400 Thread-Topic: [drinks] Open Numbering Plan Thread-Index: Acso205AbmSBaG5cQqC7Gr1ZasdKWQLAx3jQAAEL51AAALggUAABcipQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24490E48A2@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4C46FA74.7030403@nic.at><754963199212404AB8E9CFCA6C3D0CDA24490E47C9@TNS-MAIL-NA.win2k.corp.tnsi.com> <8BC845943058D844ABFC73D2220D4665094CC245@nics-mail.sbg.nic.at> <8BC845943058D844ABFC73D2220D4665094CC248@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D4665094CC248@nics-mail.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] Open Numbering Plan X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:52:40 -0000 I think I agree with your statements below, but... SMTP as a set of data structures does of course not imply much (if any) mea= ningful provisioning policy. However, the applications that manage and pro= vision email addresses and *use* SMTP under the covers apply all sorts of p= olicies. A more appropriate analogy here than SMTP I think is EPP and a domain name = provisioning system. All systems that use EPP, both as clients and server = apply all sorts of policies to control what domain names are/canBe provisio= ned using EPP, what those domain names can look like, what words those doma= in names can contain, when they can be provisioned, when and how they can b= e deleted, when and how they can be modified, when and how they can be rene= wed, etc, etc. SPPP clients and servers are highly likely to apply policie= s that rely on external "background" information. But this has little to d= o with EPP. Ken -----Original Message----- From: Alexander Mayrhofer [mailto:alexander.mayrhofer@nic.at] Sent: Wednesday, August 04, 2010 11:16 AM To: Alexander Mayrhofer; Cartwright, Ken; IETF DRINKS WG Subject: RE: [drinks] Open Numbering Plan > I don't want to require ITU-T driven (or local regulator driven) > knowledge in network elements affect the semantics of objects in our > protocol. That just does not work. (WG chair hat still off, of course!) I'd like to go even one step further. I object to all "hidden" semantics in SPPP, based on external "background" information. SPPP should even be agnostic to the list of (currently) valid country codes. For TNs in SPPP, everything should just be (E.164?) numbers. Hidden semantics should only be applied by local policy (for example, a registry could reject "prefix" type TN ranges in the NANP), but it should not be contained in the protocol. It's similar to how SMTP can be used to transport even emails using "invalid" top level domains. SMTP is agnostic to the root zone, and it's local policy of SMTP servers what to accept. Alex 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 jf.mule@cablelabs.com Wed Aug 4 15:08:37 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3563A6907 for ; Wed, 4 Aug 2010 15:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.672 X-Spam-Level: X-Spam-Status: No, score=-98.672 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8ma+0LHSg-b for ; Wed, 4 Aug 2010 15:08:36 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id BBEDE3A69DB for ; Wed, 4 Aug 2010 15:08:35 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o74M96Jr007283; Wed, 4 Aug 2010 16:09:07 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 4 Aug 2010 16:09:04 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 4 Aug 2010 16:09:04 -0600 From: Jean-Francois Mule To: Richard Shockey Date: Wed, 4 Aug 2010 16:09:01 -0600 Thread-Topic: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) Thread-Index: Acs0IaZYyeEV4DoVQGeMcWemn8qyFA== Message-ID: References: <021601cb2f81$00ce7c50$026b74f0$@us> In-Reply-To: <021601cb2f81$00ce7c50$026b74f0$@us> 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_EEA8CB2A62DB4671A5BF0A2712499BC5cablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: "drinks@ietf.org" Subject: Re: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 22:08:37 -0000 --_000_EEA8CB2A62DB4671A5BF0A2712499BC5cablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rich, I'd like to say thanks to you Rich as well. Thank you for your impulse in getting the BoFs going and WG established = and for your efforts in guiding us through the first deliverables. Jean-Francois. On Jul30 2010, at 02:49, Richard Shockey wrote: Due to professional considerations I=92ve decided I cannot properly continu= e to act as DRINKS Co-Chair. I have informed the AD=92s of this fact and they will announce a new Co-Cha= ir shortly. That does not mean that I do not have a ongoing interest in this work. I wi= ll continue to monitor this work closely, if from afar. I remain convinced DRINKS is essential to the deployment of global databa= ses that can end the plague of SS7 on planet Earth. I thank all the members of this WG for their support and continuing work. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks --_000_EEA8CB2A62DB4671A5BF0A2712499BC5cablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Rich,

  = ; I'd like to say thanks to you Rich as well.  

&nbs= p;  Thank you for your impulse in getting the BoFs going and WG establ= ished and for your efforts in guiding us through the first deliverables.
      
Jean-Francois.=
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 10px/normal Arial; color: rgb(85, 14= 6, 203); ">
<= /div>
On Jul30 2010, at 02:49, Richard Shockey wrote:

Due to professional co= nsiderations I=92ve decided I cannot properly continue to act as DRINKS Co-= Chair.
 
I have informed the AD=92s of this fa= ct and they will announce a new Co-Chair shortly.
 
That does not mean that I do not have a ongoing interest in this work= . I will continue to monitor this work closely, if from afar.
<= o:p> 
 I remain convinced DRINKS  is essential to the= deployment of global databases that can end the plague of SS7 on planet Ea= rth.
 
I thank all the members of this WG for = their support and continuing work.

Richard Shockey<= br>Shockey Consulting
Chairman of the Board of Directors SIP Forum
PS= TN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype: rshockey101LinkedIn : http://www.linkedin.com/in/rsh= ockey101
http//www.sipforum.org

&n= bsp;
_______________________________________________
dr= inks mailing list
drinks@ietf.org
https://www.ietf.org/mailman/listinfo/drinks

= --_000_EEA8CB2A62DB4671A5BF0A2712499BC5cablelabscom_-- From sumanth@cablelabs.com Wed Aug 4 15:23:46 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12A53A6AA6 for ; Wed, 4 Aug 2010 15:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.83 X-Spam-Level: X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyEp8y14zROu for ; Wed, 4 Aug 2010 15:23:41 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 0C0BC3A68DD for ; Wed, 4 Aug 2010 15:23:40 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o74MOCQ6008539; Wed, 4 Aug 2010 16:24:12 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 4 Aug 2010 16:24:10 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 4 Aug 2010 16:24:10 -0600 From: Sumanth Channabasappa To: Jean-Francois Mule , Richard Shockey Date: Wed, 4 Aug 2010 16:24:23 -0600 Thread-Topic: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) Thread-Index: Acs0IaZYyeEV4DoVQGeMcWemn8qyFAAAYBpQ Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF50486E7@srvxchg> References: <021601cb2f81$00ce7c50$026b74f0$@us> 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_76AC5FEF83F1E64491446437EA81A61F7CF50486E7srvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "drinks@ietf.org" Subject: Re: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 22:23:46 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7CF50486E7srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Thanks Rich for your leadership, contributions and expert advice thus far. = I am sure you will continue to be involved in the efforts going forward... ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Jean-Francois Mule Sent: Wednesday, August 04, 2010 4:09 PM To: Richard Shockey Cc: drinks@ietf.org Subject: Re: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) Rich, I'd like to say thanks to you Rich as well. Thank you for your impulse in getting the BoFs going and WG established = and for your efforts in guiding us through the first deliverables. Jean-Francois. On Jul30 2010, at 02:49, Richard Shockey wrote: Due to professional considerations I've decided I cannot properly continue = to act as DRINKS Co-Chair. I have informed the AD's of this fact and they will announce a new Co-Chair= shortly. That does not mean that I do not have a ongoing interest in this work. I wi= ll continue to monitor this work closely, if from afar. I remain convinced DRINKS is essential to the deployment of global databa= ses that can end the plague of SS7 on planet Earth. I thank all the members of this WG for their support and continuing work. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks --_000_76AC5FEF83F1E64491446437EA81A61F7CF50486E7srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= BASE=20 href=3D"x-msg://141/">

+1

Thanks Rich for your leadership,=20 contributions and expert advice thus far. I am sure you will continue to be= =20 involved in the efforts going forward...

 


From: drinks-bounces@ietf.org=20 [mailto:drinks-bounces@ietf.org] On Behalf Of Jean-Francois=20 Mule
Sent: Wednesday, August 04, 2010 4:09 PM
To: Richa= rd=20 Shockey
Cc: drinks@ietf.org
Subject: Re: [drinks] Thank= you=20 Rich (was: Resigning as WG Co-Chair)


Rich,

&nb= sp; =20 I'd like to say thanks to you Rich as well.  

&nb= sp; =20 Thank you for your impulse in getting the BoFs going and WG established and= for=20 your efforts in guiding us through the first=20 deliverables.
&nb= sp; =20    
Jean-Francois.

On Jul30 2010, at 02:49, Richard Shockey wrote:
Due=20 to professional considerations I’ve decided I cannot properly conti= nue to act=20 as DRINKS Co-Chair.
I=20 have informed the AD’s of this fact and they will announce a new Co= -Chair=20 shortly.
That=20 does not mean that I do not have a ongoing interest in this work. I will= =20 continue to monitor this work closely, if from afar.  I=20 remain convinced DRINKS  is essential to the deployment of global=20 databases that can end the plague of SS7 on planet Earth. I=20 thank all the members of this WG for their support and continuing=20 work. Richard= =20 Shockey
Shockey Consulting
Chairman of the Board of Directors SIP=20 Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skyp= e:=20 rshockey101
LinkedIn : http://www.linkedin.com/in/rshockey101http//www.sipforum.org

____________________________________________= ___
drinks=20 mailing list
drinks@ietf.org
https://www.ietf.or= g/mailman/listinfo/drinks

--_000_76AC5FEF83F1E64491446437EA81A61F7CF50486E7srvxchg_-- From richard@shockey.us Wed Aug 4 15:26:12 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4411D3A6A89 for ; Wed, 4 Aug 2010 15:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.742 X-Spam-Level: X-Spam-Status: No, score=-100.742 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_20=-0.74, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CisausuI6DUU for ; Wed, 4 Aug 2010 15:26:07 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 8C6203A68DD for ; Wed, 4 Aug 2010 15:26:07 -0700 (PDT) Received: (qmail 21666 invoked by uid 0); 4 Aug 2010 22:26:37 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 4 Aug 2010 22:26:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=BxMwQj2PeYD4OQaUdfKRMU4fSt3FJHBM9lyLHVK0r95NWrOURKsWdT9SywMUQlH++7ic8Ur2b1jclabmsMMG3BRuiSMKitl+4ncBXGgs3asP496Idgdj0g9DgsYbplCh; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OgmQ0-0002L0-Nl; Wed, 04 Aug 2010 16:26:37 -0600 From: "Richard Shockey" To: "'Sumanth Channabasappa'" , "'Jean-Francois Mule'" References: <021601cb2f81$00ce7c50$026b74f0$@us> <76AC5FEF83F1E64491446437EA81A61F7CF50486E7@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF50486E7@srvxchg> Date: Wed, 4 Aug 2010 18:26:34 -0400 Message-ID: <00e301cb3424$19258f30$4b70ad90$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E4_01CB3402.9213EF30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs0IaZYyeEV4DoVQGeMcWemn8qyFAAAYBpQAAA4D7A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: drinks@ietf.org Subject: Re: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 22:26:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E4_01CB3402.9213EF30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You are not going to get rid of me that easily J From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com] Sent: Wednesday, August 04, 2010 6:24 PM To: Jean-Francois Mule; Richard Shockey Cc: drinks@ietf.org Subject: RE: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) +1 Thanks Rich for your leadership, contributions and expert advice thus far. I am sure you will continue to be involved in the efforts going forward... _____ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Jean-Francois Mule Sent: Wednesday, August 04, 2010 4:09 PM To: Richard Shockey Cc: drinks@ietf.org Subject: Re: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) Rich, I'd like to say thanks to you Rich as well. Thank you for your impulse in getting the BoFs going and WG established and for your efforts in guiding us through the first deliverables. Jean-Francois. On Jul30 2010, at 02:49, Richard Shockey wrote: Due to professional considerations I've decided I cannot properly continue to act as DRINKS Co-Chair. I have informed the AD's of this fact and they will announce a new Co-Chair shortly. That does not mean that I do not have a ongoing interest in this work. I will continue to monitor this work closely, if from afar. I remain convinced DRINKS is essential to the deployment of global databases that can end the plague of SS7 on planet Earth. I thank all the members of this WG for their support and continuing work. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks ------=_NextPart_000_00E4_01CB3402.9213EF30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You are not going to get rid of me that easily = J

 

From:= Sumanth Channabasappa [mailto:sumanth@cablelabs.com]
Sent: Wednesday, August 04, 2010 6:24 PM
To: Jean-Francois Mule; Richard Shockey
Cc: drinks@ietf.org
Subject: RE: [drinks] Thank you Rich (was: Resigning as WG = Co-Chair)

 

+1

Thanks Rich for your leadership, contributions = and expert advice thus far. I am sure you will continue to be involved in the = efforts going forward...

 

 

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Jean-Francois = Mule
Sent: Wednesday, August 04, 2010 4:09 PM
To: Richard Shockey
Cc: drinks@ietf.org
Subject: Re: [drinks] Thank you Rich (was: Resigning as WG = Co-Chair)

 

Rich,=

 

   I'd like to = say thanks to you Rich as well.  

 

   Thank you for = your impulse in getting the BoFs going and WG established and for your = efforts in guiding us through the first deliverables.<= /p>

     =  =

Jean-Francois.=

 

On Jul30 2010, at 02:49, Richard Shockey = wrote:



Due to professional considerations I’ve decided I cannot properly = continue to act as DRINKS Co-Chair.

I have informed the AD’s of this fact and they will announce a new = Co-Chair shortly.

That does not mean that I do not have a ongoing interest in this work. I will continue to monitor this work closely, if from = afar.

 I remain convinced DRINKS  is essential to the deployment of global databases that can end the plague of SS7 on planet = Earth.

I thank all the members of this WG for their support and continuing = work.

Richard Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>= ;
skype: rshockey101
LinkedIn : http://www.linkedin.com/i= n/rshockey101
http//www.sipforum.org=

_____________= __________________________________
drinks mailing list
drinks@ietf.org
https://www.ietf.or= g/mailman/listinfo/drinks

 

------=_NextPart_000_00E4_01CB3402.9213EF30-- From sumanth@cablelabs.com Wed Aug 4 15:28:59 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC1A3A69ED for ; Wed, 4 Aug 2010 15:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.707 X-Spam-Level: X-Spam-Status: No, score=0.707 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVROBcQYpowi for ; Wed, 4 Aug 2010 15:28:58 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 32F3A3A6970 for ; Wed, 4 Aug 2010 15:28:58 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o74MTKS8008964; Wed, 4 Aug 2010 16:29:21 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 4 Aug 2010 16:29:18 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 4 Aug 2010 16:29:19 -0600 From: Sumanth Channabasappa To: Gonzalo Camarillo , "drinks@ietf.org" Date: Wed, 4 Aug 2010 16:29:31 -0600 Thread-Topic: Resigning as WG Co-Chair Thread-Index: Acsy7j8IOuy5z/zERNCdAKW6mgktuQBNc0Aw Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF50486E9@srvxchg> References: <021601cb2f81$00ce7c50$026b74f0$@us> <4C57E133.7090904@ericsson.com> In-Reply-To: <4C57E133.7090904@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: Richard Shockey Subject: Re: [drinks] Resigning as WG Co-Chair X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 22:28:59 -0000 Gonzalo, Alex, WG,=20 Thanks for the opportunity. I look forward to the continued collaboration w= ithin this WG, as we progress towards completing our goals. - S =20 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Tuesday, August 03, 2010 3:28 AM To: drinks@ietf.org Cc: Richard Shockey; 'Robert Sparks'; alexander.mayrhofer@enum.at; Sumanth = Channabasappa Subject: Re: Resigning as WG Co-Chair Hi, we would like to thank Richard for all his work chairing this working group= during all these years. As Alex presented in Maastricht, the plan is to cl= ose down this WG by the spring IETF. Nevertheless, we would like to have tw= o chairs until then. So, Sumanth will be cochairing this group with Alex fr= om now until its closure. We would like to thank Sumanth for volunteering t= o do this. Cheers, Gonzalo On 30/07/2010 3:49 AM, Richard Shockey wrote: > Due to professional considerations I've decided I cannot properly=20 > continue to act as DRINKS Co-Chair. >=20 > =20 >=20 > I have informed the AD's of this fact and they will announce a new=20 > Co-Chair shortly. >=20 > =20 >=20 > That does not mean that I do not have a ongoing interest in this work.=20 > I will continue to monitor this work closely, if from afar. >=20 > =20 >=20 > I remain convinced DRINKS is essential to the deployment of global=20 > databases that can end the plague of SS7 on planet Earth. >=20 > =20 >=20 > I thank all the members of this WG for their support and continuing work. >=20 > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum PSTN Mobile: +1=20 > 703.593.2683 > skype: rshockey101 > LinkedIn : http://www.linkedin.com/in/rshockey101 > http//www.sipforum.org >=20 > =20 >=20 From sumanth@cablelabs.com Wed Aug 4 15:30:48 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCAE83A6A40 for ; Wed, 4 Aug 2010 15:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.739 X-Spam-Level: X-Spam-Status: No, score=0.739 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJjN+yuEWuRF for ; Wed, 4 Aug 2010 15:30:41 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id EA5C03A6A87 for ; Wed, 4 Aug 2010 15:30:39 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o74MVAtE009137; Wed, 4 Aug 2010 16:31:10 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 4 Aug 2010 16:31:08 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 4 Aug 2010 16:31:09 -0600 From: Sumanth Channabasappa To: Richard Shockey , Jean-Francois Mule Date: Wed, 4 Aug 2010 16:31:20 -0600 Thread-Topic: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) Thread-Index: Acs0IaZYyeEV4DoVQGeMcWemn8qyFAAAYBpQAAA4D7AAACjqIA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF50486EC@srvxchg> References: <021601cb2f81$00ce7c50$026b74f0$@us> <76AC5FEF83F1E64491446437EA81A61F7CF50486E7@srvxchg> <00e301cb3424$19258f30$4b70ad90$@us> In-Reply-To: <00e301cb3424$19258f30$4b70ad90$@us> 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_76AC5FEF83F1E64491446437EA81A61F7CF50486ECsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "drinks@ietf.org" Subject: Re: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 22:30:49 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7CF50486ECsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There you are! :) So let's talk Global SPID .... - S ________________________________ From: Richard Shockey [mailto:richard@shockey.us] Sent: Wednesday, August 04, 2010 4:27 PM To: Sumanth Channabasappa; Jean-Francois Mule Cc: drinks@ietf.org Subject: RE: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) You are not going to get rid of me that easily :) From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com] Sent: Wednesday, August 04, 2010 6:24 PM To: Jean-Francois Mule; Richard Shockey Cc: drinks@ietf.org Subject: RE: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) +1 Thanks Rich for your leadership, contributions and expert advice thus far. = I am sure you will continue to be involved in the efforts going forward... ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Jean-Francois Mule Sent: Wednesday, August 04, 2010 4:09 PM To: Richard Shockey Cc: drinks@ietf.org Subject: Re: [drinks] Thank you Rich (was: Resigning as WG Co-Chair) Rich, I'd like to say thanks to you Rich as well. Thank you for your impulse in getting the BoFs going and WG established = and for your efforts in guiding us through the first deliverables. Jean-Francois. On Jul30 2010, at 02:49, Richard Shockey wrote: Due to professional considerations I've decided I cannot properly continue = to act as DRINKS Co-Chair. I have informed the AD's of this fact and they will announce a new Co-Chair= shortly. That does not mean that I do not have a ongoing interest in this work. I wi= ll continue to monitor this work closely, if from afar. I remain convinced DRINKS is essential to the deployment of global databa= ses that can end the plague of SS7 on planet Earth. I thank all the members of this WG for their support and continuing work. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks --_000_76AC5FEF83F1E64491446437EA81A61F7CF50486ECsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There you are! :) So let's talk Global SPID=20 ....
 
- S

From: Richard Shockey=20 [mailto:richard@shockey.us]
Sent: Wednesday, August 04, 2010 4:2= 7=20 PM
To: Sumanth Channabasappa; Jean-Francois Mule
Cc:=20 drinks@ietf.org
Subject: RE: [drinks] Thank you Rich (was: Resign= ing=20 as WG Co-Chair)

You=20 are not going to get rid of me that easily J<= SPAN=20 style=3D"FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11= pt">=20

 

From:<= /B> Sumanth=20 Channabasappa [mailto:sumanth@cablelabs.com]
Sent: Wednesday, Au= gust=20 04, 2010 6:24 PM
To: Jean-Francois Mule; Richard Shockey
Cc= :=20 drinks@ietf.org
Subject: RE: [drinks] Thank you Rich (was: Resign= ing=20 as WG Co-Chair)

 

+1

Thanks Rich for your leadership, contributions and = expert=20 advice thus far. I am sure you will continue to be involved in the efforts = going=20 forward...

 

 

From:<= /B>=20 drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of=20 Jean-Francois Mule
Sent: Wednesday, August 04, 2010 4:09=20 PM
To: Richard Shockey
Cc:=20 drinks@ietf.org
Subject: Re: [drinks] Thank you Rich (was: Resign= ing=20 as WG Co-Chair)

 

R= ich,

 

&= nbsp; =20 I'd like to say thanks to you Rich as well.  

 

&= nbsp; =20 Thank you for your impulse in getting the BoFs going and WG established and= for=20 your efforts in guiding us through the first deliverables.

&= nbsp; =20    

J= ean-Francois.

 

On Jul30 2010, at 02:49, Richard Shockey=20 wrote:



Due to profe= ssional=20 considerations I’ve decided I cannot properly continue to act as DRIN= KS=20 Co-Chair.

I have infor= med the=20 AD’s of this fact and they will announce a new Co-Chair=20 shortly.

That does no= t mean=20 that I do not have a ongoing interest in this work. I will continue to moni= tor=20 this work closely, if from afar.

 I rema= in=20 convinced DRINKS  is essential to the deployment of global databases t= hat=20 can end the plague of SS7 on planet Earth.

I thank all = the=20 members of this WG for their support and continuing=20 work.

Richard Shockey
Shockey Consulting
Chairman= of the=20 Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us><= BR>skype:=20 rshockey101
LinkedIn : <= A=20 href=3D"http://www.linkedin.com/in/rshockey101">http://www.linkedin.com/in/= rshockey101
http//www.sipforum.org<= /SPAN>

____________= ___________________________________
drinks=20 mailing list
drinks@ietf.org
<= A=20 href=3D"https://www.ietf.org/mailman/listinfo/drinks">https://www.ietf.org/= mailman/listinfo/drinks

 

--_000_76AC5FEF83F1E64491446437EA81A61F7CF50486ECsrvxchg_-- From wwwrun@core3.amsl.com Wed Aug 4 08:13:00 2010 Return-Path: X-Original-To: drinks@ietf.org Delivered-To: drinks@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id DF4433A6BAA; Wed, 4 Aug 2010 08:13:00 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100804151300.DF4433A6BAA@core3.amsl.com> Date: Wed, 4 Aug 2010 08:13:00 -0700 (PDT) X-Mailman-Approved-At: Tue, 10 Aug 2010 08:37:57 -0700 Cc: drinks@ietf.org Subject: [drinks] DRINKS interim meeting, September 15, 2010 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:13:01 -0000 The DRINKS working group will hold an interim WG meeting (face to face) on September 15th 2010, 9am-5pm MDT. The meeting will be hosted by Cablelabs, and will take place in Colorado, US. More details and an agenda will be posted on drinks@ietf.org soon. Remote participation will be possible via a phone conferencing system and the jabber room. Sumanth & Alex DRINKS WG chairs From syed.ali@neustar.biz Sun Aug 15 16:36:19 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F344B3A67D1 for ; Sun, 15 Aug 2010 16:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozaFTvAXcvDo for ; Sun, 15 Aug 2010 16:36:17 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 23C893A65A5 for ; Sun, 15 Aug 2010 16:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1281915407; x=1597268681; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=rQUQ9k+2ciBWEKsIvcFob0sx61rRvbWa2KVDSaN+/EY=; b=pt27Rcc7bQOIA07VuYdjAWaqoMfHtcvgd2cz7VOzs3pUa69lBWatdLPg8f5rSc bULxmXBqm6UA5SJ/25T0v7PQ== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.28521575; Sun, 15 Aug 2010 19:36:46 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Sun, 15 Aug 2010 19:36:46 -0400 From: "Ali, Syed Wasim" To: Kenneth Cartwright , Jean-Francois Mule Date: Sun, 15 Aug 2010 19:33:13 -0400 Thread-Topic: update to CORInfoType Thread-Index: Acs80jpajVTytdNW50uMweQLDL/agQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: CGael3bcyWdflJxtGaAwsA== Content-Type: multipart/mixed; boundary="_008_C88DF18442812syedalineustarbiz_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: [drinks] update to CORInfoType X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 23:36:19 -0000 --_008_C88DF18442812syedalineustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, 'corClaim' attribute is meant to assist the registrant in making the carrier-of-record claim for a given TN public identity. However, 'cor' attribute is meant to be included in the response message to help the SPPP server confirm, or not, whether if the registrant is in fact the carrier-of-record. My understanding is that these two elements are not to b= e used together in a message. Current definition of CORInfoType in the SP schema requires both 'corClaim' and 'cor' elements, with an unintended effect that both of these elements are now required for the add public identifier (TN) request. I am suggesting the following change to make sure that when CORInfoType is included in a message, a choice of either 'corClaim' or 'cor', and not the inclusion of both attributes, is enforced. In addition, the Registry often have the carrier-of-record data (TN block assignee list, NP data, etc.) available to make ad hoc decisions as to whether the registrant's claim to be a carrier-of-record can be honored. I think it is desirable to have the option to return the carrier-of-record claim result in the sppp response that corresponds to the request. I made some changes in the attached schema to support this option. Lastly, attached is the updated schema and the examples that reflect the changes discussed above. -Syed=20 --_008_C88DF18442812syedalineustarbiz_ Content-Type: application/octet-stream; name="sppp.xsd" Content-Description: sppp.xsd Content-Disposition: attachment; filename="sppp.xsd"; size=21630; creation-date="Sun, 15 Aug 2010 19:36:45 GMT"; modification-date="Sun, 15 Aug 2010 19:36:45 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNjaGVtYSB4bWxuczpzcHBw Yj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSIKICB4bWxucz0iaHR0cDovL3d3 dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiCiAgdGFyZ2V0TmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnNwcHA6YmFzZToxIgogIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIiB4 bWw6bGFuZz0iRU4iPgogIDxhbm5vdGF0aW9uPgogICAgPGRvY3VtZW50YXRpb24+IC0tLS0tLS0t LS0tLS0tLS0tLSBPYmplY3QgVHlwZSBEZWZpbml0aW9ucwogICAgICAtLS0tLS0tLS0tLS0tLSA8 L2RvY3VtZW50YXRpb24+CiAgPC9hbm5vdGF0aW9uPgogIDxjb21wbGV4VHlwZSBuYW1lPSJSdGVH cnBUeXBlIj4KICAgIDxzZXF1ZW5jZT4KICAgICAgPGVsZW1lbnQgbmFtZT0iYmFzZSIgdHlwZT0i c3BwcGI6QmFzaWNPYmpUeXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9InJ0ZUdycE5hbWUiIHR5 cGU9InNwcHBiOk9iak5hbWVUeXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9InJ0ZVJlYyIgdHlw ZT0ic3BwcGI6UnRlUmVjVHlwZSIgbWluT2NjdXJzPSIwIgogICAgICAgIG1heE9jY3Vycz0idW5i b3VuZGVkIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9ImRnTmFtZSIgdHlwZT0ic3BwcGI6T2JqTmFt ZVR5cGUiIG1pbk9jY3Vycz0iMCIKICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAg ICA8ZWxlbWVudCBuYW1lPSJwZWVyaW5nT3JnIiB0eXBlPSJzcHBwYjpPcmdJZFR5cGUiIG1pbk9j Y3Vycz0iMCIKICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICA8ZWxlbWVudCBu YW1lPSJzb3VyY2VJZGVudCIgdHlwZT0ic3BwcGI6U291cmNlSWRlbnRUeXBlIgogICAgICAgIG1p bk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0i aXNJblN2YyIgdHlwZT0iYm9vbGVhbiIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJleHQiIHR5cGU9 InNwcHBiOkV4dEFueVR5cGUiIG1pbk9jY3Vycz0iMCIvPgogICAgPC9zZXF1ZW5jZT4KICA8L2Nv bXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJEZXN0R3JwVHlwZSI+CiAgICA8c2VxdWVu Y2U+CiAgICAgIDxlbGVtZW50IG5hbWU9ImJhc2UiIHR5cGU9InNwcHBiOkJhc2ljT2JqVHlwZSIv PgogICAgICA8ZWxlbWVudCBuYW1lPSJkZ05hbWUiIHR5cGU9InNwcHBiOk9iak5hbWVUeXBlIi8+ CiAgICA8L3NlcXVlbmNlPgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IlB1 YklkVHlwZSIgYWJzdHJhY3Q9InRydWUiPgogICAgPHNlcXVlbmNlPgogICAgICA8ZWxlbWVudCBu YW1lPSJiYXNlIiB0eXBlPSJzcHBwYjpCYXNpY09ialR5cGUiLz4KICAgICAgPGVsZW1lbnQgbmFt ZT0iZGdOYW1lIiB0eXBlPSJzcHBwYjpPYmpOYW1lVHlwZSIgbWluT2NjdXJzPSIwIi8+CiAgICAg IDxlbGVtZW50IG5hbWU9InJ0ZVJlYyIgdHlwZT0ic3BwcGI6UnRlUmVjVHlwZSIgbWluT2NjdXJz PSIwIgogICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICA8L3NlcXVlbmNlPgogIDwv Y29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IkVtYWlsVHlwZSI+CiAgICA8Y29tcGxl eENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6UHViSWRUeXBlIj4KICAgICAg ICA8c2VxdWVuY2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJlbWFpbCIgdHlwZT0ic3RyaW5n Ii8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhD b250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IlROVHlwZSI+CiAg ICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6UHViSWRUeXBl Ij4KICAgICAgICA8c2VxdWVuY2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJ0biIgdHlwZT0i c3RyaW5nIi8+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJjb3JJbmZvIiB0eXBlPSJzcHBwYjpD T1JJbmZvVHlwZSIKICAgICAgICAgICAgbWluT2NjdXJzPSIwIi8+CiAgICAgICAgPC9zZXF1ZW5j ZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5 cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IlROUlR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50Pgog ICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOlROVHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgog ICAgICAgICAgPGVsZW1lbnQgbmFtZT0iZW5kVG4iIHR5cGU9InN0cmluZyIvPgogICAgICAgICAg PGVsZW1lbnQgbmFtZT0iY29ySW5mbyIgdHlwZT0ic3BwcGI6Q09SSW5mb1R5cGUiCiAgICAgICAg ICAgIG1pbk9jY3Vycz0iMCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9u PgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBu YW1lPSJSTlR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9 InNwcHBiOlB1YklkVHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQg bmFtZT0icm4iIHR5cGU9InN0cmluZyIgZGVmYXVsdD0idHJ1ZSIvPgogICAgICAgIDwvc2VxdWVu Y2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhU eXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJOQVBUUlR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50 PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOlJ0ZVJlY1R5cGUiPgogICAgICAgIDxzZXF1 ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9Im9yZGVyIiB0eXBlPSJ1bnNpZ25lZFNob3J0 Ii8+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJwcmVmIiB0eXBlPSJ1bnNpZ25lZFNob3J0Ii8+ CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJmbGFncyIgdHlwZT0ic3RyaW5nIiBtaW5PY2N1cnM9 IjAiLz4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InN2Y3MiIHR5cGU9InN0cmluZyIvPgogICAg ICAgICAgPGVsZW1lbnQgbmFtZT0icmVneCIgdHlwZT0ic3BwcGI6UmVnZXhQYXJhbVR5cGUiCiAg ICAgICAgICAgIG1pbk9jY3Vycz0iMCIvPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0icmVwbCIg dHlwZT0ic3RyaW5nIiBtaW5PY2N1cnM9IjAiLz4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InR0 bCIgdHlwZT0icG9zaXRpdmVJbnRlZ2VyIiBtaW5PY2N1cnM9IjAiLz4KICAgICAgICAgIDxlbGVt ZW50IG5hbWU9ImV4dCIgdHlwZT0ic3BwcGI6RXh0QW55VHlwZSIgbWluT2NjdXJzPSIwIi8+CiAg ICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250ZW50 PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9Ik5TVHlwZSI+CiAgICA8Y29t cGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6UnRlUmVjVHlwZSI+CiAg ICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0iaG9zdE5hbWUiIHR5cGU9 InN0cmluZyIvPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0iaXBBZGRyIiB0eXBlPSJzcHBwYjpJ UEFkZHJUeXBlIiBtaW5PY2N1cnM9IjAiCiAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVk Ii8+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJ0dGwiIHR5cGU9InBvc2l0aXZlSW50ZWdlciIg bWluT2NjdXJzPSIwIi8+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJleHQiIHR5cGU9InNwcHBi OkV4dEFueVR5cGUiIG1pbk9jY3Vycz0iMCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwv ZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21w bGV4VHlwZSBuYW1lPSJVUklUeXBlIj4KICAgIDxjb21wbGV4Q29udGVudD4KICAgICAgPGV4dGVu c2lvbiBiYXNlPSJzcHBwYjpSdGVSZWNUeXBlIj4KICAgICAgICA8c2VxdWVuY2U+CiAgICAgICAg ICA8ZWxlbWVudCBuYW1lPSJlcmUiIHR5cGU9InN0cmluZyIgZGVmYXVsdD0iXiguKikkIi8+CiAg ICAgICAgICA8ZWxlbWVudCBuYW1lPSJ1cmkiIHR5cGU9InN0cmluZyIvPgogICAgICAgICAgPGVs ZW1lbnQgbmFtZT0iZXh0IiB0eXBlPSJzcHBwYjpFeHRBbnlUeXBlIiBtaW5PY2N1cnM9IjAiLz4K ICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRl bnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iUnRlR3JwT2ZmZXJUeXBl Ij4KICAgIDxzZXF1ZW5jZT4KICAgICAgPGVsZW1lbnQgbmFtZT0iYmFzZSIgdHlwZT0ic3BwcGI6 QmFzaWNPYmpUeXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9InJ0ZUdycE9mZmVyS2V5IiB0eXBl PSJzcHBwYjpSdGVHcnBPZmZlcktleVR5cGUiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0ic3RhdHVz IiB0eXBlPSJzcHBwYjpSdGVHcnBPZmZlclN0YXR1c1R5cGUiLz4KICAgICAgPGVsZW1lbnQgbmFt ZT0ib2ZmZXJEYXRlVGltZSIgdHlwZT0iZGF0ZVRpbWUiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0i YWNjZXB0RGF0ZVRpbWUiIHR5cGU9ImRhdGVUaW1lIiBtaW5PY2N1cnM9IjAiLz4KICAgICAgPGVs ZW1lbnQgbmFtZT0iZXh0IiB0eXBlPSJzcHBwYjpFeHRBbnlUeXBlIiBtaW5PY2N1cnM9IjAiLz4K ICAgIDwvc2VxdWVuY2U+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iRWdy UnRlVHlwZSI+CiAgICA8c2VxdWVuY2U+CiAgICAgIDxlbGVtZW50IG5hbWU9ImJhc2UiIHR5cGU9 InNwcHBiOkJhc2ljT2JqVHlwZSIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJlZ3JSdGVOYW1lIiB0 eXBlPSJzcHBwYjpPYmpOYW1lVHlwZSIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJwcmVmIiB0eXBl PSJ1bnNpZ25lZFNob3J0Ii8+CiAgICAgIDxlbGVtZW50IG5hbWU9InN2Y3MiIHR5cGU9InN0cmlu ZyIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJyZWd4UmV3cml0ZVJ1bGUiIHR5cGU9InNwcHBiOlJl Z2V4UGFyYW1UeXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9ImluZ3Jlc3NSdGUiIHR5cGU9InNw cHBiOk9iaktleVR5cGUiIG1pbk9jY3Vycz0iMCIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJleHQi IHR5cGU9InNwcHBiOkV4dEFueVR5cGUiIG1pbk9jY3Vycz0iMCIvPgogICAgPC9zZXF1ZW5jZT4K ICA8L2NvbXBsZXhUeXBlPgogIDxhbm5vdGF0aW9uPgogICAgPGRvY3VtZW50YXRpb24+IC0tLS0t LS0tLS0tLS0tLS0tLSBBYnN0cmFjdCBPYmplY3QgYW5kIEVsZW1lbnQKICAgICAgVHlwZSBEZWZp bml0aW9ucyAtLS0tLS0tLS0tLS0tLSA8L2RvY3VtZW50YXRpb24+CiAgPC9hbm5vdGF0aW9uPgog IDxjb21wbGV4VHlwZSBuYW1lPSJCYXNpY09ialR5cGUiPgogICAgPHNlcXVlbmNlPgogICAgICA8 ZWxlbWVudCBuYW1lPSJyYW50SWQiIHR5cGU9InNwcHBiOk9yZ0lkVHlwZSIvPgogICAgICA8ZWxl bWVudCBuYW1lPSJyYXJJZCIgdHlwZT0ic3BwcGI6T3JnSWRUeXBlIi8+CiAgICAgIDxlbGVtZW50 IG5hbWU9ImV4dCIgdHlwZT0ic3BwcGI6RXh0QW55VHlwZSIgbWluT2NjdXJzPSIwIi8+CiAgICA8 L3NlcXVlbmNlPgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IlJ0ZVJlY1R5 cGUiIGFic3RyYWN0PSJ0cnVlIj4KICAgIDxzZXF1ZW5jZT4KICAgICAgPGVsZW1lbnQgbmFtZT0i cHJpb3JpdHkiIHR5cGU9InBvc2l0aXZlSW50ZWdlciIgZGVmYXVsdD0iMTAwIi8+CiAgICA8L3Nl cXVlbmNlPgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IlJlZ2V4UGFyYW1U eXBlIj4KICAgIDxzZXF1ZW5jZT4KICAgICAgPGVsZW1lbnQgbmFtZT0iZXJlIiB0eXBlPSJzdHJp bmciIGRlZmF1bHQ9Il4oLiopJCIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJyZXBsIiB0eXBlPSJz dHJpbmciLz4KICAgIDwvc2VxdWVuY2U+CiAgPC9jb21wbGV4VHlwZT4KICA8c2ltcGxlVHlwZSBu YW1lPSJPcmdJZFR5cGUiPgogICAgPHJlc3RyaWN0aW9uIGJhc2U9InN0cmluZyIvPgogIDwvc2lt cGxlVHlwZT4KICA8c2ltcGxlVHlwZSBuYW1lPSJPYmpOYW1lVHlwZSI+CiAgICA8cmVzdHJpY3Rp b24gYmFzZT0ic3RyaW5nIi8+CiAgPC9zaW1wbGVUeXBlPgogIDxzaW1wbGVUeXBlIG5hbWU9IlRy YW5zSWRUeXBlIj4KICAgIDxyZXN0cmljdGlvbiBiYXNlPSJzdHJpbmciLz4KICA8L3NpbXBsZVR5 cGU+CiAgPHNpbXBsZVR5cGUgbmFtZT0iTWlub3JWZXJUeXBlIj4KICAgIDxyZXN0cmljdGlvbiBi YXNlPSJ1bnNpZ25lZExvbmciLz4KICA8L3NpbXBsZVR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9 Ik9iaktleVR5cGUiPgogICAgPHNlcXVlbmNlPgogICAgICA8ZWxlbWVudCBuYW1lPSJyYW50SWQi IHR5cGU9InNwcHBiOk9yZ0lkVHlwZSIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJuYW1lIiB0eXBl PSJzcHBwYjpPYmpOYW1lVHlwZSIvPgogICAgPC9zZXF1ZW5jZT4KICA8L2NvbXBsZXhUeXBlPgog IDxjb21wbGV4VHlwZSBuYW1lPSJSdGVHcnBPZmZlcktleVR5cGUiPgogICAgPHNlcXVlbmNlPgog ICAgICA8ZWxlbWVudCBuYW1lPSJydGVHcnBLZXkiIHR5cGU9InNwcHBiOk9iaktleVR5cGUiLz4K ICAgICAgPGVsZW1lbnQgbmFtZT0ib2ZmZXJlZFRvIiB0eXBlPSJzcHBwYjpPcmdJZFR5cGUiLz4K ICAgIDwvc2VxdWVuY2U+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iQmFz aWNScXN0VHlwZSI+CiAgICA8c2VxdWVuY2U+CiAgICAgIDxlbGVtZW50IG5hbWU9ImNsaWVudFRy YW5zSWQiIHR5cGU9InNwcHBiOlRyYW5zSWRUeXBlIgogICAgICAgIG1pbk9jY3Vycz0iMCIvPgog ICAgICA8ZWxlbWVudCBuYW1lPSJtaW5vclZlciIgdHlwZT0ic3BwcGI6TWlub3JWZXJUeXBlIiBt aW5PY2N1cnM9IjAiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0iZXh0IiB0eXBlPSJzcHBwYjpFeHRB bnlUeXBlIiBtaW5PY2N1cnM9IjAiLz4KICAgIDwvc2VxdWVuY2U+CiAgPC9jb21wbGV4VHlwZT4K ICA8Y29tcGxleFR5cGUgbmFtZT0iQmFzaWNSc3Buc1R5cGUiPgogICAgPHNlcXVlbmNlPgogICAg ICA8ZWxlbWVudCBuYW1lPSJjbGllbnRUcmFuc0lkIiB0eXBlPSJzcHBwYjpUcmFuc0lkVHlwZSIK ICAgICAgICBtaW5PY2N1cnM9IjAiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0ic2VydmVyVHJhbnNJ ZCIgdHlwZT0ic3BwcGI6VHJhbnNJZFR5cGUiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0icmVzQ29k ZSIgdHlwZT0iaW50Ii8+CiAgICAgIDxlbGVtZW50IG5hbWU9InJlc01zZyIgdHlwZT0ic3RyaW5n Ii8+CiAgICAgIDxlbGVtZW50IG5hbWU9ImV4dCIgdHlwZT0ic3BwcGI6RXh0QW55VHlwZSIgbWlu T2NjdXJzPSIwIi8+CiAgICA8L3NlcXVlbmNlPgogICAgPGF0dHJpYnV0ZSBuYW1lPSJjbGllbnRU cmFuc0lkIiB0eXBlPSJzcHBwYjpUcmFuc0lkVHlwZSIvPgogICAgPGF0dHJpYnV0ZSBuYW1lPSJz ZXJ2ZXJUcmFuc0lkIiB0eXBlPSJzcHBwYjpUcmFuc0lkVHlwZSIvPgogIDwvY29tcGxleFR5cGU+ CiAgPGNvbXBsZXhUeXBlIG5hbWU9IklQQWRkclR5cGUiPgogICAgPHNlcXVlbmNlPgogICAgICA8 ZWxlbWVudCBuYW1lPSJhZGRyIiB0eXBlPSJzdHJpbmciLz4KICAgICAgPGVsZW1lbnQgbmFtZT0i dHlwZSIgdHlwZT0ic3BwcGI6SVBUeXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9ImV4dCIgdHlw ZT0ic3BwcGI6RXh0QW55VHlwZSIgbWluT2NjdXJzPSIwIi8+CiAgICA8L3NlcXVlbmNlPgogIDwv Y29tcGxleFR5cGU+CiAgPHNpbXBsZVR5cGUgbmFtZT0iSVBUeXBlIj4KICAgIDxyZXN0cmljdGlv biBiYXNlPSJ0b2tlbiI+CiAgICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0iSVB2NCIvPgogICAgICA8 ZW51bWVyYXRpb24gdmFsdWU9IklQdjYiLz4KICAgIDwvcmVzdHJpY3Rpb24+CiAgPC9zaW1wbGVU eXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJTb3VyY2VJZGVudFR5cGUiPgogICAgPHNlcXVlbmNl PgogICAgICA8ZWxlbWVudCBuYW1lPSJzb3VyY2VJZGVudExhYmVsIiB0eXBlPSJzdHJpbmciLz4K ICAgICAgPGVsZW1lbnQgbmFtZT0ic291cmNlSWRlbnRTY2hlbWUiCiAgICAgICAgdHlwZT0ic3Bw cGI6U291cmNlSWRlbnRTY2hlbWVUeXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9ImV4dCIgdHlw ZT0ic3BwcGI6RXh0QW55VHlwZSIgbWluT2NjdXJzPSIwIi8+CiAgICA8L3NlcXVlbmNlPgogIDwv Y29tcGxleFR5cGU+CiAgPHNpbXBsZVR5cGUgbmFtZT0iU291cmNlSWRlbnRTY2hlbWVUeXBlIj4K ICAgIDxyZXN0cmljdGlvbiBiYXNlPSJ0b2tlbiI+CiAgICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0i dXJpIi8+CiAgICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0iaXAiLz4KICAgICAgPGVudW1lcmF0aW9u IHZhbHVlPSJyb290RG9tYWluIi8+CiAgICA8L3Jlc3RyaWN0aW9uPgogIDwvc2ltcGxlVHlwZT4K ICA8Y29tcGxleFR5cGUgbmFtZT0iQ09SSW5mb1R5cGUiPgogICAgPHNlcXVlbmNlPgogICAgICA8 Y2hvaWNlPgogICAgICAgIDxlbGVtZW50IG5hbWU9ImNvckNsYWltIiB0eXBlPSJib29sZWFuIiBk ZWZhdWx0PSJ0cnVlIi8+CiAgICAgICAgPGVsZW1lbnQgbmFtZT0iY29yIiB0eXBlPSJib29sZWFu IiBkZWZhdWx0PSJmYWxzZSIvPgogICAgICA8L2Nob2ljZT4KICAgICAgPGVsZW1lbnQgbmFtZT0i Y29yRGF0ZVRpbWUiIHR5cGU9ImRhdGVUaW1lIiBtaW5PY2N1cnM9IjAiLz4KICAgIDwvc2VxdWVu Y2U+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iU3ZjTWVudVR5cGUiPgog ICAgPHNlcXVlbmNlPgogICAgICA8ZWxlbWVudCBuYW1lPSJzZXJ2ZXJTdGF0dXMiIHR5cGU9InNw cHBiOlNlcnZlclN0YXR1c1R5cGUiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0ibWFqTWluVmVyc2lv biIgdHlwZT0ic3RyaW5nIgogICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgIDxl bGVtZW50IG5hbWU9Im9ialVSSSIgdHlwZT0iYW55VVJJIiBtYXhPY2N1cnM9InVuYm91bmRlZCIv PgogICAgICA8ZWxlbWVudCBuYW1lPSJleHRVUkkiIHR5cGU9ImFueVVSSSIgbWluT2NjdXJzPSIw IgogICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICA8L3NlcXVlbmNlPgogIDwvY29t cGxleFR5cGU+CiAgPHNpbXBsZVR5cGUgbmFtZT0iU2VydmVyU3RhdHVzVHlwZSI+CiAgICA8cmVz dHJpY3Rpb24gYmFzZT0idG9rZW4iPgogICAgICA8ZW51bWVyYXRpb24gdmFsdWU9ImluU2Vydmlj ZSIvPgogICAgICA8ZW51bWVyYXRpb24gdmFsdWU9Im91dE9mU2VydmljZSIvPgogICAgPC9yZXN0 cmljdGlvbj4KICA8L3NpbXBsZVR5cGU+CiAgPHNpbXBsZVR5cGUgbmFtZT0iUnRlR3JwT2ZmZXJT dGF0dXNUeXBlIj4KICAgIDxyZXN0cmljdGlvbiBiYXNlPSJ0b2tlbiI+CiAgICAgIDxlbnVtZXJh dGlvbiB2YWx1ZT0ib2ZmZXJlZCIvPgogICAgICA8ZW51bWVyYXRpb24gdmFsdWU9ImFjY2VwdGVk Ii8+CiAgICA8L3Jlc3RyaWN0aW9uPgogIDwvc2ltcGxlVHlwZT4KICA8Y29tcGxleFR5cGUgbmFt ZT0iRXh0QW55VHlwZSI+CiAgICA8c2VxdWVuY2U+CiAgICAgIDxhbnkgbmFtZXNwYWNlPSIjI290 aGVyIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgPC9zZXF1ZW5jZT4KICA8L2NvbXBsZXhU eXBlPgogIDxhbm5vdGF0aW9uPgogICAgPGRvY3VtZW50YXRpb24+IC0tLS0tLS0tLS0tLS0tIE9w ZXJhdGlvbiBSZXF1ZXN0IGFuZCBSZXNwb25zZQogICAgICBPYmplY3QgVHlwZSBEZWZpbml0aW9u cyAtLS0tLS0tLS0tLS0gPC9kb2N1bWVudGF0aW9uPgogIDwvYW5ub3RhdGlvbj4KICA8Y29tcGxl eFR5cGUgbmFtZT0iQWRkUnRlR3Jwc1Jxc3RUeXBlIj4KICAgIDxjb21wbGV4Q29udGVudD4KICAg ICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1Jxc3RUeXBlIj4KICAgICAgICA8c2VxdWVu Y2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJydGVHcnAiIHR5cGU9InNwcHBiOlJ0ZUdycFR5 cGUiCiAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgICAgPC9zZXF1ZW5j ZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5 cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IkRlbFJ0ZUdycHNScXN0VHlwZSI+CiAgICA8Y29tcGxl eENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6QmFzaWNScXN0VHlwZSI+CiAg ICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0ib2JqZWN0S2V5IiB0eXBl PSJzcHBwYjpPYmpLZXlUeXBlIgogICAgICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgog ICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVu dD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJHZXRSdGVHcnBzUnFzdFR5 cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJh c2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9 Im9iamVjdEtleSIgdHlwZT0ic3BwcGI6T2JqS2V5VHlwZSIKICAgICAgICAgICAgbWluT2NjdXJz PSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwv ZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21w bGV4VHlwZSBuYW1lPSJHZXRSdGVHcnBzUnNwbnNUeXBlIj4KICAgIDxjb21wbGV4Q29udGVudD4K ICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSI+CiAgICAgICAgPHNl cXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0icnRlR3JwIiB0eXBlPSJzcHBwYjpSdGVH cnBUeXBlIiBtaW5PY2N1cnM9IjAiCiAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+ CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250 ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IkFkZERlc3RHcm91cHNS cXN0VHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3Bw cGI6QmFzaWNScXN0VHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQg bmFtZT0iZGVzdEdycCIgdHlwZT0ic3BwcGI6RGVzdEdycFR5cGUiCiAgICAgICAgICAgIG1heE9j Y3Vycz0idW5ib3VuZGVkIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+ CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5h bWU9IkRlbERlc3RHcm91cHNScXN0VHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxl eHRlbnNpb24gYmFzZT0ic3BwcGI6QmFzaWNScXN0VHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgog ICAgICAgICAgPGVsZW1lbnQgbmFtZT0ib2JqZWN0S2V5IiB0eXBlPSJzcHBwYjpPYmpLZXlUeXBl IgogICAgICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICAgIDwvc2VxdWVuY2U+ CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBl PgogIDxjb21wbGV4VHlwZSBuYW1lPSJHZXREZXN0R3JvdXBzUnFzdFR5cGUiPgogICAgPGNvbXBs ZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnFzdFR5cGUiPgog ICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9Im9iamVjdEtleSIgdHlw ZT0ic3BwcGI6T2JqS2V5VHlwZSIKICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9 InVuYm91bmRlZCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAg PC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJH ZXREZXN0R3JvdXBzUnNwbnNUeXBlIj4KICAgIDxjb21wbGV4Q29udGVudD4KICAgICAgPGV4dGVu c2lvbiBiYXNlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAg ICAgICAgPGVsZW1lbnQgbmFtZT0iZGVzdEdycCIgdHlwZT0ic3BwcGI6RGVzdEdycFR5cGUiCiAg ICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICA8 L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9j b21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iQWRkUHViSWRzUnFzdFR5cGUiPgogICAg PGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnFzdFR5 cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InBpIiB0eXBl PSJzcHBwYjpQdWJJZFR5cGUiCiAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAg ICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250ZW50 PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IkFkZFB1Yklkc1JzcG5zVHlw ZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6QmFz aWNSc3Buc1R5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9 ImNvckluZm8iIHR5cGU9InNwcHBiOkNPUkluZm9UeXBlIgogICAgICAgICAgICBtaW5PY2N1cnM9 IjAiLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxl eENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iRGVsUHViSWRz UnFzdFR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNw cHBiOkJhc2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVtZW50 IG5hbWU9InBpIiB0eXBlPSJzcHBwYjpQdWJJZFR5cGUiCiAgICAgICAgICAgIG1heE9jY3Vycz0i dW5ib3VuZGVkIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8 L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9Ikdl dFB1Yklkc1Jxc3RUeXBlIj4KICAgIDxjb21wbGV4Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBi YXNlPSJzcHBwYjpCYXNpY1Jxc3RUeXBlIj4KICAgICAgICA8c2VxdWVuY2U+CiAgICAgICAgICA8 ZWxlbWVudCBuYW1lPSJwaSIgdHlwZT0ic3BwcGI6UHViSWRUeXBlIiBtaW5PY2N1cnM9IjAiCiAg ICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAg ICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAg PGNvbXBsZXhUeXBlIG5hbWU9IkdldFB1Yklkc1JzcG5zVHlwZSI+CiAgICA8Y29tcGxleENvbnRl bnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6QmFzaWNSc3Buc1R5cGUiPgogICAgICAg IDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InBpIiB0eXBlPSJzcHBwYjpQdWJJ ZFR5cGUiIG1pbk9jY3Vycz0iMCIKICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4K ICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRl bnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iQWRkUnRlR3JwT2ZmZXJz UnFzdFR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNw cHBiOkJhc2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVtZW50 IG5hbWU9InJ0ZUdycE9mZmVyIiB0eXBlPSJzcHBwYjpSdGVHcnBPZmZlclR5cGUiCiAgICAgICAg ICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9l eHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBs ZXhUeXBlIG5hbWU9IkRlbFJ0ZUdycE9mZmVyc1Jxc3RUeXBlIj4KICAgIDxjb21wbGV4Q29udGVu dD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1Jxc3RUeXBlIj4KICAgICAgICA8 c2VxdWVuY2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJydGVHcnBPZmZlcktleSIKICAgICAg ICAgICAgdHlwZT0ic3BwcGI6UnRlR3JwT2ZmZXJLZXlUeXBlIiBtYXhPY2N1cnM9InVuYm91bmRl ZCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4 Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJBY2NlcHRSdGVH cnBPZmZlcnNScXN0VHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24g YmFzZT0ic3BwcGI6QmFzaWNScXN0VHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAg PGVsZW1lbnQgbmFtZT0icnRlR3JwT2ZmZXJLZXkiCiAgICAgICAgICAgIHR5cGU9InNwcHBiOlJ0 ZUdycE9mZmVyS2V5VHlwZSIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICA8L3NlcXVl bmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4 VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iUmVqZWN0UnRlR3JwT2ZmZXJzUnFzdFR5cGUiPgog ICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnFz dFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InJ0ZUdy cE9mZmVyS2V5IgogICAgICAgICAgICB0eXBlPSJzcHBwYjpSdGVHcnBPZmZlcktleVR5cGUiIG1h eE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNp b24+CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBl IG5hbWU9IkdldFJ0ZUdycE9mZmVyc1Jxc3RUeXBlIj4KICAgIDxjb21wbGV4Q29udGVudD4KICAg ICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1Jxc3RUeXBlIj4KICAgICAgICA8c2VxdWVu Y2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJvZmZlcmVkQnlQZWVycyIgdHlwZT0iYm9vbGVh biIgbWluT2NjdXJzPSIwIi8+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJvZmZlcmVkVG9QZWVy cyIgdHlwZT0iYm9vbGVhbiIgbWluT2NjdXJzPSIwIi8+CiAgICAgICAgICA8ZWxlbWVudCBuYW1l PSJzdGF0dXMiIHR5cGU9InNwcHBiOlJ0ZUdycE9mZmVyU3RhdHVzVHlwZSIKICAgICAgICAgICAg bWluT2NjdXJzPSIwIi8+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJwZWVyaW5nT3JnIiB0eXBl PSJzcHBwYjpPcmdJZFR5cGUiCiAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1 bmJvdW5kZWQiLz4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InJ0ZUdycE9mZmVyS2V5IgogICAg ICAgICAgICB0eXBlPSJzcHBwYjpSdGVHcnBPZmZlcktleVR5cGUiIG1pbk9jY3Vycz0iMCIKICAg ICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAg ICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8 Y29tcGxleFR5cGUgbmFtZT0iR2V0UnRlR3JwT2ZmZXJzUnNwbnNUeXBlIj4KICAgIDxjb21wbGV4 Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSI+CiAg ICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0icnRlR3JwT2ZmZXIiIHR5 cGU9InNwcHBiOlJ0ZUdycE9mZmVyVHlwZSIKICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhP Y2N1cnM9InVuYm91bmRlZCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9u PgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBu YW1lPSJBZGRFZ3JSdGVzUnFzdFR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0 ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAg ICAgICAgIDxlbGVtZW50IG5hbWU9ImVnclJ0ZSIgdHlwZT0ic3BwcGI6RWdyUnRlVHlwZSIKICAg ICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAg ICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8 Y29tcGxleFR5cGUgbmFtZT0iRGVsRWdyUnRlc1Jxc3RUeXBlIj4KICAgIDxjb21wbGV4Q29udGVu dD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1Jxc3RUeXBlIj4KICAgICAgICA8 c2VxdWVuY2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJvYmplY3RLZXkiIHR5cGU9InNwcHBi Ok9iaktleVR5cGUiCiAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgICAg PC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwv Y29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IkdldEVnclJ0ZXNScXN0VHlwZSI+CiAg ICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6QmFzaWNScXN0 VHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0ib2JqZWN0 S2V5IiB0eXBlPSJzcHBwYjpPYmpLZXlUeXBlIgogICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1h eE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNp b24+CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBl IG5hbWU9IkdldEVnclJ0ZXNSc3Buc1R5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8 ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnNwbnNUeXBlIj4KICAgICAgICA8c2VxdWVuY2U+ CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJydGVHcnAiIHR5cGU9InNwcHBiOlJ0ZUdycFR5cGUi IG1pbk9jY3Vycz0iMCIKICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAg ICA8L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAg PC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iR2V0U3ZjTWVudVJxc3RUeXBlIj4K ICAgIDxjb21wbGV4Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1Jx c3RUeXBlIi8+CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBs ZXhUeXBlIG5hbWU9IkdldFN2Y01lbnVSc3Buc1R5cGUiPgogICAgPGNvbXBsZXhDb250ZW50Pgog ICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnNwbnNUeXBlIj4KICAgICAgICA8c2Vx dWVuY2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJzdmNNZW51IiB0eXBlPSJzcHBwYjpTdmNN ZW51VHlwZSIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9j b21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxhbm5vdGF0aW9uPgogICAgPGRvY3Vt ZW50YXRpb24+IC0tLS0tLS0tLS0tLS0tIE9wZXJhdGlvbiBSZXF1ZXN0IGFuZCBSZXNwb25zZQog ICAgICBFbGVtZW50IERlZmluaXRpb25zIC0tLS0tLS0tLS0tLSA8L2RvY3VtZW50YXRpb24+CiAg PC9hbm5vdGF0aW9uPgogIDxhbm5vdGF0aW9uPgogICAgPGRvY3VtZW50YXRpb24+IC0tLS0tLS0t LS0tLS0tIE1hbmFnZSBSb3V0ZSBHcm91cHMKICAgIDwvZG9jdW1lbnRhdGlvbj4KICA8L2Fubm90 YXRpb24+CiAgPGVsZW1lbnQgbmFtZT0iYWRkUnRlR3Jwc1Jxc3QiIHR5cGU9InNwcHBiOkFkZFJ0 ZUdycHNScXN0VHlwZSIvPgogIDxlbGVtZW50IG5hbWU9ImRlbFJ0ZUdycHNScXN0IiB0eXBlPSJz cHBwYjpEZWxSdGVHcnBzUnFzdFR5cGUiLz4KICA8ZWxlbWVudCBuYW1lPSJnZXRSdGVHcnBzUnFz dCIgdHlwZT0ic3BwcGI6R2V0UnRlR3Jwc1Jxc3RUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iYWRk UnRlR3Jwc1JzcG5zIiB0eXBlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSIvPgogIDxlbGVtZW50IG5h bWU9ImRlbFJ0ZUdycHNSc3BucyIgdHlwZT0ic3BwcGI6QmFzaWNSc3Buc1R5cGUiLz4KICA8ZWxl bWVudCBuYW1lPSJnZXRSdGVHcnBzUnNwbnMiIHR5cGU9InNwcHBiOkdldFJ0ZUdycHNSc3Buc1R5 cGUiLz4KICA8YW5ub3RhdGlvbj4KICAgIDxkb2N1bWVudGF0aW9uPiAtLS0tLS0tLS0tLS0tLSBN YW5hZ2UgRGVzdGluYXRpb24gR3JvdXBzCiAgICA8L2RvY3VtZW50YXRpb24+CiAgPC9hbm5vdGF0 aW9uPgogIDxlbGVtZW50IG5hbWU9ImFkZERlc3RHcm91cHNScXN0IiB0eXBlPSJzcHBwYjpBZGRE ZXN0R3JvdXBzUnFzdFR5cGUiLz4KICA8ZWxlbWVudCBuYW1lPSJkZWxEZXN0R3JvdXBzUnFzdCIg dHlwZT0ic3BwcGI6RGVsRGVzdEdyb3Vwc1Jxc3RUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iZ2V0 RGVzdEdyb3Vwc1Jxc3QiIHR5cGU9InNwcHBiOkdldERlc3RHcm91cHNScXN0VHlwZSIvPgogIDxl bGVtZW50IG5hbWU9ImFkZERlc3RHcm91cHNSc3BucyIgdHlwZT0ic3BwcGI6QmFzaWNSc3Buc1R5 cGUiLz4KICA8ZWxlbWVudCBuYW1lPSJkZWxEZXN0R3JvdXBzUnNwbnMiIHR5cGU9InNwcHBiOkJh c2ljUnNwbnNUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iZ2V0RGVzdEdyb3Vwc1JzcG5zIgogICAg dHlwZT0ic3BwcGI6R2V0RGVzdEdyb3Vwc1JzcG5zVHlwZSIvPgogIDxhbm5vdGF0aW9uPgogICAg PGRvY3VtZW50YXRpb24+IC0tLS0tLS0tLS0tLS0tIE1hbmFnZSBQdWJsaWMgSWRlbnRpZmllcnMK ICAgIDwvZG9jdW1lbnRhdGlvbj4KICA8L2Fubm90YXRpb24+CiAgPGVsZW1lbnQgbmFtZT0iYWRk UHViSWRzUnFzdCIgdHlwZT0ic3BwcGI6QWRkUHViSWRzUnFzdFR5cGUiLz4KICA8ZWxlbWVudCBu YW1lPSJkZWxQdWJJZHNScXN0IiB0eXBlPSJzcHBwYjpEZWxQdWJJZHNScXN0VHlwZSIvPgogIDxl bGVtZW50IG5hbWU9ImdldFB1Yklkc1Jxc3QiIHR5cGU9InNwcHBiOkdldFB1Yklkc1Jxc3RUeXBl Ii8+CiAgPGVsZW1lbnQgbmFtZT0iYWRkUHViSWRzUnNwbnMiIHR5cGU9InNwcHBiOkFkZFB1Yklk c1JzcG5zVHlwZSIvPgogIDxlbGVtZW50IG5hbWU9ImRlbFB1Yklkc1JzcG5zIiB0eXBlPSJzcHBw YjpCYXNpY1JzcG5zVHlwZSIvPgogIDxlbGVtZW50IG5hbWU9ImdldFB1Yklkc1JzcG5zIiB0eXBl PSJzcHBwYjpHZXRQdWJJZHNSc3Buc1R5cGUiLz4KICA8YW5ub3RhdGlvbj4KICAgIDxkb2N1bWVu dGF0aW9uPiAtLS0tLS0tLS0tLS0tLSBNYW5hZ2UgUm91dGUgR3JvdXAgT2ZmZXJzCiAgICA8L2Rv Y3VtZW50YXRpb24+CiAgPC9hbm5vdGF0aW9uPgogIDxlbGVtZW50IG5hbWU9ImFkZFJ0ZUdycE9m ZmVyc1Jxc3QiCiAgICB0eXBlPSJzcHBwYjpBZGRSdGVHcnBPZmZlcnNScXN0VHlwZSIvPgogIDxl bGVtZW50IG5hbWU9ImRlbFJ0ZUdycE9mZmVyc1Jxc3QiCiAgICB0eXBlPSJzcHBwYjpEZWxSdGVH cnBPZmZlcnNScXN0VHlwZSIvPgogIDxlbGVtZW50IG5hbWU9ImFjY2VwdFJ0ZUdycE9mZmVyc1Jx c3QiCiAgICB0eXBlPSJzcHBwYjpBY2NlcHRSdGVHcnBPZmZlcnNScXN0VHlwZSIvPgogIDxlbGVt ZW50IG5hbWU9InJlamVjdFJ0ZUdycE9mZmVyc1Jxc3QiCiAgICB0eXBlPSJzcHBwYjpSZWplY3RS dGVHcnBPZmZlcnNScXN0VHlwZSIvPgogIDxlbGVtZW50IG5hbWU9ImdldFJ0ZUdycE9mZmVyc1Jx c3QiCiAgICB0eXBlPSJzcHBwYjpHZXRSdGVHcnBPZmZlcnNScXN0VHlwZSIvPgogIDxlbGVtZW50 IG5hbWU9ImFkZFJ0ZUdycE9mZmVyc1JzcG5zIiB0eXBlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSIv PgogIDxlbGVtZW50IG5hbWU9ImRlbFJ0ZUdycE9mZmVyc1JzcG5zIiB0eXBlPSJzcHBwYjpCYXNp Y1JzcG5zVHlwZSIvPgogIDxlbGVtZW50IG5hbWU9ImFjY2VwdFJ0ZUdycE9mZmVyc1JzcG5zIiB0 eXBlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSIvPgogIDxlbGVtZW50IG5hbWU9InJlamVjdFJ0ZUdy cE9mZmVyc1JzcG5zIiB0eXBlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSIvPgogIDxlbGVtZW50IG5h bWU9ImdldFJ0ZUdycE9mZmVyc1JzcG5zIgogICAgdHlwZT0ic3BwcGI6R2V0UnRlR3JwT2ZmZXJz UnNwbnNUeXBlIi8+CiAgPGFubm90YXRpb24+CiAgICA8ZG9jdW1lbnRhdGlvbj4gLS0tLS0tLS0t LS0tLS0gTWFuYWdlIEVncmVzcyBSb3V0ZXMKICAgIDwvZG9jdW1lbnRhdGlvbj4KICA8L2Fubm90 YXRpb24+CiAgPGVsZW1lbnQgbmFtZT0iYWRkRWdyUnRlc1Jxc3QiIHR5cGU9InNwcHBiOkFkZEVn clJ0ZXNScXN0VHlwZSIvPgogIDxlbGVtZW50IG5hbWU9ImRlbEVnclJ0ZXNScXN0IiB0eXBlPSJz cHBwYjpEZWxFZ3JSdGVzUnFzdFR5cGUiLz4KICA8ZWxlbWVudCBuYW1lPSJnZXRFZ3JSdGVzUnFz dCIgdHlwZT0ic3BwcGI6R2V0RWdyUnRlc1Jxc3RUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iYWRk RWdyUnRlc1JzcG5zIiB0eXBlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSIvPgogIDxlbGVtZW50IG5h bWU9ImRlbEVnclJ0ZXNSc3BucyIgdHlwZT0ic3BwcGI6QmFzaWNSc3Buc1R5cGUiLz4KICA8ZWxl bWVudCBuYW1lPSJnZXRFZ3JSdGVzUnNwbnMiIHR5cGU9InNwcHBiOkdldEVnclJ0ZXNSc3Buc1R5 cGUiLz4KICA8YW5ub3RhdGlvbj4KICAgIDxkb2N1bWVudGF0aW9uPiAtLS0tLS0tLS0tLS0tLSBN aXNjIE9wZXJhdGlvbnMgPC9kb2N1bWVudGF0aW9uPgogIDwvYW5ub3RhdGlvbj4KICA8ZWxlbWVu dCBuYW1lPSJnZXRTdmNNZW51UnFzdCIgdHlwZT0ic3BwcGI6R2V0U3ZjTWVudVJxc3RUeXBlIi8+ CiAgPGVsZW1lbnQgbmFtZT0iZ2V0U3ZjTWVudVJzcG5zIiB0eXBlPSJzcHBwYjpHZXRTdmNNZW51 UnNwbnNUeXBlIi8+CiAgPGFubm90YXRpb24+CiAgICA8ZG9jdW1lbnRhdGlvbj4gLS0tLS0tLS0g R2VuZXJpYyBSZXF1ZXN0IGFuZCBSZXNwb25zZSBEZWZpbml0aW9ucwogICAgICAtLS0tLS0tLS0t LS0tLS0gPC9kb2N1bWVudGF0aW9uPgogIDwvYW5ub3RhdGlvbj4KICA8ZWxlbWVudCBuYW1lPSJz cHBwUmVxdWVzdCI+CiAgICA8Y29tcGxleFR5cGU+CiAgICAgIDxzZXF1ZW5jZT4KICAgICAgICA8 YW55IG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDxhdHRy aWJ1dGUgbmFtZT0idHJhbnNhY3Rpb25hbCIgdHlwZT0iYm9vbGVhbiIgdXNlPSJvcHRpb25hbCIv PgogICAgPC9jb21wbGV4VHlwZT4KICA8L2VsZW1lbnQ+CiAgPGVsZW1lbnQgbmFtZT0ic3BwcFJl c3BvbnNlIj4KICAgIDxjb21wbGV4VHlwZT4KICAgICAgPHNlcXVlbmNlPgogICAgICAgIDxhbnkg bWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgPC9zZXF1ZW5jZT4KICAgIDwvY29tcGxleFR5 cGU+CiAgPC9lbGVtZW50Pgo8L3NjaGVtYT4K --_008_C88DF18442812syedalineustarbiz_ Content-Type: application/octet-stream; name="addPubIdsRqst_1.xml" Content-Description: addPubIdsRqst_1.xml Content-Disposition: attachment; filename="addPubIdsRqst_1.xml"; size=698; creation-date="Sun, 15 Aug 2010 19:36:45 GMT"; modification-date="Sun, 15 Aug 2010 19:36:45 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNwcHBSZXF1ZXN0ICB4bWxu cz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSIKICB4bWxuczp4c2k9Imh0dHA6 Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIgogIHhzaTpzY2hlbWFMb2NhdGlv bj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSBmaWxlOi9Vc2Vycy9zYWxpL3N5 ZWQvcHJvamVjdHMvRFJJTktTLzA4XzE1L3NwcHAueHNkIj4KICA8YWRkUHViSWRzUnFzdD4KICAg IDxjbGllbnRUcmFuc0lkPnR4aWQtNTU1NTwvY2xpZW50VHJhbnNJZD4KICAgIDxwaSB4bWxuczpu czE9InVybjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpiYXNlOjEiCiAgICAgIHhzaTp0eXBlPSJu czE6VE5UeXBlIj4KICAgICAgPGJhc2U+CiAgICAgICAgPHJhbnRJZD5yYW50SWQwPC9yYW50SWQ+ CiAgICAgICAgPHJhcklkPnJhcklkMDwvcmFySWQ+CiAgICAgIDwvYmFzZT4KICAgICAgPG5zMTpk Z05hbWU+REVTVF9HUlBfMTwvbnMxOmRnTmFtZT4KICAgICAgPHRuPisxMjAyNTU1NjY2NjwvdG4+ CiAgICAgIDxuczE6Y29ySW5mbz4KICAgICAgICA8bnMxOmNvckNsYWltPnRydWU8L25zMTpjb3JD bGFpbT4KICAgICAgPC9uczE6Y29ySW5mbz4KICAgIDwvcGk+CiAgPC9hZGRQdWJJZHNScXN0Pgo8 L3NwcHBSZXF1ZXN0Pgo= --_008_C88DF18442812syedalineustarbiz_ Content-Type: application/octet-stream; name="addPubIdsRspns_1.xml" Content-Description: addPubIdsRspns_1.xml Content-Disposition: attachment; filename="addPubIdsRspns_1.xml"; size=521; creation-date="Sun, 15 Aug 2010 19:36:45 GMT"; modification-date="Sun, 15 Aug 2010 19:36:45 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNwcHBSZXNwb25zZSB4bWxu cz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSIKICB4bWxuczp4c2k9Imh0dHA6 Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIgogIHhzaTpzY2hlbWFMb2NhdGlv bj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSBmaWxlOi9Vc2Vycy9zYWxpL3N5 ZWQvcHJvamVjdHMvRFJJTktTLzA4XzE1L3NwcHAueHNkIj4KICA8YWRkUHViSWRzUnNwbnM+CiAg ICA8Y2xpZW50VHJhbnNJZD50eGlkLTU1NTU8L2NsaWVudFRyYW5zSWQ+CiAgICA8c2VydmVyVHJh bnNJZD5zZXJ2ZXJUcmFuc0lkMDwvc2VydmVyVHJhbnNJZD4KICAgIDxyZXNDb2RlPjEwMDA8L3Jl c0NvZGU+CiAgICA8cmVzTXNnPnN1Y2Nlc3M8L3Jlc01zZz4KICAgIDxjb3JJbmZvPgogICAgICA8 Y29yPnRydWU8L2Nvcj4KICAgIDwvY29ySW5mbz4KICA8L2FkZFB1Yklkc1JzcG5zPgo8L3NwcHBS ZXNwb25zZT4= --_008_C88DF18442812syedalineustarbiz_ Content-Type: application/octet-stream; name="addPubIdsRqst_2.xml" Content-Description: addPubIdsRqst_2.xml Content-Disposition: attachment; filename="addPubIdsRqst_2.xml"; size=733; creation-date="Sun, 15 Aug 2010 19:36:45 GMT"; modification-date="Sun, 15 Aug 2010 19:36:45 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNwcHBSZXF1ZXN0IHhtbG5z PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNwcHA6YmFzZToxIgogIHhtbG5zOnhzaT0iaHR0cDov L3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiCiAgeHNpOnNjaGVtYUxvY2F0aW9u PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnNwcHA6YmFzZToxIGZpbGU6L1VzZXJzL3NhbGkvc3ll ZC9wcm9qZWN0cy9EUklOS1MvMDhfMTUvc3BwcC54c2QiPgogIDxhZGRQdWJJZHNScXN0PgogICAg PGNsaWVudFRyYW5zSWQ+dHhpZC02NjY2PC9jbGllbnRUcmFuc0lkPgogICAgPHBpIHhtbG5zOm5z MT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSIKICAgICAgeHNpOnR5cGU9Im5z MTpUTlJUeXBlIj4KICAgICAgPGJhc2U+CiAgICAgICAgPHJhbnRJZD5yYW50SWQwPC9yYW50SWQ+ CiAgICAgICAgPHJhcklkPnJhcklkMDwvcmFySWQ+CiAgICAgIDwvYmFzZT4KICAgICAgPG5zMTpk Z05hbWU+REVTVF9HUlBfMTwvbnMxOmRnTmFtZT4KICAgICAgPHRuPisxMjAyMzMzMDAwMDwvdG4+ CiAgICAgIDxlbmRUbj4rMTIwMjMzMzk5OTk8L2VuZFRuPgogICAgICA8bnMxOmNvckluZm8+CiAg ICAgICAgPG5zMTpjb3JDbGFpbT50cnVlPC9uczE6Y29yQ2xhaW0+CiAgICAgIDwvbnMxOmNvcklu Zm8+CiAgICA8L3BpPgogIDwvYWRkUHViSWRzUnFzdD4KPC9zcHBwUmVxdWVzdD4KCg== --_008_C88DF18442812syedalineustarbiz_ Content-Type: application/octet-stream; name="addPubIdsRspns_2.xml" Content-Description: addPubIdsRspns_2.xml Content-Disposition: attachment; filename="addPubIdsRspns_2.xml"; size=522; creation-date="Sun, 15 Aug 2010 19:36:45 GMT"; modification-date="Sun, 15 Aug 2010 19:36:45 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNwcHBSZXNwb25zZSB4bWxu cz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSIKICB4bWxuczp4c2k9Imh0dHA6 Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIgogIHhzaTpzY2hlbWFMb2NhdGlv bj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSBmaWxlOi9Vc2Vycy9zYWxpL3N5 ZWQvcHJvamVjdHMvRFJJTktTLzA4XzE1L3NwcHAueHNkIj4KICA8YWRkUHViSWRzUnNwbnM+CiAg ICA8Y2xpZW50VHJhbnNJZD50eGlkLTY2NjY8L2NsaWVudFRyYW5zSWQ+CiAgICA8c2VydmVyVHJh bnNJZD5zZXJ2ZXJUcmFuc0lkMTwvc2VydmVyVHJhbnNJZD4KICAgIDxyZXNDb2RlPjEwMDA8L3Jl c0NvZGU+CiAgICA8cmVzTXNnPnN1Y2Nlc3M8L3Jlc01zZz4KICAgIDxjb3JJbmZvPgogICAgICA8 Y29yPnRydWU8L2Nvcj4KICAgIDwvY29ySW5mbz4KICA8L2FkZFB1Yklkc1JzcG5zPgo8L3NwcHBS ZXNwb25zZT4K --_008_C88DF18442812syedalineustarbiz_ Content-Type: application/octet-stream; name="getPubIdsRqst_1.xml" Content-Description: getPubIdsRqst_1.xml Content-Disposition: attachment; filename="getPubIdsRqst_1.xml"; size=573; creation-date="Sun, 15 Aug 2010 19:36:45 GMT"; modification-date="Sun, 15 Aug 2010 19:36:45 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNwcHBSZXF1ZXN0ICB4bWxu cz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSIKICB4bWxuczp4c2k9Imh0dHA6 Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIgogIHhzaTpzY2hlbWFMb2NhdGlv bj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSBmaWxlOi9Vc2Vycy9zYWxpL3N5 ZWQvcHJvamVjdHMvRFJJTktTLzA4XzE1L3NwcHAueHNkIj4KICA8Z2V0UHViSWRzUnFzdD4KICAg IDxjbGllbnRUcmFuc0lkPnR4aWQtNzc3NzwvY2xpZW50VHJhbnNJZD4KICAgIDxwaSB4bWxuczpu czE9InVybjppZXRmOnBhcmFtczp4bWw6bnM6c3BwcDpiYXNlOjEiCiAgICAgIHhzaTp0eXBlPSJu czE6VE5UeXBlIj4KICAgICAgPGJhc2U+CiAgICAgICAgPHJhbnRJZD5yYW50SWQwPC9yYW50SWQ+ CiAgICAgICAgPHJhcklkPnJhcklkMDwvcmFySWQ+CiAgICAgIDwvYmFzZT4KICAgICAgPHRuPisx MjAyNTU1NjY2NjwvdG4+CiAgICA8L3BpPgogIDwvZ2V0UHViSWRzUnFzdD4KPC9zcHBwUmVxdWVz dD4K --_008_C88DF18442812syedalineustarbiz_ Content-Type: application/octet-stream; name="getPubIdsRspns_1.xml" Content-Description: getPubIdsRspns_1.xml Content-Disposition: attachment; filename="getPubIdsRspns_1.xml"; size=795; creation-date="Sun, 15 Aug 2010 19:36:45 GMT"; modification-date="Sun, 15 Aug 2010 19:36:45 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNwcHBSZXF1ZXN0ICB4bWxu cz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSIKICB4bWxuczp4c2k9Imh0dHA6 Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIgogIHhzaTpzY2hlbWFMb2NhdGlv bj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSBmaWxlOi9Vc2Vycy9zYWxpL3N5 ZWQvcHJvamVjdHMvRFJJTktTLzA4XzE1L3NwcHAueHNkIj4KICA8Z2V0UHViSWRzUnNwbnM+CiAg ICA8Y2xpZW50VHJhbnNJZD50eGlkLTc3Nzc8L2NsaWVudFRyYW5zSWQ+CiAgICA8c2VydmVyVHJh bnNJZD5zcnZyLXR4LWlkXzE8L3NlcnZlclRyYW5zSWQ+CiAgICA8cmVzQ29kZT4xMDAwPC9yZXND b2RlPgogICAgPHJlc01zZz5zdWNjZXNzPC9yZXNNc2c+CiAgICA8cGkgeG1sbnM6bnMxPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnNwcHA6YmFzZToxIgogICAgICB4c2k6dHlwZT0ibnMxOlROVHlw ZSI+CiAgICAgIDxiYXNlPgogICAgICAgIDxyYW50SWQ+cmFudElkMDwvcmFudElkPgogICAgICAg IDxyYXJJZD5yYXJJZDA8L3JhcklkPgogICAgICA8L2Jhc2U+CiAgICAgIDxuczE6ZGdOYW1lPkRF U1RfR1JQXzE8L25zMTpkZ05hbWU+CiAgICAgIDx0bj4rMTIwMjU1NTY2NjY8L3RuPgogICAgICA8 bnMxOmNvckluZm8+CiAgICAgICAgPG5zMTpjb3I+dHJ1ZTwvbnMxOmNvcj4KICAgICAgPC9uczE6 Y29ySW5mbz4KICAgIDwvcGk+CiAgPC9nZXRQdWJJZHNSc3Bucz4KPC9zcHBwUmVxdWVzdD4K --_008_C88DF18442812syedalineustarbiz_-- From kcartwright@tnsi.com Mon Aug 16 09:35:08 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F2E3A6782 for ; Mon, 16 Aug 2010 09:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIWv+KIjK-Kz for ; Mon, 16 Aug 2010 09:35:04 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 261E93A6804 for ; Mon, 16 Aug 2010 09:35:02 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.46740174; Mon, 16 Aug 2010 12:35:34 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 16 Aug 2010 12:35:34 -0400 From: "Cartwright, Ken" To: "Ali, Syed Wasim" , "jf.mule@cablelabs.com" Date: Mon, 16 Aug 2010 12:35:33 -0400 Thread-Topic: update to CORInfoType Thread-Index: Acs80jpajVTytdNW50uMweQLDL/agQAhYZlQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA2449310423@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] update to CORInfoType X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 16:35:08 -0000 Hi Syed, A few points about this: 1) The corClaim and cor elements can't be a "choice" element because when a= client app queries for the properties of a PublicIdentifier they need to k= now whether they sumitted it with a COR claim *and* whether that claim has = been approved. I think your intended goal could instead be accomplished by= combining the corClaim and the cor elements into a single element of type = enumeration whose values could be "noClaimRqst" "claimRqst" "claimRqstAppro= ved" "claimRqstRejected". 2) I think I have come to agree with you that there should be an option to = allow the result of a cor claim to be returned synchronously. The scalabil= ity concern that I have about doing this synchronously is more of an on ope= rational and/or policy concern. Bulk requests that perform this cor check = synchronously and send the response synchronously will of course be slower = and result in a lot more data sent over the wire, however, some installatio= ns may need or want to function this way and therefore are willing to pay t= his performance price. However, the manner that this has been proposed in = the XSD I think may not work. See (3) below. 3) The proposed change is to add in a AddPubIdsRspnsType object that contai= ns a set of CORINfoTypes. However, the CORInfoType does not contain the ke= y of the PublicIdentity to which it applies. And it is not good practive t= o just assume that it is based on the order in which they are passed in. I= think if we want to accomplish this, then we should include the full PubId= Type object in the response. 4) The COR claim elements should also be part of the RNTYpe. Ken -----Original Message----- From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz] Sent: Sunday, August 15, 2010 7:33 PM To: Cartwright, Ken; jf.mule@cablelabs.com Cc: drinks@ietf.org Subject: update to CORInfoType Hi, 'corClaim' attribute is meant to assist the registrant in making the carrier-of-record claim for a given TN public identity. However, 'cor' attribute is meant to be included in the response message to help the SPPP server confirm, or not, whether if the registrant is in fact the carrier-of-record. My understanding is that these two elements are not to b= e used together in a message. Current definition of CORInfoType in the SP schema requires both 'corClaim' and 'cor' elements, with an unintended effect that both of these elements are now required for the add public identifier (TN) request. I am suggesting the following change to make sure that when CORInfoType is included in a message, a choice of either 'corClaim' or 'cor', and not the inclusion of both attributes, is enforced. In addition, the Registry often have the carrier-of-record data (TN block assignee list, NP data, etc.) available to make ad hoc decisions as to whether the registrant's claim to be a carrier-of-record can be honored. I think it is desirable to have the option to return the carrier-of-record claim result in the sppp response that corresponds to the request. I made some changes in the attached schema to support this option. Lastly, attached is the updated schema and the examples that reflect the changes discussed above. -Syed 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 syed.ali@neustar.biz Tue Aug 17 11:15:04 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5FE3A6AFC for ; Tue, 17 Aug 2010 11:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_40=-0.185, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2Z4Ket5nyvG for ; Tue, 17 Aug 2010 11:13:51 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id A86E33A6AAB for ; Tue, 17 Aug 2010 11:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1282068820; x=1597423445; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=eK+bAIo1SQhEID65mbN4TgkkwWwTJpqFr8MSGeIxPyk=; b=ok6pLePCdoljxr4Orf47GUgzMgzLtE2WEsop1ncVSeLtWcOcKiQFtN322xxJIJ f80hSqm6HkibtepLv5cHzIYQ== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.28590838; Tue, 17 Aug 2010 14:13:39 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 17 Aug 2010 14:13:48 -0400 From: "Ali, Syed Wasim" To: "Cartwright, Ken" , Jean-Francois Mule Date: Tue, 17 Aug 2010 14:13:34 -0400 Thread-Topic: update to CORInfoType Thread-Index: Acs80jpajVTytdNW50uMweQLDL/agQAhYZlQADgJtzA= Message-ID: In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA2449310423@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: feuapwm+M1XmOGMo8rTDJg== Content-Type: multipart/mixed; boundary="_002_C890499043002syedalineustarbiz_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] update to CORInfoType X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:15:16 -0000 --_002_C890499043002syedalineustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the quick response. Please, see comments below: On 8/16/10 12:35 PM, "Cartwright, Ken" wrote: > Hi Syed, >=20 > A few points about this: >=20 > 1) The corClaim and cor elements can't be a "choice" element because when= a > client app queries for the properties of a PublicIdentifier they need to = know > whether they sumitted it with a COR claim *and* whether that claim has be= en > approved. I think your intended goal could instead be accomplished by > combining the corClaim and the cor elements into a single element of type > enumeration whose values could be "noClaimRqst" "claimRqst" > "claimRqstApproved" "claimRqstRejected". This is a valid point. And while use of carrier-of-record claim is certainl= y one way to request COR processing, a lot of systems today maintain this indicator implicitly that makes an explicit claim in the request unnecessary. While we can try to cover all possibilities using enumerated values, I think the original proposed boolean values should be sufficient. = I will remove the 'choice'. > 2) I think I have come to agree with you that there should be an option t= o > allow the result of a cor claim to be returned synchronously. The scalab= ility > concern that I have about doing this synchronously is more of an on > operational and/or policy concern. Bulk requests that perform this cor c= heck > synchronously and send the response synchronously will of course be slowe= r and > result in a lot more data sent over the wire, however, some installations= may > need or want to function this way and therefore are willing to pay this > performance price. However, the manner that this has been proposed in th= e XSD > I think may not work. See (3) below. Your concern for performance and excess data over the wire is not without merit. However, not including the result in the response message means separate 'getXXX' calls for all relevant requests in the bulk request message just to know the outcome. Also, the fact that CORInfoType is an optional element, it allows the needed flexibility in letting the Registry use policy knobs and return this information on a case by case basis. > 3) The proposed change is to add in a AddPubIdsRspnsType object that cont= ains > a set of CORINfoTypes. However, the CORInfoType does not contain the key= of > the PublicIdentity to which it applies. And it is not good practive to j= ust > assume that it is based on the order in which they are passed in. I thin= k if > we want to accomplish this, then we should include the full PubIdType obj= ect > in the response. I am with you on this one. I forgot about the 1-to-many association to PI. And COR is not the only case where the current schema definition of AddPubIdsRspnsType needs clarification. Consider the case where the request has multiple PI instances within a and the Registry could only honor some of them while others fail processing for one reason or another. There are a couple of ways to go about it. One, change the ordinal value for the composite AddPubIdsRqstType-->PI from 1..unbounded to 1..1. This way, the can be used to dereference the PI in the response. Two, add the *track_identifier* (trkId) attribute for each PI tha= t can be later referenced in the response to (1) convey the COR status in cases where the messages were processed successfully; and in case of a failure, (2) point to the particular PI instance in this message along with the correct failure response code. The former approach is too disruptive IM= O and adds bulk to the responses. The latter approach is do-able and tackles the failure scenarios well. I envision 'trkId' to be any arbitrary integer value the scope of which is limited to the immediate transaction, which is for the purpose of this discussion. To elaborate on this, = I am including a few examples below: - Activate three PIs txid-5555 rantId0 rarId0 DEST_GRP_1 true +12025556666 rantId0 rarId0 DEST_GRP_1 +17035556666 rantId0 rarId0 true +12025556666 100 20 40 u E2U+sip ^(.*)$ sip:\1@sbe4.ssp2.com NOTE_1: The TN key of the first and third PI in the sequence above is intentionally the same. NOTE_2: element is repetitive in the XML instance and perhaps it wil= l suffice as the member of the root element spppb:Request for most cases, if not all. I think David S. pointed this out earlier. I am just saying it out loud in case someone wants to comment. case 1: All PI are successfully provisioned and either response below from Registry should be fine. txid-5555 serverTransId0 1000 success ... true true +12025556666 ... true true +12025556666 --- OR --- txid-5555 serverTransId0 1000 success case 2: Assuming that the Registry doesn't support PI-->RteRec associations= , sample failure response including the record in error, is shown below. Also= , since the is a mini-transaction (with its own clientTransId), a failure to provision one of the three PI means that none of the PI instances in the set get provisioned. txid-5555 serverTransId0 2103 Command Invalid DEST_GRP_1 +12025556666 > 4) The COR claim elements should also be part of the RNTYpe. Sure.=20 Please, find the updated schema attached to this email. thanks, -Syed >=20 > Ken >=20 --_002_C890499043002syedalineustarbiz_ Content-Type: application/octet-stream; name="sppp.xsd" Content-Description: sppp.xsd Content-Disposition: attachment; filename="sppp.xsd"; size=21626; creation-date="Tue, 17 Aug 2010 14:13:35 GMT"; modification-date="Tue, 17 Aug 2010 14:13:35 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNjaGVtYSB4bWxuczpzcHBw Yj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzcHBwOmJhc2U6MSIKICB4bWxucz0iaHR0cDovL3d3 dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiCiAgdGFyZ2V0TmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnNwcHA6YmFzZToxIgogIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIiB4 bWw6bGFuZz0iRU4iPgogIDxhbm5vdGF0aW9uPgogICAgPGRvY3VtZW50YXRpb24+IC0tLS0tLS0t LS0tLS0tLS0tLSBPYmplY3QgVHlwZSBEZWZpbml0aW9ucwogICAgICAtLS0tLS0tLS0tLS0tLSA8 L2RvY3VtZW50YXRpb24+CiAgPC9hbm5vdGF0aW9uPgogIDxjb21wbGV4VHlwZSBuYW1lPSJSdGVH cnBUeXBlIj4KICAgIDxzZXF1ZW5jZT4KICAgICAgPGVsZW1lbnQgbmFtZT0iYmFzZSIgdHlwZT0i c3BwcGI6QmFzaWNPYmpUeXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9InJ0ZUdycE5hbWUiIHR5 cGU9InNwcHBiOk9iak5hbWVUeXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9InJ0ZVJlYyIgdHlw ZT0ic3BwcGI6UnRlUmVjVHlwZSIgbWluT2NjdXJzPSIwIgogICAgICAgIG1heE9jY3Vycz0idW5i b3VuZGVkIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9ImRnTmFtZSIgdHlwZT0ic3BwcGI6T2JqTmFt ZVR5cGUiIG1pbk9jY3Vycz0iMCIKICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAg ICA8ZWxlbWVudCBuYW1lPSJwZWVyaW5nT3JnIiB0eXBlPSJzcHBwYjpPcmdJZFR5cGUiIG1pbk9j Y3Vycz0iMCIKICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICA8ZWxlbWVudCBu YW1lPSJzb3VyY2VJZGVudCIgdHlwZT0ic3BwcGI6U291cmNlSWRlbnRUeXBlIgogICAgICAgIG1p bk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0i aXNJblN2YyIgdHlwZT0iYm9vbGVhbiIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJleHQiIHR5cGU9 InNwcHBiOkV4dEFueVR5cGUiIG1pbk9jY3Vycz0iMCIvPgogICAgPC9zZXF1ZW5jZT4KICA8L2Nv bXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJEZXN0R3JwVHlwZSI+CiAgICA8c2VxdWVu Y2U+CiAgICAgIDxlbGVtZW50IG5hbWU9ImJhc2UiIHR5cGU9InNwcHBiOkJhc2ljT2JqVHlwZSIv PgogICAgICA8ZWxlbWVudCBuYW1lPSJkZ05hbWUiIHR5cGU9InNwcHBiOk9iak5hbWVUeXBlIi8+ CiAgICA8L3NlcXVlbmNlPgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IlB1 YklkVHlwZSIgYWJzdHJhY3Q9InRydWUiPgogICAgPHNlcXVlbmNlPgogICAgICA8ZWxlbWVudCBu YW1lPSJiYXNlIiB0eXBlPSJzcHBwYjpCYXNpY09ialR5cGUiLz4KICAgICAgPGVsZW1lbnQgbmFt ZT0iZGdOYW1lIiB0eXBlPSJzcHBwYjpPYmpOYW1lVHlwZSIgbWluT2NjdXJzPSIwIi8+CiAgICAg IDxlbGVtZW50IG5hbWU9InJ0ZVJlYyIgdHlwZT0ic3BwcGI6UnRlUmVjVHlwZSIgbWluT2NjdXJz PSIwIgogICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgIDxlbGVtZW50IG1pbk9j Y3Vycz0iMCIgbmFtZT0iY29ySW5mbyIgdHlwZT0ic3BwcGI6Q09SSW5mb1R5cGUiLz4KICAgIDwv c2VxdWVuY2U+CiAgICA8YXR0cmlidXRlIG5hbWU9InRya0lkIiB0eXBlPSJwb3NpdGl2ZUludGVn ZXIiLz4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJFbWFpbFR5cGUiPgog ICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOlB1YklkVHlw ZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0iZW1haWwiIHR5 cGU9InN0cmluZyIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAg PC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJU TlR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBi OlB1YklkVHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0i dG4iIHR5cGU9InN0cmluZyIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9u PgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBu YW1lPSJUTlJUeXBlIj4KICAgIDxjb21wbGV4Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNl PSJzcHBwYjpUTlR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5h bWU9ImVuZFRuIiB0eXBlPSJzdHJpbmciLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8L2V4 dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxl eFR5cGUgbmFtZT0iUk5UeXBlIj4KICAgIDxjb21wbGV4Q29udGVudD4KICAgICAgPGV4dGVuc2lv biBiYXNlPSJzcHBwYjpQdWJJZFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxl bGVtZW50IG5hbWU9InJuIiB0eXBlPSJzdHJpbmciIGRlZmF1bHQ9InRydWUiLz4KICAgICAgICA8 L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9j b21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iTkFQVFJUeXBlIj4KICAgIDxjb21wbGV4 Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpSdGVSZWNUeXBlIj4KICAgICAg ICA8c2VxdWVuY2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJvcmRlciIgdHlwZT0idW5zaWdu ZWRTaG9ydCIvPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0icHJlZiIgdHlwZT0idW5zaWduZWRT aG9ydCIvPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0iZmxhZ3MiIHR5cGU9InN0cmluZyIgbWlu T2NjdXJzPSIwIi8+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJzdmNzIiB0eXBlPSJzdHJpbmci Lz4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InJlZ3giIHR5cGU9InNwcHBiOlJlZ2V4UGFyYW1U eXBlIgogICAgICAgICAgICBtaW5PY2N1cnM9IjAiLz4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9 InJlcGwiIHR5cGU9InN0cmluZyIgbWluT2NjdXJzPSIwIi8+CiAgICAgICAgICA8ZWxlbWVudCBu YW1lPSJ0dGwiIHR5cGU9InBvc2l0aXZlSW50ZWdlciIgbWluT2NjdXJzPSIwIi8+CiAgICAgICAg ICA8ZWxlbWVudCBuYW1lPSJleHQiIHR5cGU9InNwcHBiOkV4dEFueVR5cGUiIG1pbk9jY3Vycz0i MCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4 Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJOU1R5cGUiPgog ICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOlJ0ZVJlY1R5 cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9Imhvc3ROYW1l IiB0eXBlPSJzdHJpbmciLz4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9ImlwQWRkciIgdHlwZT0i c3BwcGI6SVBBZGRyVHlwZSIgbWluT2NjdXJzPSIwIgogICAgICAgICAgICBtYXhPY2N1cnM9InVu Ym91bmRlZCIvPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0idHRsIiB0eXBlPSJwb3NpdGl2ZUlu dGVnZXIiIG1pbk9jY3Vycz0iMCIvPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0iZXh0IiB0eXBl PSJzcHBwYjpFeHRBbnlUeXBlIiBtaW5PY2N1cnM9IjAiLz4KICAgICAgICA8L3NlcXVlbmNlPgog ICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4K ICA8Y29tcGxleFR5cGUgbmFtZT0iVVJJVHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAg IDxleHRlbnNpb24gYmFzZT0ic3BwcGI6UnRlUmVjVHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgog ICAgICAgICAgPGVsZW1lbnQgbmFtZT0iZXJlIiB0eXBlPSJzdHJpbmciIGRlZmF1bHQ9Il4oLiop JCIvPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0idXJpIiB0eXBlPSJzdHJpbmciLz4KICAgICAg ICAgIDxlbGVtZW50IG5hbWU9ImV4dCIgdHlwZT0ic3BwcGI6RXh0QW55VHlwZSIgbWluT2NjdXJz PSIwIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBs ZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IlJ0ZUdycE9m ZmVyVHlwZSI+CiAgICA8c2VxdWVuY2U+CiAgICAgIDxlbGVtZW50IG5hbWU9ImJhc2UiIHR5cGU9 InNwcHBiOkJhc2ljT2JqVHlwZSIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJydGVHcnBPZmZlcktl eSIgdHlwZT0ic3BwcGI6UnRlR3JwT2ZmZXJLZXlUeXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9 InN0YXR1cyIgdHlwZT0ic3BwcGI6UnRlR3JwT2ZmZXJTdGF0dXNUeXBlIi8+CiAgICAgIDxlbGVt ZW50IG5hbWU9Im9mZmVyRGF0ZVRpbWUiIHR5cGU9ImRhdGVUaW1lIi8+CiAgICAgIDxlbGVtZW50 IG5hbWU9ImFjY2VwdERhdGVUaW1lIiB0eXBlPSJkYXRlVGltZSIgbWluT2NjdXJzPSIwIi8+CiAg ICAgIDxlbGVtZW50IG5hbWU9ImV4dCIgdHlwZT0ic3BwcGI6RXh0QW55VHlwZSIgbWluT2NjdXJz PSIwIi8+CiAgICA8L3NlcXVlbmNlPgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5h bWU9IkVnclJ0ZVR5cGUiPgogICAgPHNlcXVlbmNlPgogICAgICA8ZWxlbWVudCBuYW1lPSJiYXNl IiB0eXBlPSJzcHBwYjpCYXNpY09ialR5cGUiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0iZWdyUnRl TmFtZSIgdHlwZT0ic3BwcGI6T2JqTmFtZVR5cGUiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0icHJl ZiIgdHlwZT0idW5zaWduZWRTaG9ydCIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJzdmNzIiB0eXBl PSJzdHJpbmciLz4KICAgICAgPGVsZW1lbnQgbmFtZT0icmVneFJld3JpdGVSdWxlIiB0eXBlPSJz cHBwYjpSZWdleFBhcmFtVHlwZSIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJpbmdyZXNzUnRlIiB0 eXBlPSJzcHBwYjpPYmpLZXlUeXBlIiBtaW5PY2N1cnM9IjAiLz4KICAgICAgPGVsZW1lbnQgbmFt ZT0iZXh0IiB0eXBlPSJzcHBwYjpFeHRBbnlUeXBlIiBtaW5PY2N1cnM9IjAiLz4KICAgIDwvc2Vx dWVuY2U+CiAgPC9jb21wbGV4VHlwZT4KICA8YW5ub3RhdGlvbj4KICAgIDxkb2N1bWVudGF0aW9u PiAtLS0tLS0tLS0tLS0tLS0tLS0gQWJzdHJhY3QgT2JqZWN0IGFuZCBFbGVtZW50CiAgICAgIFR5 cGUgRGVmaW5pdGlvbnMgLS0tLS0tLS0tLS0tLS0gPC9kb2N1bWVudGF0aW9uPgogIDwvYW5ub3Rh dGlvbj4KICA8Y29tcGxleFR5cGUgbmFtZT0iQmFzaWNPYmpUeXBlIj4KICAgIDxzZXF1ZW5jZT4K ICAgICAgPGVsZW1lbnQgbmFtZT0icmFudElkIiB0eXBlPSJzcHBwYjpPcmdJZFR5cGUiLz4KICAg ICAgPGVsZW1lbnQgbmFtZT0icmFySWQiIHR5cGU9InNwcHBiOk9yZ0lkVHlwZSIvPgogICAgICA8 ZWxlbWVudCBuYW1lPSJleHQiIHR5cGU9InNwcHBiOkV4dEFueVR5cGUiIG1pbk9jY3Vycz0iMCIv PgogICAgPC9zZXF1ZW5jZT4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJS dGVSZWNUeXBlIiBhYnN0cmFjdD0idHJ1ZSI+CiAgICA8c2VxdWVuY2U+CiAgICAgIDxlbGVtZW50 IG5hbWU9InByaW9yaXR5IiB0eXBlPSJwb3NpdGl2ZUludGVnZXIiIGRlZmF1bHQ9IjEwMCIvPgog ICAgPC9zZXF1ZW5jZT4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJSZWdl eFBhcmFtVHlwZSI+CiAgICA8c2VxdWVuY2U+CiAgICAgIDxlbGVtZW50IG5hbWU9ImVyZSIgdHlw ZT0ic3RyaW5nIiBkZWZhdWx0PSJeKC4qKSQiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0icmVwbCIg dHlwZT0ic3RyaW5nIi8+CiAgICA8L3NlcXVlbmNlPgogIDwvY29tcGxleFR5cGU+CiAgPHNpbXBs ZVR5cGUgbmFtZT0iT3JnSWRUeXBlIj4KICAgIDxyZXN0cmljdGlvbiBiYXNlPSJzdHJpbmciLz4K ICA8L3NpbXBsZVR5cGU+CiAgPHNpbXBsZVR5cGUgbmFtZT0iT2JqTmFtZVR5cGUiPgogICAgPHJl c3RyaWN0aW9uIGJhc2U9InN0cmluZyIvPgogIDwvc2ltcGxlVHlwZT4KICA8c2ltcGxlVHlwZSBu YW1lPSJUcmFuc0lkVHlwZSI+CiAgICA8cmVzdHJpY3Rpb24gYmFzZT0ic3RyaW5nIi8+CiAgPC9z aW1wbGVUeXBlPgogIDxzaW1wbGVUeXBlIG5hbWU9Ik1pbm9yVmVyVHlwZSI+CiAgICA8cmVzdHJp Y3Rpb24gYmFzZT0idW5zaWduZWRMb25nIi8+CiAgPC9zaW1wbGVUeXBlPgogIDxjb21wbGV4VHlw ZSBuYW1lPSJPYmpLZXlUeXBlIj4KICAgIDxzZXF1ZW5jZT4KICAgICAgPGVsZW1lbnQgbmFtZT0i cmFudElkIiB0eXBlPSJzcHBwYjpPcmdJZFR5cGUiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0ibmFt ZSIgdHlwZT0ic3BwcGI6T2JqTmFtZVR5cGUiLz4KICAgIDwvc2VxdWVuY2U+CiAgPC9jb21wbGV4 VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iUnRlR3JwT2ZmZXJLZXlUeXBlIj4KICAgIDxzZXF1 ZW5jZT4KICAgICAgPGVsZW1lbnQgbmFtZT0icnRlR3JwS2V5IiB0eXBlPSJzcHBwYjpPYmpLZXlU eXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9Im9mZmVyZWRUbyIgdHlwZT0ic3BwcGI6T3JnSWRU eXBlIi8+CiAgICA8L3NlcXVlbmNlPgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5h bWU9IkJhc2ljUnFzdFR5cGUiPgogICAgPHNlcXVlbmNlPgogICAgICA8ZWxlbWVudCBuYW1lPSJj bGllbnRUcmFuc0lkIiB0eXBlPSJzcHBwYjpUcmFuc0lkVHlwZSIKICAgICAgICBtaW5PY2N1cnM9 IjAiLz4KICAgICAgPGVsZW1lbnQgbmFtZT0ibWlub3JWZXIiIHR5cGU9InNwcHBiOk1pbm9yVmVy VHlwZSIgbWluT2NjdXJzPSIwIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9ImV4dCIgdHlwZT0ic3Bw cGI6RXh0QW55VHlwZSIgbWluT2NjdXJzPSIwIi8+CiAgICA8L3NlcXVlbmNlPgogIDwvY29tcGxl eFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IkJhc2ljUnNwbnNUeXBlIj4KICAgIDxzZXF1ZW5j ZT4KICAgICAgPGVsZW1lbnQgbmFtZT0iY2xpZW50VHJhbnNJZCIgdHlwZT0ic3BwcGI6VHJhbnNJ ZFR5cGUiCiAgICAgICAgbWluT2NjdXJzPSIwIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9InNlcnZl clRyYW5zSWQiIHR5cGU9InNwcHBiOlRyYW5zSWRUeXBlIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9 InJlc0NvZGUiIHR5cGU9ImludCIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJyZXNNc2ciIHR5cGU9 InN0cmluZyIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJleHQiIHR5cGU9InNwcHBiOkV4dEFueVR5 cGUiIG1pbk9jY3Vycz0iMCIvPgogICAgPC9zZXF1ZW5jZT4KICAgIDxhdHRyaWJ1dGUgbmFtZT0i Y2xpZW50VHJhbnNJZCIgdHlwZT0ic3BwcGI6VHJhbnNJZFR5cGUiLz4KICAgIDxhdHRyaWJ1dGUg bmFtZT0ic2VydmVyVHJhbnNJZCIgdHlwZT0ic3BwcGI6VHJhbnNJZFR5cGUiLz4KICA8L2NvbXBs ZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJJUEFkZHJUeXBlIj4KICAgIDxzZXF1ZW5jZT4K ICAgICAgPGVsZW1lbnQgbmFtZT0iYWRkciIgdHlwZT0ic3RyaW5nIi8+CiAgICAgIDxlbGVtZW50 IG5hbWU9InR5cGUiIHR5cGU9InNwcHBiOklQVHlwZSIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJl eHQiIHR5cGU9InNwcHBiOkV4dEFueVR5cGUiIG1pbk9jY3Vycz0iMCIvPgogICAgPC9zZXF1ZW5j ZT4KICA8L2NvbXBsZXhUeXBlPgogIDxzaW1wbGVUeXBlIG5hbWU9IklQVHlwZSI+CiAgICA8cmVz dHJpY3Rpb24gYmFzZT0idG9rZW4iPgogICAgICA8ZW51bWVyYXRpb24gdmFsdWU9IklQdjQiLz4K ICAgICAgPGVudW1lcmF0aW9uIHZhbHVlPSJJUHY2Ii8+CiAgICA8L3Jlc3RyaWN0aW9uPgogIDwv c2ltcGxlVHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iU291cmNlSWRlbnRUeXBlIj4KICAgIDxz ZXF1ZW5jZT4KICAgICAgPGVsZW1lbnQgbmFtZT0ic291cmNlSWRlbnRMYWJlbCIgdHlwZT0ic3Ry aW5nIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9InNvdXJjZUlkZW50U2NoZW1lIgogICAgICAgIHR5 cGU9InNwcHBiOlNvdXJjZUlkZW50U2NoZW1lVHlwZSIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJl eHQiIHR5cGU9InNwcHBiOkV4dEFueVR5cGUiIG1pbk9jY3Vycz0iMCIvPgogICAgPC9zZXF1ZW5j ZT4KICA8L2NvbXBsZXhUeXBlPgogIDxzaW1wbGVUeXBlIG5hbWU9IlNvdXJjZUlkZW50U2NoZW1l VHlwZSI+CiAgICA8cmVzdHJpY3Rpb24gYmFzZT0idG9rZW4iPgogICAgICA8ZW51bWVyYXRpb24g dmFsdWU9InVyaSIvPgogICAgICA8ZW51bWVyYXRpb24gdmFsdWU9ImlwIi8+CiAgICAgIDxlbnVt ZXJhdGlvbiB2YWx1ZT0icm9vdERvbWFpbiIvPgogICAgPC9yZXN0cmljdGlvbj4KICA8L3NpbXBs ZVR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IkNPUkluZm9UeXBlIj4KICAgIDxzZXF1ZW5jZT4K ICAgICAgPGVsZW1lbnQgbmFtZT0iY29yQ2xhaW0iIHR5cGU9ImJvb2xlYW4iIGRlZmF1bHQ9InRy dWUiCiAgICAgICAgbWluT2NjdXJzPSIwIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9ImNvciIgdHlw ZT0iYm9vbGVhbiIgZGVmYXVsdD0iZmFsc2UiIG1pbk9jY3Vycz0iMCIvPgogICAgICA8ZWxlbWVu dCBuYW1lPSJhc3NpZ25lZENvckRhdGVUaW1lIiB0eXBlPSJkYXRlVGltZSIKICAgICAgICBtaW5P Y2N1cnM9IjAiLz4KICAgIDwvc2VxdWVuY2U+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5 cGUgbmFtZT0iU3ZjTWVudVR5cGUiPgogICAgPHNlcXVlbmNlPgogICAgICA8ZWxlbWVudCBuYW1l PSJzZXJ2ZXJTdGF0dXMiIHR5cGU9InNwcHBiOlNlcnZlclN0YXR1c1R5cGUiLz4KICAgICAgPGVs ZW1lbnQgbmFtZT0ibWFqTWluVmVyc2lvbiIgdHlwZT0ic3RyaW5nIgogICAgICAgIG1heE9jY3Vy cz0idW5ib3VuZGVkIi8+CiAgICAgIDxlbGVtZW50IG5hbWU9Im9ialVSSSIgdHlwZT0iYW55VVJJ IiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICA8ZWxlbWVudCBuYW1lPSJleHRVUkkiIHR5 cGU9ImFueVVSSSIgbWluT2NjdXJzPSIwIgogICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+ CiAgICA8L3NlcXVlbmNlPgogIDwvY29tcGxleFR5cGU+CiAgPHNpbXBsZVR5cGUgbmFtZT0iU2Vy dmVyU3RhdHVzVHlwZSI+CiAgICA8cmVzdHJpY3Rpb24gYmFzZT0idG9rZW4iPgogICAgICA8ZW51 bWVyYXRpb24gdmFsdWU9ImluU2VydmljZSIvPgogICAgICA8ZW51bWVyYXRpb24gdmFsdWU9Im91 dE9mU2VydmljZSIvPgogICAgPC9yZXN0cmljdGlvbj4KICA8L3NpbXBsZVR5cGU+CiAgPHNpbXBs ZVR5cGUgbmFtZT0iUnRlR3JwT2ZmZXJTdGF0dXNUeXBlIj4KICAgIDxyZXN0cmljdGlvbiBiYXNl PSJ0b2tlbiI+CiAgICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0ib2ZmZXJlZCIvPgogICAgICA8ZW51 bWVyYXRpb24gdmFsdWU9ImFjY2VwdGVkIi8+CiAgICA8L3Jlc3RyaWN0aW9uPgogIDwvc2ltcGxl VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iRXh0QW55VHlwZSI+CiAgICA8c2VxdWVuY2U+CiAg ICAgIDxhbnkgbmFtZXNwYWNlPSIjI290aGVyIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAg PC9zZXF1ZW5jZT4KICA8L2NvbXBsZXhUeXBlPgogIDxhbm5vdGF0aW9uPgogICAgPGRvY3VtZW50 YXRpb24+IC0tLS0tLS0tLS0tLS0tIE9wZXJhdGlvbiBSZXF1ZXN0IGFuZCBSZXNwb25zZQogICAg ICBPYmplY3QgVHlwZSBEZWZpbml0aW9ucyAtLS0tLS0tLS0tLS0gPC9kb2N1bWVudGF0aW9uPgog IDwvYW5ub3RhdGlvbj4KICA8Y29tcGxleFR5cGUgbmFtZT0iQWRkUnRlR3Jwc1Jxc3RUeXBlIj4K ICAgIDxjb21wbGV4Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1Jx c3RUeXBlIj4KICAgICAgICA8c2VxdWVuY2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJydGVH cnAiIHR5cGU9InNwcHBiOlJ0ZUdycFR5cGUiCiAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3Vu ZGVkIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBs ZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IkRlbFJ0ZUdy cHNScXN0VHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0i c3BwcGI6QmFzaWNScXN0VHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1l bnQgbmFtZT0ib2JqZWN0S2V5IiB0eXBlPSJzcHBwYjpPYmpLZXlUeXBlIgogICAgICAgICAgICBt YXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5z aW9uPgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlw ZSBuYW1lPSJHZXRSdGVHcnBzUnFzdFR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8 ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4K ICAgICAgICAgIDxlbGVtZW50IG5hbWU9Im9iamVjdEtleSIgdHlwZT0ic3BwcGI6T2JqS2V5VHlw ZSIKICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAg ICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4K ICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJHZXRSdGVHcnBzUnNwbnNUeXBl Ij4KICAgIDxjb21wbGV4Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNp Y1JzcG5zVHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0i cnRlR3JwIiB0eXBlPSJzcHBwYjpSdGVHcnBUeXBlIiBtaW5PY2N1cnM9IjAiCiAgICAgICAgICAg IG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRl bnNpb24+CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhU eXBlIG5hbWU9IkFkZERlc3RHcm91cHNScXN0VHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAg ICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6QmFzaWNScXN0VHlwZSI+CiAgICAgICAgPHNlcXVl bmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0iZGVzdEdycCIgdHlwZT0ic3BwcGI6RGVzdEdy cFR5cGUiCiAgICAgICAgICAgIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICAgICAgPC9zZXF1 ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxl eFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IkRlbERlc3RHcm91cHNScXN0VHlwZSI+CiAgICA8 Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6QmFzaWNScXN0VHlw ZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0ib2JqZWN0S2V5 IiB0eXBlPSJzcHBwYjpPYmpLZXlUeXBlIgogICAgICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRl ZCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4 Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJHZXREZXN0R3Jv dXBzUnFzdFR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9 InNwcHBiOkJhc2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVt ZW50IG5hbWU9Im9iamVjdEtleSIgdHlwZT0ic3BwcGI6T2JqS2V5VHlwZSIKICAgICAgICAgICAg bWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICAgIDwvc2VxdWVuY2U+ CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBl PgogIDxjb21wbGV4VHlwZSBuYW1lPSJHZXREZXN0R3JvdXBzUnNwbnNUeXBlIj4KICAgIDxjb21w bGV4Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSI+ CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0iZGVzdEdycCIgdHlw ZT0ic3BwcGI6RGVzdEdycFR5cGUiCiAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJz PSJ1bmJvdW5kZWQiLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAg IDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0i QWRkUHViSWRzUnFzdFR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9u IGJhc2U9InNwcHBiOkJhc2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAg IDxlbGVtZW50IG5hbWU9InBpIiB0eXBlPSJzcHBwYjpQdWJJZFR5cGUiIG1pbk9jY3Vycz0iMCIK ICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICA8L3NlcXVlbmNlPgog ICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4K ICA8Y29tcGxleFR5cGUgbmFtZT0iQWRkUHViSWRzUnNwbnNUeXBlIj4KICAgIDxjb21wbGV4Q29u dGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSI+CiAgICAg ICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiIG1p bk9jY3Vycz0iMCIgbmFtZT0icGkiCiAgICAgICAgICAgIHR5cGU9InNwcHBiOlB1YklkVHlwZSIv PgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29u dGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJEZWxQdWJJZHNScXN0 VHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6 QmFzaWNScXN0VHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFt ZT0icGkiIHR5cGU9InNwcHBiOlB1YklkVHlwZSIKICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJv dW5kZWQiLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29t cGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iR2V0UHVi SWRzUnFzdFR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9 InNwcHBiOkJhc2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAgICAgICAgIDxlbGVt ZW50IG5hbWU9InBpIiB0eXBlPSJzcHBwYjpQdWJJZFR5cGUiIG1pbk9jY3Vycz0iMCIKICAgICAg ICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8 L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29t cGxleFR5cGUgbmFtZT0iR2V0UHViSWRzUnNwbnNUeXBlIj4KICAgIDxjb21wbGV4Q29udGVudD4K ICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSI+CiAgICAgICAgPHNl cXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0icGkiIHR5cGU9InNwcHBiOlB1YklkVHlw ZSIgbWluT2NjdXJzPSIwIgogICAgICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAg ICAgIDwvc2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4K ICA8L2NvbXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJBZGRSdGVHcnBPZmZlcnNScXN0 VHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6 QmFzaWNScXN0VHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFt ZT0icnRlR3JwT2ZmZXIiIHR5cGU9InNwcHBiOlJ0ZUdycE9mZmVyVHlwZSIKICAgICAgICAgICAg bWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8L2V4dGVu c2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5 cGUgbmFtZT0iRGVsUnRlR3JwT2ZmZXJzUnFzdFR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50Pgog ICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1 ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InJ0ZUdycE9mZmVyS2V5IgogICAgICAgICAg ICB0eXBlPSJzcHBwYjpSdGVHcnBPZmZlcktleVR5cGUiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+ CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBsZXhDb250 ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9IkFjY2VwdFJ0ZUdycE9m ZmVyc1Jxc3RUeXBlIj4KICAgIDxjb21wbGV4Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNl PSJzcHBwYjpCYXNpY1Jxc3RUeXBlIj4KICAgICAgICA8c2VxdWVuY2U+CiAgICAgICAgICA8ZWxl bWVudCBuYW1lPSJydGVHcnBPZmZlcktleSIKICAgICAgICAgICAgdHlwZT0ic3BwcGI6UnRlR3Jw T2ZmZXJLZXlUeXBlIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICAgIDwvc2VxdWVuY2U+ CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBl PgogIDxjb21wbGV4VHlwZSBuYW1lPSJSZWplY3RSdGVHcnBPZmZlcnNScXN0VHlwZSI+CiAgICA8 Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNpb24gYmFzZT0ic3BwcGI6QmFzaWNScXN0VHlw ZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0icnRlR3JwT2Zm ZXJLZXkiCiAgICAgICAgICAgIHR5cGU9InNwcHBiOlJ0ZUdycE9mZmVyS2V5VHlwZSIgbWF4T2Nj dXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4K ICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFt ZT0iR2V0UnRlR3JwT2ZmZXJzUnFzdFR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50PgogICAgICA8 ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4K ICAgICAgICAgIDxlbGVtZW50IG5hbWU9Im9mZmVyZWRCeVBlZXJzIiB0eXBlPSJib29sZWFuIiBt aW5PY2N1cnM9IjAiLz4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9Im9mZmVyZWRUb1BlZXJzIiB0 eXBlPSJib29sZWFuIiBtaW5PY2N1cnM9IjAiLz4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InN0 YXR1cyIgdHlwZT0ic3BwcGI6UnRlR3JwT2ZmZXJTdGF0dXNUeXBlIgogICAgICAgICAgICBtaW5P Y2N1cnM9IjAiLz4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InBlZXJpbmdPcmciIHR5cGU9InNw cHBiOk9yZ0lkVHlwZSIKICAgICAgICAgICAgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91 bmRlZCIvPgogICAgICAgICAgPGVsZW1lbnQgbmFtZT0icnRlR3JwT2ZmZXJLZXkiCiAgICAgICAg ICAgIHR5cGU9InNwcHBiOlJ0ZUdycE9mZmVyS2V5VHlwZSIgbWluT2NjdXJzPSIwIgogICAgICAg ICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwv ZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21w bGV4VHlwZSBuYW1lPSJHZXRSdGVHcnBPZmZlcnNSc3Buc1R5cGUiPgogICAgPGNvbXBsZXhDb250 ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnNwbnNUeXBlIj4KICAgICAg ICA8c2VxdWVuY2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJydGVHcnBPZmZlciIgdHlwZT0i c3BwcGI6UnRlR3JwT2ZmZXJUeXBlIgogICAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vy cz0idW5ib3VuZGVkIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAg ICA8L2NvbXBsZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGNvbXBsZXhUeXBlIG5hbWU9 IkFkZEVnclJ0ZXNScXN0VHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRlbnNp b24gYmFzZT0ic3BwcGI6QmFzaWNScXN0VHlwZSI+CiAgICAgICAgPHNlcXVlbmNlPgogICAgICAg ICAgPGVsZW1lbnQgbmFtZT0iZWdyUnRlIiB0eXBlPSJzcHBwYjpFZ3JSdGVUeXBlIgogICAgICAg ICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICAgIDwvc2VxdWVuY2U+CiAgICAgIDwv ZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2NvbXBsZXhUeXBlPgogIDxjb21w bGV4VHlwZSBuYW1lPSJEZWxFZ3JSdGVzUnFzdFR5cGUiPgogICAgPGNvbXBsZXhDb250ZW50Pgog ICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnFzdFR5cGUiPgogICAgICAgIDxzZXF1 ZW5jZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9Im9iamVjdEtleSIgdHlwZT0ic3BwcGI6T2Jq S2V5VHlwZSIKICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICA8L3Nl cXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21w bGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFtZT0iR2V0RWdyUnRlc1Jxc3RUeXBlIj4KICAgIDxj b21wbGV4Q29udGVudD4KICAgICAgPGV4dGVuc2lvbiBiYXNlPSJzcHBwYjpCYXNpY1Jxc3RUeXBl Ij4KICAgICAgICA8c2VxdWVuY2U+CiAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJvYmplY3RLZXki IHR5cGU9InNwcHBiOk9iaktleVR5cGUiCiAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2Nj dXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgICA8L3NlcXVlbmNlPgogICAgICA8L2V4dGVuc2lvbj4K ICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5cGUgbmFt ZT0iR2V0RWdyUnRlc1JzcG5zVHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAgIDxleHRl bnNpb24gYmFzZT0ic3BwcGI6QmFzaWNSc3Buc1R5cGUiPgogICAgICAgIDxzZXF1ZW5jZT4KICAg ICAgICAgIDxlbGVtZW50IG5hbWU9InJ0ZUdycCIgdHlwZT0ic3BwcGI6UnRlR3JwVHlwZSIgbWlu T2NjdXJzPSIwIgogICAgICAgICAgICBtYXhPY2N1cnM9InVuYm91bmRlZCIvPgogICAgICAgIDwv c2VxdWVuY2U+CiAgICAgIDwvZXh0ZW5zaW9uPgogICAgPC9jb21wbGV4Q29udGVudD4KICA8L2Nv bXBsZXhUeXBlPgogIDxjb21wbGV4VHlwZSBuYW1lPSJHZXRTdmNNZW51UnFzdFR5cGUiPgogICAg PGNvbXBsZXhDb250ZW50PgogICAgICA8ZXh0ZW5zaW9uIGJhc2U9InNwcHBiOkJhc2ljUnFzdFR5 cGUiLz4KICAgIDwvY29tcGxleENvbnRlbnQ+CiAgPC9jb21wbGV4VHlwZT4KICA8Y29tcGxleFR5 cGUgbmFtZT0iR2V0U3ZjTWVudVJzcG5zVHlwZSI+CiAgICA8Y29tcGxleENvbnRlbnQ+CiAgICAg IDxleHRlbnNpb24gYmFzZT0ic3BwcGI6QmFzaWNSc3Buc1R5cGUiPgogICAgICAgIDxzZXF1ZW5j ZT4KICAgICAgICAgIDxlbGVtZW50IG5hbWU9InN2Y01lbnUiIHR5cGU9InNwcHBiOlN2Y01lbnVU eXBlIi8+CiAgICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPC9leHRlbnNpb24+CiAgICA8L2NvbXBs ZXhDb250ZW50PgogIDwvY29tcGxleFR5cGU+CiAgPGFubm90YXRpb24+CiAgICA8ZG9jdW1lbnRh dGlvbj4gLS0tLS0tLS0tLS0tLS0gT3BlcmF0aW9uIFJlcXVlc3QgYW5kIFJlc3BvbnNlCiAgICAg IEVsZW1lbnQgRGVmaW5pdGlvbnMgLS0tLS0tLS0tLS0tIDwvZG9jdW1lbnRhdGlvbj4KICA8L2Fu bm90YXRpb24+CiAgPGFubm90YXRpb24+CiAgICA8ZG9jdW1lbnRhdGlvbj4gLS0tLS0tLS0tLS0t LS0gTWFuYWdlIFJvdXRlIEdyb3VwcwogICAgPC9kb2N1bWVudGF0aW9uPgogIDwvYW5ub3RhdGlv bj4KICA8ZWxlbWVudCBuYW1lPSJhZGRSdGVHcnBzUnFzdCIgdHlwZT0ic3BwcGI6QWRkUnRlR3Jw c1Jxc3RUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iZGVsUnRlR3Jwc1Jxc3QiIHR5cGU9InNwcHBi OkRlbFJ0ZUdycHNScXN0VHlwZSIvPgogIDxlbGVtZW50IG5hbWU9ImdldFJ0ZUdycHNScXN0IiB0 eXBlPSJzcHBwYjpHZXRSdGVHcnBzUnFzdFR5cGUiLz4KICA8ZWxlbWVudCBuYW1lPSJhZGRSdGVH cnBzUnNwbnMiIHR5cGU9InNwcHBiOkJhc2ljUnNwbnNUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0i ZGVsUnRlR3Jwc1JzcG5zIiB0eXBlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSIvPgogIDxlbGVtZW50 IG5hbWU9ImdldFJ0ZUdycHNSc3BucyIgdHlwZT0ic3BwcGI6R2V0UnRlR3Jwc1JzcG5zVHlwZSIv PgogIDxhbm5vdGF0aW9uPgogICAgPGRvY3VtZW50YXRpb24+IC0tLS0tLS0tLS0tLS0tIE1hbmFn ZSBEZXN0aW5hdGlvbiBHcm91cHMKICAgIDwvZG9jdW1lbnRhdGlvbj4KICA8L2Fubm90YXRpb24+ CiAgPGVsZW1lbnQgbmFtZT0iYWRkRGVzdEdyb3Vwc1Jxc3QiIHR5cGU9InNwcHBiOkFkZERlc3RH cm91cHNScXN0VHlwZSIvPgogIDxlbGVtZW50IG5hbWU9ImRlbERlc3RHcm91cHNScXN0IiB0eXBl PSJzcHBwYjpEZWxEZXN0R3JvdXBzUnFzdFR5cGUiLz4KICA8ZWxlbWVudCBuYW1lPSJnZXREZXN0 R3JvdXBzUnFzdCIgdHlwZT0ic3BwcGI6R2V0RGVzdEdyb3Vwc1Jxc3RUeXBlIi8+CiAgPGVsZW1l bnQgbmFtZT0iYWRkRGVzdEdyb3Vwc1JzcG5zIiB0eXBlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSIv PgogIDxlbGVtZW50IG5hbWU9ImRlbERlc3RHcm91cHNSc3BucyIgdHlwZT0ic3BwcGI6QmFzaWNS c3Buc1R5cGUiLz4KICA8ZWxlbWVudCBuYW1lPSJnZXREZXN0R3JvdXBzUnNwbnMiCiAgICB0eXBl PSJzcHBwYjpHZXREZXN0R3JvdXBzUnNwbnNUeXBlIi8+CiAgPGFubm90YXRpb24+CiAgICA8ZG9j dW1lbnRhdGlvbj4gLS0tLS0tLS0tLS0tLS0gTWFuYWdlIFB1YmxpYyBJZGVudGlmaWVycwogICAg PC9kb2N1bWVudGF0aW9uPgogIDwvYW5ub3RhdGlvbj4KICA8ZWxlbWVudCBuYW1lPSJhZGRQdWJJ ZHNScXN0IiB0eXBlPSJzcHBwYjpBZGRQdWJJZHNScXN0VHlwZSIvPgogIDxlbGVtZW50IG5hbWU9 ImRlbFB1Yklkc1Jxc3QiIHR5cGU9InNwcHBiOkRlbFB1Yklkc1Jxc3RUeXBlIi8+CiAgPGVsZW1l bnQgbmFtZT0iZ2V0UHViSWRzUnFzdCIgdHlwZT0ic3BwcGI6R2V0UHViSWRzUnFzdFR5cGUiLz4K ICA8ZWxlbWVudCBuYW1lPSJhZGRQdWJJZHNSc3BucyIgdHlwZT0ic3BwcGI6QWRkUHViSWRzUnNw bnNUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iZGVsUHViSWRzUnNwbnMiIHR5cGU9InNwcHBiOkJh c2ljUnNwbnNUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iZ2V0UHViSWRzUnNwbnMiIHR5cGU9InNw cHBiOkdldFB1Yklkc1JzcG5zVHlwZSIvPgogIDxhbm5vdGF0aW9uPgogICAgPGRvY3VtZW50YXRp b24+IC0tLS0tLS0tLS0tLS0tIE1hbmFnZSBSb3V0ZSBHcm91cCBPZmZlcnMKICAgIDwvZG9jdW1l bnRhdGlvbj4KICA8L2Fubm90YXRpb24+CiAgPGVsZW1lbnQgbmFtZT0iYWRkUnRlR3JwT2ZmZXJz UnFzdCIKICAgIHR5cGU9InNwcHBiOkFkZFJ0ZUdycE9mZmVyc1Jxc3RUeXBlIi8+CiAgPGVsZW1l bnQgbmFtZT0iZGVsUnRlR3JwT2ZmZXJzUnFzdCIKICAgIHR5cGU9InNwcHBiOkRlbFJ0ZUdycE9m ZmVyc1Jxc3RUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iYWNjZXB0UnRlR3JwT2ZmZXJzUnFzdCIK ICAgIHR5cGU9InNwcHBiOkFjY2VwdFJ0ZUdycE9mZmVyc1Jxc3RUeXBlIi8+CiAgPGVsZW1lbnQg bmFtZT0icmVqZWN0UnRlR3JwT2ZmZXJzUnFzdCIKICAgIHR5cGU9InNwcHBiOlJlamVjdFJ0ZUdy cE9mZmVyc1Jxc3RUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iZ2V0UnRlR3JwT2ZmZXJzUnFzdCIK ICAgIHR5cGU9InNwcHBiOkdldFJ0ZUdycE9mZmVyc1Jxc3RUeXBlIi8+CiAgPGVsZW1lbnQgbmFt ZT0iYWRkUnRlR3JwT2ZmZXJzUnNwbnMiIHR5cGU9InNwcHBiOkJhc2ljUnNwbnNUeXBlIi8+CiAg PGVsZW1lbnQgbmFtZT0iZGVsUnRlR3JwT2ZmZXJzUnNwbnMiIHR5cGU9InNwcHBiOkJhc2ljUnNw bnNUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iYWNjZXB0UnRlR3JwT2ZmZXJzUnNwbnMiIHR5cGU9 InNwcHBiOkJhc2ljUnNwbnNUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0icmVqZWN0UnRlR3JwT2Zm ZXJzUnNwbnMiIHR5cGU9InNwcHBiOkJhc2ljUnNwbnNUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0i Z2V0UnRlR3JwT2ZmZXJzUnNwbnMiCiAgICB0eXBlPSJzcHBwYjpHZXRSdGVHcnBPZmZlcnNSc3Bu c1R5cGUiLz4KICA8YW5ub3RhdGlvbj4KICAgIDxkb2N1bWVudGF0aW9uPiAtLS0tLS0tLS0tLS0t LSBNYW5hZ2UgRWdyZXNzIFJvdXRlcwogICAgPC9kb2N1bWVudGF0aW9uPgogIDwvYW5ub3RhdGlv bj4KICA8ZWxlbWVudCBuYW1lPSJhZGRFZ3JSdGVzUnFzdCIgdHlwZT0ic3BwcGI6QWRkRWdyUnRl c1Jxc3RUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0iZGVsRWdyUnRlc1Jxc3QiIHR5cGU9InNwcHBi OkRlbEVnclJ0ZXNScXN0VHlwZSIvPgogIDxlbGVtZW50IG5hbWU9ImdldEVnclJ0ZXNScXN0IiB0 eXBlPSJzcHBwYjpHZXRFZ3JSdGVzUnFzdFR5cGUiLz4KICA8ZWxlbWVudCBuYW1lPSJhZGRFZ3JS dGVzUnNwbnMiIHR5cGU9InNwcHBiOkJhc2ljUnNwbnNUeXBlIi8+CiAgPGVsZW1lbnQgbmFtZT0i ZGVsRWdyUnRlc1JzcG5zIiB0eXBlPSJzcHBwYjpCYXNpY1JzcG5zVHlwZSIvPgogIDxlbGVtZW50 IG5hbWU9ImdldEVnclJ0ZXNSc3BucyIgdHlwZT0ic3BwcGI6R2V0RWdyUnRlc1JzcG5zVHlwZSIv PgogIDxhbm5vdGF0aW9uPgogICAgPGRvY3VtZW50YXRpb24+IC0tLS0tLS0tLS0tLS0tIE1pc2Mg T3BlcmF0aW9ucyA8L2RvY3VtZW50YXRpb24+CiAgPC9hbm5vdGF0aW9uPgogIDxlbGVtZW50IG5h bWU9ImdldFN2Y01lbnVScXN0IiB0eXBlPSJzcHBwYjpHZXRTdmNNZW51UnFzdFR5cGUiLz4KICA8 ZWxlbWVudCBuYW1lPSJnZXRTdmNNZW51UnNwbnMiIHR5cGU9InNwcHBiOkdldFN2Y01lbnVSc3Bu c1R5cGUiLz4KICA8YW5ub3RhdGlvbj4KICAgIDxkb2N1bWVudGF0aW9uPiAtLS0tLS0tLSBHZW5l cmljIFJlcXVlc3QgYW5kIFJlc3BvbnNlIERlZmluaXRpb25zCiAgICAgIC0tLS0tLS0tLS0tLS0t LSA8L2RvY3VtZW50YXRpb24+CiAgPC9hbm5vdGF0aW9uPgogIDxlbGVtZW50IG5hbWU9InNwcHBS ZXF1ZXN0Ij4KICAgIDxjb21wbGV4VHlwZT4KICAgICAgPHNlcXVlbmNlPgogICAgICAgIDxhbnkg bWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAgICAgPC9zZXF1ZW5jZT4KICAgICAgPGF0dHJpYnV0 ZSBuYW1lPSJ0cmFuc2FjdGlvbmFsIiB0eXBlPSJib29sZWFuIiB1c2U9Im9wdGlvbmFsIi8+CiAg ICA8L2NvbXBsZXhUeXBlPgogIDwvZWxlbWVudD4KICA8ZWxlbWVudCBuYW1lPSJzcHBwUmVzcG9u c2UiPgogICAgPGNvbXBsZXhUeXBlPgogICAgICA8c2VxdWVuY2U+CiAgICAgICAgPGFueSBtYXhP Y2N1cnM9InVuYm91bmRlZCIvPgogICAgICA8L3NlcXVlbmNlPgogICAgPC9jb21wbGV4VHlwZT4K ICA8L2VsZW1lbnQ+Cjwvc2NoZW1hPgo= --_002_C890499043002syedalineustarbiz_-- From kcartwright@tnsi.com Tue Aug 17 11:58:03 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52163A6909 for ; Tue, 17 Aug 2010 11:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_20=-0.74, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY8WxmsOJ-GH for ; Tue, 17 Aug 2010 11:58:02 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 32F823A67EB for ; Tue, 17 Aug 2010 11:58:01 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.46786839; Tue, 17 Aug 2010 14:58:33 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 17 Aug 2010 14:58:33 -0400 From: "Cartwright, Ken" To: "Ali, Syed Wasim" , "jf.mule@cablelabs.com" Date: Tue, 17 Aug 2010 14:58:32 -0400 Thread-Topic: update to CORInfoType Thread-Index: Acs80jpajVTytdNW50uMweQLDL/agQAhYZlQADgJtzAAAEQLAA== Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24493CFF8E@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA2449310423@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] update to CORInfoType X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:58:03 -0000 Cool. It sounds like we're in sync on items 1 and 2. But on item 3 I have= the following thoughts a) Partial Success Within a Single Rqst Object (as apposed to across multip= le request objects): You seem to be proposing that we allow partial succes= s within a single AddPubIdRqstType object. We had decided to not allow tha= t (but we would allow it across multiple such objects, hence the current de= sign of the protocol). The current XSD as designed does not allow that at = all across any operations. So if we do want to allow that then we need to = revisit this across all the responses to make the protocol self consistent.= I'm ok with making this change, but we just need to acknowledge what we a= re proposing. This adds in notable complexity and will probably require us = to revisit the design of our response codes. But if we need to do it to su= pport use cases needed by some organizations then we should do it. b) "Track Id": Relying on the client to pass in a somewhat arbitrary integ= er, trkId (which one might call a "temporary synthetic key"), is I think no= t reliable enough a mechanism to play the role as the link between an objec= t passed in and its success/failure/status result. It makes the code on bo= th the client and server more complicated and more brittle. If we want to = support this kind of thing I think we either need to echo back each object = and its properties in the response (or perhaps just each object that was no= t fully successful) along with its specific result code, or echo back just = the object key of each object along with its specific result code and consi= der the need to add in a new response code to indicate the result of the CO= R claim. Ken -----Original Message----- From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz] Sent: Tuesday, August 17, 2010 2:14 PM To: Cartwright, Ken; jf.mule@cablelabs.com Cc: drinks@ietf.org Subject: Re: update to CORInfoType Thanks for the quick response. Please, see comments below: On 8/16/10 12:35 PM, "Cartwright, Ken" wrote: > Hi Syed, > > A few points about this: > > 1) The corClaim and cor elements can't be a "choice" element because when= a > client app queries for the properties of a PublicIdentifier they need to = know > whether they sumitted it with a COR claim *and* whether that claim has be= en > approved. I think your intended goal could instead be accomplished by > combining the corClaim and the cor elements into a single element of type > enumeration whose values could be "noClaimRqst" "claimRqst" > "claimRqstApproved" "claimRqstRejected". This is a valid point. And while use of carrier-of-record claim is certainl= y one way to request COR processing, a lot of systems today maintain this indicator implicitly that makes an explicit claim in the request unnecessary. While we can try to cover all possibilities using enumerated values, I think the original proposed boolean values should be sufficient. = I will remove the 'choice'. > 2) I think I have come to agree with you that there should be an option t= o > allow the result of a cor claim to be returned synchronously. The scalab= ility > concern that I have about doing this synchronously is more of an on > operational and/or policy concern. Bulk requests that perform this cor c= heck > synchronously and send the response synchronously will of course be slowe= r and > result in a lot more data sent over the wire, however, some installations= may > need or want to function this way and therefore are willing to pay this > performance price. However, the manner that this has been proposed in th= e XSD > I think may not work. See (3) below. Your concern for performance and excess data over the wire is not without merit. However, not including the result in the response message means separate 'getXXX' calls for all relevant requests in the bulk request message just to know the outcome. Also, the fact that CORInfoType is an optional element, it allows the needed flexibility in letting the Registry use policy knobs and return this information on a case by case basis. > 3) The proposed change is to add in a AddPubIdsRspnsType object that cont= ains > a set of CORINfoTypes. However, the CORInfoType does not contain the key= of > the PublicIdentity to which it applies. And it is not good practive to j= ust > assume that it is based on the order in which they are passed in. I thin= k if > we want to accomplish this, then we should include the full PubIdType obj= ect > in the response. I am with you on this one. I forgot about the 1-to-many association to PI. And COR is not the only case where the current schema definition of AddPubIdsRspnsType needs clarification. Consider the case where the request has multiple PI instances within a and the Registry could only honor some of them while others fail processing for one reason or another. There are a couple of ways to go about it. One, change the ordinal value for the composite AddPubIdsRqstType-->PI from 1..unbounded to 1..1. This way, the can be used to dereference the PI in the response. Two, add the *track_identifier* (trkId) attribute for each PI tha= t can be later referenced in the response to (1) convey the COR status in cases where the messages were processed successfully; and in case of a failure, (2) point to the particular PI instance in this message along with the correct failure response code. The former approach is too disruptive IM= O and adds bulk to the responses. The latter approach is do-able and tackles the failure scenarios well. I envision 'trkId' to be any arbitrary integer value the scope of which is limited to the immediate transaction, which is for the purpose of this discussion. To elaborate on this, = I am including a few examples below: - Activate three PIs txid-5555 rantId0 rarId0 DEST_GRP_1 true +12025556666 rantId0 rarId0 DEST_GRP_1 +17035556666 rantId0 rarId0 true +12025556666 100 20 40 u E2U+sip ^(.*)$ sip:\1@sbe4.ssp2.com NOTE_1: The TN key of the first and third PI in the sequence above is intentionally the same. NOTE_2: element is repetitive in the XML instance and perhaps it wil= l suffice as the member of the root element spppb:Request for most cases, if not all. I think David S. pointed this out earlier. I am just saying it out loud in case someone wants to comment. case 1: All PI are successfully provisioned and either response below from Registry should be fine. txid-5555 serverTransId0 1000 success ... true true +12025556666 ... true true +12025556666 --- OR --- txid-5555 serverTransId0 1000 success case 2: Assuming that the Registry doesn't support PI-->RteRec associations= , sample failure response including the record in error, is shown below. Also= , since the is a mini-transaction (with its own clientTransId), a failure to provision one of the three PI means that none of the PI instances in the set get provisioned. txid-5555 serverTransId0 2103 Command Invalid DEST_GRP_1 +12025556666 > 4) The COR claim elements should also be part of the RNTYpe. Sure. Please, find the updated schema attached to this email. thanks, -Syed > > Ken > 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 syed.ali@neustar.biz Tue Aug 17 12:34:38 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CDD43A68CD for ; Tue, 17 Aug 2010 12:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.132 X-Spam-Level: X-Spam-Status: No, score=-0.132 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_40=-0.185, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6uUxxoamuq4 for ; Tue, 17 Aug 2010 12:34:37 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 8D25A3A67AF for ; Tue, 17 Aug 2010 12:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1282073704; x=1596814984; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=MPHI3CM3oZGnQ+NszUi/M oXCa8GUqQFrD0JeqkjNJbY=; b=s38zwW1i3eKbNlyiO1oBWbsvd+IbIF9MbXoDU o8jaBuu91xplJNehJ0jNdlNXReyNurm5Gi0Ga/kkOHfw+J/qQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.12890393; Tue, 17 Aug 2010 15:35:03 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 17 Aug 2010 15:35:00 -0400 From: "Ali, Syed Wasim" To: "Cartwright, Ken" , "jf.mule@cablelabs.com" Date: Tue, 17 Aug 2010 15:34:58 -0400 Thread-Topic: update to CORInfoType Thread-Index: Acs80jpajVTytdNW50uMweQLDL/agQAhYZlQADgJtzAAAEQLAAACk7vY Message-ID: In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA24493CFF8E@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: oZUWqBKnjARBgoXRGpUHTg== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] update to CORInfoType X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 19:34:38 -0000 On 8/17/10 2:58 PM, "Cartwright, Ken" wrote: > Cool. It sounds like we're in sync on items 1 and 2. But on item 3 I ha= ve > the following thoughts >=20 > a) Partial Success Within a Single Rqst Object (as apposed to across mult= iple > request objects): You seem to be proposing that we allow partial success > within a single AddPubIdRqstType object. We had decided to not allow tha= t > (but we would allow it across multiple such objects, hence the current de= sign > of the protocol). The current XSD as designed does not allow that at all > across any operations. So if we do want to allow that then we need to re= visit > this across all the responses to make the protocol self consistent. I'm = ok > with making this change, but we just need to acknowledge what we are > proposing. This adds in notable complexity and will probably require us t= o > revisit the design of our response codes. But if we need to do it to sup= port > use cases needed by some organizations then we should do it. Nope, I am not proposing Partial Success within a Single Rqst Object. Withi= n a single request object , the outcome should be the whole request processed successfully or no parts of it, period. For the response message in "case 2:" below, it assumes a failure in processing the third PI of the three that were part of the request object, and while the whole request is deemed a failure, the offending PI in the request is included in the response message to help the provisioning client pin-point where the error is.=20 >=20 > b) "Track Id": Relying on the client to pass in a somewhat arbitrary int= eger, > trkId (which one might call a "temporary synthetic key"), is I think not > reliable enough a mechanism to play the role as the link between an objec= t > passed in and its success/failure/status result. It makes the code on bo= th > the client and server more complicated and more brittle. If we want to > support this kind of thing I think we either need to echo back each objec= t and > its properties in the response (or perhaps just each object that was not = fully > successful) along with its specific result code, or echo back just the ob= ject > key of each object along with its specific result code and consider the n= eed > to add in a new response code to indicate the result of the COR claim. The correlation mechanics is no different then use of and the requirement that the server mirrors it in the response. And given that the scope is clearly defined to be limited to the Rqst object, I am not sur= e it is creating any issues. Further, use of 'trkId' doesn't limit the server from including the full request object, IF it choose to do so. The two are orthogonal and implementations can support either mechanics, or not. >=20 > Ken >=20 > -----Original Message----- > From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz] > Sent: Tuesday, August 17, 2010 2:14 PM > To: Cartwright, Ken; jf.mule@cablelabs.com > Cc: drinks@ietf.org > Subject: Re: update to CORInfoType >=20 >=20 > Thanks for the quick response. Please, see comments below: >=20 > On 8/16/10 12:35 PM, "Cartwright, Ken" wrote: >=20 >> Hi Syed, >>=20 >> A few points about this: >>=20 >> 1) The corClaim and cor elements can't be a "choice" element because whe= n a >> client app queries for the properties of a PublicIdentifier they need to= know >> whether they sumitted it with a COR claim *and* whether that claim has b= een >> approved. I think your intended goal could instead be accomplished by >> combining the corClaim and the cor elements into a single element of typ= e >> enumeration whose values could be "noClaimRqst" "claimRqst" >> "claimRqstApproved" "claimRqstRejected". >=20 > This is a valid point. And while use of carrier-of-record claim is certai= nly > one way to request COR processing, a lot of systems today maintain this > indicator implicitly that makes an explicit claim in the request > unnecessary. While we can try to cover all possibilities using enumerated > values, I think the original proposed boolean values should be sufficient= . I > will remove the 'choice'. >=20 >> 2) I think I have come to agree with you that there should be an option = to >> allow the result of a cor claim to be returned synchronously. The >> scalability >> concern that I have about doing this synchronously is more of an on >> operational and/or policy concern. Bulk requests that perform this cor = check >> synchronously and send the response synchronously will of course be slow= er >> and >> result in a lot more data sent over the wire, however, some installation= s may >> need or want to function this way and therefore are willing to pay this >> performance price. However, the manner that this has been proposed in t= he >> XSD >> I think may not work. See (3) below. >=20 > Your concern for performance and excess data over the wire is not without > merit. However, not including the result in the response message means > separate 'getXXX' calls for all relevant requests in the bulk request > message just to know the outcome. Also, the fact that CORInfoType is an > optional element, it allows the needed flexibility in letting the Registr= y > use policy knobs and return this information on a case by case basis. >=20 >> 3) The proposed change is to add in a AddPubIdsRspnsType object that con= tains >> a set of CORINfoTypes. However, the CORInfoType does not contain the ke= y of >> the PublicIdentity to which it applies. And it is not good practive to = just >> assume that it is based on the order in which they are passed in. I thi= nk if >> we want to accomplish this, then we should include the full PubIdType ob= ject >> in the response. >=20 > I am with you on this one. I forgot about the 1-to-many association to PI= . > And COR is not the only case where the current schema definition of > AddPubIdsRspnsType needs clarification. Consider the case where the reque= st > has multiple PI instances within a and the Registry could > only honor some of them while others fail processing for one reason or > another. There are a couple of ways to go about it. One, change the ordin= al > value for the composite AddPubIdsRqstType-->PI from 1..unbounded to 1..1. > This way, the can be used to dereference the PI in the > response. Two, add the *track_identifier* (trkId) attribute for each PI t= hat > can be later referenced in the response to (1) convey the COR status in > cases where the messages were processed successfully; and in case of a > failure, (2) point to the particular PI instance in this message along wi= th > the correct failure response code. The former approach is too disruptive = IMO > and adds bulk to the responses. The latter approach is do-able and tackle= s > the failure scenarios well. I envision 'trkId' to be any arbitrary intege= r > value the scope of which is limited to the immediate transaction, which i= s > for the purpose of this discussion. To elaborate on this= , I > am including a few examples below: >=20 > - Activate three PIs >=20 > > txid-5555 > xsi:type=3D"ns1:TNType" trkId=3D"1"> > > rantId0 > rarId0 > > DEST_GRP_1 > > true > > +12025556666 > > xsi:type=3D"ns1:TNType" trkId=3D"2"> > > rantId0 > rarId0 > > DEST_GRP_1 > +17035556666 > > xsi:type=3D"ns1:TNType" trkId=3D"3"> > > rantId0 > rarId0 > > > true > > +12025556666 > xsi:type=3D"ns1:NAPTRType"> > 100 > 20 > 40 > u > E2U+sip > > ^(.*)$ > sip:\1@sbe4.ssp2.com > > > > >=20 > NOTE_1: The TN key of the first and third PI in the sequence above is > intentionally the same. > NOTE_2: element is repetitive in the XML instance and perhaps it w= ill > suffice as the member of the root element spppb:Request for most cases, i= f > not all. I think David S. pointed this out earlier. I am just saying it o= ut > loud in case someone wants to comment. >=20 > case 1: All PI are successfully provisioned and either response below fro= m > Registry should be fine. >=20 > > txid-5555 > serverTransId0 > 1000 > success > > ... > > true > true > > +12025556666 > > > ... > > true > true > > +12025556666 > > >=20 > --- OR --- >=20 > > txid-5555 > serverTransId0 > 1000 > success > >=20 > case 2: Assuming that the Registry doesn't support PI-->RteRec associatio= ns, > sample failure response including the record in error, is shown below. Al= so, > since the is a mini-transaction (with its own > clientTransId), a failure to provision one of the three PI means that non= e > of the PI instances in the set get provisioned. >=20 > > txid-5555 > serverTransId0 > 2103 > Command Invalid > > DEST_GRP_1 > +12025556666 > > >=20 >=20 >> 4) The COR claim elements should also be part of the RNTYpe. >=20 > Sure. >=20 > Please, find the updated schema attached to this email. >=20 > thanks, >=20 > -Syed >=20 >>=20 >> Ken >>=20 >=20 >=20 > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network > Services. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and > destroy all copies of the original message. >=20 From kcartwright@tnsi.com Tue Aug 17 15:38:05 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA023A68E0 for ; Tue, 17 Aug 2010 15:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_40=-0.185, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNm+czDRSQpb for ; Tue, 17 Aug 2010 15:38:04 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id D073D3A6828 for ; Tue, 17 Aug 2010 15:38:03 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.46793014; Tue, 17 Aug 2010 18:38:35 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 17 Aug 2010 18:38:35 -0400 From: "Cartwright, Ken" To: "Ali, Syed Wasim" , "jf.mule@cablelabs.com" Date: Tue, 17 Aug 2010 18:38:33 -0400 Thread-Topic: update to CORInfoType Thread-Index: Acs80jpajVTytdNW50uMweQLDL/agQAhYZlQADgJtzAAAEQLAAACk7vYAABBmBA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA24493D0170@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <754963199212404AB8E9CFCA6C3D0CDA24493CFF8E@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] update to CORInfoType X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 22:38:05 -0000 Ok. We're getting closer.... :-) 1) Partial success within a request object is not what you were proposing. = Ok cool. 2) I'm still not keen on the track ID concept: a) Watering it down the trackId proposal say that implementers can = choose to support the trackId element or not is too loose a specification i= mo. b) One of the suggested justifications for the trackId proposal is = that the trackId can be used for failure/error scenarios as well. But this= does not hold be cause you indicated that you are not proposing partial su= ccess/failure, and the parameterized response codes cover the existing succ= ess/failure scenarios. c) TrackId is not the same thing as a clientTranssId. The usage of= clientTransId is much very simple and succinct and applies clearly across = all types of transactions regardless of object type or operation. d) If we add this in then we would need to add it into all object t= ypes, not just PudIds. So what does it mean if the client passes in a trac= k ID on a dest group del operation? Iom, it's not clear. Ken -----Original Message----- From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz] Sent: Tuesday, August 17, 2010 3:35 PM To: Cartwright, Ken; jf.mule@cablelabs.com Cc: drinks@ietf.org Subject: Re: update to CORInfoType On 8/17/10 2:58 PM, "Cartwright, Ken" wrote: > Cool. It sounds like we're in sync on items 1 and 2. But on item 3 I ha= ve > the following thoughts > > a) Partial Success Within a Single Rqst Object (as apposed to across mult= iple > request objects): You seem to be proposing that we allow partial success > within a single AddPubIdRqstType object. We had decided to not allow tha= t > (but we would allow it across multiple such objects, hence the current de= sign > of the protocol). The current XSD as designed does not allow that at all > across any operations. So if we do want to allow that then we need to re= visit > this across all the responses to make the protocol self consistent. I'm = ok > with making this change, but we just need to acknowledge what we are > proposing. This adds in notable complexity and will probably require us t= o > revisit the design of our response codes. But if we need to do it to sup= port > use cases needed by some organizations then we should do it. Nope, I am not proposing Partial Success within a Single Rqst Object. Withi= n a single request object , the outcome should be the whole request processed successfully or no parts of it, period. For the response message in "case 2:" below, it assumes a failure in processing the third PI of the three that were part of the request object, and while the whole request is deemed a failure, the offending PI in the request is included in the response message to help the provisioning client pin-point where the error is. > > b) "Track Id": Relying on the client to pass in a somewhat arbitrary int= eger, > trkId (which one might call a "temporary synthetic key"), is I think not > reliable enough a mechanism to play the role as the link between an objec= t > passed in and its success/failure/status result. It makes the code on bo= th > the client and server more complicated and more brittle. If we want to > support this kind of thing I think we either need to echo back each objec= t and > its properties in the response (or perhaps just each object that was not = fully > successful) along with its specific result code, or echo back just the ob= ject > key of each object along with its specific result code and consider the n= eed > to add in a new response code to indicate the result of the COR claim. The correlation mechanics is no different then use of and the requirement that the server mirrors it in the response. And given that the scope is clearly defined to be limited to the Rqst object, I am not sur= e it is creating any issues. Further, use of 'trkId' doesn't limit the server from including the full request object, IF it choose to do so. The two are orthogonal and implementations can support either mechanics, or not. > > Ken > > -----Original Message----- > From: Ali, Syed Wasim [mailto:syed.ali@neustar.biz] > Sent: Tuesday, August 17, 2010 2:14 PM > To: Cartwright, Ken; jf.mule@cablelabs.com > Cc: drinks@ietf.org > Subject: Re: update to CORInfoType > > > Thanks for the quick response. Please, see comments below: > > On 8/16/10 12:35 PM, "Cartwright, Ken" wrote: > >> Hi Syed, >> >> A few points about this: >> >> 1) The corClaim and cor elements can't be a "choice" element because whe= n a >> client app queries for the properties of a PublicIdentifier they need to= know >> whether they sumitted it with a COR claim *and* whether that claim has b= een >> approved. I think your intended goal could instead be accomplished by >> combining the corClaim and the cor elements into a single element of typ= e >> enumeration whose values could be "noClaimRqst" "claimRqst" >> "claimRqstApproved" "claimRqstRejected". > > This is a valid point. And while use of carrier-of-record claim is certai= nly > one way to request COR processing, a lot of systems today maintain this > indicator implicitly that makes an explicit claim in the request > unnecessary. While we can try to cover all possibilities using enumerated > values, I think the original proposed boolean values should be sufficient= . I > will remove the 'choice'. > >> 2) I think I have come to agree with you that there should be an option = to >> allow the result of a cor claim to be returned synchronously. The >> scalability >> concern that I have about doing this synchronously is more of an on >> operational and/or policy concern. Bulk requests that perform this cor = check >> synchronously and send the response synchronously will of course be slow= er >> and >> result in a lot more data sent over the wire, however, some installation= s may >> need or want to function this way and therefore are willing to pay this >> performance price. However, the manner that this has been proposed in t= he >> XSD >> I think may not work. See (3) below. > > Your concern for performance and excess data over the wire is not without > merit. However, not including the result in the response message means > separate 'getXXX' calls for all relevant requests in the bulk request > message just to know the outcome. Also, the fact that CORInfoType is an > optional element, it allows the needed flexibility in letting the Registr= y > use policy knobs and return this information on a case by case basis. > >> 3) The proposed change is to add in a AddPubIdsRspnsType object that con= tains >> a set of CORINfoTypes. However, the CORInfoType does not contain the ke= y of >> the PublicIdentity to which it applies. And it is not good practive to = just >> assume that it is based on the order in which they are passed in. I thi= nk if >> we want to accomplish this, then we should include the full PubIdType ob= ject >> in the response. > > I am with you on this one. I forgot about the 1-to-many association to PI= . > And COR is not the only case where the current schema definition of > AddPubIdsRspnsType needs clarification. Consider the case where the reque= st > has multiple PI instances within a and the Registry could > only honor some of them while others fail processing for one reason or > another. There are a couple of ways to go about it. One, change the ordin= al > value for the composite AddPubIdsRqstType-->PI from 1..unbounded to 1..1. > This way, the can be used to dereference the PI in the > response. Two, add the *track_identifier* (trkId) attribute for each PI t= hat > can be later referenced in the response to (1) convey the COR status in > cases where the messages were processed successfully; and in case of a > failure, (2) point to the particular PI instance in this message along wi= th > the correct failure response code. The former approach is too disruptive = IMO > and adds bulk to the responses. The latter approach is do-able and tackle= s > the failure scenarios well. I envision 'trkId' to be any arbitrary intege= r > value the scope of which is limited to the immediate transaction, which i= s > for the purpose of this discussion. To elaborate on this= , I > am including a few examples below: > > - Activate three PIs > > > txid-5555 > xsi:type=3D"ns1:TNType" trkId=3D"1"> > > rantId0 > rarId0 > > DEST_GRP_1 > > true > > +12025556666 > > xsi:type=3D"ns1:TNType" trkId=3D"2"> > > rantId0 > rarId0 > > DEST_GRP_1 > +17035556666 > > xsi:type=3D"ns1:TNType" trkId=3D"3"> > > rantId0 > rarId0 > > > true > > +12025556666 > xsi:type=3D"ns1:NAPTRType"> > 100 > 20 > 40 > u > E2U+sip > > ^(.*)$ > sip:\1@sbe4.ssp2.com > > > > > > NOTE_1: The TN key of the first and third PI in the sequence above is > intentionally the same. > NOTE_2: element is repetitive in the XML instance and perhaps it w= ill > suffice as the member of the root element spppb:Request for most cases, i= f > not all. I think David S. pointed this out earlier. I am just saying it o= ut > loud in case someone wants to comment. > > case 1: All PI are successfully provisioned and either response below fro= m > Registry should be fine. > > > txid-5555 > serverTransId0 > 1000 > success > > ... > > true > true > > +12025556666 > > > ... > > true > true > > +12025556666 > > > > --- OR --- > > > txid-5555 > serverTransId0 > 1000 > success > > > case 2: Assuming that the Registry doesn't support PI-->RteRec associatio= ns, > sample failure response including the record in error, is shown below. Al= so, > since the is a mini-transaction (with its own > clientTransId), a failure to provision one of the three PI means that non= e > of the PI instances in the set get provisioned. > > > txid-5555 > serverTransId0 > 2103 > Command Invalid > > DEST_GRP_1 > +12025556666 > > > > >> 4) The COR claim elements should also be part of the RNTYpe. > > Sure. > > Please, find the updated schema attached to this email. > > thanks, > > -Syed > >> >> Ken >> > > > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network > Services. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and > destroy all copies of the original message. > 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 Thu Aug 26 06:39:19 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65EC13A6809 for ; Thu, 26 Aug 2010 06:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.246 X-Spam-Level: * X-Spam-Status: No, score=1.246 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6wThBU7rcjp for ; Thu, 26 Aug 2010 06:39:17 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id CC4B83A67A4 for ; Thu, 26 Aug 2010 06:39:14 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o7QDdk2s014927 for ; Thu, 26 Aug 2010 07:39:46 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 26 Aug 2010 07:39:46 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 26 Aug 2010 07:39:46 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Thu, 26 Aug 2010 07:40:22 -0600 Thread-Topic: DRINKS WG Interim Meeting in Sep Thread-Index: ActFJDtWPdpsBdkVQvSv0Od13HdUdg== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D1FF3FFE6@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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] DRINKS WG Interim Meeting in Sep X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:39:19 -0000 Dear WG participants, =20 In preparation for the upcoming interim meeting, please find enclosed the a= ssociated logistical details. If you are interested in attending, please RS= VP on or before Sep 7th at: http://www.surveymonkey.com/s/6V6DH26 .=20 =20 In addition, please request any agenda items on the mailing list.=20 =20 =20 =20 Data for Reachability of Inter/tra-NetworK SIP (DRINKS) Interim Meeting (78= .5) Information=20 ---------------------------------------------------------------------------= --------------- =20 Date & Time: September 15 2010 (Wednesday); 09:00 - 16:30 (Mountain Dayligh= t Time) / 03:00 - 22:30 (UTC) =20 Location:=20 858 Coal Creek Circle, Louisville, Colorado, U.S.A., 80027-9750 =20 Chairs: Alexander Mayrhofer Sumanth Channabasappa =20 =20 Real-time Applications and Infrastructure Area (RAI) Directors: Gonzalo Camarillo Robert Sparks =20 RAI Advisor: Gonzalo Camarillo =20 Mailing Lists: General Discussion: drinks@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/drinks Archive: http://www.ietf.org/mail-archive/web/drinks/curren= t/maillist.html =20 =20 Details ------- + On-Site contact person Sumanth Channabasappa =20 =1B$B!!=1B(B + Directions to the location, and nearby places to stay at http://www.cablelabs.com/about/contact/ =20 + Remote participation information 1/ Web link =20 https://www1.gotomeeting.com/join/743192888 =20 Note: Please join GoToMeeting first so that you can obtain an audio PIN; = it will help us identify callers easily instead of relying on announcements= . =20 2/Conference Info =20 - Use your microphone and speakers (VoIP) to join in via the GoToMeeting = Client. Or, call in using your telephone. =20 Dial : 215-383-1008 Access Code: 743-192-888 Audio PIN : Should be displayed on the GoToMeeting web client, after you= join =20 =1B$B!!=1B(B =20 =1B$B!!=1B(B =20 =20 =20 =20 From sumanth@cablelabs.com Thu Aug 26 06:55:24 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08CB3A6876 for ; Thu, 26 Aug 2010 06:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.31 X-Spam-Level: * X-Spam-Status: No, score=1.31 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eGYEdz0AbWl for ; Thu, 26 Aug 2010 06:55:23 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B61E73A6809 for ; Thu, 26 Aug 2010 06:55:23 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o7QDtteF016430 for ; Thu, 26 Aug 2010 07:55:55 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 26 Aug 2010 07:55:55 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 26 Aug 2010 07:55:56 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Thu, 26 Aug 2010 07:56:31 -0600 Thread-Topic: Design team call notes (8/12) Thread-Index: ActFJnzQeodHbj/rRqCglbMOVQ8pLw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D1FF3FFE9@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] Design team call notes (8/12) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:55:24 -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 8/12/2010, 10:00a-10:30a (Eastern)/8:00a-8:30a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Manjul Maharishi=20 - Alex Mayrhofer - Syed Ali - Jean-Francois Mule =20 - Sumanth Channabasappa=20 =20 =20 AGENDA =3D=3D=3D=3D=3D=3D - Follow-up from the last IETF - Interim meeting - Next Steps =20 NOTES =3D=3D=3D=3D=3D This was a quick design team meeting to note down the next steps, as a resu= lt of the discussions in Maastricht.=20 =20 1/ Follow-up from the last IETF =20 a) Requirements I-D - This document requires another iteration. We can either complete th= e iteration now, or wait for further review comments from volunteers (Jon P= eterson, Sohel Khan).=20 AI: Alex will ping the reviewers and Sumanth will proceed according= ly. =20 =20 b) Protocol document - Jean-Francois had volunteered to make a set of initial changes to = this I-D, following the comments at the last IETF, and pass it onto the oth= er authors - DONE - After this meeting, Syed will be editing the document and will mak= e changes w.r.t. the COR and add examples for the various cases (he may sha= re this with the WG first). AI: Syed to incorporate agreed-upon changes to the document, and su= rface open issues on the mailing list. AI: Alex volunteered to provide details regarding a web-based I-D c= hange management tool =20 C) Misc. - Open numbering plan; we need to make sure that we address this adeq= uately as part of the document editing process. AI: Protocol document editors =20 - Global SPID; We need to check with Penn F (who volunteered to auth= or a document)=20 AI: Alex and Sumanth to follow-up =20 2/ Interim meeting - AI: Sumanth to make arrangements for the meeting and send across the = details to the list =20 3/ Next Steps - See AIs above - Next design team call: August 26th, 2010 (10a - 11a Eastern) =20 = From sumanth@cablelabs.com Thu Aug 26 08:22:11 2010 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90643A6843 for ; Thu, 26 Aug 2010 08:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZuM2UOjybHS for ; Thu, 26 Aug 2010 08:22:10 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id A32153A697D for ; Thu, 26 Aug 2010 08:22:10 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o7QFMgC5024615 for ; Thu, 26 Aug 2010 09:22:42 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 26 Aug 2010 09:22:42 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 26 Aug 2010 09:22:42 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Thu, 26 Aug 2010 09:23:19 -0600 Thread-Topic: Rough notes from the design team call on 8/26 Thread-Index: ActFMp0ODOsrKn9ZQGaNDXjUIRWVZQ== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D1FF40003@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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Rough notes from the design team call on 8/26 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 15:22:11 -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 8/26/2010, 10:00a-10:30a (Eastern)/8:00a-8:30a (Mountain) Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Syed Ali - Jean-Francois Mule - Ken Cartwright - Sumanth Channabasappa=20 ACTION ITEMS UPDATE (from the last meeting) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AI: Alex to ping the volunteer reviewers for the use cases document Update: Alex has sent across a request to the volunteers. AI: Syed has the token for the protocol document, and will either incorpora= te agreed-upon changes or surface open issues and examples. Update: Syed had some discussions on the mailing list, but hasn't had the t= ime to incorporate the changes.=20 Update: Ken now has the token and will incorporate from the list he sent ac= ross on 7/29 (to the DRINKS mailing list) AI: Alex volunteered to provide details regarding a web-based I-D change ma= nagement tool No updates: Pending AI.=20 AI: Sumanth to make arrangements for the meeting and send across the detail= s to the list Update: Done. =1B$B!!=1B(B NEW ACTION ITEMS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D AI: Ken to take on the token as the editor of the protocol document AI: Syed to send across protocol examples to the mailing list AGENDA =3D=3D=3D=3D=3D=3D 0/ AI updates from last time 1/ Changes to the protocol document since the last IETF 2/ Details regarding the interim meeting (logistics, goals) 3/ Open issues list =1B$B!!=1B(B =1B$B!!=1B(B NOTES =3D=3D=3D=3D=3D 0/ AI updates from last time - See updates above. =1B$B!!=1B(B 1/ Changes to the protocol document since the last IETF Note: For a list of all agreed-upon changes, please refer to Ken's email to= the list on 7/29 (titled "Agreed on Protocol To-Do List") [Changes made by Jean-Francois] 9) Updates to Public Identifier Type Documentation and XSD as follows: a) (JFM)corClaimStatus boolean instead of "approved" enum and corClaimStatu= sChanges date/Time c) (JFM) TNRange should not inherit from TN In addition, Jean-Francois has added text to reflect the two types of SPPP = server implementations. =1B$B!!=1B(B [Syed] Syed is still working on the examples (which he plans to send to the mailin= g list) and decided to pass on the token to Ken =1B$B!!=1B(B 2/ Details regarding the interim meeting (logistics, goals) - Sumanth sent across the logistical details to the mailing list - [Sumanth, as a design team participant] proposed that we concentrate on t= he protocol document this time around and recommended that we request any a= dditional items in advance of the meeting (e.g., Global SPID). The team agr= eed.=20 3/ Open issues list - None were raised on the call today.