Subject: [drinks] Minutes from June 11 & June 15 protocol design team calls

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 18 Jun 2009 03:37:32 -0600

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

> end.