Subject: [Iasa20] Issues with draft-ietf-iasa2-rfc5377bis-01

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

Hi.

While this document (draft-ietf-iasa2-rfc5377bis-01, "Advice to
the Trustees of the IETF Trust on Rights to Be Granted in IETF
Documents") has cleared Working Group Last Call, I suggest its
current condition demonstrates that no one read it carefully and
possibly that the author was working a bit too quickly
(something I'm much more often guilty of than Joel is so, if
that is even part of the problem, he has my sympathy).

In particular observe the following:

(1) The header indicates that this I-D, if approved, obsoletes
RFC 5741.  It actually has little or nothing to do with RFC 5741
and does not either mention or reference it in the text.  We can
infer from the I-D name that it is actually intended to obsolete
RFC 5377.

(2) While there has been a good deal of discussion about how
much detail should be required and where in a document it should
be required to appear, there has been a long-standing rule that
documents that obsolete or update others MUST explain what they
have done and summarize the changes.   This I-D does not discuss
the changes made to RFC 5377 or even reference it (or, for that
matter, 5741).  

(3) With one possible exception, the changes themselves border
on the trivial, although not quite as trivial as the one
discussed in the thread about 2418bis.  Some of them are
incorrect.   Portions of two sentences binding the Trustees to
the IAOC are dropped and replaced by nothing.  A
wholly-redundant reference is added for the Trust License Policy
(probably "http" should be changed to "https" in line with
current policies, but it wasn't).  A change was made to the date
of RFC 5378 (which is incorrect).  A DOI is added to one RFC
reference but not to the other.  A now-unneeded reference is
dropped and the author's address is slightly updated.   Finally,
a sentence is dropped that specifies the procedure for appeals
from actions of the Trustees.  That, even more than the other
changes, calls for either substitute text, a comment, or both.
If the appeals procedure is covered by other documents, they
should at least be referenced.  Also if it is being changed,
that would appear to violate the WG charter's promise to not
make substantive changes to IETF procedures.

I believe this document constitutes another example of the issue
that has recently been discussed in the context of
draft-ietf-iasa2-rfc2418bis-01: the right solution is to simply
update the original document (RFC 5377 in  this case) to make
the changes that are actually necessary rather than replacing
that document.  As with 2418bis, this is less an aesthetic
choice (or a set of issues that should have been anticipated
when the decision to replace rather than update was made) than a
matter of potential unintended side effects of a replacement
document and the difficulties associated with getting one of
those right.

While I am certain that there are documents in the IASA2
collection that involve enough substantive changes that they
should be replaced (and, I hope, carefully checked), I have no
reason to believe that the corrections/changes needed to 2418
and 5377 make them the only ones that would better be dealt
with, even at this late date, by dealing with them on an
"updates" basis.

I should have an I-D posted before the cutoff to provide the WG
with more of a foundation for examining the issues and how to
proceed.

best,
  john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 15:46:53 -0400

1) I typoed when I added the obsoletes clause.  It should obsolete 5377. 
  You are correct.

2) It sounds like you are asking for an appendix "changes since 5377". 
It would say "1: replaced most references to IAOC with references to 
IETF LLC.  2: removed inapplicable references to the IAOC. 3: removed 
the appeals procedure."

3) The changes to the references are because of changes to the reference 
library.  Due to history, the 5378 reference does not use the library 
and the 3935 reference does.  I can change the 5378 reference to a 
libary based BCP 78 if you think it matters.
3') I can change the http to an https, if that is correct for the 
trustee policy reference.  I left it as it was in the earlier versions.

I am a bit confused as to your concerns other than typos and form with 
this document.  Unlike concerns about some of the other documents, this 
does not mis-describe any of our current procedures.
And by the time one was done being explicit about the places to replace, 
the places to delete, and the one policy change of removing teh appeals 
procedure, you would have almost as much text as the document.

Yours,
Joel

On 10/22/18 3:04 PM, John C Klensin wrote:
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Oct 2018 16:18:54 -0400

--On Monday, October 22, 2018 15:46 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> 1) I typoed when I added the obsoletes clause.  It should
> obsolete 5377.   You are correct.

I sort of assumed that is what happened.

> 2) It sounds like you are asking for an appendix "changes
> since 5377". It would say "1: replaced most references to IAOC
> with references to IETF LLC.  2: removed inapplicable
> references to the IAOC. 3: removed the appeals procedure."

