Subject: [Enum] Expert Review of: draft-ietf-enum-iax-09

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 24 Mar 2011 12:58:53 +0000

//Start of Expert Review Document//

Expert Review of: IANA Registration for Enumservice 'iax'
Document Name: draft-ietf-enum-iax-09
Document Location: http://tools.ietf.org/html/draft-ietf-enum-iax-09

Date Review Requested: 22 March 2011
Date Review Completed: 24 March 2011

Review Conducted By: Jason Livingood <[email-masked]<mailto:[email-masked]>>

--------------------------------------------
Expert's Note: This review was conducted in accordance with RFC 6117. Specific guidance on the Expert Review process for Enumservices in RFC 6117 is in Sections 6.5, and 7.

+--------------------------------------+
| Expert's Finding: APPROVED |
+--------------------------------------+

Expert's Comments: After conducing my review, it is my expert opinion that the publication of this registration document for an Enumservice 'iax' is approved.

--------------------------------------------
Expert's Detailed Review:
I was appointed by the IESG to perform an expert review of this document in accordance with the Expert Review process described in RFC 6117.

--------------------------------------------
Review Step 1: Verify conformance with the ENUM specification RFC 6116.

Review Finding: Complies.

--------------------------------------------
Review Step 2: Verify that the requirements set out in this document (Sections 3 and 5 of RFC 6117) are met.  This includes checking for completeness and whether all the aspects described in Sections 3 and 5 are sufficiently addressed.

Review Finding: Complies with sections 3 and 5 of RFC 6117. This Enumservice's class is properly defined as protocol-based, on the basis of RFC 5456 which documents the IAX protocol. It also properly defines the type, correctly omits the subtype since this is not used, and properly defines the URI scheme, functional specification, security considerations, intended usage, and Enumservice specification document. A requestor is defined, though for whatever reason only one of the two document authors are listed (Klaus Darilion has been omitted).

--------------------------------------------
Review Step 3: If a use case is provided, the experts should verify whether the proposed Enumservice does actually match the use case.  The experts should also determine whether the use case could be covered by an existing Enumservice.

Review Finding: Complies, with use cases documented in section 3 of the registration document.

--------------------------------------------
Review Step 4: Verify that the Enumservice proposed cannot be confused with identical (or similar) other Enumservices already registered.

Review Finding: Complies.

--------------------------------------------
Review Step 5: If the Enumservice is classified according to Section 4.2 of RFC 6117, the experts must verify that the principles of the Class in question are followed.

Review Finding: Complies. The registration qualifies as protocol-based, based on RFC 5456 which documents the IAX protocol.

--------------------------------------------
Review Step 6: In case the Enumservice is not classified, the experts must verify whether a convincing reason for the deviation is provided in the Registration Document.

Review Finding: Not applicable (see Review Step 5 above).

--------------------------------------------
Review Step 7: Investigate whether the proposed Enumservice has any negative side effects on existing clients and infrastructure, particularly the DNS.

Review Finding: Complies. No negative side effects on clients or infrastructure can be envisioned by the expert at this time and no one has raised any such concerns on the ENUM working group mailing list or other relevant IETF mailing lists of which the expert is aware.

--------------------------------------------
Review Step 8: If the output of processing an Enumservice might be used for input to more ENUM processing (especially services returning 'tel' URIs), the experts should verify that the authors have adequately addressed the issue of potential query loops.

Review Finding:  Complies. The document does raise the seemingly small potential for such loops in section 6 of the registration document, which should be sufficient warning for implementers to ensure that they properly implement this Enumservice. Based on the registration document's examples and a review of the entire document, no great risk of query loops can be envisioned at this time. However, the expert reviewer, while an ENUM expert, is not an IAX protocol expert and is therefore not well versed in all of the possible configurations and common configuration errors of IAX-based services.

