Subject: [Iptel] Review of draft-ietf-iptel-tel-np-03.txt

From: Flemming Andreasen <[email-masked]>
Date: Mon, 20 Dec 2004 16:57:54 -0500

Greetings

Below, please find review comments for draft-ietf-iptel-tel-np-03.txt. 
In general, I think the document is close to being done, but there are a 
few minor issues to address as well as some nits.

Non-Editorial
=============
- Section 4, ABNF
The production for "global-hex-digits" ends with "*phonedigit-hex". I 
don't understand what that is for, not least considering the ensuing 
text for "local-rn"
<quote>
   For a "local-rn", the routing number in the "rn" parameter MUST be
   meaningful in terms of "rn-context".  For example, if a national
   routing number is in the "rn" parameter, the "rn-context" MUST
   contain a valid E.164 country code after "+" if it is in the
   "global-hex-digits" format.
</quote>

Section 5.1, 6th paragraph
"The network node SHALL ignore the "cic" parameter if it identifies a 
carrier or service provider associated with that node, or if that 
parameter contains a code for indicating that a geographic number is 
supplied (e.g., +1-0110 means "local, translated geographical telephone 
number provided"). ". Given the normative requirement, we either need 
some more text or references to explain how we determine if the 
parameter contains a code for indicating that a geographic number is 
supplied.

Section 5.1, 6th paragraph
"The network node SHALL remove the "cic" parameter and look for the "rn" 
parameter for making the routing decision." I don't see why the network 
node SHALL remove the "cic" parameter and would in fact argue for at 
most a MAY. I agree it shall look for the "rn" parameter for making the 
routing decision though.

Section 5.1, 9th and 10th paragraph.
Again, I don't see why "the network SHALL remove the "rn" parameter".

Section 5.2.4, 1st paragraph
"A Public Switched Telephone Network (PSTN) gateway needs to convert
   between SS7 ISUP and the VoIP protocol such as SIP or H.323.  This
   type of network node SHALL add the corresponding information from
   the ISUP to the defined parameters to the "tel" URI for routing and
   the "tel" URI associated with the caller and vice versa."
I disagree with the latter part ("and the "tel" URI associated with the 
caller and vice versa"). We are getting into privacy and security 
related issues and hence cannot make it mandatory for all.

Section 7
Need to add security considerations for using the extensions for the 
caller (JIP considerations)

Editorial and/or nits:
======================
- Global
Three spaces after period in several places.
Not sure if formatting adheres to RFC Editor guidelines (at least I 
can't get it to print with proper page breaks)

- Abstract
Should not describe the actual extension parameters in the abstract but 
rather describe the problem and outline the solution.

- Abstract  
"that NP database dip" => "that an NP database dip"
                                ^^
- Section 2, 1st paragraph
"It has been identified that NP has impacts on several works-in-progress 
at the IETF." =>

 "NP impacts call signaling." or something like that.

- Section 2, 3rd paragraph
"call set up" => "call setup"

- Section 2, 5th paragraph
The sentence
    "Section 5 describes the rules for a network node that deals with 
some or all of the defined parameters in a "tel" URI"
is not accurate since we are only talking about some specific extensions 
here. The phrase "defined parameters" is used throughout the document to 
refer to the extensions defined in this document. I'd suggest using 
another more accurate phrase throughout.

- Section 4, 1st paragraph
Add some words explaining how this ABNF simply defines new parameters in 
accordance with the ABNF for "tel" URI provided in RFC 3966.

- Section 4, 5th paragraph
"...the routing number in the "rn" parameter MUST be meaningful in terms 
of "rn-context". Although the example that follows helps clarify it for 
E.164 numbers, it is in general not well defined what "meamingful" 
means. Please rephrase to make it clearer.

- Section 4, last paragraph
"...the CIC value in the "cic" parameter MUST be meaningful in terms of 
"cic-context". Semantics unclear - please rephrase to make it clearer.

Section 5.1, 4th paragraph
"or routing information" => "or routing number information" (?)

Section 5.1, last paragraph
"making routing decision" => "making routing decisions"
                                                     ^
"set to do so or may route the call to a designated network node that 
will access the NP database or may route the call" =>
              ^^
"set to do so, it may route the call to a designated network node that 
will access the NP database, or it may route the call"
             
^^^                                                                                
  ^    ^^

Section 5.2.2, 6th paragraph
"telephone number that is the typical case for the second freephone 
database access, the" =>

"telephone number (which is the typical case for the second freephone 
database access), the"
                  
^^^^^^                                                             ^

Section 5.2.3, 2nd paragraph
"For example, if the network node is a PSTN gateway that receives an 
ISUP message that contains the JIP, the "rn" parameter in the "tel" URI 
would normally contain the correct location information." Please 
rephrase (it is the ISUP message that contains the correct location 
information which is therefore placed in the "rn" parameter in the "tel" 
URI).

Section 5.2.4, 2nd paragraph
"put it after the "tel:" in the "tel" URI that is used for routing" =>

"put it in the global-number-digits or local-number-digits (see RFC 
3966) part of the "tel" URI that is used for routing"
        
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Section 5.2.4, 3rd paragraph
"put it after "tel:" in the "tel" URI that is used for routing" =>

"put it in the global-number-digits or local-number-digits (see RFC 
3966) part of the "tel" URI that is used for routing"
        
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Section 5.2.4, 3rd paragraph
"No "rn" SHALL appear in the "tel" URI." =>

"An "rn" SHALL NOT appear in the "tel" URI."
 ^^            ^^^

Section 5.2.4, 3rd paragraph
"It is outside the scope of this document how to include the "rn" 
parameter if the local policies require the network node to do so." I 
don't follow - the previous sentence just said that you are not allowed 
to do so.

Section 6, example B
"providerÆs" => "provider's"

Section 6, example E
"   E. A "tel" URI, tel:+1-202-533-1234;rn=+1-202-000-0000;npdi, contains
     an invalid routing number (e.g., no routing information on "+1-
     202-000"), "
Example seems to assume prefix-based routing - might be good to clarify 
that.

Section 8 and 9
There are gaps in the reference numbers. In general, it would probably 
be better to use symbolic references instead of plain numbers.
2806bis-09 is now RFC 3966.

-- Flemming

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