Re: Expert Review of: draft-ietf-enum-iax-09

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

On 3/24/11 10:45 AM, "Bernie Hoeneisen" <bernie <at> ietf.hoeneisen.ch> wrote:

>Hi,
>
>Please find the output of the expert review below.
>
>
>In addition, I do have some editorial feedback:
>
> <at> 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:
>
>> //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 <jason_livingood <at> cable.comcast.com>
>> 
>> --------------------------------------------
>> 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//
>> 
>>