Subject: [Iasa20] draft-ietf-iasa2-consolidated-upd-06

From: John C Klensin <[email-masked]>
Date: Thu, 07 Mar 2019 01:52:50 -0500

Hi.

draft-ietf-iasa2-consolidated-upd-06 should be posted in a few
minutes.  I hope this version reflects changes requested since
-05 was posted at the end of January.  In particular, it
reflects the suggestions from the RFC Editor and the  separate
status of the RFC 3716 as an IAB document and the text supplied
by Alissa in her note yesterday.

The bad news is that when I read Section 4 after patching those
changes in, it was just too convoluted and I had to restructure
and rewrite it.  I hope the changes are at least tolerable to
everyone and that I didn't make mistakes that would require
another iteration.  Of course, if I did and problems are
spotted, I'll be happy to that.  

On the other hand, if the language reflects the WG's intent
sufficiently well but some of my phrasing doesn't line up with
the needs of the IAB or RFC Editor, I recommend that we attach
appropriate notes and let them sort it out with each
other and the IESG if needed on AUTH48 rather than trying to
make small editorial changes by committee nit-picking.   Just my
preference, of course, YMMD.

    john

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 7 Mar 2019 12:12:42 -0500

Thanks. I still don’t think this is quite right because there is no basis for this working group to obsolete or render historic RFC 3929 simply because it mentions the IETF Executive Director. It seems that RFC 3929 should be treated in Section 2 the same as the other documents in that section.

Alissa

> On Mar 7, 2019, at 1:52 AM, John C Klensin <[email-masked]> wrote:
> 
> Hi.
> 
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Mar 2019 08:46:40 +1300

> Thanks. I still don’t think this is quite right because there is no basis for this working group to obsolete or render historic RFC 3929 simply because it mentions the IETF Executive Director. It s…

There's a more general issue: tracking down all "open" Experimental RFCs and deciding which of them need to be closed off as Historic or Obsolete or both. <joke>No doubt the IESG will be doing this in its copious free time.</joke> But for the present, doesn't it make more sense to clear both 3929 and 4633 up right away? I agree that it's outside the WG's mandate, strictly interpreted, but if the IESG consents, is that really a problem?

    Brian

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 7 Mar 2019 16:52:10 -0500

Hi Brian,

> On Mar 7, 2019, at 2:46 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Yes. The point of charters is to scope working groups’ work. This working group is chartered to to document the normative changes to IETF administrative structures and processes necessary to effectuate the change to IASA 2.0. Obsoleting documents about other things because they are out of date is not within the charter.

Alissa

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Mar 2019 19:56:30 -0500

--On Thursday, March 7, 2019 16:52 -0500 Alissa Cooper
<[email-masked]> wrote:

>>> Thanks. I still don't think this is quite right because
>>> there is no basis for this working group to obsolete or
>>> render historic RFC 3929 simply because it mentions the IETF
>>> Executive Director. It seems that RFC 3929 should be treated
>>> in Section 2 the same as the other documents in that section.
>> 
>> There's a more general issue: tracking down all "open"
>> Experimental RFCs and deciding which of them need to be
>> closed off as Historic or Obsolete or both. <joke>No doubt
>> the IESG will be doing this in its copious free time.</joke>
>> But for the present, doesn't it make more sense to clear both
>> 3929 and 4633 up right away? I agree that it's outside the
>> WG's mandate, strictly interpreted, but if the IESG consents,
>> is that really a problem?
> 
> Yes. The point of charters is to scope working groups' work.
> This working group is chartered to to document the normative
> changes to IETF administrative structures and processes
> necessary to effectuate the change to IASA 2.0. Obsoleting
> documents about other things because they are out of date is
> not within the charter.

Alissa,

I was in the process of putting together a discussion of the
IETF's history with making things Historic and then Brian's note
arrived and I concluded that maybe I was missing your main point
and I discarded that note.  We may have a small difference of
opinion about what it means to "scope working groups' work",
which I want to try to summarize below.

However, I, and I assume most WG participants, am much more
interested in getting this work finished than in arguing so, if
you are putting on your Responsible AD hat and telling me to
change this, I will certainly do so.

