Re: Last Call: 'Progressive Posting Rights Supsensions' to BCP (draft-carpenter-rescind-3683)

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

 



    Date:        Wed, 25 Oct 2006 22:50:06 +0200
    From:        Brian E Carpenter <brc@xxxxxxxxxxxxxx>
    Message-ID:  <453FCDFE.8060603@xxxxxxxxxxxxxx>

  | The draft (ignoring 3683) restores 2418 and adds the extra powers
  | created by 3934.

I'm sure  that's what you're intending, and it may even be that that
is the result, but it is not what the draft actually does.   What it
does is make a change to 2418 that might, or might not, undo the
unintentional side effects of 3934.   I don't really want to have to
consider whether it achieves that fully, and correctly, or not, as
we don't need to - given the intention, all that is needed is to
explicitly say that 3934 (whatever its words seem to say) does not
alter 2418, and 2418 remains in force, fully, as written.

That way, there's no need to combine together the words from two
docs, written by different people and try to consider them to be
one - instead we can just read 2418 alone, and follow it.  If anyone
ever attempts to use 3934 to limit 2418 we just refer them to your new
(not the existing) draft/rfc and say "no it doesn't, see rfcPQRS"

  | So I think the question on
  | the table is: does the community want the union of the powers created
  | by 2418 and 3934?

As Ned said, no it isn't - the current question is the last call of your -03
draft.   If you withdraw that from the IESG we could then move on to new
questions.

  | I can certainly agree that 4633, for its lifetime, seems to grant
  | at least these powers. But of course if we go that way, this discussion
  | will be back again in a year.

That has to happen anyway, to evaluate the 4633 experiment.   In a year
we'll have a year more of experience, and perhaps be better able to judge
what tools are really needed.

That however doesn't mean that I have any problems with issuing a doc that
simply says "3934 does not limit 2418 in any way" - without rescinding
3934 or altering its mechanisms (and completely ignoring 3683).  We do
not need to rewrite a part of 2418 to make a combined 2418+3934 in order
to achieve that, and not creating yet a third (or fifth or...) doc to have to
contend with seems like a win to me.

kre


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]