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

From: "Richard Shockey" <[email-masked]>
Date: Tue, 1 May 2007 11:24:23 -0400

Speak now or ..you know..

Title		: IANA Registration for IAX Enumservice
	Author(s)	: E. Guy
	Filename	: draft-ietf-enum-iax-02.txt
	Pages		: 14
	Date		: 2007-4-18

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>

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

---

From: Peter Koch <[email-masked]>
Date: Wed, 2 May 2007 09:15:07 +0200

> 	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

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 2 May 2007 10:31:01 -0400

First thanks for taking the time to review this .. 2 comments in line.

-----Original Message-----
From: Peter Koch [mailto:[email-masked]] 
Sent: Wednesday, May 02, 2007 3:15 AM
To: IETF ENUM WG
Subject: Re: [Enum] Are we ready to go to WGLC on this?

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.

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.

RS> it has to go in as a individual submission and yes that is the obvious
normative reference.

RS> Proposed ..all registration documents are Proposed

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

NIT: s/iax/iax2/

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.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Wed, 2 May 2007 17:51:16 +0200

Thanks, Richard, for responding to my questions.

> RS> Proposed ..all registration documents are Proposed

I understand that this happened in the past, but now that we're considering
an easier method for registering ENUM services, there might no longer be
an immediate need for Standards Track. By the way, I just overlooked that
the draft's header says "Intended status: Informational".
In this particular case, there's an additional argument for "Informational":
The base IAX spec <draft-guy-iax-03.txt> appears as a normative reference
and the draft does not give the IETF change control (see boilerplate):

   This document may not be modified, and derivative works of it may not
   be created.

So, my understanding is it is unlikely this will be published as anything
else but Informational. As a corollary, the ENUM services document can
only be Informational as well. Whether or not an ENUM service is "derivative
works" is for somebody else to decide.

-Peter

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 2 May 2007 12:18:01 -0400

Again Peter ..many thanks for pointing out the status issue out ..you are
totally correct.

-----Original Message-----
From: Peter Koch [mailto:[email-masked]] 
Sent: Wednesday, May 02, 2007 11:51 AM
To: Richard Shockey
Cc: 'IETF ENUM WG'; 'Ed Guy'
Subject: Re: [Enum] Are we ready to go to WGLC on this?

-Peter

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 2 May 2007 14:22:09 -0400

But on second thought .. H.323 IETF has no change control over that either.
That does establish some precedent.

ON the issue of derivative works from a Informational standard .. I think
I'll submit it as Proposed Standard and let the IESG sort out the issue,
unless there is strong objection

-----Original Message-----
From: Peter Koch [mailto:[email-masked]] 
Sent: Wednesday, May 02, 2007 11:51 AM
To: Richard Shockey
Cc: 'IETF ENUM WG'; 'Ed Guy'
Subject: Re: [Enum] Are we ready to go to WGLC on this?

-Peter

---

From: Peter Koch <[email-masked]>
Date: Wed, 2 May 2007 20:41:11 +0200

Hi Richard,

> That does establish some precedent.

sorry, that was misleading. My issue was a downref one, i.e., a spec that
is available as Informational RFC only (concluded from the current boilerplate)
would not allow the referencing document to advance past that. H.323 is
available as an ITU-T document and there's some formal liaison between
the IETF and ITU-T about references to documents.

> unless there is strong objection

Not here. And I agree some process advice might be helpful.

-Peter