From sumanth@cablelabs.com Fri Sep 7 11:51:56 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 92C2621F864D for ; Fri, 7 Sep 2012 11:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZlIeEj33O6j for ; Fri, 7 Sep 2012 11:51:56 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1455921E80D0 for ; Fri, 7 Sep 2012 11:51:52 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q87IppKJ032598 for ; Fri, 7 Sep 2012 12:51:51 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 07 Sep 2012 12:51:51 -0600 (MDT) 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; Fri, 7 Sep 2012 12:51:52 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Fri, 7 Sep 2012 12:51:49 -0600 Thread-Topic: Extension of WGLC for I-Ds draft-ietf-drinks-spp-framework-02.txt and draft-ietf-drinks-spp-protocol-over-soap-02.txt Thread-Index: Ac2NKdeoVzxAZMxlTsSBa48iPLVWBw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC6F9C26135ACsumanthcablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Extension of WGLC for I-Ds draft-ietf-drinks-spp-framework-02.txt and draft-ietf-drinks-spp-protocol-over-soap-02.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:51:56 -0000 --_000_CC6F9C26135ACsumanthcablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable WG Participants, We'd like to announce an extension for the following I-Ds: http://tools.ietf.org/id/draft-ietf-drinks-spp-framework-02.txt http://tools.ietf.org/id/draft-ietf-drinks-spp-protocol-over-soap-02.txt Thus, we are now requesting any and all feedback by Sep 21, 2012, 23:59 UTC= . -- As you are aware we originally announced WGLC in August. See: http://www.ietf.org/mail-archive/web/drinks/current/msg01216.html http://www.ietf.org/mail-archive/web/drinks/current/msg01217.html However, we have received limited feedback so far (one from Paul Hoffman; t= hanks). Given this, we reached out to the design team and the expert review= ers and it turns out that August was a busy travel/vacation month - resulti= ng in a request for more time. Please provide any and all feedback over the= next couple of weeks. Please refer to the original announcements for addit= ional, useful, information (e.g., history of the I=96Ds). Regards, Alex and Sumanth (as Chairs) --_000_CC6F9C26135ACsumanthcablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
WG Participants,

We'd like to announce a= n extension for the following I-Ds: 


Thus, we are now requesting an= y and all feedback by Sep 21, 2012, 23:59 UTC.

--
=
As you are awar= e we originally announced WGLC in August. See: 


However, we have received lim= ited feedback so far (one from Paul Hoffman; thanks). Given this, we reache= d out to the design team and the expert reviewers and it turns out that Aug= ust was a busy travel/vacation month - resulting in a request for more time= . Please provide any and all feedback over the next couple of weeks. Please= refer to the original announcements for additional, useful, information (e= .g., history of the I=96Ds). 

= Regards,
Alex and Su= manth (as Chairs)

= --_000_CC6F9C26135ACsumanthcablelabscom_-- From dean.willis@softarmor.com Mon Sep 10 19:14: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 5044C21F8701 for ; Mon, 10 Sep 2012 19:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLZc2t7b0O5F for ; Mon, 10 Sep 2012 19:14:32 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 474F921F8700 for ; Mon, 10 Sep 2012 19:14:31 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3622obb.31 for ; Mon, 10 Sep 2012 19:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; bh=JOaRvX/vnyrVlNAPx21JLQ+Jf2RuhKj462f5iwrNEhk=; b=NZRGmwfy3WOHgI0NgUPkJ19iJ+num2q9cKgqI0Z0kYqTu7ud7AJJOmCTpUKrOhM8vu lBCpu9EUUR6eaITsgSxnZwd26GQWS9s7ZBgUk7uy1lPjt/WEHfk3qZD2ar273znxKNNK 2ysEheVUeIfefcgXa5VdOaTXpqMVVJIcHsLlI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer:x-gm-message-state; bh=JOaRvX/vnyrVlNAPx21JLQ+Jf2RuhKj462f5iwrNEhk=; b=IY0bFc0JBm8Mt4A6vShwP8zYE4x1XiuYyq+AZYbKKOYblG5ThzM/WSj3MKjEvU7pa+ zHYXEYfm5xlXWesDBY1WiDbu/GhyuqhTuXp+cwbu9mbFnMPc6PMSUdRCVaEIic7ZQolG rJXBqSysM+Ug2kzIX9MJUq15oVQsCG0gwVSMihmUib2zrJvOixAD7I0aBKjUtVMaPPtg KLFACeIm17vS+SjTY/DeC8gMM0XXwPTElsIkMH5/Z2AwpjQnFUhjbQ7Fj//HSBO2rXW9 r8akXddOyXQhptwD8y0K2HNdD6BO/NJPUNE9Hc1ppffZfuWb1hLf7oGDAhkBIMRvU6rG PqXg== Received: by 10.60.25.131 with SMTP id c3mr16513121oeg.50.1347329671322; Mon, 10 Sep 2012 19:14:31 -0700 (PDT) Received: from dwillis-mb1.local.tld ([71.21.173.137]) by mx.google.com with ESMTPS id bp7sm14940340obc.12.2012.09.10.19.14.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Sep 2012 19:14:30 -0700 (PDT) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: <42BE7676-8289-453F-B180-5164138BFC30@softarmor.com> Date: Mon, 10 Sep 2012 21:14:37 -0500 To: drinks@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkvLaueoxhWN7jMb1a++3RfT/xv4+enR36/ykwD6jAGYkhiYn1aQcY7NEXeEPhJSQFJmweb Subject: [drinks] Comments on draft-ietf-spp-framework-02 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, 11 Sep 2012 02:14:34 -0000 I've been through the framework document again and outside of a few = editorial comments, it looks pretty good to me. Here's what I have: In section 3, we talk an awful lot about "protocol" for a framework = document: 3. Framework High Level Design This section introduces the structure of the data model and provides the information framework for the SPPF. The data model is defined along with all the objects manipulated by the protocol and their relationships. 3.1. Framework Data Model The data model illustrated and described in Figure 2 defines the logical objects and the relationships between these objects that the SPPF protocol supports. SPPF defines the protocol operations through which an SPPF client populates a registry with these logical objects. Various clients belonging to different registrars may use the protocol for populating the registry's data. This suggests that it might be worth grepping through the framework for = all uses of "protocol" and vetting them. Page 18 has: The .PubIdKeyType is used in Delete and Get operations on a Public Identifier object. Is there really supposed to be a period in front of PubIdKeyType? 6.3 SED Group says: As described in the introductory sections, a SED Group represents a combined grouping of Destination Groups containing a set of Public Identifiers with common Session Establishment Data(SED), The common Session Establishment Data Records, and the list of peer organizations that have access to these public identifiers using the associated SED information. This doesn't seem like a proper sentence. Is it a comma splice? Should = it be multiple sentences? I tried rewriting it several different ways = and they all turned to gobbledygook, so some rethinking may be needed = here.= From dean.willis@softarmor.com Mon Sep 10 19:47:27 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 9594C21F84E7 for ; Mon, 10 Sep 2012 19:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1RhXjZff332 for ; Mon, 10 Sep 2012 19:47:27 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E10B821F84D6 for ; Mon, 10 Sep 2012 19:47:26 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so40117obb.31 for ; Mon, 10 Sep 2012 19:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; bh=Gt7BnrKtAjhXGXDKBWxYPffM2yNU8eXqjv+iz2plZtA=; b=EvjOtOx2RDlxL++u0pRVKdWMfXDJbq+h9Gjp0k1x16mEfds7RIbCMd4FhKR2wUUQQV heJacvs0jPeUDH6d4i1EuR6sZ+CGJt6bABWc9kJHdHlv0Twe4YWxuo3/YJnFW+RTy4To zuAgxW+YA3QQuhZS0h1v8jHeKjDydULJYLqig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer:x-gm-message-state; bh=Gt7BnrKtAjhXGXDKBWxYPffM2yNU8eXqjv+iz2plZtA=; b=AY3QSE7KmwfIwZdzDCmLIjmtIRRmybvLnFz71R3WrjZzaFFIuTQTUb088veswcZiBD 3aW2g6FbEQgd6fKszKaDqEdw9x9bIOIhQ54dsqeip3BDcDEQ4/Bq8lErXz6CyiLTOOm7 JukLYg8/JUkzf3i3CoaxFltAccoVW2iyxvg1nNVi2XOrdLfV3olTUoRx/Wm0S06PDrKT 7+3VNPa8G5UgbvBMEvv/+fR9aTplNhwXnQXwQXpFhIlrKUIRG3FQZyh74P5F3pFrxEzb qLuw72X5lFssENm9KKIe8mc0Iy4m4VRII57sgqUGunJj9sPSBQHn/kDmBYAaqjJY4IG3 mYKA== Received: by 10.182.207.6 with SMTP id ls6mr16540170obc.36.1347331646535; Mon, 10 Sep 2012 19:47:26 -0700 (PDT) Received: from dwillis-mb1.local.tld ([71.21.173.137]) by mx.google.com with ESMTPS id kc5sm15018188obb.21.2012.09.10.19.47.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Sep 2012 19:47:26 -0700 (PDT) From: Dean Willis Content-Type: text/plain; charset=windows-1252 Message-Id: <7270D1CD-6443-492A-87FB-42063F644ABF@softarmor.com> Date: Mon, 10 Sep 2012 21:47:24 -0500 To: drinks@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmX1YMkpRg+sNsJSh5XowdXrnprUI+Q98SjlDMbxiZE5GR/n4/0deXH29SYibkzxAng5gfe Subject: [drinks] Review of draft-ietf-drinks-spp-protocol-over-soap-02 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, 11 Sep 2012 02:47:27 -0000 In 7.1.2 Public Identity Object Key we have: It is MUST that only one of the "number", "range", and "uri" elements appears in a PubIdKeyType instance This might be better worded as: Any instance of PubIdKeyType MUST contain exactly one element from = the following set of elements: "number", "range", "uri".=20 Section 11: Security Considerations makes TLS a SHOULD, and 11.1 makes = it a MUST IMPLEMENT. Didn't we agree to a MUST USE? Note that 11.3 = allows non-encryption =85 it's weasely. 11.1 discusses authentication alternatves, but doesn't section 5 mandate = Digest? Section 5 says: 5. Authentication and Session Management To achieve integrity and privacy, conforming SPP Protocol SOAP Clients and Servers MUST support SOAP over HTTP over TLS [RFC5246] as the secure transport mechanism. This combination of HTTP and TLS is referred to as HTTPS. And to accomplish authentication, conforming SOAP SPPF Clients and Servers MUST use HTTP Digest Authentication as defined in [RFC2617]. As a result, the communication session is established through the initial HTTP connection setup, the digest authentication, and the TLS handshake. When the HTTP connection is broken down, the communication session ends. but 11.1 says: 11.1. Integrity, Privacy, and Authentication The SPP Protocol over SOAP binding relies on an underlying secure transport for integrity and privacy. Such transports are expected to include TLS/HTTPS. In addition to the application level authentication imposed by an SPPF server, there are a number of options for authentication within the transport layer and the messaging envelope. These include TLS client certificates, HTTP Digest Access Authentication, and digital signatures within SOAP headers. At a minimum, all conforming SPP Protocol over SOAP implementations MUST support HTTPS. From sumanth@cablelabs.com Wed Sep 12 15:58:08 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 B900921F85A3 for ; Wed, 12 Sep 2012 15:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvXKc1pFsIn2 for ; Wed, 12 Sep 2012 15:58:07 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 58CCC21F85A2 for ; Wed, 12 Sep 2012 15:58:07 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q8CMw4Qk008758 for ; Wed, 12 Sep 2012 16:58:05 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 12 Sep 2012 16:58:04 -0600 (MDT) 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, 12 Sep 2012 16:58:05 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Wed, 12 Sep 2012 16:58:01 -0600 Thread-Topic: Usage of SOAP as a transport within DRINKS Thread-Index: Ac2ROhFtobeKVUEzQTO8B8Ho3+/5Qw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC766F9913D9Asumanthcablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] Usage of SOAP as a transport within DRINKS 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, 12 Sep 2012 22:58:08 -0000 --_000_CC766F9913D9Asumanthcablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Since comments regarding the use of SOAP as a proposed transport within the= DRINKS WG keeps coming up - either as a comment or surprise - I figured t= hat an unofficial, recap of how this came about may help, esp., for those w= ho haven't followed the progress of this WG and don't want to dig the histo= rical archives. I should state that the presence of a SOAP-specific transpo= rt document does not preclude other transports (e.g., RESTful web services)= from being used.This is the reason the proposal was split into two portion= s: a transport-agnostic part, and a transport-specific part (SOAP being the= currently chosen transport). Given this is my own account - as an individu= al contributor - I invite other WG participants to correct or augment my re= collections, in case I missed anything. -- Clarification I am sending this purely as an FYI =96 I don't intend to (re-)start a deba= te on the use SOAP or not! From my recollection, we have already had that d= iscussion a couple of times now and reached rough consensus that has result= ed in work that is nearing completion (I hope!). I presume IETF contributor= s are welcome to propose follow-on work with other transport mechanisms. -- Recollection #1: The rough consensus for SOAP, and the splitting of effo= rts to create a transport-agnostic protocol, and a SOAP-specific transport = proposal As one may expect, the debate around the use of SOAP v/s other options (spe= cifically RESTful web services) is as old as the WG itself :). While there= were many debates in the early days (~2008) the first official WG poll - = between IETF 74 and IETF 75 - resulted in recommendations for SOAP based on= the feedback received (see links below, which state reasons). Even some of= us (yes, myself included) who preferred to explore the use of RESTful web = services eventually agreed to SOAP, based on precedence and preference of i= mplementers -- and -- the proposed effort split that would allow for other = transports. This was subsequently discussed at IETF 75 (http://www.ietf.org= /proceedings/75/minutes/drinks.txt), where similar comments were echoed. Ho= wever, there was also a general consensus to allow for other transports (no= w or in the future). The result was to have two separate I-Ds: one for a tr= ansport-agnostic protocol and the other for a transport-specific document (= as noted in the minutes from IETF75). Proposals for transport were called a= nd - during IETF77 - the SOAP-specific transport I-D was accepted as a WG i= tem (unless I am mistaken, I believe this was the only transport proposal).= The WG then worked on the following I-Ds, in addition to the use cases do= cument (now RFC6461): http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/ (versions 1-12) http://tools.ietf.org/wg/drinks/draft-ietf-drinks-sppp-over-soap/ (versions= 1-7) -- Recollection #2: Conversion of the transport-agnostic protocol to an (ev= en more) abstract framework, to make it more conducive to non-SOAP transpor= ts As the I-Ds matured, we had the opportunity to see an open source implement= ation being built to verify the protocol and transport. Feedback from those= who authored this open source implementation (http://tools.ietf.org/agend= a/81/slides/drinks-1.pdf) - confirmed the general implementability, but re= commended that we make the split more distinct to allow for potential imple= mentations using other transport options (e.g., RESTful Web Services). Spec= ifically, there was concern raised (at IETF#81) that there was tight coupli= ng between data models and SOAP (http://www.ietf.org/proceedings/81/minutes= /drinks.txt ). This concern was debated at IETF#81, during the 81.5 interim meeting (http:= //www.ietf.org/mail-archive/web/drinks/current/msg01028.html) and in subseq= uent design team discussions. The resulting consensus was to refactor the I= -Ds to make the split more obvious, and new I-Ds were submitted in Nov, 201= 1. The question of moving away from SOAP was also brought up, and the WG de= cided to stick to the original decision, with a better split. This was rat= ified by the WG in IETF#82 (http://www.ietf.org/proceedings/82/minutes/drin= ks.txt ) This is how we got our current I-Ds, which are currently in WGLC. http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spp-framework/ http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spp-protocol-over-soap/ -- Summary While the WG debated different transport options a few times, based on roug= h consensus SOAP became the transport of choice to be specified (within its= current scope). However, there was acknowledgement that there are alternat= e options (RESTful web services). To allow for these options, a transport-a= gnostic protocol was specified. To make this even more conducive to other p= rotocols, the design team has re-worked the protocol into a more abstract, = and malleable, framework that lends itself better to other transport option= s (over the last year). This is reflected in the current I-Ds, which are in= last call. -- Historically relevant Links + IETF 72 (July, 2008) - The first "DRINKS" (previously PEPPERMINT) meeting that briefly discussed= transport options (SOAP, RESTful web services etc.). http://www.ietf.org/proceedings/72/minutes/drinks.txt + IETF 73 - One of the first discussions around preferred transport options was durin= g IETF 73 (http://www.ietf.org/proceedings/73/minutes/drinks.txt), where a = few participants proposed the use of SOAP based on current usage, with some= proposing alternatives (e.g., RESTful web services). + IETF 74 - The first official poll (between #74 and #75): http://www.ietf.org/mail-archive/web/drinks/current/msg00500.html - Questioning of assumptions and responses: http://www.ietf.org/mail-archive/web/drinks/current/msg00501.html http://www.ietf.org/mail-archive/web/drinks/current/msg00502.html - Preference for SOAP http://www.ietf.org/mail-archive/web/drinks/current/msg00503.html http://www.ietf.org/mail-archive/web/drinks/current/msg00506.html http://www.ietf.org/mail-archive/web/drinks/current/msg00507.html http://www.ietf.org/mail-archive/web/drinks/current/msg00508.html http://www.ietf.org/mail-archive/web/drinks/current/msg00509.html + IETF 75 - Follow-up discussions, and suggestions, including feedback from outside o= f the WG http://www.ietf.org/proceedings/75/minutes/drinks.txt + IETF 77 - Acceptance of SOAP-specific transport I-D at IETF 77 http://www.ietf.org/proceedings/77/minutes/drinks.txt - Confirmation of acceptance on the mailing list http://www.ietf.org/mail-archive/web/drinks/current/msg00670.html + IETF 81 - Open source implementation, and concern regarding data models being too t= ightly coupled with SOAP http://www.ietf.org/proceedings/81/minutes/drinks.txt + IETF 81.5 (Interim) - Q was raised at interim meeting (Sep 2011) and in subsequent discussions http://www.ietf.org/mail-archive/web/drinks/current/msg01028.html - Submission of refactored documents, allowing for a more malleable framewo= rk + IETF82 - Acceptance of the new I-Ds http://www.ietf.org/proceedings/82/minutes/drinks.txt - S (as an individual contributor) --_000_CC766F9913D9Asumanthcablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Since comments regarding the use of SOAP as= a proposed transport within the DRINKS WG keeps coming up - either as a co= mment or surprise -  I figured that an unofficial, recap of how this c= ame about may help, esp., for those who haven't followed the progress = of this WG and don't want to dig the historical archives. I should sta= te that the presence of a SOAP-specific transport document does not preclud= e other transports (e.g., RESTful web services) from being used.This is the= reason the proposal was split into two portions: a transport-agnostic part= , and a transport-specific part (SOAP being the currently chosen transport)= . Given this is my own account - as an individual contributor - I invi= te other WG participants to correct or augment my recollections, in case I = missed anything. 



