Subject: Re: [Iasa20] draft-ietf-iasa2-rfc2418bis-01.txt

From: John C Klensin <[email-masked]>
Date: Sat, 20 Oct 2018 16:18:16 -0400

Hi.

For whatever it is worth, I've very concerned about the IASA2
effort sliding over into replacement of fundamental process
documents.  RFC 2418, like 2026, is showing its age.  If we are
going to revise it, it seems to me that there is a very good
case for a comprehensive comparison of actual practices today
with the text and document revisions as appropriate and not
publishing a new document in which descriptions of obsolete
practices are repeated.   

As one example among many, the BOF description of 2418 still
discusses the decision to hold a BOF as one that can be made by
a single AD while today's procedure involves formal applications
on a community-wide schedule, IAB and IESG review, etc.  We've
also relaxed the "only once or possibly a second time but never
three" rule.   

As another, RFC 2418 calls for explicit disclosure of conflicts
of interest but points to RFC 2028/ BCP 11 which, AFAICT, only
discusses IPR rights.  In today's Internet and IETF, that would
seem to call for some review and perhaps some comments about AD
<-> WG Chair relationships.  And, as a third, at the time 2418
was written, saying that we do things by rough consensus was
adequate (or at least believed to be adequate).  Today, we've
got RFC 7282, which should probably be referenced, and a
collection of other documents and procedures that interact
significantly with how WGs do their work, how people
participate, and how conclusions are reached.

Those are not the only examples.

Most of those are not huge issues, but it does not seem
appropriate to issue a document that replaces / obsoletes 2418
without addressing them (and several others).

In addition, replacing fundamental IETF process documents
appears to be clearly outside the scope of the IASA2 effort.
The last paragraph of the WG charter begins:

	"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 only sense in which this work "presently relates to IASA" is
the title of the IETF Executive Director.  The I-D affirms that
by listing that as the only non-"insignificant" change from
2418.  The new term appears exactly once in this draft and the
old one appeared exactly once in 2418.  It might make sense to
completely replace 2418 if it appeared many times and was
tightly woven in the text, but it isn't. 

FWIW, there are also a number of (other) obsolete references or
missing references in this I-D.  Given that they authors have
not found and fixed them by -01, getting them out presumably
implies extra work for them and the community.

I strongly suggest that, 

 -- to avoid reissuing a fundamental process document and
	thereby explicitly reaffirming procedures and mechanisms
	that do not precisely align with current practices,
 -- to avoid creating confusion about the status of every
	document that references these old process documents, 
 -- to avoid the risks of a supposedly insignificant
	change actually having some substantive consequences,
	and 
 -- to reduce the number of documents and page count
	coming out of the IASA2 WG and process so the community
	can concentrate on reviewing changes that actually are
	important,

this I-D and any others for which the changes to the relevant
base documents are limited to updating a title (or something
equally trivial) be replaced by a single "IASA2-related
terminology update" draft that simply lists the replacement
terms and the documents that are updated to reflect them. I
haven't made a careful study, but it appears to me after quick
glances that a "gather together into one document and update
only the terminology" model could include 3005bis, possibly
4844bis, and perhaps others.

    john

--On Saturday, October 20, 2018 09:47 -0700
[email-masked] wrote:

> 
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories. This draft is a work item of the
> IETF Administrative Support Activity 2 WG of the IETF.
> 
>         Title           : IETF Working Group Guidelines and
> Procedures         Authors         : Scott Bradner
>                           Rich Salz
> 	Filename        : draft-ietf-iasa2-rfc2418bis-01.txt
> 	Pages           : 27
> 	Date            : 2018-10-20
> 
> Abstract:
>    The Internet Engineering Task Force (IETF) has
> responsibility for    developing and reviewing specifications
> intended as Internet    Standards.  IETF activities are
> organized into working groups (WGs).    This document
> describes the guidelines and procedures for formation    and
> operation of IETF working groups.  It also describes the formal
>    relationship between IETF participants WG and the Internet
>    Engineering Steering Group (IESG) and the basic duties of
> IETF    participants, including WG Chairs, WG participants,
> and IETF Area    Directors.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Oct 2018 10:07:52 +1300

