Minutes for DRINKS at IETF-interim-2012-drinks-1
minutes-interim-2012-drinks-1-00

DRINKS Virtual Interim Meeting "#82.5"
======================================

IETF Data for Reachability of Inter/tra-NetworK SIP (drinks) WG
http://tools.ietf.org/wg/drinks

Wed, Feb 01 2012, 2pm - 6pm UTC (9am - 1pm eastern)

Meeting Material:
http://www.ietf.org/proceedings/interim/2012/02/01/drinks/proceedings.html

Chairs
------

 - Alexander Mayrhofer <alexander.mayrhofer@nic.at>
 - Sumanth Channabasappa <sumanth@cablelabs.com>

Agenda
------

0) Welcome and Administrivia  (10m)
   - Note well, Logistics, Meeting Overview
   - Agenda Bashing
   - Scribes!

1) WG status review (10m)
   - Document Status, Milestones Updates

2) Group review of the two open I-Ds (80m)
   - http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spp-framework/
   - http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spp-protocol-over-soap

3) Open items discussion (60m)

4) Discuss and finalize open items that are considered
   in-scope and out-of-scope (for completion of the I-Ds) (60m)

5) Establish plan for completion prior to Paris (10m)

6) Open Mic (10m)

Participants
------------

- Syed Ali
- Jeremy Barkan
- Vikas Bhatia
- Ken Cartwright
- Sumanth Channabasappa
- Manjul Maharishi
- Alexander Mayrhofer
- David Schwartz
- Dean Willis

0) Welcome and Administrivia
----------------------------

http://www.ietf.org/proceedings/interim/2012/02/01/drinks/slides/drinks-0.ppt

The meeting starts about 5 minutes later.

Alex opens the meeting, Note well is shown, notes that this is an
official IETF working group meeting.

Alex shows the Agenda, asks for feedback from the group.

The Agenda is accepted as shown

David asks whether a new use cases document would be an option? He
misses source-ident use cases from the RFC, and also notes that
the RFC does not provide use cases for all elements.

The proposal in response was that re-opening the RFC is not currently an
option, and missing use cases can be discussed during subsequent reviews
today. Dean notes that additional use cases can always be provided as
individual submissions.

1) WG Status review
-------------------

The use cases document has been published as RFC 6461. The remaining docs
currently have milestones for Dec 2010 (submission to IESG), which is
obviously outdated.

Plan to change milestone to submit last documents to IESG by April.
This requires "advanced" versions of docs by mid March for
last call. Noted that cutoff date for updated drafts for Paris is March 12.

Proposed that we review current drafts by having most recent editor (Vikas)
talk through major changes. Most of the recent changes were "housekeeping"
or minor soiling fixes.

Vikas provides a summary based on his recent mail to the list. He changed
title & acronyms in order to address name change, but not all changes were
search & replace. He also incorporated comments that were received before
Jan 13.

Suggested that we look at "to do" list and use that as a basis for
further discussion (by Ken). Sumanth says that we will create the list
as we go through the new revisions of the drafts. Discussion starts.

It is proposed by the chairs that we go through the documents quickly,
and build a list of open issues.

Poll: How many people have read a ref since last IETF meeting?
(at least one of the revisions after the "split")

Framework: most of people on the call
Protocol: most of people on the call

David: have reviewed the docs extensively, and
some things are much clearer now

Sumanth: Proposes to do two round on documents now.
First round: identify issues, and subsequently discuss major
ones, then discuss what's open, and how to address remaining issues.

David: would like a more consistent set of document,
but have reviewed only previous the version

Sumanth: Let's list the open issues, but not
necessarily solve all of them immediately - we don't have that much time now.

Review of "Framework" document
------------------------------

Vikas showing the "Framework" document.

Skips through Introduction, terminology, to data model.

David: Noted Inconsistency between this data model and the XSD,
For example "destgrpref"... It's not called the same - wants to
see consistence in terminology.

Also, the [0..n] things could be added to the diagram - or would
that be too confusing? Actual objects don't always have an "extension",
some are only base objects, but the base object is not in the picture.
Also notes issues with route group definition.

Ken: Different views on purpose of the diagram, should reflect logical
relations. Predated XSD actually.
Discussion: What is the purpose of this digram? Is it a logical reference,
or a description of the XSD. Proposed that it is a higher-level concept.
So, how much data to include in the diagram?

