Subject: [Iasa20] Ballot positions on draft-ietf-iasa2-rfc7437bis

From: Alissa Cooper <[email-masked]>
Date: Fri, 5 Jul 2019 14:41:10 -0400

Dear IESG,

I wanted to draw your special attention to this text in draft-ietf-iasa2-rfc7437bis:

"This revision addresses only the changes required for IASA 2.0;
   should the community agree on other changes, they will be addressed
   in future documents.”

As well as this text in the IASA2 WG charter:

"This working group is chartered to document the normative changes to IETF administrative structures and processes necessary to effectuate [the change to IASA 2.0].”

If the IESG is not going to allow draft-ietf-iasa2-rfc7437bis or other IASA2 documents to progress unless changes unrelated to IASA 2.0 are made, I think the WG needs to be rechartered. The authors and the WG purposefully did not make any other changes to the base documents, so making other changes as a result of IESG evaluation does not seem appropriate. I think the appropriate thing to do would be for ADs who want to see that happen to start a thread about re-chartering on the iasa20 list. (Note: this is not my preference since I suspect it will delay the minimal changes related to IASA 2.0 from being published for a long time, but if that’s what the community wants I’ll support it.)

Thanks,
Alissa

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Jul 2019 08:10:53 +1200

I'm with Alissa on this. There are quite a lot of reasons why we
might need RFC7437bisbis, some of which are much more serious than
the various points raised by several ADs, but I believe we should
first wrap up the changes required by the creation of IETF LLC.

I don't think rechartering IASA2 for this purpose would be
appropriate at all. Starting a process that might lead to a new
version of the POISED, POISED95 or POISSON WG would seem more suitable.
See https://datatracker.ietf.org/wg/poisson/about/ for example.

Regards
   Brian Carpenter

On 06-Jul-19 06:41, Alissa Cooper wrote:
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20
>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 5 Jul 2019 13:43:49 -0700

Hi,

> On Jul 5, 2019, at 1:10 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I agree.  Especially since we have a working LLC signing contracts for us, spending money, etc, etc.  The IETF process documents like RFC7437 need to be aligned as soon a possible.

> See https://datatracker.ietf.org/wg/poisson/about/ for example.

I also agree.  Making changes to the NomCom process needs a new w.g. focused on that.   That is not the focus on the IASA 2.0 w.g., nor should it be.

Thanks,
Bob

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 5 Jul 2019 21:59:16 +0100

On 05/07/2019 21:43, Bob Hinden wrote:
> I agree.  Especially since we have a working LLC signing contracts
> for us, spending money, etc, etc.  The IETF process documents like
> RFC7437 need to be aligned as soon a possible.
> 
>> 
>> version of the POISED, POISED95 or POISSON WG would seem more
>> suitable. See https://datatracker.ietf.org/wg/poisson/about/ for
>> example.
> 
> I also agree.  Making changes to the NomCom process needs a new w.g.
> focused on that.   That is not the focus on the IASA 2.0 w.g., nor
> should it be.

FWIW, I also agree with Brian and Bob.

I'm not sure how much real energy there may be for a
concrete set of work items for a POISED-like thing,
but I do agree there're a set of potential work items
each of which likely has a bunch of people who'd like
to see 'em addressed.

But yes, not in this WG, and not in a way that'd
prevent finishing the chartered work here.

S.

> Thanks, Bob
>> Regards Brian Carpenter
>>> should the community agree on other changes, they will be
>>> addressed in future documents.”
>>> 
>>> "This working group is chartered to document the normative
>>> changes to IETF administrative structures and processes necessary
>>> to effectuate [the change to IASA 2.0].”
>>> 
>>> If the IESG is not going to allow draft-ietf-iasa2-rfc7437bis or
>>> other IASA2 documents to progress unless changes unrelated to
>>> IASA 2.0 are made, I think the WG needs to be rechartered. The
>>> authors and the WG purposefully did not make any other changes to
>>> the base documents, so making other changes as a result of IESG
>>> evaluation does not seem appropriate. I think the appropriate
>>> thing to do would be for ADs who want to see that happen to start
>>> a thread about re-chartering on the iasa20 list. (Note: this is
>>> not my preference since I suspect it will delay the minimal
>>> changes related to IASA 2.0 from being published for a long time,
>>> but if that’s what the community wants I’ll support it.)
>>> 
>>> Thanks, Alissa
>>> 
>>> 
>>> _______________________________________________ iasa20 mailing
>>> list [email-masked] 
>> _______________________________________________ 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: John C Klensin <[email-masked]>
Date: Fri, 05 Jul 2019 17:06:43 -0400

