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

Bernie Hoeneisen <[email protected]> Thu, 24 Mar 2011 15:45:03 +0100 (CET)
Newsgroups gmane.ietf.enum
Message-ID <[email protected]>
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--37663318-2001825474-1300977903=:10357
Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

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=
=20
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=3D"rfc" data=3D"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=20
publication?


cheers,
  Bernie

--

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


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

> //Start of Expert Review Document//
>=20
> 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
>=20
> Date Review Requested: 22 March 2011
> Date Review Completed: 24 March 2011
>=20
> Review Conducted By: Jason Livingood <[email protected]>
>=20
> --------------------------------------------
> Expert's Note: This review was conducted in accordance with RFC 6117. Spe=
cific
> guidance on the Expert Review process for Enumservices in RFC 6117 is in
> Sections 6.5, and 7.
>=20
> +--------------------------------------+
> | Expert's Finding: APPROVED |
> +--------------------------------------+
>=20
> Expert's Comments: After conducing my review, it is my expert opinion tha=
t the
> publication of this registration document for an Enumservice 'iax' is app=
roved.
>=20
> --------------------------------------------
> 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.=A0
>=20
> --------------------------------------------
> Review Step 1: Verify conformance with the ENUM specification RFC 6116.
>=20
> Review Finding: Complies.
>=20
> --------------------------------------------
> Review Step 2: Verify that the requirements set out in this document (Sec=
tions 3
> and 5 of RFC 6117) are met. =A0This includes checking for completeness an=
d whether
> all the aspects described in Sections 3 and 5 are sufficiently addressed.
>=20
> Review Finding: Complies with sections 3 and 5 of RFC 6117. This Enumserv=
ice's
> class is properly defined as protocol-based, on the basis of RFC 5456 whi=
ch
> 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 wh=
atever
> reason only one of the two document authors are listed (Klaus Darilion ha=
s been
> omitted).=A0
>=20
> --------------------------------------------
> Review Step 3: If a use case is provided, the experts should verify wheth=
er the
> proposed Enumservice does actually match the use case. =A0The experts sho=
uld also
> determine whether the use case could be covered by an existing Enumservic=
e.=A0
>=20
> Review Finding: Complies, with use cases documented in section 3 of the
> registration document.
>=20
> --------------------------------------------
> Review Step 4: Verify that the Enumservice proposed cannot be confused wi=
th
> identical (or similar) other Enumservices already registered.
>=20
> Review Finding: Complies.
>=20
> --------------------------------------------
> 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 questio=
n are
> followed.
>=20
> Review Finding: Complies. The registration qualifies as protocol-based, b=
ased on
> RFC 5456 which documents the IAX protocol.
>=20
> --------------------------------------------
> Review Step 6: In case the Enumservice is not classified, the experts mus=
t
> verify whether a convincing reason for the deviation is provided in the
> Registration Document.
>=20
> Review Finding: Not applicable (see Review Step 5 above).
>=20
> --------------------------------------------
> Review Step 7: Investigate whether the proposed Enumservice has any negat=
ive
> side effects on existing clients and infrastructure, particularly the DNS=
=2E
>=20
> Review Finding: Complies. No negative side effects on clients or infrastr=
ucture
> can be envisioned by the expert at this time and no one has raised any su=
ch
> concerns on the ENUM working group mailing list or other relevant IETF ma=
iling
> lists of which the expert is aware.
>=20
> --------------------------------------------
> Review Step 8: If the output of processing an Enumservice might be used f=
or
> input to more ENUM processing (especially services returning 'tel' URIs),=
 the
> experts should verify that the authors have adequately addressed the issu=
e of
> potential query loops.
>=20
> Review Finding: =A0Complies. 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 implemen=
t this
> Enumservice. Based on the registration document's examples and a review o=
f the
> entire document, no great risk of query loops can be envisioned at this t=
ime.
> However, the expert reviewer, while an ENUM expert, is not an IAX protoco=
l
> expert and is therefore not well versed in all of the possible configurat=
ions
> and common configuration errors of IAX-based services.=A0
>=20
> --------------------------------------------
> Additional Expert's Comments: Section 2 of this document correctly provid=
es the
> XML that IANA needs for updating their registry. However, while section 5=
=2E2 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 =A0section 2 of RFC 3762, sect=
ion 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, sect=
ion 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.
>=20
> --------------------------------------------
> 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 202=
6.
>=20
> //End of Expert Review Document//
>=20
>=20
>
--37663318-2001825474-1300977903=:10357
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
enum mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/enum

--37663318-2001825474-1300977903=:10357--