From alexander.mayrhofer@nic.at Wed Feb 1 03:35:51 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 0578C21F856D for ; Wed, 1 Feb 2012 03:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.12 X-Spam-Level: X-Spam-Status: No, score=-8.12 tagged_above=-999 required=5 tests=[AWL=-1.104, BAYES_40=-0.185, 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 z0NN5zR1R6WB for ; Wed, 1 Feb 2012 03:35:50 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id D4F2B21F857F for ; Wed, 1 Feb 2012 03:35:49 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Wed, 1 Feb 2012 12:35:46 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.355.2; Wed, 1 Feb 2012 12:35:44 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 1 Feb 2012 12:35:42 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B5DE8D1@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Material for today's Virtual Interim Thread-Index: Aczg1YK/tu3eEMIBSLaZTZiVVwNCqA== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] Material for today's Virtual Interim 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, 01 Feb 2012 11:35:51 -0000 I've posted the Chair's slide deck and the Agenda to the IETF's Interim Material site. Please find all information about today's Virtual Interim here: http://www.ietf.org/proceedings/interim/2012/02/01/drinks/proceedings.ht ml The meeting starts at 2pm UTC (9am Eastern). Alex From syed.ali@neustar.biz Wed Feb 1 05:21:40 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 9871721F88B8 for ; Wed, 1 Feb 2012 05:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wz7oV7PPo9Fa for ; Wed, 1 Feb 2012 05:21:39 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE7721F8748 for ; Wed, 1 Feb 2012 05:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1328102536; x=1643446473; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=N7gH8i76JxfiQNCseAIqIZ6rIfqG4g0xELiy8fpNGRw=; b=EaTmCBMLpOzdiaBpdTUAeqxwIxp7UDsOR1nifPJFs8mcqXv1KxU0m14LQBDwFN v18Vho7qJ96vao6wuDRZ/kxA== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.4744886; Wed, 01 Feb 2012 08:22:15 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 1 Feb 2012 08:21:36 -0500 From: "Ali, Syed Wasim" To: "drinks@ietf.org" Date: Wed, 1 Feb 2012 08:21:35 -0500 Thread-Topic: few comments on spp-protocol-over-soap-00 Thread-Index: Aczg5GvqzurLkoZ4Q06jnEOhN/n6EQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: x5i9tRy0leMOfeUU5tW7jA== Content-Type: multipart/alternative; boundary="_000_CB4EA3701DBB2syedalineustarbiz_" MIME-Version: 1.0 Subject: [drinks] few comments on spp-protocol-over-soap-00 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, 01 Feb 2012 13:21:40 -0000 --_000_CB4EA3701DBB2syedalineustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Here are a few things to consider: page 12: typo: change "rage" to "range" general comment: I think repetition of terminology is contributing to the b= ulk of the document. For example, 'clienttransid:', 'minorVer:'. If the mea= ning hasn't changed, perhaps a back-reference of a sort should help. page 13: In past discussions, I think we agreed that the transaction id sho= uld be a token. If so, the following definition can be updated to reflect t= his: page 19: "an specific object" to "a specific object" Embedded schema in the WSDL not only makes the definition appear too big, i= t affects readability. I think we should use the import statement within WS= DL and separately list the schema. It is considered good practice to have different targetNamespace values for= the WSDL and the schema. I remember reading about some tools getting confu= sed between the two values, something to the effect of endpoint mapping iss= ues. Thanks, -Syed --_000_CB4EA3701DBB2syedalineustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
=
H= i,
=

page 12: typo: change "rage" to "range"

=
general = comment: I think repetition of terminology is contributing to the bulk of t= he document. For example, 'clienttransid:', 'minorVer:'. If the meaning has= n't changed, perhaps a back-reference of a sort should help.

page 13: In pas= t discussions, I think we agreed that the transaction id should be a token.= If so, the following definition can be updated to reflect this:

  &nbs= p;  <simpleType name=3D"TransIdType">
       &l= t;restriction base=3D"string"/>
     </simpleType>

page= 19: "an specific object" to "a specific object"

Embedded schema in the WSDL= not only makes the definition appear too big, it affects readability. I th= ink we should use the import statement within WSDL and separately list the = schema.

It is considered good practice to have different targetNamespace val= ues for the WSDL and the schema. I remember reading about some tools gettin= g confused between the two values, something to the effect of endpoint mapp= ing issues.

Thanks,

-Syed=



--_000_CB4EA3701DBB2syedalineustarbiz_-- From dean.willis@softarmor.com Wed Feb 1 07:59:28 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 5D69111E8099 for ; Wed, 1 Feb 2012 07:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L1mwpm4ZX8N for ; Wed, 1 Feb 2012 07:59:27 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0DB11E80A3 for ; Wed, 1 Feb 2012 07:59:27 -0800 (PST) Received: by yhkk25 with SMTP id k25so729825yhk.31 for ; Wed, 01 Feb 2012 07:59:27 -0800 (PST) Received: by 10.236.192.230 with SMTP id i66mr41600056yhn.116.1328111967116; Wed, 01 Feb 2012 07:59:27 -0800 (PST) Received: from [192.168.2.104] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id r68sm45158326yhm.18.2012.02.01.07.59.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Feb 2012 07:59:26 -0800 (PST) From: Dean Willis Content-Type: text/plain; charset=windows-1252 Message-Id: <61400E21-31B6-4A4F-806C-3E2BF9A1608D@softarmor.com> Date: Wed, 1 Feb 2012 09:59:24 -0600 To: drinks@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [drinks] Interim notes on interim meeting 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, 01 Feb 2012 15:59:28 -0000 I scribed notes for first half of meeting: notes-drinks-interim-20120131 by Dean Willis Document points: Framework 5.2.2.2 Derived Object Key Types has a"there" where it needs a = "their". Chaired byAlex Mayrhofer, Sumanth Channabasappa Note Well presented Agenda accepted as presented. Plan to change milestone to submit last documents to IESG by April. This = requires "advanced" versions of docs by mid March for last call. NOted = that cutoff for Paris is March 12. Proposed that we review current drafts by having most recent editor = (Vikas) talk through major changes. Most of the recent changes were = "housekeeping" or minor soiling fixes. Vikas provided a summary based on his recent email to the list. Suggested that we look at "to do" list and use that as a basis for = further discussion. It turns out we don't really have one =85 Discussion = ensued Proposed by chair that we go through document quickly and build a = to-discuss list. Noted to-do items 1) Change egress node 2) Internationalization 3) Internal consistency on terminology and structure 4) Framework 3.1 logical structure diagram and XSD alignment; remove = "extension" from digram, handle extension consistently in XSD. 5) Clarify uniqueness of object-type names. 6) Determine whether route-group offer can be generalized to = object-offer. 7) Consider generic identifier type in Public Identifier 8) Removing "priority" attribute from RteRecType. 9) Add isInSv cattribute to RteGrpType Poll: How many people have read a ref since last IETF meeting? Framework: About a dozen Protocol: about a dozen Iterative discussion of Framework follows 3.1 Framework Data Model David noted some inconsistency between schema diagram and actual XSD, = about resource references. Also issues with route group definition, and = "extension" on Public Identifier. The reef is on the wrong object. Discussion: What is the purpose of this digram? Is it a logical = reference, or a description of the XSD. Proposed that it is a = higher-level concept. So, how much data to include in the diagram? David asked to send his compiled "list of nits" to the list. Section 5. Base Framework Data Structures and Response Codes Proposed that 5.2 Various Object Key Types be renamed Object = Relationships or Data Identity. Perhaps under 5.2 we should have = introductory text. Proposed that Section 5 is also the right spot for string comparison and = upper/lowercasing rules. Alex could send text. Or we might just keep = this in a separate internationalization section. Does object name need to be unique within scope? Probably yes; need to = clarify in text. Discussion around relationship between tntype and route rec vs route = group. Why can't we share any objKeyType? What is an offer of a = Registrant type good for? But we might want to offer destination groups. = Much discussion ensued =85 No conclusion Could carrier of record be elevated into the parent type, non-mandatory? = Ans. Probably not, as we might need types for which COR is irrelevant. Could we have a more generic (not TN) identifier in Public Identifier? = Possibly. Might use a base type with number or string. David Schwarz reiterated concerns (from mailing list and design group) = about problems with pointing TNType to a RteRecRefType instead of a = route group making his peering decisions difficult. It basically makes = the route grouping mechanism useless. Other uses cases he raised suggest = that it might be better to have a generic offer type. Section 6.3 Route Group David praised use of route group ref and asked for consistency with this = in other structures. Discussion: What is relationship between route priority, route group = priority and route group ref priority? Should we remove priority = attribute from RteRecType? Discussion shows a consensus to remove this = attribute. Discussion: Should "in service" attribute be on RteRecType instead of = RteGrpType?? Consensus says "probably" should be on both. Going to break...= From alexander.mayrhofer@nic.at Wed Feb 1 10:06: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 2A0E611E80D3 for ; Wed, 1 Feb 2012 10:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.009 X-Spam-Level: X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_40=-0.185, 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 ZbfXauiXn+hF for ; Wed, 1 Feb 2012 10:06:44 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id BF97311E80BA for ; Wed, 1 Feb 2012 10:06:42 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Wed, 1 Feb 2012 19:06:40 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.355.2; Wed, 1 Feb 2012 19:06:37 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CCE10C.3D38C4E7" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 1 Feb 2012 19:06:35 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B5DE9BF@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interim - raw notes... Thread-Index: AczhDDxkxqlsrG6UQjisgPckhAdKyQ== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] Interim - raw notes... 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, 01 Feb 2012 18:06:46 -0000 ------_=_NextPart_001_01CCE10C.3D38C4E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are my uncooked notes from the Interim Meeting. We will prepare official minutes over the course of the next days. Thanks to all for the productive meeting! Alex ------_=_NextPart_001_01CCE10C.3D38C4E7 Content-Type: text/plain; name="ietf-drinks-notes-82.5.txt" Content-Transfer-Encoding: base64 Content-Description: ietf-drinks-notes-82.5.txt Content-Disposition: attachment; filename="ietf-drinks-notes-82.5.txt" DQpEYXZpZDogaGF2ZSByZXZpZXdlZCBleHRlbnNpdmVseSwgYW5kIHNvbWUgdGhpbmdzIGNsZWFy ZXIgbm93DQoNClN1bWFudGg6IEZpcnN0IHJvdW5kOiBpZGVudGlmeSBpc3N1ZXMsIGFuZCBzdWJz ZXF1ZW50bHkgZGlzY3VzcyBtYWpvciBvbmVzLCB0aGVuIGRpc2N1c3Mgd2hhdCdzIG9wZW4sIGFu ZCBob3cgdG8gYWRkcmVzcyBpdC4NCg0KRGF2aWQ6IHdvdWxkIGxpa2UgYSBtb3JlIGNvbnNpc3Rl bnQgc2V0IG9mIGRvY3VtZW50LCBoYXZlIHJldmlld2VkIG9ubHkgcHJldmlvdXMgdGhlIHZlcnNp b24NCg0KbW9zdCBwZW9wbGUgaGF2ZSByZWFkIGVpdGhlciB0aGUgZG9jdW1lbnQgYWZ0ZXIgdGhl IHNwbGl0LCBvciB0aGUgcmVuYW1lZCByZXZpc2lvbi4NCg0KU3VtYW50aDogTGV0J3MgbGlzdCB0 aGUgb3BlbiBpc3N1ZXMsIGJ1dCBub3QgbmVjZXNzYXJpbHkgc29sdmUgYWxsIG9mIHRoZW0gaW1t ZWRpYXRlbHkuDQoNClZpa2FzIHNob3dpbmcgdGhlICJGcmFtZXdvcmsiIGRvY3VtZW50LiANCg0K SW50cm9kdWN0aW9uLCB0ZXJtaW5vbG9neSwgc2tpcHBpbmcgdG8gZGF0YSBtb2RlbC4NCg0KRGF2 aWQ6IEluY29uc2lzdGVuY3kgYmV0d2VlbiB0aGlzIGRhdGEgbW9kZWwgYW5kIHRoZSBYU0QsIGRl c3RncnByZWYuLi4gSXQncyBub3QgY2FsbGVkIHRoZSBzYW1lIC0gd2FudHMgdG8gc2VlIGNvbnNp c3RlbmNlIGluIHRlcm1pbm9sb2d5LiANCkFsc28sIHRoZSBbMC4ubl0gdGhpbmdzIGNvdWxkIGJl IGFkZGVkIC0gd291bGQgdGhhdCBiZSBjb25mdXNpbmc/DQpBY3R1YWwgb2JqZWN0cyBkb24ndCBh bHdheXMgaGF2ZSB0aGUgZXh0ZW5zaW9ucywgc29tZSBhcmUgb25seSBiYXNlIA0Kb2JqZWN0cywg YnV0IHRoZSBiYXNlIG9iamVjdCBpcyBub3QgaW4gdGhlIHBpY3R1cmUuIA0KDQpLZW46IERpZmZl cmVudCB2aWV3cyBvbiBwdXJwb3NlIG9mIHRoZSBkaWFncmFtLCBzaG91bGQgcmVmbGVjdCBsb2dp Y2FsIA0KcmVsYXRpb25zLiBQcmVkYXRlZCBYU0QgYWN0dWFsbHkuDQoNCkRhdmlkOiBPayB3aXRo IGl0LCBsYWNrIG9mIGNvbnNpc3RlbmN5LiBFeHRlbnNpb25zIGFyZSBjb25mdXNpbmcsIHRha2Ug DQp0aGVtIG91dCBvZiBhbGwgb2YgdGhlbT8gRGlhZ3JhbSBzaG91bGQgYmUgdmVyeSBjcmlzcC4N Cg0KS2VuIGFncmVlcyB0aGF0IHdlIHNob3VsZCBwcm9iYWJseSByZW1vdmUgImV4dGVuc2lvbiIu DQoNCi0tLUlURU06IEFkZHJlc3MgRGlhZ3JhbSBpbmNvbnNpc3RlbmNpZXMgKERhdmlkKQ0KDQpU aW1lIHZhbHVlcyAoMy4yKTogQWxleCB3aWxsIGp1c3QgcmVmZXIgZnJvbSB0aGUgInRpbWUiIGRl ZmluaXRpb24gcGFydCBvZiB0aGUgaTE4biBzZWN0aW9uIHRvIHRoaXMgc2VjdGlvbi4NCg0KNS4y Og0KDQpBbGV4OiBQcm9wZXIgcGxhY2UgZm9yIHRoZSBjYXNlIHNlbnNpdGl2aXR5L2NvbXBhcmlz b24gdGV4dD8NClZpa2FzOiBDb25jZXJuZWQgdGhhdCBpMThuIHRleHQgaXMgc3ByZWFkIGFsbCBv dmVyLCBiZXR0ZXIgdG8gaGF2ZSBpdCBpbiBvbmUgcGxhY2UNCktlbjogVGhpcyBhcmVhIGhhZCBj aGFuZ2VkIHF1aXRlIGEgYml0IHRvIHByZXBhcmUgZm9yIFJFU1RmdWwgZXRjLiANCklkZW50aWZp Y2F0aW9uIG9mIG9iamVjdHMgaGFzIGNoYW5nZWQsIG1vcmUgY2xlYXJlcj8NClZpa2FzOiBJdCdz IGluIHRoZSB0ZXh0IC0gbmFtZSwgcmVnaXN0cmFudCB0eXBlIGlzIHRoZSAidW5pcXVlIGtleSIu IA0KYWN0dWFsIGRlZmluaXRpb24gaXMgaW4gdGhlIHNvYXAgZG9jdW1lbnQuDQoNCkRhdmlkOiBU YWtlIG9mZiBSdGVHcnAgZnJvbSBSdGVHcnBPZmZlcktleVR5cGUsIGluIG9yZGVyIHRvIHVzZSB0 aGUgT2ZmZXIgZm9yIG90aGVyIG9iamVjdCB0eXBlcz8NCkFsZXg6IGlzIGNhdXRpb3VzLCBiZWNh dXNlIHNlbWFudGljcyBvZiAib2ZmZXIiIGFyZSBub3QgY2xlYXIgZm9yIGFsbCBvYmplY3RzDQpL ZW46IE9wdGltaXppbmcgbG9va3VwIHRpbWUgaXMgaW50ZXJuYWwgdGhhdCB5b3UgY2FuIGRvIGFu eXdheS4uIA0KRGF2aWQ6IE5vIHJlYXNvbiBpbiB0aGUgcHJvdG9jb2wgdG8gZXhjbHVkZSBvZmZl cnMgb24gYW55IG90aGVyIG9iamVjdHMuLiBqdXN0IGNoYW5nZSB0aGUgbmFtZS4uIGV2ZW4gc2No ZW1hIGRvZXMgbm90IGxpbWl0IHRoaXMgdG8gcm91dGUgZ3JvdXBzLg0KDQotLS0tIElURU06IEdl bmVyYWxpemUgIlJ0ZUdycE9mZmVyIiB0byAiT2ZmZXIiIChEYXZpZCk/DQoNCihEZWFuKQ0KTm90 ZWQgdG8tZG8gaXRlbXMNCjEpIENoYW5nZSBlZ3Jlc3Mgbm9kZQ0KMikgSW50ZXJuYXRpb25hbGl6 YXRpb24NCjMpIEludGVybmFsIGNvbnNpc3RlbmN5IG9uIHRlcm1pbm9sb2d5IGFuZCBzdHJ1Y3R1 cmUsIERhdmlkIHdpbGwgcmUtcmVhZA0KNCkgRnJhbWV3b3JrIDMuMSBsb2dpY2FsIHN0cnVjdHVy ZSBkaWFncmFtIGFuZCBYU0QgYWxpZ25tZW50OyByZW1vdmUgImV4dGVuc2lvbiIgZnJvbSBkaWFn cmFtLCBoYW5kbGUgZXh0ZW5zaW9uIGNvbnNpc3RlbnRseSBpbiBYU0QuDQo1KSBDbGFyaWZ5IHVu aXF1ZW5lc3Mgb2Ygb2JqZWN0LXR5cGUgbmFtZXMuDQo2KSBEZXRlcm1pbmUgd2hldGhlciByb3V0 ZS1ncm91cCBvZmZlciBjYW4gYmUgZ2VuZXJhbGl6ZWQgdG8gb2JqZWN0LW9mZmVyLg0KDQpWaWth czogUHVibGljIElkZW50aXR5IFR5cGUNCg0KVmlrYXM6IFJlc3BvbnNlIE1lc3NhZ2UgVHlwZXMg YXJlIGRlZmluZWQgaGVyZSwgYW5kIHRoZW4gaW1wbGVtZW50ZWQgaW4gdGhlIHRyYW5zcG9ydCBk b2NzLg0KDQpzZWN0aW9uIDY6DQoNCkRhdmlkOiBDYXJyaWVyIG9mIFJlY29yZCBub3QgaW4gYmFz ZSB0eXBlPyAtIEtlbjogWWVwLCBmb3IgZXhhbXBsZSAiZW1haWwiDQpoYXMgbm8gQ29SLi4gRGF2 aWQgaXMgY29udmluY2VkLg0KDQpLZW46IE51bWJlciBvZiBUeXBlcyBvZiBQSXMgaGFzIGJlZW4g Z3Jvd2luZyBvdmVyIHRpbWUuDQoNClZpa2FzOiBCYXNlIFR5cGUgb2YgY2hvaWNlIG9mICJudW1i ZXIiIG9yICJzdHJpbmciIGFzIHRoZSBjb3I/DQoNCi0tLS0gSVRFTTogRGVjaWRlIG9uIHR5cGUg b2YgQ29SIGlkZW50aWZpZXIgKFZpa2FzKSAtIFVSST8gIk51bWJlciIgYW5kICJTdHJpbmciPw0K DQpEYXZpZDogcG9pbnRpbmcgVE4gdHlwZSB0byBydGVncnAgaW5zdGVhZCBvZiByciwgd291bGQg YWxsb3cgdG8gZGVmaW5lIHBlZXJpbmcgbW9yZSBzZWxlY3RpdmVseS4NCg0KLS0tLUlURU06IFNl ZSBkYXZpZCdzIGNvbW1lbnQgYWJvdmUuDQoNCihOb3RlOiBJZiB3ZSBtYWtlIHRoZSAiT2ZmZXIi IGNoYW5nZSwgZGF2aWQgaXMgZmluZSB3aXRoIGl0IHBvaW50aW5nIHRvIHJyKQ0KDQpBbHNvIHdv dWxkIGJlIGFub3RoZXIgdXNlIGNhc2UgZm9yIHRoZSBnZW5lcmljICJvZmZlciIgbWVjaGFuaXNt Lg0KDQpWaWthczogRG9lc24ndCBzZWUgYW55IHByb2JsZW1zIGluIGdlbmVyYWxpemluZyBPZmZl ci4NCg0KRGlzY3Vzc2lvbiBhYm91dCBwcmlvcml0aWVzLg0KDQotLS0tSVRFTTogUmVtb3ZlIHBy aW9yaXR5IGZyb20gUnRlUmVjQmFzZVR5cGUgKEtlbiwgRGF2aWQ/KQ0KDQotLS0tSVRFTTogYWxz byBhZGQgaXNpbnNlcnZpY2UgZmxhZyBvbnQgdGhlIFJ0ZVJlY0Jhc2VUeXBlIChLZW4sIERhdmlk PykNCg0Kc3VtYW50aCBwcmVzZW50cyBvcHRpb25zIGZvciBiZXN0IHVzZSBvZiB0aW1lIC0gY29s bGVjdCBhbGwgb3BlbiBpc3N1ZXMgZm9yIG5vdywgb3IgYnJlYWsgdGhlIHJldmlldywgYW5kIHRy eSBzb2x2aW5nIHNvbWUgb2YgdGhlIGlzc3Vlcw0KDQotLS0gYnJlYWsgMTBtaW5zIC0tLQ0KDQpT dW1hbnRoIHByZXNlbnQgb3B0aW9ucyB0byBjb250aW51ZSB0aGUgbWVldGluZyAtIGNvbnRpbnVl IGVpdGhlciByZXZpZXcsIG9yIHRyeSB0byBmaXggYSBmZXcgaXNzdWVzPyBHcm91cCBhZ3JlZXMg dGhhdCByZXZpZXdpbmcgZG9jcywgYW5kIGlkZW50aWZ5aW5nIGlzc3VlcyBpcyBwcm9iYWJseSBt b3JlIHVzZWZ1bC4NCg0KRGF2aWQ6IGFncmVlcyB0aGF0IHJyUmVmIGlzIHBvaW50aW5nIHRvIHJy S2V5Lg0KDQpEYXZpZDogV2h5IHRoZSAic2VydmljZSIgZmllbGQgaW4gdGhlIE5BUFRSIHR5cGUg b25seT8NCkFsZXg6IElzIG5vdCBhbiBhYnN0cmFjdCBjb25jZXB0IG9mIERSSU5LUywgYnV0IHRo ZSB2ZXJ5ICJzZXJ2aWNlIiBlbGVtZW50IG9mIHRoZSBOQVBUUiBpdHNlbGYuDQoNCjYuNCAtIHJv dXRlIHJlY29yZA0KDQotLS0tIElURU06IERlZmluZSAic2VydmljZSIgaW4gdGhlIGJhc2Ugcm91 dGUgcmVjb3JkIHR5cGUgKERhdmlkKT8NCg0KRGF2aWQ6IGVncmVzc1JvdXRlIGhhcyB0byBjb250 YWluIGEgInNlcnZpY2UiLCBwcm9tb3RlIGl0IHRvIGJhc2UgcmVjIHR5cGU/DQoNCkRpY3Vzc2lv biBhcm91bmQgdGhlICJzZXJ2aWNlIiBmbGFnIG1vdmVtZW50Lg0KDQpBbGV4OiBTZW1hbnRpY3Mg b2YgInNlcnZpY2UiIGZpZWxkIGluIGJhZSBydCByZWMgdHlwZT8gQ2xlYXIgZm9yIE5BUFRSDQpD b25jbHVzaW9uOiBCcmluZyB0byBMaXN0Lg0KDQpTYW1lIGRpc2N1c3Npb24gZm9yICJ0dGwiLi4u IA0KDQotLS0tIElURU06IE1vdmUgdXAgInR0bCIgZmllbGQgdG8gYmFzZSByb3V0ZSByZWMgdHlw ZSAoVmlrYXMpLiBOb2JvZHkgb2JqZWN0cy4NCg0KRGF2aWQ6IERlZmF1bHQgdmFsdWVzIGZvciBp bmRpdmlkdWFsIGZpZWxkcz8gDQoNCkFsZXg6IERlZmF1bHQgdmFsdWVzIG9ubHkgZm9yIGRlZmF1 bHRzIHRoYXQgYXJlIGRlZmluZWQgaW4gdGhlIHJlc3BlY3RpdmUgc3BlY3MgYWxyZWFkeS4uLiBX b3VsZCB0cmlnZ2VyIGRpc2N1c3Npb24gd2l0aCBhdXRob3Igb2YgYWN0dWFsIHNwZWNzPw0KDQpL ZW46IFdoYXQgYWJvdXQgdGhlICJleHRlbnNpb24iPw0KRGF2aWQ6IG5vdCBzdXJlICJleHRlbnNp b24iIGlzIG5lZWRlZCBpbiBhbGwgcGxhY2VzLCBpdCdzIGFscmVhZHkgaW4gYmFzaWMgb2JqZWN0 IHR5cGUsIHNvIHdoeSBhZGRlZCBhZ2Fpbj8NCg0KLS0tLSBJVEVNOiBFeGFtaW5lIHVzZSBvZiAi ZXh0ZW5zaW9uIiBtZWNoYW5pc20/DQoNCktlbjogQ2FuJ3QgcHV0IGl0IGluIGJhc2UgdHlwZSwg YmVjYXVlIGl0IHdvdWxkIGFwcGx5IHRvIGFsbC4gSXRzIGluIGluIA0KbXVsdGlwbGUgcGxhY2Vz IGJlY2F1c2Ugd2UgbWlnaHQgaGF2ZSBleHRlbnNpb25zIGF0IG11dGxpcGxlIGxldmVsDQoNCi0t LS0gSVRFTTogRGF2aWQgd2lsbCB0YWtlIGEgbG9vayB3aXRoIHRoZSBuZXcgaW5mb3JtYXRpb24g aW4gbWluZC4NCg0KNi41LiBSb3V0ZSBncm91cCBvZmZlcg0KDQpSZWhhc2ggb2YgZWFybGllciBk aXNjdXNzaW9uIGFib3V0IGV4dGVuZGluZyBPZmZlcnMvQWNjZXB0cw0KDQpLZW46IFdvdWxkIG5l ZWQgdG8gaW50cm9kdWNlIHNvbWUgbWVjaGFuaXNtIG8gdGhhdCBzZXJ2ZXIgY2FuIGNvbW11bmlj YXRlIHdoaWNoIG9mZmVycyBpdCBzdXBwb3J0cywgd291bGQgcmVxdWlyZSBtb3JlIHRleHQNCg0K RGF2aWQ6IFRoaW5rIHRoYXQgYmVuZWZpdCBpcyBzbyBncmVhdCB0aGF0IGl0IHdvdWxkIGJlIHdv cnRoIHRoZSBoYXNzbGUuDQoNCktlbjogTmVlZCB0byBjaGFuZ2Ugb3BlcmF0aW9uIG5hbWUgaW4g V1NETCBhcyB3ZWxsLi4NCg0KNi42IGVncmVzcyByb3V0ZQ0KDQotLS0gSVRFTTogRGF2aWQgd2ls bCBwb3N0IGNvbW1lbnQgdG8gbWFpbGluZyBsaXN0Lg0KDQo3LiBPcGVyYXRpb25zDQoNCkRhdmlk OiBXaGF0IGFib3V0IGJhdGNoaW5nPyANClZpa2FzOiBCYXRjaGluZyBpcyBnZW5lcmljIHRvIGFs bCBjb21tYW5kcw0KDQotLS0gSVRFTTogTm90aWZpY2F0aW9uIGFib3V0IG1ldGhvZCBvZiBiYXRj aCBwcm9jZXNzaW5nDQoNCjguIFhNTCBjb25zaWRlcmF0aW9ucw0KDQpubyBjb21tZW50cw0KDQo5 LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQpTdW1hbnRoOiBXZSBjb3VsZCB1c2UgYW4gZWFy bHkgcmV2aWV3IGhlcmUsIGFuZCBTRUMgQURzIHNhaWQgbGV0IHVzIGtub3cgd2hlbiB5b3UncmUg cmVhZHksIHNvIHBsZWFzZSByZXZpZXcgaWYgeW91IGhhdmVuJ3QgdGhpcyB3ZWVrDQoNCi0tLS0g SVRFTTogUmV2aWV3IHNlY3VyaXR5IHNlY3Rpb24sIGFuZCB0aGVuIGRvIGVhcmx5IFNFQyByZXZp ZXcNCg0KMTAuIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbg0KDQpubyBjb21tZW50cw0KDQox MS4gMTIuIDEzLiBubyBjb21tZW50cy4NCg0KU3VtYW50aDogR2VuZXJhbGx5LCBwbGVhc2UgY29u dGludWUgdG8gcmV2aWV3IHRoaXMgZG9jdW1lbnQsIGFuZCBwb3N0IGNvbW1lbnRzIHJhdGhlciBz b29uZXIgdGhhbiBsYXRlci4NCg0KPT09PSBTT0FQIGRvY3VtZW50ID09PT0NCg0KVmlrYXMgcHJl c2VudHMgdGhlIHN0cnVjdHVyZSBvZiB0aGUgZG9jdW1lbnQNCg0KS2VuOiBEaWFncmFtIG9uIHNl Y3Rpb24gNiAtIGRvZXMgdGhhdCBuZWVkIHVwZGF0ZT8NCg0KRGF2aWQ6IEdlbmVyaWMgSUQvVVJJ L1N0cmluZyBpbiBQSSB3b3VsZCBuZWVkIHRvIGJlIGFkZGVkIGhlcmUgYXMgd2VsbC4NCg0KRGF2 aWQ6IEFkZFJlcXVlc3Q6IFRyYW5zYWN0aW9uIElEIFR5cGUgaXMgZGVmaW5lZCBhcyBzdHJpbmcg aGVyZSwgYnV0IGRlZmluZWQgYXMgYSAiVG9rZW4iIGluIHRoZSBGcmFtZXdvcmsuIE5lZWRzIHRv IGJlIGNvbnNpc3RlbnQuDQoNCi0tLS0gSVRFTTogQ2xhcmlmeSB0aGUgZGVmaW5pdGlvbiwgcHJl ZmVycmFibHkgdG8gIlRva2VuIi4gKFZpa2FzKSBSZW1vdmUgaXQgaGVyZSwgZm9yIGV4YW1wbGUu DQoNCi0tLS0gSVRFTTogQWRkIE1heCBMZW5ndGggdG8gcmVzdWx0IGNvZGUgZGVmaW5pdGlvbiAo VmlrYXMpDQoNCktlbjogQWJicmV2aWF0aW9uICJEZXRhaWwiIHRvICJEdGwiIC0gaW5jb25zaXN0 ZW50IHdpdGggbmFtaW5nIG9mIHJlc3BlY3RpdmUgVHlwZXM/DQoNCi0tLSBJVEVNOiBFdmFsdWF0 ZSB3aGV0aGVyIGV4cGFuZCAiRHRsIiBhbmQgbWFrZSBUeXBlIG5hbWVzIGNvbnNpc3RlbnQNCg0K RGF2aWQ6IFdoYXQgaGFwcGVucyB0byByZWplY3RlZCBPZmZlcj8gRG8gT2ZmZXJzIHRpbWUgb3V0 PyBXYW50cyBhIGNsZWFyIGRlZmluaXRpb24gb2Ygd2hhdCBoYXBwZW5zLCBvdGhlcndpc2UgdGhl cmUgd291bGQgYmUgaW50ZXJvcGFiaWxpdHkgaXNzdWVzLiBOZWVkIHRvIGRlZmluZSB0aGUgYmVo YXZpb3VyIG9mIHRoYXQgdXNlZnVsIG1lY2hhbmlzbS4NCg0KLS0tLSBJVEVNOiBDbGFyaWZ5IGV4 cGlyYXRpb24vYmVoYXZpb3VyIG9mIG9mZmVycywgaW5jbHVkZSBEaWFncmFtPyAoRnJhbWV3b3Jr IGRvYyByZWxhdGVkIGl0ZW0gLSBkaXNjdXNzIG9uIGxpc3QpDQoNClNlY3Rpb24gNy41LiBvZiB0 aGUgRnJhbWV3b3JrIGFscmVhZHkgaGFzIHNvbWUgdGV4dCBvbiB0aGF0LCBpcyB0aGF0IGVub3Vn aD8NCg0KSmVyZW15OiBCYXRjaCBPcHM6IElzbid0IHRoYXQgYSBkaWZmZXJlbnQgYmVhc3Q/IEJh dGNoaW5nIGxvb2tzIHNvIGNvbXBsZXRlbHkgZGlmZmVyZW50IHRoYW4gdGhlIHJlcXVlc3QvcmVz cG9uc2UuLi4gRXJyb3IgaGFuZGxpbmcsIA0KZXhwZWN0YXRpb25zIG9mIHN5bmNocm9ub3VzIHJl c3BvbnNlLi4/DQoNCktlbiBleHBsYWlucyB0aGUgbGltaXRhdGlvbnMgLyBmZWF0dXJlcyBvZiBi YXRjaGluZyB0aGF0IHdlIGFncmVlZCBvbiBkdXJpbmcgdGhlIFNQUFAgd29yayBzbyBmYXIuDQoN Ck9wZW4gTWljIHRpbWU6DQo9PT09PT09PT09PT09PQ0KDQotIFNsb3QgZm9yIFBhcmlzPyBObyBk cmFmdCBhZ2VuZGEgeWV0LCB3aWxsIGhvcGVmdWxseSBiZSBub3QgZnJpZGF5IHRoaXMgdGltZS4N Ci0gRGF2aWQgd2lsbCB0aGluayBhYm91dCBtZWNoYW5pc20gdG8gYWRkIG1vcmUgdXNlIGNhc2Vz LiBEZWFuIGFkZHMgdGhhdCBpdCdzIGFsd2F5cyBlYXNpZXIgdG8gY29tbWVudCBvbiB3cml0dGVu IHRleHQuDQoNCi0tIFByb3Bvc2FsIGZvciBuZXh0IHN0ZXBzIC0tDQoNCjEvIEN1dG9mZiBmb3Ig YWRkaXRpb25hbCBjb21tZW50cyBvbiB0aGUgbGF0ZXN0IEktRHMgKDIvMTApICAgIC0tIEFMTCAN CjIvIFJlc29sdmUgb3BlbiBpc3N1ZXMgdmlhIHRoZSBtYWlsaW5nIGxpc3QgYW5kIGRlc2lnbiB0 ZWFtIGNhbGxzICgyLzgsIDIvMTUsIDIvMjIpIC0tIERFU0lHTiBURUFNDQozLyBBdHRlbXB0IGEg cmV2aXNpb24gb2YgdGhlIGRvY3VtZW50IGZvciBlYXJseSByZXZpZXcgKDMvMik7IHRoaXMgbWF5 IG5vdCBhZGRyZXNzIGFsbCBjb21tZW50cyAtLSBBVVRIT1JTDQo0LyBGaW5hbCByZXZpc2lvbiBm b3IgUGFyaXMgKDMvMTApIC0tIEFVVEhPUlMgDQoNClRoaXMgd2lsbCBhbGxvdyB1cyB0byBkbyBh IGNvdXBsZSBvZiB0aGluZ3M6DQotIEFkZHJlc3MgYW5kIGluY29ycG9yYXRlIGFsbCBjb21tZW50 cyBzbyBmYXINCi0gR2V0IGVhcmx5IHJldmlldyBjb21tZW50cyBieSBQYXJpcywgaG9wZWZ1bGx5 DQotIERpc2N1c3MgYW55IHJlbWFpbmluZyBvcGVuIGlzc3VlcyBhbmQgb3BlbiByZXZpZXcgY29t bWVudHMgYXQgdGhlIG5leHQgSUVURg0KDQpNZWV0aW5nIGNvbmNsdWRlcyBhdCAxOTowNSANCg== ------_=_NextPart_001_01CCE10C.3D38C4E7-- From shollenbeck@verisign.com Wed Feb 1 10:29:36 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 0A09311E8080 for ; Wed, 1 Feb 2012 10:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ausDp2ri3VPs for ; Wed, 1 Feb 2012 10:29:35 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA0111E8071 for ; Wed, 1 Feb 2012 10:29:34 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKTymEjoeNUg6c9SORnrVMJSvMowJ2Sr38@postini.com; Wed, 01 Feb 2012 10:29:35 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q11ITXBG032301 for ; Wed, 1 Feb 2012 13:29:33 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Feb 2012 13:29:34 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Feb 2012 13:29:33 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 1 Feb 2012 13:29:32 -0500 From: "Hollenbeck, Scott" To: "drinks@ietf.org" Thread-Topic: TLS Client CertificateRequest? Thread-Index: AczhD3CazMXjUzGfQ2aHUd0FbpoIug== Date: Wed, 1 Feb 2012 18:29:32 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D595A08@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2012 18:29:33.0173 (UTC) FILETIME=[717DCA50:01CCE10F] Subject: [drinks] TLS Client CertificateRequest? 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, 01 Feb 2012 18:29:36 -0000 I wasn't able to attend today's interim meeting, so I apologize if this top= ic has been addressed in the past. I found and read this thread in the arch= ives: http://www.ietf.org/mail-archive/web/drinks/current/msg00980.html I've been reading through 6461 and the framework and protocol drafts. Secti= on 5 of 6461 notes that "Such frameworks and protocols MUST specify mechani= sms to authenticate and authorize any entity that provisions data into the = registry, i.e., that the entity is who it says it is and is allowed to use = the provisioning interface." Section 4.4 of the framework draft say that "t= he SPPF transport protocol MUST provide means for an SPPF server to authent= icate an SPPF Client". Sections 5 and 10.1 of the protocol draft include text that describes how t= hese requirements will be met. I see MUSTs for HTTPS, but no mention of a n= eed for the server to request a certificate from a client. Are servers requ= ired to send a TLS CertificateRequest message as part of the handshake prot= ocol? The means is there, but it doesn't appear that the protocol includes = a requirement for a server to authenticate a client at the TLS level. Scott From alexander.mayrhofer@nic.at Mon Feb 6 07:04:31 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 E9C3621F8636 for ; Mon, 6 Feb 2012 07:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.919 X-Spam-Level: X-Spam-Status: No, score=-7.919 tagged_above=-999 required=5 tests=[AWL=-0.903, BAYES_40=-0.185, 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 vkyQLc3jAEu8 for ; Mon, 6 Feb 2012 07:04:31 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id BE49221F8620 for ; Mon, 6 Feb 2012 07:04:29 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Mon, 6 Feb 2012 16:04:27 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.355.2; Mon, 6 Feb 2012 16:04:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Feb 2012 16:04:20 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B5DEEC1@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft meeting notes from the Interim Thread-Index: Aczk4Hquak5N3BggS7KRw8O39F1LcA== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] Draft meeting notes from the Interim X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 15:04:32 -0000 I've just posted the draft minutes from the Virtual Interim on Feb 01. Please review and comment - these notes will be considered final if no comments are received by Feb 17th. thanks, Alex From alexander.mayrhofer@nic.at Mon Feb 6 07:04:57 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0891A21F86A3 for ; Mon, 6 Feb 2012 07:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.051 X-Spam-Level: X-Spam-Status: No, score=-9.051 tagged_above=-999 required=5 tests=[AWL=0.379, 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 WpF4icPxPLyP for ; Mon, 6 Feb 2012 07:04:56 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9A59821F86B3 for ; Mon, 6 Feb 2012 07:04:53 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Mon, 6 Feb 2012 16:04:52 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.355.2; Mon, 6 Feb 2012 16:04:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Feb 2012 16:04:48 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B5DEEC2@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: meeting notes (now with link.., sorry!) Thread-Index: Aczk4KcCIaTNEUcBSX+ZDo5OmlK3mQ== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] meeting notes (now with link.., sorry!) X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 15:04:57 -0000 And the link to the notes is: http://www.ietf.org/proceedings/interim/2012/02/01/drinks/minutes/drinks .txt Alex From dean.willis@softarmor.com Wed Feb 8 06:57:20 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 6870B21F86FE for ; Wed, 8 Feb 2012 06:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtvkQ9lwksNU for ; Wed, 8 Feb 2012 06:57:20 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D982021F86FD for ; Wed, 8 Feb 2012 06:57:19 -0800 (PST) Received: by yenm3 with SMTP id m3so299504yen.31 for ; Wed, 08 Feb 2012 06:57:19 -0800 (PST) Received: by 10.236.128.242 with SMTP id f78mr38363913yhi.30.1328713039359; Wed, 08 Feb 2012 06:57:19 -0800 (PST) Received: from [192.168.2.129] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id a14sm3544095ana.20.2012.02.08.06.57.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 06:57:18 -0800 (PST) References: <831693C2CDA2E849A7D7A712B24E257F0D595A08@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D595A08@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <3D35AFB9-D8E1-4AF7-B483-F6DE35FEE6F2@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Wed, 8 Feb 2012 08:57:16 -0600 To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1084) Cc: "drinks@ietf.org" Subject: Re: [drinks] TLS Client CertificateRequest? 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, 08 Feb 2012 14:57:20 -0000 On Feb 1, 2012, at 12:29 PM, Hollenbeck, Scott wrote: >=20 > Sections 5 and 10.1 of the protocol draft include text that describes = how these requirements will be met. I see MUSTs for HTTPS, but no = mention of a need for the server to request a certificate from a client. = Are servers required to send a TLS CertificateRequest message as part of = the handshake protocol? The means is there, but it doesn't appear that = the protocol includes a requirement for a server to authenticate a = client at the TLS level. Nope. Basic or Digest authentication over HTTPS is considered good = enough. There's no requirement for the client to have or present a cert. -- Dean= From shollenbeck@verisign.com Wed Feb 8 10:33: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 9B31221E800E for ; Wed, 8 Feb 2012 10:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWSKq4nkrKk1 for ; Wed, 8 Feb 2012 10:33:45 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 468EA21F85B4 for ; Wed, 8 Feb 2012 10:33:45 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTzLAB/mE1MaJ1rSEfdV3Gvb0/LDWE6eI@postini.com; Wed, 08 Feb 2012 10:33:45 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q18IXfpB022896; Wed, 8 Feb 2012 13:33:43 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 13:33:41 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 13:33:40 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 8 Feb 2012 13:33:39 -0500 From: "Hollenbeck, Scott" To: Dean Willis Thread-Topic: [drinks] TLS Client CertificateRequest? Thread-Index: AQHM5nH2W6gwl4O9eEqyXBtiou8dHZYzSJ7Q Date: Wed, 8 Feb 2012 18:33:40 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D598DB4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D595A08@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <3D35AFB9-D8E1-4AF7-B483-F6DE35FEE6F2@softarmor.com> In-Reply-To: <3D35AFB9-D8E1-4AF7-B483-F6DE35FEE6F2@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 18:33:40.0845 (UTC) FILETIME=[2E01C9D0:01CCE690] Cc: "drinks@ietf.org" Subject: Re: [drinks] TLS Client CertificateRequest? 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, 08 Feb 2012 18:33:46 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, February 08, 2012 9:57 AM > To: Hollenbeck, Scott > Cc: drinks@ietf.org > Subject: Re: [drinks] TLS Client CertificateRequest? >=20 >=20 > On Feb 1, 2012, at 12:29 PM, Hollenbeck, Scott wrote: > > > > Sections 5 and 10.1 of the protocol draft include text that describes > how these requirements will be met. I see MUSTs for HTTPS, but no > mention of a need for the server to request a certificate from a > client. Are servers required to send a TLS CertificateRequest message > as part of the handshake protocol? The means is there, but it doesn't > appear that the protocol includes a requirement for a server to > authenticate a client at the TLS level. >=20 >=20 > Nope. Basic or Digest authentication over HTTPS is considered good > enough. There's no requirement for the client to have or present a > cert. If that's the case, there's a risk of malicious clients consuming server-si= de resources to the point of denying service to legitimate clients. The ris= k should be identified in the security considerations section, perhaps as a= n additional paragraph in section 10.2. I'll suggest text if it helps. Scott From sumanth@cablelabs.com Wed Feb 8 14:09:41 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 69C4721F853A for ; Wed, 8 Feb 2012 14:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppvG8nxkix8j for ; Wed, 8 Feb 2012 14:09:40 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 77D1D21F852B for ; Wed, 8 Feb 2012 14:09:40 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q18M9dAc018178 for ; Wed, 8 Feb 2012 15:09:39 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 08 Feb 2012 15:09:39 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 8 Feb 2012 15:09:39 -0700 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Wed, 8 Feb 2012 15:09:38 -0700 Thread-Topic: Draft minutes from the DRINKS design team call (2/8) Thread-Index: AczmrkVS251egrCSTFW3fsmorkwtfw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F8F279C5182@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Draft minutes from the DRINKS design team call (2/8) 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, 08 Feb 2012 22:09:41 -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 2/8/2012, 10:00a-11:00a (Eastern)/8:00a-9:00a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Alexander Mayrhofer - Dean Willis - Ken Cartwright - Vikas Bhatia - Manjul Maharishi - Sumanth Channabasappa=20 ACTION ITEMS UPDATE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - [Ken, Vikas?] Send a recommendation related to the representation of the = SPID - [Design Team] Review sections we want to prepare for the pre-review (e.g.= , security) AGENDA =3D=3D=3D=3D=3D=3D 1/ Discuss follow-up from interim 2/ Next Steps NOTES =3D=3D=3D=3D=3D 1/ Discuss follow-up from interim - The design team reviewed the draft notes from the interim, which can b= e found at: http://www.ietf.org/proceedings/interim/2012/02/01/drinks/minutes/drinks= =20 =20 - The discussions resulted in a few clarifications around the action ite= ms - Alex will update the notes, and also assign AI owners - In addition, given the lack of clarification around the definition and= use of SPID, there was a recommendation to propose text around this. 2/ Next Steps - We still plan to go with the following timelines, agreed-to at the int= erim > Cutoff for additional comments on the latest I-Ds (2/10) -- ALL=20 > Resolve open issues via the mailing list and design team calls (2/8,= 2/15, 2/22) -- DESIGN TEAM > Attempt a revision of the document for early review (3/2); this may = not address all comments -- AUTHORS > Final revision for Paris (3/10) -- AUTHORS=20 From sumanth@CableLabs.com Wed Feb 8 14:22:15 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 39FC621F8599 for ; Wed, 8 Feb 2012 14:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wJJMR8KMDGF for ; Wed, 8 Feb 2012 14:22:14 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B32BB21F85D1 for ; Wed, 8 Feb 2012 14:22:14 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q18MKpPK019581 for ; Wed, 8 Feb 2012 15:22:13 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 08 Feb 2012 15:20:51 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 8 Feb 2012 15:21:22 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Wed, 8 Feb 2012 15:21:21 -0700 Thread-Topic: Review comments on the latest revisions? Thread-Index: Aczmr/yRet2rfAZ8RFODjRX9Ap4scQ== Message-ID: <76AC5FEF83F1E64491446437EA81A61F8F279C5183@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F8F279C5183srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Review comments on the latest revisions? 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, 08 Feb 2012 22:22:15 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F8F279C5183srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, As you are probably aware, we held a productive interim meeting last week w= here we reviewed and documented comments against the latest I-D updates. If= anyone who could not make the interim has reviewed these documents and hav= e comments, we encourage you to share them soon, preferably this week. (Tha= nks to those who have already.) Here are references to these documents: 1/ Session Peering Provisioning Framework http://www.ietf.org/id/draft-ietf-drinks-spp-framework-00.txt (Replaced its predecessor @ http://tools.ietf.org/wg/drinks/draft-ietf-drin= ks-spprov/ ) 2/ Session Peering Provisioning (SPP) Protocol over SOAP http://www.ietf.org/id/draft-ietf-drinks-spp-protocol-over-soap-00.txt (Replaced http://tools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/= ) Thanks! - Alex & Sumanth --_000_76AC5FEF83F1E64491446437EA81A61F8F279C5183srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

As you = are probably aware, we held a productive interim meeting last week where we= reviewed and documented comments against the latest I-D updates. If anyone= who could not make the interim has reviewed these documents and have comme= nts, we encourage you to share them soon, preferably this week. (Thanks to = those who have already.)

 

Here are references to these documents:

 

1/ Ses= sion Peering Provisioning Framework

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

(Replaced its predecessor @ http://tools.ietf.org/wg/drink= s/draft-ietf-drinks-spprov/ )

&= nbsp;

 

2/ Session Peering Provisioning (SPP) Protocol over SOAP

<= p class=3DMsoNormal>http://www.ietf.org/id/draft-ietf-drinks-spp-pr= otocol-over-soap-00.txt

(Replaced <= a href=3D"http://tools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/= ">http://tools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/ )

 

Thanks!

- Alex & Sumanth=

= --_000_76AC5FEF83F1E64491446437EA81A61F8F279C5183srvxchg_-- From alexander.mayrhofer@nic.at Thu Feb 16 10:08:20 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 648C921F87DC for ; Thu, 16 Feb 2012 10:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.78 X-Spam-Level: X-Spam-Status: No, score=-7.78 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, 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 TBLbzq72mh2h for ; Thu, 16 Feb 2012 10:08:19 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4D46221F8645 for ; Thu, 16 Feb 2012 10:08:18 -0800 (PST) Received: from nics-mail.sbg.nic.at ([10.17.175.2]) by mail.sbg.nic.at with XWall v3.47 ; Thu, 16 Feb 2012 19:08:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Feb 2012 19:08:13 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B67EE4C@nics-mail.sbg.nic.at> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes from the DRINKS design team call (2/15) Thread-Index: Aczs0r/+zKil3Hv8QUyxOMUBe9tb/Q== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] Draft minutes from the DRINKS design team call (2/15) 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, 16 Feb 2012 18:08:20 -0000 Minutes from the Design team call are included below - please review. thanks, Alex 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 2/15/2012, 10:00a-11:00a (Eastern)/8:00a-9:00a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Alexander Mayrhofer - Dean Willis - Vikas Bhatia - Manjul Maharishi - David Schwartz AGENDA =3D=3D=3D=3D=3D=3D 1/ Discuss follow-up from interim 2/ Next Steps REVIEWERS =3D=3D=3D=3D=3D=3D=3D=3D=3D Alex reports that Peter St. Andre has volunteered to do a review=20 of an updated revision, Chairs will inform him when a new version is available. DOCUMENT ACTION ITEMS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The action items identified during the Interim were clarified, and=20 unassigned AIs were assigned to owners. The current list is as follows: (I've also assigned numbers for easier reference) Framework document ------------------ AI-1/ Address Diagram Inconsistencies (Vikas) AI-2/ Investigate Route group offer generalization (David) AI-3/ Propose text about structure of non-numeric PI (Ken, Vikas) (Originally listed as "Decide on type of CoR identifier) AI-4/ TNType to RteRecRefType pointer: reconsider (David) AI-5/ Remove priority from RteRecBaseType (Vikas) AI-6/ Also add isinservice flag on RteRecBaseType (Ken, David) ("Define 'service' in the base route rec type was considered obsolete) AI-7/ Move up "ttl" field to base route rec type (Vikas) AI-8/ Reconsider "extension" options with new info (David) AI-9/ Consider adding "service" field to Egress Route (David) AI-10/ Discuss on mailing list how registry handles batches (Jeremy) AI-11/ Review Security Cons section (All) AI-12/ Organize early expert review of Security Cons section (Chairs) SOAP document ------------- AI-13/ Clarify/remove definition of transaction id type (to "Token"), or remove definition from here (Vikas) AI-14/ Evaluate whether to expand "Dtl" and make Type names=20 consistent (Vikas) AI-15/ Add max length to result code/message definition (Vikas) AI-16/ Clarify behaviour/expiration of offers, include a lifecycle Diagram? (Alex, David) AI-17/ Internationalization/Comparison Ops (Alex) AI-18/ Ensure internal consistency on terminology and structure (David) AI-19/ Clarify uniqueness of object-type names (Vikas) TIMELINE =3D=3D=3D=3D=3D=3D=3D=3D Vikas indicated that there will be no update of the documents by=20 3/2, and he will provide the changes by 3/10. It was also noted=20 that no further comments on the documents arrived before the=20 deadline of 2/10.=20 Chairs will inform Peter St. Andre that a new version is not=20 expected before 3/10, and will decide/discuss whether he will review the current versions instead. NEXT CALL =3D=3D=3D=3D=3D=3D=3D=3D=3D 2/22/2012, 10:00a-11:00a (Eastern)/8:00a-9:00a (Mountain) From shollenbeck@verisign.com Thu Feb 16 16:03:32 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 F212521E804B for ; Thu, 16 Feb 2012 16:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGlUjabbqj4U for ; Thu, 16 Feb 2012 16:03:28 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9573121E8035 for ; Thu, 16 Feb 2012 16:03:27 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKTz2ZS6Tg1e3SRrc880If9DZVmDODUsgU@postini.com; Thu, 16 Feb 2012 16:03:27 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q1H03MPE029832; Thu, 16 Feb 2012 19:03:22 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Feb 2012 19:03:22 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Thu, 16 Feb 2012 19:03:21 -0500 From: "Hollenbeck, Scott" To: Alexander Mayrhofer , "drinks@ietf.org" Thread-Topic: Draft minutes from the DRINKS design team call (2/15) Thread-Index: Aczs0r/+zKil3Hv8QUyxOMUBe9tb/QANKlrA Date: Fri, 17 Feb 2012 00:03:20 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D59E808@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <8BC845943058D844ABFC73D2220D46650B67EE4C@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650B67EE4C@nics-mail.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Feb 2012 00:03:22.0954 (UTC) FILETIME=[905E12A0:01CCED07] Subject: Re: [drinks] Draft minutes from the DRINKS design team call (2/15) 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, 17 Feb 2012 00:03:32 -0000 The issue described here: http://www.ietf.org/mail-archive/web/drinks/current/msg01111.html should be captured and addressed. Scott > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of Alexander Mayrhofer > Sent: Thursday, February 16, 2012 1:08 PM > To: drinks@ietf.org > Subject: [drinks] Draft minutes from the DRINKS design team call (2/15) >=20 >=20 > Minutes from the Design team call are included below - please review. >=20 > thanks, >=20 > Alex >=20 >=20 >=20 > IETF DRINKS DESIGN TEAM CALL > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 2/15/2012, 10:00a-11:00a (Eastern)/8:00a-9:00a (Mountain) >=20 > Participants > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - Alexander Mayrhofer > - Dean Willis > - Vikas Bhatia > - Manjul Maharishi > - David Schwartz >=20 > AGENDA > =3D=3D=3D=3D=3D=3D >=20 > 1/ Discuss follow-up from interim > 2/ Next Steps >=20 > REVIEWERS > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Alex reports that Peter St. Andre has volunteered to do a review > of an updated revision, Chairs will inform him when a new version > is available. >=20 > DOCUMENT ACTION ITEMS > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The action items identified during the Interim were clarified, and > unassigned AIs were assigned to owners. The current list is as follows: > (I've also assigned numbers for easier reference) >=20 > Framework document > ------------------ >=20 > AI-1/ Address Diagram Inconsistencies (Vikas) >=20 > AI-2/ Investigate Route group offer generalization (David) >=20 > AI-3/ Propose text about structure of non-numeric PI (Ken, Vikas) > (Originally listed as "Decide on type of CoR identifier) >=20 > AI-4/ TNType to RteRecRefType pointer: reconsider (David) >=20 > AI-5/ Remove priority from RteRecBaseType (Vikas) >=20 > AI-6/ Also add isinservice flag on RteRecBaseType (Ken, David) >=20 > ("Define 'service' in the base route rec type was considered obsolete) >=20 > AI-7/ Move up "ttl" field to base route rec type (Vikas) >=20 > AI-8/ Reconsider "extension" options with new info (David) >=20 > AI-9/ Consider adding "service" field to Egress Route (David) >=20 > AI-10/ Discuss on mailing list how registry handles batches (Jeremy) >=20 > AI-11/ Review Security Cons section (All) >=20 > AI-12/ Organize early expert review of Security Cons section (Chairs) >=20 > SOAP document > ------------- >=20 > AI-13/ Clarify/remove definition of transaction id type (to "Token"), > or remove definition from here (Vikas) >=20 > AI-14/ Evaluate whether to expand "Dtl" and make Type names > consistent (Vikas) >=20 > AI-15/ Add max length to result code/message definition (Vikas) >=20 > AI-16/ Clarify behaviour/expiration of offers, include a lifecycle > Diagram? (Alex, David) >=20 > AI-17/ Internationalization/Comparison Ops (Alex) >=20 > AI-18/ Ensure internal consistency on terminology and structure (David) >=20 > AI-19/ Clarify uniqueness of object-type names (Vikas) >=20 > TIMELINE > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > Vikas indicated that there will be no update of the documents by > 3/2, and he will provide the changes by 3/10. It was also noted > that no further comments on the documents arrived before the > deadline of 2/10. >=20 > Chairs will inform Peter St. Andre that a new version is not > expected before 3/10, and will decide/discuss whether he will > review the current versions instead. >=20 > NEXT CALL > =3D=3D=3D=3D=3D=3D=3D=3D=3D > 2/22/2012, 10:00a-11:00a (Eastern)/8:00a-9:00a (Mountain) > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks From alexander.mayrhofer@nic.at Fri Feb 17 00:39:11 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609FA21F887F for ; Fri, 17 Feb 2012 00:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.04 X-Spam-Level: X-Spam-Status: No, score=-9.04 tagged_above=-999 required=5 tests=[AWL=0.390, 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 cmPIUTdl-AYB for ; Fri, 17 Feb 2012 00:39:10 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6857621F887E for ; Fri, 17 Feb 2012 00:39:10 -0800 (PST) Received: from nics-mail.sbg.nic.at ([10.17.175.2]) by mail.sbg.nic.at with XWall v3.47 ; Fri, 17 Feb 2012 09:39:10 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2012 09:39:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <8BC845943058D844ABFC73D2220D46650B67EEB2@nics-mail.sbg.nic.at> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D59E808@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes from the DRINKS design team call (2/15) Thread-Index: Aczs0r/+zKil3Hv8QUyxOMUBe9tb/QANKlrAABIGghA= References: <8BC845943058D844ABFC73D2220D46650B67EE4C@nics-mail.sbg.nic.at> <831693C2CDA2E849A7D7A712B24E257F0D59E808@BRN1WNEXMBX01.vcorp.ad.vrsn.com> From: "Alexander Mayrhofer" To: "Hollenbeck, Scott" , X-XWALL-BCKS: auto Subject: Re: [drinks] Draft minutes from the DRINKS design team call (2/15) 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, 17 Feb 2012 08:39:11 -0000 > The issue described here: >=20 > http://www.ietf.org/mail-archive/web/drinks/current/msg01111.html >=20 > should be captured and addressed. Scott, thanks for the heads up. It will be added to the AI list, and addressed in the next revision. Alex From dschwartz@xconnect.net Wed Feb 22 05:06:33 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 362B521F87A5 for ; Wed, 22 Feb 2012 05:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6ZH0V0kcQTx for ; Wed, 22 Feb 2012 05:06:32 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id C27B721F8697 for ; Wed, 22 Feb 2012 05:06:30 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 22 Feb 2012 15:06:28 +0200 From: David Schwartz To: "drinks@ietf.org" Date: Wed, 22 Feb 2012 15:06:29 +0200 Thread-Topic: Some general comments on SPPF Thread-Index: AczxYsmI1uzXOmFcTLyJi4XlsZC6Fg== Message-ID: <5AF54DE0-9946-4FAE-96DB-530BC979961D@xconnect.net> 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_5AF54DE099464FAE96DB530BC979961Dxconnectnet_" MIME-Version: 1.0 Subject: [drinks] Some general comments on SPPF 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, 22 Feb 2012 13:06:33 -0000 --_000_5AF54DE099464FAE96DB530BC979961Dxconnectnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are some additional comments to consider... 1. After spending considerable time analyzing this I am pretty convinced th= at peering should be completely removed from SPPF. I came to this conclusio= n afar going through some of the many peering scenarios and realizing that = the current model supports a small subset of the cases. Many real world use= cases are not addressed and the existing mechanism is simply incomplete. I= spent many cycles trying to fix prior to just giving up - Here are just so= me of the sample use cases that lead to this conclusion: * Sharing LUF in an open manner (with whomever wants it) using current mech= anism (semantically, no peeringOrgs means NO sharing of rteGrp) * peeringOrg would like to request LRF from org showing in its LUF that it = has information for a PI * Excluding a peer from receiving rteGrp information without knowing all pa= rties that are ALLOWED to receive route information IMHO an orthogonal peering model is required that can sit on top of SPPF. 2. EgressRoute is just a special case of a RouteRule and should be made mor= e general. This is needed as well to address the route manipulation aspect = of sorceIdent flag. 3. IsInService should be attribute of routeRecord as well 4. Need to have a URI type as a PI or else LUF resolution (URI) cannot be f= ed back into the system for LRF resolution. 5. Need to have in introduction option to just go identifier-> LRF without = first LUF querying 6. Batch request should be an implicit subscription. New method NOTIFY shou= ld be sent when processing is done including summary of the operation. 7. Diagram in SPPF doc should be cleaned up * remove extensions * add missing arrows (TN and RR) * add [0..n] on relevant arrows --_000_5AF54DE099464FAE96DB530BC979961Dxconnectnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Here are some additional comments to= consider...

1. After spending considerable time analyzing this I am pretty conv= inced that peering should be completely removed from SPPF. I came to this c= onclusion afar going through some of the many peering scenarios and realizi= ng that the current model supports a small subset of the cases. Many real w= orld use cases are not addressed and the existing mechanism is simply incom= plete. I spent many cycles trying to fix prior to just giving up - Her= e are just some of the sample use cases that lead to this conclusion:
=

=
* Sharing = LUF in an open manner (with whomever wants it) using current mechanism (sem= antically, no peeringOrgs means NO sharing of rteGrp)
* peeringOrg would like to= request LRF from org showing in its LUF that it has information for a PI
* Excl= uding a peer from receiving rteGrp information without knowing all parties = that are ALLOWED to receive route information

IMHO an orthogonal peering model i= s required that can sit on top of SPPF. 

2. EgressRoute i= s just a special case of a RouteRule and should be made more general. This = is needed as well to address the route manipulation aspect of sorceIdent fl= ag.

3. IsInService should be attribute of routeRecord as well<= /div>

4. Need to have a URI type as a PI or else LUF resolution (URI= ) cannot be fed back into the system for LRF resolution.

<= /div>
5. Ne= ed to have in introduction option to just go identifier-> LRF without fi= rst LUF querying

6. Batch request should be an implicit subscr= iption. New method NOTIFY should be sent when processing is done including = summary of the operation. 

7. Diagram in SPPF doc should = be cleaned up 
* remove extensions
* add missing arrows (TN and RR)
* add [0..n] on r= elevant arrows
= --_000_5AF54DE099464FAE96DB530BC979961Dxconnectnet_-- From dschwartz@xconnect.net Wed Feb 22 05:13: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 D623D21F86D5 for ; Wed, 22 Feb 2012 05:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7XNTFUP4TMp for ; Wed, 22 Feb 2012 05:13:34 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 87F4421F86CB for ; Wed, 22 Feb 2012 05:13:33 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 22 Feb 2012 15:13:32 +0200 From: David Schwartz To: "drinks@ietf.org" Date: Wed, 22 Feb 2012 15:13:33 +0200 Thread-Topic: [drinks] Some general comments on SPPF Thread-Index: AczxY8aeSiqjkaaaRNmWcPK1rbuWRw== Message-ID: References: <5AF54DE0-9946-4FAE-96DB-530BC979961D@xconnect.net> In-Reply-To: <5AF54DE0-9946-4FAE-96DB-530BC979961D@xconnect.net> 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_DAC7AFA3AE88498EBEBB5A0DEC42CB61xconnectnet_" MIME-Version: 1.0 Subject: Re: [drinks] Some general comments on SPPF 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, 22 Feb 2012 13:13:34 -0000 --_000_DAC7AFA3AE88498EBEBB5A0DEC42CB61xconnectnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I need to clarify item #4 below=85 In the introduction there is mention of LUF followed by LRF lookup. While I= am aware that this is a provisioning protocol, nonetheless, there needs to= be a mechanism to provision an LUF --> LRF relationship. As the LUF resolu= tion is a URI, what is missing is a LUF type PI. :D On Feb 22, 2012, at 1:06 PM, David Schwartz wrote: Here are some additional comments to consider... 1. After spending considerable time analyzing this I am pretty convinced th= at peering should be completely removed from SPPF. I came to this conclusio= n afar going through some of the many peering scenarios and realizing that = the current model supports a small subset of the cases. Many real world use= cases are not addressed and the existing mechanism is simply incomplete. I= spent many cycles trying to fix prior to just giving up - Here are just so= me of the sample use cases that lead to this conclusion: * Sharing LUF in an open manner (with whomever wants it) using current mech= anism (semantically, no peeringOrgs means NO sharing of rteGrp) * peeringOrg would like to request LRF from org showing in its LUF that it = has information for a PI * Excluding a peer from receiving rteGrp information without knowing all pa= rties that are ALLOWED to receive route information IMHO an orthogonal peering model is required that can sit on top of SPPF. 2. EgressRoute is just a special case of a RouteRule and should be made mor= e general. This is needed as well to address the route manipulation aspect = of sorceIdent flag. 3. IsInService should be attribute of routeRecord as well 4. Need to have a URI type as a PI or else LUF resolution (URI) cannot be f= ed back into the system for LRF resolution. 5. Need to have in introduction option to just go identifier-> LRF without = first LUF querying 6. Batch request should be an implicit subscription. New method NOTIFY shou= ld be sent when processing is done including summary of the operation. 7. Diagram in SPPF doc should be cleaned up * remove extensions * add missing arrows (TN and RR) * add [0..n] on relevant arrows --_000_DAC7AFA3AE88498EBEBB5A0DEC42CB61xconnectnet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I need to clarify item #4 = below=85

In the introduction there is mention of LUF fol= lowed by LRF lookup. While I am aware that this is a provisioning protocol,= nonetheless, there needs to be a mechanism to provision an LUF --> LRF = relationship. As the LUF resolution is a URI, what is missing is a LUF type= PI.

:D

On Feb 22, 2012, a= t 1:06 PM, David Schwartz wrote:

Here are some additional co= mments to consider...

1. After spending considerable time analyzing this I am pr= etty convinced that peering should be completely removed from SPPF. I came = to this conclusion afar going through some of the many peering scenarios an= d realizing that the current model supports a small subset of the cases. Ma= ny real world use cases are not addressed and the existing mechanism is sim= ply incomplete. I spent many cycles trying to fix prior to just giving= up - Here are just some of the sample use cases that lead to this conclusi= on:
<= br>
*= Sharing LUF in an open manner (with whomever wants it) using current mecha= nism (semantically, no peeringOrgs means NO sharing of rteGrp)
* peeringOrg woul= d like to request LRF from org showing in its LUF that it has information f= or a PI

IMHO an orthogonal peerin= g model is required that can sit on top of SPPF. 

2. Egre= ssRoute is just a special case of a RouteRule and should be made more gener= al. This is needed as well to address the route manipulation aspect of sorc= eIdent flag.

3. IsInService should be attribute of routeRecord= as well

4. Need to have a URI type as a PI or else LUF resolu= tion (URI) cannot be fed back into the system for LRF resolution.

5. Need to have in introduction option to just go identifier-> LRF w= ithout first LUF querying

6. Batch request should be an implic= it subscription. New method NOTIFY should be sent when processing is done i= ncluding summary of the operation. 

7. Diagram in SPPF d= oc should be cleaned up 
* remove extensions
* add missing arrows (TN and RR)
* add [= 0..n] on relevant arrows
<ATT00001..c>

= --_000_DAC7AFA3AE88498EBEBB5A0DEC42CB61xconnectnet_-- From dean.willis@softarmor.com Wed Feb 22 07:57:36 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 A456721F8824 for ; Wed, 22 Feb 2012 07:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BE9CKJipTqvo for ; Wed, 22 Feb 2012 07:57:36 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 309BE21F8826 for ; Wed, 22 Feb 2012 07:57:32 -0800 (PST) Received: by yenm3 with SMTP id m3so121061yen.31 for ; Wed, 22 Feb 2012 07:57:31 -0800 (PST) Received-SPF: pass (google.com: domain of dean.willis@softarmor.com designates 10.236.186.1 as permitted sender) client-ip=10.236.186.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dean.willis@softarmor.com designates 10.236.186.1 as permitted sender) smtp.mail=dean.willis@softarmor.com Received: from mr.google.com ([10.236.186.1]) by 10.236.186.1 with SMTP id v1mr45006685yhm.4.1329926251881 (num_hops = 1); Wed, 22 Feb 2012 07:57:31 -0800 (PST) Received: by 10.236.186.1 with SMTP id v1mr35176605yhm.4.1329926251782; Wed, 22 Feb 2012 07:57:31 -0800 (PST) Received: from [192.168.2.124] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id p18sm23966107yhh.9.2012.02.22.07.57.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 07:57:30 -0800 (PST) References: <5AF54DE0-9946-4FAE-96DB-530BC979961D@xconnect.net> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-14--568268965 Message-Id: <0EA3C3A2-1E7C-438E-B08C-B1E393E719D0@softarmor.com> From: Dean Willis Date: Wed, 22 Feb 2012 09:57:29 -0600 To: David Schwartz X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnq02oHatHIM25N/zR0fajqmMWWtlaEvpdRIsy+50u0O2l11IMJ/0Z+IdQGzDpcJGPXAU9m Cc: "drinks@ietf.org" Subject: Re: [drinks] Some general comments on SPPF 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, 22 Feb 2012 15:57:36 -0000 --Apple-Mail-14--568268965 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 22, 2012, at 7:13 AM, David Schwartz wrote: >>=20 >> 5. Need to have in introduction option to just go identifier-> LRF = without first LUF querying Can you clarify this one? I'm not exactly sure what you are talking = about. -- Dean --Apple-Mail-14--568268965 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

5. Need to have in = introduction option to just go identifier-> LRF without first LUF = querying

=
Can you clarify this one? I'm not exactly sure what you are talking = about.

--
Dean

= --Apple-Mail-14--568268965-- From sumanth@cablelabs.com Wed Feb 22 09:23: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 6490621F865E for ; Wed, 22 Feb 2012 09:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5icA8RFnKXj for ; Wed, 22 Feb 2012 09:23:06 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA3421F8622 for ; Wed, 22 Feb 2012 09:23:06 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q1MHG6Y2030703 for ; Wed, 22 Feb 2012 10:23:00 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 22 Feb 2012 10:16:06 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 22 Feb 2012 10:16:06 -0700 From: Sumanth Channabasappa To: "drinks@ietf.org" Date: Wed, 22 Feb 2012 10:16:11 -0700 Thread-Topic: Draft minutes from the DRINKS design team call (2/22) Thread-Index: AczxhZ9+Q6EESoPfSrO+uvRzE8LwYw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F8F2BCBA049@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Draft minutes from the DRINKS design team call (2/22) 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, 22 Feb 2012 17:23:10 -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 2/22/2012, 10:00a-11:10a (Eastern)/8:00a-9:10a (Mountain) =20 Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Vikas Bhatia - Dean Willis - Jeremy Barkan - Ken Cartwright - Sumanth Channabasappa=20 Apologies: - Alexander Mayrhofer - David Schwartz - Syed Ali ACTION ITEMS UPDATE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General ------- - [Ken, Vikas] Send a recommendation related to the representation of the S= PID - [WG] Make a decision around the peering offer/accept; see discussion belo= w Framework document ------------------ AI-1/ Address Diagram Inconsistencies (Vikas) AI-2/ Investigate Route group offer generalization (David) AI-3/ Propose text about structure of non-numeric PI (Ken, Vikas) (Original= ly listed as "Decide on type of CoR identifier) AI-4/ TNType to RteRecRefType pointer: reconsider (David) AI-5/ Remove priority from RteRecBaseType (Vikas) AI-6/ Also add isinservice flag on RteRecBaseType (Ken, David) ("Define 'service' in the base route rec type was considered obsolete) AI-7/ Move up "ttl" field to base route rec type (Vikas) AI-8/ Reconsider "extension" options with new info (David) AI-9/ Consider adding "service" field to Egress Route (David) AI-10/ Discuss on mailing list how registry handles batches (Jeremy) AI-11/ Review Security Cons section (All) AI-12/ Organize early expert review of Security Cons section (Chairs) AI-13/ Clarify bulk operations and the DOS threat; also allow for the reje= ction of bulk operations based on criteria such as size limitations, and a = generic mechanism to return the reason in the response=20 SOAP document ------------- AI-13/ Clarify/remove definition of transaction id type (to "Token"), or re= move definition from here (Vikas) AI-14/ Evaluate whether to expand "Dtl" and make Type names consistent (Vik= as) AI-15/ Add max length to result code/message definition (Vikas) AI-16/ Clarify behaviour/expiration of offers, include a lifecycle Diagram?= (Alex, David) AI-17/ Internationalization/Comparison Ops (Alex) AI-18/ Ensure internal consistency on terminology and structure (David) AI-19/ Clarify uniqueness of object-type names (Vikas) AGENDA =3D=3D=3D=3D=3D=3D 1/ Discuss follow-up from interim 2/ Next Steps NOTES =3D=3D=3D=3D=3D 1/ Discuss comments on the documents - We discussed comments shared by David Schwartz on the list; see:=20 http://www.ietf.org/mail-archive/web/drinks/current/msg01118.html + We spent quite a bit of time on the peering offer/accept. David's asse= rtion that there are a few use cases that are not currently addressed were acknowledged, since the protocol was not meant to address everything.= =20 > (Jeremy) made the observation that the protocol does a good job with= registry provisioning (i.e., the transactional aspect), but lacks enough clarity around peering (offer/accept) > (Dean) suggested that perhaps we should stick to what the protocol d= oes best, and defer what it doesn't to an external extension or a different protocol (outside of the current scope) > (Ken) indicated that while some of the use cases can be addressed, w= e would need to flesh them out more and this would take time and effort.=20 He was OK with removing the peering offer/accept, with the caveat th= at this will render the offer/accept non-standard and perhaps unaddressed (in a standard manner) for a long time. > (Vikas) was in favor of removing the current peering offer/accept. =20 > (Sumanth) detailed a few options: A) Do nothing. (But this does not address the comment.) B) Leave the peering offer/accept in the document, but ensure it is = extensible for future work. C) Remove the peering offer/accept and consider it out of scope > In general, there was agreement with B) - we need to discuss this on= the list and get WG consensus since we are not going to be addressing a use case we agreed to. We should also consider the caveat from Ken= while making this decision.=20 - Sumanth requested that we highlight this on the DRINKS mailing lis= t + Towards the end we discussed the suggestion around batch request 6. Batch request should be an implicit subscription. New method NOTIF= Y should be sent when processing is done including summary of the operation= .=20 =20 - (Jeremy, Dean) clarified that the intention was to have a response = indicating 'I received the batch request' and a subsequent notification whe= n the processing has been completed.=20 - (Ken) clarified that, currently, the operations are expected to be = synchronous. He also added that batch provisioning was explicitly left out = of scope, based on previous discussions.=20 - (Sumanth) confirmed, and added that there was a call for batch prov= isioning proposals at one point in time. In the absence of such proposals we decided to keep it out of scope.=20 =20 - (Dean, Vikas, Ken, Sumanth) then discussed the possibility of DOS a= ttacks and if we should say or do anything, e.g., limit the number of reque= sts - (Ken) highlighted that DOS attacks are true of various API calls an= d that it is not unique - (Sumanth) indicated, and recommended, that we address it as a secur= ity threat and provide a mechanism for rejection with a reason (e.g., when = the number of requests is too high). - (Dean) indicated that perhaps we could have a query mechanism to id= entify the number of supported transactions. - (Sumanth) suggested that one could also have a response mechanism w= ithin which such a limit is indicated (in lieu of a query mechanism) - (Dean) agreed that this was a possibility, provided it was clear en= ough - (Vikas) indicated that the reason such as mechanism is usually unsp= ecified is because there are multiple ways to do it (e.g., byte size, # of = transactions)=20 etc. - (Suamnth) agreed; now, that's the criteria for rejection, which can= be left unspecified. The proposal is to provide a mechanism to convey this= limitation so that the client can be made aware.=20 - (Vikas) agreed. =20 - We also discussed the remaining action items and came to the followin= g conclusions =20 Action items currently exist for the following: 3. IsInService should be attribute of routeRecord as well 4. Need to have a URI type as a PI or else LUF resolution (URI) cannot = be fed back into the system for LRF resolution. 7. Diagram in SPPF doc should be cleaned up=20 Need more clarification around: 5. Need to have in introduction option to just go identifier-> LRF with= out first LUF querying The note-taker (Sumanth) missed the conversation around the following: 2. EgressRoute is just a special case of a RouteRule and should be made= more general. This is needed as well to address the route manipulation asp= ect of sorceIdent flag. (Design team members, please clarify resolution on the mailing list.) 2/ Next Steps - (Authors) to continue incorporating comments - (Everyone) make progress on the action items From dschwartz@xconnect.net Wed Feb 22 10:31:15 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 EA70421F86E2 for ; Wed, 22 Feb 2012 10:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0DsEEJx889c for ; Wed, 22 Feb 2012 10:31:15 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 32CCD21F85FD for ; Wed, 22 Feb 2012 10:31:09 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 22 Feb 2012 20:31:07 +0200 From: David Schwartz To: Dean Willis Date: Wed, 22 Feb 2012 20:31:09 +0200 Thread-Topic: [drinks] Some general comments on SPPF Thread-Index: AczxkCRiK0v2MHDwQJ+IbcW9A0blog== Message-ID: <0293475F-09E7-4EBB-BEAF-7AA2F42E5DFC@xconnect.net> References: <5AF54DE0-9946-4FAE-96DB-530BC979961D@xconnect.net> <0EA3C3A2-1E7C-438E-B08C-B1E393E719D0@softarmor.com> In-Reply-To: <0EA3C3A2-1E7C-438E-B08C-B1E393E719D0@softarmor.com> 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_0293475F09E74EBBBEAF7AA2F42E5DFCxconnectnet_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Some general comments on SPPF 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, 22 Feb 2012 18:31:16 -0000 --_000_0293475F09E74EBBBEAF7AA2F42E5DFCxconnectnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dean This is taken from page 5 of the draft=85 "A "terminating" SIP Service Provider (SSP) provisions SED into the registry to be selectively shared with other peer SSPs. Subsequently, a registry may distribute the provisioned data into local data repositories used for look-up queries (identifier -> URI) or for lookup and location resolution (identifier -> URI -> ingress SBE of terminating SSP). In some cases, the registry may additionally offer a central query resolution service (not shown in the above figure)." The part I was referring to was where it says used for look-up queries (id= entifier -> URI) or for lookup and location resolution (identifier -> URI -= > ingress SBE of terminating SSP) imho there is a third option =85 identifier -> ingress SBE i.e. identifier-= >LRF directly without first looking up LUF. :D On Feb 22, 2012, at 3:57 PM, Dean Willis wrote: On Feb 22, 2012, at 7:13 AM, David Schwartz wrote: 5. Need to have in introduction option to just go identifier-> LRF without = first LUF querying Can you clarify this one? I'm not exactly sure what you are talking about. -- Dean --_000_0293475F09E74EBBBEAF7AA2F42E5DFCxconnectnet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dean

This is taken from page 5 of the draft=85

"A "terminating" SIP Service Provider (SSP) provisions SED into the
   registry to be selectively shared with other p=
eer SSPs.
   Subsequently, a registry may distribute the provisioned data into
   local data repositories used for look-up queries (identifier -> URI)
   or for lookup and location resolution (identifier -> URI -> ingres=
s
   SBE of terminating SSP).  In some cases, the registry may
   additionally offer a central query resolution service (not shown in
   the above figure)."
The part I was referring to was where =
it says  used for look-up queries (identifier -> URI) or for lookup and location resolution (identifier -> URI=
 -> ingress SBE of terminating SSP)
<=
br>
imho there is a thir=
d option =85 identifier -> ingress SBE i.e. identifier->LRF directly without first l=
ooking up LUF.

=
:D
On Feb 22, 2012, at 3:57 PM, Dean Wil= lis wrote:


On Feb 22, 2012, at 7:13 = AM, David Schwartz wrote:

5. Need t= o have in introduction option to just go identifier-> LRF without first = LUF querying
<= br>
Can you clarify this one? I'm not exactly sure what you are talking= about.

--
Dean


= --_000_0293475F09E74EBBBEAF7AA2F42E5DFCxconnectnet_-- From dean.willis@softarmor.com Thu Feb 23 10:25:39 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54F221F8820 for ; Thu, 23 Feb 2012 10:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 h8mmiWHg3GId for ; Thu, 23 Feb 2012 10:25:38 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 042F321F875C for ; Thu, 23 Feb 2012 10:25:37 -0800 (PST) Received: by ggnq2 with SMTP id q2so863169ggn.31 for ; Thu, 23 Feb 2012 10:25:25 -0800 (PST) Received-SPF: pass (google.com: domain of dean.willis@softarmor.com designates 10.236.76.198 as permitted sender) client-ip=10.236.76.198; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dean.willis@softarmor.com designates 10.236.76.198 as permitted sender) smtp.mail=dean.willis@softarmor.com Received: from mr.google.com ([10.236.76.198]) by 10.236.76.198 with SMTP id b46mr5004090yhe.25.1330021525833 (num_hops = 1); Thu, 23 Feb 2012 10:25:25 -0800 (PST) Received: by 10.236.76.198 with SMTP id b46mr4037804yhe.25.1330021525761; Thu, 23 Feb 2012 10:25:25 -0800 (PST) Received: from [192.168.2.124] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id g23sm3446347ann.9.2012.02.23.10.25.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 10:25:24 -0800 (PST) References: <5AF54DE0-9946-4FAE-96DB-530BC979961D@xconnect.net> <0EA3C3A2-1E7C-438E-B08C-B1E393E719D0@softarmor.com> <0293475F-09E7-4EBB-BEAF-7AA2F42E5DFC@xconnect.net> In-Reply-To: <0293475F-09E7-4EBB-BEAF-7AA2F42E5DFC@xconnect.net> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23--472994724 Message-Id: <6D18ABBA-E3FE-4E76-87D4-935152755685@softarmor.com> From: Dean Willis Date: Thu, 23 Feb 2012 12:25:23 -0600 To: David Schwartz X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQk4IHaii43v38gFtR0663UiN6GHQB8JTEomHq4IzaMRPfhxfZLxTeTzXRfcvJf3S3Jgo0/6 Cc: "drinks@ietf.org" Subject: Re: [drinks] Some general comments on SPPF 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, 23 Feb 2012 18:25:40 -0000 --Apple-Mail-23--472994724 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 22, 2012, at 12:31 PM, David Schwartz wrote: > Hi Dean >=20 > This is taken from page 5 of the draft=85 >=20 > "A "terminating" SIP Service Provider (SSP) provisions SED into the > registry to be selectively shared with other peer SSPs. > Subsequently, a registry may distribute the provisioned data into > local data repositories used for look-up queries (identifier -> = URI) > or for lookup and location resolution (identifier -> URI -> ingress > SBE of terminating SSP). In some cases, the registry may > additionally offer a central query resolution service (not shown in > the above figure)." > The part I was referring to was where it says used for look-up = queries (identifier -> URI) or for lookup and location resolution = (identifier -> URI -> ingress SBE of terminating SSP) >=20 > imho there is a third option =85 identifier -> ingress SBE i.e. = identifier->LRF directly without first looking up LUF. But isn't that the same as identifier -> URI where the URI identifies = the ingress SBE of the terminating SSP? -- Dean --Apple-Mail-23--472994724 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi = Dean

This is taken from page 5 of the = draft=85

"A "terminating" SIP = Service Provider (SSP) provisions SED into the
   registry to be selectively shared with other peer =
SSPs.
   Subsequently, a registry may distribute the provisioned data into
   local data repositories used for look-up queries (identifier -> =
URI)
   or for lookup and location resolution (identifier -> URI -> =
ingress
   SBE of terminating SSP).  In some cases, the registry may
   additionally offer a central query resolution service (not shown in
   the above figure)."
The part I was =
referring to was where it says  used for look-up =
queries (identifier -> URI) or for lookup and =
location resolution (identifier -> URI -> ingress SBE of terminating SSP)

imho there is =
a third option =85 identifier -> ingress SBE i.e. =
identifier->LRF directly without first looking up =
LUF.

But = isn't that the same as identifier -> URI where the URI identifies the = ingress SBE of the terminating = SSP?


--
Dean

= --Apple-Mail-23--472994724-- From vbhatia@tnsi.com Fri Feb 24 15:15:15 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 9A6DE21F8679 for ; Fri, 24 Feb 2012 15:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAT-d6zrlC-Y for ; Fri, 24 Feb 2012 15:15:12 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC5921F8677 for ; Fri, 24 Feb 2012 15:15:10 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EANkZSE+sEQfn/2dsb2JhbABEglGxV4FzAQEFJwZcAgEIDgMEAQEOGgcyFAkIAQEEARIIvyeJeIMEEQQCCQYCAgMDRh2EWgIDBQUCAhYHDHSCWWMEiE+feYE+ X-IronPort-AV: E=Sophos;i="4.73,478,1325462400"; d="scan'208,217";a="932351" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 24 Feb 2012 23:15:09 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 24 Feb 2012 18:15:09 -0500 From: "Bhatia, Vikas" To: David Schwartz , "drinks@ietf.org" Date: Fri, 24 Feb 2012 18:15:06 -0500 Thread-Topic: Some general comments on SPPF Thread-Index: AczxYsmI1uzXOmFcTLyJi4XlsZC6FgB4l1iA Message-ID: References: <5AF54DE0-9946-4FAE-96DB-530BC979961D@xconnect.net> In-Reply-To: <5AF54DE0-9946-4FAE-96DB-530BC979961D@xconnect.net> 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_B4254E341B54864B92D28BC2138A9DC301E353862BTNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Some general comments on SPPF 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, 24 Feb 2012 23:15:15 -0000 --_000_B4254E341B54864B92D28BC2138A9DC301E353862BTNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see below w.r.t #1 (follow up from discussion in last design call)..= . Thanks, Vikas From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= David Schwartz Sent: Wednesday, February 22, 2012 8:06 AM To: drinks@ietf.org Subject: [drinks] Some general comments on SPPF Here are some additional comments to consider... 1. After spending considerable time analyzing this I am pretty convinced th= at peering should be completely removed from SPPF. I came to this conclusio= n afar going through some of the many peering scenarios and realizing that = the current model supports a small subset of the cases. Many real world use= cases are not addressed and the existing mechanism is simply incomplete. I= spent many cycles trying to fix prior to just giving up - Here are just so= me of the sample use cases that lead to this conclusion: * Sharing LUF in an open manner (with whomever wants it) using current mech= anism (semantically, no peeringOrgs means NO sharing of rteGrp) * peeringOrg would like to request LRF from org showing in its LUF that it = has information for a PI [VB:] David, can you please elaborate on what you mean? * Excluding a peer from receiving rteGrp information without knowing all pa= rties that are ALLOWED to receive route information [VB:] After thinking some more about this after the last design call, I thi= nk we probably need to spend more time on this before we choose the directi= on. The cases listed here are an extension to the peering concept but that = does not necessarily mean that the current protocol cannot be extended in f= uture to meet these cases. The reason I say that is because cases listed he= re are not strictly offer/accept cases. The current offer key (RteGrpOfferK= ey) is strictly for offer/accept mechanisms. Like sharing RG in an open man= ner, means we want to have a RG that is like an 'open' RG. Anyone intereste= d can use it. There is no strict offer or accept here. It is available for = everyone. So an extension to the protocol *may* decide to have a RG Type of= of 'open' RG. Similarly for the case of where a RG is 'open' except for = a certain peer is also not a offer/accept case. It's a case of Route that i= s 'open' to everyone except, so in this case the extension *may* add a attr= ibute that represents a list of Org Ids that excluded from using the RG. The point imho is that these cases do not necessarily present enough to jus= tify that Peering, pertaining to offer/accept mechanism, should be taken ou= t of the protocol. To alleviate some concerns. we can make the RG as a abst= ract base type and provide one concrete definition (the current one) of the= RG. The other definitions of a RG (as pertaining to these new cases) will = be extensible. Just some thoughts to consider for the group. IMHO an orthogonal peering model is required that can sit on top of SPPF. 2. EgressRoute is just a special case of a RouteRule and should be made mor= e general. This is needed as well to address the route manipulation aspect = of sorceIdent flag. 3. IsInService should be attribute of routeRecord as well 4. Need to have a URI type as a PI or else LUF resolution (URI) cannot be f= ed back into the system for LRF resolution. 5. Need to have in introduction option to just go identifier-> LRF without = first LUF querying 6. Batch request should be an implicit subscription. New method NOTIFY shou= ld be sent when processing is done including summary of the operation. 7. Diagram in SPPF doc should be cleaned up * remove extensions * add missing arrows (TN and RR) * add [0..n] on relevant arrows ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_B4254E341B54864B92D28BC2138A9DC301E353862BTNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see below w.r.t #1 (follow up from discussion in last d= esign call)…

 

Thanks,

Vikas

 

From: drinks-b= ounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of David Schwartz
Sent: Wednesday, February 22, 2012 8:06 AM
To: drinks@ietf.org
Subject: [drinks] Some general comments on SPPF

 

Here are some additional comments to = consider...

 

1. After spending considerable time a= nalyzing this I am pretty convinced that peering should be completely remov= ed from SPPF. I came to this conclusion afar going through some of the many peering scenarios and realizing that the current model su= pports a small subset of the cases. Many real world use cases are not addre= ssed and the existing mechanism is simply incomplete. I spent many cyc= les trying to fix prior to just giving up - Here are just some of the sample use cases that lead to this conclusi= on:

 

* Sharing LUF in an open manner (with= whomever wants it) using current mechanism (semantically, no peeringOrgs m= eans NO sharing of rteGrp)

* peeringOrg would like to request LR= F from org showing in its LUF that it has information for a PI

[VB:] David, can you please elaborate on what you mean?

 

* Excluding a peer from receiving rte= Grp information without knowing all parties that are ALLOWED to receive rou= te information

 

 

[VB:] After thinking some more about this after the last design call, I th= ink we probably need to spend more time on this before we choose the direct= ion. The cases listed here are an extension to the peering concept but that does not necessaril= y mean that the current protocol cannot be extended in future to meet these= cases. The reason I say that is because cases listed here are not strictly= offer/accept cases. The current offer key (RteGrpOfferKey) is strictly for offer/accept mechanisms. Like s= haring RG in an open manner, means we want to have a RG that is like an = 216;open’ RG. Anyone interested can use it. There is no strict offer = or accept here. It is available for everyone. So an extension to the protocol *may* decide to have a RG Type of o= f ‘open’ RG.   Similarly for the case of where a RG i= s ‘open’ except for a certain peer is also not a offer/accept c= ase. It’s a case of Route that is ‘open’ to everyone exce= pt, so in this case the extension *may* add a attribute that represents a lis= t of Org Ids that excluded from using the RG.  

 

The point imho is that these cases do not necessa= rily present enough to justify that Peering, pertaining to offer/accept mec= hanism, should be taken out of the protocol. To alleviate some concerns. we= can make the RG as a abstract base type and provide one concrete definition (the current one) of the RG. The = other definitions of a RG (as pertaining to these new cases) will be extens= ible. Just some thoughts to consider for the group.

 

 

IMHO an orthogonal peering model is r= equired that can sit on top of SPPF. 

 

2. EgressRoute is just a special case= of a RouteRule and should be made more general. This is needed as well to = address the route manipulation aspect of sorceIdent flag.=

 

3. IsInService should be attribute of= routeRecord as well

 

4. Need to have a URI type as a PI or= else LUF resolution (URI) cannot be fed back into the system for LRF resol= ution.

 

5. Need to have in introduction optio= n to just go identifier-> LRF without first LUF querying

 

6. Batch request should be an implici= t subscription. New method NOTIFY should be sent when processing is done in= cluding summary of the operation. 

 

7. Diagram in SPPF doc should be clea= ned up 

* remove extensions=

* add missing arrows (TN and RR)=

* add [0..n] on relevant arrows<= /o:p>


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_B4254E341B54864B92D28BC2138A9DC301E353862BTNSMAILNAwin2_-- From vbhatia@tnsi.com Tue Feb 28 06:48:41 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 DA3B421F863F for ; Tue, 28 Feb 2012 06:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.719, 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 xhZfp7kL-jf4 for ; Tue, 28 Feb 2012 06:48:41 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C87721F8637 for ; Tue, 28 Feb 2012 06:48:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAEboTE+sEQfn/2dsb2JhbABCtG6BcwEBAQQBAQE3NAsMBAIBCBEEAQEBHgkHJwsUCQgCBAENBQiICblfBIl7gwUBDwYEBgYCBgMDAgoCDQkDCRkJAoRCCD4EBjEBGAYBGAGCSWMEiE+ffoE/ X-IronPort-AV: E=Sophos;i="4.73,496,1325462400"; d="scan'208";a="939477" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 28 Feb 2012 14:48:39 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 28 Feb 2012 09:48:39 -0500 From: "Bhatia, Vikas" To: "Hollenbeck, Scott" , Dean Willis Date: Tue, 28 Feb 2012 09:48:38 -0500 Thread-Topic: [drinks] TLS Client CertificateRequest? Thread-Index: AQHM5nH2W6gwl4O9eEqyXBtiou8dHZYzSJ7QgB6RDRA= Message-ID: References: <831693C2CDA2E849A7D7A712B24E257F0D595A08@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <3D35AFB9-D8E1-4AF7-B483-F6DE35FEE6F2@softarmor.com> <831693C2CDA2E849A7D7A712B24E257F0D598DB4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D598DB4@BRN1WNEXMBX01.vcorp.ad.vrsn.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 Cc: "drinks@ietf.org" Subject: Re: [drinks] TLS Client CertificateRequest? 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, 28 Feb 2012 14:48:42 -0000 Hello Scott, Please provide the text that you would like to suggest pertaining to this a= spect of Security Considerations. Thanks, Vikas > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf > Of Hollenbeck, Scott > Sent: Wednesday, February 08, 2012 1:34 PM > To: Dean Willis > Cc: drinks@ietf.org > Subject: Re: [drinks] TLS Client CertificateRequest? > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Wednesday, February 08, 2012 9:57 AM > > To: Hollenbeck, Scott > > Cc: drinks@ietf.org > > Subject: Re: [drinks] TLS Client CertificateRequest? > > > > > > On Feb 1, 2012, at 12:29 PM, Hollenbeck, Scott wrote: > > > > > > Sections 5 and 10.1 of the protocol draft include text that > describes > > how these requirements will be met. I see MUSTs for HTTPS, but no > > mention of a need for the server to request a certificate from a > > client. Are servers required to send a TLS CertificateRequest message > > as part of the handshake protocol? The means is there, but it doesn't > > appear that the protocol includes a requirement for a server to > > authenticate a client at the TLS level. > > > > > > Nope. Basic or Digest authentication over HTTPS is considered good > > enough. There's no requirement for the client to have or present a > > cert. > > If that's the case, there's a risk of malicious clients consuming > server-side resources to the point of denying service to legitimate > clients. The risk should be identified in the security considerations > section, perhaps as an additional paragraph in section 10.2. I'll > suggest text if it helps. > > Scott > _______________________________________________ > 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 shollenbeck@verisign.com Tue Feb 28 08:06:01 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 72E5A21F86DE for ; Tue, 28 Feb 2012 08:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zANxabH9BSON for ; Tue, 28 Feb 2012 08:06:00 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8A321F869A for ; Tue, 28 Feb 2012 08:05:58 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKT0z7ZAgssjm1XI8HRrV1b/dqKjUJgBnL@postini.com; Tue, 28 Feb 2012 08:06:00 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q1SG5u9J018916; Tue, 28 Feb 2012 11:05:56 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 11:05:49 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Tue, 28 Feb 2012 11:05:42 -0500 From: "Hollenbeck, Scott" To: "Bhatia, Vikas" , Dean Willis Thread-Topic: [drinks] TLS Client CertificateRequest? Thread-Index: AQHM5nH2W6gwl4O9eEqyXBtiou8dHZYzSJ7QgB6RDRCAALdsIA== Date: Tue, 28 Feb 2012 16:05:49 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D5B50AB@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F0D595A08@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <3D35AFB9-D8E1-4AF7-B483-F6DE35FEE6F2@softarmor.com> <831693C2CDA2E849A7D7A712B24E257F0D598DB4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 16:05:49.0161 (UTC) FILETIME=[D6553D90:01CCF632] Cc: "drinks@ietf.org" Subject: Re: [drinks] TLS Client CertificateRequest? 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, 28 Feb 2012 16:06:01 -0000 Proposed text for section 10.2: Sections 5 and 10.1 describe requirements for HTTPS support using TLS. The = TLS handshake protocol requires certificate-based server authentication for= all key exchange methods defined in RFC 5246 except DH_anon. Non-anonymous= TLS servers can optionally request a certificate from a TLS client; that o= ption is not a requirement for this protocol. This presents a denial of ser= vice risk in which unauthenticated clients can consume server CPU resources= by creating TLS sessions. The risk is increased if the server supports cli= ent-initiated renegotiation. This risk can be mitigated by disabling client= -initiated renegotiation on the server and by ensuring that other means (su= ch as firewall access control lists) are used to restrict unauthenticated c= lient access to servers. I'm open to wordsmithing. Scott > -----Original Message----- > From: Bhatia, Vikas [mailto:vbhatia@tnsi.com] > Sent: Tuesday, February 28, 2012 9:49 AM > To: Hollenbeck, Scott; Dean Willis > Cc: drinks@ietf.org > Subject: RE: [drinks] TLS Client CertificateRequest? >=20 > Hello Scott, >=20 > Please provide the text that you would like to suggest pertaining to > this aspect of Security Considerations. >=20 > Thanks, > Vikas >=20 >=20 >=20 > > -----Original Message----- > > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf > > Of Hollenbeck, Scott > > Sent: Wednesday, February 08, 2012 1:34 PM > > To: Dean Willis > > Cc: drinks@ietf.org > > Subject: Re: [drinks] TLS Client CertificateRequest? > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Wednesday, February 08, 2012 9:57 AM > > > To: Hollenbeck, Scott > > > Cc: drinks@ietf.org > > > Subject: Re: [drinks] TLS Client CertificateRequest? > > > > > > > > > On Feb 1, 2012, at 12:29 PM, Hollenbeck, Scott wrote: > > > > > > > > Sections 5 and 10.1 of the protocol draft include text that > > describes > > > how these requirements will be met. I see MUSTs for HTTPS, but no > > > mention of a need for the server to request a certificate from a > > > client. Are servers required to send a TLS CertificateRequest > message > > > as part of the handshake protocol? The means is there, but it > doesn't > > > appear that the protocol includes a requirement for a server to > > > authenticate a client at the TLS level. > > > > > > > > > Nope. Basic or Digest authentication over HTTPS is considered good > > > enough. There's no requirement for the client to have or present a > > > cert. > > > > If that's the case, there's a risk of malicious clients consuming > > server-side resources to the point of denying service to legitimate > > clients. The risk should be identified in the security considerations > > section, perhaps as an additional paragraph in section 10.2. I'll > > suggest text if it helps. > > > > Scott > > _______________________________________________ > > drinks mailing list > > drinks@ietf.org > > https://www.ietf.org/mailman/listinfo/drinks >=20 > This e-mail message is for the sole use of the intended recipient(s)and > may > contain confidential and privileged information of Transaction Network > Services. > Any unauthorised review, use, disclosure or distribution is prohibited. > If you > are not the intended recipient, please contact the sender by reply e- > mail and destroy all copies of the original message. From alexander.mayrhofer@nic.at Wed Feb 29 03:08:29 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24021F88F2 for ; Wed, 29 Feb 2012 03:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.042 X-Spam-Level: X-Spam-Status: No, score=-9.042 tagged_above=-999 required=5 tests=[AWL=0.388, 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 WGzBsYsHD6sX for ; Wed, 29 Feb 2012 03:08:28 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2440E21F88D6 for ; Wed, 29 Feb 2012 03:08:27 -0800 (PST) Received: from nics-mail.sbg.nic.at ([10.17.175.2]) by mail.sbg.nic.at with XWall v3.47 ; Wed, 29 Feb 2012 12:08:25 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 29 Feb 2012 12:08:24 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B721CD7@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated "internationalization & comparison" proposal. Thread-Index: Acz2zgZvYF0+Rz0uT6y6e/4egSmhaQ== From: "Alexander Mayrhofer" To: X-XWALL-BCKS: auto Subject: [drinks] Updated "internationalization & comparison" proposal. 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, 29 Feb 2012 11:08:29 -0000 Hi, in light of my action item AI-17 (see design team meeting minutes), here's an updated proposal regarding internationalization and comparison. (I do propose to add the "Internationalization" section between section 8 and 9 (XML/Security cons) of the framework document - i think we can keep it reasonably short): --- snip --- 9. Internationalization 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 4646, 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 --- For the "comparison" discussion, i suggest to add the following text as a new sub-section to section 5 of the framework document (for example, between current 5.2 and 5.3): --- snip --- 5.3 Comparison Operations The protocol contains two categories of elements. The first category, called "blobs" for the purpose of this document,=20 contains data that is transported by means of that protocol, but is neither used to identify objects, or to refer between objects. The other category is called "identifier", and is either used to address an object, or to refer between objects. The following elements are "identifiers": * rant * rar * dgName * rgName * egrRteName All other elements contained in the protocol fall under the "blobs" category. For "identifiers", the following rules apply: * Identifiers are case insensitive, and MUST use Unicode Normalization Form C (NFC) in comparison and mapping operations * Identifiers MUST be limited to contain characters from the following Unicode General Categories only: Lu, Ll, Lm, Lo, Mn, Mc, Me, Nd, Nl, No, Pc, Pd, Ps, Pe, Pi, Pf, Po, Zs * The Registry MUST store such identifiers in their lower case mapping, and MUST correctly map upper case representations of identifiers to their lower case equivalent in comparison operations * Clients SHOULD lowercase identifiers before sending them to the Registry. If elements of the "blob" category are ever to be compared, byte-wise comparison MUST be used. --- snip --- (Note: Since i am not a unicode expert, the list of Character Categories might need some review...) Please comment on the new proposal. Alex From vbhatia@tnsi.com Wed Feb 29 06:48:32 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 5DA7A21F86FA for ; Wed, 29 Feb 2012 06:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.629, 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 CUaRXvvMeC3D for ; Wed, 29 Feb 2012 06:48:31 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD7521F86F6 for ; Wed, 29 Feb 2012 06:48:30 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAOs5Tk+sEQfn/2dsb2JhbAA6CrRngXcBAQEDAQEBARoKEzEDEAcEAgEZBAEBDhEJBycLFAkIAQEEEwgBh3oQuXKJeQUEgngGAgcHAgEEBwkCBAIGAwMCCgINCQMJGYRNCD4EBjEBDQcEBhqCSWMEiE+ff4E3Bw X-IronPort-AV: E=Sophos;i="4.73,502,1325462400"; d="scan'208";a="943964" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 29 Feb 2012 14:48:29 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 29 Feb 2012 09:48:29 -0500 From: "Bhatia, Vikas" To: "drinks@ietf.org" Date: Wed, 29 Feb 2012 09:48:27 -0500 Thread-Topic: non numeric PI Thread-Index: AczxhZ9+Q6EESoPfSrO+uvRzE8LwYwE6EjJg Message-ID: References: <76AC5FEF83F1E64491446437EA81A61F8F2BCBA049@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F8F2BCBA049@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 Subject: [drinks] non numeric PI 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, 29 Feb 2012 14:48:32 -0000 Hi, With respect to AI-3 (Propose text about structure of non-numeric PI - see = design team meeting minutes) below is the proposal: Proposed structure for non-numeric PI: The key definition in the protocol shall be as follows: We currently have a "URIType" for RRs - so to avoid namespace conflict and = for clarity the name of "URIType" shall change to "URIRteRecType" Let me know if anyone has comments/suggestions. Thanks, Vikas > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf > Of Sumanth Channabasappa > Sent: Wednesday, February 22, 2012 12:16 PM > To: drinks@ietf.org > Subject: [drinks] Draft minutes from the DRINKS design team call (2/22) > > IETF DRINKS DESIGN TEAM CALL > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 2/22/2012, 10:00a-11:10a (Eastern)/8:00a-9:10a (Mountain) > > Participants > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - Vikas Bhatia > - Dean Willis > - Jeremy Barkan > - Ken Cartwright > - Sumanth Channabasappa > > Apologies: > - Alexander Mayrhofer > - David Schwartz > - Syed Ali > > > ACTION ITEMS UPDATE > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > General > ------- > - [Ken, Vikas] Send a recommendation related to the representation of > the SPID > - [WG] Make a decision around the peering offer/accept; see discussion > below > > > Framework document > ------------------ > AI-1/ Address Diagram Inconsistencies (Vikas) > AI-2/ Investigate Route group offer generalization (David) > AI-3/ Propose text about structure of non-numeric PI (Ken, Vikas) > (Originally listed as "Decide on type of CoR identifier) > AI-4/ TNType to RteRecRefType pointer: reconsider (David) > AI-5/ Remove priority from RteRecBaseType (Vikas) > AI-6/ Also add isinservice flag on RteRecBaseType (Ken, David) > ("Define 'service' in the base route rec type was considered obsolete) > AI-7/ Move up "ttl" field to base route rec type (Vikas) > AI-8/ Reconsider "extension" options with new info (David) > AI-9/ Consider adding "service" field to Egress Route (David) > AI-10/ Discuss on mailing list how registry handles batches (Jeremy) > AI-11/ Review Security Cons section (All) > AI-12/ Organize early expert review of Security Cons section (Chairs) > AI-13/ Clarify bulk operations and the DOS threat; also allow for the > rejection of bulk operations based on criteria such as size limitations, > and a generic mechanism to return the reason in the response > > SOAP document > ------------- > AI-13/ Clarify/remove definition of transaction id type (to "Token"), or > remove definition from here (Vikas) > AI-14/ Evaluate whether to expand "Dtl" and make Type names consistent > (Vikas) > AI-15/ Add max length to result code/message definition (Vikas) > AI-16/ Clarify behaviour/expiration of offers, include a lifecycle > Diagram? (Alex, David) > AI-17/ Internationalization/Comparison Ops (Alex) > AI-18/ Ensure internal consistency on terminology and structure (David) > AI-19/ Clarify uniqueness of object-type names (Vikas) > > > > AGENDA > =3D=3D=3D=3D=3D=3D > 1/ Discuss follow-up from interim > 2/ Next Steps > > > NOTES > =3D=3D=3D=3D=3D > 1/ Discuss comments on the documents > - We discussed comments shared by David Schwartz on the list; see: > http://www.ietf.org/mail-archive/web/drinks/current/msg01118.html > > + We spent quite a bit of time on the peering offer/accept. David's > assertion that there are a few use cases that are not currently > addressed were > acknowledged, since the protocol was not meant to address > everything. > > (Jeremy) made the observation that the protocol does a good job > with registry provisioning (i.e., the transactional aspect), but lacks > enough > clarity around peering (offer/accept) > > (Dean) suggested that perhaps we should stick to what the > protocol does best, and defer what it doesn't to an external extension > or a different > protocol (outside of the current scope) > > (Ken) indicated that while some of the use cases can be > addressed, we would need to flesh them out more and this would take time > and effort. > He was OK with removing the peering offer/accept, with the caveat > that this will render the offer/accept non-standard and perhaps > unaddressed > (in a standard manner) for a long time. > > (Vikas) was in favor of removing the current peering > offer/accept. > > > (Sumanth) detailed a few options: > A) Do nothing. (But this does not address the comment.) > B) Leave the peering offer/accept in the document, but ensure it > is extensible for future work. > C) Remove the peering offer/accept and consider it out of scope > > > > In general, there was agreement with B) - we need to discuss this > on the list and get WG consensus since we are not going to be addressing > a use case we agreed to. We should also consider the caveat from > Ken while making this decision. > - Sumanth requested that we highlight this on the DRINKS mailing > list > > > + Towards the end we discussed the suggestion around batch request > 6. Batch request should be an implicit subscription. New method > NOTIFY should be sent when processing is done including summary of the > operation. > > - (Jeremy, Dean) clarified that the intention was to have a > response indicating 'I received the batch request' and a subsequent > notification when > the processing has been completed. > - (Ken) clarified that, currently, the operations are expected to > be synchronous. He also added that batch provisioning was explicitly > left out of > scope, based on previous discussions. > - (Sumanth) confirmed, and added that there was a call for batch > provisioning proposals at one point in time. In the absence of such > proposals > we decided to keep it out of scope. > > > - (Dean, Vikas, Ken, Sumanth) then discussed the possibility of > DOS attacks and if we should say or do anything, e.g., limit the number > of requests > - (Ken) highlighted that DOS attacks are true of various API calls > and that it is not unique > - (Sumanth) indicated, and recommended, that we address it as a > security threat and provide a mechanism for rejection with a reason > (e.g., when the > number of requests is too high). > - (Dean) indicated that perhaps we could have a query mechanism to > identify the number of supported transactions. > - (Sumanth) suggested that one could also have a response > mechanism within which such a limit is indicated (in lieu of a query > mechanism) > - (Dean) agreed that this was a possibility, provided it was clear > enough > - (Vikas) indicated that the reason such as mechanism is usually > unspecified is because there are multiple ways to do it (e.g., byte > size, # of transactions) > etc. > - (Suamnth) agreed; now, that's the criteria for rejection, which > can be left unspecified. The proposal is to provide a mechanism to > convey this limitation > so that the client can be made aware. > - (Vikas) agreed. > > > > - We also discussed the remaining action items and came to the > following conclusions > > Action items currently exist for the following: > 3. IsInService should be attribute of routeRecord as well > 4. Need to have a URI type as a PI or else LUF resolution (URI) > cannot be fed back into the system for LRF resolution. > 7. Diagram in SPPF doc should be cleaned up > > Need more clarification around: > 5. Need to have in introduction option to just go identifier-> LRF > without first LUF querying > > > > The note-taker (Sumanth) missed the conversation around the > following: > 2. EgressRoute is just a special case of a RouteRule and should be > made more general. This is needed as well to address the route > manipulation aspect of sorceIdent flag. > (Design team members, please clarify resolution on the mailing > list.) > > > 2/ Next Steps > - (Authors) to continue incorporating comments > - (Everyone) make progress on the action items > > > > _______________________________________________ > 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 dschwartz@xconnect.net Wed Feb 29 09:34:55 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 EF98621F8618 for ; Wed, 29 Feb 2012 09:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH3rQpsrMQEQ for ; Wed, 29 Feb 2012 09:34:53 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id A185C21F8625 for ; Wed, 29 Feb 2012 09:34:51 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 29 Feb 2012 19:34:49 +0200 From: David Schwartz To: "drinks@ietf.org" Date: Wed, 29 Feb 2012 19:34:48 +0200 Thread-Topic: Proposed changes to SPPF model Thread-Index: Acz3CG9vP1c06PSuSKat+skqwLLtsg== Message-ID: 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_E9661831D18D4E2493A1BC90DF1043F0xconnectnet_" MIME-Version: 1.0 Subject: [drinks] Proposed changes to SPPF model 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, 29 Feb 2012 17:34:55 -0000 --_000_E9661831D18D4E2493A1BC90DF1043F0xconnectnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In the current model, the relationship between the routes and the identitie= s (phone numbers) is encapsulated for all practical purposes in the RteGrp = object. It is for this reason that all aspects of peering as well are sitti= ng in the RG as this is the focal point of the resolution process. While it= is understandable why this is so (optimize the use case that is most commo= n --> grouping of numbers and their associated routing options) it is sever= ely limiting for other relationships that don't fit this profile (e.g. TNTy= pe to RteRec). As a result, if we want to associate a TNType with a RteRec = and yet retain all the properties associated with a RteGrp (e.g. peeringOrg= s) we need to either have a TNType - RG relationship (bypassing the DG and = kinda breaking the model), Have a DG with just 1 PI and risk countless usel= ess DGs just sitting around for this purpose, or associate the TNType direc= tly with the RteRec and lose the peering properties afforded by the RG conc= ept. What is proposed is a slight change to the model which abstracts the associ= ation between the RG and DG to a higher layer represented by RteElement and= IDElement respectively (both are abstract) extending the association capab= ilities to 1-1 relationships as well. Instead of the RteGrp containing the = association information, this information is relegated to the RteElement as= shown in the figure below=85 **************** * BasicObjType * **************** ^ ^ / \ / \ ************** ************** * IDElement *<-------------------* RteElement * ************** ************** ^ ^ ^ ^ / \ / \ / \ / \ *********** *********** *********** *********** * PubID *--->* DestGrp * * RteGrp *--->* RteRec * *********** *********** *********** *********** As can be seen in this figure, we still maintain the PI to DestGrp and RteG= rp to RteRec relationships as well the RteGrp to DestGrp relationship (albe= it indirectly). What we gain, however is a direct relationship between the = RteRec and the PI which we were missing in the previous model. I will send the actual XSD in a followup post for further clarity. :D --_000_E9661831D18D4E2493A1BC90DF1043F0xconnectnet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
In the current model, the relationsh= ip between the routes and the identities (phone numbers) is encapsulated fo= r all practical purposes in the RteGrp object. It is for this reason that a= ll aspects of peering as well are sitting in the RG as this is the focal po= int of the resolution process. While it is understandable why this is = so (optimize the use case that is most common --> grouping of numbers an= d their associated routing options) it is severely limiting for other relat= ionships that don't fit this profile (e.g. TNType to RteRec). As a result, = if we want to associate a TNType with a RteRec and yet retain all the prope= rties associated with a RteGrp (e.g. peeringOrgs) we need to either have a = TNType - RG relationship (bypassing the DG and kinda breaking the model), H= ave a DG with just 1 PI and risk countless useless DGs just sitting around = for this purpose, or associate the TNType directly with the RteRec and lose= the peering properties afforded by the RG concept.

=
What is pr= oposed is a slight change to the model which abstracts the association betw= een the RG and DG to a higher layer represented by RteElement and IDElement= respectively (both are abstract) extending the association capabilities to= 1-1 relationships as well. Instead of the RteGrp containing the associatio= n information, this information is relegated to the RteElement as shown in = the figure below=85

                  &nbs= p;                   *********= *******
                  =                   * BasicObjT= ype *
         &nbs= p;                     &n= bsp;   /                 = \
        = ;             **************    &nb= sp;               **************
 &n= bsp;                   * IDEle= ment  *<-------------------* RteElement *
      =               **************  &nbs= p;                 **************
&n= bsp;                     = ^         ^             &= nbsp;         ^         ^
 &nbs= p;                   /   =         \             &nb= sp;       /           \
   = ;                 /     &= nbsp;       \             &nbs= p;     /             \
   =             ***********    ********= ***        ***********    ***********
 &n= bsp;             *  PubID  *--->= * DestGrp *        * RteGrp  *--->* RteRec = ; *

As can be seen in this figure, we still maintain = the PI to DestGrp and RteGrp to RteRec relationships as well the RteGrp to = DestGrp relationship (albeit indirectly). What we gain, however is a direct= relationship between the RteRec and the PI which we were missing in the pr= evious model.

I will send the actual XSD in a followup post for further clarity.=

=
:D= --_000_E9661831D18D4E2493A1BC90DF1043F0xconnectnet_-- From dschwartz@xconnect.net Wed Feb 29 17:53:38 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 4EF9D21F85CD for ; Wed, 29 Feb 2012 17:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKXVeqg8Bhtd for ; Wed, 29 Feb 2012 17:53:37 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0678B21F85C5 for ; Wed, 29 Feb 2012 17:53:35 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Thu, 1 Mar 2012 03:53:30 +0200 From: David Schwartz To: "drinks@ietf.org" Date: Thu, 1 Mar 2012 03:53:29 +0200 Thread-Topic: [drinks] Proposed changes to SPPF model Thread-Index: Acz3ThmiLT2tA3s5ST+OB8D2Rb3ORA== Message-ID: <871FD974-0007-40C8-B807-AE27F73BF995@xconnect.net> 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: multipart/alternative; boundary="_000_871FD974000740C8B807AE27F73BF995xconnectnet_" MIME-Version: 1.0 Subject: Re: [drinks] Proposed changes to SPPF model 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, 01 Mar 2012 01:53:38 -0000 --_000_871FD974000740C8B807AE27F73BF995xconnectnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here are the XSD changes that go along with the previous email - thanks to = Mickael for writing this up. Only the modified types are shown below. This model allows us to define 4 t= ypes of associations (as opposed to 1 in the current model) between identif= iers and routes. These are: =B7 Public identifier - route record =B7 Public identifier - route group =B7 Destination group - route record =B7 Destination group - route group // only one t= hat is supported in current model The PubIdElemType is an abstract type that may represent a single public id= entifier or a group of public identifiers (namely a destination group). The base type of the PubIdType is now replaced by PubIdElemType. The base type of the DestGrpType is now replaced by PubIdElemType. The TNType is modified since a telephone number can now be associated to ro= utes through the association between PubIdElemType and RouteElemType. The o= ther types of public identifiers remain unchanged. The RouteElemType is an abstract type that may represent a single route rec= ord or a group of route records (namely a route group). You will note that = elements associated with peering as well as elements appearing in both RteR= ec and RteGrp (e.g. Priority) have been moved into this item from the RteGr= p The base type of RteRecType is now replaced by RouteElemType. The base type of the RteGrpType is now replaced by RouteElemType. On Feb 29, 2012, at 7:34 PM, David Schwartz wrote: In the current model, the relationship between the routes and the identitie= s (phone numbers) is encapsulated for all practical purposes in the RteGrp = object. It is for this reason that all aspects of peering as well are sitti= ng in the RG as this is the focal point of the resolution process. While it= is understandable why this is so (optimize the use case that is most commo= n --> grouping of numbers and their associated routing options) it is sever= ely limiting for other relationships that don't fit this profile (e.g. TNTy= pe to RteRec). As a result, if we want to associate a TNType with a RteRec = and yet retain all the properties associated with a RteGrp (e.g. peeringOrg= s) we need to either have a TNType - RG relationship (bypassing the DG and = kinda breaking the model), Have a DG with just 1 PI and risk countless usel= ess DGs just sitting around for this purpose, or associate the TNType direc= tly with the RteRec and lose the peering properties afforded by the RG conc= ept. What is proposed is a slight change to the model which abstracts the associ= ation between the RG and DG to a higher layer represented by RteElement and= IDElement respectively (both are abstract) extending the association capab= ilities to 1-1 relationships as well. Instead of the RteGrp containing the = association information, this information is relegated to the RteElement as= shown in the figure below=85 **************** * BasicObjType * **************** ^ ^ / \ / \ ************** ************** * IDElement *<-------------------* RteElement * ************** ************** ^ ^ ^ ^ / \ / \ / \ / \ *********** *********** *********** *********** * PubID *--->* DestGrp * * RteGrp *--->* RteRec * *********** *********** *********** *********** As can be seen in this figure, we still maintain the PI to DestGrp and RteG= rp to RteRec relationships as well the RteGrp to DestGrp relationship (albe= it indirectly). What we gain, however is a direct relationship between the = RteRec and the PI which we were missing in the previous model. I will send the actual XSD in a followup post for further clarity. --_000_871FD974000740C8B807AE27F73BF995xconnectnet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Here are the XSD changes that g= o along with the previous email - thanks to Mickael for writing this up.

Only the modified types are shown below. This model allows = us to define 4 types of associations (as opposed to 1 in the current model)= between identifiers and routes. These are:

=B7           = ;Public identifier - route record

=B7           Public identifi= er - route group

=B7  =          Destination group - rout= e record

= =B7   &= nbsp;       Destination group - route group=                 // only one that i= s supported in current model


The PubIdElemType is an abst= ract type that may represent a single public identifier or a group of publi= c identifiers (namely a destination group).
<complexType name=3D"PubIdEle= mType" abstract=3D"true">
   <complexContent>
  =      <extension base=3D"sppfb:BasicObjType"> = ;         
    &= nbsp;  </extension>
    </complexContent&g= t;
 

The base t= ype of the PubIdType is now replaced by PubIdElemType.

<complexType name=3D"PubIdTy= pe" abstract=3D"true">
    <complexContent>
 &nb= sp;     <extension base=3D"sppfb:PubIdElemType"><= /div>
&= nbsp;         <sequence>
 = ;            <ele= ment name=3D"dgName" type=3D"sppfb:ObjNameType" minOccurs=3D"0"/>
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal 'Courier New'; "> &= nbsp;        </sequence>
 &nbs= p;     </extension>
    </comple= xContent>
</complexType>
 
<= /div>

= The base type of the DestGrpType is now replaced by PubIdElemType= .

    <complexCo= ntent>
       <extension base=3D"sppfb:P= ubIdElemType">
          <= ;sequence>
          &n= bsp;  <element name=3D"dgName" type=3D"sppfb:ObjNameType"/>
 = ;         </sequence>
 &n= bsp;     </extension>
    </comp= lexContent>
</complexType>

  

The TNType is modified sin= ce a telephone number can now be associated to routes through the associati= on between PubIdElemType and RouteElemType. The other types o= f public identifiers remain unchanged.

<complexType name=3D"TNType">
&nbs= p;  <complexContent>
      <extension= base=3D"sppfb:PubIdType">
       &nbs= p; <sequence>
         &n= bsp;  <element name=3D"tn" type=3D"sppfb:NumberValType"/>
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal 'Courier New'; "> &= nbsp;          <element nam= e=3D"corInfo" type=3D"sppfb:CORInfoType" minOccurs=3D"0"/>
  &n= bsp;      </sequence>
    = ;  </extension>
   </complexContent>
</complexT= ype>
 

The = RouteElemType is an abstract type that may represent a single route = record or a group of route records (namely a route group). You will note th= at elements associated with peering as well as elements appearing in both R= teRec and RteGrp (e.g. Priority) have been moved into this item from the Rt= eGrp 

<complexType name=3D"RouteElemType" abstract=3D"true">
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal 'Courier New'; "> &= nbsp; <complexContent>
       <extens= ion base=3D"sppfb:BasicObjType">
      &nbs= p;   <sequence>
       &n= bsp;     <element name=3D"pubIdElements" type=3D"spp= fb:PubIdElemType"
         &nbs= p;             =     minOccurs=3D"0" maxOccurs=3D"unbounded"/>
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal 'Courier New'; ">
              <element n= ame=3D"peeringOrg" type=3D"sppfb:OrgIdType"
        &nbs= p;                  minOccurs= =3D"0" maxOccurs=3D"unbounded"/>
           = ;  <element name=3D"sourceIdent"
          =                  type=3D"sppfb= :SourceIdentType"
                &n= bsp;          minOccurs=3D"0" maxOccurs=3D"unbound= ed"/>
             <element name=3D= "isInSvc" type=3D"boolean"/>
            &n= bsp;<element name=3D"priority" type=3D"unsignedShort"/>
 &n= bsp;        </sequence>
  = ;     </extension>
   </complexConten= t>
 

The base type of RteRecType is now repl= aced by RouteElemType.
<complexType name=3D"RteRecType" abstract= =3D"true">
     <complexContent>
  &nb= sp;        <extension base=3D"sppfb:R= outeElemType">
         &nbs= p;     <sequence>
     &n= bsp;            = ; <element name=3D"rrName" type=3D"sppfb:ObjNameType"/>
  &n= bsp;            <= /sequence>
       </extension>
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal 'Courier New'; "> &= nbsp;   </complexContent>
</complexType>

 

The base type of th= e RteGrpType is now replaced by RouteElemType.
<complexType= name=3D"RteGrpType">
     <complexContent>
&nbs= p;          <extension base= =3D"sppfb:RouteElemType">
        = ;      <sequence>
    &nb= sp;            =   <element name=3D"rgName" type=3D"sppfb:ObjNameType"/>
 &nb= sp;            =      <element name=3D"rrRef" type=3D"sppfb:RteRecRef= Type"
         &= nbsp;         <element name=3D"e= xt" type=3D"sppfb:ExtAnyType"
       &nbs= p;            &= nbsp; minOccurs=3D"0"/>
        &= nbsp;     </sequence>
    &nbs= p;       </extension>
  &nbs= p;  </complexContent>
</complexType>



On Feb 29, 2012, at 7:34 PM, David Schwart= z wrote:

In the current model, the relationship between the = routes and the identities (phone numbers) is encapsulated for all practical= purposes in the RteGrp object. It is for this reason that all aspects of p= eering as well are sitting in the RG as this is the focal point of the reso= lution process. While it is understandable why this is so (optimize th= e use case that is most common --> grouping of numbers and their associa= ted routing options) it is severely limiting for other relationships that d= on't fit this profile (e.g. TNType to RteRec). As a result, if we want to a= ssociate a TNType with a RteRec and yet retain all the properties associate= d with a RteGrp (e.g. peeringOrgs) we need to either have a TNType - RG rel= ationship (bypassing the DG and kinda breaking the model), Have a DG with j= ust 1 PI and risk countless useless DGs just sitting around for this purpos= e, or associate the TNType directly with the RteRec and lose the peering pr= operties afforded by the RG concept.

What is proposed is a sli= ght change to the model which abstracts the association between the RG and = DG to a higher layer represented by RteElement and IDElement respectively (= both are abstract) extending the association capabilities to 1-1 relationsh= ips as well. Instead of the RteGrp containing the association information, = this information is relegated to the RteElement as shown in the figure belo= w=85

  =                      = ;               ****************
 &n= bsp;                     =               * BasicObjType *
 &nbs= p;                     &n= bsp;             ****************
   = ;                     &nb= sp;           ^          =       ^
              = ;                     /&n= bsp;                 \
   =                     &nbs= p;         /            &= nbsp;       \
            =         **************        &nbs= p;           **************
     &nb= sp;               * IDElement  *<= ;-------------------* RteElement *
           =           **************       = ;             **************
    &n= bsp;                 ^    = ;     ^                 &= nbsp;     ^         ^
     &nbs= p;               /       =     \                 &nb= sp;   /           \
       = ;             /         &= nbsp;   \                 &nbs= p; /             \
       =         ***********    ***********  &nbs= p;     ***********    ***********
     &n= bsp;         *  PubID  *--->* DestGrp *&nb= sp;       * RteGrp  *--->* RteRec  *
  = ;             ***********    ******= *****        ***********    ***********
=

As can be seen in this figure, we still maintain the PI to Dest= Grp and RteGrp to RteRec relationships as well the RteGrp to DestGrp relati= onship (albeit indirectly). What we gain, however is a direct relationship = between the RteRec and the PI which we were missing in the previous model.<= /div>

<= /div>
I wil= l send the actual XSD in a followup post for further clarity.
= --_000_871FD974000740C8B807AE27F73BF995xconnectnet_-- From dschwartz@xconnect.net Wed Feb 29 18:33:54 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 64CBC21E8081 for ; Wed, 29 Feb 2012 18:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emliZXeHFoqI for ; Wed, 29 Feb 2012 18:33:53 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id CFE2C21E807F for ; Wed, 29 Feb 2012 18:33:51 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Thu, 1 Mar 2012 04:33:50 +0200 From: David Schwartz To: "drinks@ietf.org" Date: Thu, 1 Mar 2012 04:33:50 +0200 Thread-Topic: [drinks] Proposed changes to SPPF model Thread-Index: Acz3U7yZqTIYs35rSLGuOWFKx5BzbA== 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: multipart/alternative; boundary="_000_B53E1D8269844D2995B5AB4F848AC8F9xconnectnet_" MIME-Version: 1.0 Subject: Re: [drinks] Proposed changes to SPPF model 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, 01 Mar 2012 02:33:54 -0000 --_000_B53E1D8269844D2995B5AB4F848AC8F9xconnectnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Here is another change that I would like to propose/discuss=85 There are many elements in the model that serve as "attributes" of their co= ntainer elements. They provide some additional information that in SQL term= inology would form the basis of the "where" command. Examples include the c= orInfo element present in the different types of public identifiers, the pr= iority of a route group and the isInSvc flag of a route group. There are m= any additional and useful attributes that are not in the draft (e.g. capaci= ty associated with a route) and while one can always use the built in exten= sibility mechanism to add additional attributes, the lifecycle of attribute= s (CRUD) is not defined and as such interoperability is affected. What I would like to propose is the following. Create an "Attribute" object= (example provided below) and allow BasicObjType to add 0 or more such elem= ents thereby enabling any element to take advantage of this specific extens= ion and more importantly future-proffing this protocol. In the SOAP documen= t define the attribute operations (CRUD) and in parallel, write another dra= ft specifying an attribute profile for SPPF which includes the currently "k= nown" attributes such as "priority" and "corInfo". (alternatively, the exis= ting attributes such as corInfo can stay in this draft and the attribute el= ement be used for new attributes). The current proposal for attributes distinguishes between two kinds of attr= ibutes: name-value (e.g. priority=3D5) and flag attribute (e.g. corInfo). **************** [0..n] ************* * BasicObjType *--------->* Attribute * **************** ************* ^ ^ / \ / \ ********** *********** * Flag * * NameVal * ********** *********** The AttributeType is an abstract type that represents additional informatio= n relating to a BasicObjType The NameValueType is an attribute of type name=3Dval The FlagType is an attribute that is boolean true if present The BasicObjType is modified as follows (Thanks to Mickael for XSD code) Thoughts? On Feb 29, 2012, at 7:34 PM, David Schwartz wrote: In the current model, the relationship between the routes and the identitie= s (phone numbers) is encapsulated for all practical purposes in the RteGrp = object. It is for this reason that all aspects of peering as well are sitti= ng in the RG as this is the focal point of the resolution process. While it= is understandable why this is so (optimize the use case that is most commo= n --> grouping of numbers and their associated routing options) it is sever= ely limiting for other relationships that don't fit this profile (e.g. TNTy= pe to RteRec). As a result, if we want to associate a TNType with a RteRec = and yet retain all the properties associated with a RteGrp (e.g. peeringOrg= s) we need to either have a TNType - RG relationship (bypassing the DG and = kinda breaking the model), Have a DG with just 1 PI and risk countless usel= ess DGs just sitting around for this purpose, or associate the TNType direc= tly with the RteRec and lose the peering properties afforded by the RG conc= ept. What is proposed is a slight change to the model which abstracts the associ= ation between the RG and DG to a higher layer represented by RteElement and= IDElement respectively (both are abstract) extending the association capab= ilities to 1-1 relationships as well. Instead of the RteGrp containing the = association information, this information is relegated to the RteElement as= shown in the figure below=85 **************** * BasicObjType * **************** ^ ^ / \ / \ ************** ************** * IDElement *<-------------------* RteElement * ************** ************** ^ ^ ^ ^ / \ / \ / \ / \ *********** *********** *********** *********** * PubID *--->* DestGrp * * RteGrp *--->* RteRec * *********** *********** *********** *********** As can be seen in this figure, we still maintain the PI to DestGrp and RteG= rp to RteRec relationships as well the RteGrp to DestGrp relationship (albe= it indirectly). What we gain, however is a direct relationship between the = RteRec and the PI which we were missing in the previous model. I will send the actual XSD in a followup post for further clarity. --_000_B53E1D8269844D2995B5AB4F848AC8F9xconnectnet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Here is another chang= e that I would like to propose/discuss=85

There ar= e many elements in the model that serve as "attributes" of their container = elements. They provide some additional information that in SQL terminology = would form the basis of the "where" command. Examples include the = ;corInfo element present in the different types of public identifiers, the priority of a route group and the isInSvc flag of a route group.  = ;There are many additional and useful attributes that are not in the draft = (e.g. capacity associated with a route) and while one can always use the bu= ilt in extensibility mechanism to add additional attributes, the lifecycle = of attributes (CRUD) is not defined and as such interoperability is affecte= d. 

What I would like to propose is the follo= wing. Create an "Attribute" object (example provided below) and allow Basic= ObjType to add 0 or more such elements thereby enabling any element to take= advantage of this specific extension and more importantly future-proffing = this protocol. In the SOAP document define the attribute operations (CRUD) = and in parallel, write another draft specifying an attribute profile for SP= PF which includes the currently "known" attributes such as "priority" and "= corInfo". (alternatively, the existing attributes such as corInfo can stay = in this draft and the attribute element be used for new attributes).
<= div>
The current proposal for attributes distinguishes b= etween two kinds of attributes: name-value (e.g. priority=3D5) and flag attribute (e.g= . corInfo).

  =       ****************  [0.= .n]  *************
--------= ->* Attribute *
      &nb= sp;****************   &= nbsp;      *************
                &n= bsp;                  ^  =     ^
      <= /span>               =              / &nbs= p;       \
    &nbs= p;               &n= bsp;            /        =   \
         =              =  **********      ***********
            &= nbsp;            * =  Flag  *      * NameVal *
                         ********** =      ***********

The AttributeType is an abstract type that re= presents additional information relating to a BasicObjType
<complexType name=3D"AttributeType" abstract=3D"true">
     <compl=
exContent>
        &nbs= p;</sequence>
       </extension><=
o:p>
     </complexContent&=
gt;
</c=
omplexType>
 
The NameValueTyp= e is an attribute of type name=3Dval
<complexType name=3D"NameValueType" abstract=3D"true">
= 
     <complexContent>
     &nbs=
p;     <extension base=3D"sppfb:AttributeType=
">
    &nb=
sp;          <sequen=
ce>
    &n=
bsp;            =
;  <element name=3D"name" type=3D"sppfb:ObjNameType"/>
      =
;             <=
/span><element name=3D"value" type=3D"sppfb:AttrValueType"
       &nbs=
p;            &=
nbsp;    minOccurs=3D"0"/>
    &n=
bsp;          </sequence>
&nb=
sp;      </extension>
     </complexContent><=
/font>
</complexType><=
o:p>

<simpleTyp= e name=3D"AttrValueType">
     <=
;restriction base=3D"token"/>
</simpleType>

 

The FlagType is an attr= ibute that is boolean true if present
<complexTyp=
e name=3D"FlagType" abstract=3D"true">
     <complexContent>
  &n=
bsp;        <extension base=3D=
"sppfb:AttributeType">
    &n=
bsp;      =
    <sequence>
         =
;          <element =
name=3D"name" type=3D"sppfb:ObjNameType"/>
<=
font class=3D"Apple-style-span" face=3D"'Courier New'">          &n=
bsp;    </sequence>
     =
  </extension>
   &=
nbsp; </complexContent>
</complexType>
=
 
The BasicObjType is modified a= s follows
= <complexType name=3D"BasicObjType" abstract=3D"true">
   =
;   <sequence>
          <elem=
ent name=3D"rant" type=3D"sppfb:OrgIdType"/>
          <element name=3D"rar" type=3D"sppfb:OrgIdType"/><= /pre>
        &nb=
sp; <element name=3D"cDate" type=3D"dateTime"
        &nbs=
p;            &=
nbsp;       minOccurs=3D"0"/><=
/o:p>
      &n=
bsp;   <element name=3D"mDate" type=3D"dateTime"
    =
;      <element name=3D"attributes" type=
=3D"sppfb:AttributeType"
 &n=
bsp;            =
;            &n=
bsp;  minOccurs=3D"0" maxOccurs=3D"unbounded"/>
       &nb=
sp;  <element name=3D"ext" type=3D"sppfb:ExtAnyType"
      &nbs=
p;      &n=
bsp;            =
;   minOccurs=3D"0"/>
=
      </sequence><=
/o:p>
</complexType>

(Thanks to Mickael for XSD code)

Thoug= hts?
=

=

=

On Feb 29, 2012, at 7:34 PM, David Schwar= tz wrote:

In the current model, the relationship between the= routes and the identities (phone numbers) is encapsulated for all practica= l purposes in the RteGrp object. It is for this reason that all aspects of = peering as well are sitting in the RG as this is the focal point of the res= olution process. While it is understandable why this is so (optimize t= he use case that is most common --> grouping of numbers and their associ= ated routing options) it is severely limiting for other relationships that = don't fit this profile (e.g. TNType to RteRec). As a result, if we want to = associate a TNType with a RteRec and yet retain all the properties associat= ed with a RteGrp (e.g. peeringOrgs) we need to either have a TNType - RG re= lationship (bypassing the DG and kinda breaking the model), Have a DG with = just 1 PI and risk countless useless DGs just sitting around for this purpo= se, or associate the TNType directly with the RteRec and lose the peering p= roperties afforded by the RG concept.

What is proposed is a sl= ight change to the model which abstracts the association between the RG and= DG to a higher layer represented by RteElement and IDElement respectively = (both are abstract) extending the association capabilities to 1-1 relations= hips as well. Instead of the RteGrp containing the association information,= this information is relegated to the RteElement as shown in the figure bel= ow=85

                      &nbs= p;               ****************
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal 'Courier New'; "> &= nbsp;                    =               * BasicObjType *
 &nb= sp;                     &= nbsp;             ****************
  &nbs= p;                     &n= bsp;           ^         =       ^
             &nbs= p;                     /&= nbsp;                 \
   = ;                     &nb= sp;         /            =         \
            = ;         **************        &nb= sp;           **************
     &n= bsp;               * IDElement  *&l= t;-------------------* RteElement *
          =           **************      &nbs= p;             **************
    &n= bsp;                 ^    = ;     ^                 &= nbsp;     ^         ^
     &nbs= p;               /       =     \                 &nb= sp;   /           \
       = ;             /         &= nbsp;   \                 &nbs= p; /             \
       =         ***********    ***********  &nbs= p;     ***********    ***********
     &n= bsp;         *  PubID  *--->* DestGrp *&nb= sp;       * RteGrp  *--->* RteRec  *
  = ;             ***********    ******= *****        ***********    ***********
=

As can be seen in this figure, we still maintain the PI to Dest= Grp and RteGrp to RteRec relationships as well the RteGrp to DestGrp relati= onship (albeit indirectly). What we gain, however is a direct relationship = between the RteRec and the PI which we were missing in the previous model.<= /div>

<= /div>
I wil= l send the actual XSD in a followup post for further clarity.

= --_000_B53E1D8269844D2995B5AB4F848AC8F9xconnectnet_--