Understood and I had deduced that from a careful (and
time-consuming) comparison of the I-D with 5377.  However,
regardless of what I'm asking for, the IESG has been fairly
consistently bounding documents that do no contain an
explanation of what has been changed (the most extreme reading
of the relevant policy requires at least a pointer to the
information in the Abstract and that the information itself be
in the body of the document, probably the introduction. rather
than an appendix.  I'm not a huge fan of rigidity on that
subject, but the information should be there if you are going to
replace the original.   And, while the other changes are clearly
justified by the IASA2 effort, removing the appeals text
requires, IMO, some explanation because, if any actual change is
implied, it puts the draft outside the scope of the IASA2 WG.

> 3) The changes to the references are because of changes to the
> reference library.  Due to history, the 5378 reference does
> not use the library and the 3935 reference does.  I can change
> the 5378 reference to a libary based BCP 78 if you think it
> matters.

It am happy to leave that to the RFC Editor.  It was just
another anomaly.  See below.

> 3') I can change the http to an https, if that is correct for
> the trustee policy reference.  I left it as it was in the
> earlier versions.

I did check and there is an https-accessible version.  More
nit-picking.  Again, see below.

> I am a bit confused as to your concerns other than typos and
> form with this document.  Unlike concerns about some of the
> other documents, this does not mis-describe any of our current
> procedures.
> And by the time one was done being explicit about the places
> to replace, the places to delete, and the one policy change of
> removing teh appeals procedure, you would have almost as much
> text as the document.

I had two or three concerns:

(i) That replacing documents, rather than updating them, would
introduce errors or other issues, even if (as in this case)
those errors could be easily fixed once identified.   That is,
to some degree, a "more text with potential changes, more
opportunity for problems" concern rather than anything more
complicated.

(ii) If the removal of the appeals text is actually a policy
change (I have not done enough research to be convinced it is,
but you say that above), it is explicitly prohibited in an IASA2
document by the IASA2 charter (see recent note to Joseph Lorenzo
Hall).

(iii) For whatever reason, these documents are not getting
careful review within the WG.   While easily fixed, the
observation that this I-D got through WG LC without that
"updates" typo being spotted, without a normative reference to
the earlier document, and without even a minimal explanation of
the changes and the reasons for them should be of concern to all
of us, especially those who are inclined to believe that, if a
WG was ok with a document that is not of special interest to
them, they should just let it go at IETF LC.

As to the "almost as much text as the document" observation, see
draft-klensin-iasa2-2418upd-5377upd-00, which will be posted as
soon as it makes it through the queue.

best,
   john

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Oct 2018 16:34:32 -0400

Thanks for the replies.

On the issue of the appeals policy, something had to change.  Even a 
simple replacement was actually a more substantive change than it 
appeared.  Which led to my taking a first guess (the simplest 
substitution), and the WG concluding that no, that was silly, just drop it.

It can be argued that was out of scope for the WG.  But since any 
modification was an actual change in the appelas process, we had to do 
something.  If it had ben possible to do nothing, that would have been 
my preference.

Yours,
Joel

---

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

--On Monday, October 22, 2018 16:34 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> Thanks for the replies.
> 
> On the issue of the appeals policy, something had to change.
> Even a simple replacement was actually a more substantive
> change than it appeared.  Which led to my taking a first guess
> (the simplest substitution), and the WG concluding that no,
> that was silly, just drop it.
> 
> It can be argued that was out of scope for the WG.  But since
> any modification was an actual change in the appelas process,
> we had to do something.  If it had ben possible to do nothing,
> that would have been my preference.

Yes, I understand the problem.  For substantive reasons this is
a big deal.  Creating a body with no mechanism at all for formal
"hey, wait a minute, have you considered..." requests and, if
needed, external review), "just drop it" is something we have
rather carefully avoided since POISED "fixed" the Kobe problem.
I think there is rather broad consensus about that position.   

Bluntly, if the WG thinks it can create that situation by
quietly dropping a few lines of text and without either
discussing it with the broader community or calling it out very
strongly in the document (possibly even considering that part of
the document as if it were an individual submission and asking
for a four-week Last Call that carefully and explicitly
identified the issue), that is not only a charter problem but
hubris.  

I would encourage you, and the WG leadership, to think about
what would happen if, e.g., a decision was made to subject the
document to an ordinary WG-submission IETF LC and that were
appealed on the grounds that it was not only a charter violation
but a deliberate effort by the WG to create an unprecedented
situation that contained no safeguards for community review and
fairness.  I'd assume that someone obnoxious could write such an
appeal in a way that would paralyze any processing of any IASA2
output or at least output with implications for the Trust until
either the IESG forces a do-over or the ISOC BoT got through
doing its thing.   As I said, you really don't want to go there.

Sorry to be the bearer of bad news.

   best,
     john

