X-List-Received-Date: Wed, 09 Nov 2011 22:34:47 -0000 --bcaec521639d1e04c504b154e546 Content-Type: text/plain; charset=ISO-8859-1 The discussion around Organization in 3.1 Protocol Data Model may be inconsistent with reintroduction of "rar" into the schema: o Organization: An Organization is an entity that may fulfill the role of a registrant or a peering organization. All SPPP objects are associated with an organization identifier to identify each object's registrant, while tracking the identity of the registrar that provisioned each SPPP object is left as a matter of policy for an SPPP implementation. If rar is in the object schema, tracking it may not be optional. We noted during the OpenSPP work that we were having a hard time modeling a number of use cases without tracking the rar. I suggest replacing "while tracking..." with "and a registrar identifier to identify the registrar that provisioned the object." -- Dean --bcaec521639d1e04c504b154e546 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The discussion around Organization in 3.1 Protocol Data Model may = be inconsistent with reintroduction of "rar" into the schema:

   o  =
Organization:
      An Organization is an entity that may fulfill the role of a
      registrant or a peering organization.  All SPPP objects are
      associated with an organization identifier to identify each
      object's registrant, while tracking the identity of the registrar
      that provisioned each SPPP object is left as a matter of policy
      for an SPPP implementation.

If rar is in the object schema, tracking it may n=
ot be optional. We noted during the OpenSPP work that we were having a hard=
 time modeling a number of use cases without tracking the rar.

I suggest rep=
lacing "while tracking..." with "and a registrar identifier =
to identify the registrar that provisioned the object."

--<=
/pre>Dean


--bcaec521639d1e04c504b154e546--

From dean.willis@softarmor.com  Wed Nov  9 14:50:08 2011
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 26DC91F0C41 for ; Wed,  9 Nov 2011 14:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDEmhi8JCiEx for ; Wed,  9 Nov 2011 14:50:07 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5FA21F0C34 for ; Wed,  9 Nov 2011 14:50:07 -0800 (PST)
Received: by ggnr4 with SMTP id r4so773548ggn.31 for ; Wed, 09 Nov 2011 14:50:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.17.201 with SMTP id q9mr8778916pbd.15.1320879006921; Wed, 09 Nov 2011 14:50:06 -0800 (PST)
Received: by 10.142.233.10 with HTTP; Wed, 9 Nov 2011 14:50:06 -0800 (PST)
Date: Wed, 9 Nov 2011 16:50:06 -0600
Message-ID: 
From: Dean Willis 
To: drinks@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [drinks] Thoughts on sppp-over-soap-06
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, 09 Nov 2011 22:50:08 -0000

I really like the new approach to splitting generic and implementation
protocols. This is looking good.



In 3. SOAP Features and Protocol Layering we have a sentence that
doesn't parse for me:

Orig:

It is characterized by setting the soapAction binding style as
_document_, the soapAction encoding style    as _literal_, and then
defining the SOAP messages to simply contain a single data element
that _wraps_ that is a data structure containing all the required
input or output data elements.

Is this the same as:

It is characterized by setting the soapAction binding style as
_document_, the soapAction encoding style    as _literal_, and then
defining the SOAP messages to simply contain a single data element
that _wraps_ a data structure containing all the required input or
output data elements.

(I took out a "that is" that seemed superfluous, after _wraps_).



One general worry point is that we sometimes refer to "SPPP" behavior,
when we're talking about "SPPP over SOAP". This is evident in the
general description under section 6, which implies that the
SOAP-specific wrapping is an aspect of SPPP, whereas it's really tied
to our implementation of SPPP using SOAP. Could we call this
SPPP/SOAP? If so, a simple search-replace operation could fix section
6, and probably most of the following text.

From dean.willis@softarmor.com  Wed Nov  9 15:11:56 2011
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 B7AB311E809A for ; Wed,  9 Nov 2011 15:11:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.755
X-Spam-Level: 
X-Spam-Status: No, score=-101.755 tagged_above=-999 required=5 tests=[AWL=-1.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_MULTI_PRN2=1.66, SARE_SUB_NEED_REPLY=0.784, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj4UHTmgvh43 for ; Wed,  9 Nov 2011 15:11:56 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEE711E8087 for ; Wed,  9 Nov 2011 15:11:48 -0800 (PST)
Received: by ggnr4 with SMTP id r4so792830ggn.31 for ; Wed, 09 Nov 2011 15:11:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.75.170 with SMTP id d10mr8815816pbw.49.1320880307706; Wed, 09 Nov 2011 15:11:47 -0800 (PST)
Received: by 10.142.233.10 with HTTP; Wed, 9 Nov 2011 15:11:47 -0800 (PST)
Date: Wed, 9 Nov 2011 17:11:47 -0600
Message-ID: 
From: Dean Willis 
To: drinks@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [drinks] A little more on spprov-11 request-response model and spppUpdateResponse
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, 09 Nov 2011 23:11:56 -0000

   o    corInfo: corInfo is an optional parameter of type CORInfoType
        that allows the registrant organization to set forth a claim to
        be the carrier-of-record (see [RFC5067]).  This is done by
        setting the value of  element of the CORInfoType


Previously, we assumed that a request-response model consistent with
SOAP. SOAP allows us to return a structured type that includes a lot
of information. This assumption is illustrated in section 4.2 Request
and Response Model in the spprov-11 draft:

4.2.  Request and Response Model

   Provisioning operations in SPPP follow the request-response model,
   where a client sends a request message to initiate a transaction and
   the server responds with a response.  Multiple subsequent request-
   response exchanges MAY be performed over a single persistent
   connection.

   Therefore, a transport protocol for SPPP MUST follow the request-
   response model by allowing a response to be sent to the request
   initiator.


One of the challenges in re-layering the specification is that some
potentially interesting protocol bindings (such as RESTful HTTP) use a
different response paradigm. REST, in particular, suggests that the
response code set by mapped onto the relatively small set of HTTP
responses, although some transactions (notably query or "GET"
transactions) can obviously return a large amount of structured data.
So this is particularly of concern on write/update transactions,
("PUT", "POST", "DELETE").

So this means that we can't always return a structured type like the
"spppUpdateResponse". It's just something that a non-SOAP binding is
going to have to find an appropriate way to do.

However, the current spprov-11 draft retains a few references to
"spppUpdateResponse" that still need to be cleaned out. Specifically,
I noted references in section 6.3 Route Group (right at the end) that
can probably just be deleted.

There's also some discussion in the corInfo bullet under TNType in
section 6.2 Public Identifier. I think it's okay to just delete the
last sentence that talks about  spppUpdateResponse, but this needs
some thinking about.

Specifically, I'm wondering of there's actually some sort of
authorization failure that needs to be asserted if 1) the
carrier-of-record claimed in the update is inconsistent with the
previously claimed authority information, and 2) the server policy
cares about this distinction. If we need to assert such an error, how
might we assert it?

Related question for the SOAP binding: Is just including a mismatched
corInfo in the response a strong enough assertion of this error
condition?


--
Dean

