From root@core3.amsl.com Wed May 27 11:15:01 2009 Return-Path: X-Original-To: drinks@ietf.org Delivered-To: drinks@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B704A3A70EE; Wed, 27 May 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090527181501.B704A3A70EE@core3.amsl.com> Date: Wed, 27 May 2009 11:15:01 -0700 (PDT) X-Mailman-Approved-At: Mon, 01 Jun 2009 11:02:00 -0700 Cc: drinks@ietf.org Subject: [drinks] I-D Action:draft-ietf-drinks-usecases-requirements-00.txt X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 18:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Data for Reachability of Inter/tra-NetworK SIP Working Group of the IETF. Title : DRINKS Use cases and Protocol Requirements Author(s) : S. Channabasappa Filename : draft-ietf-drinks-usecases-requirements-00.txt Pages : 22 Date : 2009-05-27 This document captures the use cases and associated requirements for interfaces to provision session establishment data into SIP Service Provider components that aid with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drinks-usecases-requirements-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-drinks-usecases-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-27110739.I-D@ietf.org> --NextPart-- From jf.mule@cablelabs.com Fri Jun 12 08:02:59 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0963A68E5 for ; Fri, 12 Jun 2009 08:02:59 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCnRoXPHgx7E for ; Fri, 12 Jun 2009 08:02:42 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 816D33A6877 for ; Fri, 12 Jun 2009 08:02:42 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n5CF2oAg012500 for ; Fri, 12 Jun 2009 09:02:50 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 12 Jun 2009 09:02:50 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EB6E.DA80951D" Date: Fri, 12 Jun 2009 09:02:26 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601EED10B@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes from May 28 & June 9 protocol design team calls thread-index: Acne6sDoOZPHzmdfQAO0sBMSNs2nEQMgywTA From: "Jean-Francois Mule" To: X-Approved: ondar Subject: [drinks] Minutes from May 28 & June 9 protocol design team calls X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 15:02:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EB6E.DA80951D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ---=20 --- IETF DRINKS WG, protocol design team minutes --- Summary of May 28 and June 9, 2009 Calls --- 5/28 Attendees Debbie Guyton=20 Alex Mayhofer Manjul Maharishi Ken Cartwright Spencer Dawkins Richard Shockey Jean-Francois Mule --- 6/9 Attendees Debbie Guyton Richard Shockey Manjul Maharishi Ken Cartwright Jean-Francois Mule --- Combined Agendas 1/ Updated Action Item List 2/ Protocol I-D: Outline discussion 3/ Data Model Discussion 4/ Timeline reminder for the first proto I-D=20 5/ Other open items --- Notes Minutes reported by Debbie and Jean-Francois.=20 Any comments on these notes should be sent to drinks@ietf.org=20 =20 The meeting notes from the 5/21 call were reviewed and there were no comments or questions. 1/ Updated Action Item List [Jean-Francois] We reviewed the action item list on the 5/28 and 6/9 calls. Below are the open and closed action items. Action Item (AI): Jean-Francois, closed 6/8 Jean-Francois did ping Lisa to get her on a call with this group, copied wg chairs # AI: Sumanth, open # On a regular basis by sending mails to IETF drinks list with deltas # and proposed changes. Keep the use case and requirement documents in # sync in case use cases need to be improved. =20 # AI: Ken, closed and re-open, provide update before 6/12 COB=20 # Ken to send a updated proposal for doc outline based on the design # team feedback (see notes below). # AI: Jean-Francois, open, due by COB 6/12 # Send input based on previous IETF DRINKS discussions related to # protocol transport requirements # AI: All, open, due by COB 6/12 # Review list of protocol data elements provided by Debbie on 5/28 for # consideration, send comments=20 =20 # AI: Manjul, closed and re-open, provide update by 6/12 COB # Send updated data model based on design team comments # AI: Manjul and Rich, by COB 6/12 # Come up with a couple of examples of source-based routing and the # notion of an SED Record: how could it be addressed in the data model? # -> candidate for use case update? =20 2/ Protocol I-D: Outline discussion We discussed the document outline proposed by Ken on the 6/9 call. + Naming As usual, we started with a discussion on the name of the protocol. We welcome ideas from the DRINKS protocol naming committee. For now, we were all fine with using: - Session Peering Provisioning Protocol (SPPP) for client to Registrar - Session Peering Distribution Protocol (SPDP) for registrar to downstream entities We thought we should avoid using "voice" and some thought we may not even need to use peering. + Docs used for reference and document structure Ken covered the list of RFCs reviewed to come up with the document outline, including NETCONF and EPP. We reviewed the high level approach of separating the message from the transport and have 2 separate documents in the long term. The first draft may have combined sections to expedite things though. In addition, it might be useful to have another (3rd) document that considers a file based approach to provisioning. + Thin vs. Thick approach for WSDL definition Ken suggested we use a "thin" WSDL approach versus "thick". Keep the protocol generic with a request and a response. Give an object type and then within the XML, extend the generic types with concrete objects. It is the approach taken by NETCONF. Ken noted that this approach was not retained in a separate industry effort (e.g. ESPP protocol submitted once to peppermint as in put was not designed like that). The first protocol definition will give a good example of what is meant by Thin here. + Extensibilility of the protocol We discussed extensibility and that it is desirable. We discussed some details of what should be extensible vs. firmed up in the protocol definition so that extensibility does not become an issue. Alex stated that too many levels of extensibility may actually create issues because folks extend it in all ways possible. After some discussion, Ken suggested that may be the core protocol elements may not be extended. Jean-Francois proposed to define rules for how one could extend the protocol and we should define a registry with rules for what extensions are ok without expert reviews vs. ones that do need to go through IETF expert reviews. Consensus for now: focus on the first protocol draft and wg comments. Once we have a good draft, we will go through a detailed review to discuss each extension field to determine if it is needed, good or bad. + Outline We reviewed the first draft outline for SPPP sent by Ken to the DRINKS list. 1 Introduction=20 2 Transport Requirements=20 2.1 Connection Oriented Operation=20 2.2 Authentication=20 2.3 Mandatory Transport=20 2.4 Pipelining=20 3 XML Considerations=20 3.1 Namespaces=20 3.2 Versioning=20 4 Request and Reply Model=20 4.1 Request=20 4.2 Reply=20 4.3 Object Identity=20 4.4 Client/Server Synchronization=20 4.5 Result Codes=20 As we looked at the client/server synchronization heading (section 4.4), Jean-Francois suggested that we might want to consider discussing a "publish and subscribe" model.=20 It was felt that this may make some sense on the distribution side, but not on the provisioning side. Debbie suggested that it may be impacted by the number of Registries in place. Manjul questioned whether the publish and subscribe model would be at the TN or user identity or Service Provider (SP) level? At the TN level this would get complicated. It was suggested that we keep this idea on our open ideas' list. 5 Protocol Commands=20 5.1 "Command 1"=20 5.1.1 Description=20 5.1.2 Example=20 5.1.2 Applicable Result Codes=20 5.2 "Command 2"=20 5.2.1 Description=20 5.2.2 Example=20 5.2.2 Applicable Result Codes=20 6 Security Considerations=20 7 IANA Considerations=20 8 Authors and Acknowledgements=20 9 References=20 9.1 Normative References=20 9.2 Informative References=20 Appendix A Formal Specification - XSD=20 Appendix B Specification Extensibility=20 Spencer recommended that we look at RFC 3552 as it discusses information to help write the security considerations section. Also we suggested we move the appendices up into the document itself to become normative text. As we had only approximately 10 minutes left for the call, we agreed to not review the transport outline as there we no major comments planned. Folks should review and follow up with comments to the list as necessary. 3/ Data Model Discussion We moved to a discussion of the data model and Manjul reviewed the basic model below: +---------+ +--------------+ | Data | |DATA RECIPIENT| |Recipient|----------->| GROUP | +---------+ +------.-------+ ^ | | +--------------+ +---------+ | ROUTING | ------------->| SED | | GROUP | | Record | +--------------+ +---------+ ^ ^ | | | | +--------------+ | ----->| DESTINATION |<----- | | | GROUP | | | | +--------------+ | | | ^ | | | | | | | | | | | | | | +---------+ +---------+ +---------+ | | RN | | TN | | Public |------- | | | Range | |Identity | +---------+ +---------+ +---------+ We discussed the term "SED Record" and based on a question from Jean-Francois, we were not clear what we meant for "SED Record". This used to the information you can get back from a NAPTR DNS RR, or a pointer to an NS RR for where to get the information. We did remember that during the IETF DRINKS WG meetings, some folks thought that we should not use DNS Resource Record as statically in the data model. Manjul suggested that per the use cases, we may also want to add route prioritization and source based routing. Jean-Francois recommended that we drill down look at what this SED Record could/should include in more detail terms. # AI: Manjul and Rich, by COB 6/12 # Come up with a couple of examples of source-based routing and the # notion of an SED Record: how could it be addressed in the data model? # -> candidate for use case update? perhaps give some examples. Time was up for the 5/28 call. There were no calls the week of June 1st. On the 6/9 call, we continued reviewing the data model with an update from Ken (provided file was a MS Visio diagram and a Word one, available upon request to Ken, Debbie or Jean-Francois).=20 The updated data model provided more details on the lower part of the data model and had NS and NAPTR objects associated with Routing Group. Ken and Manjul proposed an updated draft data model based on what is in the use case and requirements document. A number of elements addressing requirements were left out to focus on the key objects and object grouping first. A new object replaced the "Data Recipient" object above. It is now called 'Organization' and it represents an entity that can play various roles: - a session peer (data recipient) - an entity that has legal responsibility for some of the data - a registrar that manages the data in the Registry on behalf of a registrant =20 Changes requested based on team comments: a) use public identifier instead of public identity; agreed b) use RN instead of LRN, less US centric; agreed c) carry the registrar and registrant ID on each object; agreed. We had some discussion on this. Ken explained the different roles: - role 1: "registrar" - an entity that manages the data in the registry on behalf of one or more registrant(s). - e.g. provision an object - entity that can insert/create/delete/view - role 2: "registrant" - business entity that "owns" the data from a business perspective... - an entity that has rights to manage data: e.g. carrier of record =3D> we agreed to have a registrar and registrant ID for all objects for now; we need to explain more clearly why that is and whether this imposes some limitations or to the contrary, allows simpler use & protocol implementations. We also digressed and discussed how do we validate that an organization A can provision data on behalf of B? We had consensus to say that this is more of a business agreement that has to be reflected outside the data model (out of scope). d) "only one entity can do the provisioning of the data" A registrant may outsource part of the data provisioning to a registrar and there might be multiple registrars that can administer different parts of the data for a given registrant. That said, given an object instance, there was agreement that it is ok to limit the protocol so that only one entity has create/update/delete access to the object's value. Jean-Francois proposed we clarify our vocabulary, what roles mean in terms of access rights (CRUD or rwxd). e) remove sourceIPs as attribute to any object Jean-Francois commented that basing the source-based routing on the source IP of the resolution or querying systems will not fly. Rich and Ken indicated this is how it's implemented in some networks today. After some discussion, it was agreed that how one maps a resolution request with the organization identity can vary (some may based this mapping on lower-layer security mechanisms, some may do so by linking transport layer credentials to data model views, etc.). The idea is that we likely don't care much in the protocol. Rich used the example of the discussions in DNSop around source-based DNS resolution as another way to distinguish who asks the query. Consensus: - remove sourceIPs - define a generic attribute called source_label and state that additional security mechanisms can be layered on top of that to determine the source of a query. f) More general Route objects as opposed to NAPTR and NS Objects Jean-Francois sent comments to generalize those objects. Ken added that the proposal should be explored. We discussed the two possible approaches: - one object called NS and one NAPTR (static, DNS centric structures), and may be other objects as well - single object e.g. Route or Route Node that contains the attributes of NS, NAPTR, URI that can be extended in the future, something closer to a list of parameters that can be used to construct those specific objects by the resolution engines Ken added that it may simplify the data model to some extent but we would need to define Route types. We did a roundtable to understand where the consensus was. We determined that we had no consensus on the 6/9 call and more discussions are required with an example. Manjul added that the result of a LUF is a URI, the key question is where do we get the URI from in our data model and how to model it. # AI: Ken to update the data model and investigate proposal to see # what it would mean to remove NS and NAPTR RRs. # due date: COB 6/12 4/ Timeline reminder for the first proto I-D We are still shooting for a first draft for WG review and comments by the cut-off date. =20 5/ Other open items During our discussions, some questions remain open and we would welcome input from the DRINKS WG: - provide some examples of SED data elements Basically, what needs to be represented as an object attribute in the data model, somehow, somewhere so that querying entities can make up the stuff they need to do (either complete LRF resolution, or just initiate signaling) - organization or enterprise identifiers Explain the roles of enterprise ids in the data model clearly and what rules are associated with those roles. Currently identified roles are: registrar, registrant. =20 - do we need a means to push updates in the protocol? publish/subscribe model for some data? - review list of data elements proposed with an extension field and argue whether it is really needed, potentially harmful or actually good. Next calls: - Thursday June 11, 1pm MT, 3pm ET, and 9pm CET. - Monday June 15, 8am MT, 10am ET, 4pm CET. - Wednesday June 17, 1pm MT, 3pm ET, 9 pm CET (call with Lisa) Any comments on these notes should be sent to drinks@ietf.org > end. ------_=_NextPart_001_01C9EB6E.DA80951D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes from May 28 & June 9 protocol design team = calls