--------------------------------------------
Additional Expert's Comments: Section 2 of this document correctly provides the XML that IANA needs for updating their registry. However, while section 5.2 of RFC 6117 clearly instructs authors of a registration document to provide the registration in XML, this does not preclude authors from describing the registration in plain text in order to enhance the readability of their document. Examples of this can be found in  section 2 of RFC 3762, section 2 of RFC 3764, section 3 of RFC 4002, section 3 of RFC 4355, section 3 of RFC 4415, section 3 of RFC 4769, section 3 of RFC 4969, section 3 of RFC 4979, section 2 of RFC 5028, section 4 of RFC 5278, and section 2 of RFC 5333. This is a minor point and no update of the registration document is necessary.

--------------------------------------------
Appeals of the Expert Review Process: Appeals of Expert Review decisions follow the process described in Section 7 of RFC 5226 and Section 6.5 of RFC 2026.

//End of Expert Review Document//

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 24 Mar 2011 15:45:03 +0100 (CET)

Hi,

Please find the output of the expert review below.

In addition, I do have some editorial feedback:

@Jason: Please shout, in case you believe these changes are more than just 
editorial.

* Abstract:

   Replace XXXX by 6117
   Delete the Note for RFC Editor in the beginning

* IANA Registration section, <security>:

   In the <security> elements, there is a reference to
   "general considerations" of Section 4 mentioned. However, there is no
   "general considerations" mentioned in Section 4 (anymore?).

   You might want to simplify this by:
      <security>
        See <xref type="rfc" data="rfcTHIS" />, Section 4.
      </security>