From kcartwright@tnsi.com  Thu Nov 10 06:33:36 2011
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 3C53021F8B21 for ; Thu, 10 Nov 2011 06:33:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebnWMxV1y-Ae for ; Thu, 10 Nov 2011 06:33:35 -0800 (PST)
Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 12F8621F8B08 for ; Thu, 10 Nov 2011 06:33:34 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArMAAEbfu06sEQfn/2dsb2JhbAA6AQmCTZdgkH2BcgEBBS1cAgEIEQQBASgHMhQJCAEBBAEQAgjAO4ZLAYJPYwSID54sHw
X-IronPort-AV: E=Sophos;i="4.69,489,1315177200"; d="scan'208,217";a="473120"
Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 10 Nov 2011 14:33:31 +0000
Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Thu, 10 Nov 2011 09:33:31 -0500
From: "Cartwright, Ken" 
To: Dean Willis , "drinks@ietf.org" 
Date: Thu, 10 Nov 2011 09:33:29 -0500
Thread-Topic: [drinks] Implications of re-adding rar in spprov-11
Thread-Index: AcyfL8xoMbfzrmPnQdiYtnt4d33YKAAhb+8A
Message-ID: <754963199212404AB8E9CFCA6C3D0CDA4B5860A054@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_754963199212404AB8E9CFCA6C3D0CDA4B5860A054TNSMAILNAwin2_"
MIME-Version: 1.0
Subject: Re: [drinks] Implications of re-adding rar in spprov-11
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, 10 Nov 2011 14:33:36 -0000

--_000_754963199212404AB8E9CFCA6C3D0CDA4B5860A054TNSMAILNAwin2_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That sentace is a holdover from when we removed rar from the schema.  It ne=
eds to be changed now that we have added it back in.

________________________________
From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of=
 Dean Willis
Sent: Wednesday, November 09, 2011 5:35 PM
To: drinks@ietf.org
Subject: [drinks] Implications of re-adding rar in spprov-11


The discussion around Organization in 3.1 Protocol Data Model may be incons=
istent with reintroduction of "rar" into the schema:

   o  Organization:

      An Organization is an entity that may fulfill the role of a

      registrant or a peering organization.  All SPPP objects are

      associated with an organization identifier to identify each

      object's registrant, while tracking the identity of the registrar

      that provisioned each SPPP object is left as a matter of policy

      for an SPPP implementation.

If rar is in the object schema, tracking it may not be optional. We noted d=
uring the OpenSPP work that we were having a hard time modeling a number of=
 use cases without tracking the rar.

I suggest replacing "while tracking..." with "and a registrar identifier to=
 identify the registrar that provisioned the object."





--

Dean





________________________________
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_754963199212404AB8E9CFCA6C3D0CDA4B5860A054TNSMAILNAwin2_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









That sentace is a holdover from when w=
e removed rar from the schema.  It needs to be changed now that we hav=
e added it back in.
 




From: drin=
ks-bounces@ietf.org [mailto:drinks-bounces@ietf.org]
On Behalf Of Dean Willis

Sent: Wednesday, November 09=
, 2011 5:35 PM

To: drinks@ietf.org

Subject: [drinks] Implicatio=
ns of re-adding rar in spprov-11

 
 

The discussion around Organization in 3.1 Protocol Data Model may b=
e inconsistent with reintroduction of "rar" into the schema:=



   o  =
Organization:
      An Organization is an entity that may fulfi=
ll the role of a
      registrant or a peering organization. =
 All SPPP objects are
      associated with an organization identifier =
to identify each
      object's registrant, while tracking the ide=
ntity of the registrar
      that provisioned each SPPP object is left a=
s a matter of policy
      for an SPPP implementation.
If rar is in the obje=
ct schema, tracking it may not be optional. We noted during the OpenSPP wor=
k that we were having a hard time modeling a number of use cases without tr=
acking the rar.
I suggest replacing &=
quot;while tracking..." with "and a registrar identifier to ident=
ify the registrar that provisioned the object."

 
 
--<=
/font>

Dean
 
 





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_754963199212404AB8E9CFCA6C3D0CDA4B5860A054TNSMAILNAwin2_--

From syed.ali@neustar.biz  Thu Nov 10 06:49:38 2011
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 5BB3C21F88AB for ; Thu, 10 Nov 2011 06:49:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qCVF+E6ioZF for ; Thu, 10 Nov 2011 06:49:36 -0800 (PST)
Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0B621F8880 for ; Thu, 10 Nov 2011 06:49:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1320936529; x=1636292841; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=8rSmuNk6Zn0xwjuHCV0l9AgVrADqZ2YYKPBe2kwTpus=; b=ppoL74rU2Lm6yudyMuG8d44AplnGlYdGjwGfOI5XQpJH0XTpp0cksyy7PTGZe8 DqGMugQwnycGfXVCf7ERxiKg==
Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.1382046;  Thu, 10 Nov 2011 09:48:48 -0500
Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 10 Nov 2011 09:49:26 -0500
From: "Ali, Syed Wasim" 
To: "Bhatia, Vikas" , "drinks@ietf.org" 
Date: Thu, 10 Nov 2011 09:49:20 -0500
Thread-Topic: [drinks] Refactored SPPP protocol schema and WSDL
Thread-Index: Acyft/EiURAnccH7TPqXFAGCzB8n1g==
Message-ID: 
In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA4B5605B857@TNS-MAIL-NA.win2k.corp.tnsi.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.0.101115
acceptlanguage: en-US
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: oloB0vfG8vMkiM5RJVUnrg==
Content-Type: multipart/alternative; boundary="_000_CAE14E5819B10syedalineustarbiz_"
MIME-Version: 1.0
Subject: Re: [drinks] Refactored SPPP protocol schema and WSDL
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, 10 Nov 2011 14:49:38 -0000

--_000_CAE14E5819B10syedalineustarbiz_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Vikas/Ken,

Thanks for making the updates. There are a couple things that are not clear=
 in my mind and I could be missing a thing or two that you can help with.

What is the motivation of making the ObjKeyType and RteGrpOfferKeyType abst=
ract? I guess what I am trying to understand is the impact of putting the d=
efinition of what constitutes the object-key in the WSDL. In the worst case=
, this can have interoperability impact where two known transport/binding o=
f sppp interpret the object-key differently. My understanding of the best u=
se of "type" in WSDL is for a control object that doesn't take away key pie=
ce of information from the base schema.

Also, since the data model is described in the main document, perhaps it wi=
ll help to list the type of errors that may arise in the base document as w=
ell. This way, the implementation of the spec will enumerate these error co=
nditions as well, in addition to any other error conditions that are transp=
ort specific. I think this will effect interoperability as well. How the er=
ror condition is played back will certainly be transport specific.

Let me know what you think.

Thanks,

-Syed

From: "Bhatia, Vikas" >
Date: Thu, 27 Oct 2011 08:07:30 -0400
To: "drinks@ietf.org" >
Subject: [drinks] Refactored SPPP protocol schema and WSDL

Attached is the revised protocol base schema document (spppbase.xsd) and tr=
ansport WSDL (sppp.wsdl). For reference, I am also attaching the =93old=94 =
base protocol schema and wsdl (spppbase_beforechange.xsd and sppp_beforecha=
nge.wsdl).

