Re: [Enum] Are we ready to go to WGLC on this?

Peter Koch <pk@DENIC.DE> Wed, 02 May 2007 07:15 UTC

Return-path: <enum-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj93Y-0004Zx-ER; Wed, 02 May 2007 03:15:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj93X-0004Zp-6W for enum@ietf.org; Wed, 02 May 2007 03:15:19 -0400
Received: from smtp.denic.de ([81.91.161.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj93U-0006xS-N1 for enum@ietf.org; Wed, 02 May 2007 03:15:19 -0400
Received: from mail-int1.denic.de (mail-int1.denic.de [192.168.0.45]) by smtp.denic.de with esmtp id 1Hj93T-00053z-1m; Wed, 02 May 2007 09:15:15 +0200
Received: from localhost by mail-int1.denic.de with local id 1Hj93L-0003x8-00; Wed, 02 May 2007 09:15:07 +0200
Date: Wed, 02 May 2007 09:15:07 +0200
From: Peter Koch <pk@DENIC.DE>
To: IETF ENUM WG <enum@ietf.org>
Subject: Re: [Enum] Are we ready to go to WGLC on this?
Message-ID: <20070502071507.GA11659@denics7.denic.de>
Mail-Followup-To: IETF ENUM WG <enum@ietf.org>
References: <01fc01c78c04$cd1e95c0$675bc140$@us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <01fc01c78c04$cd1e95c0$675bc140$@us>
User-Agent: Mutt/1.4i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On Tue, May 01, 2007, Richard Shockey wrote:

> Speak now or ..you know..
> 
> Title		: IANA Registration for IAX Enumservice
> 	Filename	: draft-ietf-enum-iax-02.txt

I've reviewed draft-ietf-enum-iax-02.txt and here are some remarks before
it goes to LC:

The boilerplate text in section 1, terminology isn't necessary since no
normative language is used in the document. Actually, ``<?rfc compact="yes"?>''
might save even more space.

> 3. IAX Service Registration
> 
>       A client selecting this NAPTR will have support for originating a
>       call utilizing the IAX2 protocol [ID-IAX].

Is "will have support" meant to read "needs to be able to support"?

In the service description, there is only one subtype defined. Our draft guide-
lines for ENUM service registrations, "draft-ietf-enum-enumservices-guide-03",
suggest that there be at least two or subtypes should not be defined. In the
change history it says "* Added the 'iax2' subtype at WG request." and the
introduction states about IAX2: "In addition, its open nature permits new
payload types additions needed to support additional services."
Now, if there is a reason to deviate from the guidelines, it would be good
to state that explicitly.

The normative reference to [ID-IAX] is definitely necessary. The I-D tracker
lists it as "ID exists" only, so what is the status of that document?

Is this ENUM service registration aimed at Proposed or Informational?

> 4.1.  Simple IAX Registration

>    $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
> 
>    @ IN NAPTR 10 100 "u" "E2U+iax:iax2" "!^.*$!iax2:example.com/
>    charlie!"

NIT: whitespace in URIs ought to be ignored, but that's not necessarily true
     for the regexp field. Better split the RR over two lines using the '('
     ')' RR convention.
NIT: the final "." is missing, also with some other NAPTR RRs
NIT: a reference to OFCOM's daram numbers might be advised

>    This contact information indicates that the domain
>    8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. may be contacted by using the IAX2
>    protocol at domain 'example.com' with the identifier 'charlie'.

While I realize the wording is copied from RFC 3761, I don't buy the idea of
a domain being contacted.  Instead, say that "+442079460148" can be
accessed (or contacted, for that matter) via IAX2 or offers service with
IAX2 or the like.

> 4.2.  Registration with Preference Order
> 
>    The next example demonstrates that the domain
>    3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is preferably contacted by IAX2,
>    secondly via SIP, and then H.323 for voice, and lastly by SMTP for
>    messaging.  Note that the tokens "iax", "sip", "h323", and "msg" are
>    Types registered (or to be registered) with IANA, and they have no
>    implicit connection with the protocols or URI schemes with the same
>    names.

Again I understand this is copied from RFC 3761, but see above for the
language. Also, I'm not sure what additional insight this example provides,
given that the general Preference mechanism is already explained in RFC 3761.
Anyway, the subject heading "Preference Order" is a bit misleading since
the two fields' names labeled "Preference" and "Order". If the example is going
to stay, say, e.g., "Variable Preferences".

Ceterum censeo, "msg" should go away.  For "sip" and "h323" informative
references to RFC 3764 and RFC 3762 could be added.

>    In each case, the next step in the resolution process is to use the
>    resolution mechanism appropriate to each of the protocols, (specified
>    by the URI schemes iax, sip, h323 and mailto).

NIT: s/iax/iax2/

> 4.4.  IPv6 Registration
> 
>    The following is an example of the use of the enumservice registered
>    by this document in a NAPTR resource record that contains a
>    destination 'context'.

Change introduction to emphasize v6. However, what's the particular point in
this example?  It appears not even the '[' and ']' characters on the regexp's
RHS would need special attention.

>    $ORIGIN 9.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
>    @ IN NAPTR 10 100 "u" "E2U+iax:iax2" "!^.*$!iax2:[2001:db8::1]:4569/
>    alice?friends!"

NIT: "." as the NAPTR's final element is missing

>    This contact information indicates that the domain
>    9.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. may be contacted by using the IAX2
>    protocol at IPv6 address [2001:db8::1], port 4569with the identifier
>    'alice' in the context (or user partition) 'friends'.

NIT: s/port 4569with the/port 4569 with the/

Maybe add a reference to RFC 3849 for the use of 2001:DB8::1.

> 5.  Security Considerations

This section lacks a reference to the basic ENUM security considerations.
The reference to RFC 2535 is outdated and needs to be replaced by one to the
DNSSECbis trilogy (see, e.g., RFC 4769). This section also should explain
what kind of privacy relevant information might be disclosed by publishing
NAPTR RRs with the IAX scheme.

-Peter

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum