Subject: [Iptel] RE: Comments on draft-yu-tel-url-08

From: "Yu, James" <[email-masked]>
Date: Wed, 7 Jan 2004 14:33:05 -0600

Flemming,

Thanks for the comments.  Please see the responses below.  I'll wait for a
few days to see if there are additional comments before issuing the
revision.

Jonathan, I assume that the next version would be
draft-ietf-iptel-tel-parameters-00.txt.  

James

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Friday, December 12, 2003 9:16 PM
> To: Yu, James; list iptel
> Subject: Comments on draft-yu-tel-url-08
> 
> 
> I've taken a closer look at the draft-yu-tel-url-08.txt and have some
> questions and comments on it.
> 
> Non-Editorial Comments:
> - The document is fairly focused on how you can use the tel-URL
> extensions defined here in SIP. At least in the Abstract and 
> Section 1,
> I'd suggest loosening this coupling a bit as the subject of 
> the document
> is the tel-URL extensions rather than how to use them with 
> SIP. Also, it
> might be worthwhile making it clear, that these extensions can be used
> with any protocol that happens to make use of the tel-URL, 
> e.g. H.323 as
> well. In line with this, I'd suggest removing Section 8.

[YU] Will modify so that the document is not too SIP-specific.

> 
> - Lack of requirements: While reading through the document, I 
> felt that
> the document was a bit "loose" in some places and relied on the reader
> just knowing how these things work. It then occurred to me, that there
> is not a single RFC 2119 requirements word to be found in the document
> which doesn't seem quite right. I'd suggest taking another pass and
> adding some RFC 2119 requirement words throughout (or at least in
> Section 5 where firmer language and additional detail is generally
> needed).

[YU] Will use appropriate requirement language when discussing the
preference in using the parameters for routing decisions.

> 
> - JIP Parameter: It is listed in the Abbreviations section but not
> referenced in the doc. That's of course a minor issue but there is a
> bigger issue of whether we should have support for the JIP 
> parameter as
> I don't believe you have full support for LNP without it (billing
> problem when originator has been ported if I understand correctly).

[YU] Will remove.

> 
> - Section 5, second last paragraph states that:
>    "The "CIC" can be expanded to include VoIP carriers and other types
>    of carriers in the same country or under the same country code so
>    that all carriers can be identified in the IP domain for routing
>    purpose."
> I don't quite understand what this means. Is this something 
> the document
> defines and if so how ? Either way, this should be clarified.

[YU] Will clarify.  "CICs" in the U.S. are only assigned to certain PSTN
carriers.  This paragraph indicates that other types of carriers may be
assigned the CICs for routing in the IP domain.

> 
> - Section 6.1, last paragraph:    I don't follow the 
> recommendation. The
> example just above the text that talks about "the example described
> above" does not show the "rn" parameter, and if the "rn" parameter is
> not included in the previous example, I'm not sure how it would work.
> Please elaborate.

[YU] Will clarify.  The example does not show "rn."   But technically, it
could include "rn" that carries the called party number.  The recommendation
is not to include it.

> 
> - Section 9: The security considerations should provide guidelines for
> how to remedy the threats identified.

[YU] Will add texts to clarify that the applications/protocols that carry
the tel URL with those parameters may need to support data integrity to
prevent those parameters from being modified.

> 
> 
> General editorial comments:
> - There are numerous format/conversion problems throughout 
> the document
> (doesn't look like pure ASCII).

[YU] Please be more specific (e.g., point out a few problems).

> - Use of commas and periods inside or outside double-quotes. This is
> clearly a style issue with no universally agreed upon rules, 
> but clarity
> argues for placing them outside the quotes when you are referencing a
> literal value rather than quoting a piece of text, i.e. "rn," should
> rather be "rn", IMO.

[YU] I'll leave it to the group to decide the format to use.  I've been
following this rule  (e.g., "rn." instead of "rn". when the sentence ends
with "rn") from a book/an article that I don't remember its name now.

> - Should probably also reference Security Considerations 
> section at the
> end of Section 1.

[YU] Will add.

> - The document treats POTS and free-phone numbers as two different
> things; are they ? See for example, Section 1, 2nd paragraph.

[YU] POTS numbers usually refer to the geographic numbers (e.g., Plain Old
Telephone Service or POTS does not include freephone service).  I can change
"POTS numbers" to "geographical E.164 numbers" if there is no objection.

> - The document talks about the extensions as being 
> "proposed". May want
> to reword to "defined" or something like that.
> 

[YU] Will change.

> 
> Detailed editorial comments:
> 
> p. 1
> OLD: ABTRACT
> NEW: ABSTRACT
> 

[YU] Will change.

> Section 1, 3rd paragraph
> OLD: associate
> NEW: associated

[YU] Will change.

> Abbreviations:
> OLD: Telephony Routing Information Protocol
> NEW: Telephony Routing over IP
> 

[YU] Will change (also in the reference section).

> OLD: Uniform Resource Locators
> NEW: Uniform Resource Locator
> 

[YU] Will change.

> Section 4, 2nd and 3rd paragraph (i.e. twice)
> 
> OLD: POT number
> NEW: POTS number
> 

[YU] Will change unless "POTS number" is changed to "geographical E.164
number."

> Section 5, ABNF
> OLD: ";rn"
> NEW: "rn"

[YU] Will change.

> Section 5, 2nd paragraph after ABNF:
> OLD: identify a country code
> NEW: identify an E.164 country code
> 

[YU] Will change.

> Section 5, 4th paragraph after ABNF:
> The sentence:
>    "It is also possible that the SIP protocol can be used for the NP
> query.
>    In that case, the response (e.g., 302 Moved) to the SIP message may
>    carry the NP related information in the "tel" or "sip" URL format
>    with the parameters proposed in this document."
> doesn't belong in this document IMO (unless you want to define that
> mechanism here as well).

[YU] Will delete.

> 
> Section 5, 5th paragraph after ABNF:
>    "A new address family in the Telephony Routing Information Protocol
> (TRIP)[7] has
>    been defined for cic."
> Where is this defined - is there a reference ?
>

[YU] Will change to refer to 
http://www.ietf.org/internet-drafts/draft-ietf-iptel-tgrep-02.txt.
 
> Regards
>        Flemming

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

---

From: Michael Hammer <[email-masked]>
Date: Thu, 08 Jan 2004 11:31:36 -0500

James,

I have a couple editorial comments:

It might be useful to mention the new parameters created by name in the 
Abstract to enable someone searching on a parameter name to quickly 
identify this as the relevant document.

It might be useful to fully separate the syntax definitions from the 
procedural definitions.  Many other documents have a section heading that 
is simply X Syntax.

It may help the reader if the procedures are divided into separate sections 
for each parameter or by each type of action that may be rendered on a 
parameter.  E.g. what does an initiator (UAC) v. modifier/user (Proxy) v. 
recipient (UAS) do with each parameter?  Much of this is already there, 
just suggesting a little more structure to help reader locate relevant text 
more quickly.  Currently, this material is spread over section 1, 3, 4, 5, 
6, and 7, with normative rules being perhaps spread across all of those 
sections.  I would suggest:
Section 1 introduction
Section 3 syntax definition
Section 4 normative rules
Section 5 service examples

Section 10: Provide a specific URL reference to the IANA registry 
location.  I browsed through there recently and did not see anything, so 
presumable this will create it?

Section 12: It seemed odd that this draft would make a normative 
modification to the syntax of another document, yet list that other 
document as informative (ref [4]).  Also, could these be renumbered?

Thanks,
Mike