---

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

I will defer to the relevant AD and WG chairs whether dropping the 
appeals process for the IETF Trust decisions needs to be dealt with 
differently.  I am happy to add text to the document noting taht this 
was removed.

As far as I can tell, but I am not a lawyer and trusts seem to be messy 
beasts, the only way the IETF trust can affect IETF poliy is if it were 
to try to change the terms we put in the IETF documents assigning rights 
to the trust.  But taht change would be an IETF change, and would go 
through the IETF itself.  Putting that aside, I don't see trust decision 
that affect IETF process.  I can imagine trust decision that the IETF 
would dislike.  Heck, there is a decent chance of trust decision that I 
don't like (but that the community does).  I simply do not see any sane 
way to create an appeals procedure for trust decisions.

Yours,
Joel

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 23 Oct 2018 11:10:56 +0200

Joel,

RFC 5377 says "Appeals of the actions of the Trustees of the IETF Trust are governed by other documents.” Do you know which other documents this refers to?

Thanks,
Alissa

> On Oct 22, 2018, at 11:38 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> I will defer to the relevant AD and WG chairs whether dropping the appeals process for the IETF Trust decisions needs to be dealt with differently.  I am happy to add text to the document noting taht this was removed.
> 
> As far as I can tell, but I am not a lawyer and trusts seem to be messy beasts, the only way the IETF trust can affect IETF poliy is if it were to try to change the terms we put in the IETF documents assigning rights to the trust.  But taht change would be an IETF change, and would go through the IETF itself.  Putting that aside, I don't see trust decision that affect IETF process.  I can imagine trust decision that the IETF would dislike.  Heck, there is a decent chance of trust decision that I don't like (but that the community does).  I simply do not see any sane way to create an appeals procedure for trust decisions.
> 
> Yours,
> Joel
>

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 23 Oct 2018 17:47:00 +0200

Joel helpfully clarified this for me off-list. I read this to mean “other than BCP 101” but it is intended to mean “other than this document.”

I wonder if it would be possible to describe two buckets of trust decisions and apply the appeals process to one of them, sort of how 4071 does for IAOC decisions. For example, if the trust were to make a bunch of updates to the trust agreement without consulting with the community, that seems like something that could be appealable. No appeal could really be binding — that is, even if such a decision were appealed the trust couldn’t be forced to retract the changes — but if the community wants to make provision for process appeals of that sort that could probably be written down.

Alissa

> On Oct 23, 2018, at 11:10 AM, Alissa Cooper <[email-masked]> wrote:
> 
> Joel,
>

---

From: "John Levine" <[email-masked]>
Date: 23 Oct 2018 18:26:45 +0200

In article <[email-masked]> you write:
>Joel,
>
>RFC 5377 says "Appeals of the actions of the Trustees of the IETF Trust are governed by other documents.” Do
>you know which other documents this refers to?

It's in the trust procedures.  The current procedures say it's treated
as an IAOC appeal.  The updated draft language says you can appeal to
the trustees, and if you're not satisfied you can replace them:

 Any member of the IETF community may appeal a decision of the trust by
 transmitting the appeal to the Chair. The Chair shall present the
 appeal to the Trustees for consideration and possible action, and
 shall inform the appellant of the Trustees’ decision. Trustees
 appointed by the IETF NomCom may be recalled by the member recall
 process described in section 7 of BCP 10. Trustees appointed by the
 IESG or by the ISOC Board of Directors may be recalled by vote of the
 appointing body.

As far as I know there has never been a trust appeal, so it didn't
strike me as a good use of anyone's time to create anything more
complex.  Also, it occurred to me that the trust is a separate legal
entity from the IETF, and trustee actions often create contracts.  It
seems a lot cleaner if only the trustees (whoever they are) can make
trust decisions.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 24 Oct 2018 17:35:35 +0200

In article <[email-masked]> you write:
>I wonder if it would be possible to describe two buckets of trust decisions and apply the appeals process to one
>of them, sort of how 4071 does for IAOC decisions. For example, if the trust were to make a bunch of updates to
>the trust agreement without consulting with the community, that seems like something that could be appealable. No
>appeal could really be binding — that is, even if such a decision were appealed the trust couldn’t be forced
>to retract the changes — but if the community wants to make provision for process appeals of that sort that
>could probably be written down.

If the trustees did something as egregious as unilaterally amending
the trust, and their response to an informal appeal was anything other
than holy smokes, we screwed up, we'll redo it right, the appropriate
response would be to fire them and replace them with people who
understand what their job is.  This seems to me like process for the
sake of process to deal with vanishingly unlikely situations.

R's,
John