Subject: [Iasa20] Mirja Kühlewind's No Objection on draft-ietf-iasa2-rfc4071bis-08: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 02 Apr 2019 08:30:16 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-iasa2-rfc4071bis-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc4071bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

One high level question: I would have expected that this document also says
something about interaction with the IETF Trust. Or are there none?

I believe my other comments below are mostly editorial, however, I also have a
few question. Sorry, if those questions have been discussed earlier.

1) I find it rather confusing to have a reference to [ietf101-slides] in the
doc (given the pictures there are not fully up to date). I don't think that
particular reference is needed to make the point about transparency.

2) Sec 4.4.: "Unification: The IETF LLC provides the corporate legal home for
      the IETF, the Internet Architecture Board (IAB), and the Internet
      Research Task Force (IRTF), and financial support for the
      operation of the RFC Editor."
I'm wondering why the RFC Editor is named here but no other services the IETF
contracts with...?

Similar in section 7: "environment within which the work of the IETF, IAB,
   IRTF, and RFC Editor can remain vibrant and productive."
I understand that the money flow is different for e.g. IANA, however, they also
provide an important function.

And similar in section 7.7.: "The IETF LLC exists to support the IETF, IAB, and
IRTF.  Therefore,
   the IETF LLC's funding and all revenues, in-kind contributions, and
   other income that comprise that funding shall be used solely to
   support activities related to the IETF, IAB, IRTF, and RFC Editor,
   and for no other purposes."

3) sec 4.7: Is it appropriate to have the LLC Broad review its own decision
instead of having an independent entity to do that?

4) Regarding the IESG delegate for the LLC Board, sec 6.4 states that the term
is 2 years. That makes sense if the IETF chairs takes that position which
should be the usual case. However, if another IESG member would take the
position, is the expectation that the IESG can only select someone whose AD
term just started? Or would that person be the delegate for 2 years even if he
or she leaves the IESG after one year? Also would the IESG be able to remove or
change the delegate before the end of that term? I guess that second question
also applies to the appointee from ISOC...

5) sec 6.12: "The IETF, IAB and IRTF chairs, and the chair
of ISOC's Board, will be ineligible for this Board Chair role."
Are the IAB and IRTF chair listed here because they could be NomCom- or IESG-
selected Board members? Or is that an oversight?

Also then this is picked up in section 8.1 again:
"The IETF, ISOC Board, IAB, or IRTF chair cannot be chair of the
      IETF LLC Board, though they may serve as a Director."
However the following sentence in the same section, seem to assume that this
policy is not defined in this doc but developed by the Board in future. "The
Board is expected to maintain a Conflict of Interest policy for
   the IETF LLC. "

nit:
s/agreements that that meet a significant materiality threshold/agreements that
meet a significant materiality threshold/ -> 2x that

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 9 Apr 2019 11:41:39 -0400

(Sorry to have taken so long to get to these, Mirja! Removing all CCs other
than IASA WG.)

The draft points to a separate ID that discusses the Trust issues, which
were largely separate from the rfc4071bis effort, from Section 1:

"The details of how this is done are outside the scope of this document but
are covered in [I-D.ietf-iasa2-trust-update]."

https://tools.ietf.org/html/draft-ietf-iasa2-trust-update-03

Does that cover your comment here?

> particular reference is needed to make the point about transparency.

That reference is less about pictures but to point to where WG consensus
was achieved on the "default public" rule for the LLC Board with respect to
transparency (the default being everything is public without a specific
justification for something being kept confidential).

>    and for no other purposes."

