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

[Cullen Jennings <[e-mail]>]

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.



On 12/9/05 1:43 AM, "Alexander Mayrhofer" <[e-mail]>
wrote:

> Cullen Jennings wrote:
> 
>> 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.
> 
> 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

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