Re: [nfsv4] Ben Campbell's Abstain on draft-ietf-nfsv4-mv1-msns-update-04: (with COMMENT)

[Ben Campbell <[e-mail]>]

Hi, thanks for the response. A few comments inline:

Thanks!

Ben.

> On Mar 7, 2019, at 5:23 AM, David Noveck <[e-mail]> wrote:
> 
> It couldn't be quite that simple since a bis document would need to address a number of other things:
> 
>    - Replace the internationalization chapter so it coresponds to that of RFC7530 and existing NFSv4.1 implementations.   The one in rfc5661 is flat-out wrong and, as with the one in rfc3530, people never really read it.
>     - There are a significant number of erratta accumulated for RFC5661 which would have to be addressed in a bis document.
> 
> In any case, I and many people within the group felt that, having lived through the rfc3530bis experience, that "simple" was unlikely to be an appropriate adjective to apply to the publication of a bis document for a large document such as RFC5661.

On today’s telechat, multiple people suggested they could probably accept a bis draft that did not solve all known (or even all serious) problems, as long as there was text point that the material issues that remained unfixed. I think that was said in the abstract, so I can’t speak for how it would impact this particular document.

> 
> Another option, short of a full bis, that I considered was simply to apply the changes to Section eleven in
> the document under review and include that full replacement section instead of the detailed changes that are currently there.   The reason I didn't take that approach is that, while that document might be much easier for a NFSv4.1 neophyte to read, it would more difficult more those in the working group (many of whom are implementers) to assimilate and review.  People would be left to diff the two section 11's and figure out what changed.

While I would have to see text to really assess things, I think this would be better than the current state. At least, it would be much more likely that two different people would perceive the updated draft the same way.

As far as diffs are concerned, that’s commonly the case for any bis draft as well. (I regularly request people avoid non-essential changes to help keep the diffs useful.) The better bis drafts include sections that describe the material changes.

> 
> I understand the issues that this approach raises for an important class of readers but I feel that, practically speaking, the majority who would have to act on this work are implementers who are already familiar with the existing Section 11, with a large fraction of those involved in the work of the working group.   Clearly the needs of others, with less familiarity with NFSv4.1 would have to be met by a bis document, which I have started on.

I think it’s important that open standards be accessible by people new to a protocol. I am skeptical that people who are already familiar with the protocol would have that much trouble figuring out the changes, especially if the bis draft describes the material changes.

> 
> I know many people will not agree but I feel the most expedient path forward is to address the technical and clarity issues that have been raised and publish the document in essentially its current form, knowing that the appropriate audience is not going to include NFSv4.1 neophytes.   Some implementation work has started and publication would allow other implementation work to proceed.   Then, when this work is included in a bis document, we would have the benefit of that additional implementation work and any possible  need for clarification or corrections that the implementation work exposed.
> 
> On Tue, Mar 5, 2019 at 6:33 PM Datatracker on behalf of Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-nfsv4-mv1-msns-update-04: Abstain
> 
> 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 <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-mv1-msns-update/ <https://datatracker.ietf.org/doc/draft-ietf-nfsv4-mv1-msns-update/>
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for the huge amount of work in this draft, but I cannot recommend
> publishing it in it's current form. I am balloting "ABSTAIN" rather than
> "DISCUSS", so that I do not get in the way of publication if the rest of the
> IESG thinks it's fine as is. I apologize for not doing a more technical review,
> but I think the structural issues need to be addressed first.
> 
> I once spent several weeks over a summer in high school applying page updates
> to a shelf full of US Tax Code binders in a CPAs office. The IRS, (or whoever
> published the code) would send out boxes of new page-sets, each labeled for
> which original pages it would replace.  When we were done in the CPA office, we
> had a coherent set of documents, at least to the degree you can apply words
> like "coherent" to tax codes.
> 
> This draft does something akin to that, except that we don't end up with a
> coherent document as a result. If the RFC Editor applied patches from RFCs that
>  "UPDATE" other RFCs to render final text,  things would be different. But that
> doesn't happen with RFCs.  That being said, I don't object to RFC updates in
> general, as long as those updates are simple and fairly self-contained. But
> this draft is over 100 pages of intricate updates, reorganizations, and
> explanatory text. This will make life very hard for readers that were not
> involved in the standards process.
> 
> I think the right approach for an update of this complexity is to just do a
> 5661bis draft, and use this one as an input to that. Such a bis draft could be
> something as simple as applying the changes in this draft (and maybe
> trunking-update)  and publishing the result.
> 
>