I'll need some help from folks more in tune with Editor/Secretariat/etc.
relationships but my sense is that we tried to capture the major
contract-signing entities (LLC Board, IAB) and the main features of the
IETF here. Would you like to see a more fulsome list in both of these
places as to entities that make up the IETF? (We did have diagrams at one
point but omg those made brains hurt, despite RLB's crack abilities.)

> instead of having an independent entity to do that?
The previous structure had the ISOC Board as the ultimate appeals chain,
but since the whole effort here was to increase independence of the IETF
from ISOC, the LLC Board is where the administrative buck stops, so to
speak. The recall process is noted in that section as the mechanism for the
community to deal with extreme dissatisfaction with the LLC Board.

> also applies to the appointee from ISOC...
The text is silent as to what the IESG can do to remove its own appointee
(and because this isn't a NomCom-appointed member the removal vote doesn't
apply to this person). It would need to be the IETF recall process.
Presumably ISOC can do whatever it wants if their appointee resigns or is
not performing to satisfaction.

> selected Board members? Or is that an oversight?

I'm not sure I understand this. We wanted the various chairs to not have
the burden/responsiblity of chairing the LLC Board, and certainly IAB and
IRTF chairs could be selected by NomCom or IESG for an LLC Board role.

> Board is expected to maintain a Conflict of Interest policy for

We wanted to offload as much "Board policy" to the Board itself to develop,
and you'll see that there are a lot of documents that they need to have in
place, and soon! The COI policy here is much more about financial conflicts
of interest (say a Director has an interest in a business contracting with
IETF LLC). So the rule that the Chairs can't serve as LLC Board Chair is
one that we felt we wanted here and not in the "board-developed" policy
documents.

> meet a significant materiality threshold/ -> 2x that

Thank you very much!

-- 
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

Don't miss out! CDT's Tech Prom is April 10, 2019, at The
Anthem. Please join us: https://cdt.org/annual-dinner/

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 10 Apr 2019 18:29:13 +0200

Hi!

See below.

> On 9. Apr 2019, at 17:41, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> (Sorry to have taken so long to get to these, Mirja! Removing all CCs other than IASA WG.)
> 
No problem. These are just comments and some of them were basically already discussed. Re-adding at least IESG...

> On Tue, Apr 2, 2019 at 11:30 AM Mirja Kühlewind via Datatracker <[email-masked]> wrote:
> The draft points to a separate ID that discusses the Trust issues, which were largely separate from the rfc4071bis effort, from Section 1:
> 
> "The details of how this is done are outside the scope of this document but are covered in [I-D.ietf-iasa2-trust-update]."
> 

I looked at this draft, at least briefly, and I had the feeling that it “only” defines the role of the trust but does also not really discuss the relation to the LLC. Again, I don’t know if there is more to say because I understand too few about the actual roles there but wanted to double-check. If you have checked draft-ietf-iasa2-trust-update and are sure that everything that needs to be said about the relation between the trust and the LLC is said somewhere, I trust you that it should be fine.

> That reference is less about pictures but to point to where WG consensus was achieved on the "default public" rule for the LLC Board with respect to transparency (the default being everything is public without a specific justification for something being kept confidential).

I don’t think pointing to a “random” working group presentation is a good proof that consensus was achieve. A much better proof is to write down in an IETF-consensus document that consensus is achieved :-) Again, I’m just saying that I think this reference is probably not needed, and therefore could even potentially be more confusing than helpful.

> I'll need some help from folks more in tune with Editor/Secretariat/etc. relationships but my sense is that we tried to capture the major contract-signing entities (LLC Board, IAB) and the main features of the IETF here. Would you like to see a more fulsome list in both of these places as to entities that make up the IETF? (We did have diagrams at one point but omg those made brains hurt, despite RLB's crack abilities.) 

Actually the opposite. Given it's probably not likely to be helpful to aim for a fulsome list, I was rather wondering why some entities were picked (while others not). So maybe the better solution is to say rather less than more…?
 
> The previous structure had the ISOC Board as the ultimate appeals chain, but since the whole effort here was to increase independence of the IETF from ISOC, the LLC Board is where the administrative buck stops, so to speak. The recall process is noted in that section as the mechanism for the community to deal with extreme dissatisfaction with the LLC Board.

What about having e.g. the IAB at the end of the appeal chain in this case? Was that discussed? I didn’t think too hard about this but I think that would have been my expectation. If that was discussed and is not an appropriate approach, I guess it could be good to put some more reasoning for future readers in the draft about the reason for the taken approach.

> The text is silent as to what the IESG can do to remove its own appointee (and because this isn't a NomCom-appointed member the removal vote doesn't apply to this person). It would need to be the IETF recall process. Presumably ISOC can do whatever it wants if their appointee resigns or is not performing to satisfaction.

This was discussed on the other thread. With the proposal to either clarify that the recall process is used, or alternative the IESG has also the right to remove someone. I personally think the latter one would be appropriate. I guess the situation for ISOC is different; I understood that now. I guess one could also note in the draft, that the ISOC can/will define an own process to  place and replace appointees.

> I'm not sure I understand this. We wanted the various chairs to not have the burden/responsiblity of chairing the LLC Board, and certainly IAB and IRTF chairs could be selected by NomCom or IESG for an LLC Board role. 

