Thanks for the review.
This document, once approved, will update RFC 5661 and RFC 7862.
Yes, because it invalidates statements regarding versioning made in
those documents.
It seems to me that it should also update RFC 7530.
I don't see why. What is in RFC7530 regarding versioning still
remains valid once this document is approved.
It fulfills a promise made in Section 11 of RFC 7530.
Section 11 says that a document such as this would be desirable
but it doesn't make any sort of promise.
I think the question is what is the proper stanard for one RFC to
update another. I followed my own understanding. If that is wrong, I
will change it.
In Section 4.2, the last bullet in the section is unusual. That
bullet add a new context for the entire list of bullets.
It would be better
for the introduction to the list to provide the full context at the
beginning.
Actually, the last bullet in saying "these items" is not referring to
the items in all the bullets, but only those in the last bullet.
Still, this is confusing. The last bullet shoud be merged into the third.
Throughout the document, some bullet items end with periods and
others do not.
Use of the period is more common. Please pick one style and
use it throughout the document.
Will do.
The last sentence of the Introduction is not clear. After reading it
several times, I think you are trying to say:
... enabling interoperation to proceed just as if both
implementations supported only the parts of the protocol
that are being used.
I'm having trouble understanding that. I think the problem we
re both having is that, except for callbacks, the client doesn't
support features it uses them. I think we have a fundamentally
asymmetric situation and we keep tripping over ourselves as we
try to present it symmetrically.
How about:
As described in Section 4.4, two implementations can each choose a
subset of available extensions, with the client able to use the subset
of the extensions that it is prepared to use that the server supports
as well. Support for this common subset is not affected by the fact
that extensions outside this common subset may be supported by the
server or potentially used by the client.
In Section 2.3:
s/(not necessarily proper)/(not necessarily a proper subset)/
Will change.
In Section 4.4.2, in the last set of bullets, the first bullet begins
with "The minor version consists", but it should begin with "When the
minor version consists". The "so" following the comma should also be
removed.
Will fix. Your version is better.
In Section 6, 2nd paragraph, I found the text confusing because
"following" is used with two very different meanings in the same
sentence. I suggest: S/to following/to obeying/
I think I prefer S/the following rules/the rules listed below/.
On Tue, May 2, 2017 at 3:04 PM, Russ Housley <housley(_at_)vigilsec(_dot_)com>
wrote:
Reviewer: Russ Housley
Review result: Almost Ready
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 wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-nfsv4-versioning-09
Reviewer: Russ Housley
Review Date: 2017-05-02
IETF LC End Date: 2017-03-08
IESG Telechat date: Unknown
Summary: Almost Ready
Major Concerns:
This document, once approved, will update RFC 5661 and RFC 7862. It
seems to me that it should also update RFC 7530. It fulfills a
promise
made in Section 11 of RFC 7530.
Minor Concerns:
In Section 4.2, the last bullet in the section is unusual. That
bullet
add a new context for the entire list of bullets. It would be better
for the introduction to the list to provide the full context at the
beginning.
Nits:
Throughout the document, some bullet items end with periods and
others
do not. Use of the period is more common. Please pick one style and
use it throughout the document.
The last sentence of the Introduction is not clear. After reading it
several times, I think you are trying to say:
... enabling interoperation to proceed just as if both
implementations supported only the parts of the protocol
that are being used.
In Section 2.3:
s/(not necessarily proper)/(not necessarily a proper subset)/
In Section 4.4.2, in the last set of bullets, the first bullet begins
with "The minor version consists", but it should begin with "When the
minor version consists". The "so" following the comma should also be
removed.
In Section 6, 2nd paragraph, I found the text confusing because
"following" is used with two very different meanings in the same
sentence. I suggest: S/to following/to obeying/