Re: [nfsv4] Working Group last call for NFSv4.1 - ending September 23rd

[David Noveck <[e-mail]>]

> To clarify, the 14 ones that are in reported are the ones that needs
> the WG to evaluate them and decided what needs to be done about them.

Understand that these need to be dealt with in the next few months and that
you
need a working group recommendation on them.

However, as part of the errata review the working group is free to (and
should)
look at whether it agrees with the decisions made regarding the other 25
erratta.
Anyone is free to suggest text modifications or argue that an erratta
already
verified would change a consensus decision.

>The one held for document update are exactly the ones that should be
> incorporated in an updated document.

I expect that other verified erratta or those that will be verifided as
part of the
review process will need to be incorporated as well.

Just to clarify,  I believe that the updated document you are referrring to
is,
in this case, rfc5661bis and not rfc5661sesqui.  Correct?

>They are usually the ones that
> have minor relevance but still worth doing something about when anyway
> improving the document.

> The rejected needs to be looked at. If it is rejected due to that it
> attempted to change a consensus decision, then that issue may still be
> relevant.

I don't think there was an attempt to  change a consensus decision.   My
impression was that this was rejected becauese addressing it was outside
the replace-text-A-by-text-B paradigm.   I think this could be clarified in
rfc5661bis and I will make a suggestion about how to do that next month, as
part of the errata review.

> In this case we have a document updating the specifcation for NFS 4.1
> although with a particular scope. In that process I see it is important
> that all issues relveant to the scope of the update have been
> considered.

I think this was the point of Chuck's comments.    He was the first to make
the
distinction between errata that related to the changes in rfc5661sesqui and
those that
did not.

>Thus, the Errata are input into determining if this
> document are as good as possible and addresses raised issues.

Yes, but only those errata that relate to matter changed in rfc5661sesqui
are relevant to that effort.   My intial review has convinced me that there
are
no such errata.   I think we can deal with possibility of me being wrong
about
that by asking anyone aware of such relevant errata to make them known to
the
working group ASAP, as part of WGLC for rfc5661sesqui.

> Secondly, the errata themselves are item on the previous version.

I assume that by that you mean rfc5661.

>Thus,
> they also needs to be dealt with somehow. We could reject all that are
>addressed by the future RFC, simply saying that they are not relevant
>anymore.

I don't think we can do that until rfc5661bis is farther long.  "will (kind
of) soon not be relevant" is very unconvincing.

> However, due to the limited scope of this updates I think it
> might be clearer if we actually decided what state each of the reported
> ones should be in and have a record of the decisions.

I agree that we need/want that.   The question is how to get there.

In my recent email I proposed that one of the working group co-chairs
announce an organized review process in the next month.   In order
to ensure that the review process actually occurs, I'd like to suggest that
you designate someone to propose such a review process, if one of the
WG co-chairs does not do so.

> This point is specifically to these that are in Reported state. They
> have not been processed and yet determined what to do with them. That
> is why I think these are especially important to go through.

I agree.   In view of the conffusion engendered by the initial mention of
the
verified errata in the WGLC announcement, I would suggest that that
announcement be re-issued, if possible.

> Please keep this effort first of all focused on that if the errata
> topic covers the part that is being updated in the limited scope
> update. If not then it will not impact the last call.

I expect that it will not, but anyone in the working group is free to
cite an instance where it should and raise the issue on the wg list.

> However, the
> determination what to do with the errata will be needed later, and
> applies to the future full update.

Given that we can treat the decisions already made as correct-until-shown-
otherwise, it should be possible to organize a review process that deals
with the
14 reported errata that completes in October.


On Mon, Sep 2, 2019 at 5:17 AM Magnus Westerlund <
[e-mail]> wrote:

> On Wed, 2019-08-28 at 09:37 -0400, David Noveck wrote:
> > > What you arrived at being important is that you review those
> > erratas related to
> > > document updating the old RFC, which is what you appear to have
> > concluded.
> >
> > So far, we have only considered the issue of the verified errata on
> > Spencer's list
> > but my impresion is that you also want of a review of:
> > > - the 14 errata in state Reported (i.e. not really looked-at yet).
> > > - the 7 errata in state Held Over
> > > - the one errata in state Rejected.
> > >
> > For the full list, see
> > https://www.rfc-editor.org/errata_search.php?rfc=5661&presentation=table
>
>
> To clarify, the 14 ones that are in reported are the ones that needs
> the WG to evaluate them and decided what needs to be done about them.
>
> The one held for document update are exactly the ones that should be
> incorporated in an updated document. They are usually the ones that
> have minor relevance but still worth doing something about when anyway
> improving the document.
>
> The rejected needs to be looked at. If it is rejected due to that it
> attempted to change a consensus decision, then that issue may still be
> relevant.
>
> >
> > For the seventeen errata previously listed, someone has decided that
> > they
> > fit wthin the parameters you've outlined.   However, as part of the
> > WG review,
> > anyone may raise the issue if they feel that the suggested text
> > changes a consensus
> > decison.  The working group will have to address situations in which
> > it might
> > not be clear whether there was, in fact, a consensus decision on some
> > particular
> > point.
> >
>
> So let me try to clarify the seperation of concerns here.
>
> In this case we have a document updating the specifcation for NFS 4.1
> although with a particular scope. In that process I see it is important
> that all issues relveant to the scope of the update have been
> considered. Thus, the Errata are input into determining if this
> document are as good as possible and addresses raised issues.
>
> Secondly, the errata themselves are item on the previous version. Thus,
> they also needs to be dealt with somehow. We could reject all that are
> addressed by the future RFC, simply saying that they are not relevant
> anymore. However, due to the limited scope of this updates I think it
> might be clearer if we actually decided what state each of the reported
> ones should be in and have a record of the decisions.
>
> > > But, I will need per Errata recommendations from the WG,
> >
> > I'm assuming you will need these recommmendations for all the
> > erratta, not just those that have been verified/accepted.
>
> This point is specifically to these that are in Reported state. They
> have not been processed and yet determined what to do with them. That
> is why I think these are expecially important to go through.
>
> Please keep this effort first of all focused on that if the errata
> topic covers the part that is being updated in the limited scope
> update. If not then it will not impact the last call. However, the
> determination what to do with the errata will be needed later, and
> applies to the future full update.
>
>
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>
>