These changes primarily address items A), C) an D) in Ken=92s email below a=
long with reintroduction of the =93rar=94 element (identifying the Registra=
r).

The list of changes are:


1.     Made ObjKeyType abstract in the Protocol and extended it in the type=
s definition in the WSDL.

2.     Made RteGrpOfferKeyType abstract in the Protocol and extended it in =
the types definition in the WSDL.

3.     Moved all schema types related to verbs/operations from the Protocol=
 to the Transport. In essence, the base schema (spppbase.xsd) now has the d=
efinition of objects (nouns) in sppp but no verbs/operations. All operation=
 (verb) definitions are in the WSDL types.  All types annotated (in spppbas=
e_beforechange.xsd) with =93Generic Request and Response Definitions=93 and=
 =93Operation Request and Response Object Type Definitions=94 have been mov=
ed as part of this restructuring to the =93types=94 section of the transpor=
t WSDL.

4.     #3 above includes =93ResultCodeType=94 and =93RqstObjResultCodeType=
=94 moving to the transport WSDL. This was for completeness of the change a=
round this. (to some extent this relates to item B)

5.      Reintroduced the element =93rar=94 back in to the =93BasicObjType=
=94 (spppbase,xsd).



We can discuss in detail around these in the design call.

Thanks,
Vikas


From: drinks-bounces@ietf.org [mailto:drink=
s-bounces@ietf.org] On Behalf Of Cartwright, Ken
Sent: Thursday, September 15, 2011 1:01 PM
To: drinks@ietf.org
Subject: Re: [drinks] Rafactoring SPPP to make it ReST Friendly

Today we jumped the gun a bit and tried to have a meaningful discussion on =
item D below, even though not a lot of meaningful thought had been put into=
 it.  But I believe the =93solution=94 to Item D below, which I also hint a=
t in the description of item D, is to just not have those XSD data structur=
es (the ones that currently enable any set of verb/noun pairs to be passed =
in and processed as a single request/transaction) be part of the =93protoco=
l=94 document=92s XSD.  How (and if) that feature will be provided will jus=
t not be specified in the =93protocol=94 document.  If an author wants to w=
rite a ReST specification they can just decide if they even want to provide=
 that feature, and if so, how they want to do it. And for SOAP, the SOAP =
=93transport=94 document will contribute those data structures (probably in=
 a form somewhat modified from what we have now) via a separate XSD to prov=
ide that feature.

Ken

________________________________
From: Cartwright, Ken
Sent: Tuesday, September 13, 2011 3:47 PM
To: drinks@ietf.org
Subject: Rafactoring SPPP to make it ReST Friendly

Syed and I meet for about 90 minutes today to talk through the details of t=
he impacts that result from making the protocol document ReST friendly.  I=
=92ve summarized these impacts below in fairly good detail, so please revie=
w it if you wish.  To kick off this effort I=92m going to take on how to ma=
ke the changes described below under =93A) Object Identity=94, and Syed is =
going to take on the changes below under =93B) Response Codes and Response =
Data Structures=94.  After A and B are done, which, along with D, are the m=
ore involved tasks, we will tackle C, D, E, and F.

Ken

A) Object Identity
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
SPPP uses composite business keys to identity object instances.  There are =
SPPP XSD data structures like ObjKeyType that serve this purpose.  Object k=
eys are used to house relationships between objects and to query for (get) =
a specific object instance.  ReST controls how object identity (object keys=
) must be encoded/structured, using URIs.  So the SPPP XSD will need to be =
changed to support the use of either URIs or more traditional approaches su=
ch as that currently used by SPPP.  And this will have to work for both the=
 non-composite object relationship case and for the query/get case.  And th=
ese changes will impact the current structure of the SPPP =93nouns=94.  So,=
 more specifically, the following XSD data structures will need to change:

1) RteRecType  (because it identifies the DestGroups that is relates to)
2) PubIdType (because it identifies the DestGroup that it belongs to)
3) ObjKeyType (because it is not a ReST friendly structure for object ident=
ity)
4) The Data Structures that contain or depend on an ObjKeyType
   4.1) RteGrpOfferKeyType
   4.2) RteGrpOfferType
   4.3) EgressRteType
   4.4) RteRecRefType


B) Response Codes and Response Data Structures
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ReST controls what response codes and the corresponding response messages t=
hat are available to the application, the HTTP response codes.  So SPPP=92s=
 response codes will have to be removed since ReST dictates that it is the =
HTTP protocol=92s response codes that are allowed.  The response codes will=
 have to be moved to the =93Transport=94 document.
SPPP=92s parameterized error response code message structures that define w=
hat data element of what object was found to be erroneous will have to be r=
emoved/changed since the HTTP response codes do not give you that level of =
detail about what failed.  We will either have to punt on this capability o=
r create a hybrid approach that can be hacked into ReST, such that response=
 objects contain additional sub-response codes and data structures.
SPPP=92s response data structure, that incorporates an overall response cod=
e and, if there is an error, the data structure of the object that failed v=
alidation will have to be watereddown/removed/changed.

So, more specifically, in addition to the response code definitions being c=
hanged and the parameterization of the response code messages being removed=
 and replaced with some other scheme, the XSD items that are likely to need=
 to be changes are:

1) ResultCodeType
2) RqstObjResultCodeType
3) spppUpdateResponse

C) Actions/Verbs/Operations
=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
The SPPP XSD currently defines the operations/verbs that can be performed o=
n each of the SPPP data model objects/nouns, and the required inputs and ou=
tputs of each.  But ReST controls what verbs are available to the applicati=
on (Put, Post, Get, Del), and provides no way of enforcing the allowable in=
put and output data structures for each.  So we will need to remove all ope=
rations/verbs and remove the specification of the required inputs and outpu=
ts for each operation/verb from the XSD.  These will now need to be documen=
ted just in textual form in the document.

D) Base Protocol Data Structures and Housekeeping Features
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
SPPP currently defines common request and response data structures that are=
 used for any type of operation/verb and any type of noun, and in-fact allo=
ws different verb and noun pairs to be passed into a single request.  This =
was done to allow any set of verb/noun pairs to be passed in and processed =
as a single transaction, all or nothing, giving the client optional control=
 over their transaction boundaries.  But because ReST uses the pre-determin=
ed verbs from HTTP (Post, Put, Get, Del), which is embedded inside the HTTP=
 envelope, this type of feature cannot be cleanly provided.  Furthermore, h=
ouse-keeping features such as clientTransId, serverTransId, minorVer are ho=
used within these base data structures.

So we will either say that a ReST implementation will just not support some=
 of these features, or restructure the following XSD data structures in som=
e way to allow some of them:

1) spppUpdateRequest
2) spppUpdateResponse
3) spppQueryRequest
4) spppQueryResponse
5) spppServerStatusRequest
6) spppServerStatusResponse


E) SPP =93Protocol=94 Documentation Changes

And of course all of the above will require notable changes to the document=
 content itself.

F) SPP =93Transport=94 Document Changes

And of course all of the above will require notable changes to the document=
 content itself because they push mofer of the specification out of the =93=
