Re: A quick poll about RFC 7221

[David Noveck <[e-mail]>]

On Sun, Sep 13, 2020, 11:44 AM Joel M. Halpern <[e-mail]> wrote:

> Without trying to revisit ancient history, what you describe is not the
> case.
>

Nevertheless, it happened.


> The IESG never owns the document.


Perhaps not, but the fact that it cannot be published without the IESG's
assent makes the question of ownership irrelevant.

  One can argue that the IETF owns it
> during and after IETF last call.


Perhaps so, but I'm not clear what this "ownership" consists of.

If events transpired as you say, I
> would have said that the chairs were obliged to notify the WG of the
> changes.


Perhaps so but they didn't, for reasons that are starting to become clear
to me.

If

> they were indeed of that magnitude, a new WG LC could well
> have been appropriate.


Formally perhaps, but what would have been the likely result?  There is no
way the working group would ever have accepted the IESG's approach.  And
the wg's approach had been rejected by the IESG once.   The most likely
result would have been the death of nfsv4 and that is probably what
motivated the chairs to avoid the discussion.

After all, in a discussion of documents, the IESG has the upper hand so it
was not in the working group's interest to have that discussion.  In the
years running up to RFC 7530, the wg's approach was successfully
implemented while stringprep, thought of as salvific by the IESG in 2003,
lost its previous sheen.


In some cases, I have seen a new IETF LC as well
> when the changes were sufficiently large.
>
> Yours,
> Joel
>
> On 9/13/2020 8:50 AM, David Noveck wrote:
> > I haven't seen this be a major problem in recent years, although it is
> > an illustration of the fact that, once WGLC has happened, its ownership
> > of the document has effectively lapsed and only the authors have a role
> > in dealing with potential changes that would interfere with the wg
> > consensus.
> >
> > Way back in 2003, the internationalization section of rfc3530 was
> > essentially rewritten at IESG direction.  The fact that the wg was not
> > aware of the change meant that nobody implemented it.  As a result, all
> > nfsv4 implementations followed the WGLC document rather than the iesg's
> > revision. The wg had the last word since they were the implementers as
> > well.  This was all corrected for nfsv4.0 by rfc7530
> >
> > I'm not sure what would have happened if the wg had been made aware of
> > this change but the process would probably have been quite contentious.
> > It almost certainly would have prevented rfc5661 internationalization
> > from following the unimplemented rfc3530 one. We now have to deal with
> > this as part of rfc5661bis.  Sigh!
> >
> > On Sat, Sep 12, 2020, 5:49 PM Erik Kline <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >
> >
> >     On Sat, Sep 12, 2020 at 2:40 PM Joel M. Halpern <[e-mail]
> >     <mailto:[e-mail]>> wrote:
> >
> >         Actually Carsten, I would phrase your comment differently.
> >
> >         We allow the editors of documents to make changes during the
> >         process.
> >         We expect them to tell the WG what they are doing.
> >         The important part is that if the WG disagrees, the editors are
> >         required
> >         (not merely expected, required) to make the changes to conform
> >         with the
> >         WG rough consensus.
> >
> >         Many years ago I fired a WG document editor for refusing to do
> so.
> >         I have come close to doing so more than once since.
> >
> >         The document belongs to the WG, not to the editor.
> >         For practical reasons, we allow the editors a lot of room to
> >         work on the
> >         document.
> >
> >         The WG LC should, if things are going right, serve as a final
> >         confirmation that nothing has gone wrong.  That does not mean it
> is
> >         unnecessary.
> >
> >
> >     Sadly changes can also creep in during IETF LC and IESG eval (and
> >     during AUTH48), without much awareness by the working group(s).  :-/
> >
> >         Yours,
> >         Joel
> >
> >         On 9/12/2020 4:50 PM, Carsten Bormann wrote:
> >          > Interesting.  I didn’t actively know about this document.
> >          > (I might have heard about it in 2014, but have since
> >         forgotten about it.)
> >          >
> >          > The title is misleading:
> >          >
> >          >             Handling of Internet-Drafts by IETF Working Groups
> >          >
> >          > Instead, it mostly is about adoption of WG documents (and the
> >         selection of authors for that segment of its life), except for
> >         the introduction where it states in passing that a WG document
> >         is (at least substantively) always representing the WG rough
> >         consensus.
> >          >
> >          > This is the second time I need to use the term “process
> >         confabulation” today.  While having this statement in an (albeit
> >         informational) document is a great stick with which WG chairs
> >         can beat up errant authors, it does not reflect reality (even if
> >         it does more so in the times of development by github than it
> >         used to be), not even an actually always desired process.  (If
> >         it actually were true, we wouldn’t need a WGLC.)
> >          >
> >          > The reality is that in many WGs, authors have pretty wide
> >         authority [sic!] to generate new I-Ds that they believe will
> >         bring the process forward, and obtain feedback [that could be
> >         (but most often is not) judged by the WG chairs to represent WG
> >         consensus] only after publishing the new I-D.  Very large WGs
> >         may have more elaborate processes that might be closer to
> >         mini-WGLCs before accepting changes (in particular with github’s
> >         help), but as a universal process requirement, requiring
> >         consensus before publishing each update would really impede
> >         progress.  The WG needs something concrete to discuss, and I-Ds
> >         are that concrete writeup that is input, not output of the
> >         current discussion.
> >          >
> >          > Grüße, Carsten
> >          >
> >
>