Subject: Re: [Iasa20] WGLC: RFC 7776-bis (oops)

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 1 Apr 2019 09:02:24 +0100

Thanks Bob,

That is a good inclusion in 7437bis, but makes 7776bis a bit confusing.
I'll try to work something out 😊

A

-----Original Message-----
From: Bob Hinden <[email-masked]> 
Sent: 31 March 2019 16:16
To: [email-masked]
Cc: Bob Hinden <[email-masked]>; Sean Turner <[email-masked]>; Jason Livingood <[email-masked]>; [email-masked]
Subject: Re: [Iasa20] WGLC: RFC 7776-bis (oops)

Adrian,

> On Mar 30, 2019, at 12:53 PM, Adrian Farrel <[email-masked]> wrote:
> 
> Well, we can do this.
> It is a bit ugly because 7776 updates 7437.
> So what we end up with is an I-D going into the RFC Editor Queue with a planned update to an I-D going into the RFC Editor Queue at the same time.

I believe that draft-ietf-iasa2-rfc7437bis includes the Ombudsteam changes made by RFC7776.   It’s called out in the change log:

      draft-ietf-iasa2-rfc74337bis-03, 2018-October-22:

      *  Revised Section 7 to focus on repeal of the the NomCom appoint
         LLC Director positions.
      *  Added that the IETF Trust Trustees and IETF LLC Directors, each
         may appoint a liaison to the NomCom.
      *  Incorporated the update to RFC7437 done by RFC7776.
      *  Incorporated the update to RFC7437 done by [RFC8318] and
         updated it to refer to the IETF Trust and IETF LLC. instead of
         the IAOC.
      *  Editorial changes.

Specificly see Section 7.1. “Petition” and 7.1.2. "Ombudsteam Petition”

Thanks,
Bob

> 
> Just as a reminder, while 7437bis is a full replacement for (i.e., obsoletes) 7437, 7776bis is only a minor delta (i.e., updates) 7776.
> 
> I completely understand the notion of "this document is only open to make the IASA2.0 changes" but maybe this could be cleaner?
> 
> I will update my working copy of 7776bis to show the update to the work in progress, but if you or the WG prefer that we clean this up, I am happy to discuss doing different.
> 
> Cheers,
> Adrian
> 
> PS If anyone knows how to wrangle the XML to handle this case, I'd welcome a clue. O/w I am using a note in the text.
> 
> -----Original Message-----
> From: iasa20 <[email-masked]> On Behalf Of Bob Hinden
> Sent: 30 March 2019 08:36
> To: Sean Turner <[email-masked]>
> Cc: Jason Livingood <[email-masked]>; Bob Hinden <[email-masked]>; [email-masked]
> Subject: Re: [Iasa20] WGLC: RFC 7776-bis (oops)
> 
> 
> 
>> On Mar 30, 2019, at 8:40 AM, Sean Turner <[email-masked]> wrote:
>> 
>> References to RFC 7437 appear:
>> 
>>  [RFC7437]  Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection,
>>             Confirmation, and Recall Process: Operation of the
>>             Nominating and Recall Committees", BCP 10, RFC 7437,
>>             DOI 10.17487/RFC7437, January 2015,
>>             <http://www.rfc-editor.org/info/rfc7437>.
>> 
>> should we update them to refer to draft-ietf-iasa2-rfc7437bis?
> 
> I would think so.
> 
> Bob
> 
> 
>> 
>> spt
>> 
>>> On Mar 24, 2019, at 11:03, Livingood, Jason <[email-masked]> wrote:
>>> 
>>> We’ve just realized that while we thought we’d issued all the WGLCs we seem to have missed one for RFC7776-bis (https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7776bis/). I guess this is the danger of closing so many documents simultaneously. Anyway – WGLC is now open, ending 7-April-2019.
>>> 
>>> Thanks
>>> Jason
>>> _______________________________________________
>>> iasa20 mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/iasa20
>> 
>> _______________________________________________
>> iasa20 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/iasa20
> 
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20
>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 1 Apr 2019 08:48:40 -0400

Hi Adrian,

> I will update my working copy of 7776bis to show the update to the work in progress, but if you or the WG prefer that we clean this up, I am happy to discuss doing different.

While I am replying to this note, I have read the later replies and this
text seems the most logical to respond to...

I would support having 7437bis take on the responsibility of fixing the
text that 7776bis is currently trying to fix in 7437. It is silly to
have an active -bis document updating another active -bis document. The
gyrations needed to follow that logic will make it extremely difficult
for any new reader of those documents to follow along.

Let's do the right thing here.

Regards,
Brian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 1 Apr 2019 13:53:27 +0100

Yes, Brian, I agree.

My joy (which I will resolve!) is that 7776bis is an update (just pointing at bits of text to be replaced) while 7437bis is a full replacement.

It is quite ugly to remove text that said "updates" and replace it with pointers. But *everything* is possible.

Adrian

-----Original Message-----
From: iasa20 <[email-masked]> On Behalf Of Brian Haberman
Sent: 01 April 2019 13:49
To: [email-masked]
Subject: Re: [Iasa20] WGLC: RFC 7776-bis (oops)

Hi Adrian,

Regards,
Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 01 Apr 2019 09:55:03 -0400

--On Monday, April 1, 2019 08:48 -0400 Brian Haberman
<[email-masked]> wrote:

>...
> I would support having 7437bis take on the responsibility of
> fixing the text that 7776bis is currently trying to fix in
> 7437. It is silly to have an active -bis document updating
> another active -bis document. The gyrations needed to follow
> that logic will make it extremely difficult for any new reader
> of those documents to follow along.

With the understanding that, because of what was done with
draft-ietf-iasa2-consolidated-upd-, I am in a slightly
conflicted position about this, I suggest that this is not as
complicated as it seems.   If 7776bis contains a normative
reference to 7437bis (or vice versa) both go into the RFC Editor
queue as a cluster.  As long as the final results are consistent
and the documents are published at the same time, the gyrations
you are concerned about become largely non-existent, especially
if someone (like the IESG) informally suggests to the RFC Editor
that the -bis document that updates the other get the higher
number in the series.  Interrelated documents that address parts
of the same topic, especially when they change or replace other
documents on the topic, are one of the two reasons that
normative reference holds were introduced (the other is to avoid
normative references to I-Ds, but that has the same effect).  We
create extra gyrations for future readers only if the documents
don't get the references right.

That does not make the situation non-silly, but we should not
exaggerate the impact.   The potential for silliness and
excessive complexity for future readers is also the reason I
suggested trying to minimize the total number of documents from
the WG as much as possible.  I'm not sure we've gotten the
balance right, but it is probably much too late to reconsider
the current document profile.

    john