[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: Transition rules?

Ran/Harald et al -

A third view is that these won't become active until the next Nomcom is empaneled and that they won't apply to this Nomcom at all. I haven't done a line by line analysis of the changes, but for example if the new rules were approved this week - would the new rules on challenges to the random selection (which has to occur in the first week after the selection of the Nomcom) apply?

There may be other race conditions depending on when the rules actually go into effect.

I think I'm going to have to argue for this third view.

And no, I'm not changing my mind from previous discussions. If we could have gotten the new stuff approved prior to the nomcom being seated it would be clear which rules to follow.

Regardless, I agree with Ran that because of the dependency on ISOC for insurance that we should not skip that step.

Mike

At 07:24 10/13/2003, RJ Atkinson wrote:

On Monday, Oct 13, 2003, at 04:09 America/Montreal, Harald Tveit Alvestrand wrote: 
Of course, an alternate is that the rules take effect
when the IESG has approved the document. Thoughts?

Harald,

        I suspect that would not conform with the requirements of
Virginia law, where the IETF Secretariat is located (so there
would be "nexus" legally) and where ISoC offices are located
(hence also "nexus"), or with the terms of the insurance obtained
by ISoC.  So I believe that if the IESG undertook such unilateral
action, it would not be valid legally and thereby would put into
jeopardy the various protections (including the insurance) provided
to IAB, IESG, and IETF by ISoc.

        Brian has repeatedly indicated that ISoC BoT can act quickly
when the BoT are inclined to do so.  So I cannot possibly imagine
any legitimate "need" for the IESG to assert itself in the
manner you suggest.

        Further, I would hope that the community would not find itself
in the situation where it needed to approve these rules in extreme
and reckless haste.  If it did want to expedite things, a much better
approach would be to use an expedited correct process,
(approximately this):
        - IESG approves the I-D and asks RFC Editor to publish.
        - IAB asks RFC Editor to prioritise getting this RFC out
                as quickly as possible, priority one.
        - RFC Editor publishes the I-D as an RFC.
        - ISoC BoT approves it in a specially scheduled vote,
                very quickly after the RFC has been published.

        Should IESG not follow the existing documented procedures as
part of its approval, then by IETF's own rules the IESG decision
would not be valid, of course, so there is some inherent process
delay (e.g. Last Call timeouts) in getting IESG Approval.

        I am confident that the ISoc BoT would approve any reasonable
change(s) to the current procedures, so I don't think any crisis
is looming there either.

        I'm sending this note privately because I see no value in
pointing all this out to those lurkers on the public list.

        While in Europe, people might be unlikely to file frivolous
lawsuits, the same cannot be claimed in the US.  While Virginia
is very significantly less tolerant of such things than California,
someone could still create a large hassle for IAB/IESG/ISoC.
(For the record, I have never sued anyone and I don't plan to ever
sue anyone, so I'm speaking about hypothetical other people in this
note.)

Yours,

Ran Atkinson
rja@extremenetworks.com