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

[Mirja Kuehlewind <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
> On Wed, Apr 10, 2019 at 12:29 PM Mirja Kuehlewind <[e-mail]> wrote:
> 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.
> 
> 
> 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 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.
> 
> Understood! ::) Will zap that:
> 
> https://github.com/IASA2/draft-ietf-iasa2-struct/issues/104
>  
> > 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…?
> 
> 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..
>  
> >  
> > 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.
> 
> 
> 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?
>  
> >  
> > 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.
> 
> 
> Let me know if the result in the other thread doesn't deal with your comment here.
>  
> >  
> > 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? 
> 
> 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.
>  
> >  
> > 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?
> 
> 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]
> 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
>