fwiw I agree. There is no reference to IASA in 2418, for obvious reasons.

>From a practical point of view, any terminology issue could be handled
as an erratum with disposition "wait for update".

Regards
   Brian

On 2018-10-21 09:18, John C Klensin wrote:
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 20 Oct 2018 17:27:18 -0400

> as an erratum with disposition "wait for update".

That, IMO, would be an even better solution than creating an
updating document that says "any time earlier documents say
'IETF Executive Director' replace it with..." and similar things
and then hunting down the relevant documents and marking them as
updated.  

Depending on how compulsive the WG and relevant AD are feeling,
I think either would work.  But we really have better ways to
spend our time than replacing a process document to change a
title... or at least I hope we do.  

Frankly, the only good reason I can see for generating all of
these IASA2 documents just to change terminology is to create
enough noise that the community doesn't notice and pay attention
to changes that actually might be controversial.   I trust and
assume that is not the intent of anyone involved.

    john

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sat, 20 Oct 2018 18:45:25 -0400

sure seems a lot more efficient to just have one short RFC instead of a bunch of RFCs that wind
up changing well known RFC #s for almost no meaningful changes - i

(never mind having to change training documents to point to the changed RFC numbers)

Scott

> On Oct 20, 2018, at 5:27 PM, John C Klensin <[email-masked]> wrote:
> 
> 
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 21 Oct 2018 00:03:15 +0000

FWIW, I haven't seen that happening.

There's another explanation, that makes more sense to me.  Our field is full of perfectionist, completist, OCD-types and we're trying to just line everything up with the new terminology/organization.

I agree that there is more to a real 2418-bis than just changing the IETF director's title.

---

From: Bob Hinden <[email-masked]>
Date: Sun, 21 Oct 2018 08:39:33 -0700

Scott,

> On Oct 20, 2018, at 3:45 PM, Scott O. Bradner <[email-masked]> wrote:
> 

I think it depends on the document.   While there are some that could be handled this way, others are more complicated.  For example, Jason and I are working on RFC7437bis " IAB,IESG, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees”.   That’s gotten more complicated because the IETF Trust Trustees and LLC Directors are being (partially) selected by the NomCom under the IASA2.0 work.  The changes are not, for example, s/IAOC/LLC/.  There are other changes that make sense like having the chairs communicate direclty with the NomCom instead it going through the IETF Executive Director (now called Managing Director, IETF Secretariat).  Now starting to look at bringing in the Ombudsman changes from RFC7776.

I suspect we are going to have the new ISAS 2 model for a while, good to get this right where it matters.

Bob

---

From: John C Klensin <[email-masked]>
Date: Sun, 21 Oct 2018 12:00:03 -0400

--On Sunday, October 21, 2018 00:03 +0000 "Salz, Rich"
<[email-masked]> wrote:

> There's another explanation, that makes more sense to me.  Our
> field is full of perfectionist, completist, OCD-types and
> we're trying to just line everything up with the new
> terminology/organization.

Sure.  And that was exactly why I didn't push back on other
documents, including 6220bis.  It seemed reasonable to just
mumble into my beard and let it go.  However, if one looks at
2418 that explanation is an even stronger argument for asking
"are we really ready to open and revise 2418?"   The current I-D
would presumably be offensive to "perfectionist, completist,
OCD-types" because references that almost certainly belong there
are not, statements are made that don't align with contemporary
reality, etc.

> changing the IETF director's title.

Exactly.  But we don't have an RFC category for "not-real"
2418bis (or anything else).  So, if you are going to replace
("obsolete") 2418, you have some obligation to address those
issues.

Just to give further examples of where this is headed: 

