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]

 



> It seems to me that part of the source of your disconnect is
> that not only has 3683 been taken, intentionally or otherwise,
> as modifying and restricting 2418, but 3934, intentionally or
> otherwise, restricted the provisions of 2418 by (apparently)
> banning any suspension longer than 30 days although permitting a
> sequence of 30 day suspensions.

RFC 3934 explicitly updates RFC 2418 and I have no problem rescinding that
update. RFC 3683 does not, and actually uses terms like "consistent with" and
"those guidelines will produce the desired modification in behaviour" when
referring RFC 2418. I therefore see no way to read RFC 3683 as eliminating any
actions possible under RFC 2418 and that means it is not necessary to obsolete
RFC 3683 to "fix" RFC 2418. If anyone believes otherwise, I'd like to hear some
justificaiton for how they have arrived at this conclusion.

Kre is also correct in stating that the current proposal does not restore RFC
2418. Rather, it replaces a piece of RFC 2418 with a new and slightly different
mechanism. I have no problem with making this change but kre is right in saying
that labelling this as "RFC 2418 restoration" is bogus.

> I believe it is that state of affairs that, as construed, has
> led to the conclusion that we have no tools for dealing with
> disruptive behavior that lie between "30 day suspension by WG
> Chair and unclear situation wrt non-WG lists" and "PR-Actions
> under 3863".

I understand how RFC 3934 leads to this conclusion. I don't understand how RFC
3683 does.

> We also have 4633 on the table.  Many of us believed that was
> the necessary and sufficient measure to permit investigation of
> ways to fill that gap. Its presence leaves me wishing for two
> things, and two things only, at this point:

> (1) If the existence of 3683, or 3934, or both, really impede
> whatever would be sensible to do under 4633, then we should
> clear those impediments away.    If that is needed, I think
> kre's suggestion, and language, are exactly right: we affirm
> that neither 3683 nor 3934 were intended to restrict 2418 but to
> add additional possible mechanisms and then we move on.

I guess I have no problem with a statement that says "any such effect by RFC
3683 was unintentional and is hereby voided" but really, this reminds me of a
bunch of mathematics papers written some years back about a particular class of
paracompact sets. It turned out the only such set is the empty set, and much
work had been done to understand, characteriize and clarify ... exactly
nothing.

> (2) If they don't impede doing whatever it is sensible to do
> under 4633, then we drop this until we have the experience that
> 4633 should give us plus whatever Jim's group concludes..  After
> that, if necessary, we write a new, comprehensive, mailing list
> document that pulls things back together -- we don't try to do
> more patchwork.

Nodulo obsoleting RFC 3934, I think a wait-and-see approach makes
a ton of sense. Once we see how this plays out over a period of time
I think we'll be in a much better position to obsolete all of the
current documents with a single coherent set of mailing list guidelines.

> And, finally, in the interim, people don't believe that the use
> of 3683 is worth the energy it takes, then we don't use it.
> Having it available as a mechanism that is not used is certainly
> no worse than having a standards-track document lying around
> that no one is paying attention to and no one is is moving to
> have withdrawn ("declared historic").

I will again point out that RFC 3683 defines two sorts of PR actions, one to
suspect posting rights and one to restore them. One of my objections to the
current draft is that it obsoletes both types of action while leaving the
current suspensions in place. I don't think this is a good thing.

				Ned

_______________________________________________

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]