That was exactly my question. Let me ask another question now: do we really want to e.g. give the NomCom/IESG the option to select the current IRTF/IAB chair as a director, or should these position maybe anyway be mutually exclusive? 

> We wanted to offload as much "Board policy" to the Board itself to develop, and you'll see that there are a lot of documents that they need to have in place, and soon! The COI policy here is much more about financial conflicts of interest (say a Director has an interest in a business contracting with IETF LLC). So the rule that the Chairs can't serve as LLC Board Chair is one that we felt we wanted here and not in the "board-developed" policy documents. 

I do see the point but objectively I’m not sure if there is a good reason to have this policy written down in an RFC while other policies are developed in the responsibility of the board itself. Why is this policy so special/important?

Mirja

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 11 Apr 2019 12:08:38 -0400

On Wed, Apr 10, 2019 at 12:29 PM Mirja Kuehlewind <[email-masked]> wrote:

> No problem. These are just comments and some of them were basically
> already discussed. Re-adding at least IESG...
>
>
> > "The details of how this is done are outside the scope of this document
> but are covered in [I-D.ietf-iasa2-trust-update]."
> >
> I looked at this draft, at least briefly, and I had the feeling that it
> “only” defines the role of the trust but does also not really discuss the
> relation to the LLC. Again, I don’t know if there is more to say because I
> understand too few about the actual roles there but wanted to double-check.
> If you have checked draft-ietf-iasa2-trust-update and are sure that
> everything that needs to be said about the relation between the trust and
> the LLC is said somewhere, I trust you that it should be fine.
>
>
Yes, this is pretty opaque to me too, but my sense is that folks like Jari
A., Ted H., and John L. have been pretty vigilant in making sure the right
stuff is in 4071bis and in the trust-update document (e.g., Section 2 of
trust-update does what I think you want). Maybe we can lean on one of them
to say more? Otherwise, I'm not sure what to do to improve it.

> I don’t think pointing to a “random” working group presentation is a good
> proof that consensus was achieve. A much better proof is to write down in
> an IETF-consensus document that consensus is achieved :-) Again, I’m just
> saying that I think this reference is probably not needed, and therefore
> could even potentially be more confusing than helpful.
>

Understood! ::) Will zap that:

https://github.com/IASA2/draft-ietf-iasa2-struct/issues/104

> Actually the opposite. Given it's probably not likely to be helpful to aim
> for a fulsome list, I was rather wondering why some entities were picked
> (while others not). So maybe the better solution is to say rather less than
> more…?
>

Suresh and Barry raised this wrt Section 7.7. I'm hoping the Working Group
can help gut-check if this needs to be ironed out as we've spent some time
discussing this and frankly the RFC Editor was one that folks really wanted
an explicit call-out in some areas. I'm happy to do whatever makes sense,
but it would be great if someone could suggest text that would streamline
this a bit.

> What about having e.g. the IAB at the end of the appeal chain in this
> case? Was that discussed? I didn’t think too hard about this but I think
> that would have been my expectation. If that was discussed and is not an
> appropriate approach, I guess it could be good to put some more reasoning
> for future readers in the draft about the reason for the taken approach.
>
>
Having the IAB as the end of the appeal chain was discussed extensively and
the result was having no party other than the LLC Board be the ultimate end
of the chain, for legal reasons:

https://mailarchive.ietf.org/arch/msg/iasa20/syaOZur4YmGqpi-vDqJbudO6UCg

I can't imagine distilling that discussion down to a few sentences, but I
could try?

