Subject: Re: [Iptel] Sending draft-ietf-iptel-tel-np to IESG

From: Cullen Jennings <[email-masked]>
Date: Mon, 05 Dec 2005 20:46:30 -0800

Hi all, 

I hoping that someone can do a NITS review of this draft and send James
comments so he can resubmit a version I can request publication on.

Thanks, Cullen

On 10/29/05 1:15 PM, "Richard Shockey" <[email-masked]> wrote:

> Cullen Jennings wrote:
>> I reviewed this and would like one other person to do a careful NITS review
>> of of draft-ietf-iptel-tel-np-07 and send any typos to James and list. Can
>> someone please volunteer for this.
> 
> Sure .. I'll ask Alex Mayrhofer to take a look at it ASAP he's now ENUM
> WG Secretary and Patrik and I are having him run the NITS review on all
> our documents.
> 
>> 
>> Once James submits a new version I plan to submit this to IESG the day it
>> gets in the drafts directory which could be as early as Nov 7. This was
>> already WGLC and the comments from WGLC were incorporated.
>> 
>> Cullen
>> 
>> _______________________________________________
>> Iptel mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/iptel
>> 
> 

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 06 Dec 2005 14:03:39 +0100

> comments so he can resubmit a version I can request publication on.

I'm going to review this. I'll try to do it by tomorrow, but i'm a bit 
"disconnected" here at the ITU ;)

cheers

alex

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 08 Dec 2005 10:04:33 -0600

> comments so he can resubmit a version I can request publication on.

I know Alex graciously volunteered for this, but I was also able
to find some time to do a nits review of tel-np.  Hopefully, along
with Alex's, this'll help the author as well.

Overall, the document is well written and easy to read.  The nits
I found are listed below.

0) At various point in the document, a SHALL strength is used
  where (to me) a MUST strength is applicable (like adding the
  "npdi" parameter, removing the "cic" and so on).  Is it
  intentional that SHALL has been used and not MUST?  It could
  be that I am missing some history on this, since I have not
  tracked the draft from inception; and if so, please disregard
  this comment.
1) Since the I-D is > 10 pages long, I think a ToC is a good idea.
2) In preparation for IESG LC, take out "This work is being discussed
  on the [email-masked] mailing list."
3) Since RFC3966 extols implementations to order parameters by
  lexicographical ordering, certain examples in Section 6 should be
  redone to have the ";npdi" parameter appear before the ";rn"
  parameter.
4) An "IANA Consideration" section should be added referring simply
  to draft-ietf-iptel-tel-reg-00.

Thank you.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Lucent Technologies/Bell Laboratories, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216
_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 08 Dec 2005 11:19:06 -0500

RFC 2119 makes MUST and SHALL equivalent.

>  tracked the draft from inception; and if so, please disregard
...

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 08 Dec 2005 10:36:34 -0600

> RFC 2119 makes MUST and SHALL equivalent.

So it does ... however, to the uninitiated reader of the specification,
having a MUST somehow seems more authoritative than having a SHALL
(I had to look up rfc2119, and I am a wee bit initiated in the
ways of the IETF ...)

I'll leave it up to the author to decide what to do.

Thanks,

- vijay

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 09 Dec 2005 10:43:53 +0100

> comments so he can resubmit a version I can request publication on.

Hi,

I've completed my review, here are my comments - disclaimer: I've not read 
any discussion about this draft, so if i'm repeating something that has 
already been addressed please excuse my ignorance.

Summary: I think that technically this is pretty mature, however, certain
parts of the text should be improved for clarity and brevity. Here we go:

- The online ID-NITS checker reports that there is an issue with the IPR 
boilerplate. I've not investigated this in more detail. Additionally, it 
reports the missing IANA section. Here is the raw output:

----
idnits 1.74

iptel/draft-ietf-iptel-tel-np/draft-ietf-iptel-tel-np-07.txt:

   Checking nits according to http://www.ietf.org/ID-Checklist.html:
   * The document seems to lack an IANA Considerations section.
     Checking conformance with RFC 3978/3979 boilerplate...
   * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
     Nothing found here (but these checks do not cover all of
     1id-guidelines.txt yet).

   Miscellaneous warnings:
     None.

     Summary: 2 nits, 0 warnings

     Run idnits with the --verbose option for more detailed information.
----

