[nfsv4] Re: Draft adoption call for WG - draft-dnoveck-nfsv4-rfc5662bis-03

[Tom Haynes <[e-mail]>]

I didn't know that RFC88881 was not a real bis effort, thanks for
explaining that.

But you can't lay my suggestion to separate the sections into new RFCs onto
needing 5661bis. My vision would be to never touch 5661 or 8881 again.

Simply supply new documents that update/replace those documents.

I certainly was not an advocate of rewriting the ACL model. I.e., I saw no
reason to significantly change the documents.

Instead, I've drawn the line that occurs in 4.3.

On Wed, Jul 24, 2024, 04:32 David Noveck <[e-mail]> wrote:

> First of all, rfc8881 was never intended as a bis. It was a
> limited-function update which did not do a lot of things that a bis would
> need to do.  Because of time considerations we decide to defer that work.
> Given  the time involved, I'm glad we did.  I am referring to the following
> work which was needed in an rfc5661bis:
>
>    - Fixed a ton (or at least 100kg :-) of pending errata reports.
>    - Get rid of the internationalization approach in rfc5661, that was
>    totally wrong.
>    - Fix the security approach which needed extensive revision for the
>    reasons set out in Section 1.1.1 of* draft-dnoveck-nfsv4-security-10*.
>    BTW, Sections 1.1.2 and 1.1.3 list other reasons that security needed
>    extensive revision, even though I didn't know that when I
>    started this effort in 7/2021.
>
> IIRC, it was your advice at the time that I do this as a
> separate NFSv-wide document.  It is not your fault, but I would never do
> that again, given the unpleasant consequences of separate adoption calls
> for the individual documents.  In this case, the problem was exacerbated by
> chair mishandling of the adoption process.  The original adoption call
> started in 10/2022.  Now we have a situation in which people who may not
> have been aware of that history are asked to comment on adoption without
> knowledge of the context.  Sigh!
>
> Now to get back to the issue of rfc5662bis.  This is needed now rather
> than earlier since there were  no changes in rfc8881 that required matching
> xdr changes.  We need an rfc5662bis now because of the following  changes
> in other documents that are part of the respecification effort:
>
>
>    - Changes to string-related typedefs to reflect the work in
>    draft-ietf-nfsv4-internationalization.  These are similar to changes that
>    were made in RFC7531.
>    - A number of other changes made necessary by changes in other related
>    documents.  These include the non-use of certain fields resulting from
>    errata fixes and some cases of protocol extension as provided for by
>    Section 9 of RFC8178.
>
> These changes are all listed in Section 1.2 of
> *draft-dnoveck-nfsv4-rfc5662bis-03*.  IIRC I added that section to the
> document in -02 to respond to your concerns about the propriety of XDR
> changes in a bis.  I hope those concerns were addressed satisfactorily.
>
> BTW, I added some changes for better support of draft POSIX ACLs (more to
> say about that in a separate email) but did not update Section 1.2 to
> include them.  That willl be fixed in -04.
>
>
>
>
>
>
>
>
>
>
> On Tue, Jul 23, 2024, 11:08 AM Thomas Haynes <[e-mail]> wrote:
>
>>
>>
>> > On Jul 23, 2024, at 12:48 AM, Chris Inacio <[e-mail]> wrote:
>> >
>> > Hello all,
>> >
>> > The chairs are initiating an adoption for
>> draft-dnoveck-nfsv4-rfc5662bis-03.
>> >
>> > The chairs are interested in people supporting the adoption of this
>> draft and are willing to provide any of the following:
>> >
>> > * constructive text
>> > * Review
>> >
>> > The chairs are also interested in hearing if anyone is opposed to
>> adoption of this draft and a reason why the WG should not adopt it.
>> >
>> > We will include time for discussion of adoption during IETF-120 and
>> will close the adoption call reasonably soon after IETF-120.
>> >
>> > Thanks
>> > NFSv4 Chairs
>> > _______________________________________________
>> > nfsv4 mailing list -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>>
>>
>> Hi,
>>
>> I’e asked this question a couple of times, why do we need a second bis
>> for 5661 and 5662?
>>
>> Also, why is 5661bis not 8881bis?
>>
>> Thanks,
>> Tom
>> _______________________________________________
>> nfsv4 mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>