[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evaluation: draft-ema-vpim-clid - Calling Line Identification for Voice Mail Messages to Proposed Standard

In message <200303290322.WAA00019@ietf.org>, IESG Secretary writes:
>
>Last Call to expire on: 2003-4-8
>
>	Please return the full line with your position.
>
>                    Yes    No-Objection  Discuss *  Abstain  
>
>Steve Bellovin      [   ]     [   ]       [ X ]      [   ] 

Some of the writing just doesn't make sense.  For example, the fourth 
paragraph of Section 1 starts "As a result", but I don't see what 
that's a result of.  The following sentence, about "future generation 
of the proper Internet address", makes even less sense.  (Note that I'm 
talking about semantics, not grammar.)

3.2 is just as obscure.  It says "requires provisioning for up to 15 digits",
which sounds like a storage allocation requirement for the program 
generating or accepting the Caller-ID header.  But it then goes on to 
speak of some telephonhy providers only supporting 10 digits, and how 
it is better that "an international number NOT be truncated".  Why 
should implementations of this spec truncate the number?  Is it a 
comment on phone systems?  If so, it's gratuitous.  And the capitalized 
NOT -- which isn't in 2119 -- should not be used in that case.

3.3 ties the dialing plan to the FQDN of the sender.  That's wrong, or 
rather, it's useless -- FQDNs can span numbering plan areas.  Or 
rather, there's no intrinsic link between an FQDN and any geographic 
location, and hence a numbering plan.

The Security Considerations have little to do with security.  The 
information is useful, but shouldn't be presented in this section.

It would be nice if the phone number formats used here were compatible 
with other Internet formats, i.e., that in RFC 3192 or in SIP URIs.
A gateway that receives phone numbers can certainly translate to such 
formats; the translation back to a localized format can be done as well 
by the ultimate recipient's machine.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)