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

[Spencer Dawkins at IETF <[e-mail]>]

Dear NFSv4,

After today's telechat, this draft is in AD follow-up, and the AD I'll be
handing off to at IETF 104 will be Magnus Westerlund.

My suggestion at this point is to wait until Magnus and I can discuss where
the IESG ended up, before the working group spends a lot of time trying to
figure out where the IESG ended up. We most often talk on Mondays, so look
for a note from us early next week.

And thanks for your patience.

Spencer

On Thu, Mar 7, 2019 at 6:33 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

> For the IESG ...
>
> It's also worth noting that multiple ADs said "not standing in the way of
> publication" in their Abstain ballots, but this is a standards-track draft
> that requires 10 Yes or No Objection ballots for approval.
>
> This is different from https://datatracker.ietf.org/doc/rfc8540/, which
> was also an Abstain magnet, but was Informational, requiring one Yes and no
> Discusses.
>
> So, if the next IESG intends to block standards-track documents of this
> style by collective action, it would be awesome to tell the community that,
> rather than reveal it to one working group at a time during IESG Evaluation.
>
> Spencer (D)
>
> On Thu, Mar 7, 2019, 05:24 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.
>>
>> 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.
>>
>> 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 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]> 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
>>> 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/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> 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.
>>>
>>>
>>>