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

[Magnus Westerlund <[e-mail]>]

On Mon, 2019-09-02 at 08:52 -0400, David Noveck wrote:
> > 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.

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. 

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

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. 

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

Okay, that may also be a relevant reason. 

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

Yes. 


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

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

> 
> > 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 is something that is the responsibility of the WG chairs to figure
out. I am just trying to make clear my expectations.


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

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 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------