I note that your text reflects Erratum 3752 (but does not
reflect that in Appendix B in spite of the fact that change is
not insignificant.  However, the "Mailing list" subsection in
which the change was made describes IETF-hosted mailing lists
"as a service to the community" and seems to encourage lists
hosted elsewhere.  My understanding of current practice is that,
in order to keep archival records, we strongly discourage WG
lists hosted on other than the IETF site.  Similarly and
especially given the recent changes in mail archives, pointing
to a list of FTP repositories does not seem optimal.

Even more important, RFC 7475 changed 2418 to allow for more
than two ADs per area.  Your I-D, however, contains the original
text from 2418.  Since the text has not been adjusted to reflect
7475 (and update it to note that the change to 2418 --as
distinct from the 2026 one-- is OBE), I assume that, if the I-D
were adopted, as is, as 2418bis, the third AD in any area that
had more than two would be forced to immediately step down.

It seems to me that you, Scott, and the WG have three possible
choices:

(1) Put in the effort to get this document right as either a
"real 2418bis" or a document that obsoletes 2418 but explains
all of the loose ends _and_ risk an appeal if the document goes
to IETF Last Call on the grounds that it violates a very
explicit provision of the WG Charter.  See Scott's note about
this too.

(2) Either issue a trivial RFC that updates 2418 to change the
position title and does nothing else or that, less trivially,
makes many or all of the needed changes like this to multiple
RFCs.

(3) Follow the example of the RFC Editor, the POISSON WG, and
Erratum 3752 and treat the title as a simple editorial change to
be noted for future revisions of 2418 if and when they occur.

Noting that the third requires zero additional effort by
authors/editors, the WG, or the community and that the first is
risky and requires a good deal more work than either of the
others, I think I know what application of good sense suggests
about a preference order.  YMMD.

    john

---

From: John C Klensin <[email-masked]>
Date: Sun, 21 Oct 2018 12:11:41 -0400

Bob,

I don't think Scott suggested a consolidated update to all of
these documents.  Having started this thread, I certainly
didn't.   If there is a substantive reason to rework a document,
by all means do that... especially if the scope of the original
document is very narrow.  However, if the only change that is
required to a given document simple substitution, especially in
one place and especially if the document has very broad scope,
let's try to find a way to do a narrow update rather than
replacing/obsoleting the document.

Like Scott, I hope that could be done by a single document that
draws all of the trivial updates together.  But, if it cannot, I
believe we would be far better off with, using 2418 as an
example, with a one (substantive)-paragraph RFC changing the job
title rather than issuing a new, supposedly-complete, document
and obsoleting the original one.  That also minimizes the risk
of unintended consequences.  Or, while I had forgotten until
Rich's note caused me to review the history of 2418, for these
trivial cases, we could simply follow the POISSON/RFC Editor
precedent, treat the change of title as a simple editorial
matter, record it in an erratum identified as "save for
revision", and move on.  

If one wants to minimize the amount of community effort spent
per unit improvement, the latter is almost certainly the right
option for those simple cases.

  best,
     john

--On Sunday, October 21, 2018 08:39 -0700 Bob Hinden
<[email-masked]> wrote:

>> sure seems a lot more efficient to just have one short RFC
>> instead of a bunch of RFCs that wind up changing well known
>> RFC #s for almost no meaningful changes - i
> 
> I think it depends on the document.   While there are some
> that could be handled this way, others are more complicated.
> For example, Jason and I are working on RFC7437bis " IAB,IESG,
> and IETF LLC Selection, Confirmation, and Recall Process:
> Operation of the IETF Nominating and Recall Committees".
> That's gotten more complicated because the IETF Trust
> Trustees and LLC Directors are being (partially) selected by
> the NomCom under the IASA2.0 work.  The changes are not, for
> example, s/IAOC/LLC/.  There are other changes that make sense
> like having the chairs communicate direclty with the NomCom
> instead it going through the IETF Executive Director (now
> called Managing Director, IETF Secretariat).  Now starting to
> look at bringing in the Ombudsman changes from RFC7776.
> 
> I suspect we are going to have the new ISAS 2 model for a
> while, good to get this right where it matters.
> 
> Bob
> 
>> 
>>> 'IETF Executive Director' replace it with..." and similar
>>> things and then hunting down the relevant documents and
>>> marking them as updated.
>>> 
>>> Depending on how compulsive the WG and relevant AD are
>>> feeling, I think either would work.  But we really have
>>> better ways to spend our time than replacing a process
>>> document to change a title... or at least I hope we do.
>>> 
>>> enough noise that the community doesn't notice and pay
>>> attention to changes that actually might be controversial.
>>> I trust and assume that is not the intent of anyone involved.
>>> 
>>>   john
>>> 
>>> 
>>> 
>>

---

From: Scott Bradner <[email-masked]>
Date: Sun, 21 Oct 2018 12:38:42 -0400

agree - all docs are not equal

Scott

> On Oct 21, 2018, at 11:39 AM, Bob Hinden <[email-masked]> wrote:
> 
> Scott,
>

---

From: Scott Bradner <[email-masked]>
Date: Sun, 21 Oct 2018 12:39:32 -0400

+1

> On Oct 21, 2018, at 12:11 PM, John C Klensin <[email-masked]> wrote:
> 
> Bob,
>

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 22 Oct 2018 05:43:30 -0400

I think 2418 can be covered under the “others can be grouped into one or a small number of documents that update several other RFCs at once” category at https://github.com/IASA2/Miscellaneous/blob/master/Document%20Work%20List.md. There are a bunch of other docs on that list for which that isn’t the right answer though.

Alissa

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Oct 2018 07:05:44 -0600

+1

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 22 Oct 2018 14:19:30 +0000

That seems a rather odd claim. We've been very straightforward in our plans for updating these docs every step of the way, including by suggesting to the WG which ones needed to be updated, calling to adopt their update, asking for volunteers to do so, etc.

Jason

On 10/20/18, 5:27 PM, "iasa20 on behalf of John C Klensin" <[email-masked] on behalf of [email-masked]> wrote:

        john

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 22 Oct 2018 14:23:09 +0000

We debated the update tactic some months ago. It seemed whatever path we took, we might be criticized but we had to pick one. This is very nearly the final document in that long list, so it is interesting that its really only one of the last few to see this issue raised. Of course it seems quite possible we'll now spend more time debating it on email lists that it'd take to produce the document updates. ;-) 

JL

On 10/20/18, 6:45 PM, "iasa20 on behalf of Scott O. Bradner" <[email-masked] on behalf of [email-masked]> wrote:

    
Scott

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 22 Oct 2018 14:25:05 +0000

Thanks, Alissa, we’ll take a look and assess this.

Jason

From: ietf <[email-masked]> on behalf of Alissa Cooper <[email-masked]>
Date: Monday, October 22, 2018 at 5:44 AM
To: John C Klensin <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Iasa20] draft-ietf-iasa2-rfc2418bis-01.txt

Alissa

On Oct 20, 2018, at 5:27 PM, John C Klensin <[email-masked]<mailto:[email-masked]>> wrote:

--On Sunday, October 21, 2018 10:07 +1300 Brian E Carpenter
<[email-masked]<mailto:[email-masked]>> wrote:

fwiw I agree. There is no reference to IASA in 2418, for
obvious reasons.

From a practical point of view, any terminology issue could
be handled
as an erratum with disposition "wait for update".

  john

_______________________________________________
iasa20 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/iasa20

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Oct 2018 14:01:00 -0400

Jason,

For perspective, I think there is a longstanding problem with
IETF procedural work.   I don't know how typical I am, but, in
recent years, I've ended up with very little time to spend on
IETF work.  Both personal preferences and my perceptions of the
best interests of the Internet lead me to try to spend as large
a portion of that time as possible on substantive work rather
than procedures.  So, although I'm on the WG mailing list, I
looked at the WG Charter and early discussions, accepted the
explanation that this was about a largely technical change from
the original "ISOC activity" model and corresponding IASA
structure to a semi-separate LLC and the things that implies and
the promise in the charter that the effort would have no effect
one IETF procedures, and have not been paying in-depth
attention.   I'm still not convinced that the changes are worth
the trouble but, if the IESG and those who are active in the WG
are convinced --and convinced you can get it right-- my attitude
has been "go for it and I'll go spend my time on substantive
technical work".

