Subject: [drinks] Rough Notes and AI list from the call on 12/2

From: Sumanth Channabasappa <[email-masked]>
Date: Thu, 2 Dec 2010 08:59:13 -0700

IETF DRINKS DESIGN TEAM CALL
============================
12/02/2010, 10:00a-11:00a (Eastern)/8:00a-9:00a (Mountain)

Participants
============
- Ken Cartwright
- Manjul Maharishi
- Jean-Francois Mule (first half)

- Sumanth Channabasappa

ACTION ITEMS
============
[Syed, Ken] Verify the comments received so far and make updates to agreed-upon sections.

AGENDA
======
1. Comments against against the protocol document (http://tools.ietf.org/html/draft-ietf-drinks-spprov-03)
2. Next Steps

NOTES
=====
1. Comments against against the protocol document

- Link: http://tools.ietf.org/html/draft-ietf-drinks-spprov-03
- We discussed Manjul's comments in detail

+ Here are the specific comments from Manjul (http://www.ietf.org/mail-archive/web/drinks/current/msg00841.html) that were considered non-editorial

> Sect 3.2, page 12: Public Identifier: Text needs to be tightened up. It states Public Identifier is used as a key to perform lookup functions. And then it states that RN and range could be used as a lookup key, which is not quite correct.
[Design Team] Agree

> Sect 4.4, page 16: IMO, needs some explanation for allowing unauthenticated connections.
[Design Team]  We agreed to remove unauthenticated connections.

> There is mention of expansion of number ranges in Open Number Plan section. There is no detail of what that means, and personally, I am not sure we want to go that route. I would prefer to reword this and remove the word "expand". Additionally, I didn't quite follow the explanation (and I admit that I haven't followed all of the discussion on the mailing list wrt this) of how the ONP stuff is supposed to work. IMO - some additional explanation would help to keep everything in the same place (instead of some of it being on the mailing list, and not in the document itself).
[Design Team] We agreed that the text is not very clear, and recommend we update it. Perhaps we could use some of the description from the examples?

> 13.   Sect 7.5, page 60: CorDateTime is shown as prior to the Creation date time. Is this an oversight, or there is additional implication behind this - ie the Registry can return back the Date Time when the Regulatory body actually affirmed the COR claim of the Registrant? IMO, that imposes unnecessary requirement on the Registry and so the COR date time should be at or after the Creation date time.
[Design Team] We agreed that this needs to be clarified in the text

> 5.   Sect 7.6, page 61: IMO, the rn parameter should be in E.164 format. Having said that, we haven't made any statement in the doc wrt E.164 nature of the TN/TNR/TNP/RN parameters - the question is should we? I think it should be left to the local policy of the Registry on how to handle non-E.164 elements being provisioned (e.g.: use some other rules to determine how to normalize such data prior to storage and/or further distribution). However, that does add avoidable complications, and it might be preferable to simply store everything as E.164 objects.
[Design Team] We discussed this in some detail. [Manjul] recommended that, for the sake of simplicity, we specify that all numbers be provisioned as E.164 numbers. After some discussion we agreed to ask the WG.

+ We also discussed comments from Otmar
See: http://www.ietf.org/mail-archive/web/drinks/current/msg00840.html
[Design Team] We agreed to modify the text.

http://www.ietf.org/mail-archive/web/drinks/current/msg00839.html
[Design Team] Agreed.

+ There were a few other comments raised by Ken, reproduced below:
[Ken] I believe that we had agreed to remove the EmailType, but that never got reflected in the XSD or the wsdl.  Removing this would be an easy change.

[Ken] We should consider shortening a few of the element names, particularly those that are contained in the PubIDType base type and the concrete public identity types such as TN, TN Range, etc.  This will lessen the number of characters going over the wire.  This would be any easy search and replace activity.

[Ken] The statements about expanding TN Ranges should probably be removed from the doc.  That is probably not an advisable approach, but in any case it would be an internal implementation decision of the server rather than something for the protocol.

[Ken] The "prefix" attribute in TNRType should be an element rather than an attribute.  Rather than having the properties of an object mixed between elements and attributes we've standardized on using elements.

2. Next Steps
- The authors will be making updates based on the discussions today and any resulting discussions from the mailing list. They will update the WG as updates are made.