Protocol=94 document and up into the =93Transport=94 document.


________________________________
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.

________________________________
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_CAE14E5819B10syedalineustarbiz_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



=
Vikas/Ken,

Thanks for making =
the updates. There are a couple things that are not clear in my mind and I =
could be missing a thing or two that you can help with.
<=
br>
What is the motivation of making the ObjKeyType and R=
teGrpOfferKeyType abstract? I guess what I am trying to understand is the i=
mpact of putting the definition of what constitutes the object-key in the W=
SDL. In the worst case, this can have interoperability impact where two kno=
wn transport/binding of sppp interpret the object-key differently. My =
understanding of the best use of "type" in WSDL is for a control =
object that doesn't take away key piece of information from the base schema=
. 

Also, since the data model=
 is described in the main document, perhaps it will help to list the type o=
f errors that may arise in the base document as well. This way, the impleme=
ntation of the spec will enumerate these error conditions as well, in addit=
ion to any other error conditions that are transport specific. I think this=
 will effect interoperability as well. How the error condition is played ba=
ck will certainly be transport specific.

Let me know what you think.


-Syed
<=
div>
<=
/font>

From: "= Bhatia, Vikas" <vbhatia@tnsi.co= m>
Date: Thu, 27 Oct 201= 1 08:07:30 -0400
To: "drinks@ietf.org" <drinks@ietf.org>
Subject: [drinks] Refactored SPPP protocol schema and WSDL

Attached is= the revised protocol base schema document (spppbase.xsd) and transp= ort WSDL (sppp.wsdl). For reference, I am also attaching the =93old= =94 base protocol schema and wsdl (spppbase_beforechange.xsd and spp= p_beforechange.wsdl).

These changes prima= rily address items A), C) an D) in Ken=92s email below along with reintrodu= ction of the =93rar=94 element (identifying the Registrar).

<= /p>

The list of changes are:

1. &nbs= p; Made ObjKeyType abstract in the Protocol and extended it in the types = definition in the WSDL.

2. Made RteGrpOfferKeyType abstract in the Protocol and extended it in the <= i>types definition in the WSDL.

3. Moved all schema types related to verbs/operations from the Protocol to the Transport= . In essence, the base schema (spppbase.xsd) now has the definition = of objects (nouns) in sppp but no verbs/operations. All operation (verb) de= finitions are in the WSDL types. All types annotated (in spppbase_beforechange.xsd) with =93Generic Request and Response Definitions=93 and =93Ope= ration Request and Response Object Type Definitions=94 have been moved = as part of this restructuring to the =93types=94 section of the transport WSDL.

4. #3 above includes =93ResultCodeT= ype=94 and =93RqstObjResultCodeType=94 moving to the transport WSDL. Th= is was for completeness of the change around this. (to some extent this rel= ates to item B)

5. Reintroduced the element =93<= i>rar=94 back in to the =93BasicObjType=94 (spppbase,xsd).

We can discuss in detail around these in the design call.

Thanks,

Vikas

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Cartwright, Ken
Sent: Thursday, September 15,= 2011 1:01 PM
To: drinks@ietf.= org
Subject: Re: [drinks] Rafactoring SPPP to make it ReST Fr= iendly

<= /o:p>

Today we jumped the gun a bit and tried to have a me= aningful discussion on item D below, even though not a lot of meaningful th= ought had been put into it. But I believe the =93solution=94 to Item D below, which I also hint at in the description of= item D, is to just not have those XSD data structures (the ones that curre= ntly enable any set of verb/noun pairs to be passed in and processed as a s= ingle request/transaction) be part of the =93protocol=94 document=92s XSD. How (and if) that feature will = be provided will just not be specified in the =93protocol=94 document. = ; If an author wants to write a ReST specification they can just decide if = they even want to provide that feature, and if so, how they want to do it. And for SOAP, the SOAP =93transport=94 document will c= ontribute those data structures (probably in a form somewhat modified from = what we have now) via a separate XSD to provide that feature.

Ken

From: Cartwright, Ken
Sent: Tuesday, September 13, 2011 3:47 PM
To: drinks@ietf.org
Subject: Rafactor= ing SPPP to make it ReST Friendly

Syed and I meet for about 90 mi= nutes today to talk through the details of the impacts that result from mak= ing the protocol document ReST friendly. I=92ve summarized these impa= cts below in fairly good detail, so please review it if you wish. To kic= k off this effort I=92m going to take on how to make the changes described = below under =93A) Object Identity=94, and Syed is going to take on the chan= ges below under =93B) Response Codes and Response Data Structures=94. After A and B are done, which, along with D, are= the more involved tasks, we will tackle C, D, E, and F.<= /p>

Ken

<= span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">A) Object = Identity

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

SPPP uses composite = business keys to identity object instances. There are SPPP XSD data s= tructures like ObjKeyType that serve this purpose. Object keys are us= ed to house relationships between objects and to query for (get) a specific object ins= tance. ReST controls how object identity (object keys) must be encode= d/structured, using URIs. So the SPPP XSD will need to be changed to = support the use of either URIs or more traditional approaches such as that currently used by SPPP. And this will have t= o work for both the non-composite object relationship case and for the quer= y/get case. And these changes will impact the current structure of th= e SPPP =93nouns=94. So, more specifically, the following XSD data structures will need to change:

1) RteRecType = (because it identifies the DestGroups that is relates to)=

2) PubIdType (because it identifies the DestGroup that it= belongs to)

3) ObjKeyType (because it i= s not a ReST friendly structure for object identity)

<= p class=3D"MsoNormal">4) The Data Structures that contain or depend on an ObjKeyType=

4.1) RteGrpOfferKeyType

4.2) RteGrpOfferType

4.3) EgressRteType

4.4) RteRecRefType

B) Response Codes and Response Data Structures

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

ReST controls what response codes and t= he corresponding response messages that are available to the application, t= he HTTP response codes. So SPPP=92s response codes will have to be removed since ReST dictates that it is the HTTP protocol=92s respons= e codes that are allowed. The response codes will have to be moved to= the =93Transport=94 document.

= SPPP=92s = parameterized error response code message structures that define what data = element of what object was found to be erroneous will have to be removed/ch= anged since the HTTP response codes do not give you that level of detail about what failed= . We will either have to punt on this capability or create a hybrid a= pproach that can be hacked into ReST, such that response objects contain ad= ditional sub-response codes and data structures.

SPPP=92s response data stru= cture, that incorporates an overall response code and, if there is an error= , the data structure of the object that failed validation will have to be watereddown/removed/changed.

<= span style=3D"font-size: 10pt; font-family: Arial, sans-serif; "> = ;

So, more specifically, in addition to the r= esponse code definitions being changed and the parameterization of the resp= onse code messages being removed and replaced with some other scheme, the XSD items that are likely to need to be changes are:

1= ) ResultCodeType

2) RqstObjResultCodeTyp= e

3) spppUpdateResponse

C) Actions/Ver= bs/Operations

=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=