However, that approach is conditioned on the WG being able to
get all of it right.  Whether to adjust the terminology of 2418
by update or replacement is a matter of taste and I'm happy to
defer to the WG's consensus taste... However, if the WG manages
to demonstrate that it can't produce an update to 2418 without
unintended side effects or pushing the boundaries of the
contract with the community implied by the charter, at least
without significantly more effort than has been invested so far,
then, as I see it, the balance changes from "WG choice" to
"better go the update" route.   And, fwiw, while it is late in
your process, you are, IMO at least, far better off finding that
out now than getting the same feedback during IETF Last Call
(potentially including appeals from the Last Call itself because
the document fell outside the WG Charter into areas that would
have drawn people who would have participated more actively in
the WG effort had changes to IETF procedures been on the agenda).

So, while I should have been doing other things, I've spent much
of today looking at another document or two that might have been
candidates for the "update" approach.  For better or worse, I've
found the same sort of issues that I found with 2418bis: changes
that should have been made if the document was to be a
replacement, a substantive error or two, q0uestions about
whether IETF procedures for document approval were being
changes, and difficulties with longstanding rules about
replacement ("obsoleting") documents.   In at least one case,
the document has cleared WGLC but, given those issues, is
clearly not ready for IETF LC.   

IMO, two documents with problems of this sort, including one
that the WG was prepared to sign off on, takes the substantive
part of the replace vs. update choice out of the realms of both
"WG preference" and "isolated example".  

So, too bad this is late.  And too bad it is going to require
more work.  However, it seems to me that we are better of
catching these things now rather than later... and I hope that
it does not suggest that we need to ask ourselves fundamental
questions about the quality of the WG process in assembling and
reviewing other documents.  

I sincerely hope you can avoid blaming the messengers.

best,
   john

--On Monday, October 22, 2018 14:23 +0000 "Livingood, Jason"
<[email-masked]> wrote:

> We debated the update tactic some months ago. It seemed
> whatever path we took, we might be criticized but we had to
> pick one. This is very nearly the final document in that long
> list, so it is interesting that its really only one of the
> last few to see this issue raised. Of course it seems quite
> possible we'll now spend more time debating it on email lists
> that it'd take to produce the document updates. ;-)

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Mon, 22 Oct 2018 15:35:27 -0400

These kinds of updates are not in scope for this WG, it seems to me.

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Oct 2018 15:55:53 -0400

For clarification, which kinds of updates?   Updating a document
to reflect different organizational structure clearly is in
scope.  Whether replacing the document (rather than updating it
with a new document) is in scope seems to me to be simply a
different choice as long as the replacement document meets two
conditions:

(1) It does not leave a lot of loose ends in terms of references
to the original document, existing updates to the original
document, or other things that would create confusion and best
and contradictory requirements at worst.