---
--- IETF DRINKS WG, protocol = design team minutes
--- Summary of May 28 and June 9, = 2009 Calls


--- 5/28 = Attendees
Debbie Guyton

Alex Mayhofer
Manjul Maharishi
Ken Cartwright
Spencer Dawkins
Richard Shockey
Jean-Francois Mule

--- 6/9 = Attendees
Debbie Guyton
Richard Shockey
Manjul Maharishi
Ken Cartwright
Jean-Francois Mule


--- = Combined Agendas
1/ Updated Action Item = List
2/ Protocol I-D: Outline = discussion
3/ Data Model = Discussion
4/ Timeline reminder for the = first proto I-D
5/ Other open = items


--- Notes
Minutes reported by Debbie and = Jean-Francois.
Any comments on these notes should be sent to drinks@ietf.org
 
The meeting notes from the 5/21 call were reviewed and there were no
comments or questions.


1/ = Updated Action Item List [Jean-Francois]
We reviewed the action item list on the 5/28 = and 6/9 calls.  Below are
the open and closed action items.

Action Item (AI): Jean-Francois, closed 6/8
Jean-Francois did ping Lisa to get her on a call with this group,
copied wg chairs

# = AI:  Sumanth, open
# On a regular basis by sending = mails to IETF drinks list with deltas
# and proposed changes. Keep the = use case and requirement documents in
# sync in case use cases need to = be improved.
 
# AI: = Ken, closed and re-open, provide update before 6/12 = COB
# Ken to send a updated proposal = for doc outline based on the design
# team feedback (see notes = below).

# AI: Jean-Francois, open, due by = COB 6/12
# Send input based on previous = IETF DRINKS discussions related to
# protocol transport = requirements

# AI: All, open, due by COB = 6/12
# Review list of protocol data = elements provided by Debbie on 5/28 for
# consideration, send = comments
 
# AI: = Manjul, closed and re-open, provide update by 6/12 = COB
# Send updated data model based = on design team comments

# AI: Manjul and Rich, by COB = 6/12
# Come up with a couple of = examples of source-based routing and the
# notion of an SED Record: how = could it be addressed in the data model?
# -> candidate for use case = update?
 
2/ = Protocol I-D: Outline discussion
We discussed the document outline proposed by = Ken on the 6/9 call.

+ Naming
As usual, we started with a discussion on the = name of the protocol.
We welcome ideas from the DRINKS protocol naming = committee.  For now,
we were all fine with using:
 - Session Peering Provisioning Protocol (SPPP)
        for client to = Registrar
 - Session Peering Distribution Protocol (SPDP)
        for registrar to = downstream entities
We thought we should avoid using "voice" and some thought we = may not
even need to use peering.

+ Docs used for reference and = document structure
Ken covered the list of RFCs reviewed to come = up with the document
outline, including NETCONF and EPP.
We reviewed the high level approach of separating the message from = the
transport and have 2 separate documents in the long term.   = The first
draft may have combined sections to expedite things though.
In addition, it might be useful to have another (3rd) document that
considers a file based approach to provisioning.

+ Thin vs. Thick approach for = WSDL definition
Ken suggested we use a “thin” = WSDL approach versus “thick”. Keep the
protocol generic with a request and a response.  Give an = object type
and then within the XML, extend the generic types with concrete
objects.  It is the approach taken by NETCONF.  Ken = noted that this
approach was not retained in a separate industry effort (e.g. ESPP
protocol submitted once to peppermint as in put was not designed = like
that).
The first protocol definition will give a good example of what is
meant by Thin here.

+ Extensibilility of the = protocol
We discussed extensibility and that it is = desirable. We discussed some
details of what should be extensible vs. firmed up in the protocol
definition so that extensibility does not become an issue.
Alex stated that too many levels of extensibility may actually = create
issues because folks extend it in all ways possible. After some
discussion, Ken suggested that may be the core protocol elements may
not be extended. Jean-Francois proposed to define rules for how one
could extend the protocol and we should define a registry with rules
for what extensions are ok without expert reviews vs. ones that do
need to go through IETF expert reviews.

Consensus for now: focus on the first protocol draft and wg = comments.
Once we have a good draft, we will go through a detailed review to
discuss each extension field to determine if it is needed, good or
bad.


+ Outline
We reviewed the first draft outline for SPPP = sent by Ken to the DRINKS
list.

 1 Introduction
 2 Transport Requirements
 2.1 Connection Oriented Operation
 2.2 Authentication
 2.3 Mandatory Transport
 2.4 Pipelining

 3 XML Considerations
 3.1 Namespaces
 3.2 Versioning

 4 Request and Reply Model
 4.1 Request
 4.2 Reply
 4.3 Object Identity
 4.4 Client/Server Synchronization
 4.5 Result Codes

As we looked at the client/server synchronization heading (section
 4.4), Jean-Francois suggested that we might want to consider
discussing a “publish and subscribe” model.
It was felt that this may make some sense on the distribution side, = but
not on the provisioning side. Debbie suggested that it may be = impacted
by the number of Registries in place.  Manjul questioned = whether the
publish and subscribe model would be at the TN or user identity
or Service Provider (SP) level?  At the TN level this would = get
complicated.
It was suggested that we keep this idea on our open ideas' list.

 5 Protocol Commands
 5.1 "Command 1"
 5.1.1 Description
 5.1.2 Example
 5.1.2 Applicable Result Codes
 5.2 "Command 2"
 5.2.1 Description
 5.2.2 Example
 5.2.2 Applicable Result Codes

 6 Security Considerations
 7 IANA Considerations
 8 Authors and Acknowledgements
 9 References
 9.1 Normative References
 9.2 Informative References
   Appendix A Formal Specification - XSD
   Appendix B Specification Extensibility

Spencer recommended that we look at RFC 3552 as it discusses
information to help write the security considerations section. Also = we
suggested we move the appendices up into the document itself to = become
normative text.

As we had only approximately 10 minutes left for the call, we agreed
to not review the transport outline as there we no major comments
planned.  Folks should review and follow up with comments to = the list
as necessary.

3/ Data = Model Discussion
We moved to a discussion of the data model = and Manjul reviewed the
basic model below:

       = +---------+          &n= bsp; +--------------+
       |  Data   = |            = |DATA RECIPIENT|
       = |Recipient|----------->|     = GROUP    |
       = +---------+          &n= bsp; +------.-------+
            &= nbsp;           &n= bsp;            = ^
            &= nbsp;           &n= bsp;            = |
            &= nbsp;           &n= bsp;            = |
            &= nbsp;           &n= bsp;     +--------------+    = ;           = +---------+
            &= nbsp;           &n= bsp;     |    ROUTING &= nbsp; | ------------->|   SED   |
            &= nbsp;           &n= bsp;     |     = GROUP    |       &= nbsp;       |  Record |
            &= nbsp;           &n= bsp;     +--------------+    = ;           = +---------+
            &= nbsp;           &n= bsp;            = ^            =             &= nbsp;   ^
            &= nbsp;           &n= bsp;            = |            =             &= nbsp;   |
            &= nbsp;           &n= bsp;            = |            =             &= nbsp;   |
            &= nbsp;           &n= bsp;     +--------------+    = ;            =     |
            &= nbsp;           --= --->| = DESTINATION  |<-----      &nbs= p;       |
            &= nbsp;          = |      |    GROUP =     = |      |      = ;       |
            &= nbsp;          = |      +--------------+   &n= bsp;  |         &n= bsp;   |
            &= nbsp;          = |            = = ^            =   |          =    |
            &= nbsp;          = |            = = |            =   |          =    |
            &= nbsp;          = |            = = |            =   |          =    |
            &= nbsp;          = |            = = |            =   |          =    |
            &= nbsp;     +---------+   = +---------+     = +---------+       |
            &= nbsp;     |   = RN    |   |   = TN    |     | = Public  |-------
            &= nbsp;     |      &= nbsp;  |   = |  Range  |     |Identity |
            &= nbsp;     +---------+   = +---------+     +---------+


We discussed the term “SED Record” and based on a question = from
Jean-Francois, we were not clear what we meant for "SED = Record".
This used to the information you can get back from a NAPTR DNS RR, = or
a pointer to an NS RR for where to get the information.
We did remember that during the IETF DRINKS WG meetings, some folks
thought that we should not use DNS Resource Record as statically in
the data model.

Manjul suggested that per the use cases, we may also want to add = route
prioritization and source based routing.
Jean-Francois recommended that we drill down look at what this SED
Record could/should include in more detail terms.
# AI: = Manjul and Rich, by COB 6/12
# Come up with a couple of = examples of source-based routing and the
# notion of an SED Record: how = could it be addressed in the data model?
# -> candidate for use case = update?
perhaps give some examples.

Time was up for the 5/28 call. There were no calls the week of June
1st.

On the 6/9 call, we continued reviewing the data model with an = update
from Ken (provided file was a MS Visio diagram and a Word one,
available upon request to Ken, Debbie or Jean-Francois).
The updated data model provided more details on the lower part of = the
data model and had NS and NAPTR objects associated with Routing = Group.

Ken and Manjul proposed an updated draft data model based on what is
in the use case and requirements document.  A number of = elements
addressing requirements were left out to focus on the key objects = and
object grouping first.

A new object replaced the "Data Recipient" object = above.  It is now
called 'Organization' and it represents an entity that can play
various roles:
        - a session peer (data = recipient)
        - an entity that has = legal responsibility for some of the data
        - a registrar that = manages the data in the Registry on behalf
          of a = registrant
  
Changes requested based on team comments:
a) use public identifier instead of public identity; agreed
b) use RN instead of LRN, less US centric; agreed
c) carry the registrar and registrant ID on each object; agreed.
We had some discussion on this.  Ken explained the different = roles:
        - role 1: = "registrar"
            &= nbsp;   - an entity that manages the data in the registry = on
            &= nbsp;     behalf of one or more = registrant(s).
            &= nbsp;   - e.g. provision an object
            &= nbsp;   - entity that can insert/create/delete/view
        - role 2: = "registrant"
            &= nbsp;   - business entity that "owns" the data = from a business
            &= nbsp;     perspective...
            &= nbsp;   - an entity that has rights to manage data:
            &= nbsp;      e.g. carrier of record
=3D> we agreed to have a registrar and registrant ID for all objects = for
now; we need to explain more clearly why that is and whether this
imposes some limitations or to the contrary, allows simpler use = &
protocol implementations.
We also digressed and discussed how do we validate that an
organization A can provision data on behalf of B?  We had = consensus to
say that this is more of a business agreement that has to be = reflected
outside the data model (out of scope).

d) "only one entity can do the provisioning of the data"
A registrant may outsource part of the data provisioning to a
registrar and there might be multiple registrars that can administer
 different parts of the data for a given registrant.
That said, given an object instance, there was agreement that it is = ok
to limit the protocol so that only one entity has = create/update/delete
access to the object's value.
Jean-Francois proposed we clarify our vocabulary, what roles mean in
terms of access rights (CRUD or rwxd).

e) remove sourceIPs as attribute to any object
Jean-Francois commented that basing the source-based routing on the
source IP of the resolution or querying systems will not = fly.  Rich
and Ken indicated this is how it's implemented in some networks = today.
After some discussion, it was agreed that how one maps a resolution
request with the organization identity can vary (some may based this
mapping on lower-layer security mechanisms, some may do so by = linking
transport layer credentials to data model views, = etc.).    The idea is
that we likely don't care much in the protocol.
Rich used the example of the discussions in DNSop around = source-based
DNS resolution as another way to distinguish who asks the query.
Consensus:
    - remove sourceIPs
    - define a generic attribute called source_label = and state that
      additional security mechanisms can = be layered on top of that to
      determine the source of a query.

f) More general Route objects as opposed to NAPTR and NS Objects
Jean-Francois sent comments to generalize those objects.  Ken = added
that the proposal should be explored.

We discussed the two possible approaches:
        - one object called NS = and one NAPTR (static, DNS centric
          structures), = and may be other objects as well
        - single object e.g. = Route or Route Node that contains the
          attributes = of NS, NAPTR, URI that can be extended in the
          future, = something closer to a list of parameters that can be
          used to = construct those specific objects by the resolution
          engines

Ken added that it may simplify the data model to some extent but we
would need to define Route types.
We did a roundtable to understand where the consensus = was.  We
determined that we had no consensus on the 6/9 call and more
discussions are required with an example.
Manjul added that the result of a LUF is a URI, the key question is
where do we get the URI from in our data model and how to model it.

