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

[Mirja Kuehlewind <[e-mail]>]

Hi!

See below.

> On 9. Apr 2019, at 17:41, Joseph Lorenzo Hall <[e-mail]> 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 <[e-mail]> wrote:
> ----------------------------------------------------------------------
> 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?
> 
> 
> 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?

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.

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

>  
> 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."
> 
> 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…?
 
>  
> 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?
> 
> 
> 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.

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

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

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


>  
> nit:
> s/agreements that that meet a significant materiality threshold/agreements that
> 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: [e-mail], 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/