(2) It does not make "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."  (quoting from the last paragraph of the charter
at https://datatracker.ietf.org/doc/charter-ietf-iasa2/ )

My main difficulty with the 2814bis I-D is that it seems to
create issues with both (1) and (2) above.  My main difficulty
with 5377bis is that it _may_ be a problem with (2).   Both also
contain a number of errors, some at the nit-picking level and
others not, but those are not scope issues.

Watch for draft-klensin-iasa2-2418upd-5377upd-00, which should
provide a better idea of what I have in mind as a
clearly-in-scope alternative than my ranting.

   best,
     john

--On Monday, October 22, 2018 15:35 -0400 Joseph Lorenzo Hall
<[email-masked]> wrote:

>> IETF work.  Both personal preferences and my perceptions of
>> the best interests of the Internet lead me to try to spend as
>> large a portion of that time as possible on substantive work
>> rather than procedures.  So, although I'm on the WG mailing
>> list, I looked at the WG Charter and early discussions,
>> accepted the explanation that this was about a largely
>> technical change from the original "ISOC activity" model and
>> corresponding IASA structure to a semi-separate LLC and the
>> things that implies and the promise in the charter that the
>> effort would have no effect one IETF procedures, and have not
>> been paying in-depth attention.   I'm still not convinced
>> that the changes are worth the trouble but, if the IESG and
>> those who are active in the WG are convinced --and convinced
>> you can get it right-- my attitude has been "go for it and
>> I'll go spend my time on substantive technical work".
>> 
>> get all of it right.  Whether to adjust the terminology of
>> 2418 by update or replacement is a matter of taste and I'm
>> happy to defer to the WG's consensus taste... However, if the
>> WG manages to demonstrate that it can't produce an update to
>> 2418 without unintended side effects or pushing the
>> boundaries of the contract with the community implied by the
>> charter, at least without significantly more effort than has
>> been invested so far, then, as I see it, the balance changes
>> from "WG choice" to "better go the update" route.   And,
>> fwiw, while it is late in your process, you are, IMO at
>> least, far better off finding that out now than getting the
>> same feedback during IETF Last Call (potentially including
>> appeals from the Last Call itself because the document fell
>> outside the WG Charter into areas that would have drawn
>> people who would have participated more actively in the WG
>> effort had changes to IETF procedures been on the agenda).
>> 
>> So, while I should have been doing other things, I've spent
>> much of today looking at another document or two that might
>> have been candidates for the "update" approach.  For better
>> or worse, I've found the same sort of issues that I found
>> with 2418bis: changes that should have been made if the
>> document was to be a replacement, a substantive error or two,
>> q0uestions about whether IETF procedures for document
>> approval were being changes, and difficulties with
>> longstanding rules about replacement ("obsoleting")
>> documents.   In at least one case, the document has cleared
>> WGLC but, given those issues, is clearly not ready for IETF
>> LC.
>> 
>> part of the replace vs. update choice out of the realms of
>> both "WG preference" and "isolated example".
>> 
>> questions about the quality of the WG process in assembling
>> and reviewing other documents.
>> 
>> > pick one. This is very nearly the final document in that
>> > long list, so it is interesting that its really only one of
>> > the last few to see this issue raised. Of course it seems
>> > quite possible we'll now spend more time debating it on
>> > email lists that it'd take to produce the document updates.
>> > ;-)
>> 
>> 
>> 
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2018 09:28:58 +1300

> These kinds of updates are not in scope for this WG, it seems to me.