# AI: Ken = to update the data model and investigate proposal to = see
# what it would mean to remove NS = and NAPTR RRs.
# due date: COB = 6/12


4/ Timeline reminder for the = first proto I-D
We are still shooting for a first draft for = WG review and comments by
the cut-off date.

 
5/ Other = open items
During our discussions, some questions remain = open and we would
welcome input from the DRINKS WG:

 - provide some examples of SED data elements
   Basically, what needs to be represented as an object = attribute in
   the data model, somehow, somewhere so that querying = entities can
   make up the stuff they need to do (either complete LRF = resolution,
   or just initiate signaling)

 - organization or enterprise identifiers
   Explain the roles of enterprise ids in the data model = clearly and
   what rules are associated with those = roles.  Currently identified
   roles are: registrar, registrant.
 
 - do we need a means to push updates in the protocol?
   publish/subscribe model for some data?

 - review list of data elements proposed with an extension field = and
   argue whether it is really needed, potentially harmful or = actually
   good.

Next calls:

  = - Thursday June 11, 1pm MT, 3pm ET, and 9pm = CET.

  - = Monday June 15, 8am MT, 10am ET, 4pm CET.

  - = Wednesday = June 17, 1pm MT, 3pm ET, 9 pm CET (call with = Lisa)


Any comments on these notes should be sent to = drinks@ietf.org

> end.

------_=_NextPart_001_01C9EB6E.DA80951D-- From dguyton@telcordia.com Sun Jun 14 19:37:07 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E7F3A6900 for ; Sun, 14 Jun 2009 19:37:07 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vluh4f-PBFZo for ; Sun, 14 Jun 2009 19:37:03 -0700 (PDT) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by core3.amsl.com (Postfix) with ESMTP id A685A3A6823 for ; Sun, 14 Jun 2009 19:37:02 -0700 (PDT) Received: from rrc-dte-ieg01.dte.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1pya.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id n5F2bBlC028184 for ; Sun, 14 Jun 2009 22:37:12 -0400 (EDT) X-AuditID: 80601416-000010cc00000554-41-4a35b3d3661d Received: from rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) by rrc-dte-ieg01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Jun 2009 22:37:07 -0400 Received: from rrc-dte-exmb2.dte.telcordia.com ([128.96.180.27]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Sun, 14 Jun 2009 22:37:07 -0400 From: "Guyton, Deborah A" To: "drinks@ietf.org" Date: Sun, 14 Jun 2009 22:37:06 -0400 Thread-Topic: request for input Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AE85DAD2723E724EAB2A704148DE15AC27F782B920rrcdteexmb2dt_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [drinks] request for input X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 02:37:07 -0000 --_000_AE85DAD2723E724EAB2A704148DE15AC27F782B920rrcdteexmb2dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The protocol design team has been working on a data model and protocol for = the registry provisioning interface. We have associated with each public identifier routing information in the f= orm of resolution answers on the name server. Initially we looked at speci= fic types of routing info - such as NS and NAPTR Resource Records. We have = heard feedback that this is too DNS-centric. We are discussing collapsing t= hese into a "generic" Route Object. This may lead to a long set of attribut= es, one would be route type, but many others would be optional and may only= apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a ge= neric Route Object? Other suggestions are welcome. Thank you. Please reply to the list. --_000_AE85DAD2723E724EAB2A704148DE15AC27F782B920rrcdteexmb2dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The protocol design team has been working on a data mo= del and protocol for the registry provisioning interface.

We have associated with each public identifier routing information in the form of resolution answers on the name server.  Initially we looked at specific types of routing info – such as NS an= d NAPTR Resource Records. We have heard feedback that this is too DNS-centric= . We are discussing collapsing these into a “generic” Route Object. = This may lead to a long set of attributes, one would be route type, but many oth= ers would be optional and may only apply to a given route type.

We would appreciate some feedback –does it make = sense to collapse into a generic Route Object? Other suggestions are welcome.

 

Thank you. Please reply to the list.

 

 

--_000_AE85DAD2723E724EAB2A704148DE15AC27F782B920rrcdteexmb2dt_-- From dranalli@netnumber.com Mon Jun 15 06:04:55 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52AA73A68F3 for ; Mon, 15 Jun 2009 06:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2bvkOP-lidm for ; Mon, 15 Jun 2009 06:04:51 -0700 (PDT) Received: from agamemnon.swishmail.com (agamemnon.swishmail.com [64.39.51.26]) by core3.amsl.com (Postfix) with ESMTP id 009083A6C32 for ; Mon, 15 Jun 2009 06:04:50 -0700 (PDT) Received: (qmail 15588 invoked by uid 89); 15 Jun 2009 13:04:52 -0000 Received: by simscan 1.4.0 ppid: 15579, pid: 15584, t: 0.1255s scanners: attach: 1.4.0 clamav: 0.94.2/m:51/d:9467 Received: from unknown (HELO dranalli3) (75.150.73.57) by agamemnon.swishmail.com with SMTP; 15 Jun 2009 13:04:51 -0000 From: "Douglas Ranalli" To: "'Guyton, Deborah A'" , Date: Mon, 15 Jun 2009 09:02:37 -0400 Organization: NetNumber, Ind. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01C9ED98.07DD5F10" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: thread-index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAVMJ+Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Message-Id: <20090615130451.009083A6C32@core3.amsl.com> Subject: Re: [drinks] request for input X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dranalli@netnumber.com List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 13:04:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005C_01C9ED98.07DD5F10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Deborah, I support the approach of using a Route Object. DNS is not the only protocol that is used today to access interconnect routing information and DNS/ENUM may not survive as the long term query-response protocol for accessing interconnect routing data. The one thing we can be sure of is that new protocols will be developed by the IETF as we move forward as an industry. Doug _____ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A Sent: Sunday, June 14, 2009 10:37 PM To: drinks@ietf.org Subject: [drinks] request for input The protocol design team has been working on a data model and protocol for the registry provisioning interface. We have associated with each public identifier routing information in the form of resolution answers on the name server. Initially we looked at specific types of routing info - such as NS and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. We are discussing collapsing these into a "generic" Route Object. This may lead to a long set of attributes, one would be route type, but many others would be optional and may only apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a generic Route Object? Other suggestions are welcome. Thank you. Please reply to the list. ------=_NextPart_000_005C_01C9ED98.07DD5F10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Deborah,

 

I support the approach of using a = Route Object.  DNS is not the only protocol that is used today to access interconnect routing information and DNS/ENUM may not survive as the = long term query-response protocol for accessing interconnect routing data. =  The one thing we can be sure of is that new protocols will be developed by the = IETF as we move forward as an industry. =   

 

Doug

 

 

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A
Sent: Sunday, June 14, = 2009 10:37 PM
To: drinks@ietf.org
Subject: [drinks] request = for input

 

The protocol design team has been working on a data model and protocol for = the registry provisioning interface.

We have associated with each public identifier routing information in the = form of resolution answers on the name server.  Initially we looked at = specific types of routing info – such as NS and NAPTR Resource Records. We = have heard feedback that this is too DNS-centric. We are discussing = collapsing these into a “generic” Route Object. This may lead to a long set = of attributes, one would be route type, but many others would be optional = and may only apply to a given route type.

We would appreciate some feedback –does it make sense to collapse = into a generic Route Object? Other suggestions are = welcome.

 

Thank you. Please reply to the list.

 

 

------=_NextPart_000_005C_01C9ED98.07DD5F10-- From dschwartz@xconnect.net Mon Jun 15 06:22:01 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7533C3A6A28 for ; Mon, 15 Jun 2009 06:22:01 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj-uDe2g3B5N for ; Mon, 15 Jun 2009 06:21:57 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id CEA883A6934 for ; Mon, 15 Jun 2009 06:21:56 -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; Mon, 15 Jun 2009 16:21:55 +0300 From: David Schwartz To: "Guyton, Deborah A" , "drinks@ietf.org" Date: Mon, 15 Jun 2009 16:21:53 +0300 Thread-Topic: request for input Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAWNspA Message-ID: <6EA53FAD386F9D46B97D49BFE148D5147D5996@ISR-JLM-MAIL1.xconnect.co.il> 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_6EA53FAD386F9D46B97D49BFE148D5147D5996ISRJLMMAIL1xconne_" MIME-Version: 1.0 Subject: Re: [drinks] request for input X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 13:22:01 -0000 --_000_6EA53FAD386F9D46B97D49BFE148D5147D5996ISRJLMMAIL1xconne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Deborah In general I would caution against following the DNS model blindly, so to a= nswer your question I would say yes. On a more general note, is there a preliminary model I can view? Are you re= ferring to the ESPP one? If so, I have some comments relating to the data m= odel. Is this the forum for that or is it premature to raise my issues? David ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Guyton, Deborah A Sent: Monday, June 15, 2009 5:37 AM To: drinks@ietf.org Subject: [drinks] request for input The protocol design team has been working on a data model and protocol for = the registry provisioning interface. We have associated with each public identifier routing information in the f= orm of resolution answers on the name server. Initially we looked at speci= fic types of routing info - such as NS and NAPTR Resource Records. We have = heard feedback that this is too DNS-centric. We are discussing collapsing t= hese into a "generic" Route Object. This may lead to a long set of attribut= es, one would be route type, but many others would be optional and may only= apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a ge= neric Route Object? Other suggestions are welcome. Thank you. Please reply to the list. --_000_6EA53FAD386F9D46B97D49BFE148D5147D5996ISRJLMMAIL1xconne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Deborah

 

In general I would caution against fol= lowing the DNS model blindly, so to answer your question I would say yes.

 

On a more general note, is there a pre= liminary model I can view? Are you referring to the ESPP one? If so, I have some comments relating to the data model.

 

Is this the forum for that or is it premature to raise my issues?

 

David

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A
Sent: Monday, June 15, 2009 = 5:37 AM
To: drinks@ietf.org
Subject: [drinks] request fo= r input

 

The protocol design team has been working on a data model and protocol for the registry provisioning interface.

We have associated with each public identifier routing information in the form= of resolution answers on the name server.  Initially we looked at specifi= c types of routing info – such as NS and NAPTR Resource Records. We hav= e heard feedback that this is too DNS-centric. We are discussing collapsing t= hese into a “generic” Route Object. This may lead to a long set of attributes, one would be route type, but many others would be optional and = may only apply to a given route type.

We would appreciate some feedback –does it make sense to collapse into a generic Route Object? Other suggestions are welcome.

 

Thank you. Please reply to the list.

 

 

--_000_6EA53FAD386F9D46B97D49BFE148D5147D5996ISRJLMMAIL1xconne_-- From br@brianrosen.net Mon Jun 15 06:55:07 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A363A6CA7 for ; Mon, 15 Jun 2009 06:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eGTGeX0hS2J for ; Mon, 15 Jun 2009 06:55:03 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 7CC483A6CDE for ; Mon, 15 Jun 2009 06:55:03 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MGCdn-0000KH-1N; Mon, 15 Jun 2009 08:54:27 -0500 From: "Brian Rosen" To: "'Guyton, Deborah A'" , References: In-Reply-To: Date: Mon, 15 Jun 2009 09:54:30 -0400 Message-ID: <00cc01c9edc0$cfe33ed0$6fa9bc70$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CD_01C9ED9F.48D19ED0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAXxC+Q Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [drinks] request for input X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 13:55:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CD_01C9ED9F.48D19ED0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We haven't found anything we can't do with a NAPTR, with parameters. Could someone cite an example of what you can't do with a NAPTR? Brian From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A Sent: Sunday, June 14, 2009 10:37 PM To: drinks@ietf.org Subject: [drinks] request for input The protocol design team has been working on a data model and protocol for the registry provisioning interface. We have associated with each public identifier routing information in the form of resolution answers on the name server. Initially we looked at specific types of routing info - such as NS and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. We are discussing collapsing these into a "generic" Route Object. This may lead to a long set of attributes, one would be route type, but many others would be optional and may only apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a generic Route Object? Other suggestions are welcome. Thank you. Please reply to the list. ------=_NextPart_000_00CD_01C9ED9F.48D19ED0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We haven’t = found anything we can’t do with a NAPTR, with parameters.

 

Could someone cite an = example of what you  can’t do with a NAPTR?

 

Brian

 

From:= drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of = Guyton, Deborah A
Sent: Sunday, June 14, 2009 10:37 PM
To: drinks@ietf.org
Subject: [drinks] request for input

 

The protocol design team has been working on a data = model and protocol for the registry provisioning interface.

We have associated with each public identifier = routing information in the form of resolution answers on the name server.  Initially we looked at specific types of routing info – such as NS = and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. = We are discussing collapsing these into a “generic” Route Object. = This may lead to a long set of attributes, one would be route type, but many others would = be optional and may only apply to a given route type.

We would appreciate some feedback –does it = make sense to collapse into a generic Route Object? Other suggestions are = welcome.

 

Thank you. Please reply to the list.

 

 

------=_NextPart_000_00CD_01C9ED9F.48D19ED0-- From dschwartz@xconnect.net Mon Jun 15 07:01:37 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03AF3A6CE4 for ; Mon, 15 Jun 2009 07:01:37 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKxWuuR9EOZB for ; Mon, 15 Jun 2009 07:01:35 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id 70C063A6A16 for ; Mon, 15 Jun 2009 07:01:34 -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; Mon, 15 Jun 2009 17:01:24 +0300 From: David Schwartz To: Brian Rosen , "'Guyton, Deborah A'" , "drinks@ietf.org" Date: Mon, 15 Jun 2009 17:01:22 +0300 Thread-Topic: [drinks] request for input Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAXxC+QAAArKfA= Message-ID: <6EA53FAD386F9D46B97D49BFE148D5147D59AD@ISR-JLM-MAIL1.xconnect.co.il> References: <00cc01c9edc0$cfe33ed0$6fa9bc70$@net> In-Reply-To: <00cc01c9edc0$cfe33ed0$6fa9bc70$@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_6EA53FAD386F9D46B97D49BFE148D5147D59ADISRJLMMAIL1xconne_" MIME-Version: 1.0 Subject: Re: [drinks] request for input X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 14:01:38 -0000 --_000_6EA53FAD386F9D46B97D49BFE148D5147D59ADISRJLMMAIL1xconne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the question is "Can I put whatever information I want in a regex?" than= the answer is yes - a NAPTR can suffice. If the question is "Is a regex th= e most elegant way to store routing information other than target FQDN (e.g= . trunk group info, LRN info, etc.)" than the answer is no. There are other issues as well (am heading into a meeting so I will elabora= te later)... D. ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Brian Rosen Sent: Monday, June 15, 2009 4:55 PM To: 'Guyton, Deborah A'; drinks@ietf.org Subject: Re: [drinks] request for input We haven't found anything we can't do with a NAPTR, with parameters. Could someone cite an example of what you can't do with a NAPTR? Brian From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of= Guyton, Deborah A Sent: Sunday, June 14, 2009 10:37 PM To: drinks@ietf.org Subject: [drinks] request for input The protocol design team has been working on a data model and protocol for = the registry provisioning interface. We have associated with each public identifier routing information in the f= orm of resolution answers on the name server. Initially we looked at speci= fic types of routing info - such as NS and NAPTR Resource Records. We have = heard feedback that this is too DNS-centric. We are discussing collapsing t= hese into a "generic" Route Object. This may lead to a long set of attribut= es, one would be route type, but many others would be optional and may only= apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a ge= neric Route Object? Other suggestions are welcome. Thank you. Please reply to the list. --_000_6EA53FAD386F9D46B97D49BFE148D5147D59ADISRJLMMAIL1xconne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If the question is “Can I put wh= atever information I want in a regex?” than the answer is yes – a NAPT= R can suffice. If the question is “Is a regex the most elegant way to store routing inf= ormation other than target FQDN (e.g. trunk group info, LRN info, etc.)” than = the answer is no.

 

There are other issues as well (am hea= ding into a meeting so I will elaborate later)…

 

D.

 

From: drinks-b= ounces@ietf.org [mailto:drinks-bounces@ietf.org] On Beh= alf Of Brian Rosen
Sent: Monday, June 15, 2009 = 4:55 PM
To: 'Guyton, Deborah A'; drinks@ietf.org
Subject: Re: [drinks] reques= t for input

 

We haven’t found anything we= can’t do with a NAPTR, with parameters.

 

Could someone cite an example of w= hat you  can’t do with a NAPTR?

 

Brian

 

From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A
Sent: Sunday, June 14, 2009 = 10:37 PM
To: drinks@ietf.org
Subject: [drinks] request fo= r input

 

The protocol design team has been working on a data model and protocol for the registry provisioning interface.

We have associated with each public identifier routing information in the form= of resolution answers on the name server.  Initially we looked at specifi= c types of routing info – such as NS and NAPTR Resource Records. We hav= e heard feedback that this is too DNS-centric. We are discussing collapsing these i= nto a “generic” Route Object. This may lead to a long set of attrib= utes, one would be route type, but many others would be optional and may only apply to a gi= ven route type.

We would appreciate some feedback –does it make sense to collapse into a= generic Route Object? Other suggestions are welcome.

 

Thank you. Please reply to the list.

 

 

--_000_6EA53FAD386F9D46B97D49BFE148D5147D59ADISRJLMMAIL1xconne_-- From jf.mule@cablelabs.com Mon Jun 15 07:03:30 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC603A694C for ; Mon, 15 Jun 2009 07:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.162 X-Spam-Level: X-Spam-Status: No, score=-0.162 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7crqIoTKYuk for ; Mon, 15 Jun 2009 07:03:25 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 9D2D328C142 for ; Mon, 15 Jun 2009 07:03:25 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n5FE3UPP007554; Mon, 15 Jun 2009 08:03:30 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 15 Jun 2009 08:03:30 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EDC2.0FD0617A" Date: Mon, 15 Jun 2009 08:02:53 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601EED191@srvxchg3.cablelabs.com> In-Reply-To: <00cc01c9edc0$cfe33ed0$6fa9bc70$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] request for input Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAXxC+QAAAcpaA= References: <00cc01c9edc0$cfe33ed0$6fa9bc70$@net> From: "Jean-Francois Mule" To: "Brian Rosen" , "Guyton, Deborah A" , X-Approved: ondar Subject: Re: [drinks] request for input X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 14:03:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EDC2.0FD0617A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to echo Brian's comment, it is what some in the design team think. The NAPTR gives us quite a bit of flexibility to express what a response to a LUF or LUF+LRF resolution query could be. =20 When trying to build something more generic than a DNS RR like NAPTR, you basically end up doing the following: - Take NAPTR fields out of that structure and put them as attributes of a new object - Define ways to properly return URIs - Try and re-create the meaning of svces in NAPTR - Add something close to order and preference fields in NAPTR =20 Bottom line, given the implementations of NAPTRs in the space we're targeting, is there really something you can't do with a NAPTR? =20 Jean-Francois =20 From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, June 15, 2009 7:55 AM To: 'Guyton, Deborah A'; drinks@ietf.org Subject: Re: [drinks] request for input =20 We haven't found anything we can't do with a NAPTR, with parameters. =20 Could someone cite an example of what you can't do with a NAPTR? =20 Brian =20 From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A Sent: Sunday, June 14, 2009 10:37 PM To: drinks@ietf.org Subject: [drinks] request for input =20 The protocol design team has been working on a data model and protocol for the registry provisioning interface. We have associated with each public identifier routing information in the form of resolution answers on the name server. Initially we looked at specific types of routing info - such as NS and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. We are discussing collapsing these into a "generic" Route Object. This may lead to a long set of attributes, one would be route type, but many others would be optional and may only apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a generic Route Object? Other suggestions are welcome. =20 Thank you. Please reply to the list. =20 =20 ------_=_NextPart_001_01C9EDC2.0FD0617A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like to = echo Brian’s comment, it is what some in the design team think.  The NAPTR gives = us quite a bit of flexibility to express what a response to a LUF or LUF+LRF = resolution query could be.

 

When trying to build = something more generic than a DNS RR like NAPTR, you basically end up doing the following:

-          Take NAPTR = fields out of that structure and put them as attributes of a new = object

-          Define ways = to properly return URIs

-          Try and = re-create the meaning of svces in NAPTR

-          Add = something close to order and preference fields in NAPTR

 

Bottom line, given the implementations of NAPTRs in the space we’re = targeting, is there really something you can’t do with a = NAPTR?

 

Jean-Francois

 

From:= drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of = Brian Rosen
Sent: Monday, June 15, 2009 7:55 AM
To: 'Guyton, Deborah A'; drinks@ietf.org
Subject: Re: [drinks] request for input

 

We haven’t = found anything we can’t do with a NAPTR, with parameters.

 

Could someone cite an = example of what you  can’t do with a NAPTR?

 

Brian

 

From:= drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of = Guyton, Deborah A
Sent: Sunday, June 14, 2009 10:37 PM
To: drinks@ietf.org
Subject: [drinks] request for input

 

The protocol design team has been working on a data = model and protocol for the registry provisioning interface.

We have associated with each public identifier = routing information in the form of resolution answers on the name server.  Initially we looked at specific types of routing info – such as NS = and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. = We are discussing collapsing these into a “generic” Route Object. = This may lead to a long set of attributes, one would be route type, but many others would = be optional and may only apply to a given route type.

We would appreciate some feedback –does it = make sense to collapse into a generic Route Object? Other suggestions are = welcome.

 

Thank you. Please reply to the list.

 

 

------_=_NextPart_001_01C9EDC2.0FD0617A-- From ppfautz@att.com Mon Jun 15 07:20:17 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348893A68F3 for ; Mon, 15 Jun 2009 07:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZG2+81kS5Lt for ; Mon, 15 Jun 2009 07:20:13 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id A61F83A6AAA for ; Mon, 15 Jun 2009 07:20:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-9.tower-146.messagelabs.com!1245075617!16821982!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 16662 invoked from network); 15 Jun 2009 14:20:17 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jun 2009 14:20:17 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5FEKFLx031579 for ; Mon, 15 Jun 2009 10:20:16 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5FEKCvD031555 for ; Mon, 15 Jun 2009 10:20:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EDC4.64B4EFD5" Date: Mon, 15 Jun 2009 10:20:09 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B01AE4607@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] request for input Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAYdraw References: From: "PFAUTZ, PENN L, ATTCORP" To: "Guyton, Deborah A" , Subject: Re: [drinks] request for input X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 14:20:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EDC4.64B4EFD5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Debbie: While flexibility is a good thing and I think that the model should incorporate at least a variety of RR types, I'm not in favor of defining some new object with a bunch of attributes in the absence of seeing how that would actually work. I'm concerned that it will lead to more work on the backend. Are there specific proposals for how the generic route object would be set up?=20 =20 Penn Pfautz AT&T Access Management +1-732-420-4962 =20 ________________________________ From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A Sent: Sunday, June 14, 2009 10:37 PM To: drinks@ietf.org Subject: [drinks] request for input The protocol design team has been working on a data model and protocol for the registry provisioning interface. We have associated with each public identifier routing information in the form of resolution answers on the name server. Initially we looked at specific types of routing info - such as NS and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. We are discussing collapsing these into a "generic" Route Object. This may lead to a long set of attributes, one would be route type, but many others would be optional and may only apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a generic Route Object? Other suggestions are welcome. =20 Thank you. Please reply to the list. =20 =20 ------_=_NextPart_001_01C9EDC4.64B4EFD5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Debbie:
While flexibility is a good thing and I think = that the=20 model should incorporate at least a variety of RR types, I'm not in = favor of=20 defining some new object with a bunch of attributes in the absence of = seeing how=20 that would actually work. I'm concerned that it will lead to more work = on the=20 backend.
Are there specific proposals for how the = generic route=20 object would be set up? 
 