-- Clarification

I am se= nding this purely as an FYI =96  I don't intend to (re-)start a d= ebate on the use SOAP or not! From my recollection, we have already had tha= t discussion a couple of times now and reached rough consensus that has res= ulted in work that is nearing completion (I hope!). I presume IETF contribu= tors are welcome to propose follow-on work with other transport mechanisms.=  



-- Recollection #1: The rough consensus for SOAP, and the s= plitting of efforts to create a transport-agnostic protocol, and a SOAP-spe= cific transport proposal 

As one may expect, the debate around the use of SOAP v/s ot= her options (specifically RESTful web services) is as old as the WG itself = :).  While there were many debates in the early days (~2008)  the= first official WG poll - between IETF 74 and IETF 75 - resulted in recomme= ndations for SOAP based on the feedback received (see links below, which st= ate reasons). Even some of us (yes, myself included) who preferred to explo= re the use of RESTful web services eventually agreed to SOAP, based on prec= edence and preference of implementers -- and -- the proposed effort split t= hat would allow for other transports. This was subsequently discussed at IE= TF 75 (ht= tp://www.ietf.org/proceedings/75/minutes/drinks.txt), where similar com= ments were echoed. However, there was also a general consensus to allow for= other transports (now or in the future). The result was to have two separa= te I-Ds: one for a transport-agnostic protocol and the other for a transpor= t-specific document (as noted in the minutes from IETF75). Proposals for tr= ansport were called and - during IETF77 - the SOAP-specific transport I-D w= as accepted as a WG item (unless I am mistaken, I believe this was the only= transport proposal). The WG then worked on the  following I= -Ds, in addition to the use cases document (now RFC6461):


http://t= ools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/ (versions 1-12)<= /p>

http://tools.ietf.org/wg/drink= s/draft-ietf-drinks-sppp-over-soap/ (versions 1-7)




-- Recollection #2: Conversion of the transport-agnostic protocol to a= n (even more) abstract framework, to make it more conducive to non-SOAP tra= nsports

=

As the I-Ds matured, we had = the opportunity to see an open source implementation being built to verify = the protocol and transport. Feedback from those who authored this open sour= ce implementation  (http://tools.ietf.org/agenda/81/slides/drinks-1.pdf) - &n= bsp;confirmed the general implementability, but recommended that we make th= e split more distinct to allow for potential implementations using other tr= ansport options (e.g., RESTful Web Services). Specifically, there was conce= rn raised (at IETF#81) that there was tight coupling between data models an= d SOAP (h= ttp://www.ietf.org/proceedings/81/minutes/drinks.txt ). 

<= p style=3D"font-family: Calibri, sans-serif; font-size: 14px; margin-top: 0= px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal n= ormal normal 12px/normal Helvetica; ">

This concern was debated at IETF#81, during the 81.5 interim meet= ing (http://www.ietf.org/mail-archive/web/drinks/current/msg01028.html) and in subsequent design team discussions. The resulting consensus was = to refactor the I-Ds to make the split more obvious, and new I-Ds were subm= itted in Nov, 2011. The question of moving away from SOAP was also brought = up, and the WG decided to stick to the original decision, with a better spl= it.  This was ratified by the WG in IETF#82 (http://www.ietf.org/proceedings/82= /minutes/drinks.txt )


This is how we got our current I-Ds, which are currently i= n WGLC. 

<= br>

http://tools.ietf.org/wg/dr= inks/draft-ietf-drinks-spp-framework/  

http://tools.ietf.org/wg/drinks/draft-ietf-= drinks-spp-protocol-over-soap/  





While the WG debated different transport options a few times, based on = rough consensus SOAP became the transport of choice to be specified (within=  its current scope). However,= there was acknowledgement that there are alternate options (REST= ful web services). To allow for these options, a transport= -agnostic protocol was specified. To make this even more conducive to other= protocols, the design team has re-worked the protoco= l into a more abstract, and malleable, framework that lends itself better t= o other transport options (over the last year). This is reflected in the cu= rrent I-Ds, which are in last call.




-- Historically relevant Links


+ IETF 72 (July, 2008) 

- The first "DRINKS" (previously PEPPERMINT) meeting tha= t briefly discussed transport options (SOAP, RESTful web services etc.).&nb= sp;

http://www.ietf.org/proceedings/72/min= utes/drinks.txt


+ IETF 73

- One of the first discussions around pref= erred transport options was during IETF 73 (http://www.ietf.org/proceedings/73/minut= es/drinks.txt), where a few participants proposed the use of SOAP based= on current usage, with some proposing alternatives (e.g., RESTful web serv= ices). 

+ IETF 74 

- The first official poll (between #74 and = #75): 

http://www.ietf.or= g/mail-archive/web/drinks/current/msg00500.html


- Questioning of assumptions and responses:

http://www.ietf.org/mail-archive/web/drinks/current/= msg00501.html

http://www.i= etf.org/mail-archive/web/drinks/current/msg00502.html


- Preference for SOAP

http://www.ietf.org/mail-archive/web/drinks/current/msg00503.html

http://www.ietf.org/mail-arc= hive/web/drinks/current/msg00506.html

http://www.ietf.org/mail-archive/web/drinks/current/msg00507.ht= ml

http://www.ietf.org/mai= l-archive/web/drinks/current/msg00508.html

http://www.ietf.org/mail-archive/web/drinks/current/msg005= 09.html


+ IETF 75

- Follow-up discussions, and suggestions, including feedback= from outside of the WG

http://www.ietf.= org/proceedings/75/minutes/drinks.txt



+ IETF = 77

- Acceptance of SOAP-specific = transport I-D at IETF 77 

http://www.= ietf.org/proceedings/77/minutes/drinks.txt


- Confirmation of acceptance on the mailing list 

http://www.ietf.org/mail-archive/web/drinks/cu= rrent/msg00670.html


<= br>

+  IETF 81

- Open source implementation, and concern = regarding data models being too tightly coupled with SOAP 

http://www.ietf.org/proceedings/81/minutes/drinks.txt=  


=


+  IETF 81.5 (Interim)

- Q was raised at interim meeting (Sep 2011= ) and in subsequent discussions

<= a href=3D"http://www.ietf.org/mail-archive/web/drinks/current/msg01028.html= ">http://www.ietf.org/mail-archive/web/drinks/current/msg01028.html

=


- Submission of refactored documents, allowi= ng for a more malleable framework 


= 3;  IETF82

- Acceptance of t= he new I-Ds

http://www.ietf.org/proceeding= s/82/minutes/drinks.txt



- S

(as an = individual contributor)

--_000_CC766F9913D9Asumanthcablelabscom_-- From dschwartz@xconnect.net Fri Sep 21 07:55:19 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 D472421F8822 for ; Fri, 21 Sep 2012 07:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAguavvgtRa6 for ; Fri, 21 Sep 2012 07:55:17 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1109421F8819 for ; Fri, 21 Sep 2012 07:55:15 -0700 (PDT) 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; Fri, 21 Sep 2012 16:55:13 +0200 From: David Schwartz To: "drinks@ietf.org WG" Date: Fri, 21 Sep 2012 16:55:10 +0200 Thread-Topic: Comments to the WGLC on SPPF document Thread-Index: Ac2YCRoeieRionA9Sem0GjWxRrCb/g== Message-ID: <2B7C55FC-88A3-4988-9173-9E740889357A@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_2B7C55FC88A3498891739E740889357Axconnectnet_" MIME-Version: 1.0 Subject: [drinks] Comments to the WGLC on SPPF document 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, 21 Sep 2012 14:55:19 -0000 --_000_2B7C55FC88A3498891739E740889357Axconnectnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Almost ALL of these comments are typo/style and general "nit" comments. Note that for ease of change tracking I added ">> text <<" to indicate the = need for removal of some text and "<< text >>" to indicate the need to add= some text. ***************************************************************************= ********************************************************** Abstract old: "The provisioned data is typically used by network elements for session >>p= eering<<" new: "The provisioned data is typically used by network elements for session <>" 1. Introduction old: "Service providers and enterprises use registries to make session routing decisions for Voice over IP, SMS and MMS traffic exchanges=85" new: "Service providers and enterprises use <> regist= ries to make session routing decisions for Voice over IP, SMS and MMS traffic exchanges=85" old: "Three types of provisioning flows have been described in the use case document: client to registry >>provisioning<<, registry to local data repository and registry to registry." new: "Three types of provisioning flows have been described in the use case document: client to registry, registry to local data repository and registry to registry." old: "This document addresses client to registry aspect to fulfill the need to provision Session Establishment Data (SED)." new: "This document addresses the client to registry <> enabling the provisioning of Session Establishment Data (SED)." old: "The data provisioned for session establishment is typically used by various downstream SIP signaling systems to route a call to the next hop associated with the called domain. These systems typically use a local data store ("Local Data Repository") as their source of session routing information." new: "The data provisioned for session establishment is <> typically used by various downstream SIP sign= aling systems to route a call to the next hop associated with the called domain." old: "Subsequently, a registry may distribute the provisioned data into local data repositories, used for lookup 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)." new: "Subsequently, a registry may distribute the provisioned data into local data repositories <>" old: "Transport requirements are provided in this document to help with the selection of the optimum transport mechanism. The SPP Protocol over SOAP document identifies a protocol for SPPF that uses SOAP/HTTP as the transport mechanism." new: "Transport requirements are provided in this document to help with the selection of the optimum transport mechanism." /* this second sentence creates a dependency on the SOAP document so imho i= t should be removed */ old "Section 5 describes the base framework data structures, the generic response types that MUST be supported by a conforming "protocol" specification, and the basic object type most first class objects extend from;" new: "Section 5 describes the base framework data structures, the generic response types that MUST be supported by a conforming <> "protocol" specification, and the basic object type m= ost first class objects extend from;" old: " o Section 6 detailed description of the data model object specifications;" new: " o Section 6 <> detailed description of the data model ob= ject specifications; << o Section 7 describes the operations that are supported by the data= model o Sections 9 - 11 discuss security, internationalization and IANA c= onsiderations >>" 2. Terminology old: "SPDP: Session Peering Distribution Protocol, the protocol used to distribute data to Local Data Repository (see arrow labeled "2." in Figure 1 of [RFC6461])." new: /* remove as this is not really discussed anywhere in the document */ old: "Client: An application that >>supports an SPPF client<<; it is sometimes referred to as a "registry client"." new: "Client: <> an application that <>; it is sometimes referred to as a "registry client". Server: <> an application that receives a provisioning request and responds accordingly. The server typically operates a master database of Session Establishment Data (SED) for one or more Registrants. In the context of SPPF, the provisioning server is referred to as a Registry. Registry: a provisioning server." 3. Framework High Level Design old: "The data model is defined along with all the objects manipulated by >>the protocol<< and their relationships." new: "The data model is defined along with all the objects manipulated by <> protocol and their relationships." 3.1. Framework Data Model old: "The data model illustrated and described in Figure 2 defines the logical objects and the relationships between these objects >>that the SPPF protocol supports<<." new: "The data model illustrated and described in Figure 2 defines the logical objects and the relationships between these objects supported by SPPF." old: "SPPF defines >>the<< protocol operations through which an SPPF client populates a registry with these logical objects. Various clients belonging to different registrars may >>use the protocol for populating the registry's data<<." new: "SPPF defines protocol operations through which an SPPF client populates a registry with these logical objects. Various clients belonging to different registrars may provision data into the registry using a conforming transport protocol implementing these operations." old: in figure, the Public Identifier has an element called "sedRecRef" - this n= eeds to be removed new: the TN element needs to have this element 5.1. Basic Object Type and Organization Identifiers old: "The identifiers used for registrants (rant), registrars (rar), and peering organizations (peeringOrg) are instances of OrgIdType." new: The identifiers used for registrants (rant) and registrars (rar) are instan= ces of OrgIdType. /* no need to introduce peeringOrg over here - it just serves to confuse. M= ove the peeringOrg comment to where its mentioned */ 5.2. Various Object Key Types old: ">>In addition,<< an object's unique identity is required to Delete or Get the details of an object." new: "<> an object's unique identity is required to Delete or Get the details of an object." old: \""Name" attributes that are used as components of object key types MUST be treated case insensitive." new: \""Name" attributes that are used as components of object key types MUST be treated <> case insensitive." 5.2.2. Derived Object Key Types old: "and defined in there own abstract key types. Because these object key types are abstract, these MUST be specified in a concrete form in any conforming SPPF "protocol" specification." new: "and defined in there own abstract key types. Because these object key types are abstract, these MUST be specified in a concrete form in any SPPF conforming <> protocol specification." old: The >>.<> protocol" specification and im= plemented by a conforming SPPF server." 6. Framework Data Model Objects old: "However, the specification of the data structures necessary to support each command is delegated to >>the "protocol"<< specification." New: "However, the specification of the data structures necessary to support each command is delegated to <> specification." 6.2. Public Identifier old: /* No XML describing CORInfoType in the TNTYpe description - yet elements = of this type are discussed in descriptive text */ new: add before the "NumberValType" " " Old: "RNType has the following attributes: =85 o corInfo: Optional element of type CORInfoType." New: "RNType has the following attributes: =85 o corInfo: corInfo is an optional parameter of type CORInfoType that allows the registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067])." Old: "TNRType has the following attributes: =85 o corInfo: Optional element of type CORInfoType." New: "TNRType has the following attributes: =85 o corInfo: corInfo is an optional parameter of type CORInfoType that allows the registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067])." Old: "TNPType has the following attributes: =85 o corInfo: Optional element of type CORInfoType." New: "TNPType has the following attributes: =85 o corInfo: corInfo is an optional parameter of type CORInfoType that allows the registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067])." Old: /* in the definition of URIPubIdType there is an "ext" element whereas in a= ll other pubIDs there isn't - why? */ New: remove=85 "" 6.2. SED Group Old: "As described in the introductory sections, a SED Group represents a combined grouping of Destination Groups containing a set of Public Identifiers >>with common Session Establishment Data(SED)<<, The common Session Establishment Data Records, and the list of peer organizations that have access to these public identifiers using the associated SED information." New: /* too verbose */ "As described in the introductory sections, a SED Group represents a combined grouping of Destination Groups (containing a set of Public Identifiers), The common Session Establishment Data Records, and the list of peer organizations that have access to this gouging (public identifiers using the associated SED information.)" Old: /* in the definition of SedGrpType there is an "ext" element - why? */ New: remove=85 "" Old: /* no mention of peeringOrg type */ New: "Note that the identifier used for peering organization (peeringOrg) is an = instance of OrgIdType." 6.4. SED Record Old: "The data provisioned in a registry can be leveraged for many purposes and queried using various protocols including SIP, ENUM and others. As such, the resolution data represented by the >>SedRecords<< must be in a form suitable for transport using one of these protocols. New: "The data provisioned in a registry can be leveraged for many purposes and queried using various protocols including SIP, ENUM and others. As such, the resolution data represented by the <> must be in a form suitable for transport using one of these protocols. 6.4. SED Record Old: "In a high-availability environment, the originating SSP likely has more than one egress path>>s<< to the ingress SBE of the target SSP." New: "In a high-availability environment, the originating SSP likely has more than one egress path to the ingress SBE of the target SSP." Old: "A Egress Route object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in the section "Generic Object Key Type" of this document." New: "A<> Egress Route object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in the section "Generic Object Key Type" of this document." 7. Framework Operations 7.1/2/3/4/5/6 Old: "Any conforming "protocol" specification MUST provide=85" New: "Any conforming <> specification MUST provide=85" 9.3.1 DoS Issues Inherited from Transport Mechanism Old: "The typical deployment scenario for SPPF is to have servers in a managed facility, and therefor techniques such as Network Ingress Filtering ([RFC2609]) are generally applicable." New: "The typical deployment scenario for SPPF is to have servers in a managed facility, and therefor<> techniques such as Network Ingress Filtering ([RFC2609]) are generally applicable." 13 Acknowledgments /* Jeremy Barkan participated in many discussions and should be acknowledge= d */ --_000_2B7C55FC88A3498891739E740889357Axconnectnet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Almost ALL of these c= omments are typo/style and general "nit" comments.

Note that for ease of change tracking I added ">> text <<" to = indicate the need for removal of some text and "<<  text >>= ;" to indicate the need to add some text.

********= ***************************************************************************= **************************************************

Abstract&= nbsp;

old: 
"The provisioned data is typically used by network e= lements for session >>peering<<"

new:
"The provisioned da= ta is typically used by network elements for session <<establishment&= gt;>"

1. Introduction

old: 
"Service providers and ent= erprises use registries to make session
routing decisions for Voice over IP, SMS a= nd MMS traffic exchanges=85"
 
new:
"Service providers and enterprises use <<routing databases know a= s>> registries to make session
routing decisions for Voice over IP, SMS and = MMS traffic exchanges=85" 

old: 
"Three types of provisioning= flows have been described in the use case
document: client to registry >>pr= ovisioning<<, registry to local data
repository and registry to registry." &= nbsp;

new:
"Three types of provisioning flows have been described in the = use case
repository and registry to = registry."  

old: 
"This document addresses client
to registry aspec= t to fulfill the need to provision Session
Establishment Data (SED)."

new:
"= This document addresses the client
to registry <<flow>> enabling the p= rovisioning of Session
Establishment Data (SED)."

old: 
"The data provis= ioned for session establishment is typically used by
various downstream SIP signal= ing systems to route a call to the next
hop associated with the called domain.&nbs= p; These systems typically use a
local data store ("Local Data Repository") as the= ir source of session
routing information." 

new:
"The data provisioned = for session establishment is <<known as Session Establishment Data or= SED and is>> typically used by various downstream SIP signaling syst= ems to route a call to the next
hop associated with the called domain."  

old: 
"Subsequently, a registry may distribute the provisioned data i= nto
loc= al data repositories, used for lookup queries (identifier -> URI)
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal Courier; ">or for lookup= and location resolution (identifier -> URI -> ingress
SBE of terminating SS= P).  In some cases, the registry may
additionally offer a central query resol= ution service (not shown in
the above figure)."

new:
"Subsequently, a registry= may distribute the provisioned data into
local data repositories <<or may a= dditionally offer a central query 
resolution service (not shown in the above= figure) for query purposes.>>"

old: 
"Transport requirement= s are provided in this document to help with the
selection of the optimum transpor= t mechanism.  The SPP Protocol over
SOAP document identifies a protocol for S= PPF that uses SOAP/HTTP as
the transport mechanism."

new:
"Transport require= ments are provided in this document to help with the
selection of the optimum tran= sport mechanism."  
/* this second sentence creates a dependency on the SOAP = document so imho it should be removed */


<= /div>
old&n= bsp;
"S= ection 5 describes the base framework data structures, the
      &= nbsp; generic response types that MUST be supported by a conforming
    =     "protocol" specification, and the basic object type most firs= t
 = ;       class objects extend from;"
new:
"Section 5 describes the base f= ramework data structures, the
        generic response types t= hat MUST be supported by a conforming
        <<transpor= t>> "protocol" specification, and the basic object type most first
  &n= bsp;     class objects extend from;"

old: 
"   o&= nbsp;   Section 6 detailed description of the data model object
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal Courier; ">   =     specifications;"

new:
"   o    Section = 6 <<provides a>> detailed description of the data model object<= /div>
  =       specifications;

<<   o   = ; Section 7 describes the operations that are supported by the data model

     o    Sections 9 - 11 discuss security= , internationalization and IANA considerations >>"

<= /div>
2. Term= inology

old: 
"SPDP: Session Peering Distribution Protocol, the = protocol used to
      distribute data to Local Data Repository (se= e arrow labeled "2."
      in Figure 1 of [RFC6461])."

new:
/* remove as this is not really discussed anywhere in the document */

old: 
"Client:   An application that >>supports an SPPF c= lient<<; it is
      sometimes referred to as a "registry cli= ent"."
= "Client:   <<In the context of SPPF, this is>> 
=
   = ;   an application that <<initiates a provisioning request>&g= t;; it is
=

Server:   <<In the context of SPPF, this is>>
    &= nbsp; an application that receives a provisioning request and responds = ;
 = ;     accordingly. The server typically operates a master databas= e of 
      Session Establishment Data (SED) for one or more R= egistrants. In
      the context of SPPF, the provisioning server i= s referred to as 
      a Registry.

Registry: a provi= sioning server."

3. Framework High Level Design

old:&nb= sp;
"Th= e data model is defined along with all the objects manipulated 
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal Courier; ">by >>th= e protocol<< and their relationships."

new:
"The data model is de= fined along with all the objects manipulated 
by <<a conforming tranpor= t>> protocol and their relationships."

3.1. Framework Data M= odel

old: 
"The data model illustrated and described in Figure 2 d= efines the
logical objects and the relationships between these objects >>tha= t the
S= PPF protocol supports<<."

new:
"The data model illustrated and = described in Figure 2 defines the
logical objects and the relationships between th= ese objects supported 
by SPPF."

old: 
"SPPF defines >>the&l= t;< protocol operations through
which an SPPF client populates a registry with = these logical objects.
Various clients belonging to different registrars may >&= gt;use the
protocol for populating the registry's data<<."
ne= w:
"SPP= F defines protocol operations through
which an SPPF client populates a registry wi= th these logical objects.
Various clients belonging to different registrars may pr= ovision data 
into the registry using a conforming transport protocol impleme= nting 
these operations."

old: 
in figure, the Public Identifier= has an element called "sedRecRef" - this needs to be removed
=
= new:
= the TN element needs to have this element

5.1.  Basic Objec= t Type and Organization Identifiers

old: 
"The identifiers used = for registrants (rant), registrars (rar), and
peering organizations (peeringOrg) a= re instances of OrgIdType."

new:
The identifiers used for registrants= (rant) and registrars (rar) are instances of OrgIdType.
/* no need to introduce p= eeringOrg over here - it just serves to confuse. Move the peeringOrg
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal Courier; ">   = comment to where its mentioned */

5.2.  Various Object Key Ty= pes

old: 
">>In addition,<< an object's unique identit= y is required to Delete or Get
the details of an object."  
ne= w:
"<<Not= e that>> an object's unique identity is required to Delete or = Get
the= details of an object."  

old: 
\""Name" attributes that ar= e used as components of object key types
MUST be treated case insensitive."
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal Helvetica; min-height: 1= 4px; ">
new:
\""Name" attributes that are used as components of object key types
MUST be t= reated <<as>> case insensitive."

5.2.2.  Derive= d Object Key Types

old: 
"and defined in there own abstract key ty= pes.  Because these object
key types are abstract, these MUST be specified in= a concrete form in
any conforming SPPF "protocol" specification."
ne= w:
"and= defined in there own abstract key types.  Because these object
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal Courier; ">key types are= abstract, these MUST be specified in a concrete form in
any SPPF conforming <&= lt;transport>> protocol specification."

old: 
=
The >>= .<<PubIdKeyType is used in Delete and Get operations on a
Public Identifier = object.

new:
The PubIdKeyType is used in Delete and Get operations on= a
Publ= ic Identifier object.

5.3.  Response Message Types

old: 
"This section contains the listing of response types that MUST be
defined by = the conforming "protocol" specification and implemented by
a conforming SPPF serv= er."

new:
"This section contains the listing of response types that MUS= T be
de= fined by the <<SPPF conforming transport>> protocol" specificat= ion and implemented by
a conforming SPPF server."

6.  Framework Dat= a Model Objects

old:
"However, the specification of the data structures n= ecessary to
support each command is delegated to >>the "protocol"<< sp= ecification."

New:
"However, the specification of the data structures nec= essary to

6.2. Public Identifier

old: 
/* No XML describing CORInfoType in the TNTYpe description = - yet elements of this type are discussed in descriptive text */

new:
add before the "NumberValType"

   " <complexType = name=3D"CORInfoType">
     <sequence>
      <el= ement name=3D"corClaim" type=3D"boolean" default=3D"true"/>
     = ; <element name=3D"cor" type=3D"boolean" default=3D"false" minOccurs=3D"= 0"/>
      <element name=3D"corDate" type=3D"dateTime" minOcc= urs=3D"0"/>
     </sequence>
    </complexType>"<= /div>

Old:
"RNType has the following attributes:
=85
   o    corInfo: O= ptional <corInfo> element of type CORInfoType."

=
New:
"RNType has th= e following attributes:
=85
   o    corInfo: corInfo is an optional p= arameter of type CORInfoType
        that allows the registran= t organization to set forth a claim to
        be the carrier-= of-record (see [RFC5067])."  

Old:
"TNRType has the following attr= ibutes:
=85
&n= bsp;  o    corInfo: Optional <corInfo> element of type= CORInfoType."

New:
"TNRType has the following attributes:
=85
   o  &= nbsp; corInfo: corInfo is an optional parameter of type CORInfoType
    =     that allows the registrant organization to set forth a claim = to
&nbs= p;       be the carrier-of-record (see [RFC5067])."

"TNPType has the following attributes:
=85
   o    corInfo: Optional= <corInfo> element of type CORInfoType."

New:
"TNPType has the foll= owing attributes:
=85
   o    corInfo: corInfo is an optional paramet= er of type CORInfoType
        that allows the registrant orga= nization to set forth a claim to
        be the carrier-of-rec= ord (see [RFC5067])."  

Old:
/* in the definition of URIPubIdType th= ere is an "ext" element whereas in all other pubIDs there isn't - why? */

New:
remove=85
   "<element name=3D"ext" type=3D"sppfb:ExtAnyType" m= inOccurs=3D"0"/>"

6.2. SED Group

Old:
"As described in the i= ntroductory sections, a SED Group represents a
combined grouping of Destination Gr= oups containing a set of Public
Identifiers >>with common Session Establishm= ent Data(SED)<<, The common
Session Establishment Data Records, and the list= of peer
associated = SED information."  

New:
/* too verbose */
"As described in the introductor= y sections, a SED Group represents a
combined grouping of Destination Groups (cont= aining a set of Public
Identifiers), The common Session Establishment 
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal Courier; ">Data Records,= and the list of peer organizations that have access to this
gouging (public ident= ifiers using the associated SED information.)"  

Old:
=
/* in the de= finition of SedGrpType there is an "ext" element - why? */

=
New:
remove= =85
&nb= sp;  "<element name=3D"ext" type=3D"sppfb:ExtAnyType" minOccurs=3D"= 0"/>"


Old:
/* no mention of peeringOrg type */

= "Note that the identifier used for peering organization (peeringOrg) is an = instance of OrgIdType."

6.4. SED Record

Old:
"The data provision= ed in a registry can be leveraged for many purposes
and queried using various prot= ocols including SIP, ENUM and others.
As such, the resolution data represented by = the >>SedRecords<< must be in
a form suitable for transport using one = of these protocols.

New:
"The data provisioned in a registry can be lever= aged for many purposes
and queried using various protocols including SIP, ENUM and= others.
a form suitable for transport using one of these protocols.
6.4. SED Record

Old:
"In a high-availability environment, the originatin= g SSP likely has
more than one egress path>>s<< to the ingress SBE of = the target SSP."
  
Ne= w:
"In = a high-availability environment, the originating SSP likely has
more than one egre= ss path to the ingress SBE of the target SSP."

Old:
"A Egress Route object MU= ST be uniquely identified by attributes as
defined in the description of "ObjKeyTy= pe" in the section "Generic
Object Key Type" of this document."

New:
"A<<n>= > Egress Route object MUST be uniquely identified by attributes as
=
defined in t= he description of "ObjKeyType" in the section "Generic
Object Key Type" of this do= cument."

7. Framework Operations

7.1/2/3/4/5/6
Old:
"Any conforming "= protocol" specification MUST provide=85"

New:
"Any conforming <<tra= nsport protocol>> specification MUST provide=85"

9.3.1 DoS I= ssues Inherited from Transport Mechanism

Old:
"The typical deployment sce= nario for SPPF is to have servers in a
managed facility, and therefor techniques s= uch as Network Ingress
Filtering ([RFC2609]) are generally applicable." 

New:
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin= -left: 0px; font: normal normal normal 12px/normal Courier; ">managed facil= ity, and therefor<<e>> techniques such as Network Ingress
=
Filtering ([= RFC2609]) are generally applicable." 

13 Acknowledgments
/* Jeremy = Barkan participated in many discussions and should be acknowledged */
=
= --_000_2B7C55FC88A3498891739E740889357Axconnectnet_-- From alexander.mayrhofer@nic.at Fri Sep 21 13:29:07 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 AA61F21E8086 for ; Fri, 21 Sep 2012 13:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyxZZowXjzUD for ; Fri, 21 Sep 2012 13:29:07 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6300021E8084 for ; Fri, 21 Sep 2012 13:29:06 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.48 ; Fri, 21 Sep 2012 22:29:04 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Fri, 21 Sep 2012 22:28:58 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: WGLC comments from Andrew Sullivan on draft-ietf-drinks-spp-framework-02 Thread-Index: Ac2YN4diJqCJqgXRTTSNoTb62GLmhQ== Date: Fri, 21 Sep 2012 20:28:57 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075096F3501@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.107] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] WGLC comments from Andrew Sullivan on draft-ietf-drinks-spp-framework-02 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, 21 Sep 2012 20:29:07 -0000 QW5kcmV3IGhhcyBzZW50IHRoZXNlIGNvbW1lbnRzIHByaXZhdGVseSB0byBtZSAtIGknbSBmb3J3 YXJkaW5nIHRoZXNlIHRvIHRoZSBsaXN0IC0gc2VlIGJlbG93Li4NCg0KQWxleA0KDQotLS0tLVVy c3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IGFzdWxsaXZhbkBkeW4uY29tIFttYWls dG86YXN1bGxpdmFuQGR5bi5jb21dIA0KR2VzZW5kZXQ6IERvbm5lcnN0YWcsIDIwLiBTZXB0ZW1i ZXIgMjAxMiAxODozOQ0KQW46IEFsZXhhbmRlciBNYXlyaG9mZXINCkJldHJlZmY6IHNwcC1mcmFt ZXdvcmsgKHdhczogUGluZyA6LSkpDQoNCkhpLA0KDQpJJ20gbm90IGdvaW5nIHRvIHN1YnNjcmli ZSB0byB0aGUgRFJJTktTIGxpc3QgdG8gZG8gdGhpcyByZXZpZXcgKHNvcnJ5KSwgc28gSSdsbCBz ZW5kIGl0IHRvIHlvdSB0byBmb3J3YXJkIGFwcHJvcHJpYXRlbHkuDQoNCkkgaGF2ZSByZXZpZXdl ZCBkcmFmdC1pZXRmLWRyaW5rcy1zcHAtZnJhbWV3b3JrLTAyLiAgSSBoYXZlIHNvbWUgY29tbWVu dHMuICBJIGhhdmVuJ3QgaW5jbHVkZWQgbml0cyBJIGRpc2NvdmVyZWQ7IEknbSByZWx5aW5nIG9u IHRoZSBSRkMgRWRpdG9yIGZvciB0aGF0LiAgSSBhbHNvIGRpZCBub3QgY2hlY2sgdGhlIFhNTCBl eGFtcGxlcyBhdCBhbGwuICBJIHRydXN0IHNvbWVvbmUgaGFzIGJlZW4gdGhyb3VnaCB0aG9zZSBj YXJlZnVsbHkuDQoNClNlY3Rpb24gMy4yOiAgSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgc2VjdGlv biBhdCBhbGwuICBUaGUgZHJhZnQgc2F5cyB0aGF0IHVucXVhbGlmaWVkIGxvY2FsIHRpbWUgaXMg ZGlzY291cmFnZWQsIHRoZW4gc2F5cyB5b3UgTVVTVCB1c2UgVVRDLCB0aGVuIHNheXMgdGhhdCBw ZXJmZWN0bHkgdmFsaWQgVVRDIHRpbWUgZm9ybWF0cyBhcmUgbm90IGFsbG93ZWQuDQpXaHkgbm90 IGp1c3Qgc3RhdGUgaG93IHRpbWUgaXMgcGVybWl0dGVkIHRvIGJlIGV4cHJlc3NlZCwgcGVyaW9k Pw0KDQpTZWN0aW9uIDQuNjogDQoNCiAgIEluIHNvbWUgZGVwbG95bWVudHMsIHRoZSBTUFBGIG9i amVjdHMgdGhhdCBhbiBTUFBGIHJlZ2lzdHJ5IG1hbmFnZXMNCiAgIGNhbiBiZSBwcml2YXRlIGlu IG5hdHVyZS4gIEFzIGEgcmVzdWx0IGl0IE1BWSBOT1QgYmUgYXBwcm9wcmlhdGUgdG8NCiAgIGZv ciB0cmFuc21pc3Npb24gaW4gcGxhaW4gdGV4dCBvdmVyIGEgY29ubmVjdGlvbiB0byB0aGUgU1BQ Rg0KDQpUaGF0ICJNQVkgTk9UIiBpcyB3cm9uZy4gIEl0J3Mgbm90IGFjdHVhbGx5IGEgMjExOSBr ZXkgd29yZCwgd2hpY2ggbWVhbnMgInlvdSdyZSBub3QgYWxsb3dlZCB0byBkbyB0aGlzIi4NCg0K U2VjdGlvbiA1LjE6ICJPcmdJZFR5cGUgaW5zdGFuY2VzIFNIT1VMRCBmb2xsb3ciLiAgT2ssIHdo YXQgaWYgdGhleSBkb24ndD8gIFRoYXQgc2VlbXMgbGlrZSBhIHBvdGVudGlhbCBzZXJpb3VzIGlu dGVyb3AgcHJvYmxlbSB0byBtZS4NCg0KU2VjdGlvbiA1LjI6IA0KICAgDQogICAiTmFtZSIgYXR0 cmlidXRlcyB0aGF0IGFyZSB1c2VkIGFzIGNvbXBvbmVudHMgb2Ygb2JqZWN0IGtleSB0eXBlcw0K ICAgTVVTVCBiZSB0cmVhdGVkIGNhc2UgaW5zZW5zaXRpdmUuDQoNClNlY3Rpb24gOCBzYXlzIHRo YXQgaW5wdXQgbWF5IGJlIGluIFVURi04LCBhbmQgc2VjdGlvbiAxMCBzYXlzIHlvdSBjYW4gdXNl IGFueSBsYW5ndWFnZSB5b3UgbGlrZS4gIFdoYXQgaXMgdGhlIGNhc2UtaW5zZW5zaXRpdmUgdHJl YXRtZW50IG9mIHRoZSBzdHJpbmcgIkVjb2xlIFBvbHl0ZWNobmlxdWUiPyAgQmVjYXVzZSB3aGVy ZSBJIGNvbWUgZnJvbSwgdGhlIGxvd2VyIGNhc2UgaXMgIsOpY29sZSBwb2x5dGVjaG5pcXVlIiwg YnV0IHRoYXQncyBub3Qgd2hhdCBVbmljb2RlIGNhc2UgZm9sZCBkb2VzLiAgVGhpcyByZXF1aXJl bWVudCBpbiA1LjIgbmVlZHMgYSBfbG90XyBtb3JlIGRldGFpbC4gIE9uZSB0aGluZyB5b3UgY291 bGQgZG8gaXMgd2hhdCBJRE5BIGRpZCwgYW5kIHNheSB0aGF0IGFueSBjaGFyYWN0ZXIgdGhhdCBp cyBub3Qgc3RhYmxlIHVuZGVyIGNhc2VGb2xkKGNhc2VGb2xkKE5GS0MoY3ApKSkgaXMgbm90IGFj Y2VwdGFibGUgZm9yIHVzZSBpbiBhIE5hbWUgYXR0cmlidXRlIHdoZXJlIHVzZWQgYXMgYSBjb21w b25lbnQgb2Ygb2JqZWN0IGtleSB0eXBlcy4gIFRoYXQncyBnb25uYSBiZSBzb21lIHdvcmssIHRo b3VnaC4gIFNlY3Rpb24gMTIgZGlkbid0IHNlZW0gdG8gdGVsbCBtZSBtb3JlIGFib3V0IHdoYXQg SSB3YW50ZWQgdG8ga25vdywgYnV0IGlmIEkgb3Zlcmxvb2tlZCBpdCBhIGZvcndhcmQgcmVmZXJl bmNlIGluIHRoZSBkb2Mgd291bGQgYmUgZW5vdWdoLg0KDQpTZWN0aW9uIDUuMzoNCg0KSSBmaW5k IGl0IHByZXR0eSBzdHJhbmdlIHRoYXQgdGhlIG1lc3NhZ2UgdHlwZXMgYXJlIG5vdCBhY3R1YWxs eSBwYXJ0IG9mIHRoZSBmcmFtZXdvcmsuICBPbmUgb2YgdGhlbSBpcyBwYXJ0aWN1bGFybHkgc3Ry YW5nZTogIlZlcnNpb24gbm90IHN1cHBvcnRlZCIuICBMZWF2aW5nIHRoYXQgdG8gdGhlIHByb3Rv Y29sIGRlZmluaXRpb24gZmVlbHMgd3JvbmcsIGJlY2F1c2UgYSBjbGllbnQgd2l0aCBhbiBvbGQg dmVyc2lvbiBvZiB0aGUgcHJvdG9jb2wgbWlnaHQgbm90IGJlIGFibGUgdG8gdW5kZXJzdGFuZCB0 aGUgbmV3IHNlcnZlcidzIHJlc3BvbnNlLg0KDQpBbHNvLCB3aHkgYXJlIHRoZXNlIFNIT1VMRHM6 DQoNCiAgIG8gICAgUmVzcG9uc2UgdHlwZSAiQXR0cmlidXRlIHZhbHVlIGludmFsaWQiIFNIT1VM RCBiZSB1c2VkIHdoZW5ldmVyDQogICAgICAgIGFuIGVsZW1lbnQgdmFsdWUgZG9lcyBub3QgYWRo ZXJlIHRvIGRhdGEgdmFsaWRhdGlvbiBydWxlcy4NCg0KICAgbyAgICBSZXNwb25zZSB0eXBlcyAi QXR0cmlidXRlIHZhbHVlIGludmFsaWQiIGFuZCAiT2JqZWN0IGRvZXMgbm90DQogICAgICAgIGV4 aXN0IiBNVVNUIE5PVCBiZSB1c2VkIGludGVyY2hhbmdlYWJseS4gIFJlc3BvbnNlIHR5cGUgIk9i amVjdA0KICAgICAgICBkb2VzIG5vdCBleGlzdCIgU0hPVUxEIGJlIHJldHVybmVkIGJ5IGFuIEFk ZC9EZWwvQWNjZXB0L1JlamVjdA0KICAgICAgICBvcGVyYXRpb24gd2hlbiB0aGUgZGF0YSBlbGVt ZW50KHMpIHVzZWQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYQ0KICAgICAgICBwcmUtZXhpc3Rpbmcg b2JqZWN0IGRvIG5vdCBleGlzdC4gIElmIHRoZSBkYXRhIGVsZW1lbnRzIHVzZWQgdG8NCiAgICAg ICAgdW5pcXVlbHkgaWRlbnRpZnkgYW4gb2JqZWN0IGFyZSBtYWxmb3JtZWQsIHRoZW4gcmVzcG9u c2UgdHlwZQ0KICAgICAgICAiQXR0cmlidXRlIHZhbHVlIGludmFsaWQiIFNIT1VMRCBiZSByZXR1 cm5lZC4NCj8NCg0KU2VjdGlvbiA2LjQ6DQoNCiAgIG8gICAgaG9zdE5hbWU6IEZ1bGx5IHF1YWxp ZmllZCBob3N0IG5hbWUgb2YgdGhlIG5hbWUgc2VydmVyLg0KDQpSZWFsbHkgZnVsbHktcXVhbGlm aWVkLCBvciByb290LXJlbGF0aXZlIHF1YWxpZmllZD8gIChMb3RzIG9mIHNwZWNzIGdldCB0aGlz IHdyb25nLCBhbmQgaXQncyBteSBuZXcgY3J1c2FkZS4pICBUaGF0IGlzLCBpcyBob3N0TmFtZSAi bnMxLmV4YW1wbGUuY29tIiBvciAibnMxLmV4YW1wbGUuY29tLiI/DQoNCiAgIG8gICAgaXBBZGRy OiBaZXJvIG9yIG1vcmUgb2JqZWN0cyBvZiB0eXBlIElwQWRkclR5cGUuICBFYWNoIG9iamVjdA0K ICAgICAgICBob2xkcyBhbiBJUCBBZGRyZXNzIGFuZCB0aGUgSVAgQWRkcmVzcyB0eXBlLCBJUHY0 IG9yIElQIHY2Lg0KDQpXaHkgaXMgdGhlIElQIGFkZHJlc3MgbmVlZGVkPyAgU2hvdWxkbid0IHlv dSBqdXN0IGxvb2sgdGhlIG5hbWUgdXAgaW4gdGhlIEROUz8NCg0KU2VjdGlvbiA3LjI6IFRoaXMg c2VjdGlvbiBhcHBlYXJzIGluIGVmZmVjdCB0byBjYXVzZSBhbnkgZGVsZXRpb24gdG8gY2FzY2Fk ZSwgc28gdGhhdCBpZiBhbiBvYmplY3QgaXMgZGVsZXRlZCBhbGwgcmVmZXJlbmNlcyB0byBpdCBn ZXQgZGVsZXRlZC4gIERvZXNuJ3QgdGhpcyBoYXZlIHRoZSBwb3RlbnRpYWwgZm9yIGEgZGVuaWFs IG9mIHNlcnZpY2U/ICAoSSBnZW51aW5lbHkgZG9uJ3Qga25vdyAtLSBJIHRoaW5rIEkgZG9uJ3Qg dW5kZXJzdGFuZCBlbm91Z2ggYWJvdXQgdGhlIHJlbGF0aW9uc2hpcHMgYW1vbmcgdmFyaW91cyBh Y3RvcnMgdG8gdW5kZXJzdGFuZCB3aGV0aGVyIHRoZXkgY2FuIGhhdmUNCmNyb3NzLWRlcGVuZGVu Y2llcy4pICANCg0KLS0NCkFuZHJldyBTdWxsaXZhbg0KRHluIExhYnMNCmFzdWxsaXZhbkBkeW4u Y29tDQo= From alexander.mayrhofer@nic.at Fri Sep 21 17:19: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 D305221F84F0 for ; Fri, 21 Sep 2012 17:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.972 X-Spam-Level: X-Spam-Status: No, score=-8.972 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4qSnNo4HRu2 for ; Fri, 21 Sep 2012 17:19:46 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8330E21F84EF for ; Fri, 21 Sep 2012 17:19:43 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.48 ; Sat, 22 Sep 2012 02:19:42 +0200 Received: from NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e]) by NICS-EXCH.sbg.nic.at ([fe80::486:1ecc:eabc:531e%12]) with mapi id 14.02.0247.003; Sat, 22 Sep 2012 02:19:39 +0200 From: Alexander Mayrhofer To: "drinks@ietf.org" Thread-Topic: WGLC comments on draft-ietf-drinks-spp-framework-02 Thread-Index: Ac2YVy7nKZNVZR64RTiMUP8dupG80A== Date: Sat, 22 Sep 2012 00:19:38 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE075096F35C4@NICS-EXCH.sbg.nic.at> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.3.107] Content-Type: multipart/alternative; boundary="_000_19F54F2956911544A32543B8A9BDE075096F35C4NICSEXCHsbgnica_" MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: [drinks] WGLC comments on draft-ietf-drinks-spp-framework-02 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: Sat, 22 Sep 2012 00:19:55 -0000 --_000_19F54F2956911544A32543B8A9BDE075096F35C4NICSEXCHsbgnica_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, here are my comments on the framework document. Most of them are nits or is= sues around references, duplicate text, etc. Luckily, i haven't found any s= ubstantial issues. All my comments are tagged with "AM>>", any other text i= s from the original draft to provide context: thanks, Alex ---- snip ---- Abstract This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data AM>> we use capitalized "Session Establishment Data" in the introduction AM>> section - stick to it here as well? The other terminology is AM>> capitalized as well.. [...] 1. Introduction Service providers and enterprises use registries to make session routing decisions for Voice over IP, SMS and MMS traffic exchanges. This document is narrowly focused on the provisioning framework for these registries. This framework prescribes a way for an entity to provision session-related data into a registry. The data being provisioned can be optionally shared with other participating peering entities. The requirements and use cases driving this framework have been documented in [RFC6461]. The reader is expected to be familiar with the terminology defined in the previously mentioned document. AM>> would remove the last sentence - general expectation from RFC readers? [...] Please note that the role of the "client" and the "server" only AM>> Would remove the "please note" [...] A "terminating" SIP Service Provider (SSP) provisions SED into the registry to be selectively shared with other peer SSPs. AM>> move the above paragraph up, between the Figure and the "The data AM>> provisioned"? Would reflect the logical order: 1) provision 2) use AM>> 3) redistribute. 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 AM>> Is there a difference between "look-up" and "lookup"? I vaguely AM>> remember some dicussion long time ago? [...] A key requirement for the SPPF is to be able to accommodate two basic deployment scenarios: 1. A resolution system returns a Look-Up Function (LUF) that comprises the target domain to assist in call routing (as described in [RFC5486]). In this case, the querying entity may use other means to perform the Location Routing Function (LRF) AM>> Strictly speaking, a system can not return a "Function" itself. Change AM>> that to "returns a Look-Up Function (LUF) response.."? Cartwright, et al. Expires January 17, 2013 [Page 5] Internet-Draft draft-drinks-spp-framework July 2012 which in turn helps determine the actual location of the Signaling Function in that domain. 2. A resolution system returns a Location Routing Function (LRF) that comprises the location (address) of the signaling function in the target domain (as described in [RFC5486]). AM>> same as above.. can't return "function" itself. In terms of framework design, SPPF is agnostic to the transport protocol. This document includes the specification of the data model and identifies, but does not specify, the means to enable protocol operations within a request and response structure. That aspect of the specification has been delegated to the "protocol" specification for the framework. To encourage interoperability, the framework supports extensibility aspects. AM>> Depends whether "interopability" means "interopability between AM>> various implementions of SPPF", or "interopability between SPPF AM>> and other systems". The second is true, the first probably not. Transport requirements are provided in this document to help with the selection of the optimum transport mechanism. The SPP Protocol over SOAP document identifies a protocol for SPPF that uses SOAP/HTTP as the transport mechanism. AM>> There should be a reference to the SOAP document at this point. [...] 2. Terminology [...] Client: An application that supports an SPPF client; it is sometimes referred to as a "registry client". AM>> I'm slightly confused... "Client" is the software, "SPPF client" AM>> is an entity, such as an organization? Has been some time since AM>> we discussed this, i guess. [...] Registrant: In this document we extend the definition of a Registrant based on [RFC4725]. The Registrant is the end-user, AM>> I understand from previous dicussions with the RFC authors that AM>> "we" is to be avoided in RFCs. Change that to "the definition .. AM>> .. is extended". [...] Registrar: In this document we extend the definition of a Registrar from [RFC4725]. A Registrar is an entity that performs provisioning operations on behalf of a Registrant by interacting with the Registry via SPPF operations. In other words the Registrar is the SPPF Client. The Registrar and Registrant roles are logically separate to allow, but not require, a single Registrar to perform provisioning operations on behalf of more than one Registrant. AM>> As above... avoid "we".. [...] 3.1. Framework Data Model The data model illustrated and described in Figure 2 defines the logical objects and the relationships between these objects that the SPPF protocol supports. SPPF defines the protocol operations through which an SPPF client populates a registry with these logical objects. Various clients belonging to different registrars may use the protocol for populating the registry's data. AM>> "Clients" instead of "clients", same for "Registrars" and "Registry" AM>> to identify it's meant to be terminology as defined above. AM>> However, given my point above, not sure it applies to "SPPF clients"? +-------------+ +-----------------+ | all object | |Egress Route: | | types | 0..n | rant, | +-------------+ +--| egrRteName, | |0..n / | pref, | | / | regxRewriteRule,| |2 / | ingrSedGrp, | AM>> I think the "2" above warrants some explaination - Short AM>> sentence that each object has a rant/rar attribute, and that's AM>> where that "2" comes from? +----------------------+ / | svcs | |Organization: | / +-----------------+ | orgId | / +----------------------+ / |0..n / | / |A SED Group is / |associated with / |zero or more / +---[abstract]----+ |Peering / | SED Record: | |Organizations / | rant, | | / | sedName, |0..n |0..n / | sedFunction, |------| +--------+--------------+0..n 0..n| isInSvc, | | |SED Group: |------------------| ttl | | | rant, | +-----------------+ | [...] (section 3.1) o SED Group: A SED Group contains a set of SED Record references, a set of Destination Group references, and a set of peering organization identifiers. This is used to establish a three part relationships between a set of Public Identifiers, the session establishment information (SED) shared across these Public Identifiers, and the list of peering organizations whose query responses from the resolution system may include the session establishment information contained in a given SED group. In addition, the sourceIdent element within a SED Group, in concert with the set of peering organization identifiers, enables fine-grained source based routing. For further details about the SED Group and source based routing, refer to the definitions and descriptions of the SED Group operations found later in this document. AM>> Reference to actual section, instead of "found later". o SED Record: A SED Record contains the data that a resolution system returns in response to a successful query for a Public Identifier. SED Records are generally associated with a SED Group when the SED within is not specific to a Public Identifier. To support the use cases defined in [RFC6461], SPPF framework AM>> "SPPF framework" has a redundant "framework". Occurs a few more AM>> times in the document. [...] o Egress Route: In a high-availability environment, the originating SSP likely has more than one egress paths to the ingress SBE of the target SSP. AM>> "SBE" is never expanded in the document. [...] 3.2. Time Value Some request and response messages in SPPF framework include time value(s) defined as type xs:dateTime, a built-in W3C XML Schema Datatype. Use of unqualified local time value is discouraged as it can lead to interoperability issues. The value of time attribute MUST BE expressed in Coordinated Universal Time (UTC) format without the timezone digits. AM>> The "BE" does not need to be capitalized. [...] 4.4. Authentication All SPPF objects are associated with a registrant identifier. SPPF Clients provisions SPPF objects on behalf of registrants. An authenticated SPP Client is a registrar. Therefore, the SPPF transport protocol MUST provide means for an SPPF server to authenticate an SPPF Client. AM>> Uppercase "registrant" and "registrar"? We also have "SPPF Clients" AM>> as well as "SPP Client" in the paragraph.. intended? [..] 4.5. Authorization After successful authentication of the SPPF client as a registrar the registry performs authorization checks to determine if the registrar is authorized to act on behalf of the Registrant whose identifier is included in the SPPF request. Refer to the Security Considerations section for further guidance. AM>> Uppercasing of "registrar", "registry"..? Same is true for many AM>> other subsequent spots in the draft. [...] 5.1. Basic Object Type and Organization Identifiers This section introduces the basic object type that most first class objects derive from. AM>> Looking at the paragraph below, the paragraph above (or at least the AM>> second part) seems redundant and contradictory ("most" vs. "all") All first class objects extend the basic object type BasicObjType that contains the identifier of the registrant organization that owns this object, the identifier of the registrar organization that created this object, the date and time that the object was created by the server, and the date and time that the object was last modified. AM>> We should add element names to the date/time descriptions above, AM>> otherwise the relation between text and elements is not clear. [...] The identifiers used for registrants (rant), registrars (rar), and peering organizations (peeringOrg) are instances of OrgIdType. The OrgIdType is defined as a string and all OrgIdType instances SHOULD follow the textual convention: "namespace:value" (for example "iana- en:32473"). See the IANA Consideration section for more details. AM>> peeringOrg does not occur in BasicObjType. This might be confusing, AM>> move that definition further down? [...] (Section 5.2.1) A Public Identity object MUST use attributes of PubIdKeyType for its unique identification . Refer the "Framework Data Model Objects" section of this document for a description of Public Identity object. AM>> Add proper reference to section.. 5.3. Response Message Types [...] | | way to indicate the Attribute Name and the | | | Attribute Value that identifies the object. | +---------------------+---------------------------------------------+ Table 1: Response Types AM>> The "Any conforming specification MUST... " is identical for all AM>> response types, and there's no exception. Therefore, this could AM>> be stated once in front of the table as well instead.. [...] 6.1. Destination Group As described in the introductory sections, a Destination Group represents a set of Public Identifiers with common session establishment information. The transport protocol MUST support the ability to Create, Modify, Get, and Delete Destination Groups (refer the "Framework Operations" section of this document for a generic description of various operations). AM>> Proper reference would be good. [...] o base: All first class objects extend BasicObjType that contains the ID of the registrant organization that owns this object, registrar organization that provisioned this object on behalf of the registrant, the date and time that the object was created by the server, and the date and time that the object was last modified. If the client passed in either the created date or the modification date, the server will ignore them. The server sets these two date/time values. AM>> The description of the "base" attribute seems a duplicate of the AM>> definition in section 5.1 - really needed here? The definition AM>> about ignoring create / modification details should be moved up? AM>> This applies to many more objects as well.. [page 22] o ext: Point of extensibility described in a previous section of this document. AM>> concrete reference would be better. 6.2. Public Identifier [...] SPPF identifies three types of Public Identifiers: telephone numbers (TN), routing numbers (RN), and URI type of Public Identifiers (like an email address). SPPF provides structures to manage a single TN, a contiguous range of TNs, and a TN prefix. The transport protocol MUST support the ability to Create, Modify, Get, and Delete Public Identifiers (refer the "Framework Operations" section of this document for a generic description of various operations). AM>> (Think i had a similar comment long time ago): I don't think "email" AM>> is a good example for a URI type PI, because email is not a session AM>> establishment protocol. "sip" would be more appropriate, imho. A Public Identity object MUST be uniquely identified by attributes as defined in the description of "PubIdKeyType" in the section "Derived Object Key Types" of this document. AM>> concrete reference, eg "in Section 5.2.2 of this document". The abstract XML schema type definition PubIDType is a generalization for the concrete Public Identifier schema types. PubIDType element 'dgName' represents the name of the destination group that a given Public Identifier MAY be a member of. The PubIDType object structure is defined as follows: AM>> I don't think the RFC2119 "MAY" is appropriate here. Should be lowerca= sed [...] A routing number is provisioned using the RNType, an extension of PubIDType. SSPs that possess the number portability data may be able AM>> Typo: "possess" [...] RNType has the following attributes: o rn: Routing Number used as the search key. o corInfo: Optional element of type CORInfoType. AM>> The "corInfo" definition does not provide more information than AM>> the schema snippet. Briefly mention its function instead AM>> (Same is true for remaining corInfo elements descriptions below) [...] 6.3. SED Group As described in the introductory sections, a SED Group represents a AM>> concrete reference [...] o sedFunction: As described in [RFC6461], SED or Session Establishment Data falls primarily into one of two categories or functions, LUF and LRF. To remove any ambiguity as to the function a SED record is intended to provide, this optional element allows the provisioning party to make his or her intentions explicit. AM>> would add the actual values in parantheses behind the functions: AM>> LUF ("lookup") etc ... [...] As described above, SED records are based on an abstract type: SedRecType. The concrete types that use SedRecType as an extension base are NAPTRType, NSType, and URIType. The definitions of these types are included below. The NAPTRType object is comprised of the data elements necessary for a NAPTR that contains routing information for a SED Group. The NSType object is comprised of the data elements necessary for a DNS name server that points to another DNS server that contains the desired routing information. The NSType is relevant only when the resolution protocol is ENUM. The URIType object is comprised of the data elements necessary to house a URI. AM>> Informative references to NAPTR and ENUM specifications? [...] 7.2. Delete Operation [...] o Destination Groups: When a destination group is deleted all public identifiers within that destination group must also be automatically deleted by the SPPF implementation as part of fulfilling the deletion request. And any references between that destination group and any SED group must be automatically removed by the SPPF implementation as part of fulfilling the deletion request. AM>> Deletion of a large DG can trigger deletion of millions of numbers.. AM>> Alternatively, we could just remove the references in the PIs? AM>> This has probably been discussed before? [...] 11. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URI assignments are requested. AM>> I think that "Two XML namespace URI assignments" would be more AM>> precise, because the sentence above could be interpreted as AM>> requests for URI schemes.. --_000_19F54F2956911544A32543B8A9BDE075096F35C4NICSEXCHsbgnica_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