FWIW, as someone who argued for making more extensive changes in
order to clean up problems we knew about _and_ who argued for
more focus on the approach of draft-ietf-iasa2-consolidated-upd
in order to avoid issuing replacement ("X obsoletes Y")
documents when we knew there were outstanding issues with them,
I agree with Brian and Alissa.  

The time to raise the question of whether IASA2 should do a
general cleanup was back when the IASA2 WG was chartered and has
long passed.  If we are ready to reopen basic procedures or
models that are not involved with the IASA transition, something
in the POISED, POISED95 or POISSON chain, or perhaps the NEWTRK
one, might be appropriate but pretending that IASA2 is properly
organized to do that -- even with a recharter -- would, IMO, be
a considerable disservice to the community.

In a more perfect world, I strongly prefer that we not replace
documents unless we sort out all known issues with them.  For
technical specifications, the language of RFC 2026 just about
requires that.  But that isn't what the IESG (and, at least to
some extent, the community) decided to with IANA2.  Trying to
change that retroactively would be even worse.

In the interim, if clarifications that are not in scope for
IASA2 are needed, there is a relatively lightweight mechanism
that would probably be considered the only appropriate one if
these suggestions were not emerging from the IESG.   Generate an
I-D that updates whatever comes out of IASA2, get some AD to
sponsor it, push it through IETF LC, and move on.

  best,
    john

--On Saturday, July 6, 2019 08:10 +1200 Brian E Carpenter
<[email-masked]> wrote:

> I'm with Alissa on this. There are quite a lot of reasons why
> we might need RFC7437bisbis, some of which are much more
> serious than the various points raised by several ADs, but I
> believe we should first wrap up the changes required by the
> creation of IETF LLC.
> 
> suitable. See https://datatracker.ietf.org/wg/poisson/about/
> for example.
> 
> Regards
>    Brian Carpenter
> 
>> "This revision addresses only the changes required for IASA
>> 2.0; should the community agree on other changes, they will
>>    be addressed in future documents."
>> 
>> changes to IETF administrative structures and processes
>> necessary to effectuate [the change to IASA 2.0]."
>> 
>> If the IESG is not going to allow draft-ietf-iasa2-rfc7437bis
>> or other IASA2 documents to progress unless changes unrelated
>> to IASA 2.0 are made, I think the WG needs to be rechartered.
>> The authors and the WG purposefully did not make any other
>> changes to the base documents, so making other changes as a
>> result of IESG evaluation does not seem appropriate. I think
>> the appropriate thing to do would be for ADs who want to see
>> that happen to start a thread about re-chartering on the
>> iasa20 list. (Note: this is not my preference since I suspect
>> it will delay the minimal changes related to IASA 2.0 from
>> being published for a long time, but if that's what the
>> community wants I'll support it.)
>> 
>> Thanks,
>> Alissa
>> 
>>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 5 Jul 2019 15:29:12 -0700

On Fri, Jul 5, 2019 at 11:41 AM Alissa Cooper <[email-masked]> wrote:
> If the IESG is not going to allow draft-ietf-iasa2-rfc7437bis or other IASA2 documents to progress unless changes unrelated to IASA 2.0 are made, I think the WG needs to be rechartered.

I'm not sure if this is directed at me -- I'm holding a DISCUSS
position with some questions / clarifications, but I'm perfectly fine
to be told for any or all of them that these are outside the scope of
what the WG is chartered for / doing with this -bis.

> The authors and the WG purposefully did not make any other changes to the base documents, so making other changes as a result of IESG evaluation does not seem appropriate. I think the appropriate thing to do would be for ADs who want to see that happen to start a thread about re-chartering on the iasa20 list. (Note: this is not my preference since I suspect it will delay the minimal changes related to IASA 2.0 from being published for a long time, but if that’s what the community wants I’ll support it.)

Fair 'nuff -- but (for me at least) I don't think that my questions /
requests for clarification count as substantive changes. If others do,
I'm perfectly fine to clear them, etc.
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Warren Kumari <[email-masked]>
Date: Sun, 7 Jul 2019 06:03:23 -0700

[ Replying midway through the thread, because this seemed to be the
most appropriate message to reply to ]

> prevent finishing the chartered work here.

I've just changed my position from DISCUSS to NoObjection, and added:
-----
NOTE:
My original position was DISCUSS - I'm changing it to NoObjection, but
I'm still quite uncomfortable with this -- I view NoObjection as
signalling that I'm comfortable with the document.
"The IESG is expected to ensure that the documents are of a sufficient
quality for release as RFCs, that they describe their subject matter
well, and that there are no outstanding engineering issues that should
be addressed before publication. The degree of review will vary with
the intended status and perceived importance of the documents."
(RFC3710).

I view this document as very important, but as whole I don't think it
is "of a sufficient quality for release as RFC" and that it
"describe(s) their subject matter well" - there are some open
questions / places where clarification would help. I fully understand
the need to patch this to support IASA2 (and it's the right thing to
do), and the reasoning behind not opening up the entire document for
review and fixing all the bugs...
The paragraph which says "This revision addresses only the changes
required for IASA 2.0;should the community agree on other changes,
they will be addressed in future documents." addresses basically all
of my concerns, but I'd be **much** happier (and would be comfortable
voting "Yes") if it were moved from the Introduction into the Abstract
or made more prominent in some other way. "
------