To me, there are two closely-related principles for charters and
limits on the scope of a WG's work:

(1) To be sure enough that the community is aware of what the WG
is doing so that IETF participants who are skilled in the topic
area(s) and materially concerned can either participate or
otherwise follow the WG's efforts and, in particular, are not
blindsided at IETF LC time or later.

(2) To lower the odds that the WG will go off in the weeds in a
major way, in particular by exceeding its competence and/or
taking up time that detracts from the overall planned schedule
or other tasks, and giving people who believe it is doing that a
basis for raising objections.

However, I think it is also important to keep some perspective
and flexibility on charters and scope if those principles are
not grossly violated.  One of the hallmarks of the IETF (and the
network specification development mechanisms long before it) has
been that it is far more important to get the right things to
happen and get the right things done than to go looking for
rules to interpret and enforce narrowly.  Some of us have even
argued in other contexts that, in addition to technical
advantages, much of the reason why the core technology for
modern networking is TCP/IP and related protocols as specified
by the IETF and its predecessor rather than, e.g., OSI, is
precisely that focus on getting the right things done rather
that spending disproportionate energy figuring out the letter of
the are and enforcing them.

So, in this particular case, the WG, working well within its
scope, discovered some now-problematic phrasing in 3929.   In
the process of figuring out how to fix that, it was observed
that the document was almost certainly no longer relevant.  The
conclusion, as I understood it, was that getting it off the list
of things that people were expected to read and understand would
be a more efficient fix than patching a phrase in a seriously
old document and perhaps creating confusion about whether the
specified experiment was still alive and relevant.  That is not
exceeding the WG's task area or competence, because almost
anyone could spot the relative obsolescence of the spec and the
problem was discovered in the process of doing the WG's work.
It didn't take extra time or effort.  Ted (the author), who
appears to be following the WG's work, didn't stand up and say
"no, no, that experiment is still active and the document is
still alive" and neither did anyone else.  I assume any such
substantive objection would have immediately killed the "make
Historic" plan.

So, yes, the decision could be to just patch the document
because making it Historic is not strictly within the WG's scope
but I don't see any possible harm that could result from just
getting 3929 off everyone's radar and out of the way.   In
addition, now that the problem has been identified and with a
nod to Brian's joke, do you really want to either get a request
for a WG or an individual submission to make 3929 Historic?
While I certainly would not want to advocate a hunting
expedition to identify and consider all of outstanding
Experimental documents and figure out which ones should be
Historic and/or Obsolete, in this case, the hard work of
identifying a relevant document and even writing an appropriate
sentence has been done already.

best,
    john

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 8 Mar 2019 06:30:35 -0500

Hi John,

> On Mar 7, 2019, at 7:56 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

Yes, I am.

Thanks,
Alissa

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Mar 2019 09:53:25 -0500

--On Friday, March 8, 2019 06:30 -0500 Alissa Cooper
<[email-masked]> wrote:

>...
>> interested in getting this work finished than in arguing so,
>> if you are putting on your Responsible AD hat and telling me
>> to change this, I will certainly do so.
> 
> Yes, I am.
> 
> Thanks,
> Alissa

I will try to find the time to make the changes and get a new
version up over the weekend.  For the record, I believe that a
single AD making a decision like this without offering evidence
of either WG or IETF consensus to be an abuse of power and hope
it does not set a precedent but, as suggested above, as far as
this document is concerned, I just want to move on.

regards,
   john

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 8 Mar 2019 11:08:26 -0500

Hi John,

> On Mar 8, 2019, at 9:53 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

The point of AD evaluation is to catch things like this. But if the WG chairs would like to issue a consensus call about whether this WG should do something outside its charter, I can wait to request the issuance of the IETF last call until that is done.

The evaluation of IETF consensus will occur after IETF last call has completed.

Thanks,
Alissa

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Mar 2019 11:39:00 -0500

--On Friday, March 8, 2019 11:08 -0500 Alissa Cooper
<[email-masked]> wrote:

