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 - Sumanth Channabasappa 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