Penn Pfautz
AT&T Access = Management
+1-732-420-4962
 

From: drinks-bounces@ietf.org=20 [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah=20 A
Sent: Sunday, June 14, 2009 10:37 PM
To:=20 drinks@ietf.org
Subject: [drinks] request for=20 input

The protocol design team has been working on a data = model and=20 protocol for the registry provisioning interface.

We have associated with each public identifier = routing=20 information in the form of resolution answers on the name server. =20 Initially we looked at specific types of routing info – such as NS = and NAPTR=20 Resource Records. We have heard feedback that this is too DNS-centric. = We are=20 discussing collapsing these into a “generic” Route Object. = This may lead to a=20 long set of attributes, one would be route type, but many others would = be=20 optional and may only apply to a given route type.

We would appreciate some feedback –does it = make sense to=20 collapse into a generic Route Object? Other suggestions are=20 welcome.

 

Thank you. Please reply to the list.

 

 

------_=_NextPart_001_01C9EDC4.64B4EFD5-- From richard@shockey.us Mon Jun 15 07:40:09 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135283A6CCC for ; Mon, 15 Jun 2009 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV9cbxJ5Arr3 for ; Mon, 15 Jun 2009 07:40:04 -0700 (PDT) Received: from outbound-mail-31.bluehost.com (outbound-mail-31.bluehost.com [69.89.18.151]) by core3.amsl.com (Postfix) with SMTP id A37233A6B6E for ; Mon, 15 Jun 2009 07:40:04 -0700 (PDT) Received: (qmail 10727 invoked by uid 0); 15 Jun 2009 14:25:48 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 15 Jun 2009 14:25:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:thread-index:Content-Language:X-Identified-User; b=NI3YLU/aLwHzaSth9pIe42zj0vE5CuQBZEoCPCnfZQNQX4pdTqku/3uEYmZeksBNMLpzprDDmFhlrM5mK2fhbCs5O9uT9XdDylr7yO2eM3rHOnsG+8WJ2YkCkFaC8mqq; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MGD88-0000EJ-0B; Mon, 15 Jun 2009 08:25:48 -0600 From: "Richard Shockey" To: "'Brian Rosen'" , "'Guyton, Deborah A'" , References: <00cc01c9edc0$cfe33ed0$6fa9bc70$@net> In-Reply-To: <00cc01c9edc0$cfe33ed0$6fa9bc70$@net> Date: Mon, 15 Jun 2009 10:25:38 -0400 Message-ID: <00bb01c9edc5$287b01a0$797104e0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BC_01C9EDA3.A16961A0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAXxC+QAAD6EtA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: Re: [drinks] request for input X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 14:40:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00BC_01C9EDA3.A16961A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Trunkgroup? The LRF whatever that really is.. A sore point for me BTW. Part of this is an attempt to make sure the data provisioned is agnostic to the protocol used to retrieve it . Its not supported to be either ENUM or SIP redirect centric. From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Monday, June 15, 2009 9:55 AM To: 'Guyton, Deborah A'; drinks@ietf.org Subject: Re: [drinks] request for input We haven't found anything we can't do with a NAPTR, with parameters. Could someone cite an example of what you can't do with a NAPTR? Brian From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah A Sent: Sunday, June 14, 2009 10:37 PM To: drinks@ietf.org Subject: [drinks] request for input The protocol design team has been working on a data model and protocol for the registry provisioning interface. We have associated with each public identifier routing information in the form of resolution answers on the name server. Initially we looked at specific types of routing info - such as NS and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. We are discussing collapsing these into a "generic" Route Object. This may lead to a long set of attributes, one would be route type, but many others would be optional and may only apply to a given route type. We would appreciate some feedback -does it make sense to collapse into a generic Route Object? Other suggestions are welcome. Thank you. Please reply to the list. ------=_NextPart_000_00BC_01C9EDA3.A16961A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Trunkgroup?  The = LRF whatever that really is..

 

A sore point for me = BTW. 

 

Part of this is an = attempt to make sure the data provisioned is agnostic to the protocol used to = retrieve it . Its not supported to be either ENUM or SIP redirect = centric.

 

From:= drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of = Brian Rosen
Sent: Monday, June 15, 2009 9:55 AM
To: 'Guyton, Deborah A'; drinks@ietf.org
Subject: Re: [drinks] request for input

 

We haven’t = found anything we can’t do with a NAPTR, with parameters.

 

Could someone cite an = example of what you  can’t do with a NAPTR?

 

Brian

 

From:= = drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf Of Guyton, Deborah = A
Sent: Sunday, June 14, 2009 10:37 PM
To: drinks@ietf.org
Subject: [drinks] request for input

 

The protocol design team has been working on a data = model and protocol for the registry provisioning interface.

We have associated with each public identifier = routing information in the form of resolution answers on the name server.  Initially we looked at specific types of routing info – such as NS = and NAPTR Resource Records. We have heard feedback that this is too DNS-centric. = We are discussing collapsing these into a “generic” Route Object. = This may lead to a long set of attributes, one would be route type, but many others would = be optional and may only apply to a given route type.

We would appreciate some feedback –does it = make sense to collapse into a generic Route Object? Other suggestions are = welcome.

 

Thank you. Please reply to the list.

 

 

------=_NextPart_000_00BC_01C9EDA3.A16961A0-- From br@brianrosen.net Mon Jun 15 10:03:37 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368243A67B4 for ; Mon, 15 Jun 2009 10:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LUTSiOcbaHY for ; Mon, 15 Jun 2009 10:03:36 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 667A23A6784 for ; Mon, 15 Jun 2009 10:03:36 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MGDS1-0005DX-QI; Mon, 15 Jun 2009 09:46:22 -0500 From: "Brian Rosen" To: "'Richard Shockey'" , "'Guyton, Deborah A'" , References: <00cc01c9edc0$cfe33ed0$6fa9bc70$@net> <00bb01c9edc5$287b01a0$797104e0$@us> In-Reply-To: <00bb01c9edc5$287b01a0$797104e0$@us> Date: Mon, 15 Jun 2009 10:46:25 -0400 Message-ID: <002101c9edc8$110ebb30$332c3190$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAXxC+QAAD6EtAAAMDqgA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [drinks] request for input X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 17:03:37 -0000 I=92d rather this work not get ahead of other protocol work. If there is some protocol effort for routing of =93phone-like=94 = services, and it doesn=92t use NAPTRs, and it has information that NAPTRs don=92t = handle, then let=92s talk about it. I=92m not aware of such, and consequently, I'd like to keep the scope to = what we have, or can reasonably forecast. Brian From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Monday, June 15, 2009 10:26 AM To: 'Brian Rosen'; 'Guyton, Deborah A'; drinks@ietf.org Subject: RE: [drinks] request for input Trunkgroup?=A0 The LRF whatever that really is.. A sore point for me BTW.=A0=20 Part of this is an attempt to make sure the data provisioned is agnostic = to the protocol used to retrieve it . Its not supported to be either ENUM = or SIP redirect centric. From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf = Of Brian Rosen Sent: Monday, June 15, 2009 9:55 AM To: 'Guyton, Deborah A'; drinks@ietf.org Subject: Re: [drinks] request for input We haven=92t found anything we can=92t do with a NAPTR, with parameters. Could someone cite an example of what you=A0 can=92t do with a NAPTR? Brian From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On Behalf = Of Guyton, Deborah A Sent: Sunday, June 14, 2009 10:37 PM To: drinks@ietf.org Subject: [drinks] request for input The protocol design team has been working on a data model and protocol = for the registry provisioning interface. We have associated with each public identifier routing information in = the form of resolution answers on the name server.=A0 Initially we looked at specific types of routing info =96 such as NS and NAPTR Resource = Records. We have heard feedback that this is too DNS-centric. We are discussing collapsing these into a =93generic=94 Route Object. This may lead to a = long set of attributes, one would be route type, but many others would be = optional and may only apply to a given route type. We would appreciate some feedback =96does it make sense to collapse into = a generic Route Object? Other suggestions are welcome. Thank you. Please reply to the list. From jf.mule@cablelabs.com Wed Jun 17 09:14:49 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0D513A6BA8 for ; Wed, 17 Jun 2009 09:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.17 X-Spam-Level: X-Spam-Status: No, score=-0.17 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brfwEkJrfokd for ; Wed, 17 Jun 2009 09:14:48 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id D3F5D3A6B82 for ; Wed, 17 Jun 2009 09:14:48 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n5HGF0ti017424; Wed, 17 Jun 2009 10:15:00 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Wed, 17 Jun 2009 10:15:00 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 10:14:35 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601EED2E4@srvxchg3.cablelabs.com> In-Reply-To: <6EA53FAD386F9D46B97D49BFE148D5147D5996@ISR-JLM-MAIL1.xconnect.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [drinks] request for input Thread-Index: AcntYaBKrPg8YX/uQ7CwkIs1e5DjAQAWNspAAGrSU+A= References: <6EA53FAD386F9D46B97D49BFE148D5147D5996@ISR-JLM-MAIL1.xconnect.co.il> From: "Jean-Francois Mule" To: "David Schwartz" X-Approved: ondar Cc: drinks@ietf.org Subject: Re: [drinks] request for input X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 16:14:49 -0000 Hi David, You asked: > On a more general note, is there a preliminary model I can view? > Are you referring to the ESPP one? If so, I have some comments > relating to the data model. Just sent you what the design team has come up with. If you can post it = onto a wiki somewhere and give a link for all folks here, even better. Jean-Fran=E7ois > -----Original Message----- > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of David Schwartz > Sent: Monday, June 15, 2009 7:22 AM > To: Guyton, Deborah A; drinks@ietf.org > Subject: Re: [drinks] request for input >=20 > Hi Deborah >=20 > In general I would caution against following the DNS model blindly, > so to answer your question I would say yes. >=20 > On a more general note, is there a preliminary model I can view? > Are you referring to the ESPP one? If so, I have some comments > relating to the data model. >=20 > Is this the forum for that or is it premature to raise my issues? >=20 > David > ________________________________________ > From: drinks-bounces@ietf.org [mailto:drinks-bounces@ietf.org] On > Behalf Of Guyton, Deborah A > Sent: Monday, June 15, 2009 5:37 AM > To: drinks@ietf.org > Subject: [drinks] request for input >=20 > The protocol design team has been working on a data model and > protocol for the registry provisioning interface. > We have associated with each public identifier routing information > in the form of resolution answers on the name server.=A0 Initially we > looked at specific types of routing info - such as NS and NAPTR > Resource Records. We have heard feedback that this is too DNS- > centric. We are discussing collapsing these into a "generic" Route > Object. This may lead to a long set of attributes, one would be > route type, but many others would be optional and may only apply to > a given route type. > We would appreciate some feedback -does it make sense to collapse > into a generic Route Object? Other suggestions are welcome. >=20 > Thank you. Please reply to the list. >=20 From jf.mule@cablelabs.com Thu Jun 18 02:37:48 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF9D3A698D for ; Thu, 18 Jun 2009 02:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=0.256, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nGprwI0bvNc for ; Thu, 18 Jun 2009 02:37:46 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 5EDCC3A6813 for ; Thu, 18 Jun 2009 02:37:46 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n5I9bwjh001290 for ; Thu, 18 Jun 2009 03:37:58 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 18 Jun 2009 03:37:58 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EFF8.76C5C81D" Date: Thu, 18 Jun 2009 03:37:32 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601EED350@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes from June 11 & June 15 protocol design team calls Thread-Index: Acnv+GeuEMjAZNVGQESo0a4Pts8K0A== From: "Jean-Francois Mule" To: X-Approved: ondar Subject: [drinks] Minutes from June 11 & June 15 protocol design team calls X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 09:37:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EFF8.76C5C81D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ---=20 --- IETF DRINKS WG, protocol design team minutes --- Summary of June 11 and 15, 2009 Calls --- 6/11 Attendees Debbie Guyton Manjul Maharishi Ken Cartwright Spencer Dawkins Jean-Francois Mule --- 6/15 Attendees Debbie Guyton Manjul Maharishi Jean-Francois Mule --- Combined Agendas 1/ Review Action Item List=20 2/ Review Data model 3/ Drafting text=20 4/ Topics for our call with Lisa 5/ Other open items --- Notes Minutes reported by Jean-Francois.=20 Any comments on these notes should be sent to drinks@ietf.org=20 =20 The meeting notes from the last call were reviewed and there were no comments or questions. 1/ Updated Action Item List [Jean-Francois] We reviewed the action item list on the 5/28 and 6/9 calls. Below are the open and closed action items. Action Item (AI): Jean-Francois, closed 6/8 Jean-Francois did ping Lisa to get her on a call with this group, copied wg chairs. Call was scheduled for 6/17 and a follow-up is planned for Wed July 1st, 12noon PT, 3pm ET. # AI: Sumanth, open (on-going) # On a regular basis by sending mails to IETF drinks list with deltas # and proposed changes. Keep the use case and requirement documents in # sync in case use cases need to be improved. =20 AI: Ken and Manjul done, last update on 6/15 Ken and Manjul to send a updated proposal for doc outline based on the design team feedback (see notes below). # AI: Jean-Francois, open, due by COB 6/19 # Send input based on previous IETF DRINKS discussions related to # protocol transport requirements # AI: All, open, due by COB 6/19 # Review list of protocol data elements provided by Debbie on 5/28 for # consideration, send comments -> some are incorporated in the data model, not all.=20 We need to have a discussion on the call for the others, may be in the draft-01 revision timeframe given the timeline for draft-00. # AI: Manjul and Rich, by COB 6/19 # Come up with a couple of examples of source-based routing and the # notion of an SED Record: how could it be addressed in the data model? # -> candidate for use case update? #AI: Debbie, Manjul, JFM to provide first ID draft text by COB 6/22 #AI: JFM to send current IETF I-D XML template with populated outline # by COB 6/18 2/ Review of the Draft Data model=20 We spent most of the time on our last 2 calls to discuss and update the data model. We reviewed SPPPDataModel_02.doc and SPPPDataModel_03.doc sent by Ken and have now the revision _04 that is pretty close to what we think we will put in draft-00 for wg discussion and reviews. 2.1/ Changes from 6/11 call include: + composite or business keys for all objects In the previous versions, all the objects used to have synthetic keys generated by the system (object identifiers). We had a good discussion on why under some circumstances, it is best to use business keys rather than synthetic keys, and the reverse. We need to have unique keys for all objects but if we use synthetic keys, each time the client needs to generate an object, the server would have to send the key it generated for the object back to the client. This is suited for some modeling but the consensus is that we could likely do without it. =3D> Ken summed it up:=20 it makes the interface more intricate since the client needs to be told the key for the object it created. One exception might be a NAPTR as it is difficult to have a composite key. We discussed the reasons for moving to a composite key and the potential benefits of having both: - allow clients to use business keys to query - allow apps to use synthetic keys for some operations For now, we decided to keep the composite keys only, and Ken or Manjul will start a thread on the DRINKS list. # Manjul, get wg feedback on the type of object keys to use by COB by # 6/19 + availabilityWindow vs. activationDate Do we need this availabilityWindow day one? This is for a client to indicate when some data is available (data can be active but not available during some time of the day for e.g.). Consensus: no Unless someone needs this in the wg, we want to remove it from the first protocol, it could be an extension added later. If we get folks that need it, we can add it in a later draft. Speak on the drinks list. + Consolidation of so called "Resolution Lookup Keys" The resolution look-up keys (for a lack of a better term) are the things like a URI, TN, RN, input data that systems would use to get a LUF/LRF response for. We agreed to have only two for now: + a public identifier (URI), which includes TN and an attribute to say if it is a special PSTN RN identifier; + TNRange =20 + Combine NS and NAPTR Debbie to send a note to the DRINKS wg list AI: Debbie to poll the group on this on 6/14 - done, got some feedback and expecting more. AI: Ken and Manjul sent updated models based on our discussions; last update on 6/15. 2.2/ Changes from 6/15 call We reviewed the changes and discussed what constitutes a unique key for an object. The goal is to freeze the data model by end of June 19 to start writing the first Internet-Draft for wg review. Changes: - add registrantOrgName as a key to Public Identifier and TNRange objects 3/ Drafting text=20 We discussed the plan on 6/11 and allocated sections to folks on the 6/15 call. - Drafting text by 6/19 #AI: Jean-Francois will send an XML template to folks by COB 6/17 1 Introduction=20 JFM 2 Transport Requirements=20 Manjul 3 XML Considerations=20 Debbie 4 Request and Reply Model=20 Manjul and JFM 5 Protocol Commands=20 Manjul and JFM to do an example then divide 6 Security Considerations=20 TBD 7 IANA Considerations=20 8 Authors and Acknowledgements=20 9 References=20 10 Formal Specification - XSD=20 11 Specification Extensibility=20 4/ Topics for security discussion with Lisa The idea of the call is to discuss the assumptions on the protocol=20 (use of SOAP, security model, ...) and get guidances on how to get started on the right foot. We discussed that we should give an intro about what we're doing. We described the actors: - multiple clients to a Registry - associations between clients and servers are small in number (hundreds of registrants per registry,=20 a smaller number of registrars, low hundreds, may be half of the size of the number of registrants) - client may change one data element or create thousands of new ones =20 Protocol exchanges may be machine-to-machine (automated) or human-to-machine (via web browser). We should discuss our preference for using SOAP. Manjul and Debbie will discuss real-life examples from TNSI and Telcordia on how security is handled for similar protocol exchanges. - how do we build the security in the protocol? - what are the security properties we need? Should be able to authenticate a client as a valid one for access of a given registry (mutual auth)? Ownership of data elements? What entities can have read/write access and how is that managed?=20 What features do we need to address Registrar/Registrant roles and associated access? How do we manage requirements about audit trails?=20 Any considerations about that or is this just a DB BCP? Above are random questions we thought were important to figure out (not sure they all apply to this upcoming call with Lisa). One last question: we should ask Lisa for any recommendations and pointers on XML considerations (namespace, versioning) in IETF protocols. 5/ Other open items During our discussions, some questions remain open and we would welcome input from the DRINKS WG: - provide some examples of SED data elements Basically, what needs to be represented as an object attribute in the data model, somehow, somewhere so that querying entities can make up the stuff they need to do (either complete LRF resolution, or just initiate signaling) - organization or enterprise identifiers Explain the roles of enterprise ids in the data model clearly and what rules are associated with those roles. Currently identified roles are: registrar, registrant. =20 - do we need a means to push updates in the protocol? publish/subscribe model for some data? - review list of data elements proposed with an extension field and argue whether it is really needed, potentially harmful or actually good. - do we need an availabilityWindow? for now, consensus is no, but we park it in here. Next calls are - Wed June 17, 1pm MT, 3pm ET, and 9pm CET (call with Lisa), then - Thursday June 18, same time. Any comments on these notes should be sent to drinks@ietf.org > end. ------_=_NextPart_001_01C9EFF8.76C5C81D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

---
--- IETF DRINKS WG, protocol design = team minutes
--- Summary of June 11 and 15, 2009 = Calls


--- 6/11 Attendees
Debbie Guyton
Manjul Maharishi
Ken Cartwright
Spencer Dawkins
Jean-Francois Mule

--- 6/15 Attendees
Debbie Guyton
Manjul Maharishi
Jean-Francois Mule


--- Combined Agendas
1/ Review Action Item List =
2/ Review Data model
3/ Drafting text
4/ Topics for our call with = Lisa
5/ Other open items


--- Notes
Minutes reported by Jean-Francois.
Any comments on these notes should be sent to drinks@ietf.org
 
The meeting notes from the last call were reviewed and there were no
comments or questions.


1/ Updated Action Item List = [Jean-Francois]
We reviewed the action item list on the 5/28 and 6/9 = calls.  Below are
the open and closed action items.

Action Item (AI): Jean-Francois, closed 6/8
Jean-Francois did ping Lisa to get her on a call with this group,
copied wg chairs.  Call was scheduled for 6/17 and a follow-up = is
planned for Wed July 1st, 12noon PT, 3pm ET.

# AI:  Sumanth, open = (on-going)
# On a regular basis by sending mails = to IETF drinks list with deltas
# and proposed changes. Keep the use = case and requirement documents in
# sync in case use cases need to be = improved.
 
AI: Ken and Manjul done, last update on 6/15
Ken and Manjul to send a updated proposal for doc outline based on = the
design team feedback (see notes below).

# AI: Jean-Francois, open, due by COB = 6/19
# Send input based on previous IETF = DRINKS discussions related to
# protocol transport = requirements

# AI: All, open, due by COB = 6/19
# Review list of protocol data elements = provided by Debbie on 5/28 for
# consideration, send = comments
-> some are incorporated in the data = model, not all.
We need to have a discussion on the call for the others, may be in = the
draft-01 revision timeframe given the timeline for draft-00.

# AI: Manjul and Rich, by COB = 6/19
# Come up with a couple of examples of source-based routing and the
# notion of an SED Record: how could it = be addressed in the data model?
# -> candidate for use case = update?

#AI: Debbie, Manjul, JFM to provide = first ID draft text by COB 6/22

#AI: JFM to send current IETF I-D XML = template with populated outline
# by COB 6/18


2/ Review of the Draft Data model =

We spent most of the time on our last 2 calls to discuss and update
the data model.
We reviewed SPPPDataModel_02.doc and SPPPDataModel_03.doc sent by = Ken
and have now the revision _04 that is pretty close to what we think = we
will put in draft-00 for wg discussion and reviews.

2.1/ Changes from 6/11 call = include:
+  composite or business keys = for all objects
In the previous versions, all the objects used to have synthetic = keys
generated by the system (object identifiers).  We had a = good
discussion on why under some circumstances, it is best to use = business
keys rather than synthetic keys, and the reverse.

We need to have unique keys for all objects but if we use synthetic
keys, each time the client needs to generate an object, the server
would have to send the key it generated for the object back to the
client.  This is suited for some modeling but the consensus is = that we
could likely do without it.
        =3D> Ken summed it = up:
it makes the interface more intricate since the client needs to be
told the key for the object it created.

One exception might be a NAPTR as it is difficult to have a = composite
key.

We discussed the reasons for moving to a composite key and the
potential benefits of having both:
 - allow clients to use business keys to query
 - allow apps to use synthetic keys for some operations

For now, we decided to keep the composite keys only, and Ken or = Manjul
will start a thread on the DRINKS list.
# Manjul, get wg feedback on the type = of object keys to use by COB by
# 6/19


+ availabilityWindow vs. = activationDate
Do we need this availabilityWindow day one?  This is for a = client to
indicate when some data is available (data can be active but not
available during some time of the day for e.g.).
Consensus: no
Unless someone needs this in the wg, we want to remove it from the
first protocol, it could be an extension added later.  If we = get folks
that need it, we can add it in a later draft.  Speak on the = drinks
list.

+ Consolidation of so called = "Resolution Lookup Keys"
The resolution look-up keys (for a lack of a better term) are the
things like a URI, TN, RN, input data that systems would use to get = a
LUF/LRF response for.

We agreed to have only two for now:
  + a public identifier (URI), which includes TN and an = attribute to
say if it is a special PSTN RN identifier;
  + TNRange
 
+ Combine NS and NAPTR
Debbie to send a note to the DRINKS wg list
AI: Debbie to poll the group on this on 6/14 - done, got some
feedback and expecting more.

AI: Ken and Manjul sent updated models based on our discussions; = last
update on 6/15.

2.2/ Changes from 6/15 = call
We reviewed the changes and discussed what constitutes a unique key
for an object.
The goal is to freeze the data model by end of June 19 to start
writing the first Internet-Draft for wg review.

Changes:
 - add registrantOrgName as a key to Public Identifier and = TNRange
   objects



3/ Drafting text
We discussed the plan on 6/11 and allocated sections to folks on the
 6/15 call.

- Drafting text by 6/19
#AI: Jean-Francois will send an XML = template to folks by COB 6/17
       1 Introduction
          JFM
       2 Transport Requirements
          Manjul
       3 XML Considerations
          Debbie
       4 Request and Reply Model
          Manjul and = JFM
       5 Protocol Commands
          Manjul and = JFM to do an example
          then = divide
       6 Security Considerations
         TBD
       7 IANA Considerations
       8 Authors and Acknowledgements
       9 References
       10 Formal Specification - XSD
       11 Specification Extensibility


4/ Topics for security discussion with = Lisa
The idea of the call is to discuss the assumptions on the protocol
(use of SOAP, security model, ...) and get guidances on how to get
started on the right foot.

We discussed that we should give an intro about what we're = doing.  We
described the actors:
        - multiple clients to a Registry
        - associations between = clients and servers are small in number
          (hundreds of registrants per registry,
           a smaller = number of registrars, low hundreds, may be half
           of the size = of the number of registrants)
        - client may change one = data element or create thousands of
          new ones
  
Protocol exchanges may be machine-to-machine (automated) or
human-to-machine (via web browser).

We should discuss our preference for using SOAP.

Manjul and Debbie will discuss real-life examples from TNSI and
Telcordia on how security is handled for similar protocol exchanges.
  - how do we build the security in the protocol?
  - what are the security properties we need?
        Should be able to = authenticate a client as a valid one for
        access of a given = registry (mutual auth)?

        Ownership of data = elements?
        What entities can have = read/write access and how is that
        managed?
        What features do we need = to address Registrar/Registrant
        roles and associated = access?
        How do we manage = requirements about audit trails?
        Any considerations about = that or is this just a DB BCP?
Above are random questions we thought were important to figure out
(not sure they all apply to this upcoming call with Lisa).

One last question: we should ask Lisa for any recommendations and
pointers on XML considerations (namespace, versioning) in IETF
protocols.


5/ Other open items
During our discussions, some questions remain open and we would
welcome input from the DRINKS WG:

 - provide some examples of SED data elements
   Basically, what needs to be represented as an object = attribute in
   the data model, somehow, somewhere so that querying = entities can
   make up the stuff they need to do (either complete LRF = resolution,
   or just initiate signaling)

 - organization or enterprise identifiers
   Explain the roles of enterprise ids in the data model = clearly and
   what rules are associated with those = roles.  Currently identified
   roles are: registrar, registrant.
 
 - do we need a means to push updates in the protocol?
   publish/subscribe model for some data?

 - review list of data elements proposed with an extension field = and
   argue whether it is really needed, potentially harmful or = actually
   good.

  - do we need an availabilityWindow?
    for now, consensus is no, but we park it in = here.


Next calls are
        - Wed June 17, 1pm MT, = 3pm ET, and 9pm CET
         (call with Lisa), = then
        - Thursday June 18, same = time.

Any comments on these notes should be sent to drinks@ietf.org




> end.

------_=_NextPart_001_01C9EFF8.76C5C81D-- From richard@shockey.us Mon Jun 22 07:33:04 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2900928C205 for ; Mon, 22 Jun 2009 07:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNtV1LmnZAcU for ; Mon, 22 Jun 2009 07:33:03 -0700 (PDT) Received: from outbound-mail-129.bluehost.com (outbound-mail-129.bluehost.com [67.222.38.29]) by core3.amsl.com (Postfix) with SMTP id 41BBE28C1F4 for ; Mon, 22 Jun 2009 07:33:03 -0700 (PDT) Received: (qmail 3390 invoked by uid 0); 22 Jun 2009 14:33:18 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy4.bluehost.com with SMTP; 22 Jun 2009 14:33:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-language:X-Identified-User; b=Gb0mGcGHYNHzROgGLdHiM8Fe+jc/fFa9+sDYoM9b7Sk4u9EPeO1CG9IOIKGGtBJ4PbpM7w13jQPAc+z8B6sKH+BhiyooccVrVglTOzMP6ed8v8DhWpnLPWEfUlIGpFlp; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MIkaE-0003GJ-E6 for drinks@ietf.org; Mon, 22 Jun 2009 08:33:18 -0600 From: "Richard Shockey" To: Date: Mon, 22 Jun 2009 10:33:08 -0400 Message-ID: <008c01c9f346$5d4086e0$17c194a0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnxVgYvr0Y+x8xcQ1i4Ef97iN2i3QB8Eing Content-language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [drinks] FW: 75th IETF - DRAFT Agenda X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 14:33:04 -0000 It looks like Monday afternoon right now. -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On = Behalf Of IETF Secretariat Sent: Friday, June 19, 2009 11:20 PM To: IETF Announcement list Cc: irsg@isi.edu; wgchairs@ietf.org; bofchairs@ietf.org Subject: 75th IETF - DRAFT Agenda=20 The Draft agenda is now available at: http://www.ietf.org/meetings/75/ Online registration for the IETF meeting is at: http://www.ietf.org/meetings/75/ Only 37 days until the Stockholm IETF!=20 From alexander.mayrhofer@nic.at Fri Jun 26 06:29:30 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07F7B3A6B25 for ; Fri, 26 Jun 2009 06:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.337 X-Spam-Level: X-Spam-Status: No, score=-9.337 tagged_above=-999 required=5 tests=[AWL=0.093, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBLrx05RJmCz for ; Fri, 26 Jun 2009 06:29:28 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 1706028C0E5 for ; Fri, 26 Jun 2009 06:29:09 -0700 (PDT) Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.44 ; Fri, 26 Jun 2009 15:29:23 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 26 Jun 2009 15:29:24 +0200 Message-ID: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG poll on transport protocol Thread-Index: Acn2Yh8jnu04p0/PR3Wwi5SjbfhmhQ== From: "Alexander Mayrhofer" To: "IETF DRINKS WG" X-XWALL-BCKS: auto Subject: [drinks] WG poll on transport protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 13:29:30 -0000 All, The chairs would like to seek some input from the list on the practical options the WG now needs to confront on what is the most appropriate, but more importantly, what is also most deployable transport protocol for DRINKS. The protocol design team has made good progress towards a first draft=20 of the DRINKS protocol, and the issue of which transport protocol to proceed with was discussed during several conference calls. The chairs wish to formally reach concensus on how the group should proceed regarding that protocol transport issue. Discussions during our face to face meetings have indicated that a SOAP/XML based approach would fit most of the various vendors and service providers that would potentially deploy a DRINKS protocol.=20 http://en.wikipedia.org/wiki/SOAP The design team been advised that it might also be useful to look at REST-like protocols as REST design principles for WEB protocols overcome many of the known limitations and interoperability problems associated with SOAP. There are arguments that a RESTful Web Services approach for a DRINKS protocol from a provisioning would not only be appropriate for a Client 2 Server but also Server 2 Server approaches as well.=20 It should be understood that REST is not a protocol but a series of design principals.=20 http://en.wikipedia.org/wiki/REST The central counter argument is that SOAP is the most universally deployed data exchange mechanism out there and that anecdotal evidence indicates that SOAP is the predominant form of transport mechanism in current use among SSP's and will be for the foreseeable future. The design team has currently concluded that it would be beneficial to seperate the definition of the data object from the underlying=20 transport protocol to permit defining more than one transport, if=20 necessary. In order to document WG consensus on this issue the chairs would like to poll the WG on the following questions: It is very important that as many members of the list participate in this poll as possible. Please provide feedback to each question as fully as possible. General questions regarding deployed transport protocols: 1. How many folks have SOAP implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out?=20 2. How many folks have a REST-like implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out? 3. In general what data model or protocol properties do your organizations ultimately lean towards - SOAP vs. REST? Other? 4. What are the specific applications that SSP are looking for DRINKS to enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ?? =20 Questions to reach WG concensus on: 3. Do you agree that the design team should define the architecture /=20 data model independently from the definition of a potential=20 transport protocol? (as far as possible) 4. Given the goal to define the data model outside its transport, do you prefer the group to=20 A. Define a SOAP based transport protocol and if anyone is interested they can work on a RESTful version?=20 B. The WG try and do both?=20 =20 Please provide feedback before July 8th, if possible. Thanks, Richard & Alex From andy@hxr.us Fri Jun 26 13:40:59 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3073A6C46 for ; Fri, 26 Jun 2009 13:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+fW8COmydsl for ; Fri, 26 Jun 2009 13:40:58 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 5DE6A3A6C25 for ; Fri, 26 Jun 2009 13:40:58 -0700 (PDT) Received: from zx80.home.hxr.us ([::ffff:70.179.98.221]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 26 Jun 2009 16:40:45 -0400 id 015842D4.4A45324D.00004ED2 Message-Id: <57C00EDA-5394-4E6E-A286-D32AF5F861FF@hxr.us> From: Andrew Newton To: "Alexander Mayrhofer" In-Reply-To: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 26 Jun 2009 16:40:44 -0400 References: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> X-Mailer: Apple Mail (2.935.3) Cc: IETF DRINKS WG Subject: Re: [drinks] WG poll on transport protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 20:40:59 -0000 On Jun 26, 2009, at 9:29 AM, Alexander Mayrhofer wrote: > The central counter argument is that SOAP is the most universally > deployed > data exchange mechanism out there and that anecdotal evidence > indicates > that > SOAP is the predominant form of transport mechanism in current use > among > SSP's and will be for the foreseeable future. Not that I have a dog in this fight, but I seriously doubt that first part is true. -andy From theo@crazygreek.co.uk Fri Jun 26 14:21:49 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EA63A6C56 for ; Fri, 26 Jun 2009 14:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+8LpVX6uYhy for ; Fri, 26 Jun 2009 14:21:48 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with SMTP id 10C663A6BB3 for ; Fri, 26 Jun 2009 14:21:48 -0700 (PDT) Received: from source ([209.85.220.224]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSkU7/mJ/iKsr03sArDz5HEPMkDEi1dB2@postini.com; Fri, 26 Jun 2009 14:22:07 PDT Received: by fxm24 with SMTP id 24so1601903fxm.23 for ; Fri, 26 Jun 2009 14:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.49.16 with SMTP id w16mr3991654fgw.67.1246051311132; Fri, 26 Jun 2009 14:21:51 -0700 (PDT) In-Reply-To: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> References: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> From: Theo Zourzouvillys Date: Fri, 26 Jun 2009 22:21:31 +0100 Message-ID: <167dfb9b0906261421y7d65ae34g5f078454127d18e1@mail.gmail.com> To: Alexander Mayrhofer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF DRINKS WG Subject: Re: [drinks] WG poll on transport protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 21:21:49 -0000 On Fri, Jun 26, 2009 at 2:29 PM, Alexander Mayrhofer wrote: > The central counter argument is that SOAP is the most universally > deployed data exchange mechanism out there are you sure? I don't think i've needed to touch a SOAP API since perhaps 2003. Every single API around these days seems ot be RESTful ... http://www.programmableweb.com/apis/directory But then, i've been working in an industry that doesn't move at 0.00034km/h below snails pace since then. SOAP appears to be popular in corporate cultures as it is all "point-clickey". WSDL allows stub generation, integration is all very pretty and useful if the developer has no clue what they're doing, but as soon as you grind down to the protocol, it's seriously bloated and relies on large libraries to do all the voodoo for you. WADL now can provide similar functionallity to WSDL, so i fail to see any excuses for using SOAP anymore. on a more serious practical note, people commonly stumble on using REST over SOAP because they don't see the equvilent of WS-Transactions and WS-Notifications in REST. That doesn't mean you can't achieve the same results, just it's not a "primitive" of the protocol like it is in SOAP. > 1. How many folks have SOAP implementations in their OSS-BSS systems for > the > kinds of protocols DRINKS is looking out? probably a large number of the old-school carriers and telcos. > 2. How many folks have a REST-like implementations in their OSS-BSS > systems > for the kinds of protocols DRINKS is looking out? some do, for sure (we do), and i know of at least one multi-national voice carrier than does. The rest of the interwebs seem to prefer it, too. > 3. In general what data model or protocol properties do your > organizations > ultimately lean towards - SOAP vs. REST? Other? REST > 4. What are the specific applications that SSP are looking for DRINKS to > enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ?? SIP inteconnection. > Questions to reach WG concensus on: > > 3. Do you agree that the design team should define the architecture / > data model independently from the definition of a potential > transport protocol? (as far as possible) obviously, to a degree. While sending SOAP messages over SMTP seems "cool", and i'm sure it's got a use, i frankly couldn't care less about it :-) > 4. Given the goal to define the data model outside its transport, do you > prefer the group to > =A0 =A0 =A0 =A0A. Define a SOAP based transport protocol and if anyone is > interested they can work on a RESTful version? > =A0 =A0 =A0 =A0B. The WG try and do both? putting my pragmatic hat on for a second, i'd prefer (A) over (B) if the WG has no REST experience - It's harder to get SOAP wrong, as it's already wrong - otherwise, i'd prefer C: REST only. ~ Theo From richard@shockey.us Fri Jun 26 15:11:55 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADFB3A6A89 for ; Fri, 26 Jun 2009 15:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2L9UqLa4dcv for ; Fri, 26 Jun 2009 15:11:54 -0700 (PDT) Received: from outbound-mail-08.bluehost.com (outbound-mail-08.bluehost.com [69.89.17.208]) by core3.amsl.com (Postfix) with SMTP id 8EE433A6A49 for ; Fri, 26 Jun 2009 15:11:52 -0700 (PDT) Received: (qmail 25421 invoked by uid 0); 26 Jun 2009 22:12:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy1.bluehost.com with SMTP; 26 Jun 2009 22:12:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=XhmxY5forr5PCMaVFKPkC9xxSQiH12jhd+pJt4rjtPO9slvcj/IPps8yzY8hZso6nkj6I8R69YKOHNZWxT1ZhCohznnpTWJV5cb0ABd2mz3aoIGYghgeVRA4exsrJpIw; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MKJeU-0006Qd-Q4; Fri, 26 Jun 2009 16:12:11 -0600 From: "Richard Shockey" To: "'Alexander Mayrhofer'" , "'IETF DRINKS WG'" References: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> Date: Fri, 26 Jun 2009 18:12:07 -0400 Message-ID: <016e01c9f6ab$25e03160$71a09420$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn2Yh8jnu04p0/PR3Wwi5SjbfhmhQARRvUA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: Re: [drinks] WG poll on transport protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 22:11:55 -0000 WG Chair HAT off. > > General questions regarding deployed transport protocols: > > 1. How many folks have SOAP implementations in their OSS-BSS systems > for the kinds of protocols DRINKS is looking out? As far as I have been able to tell the vast majority of Global Telecommunications firms I have personally consulted with and for and other potential SSP's have formalized their Data Exchange Mechanisms on SOAP based transport mechanisms. Teleco firms are traditionally very very conservative and DRINKS is not exactly a WEB 2.0 like application. > > 2. How many folks have a REST-like implementations in their OSS-BSS > systems for the kinds of protocols DRINKS is looking out? I know of NO telecommunications OSS-BSS systems that currently use REST like systems for data provisioning. > > 3. In general what data model or protocol properties do your > organizations ultimately lean towards - SOAP vs. REST? Other? In the majority of telecommunications I am acquainted with SOAP is the current flavor dejure though there are provisioning systems that I could describe involving Local Number Portability that have not been fundamentally updated in decades. Of course TELEX is still in wide deployment as well as Frame Relay, ATM. > > 4. What are the specific applications that SSP are looking for DRINKS > to enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ?? All of the above and realtime video point to point using E.164 addressing. > > Questions to reach WG concensus on: > > 3. Do you agree that the design team should define the architecture / > data model independently from the definition of a potential > transport protocol? (as far as possible) Yes. > > 4. Given the goal to define the data model outside its transport, do > you prefer the group to > A. Define a SOAP based transport protocol and if anyone is > interested they can work on a RESTful version? > B. The WG try and do both? Option A. I do not believe the WG can do both though if anyone want to do B they are more than welcome to do so. PLUS IMHO any SOAP version MUST be a Proposed Standard or no vendor will seriously adopt it except under severe threat of loss of revenue. Any idea that a SOAP based transport protocol for DRINKS would be classified 'Experimental' is completely unacceptable. > > > Please provide feedback before July 8th, if possible. > > Thanks, > > Richard & Alex > _______________________________________________ > drinks mailing list > drinks@ietf.org > https://www.ietf.org/mailman/listinfo/drinks From richard@shockey.us Sun Jun 28 17:57:43 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5C828C141 for ; Sun, 28 Jun 2009 17:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt4pCj2Yj7hu for ; Sun, 28 Jun 2009 17:57:42 -0700 (PDT) Received: from outbound-mail-106.bluehost.com (outbound-mail-106.bluehost.com [69.89.22.6]) by core3.amsl.com (Postfix) with SMTP id C7B813A6840 for ; Sun, 28 Jun 2009 17:57:42 -0700 (PDT) Received: (qmail 10199 invoked by uid 0); 29 Jun 2009 00:58:02 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 29 Jun 2009 00:58:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=EnXDU89gRAbQnUJSQoUAH7GXrhMblfujB0KpfS/hBC6a/EJY9ac2RJ/hBXmjxEtJxl0OdIch8bPtQninZTGea++uMUepZpyjOMV5zCqkHHzHuK6sFdv+oP8x176Hidj8; Received: from pool-173-66-69-164.washdc.fios.verizon.net ([173.66.69.164] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1ML5C5-0000zn-Lf for drinks@ietf.org; Sun, 28 Jun 2009 18:58:02 -0600 From: "Richard Shockey" To: "'IETF DRINKS WG'" Date: Sun, 28 Jun 2009 20:57:53 -0400 Message-ID: <010301c9f854$a2d9bdd0$e88d3970$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn2bwakHkaJ+ne5SpKYmniNFuY2oAB5ZZhA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.164 authed with richard+shockey.us} Subject: [drinks] FW: Internet-Drafts Submission Cutoff Dates for IETF 75 in Stockholm, Sweden X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 00:57:43 -0000 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IETF Secretariat Sent: Friday, June 26, 2009 11:00 AM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for IETF 75 in Stockholm, Sweden There are two (2) Internet-Draft cutoff dates for IETF 75 in Stockholm, Sweden. * Monday, July 6, 2009 (17:00 PDT; 24:00 UTC/GMT): Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate working group chair before they can be processed or announced. The Secretariat would appreciate receiving working group chair approval by Monday, June 29 at 17:00 PDT (24:00 UTC/GMT). * Monday, Jul 13, 2009 (17:00 PDT; 24:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 27, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. The Internet-Draft cutoff dates as well as other significant dates for IETF 75 can be found at: http://www.ietf.org/meetings/75/cutoff-dates.html The Internet-Draft submission tool can be found at: https://datatracker.ietf.org/idst/upload.cgi Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From kcartwright@tnsi.com Tue Jun 30 07:10:46 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC6D3A6B48 for ; Tue, 30 Jun 2009 07:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nb89WTacDMW for ; Tue, 30 Jun 2009 07:10:44 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 9F22A3A6AC1 for ; Tue, 30 Jun 2009 07:10:44 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.29618166; Tue, 30 Jun 2009 10:11:52 -0400 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; Tue, 30 Jun 2009 10:09:48 -0400 From: "Cartwright, Kenneth" To: IETF DRINKS WG Date: Tue, 30 Jun 2009 10:09:45 -0400 Thread-Topic: WG poll on transport protocol Thread-Index: Acn2Yh8jnu04p0/PR3Wwi5SjbfhmhQCiw+WwACfDNEA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA053D7280E1@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [drinks] WG poll on transport protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 14:10:46 -0000 KJC>> My $.02. (I'm re-sending this due to mailing list admin. You may no= t have received the first attempt.) KJC>> Preamble: This discussion about SOAP or REST is a diversion, imo. W= hen it comes down to it I would work with either. But I vote for SOAP for = now, reasons below. The much more important and difficult discussion shoul= d be around the necessary operations and data model and peering ecosystem. = But since SOAP/REST is what we've chosen to focus on in this email thread,= here goes.... I'm adding in some technical details here in this response, = because talking about this decision purely in the abstract does not do it j= ustice. KJC>> From the all important *practical/business* perspective, SOAP is on t= he very very short list of B-to-B de-facto API standards at this point in t= ime. REST is *probably* not on that list *yet*, imo. But REST is definite= ly a very nice and elegant set of architectural principles and approach. A= nd some or all of these principles are applicable in general, even if the d= elivery envelope is SOAP (idempotence of PUT and DELETE, stateless operatio= ns, simplicity, brevity, separation of form and function, etc). And the co= mmon instantiation of REST that specifies the use of URIs for identity and = type and form, TCP for transport, HTTP for envelope and, HTTP GET/POST/PUT/= DELETE for operation/action, is a very elegant and Web oriented approach, a= lbeit a somewhat less practical one at this point in time. As a software d= eveloper I very very much appreciate REST, but as a business person I like = SOAP at this point in time. It's not fun making a trade-off like this, I w= ish I was still in graduate school. :-). General questions regarding deployed transport protocols: 1. How many folks have SOAP implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out?=20 KJC>> Add me to that list. When specifying a B-to-B application over the i= nternet, it is easy to get agreement on and adoption of SOAP (sort of like = when selecting a relational DB for an enterprise application it's easy to g= et agreement on Oracle). SOAP, and "simple" XML over TCP, are the de-facto= standards for these types of apps, based on the various projects I've been= exposed to over the past several years. Prior to the past several years, = CORBA was very common (I loved CORBA, :-)), prior to that, home grown text = delimiting over TCP was very common (that was fine as well). And-on-and-on= -and-on. "Technology thrashing" is the term I like, costing companies mill= ions of $ to constantly change, adapt, re-train, etc. But I digress. SOAP= is undoubtedly one of *the* (if not *the* 1) de-facto standards for these = types of applications at this point in time. 2. How many folks have a REST-like implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out? KJC>> None that I know of. But there may be. And there would be nothing w= rong with that from a *technology* perspective. But a *practical* *busines= s* perspective that necessitates adoption is another matter. 3. In general what data model or protocol properties do your organizations ultimately lean towards - SOAP vs. REST? Other? KJC>> SOAP for now, because that is most practical from a business perspect= ive. But REST has very good technical merits, imo. 4. What are the specific applications that SSP are looking for DRINKS to enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ?? =20 KJC>> All of the above. Questions to reach WG concensus on: 3. Do you agree that the design team should define the architecture /=20 data model independently from the definition of a potential=20 transport protocol? (as far as possible) KJC>> Most definitely. I am espousing this approach, which has been succe= ssfully applied in other IETF RFCs. However, there are practical side affe= cts of this. Most importantly, the data model must be designed to not prev= ent the specification of multiple envelopes/architectures, particularly tho= se like REST that impose an approach to Identity (URIs with embedded synthe= tic keys), Action (HTTP's PUT, GET, POST, DELETE), Type (also embedded in t= he URIs), idempotence, etc. As specific examples, (1) REST APIs are often/= usually built on the assumption that a URI can be used as object identity w= here any subpart of the URI can be an object identifier, http://adgfadvs.co= m/serviceArea/3987/17039871234), and (2) that the supported operations on a= ny object type are *at most* DELETE, PUT, POST, GET. Meaning, respectively= , that object identity cannot be a composite business key, and that the act= ion/operation should not be embedded as a structure or element in the data = model. Both of these requirements of REST will have notable side affects o= n the structure of the data model. 4. Given the goal to define the data model outside its transport, do you prefer the group to=20 A. Define a SOAP based transport protocol and if anyone is interested they can work on a RESTful version?=20 B. The WG try and do both?=20 KJC>> A, at a minimum. As a software developer, I'm interested in B, but a= s a business person I am not interested in B at this point in time. It's n= ot fun making a trade-off like this, I wish I was still in graduate school.= :-). =20 Please provide feedback before July 8th, if possible. Thanks, Richard & Alex _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks From kcartwright@tnsi.com Mon Jun 29 14:50:32 2009 Return-Path: X-Original-To: drinks@core3.amsl.com Delivered-To: drinks@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC87E3A6C13 for ; Mon, 29 Jun 2009 14:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKugLZXqIm3c for ; Mon, 29 Jun 2009 14:50:31 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 781E33A6C66 for ; Mon, 29 Jun 2009 14:50:30 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.29595422; Mon, 29 Jun 2009 17:52:06 -0400 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; Mon, 29 Jun 2009 17:50:04 -0400 From: "Cartwright, Kenneth" To: Alexander Mayrhofer , IETF DRINKS WG Date: Mon, 29 Jun 2009 17:50:03 -0400 Thread-Topic: WG poll on transport protocol Thread-Index: Acn2Yh8jnu04p0/PR3Wwi5SjbfhmhQCiw+Ww Message-ID: <754963199212404AB8E9CFCA6C3D0CDA053D727FEA@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D46650859FC1F@nics-mail.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 30 Jun 2009 08:23:10 -0700 Subject: Re: [drinks] WG poll on transport protocol X-BeenThere: drinks@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DRINKS WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 13:18:24 -0000 KJC>> My $.02. KJC>> Preamble: This discussion about SOAP or REST is a diversion, imo. W= hen it comes down to it I would work with either. But I vote for SOAP for = now, reasons below. The much more important and difficult discussion shoul= d be around the necessary operations and data model and peering ecosystem. = But since SOAP/REST is what we've chosen to focus on in this email thread,= here goes.... I'm adding in some technical details here in this response, = because talking about this decision purely in the abstract does not do it j= ustice. KJC>> From the all important *practical/business* perspective, SOAP is on t= he very very short list of B-to-B de-facto API standards at this point in t= ime. REST is *probably* not on that list *yet*, imo. But REST is definite= ly a very nice and elegant set of architectural principles and approach. A= nd some or all of these principles are applicable in general, even if the d= elivery envelope is SOAP (idempotence of PUT and DELETE, stateless operatio= ns, simplicity, brevity, separation of form and function, etc). And the co= mmon instantiation of REST that specifies the use of URIs for identity and = type and form, TCP for transport, HTTP for envelope and, HTTP GET/POST/PUT/= DELETE for operation/action, is a very elegant and Web oriented approach, a= lbeit a somewhat less practical one at this point in time. As a software d= eveloper I very very much appreciate REST, but as a business person I like = SOAP at this point in time. It's not fun making a trade-off like this, I w= ish I was still in graduate school. :-). General questions regarding deployed transport protocols: 1. How many folks have SOAP implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out?=20 KJC>> Add me to that list. When specifying a B-to-B application over the i= nternet, it is easy to get agreement on and adoption of SOAP (sort of like = when selecting a relational DB for an enterprise application it's easy to g= et agreement on Oracle). SOAP, and "simple" XML over TCP, are the de-facto= standards for these types of apps, based on the various projects I've been= exposed to over the past several years. Prior to the past several years, = CORBA was very common (I loved CORBA, :-)), prior to that, home grown text = delimiting over TCP was very common (that was fine as well). And-on-and-on= -and-on. "Technology thrashing" is the term I like, costing companies mill= ions of $ to constantly change, adapt, re-train, etc. But I digress. SOAP= is undoubtedly one of *the* (if not *the* 1) de-facto standards for these = types of applications at this point in time. 2. How many folks have a REST-like implementations in their OSS-BSS systems for the kinds of protocols DRINKS is looking out? KJC>> None that I know of. But there may be. And there would be nothing w= rong with that from a *technology* perspective. But a *practical* *busines= s* perspective that necessitates adoption is another matter. 3. In general what data model or protocol properties do your organizations ultimately lean towards - SOAP vs. REST? Other? KJC>> SOAP for now, because that is most practical from a business perspect= ive. But REST has very good technical merits, imo. 4. What are the specific applications that SSP are looking for DRINKS to enable .. LNP?..MMS/SMS interoperability, SIP interconnection etc ?? =20 KJC>> All of the above. Questions to reach WG concensus on: 3. Do you agree that the design team should define the architecture /=20 data model independently from the definition of a potential=20 transport protocol? (as far as possible) KJC>> Most definitely. I am espousing this approach, which has been succe= ssfully applied in other IETF RFCs. However, there are practical side affe= cts of this. Most importantly, the data model must be designed to not prev= ent the specification of multiple envelopes/architectures, particularly tho= se like REST that impose an approach to Identity (URIs with embedded synthe= tic keys), Action (HTTP's PUT, GET, POST, DELETE), Type (also embedded in t= he URIs), idempotence, etc. As specific examples, (1) REST APIs are often/= usually built on the assumption that a URI can be used as object identity w= here any subpart of the URI can be an object identifier, http://adgfadvs.co= m/serviceArea/3987/17039871234), and (2) that the supported operations on a= ny object type are *at most* DELETE, PUT, POST, GET. Meaning, respectively= , that object identity cannot be a composite business key, and that the act= ion/operation should not be embedded as a structure or element in the data = model. Both of these requirements of REST will have notable side affects o= n the structure of the data model. 4. Given the goal to define the data model outside its transport, do you prefer the group to=20 A. Define a SOAP based transport protocol and if anyone is interested they can work on a RESTful version?=20 B. The WG try and do both?=20 KJC>> A, at a minimum. As a software developer, I'm interested in B, but a= s a business person I am not interested in B at this point in time. It's n= ot fun making a trade-off like this, I wish I was still in graduate school.= :-). =20 Please provide feedback before July 8th, if possible. Thanks, Richard & Alex _______________________________________________ drinks mailing list drinks@ietf.org https://www.ietf.org/mailman/listinfo/drinks