The SPPP XSD currently defines the operations/verbs that = can be performed on each of the SPPP data model objects/nouns, and the requ= ired inputs and outputs of each. But ReST controls what verbs are available to the application (Put, Post, Get, Del)= , and provides no way of enforcing the allowable input and output data stru= ctures for each. So we will need to remove all operations/verbs and r= emove the specification of the required inputs and outputs for each operation/verb from the XSD. These will = now need to be documented just in textual form in the document.<= /span>

= D) Base P= rotocol Data Structures and Housekeeping Features

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

SPPP currently defines common reques= t and response data structures that are used for any type of operation/verb= and any type of noun, and in-fact allows different verb and noun pairs to be passed into a single request. This was done to allo= w any set of verb/noun pairs to be passed in and processed as a single tran= saction, all or nothing, giving the client optional control over their tran= saction boundaries. But because ReST uses the pre-determined verbs from HTTP (Post, Put, Get, Del), which is em= bedded inside the HTTP envelope, this type of feature cannot be cleanly pro= vided. Furthermore, house-keeping features such as clientTransId, ser= verTransId, minorVer are housed within these base data structures.

So we will either say that a ReST implementa= tion will just not support some of these features, or restructure the follo= wing XSD data structures in some way to allow some of them:

1) spppUpdateRequest

<= span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">2) spppUpd= ateResponse

3) spppQueryRequest

4) spppQueryResponse

5) spppServerStatusRequest

6) sp= ppServerStatusResponse

E) SPP = =93Protocol=94 Documentation Changes

And of course all of the above will = require notable changes to the document content itself.

F) SPP =93Transpo= rt=94 Document Changes

And of course all of the above will require notabl= e changes to the document content itself because they push mofer of the spe= cification out of the =93Protocol=94 document and up into the =93Transport=94 document.

This e-mail message is for the sole use of the int= ended 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.

<= br>