David: Ok with it, lack of consistency. Extensions are confusing, take
them out of all of them? Diagram should be very crisp.

Ken agrees that we should probably remove "extension".

David is asked to send his compiled "list of nits" to the mailing list.

---ACTION ITEM: Address Diagram inconsistencies (David)

Time values (3.2): Alex will just refer from the "time" definition
part of the i18n section to this section.

Section 5.  Base Framework Data Structures and Response Codes

Section 5.2:

Proposed that 5.2 Various Object Key Types be renamed
Object Relationships or Data Identity. Perhaps under
5.2 we should have introductory text.

Alex: Proper place for the case sensitivity/comparison text?

Proposed that Section 5 is also the right spot for string
comparison and upper/lowercasing rules. Alex could send text.
Or we might just keep this in a separate internationalization section.

Vikas: Concerned that i18n text is spread all over, better to have it in one
place Ken: This area had changed quite a bit to prepare for RESTful etc.
Identification of objects has changed, more clearer?  Does object name need to
be unique within scope? Probably yes; need to clarify in text. Vikas: It's in
the text - name, registrant type is the "unique key".

actual definition is in the soap document.

David: Take off RteGrp from RteGrpOfferKeyType, in order to use the
Offer for other object types?
Alex: is cautious, because semantics of "offer" are not clear for all objects
Ken: Optimizing lookup time is internal that you can do anyway..
David: No reason in the protocol to exclude offers on any
other objects.. just change the name.. even schema does not
limit this to route groups.

Discussion around relationship between tntype and route rec
vs route group. Why can't we share any objKeyType? What
is an offer of a Registrant type good for? But we might
want to offer destination groups. Much discussion
ensued … No conclusion

---- ACTION ITEM: Investigate whether to generalize
"RteGrpOffer" to "Offer" (David)?

(Dean)
Noted to-do items
1) Change egress node
2) Internationalization
3) Internal consistency on terminology and structure, David will re-read
4) Framework 3.1 logical structure diagram and XSD alignment; remove
"extension" from diagram, handle extension consistently in XSD. 5) Clarify
uniqueness of object-type names. 6) Determine whether route-group offer can be
generalized to object-offer.

Vikas: Public Identity Type

Vikas: Response Message Types are defined here, and then implemented in the
transport docs.

section 6:

David: Carrier of Record not in base type? Could it be elevated there?
Ken: Cannot elevate, there are types for which CoR is irrelevant.
for example "email" has no CoR.. David is convinced.

Could we have a more generic (not TN) identifier in Public Identifier?
Possibly. Might use a base type with number or string. No clear action
item, though.

Ken: Number of Types of PIs has been growing over time.

Vikas: Base Type of choice of "number" or "string" as the cor?

---- ACTION ITEM: Decide on type of CoR identifier (Vikas)
URI? "Number" and "String"?

David Schwarz reiterated concerns (from mailing list and design
group) about problems with pointing TNType to a RteRecRefType
instead of a route group making his peering decisions
difficult. It basically makes the route grouping mechanism
useless. Other uses cases he raised suggest that it
might be better to have a generic offer type.

---- ACTION ITEM: TNType pointer structure (see above, David)

(Note: If we make the "Offer" change, david is fine with it pointing to rr)
Also would be another use case for the generic "offer" mechanism.
Vikas: Doesn't see any problems in generalizing Offer.
Discussion about priorities.

Section 6.3 Route Group

David praised use of route group ref and asked for
consistency with this in other structures.

Discussion: What is relationship between route priority,
route group priority and route group ref priority? Should
we remove priority attribute from RteRecType? Discussion
shows a consensus to remove this attribute.

---- ACTION ITEM: Remove priority from RteRecBaseType (Ken, David?)

Discussion: Should "in service" attribute be on RteRecType
instead of RteGrpType?? Consensus says "probably" should be on both.

---- ACTION ITEM: also add isinservice flag ont the RteRecBaseType (Ken, David?)

--- break 10mins ---

Sumanth present options to continue the meeting. Agenda
time for review is already over. Continue either review,
or try to fix a few issues? Group agrees that reviewing
docs, and identifying issues is probably more useful.
Conclusion: Continue review, goal is to get a complete
list of open issues.

