ietf
[Top] [All Lists]

Re: [arch-d] Call for Comment: <draft-iab-rfc3677bis> (IETF ISOC Board of Trustee Appointment Procedures)

2016-02-29 09:47:22
Mike,

After reading your email, I think Brian’s proposed text is fine.  I don’t think 
anything more is needed.

The IAB did the right thing when the ISOC bylaws changed the number of IETF 
appointed board members, and they are doing the right thing to update RFC3677.

Next.

Bob


On Feb 28, 2016, at 12:06 PM, Michael StJohns 
<mstjohns(_at_)comcast(_dot_)net> wrote:

On 2/28/2016 1:48 PM, Brian E Carpenter wrote:
Well, OK.

NEW NEW:
  If ISOC further modifies [ISOC-By-Laws] concerning the
  number of IETF appointments to the ISOC Board or the
  timing thereof, the IAB may make corresponding
  modifications to the frequency and the timing of the
  processes embodied in this document. Such changes will
  be announced via an IAB statement. The IAB must then
  propose a corresponding update to this document within
  one year.

Regards
   Brian


I'm always somewhat pained by toothless requirements.  E.g.  what's the 
downside if the IAB fails propose an update, or if they drag out the 
completion of the update for several years because other things are more 
important?

The above is either too much or too little.  So if its too much then:

Replace 3.4.1 and 3.4.2 with:  "The IAB shall appoint the IETF-sourced 
members to the ISOC board with the terms and schedule for such members as 
described by the ISOC charter, and as they are notified by the ISOC board of 
IETF-sourced vacancies."

[I see no reason for the BCP to go into the details of which years as a) its 
not under the IETF's control, and b) it's subject to change if the ISOC board 
needs to move things around]

If its too little then:

replace 3.4.2 with the Brian's text (replacing "proposed" with "completed") 
and adding:  "If the IAB fails to complete a change to the BCP within 1 year, 
then their power to appoint the IETF-sourced members of the ISOC board shall 
lapse  and such power shall devolve upon the most recently seated IETF 
nominations committee. The confirmation of such appointments shall remain 
with the IESG.  The power to make such appointments shall revert to the IAB 
upon publication of the updated BCP."

[Basically, if the IAB doesn't have time to complete the BCP, then it 
probably doesn't have time to deal with the ISOC appointments]


To be clear, I'd go with the "too much" alternative above and just say that 
the appointments are made on the schedule described by the ISOC.

On the other hand, noting that the language in the rationale section (1.2) is 
no longer a completely accurate statement of reality (cf appointment of IAOC 
members), it may make sense to re-address who should be doing these 
appointments.  Perhaps the IAOC is a better body?  Or this can be folded into 
the Nomcom process?   Not making any recommendations here, just noting that 
if we're updating this document, we should make sure it's all valid as of the 
date of publication.

Later, Mike



On 29/02/2016 05:11, Bob Hinden wrote:
On Feb 27, 2016, at 12:39 PM, John C Klensin 
<john-ietf(_at_)jck(_dot_)com> wrote:



--On Saturday, February 27, 2016 12:35 -0800 Barry Leiba
<barryleiba(_at_)computer(_dot_)org> wrote:

NEW:
  If ISOC further modifies [ISOC-By-Laws] concerning the
  number of IETF appointments to the ISOC Board or the
  timing thereof, the IAB may make corresponding
  modifications to the frequency and the timing of the
  processes embodied in this document, pending any
  modification to this document. Such changes will be
  announced via an IAB statement.
I think a change such as that would be good.
I agree but, if the intent is that the IAB modifications and
statement are a stopgap, to avoid discontinuities, etc., but
that the IAB is still expected to move expeditiously to get the
BCP updated, that could be said a lot more clearly.
I agree.  The IAB shouldn’t delay it’s board appointment until this 
document is updated, but it should do an update in a reasonable amount of 
time.

Thanks,
Bob




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

<Prev in Thread] Current Thread [Next in Thread>