here are my comments on the framework document. Most= of them are nits or issues around references, duplicate text, etc. Luckily= , i haven’t found any substantial issues. All my comments are tagged = with „AM>>“, any other text is from the original draft to provide context:

 

thanks,

 

Alex

 

---- snip ----

 

Abstract

 

   This document specifies the data model = and the overall structure for

   a framework to provision session establ= ishment data into Session Data

 

AM>> we use capitalized "Session Establis= hment Data" in the introduction

AM>> section - stick to it here as well? The o= ther terminology is

AM>> capitalized as well..

 

[...]

 

1.  Introduction

 

   Service providers and enterprises use r= egistries to make session

   routing decisions for Voice over IP, SM= S and MMS traffic exchanges.

   This document is narrowly focused on th= e provisioning framework for

   these registries.  This framework = prescribes a way for an entity to

   provision session-related data into a r= egistry.  The data being

   provisioned can be optionally shared wi= th other participating peering

   entities.  The requirements and us= e cases driving this framework have

   been documented in [RFC6461].  The= reader is expected to be familiar

   with the terminology defined in the pre= viously mentioned document.

 

AM>> would remove the last sentence - general = expectation from RFC readers?

  

[...]

 

   Please note that the role of the "= client" and the "server" only

  

AM>> Would remove the "please note"<= o:p>

 