David: agrees that rrRef is pointing to rrKey.

6.4 - route record

David: egressRoute has to contain a "service", promote it to base rec type?
Dicussion around the "service" flag movement.
Alex: Semantics of "service" field in bae rt rec type? Clear for NAPTR
Alex: Is not an abstract concept of DRINKS,
but the very "service" element of the NAPTR itself.
Conclusion: Bring to List.

---- ACTION ITEM: Define "service" in the base route record type (David)?

Same discussion for "ttl"...

---- ACTION ITEM: Move up "ttl" field to base route rec type (Vikas). Nobody
objects.

David: Default values for individual fields?
Alex: Default values only for defaults that are
defined in the respective specs already... Would
trigger discussion with author of actual specs?

Ken: What about the "extension"?
David: not sure "extension" is needed in all places,
it's already in basic object type, so why added again?

Ken: Can't put it in base type, becaue it would apply to all. Its in in
multiple places because we might have extensions at mutiple level

---- ACTION ITEM: Reconsider "extension" change with new info (David)

6.5. Route group offer

Rehash of earlier discussion about extending Offers/Accepts

Ken: Would need to introduce some mechanism so that
server can communicate which offers it supports,
would require more text

David: Think that benefit is so great that
it would be worth the hassle.

Ken: Need to change operation name in WSDL as well..

(see earlier action item above)

6.6 egress route

--- ACTION ITEM: David will post comment to mailing list.

7. Operations

David: What about batching?
Vikas: Batching is generic to all commands

--- ACTION ITEM: Describe Notification about method
of batch processing.

8. XML considerations

no comments

9. Security Considerations

Sumanth: We could use an early review here, and SEC ADs said let us know when
you're ready, so please review if you haven't this week

---- ACTION ITEM: Review security section, and then do early SEC review (All,
Chairs)

10. IANA considerations section

no comments

11. 12. 13. no comments.

Sumanth: Requests to generally continue to review this document,
and post comments to list rather sooner than later.

==== SOAP document ====

Vikas presents the structure of the document

Ken: Diagram on section 6 - does that need update?

David: Generic ID/URI/String in PI would need to be added here as well.

David: AddRequest: Transaction ID Type is defined as string here,
 but defined as a "Token" in the Framework. Needs to be consistent.

---- ACTION ITEM: Clarify the definition, preferrably
to "Token". (Vikas) Remove it here, for example.

Discussion about length of result code. Important to limit it,
because otherwise implementors would eg. have a hard time when
designing their database scheme.

---- ACTION ITEM: Add Max Length to result code definition (Vikas)

Ken: Abbreviation "Detail" to "Dtl" - inconsistent with
naming of respective Types?

--- ACTION ITEM: Evaluate whether expand "Dtl" and make
Type names consistent

David: What happens to rejected Offer? Do Offers time out?
Wants a clear definition of what happens, otherwise there
would be interopability issues. Need to define the
behaviour of that useful mechanism.

---- ITEM: Clarify expiration/behaviour of offers,
include Diagram? (Framework doc related item - discuss on list)

Section 7.5. of the Framework already has some text on that, is that enough?

Jeremy: Batch Ops: Isn't that a different beast? Batching looks
so completely different than the request/response...
Error handling, expectations of synchronous response..?

Ken explains the limitations / features of batching
that we agreed on during the SPPP work so far.

Open Mic time:
==============

- Slot for Paris? Was requested. No IETF draft agenda yet,
will hopefully not have the session on friday this time.
- David will think about mechanism to add more use cases.
Dean adds that it's always easier to comment on written text.

-- Proposal for next steps --

1/ Cutoff for additional comments on the latest I-Ds (2/10)    -- ALL
2/ Resolve open issues via the mailing list and design team calls (2/8, 2/15,
2/22) -- DESIGN TEAM 3/ Attempt a revision of the document for early review
(3/2); this may not address all comments -- AUTHORS 4/ Final revision for Paris
(3/10) -- AUTHORS

This will allow us to do a couple of things:
- Address and incorporate all comments so far
- Get early review comments by Paris, hopefully
- Discuss any remaining open issues and open review comments at the next IETF

Meeting concludes at 19:05