>> single AD making a decision like this without offering
>> evidence of either WG or IETF consensus to be an abuse of
>> power and hope it does not set a precedent but, as suggested
>> above, as far as this document is concerned, I just want to
>> move on.
> 
> The point of AD evaluation is to catch things like this. But
> if the WG chairs would like to issue a consensus call about
> whether this WG should do something outside its charter, I can
> wait to request the issuance of the IETF last call until that
> is done.
> 

Alissa,

I don't want to drag this out and hope the WG Chairs and
Participants don't either.  However, to clarify my comment in
the light of your comment above, I think it is entirely
reasonable for you to call out your concern as part of AD review
and let the WG figure out what to do about that.  At the same
time, as a document editor who is just trying to follow WG
directions, I've got text that was put in at the direction of WG
participants confirmed by one of the co-chairs, that has been in
several consecutive I-Ds without, IIR, anyone in the WG
suggesting it be removed or restructured and certainly without
the co-chairs telling me to change it.  From that perspective, I
would have expected your comment/preference to trigger a WG
discussion and either different instructions to me from the WG
or a WG decision to push back.   In that context, the "abuse of
power" comment comes from your unilaterally telling me to change
text which I've assumed up to this point represents at least
rough WG consensus.

Separately, I think making decisions based on readings of a WG
charter that prevent a WG from addressing an issue discovered as
part of its work when that appears to be consistent with good
sense and the general intend of charter rules is a bad idea for
the IETF and that the precedents for it are, at best, mixed and
inconsistent.   But let's save that for another day.

best,
   john

---

From: Ted Hardie <[email-masked]>
Date: Fri, 8 Mar 2019 08:40:00 -0800

Comments in-line.

> substantive objection would have immediately killed the "make

Actually, the issue was raised by Robert, who was surprised at the
deprecation.  In my follow-up to Brian's message, I said this:

I don't see how the lack of experimental deadline makes it this WG's job to
>> decide--can you clarify your thinking?  In this document's case, it is hard
>> to call the experiment done when it has never been exercised.  We can say
>> that the threat of it has been useful, but that the actual methods are "not
>> proven" (in the Scots legal sense).
>>
>> My take on why they were included was more that they included the phrase
>> "IETF Executive Director"; the doc says that specific methods require
>> telling the IETF Executive Director something (e.g. that you volunteer to
>> serve).  The working group concluded that this didn't mean the new
>> Executive Director, but meant the Secretariat role that used that term
>> before.  I personally would fix that with an erratum, rather than
>> deprecation or obsolescence.
>>
>> I may, of course, have a slight bias here.
>>
>
If that was not clear that I thought that the document is still live; I
apologize.  As far as I can tell, the idea of this has helped, but the
methods have not been tested.  As a result, I don't think the document is
past its useful life.  Patching it seems sufficient.

Ted

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Mar 2019 12:18:21 -0500

Ted,

(top post)

Thanks.

This seems entirely reasonable to me and, unless Jason or Jon
direct otherwise, I will modify the document accordingly.  In
the event that it was not clear, what I've been objecting to was
a late command directive after the WG appeared to have made up
its mind.

It is a separate issue and clearly not within this WG's scope,
but experiments that run for 18 years (and counting) are unusual
in the IETF (and most other engineering work) and, IIR, the IESG
has argued against them several times.  If you believe it is
still live, I think it would be extremely desirable for you to
generate an update that discusses what has helped and why (or
if) the methods should be tested.  Ideally, such an update would
also bring it into line with current norms about experiments
that actually produce conclusions and end.

best,
   john

--On Friday, March 8, 2019 08:40 -0800 Ted Hardie
<[email-masked]> wrote:

>> >>> render historic RFC 3929 simply because it mentions the
>> >>> IETF Executive Director. It seems that RFC 3929 should be
>> >>> treated in Section 2 the same as the other documents in
>> >>> that section.
>> >> 
>> >> the IESG will be doing this in its copious free
>> >> time.</joke> But for the present, doesn't it make more
>> >> sense to clear both 3929 and 4633 up right away? I agree
>> >> that it's outside the WG's mandate, strictly interpreted,
>> >> but if the IESG consents, is that really a problem?
>> > 
>> IETF's history with making things Historic and then Brian's
>> note arrived and I concluded that maybe I was missing your
>> main point and I discarded that note.  We may have a small
>> difference of opinion about what it means to "scope working
>> groups' work", which I want to try to summarize below.
>> 
>> To me, there are two closely-related principles for charters
>> and limits on the scope of a WG's work:
>> 
>> (1) To be sure enough that the community is aware of what the
>> WG is doing so that IETF participants who are skilled in the
>> topic area(s) and materially concerned can either participate
>> or otherwise follow the WG's efforts and, in particular, are
>> not blindsided at IETF LC time or later.
>> 
>> (2) To lower the odds that the WG will go off in the weeds in
>> a major way, in particular by exceeding its competence and/or
>> or other tasks, and giving people who believe it is doing
>> that a basis for raising objections.
>> 
>> not grossly violated.  One of the hallmarks of the IETF (and
>> the network specification development mechanisms long before
>> it) has been that it is far more important to get the right
>> things to happen and get the right things done than to go
>> looking for rules to interpret and enforce narrowly.  Some of
>> us have even argued in other contexts that, in addition to
>> technical advantages, much of the reason why the core
>> technology for modern networking is TCP/IP and related
>> protocols as specified by the IETF and its predecessor rather
>> than, e.g., OSI, is precisely that focus on getting the right
>> things done rather that spending disproportionate energy
>> figuring out the letter of the are and enforcing them.
>> 
>> that the document was almost certainly no longer relevant.
>> The conclusion, as I understood it, was that getting it off
>> the list of things that people were expected to read and
>> understand would be a more efficient fix than patching a
>> phrase in a seriously old document and perhaps creating
>> confusion about whether the specified experiment was still
>> alive and relevant.  That is not exceeding the WG's task area
>> or competence, because almost anyone could spot the relative
>> obsolescence of the spec and the problem was discovered in
>> the process of doing the WG's work. It didn't take extra time
>> or effort.  Ted (the author), who appears to be following the
>> WG's work, didn't stand up and say "no, no, that experiment
>> is still active and the document is still alive" and neither
>> did anyone else.  I assume any such substantive objection
>> would have immediately killed the "make Historic" plan.
>> 
> 
> Actually, the issue was raised by Robert, who was surprised at
> the deprecation.  In my follow-up to Brian's message, I said
> this:
> 
>>> decide--can you clarify your thinking?  In this document's
>>> case, it is hard to call the experiment done when it has
>>> never been exercised.  We can say that the threat of it has
>>> been useful, but that the actual methods are "not proven"
>>> (in the Scots legal sense).
>>> 
>>> My take on why they were included was more that they
>>> included the phrase "IETF Executive Director"; the doc says
>>> that specific methods require telling the IETF Executive
>>> Director something (e.g. that you volunteer to serve).  The
>>> working group concluded that this didn't mean the new
>>> Executive Director, but meant the Secretariat role that used
>>> that term before.  I personally would fix that with an
>>> erratum, rather than deprecation or obsolescence.
>>> 
> If that was not clear that I thought that the document is
> still live; I apologize.  As far as I can tell, the idea of
> this has helped, but the methods have not been tested.  As a
> result, I don't think the document is past its useful life.
> Patching it seems sufficient.
> 
> Ted
> 
> 
>> 
>> because making it Historic is not strictly within the WG's
>> scope but I don't see any possible harm that could result
>> from just getting 3929 off everyone's radar and out of the
>> way.   In addition, now that the problem has been identified
>> and with a nod to Brian's joke, do you really want to either
>> get a request for a WG or an individual submission to make
>> 3929 Historic? While I certainly would not want to advocate a
>> hunting expedition to identify and consider all of outstanding
>> identifying a relevant document and even writing an
>> appropriate sentence has been done already.
>> 
>> best,
>>     john
>>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 11 Mar 2019 02:37:43 +0000

John - Thanks in advance for updating the doc. Hoping we can then keep moving in the processing of the doc after that.

JL

On 3/8/19, 12:18 PM, "iasa20 on behalf of John C Klensin" <[email-masked] on behalf of [email-masked]> wrote:

    Ted,
    
    (top post)
    
    Thanks.

    
    best,
       john