Expert Review of: draft-ietf-enum-iax-10
"Livingood, Jason" <[email protected]> Mon, 28 Mar 2011 10:42:27 +0000
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <C9B63227.1FF6E%[email protected]> |
--===============1968521772== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_C9B632271FF6Ejasonlivingoodcablecomcastcom_" --_000_C9B632271FF6Ejasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While not required, since the draft was updated I have updated my expert re= view. There were no substantive changes and so this document is still fine,= from my standpoint. - Jason //Start of Expert Review Document// 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 Review Conducted By: Jason Livingood <[email protected]> -------------------------------------------- Expert's Note: This review was conducted in accordance with RFC 6117. Speci= fic guidance on the Expert Review process for Enumservices in RFC 6117 is i= n 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 a= pproved. -------------------------------------------- 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 (Secti= ons 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 Enumservic= e's class is properly defined as protocol-based, on the basis of RFC 5456 w= hich documents the IAX protocol. It also properly defines the type, correct= ly omits the subtype since this is not used, and properly defines the URI s= cheme, functional specification, security considerations, intended usage, E= numservice specification document, and requestors. -------------------------------------------- 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 sh= ould also determine whether the use case could be covered by an existing En= umservice. Review Finding: Complies, with use cases documented in section 3 of the reg= istration 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 ques= tion are followed. Review Finding: Complies. The registration qualifies as protocol-based, bas= ed 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 Reg= istration Document. Review Finding: Not applicable (see Review Step 5 above). -------------------------------------------- Review Step 7: Investigate whether the proposed Enumservice has any negativ= e side effects on existing clients and infrastructure, particularly the DNS= . Review Finding: Complies. No negative side effects on clients or infrastruc= ture 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 IET= F 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 is= sue of potential query loops. Review Finding: Complies. The document does raise the seemingly small pote= ntial for such loops in section 6 of the registration document, which shoul= d be sufficient warning for implementers to ensure that they properly imple= ment this Enumservice. Based on the registration document's examples and a = review of the entire document, no great risk of query loops can be envision= ed 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 poss= ible 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 sectio= n 5.2 of RFC 6117 clearly instructs authors of a registration document to p= rovide the registration in XML, this does not preclude authors from describ= ing the registration in plain text in order to enhance the readability of t= heir document. Examples of this can be found in section 2 of RFC 3762, sec= tion 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 RF= C 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 n= ecessary. -------------------------------------------- Appeals of the Expert Review Process: Appeals of Expert Review decisions fo= llow the process described in Section 7 of RFC 5226 and Section 6.5 of RFC = 2026. //End of Expert Review Document// On 3/24/11 8:58 AM, "Livingood, Jason" <[email protected]<m= ailto:[email protected]>> 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 <[email protected]<mai= lto:[email protected]>> -------------------------------------------- Expert's Note: This review was conducted in accordance with RFC 6117. Speci= fic guidance on the Expert Review process for Enumservices in RFC 6117 is i= n 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 a= pproved. -------------------------------------------- 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 (Secti= ons 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 Enumservic= e's class is properly defined as protocol-based, on the basis of RFC 5456 w= hich documents the IAX protocol. It also properly defines the type, correct= ly omits the subtype since this is not used, and properly defines the URI s= cheme, functional specification, security considerations, intended usage, a= nd Enumservice specification document. A requestor is defined, though for w= hatever reason only one of the two document authors are listed (Klaus Daril= ion 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 sh= ould also determine whether the use case could be covered by an existing En= umservice. Review Finding: Complies, with use cases documented in section 3 of the reg= istration 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 ques= tion are followed. Review Finding: Complies. The registration qualifies as protocol-based, bas= ed 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 Reg= istration Document. Review Finding: Not applicable (see Review Step 5 above). -------------------------------------------- Review Step 7: Investigate whether the proposed Enumservice has any negativ= e side effects on existing clients and infrastructure, particularly the DNS= . Review Finding: Complies. No negative side effects on clients or infrastruc= ture 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 IET= F 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 is= sue of potential query loops. Review Finding: Complies. The document does raise the seemingly small pote= ntial for such loops in section 6 of the registration document, which shoul= d be sufficient warning for implementers to ensure that they properly imple= ment this Enumservice. Based on the registration document's examples and a = review of the entire document, no great risk of query loops can be envision= ed 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 poss= ible 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 sectio= n 5.2 of RFC 6117 clearly instructs authors of a registration document to p= rovide the registration in XML, this does not preclude authors from describ= ing the registration in plain text in order to enhance the readability of t= heir document. Examples of this can be found in section 2 of RFC 3762, sec= tion 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 RF= C 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 n= ecessary. -------------------------------------------- Appeals of the Expert Review Process: Appeals of Expert Review decisions fo= llow the process described in Section 7 of RFC 5226 and Section 6.5 of RFC = 2026. //End of Expert Review Document// _______________________________________________ enum mailing list enum@ietf= .org<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/enum --_000_C9B632271FF6Ejasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <[email protected]> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-fami= ly: Calibri, sans-serif; "> <div> <div> <div>While not required, since the draft was updated I have updated my expe= rt review. There were no substantive changes and so this document is still = fine, from my standpoint.</div> <div><br> </div> <div>- Jason</div> <div><br> </div> <div> <div>//Start of Expert Review Document//</div> <div><br> </div> <div>Expert Review of: IANA Registration for Enumservice 'iax'</div> <div>Document Name: draft-ietf-enum-iax-10</div> <div>Document Location: http://tools.ietf.org/html/draft-ietf-enum-iax-10</= div> <div><br> </div> <div>Date Review Requested: 28 March 2011</div> <div>Date Review Completed: 28 March 2011</div> <div><br> </div> <div>Review Conducted By: Jason Livingood <[email protected]= .com></div> <div><br> </div> <div>--------------------------------------------</div> <div>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.</div> <div><br> </div> <div>+----------------------------+</div> <div>| Expert's Finding: APPROVED |</div> <div>+----------------------------+</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Expert's Detailed Review:</div> <div>I was appointed by the IESG to perform an expert review of this docume= nt in accordance with the Expert Review process described in RFC 6117. = ;</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 1: Verify conformance with the ENUM specification RFC 6116= .</div> <div><br> </div> <div>Review Finding: Complies.</div> <div><br> </div> <div>--------------------------------------------</div> <div>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 com= pleteness and whether all the aspects described in Sections 3 and 5 are suf= ficiently addressed.</div> <div><br> </div> <div>Review Finding: Complies with sections 3 and 5 of RFC 6117. This Enums= ervice's class is properly defined as protocol-based, on the basis of RFC 5= 456 which documents the IAX protocol. It also properly defines the type, co= rrectly omits the subtype since this is not used, and properly defines the URI scheme, functional specific= ation, security considerations, intended usage, Enumservice specification d= ocument, and requestors.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 3: If a use case is provided, the experts should verify wh= ether the proposed Enumservice does actually match the use case. The = experts should also determine whether the use case could be covered by an e= xisting Enumservice. </div> <div><br> </div> <div>Review Finding: Complies, with use cases documented in section 3 of th= e registration document.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 4: Verify that the Enumservice proposed cannot be confused= with identical (or similar) other Enumservices already registered.</div> <div><br> </div> <div>Review Finding: Complies.</div> <div><br> </div> <div>--------------------------------------------</div> <div>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.</div> <div><br> </div> <div>Review Finding: Complies. The registration qualifies as protocol-based= , based on RFC 5456 which documents the IAX protocol.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 6: In case the Enumservice is not classified, the experts = must verify whether a convincing reason for the deviation is provided in th= e Registration Document.</div> <div><br> </div> <div>Review Finding: Not applicable (see Review Step 5 above).</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 7: Investigate whether the proposed Enumservice has any ne= gative side effects on existing clients and infrastructure, particularly th= e DNS.</div> <div><br> </div> <div>Review Finding: Complies. No negative side effects on clients or infra= structure can be envisioned by the expert at this time and no one has raise= d any such concerns on the ENUM working group mailing list or other relevan= t IETF mailing lists of which the expert is aware.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 8: If the output of processing an Enumservice might be use= d for input to more ENUM processing (especially services returning 'tel' UR= Is), the experts should verify that the authors have adequately addressed t= he issue of potential query loops.</div> <div><br> </div> <div>Review Finding: Complies. The document does raise the seemingly = small potential for such loops in section 6 of the registration document, w= hich should be sufficient warning for implementers to ensure that they prop= erly implement this Enumservice. Based on the registration document's examples and a review of the entire documen= t, no great risk of query loops can be envisioned at this time. However, th= e 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. </div> <div><br> </div> <div>--------------------------------------------</div> <div>Additional Expert's Comments: Section 2 of this document correctly pro= vides the XML that IANA needs for updating their registry. However, while s= ection 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 pl= ain 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, s= ection 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 s= ection 2 of RFC 5333. This is a minor point and no update of the registrati= on document is necessary.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Appeals of the Expert Review Process: Appeals of Expert Review decisio= ns follow the process described in Section 7 of RFC 5226 and Section 6.5 of= RFC 2026.</div> <div><br> </div> <div>//End of Expert Review Document//</div> </div> <div><br> </div> <div> <div> <div><br> </div> </div> </div> </div> </div> <div><br> </div> <span id=3D"OLK_SRC_BODY_SECTION"> <div> <div>On 3/24/11 8:58 AM, "Livingood, Jason" <<a href=3D"mailto= :[email protected]">[email protected]</a>&g= t; wrote:</div> </div> <div><br> </div> <blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT:= #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"> <div> <div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: Calibri, s= ans-serif; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-br= eak: after-white-space; "> <div> <div> <div> <div>//Start of Expert Review Document//</div> <div><br> </div> <div>Expert Review of: IANA Registration for Enumservice 'iax'</div> <div>Document Name: draft-ietf-enum-iax-09</div> <div>Document Location: <a href=3D"http://tools.ietf.org/html/draft-ietf-en= um-iax-09"> http://tools.ietf.org/html/draft-ietf-enum-iax-09</a></div> <div><br> </div> <div>Date Review Requested: 22 March 2011</div> <div>Date Review Completed: 24 March 2011</div> <div><br> </div> <div>Review Conducted By: Jason Livingood <<a href=3D"mailto:jason_livin= [email protected]">[email protected]</a>></div> <div><br> </div> <div>--------------------------------------------</div> <div>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.</div> <div><br> </div> <div>+--------------------------------------+</div> <div>| Expert's Finding: APPROVED |</div> <div>+--------------------------------------+</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Expert's Detailed Review:</div> <div>I was appointed by the IESG to perform an expert review of this docume= nt in accordance with the Expert Review process described in RFC 6117. = ;</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 1: Verify conformance with the ENUM specification RFC 6116= .</div> <div><br> </div> <div>Review Finding: Complies.</div> <div><br> </div> <div>--------------------------------------------</div> <div>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 com= pleteness and whether all the aspects described in Sections 3 and 5 are suf= ficiently addressed.</div> <div><br> </div> <div>Review Finding: Complies with sections 3 and 5 of RFC 6117. This Enums= ervice's class is properly defined as protocol-based, on the basis of RFC 5= 456 which documents the IAX protocol. It also properly defines the type, co= rrectly omits the subtype since this is not used, and properly defines the URI scheme, functional specific= ation, security considerations, intended usage, and Enumservice specificati= on document. A requestor is defined, though for whatever reason only one of= the two document authors are listed (Klaus Darilion has been omitted). </div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 3: If a use case is provided, the experts should verify wh= ether the proposed Enumservice does actually match the use case. The = experts should also determine whether the use case could be covered by an e= xisting Enumservice. </div> <div><br> </div> <div>Review Finding: Complies, with use cases documented in section 3 of th= e registration document.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 4: Verify that the Enumservice proposed cannot be confused= with identical (or similar) other Enumservices already registered.</div> <div><br> </div> <div>Review Finding: Complies.</div> <div><br> </div> <div>--------------------------------------------</div> <div>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.</div> <div><br> </div> <div>Review Finding: Complies. The registration qualifies as protocol-based= , based on RFC 5456 which documents the IAX protocol.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 6: In case the Enumservice is not classified, the experts = must verify whether a convincing reason for the deviation is provided in th= e Registration Document.</div> <div><br> </div> <div>Review Finding: Not applicable (see Review Step 5 above).</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 7: Investigate whether the proposed Enumservice has any ne= gative side effects on existing clients and infrastructure, particularly th= e DNS.</div> <div><br> </div> <div>Review Finding: Complies. No negative side effects on clients or infra= structure can be envisioned by the expert at this time and no one has raise= d any such concerns on the ENUM working group mailing list or other relevan= t IETF mailing lists of which the expert is aware.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Review Step 8: If the output of processing an Enumservice might be use= d for input to more ENUM processing (especially services returning 'tel' UR= Is), the experts should verify that the authors have adequately addressed t= he issue of potential query loops.</div> <div><br> </div> <div>Review Finding: Complies. The document does raise the seemingly = small potential for such loops in section 6 of the registration document, w= hich should be sufficient warning for implementers to ensure that they prop= erly implement this Enumservice. Based on the registration document's examples and a review of the entire documen= t, no great risk of query loops can be envisioned at this time. However, th= e 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. </div> <div><br> </div> <div>--------------------------------------------</div> <div>Additional Expert's Comments: Section 2 of this document correctly pro= vides the XML that IANA needs for updating their registry. However, while s= ection 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 pl= ain 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, s= ection 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 s= ection 2 of RFC 5333. This is a minor point and no update of the registrati= on document is necessary.</div> <div><br> </div> <div>--------------------------------------------</div> <div>Appeals of the Expert Review Process: Appeals of Expert Review decisio= ns follow the process described in Section 7 of RFC 5226 and Section 6.5 of= RFC 2026.</div> <div><br> </div> <div>//End of Expert Review Document//</div> </div> </div> </div> <div><br> </div> </div> </div> _______________________________________________ enum mailing list <a href= =3D"mailto:[email protected]"> [email protected]</a> <a href=3D"https://www.ietf.org/mailman/listinfo/enum">ht= tps://www.ietf.org/mailman/listinfo/enum</a> </blockquote> </span> </body> </html> --_000_C9B632271FF6Ejasonlivingoodcablecomcastcom_-- --===============1968521772== 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 --===============1968521772==--