- Title: I'm not really happy with the word "new" in the title. The RFC
would still be named like that in 20 years (when, hoepfully, those parameters
will no be new anymore at all) - my recommendation is to simply remove the
word from the title, or even change the title to 'Number Portability 
Parameters for the "tel" URI'

- Abstract: same issue with "new". Could be left out here as well. My
feeling is that the abstract is a pretty long sentence. Probably it should
be split after "... related information", and continue with "This
information could...". As i'm not a native speaker, i'm unsure here, 
however. comments appreciated

- Abstract, sentence mentioning the mailing list: This should be removed 
prior publication (or the RFC editors should be instructed to do so).

- I'm missing a ToC

- 2. Introduction:

First para: Personally, i'd remove the word "the" in front of "telephony
subscribers". "800 numbers in the North America" should be changed to
"numbers within the 800 area code in the North American Numbering Plan".
Generally, i don't think the sentence "The NP implementations in many
countries..." is neccessary here, because it does not provide any additional
information relevant for the protocol described (and readers can be expected
to be familiar with ranges that support NP, anyways).

Second/Third para: [disclaimer: I know close to nothing about SS7 etc.] Is
this really specific to geographic numbers? In all countries? I think that
this should be generalized. Also, are numbers really "located" at a carrier?
I think that they are "serviced" or "initially allocated". I'm sure that
other members of the group could provide more precise terms for this.

4th para: Is this specific to "freephone" only? Again, in which countries?
Rephrasing this to "... identifies the current carrier of the respective
phone number" (in what network? ahhh...). Does the second sentence also
refer to free phone numbers?

Personally, i'd reduce the introduction to a few sentences which explain 
what the parameters to be introduced are - the NP mechanics should already 
be explained in RFC3482 to which you are refering anyways.

The last few sentences of the the introduction would become redundant if 
you'd introduce a more formal ToC.

- I like the "abbreviations" section. It gives a good overview. However, you 
can safely remove "IETF" and "IP" from the lists as those two are considered 
well known abbreviations within the IETF, and don't need to be spelled out.

- Formal syntax: The ABNF and the description what goes into the URI are a 
bit inconsistent. First, the "phonedigit" definition is never used (all 
relevant parameters contain "phonedigit-hex"), so it could be safely 
removed. Additionally, i don't understand why you have the following 
definitions there, since they just "rename" other definitions: rn, npdi, 
cic. What is the reason for introducing 2 names for those definitions?

You should state which part of the "tel" URI definition is to be extended by 
those parameters (that would be the "par" definition in RFC3966, afais).

The ABNF validator at http://rtg.ietf.org/~fenner/abnf.cgi suggests a few 
changes with regards to normalization, btw.

- Section 5: Again, i'm not happy with the specifics regarding "freephone" 
and "geographic" number ranges. I'm sure that i don't have enough insight 
into number portability, but i suspect that those parameters might be useful 
in other scenarios as well (like mobile number portability). You are 
basically excluding such scenarios.

I'd like to see comments from number portability gurus _outside_ the NANP 
here - they are for sure more competent in reviewing this than i am.

- Section "5.2" - you are refering to section "5.3.4" which does not exist 
in the document. That should probably be "5.2.4".

- Section 6, example "A": "service provide with" should be corrected to 
"service provider with"
- Section 6, example "B": That should read "service providers" instead of 
"service provider's".
- Section 6, example "G": "If the valid" should be "If valid" - generally, 
my impression is that there are a few "the"s in the example section where i 
would not expect them ('... value of the "rn" of "cic" ...') - again, i'm 
not a native speaker.

- IANA section: Please include one, probably with "there are no 
considerations for IANA" with an explaination to the RFC editors that those 
parameters are already included in the upcoming tel URI parameter registry 
document.

hope that helps

cheers

alex

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 17:48:58 -0800

Alex thanks for the detail review.

James, any idea when we could have a rev that addressed these and Vijay's
comments? I would really really like to have this sent to the AD before the
holidays. 

Thanks, Cullen.

PS - I agree that SHALL or MUST is left to your discretion - I'm happy
either way. I will note that the MAY/SHOULD/MUST are used the most and many
people seem more familiar with those.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Dec 2005 13:02:46 -0500

(not as chair) I think we should go for MUST; this is used much more 
often in the RAI set of specifications, and we should be consistent.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com