Subject: [nfsv4] Ben Campbell's No Objection on draft-ietf-nfsv4-mv0-trunking-update-03: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 09 Jan 2019 14:00:53 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-nfsv4-mv0-trunking-update-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-mv0-trunking-update/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

General: I don't expect a change in approach this late in the process, but I
think the approach of this update (replacing, inserting, and updating sections
in the updated RFC) is pretty unfriendly to the readers. This would make sense
if we actually rendered patched versions of updated RFCs, but we do not. This
leaves readers to flip back and forth to figure out the context of each update.

§1: s/"which enables"/"that enables"

§5.1 Does "updated introduction" to section 8.4 mean the same as "replaces
section 8.4, but not it's subsections?"

§5.2.2 (and other sections that add a new subsection to 8.4). Are these assumed
to be inserted in a particular location under 8.4? That is, can you state the
new section numbers? Otherwise the reader is left to guess where these would be
inserted.

§6: What is meant by "outside section 8"?

---

From: David Noveck <[email-masked]>
Date: Wed, 16 Jan 2019 12:38:34 -0500

> General: I don't expect a change in approach this late in the process,

Given that we have already gone through the working group process, making a
change at this point would occasion a significant delay.

> but I
> in the updated RFC) is pretty unfriendly to the readers.

On the othe hand, if we just produced an updated v4.0 section 8, the result
would be hard to review, in that you would force readers and reviewers to
diff old and new documents to see what has changed.

> This would make sense
> if we actually rendered patched versions of updated RFCs, but we do not.

We don't do so automatically or routinely but we do have the option to use
this document to produce an updated Section 8 for RFC7530.

> This

I hope this is not too onerous

> §1: s/"which enables"/"that enables"

OK.  Will be in -04.

> section 8.4, but not it's subsections?"

Yes. I think we can make this clearer in -04 by updating the first
sub-bullet of the second bullet in Section 5.  It how reads:

Section 5.2.1 replaces the introductory material within Section 8.4 of
[RFC7530].

This could be replaced by:

Section 5.2.1 replaces the introductory material within Section 8.4 of
[RFC7530]*, *i.e., the material within that Section 8.4, exclusive of
subsections.

> new section numbers? Otherwise the reader is left to guess where these
would be

Will address in -04 by updating the material in the sub-bullets of the
second bullet within Section 5, to read as follows:

   - Section 5.2.2 is to be added as a new sub-section of Section 8.4
before the updated Section 8.4.1 of [RFC7530].  In a consolidated
document, it would appear as Section 8.4.1.

   - Section 5.2.3 is to be added as an additional new sub-section of
Section 8.4 before the updated Section 8.4.1 of [RFC7530]. In a
consolidated document, it would appear as Section 8.4.2.

   - Section 5.2.4 replaces Section 8.4.1 of [RFC7530], entitled "File
System Replication". In a consolidated document, it would appear as
Section 8.4.3.

   -  Section 5.2.5 replaces Section 8.4.2 of [RFC7530], entitled
"File System Migration".  In a consolidated document, it would appear
as Section 8.4.4.

   - Section 5.2.6 is to be added as a new sub-section of Section 8.4
before Section 8.4.3 of [RFC7530].   In a consolidated document, it
would appear as Section 8.4.4 while the existing Section 8.3 would
appear as Section 8.4.6.

> §6: What is meant by "outside section 8"?

I assume you are referring to the title of Section 6.  It is referring to
changes necessary in parts of [RFC7530] ouside of Section 8 of that
document.  Not sure how to make this clearer*.  *Would appreciate any
suggestions you might have.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 16 Jan 2019 11:46:46 -0600

> On Jan 16, 2019, at 11:38 AM, David Noveck <[email-masked]> wrote:
> 
> I assume you are referring to the title of Section 6.  It is referring to changes necessary in parts of [RFC7530] ouside of Section 8 of that document.  Not sure how to make this clearer.  Would appreciate any suggestions you might have.
> 

Nevermind; I see I misread the first paragraph last time. There is no confusion in the text.

Thanks!

Ben.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 16 Jan 2019 11:49:15 -0600

> diff old and new documents to see what has changed.

I already have to diff old and new documents to see what has changed; with
a single updated section 8, I would be doing one diff operation instead of
four.  My diff tool is smart enough to not show me the sections that
haven't changed.

-Benjamin