Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-mv1-msns-update-04: (with DISCUSS and COMMENT)

[David Noveck <[e-mail]>]

> those changes to the several section 15.1 changes.

Given that you haven't tried to read the document, I'm going to assume that
you are basing this on reading the table-of-contents, rather than on some
hard-to-understand psychic power.  While that would be an appropriate
superpower for an AD to have, it could freak people out, including me.

In any case, although the table-of-contents might lead one to think
othewise, I have already done some work to present changes in a
siginificant-sized chunk.    I have replaced all of 15.1.9 even though
there are wording changes in only some of the errors.   the way the table
of content is now done makes it appear that there are 5 individual sections
changed and there really aren't.

So i think I would deal with 15.1.9 by,

   - Adding some additional explanatory material explaining what is changed
within 15.1.9 and why.
   - Supressing the TOC entries for the 13.7.x sections.
   - Giving these sections ttles more like they had in rfc5661, leaving it
to the TOC entry for 13.7 to explain the replacement and numbering issues.

This leaves the update to NFS4ERR_MOVED in section 13.7 as the only other
update to section 15.1.   I really can't see putting in a complete
replacement for 15.1.1 given that this set of "general" errors is basically
a grab-bag of things that don't belong anywhere else.

So here is what I would propose for updates to error definitions:
   - create a new top-level section "updates to error definitions"
   - the first subsection within it would explain what is changed and why
and what is not changed.
   - the next subsection within would replace table 5 currently in 15.1.1
of rfc5661.   For each error ,it would give the appropriate reference,
whether in rfc5661 or the update.
   - The next section would be the replacement for 15.1.2.4
   - the last section would be the replacement for 15.1,9

On Tue, Mar 26, 2019 at 6:49 AM Magnus Westerlund <
[e-mail]> wrote:

> Hi David,
>
> I think there are some potential to this idea. However, as I have not
> attempted to read the document, I would request that you comment on what to
> do with the other sections, for example those changes to the several
> section 15.1 changes. Will it work out to have those changes to be included
> in a larger chunks also?
>
> Cheers
>
> Magnus
>
> On 2019-03-25 16:01, David Noveck wrote:
>
> > For this reason, I waited until I knew who the responsible AD for NFSv4
> would be - "hi, Magnus" -
> > and am now telling you folks know that my advice would be to produce a
> -bis version of NFSv4.1,
> > rather than trying to advance this draft.
>
> I don't think those are the only options even though i realize that there
> is no point in trying to advance the current draft    As I understand it,
> an rfc5661bis would require a lot of work, particularly in the security
> area and this would go beyond merely applying changes in the current draft
> to the existing rfc5661.
>
> I certainly could put the document into a bis-like form as you  suggest,
> but I can't see the IESG approving the resulting Security Considerations
> section as part of an rfc5661bis, given that it totally ignores the
> requirements of RFC 3552.   The IESG approved rfc5661 with a defective
> Security Considerations section but am doubtful about a possible repeat.
>
> Another option would be to put the document in a more bis-like form by
> producing a replacement for section 11 (instead of the current set of
> updates to section 11), without totally replacing all of rfc5661.   I still
> think that latter work is needed but producing a high-quality bis is a ways
> away.
>
> > I would suggest that you ask Benjamin whether he would be more
> comfortable continuing discussion > of his ballot position of this material
> in this form, or in -bis form
>
> Instead, I'll ask hIm what form he'd like to base the discussion on,
> whether in one of the forms suggested so far or in another one.
>
> On Mon, Mar 25, 2019 at 9:58 AM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> I'm putting this here, in Benjamin's Discuss ballot thread, but this is
>> my suggestion for going forward on this draft. Magnus will be your AD
>> starting Thursday morning, but if I might provide advice that I hope will
>> be helpful ...
>>
>> If you take a look at
>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-mv1-msns-update/ballot/,
>> you'll see that only 6 ADs cast ballot postions that are included in
>> considering whether a draft is to be approved during IESG Evaluation (Yes,
>> No Objection, or Discuss). That is barely half of the number of ballots
>> needed to approve this draft for publication.
>>
>> Abstains and No Position ballots may have have useful comments, but they
>> are ignored when counting ballots for approval.
>>
>> And my ballot expires on Wednesday, so clearing Benjamin's Discuss will
>> leave you only half the way to getting this draft approved.
>>
>> As the ballot positions arrived, I began considering alternative ways
>> forward. Some ADs Abstained, saying "I don't think it's reasonable for me
>> to review a 100-page patch to a 600-page RFC", and that's a conversation
>> that I was prepared to have with the IESG, but other ADs Abstained, saying
>> "I tried, but I couldn't do it". In one case, Suresh, who is an experienced
>> and conscientious reviewer, said he found instances where he couldn't
>> identify changes between OLD and NEW blocks of text. So I decided I was
>> willing to believe the "not reasonable to review" Abstain positions, as
>> well as the "I tried and couldn't do it" Abstain positions.
>>
>> For this reason, I waited until I knew who the responsible AD for NFSv4
>> would be - "hi, Magnus" - and am now telling you folks know that my advice
>> would be to produce a -bis version of NFSv4.1, rather than trying to
>> advance this draft.
>>
>> Magnus can accept my suggestion, or do something else, starting Thursday
>> morning (he and I both try to act in your best interests, and we might not
>> always agree on what that means). And you don't have to wait until Thursday
>> morning to start talking with Magnus, and with each other.
>>
>> I would suggest that you ask Benjamin whether he would be more
>> comfortable continuing discussion of his ballot position of this material
>> in this form, or in -bis form.
>>
>> And I am truly sorry that you experienced this Late Surprise as I was
>> stepping down.
>>
>> Best wishes with your work, and enjoy not having to include a last name
>> initial every time you mention "Spencer" in NFSv4 e-mail!
>>
>> Spencer (D)
>>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>