Russ, thanks for your review! I think the changes David proposed in response look good. I agree with his reasoning about there not being a need for this document to formally update RFC 7530. I have ballotted No Objection.
Alissa > On May 2, 2017, at 7:48 PM, David Noveck <[email protected]> wrote: > > 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 <[email protected] > <mailto:[email protected]>> 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 > <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/ > > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