> > The text is silent as to what the IESG can do to remove its own
> appointee (and because this isn't a NomCom-appointed member the removal
> vote doesn't apply to this person). It would need to be the IETF recall
> process. Presumably ISOC can do whatever it wants if their appointee
> resigns or is not performing to satisfaction.
>
> This was discussed on the other thread. With the proposal to either
> clarify that the recall process is used, or alternative the IESG has also
> the right to remove someone. I personally think the latter one would be
> appropriate. I guess the situation for ISOC is different; I understood that
> now. I guess one could also note in the draft, that the ISOC can/will
> define an own process to  place and replace appointees.
>
>
Let me know if the result in the other thread doesn't deal with your
comment here.

> That was exactly my question. Let me ask another question now: do we
> really want to e.g. give the NomCom/IESG the option to select the current
> IRTF/IAB chair as a director, or should these position maybe anyway be
> mutually exclusive?
>

I know the Working Group discussed this and thought that would be overly
restrictive. I can't seem to find evidence of that discussion. I suspect it
would take some serious persuasion to get either to serve but don't see a
particularly good reason to prohibit it in this document.

> > We wanted to offload as much "Board policy" to the Board itself to
> develop, and you'll see that there are a lot of documents that they need to
> have in place, and soon! The COI policy here is much more about financial
> conflicts of interest (say a Director has an interest in a business
> contracting with IETF LLC). So the rule that the Chairs can't serve as LLC
> Board Chair is one that we felt we wanted here and not in the
> "board-developed" policy documents.
>
> I do see the point but objectively I’m not sure if there is a good reason
> to have this policy written down in an RFC while other policies are
> developed in the responsibility of the board itself. Why is this policy so
> special/important?
>

Much of the work on this document and of this WG involved initially
figuring out what needs to go in here and gain IETF consensus and what we
think would be best for the Board to do on it's own. This constrains the
Board in a way the Working Group felt important. I'm not sure what else to
say?

best, Joe

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 11 Apr 2019 13:31:15 -0400

> On Apr 11, 2019, at 12:08 PM, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> 
> 
> On Wed, Apr 10, 2019 at 12:29 PM Mirja Kuehlewind <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
> Suresh and Barry raised this wrt Section 7.7. I'm hoping the Working Group can help gut-check if this needs to be ironed out as we've spent some time discussing this and frankly the RFC Editor was one that folks really wanted an explicit call-out in some areas. I'm happy to do whatever makes sense, but it would be great if someone could suggest text that would streamline this a bit..

The sense that I got from the WG was that people wanted to capture in a consensus IETF document that the budget for the RFC Series Editor would be the LLC’s responsibility, because there are other alternatives imaginable given that the RFC Series is defined to serve the Internet broadly. This is not really the case for the LLC’s other contractors. E.g., it would be hard to argue that someone else should pay MeetEcho for remote participation services at IETF meetings. ICANN provides the IANA protocol parameter registration services to the IETF at no cost, so it does not appear in the budget.

Alissa

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 12 Apr 2019 17:29:11 +0200

Hi Joe,

I’ll leave any further concrete edits to you and your co-authors. Just one more comment on the appeal process for the LLC. Maybe at least add a “for legal reasons” somewhere. Of course if you can further summarise these reasons in a crisps way that would be even better but I think it would be at least good to indicate that this was broadly considered and discussed.

Thanks!
Mirja

> On 11. Apr 2019, at 18:08, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> 
> 
> Yes, this is pretty opaque to me too, but my sense is that folks like Jari A., Ted H., and John L. have been pretty vigilant in making sure the right stuff is in 4071bis and in the trust-update document (e.g., Section 2 of trust-update does what I think you want).. Maybe we can lean on one of them to say more? Otherwise, I'm not sure what to do to improve it.
>  
> >  
> Having the IAB as the end of the appeal chain was discussed extensively and the result was having no party other than the LLC Board be the ultimate end of the chain, for legal reasons:
> 
> I can't imagine distilling that discussion down to a few sentences, but I could try?
>  
> >  
> This was discussed on the other thread. With the proposal to either clarify that the recall process is used, or alternative the IESG has also the right to remove someone. I personally think the latter one would be appropriate.. I guess the situation for ISOC is different; I understood that now. I guess one could also note in the draft, that the ISOC can/will define an own process to  place and replace appointees.
> 
> 
> Let me know if the result in the other thread doesn't deal with your comment here.
>  
> >  
> > I'm not sure I understand this. We wanted the various chairs to not have the burden/responsiblity of chairing the LLC Board, and certainly IAB and IRTF chairs could be selected by NomCom or IESG for an LLC Board role.. 
> 
> I know the Working Group discussed this and thought that would be overly restrictive. I can't seem to find evidence of that discussion. I suspect it would take some serious persuasion to get either to serve but don't see a particularly good reason to prohibit it in this document.
>  
> >  
> > policy is not defined in this doc but developed by the Board in future.. "The
> Much of the work on this document and of this WG involved initially figuring out what needs to go in here and gain IETF consensus and what we think would be best for the Board to do on it's own. This constrains the Board in a way the Working Group felt important. I'm not sure what else to say?
> 
> best, Joe
> 
> -- 
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www.cdt..org]