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

[David Noveck <[e-mail]>]

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]
>