Subject: [drinks] Minutes from May 28 & June 9 protocol design team calls

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 12 Jun 2009 09:02:26 -0600

--- 
--- 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 [email-masked] 
 
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:

       +---------+            +--------------+
       |  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). 
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"
                - 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
=> 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 [email-masked]

> end.