Subject: [Iptel] iptel-tel-enumdi-02, one more try

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 19:26:35 -0800

Glad to see the document made it into the directory but I was sort of sad to
see it had not taken into account Alex's comments (ok and mine too :-).
Could you take a stab at fixing those up and just resubmit. It is probably
30 minutes work. 

I think it would be nice (and very clear for IANA) if the IANA section
started with a sentence along lines of "This specification requires no IANA
actions", then continued with rest of stuff that is there now.

On 11/3/05 4:59 AM, "Alexander Mayrhofer" <[email-masked]>
wrote:

> All,
> 
>> Cullen Jennings wrote:
>>> The BNF does not add the enumdi to the par rule in the tel RFC. And
>>> the IANA
>>> registry question would also impact this.
>>> 
>>> I'm also wondering if I am nuts thinking that the we need to say that
>>> this
>>> draft updates the par line. It makes sense to me but if others think
>>> this is
>>> not needed - let me know I am nuts.
> 
> I second that we need to say this. The last sentence of the section (which,
> btw, should mention "enumdi" instead of "enum-dip-indicator"?) should at
> least specify where in the tel URI can appear. I like the style from
> draft-ietf-iptel-trunk-group, btw.
> 
> I also think that "No considerations for IANA" should be clarified. Without
> the background of the tel URI registry draft this is a imho bit misleading
> (and, could be interpreted as an suggestion that tel URI parameters do not
> need to be registered/coordinated at all [otoh, 3966 section 5.4 clarifies
> this already]).
> 
>>> Can we also get someone to do a NITS review of this draft. It the
>>> review was
>>> already done in the ENUM group then I am happy to skip it.
> 
> My comments are as follows:
> 
> - As Cullen already pointed out, there's a IPR Boilerplate issue. I've not
> investigated this in detail.
> 
> - Secion 1 has a small typo in it: "thisdocument"
> 
> - Abbreviations: There are a lot of abbreviations which are never spelled
> out. I've spotted "VoIP", "UAS", "UAC", "ENUM", "PSTN", "URI" (spelled out
> in abstract only - is this ok?), "NAPTR", "RR" not to be on the list of well
> known abbreviations.
> 
> - Abstract: The second sentenct of the abstract is a bit too long for my
> poor Engrish ;), would appreciate comments from native speakers here. In
> addition, it only talks about "receiving" an enumdi URI which could lead to
> the impression that the document is only about handling, but not creating
> the parameter in URIs. Furthermore, the ID-Checklist mandates to not use any
> citations in abstracts - Please remove references to RFCs from it. Please
> expand any abbreviations - this could lead to cluttering of the first
> sentence, maybe "SIP Proxies, H.323 gatekeepers and other VoIP elements"
> should be simply replaced by "network elements".
> 
> - Readability: Generally, there are a few rather long nested sentences. It
> makes the document hard to read in some points.
> 
> - URI examples: "<" and ">" are not part of the URI itself - they are a way
> of embedding URIs in other protocols. Please remove them from the examples.
> 
> - IANA considerations: see comment above.
> 
> - ABNF is used in the document: Please change its reference to normative.
> 
> cheers
> 
> Alex Mayrhofer
> enum.at

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