---
--- 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 at 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.
=> 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 at ietf.org
> end.