Subject: [drinks] Seeing volunteers for the protocol I-D

From: Sumanth Channabasappa <[email-masked]>
Date: Tue, 2 Nov 2010 17:36:21 -0600

Folks,

The authors of the protocol I-D have indicated that they have addressed open issues and comments (to the best of their knowledge) in the latest revision of the document (draft-ietf-drinks-spprov-03). They have shared updates along the way on this mailing list (or in design team notes), and will be providing additional details at the DRINKS WG meeting next week.

Given this, we would like to request expert reviewers who can help the WG make progress on this I-D. If you are capable, willing, and interested, please respond to this email, or let us know in Beijing next week.

Thanks!
Alex and Sumanth (as WG Chairs)

---

From: "Maharishi, Manjul" <[email-masked]>
Date: Mon, 29 Nov 2010 12:27:13 -0500

Hi Sumanth, Authors of Transport I-D,

I have gone thru the doc and overall, it looks very nice!.

I have some comments as detailed below:

1.       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.

2.       Sect 3.2, page 12: Destination Group: Typo: Should be "named" instead of "name", "their" instead of thier".

3.       Sect 3.2, page 12: Route Group: Typo: "establishe" instead of "establish".

4.       Sect 4, page 14: Can we leave topics open for discussion, or we need to close these before this I-D gets thru for publication as RFC?

5.       Sect 4.4, page 16: IMO, needs some explanation for allowing unauthenticated connections.

6.       Sect 6.1, page 28: last sentence...two occurrences of "the" together.

7.       Sect 6.1, page 29: First para: Typo: missing "t" in Route Group.

8.       Sect 6.9, page 41: Layout and description of the attributes in TNType (such as corInfo) is inconsistent with the way it is defined in other places. Rest of the doc has the XSD definition first, and then the explanation of the parameters/attributes. Accordingly, this definition should go after the XSD specification on top of page 42.

9.       Sect 6.9, page 43: 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).

10.   Sect 6.11, page 47: third line - typo, should be "serve" instead of "server".

11.   Sect 7.1, page 55: Mismatch in clientTransId values between the query and response.

12.   Sect 7.3, page 57: Namespace usage for the elements is shown inconsistently - it is not shown for rantId and rarId, but is shown for rrName, ete and uri.

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.

14.   Sect 7.6, page 61: "rantId0" and "rarId0" should be replaced with "iana-en:222".

15.   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.

16.   Sect 7.16, page 72: The example for GetRteGrpOffersRqstType brings up a deficiency in the XSD definition. I think rantId and rarId need to be attributes that should be specifiable in the XSD for this "Get" operation.

17.   Sect 7.16, page 72: Same example - should be "iana-en:111" instead of "ssp1".

18.   Sect 7.17, page 72: Typo in heading - should be "Egress".

19.   Sect 8.1, page 79: Typo - should be "the" instead of "te".

20.   Sect 12, page 95: States that this section explains how to extend the protocol and procedures necessary etc, but there is no explanation!.

Manjul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sumanth Channabasappa
Sent: Tuesday, November 02, 2010 7:36 PM
To: [email-masked]
Subject: [drinks] Seeing volunteers for the protocol I-D

Folks,

Thanks!

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.