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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 2 Sep 2019 08:59:29 +0000

On Wed, 2019-08-28 at 10:10 +0000, Magnus Westerlund wrote:
> Please remember that what you can do to address an errata in a
> document
> replacing the old RFC is much more than what is allowed in answering
> the Errata itself. An errata is now allowed to change a consensus
> decision, only clarify the interpretation of the document. 

Sorry, made a bad typo above. An errata is NOT allowed to change a
consensus decision. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 2 Sep 2019 09:16:59 +0000

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

---

From: David Noveck <[email-masked]>
Date: Mon, 2 Sep 2019 08:52:54 -0400

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

> 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

> attempted to change a consensus decision, then that issue may still be

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.

> 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

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

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.

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

> 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

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 3 Sep 2019 09:28:47 +0000

On Mon, 2019-09-02 at 08:52 -0400, David Noveck wrote:
> Understand that these need to be dealt with in the next few months
> and that you
> 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.

So the errata that are already verified or Held for Update I will not
change. However, if the reason for the errata is one that could be
better resolved in the updated document then it is a possible thing to
do. However, to minimize the work, I think the main focus is to ensure
that the errata has been implemented in the update. 

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

Not completly. If there are any errata that affects the section that
are updated in rfc5661sesqui then it should be ensured that the issue
does not remain. 

All other erratas on rfc5661 will need to be integrated in rfc5661bis. 

> part of the errata review.

Okay, that may also be a relevant reason. 

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

Yes. 

> of) soon not be relevant" is very unconvincing.

Thus, then making a decision on the errata on RFC 5661 is then relevant
in the process towards an RFC5661bis and have utility. 

> WG co-chairs does not do so.

This is something that is the responsibility of the WG chairs to figure
out. I am just trying to make clear my expectations.

> I agree.   In view of the conffusion engendered by the initial
> mention of the
> otherwise, it should be possible to organize a review process that
> deals with the

My experience is that it is often quite easy to process the erratas.
Someone with good knowledge of the RFC can usually determine if it is
correct, wrong or needs WG discussion. So, yes I do expect that you can
get through them within the timespan of a month. 

Cheers

Magnus Westerlund

---

From: David Noveck <[email-masked]>
Date: Tue, 3 Sep 2019 10:21:26 -0400

> Please do note that most of these errata are the result of further
implementation experience by various vendors,
> and at this point, reflects code that has been in public use for several
years.

Good point. :-(

> As such, the default assumption should be that the errata are valid, and
any attempt to invalidate them needs
> strong justification,

I think the criterion that Magnus laid out, i.e. "changes a [wg] consensus
decision" is a sufficiently high bar for rejection.   Except for for one
small errata to which your point does not apply, any reccommendation to
reject.an errata would be made by this  working group and we should not
accept a bare assertion that a  consensus decision is changed, given that
this question is rarely cut-and-dried.  In my opinion, clear and convincing
evidence of this supposed change should be provided.

> since it would by implication also require changing the implementations
on which they are based

Note that if we do run into this sort of conflict, a bis document can
change a consensus decision reflected in the base document.  This is what
happened with internationalization in RFC7530.  So, even if we decide an
errata is to be rejected as changing a consensus decision, the editor of
the bis can indicate why, based on the existing implementations, the change
should be made.   However, any such decision will need to be justified to
the IESG, requiring a more detailed explamation than one that simply
reflects a verified errata..

On Tue, Sep 3, 2019 at 9:22 AM Trond Myklebust <[email-masked]>
wrote:

>
>
> On Sep 3, 2019, at 05:28, Magnus Westerlund <
> Please do note that most of these errata are the result of further
> implementation experience by various vendors, and at this point, reflects
> code that has been in public use for several years. As such, the default
> assumption should be that the errata are valid, and any attempt to
> invalidate them needs strong justification, since it would by implication
> also require changing the implementations on which they are based.
>
> Regards
>   Trond
>
>
> _________________________________
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> [email-masked]
>
>