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

[Joseph Lorenzo Hall <[e-mail]>]

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