[...]

 

   A "terminating" SIP Service P= rovider (SSP) provisions SED into the

   registry to be selectively shared with = other peer SSPs.

  

AM>> move the above paragraph up, between the = Figure and the "The data

AM>> provisioned"? Would reflect the logi= cal order: 1) provision 2) use

AM>> 3) redistribute.

 

   Subsequently, a registry may distribute= the provisioned data into

   local data repositories used for look-u= p queries (identifier -> URI)

   or for lookup and location resolution (= identifier -> URI -> ingress

  

AM>> Is there a difference between "look-= up" and "lookup"? I vaguely

AM>> remember some dicussion long time ago?

  

[...]

 

   A key requirement for the SPPF is to be= able to accommodate two basic

   deployment scenarios:

 

   1.  A resolution system returns a = Look-Up Function (LUF) that

       comprises the t= arget domain to assist in call routing (as

       described in [R= FC5486]).  In this case, the querying entity may

       use other means= to perform the Location Routing Function (LRF)

 

AM>> Strictly speaking, a system can not retur= n a "Function" itself. Change

AM>> that to "returns a Look-Up Function = (LUF) response.."?

 

 

Cartwright, et al.      Exp= ires January 17, 2013         =        [Page 5]

 

Internet-Draft      &n= bsp;  draft-drinks-spp-framework      &n= bsp;       July 2012

 

 

       which in turn h= elps determine the actual location of the

       Signaling Funct= ion in that domain.

 

   2.  A resolution system returns a = Location Routing Function (LRF)

       that comprises = the location (address) of the signaling function

       in the target d= omain (as described in [RFC5486]).

 

AM>> same as above.. can't return "functi= on" itself.

        &nbs= p;         

   In terms of framework design, SPPF= is agnostic to the transport

   protocol.  This document includes = the specification of the data model

   and identifies, but does not specify, t= he means to enable protocol

   operations within a request and respons= e structure.  That aspect of

   the specification has been delegated to= the "protocol" specification

   for the framework.  To encourage i= nteroperability, the framework

   supports extensibility aspects.

 

AM>> Depends whether "interopability"= ; means "interopability between

AM>> various implementions of SPPF", or &= quot;interopability between SPPF

AM>> and other systems". The second is tr= ue, the first probably not.

 

   Transport requirements are provided in = this document to help with the

   selection of the optimum transport mech= anism.  The SPP Protocol over

   SOAP document identifies a protocol for= SPPF that uses SOAP/HTTP as

   the transport mechanism.

 

AM>> There should be a reference to the SOAP d= ocument at this point.

 

[...]

 

2.  Terminology

 

[...]

  

   Client:   An application= that supports an SPPF client; it is

      sometimes referred to= as a "registry client".

 

AM>> I'm slightly confused... "Client&quo= t; is the software, "SPPF client"

AM>> is an entity, such as an organization? Ha= s been some time since

AM>> we discussed this, i guess.

 

[...]

 

   Registrant:   In this documen= t we extend the definition of a

      Registrant based on [= RFC4725].  The Registrant is the end-user,

        &nbs= p;        

AM>> I understand from previous dicussions wit= h the RFC authors that

AM>> "we" is to be avoided in RFCs. = Change that to "the definition ..

AM>> .. is extended".

 

[...]

 

   Registrar:   In this document= we extend the definition of a Registrar

      from [RFC4725]. = A Registrar is an entity that performs

      provisioning operatio= ns on behalf of a Registrant by interacting

      with the Registry via= SPPF operations.  In other words the

      Registrar is the SPPF= Client.  The Registrar and Registrant roles

      are logically separat= e to allow, but not require, a single

      Registrar to perform = provisioning operations on behalf of more

      than one Registrant.<= o:p>

 

AM>> As above... avoid "we"..

        &nbs= p;        

[...]

 

3.1.  Framework Data Model

 

   The data model illustrated and describe= d in Figure 2 defines the

   logical objects and the relationships b= etween these objects that the

   SPPF protocol supports.  SPPF defi= nes the protocol operations through

   which an SPPF client populates a regist= ry with these logical objects.

   Various clients belonging to different = registrars may use the

   protocol for populating the registry's = data.

 

AM>> "Clients" instead of "clie= nts", same for "Registrars" and "Registry"

AM>> to identify it's meant to be terminology = as defined above.

AM>> However, given my point above, not sure i= t applies to "SPPF clients"?

  

       +-----= --------+          &n= bsp;            &nbs= p;+-----------------+

       | all object&nb= sp; |           &nbs= p;            |Egres= s Route:    |

       | types &n= bsp;     |       &nb= sp;           0..n | rant= ,           |<= /p>

       +----------= ---+           &= nbsp;         +--| egrRteName,&= nbsp;    |

        &nbs= p;    |0..n        &= nbsp;            &nb= sp;  /   | pref,      &nb= sp;    |

        &nbs= p;    |         = ;            &n= bsp;     /    | regxRewriteRule,|

        &nbs= p;    |2        &nbs= p;            &= nbsp;   /     | ingrSedGrp,   =   |

        &nbs= p;            &= nbsp;           &nbs= p;             =

AM>> I think the "2" above warrants = some explaination - Short

AM>> sentence that each object has a rant/rar = attribute, and that's

AM>> where that "2" comes from?=

        &nbs= p;            &= nbsp;           &nbs= p;             =

   +----------------------+&n= bsp;           / &nb= sp;    | svcs        = ;    |

   |Organization:    &= nbsp;    |        &n= bsp;  /       +-----------------+= ;

   | orgId     &n= bsp;          |  &nb= sp;       /

   +----------------------+ &= nbsp;       /

        &nbs= p; |0..n           &= nbsp;        /

        &nbs= p; |            = ;           /<= /p>

        &nbs= p; |A SED Group is        /

        &nbs= p; |associated with      /

        &nbs= p; |zero or more        /  &nb= sp;           +---[ab= stract]----+

        &nbs= p; |Peering          &nbs= p; /            = ;   | SED Record:     |

        &nbs= p; |Organizations     /     &n= bsp;          |  rant,&nb= sp;         |

        &nbs= p; |            = ;     /        =          |  sedName, &nbs= p;     |0..n

        &nbs= p; |0..n            = /            &n= bsp;     |  sedFunction,   |------|=

   +--------+--------------+0.= .n          0..n|  isInSv= c,       |      |

   |SED Group:    &nbs= p;        |------------------|  ttl=             | &= nbsp;    |

   |  rant,    &n= bsp;           | &nb= sp;            =     +-----------------+     = ; |

  

[...]

 

(section 3.1)

 

   o  SED Group:

      A SED Group contains = a set of SED Record references, a set of

      Destination Group ref= erences, and a set of peering organization

      identifiers.  Th= is is used to establish a three part relationships

      between a set of Publ= ic Identifiers, the session establishment

      information (SED) sha= red across these Public Identifiers, and the

      list of peering organ= izations whose query responses from the

      resolution system may= include the session establishment

      information contained= in a given SED group.  In addition, the

      sourceIdent element w= ithin a SED Group, in concert with the set of

      peering organization = identifiers, enables fine-grained source

      based routing.  = For further details about the SED Group and source

      based routing, refer = to the definitions and descriptions of the

      SED Group operations = found later in this document.

 

AM>> Reference to actual section, instead of &= quot;found later".

        &nbs= p;        

   o  SED Record:

      A SED Record contains= the data that a resolution system returns in

      response to a success= ful query for a Public Identifier.  SED

      Records are generally= associated with a SED Group when the SED

      within is not specifi= c to a Public Identifier.

      To support the use ca= ses defined in [RFC6461], SPPF framework

        &nbs= p;        

AM>> "SPPF framework" has a redundan= t "framework". Occurs a few more

AM>> times in the document.

 

[...]

 

   o  Egress Route:

      In a high-availabilit= y environment, the originating SSP likely has

      more than one egress = paths to the ingress SBE of the target SSP.

        &nbs= p;        

AM>> "SBE" is never expanded in the = document.

 

[...]

 

3.2.  Time Value

 

   Some request and response messages in S= PPF framework include time

   value(s) defined as type xs:dateTime, a= built-in W3C XML Schema

   Datatype.  Use of unqualified loca= l time value is discouraged as it

   can lead to interoperability issues.&nb= sp; The value of time attribute

   MUST BE expressed in Coordinated Univer= sal Time (UTC) format without

   the timezone digits.

 

AM>> The "BE" does not need to be ca= pitalized.

 

[...]  

 

4.4.  Authentication

 

   All SPPF objects are associated with a = registrant identifier.  SPPF

   Clients provisions SPPF objects on beha= lf of registrants.  An

   authenticated SPP Client is a registrar= .  Therefore, the SPPF

   transport protocol MUST provide means f= or an SPPF server to

   authenticate an SPPF Client.=

 

AM>> Uppercase "registrant" and &quo= t;registrar"? We also have "SPPF Clients"

AM>> as well as "SPP Client" in the = paragraph.. intended?

 

[..]

 

4.5.  Authorization

 

   After successful authentication of the = SPPF client as a registrar the

   registry performs authorization checks = to determine if the registrar

   is authorized to act on behalf of the R= egistrant whose identifier is

   included in the SPPF request.  Ref= er to the Security Considerations

   section for further guidance.

 

AM>> Uppercasing of "registrar", &qu= ot;registry"..? Same is true for many

AM>> other subsequent spots in the draft.=

 

[...]

 

5.1.  Basic Object Type and Organization Identi= fiers

 

   This section introduces the basic objec= t type that most first class

   objects derive from.

 

AM>> Looking at the paragraph below, the parag= raph above (or at least the

AM>> second part) seems redundant and contradi= ctory ("most" vs. "all")

  

   All first class objects extend the= basic object type BasicObjType

   that contains the identifier of the reg= istrant organization that owns

   this object, the identifier of the regi= strar organization that

   created this object, the date and time = that the object was created by

   the server, and the date and time that = the object was last modified.

 

AM>> We should add element names to the date/t= ime descriptions above,

AM>> otherwise the relation between text and e= lements is not clear.

  

[...]

 

   The identifiers used for registrants (r= ant), registrars (rar), and

   peering organizations (peeringOrg) are = instances of OrgIdType.  The

   OrgIdType is defined as a string and al= l OrgIdType instances SHOULD

   follow the textual convention: "na= mespace:value" (for example "iana-

   en:32473").  See the IANA Con= sideration section for more details.

 

AM>> peeringOrg does not occur in BasicObjType= . This might be confusing,

AM>> move that definition further down?

 

[...]

 

(Section 5.2.1)

 

   A Public Identity object MUST use attri= butes of PubIdKeyType for its

   unique identification .  Refer the= "Framework Data Model Objects"

   section of this document for a descript= ion of Public Identity object.

 

AM>> Add proper reference to section..

  

5.3.  Response Message Types

 

[...]

 

   |      &n= bsp;            = ;  | way to indicate the Attribute Name and the  |

   |      &n= bsp;            = ;  | Attribute Value that identifies the object. |

   +---------------------+--------= -------------------------------------+

 

        &nbs= p;            &= nbsp;    Table 1: Response Types

 

AM>> The "Any conforming specification MU= ST... " is identical for all

AM>> response types, and there's no exception.= Therefore, this could

AM>> be stated once in front of the table as w= ell instead..

 

[...]

 

6.1.  Destination Group

 

   As described in the introductory sectio= ns, a Destination Group

   represents a set of Public Identifiers = with common session

   establishment information.  The tr= ansport protocol MUST support the

   ability to Create, Modify, Get, and Del= ete Destination Groups (refer

   the "Framework Operations" se= ction of this document for a generic

   description of various operations).

 

AM>> Proper reference would be good.

 

[...]

  

   o    base: All firs= t class objects extend BasicObjType that contains

        the ID of= the registrant organization that owns this object,

        registrar= organization that provisioned this object on behalf of

        the regis= trant, the date and time that the object was created by

        the serve= r, and the date and time that the object was last

        modified.=   If the client passed in either the created date or

        the modif= ication date, the server will ignore them.  The server

        sets thes= e two date/time values.

 

AM>> The description of the "base" a= ttribute seems a duplicate of the

AM>> definition in section 5.1 - really needed= here? The definition

AM>> about ignoring create / modification deta= ils should be moved up?

AM>> This applies to many more objects as well= ..

        &nbs= p;            &= nbsp;        

[page 22]

 

   o    ext: Point of exten= sibility described in a previous section of

        this docu= ment.

 

AM>> concrete reference would be better.<= /o:p>

 

6.2.  Public Identifier

 

[...]

 

   SPPF identifies three types of Public I= dentifiers: telephone numbers

   (TN), routing numbers (RN), and URI typ= e of Public Identifiers (like

   an email address).  SPPF provides = structures to manage a single TN, a

   contiguous range of TNs, and a TN prefi= x.  The transport protocol

   MUST support the ability to Create, Mod= ify, Get, and Delete Public

   Identifiers (refer the "Framework = Operations" section of this

   document for a generic description of v= arious operations).

 

AM>> (Think i had a similar comment long time = ago): I don't think "email"

AM>> is a good example for a URI type PI, beca= use email is not a session

AM>> establishment protocol. "sip" w= ould be more appropriate, imho.

 

   A Public Identity object MUST be unique= ly identified by attributes as

   defined in the description of "Pub= IdKeyType" in the section "Derived

   Object Key Types" of this document= .

  

AM>> concrete reference, eg "in Section 5= .2.2 of this document".

 

   The abstract XML schema type definition= PubIDType is a generalization

   for the concrete Public Identifier sche= ma types.  PubIDType element

   'dgName' represents the name of the des= tination group that a given

   Public Identifier MAY be a member of.&n= bsp; The PubIDType object structure

   is defined as follows:

 

AM>> I don't think the RFC2119 "MAY"= is appropriate here. Should be lowercased

 

[...]

 

   A routing number is provisioned using t= he RNType, an extension of

   PubIDType.  SSPs that possess the = number portability data may be able

  

AM>> Typo: "possess"

 

[...]

 

   RNType has the following attributes:

 

   o    rn: Routing Number = used as the search key.

 

   o    corInfo: Optional &= lt;corInfo> element of type CORInfoType.

 

AM>> The "corInfo" definition does n= ot provide more information than

AM>> the schema snippet. Briefly mention its f= unction instead

AM>> (Same is true for remaining corInfo eleme= nts descriptions below)

 

[...]

  

6.3.  SED Group

 

   As described in the introductory sectio= ns, a SED Group represents a

  

AM>> concrete reference

 

[...]

 

   o    sedFunction: As des= cribed in [RFC6461], SED or Session

        Establish= ment Data falls primarily into one of two categories or

        functions= , LUF and LRF.  To remove any ambiguity as to the

        function = a SED record is intended to provide, this optional

        element a= llows the provisioning party to make his or her

        intention= s explicit.

 

AM>> would add the actual values in paranthese= s behind the functions:

AM>> LUF ("lookup") etc ...

 

[...]

 

   As described above, SED records are bas= ed on an abstract type:

   SedRecType.  The concrete types th= at use SedRecType as an extension

   base are NAPTRType, NSType, and URIType= .  The definitions of these

   types are included below.  The NAP= TRType object is comprised of the

   data elements necessary for a NAPTR tha= t contains routing information

   for a SED Group.  The NSType objec= t is comprised of the data elements

   necessary for a DNS name server that po= ints to another DNS server

   that contains the desired routing infor= mation.  The NSType is

   relevant only when the resolution proto= col is ENUM.  The URIType

   object is comprised of the data element= s necessary to house a URI.

 

AM>> Informative references to NAPTR and ENUM = specifications?

 

[...]

 

7.2.  Delete Operation

 

[...]

 

   o    Destination Groups:= When a destination group is deleted all

        public id= entifiers within that destination group must also be

        automatic= ally deleted by the SPPF implementation as part of

        fulfillin= g the deletion request.  And any references between

        that dest= ination group and any SED group must be automatically

        removed b= y the SPPF implementation as part of fulfilling the

        deletion = request.

 

AM>> Deletion of a large DG can trigger deleti= on of millions of numbers..

AM>> Alternatively, we could just remove the r= eferences in the PIs?

AM>> This has probably been discussed before?<= o:p>

        &nbs= p;            &= nbsp;        

[...]

 

11.  IANA Considerations

 

   This document uses URNs to describe XML= namespaces and XML schemas

   conforming to a registry mechanism desc= ribed in [RFC3688].

 

   Two URI assignments are requested.=

  

AM>> I think that "Two XML namespace URI = assignments" would be more

AM>> precise, because the sentence above could= be interpreted as

AM>> requests for URI schemes..

 

--_000_19F54F2956911544A32543B8A9BDE075096F35C4NICSEXCHsbgnica_-- From mmaharishi@tnsi.com Fri Sep 21 19:05:59 2012 Return-Path: X-Original-To: drinks@ietfa.amsl.com Delivered-To: drinks@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CF021F84F5 for ; Fri, 21 Sep 2012 19:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPovosiZReVZ for ; Fri, 21 Sep 2012 19:05:57 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id C565C21F84F8 for ; Fri, 21 Sep 2012 19:05:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EANwbXVCsEQfn/2dsb2JhbABFgkuyfwGJYIIgAQEFLT4eAgEIEQQBASQEBzIUCQgBAQQTCAGIB7kzixwUBoUsYAOWeZIQgT4J X-IronPort-AV: E=Sophos;i="4.80,465,1344207600"; d="scan'208,217";a="1555379" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 22 Sep 2012 03:05:57 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 21 Sep 2012 22:05:50 -0400 From: "Maharishi, Manjul" To: "Drinks@ietf.org" Date: Fri, 21 Sep 2012 22:05:47 -0400 Thread-Topic: [drinks] Extension of WGLC for I-Ds draft-ietf-drinks-spp-framework-02.txt and draft-ietf-drinks-spp-protocol-over-soap-02.txt Thread-Index: Ac2NKdeoVzxAZMxlTsSBa48iPLVWBwLPKtqw Message-ID: <6D4D683E163CA147B07281DB6D7111291558396B44@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6D4D683E163CA147B07281DB6D7111291558396B44TNSMAILNAwin2_" MIME-Version: 1.0 Subject: Re: [drinks] Extension of WGLC for I-Ds draft-ietf-drinks-spp-framework-02.txt and draft-ietf-drinks-spp-protocol-over-soap-02.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 02:05:59 -0000 --_000_6D4D683E163CA147B07281DB6D7111291558396B44TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also re-reviewed both these I-Ds. I don't have anything additional commen= ts on top of what was commented by David Schwartz and Alex Mayrhofer earlie= r today. Manjul From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Sumanth Channabasappa Sent: Friday, September 07, 2012 2:52 PM To: Drinks@ietf.org Subject: [drinks] Extension of WGLC for I-Ds draft-ietf-drinks-spp-framewor= k-02.txt and draft-ietf-drinks-spp-protocol-over-soap-02.txt WG Participants, We'd like to announce an extension for the following I-Ds: http://tools.ietf.org/id/draft-ietf-drinks-spp-framework-02.txt http://tools.ietf.org/id/draft-ietf-drinks-spp-protocol-over-soap-02.txt Thus, we are now requesting any and all feedback by Sep 21, 2012, 23:59 UTC= . -- As you are aware we originally announced WGLC in August. See: http://www.ietf.org/mail-archive/web/drinks/current/msg01216.html http://www.ietf.org/mail-archive/web/drinks/current/msg01217.html However, we have received limited feedback so far (one from Paul Hoffman; t= hanks). Given this, we reached out to the design team and the expert review= ers and it turns out that August was a busy travel/vacation month - resulti= ng in a request for more time. Please provide any and all feedback over the= next couple of weeks. Please refer to the original announcements for addit= ional, useful, information (e.g., history of the I-Ds). Regards, Alex and Sumanth (as Chairs) ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_6D4D683E163CA147B07281DB6D7111291558396B44TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also re-reviewed both t= hese I-Ds. I don’t have anything additional comments on top of what w= as commented by David Schwartz and Alex Mayrhofer earlier today.=

 <= /p>

Manjul<= /p>

 <= /p>

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Sumanth Channabasappa
Sent: Friday, September 07, 2012 2:52 PM
To: Drinks@ietf.org
Subject: [drinks] Extension of WGLC for I-Ds draft-ietf-drinks-spp-f= ramework-02.txt and draft-ietf-drinks-spp-protocol-over-soap-02.txt

 

WG Participants,

 

We'd like to announce an extension for the following I-= Ds: 

 

=  

= Thus, we are now requesting any and all feedback by Sep 21, 2012, 23:5= 9 UTC.

=  

= --

=  

= As you are aware we originally announced WGLC in August. See: 

=  

=  

= However, we have received limited feedback so far (one from Paul Hoffman; t= hanks). Given this, we reached out to the design team and the expert reviewers and it turns out that August was a busy travel/vacati= on month - resulting in a request for more time. Please provide any and all= feedback over the next couple of weeks. Please refer to the original annou= ncements for additional, useful, information (e.g., history of the I–Ds). 

=  

= Regards,

= Alex and Sumanth (as Chairs)

=  

=  


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_6D4D683E163CA147B07281DB6D7111291558396B44TNSMAILNAwin2_-- From syedwasimali@gmail.com Fri Sep 21 22:26:49 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 38AA321F8645 for ; Fri, 21 Sep 2012 22:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToxUHUyStkmO for ; Fri, 21 Sep 2012 22:26:48 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B10F221F8622 for ; Fri, 21 Sep 2012 22:26:48 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so4958133vbb.31 for ; Fri, 21 Sep 2012 22:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:mime-version:date:message-id:subject:to:content-type; bh=xSTR2yW0uY7PaIRTfVAhTxymdbon9nuP1jWmY7tUCkc=; b=TiZISOmWYjHO+AiaoWBgFok5kGLfySwr20R9BnvBrOcIGaYPzElLrgWck32Ag2J95l Yt36yOrC2GNGcxMCgok07bJbWe53m2+2L+Ryb+QY33cRponH5lnq4j8bwZyPqoFcXLeI GL7CbBiO/gcq3PbUno531NRzqsRuT01ntixSGWN31pqf9BSPgCZtV6OpZ4tPS2C+Oa7f h25XwomSwojkJKJ8T4ZOHaD5q3Hv+XOK14FM8DN2kwSRvA7yHmIEgHicC0Yke/UAVH9n GGzln8BCsirTRLN29s+ywzDJf0NHcJySZ+gI0+/B6GE12hmoMzTHNGgwJtpWA4Iqk6oZ RVHA== Received: by 10.221.11.71 with SMTP id pd7mr4205897vcb.45.1348291608178; Fri, 21 Sep 2012 22:26:48 -0700 (PDT) From: Syed Ali Mime-Version: 1.0 (1.0) Date: Fri, 21 Sep 2012 22:26:39 -0700 Message-ID: <2623838818902169821@unknownmsgid> To: "drinks@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [drinks] reviewed the soap transport document 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: Sat, 22 Sep 2012 05:26:49 -0000 Hi, I just wanted to note that i reviewed the XML examples in the soap transport document for correctness and to make sure that they conform to the schema. I don't have any issues to report at this time. Thanks, -Syed From vbhatia@tnsi.com Wed Sep 26 07:02:27 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 B2BB521F8699 for ; Wed, 26 Sep 2012 07:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45OU6du1hyUx for ; Wed, 26 Sep 2012 07:02:20 -0700 (PDT) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC86D21F879F for ; Wed, 26 Sep 2012 07:02:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EACkKY1CsEQfn/2dsb2JhbAA8CYJLvRaCIAEBBRoNBjoLBxACAQgOAwQBASEBBgcyFAkIAQEEDgUIhgm8E4sYEQmFD2ADqReBRw X-IronPort-AV: E=Sophos;i="4.80,490,1344207600"; d="scan'208,217";a="1563916" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 26 Sep 2012 15:02:23 +0100 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 26 Sep 2012 10:02:15 -0400 From: "Bhatia, Vikas" To: David Schwartz Date: Wed, 26 Sep 2012 10:02:13 -0400 Thread-Topic: Comments to the WGLC on SPPF document Thread-Index: Ac2YCRoeieRionA9Sem0GjWxRrCb/gDQp4OA Message-ID: References: <2B7C55FC-88A3-4988-9173-9E740889357A@xconnect.net> In-Reply-To: <2B7C55FC-88A3-4988-9173-9E740889357A@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_B4254E341B54864B92D28BC2138A9DC3031821BCBDTNSMAILNAwin2_" MIME-Version: 1.0 Cc: "drinks@ietf.org" Subject: Re: [drinks] Comments to the WGLC on SPPF document 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, 26 Sep 2012 14:02:27 -0000 --_000_B4254E341B54864B92D28BC2138A9DC3031821BCBDTNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Most part it seems fine. Some of my comments...Please see inline. Thanks, Vikas From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= David Schwartz Sent: Friday, September 21, 2012 10:55 AM To: drinks@ietf.org WG Subject: [drinks] Comments to the WGLC on SPPF document Almost ALL of these comments are typo/style and general "nit" comments. Note that for ease of change tracking I added ">> text <<" to indicate the = need for removal of some text and "<< text >>" to indicate the need to add= some text. ***************************************************************************= ********************************************************** Abstract old: "The provisioned data is typically used by network elements for session >>p= eering<<" new: "The provisioned data is typically used by network elements for session <>" 1. Introduction old: "Service providers and enterprises use registries to make session routing decisions for Voice over IP, SMS and MMS traffic exchanges..." new: "Service providers and enterprises use <> regist= ries to make session routing decisions for Voice over IP, SMS and MMS traffic exchanges..." [VB:] "routing databases" ..is "SED databases" a better term?..in line wit= h your subsequent definition of SPPF server "The server typically operates = a master database of Session Establishment Data (SED)" old: "Three types of provisioning flows have been described in the use case document: client to registry >>provisioning<<, registry to local data repository and registry to registry." new: "Three types of provisioning flows have been described in the use case document: client to registry, registry to local data repository and registry to registry." old: "This document addresses client to registry aspect to fulfill the need to provision Session Establishment Data (SED)." new: "This document addresses the client to registry <> enabling the provisioning of Session Establishment Data (SED)." old: "The data provisioned for session establishment is typically used by various downstream SIP signaling systems to route a call to the next hop associated with the called domain. These systems typically use a local data store ("Local Data Repository") as their source of session routing information." new: "The data provisioned for session establishment is <> typically used by various downstream SIP sign= aling systems to route a call to the next hop associated with the called domain." old: "Subsequently, a registry may distribute the provisioned data into local data repositories, used for lookup 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)." new: "Subsequently, a registry may distribute the provisioned data into local data repositories <>" old: "Transport requirements are provided in this document to help with the selection of the optimum transport mechanism. The SPP Protocol over SOAP document identifies a protocol for SPPF that uses SOAP/HTTP as the transport mechanism." new: "Transport requirements are provided in this document to help with the selection of the optimum transport mechanism." /* this second sentence creates a dependency on the SOAP document so imho i= t should be removed */ [VB:] I tend to agree and mentioned this in the past as well. imo, we shoul= d not have any references to the SOAP document in Framework document. old "Section 5 describes the base framework data structures, the generic response types that MUST be supported by a conforming "protocol" specification, and the basic object type most first class objects extend from;" new: "Section 5 describes the base framework data structures, the generic response types that MUST be supported by a conforming <> "protocol" specification, and the basic object type m= ost first class objects extend from;" old: " o Section 6 detailed description of the data model object specifications;" new: " o Section 6 <> detailed description of the data model ob= ject specifications; << o Section 7 describes the operations that are supported by the data= model o Sections 9 - 11 discuss security, internationalization and IANA c= onsiderations >>" 2. Terminology old: "SPDP: Session Peering Distribution Protocol, the protocol used to distribute data to Local Data Repository (see arrow labeled "2." in Figure 1 of [RFC6461])." new: /* remove as this is not really discussed anywhere in the document */ old: "Client: An application that >>supports an SPPF client<<; it is sometimes referred to as a "registry client"." new: "Client: <> an application that <>; it is sometimes referred to as a "registry client". Server: <> an application that receives a provisioning request and responds accordingly. The server typically operates a master database of Session Establishment Data (SED) for one or more Registrants. In the context of SPPF, the provisioning server is referred to as a Registry. Registry: a provisioning server." 3. Framework High Level Design old: "The data model is defined along with all the objects manipulated by >>the protocol<< and their relationships." new: "The data model is defined along with all the objects manipulated by <> protocol and their relationships." [VB:] typo on "transport" .. 3.1. Framework Data Model old: "The data model illustrated and described in Figure 2 defines the logical objects and the relationships between these objects >>that the SPPF protocol supports<<." new: "The data model illustrated and described in Figure 2 defines the logical objects and the relationships between these objects supported by SPPF." old: "SPPF defines >>the<< protocol operations through which an SPPF client populates a registry with these logical objects. Various clients belonging to different registrars may >>use the protocol for populating the registry's data<<." new: "SPPF defines protocol operations through which an SPPF client populates a registry with these logical objects. Various clients belonging to different registrars may provision data into the registry using a conforming transport protocol implementing these operations." old: in figure, the Public Identifier has an element called "sedRecRef" - this n= eeds to be removed new: the TN element needs to have this element 5.1. Basic Object Type and Organization Identifiers old: "The identifiers used for registrants (rant), registrars (rar), and peering organizations (peeringOrg) are instances of OrgIdType." new: The identifiers used for registrants (rant) and registrars (rar) are instan= ces of OrgIdType. /* no need to introduce peeringOrg over here - it just serves to confuse. M= ove the peeringOrg comment to where its mentioned */ 5.2. Various Object Key Types old: ">>In addition,<< an object's unique identity is required to Delete or Get the details of an object." new: "<> an object's unique identity is required to Delete or Get the details of an object." old: \""Name" attributes that are used as components of object key types MUST be treated case insensitive." new: \""Name" attributes that are used as components of object key types MUST be treated <> case insensitive." 5.2.2. Derived Object Key Types old: "and defined in there own abstract key types. Because these object key types are abstract, these MUST be specified in a concrete form in any conforming SPPF "protocol" specification." new: "and defined in there own abstract key types. Because these object key types are abstract, these MUST be specified in a concrete form in any SPPF conforming <> protocol specification." old: The >>.<> protocol" specification and im= plemented by a conforming SPPF server." 6. Framework Data Model Objects old: "However, the specification of the data structures necessary to support each command is delegated to >>the "protocol"<< specification." New: "However, the specification of the data structures necessary to support each command is delegated to <> specification." 6.2. Public Identifier old: /* No XML describing CORInfoType in the TNTYpe description - yet elements = of this type are discussed in descriptive text */ new: add before the "NumberValType" " " Old: "RNType has the following attributes: ... o corInfo: Optional element of type CORInfoType." New: "RNType has the following attributes: ... o corInfo: corInfo is an optional parameter of type CORInfoType that allows the registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067])." Old: "TNRType has the following attributes: ... o corInfo: Optional element of type CORInfoType." New: "TNRType has the following attributes: ... o corInfo: corInfo is an optional parameter of type CORInfoType that allows the registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067])." Old: "TNPType has the following attributes: ... o corInfo: Optional element of type CORInfoType." New: "TNPType has the following attributes: ... o corInfo: corInfo is an optional parameter of type CORInfoType that allows the registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067])." Old: /* in the definition of URIPubIdType there is an "ext" element whereas in a= ll other pubIDs there isn't - why? */ New: remove... "" 6.2. SED Group Old: "As described in the introductory sections, a SED Group represents a combined grouping of Destination Groups containing a set of Public Identifiers >>with common Session Establishment Data(SED)<<, The common Session Establishment Data Records, and the list of peer organizations that have access to these public identifiers using the associated SED information." New: /* too verbose */ "As described in the introductory sections, a SED Group represents a combined grouping of Destination Groups (containing a set of Public Identifiers), The common Session Establishment Data Records, and the list of peer organizations that have access to this gouging (public identifiers using the associated SED information.)" [VB:] gouging -> grouping? Old: /* in the definition of SedGrpType there is an "ext" element - why? */ New: remove... "" [VB:] the same reason I believe as for all other objects in SPPF, like "Bas= icObjType", "EgrRteType"..Extensibility of these schema elements to provide= supplemental information to the server...( even though these were added mu= ch before I came onboard ...) Old: /* no mention of peeringOrg type */ New: "Note that the identifier used for peering organization (peeringOrg) is an = instance of OrgIdType." 6.4. SED Record Old: "The data provisioned in a registry can be leveraged for many purposes and queried using various protocols including SIP, ENUM and others. As such, the resolution data represented by the >>SedRecords<< must be in a form suitable for transport using one of these protocols. New: "The data provisioned in a registry can be leveraged for many purposes and queried using various protocols including SIP, ENUM and others. As such, the resolution data represented by the <> must be in a form suitable for transport using one of these protocols. 6.4. SED Record Old: "In a high-availability environment, the originating SSP likely has more than one egress path>>s<< to the ingress SBE of the target SSP." New: "In a high-availability environment, the originating SSP likely has more than one egress path to the ingress SBE of the target SSP." Old: "A Egress Route object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in the section "Generic Object Key Type" of this document." New: "A<> Egress Route object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in the section "Generic Object Key Type" of this document." 7. Framework Operations 7.1/2/3/4/5/6 Old: "Any conforming "protocol" specification MUST provide..." New: "Any conforming <> specification MUST provide..." 9.3.1 DoS Issues Inherited from Transport Mechanism Old: "The typical deployment scenario for SPPF is to have servers in a managed facility, and therefor techniques such as Network Ingress Filtering ([RFC2609]) are generally applicable." New: "The typical deployment scenario for SPPF is to have servers in a managed facility, and therefor<> techniques such as Network Ingress Filtering ([RFC2609]) are generally applicable." 13 Acknowledgments /* Jeremy Barkan participated in many discussions and should be acknowledge= d */ ________________________________ 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_B4254E341B54864B92D28BC2138A9DC3031821BCBDTNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Most part it seems fine. Some of my comments…Please se= e inline.

 

Thanks,

Vikas

 

From: drinks-b= ounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of David Schwartz
Sent: Friday, September 21, 2012 10:55 AM
To: drinks@ietf.org WG
Subject: [drinks] Comments to the WGLC on SPPF document

 

Almost ALL of these comments are typo/style and gene= ral "nit" comments.

 

Note that for ease of change tracking I added "= >> text <<" to indicate the need for removal of some text = and "<<  text >>" to indicate the need to add so= me text.

 

****************************************************= ***************************************************************************= ******

 

Abstract 

 

old: 

= "The provisioned data is typically used by network elements for sessio= n >>peering<<"

 

new:

= "The provisioned data is typically used by network elements for sessio= n <<establishment>>"

=  

= 1. Introduction

=  

old: 

= "Service providers and enterprises use registries to make session=

= routing decisions for Voice over IP, SMS and MMS traffic exchanges…&q= uot;

=  

new:

= "Service providers and enterprises use <<routing databases know = as>> registries to make session

= routing decisions for Voice over IP, SMS and MMS traffic exchanges…&q= uot; 

[VB:] “routing databases” ..is  “SED = databases” a better term?..in line with your subsequent definition of= SPPF server “The server typically operates a master database of 

      Session Establishment Data (SED)”=

=  

old: 

= "Three types of provisioning flows have been described in the use case=

= document: client to registry >>provisioning<<, registry to loca= l data

= repository and registry to registry."  

=  

= new:

= "Three types of provisioning flows have been described in the use case=

= document: client to registry, registry to local data

= repository and registry to registry."  

=  

old: 

= "This document addresses client

= to registry aspect to fulfill the need to provision Session

= Establishment Data (SED)."

 

new:

= "This document addresses the client

= to registry <<flow>> enabling the provisioning of Session<= /o:p>

= Establishment Data (SED)."

=  

old: 

= "The data provisioned for session establishment is typically used by

= various downstream SIP signaling systems to route a call to the next

= hop associated with the called domain.  These systems typically use a<= o:p>

= local data store ("Local Data Repository") as their source of ses= sion

= routing information." 

 

new:

= "The data provisioned for session establishment is <<known as Se= ssion Establishment Data or SED and is>> typically used by various do= wnstream SIP signaling systems to route a call to the next

= hop associated with the called domain."  

=  

old: 

= "Subsequently, a registry may distribute the provisioned data into

= local data repositories, used for lookup 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)."

=  

new:

= "Subsequently, a registry may distribute the provisioned data into

= local data repositories <<or may additionally offer a central query&n= bsp;

= resolution service (not shown in the above figure) for query purposes.>&= gt;"

=  

old: 

= "Transport requirements are provided in this document to help with the=

= selection of the optimum transport mechanism.  The SPP Protocol over

= SOAP document identifies a protocol for SPPF that uses SOAP/HTTP as

= the transport mechanism."

 

new:

= "Transport requirements are provided in this document to help with the=

= selection of the optimum transport mechanism."  

= /* this second sentence creates a dependency on the SOAP document so imho i= t should be removed */

[VB:] I tend to agree and mentioned this in the past as well= . imo, we should not have any references to the SOAP document in Framework = document.

=  

 

old 

= "Section 5 describes the base framework data structures, the

=         generic response types that MUST be supported b= y a conforming

=         "protocol" specification, and the bas= ic object type most first

=         class objects extend from;"

new:

= "Section 5 describes the base framework data structures, the

=         generic response types that MUST be supported b= y a conforming

=         <<transport>> "protocol" = specification, and the basic object type most first

=         class objects extend from;"

 

old: 

= "   o    Section 6 detailed description of the data mod= el object

=         specifications;"

 

new:

= "   o    Section 6 <<provides a>> detailed = description of the data model object

=         specifications;

=  

= <<   o    Section 7 describes the operations that are = supported by the data model

=  

=      o    Sections 9 - 11 discuss security, intern= ationalization and IANA considerations >>"

 

= 2. Terminology

 

old: 

= "SPDP: Session Peering Distribution Protocol, the protocol used to

=       distribute data to Local Data Repository (see arrow la= beled "2."

=       in Figure 1 of [RFC6461])."

 

new:

/* remove as this is not really discus= sed anywhere in the document */

 

old: 

= "Client:   An application that >>supports an SPPF client<= ;<; it is

=       sometimes referred to as a "registry client"= ."

new:

= "Client:   <<In the context of SPPF, this is>> <= o:p>

=       an application that <<initiates a provisioning r= equest>>; it is

=       sometimes referred to as a "registry client"= .

=  

= Server:   <<In the context of SPPF, this is>>

=       an application that receives a provisioning request an= d responds 

=       accordingly. The server typically operates a master da= tabase of 

=       Session Establishment Data (SED) for one or more Regis= trants. In

=       the context of SPPF, the provisioning server is referr= ed to as 

=       a Registry.

=  

= Registry: a provisioning server."

=  

= 3. Framework High Level Design

=  

old: 

= "The data model is defined along with all the objects manipulated = ;

= by >>the protocol<< and their relationships."

=  

new:

= "The data model is defined along with all the objects manipulated = ;

= by <<a conforming tranport>> protocol and their relationships.&= quot;

[VB:] typo on “transport” ..

=  

= 3.1. Framework Data Model

=  

old: 

= "The data model illustrated and described in Figure 2 defines the=

= logical objects and the relationships between these objects >>that th= e

= SPPF protocol supports<<."

 

new:

= "The data model illustrated and described in Figure 2 defines the=

= logical objects and the relationships between these objects supported =

= by SPPF."

 

old: 

= "SPPF defines >>the<< protocol operations through

= which an SPPF client populates a registry with these logical objects.<= /o:p>

= Various clients belonging to different registrars may >>use the<= /o:p>

= protocol for populating the registry's data<<."

 

new:

= "SPPF defines protocol operations through

= which an SPPF client populates a registry with these logical objects.<= /o:p>

= Various clients belonging to different registrars may provision data <= o:p>

= into the registry using a conforming transport protocol implementing <= o:p>

= these operations."

 

old: 

in figure, the Public Identifier has a= n element called "sedRecRef" - this needs to be removed

 

new:

the TN element needs to have this elem= ent

 

= 5.1.  Basic Object Type and Organization Identifiers=

 

old: 

= "The identifiers used for registrants (rant), registrars (rar), and

= peering organizations (peeringOrg) are instances of OrgIdType."

 

new:

= The identifiers used for registrants (rant) and registrars (rar) are instan= ces of OrgIdType.

= /* no need to introduce peeringOrg over here - it just serves to confuse. M= ove the peeringOrg

=    comment to where its mentioned */

=  

= 5.2.  Various Object Key Types

=  

old: 

= ">>In addition,<< an object's unique identity is required = to Delete or Get

= the details of an object."  

 

new:

"<<Note that>> an object's unique ide= ntity is required to Delete or Get

= the details of an object."  

 

old: 

= \""Name" attributes that are used as components of object ke= y types

= MUST be treated case insensitive."

 

new:

= \""Name" attributes that are used as components of object ke= y types

= MUST be treated <<as>> case insensitive."

 

= 5.2.2.  Derived Object Key Types

=  

old: 

= "and defined in there own abstract key types.  Because these obje= ct

= key types are abstract, these MUST be specified in a concrete form in<= /o:p>

= any conforming SPPF "protocol" specification."

 

new:

= "and defined in there own abstract key types.  Because these obje= ct

= key types are abstract, these MUST be specified in a concrete form in<= /o:p>

= any SPPF conforming <<transport>> protocol specification."=

 

old: 

= The >>.<<PubIdKeyType is used in Delete and Get operations on a=

= Public Identifier object.

 

new:

= The PubIdKeyType is used in Delete and Get operations on a

= Public Identifier object.

=  

= 5.3.  Response Message Types

=  

old: 

= "This section contains the listing of response types that MUST be=

= defined by the conforming "protocol" specification and implemente= d by

= a conforming SPPF server."

=  

new:

= "This section contains the listing of response types that MUST be=

= defined by the <<SPPF conforming transport>> protocol" spe= cification and implemented by

= a conforming SPPF server."

=  

= 6.  Framework Data Model Objects

=  

= old:

= "However, the specification of the data structures necessary to

= support each command is delegated to >>the "protocol"<&l= t; specification."

=  

= New:

= "However, the specification of the data structures necessary to

= support each command is delegated to <<an SPPF conforming transport p= rotocol>> specification."

=  

= 6.2. Public Identifier

 

old: 

/* No XML describing CORInfoType in th= e TNTYpe description  - yet elements of this type are discussed in des= criptive text */

 

new:

add before the "NumberValType&quo= t;

 

=    " <complexType name=3D"CORInfoType">=

=      <sequence>

=       <element name=3D"corClaim" type=3D"b= oolean" default=3D"true"/>

=       <element name=3D"cor" type=3D"boolea= n" default=3D"false" minOccurs=3D"0"/>

=       <element name=3D"corDate" type=3D"da= teTime" minOccurs=3D"0"/>

=      </sequence>

=     </complexType>"

 

= Old:

= "RNType has the following attributes:

= …

=    o    corInfo: Optional <corInfo> element of ty= pe CORInfoType."

=  

= New:

= "RNType has the following attributes:

= …

=    o    corInfo: corInfo is an optional parameter of ty= pe CORInfoType

=         that allows the registrant organization to set = forth a claim to

=         be the carrier-of-record (see [RFC5067])."=  

 

= Old:

= "TNRType has the following attributes:

= …

=    o    corInfo: Optional <corInfo> element of ty= pe CORInfoType."

=  

= New:

= "TNRType has the following attributes:

= …

=    o    corInfo: corInfo is an optional parameter of ty= pe CORInfoType

=         that allows the registrant organization to set = forth a claim to

=         be the carrier-of-record (see [RFC5067])."=

 

= Old:

= "TNPType has the following attributes:

= …

=    o    corInfo: Optional <corInfo> element of ty= pe CORInfoType."

=  

= New:

= "TNPType has the following attributes:

= …

=    o    corInfo: corInfo is an optional parameter of ty= pe CORInfoType

=         that allows the registrant organization to set = forth a claim to

=         be the carrier-of-record (see [RFC5067])."=  

=  

= Old:

= /* in the definition of URIPubIdType there is an "ext" element wh= ereas in all other pubIDs there isn't - why? */

=  

= New:

= remove…

=    "<element name=3D"ext" type=3D"sppfb:Ex= tAnyType" minOccurs=3D"0"/>"

=  

= 6.2. SED Group

=  

= Old:

= "As described in the introductory sections, a SED Group represents a

= combined grouping of Destination Groups containing a set of Public

= Identifiers >>with common Session Establishment Data(SED)<<, Th= e common

= Session Establishment Data Records, and the list of peer<= /p>

= organizations that have access to these public identifiers using the

= associated SED information."  

=  

= New:

= /* too verbose */

= "As described in the introductory sections, a SED Group represents a

= combined grouping of Destination Groups (containing a set of Public

= Identifiers), The common Session Establishment 

= Data Records, and the list of peer organizations that have access to this

= gouging (public identifiers using the associated SED information.)" &n= bsp;

 

[VB:] gouging -> grouping?=

 

= Old:

= /* in the definition of SedGrpType there is an "ext" element - wh= y? */

=  

= New:

= remove…

=    "<element name=3D"ext" type=3D"sppfb:Ex= tAnyType" minOccurs=3D"0"/>"

[VB:] the same reason I believe as for all other objects in = SPPF, like “BasicObjType”, “EgrRteType”..Extensibil= ity of these schema elements to provide supplemental information to the server…( even though these were adde= d much before I came onboard …)

=  

=  

= Old:

= /* no mention of peeringOrg type */

=  

= New:

= "Note that the identifier used for peering organization (peeringOrg) i= s an instance of OrgIdType."

=  

= 6.4. SED Record

=  

= Old:

= "The data provisioned in a registry can be leveraged for many purposes=

= and queried using various protocols including SIP, ENUM and others.

= As such, the resolution data represented by the >>SedRecords<< = must be in

= a form suitable for transport using one of these protocols.

=  

= New:

= "The data provisioned in a registry can be leveraged for many purposes=

= and queried using various protocols including SIP, ENUM and others.

= As such, the resolution data represented by the <<SED records>>= must be in

= a form suitable for transport using one of these protocols.

=  

= 6.4. SED Record

=  

= Old:

= "In a high-availability environment, the originating SSP likely has

= more than one egress path>>s<< to the ingress SBE of the target= SSP."

=   

= New:

= "In a high-availability environment, the originating SSP likely has

= more than one egress path to the ingress SBE of the target SSP."<= /o:p>

=  

= Old:

= "A Egress R= oute object MUST be uniquely identified by attributes as<= /p>

= defined in the description of "ObjKeyType" in the section "G= eneric

= Object Key Type" of this document."

=  

= New:

= "A<<n= >> Egress Route object MUST be uniquely identified by attributes as

= defined in the description of "ObjKeyType" in the section "G= eneric

= Object Key Type" of this document."

=  

= 7. Framework Operations

=  

= 7.1/2/3/4/5/6

= Old:

= "Any conforming "protocol" specification MUST provide…= "

=  

= New:

= "Any conforming <<transport protocol>> specification MUST = provide…"

=  

= 9.3.1 DoS Issues Inherited from Transport Mechanism

=  

= Old:

= "The typical deployment scenario for SPPF is to have servers in a=

= managed facility, and therefor techniques such as Network Ingress

= Filtering ([RFC2609]) are generally applicable." 

=  

= New:

= "The typical deployment scenario for SPPF is to have servers in a=

= managed facility, and therefor<<e>> techniques such as Network = Ingress

= Filtering ([RFC2609]) are generally applicable." 

=  

= 13 Acknowledgments

= /* Jeremy Barkan participated in many discussions and should be acknowledge= d */


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_B4254E341B54864B92D28BC2138A9DC3031821BCBDTNSMAILNAwin2_-- From sumanth@cablelabs.com Thu Sep 27 09:18:47 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 2578E21F8534 for ; Thu, 27 Sep 2012 09:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpLjxsJrMskH for ; Thu, 27 Sep 2012 09:18:46 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB6221F845B for ; Thu, 27 Sep 2012 09:18:46 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q8RGIjCm021753 for ; Thu, 27 Sep 2012 10:18:45 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 27 Sep 2012 10:18:45 -0600 (MDT) 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; Thu, 27 Sep 2012 10:18:45 -0600 From: Sumanth Channabasappa To: "Drinks@ietf.org" Date: Thu, 27 Sep 2012 10:18:45 -0600 Thread-Topic: DRAFT minutes from the DRINKS design team call on Sep 26th, 2012 Thread-Index: Ac2cy8SHmZP70Jz5QR2QJcqj4ASjdA== Message-ID: In-Reply-To: <19F54F2956911544A32543B8A9BDE075192F53@NICS-EXCH.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 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 on Sep 26th, 2012 X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 16:18:47 -0000 DRINKS design team call Sep 26, 2012 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 10a-10:30a Participants ------------ - Vikas Bhatia - Dean Willis - Manjul Maharishi - Syed Ali - Ken Cartwright - Sumanth Channabasappa ACTION ITEMS ------------ [Syed] Volunteered to be the primary on the framework document, and will propose changes in collaboration with co-authors [Vikas] Volunteered to coordinate and lead changes w.r.t. the SOAP document=20 Agenda ------ 1/ WGLC Comments We received the comments from the following: + Paul Hoffman (early review comments from the Sec Dir). - Secdir review of draft-ietf-drinks-spp-framework + Dean Willis - Comments on draft-ietf-spp-framework-02 - Review of draft-ietf-drinks-spp-protocol-over-soap-02 + David Schwartz - Comments to the WGLC on SPPF document + Andrew Sullivan WGLC comments from Andrew Sullivan on draft-ietf-drinks-spp-framework-02 + Alex M. - WGLC comments on draft-ietf-drinks-spp-framework-02 - Extension of WGLC for I-Ds draft-ietf-drinks-spp-framework-02.txt and draft-ietf-drinks-spp-protocol-over-soap-02.txt + Manjul Maharishi - reviewed the soap transport document (Thanks to the above.) Based on this we discussed if there were any concerns from the design team. The participants felt that the reviews were useful, and there are additional clarifications that should be provided, but no major issues. 2/ Next Steps To facilitate with the addressing and incorporation of comments, Sumanth asked for volunteers. Vikas and Syed volunteered for the framework and protocol docs, respectively. Accordingly: - They will work with the other authors to address the comments - They will shepherd updates from the co-authors, and present updates (over the next week or so)