Nobody is suggesting otherwise, and those of who are veterans of various
attempts to update the fundamental IETF process documents take this lightly.
(That's why I created what is now https://www.ietf.org/standards/process/informal/)

IASA is not fundamental in that sense.

So, it seems to me that this WG's competence is limited to patching
terminology in those fundamental documents, and that is best done
by errata and patch documents in most (but not all) cases.

   Brian

---

From: Scott Bradner <[email-masked]>
Date: Mon, 22 Oct 2018 17:08:36 -0400

this is a separate issue about the iasa2 proposed updates

come on - you update an RFC without including a section that says what changes you are making???

are you purposely trying to make it harder for IETF participants to understand what’s going on?

every RFC that updates another RFC needs (MUST?) have a section that tells the reader what has
changed - this is vital for any technical speck so the implementor knows what they have to change in
their implementation but its also very important in process documents so participants can understand 
if they need to change how they do things

so, be nice to the participants and admit (in writing) what changes you are proposing

Scott

---

From: Scott Bradner <[email-masked]>
Date: Mon, 22 Oct 2018 17:17:49 -0400

in addition you need to say why changes are being made - for example Joel mentioned that the appeals process
is being removed from 5377 

5377 says "the appeals procedure documented in BCP 101 (currently [RFC4371]) is applicable.” 

this text has been removed from the bis ID -

what does this mean?  is the new board immune from all review other than noncom at end of term?
suddenly do we have an imperial board?

without some explanation should people worry on just what planet has the iasa2 WG has been?

so please update the IDs with a changes section that says what & why for each proposed change

Scott

> On Oct 22, 2018, at 5:08 PM, Scott Bradner <[email-masked]> wrote:
>

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 22 Oct 2018 17:28:31 -0400

Hi,

I wanted to remind everyone that the IASA2 WG has requested publication of a total of two documents so far. All of the rest of the documents are still under discussion in the working group and will be undergoing IETF last call only after the WG requests publication and I do AD reviews. I would encourage people to continue making constructive suggestions for how to improve the documents in the WG and avoid making assumptions about authors’ motivations. Thus far we’ve had a great constructive dialogue with lots of people chipping in to do this less-than-thrilling administrative work, which is very much appreciated.

Regards,
Alissa

---

From: Scott Bradner <[email-masked]>
Date: Mon, 22 Oct 2018 17:32:30 -0400

full explanations (in the documents) keeps people from having to make assumptions
I do not want to be driven to making assumptions which is why I’m asking for explanations in the documents 

Scott

> On Oct 22, 2018, at 5:28 PM, Alissa Cooper <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 17:47:12 -0400

I have no problem adding a section taht says we removed the appeals 
chain as we could not find a suitable and legal target for it.

As for whether that will answer any question about what that means?  I 
doubt it will.  Will it address any concerns about creating an imperial 
trust?  If the trust were responsible for standardization or IETF 
process, I would have serious concerns.  If I had a good answer for 
where an appeal could point, I would at least ask the lawyers if we 
could legally do that.
lacking either urgency from impact or a better answer, I don't know what 
you want done.

Regarding quietly chaning this, I was carefully not quiet.  I explicitly 
notified the working group of the concern when I first posted.  There 
was discussion on the working group list.  The chairs, as is their job, 
drew a conclusion from the discussion, and I implemented it.  This was 
unaffected by the fact that folks are not reading a lot of the document 
revisions (a charge to which I plead guilty.)

Yours,
Joel

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 22 Oct 2018 17:58:57 -0400

Thanks

Helpful

Scott 

Sent from my iPhone

> On Oct 22, 2018, at 5:47 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> I have no problem adding a section taht says we removed the appeals chain as we could not find a suitable and legal target for it.
> 
> As for whether that will answer any question about what that means?  I doubt it will.  Will it address any concerns about creating an imperial trust?  If the trust were responsible for standardization or IETF process, I would have serious concerns.  If I had a good answer for where an appeal could point, I would at least ask the lawyers if we could legally do that.
> lacking either urgency from impact or a better answer, I don't know what you want done.
> 
> Regarding quietly chaning this, I was carefully not quiet.  I explicitly notified the working group of the concern when I first posted.  There was discussion on the working group list.  The chairs, as is their job, drew a conclusion from the discussion, and I implemented it.  This was unaffected by the fact that folks are not reading a lot of the document revisions (a charge to which I plead guilty.)
> 
> Yours,
> Joel
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 22 Oct 2018 23:51:31 +0000

Echoing Alissa's note: it is nice to have some additional and quite experienced eyes on these documents. It's not a sexy or fun thing to work on, for sure, but important nonetheless. 

In any case, having specific feedback on what to improve or challenge, particularly when offered in such a succinct a way as you have below, is always appreciated and will make the eventual work product better in the end.

JL

On 10/22/18, 5:34 PM, "ietf on behalf of Scott Bradner" <[email-masked] on behalf of [email-masked]> wrote:

    Scott

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 23 Oct 2018 00:17:16 +0000

On 10/22/18, 4:30 PM, "iasa20 on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

[JL] Thanks for offering your experienced perspective on that. We've done some update/replace work and more recently filed errata. We'll certainly take a look at that again to see if there are cases where it may be better. In some cases it genuinely will be so, while perhaps in others it is a matter that could equally go one or the other direction.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 23 Oct 2018 08:39:07 -0700

Scott,

> On Oct 22, 2018, at 2:08 PM, Scott Bradner <[email-masked]> wrote:
> 

I agree, a documents that updates another RFC should be very clear about what is being updated.  For example, RFC 8318 is very clear what it was updating in RFC7437, see Section 3.1.   This was very helpful in working on RFC7437bis.

> are you purposely trying to make it harder for IETF participants to understand what’s going on?

I don’t think anyone is trying to do this.  I think "Hanlon's razor” applies here :-)

Bob