I *did* read the "This revision addresses only the changes ..." when
originally reviewing document, but it is somewhat buried. I nodded,
thought "fair 'nuff, makes sense", and then stumbled when I found nits
/ areas to be clarified.
I think that this is a really important document, and support us
making it compatible with IASA 2.0 (duh!) -- but I really don't want
others to miss this important bit and think that No Objection means
that I think all of the document is perfect, or that we don't still
have areas for improvement.

W

---

From: Bob Hinden <[email-masked]>
Date: Sun, 7 Jul 2019 09:12:44 -0700

Warren,

> On Jul 7, 2019, at 6:03 AM, Warren Kumari <[email-masked]> wrote:
> 

Doesn’t it count for something that this document was approved by an earlier IESG in 2014?

  https://datatracker.ietf.org/doc/rfc7437/ballot/

As far as I can tell, your comments all relate to original text approved in 2014.   The datatracker shows that Barry was on that IESG and he voted YES.

Why is it OK for ADs to create new Discusses on something an earlier IESG approved.   In my view, this behavior from ADs does not add to the overall quality of the IETFs work, it just makes more work for everyone and slows everything down.

Also, a great deal of irony that most of the current IESG was appointed by the process defined in this document.  It seems like it works.

Bob

p.s. As the document editor, I will make the changes need to move this forward once I get direction from the w.g. chairs.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 7 Jul 2019 16:46:42 +0000

[Clearing all previous comments as they are not really relevant to the text below]

Alissa, thank you for framing the discussion. I now understand Bob's reply to my COMMENTs "out of scope" that I failed to understand to be honest.

While I now understand that we need to "upgrade" RFC 7437 as soon as possible to accommodate the new structure; I share Warren's concerns: I am not comfortable of saying "no objection" with COMMENTs that won't be addressed at all (not to mention some DISCUSSs). 

If everyone thinks that:
1) let's deliver ASAP RFC7437bis with a "simple relifting" to accommodate the new structure
2) later let's redo it with a more refined content

Then, I have no problem EXCEPT that the following sentence is rather vague, not binding and not very visible (esp for a BCP):
   "This revision addresses only the changes required for IASA 2.0;
   should the community agree on other changes, they will be addressed
   in future documents."

I would strongly prefer a clear hint / requirement to have more work to be done on RFC 7437ter or at least having this 'limited scope' in the front abstract.

Regards and thanks to the authors & WG participants,

-éric

---

From: Bob Hinden <[email-masked]>
Date: Sun, 7 Jul 2019 10:08:01 -0700

Eric,

> On Jul 7, 2019, at 9:46 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 

I think adding text to the abstract is fine.  How about something like this:

   The process by which the members of the IAB and IESG, some Trustees
   of the IETF Trust, and some Directors of the IETF LLC are selected,
   confirmed, and recalled is specified in this document.  This document
   is based on RFC3777 and RFC7437 and has been updated to only reflect the
   changes introduced by IASA 2.0.  Any other changes will be addressed in
   future documents.

BTW, if we do an RFC7437bisbis, I am willing to be the document editor.

Thanks,
Bob

---

From: John C Klensin <[email-masked]>
Date: Sun, 07 Jul 2019 13:40:17 -0400

--On Sunday, 07 July, 2019 10:08 -0700 Bob Hinden
<[email-masked]> wrote:

