Re: [nfsv4] Update on documents related to rfc5661bis effort.

[David Noveck <[e-mail]>]

As before. My remarks are made as editor of the documents in question and
as a wg member.

On Tue, Oct 11, 2022 at 9:29 AM Chuck Lever III <[e-mail]>
wrote:

>
>
> On Oct 9, 2022, at 10:06 AM, David Noveck <[e-mail]> wrote:
>
> As before, my remarks are made as the editor of
> draft-{ietf,dnoveck}-nfsv4-{internationaization,security,rfc5661bis,rfc5662bis}
> and a wg member and not as wg co-chair.
>
> On Sat, Oct 8, 2022 at 11:23 AM Chuck Lever III <[e-mail]>
> wrote:
>
>>
>> On Oct 8, 2022, at 5:54 AM, David Noveck <[e-mail]> wrote:
>>
>> On Wed, Oct 5, 2022, 10:44 AM Chuck Lever III <[e-mail]>
>> wrote:
>>
>>>
>>> Thanks for posting your plan!
>>>
>>> We already have three WG documents (not counting the RPC/RDMA v2
>>> documents that are to expire), at least two of which might require
>>> significant external review. In years past, we had a large body of folks
>>> who could help out. But these days, and considering the total number of
>>> pages involved, does the WG have enough review and document stewardship
>>> resources to proceed with all of these in parallel?
>>>
>>
>> Rfc5661bis has already been put off far too long, so I  really can't see
>> us doing these seriatim.  By the time we get to the bis, it will be
>> difficult to remember the issues, even though they will still need to be
>> dealt with. Sigh!
>>
>> Note that it is already almost 13 years since rfc5661 was published and
>> that it is clearly deficient in a  number of major areas.  That is why I
>> have devoted a lot of my time to this effort.  I had been assuming that the
>> working group in general was in a position to do its part.  If it isn't,
>> then the working group is in the position of doing extensions to v4.1
>> without a good description of v4.1, the previous approval of rfc5661 and
>> rfc8881 as a Proposed Standards notwithstanding.
>>
>>
>> You might misunderstand my concern.
>>
>
> I might or might not understand your concern.  You appear to want to give
> the three documents you refer to priority over my three documents related
> to the bis effort.  Since you do not provde any reason for this stance, it
> is quite hard to understand your position.
>
>
> I want to give the three existing WG documents (including i18n) a fair
> shot at available resources because they are already adopted. The other bis
> documents have not yet been adopted, and I fear that once they are, they
> will consume all remaining oxygen, leaving nothing left for completing
> documents that were adopted before them.
>

It is true that progress on pnfs-nvme and delstid has been slow but I feel
that is primarily because of the details of those specific efforts and not
a generalized shortage of resources that might be affected by work on the
bis documents going forward.

   -  pnfs-nvme has gone way beyond its original milestone and the adopted
   draft is an informational document while the milestone says "as a Proposed
   Standard".   There is no indication that this delay is due to  ongoing work
   on the bis documents which have been making progress independently.
   - delstid, while adopted, needs significant work to make it ready for
   IESG submission.   That is primarily because it was left expired without
   any work for several years.  The bis documents have had no no effect on
   that and ironically, the only serious review of the document was by me,
   despite the fact I was working on the bis.

 These document have had a fair shot of available resources and don't see
that changing.


> The minutiae around adoption of the i18n document were not especially
> transparent to the WG diaspora.
>

I'm not sure what you mean or even who the "WG diaspora" might be.   In any
case, document adoption was discussed on the mailing list, although I am
not aware of any "minutiae" being discussed in connection with wg adoption.

Even though I agree with the outcome, I think WG contributors need to have
> some oversight on those decisions simply because resources are quite scarce.
>

WG contributors were aware of this discussion and could have raised issues,
although none were.   In this sense, we were appropriately transparent
although we did not go beyond that  in trying to be "especially"
transparent.

Regarding the need for and potential value of more wg contributor
oversight, I think the choice to exercise such oversight is, appropriately,
made by those contributors and don't see how we could increase such
oversight.  After all, you can lead a horse to water but you can't make him
put on a bathing suit.

Regarding resources, I think complicating things by increasing the
complexity of the adoption call is more likely to result in increased
resource use rather than making additional resources available.


>
> In any case, I am troubled by the fact that in your previous email you
> were only objecting to adoption of security but now are objecting to all
> the documents except internationalization.
>
>
> I'm technically objecting to the security document, and you have stated
> that it doesn't make sense to consider adopting the remaining bis document
> without adopting the security document at the same time.
>

I don't think we can adopt all of these at the same time, although there is
a reason to prioritize internationalization and security.


