Skip to main content

Last Call Review of draft-murchison-webdav-prefer-11

Request Review of draft-murchison-webdav-prefer
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-01-16
Requested 2016-12-19
Authors Kenneth Murchison
I-D last updated 2016-12-21
Completed reviews Genart Last Call review of -11 by Stewart Bryant (diff)
Secdir Last Call review of -14 by Hannes Tschofenig
Opsdir Last Call review of -13 by Al Morton (diff)
Genart Last Call review of -13 by Stewart Bryant (diff)
Assignment Reviewer Stewart Bryant
State Completed
Request Last Call review on draft-murchison-webdav-prefer by General Area Review Team (Gen-ART) Assigned
Reviewed revision 11 (document currently at 14)
Result Ready w/issues
Completed 2016-12-21
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-murchison-webdav-prefer-11
Reviewer: Stewart Bryant
Review Date: 21 Dec 2016
IETF LC End Date: 16 January 2017
IESG Telechat date: Unknown

Summary: Ready with issues

This is a well written document with some minor editorial issues that need
to be looked at before it is sent to the RFC Editor.


From ID-nits:

  -- The draft header indicates that this document updates RFC7240, but the
     abstract doesn't seem to mention this, which it should.


SB> The following suggests an open issue, which needs to be
SB> closed, or if closed already, the issue warning needs to be removed.

Open Issues

   o  Should we add any text regarding caching responses in Section 3?


3.1.  Successful State-Changing Requests

   representating the current state resource in the resulting 201
SB> representating - do you mean representing?


3.2.  Unsuccessful Conditional State-Changing Requests

   Frequently, clients using a state-changing method such as those
   listed above will make them conditional by including either an If-
   Match or If-None-Match [RFC7232] header field in the request.  This
   is done to prevent the client from accidentially overwriting a
SB> s/accidentially/accidentally./


9.3.  URIs

SB> I think that this section needs a "remove on publishing instruction"
SB> since I think you have given instructions to remove all the
SB> text that calls its entries.