1= .) There are some naming inconsistencies, specifically as they relate to th= e two URI types:

* NAPTRType, NSType and URIRteR= ecType

I understand the need for disambiguating the two URI types but this l= eads to lack of consistency with class members. What is wrong with always i= ncluding the "abstract" parent in the name?

* NA= PTRSedRecType, NSSedRecType and URISedRecType

* TNPubIdType, RNPub= IdType, TNRPubIdType, TNPPubIdType and URIPubIdType

2.) RNType= definition is as follows:

"A routing number is provisioned using the RNType, an extensio= n of PubIDType. SSPs that possess the number portability data may be able t= o leverage the RN search key to discover the ingress routes for session est= ablishment. Therefore, the registrant organization can add the RN and assoc= iate it with the appropriate destination group to share the route informati= on. Each RNType object is uniquely identified by the combination of i= ts value inside the <rn> element, and the unique key of its parent De= stination Group (dgName and rantId). In other words a given routing number = string may exist within one or more destination Groups, but must not exist = more than once within a Destination Group.

My specific question re= lates to this snippet...

Therefore, the registrant organization can ad= d the RN and associate it with the appropriate destination group to share the route informati= on.

The Public Identifiers represent the "subjects" or "keys" that= are used to lookup the "attributes" or "values" specified as session estab= lishment data. It is SED that is shared - not identifiers. In fact, isn't R= N type information similar enough to LUF (i.e. "need another mechanism or l= ookup to find the actual LRF data") to be another SEDRecordType? We have NA= PTRType, NSType and URIType. Should we have RNType as well as a child of SE= DRecType? We already have a 1-1 association of a TNType to a SEDRecType so = a number that is ported would be represented by a TNType and an associated = SED record RNType. One could then take the RNType (which looks just like a = TN anyway) and perform an LRF query on this to find the actual relevant ing= ress point.

Does any of this make sense?

Thoughts?

