Re: Review of draft-murchison-webdav-prefer-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Stewart,

Thanks for the review.  Comments inline.


On 12/21/2016 02:31 PM, Stewart Bryant wrote:
Reviewer: Stewart Bryant
Review result: Ready with Issues

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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.


Issues:

>From ID-nits:

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

Corrected in my working copy.


=======

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?

Removed in my working copy.


========



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./

Fixed both typos in my working copy.


=========


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.

<end>

I don't know if the editor would do this automatically when removing the Implementation Status section, but I will add an explicit instruction to do so in my working copy.

--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]