> The security document appears to contain new protocol in it,
>

I don't know what you mean.   rfc5662bis does not change the OTW XDR and
any new protocol is discussed as possible future protocol extensions.
 Also, note that I originally added discussion of protocol security
extensions in response to your request.


> but because this effort is officially a bis effort, it should be
> constrained to documenting existing implementations
>

I don't agree.   In any case, this is kind of late to shift things to such
a restricted model.   It has always been clear that providing a threat
analysis  and adapting recommendations to reflect the need for encryption
and the security problems with AUTH_SYS were an integral part of this
work.   I don't see how we can do a security document for NFSv4 that does
not do that.   We also have to provide a security considerations section
with a real threat analysis.  I don't think we want one that just documents
the fact that nfsv4 security is a not in a good state, leading readers to
conclude it should not be used.

I'm requesting that the new protocol elements be moved out of this document
> before it is adopted.
>

Please be more specifIc about what you mean by "new protocol elements."  It
doesn't make sense for me to guess what might strike you that way.

>
>
> I surmise that, for some reason, you are reading far more into adoption of
> documents as  working group documents than is reasonable or was intended by
> the working group.
>
> Adoption as a wg document has never come with a guarantee that a document
> will move forward or that other documents will be deferred on that basis.
> When we agreed to wg adoption, I don't believe that wg members were
> agreeing to that.
>
>
> I wasn't clear before. My technical objection is as stated above. If you
> prefer, my concern about available review and stewardship resources can be
> considered outside of the adoption process.
>

That would be helpful.


>
>
> I'd like to clear the decks of the current set of adopted documents so
>> that we can guarantee the the already adopted documents move forward,
>>
>
> I don't think it is realistically possible to have such a guarantee and
> the wg has never provided one.  Let's look at those specific documents:
>
>    - draft-ietf-nfsv4-scsi-layout-nvme-00 is an eight-page draft for an
>    informational RFC.  Normally, I would think that it is reasonable to get
>    this in shape for submission in a limited time, although there is no way to
>    guarantee that.  However, in recent discussions, many people indicated a
>    desire for a standards-track document and I don't see how the wg can
>    guarantee its prompt completion, although there is a considerable interest
>    in getting that done.
>
> This applies no matter what restrictions are placed on the bis documents
> and restricting consideration of the bis documents will not make this
> happen any faster.
>
>
>    - draft-ietf-nfsv4-delstid-01 is a fifteen-page draft containing some
>    useful extensions.   There is need for further working group discussion of
>    those extensions although I fail to see how work on the bis document would
>    interfere with that.   No guarantee of progress is possible but the big
>    issue with this document, as indicated in my review, is that it includes
>    modifications of internal flexible-files data structures.  This document
>    may have to be split into two documents but we will have to hear from Tom,
>    before we can assess this document's future path.
>
> I don't see any reason to deal with this document on an expedited basis.
> It spent over two years as an expired document before being revived without
> change in June 2022.  It has had very little working group discussion.  The
> fact that I was working on the bis documents did not stop me from providing
> a serious review and I don't see how restricting bis work would help it to
> progress.
>
>
>    - draft-ietf-nfsv4-internationalization-00 is a sixty-page draft which
>    has needed more working group discussion for quite some time.  In any case,
>    I don't see how delaying the other bis-related documents would,
>    realistically, help this one progress.
>
>
>
>> and then afterwards ensure that the WG can proceed with the bis documents
>> in parallel.
>>
>
> I think they all of these should be done in parallel, including
> internationalization.  There is no point in delaying three of these while
> doing internationalization first.
>
>
>> Again, the WG has limited resources, and the bis documents comprise a
>> very high page count.
>>
>
> Yes. There is a lot to do.  In my view, this makes imposing an artificial
> delay inadvisable.
>
>
> I'm not certain why WG adoption is necessary in order to make progress.
>

It is not, but to make progress while the documents are still at the I-D
stage, wg members will have to agree to comment on the draft and help to
resolve the issues layed out in Appendix B of security.   So far that
hasn't happened and if it doesn't happen now there will not be much
progress. 😞

What delay do you think I'm imposing.
>

It is hard to say given that your position has shifted a number of times.
Clearly, in a decision framework which focuses on a generalized concern for
resources using Oxygen as a metaphor, there is reason to worry that your
desire to give these adopted documents resources simply because they were
adopted at one time, there is reason to worry that there might not be
oxygen available.

In any case, that might not apply any more and I hope we can work together
without arguing about available Oxygen all the time.  We can discuss
specific needs and in that context I will try to allocate my time to help
these adopted documents progress.

>
>