- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 18 Nov 2013 22:09:21 +0100
- To: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-httpbis-method-registrations.all@tools.ietf.org" <draft-ietf-httpbis-method-registrations.all@tools.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 2013-11-18 22:02, Moriarty, Kathleen wrote: > Document: draft-ietf-httpbis-method-registrations-14 > Reviewer: Kathleen Moriarty > Review Date: November 18, 2013 > IETF LC End Date: > IESG Telechat date: 12/19 > > Summary: > Please check idnits, there are several issues to resolve. You can see the list from the data tracker version of the draft and just use the "Check nits" link. > https://datatracker.ietf.org/doc/draft-ietf-httpbis-method-registrations/?include_text=1 > Once the idnits are resolved satisfactorily, the document is ready for publication. > ... The issues reported are: > Checking nits according to http://www.ietf.org/id-info/checklist : > ---------------------------------------------------------------------------- > > == There are 2 instances of lines with non-RFC5735-compliant IPv4 addresses > in the document. If these are example addresses, they should be changed. No, there aren't. > Miscellaneous warnings: > ---------------------------------------------------------------------------- > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but may > have content which was first submitted before 10 November 2008. If you > have contacted all the original authors and they are all willing to grant > the BCP78 rights to the IETF Trust, then this is fine, and you can ignore > this comment. If not, you may need to add the pre-RFC5378 disclaimer. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) No, it doesn't (why does idnits think so?) > Checking references for intended status: Informational > ---------------------------------------------------------------------------- > > ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) RFC 2068 currently is the only document that defines LINK/UNLINK. The only thing we can do here is to declare all references in the registrations to be informative, but I really really don't see why it would matter here. Best regards, Julian
Received on Monday, 18 November 2013 21:09:53 UTC