[Oops, resending with the updated address for Laura Liess. Sorry for the repeat] I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ecrit-location-hiding-req-02 Reviewer: Ben Campbell Review Date: 16 Feb 2010 IESG Telechat date: 18 Feb 2010 Summary: This draft is really close to ready for publication as an informational RFC. I have one unaddressed editorial comment, which on reflection I am promoting to a minor issue, as well as a few more editorial comments that should probably not block publication. Major issues: Minor issues: -- section 3.3, first bullet: I'm still a little confused by seeing a normative MUST in a section entitled "Desirable Properties". If it's really a MUST, then perhaps it should be promoted to a bona-fide requirement? Otherwise, perhaps it should be a SHOULD? Nits/editorial comments: -- Req-10: The solution MUST allow the end host to determine PSAP/ESRP URLs prior to the call, for all emergency services. Who is the "end host"? -- section 3.3, third bullet: s/"...break by the presence..."/"...break in the presence..." [or "...be broken by the presence..."] -- idnits has some new things to say. (I suspect the boilerplate complaints have to do with the paragraphs splitting across page breaks.) > tmp/draft-ietf-ecrit-location-hiding-req-02.txt: > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > http://trustee.ietf.org/license-info): > ---------------------------------------------------------------------------- > > ** The document seems to lack a License Notice according IETF Trust > Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 > Section 6.b -- however, there's a paragraph with a matching beginning. > Boilerplate error? > > (You're using the IETF Trust Provisions' Section 6.b License Notice from > 12 Feb 2009 rather than one of the newer Notices. See > http://trustee.ietf.org/license-info/.) > > > Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: > ---------------------------------------------------------------------------- > > No issues found here. > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > ---------------------------------------------------------------------------- > > No issues found here. > > Miscellaneous warnings: > ---------------------------------------------------------------------------- > > == The copyright year in the IETF Trust and authors Copyright Line does not > match the current year > > == The document seems to lack the recommended RFC 2119 boilerplate, even if > it appears to use RFC 2119 keywords -- however, there's a paragraph with > a matching beginning. Boilerplate error? > > (The document does seem to have the reference to RFC 2119 which the > ID-Checklist requires). > == The document seems to lack a disclaimer for pre-RFC5378 work, but was > first submitted before 10 November 2008. Should you add the disclaimer? > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.). > > > Checking references for intended status: Informational > ---------------------------------------------------------------------------- > > == Outdated reference: A later version (-10) exists of > draft-ietf-geopriv-l7-lcp-ps-09 > > == Outdated reference: A later version (-10) exists of > draft-ietf-ecrit-framework-09 > > == Outdated reference: A later version (-09) exists of > draft-ietf-geopriv-lbyr-requirements-07 > > == Outdated reference: A later version (-16) exists of > draft-ietf-geopriv-http-location-delivery-15 > > > Summary: 1 error (**), 7 warnings (==), 0 comments (--). > > Run idnits with the --verbose option for more detailed information about > the items above. > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf