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

From: "Yu, James" <[email-masked]>
Date: Wed, 16 Feb 2005 16:09:33 -0500

Flemming,

Thanks for the comments.

Sorry to respond late.  I was waiting for the message that I asked you to resend but did not see it until today.  Please see the responses below.  I'll submit the -04 version today.

James

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Monday, January 17, 2005 12:01 PM
To: [email-masked]
Cc: Flemming Andreasen; Yu, James; Cullen Jennings
Subject: Re: [Iptel] Review of draft-ietf-iptel-tel-np-03.txt

Resend by request

Flemming Andreasen wrote:

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

[YU]  global-rn	should be "+" 1*global-hex-digits    instead of "+" 1*phonedigit-hex.
I'll also emphasize that the "national" number part of a "global-rn" or the "local-rn" may contain hexadecimal digit(s).

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

[YU]  Will break this dashed item to two dashed items.

**************************
- The network node SHALL ignore the "cic" parameter if the CIC identifies a carrier or service provider associated with that node and look for the "rn" parameter for making the routing decision.  It SHALL remove the "cic" parameter when it routes the call to the next-hop network node that belongs to another carrier or service provider.
 
- The network node MAY invoke special handling process if the "cic" parameter contains a code that requires such a treatment.  It SHALL remove the "cic" parameter after it has performed the special handling process.  For example, a CIC value of "0110" in the response to a freephone DB query in the North America indicates "local, translated geographical telephone number provided").  In this particular example, the "cic" parameter is ignored.  Please note that this particular CIC value of "+1-0110" normally will not appear in the call setup message. It is given as an example to show that such special CIC values may exist.  The exact code values and the handling of them are outside the scope of this document.
**************************
>
>
> Section 5.1, 9th and 10th paragraph.
> Again, I don't see why "the network SHALL remove the "rn" parameter".

[YU]  Will change the texts in those two paragraphs to

**************************
- If the routing number in the "rn" parameter points to this network node (e.g., the call has reached the intended network node), this network node SHALL look for the freephone number or geographical telephone number for making the routing decision.  It SHALL remove the "rn" parameter when setting up the call to the next-hop network node regardless if that next-hop network node is in the same or different network.

- If the routing number in the "rn" parameter points to a network this network node is in (e.g., in some countries the routing number gets the call to the serving carrier network where another NP database access is required to locate the serving switch), this network node SHALL look for the freephone number or geographical telephone number for making the routing decision.  The network node MAY access the NP database for routing information if it is set to do so.  It SHALL remove the "rn" parameter if the next-hop network node belongs to another carrier or service provider.**************************
**************************

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

[YU]  Will change and break the first paragraph to two paragraphs. 

**************************
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 map between the corresponding ISUP parameters and the parameters defined in this document associated with the "tel" URI for routing and MAY map between the corresponding ISUP parameters and the parameters defined in this document that are in the "tel" URI associated with the caller.

Since ISUP support for NP depends on the individual country, the following discussion applies to a situation when a network node is to map between the NP information in the American National Standards Institute (ANSI) ISUP and the NP-related parameters in the "tel" URI.  
**************************

I also added one sentence to the 2nd to the last paragraph.

**************************
The mapping may be subject to the network node's local policy and/or the signaling protocol that carries the "tel" URI.
**************************

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

[YU] Will add a paragraph.

**************************
If the "rn" in the "tel" URI that is associated with the caller is illegally changed or inserted, the call charge based on that "rn" would be incorrect.  
**************************

>
> 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)

[YU] I'll search and delete the extra space.

     If you have (or anyone has) the correct template, please send to me and I'll use that template for the next revision.  

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

[YU] Will change the abstract to 

**************************
Number Portability (NP) for the geographical telephone numbers and freephone numbers impacts signaling and routing in the Global Switched Telephone Network (GSTN) and Internet Protocol (IP) domain.  At present, there is no mechanism for a network node in the IP domain to pass the NP-related information to the next-hop network node after it has performed an NP database dip.  This document defines several new parameters in the "tel" Uniform Resource Identifier (URI) to carry the NP-related information that can be used by the network nodes in the IP domain to correctly set up the calls or sessions.  
**************************

>
> - Abstract  "that NP database dip" => "that an NP database dip"
                                ^^

[YU]  Will Change.

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

[YU] Will changed to 

**************************
NP impacts call signaling and routing.
**************************

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

[YU]  Will Change.

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

[YU]  Will change to indicate "parameters defined in this document" or something like that.

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

[YU]  Will Change.

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

[YU] Will change the sentence.

**************************
For a "local-rn", the routing number in the "rn" parameter MUST be interpreted according to the "rn-context".  
**************************

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

[YU] Will change the sentence.

**************************
For a "local-cic", the CIC value in the "cic" parameter MUST be interpreted according to the "cic-context". 
**************************

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

[YU]  Will Change the first part of the sentence to 

**************************
If the network node does not know how to route based on the "cic" or "rn" parameter
**************************

>
> Section 5.1, last paragraph
> "making routing decision" => "making routing decisions"
>                                                     ^

[YU] Will Change.

> "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"
>             
> ^^^                                                                                
>  ^    ^^

[YU] Will Change.

>
> 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"
>                  
> ^^^^^^   

[YU] Will Change.
                                                          ^
>
> 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).
>

[YU] Will change the last paragraph to

**************************
For example, if the network node is a PSTN gateway that receives an ISUP message that contains the JIP, the correct location information in the JIP can be placed in the "rn" parameter of the "tel" URI that is associated with the caller.
**************************

>
> 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"
>        
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[YU] Will change.

>
> 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"
>        
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[YU] Will change.

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

[YU] Will change to 

**************************
A "rn" SHALL NOT appear in the "tel" URI unless the local policies require the network node to include it. 
**************************

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

[YU] The change above will take care of this comment.

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

[YU]  I looks fine in my document but will retype.  
>
> 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.

[YU] Will change "(e.g., no routing information on "+1-202-000") to "e.g., no routing information on "+1-202-000-0000") so as not to explain the prefix-based routing.
 
>
> 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.

[YU] Will change.

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

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