> 
>    The process by which the members of the IAB and IESG, some
> Trustees    of the IETF Trust, and some Directors of the IETF
> LLC are selected,    confirmed, and recalled is specified in
> this document.  This document    is based on RFC3777 and
> RFC7437 and has been updated to only reflect the    changes
> introduced by IASA 2.0.  Any other changes will be addressed in
>    future documents.

To save the RFC Editor a small bit of trouble (and AUTH48
surprises), that should probably be "updated only to reflect" or 

	"This document is based on RFC3777 and RFC7437. Only
	those updates required to reflect the changes introduced
	by IASA 2.0 have been included.  Any other...'

best,
   john

---

From: Bob Hinden <[email-masked]>
Date: Sun, 7 Jul 2019 10:43:37 -0700

> On Jul 7, 2019, at 10:40 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> 	by IASA 2.0 have been included.  Any other…'

Thanks, looks good.

Bob

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 8 Jul 2019 06:12:47 +0000

Bob,

Much better like that

-éric

On 07/07/2019, 19:08, "Bob Hinden" <[email-masked]> wrote:

    Eric,

    

    Thanks,
    Bob

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 8 Jul 2019 10:42:11 -0400

Hi Warren,

> On Jul 5, 2019, at 6:29 PM, Warren Kumari <[email-masked]> wrote:
> 

Not specifically. I wanted to have the conversation with everyone.

Looks like we’re moving in a good direction with the abstract.

Thanks,
Alissa

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Jul 2019 10:43:07 -0400

> Doesn’t it count for something that this document was approved by an earlier IESG in 2014?

You're being disingenuous.  THIS document was never put before the
IESG before.  The draft that became RFC 7437 was, but that was a
different document.

Today, we're being asked to review draft-ietf-iasa2-rfc7437bis, not
draft-kucherawy-rfc3777bis.

Now, first, it would have been nice to have been alerted that a
thorough editorial review was not welcome *before* the document was
put on the telechat agenda and a ballot was opened.  I spent a few
hours working on it and being thorough, and would liked to have not
wasted my time on things that will be ignored.

Second, the working group charter says this:

   Aside from instances where they presently relate to IASA, it is outside the
   scope of this working group to consider any changes to anything related to
   the oversight or steering of the standards process as currently conducted by
   the IESG and IAB, the appeal chain, the confirming bodies for existing IETF
   and IAB appointments, the IRTF, or ISOC's memberships in other organizations.

I see a huge difference between not considering changes to the process
(and oversight and steering)... and not considering editorial changes
that correct or clarify existing text.  Clearly, not everyone agrees
with me on that, but it's part of the job to which I've been appointed
to review documents for correctness and clarity, and to call out areas
where I think the documents fail.

I'll note, for example, that in the text I've been trying to get
discussed, in Section 3.8, this document -- THIS document -- already
makes changes to what was in 7437, some of which were not required for
the IASA2 changes.  It changes "nominating committee" to "NomCom" (why
does that relate to IASA2?) and merges bullets 3 and 4 from the
original.  I'm not suggesting that those changes should not have been
made, nor that they caused the issue I'm questioning.  I'm only saying
that we're already not being rigorous about limiting text changes to
those absolutely necessary.  So let's get some perspective here.

> In my view, this behavior from ADs does not add to the overall quality of the IETFs work,
> it just makes more work for everyone and slows everything down.

Is it your view that if an error is missed once, we're stuck with it forever?

Am I really not adding to overall quality by asking for clarity in
text that I think simply doesn't work as written?  I could be wrong
when I say the text appears to be broken, but we're not having a real
discussion about it, so I wouldn't know.  Maybe it's attempts to
deflect discussions, rather than actually have them and resolve the
issues, that makes more work for everyone and slows everything down.

I am not trying to block this document; quite the opposite: I think
it's a critically important document, and I'm helping to make sure
it's clear and correct in what it's saying.  I don't want to make
changes to the process here.  I want to make sure there isn't
something that, when something comes up that sends us to it, isn't
clearly understandable.

> p.s. As the document editor, I will make the changes need to move this forward once I get direction from the w.g. chairs.

I have a large number of comments that are editorial, and which are
not in the DISCUSS group.  Some of those are important, and some
directly relate to errors in the text about IASA2 issues.  Please make
sure you go through those and incorporate at least those in the latter
group, along with any others that seem important enough to include.

Barry

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 8 Jul 2019 11:15:55 -0400

Hi Barry,

> On Jul 8, 2019, at 10:43 AM, Barry Leiba <[email-masked]> wrote:
> 