This e-mail message i= s 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_CAE14E5819B10syedalineustarbiz_-- From internet-drafts@ietf.org Tue Nov 15 14:31:54 2011 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 EDA8611E80EA; Tue, 15 Nov 2011 14:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soVWGSA+uHNL; Tue, 15 Nov 2011 14:31:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CD321F84CD; Tue, 15 Nov 2011 14:31:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111115223150.17141.18769.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2011 14:31:50 -0800 Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spprov-12.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:31:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : Session Peering Provisioning Protocol Data Model Author(s) : Kenneth Cartwright Syed Wasim Ali Alexander Mayrhofer Vikas Bhatia Filename : draft-ietf-drinks-spprov-12.txt Pages : 59 Date : 2011-11-15 This document specifies the data model and the overall structure for a protocol to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The protocol is called the Session Peering Provisioning Protocol (SPPP). The provisioned data is typically used by network elements for session peering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spprov-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-spprov-12.txt From internet-drafts@ietf.org Tue Nov 15 14:32:29 2011 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 2AD7C21F84D3; Tue, 15 Nov 2011 14:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TxpJ-0zEkrZ; Tue, 15 Nov 2011 14:32:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BC521F84CD; Tue, 15 Nov 2011 14:32:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111115223224.17713.67188.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2011 14:32:24 -0800 Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-sppp-over-soap-07.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:32:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : SPPP Over SOAP and HTTP Author(s) : Kenneth Cartwright Vikas Bhatia Filename : draft-ietf-drinks-sppp-over-soap-07.txt Pages : 87 Date : 2011-11-15 The Session Peering Provisioning Protocol (SPPP) is an XML protocol that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport for SPPP is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPP XML structures over SOAP and HTTP(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-sppp-over-soap-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-sppp-over-soap-07.txt From vbhatia@tnsi.com Tue Nov 15 14:38:39 2011 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 76FF01F0C6C for ; Tue, 15 Nov 2011 14:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkh85rjiUp49 for ; Tue, 15 Nov 2011 14:38:35 -0800 (PST) Received: from relayus.tnsi.com (relayus.tnsi.com [208.224.248.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1AC1F0C67 for ; Tue, 15 Nov 2011 14:38:31 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgAAM3owk6sEQfn/2dsb2JhbABCmWeRBgeBcgEBAQQBAQE3NBcGAQgRBAEBHwkuCxQHAQEFBAEEEwgBiAG4c4kuYwSIE543 X-IronPort-AV: E=Sophos;i="4.69,517,1315177200"; d="scan'208";a="494886" Received: from mail-hub-na.win2k.corp.tnsi.com ([172.17.7.231]) by relayus.tnsi.com with ESMTP/TLS/RC4-MD5; 15 Nov 2011 22:38:29 +0000 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 15 Nov 2011 17:38:28 -0500 From: "Bhatia, Vikas" To: "drinks@ietf.org" Date: Tue, 15 Nov 2011 17:38:27 -0500 Thread-Topic: [drinks] I-D Action: draft-ietf-drinks-spprov-12.txt Thread-Index: Acyj5mSv2ki1MIXrQHSmZieMyf0E4QAAGF7A Message-ID: <754963199212404AB8E9CFCA6C3D0CDA4B5871343E@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [drinks] FW: I-D Action: draft-ietf-drinks-spprov-12.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 22:38:39 -0000 Just submitted the updates to the protocol (new version 7) and transport (n= ew version 12) documents. The latest updates finalize the restructuring of = these documents, and all necessary changes, to provide a ReSTFul mapping to= the protocol. Thanks, Vikas -----Original Message----- From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: Tuesday, November 15, 2011 5:32 PM To: i-d-announce@ietf.org Cc: drinks@ietf.org Subject: [drinks] I-D Action: draft-ietf-drinks-spprov-12.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Data for Reachability of Inter/tra-Ne= tworK SIP Working Group of the IETF. Title : Session Peering Provisioning Protocol Data Model Author(s) : Kenneth Cartwright Syed Wasim Ali Alexander Mayrhofer Vikas Bhatia Filename : draft-ietf-drinks-spprov-12.txt Pages : 59 Date : 2011-11-15 This document specifies the data model and the overall structure for a protocol to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The protocol is called the Session Peering Provisioning Protocol (SPPP). The provisioned data is typically used by network elements for session peering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-spprov-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-drinks-spprov-12.txt _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From stpeter@stpeter.im Wed Nov 16 01:27:49 2011 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 0662921F93AC for ; Wed, 16 Nov 2011 01:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17fanEBDFmnE for ; Wed, 16 Nov 2011 01:27:48 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3227421F94D8 for ; Wed, 16 Nov 2011 01:27:48 -0800 (PST) Received: from squire.local (unknown [130.129.21.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 728A24214E; Wed, 16 Nov 2011 02:34:02 -0700 (MST) Message-ID: <4EC3820F.9060908@stpeter.im> Date: Wed, 16 Nov 2011 17:27:43 +0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Mayrhofer References: <8BC845943058D844ABFC73D2220D46650AD29D98@nics-mail.sbg.nic.at> <4E678FF8.9030503@stpeter.im> <8BC845943058D844ABFC73D2220D46650AD2A024@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650AD2A024@nics-mail.sbg.nic.at> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: drinks@ietf.org Subject: Re: [drinks] on internationalization. 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, 16 Nov 2011 09:27:49 -0000 Just FYI, Alex and I talked about this with Pete Resnick and a few other folks this evening. I assume Alex will report further. On 9/9/11 9:27 PM, Alexander Mayrhofer wrote: >>> One of the action items from the interim was to look at >>> Internationalization in SPPP. >> >> First, what are you trying to achieve? Saying "internationalization" is a bit like >> saying "security": it has many facets and often means different things to >> different people. > > Peter, that's an excellent comment and comparison. I think the considerations are as follows: > > - We have "data fields" and "identifiers" in the protocol: "data fields" are just passed through the protocol / registry ("garbage in / garbage out" style), and "identifiers" need to be compared, eg. against parameters in commands, because they're used to identify objects that are provisioned. > > - I understand (and agree) that modern IETF protocols should not be limited to pure ASCII. > > - "data fields" are probably easy to internationalize, since the components handling the procotol do not need to examine their contents. However, there might be issues when such fields are displayed (for example, when LTR and RTL strings are mixed within a field) - are there any recommendations on text regarding such issues? > > - "identifiers" are more complicated, because they're affected by all the obvious normalization / comparison issues. A quick win would be to restrict such fields to ASCII only, however, i understand that might be unacceptable from the Internationalization perspective. > > [..] >>> However, there are no additional constraints in EPP regarding the >>> contents of any field in the protocol. That means that - unless i've >>> overlooked something - EPP object data can include arbitrary Unicode >>> characters. >> >> To be precise, UTF-8-encoded Unicode code points. :) > > agreed - and, that's the option we would go for in SPPP as well. > >> See http://tools.ietf.org/html/draft-ietf-appsawg-rfc3536bis-06 for a helpful >> explanation of various i18n terms. > > Ah, thanks for the pointer - great! > > [..] >>> Therefore, to conclude, EPP allows for a broad range of characters in >>> identifiers, >> >> Earlier you talked about fields in the protocol, now you are talking about >> identifiers. Do you care more about identifiers than any other kind of field? Is >> there a distinction here? What do you *do* with these various fields and >> identifiers? Do you, for example, compare them? If so, for what purposes >> (authentication, authorization, etc.)? What are the implications if a >> comparison operation yields a false positive or a false negative? > > As outlined above, i think the identifiers are the crucial part (which doesn't mean that other fields don't matter, but they're typically not used to identify objects). > > Comparison operations are important since those identifiers are used to identify relations between objects, and also "address" objects affected by a certain command. False positives and/or negatives could lead to loosing data integrity between objects, or commands affecting the wrong objects. > >> See http://tools.ietf.org/html/draft-iab-identifier-comparison-00 for a >> detailed discussion of these issues. >> >> As to comparison of internationalized strings in application protocols, please >> consult the work of the PRECIS WG to see if it is relevant here: >> >> http://tools.ietf.org/html/draft-ietf-precis-problem-statement-03 >> >> http://tools.ietf.org/html/draft-ietf-precis-framework-00 >> >> If you are going to be comparing identifiers for purposes that have security >> implications, then I think you will need to say something more than "just use >> UTF-8". > > I will look at the PRECIS work. > >>> and since EPP has gone through IESG review successfully 3 times, i >>> would suggest that we include a similiar "Internationalization >>> Considerations" section in the SPPP protocol document, and not try to >>> restrict fields more than EPP does. >> >> What is the relationship between EPP and SPPP? Does SPPP essentially >> emulate EPP? If so, it might make sense to re-use some text from the EPP >> spec. On the other hand, it's possible that i18n issues were not really >> addressed in the EPP spec (despite surviving IESG review three times) and >> that you might want to think about these issues anew for SPPP. > > EPP and SPP serve similar purposes (provisioning objects in a "registry"), but serve different domains. SPPP is not an emulation of EPP, but has some similar properties. The impact of comparison operations on identifiers in EPP is similar to those in SPPP, which is why i was looking for respective text in those RFCs. > > Alex From sumanth@cablelabs.com Wed Nov 16 22:49:48 2011 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 A6AB821F97E7 for ; Wed, 16 Nov 2011 22:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI17-Ppi1dfr for ; Wed, 16 Nov 2011 22:49:47 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id CDA7121F97B6 for ; Wed, 16 Nov 2011 22:49:44 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id pAH6nhSS020247 for ; Wed, 16 Nov 2011 23:49:43 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 16 Nov 2011 23:49:43 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 16 Nov 2011 23:49:43 -0700 From: Sumanth Channabasappa To: "Drinks@ietf.org" Importance: high X-Priority: 1 Date: Wed, 16 Nov 2011 23:49:43 -0700 Thread-Topic: DRINKS WG is meeting tomorrow (Fri) Thread-Index: Acyk8+4Yx4x9H5HbTnWZi61/tF6WKA== Message-ID: <76AC5FEF83F1E64491446437EA81A61F819B271029@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F819B271029srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [drinks] DRINKS WG is meeting tomorrow (Fri) 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, 17 Nov 2011 06:49:48 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F819B271029srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, A quick reminder that the DRINKS WG is meeting tomorrow (starting at 11:20a= Taipei time). As you may be aware, the design team has been busy making pr= ogress since Quebec and the interim meeting we had in August. As a result t= here have been a few revisions to the I-Ds since the last IETF. We will be = discussing the changes, status, and the next steps. We hope to see you ther= e! You can find the agenda at: http://www.ietf.org/proceedings/82/agenda/drink= s.txt Thanks! - Alex & Sumanth --_000_76AC5FEF83F1E64491446437EA81A61F819B271029srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

A quick= reminder that the DRINKS WG is meeting tomorrow (starting at 11:20a Taipei= time). As you may be aware, the design team has been busy making progress = since Quebec and the interim meeting we had in August. As a result there ha= ve been a few revisions to the I-Ds since the last IETF. We will be discuss= ing the changes, status, and the next steps. We hope to see you there!=

Yo= u can find the agenda at: http://www.ietf.org/proceedings/82/agenda/drinks.txt

Thanks!

- Alex & Sumanth=

&nb= sp;

= --_000_76AC5FEF83F1E64491446437EA81A61F819B271029srvxchg_-- From alexander.mayrhofer@nic.at Thu Nov 17 01:17:57 2011 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 1938421F99A8 for ; Thu, 17 Nov 2011 01:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.724 X-Spam-Level: X-Spam-Status: No, score=-8.724 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUsyiD4ZOjlz for ; Thu, 17 Nov 2011 01:17:56 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id CF95721F94C4 for ; Thu, 17 Nov 2011 01:17:55 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Thu, 17 Nov 2011 10:17:54 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.339.1; Thu, 17 Nov 2011 10:17:51 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 17 Nov 2011 10:17:46 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B0E3766@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internationalization Update Thread-Index: Acyk+hrlfO1mCG7qTie2di7jzoQXJA== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Cc: pete resnick Subject: [drinks] Internationalization Update 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, 17 Nov 2011 09:17:57 -0000 All, one of the open issues of SPPP is updating Internationalization considerations. For a background of the issue, please read the following earlier thread: http://www.ietf.org/mail-archive/web/drinks/current/msg01024.html I met with Peter Saint-Andre, Robert Sparks and Pete Resnick, and we hab a brief, but very productive discussion. I explained that we have concerns about two different types of elements in our protocol: - Elements that are simple "garbage in", "garbage out" (or "Blobs"). These elements serve as "data container" and the contents of these elements is not tied to any semantics in the protocol. An example of such an element is the "sourceIdentLabel". - Elements that serve as identifiers: Since those elements are used to identify object instances, they have semantics attached to their values, and need eg. be compared. An example of such an element is the "dgName" For the "simple" elements, there was agreement that no special considerations need to be applied. If comparison of such elements is ever to be done, then it would be bytewise comparison. I clarified that we have already restricted most elements to the XML "token" schema definition. For the "identifier" elements: Pete Resnick asked me a few questions to narrow the issue down (my answer in parentheses, i hope i remembered all of them correctly): - Q: Are the elements machine-generated? A: No, could be created by provisioning staff. - Q: Are they going to be displayed to users? A: Yes, could be that provisioning staff reads them. - Q: Do we want to allow whitespace in those identifiers? A: No, we don't need whitespace (Personal decision, any objections?) - Q: Do we need "similar looking" characters, such as the japanese "ASCII-equivalent"-Characters eg. match the respective ASCII characters? In other words, are we fine with some false negatives? A: Yes, we are fine with false negatives in comparison operations in such cases. - Do we want the elements to be case sensitive? A: Not sure, probably. We continued the discussion with my assumption that we would need to choose a Stringprep profile, and apply that in the propoer positions in the data flow. However, Pete noted that we would probably not need Stringprep in the first place, but one of the Unicode normalization function would be sufficient. The recommended method would be NFC (Normalization Form C).=20 If we want the elements to be case insensitive, we could alsp require the Unicode operation toLower applied. >From my perspective, the next step would be to decide at which point those normalizations need to be applied (Client? Server?). Maybe we can briefly discuss this in the WG session on friday, and subsequently create actual text. Alex From stpeter@stpeter.im Thu Nov 17 02:03:42 2011 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 2D26621F9B92 for ; Thu, 17 Nov 2011 02:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gvpywN9N4d1 for ; Thu, 17 Nov 2011 02:03:41 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBB421F9B6F for ; Thu, 17 Nov 2011 02:03:41 -0800 (PST) Received: from dhcp-1422.meeting.ietf.org (unknown [130.129.20.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D6B38421AB; Thu, 17 Nov 2011 03:09:58 -0700 (MST) Message-ID: <4EC4DBF9.3030906@stpeter.im> Date: Thu, 17 Nov 2011 18:03:37 +0800 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Pete Resnick References: <8BC845943058D844ABFC73D2220D46650B0E3766@nics-mail.sbg.nic.at> <4EC4D513.6090807@qualcomm.com> In-Reply-To: <4EC4D513.6090807@qualcomm.com> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: drinks@ietf.org Subject: Re: [drinks] Internationalization Update 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, 17 Nov 2011 10:03:42 -0000 On 11/17/11 5:34 PM, Pete Resnick wrote: > On 11/17/11 5:17 PM, Alexander Mayrhofer wrote: >> From my perspective, the next step would be to decide at which point >> those normalizations need to be applied (Client? Server?). Maybe we can >> briefly discuss this in the WG session on friday, and subsequently >> create actual text. >> > > If you let me know approximately when this might appear on the agenda, > I'll be there. At the very least, I'll make sure to be in Jabber and you > can give me a heads-up when the topic is starting. I'll be in the CORE WG session at that time, so unable to join. Peter -- Peter Saint-Andre https://stpeter.im/ From alexander.mayrhofer@nic.at Thu Nov 17 06:12:19 2011 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 8409411E8123 for ; Thu, 17 Nov 2011 06:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.825 X-Spam-Level: X-Spam-Status: No, score=-8.825 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AVQ+ktDtQwK for ; Thu, 17 Nov 2011 06:12:19 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 81A6B11E80E4 for ; Thu, 17 Nov 2011 06:12:18 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Thu, 17 Nov 2011 15:12:17 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.339.1; Thu, 17 Nov 2011 15:12:15 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 17 Nov 2011 15:12:12 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B0E37DE@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slide decks for DRINKS WG meeting are posted. Thread-Index: AcylMlSshsZb2aP+QuWHz8rz0MBI2A== From: Alexander Mayrhofer To: X-XWALL-BCKS: auto Subject: [drinks] Slide decks for DRINKS WG meeting are posted. 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, 17 Nov 2011 14:12:19 -0000 All, the slide decks for our WG meeting tomorrow are now available on the Meeting Materials site: https://datatracker.ietf.org/meeting/82/materials.html We might still apply minor changes to the slides, so you might want to re-fetch the slides right before the meeting. thanks, Alex From dschwartz@xconnect.net Thu Nov 17 07:21:58 2011 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 5C77E1F0C8B for ; Thu, 17 Nov 2011 07:21:58 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBER1r9dV79i for ; Thu, 17 Nov 2011 07:21:53 -0800 (PST) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by ietfa.amsl.com (Postfix) with ESMTP id 90E911F0C69 for ; Thu, 17 Nov 2011 07:21:52 -0800 (PST) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Thu, 17 Nov 2011 17:21:50 +0200 From: David Schwartz To: "drinks@ietf.org" Date: Thu, 17 Nov 2011 17:21:49 +0200 Thread-Topic: Some comments/nits on latest SPProv doc Thread-Index: AcylPKCeXYFm9wU6TJm6VV7C43gloQ== Message-ID: <00DC9946-3629-43F1-BEAC-CBEEC5FC736C@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_00DC9946362943F1BEACCBEEC5FC736Cxconnectnet_" MIME-Version: 1.0 Subject: [drinks] Some comments/nits on latest SPProv doc X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 15:21:58 -0000 --_000_00DC9946362943F1BEACCBEEC5FC736Cxconnectnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi guys I reviewed the SPProv doc and have a few comments. I will start with the little nits=85 * Throughout the doc there is reference to "Modify" operation when in reali= ty it does not exist (only ADD/DEL/GET/ACCEPT/REJECT) * Page 12 - An an organization=85 * Page 30 - missing SourceIdentRegex in the schema of SourceIdentType * Page 38 - egrRte missing from arc diagram on page 10 * 5.2.1 - the enumeration value --> not vaue * 5.2.2 - Is this a contradiction? --> ObjKeyType MUST contain the followin= g attribute . . . DG . . . This is an optional attribute. * 7.6 - double "." at end of sentence Moving on to comments... 4.3 -> why isn't this a MUST? 4.8 -> why isn't this a MUST? And some questions/opinions=85 Destination Groups 6.1 -> I think that DG should have priority field as well. This allows to d= ifferentiate based on a a parameter other than route (e.g. cost) Page 40 - When DG removed - it says PIs removed -> not references by PIs (s= ee next comment about PIs) PIs Page 23 - why is a PI associated with only 1 DG? why not more? What if I ha= ve some TNRange and I want to have both "gold" and "silver" routes associat= ed with it - how would I do this without having this TNR referencing more t= han one DG? 6.2 -> what happened to the URI type? Why can't an identifier be a URI (e.g= . AOR)? Why can't my gmail address be the lookup identity without requiring= "gmail.com" to me anything more than an opaque string. Page 24 -> isn't the idea of a RouteGroup to "group" route records"? Why th= en in the definition of a TN do we refer to an rrRef instead of an rgRef? T= he description does say "one or more" rrRefs which would imply to me that t= his could be a rgRef Page 25 - why is RNType associated with DG and not RG or RR? what is logic = of grouping RN's? I would assume that RN's have a closer relationship to RG= s than DGs Why isn't corinfo part of the base PI type SourceID Page 30 - Why not simply a URI instead of enumeration as regex can deal wit= h parts of URI. We all know that in the end the source information will be = represented in the DNS request using a URI. Page 38 - why isn't egrRte associated with RG? Page 38 - why not associated with RteRecType instead of obj? :D --_000_00DC9946362943F1BEACCBEEC5FC736Cxconnectnet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi guys

I reviewed the SPProv doc a= nd have a few comments.

I will start with the little nits=85

* Th= roughout the doc there is reference to "Modify" operation when in reality i= t does not exist (only ADD/DEL/GET/ACCEPT/REJECT)

* Page 12 - An an organizati= on=85

* P= age 30 - missing SourceIdentRegex in the schema of SourceIdentType

* Page 38 - egrRt= e missing from arc diagram on page 10

* 5.2.1 - the enumeration value --> = not vaue

* 5.2.2 - Is this a contradiction? --> ObjKeyType MUST contain th= e following attribute . . . DG . . . This is an optional attribute.

* 7.6 - double "= ." at end of sentence

Moving on to comments...

4.3 -> why isn'= t this a MUST?

4.8 -> why isn't this a MUST?

And some questions/opinions=85<= /div>

Destination Groups

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

P= age 40 - When DG removed - it says PIs removed -> not references by PIs = (see next comment about PIs)

PIs

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

6.2 -> what happened to the URI type? Wh= y can't an identifier be a URI (e.g. AOR)? Why can't my gmail address be th= e lookup identity without requiring "gmail.com= " to me anything more than an opaque string.

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

Page 25 - why = is RNType associated with DG and not RG or RR? what is logic of grouping RN= 's? I would assume that RN's have a closer relationship to RGs than DGs

Why isn't co= rinfo part of the base PI type

SourceID

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

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

Page 38 - why not associate= d with RteRecType instead of obj?

= --_000_00DC9946362943F1BEACCBEEC5FC736Cxconnectnet_-- From ietf@meetecho.com Thu Nov 17 10:36:59 2011 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 C40F91F0C65 for ; Thu, 17 Nov 2011 10:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqj6uX5EuRcN for ; Thu, 17 Nov 2011 10:36:59 -0800 (PST) Received: from smtplq03.aruba.it (smtplq-out18.aruba.it [62.149.158.38]) by ietfa.amsl.com (Postfix) with SMTP id 726D31F0C64 for ; Thu, 17 Nov 2011 10:36:55 -0800 (PST) Received: (qmail 10211 invoked by uid 89); 17 Nov 2011 18:36:53 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq03.aruba.it with SMTP; 17 Nov 2011 18:36:53 -0000 Received: (qmail 20881 invoked by uid 89); 17 Nov 2011 18:36:53 -0000 Received: from unknown (HELO ?192.168.15.115?) (ietf@meetecho.com@114.24.8.77) by smtp1.ad.aruba.it with SMTP; 17 Nov 2011 18:36:53 -0000 Message-ID: <4EC5543B.2090205@meetecho.com> Date: Thu, 17 Nov 2011 19:36:43 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: drinks@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Subject: [drinks] Meetecho support for DRINKS WG meeting session 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, 17 Nov 2011 18:36:59 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Friday's DRINKS WG meeting session. Access to the on-line session (including audio and video streams) will be available from 11:20am at: http://www.meetecho.com/ietf82/drinks The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf82/tutorials For further information you can contact us at ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From alexander.mayrhofer@nic.at Thu Nov 17 17:59:15 2011 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 D8BC311E8097 for ; Thu, 17 Nov 2011 17:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.9 X-Spam-Level: X-Spam-Status: No, score=-8.9 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBIkI92qu98A for ; Thu, 17 Nov 2011 17:59:15 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id E9D1611E808A for ; Thu, 17 Nov 2011 17:59:14 -0800 (PST) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47 ; Fri, 18 Nov 2011 02:59:12 +0100 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.1.339.1; Fri, 18 Nov 2011 02:59:07 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 18 Nov 2011 02:59:03 +0100 Message-ID: <8BC845943058D844ABFC73D2220D46650B0E3821@nics-mail.sbg.nic.at> In-Reply-To: <4EC4D513.6090807@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internationalization Update Thread-Index: AcylDBkGONE1kGd2SqKdbW4rpc/a8QAiRJqA References: <8BC845943058D844ABFC73D2220D46650B0E3766@nics-mail.sbg.nic.at> <4EC4D513.6090807@qualcomm.com> From: Alexander Mayrhofer To: Pete Resnick X-XWALL-BCKS: auto Cc: drinks@ietf.org Subject: Re: [drinks] Internationalization Update 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, 18 Nov 2011 01:59:16 -0000 > If you let me know approximately when this might appear on the agenda, I'll > be there. At the very least, I'll make sure to be in Jabber and you can give me > a heads-up when the topic is starting. Pete, sorry for the late notice. We will only make use of the first meeting slot for DRINKS (11:20 - 12:20), and we will discuss i18n at the end of the "Protocol" agenda item. This should come up shortly before noon (it's on the last slide of the "Protocol" slide deck, which is scheduled for between 11:40 and 11:55).=20 Would be great if you can make it. We will definitely give you a heads up in Jabber. Alex From ietf@meetecho.com Mon Nov 21 02:53:16 2011 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 34AA021F87E2 for ; Mon, 21 Nov 2011 02:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.329 X-Spam-Level: X-Spam-Status: No, score=0.329 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb5UBKwgQL8k for ; Mon, 21 Nov 2011 02:53:12 -0800 (PST) Received: from smtplq02.aruba.it (smtplq-out17.aruba.it [62.149.158.37]) by ietfa.amsl.com (Postfix) with SMTP id 47DA821F85EF for ; Mon, 21 Nov 2011 02:53:05 -0800 (PST) Received: (qmail 17965 invoked by uid 89); 21 Nov 2011 10:53:05 -0000 Received: from unknown (HELO smtp7.aruba.it) (62.149.158.227) by smtplq02.aruba.it with SMTP; 21 Nov 2011 10:53:05 -0000 Received: (qmail 855 invoked by uid 89); 21 Nov 2011 10:53:05 -0000 Received: from unknown (HELO ?143.225.229.189?) (ietf@meetecho.com@143.225.229.189) by smtp7.ad.aruba.it with SMTP; 21 Nov 2011 10:53:04 -0000 Message-ID: <4ECA2D82.6040907@meetecho.com> Date: Mon, 21 Nov 2011 11:52:50 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: drinks@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp7.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Subject: [drinks] DRINKS session recording available X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 10:53:16 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of DRINKS session at IETF-82 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/82/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf82/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com