* IANA Registration section, <requesters>

   You might want to consider adding yourself as a requester.
   (It's up to you, of course.)

* Security Considerations section

   RFC 6117 has the following requirement:

    "Enumservice Specifications do not need to and SHOULD NOT repeat
    considerations already listed in that document. However, Enumservice
    Specifications SHOULD include a reference to that section."

    Please add a reference to RFC 6116, Section 7 (at the end of
    the Security Consideration section) such as:

   "For Security considerations that apply to all Enumservices,
    please refer to RFC 6116, Section 7"

    (or alike).

* Replace any instance of I-D.ietf-enum-3761bis by RFC6116

* Replace any instance of draft-ietf-enum-enumservices-guide
   by RFC 6117

Can you do the revision during this week, so that I can request 
publication?

cheers,
  Bernie

--

http://ucom.ch/
Tech Consulting for Internet Standardization

On Thu, 24 Mar 2011, Livingood, Jason wrote:

> Review Conducted By: Jason Livingood <[email-masked]>
> 
> Expert's Note: This review was conducted in accordance with RFC 6117. Specific
> guidance on the Expert Review process for Enumservices in RFC 6117 is in
> Sections 6.5, and 7.
> 
> Expert's Comments: After conducing my review, it is my expert opinion that the
> publication of this registration document for an Enumservice 'iax' is approved.
> 
> I was appointed by the IESG to perform an expert review of this document in
> accordance with the Expert Review process described in RFC 6117. 
> 
> Review Step 2: Verify that the requirements set out in this document (Sections 3
> and 5 of RFC 6117) are met.  This includes checking for completeness and whether
> all the aspects described in Sections 3 and 5 are sufficiently addressed.
> 
> Review Finding: Complies with sections 3 and 5 of RFC 6117. This Enumservice's
> class is properly defined as protocol-based, on the basis of RFC 5456 which
> documents the IAX protocol. It also properly defines the type, correctly omits
> the subtype since this is not used, and properly defines the URI scheme,
> functional specification, security considerations, intended usage, and
> Enumservice specification document. A requestor is defined, though for whatever
> reason only one of the two document authors are listed (Klaus Darilion has been
> omitted). 
> 
> Review Step 3: If a use case is provided, the experts should verify whether the
> proposed Enumservice does actually match the use case.  The experts should also
> determine whether the use case could be covered by an existing Enumservice. 
> 
> Review Step 4: Verify that the Enumservice proposed cannot be confused with
> identical (or similar) other Enumservices already registered.
> 
> Review Step 5: If the Enumservice is classified according to Section 4.2 of RFC
> 6117, the experts must verify that the principles of the Class in question are
> followed.
> 
> Review Finding: Complies. The registration qualifies as protocol-based, based on
> RFC 5456 which documents the IAX protocol.
> 
> Review Step 6: In case the Enumservice is not classified, the experts must
> verify whether a convincing reason for the deviation is provided in the
> Registration Document.
> 
> Review Step 7: Investigate whether the proposed Enumservice has any negative
> side effects on existing clients and infrastructure, particularly the DNS.
> 
> Review Finding: Complies. No negative side effects on clients or infrastructure
> can be envisioned by the expert at this time and no one has raised any such
> concerns on the ENUM working group mailing list or other relevant IETF mailing
> lists of which the expert is aware.
> 
> Review Step 8: If the output of processing an Enumservice might be used for
> input to more ENUM processing (especially services returning 'tel' URIs), the
> experts should verify that the authors have adequately addressed the issue of
> potential query loops.
> 
> Review Finding:  Complies. The document does raise the seemingly small potential
> for such loops in section 6 of the registration document, which should be
> sufficient warning for implementers to ensure that they properly implement this
> Enumservice. Based on the registration document's examples and a review of the
> entire document, no great risk of query loops can be envisioned at this time.
> However, the expert reviewer, while an ENUM expert, is not an IAX protocol
> expert and is therefore not well versed in all of the possible configurations
> and common configuration errors of IAX-based services. 
> 
> Additional Expert's Comments: Section 2 of this document correctly provides the
> XML that IANA needs for updating their registry. However, while section 5.2 of
> RFC 6117 clearly instructs authors of a registration document to provide the
> registration in XML, this does not preclude authors from describing the
> registration in plain text in order to enhance the readability of their
> document. Examples of this can be found in  section 2 of RFC 3762, section 2 of
> RFC 3764, section 3 of RFC 4002, section 3 of RFC 4355, section 3 of RFC 4415,
> section 3 of RFC 4769, section 3 of RFC 4969, section 3 of RFC 4979, section 2
> of RFC 5028, section 4 of RFC 5278, and section 2 of RFC 5333. This is a minor
> point and no update of the registration document is necessary.
> 
> Appeals of the Expert Review Process: Appeals of Expert Review decisions follow
> the process described in Section 7 of RFC 5226 and Section 6.5 of RFC 2026.
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 24 Mar 2011 20:30:40 +0000

These changes all seem minor and sensible to me.

Please also note my one review comment: A requestor is defined, though for
whatever reason only one of the two document authors are listed (Klaus
Darilion has been omitted).

Jason

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 25 Mar 2011 09:53:53 +0100 (CET)

Hi Klaus

On Thu, 24 Mar 2011, Klaus Darilion wrote:

> Done. XML and txt is attached (I named it version -10). What next?

Thanks a lot for updating this so fast! From my point of view (as a 
document shepherd) this document is ready for publication, unless Jason 
(as the designated expert for the IAX Eumservice) objects to the changes 
you just made.

Please submit -10 as soon as possible. Unfortunately, we'll have to wait 
until Monday, when I-D submissions are possible again (block-out period). 
Please also submit the .xml version with the I-D submission tool, so that 
the RFC Editor can fetch it directly from the tools.

I will request publication as soon as -10 is online.

cheers,
  Bernie

PS: Looks like the ENUM WG will be dissolved next Monday, timely with the 
"beer&dinner" when we are celebrating it.

--

http://ucom.ch/

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 28 Mar 2011 10:42:27 +0000

While not required, since the draft was updated I have updated my expert review. There were no substantive changes and so this document is still fine, from my standpoint.

- Jason

Expert Review of: IANA Registration for Enumservice 'iax'
Document Name: draft-ietf-enum-iax-10
Document Location: http://tools.ietf.org/html/draft-ietf-enum-iax-10

Date Review Requested: 28 March 2011
Date Review Completed: 28 March 2011

+----------------------------+
| Expert's Finding: APPROVED |
+----------------------------+

Review Finding: Complies with sections 3 and 5 of RFC 6117. This Enumservice's class is properly defined as protocol-based, on the basis of RFC 5456 which documents the IAX protocol. It also properly defines the type, correctly omits the subtype since this is not used, and properly defines the URI scheme, functional specification, security considerations, intended usage, Enumservice specification document, and requestors.

On 3/24/11 8:58 AM, "Livingood, Jason" <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________ enum mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/enum