Sorry, this was my bad. When I see process bis docs on the telechat agenda I tend to focus on the changes visible in the diff, but I shouldn’t assume everyone does that.

Alissa

---

From: Bob Hinden <[email-masked]>
Date: Mon, 8 Jul 2019 08:18:57 -0700

Barry,

> On Jul 8, 2019, at 7:43 AM, Barry Leiba <[email-masked]> wrote:
> 
> You're being disingenuous.

Really?  The definition of disingenuous is:

  adjective
     not candid or sincere, typically by pretending that one knows
     less about something than one really does.

> THIS document was never put before the

But most of the text has been before the IESG before.  That’s why I said:

   Doesn’t it count for something that this document was approved by an
   earlier IESG in 2014?

> wasted my time on things that will be ignored.

I agree that would have been better, but please note, I am only the document editor here.

> where I think the documents fail.

If we want to make a lot of changes, then I think it will need at least another IETF last call, or given the other NomCom related issues being discussed recently, a new w.g.

> those absolutely necessary.  So let's get some perspective here.

The intent for this change was to use the term that is in common use, but if it’s an issue we could go back to “nominating committee”.  I think that’s different than for example rewriting the text in Section 3.8. "Sitting Members and Directors” regarding the exception for the IAB.

> Is it your view that if an error is missed once, we're stuck with it forever?

No, I don’t think I said that.

> group, along with any others that seem important enough to include.

Will do.

Bob

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Jul 2019 11:50:45 -0400

>      less about something than one really does.

Yes, sorry; I did malign your sincerity, and that's not right.  Please
accept my apology for that.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Jul 2019 11:54:51 -0400

> If we want to make a lot of changes, then I think it will need at least another IETF last call

That's up to Alissa's judgment as responsible AD, but for my part, I
think changes for clarity and editorial correctness generally would
not need that.  I've suggested a lot of very small changes, but each
is individually... very small, and purely editorial.

I updated my ballot this morning to bubble up the editorial
suggestions that relate to the IASA changes, so it should be easier
for you to find them.  Some definitely have to be made, such as some
places where the document needed to be updated for "LLC Director and
IETF Trust", and it was missed.

> or given the other NomCom related issues being discussed recently, a new w.g.

Oh, my... yes, I think we *will* need a new WG for those, but I do NOT
mean to suggest any changes of that nature here!

Barry

---

From: Bob Hinden <[email-masked]>
Date: Mon, 8 Jul 2019 09:15:26 -0700

Barry,

> On Jul 8, 2019, at 8:50 AM, Barry Leiba <[email-masked]> wrote:
> 

Thank you, very appreciated.

Bob

---

From: Warren Kumari <[email-masked]>
Date: Mon, 8 Jul 2019 13:38:51 -0400

Hi there,

> Sorry, this was my bad. When I see process bis docs on the telechat agenda I tend to focus on the changes visible in the diff, but I shouldn’t assume everyone does that.

Thank you.
I must admit that I *thought* that I was initially somewhat miffed
because I'd put in lots of time, and is seemed I was being asked to
rubberstamp something along the lines of  'cat RFC7437.txt | sed
"s/ISOC/LLC/" > RFCxxxx.txt".

On further reflection I realize that my discomfort was rather that I'm
sensitive to the recall and similar issues, and don't want my
"approval" of the document to be viewed as a signal that I think that
*everything* in this document is perfect - I don't want to dissuade or
discourage $someone (AKA, not me!) fixing this (and other issues in
this and other process documents) to reflect what the community
wants[0]. This is obviously a *much* larger, and much more difficult
set of questions, and I don't want to us delay "patching" this
document to reflect reality while solving the bigger, more important
issues.

When removing my DISCUSS position I spent quite a while trying to
figure out which of the other positions best singalled this -
initially I'd chosen Abstain, but this means "I cannot support sending
this document forward."
(https://www.ietf.org/standards/process/iesg-ballots/) - I *do*
support moving it forward, but don't want to signal it's perfect. "No
Record" doesn't work - I have reviewed it and have views. Discuss no
longer works - I am sympathetic to not opening the can of worms in
this patch cycle. Clearly Yes wasn't right, so "No Objection", coupled
with a soapbox sermon seemed to be best...

W
[0]: e.g I *personally* think that if I'm doing a crappy job, the
community (both in-person and remote) should be able to replace me.
I'd hope that there would be some clear signalling before so I know
that I'm messing up, but I really don't want people to be in a
position where they are not comfortable doing this because they fear
retribution or are not franchised.