<= /div>= --_000_88A69B9BE98A458CA2836AA8716EB18Bxconnectnet_-- From alexander.mayrhofer@nic.at Wed Jun 6 03:18:26 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2775C21F87F8 for ; Wed, 6 Jun 2012 03:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.13 X-Spam-Level: X-Spam-Status: No, score=-9.13 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcG4-Rd4wCI7 for ; Wed, 6 Jun 2012 03:18:25 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 123C621F86FA for ; Wed, 6 Jun 2012 03:18:24 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Wed, 6 Jun 2012 12:18:22 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Wed, 6 Jun 2012 12:18:18 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRAFT minutes of the DRINKS design team call on 2012-05-31 Thread-Index: Ac1DzV6+ytoMF0A4RFW4XSN6p0ZC6A== Date: Wed, 6 Jun 2012 10:18:17 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075096489E0@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] DRAFT minutes of the DRINKS design team call on 2012-05-31 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 10:18:26 -0000 All,=20 please find the minutes of the design team call on May 31 attached. Sorry f= or the late action - i was travelling the last two days. Alex -- DRAFT minutes DRINKS design team call May 31 2012 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Participants ------------ - Vikas Bhatia - Manjul Maharishi - David Schwartz=20 - Dean Willis - Alexander Mayrhofer - Syed Ali - Ken Cartwright - Sumanth Channabasappa=20 ACTION ITEMS ------------ 1/ Re-Check the URI Type definition text in context of the SEDFunctionType= =20 addition - David (+all) 2/ Change rteRecType to SEDRecType (+related types) - David 3/ Add SEDFunctionType - David Agenda ------ 1/ Work on documented open issues Minutes ------- The group continues with the discussion of the "categorization" issue. David has sent a proposal to the mailing list: http://www.ietf.org/mail-archive/web/drinks/current/msg01194.html Ken: Who would be using that - David and Syed saying they=20 will be using such a mechanism. Ken: Naming - asks what is the difference in the actual action once such in= fo is encountered during lookup? why not call it LRF and LUF ? David says term= s are=20 ambigiuous.=20 Calling it "lookup" and "routing" would be better. Group agrees to use=20 the following snippet (also replacing the "undefined" enum value with an=20 minOccurs 0) Vikas mentions that there is some text in the existing definition=20 of the URI type regarding the use of information and dereferencing -=20 this could overlap with info here? - David agrees we need=20 to re-read the URI specification. David offers to re-read the URI type specs, and propose changes. ACTION ITEM: Re-check the URItype text - David & all Decision: Change Rte* to SED* - David has the ACTION ITEM to change this. Vikas notes that both the Framework and SOAP document are affected Q: Anybody opposed to adding the FunctionType? Vikas: Adding the function type is fine, as long as we solve the URI=20 problems discussed before. Keep the discussion about the values open.=20 Ken: we identified the two type names, let's go with them. David: No open string, we have two use cases, let's stick with them. Decision: Add the FunctionType, keep "lookup" and "routing" Q: Rename? Yes, decided - rename. Last remaining sub-issue: replace all rectypes with URI+ereg. Alex explains that this is not=20 possible since the dns: URI type reflects only DNS *queries*, not response= =20 data. Dean agrees that it's fine. David: peering / route group offer generalization offer can=20 now be closed, since it's an SEDGrpOffer other open issues: I18n - need to propose text (Alex) DoS - need to talk it through (Jeremy, Ken?) From alexander.mayrhofer@nic.at Fri Jun 8 04:29:13 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA4B21F88B8 for ; Fri, 8 Jun 2012 04:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.37 X-Spam-Level: X-Spam-Status: No, score=-9.37 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5C0UTLuFIYQ for ; Fri, 8 Jun 2012 04:29:12 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 20AD221F885E for ; Fri, 8 Jun 2012 04:29:12 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Fri, 8 Jun 2012 13:29:11 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Fri, 8 Jun 2012 13:29:05 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRAFT minutes of the DRINKS design team call on Jun 06 2012 Thread-Index: Ac1FacZgIrAr6afeS+GHC3UW3gumtw== Date: Fri, 8 Jun 2012 11:29:04 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750964B78F@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] DRAFT minutes of the DRINKS design team call on Jun 06 2012 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:29:13 -0000 DRAFT minutes of the DRINKS design team call =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jun 06 2012, 10am - 11am eastern Participants: ------------- - Vikas Bhatia - Manjul Maharishi - David Schwartz=20 - Dean Willis - Alexander Mayrhofer - Syed Ali - Ken Cartwright - Sumanth Channabasappa=20 ACTION ITEMS ------------ 1/ Provide updated documents to group (David) 2/ Provide text on internationalization (Alex) Agenda ------ 1/ Continue discussion of open issues Minutes ------- Sumanth opens the meeting. Alex quickly runs thorugh last weeks minutes David has worked on the changes regarding his action items, and has posted some questions regarding the changes to the mailing list.=20 He says he's is almost done with the editing, and will send back=20 to the group once all changes are applied - aims at end of week. His post to the mailing list is discussed: http://www.ietf.org/mail-archive/web/drinks/current/msg01195.html He raises two open questions in that message: a) Naming inconsistencies Naming inconsistencies of the types as indicated in his email. He=20 wants to put the abstract base type into the concrete type.=20 discussion around the implications. (bridge disconnected) Ken: Better avoid adding base names, because would create long names Alex: use "URISEDType" and "URIPubIdType", and leave all the others? Another suggestion: "URISEDType" - "URIType" - consensus? Unclear, David will think about the options. b) RNType definition David: Concern that this definition is a "u-turn"? RN could return LUF? Ken: says that carriers maybe want the relation TN->RN outside of the registry, and only use registry to provision RNs as PubID. When numbers are ported in, no change to the registry needed. More clarifications between David and Ken during the discussion.=20 Syed: David saying that the use case is implicitely covered, but wants=20 explicit to mention it? Manjul: SEDFunctionType could be helpful here?=20 David: RN is kind of a LUF - adding in another enumeration value=20 would be a hack. Conclusion: No change to the documents necessary. David will finish off the text changes, and will send out updated=20 versions of the documents this week.=20 Next steps:=20 There are two more open issues - internationalization and DoS.=20 aiming at getting both things into the document asap. i18n: rfc 2277 - alex will look into that, or an updated version.=20 Timeline: have docs ready shortly before next week's call, and maybe=20 decide about publishing them shortly afterwards. Meeting concludes - next call on Jun 13 2012. From alexander.mayrhofer@nic.at Tue Jun 12 14:23:52 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BD821F869E for ; Tue, 12 Jun 2012 14:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY8cLeJSMreM for ; Tue, 12 Jun 2012 14:23:51 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 89E7F21F8661 for ; Tue, 12 Jun 2012 14:23:46 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Tue, 12 Jun 2012 23:23:45 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Tue, 12 Jun 2012 23:23:38 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: Internationalization followup.. Thread-Index: Ac1I3ohyW6APJJ8qQNKwPfKjUor+DQ== Date: Tue, 12 Jun 2012 21:23:36 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750964F4B9@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.17.175.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] Internationalization followup.. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 21:23:52 -0000 Preparing for the call tomorrow, i went through the various internationaliz= ation discussions that we had. There were a number of threads started on th= e list since Taipei, but we never actually agreed on text: 1/ http://www.ietf.org/mail-archive/web/drinks/current/msg01070.html 2/ http://www.ietf.org/mail-archive/web/drinks/current/msg01090.html 3/ http://www.ietf.org/mail-archive/web/drinks/current/msg01093.html 4/ http://www.ietf.org/mail-archive/web/drinks/current/msg01126.html As a basis for tomorrow's discussion, i'd use the last message. The text pr= oposed consisted of two seperate parts, one concerning the "Internationaliz= ation", and the other concerning the "Comparison". I'd like to discuss both= parts seperately as follows: 1) Internationalization. I'm proposing to use slightly modified text from the message as follows, in= serting it between section 8 and 9 (XML / Security considerations): --- snip --- 9. Internationalization Considerations Character encodings to be used for SPPF elements are described in Section 8. The use of time values in the protocol is specified in Section 3.2. Where human-readable languages are used in the protocol, those messages SHOULD be tagged according to RFC 5646, and the transport protocol MUST support a respective mechanism to transmit such tags together with those human-readable messages.=20 If tags are absent, the language of the message defaults to "en" (English). --- snip ---=20 2) Comparison I've researched the respective topic for similar protocols (specifically EP= P), and the only relevant text in the EPP RFCs seems to be the following pa= ragraph at the end of section 1 of RFC 5730: "XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation. There are no detailed definitions with respect of the comparison operations= of object identifiers, nor other fields. The identifiers are (similarly to= our drafts) defined as XSD "token" type, with no additional pattern matchi= ng restrictions. Considering that EPP has successfully achieved "STANDARD" = status, i think we might not necessarily need the definitions that i create= d i my last proposals. However, not describing how comparison operations are performed (and hence = leaving comparison to normal XML logic) would mean that our identifiers wou= ld be case sensitive, as far as i understand the "token" definition of XML = Schema. That would be the opposite of what we were inclined in previous dis= cussions. I'd like to quickly discuss this during tomorrow's call - if we decide that= we leave comparison to the standard XML definitions, we would *not* need a= ny additional text in the draft. comments appreciated. Alex From vbhatia@tnsi.com Tue Jun 12 14:33:34 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F7521F866D for ; Tue, 12 Jun 2012 14:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bijBNKygXSaP for ; Tue, 12 Jun 2012 14:33:33 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7A821F865C for ; Tue, 12 Jun 2012 14:33:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAA6110+sEQfn/2dsb2JhbAA7CrY9ghgBAQEEAQEBJBM0FwQCARkEAQEfCQcnCxQJCAEBBAESCAGIDbk8iycQBAaFF2ADqBaBOgk X-IronPort-AV: E=Sophos;i="4.75,759,1330905600"; d="scan'208";a="1290436" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 12 Jun 2012 22:33:31 +0100 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, 12 Jun 2012 17:33:31 -0400 From: "Bhatia, Vikas" To: Alexander Mayrhofer , "drinks@ietf.org" Date: Tue, 12 Jun 2012 17:33:29 -0400 Thread-Topic: Egress Route - RE: [drinks] DRAFT minutes of the DRINKS design team call on May 30 2012. Thread-Index: Ac0/L9mIDjg9gMfZQoq5o3R/95bARAJn4XFQ Message-ID: References: <19F54F2956911544A32543B8A9BDE075192F53@NICS-EXCH.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE075192F53@NICS-EXCH.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: [drinks] Egress Route - RE: DRAFT minutes of the DRINKS design team call on May 30 2012. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 21:33:34 -0000 For my action item on Egress Route - below is the schema element definition= that we already discussed (and my proposed text) for the egress route asso= ciation to Route Group (a.k.a SED Group..nomenclature change not included i= n my text..) Changes are: "ingrRteRec" changed to "ingrRteGrp" - Zero or more Route Group(s) to which= an Egress Route applies. svcs: ENUM service(s) that are served by an Egress Route. This element is = used to identify the ingress NAPTRs associated with the Route Group to whic= h an Egress Route's regxRewriteRule should be applied. If no ENUM service(s= ) are associated with an Egress Route, then the Egress Route's regxRewriteR= ule should be applied to all the NAPTRs associated with the Route Group. Th= is field's value must be of the form specified in [RFC6116] (e.g., E2U+pstn= :sip+sip). The allowable values are a matter of policy and not limited by t= his protocol. Thanks, Vikas -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Alexander Mayrhofer Sent: Thursday, May 31, 2012 9:19 AM To: drinks@ietf.org Subject: [drinks] DRAFT minutes of the DRINKS design team call on May 30 20= 12. DRAFT minutes DRINKS design team call May 30 2012 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D May 30 2012, 10am - 11am eastern Participants ------------ - Vikas Bhatia - Manjul Maharishi - David Schwartz - Alexander Mayrhofer - Syed Ali - Ken Cartwright - Sumanth Channabasappa ACTION ITEMS ------------ - continue discussion of open items Agenda ------ 1/ Work on documented open issues Minutes ------- Sumanth opens the call - runs through last week notes. Alex summarizes decisions from last week. Vikas mentions that the decision whether egress route was to be associated with rte grp instead of rte rec was pending. Alex asks whether the design team would be ok with chaing egr rte from rte rec to rte grp. Sumanth brings up the respective email from vikas, group is ok with the cha= nge, including the svcs addition (alex mentions that the svcs field semantics need to be clearly defined). The team agrees to the two changes. -> Decision: change association of egress route from route record to route group, add "svcs" field to egress route. Clarify svcs semantics. Target vs. location (and rte to sed rename): Vikas said they are connected, david comments he's not sure why. David explains the Target/Location issue - sees a gap between SPEERMINT terminology and the DRINKS documents. Alex notes that an "identification" field in the base rte rec type (optiona= l) would allow people to choose whether or not they want to use the "split". Sumanth brings up david's proposal (chart): http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html Manjul: are we trying to solve an resolution protocol problem here? David: no, just trying to add to the provisioning side a way to differentiate whether the provisioned data is LUF or LRF. Alex: concerned that people would be forced to categorize.. David: Want to force people to do it, in order to solve interopability nigh= tmares. Syed: Clarification that it's just *annotation*, there's no effect on the resolution protocol side. Ken: please summarize issue in two sentences? David: Trying to force the SP into removing ambiguity from the provisioned data. Resolution side is not affected. There's just a little bit of extra data in the registry. More discussion around whether that split is useful, and options to convey = it in resolution protocols (such as terminal flag in ENUM). Discussion whether this is in scope or not - "S" in "drinks" stands for "SI= P"? Sumanth: Thinks we should be ok if that is annotation only. Ken: Need to think that through, but would it be possible to make "collidin= g" annotations, such as a "gspid:" URI scheme with a "Location" type? Syed: All we're looking is adding an additional element for annotation, in order to distinguish the types. Sumanth: Call on Fri? Group: Let's do Thur - new call tomorrow. Discussion about whether sub-typing or attribute would be the easier way. Alex feels that subtyping is pretty strict (Ken agrees), David thinks being strict can be an advantage. No conclusion here. Call concludes after an hour, next call on Thu, May 31. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From vbhatia@tnsi.com Wed Jun 13 06:33:42 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB3721F8522 for ; Wed, 13 Jun 2012 06:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuDBKAW14bJd for ; Wed, 13 Jun 2012 06:33:41 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFD4121F84A7 for ; Wed, 13 Jun 2012 06:33:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEKV2E+sEQfn/2dsb2JhbABFtkWCGAEBAQQBAQE3NBcEAgEIEQQBAR8JBycLFAkIAQEEARIIAYgNug2LMRqFF2ADqBmBQw X-IronPort-AV: E=Sophos;i="4.75,763,1330905600"; d="scan'208";a="1292221" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 13 Jun 2012 14:33:33 +0100 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, 13 Jun 2012 09:33:32 -0400 From: "Bhatia, Vikas" To: Alexander Mayrhofer , "drinks@ietf.org" Date: Wed, 13 Jun 2012 09:33:31 -0400 Thread-Topic: Internationalization followup.. Thread-Index: Ac1I3ohyW6APJJ8qQNKwPfKjUor+DQAO1qrQ Message-ID: References: <19F54F2956911544A32543B8A9BDE0750964F4B9@NICS-EXCH.sbg.nic.at> In-Reply-To: <19F54F2956911544A32543B8A9BDE0750964F4B9@NICS-EXCH.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] Internationalization followup.. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 13:33:42 -0000 Hi Alex, RFC 2277 (briefly mentioned this on the last design call and not sure if it= 's been obsoleted by another RFC...) seems to have some guidance on the iss= ue of a "name" (identifier) definition w.r.t internationalization: http://www.ietf.org/rfc/rfc2277.txt Specifically I was referring to the following excerpts..just something for = discussion. Section 3 defines: " A "name" is an identifier such as a person's name, a hostname, a domainname, a filename or an E-mail address; it is often treated as an identifier rather than as a piece of text, and is often used in protocols as an identifier for entities, without surrounding text." Section 2 has some text on "name" internationalization: "Names are a problem, because people feel strongly about them, many of them are mostly for local usage, and all of them tend to leak out of the local context at times. RFC 1958 [RFC 1958] recommends US-ASCII for all globally visible names. This document does not mandate a policy on name internationalization, but requires that all protocols describe whether names are internationalized or US-ASCII." Vikas -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Alexander Mayrhofer Sent: Tuesday, June 12, 2012 5:24 PM To: drinks@ietf.org Subject: [drinks] Internationalization followup.. Preparing for the call tomorrow, i went through the various internationaliz= ation discussions that we had. There were a number of threads started on th= e list since Taipei, but we never actually agreed on text: 1/ http://www.ietf.org/mail-archive/web/drinks/current/msg01070.html 2/ http://www.ietf.org/mail-archive/web/drinks/current/msg01090.html 3/ http://www.ietf.org/mail-archive/web/drinks/current/msg01093.html 4/ http://www.ietf.org/mail-archive/web/drinks/current/msg01126.html As a basis for tomorrow's discussion, i'd use the last message. The text pr= oposed consisted of two seperate parts, one concerning the "Internationaliz= ation", and the other concerning the "Comparison". I'd like to discuss both= parts seperately as follows: 1) Internationalization. I'm proposing to use slightly modified text from the message as follows, in= serting it between section 8 and 9 (XML / Security considerations): --- snip --- 9. Internationalization Considerations Character encodings to be used for SPPF elements are described in Section 8. The use of time values in the protocol is specified in Section 3.2. Where human-readable languages are used in the protocol, those messages SHOULD be tagged according to RFC 5646, and the transport protocol MUST support a respective mechanism to transmit such tags together with those human-readable messages. If tags are absent, the language of the message defaults to "en" (English). --- snip --- 2) Comparison I've researched the respective topic for similar protocols (specifically EP= P), and the only relevant text in the EPP RFCs seems to be the following pa= ragraph at the end of section 1 of RFC 5730: "XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation. There are no detailed definitions with respect of the comparison operations= of object identifiers, nor other fields. The identifiers are (similarly to= our drafts) defined as XSD "token" type, with no additional pattern matchi= ng restrictions. Considering that EPP has successfully achieved "STANDARD" = status, i think we might not necessarily need the definitions that i create= d i my last proposals. However, not describing how comparison operations are performed (and hence = leaving comparison to normal XML logic) would mean that our identifiers wou= ld be case sensitive, as far as i understand the "token" definition of XML = Schema. That would be the opposite of what we were inclined in previous dis= cussions. I'd like to quickly discuss this during tomorrow's call - if we decide that= we leave comparison to the standard XML definitions, we would *not* need a= ny additional text in the draft. comments appreciated. Alex _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From alexander.mayrhofer@nic.at Thu Jun 14 07:09:46 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331FD21F846A for ; Thu, 14 Jun 2012 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgTQwAIg3tCz for ; Thu, 14 Jun 2012 07:09:45 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 513C821F8448 for ; Thu, 14 Jun 2012 07:09:37 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Thu, 14 Jun 2012 16:09:35 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Thu, 14 Jun 2012 16:09:31 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRAFT minutes of the DRINKS design team call on Jun 13 2012. Thread-Index: Ac1KN09nRqmHGM6GRi+8Jn56a0cLag== Date: Thu, 14 Jun 2012 14:09:31 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075096523F7@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] DRAFT minutes of the DRINKS design team call on Jun 13 2012. X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 14:09:46 -0000 DRAFT minuts of the 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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jun 13 2012, 10am - 11am eastern. Participants ------------ - Vikas Bhatia - David Schwartz=20 - Alexander Mayrhofer - Ken Cartwright Apologies --------- - Dean Willis - Sumanth Channabasappa ACTION ITEMS ------------ 1/ Alex: update i18n and comparison text=20 2/ David: fix egress route examples once Alex hands back document token 3/ WG Chairs: Contact IESG regarding author list preference. 4/ David: Propose DoS text Minutes ------- David leads through the new document, explains changes. the xml2rfc=20 processing issues are now solved. Asks everybody to review the changes=20 in a diff, did some wordsmithing as well. Internationalization -------------------- Alex proposes an internationalization text for the document: http://www.ietf.org/mail-archive/web/drinks/current/msg01198.html Vikas notes that we need some text in the SOAP document regarding=20 the actual implementation. Discussion about language indicator: Server required to follow clients request? Alex clarifies: language=20 indicated by the client is actually a "preference" rather than a requiremen= t. Alex explains comparison options, Vikas mentions rfc 2277 has some respecti= ve=20 text. Alex asks whether we would keep the case insensitivity or not.=20 All on the call tend to want identifiers to be case insensitive, this=20 will require extra text to clarify. Not clarifying it could lead to=20 interopability issues. Alex will propose some text regarding case insensitivity when he edits=20 the docs. DoS --- Ken did not have time to work on text. David wants to=20 close this - will propose some text. Authorship ---------- Alex proposes the new list of authorship as discussed among the co-chairs,= =20 Ken says JF Mule should be on the framework document as well, and syed=20 on the framework document as well. Alex mentions another option would be that there's only an "editor", and=20 the authors are in the Ack section. Ken would be fine with the option of "editor" as well.=20 Chairs will communicate with IESG what the preferred solution is. Next Steps ---------- Token goes to Alex - he changes internationalization text, and then=20 gives back the token to david. Vikas notes there's still a bug in the egress route example - david will=20 fix that once the token goes back to him. Call concludes around 16:50. From alexander.mayrhofer@nic.at Fri Jun 22 05:15:48 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189F221F85FF for ; Fri, 22 Jun 2012 05:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5FuyFpiRIvD for ; Fri, 22 Jun 2012 05:15:47 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0D01121F85B6 for ; Fri, 22 Jun 2012 05:15:46 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Fri, 22 Jun 2012 14:15:44 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Fri, 22 Jun 2012 14:15:35 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: DRAFT notes of the DRINKS design team call on Jun 21 2012 Thread-Index: Ac1QcKYm+Fqf5qFMQi6OP+GtkaX61A== Date: Fri, 22 Jun 2012 12:15:35 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750966A1C0@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] DRAFT notes of the DRINKS design team call on Jun 21 2012 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 12:15:48 -0000 DRAFT minutes of the DRINKS design team call =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jun 20 2012, 10am - 11am Eastern Participants ------------ - Vikas Bhatia - Manjul Maharishi - David Schwartz=20 - Dean Willis - Alexander Mayrhofer - Sumanth Channabasappa=20 Apologies --------- - Syed Ali - Ken Cartwright ACTION ITEMS ------------ 1/ Provide text regarding DoS, update egrRoute example (David) 2/ Followup on comments regarding text changes (Alex) 3/ Read through and comment on David's changes to the documents (All) Agenda ------ 1/ Discussion of changes to documents, as sent out by Alex 2/ Next Steps planning Minutes ------- Alex starts the meeting. Has sent out updates to documents on monday, goes through those changes (using the diff files): Case insensitivity: Vikas thinks the definition of that text is too generic, and that only *name* attributes should be case insensitive=20 in object key types. Alex will look into this, and propose updates to the text. Internationalization section: vikas ask whether the language requirements=20 are related to the XML charset? Alex says they're disjunct. SOAP document - implementation of language tag requirement: Vikas feels tha= t MUST is too strong here. Discussion about malformed sentence, Alex will=20 change that in the sense of "if language tagging is used, ..." David's changes: Didn't have time for the "new" changes, but sends out diff with "previous" changes. Diff is quite big because lots of (also minor)=20 changes. Explains that some changes are wordsmithing, some are content. David mentions a change in 6.4 regarding the URIType text - thinks=20 it's now much clearer, suggests people look at all of the changes. Next call: Because several participants indicate conflicts with=20 next week's call on Wed, the call will take places on Thu. From dean.willis@softarmor.com Thu Jun 28 08:07:59 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF6121F858F for ; Thu, 28 Jun 2012 08:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxxqMMn9qW8s for ; Thu, 28 Jun 2012 08:07:58 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90E2921F8513 for ; Thu, 28 Jun 2012 08:07:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2153070ghb.31 for ; Thu, 28 Jun 2012 08:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; bh=PtTTG6SP+/9le5nA15sQ8bKuAGMx7xC4QbslpY0FHOo=; b=cj54LZdlcGEneF3OPZ/6vv+npPdSU0CRAlCwwkCRSlAovuD0Ey14KLgPJZxurEFhF8 +tIhpAkY0wvDjnV3SmLXYV5pc2NsjyRxLTn+cCjZZpedlKOvVLMMkvxmLzPPsoWDA+ao ad1uX4QB3xjnhT4/QUZkSZra9CbPdm09xKpKM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer:x-gm-message-state; bh=PtTTG6SP+/9le5nA15sQ8bKuAGMx7xC4QbslpY0FHOo=; b=gpiqbXJN/Dlw6dm7zPnXGDEipc4KrOdF/lEJU4DCQ+cf0SnCzo9umLc9A4ZiZ1cdig 5SDpwF6417RIPaSQeFqSV1h/3vh/wPWm+p6R6xhBOvBW1s4Vf9jq//45P7A0T0ynu7EY 11E0UL4QWy4z1d5Iq8CbDUDCjkKSH2PCbnnHJbH+1CSWE3rAjw1peKKa1QqyvZx7prFs qllx9DXREo7f0fA9RJNZ3TlmqFwEzYVulBZqc9D6tIBC7rxe3A2q2U4GDu4bGMC2KtN2 1bTO+z1pLnyLb7ohkdKGjjBVc2Y5RR+az/WI/JWjc77DQ8vqj9cTjLUGI+NZ4mVhWQzt aFUA== Received: by 10.60.154.232 with SMTP id vr8mr2887379oeb.30.1340896073718; Thu, 28 Jun 2012 08:07:53 -0700 (PDT) Received: from [192.168.2.119] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id j10sm15310440oej.10.2012.06.28.08.07.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2012 08:07:53 -0700 (PDT) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: Date: Thu, 28 Jun 2012 10:07:51 -0500 To: drinks@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkRo2vnTp7OcWkyC8bb5L4By4EijLvq5PymhKmJf0V78z6GpTuhJPihJ2Ni7e/inpchExBR Subject: [drinks] Proposed text for Security Considerations/DOS X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:07:59 -0000 I think David asked me to put together some text for the DoS = considerations that we discussed on-list. This would go into the = mandatory Security Considerations section. Here's a starting point: X.X.1 Denial of Service Issues Guidance on Denial-of-Service (DoS) issues in general is given in RFC = 4732, "Internet Denial of Service Considerations", which also gives a = general vocabulary for describing the DoS issue. SPPP is a high-level client-server protocol that can be implemented on = lower-level mechanisms such as remote procedure call and web-service API = protocols. As such, it inherits any Denial-of-Service issues inherent to = the specific lower-level mechanism used for any implementation of SPPP. = SPPP also has its own set of higher-level exposures that are likely to = be independent of lower-layer mechanism choices. X.X.1.1 DoS Issues Inherited from Transport Mechanism SPPP implementation is in general dependent on the selection and = implementation of a lower-level transport protocol and a binding between = that protocol and SPPP. The archetypal SPPP implementation uses XML = (http://www.w3.org/TR/xml/) representation in a SOAP = (http://www.w3.org/TR/soap/) request/response framework over HTTP (RFC = 2616), and probably also uses TLS (RFC 5246) for on-the wire data = integrity and participant authentication, and might use HTTP Digest = authentication (RFC 2069). The typical deployment scenario for SPPP is = to have servers in a managed facility, and therefor techniques such as = Network Ingress Filtering (RFC 2827) are generally applicable. In short, = any DoS mechanism affecting a typical HTTP implementation would affect = such an SPPP implementation, and the mitigation tools for HTTP in = general also therefore apply to SPPP. SPPP does not directly specify an authentication mechanism, instead = relying on the lower-level transport protocol to provide for = authentication. In general, authentication is an expensive operation, = and one apparent attack vector is to flood an SPPP server with repeated = requests for authentication, thereby exhausting its resources. SPPP = implementations SHOULD therefore be prepared to handle authentication = floods, perhaps by noting repeated failed login requests from a given = source address and blocking that source address. X.X.2.2 DoS Issues Specific to SPPP The primary defense mechanism against DoS within SPPP is authentication. = Implementations MUST tightly control access to the SPPP service, SHOULD = implement DoS and other policy control screening, and MAY employ a = variety of policy violation reporting and response measures such as = automatic blocking of specific users and alerting of operations = personnel. In short, the primary SPPP response to DoS-like activity by a = user is to block that user or subject their actions to additional = review. SPPP allows a client to submit multiple-element or "batch" requests that = may insert or otherwise affect a large amount of data with a single = request. In the simplest case, the server progresses sequentially = through each element in a batch, completing one and before starting the = next. However, implementations may re-order request elements, = parallelize them, distribute them to subprocesses, or perform other = optimizations. Implementation designers must choose how to handle a = mid-batch failure and decide what to do with other request elements in = batch wherein one or more elements fail. Options include 1) stopping the = batch with a "partial commit" wherein previously complemented request = elements remain committed to the data store but elements "after" the = failing element do not execute, 2) stopping the batch and rolling-back = the data store to its pre-request state, and 3) continuing the batch, = such that all non-failing elements complete and are committed to the = data store. This is a complex set of alternatives, and implementors must = thoroughly analyze their choices for DoS vulnerabilities. In particular, a "stop and roll-back" choice provides a DoS opportunity. = A hostile client could repeatedly issue large batch requests with one or = more failing elements, causing the server to repeatedly stop and = roll-back large transactions. The suggested response is to monitor = clients for such failures, and take administrative action (such as = blocking the user) when an excessive number of roll-vbacks is reported. From kcartwright@tnsi.com Thu Jun 28 08:27:10 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FDF21F84B8 for ; Thu, 28 Jun 2012 08:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeJOdH+uvj5v for ; Thu, 28 Jun 2012 08:27:09 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 31D3221F84B5 for ; Thu, 28 Jun 2012 08:27:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAAN37E+sEQfn/2dsb2JhbABFtzKCGAEBAQQBAQE3NBcEAgEIEQQBARcBBwkHJwsUCQgBAQQBEgiGCYIFuSqLNxqCUAGCP2ADqDCBPAc X-IronPort-AV: E=Sophos;i="4.77,492,1336345200"; d="scan'208";a="1339340" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 28 Jun 2012 16:27:07 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 28 Jun 2012 11:27:07 -0400 From: "Cartwright, Ken" To: Dean Willis , "drinks@ietf.org" Date: Thu, 28 Jun 2012 11:27:06 -0400 Thread-Topic: [drinks] Proposed text for Security Considerations/DOS Thread-Index: Ac1VP9HO+1NTI3s8Qem4vm26wFaelgAAY/6g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] Proposed text for Security Considerations/DOS X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:27:10 -0000 Sounds good... A couple minor comments suggested in-line below. Ken -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Dean Willis Sent: Thursday, June 28, 2012 11:08 AM To: drinks@ietf.org Subject: [drinks] Proposed text for Security Considerations/DOS I think David asked me to put together some text for the DoS considerations= that we discussed on-list. This would go into the mandatory Security Consi= derations section. Here's a starting point: X.X.1 Denial of Service Issues Guidance on Denial-of-Service (DoS) issues in general is given in RFC 4732,= "Internet Denial of Service Considerations", which also gives a general vo= cabulary for describing the DoS issue. SPPP is a high-level client-server protocol that can be implemented on lowe= r-level mechanisms such as remote procedure call and web-service API protoc= ols. As such, it inherits any Denial-of-Service issues inherent to the spec= ific lower-level mechanism used for any implementation of SPPP. SPPP also = has its own set of higher-level exposures that are likely to be independent= of lower-layer mechanism choices. X.X.1.1 DoS Issues Inherited from Transport Mechanism SPPP implementation is in general dependent on the selection and implementa= tion of a lower-level transport protocol and a binding between that protoco= l and SPPP. The archetypal SPPP implementation uses XML (http://www.w3.org/= TR/xml/) representation in a SOAP (http://www.w3.org/TR/soap/) request/resp= onse framework over HTTP (RFC 2616), and probably also uses TLS (RFC 5246) = for on-the wire data integrity and participant authentication, and might us= e HTTP Digest authentication (RFC 2069). The typical deployment scenario fo= r SPPP is to have servers in a managed facility, and therefor techniques su= ch as Network Ingress Filtering (RFC 2827) are generally applicable. In sho= rt, any DoS mechanism affecting a typical HTTP implementation would affect = such an SPPP implementation, and the mitigation tools for HTTP in general a= lso therefore apply to SPPP. SPPP does not directly specify an authentication mechanism, instead relying= on the lower-level transport protocol to provide for authentication. In ge= neral, authentication is an expensive operation, and one apparent attack ve= ctor is to flood an SPPP server with repeated requests for authentication, = thereby exhausting its resources. SPPP implementations SHOULD therefore be = prepared to handle authentication floods, perhaps by noting repeated failed= login requests from a given source address and blocking that source addres= s. X.X.2.2 DoS Issues Specific to SPPP The primary defense mechanism against DoS within SPPP is authentication. Im= plementations MUST tightly control access to the SPPP service, SHOULD imple= ment DoS and other policy control screening, and MAY employ a variety of po= licy violation reporting and response measures such as automatic blocking o= f specific users and alerting of operations personnel. In short, the primar= y SPPP response to DoS-like activity by a user is to block that user or sub= ject their actions to additional review. SPPP allows a client to submit multiple-element or "batch" requests that ma= y insert or otherwise affect a large amount of data with a single request. = In the simplest case, the server progresses sequentially through each eleme= nt in a batch, completing one and before starting the next. However, implem= entations may re-order request elements, parallelize them, distribute them = to subprocesses, or perform other optimizations. KJC: While it is theoretically possible under some circumstances, suggesti= ng that implementations can/may "re-order request elements" might be a pand= ora's box that we should not open. Re-ordering of request elements in a bat= ch request is not the intended approach, and I think that in-order processi= ng is discussed/mentioned in the doc. So you might want to consider removi= ng the above sentence. Implementation designers must choose how to handle a mid-batch failure and = decide what to do with other request elements in batch wherein one or more = elements fail. Options include 1) stopping the batch with a "partial commit= " wherein previously complemented request elements remain committed to the = data store but elements "after" the failing element do not execute, 2) stop= ping the batch and rolling-back the data store to its pre-request state, an= d 3) continuing the batch, such that all non-failing elements complete and = are committed to the data store. This is a complex set of alternatives, and implementors must thoroughly analyze th= eir choices for DoS vulnerabilities. In particular, a "stop and roll-back" choice provides a DoS opportunity. A = hostile client could repeatedly issue large batch requests with one or more= failing elements, causing the server to repeatedly stop and roll-back larg= e transactions. The suggested response is to monitor clients for such failu= res, and take administrative action (such as blocking the user) when an exc= essive number of roll-vbacks is reported. KJC: An additional suggested response is for an implementer to set their m= aximum allowable XML message size, and their maximum allowable batch size a= t a level that they feel protects their operational instance, given the har= dware sizing they have in place and the expected load and size needs that t= heir users expect. _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.