Re: Should the RFC Editor publish an RFC in less than 2 months?

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

 



At Wed, 28 Nov 2007 17:15:40 -0500,
Sam Hartman wrote:
> 
> >>>>> "John" == John C Klensin <john-ietf@xxxxxxx> writes:
> 
>     John> --On Thursday, 29 November, 2007 09:54 +1300 Brian E
>     John> Carpenter
>     John> <brian.e.carpenter@xxxxxxxxx> wrote:
> 
>     John> I'd like to see something like the above combined with a
>     John> shorter window, maybe at two levels ("hold publication
>     John> until..." and "provisional until...").  Of course, if an
>     John> appeal is actually filed, it would be sensible to hold
>     John> publication until it is resolved.  
> 
> I disagree that it is always sensible to hold publication until the
> appeal is resolved, particularly for expedited publication drafts.
> 
> We've had some very bogus appeals and writing up the responses is not
> always our top priority.

I'm actually very concerned by this reasoning. Upon deciding an
appeal, the IESG owes the appellant a prompt response. If they don't
have time to write up a response, then that's fine, they can treat the
appeal as undecided but the document should be held pending the IESG
getting time to do that.

Remember that the appellant cannot appeal to the IAB until the IESG
has responded to his appeal (S 6.5.2.). Given that many appeals are
appeals *of IESG actions* and therefore that the IESG is not a 
neutral party, it seems quite problematic to allow the IESG
to in effect decide the appeal but simply not respond, thus denying
the appellant any avenue of recourse to a neutral body. 

In the limit, the IESG could simply internally decide to proceed as if
the appeal had been denied, but hold the appeal response indefinitely,
thus indefinitely denying the appellant further recourse under 2026.


> One critical assumption in my evaluation is that RFCs can be
> withdrawn.  I'm quite confident that given a court order the RFC
> editor, the IETF website, etc, would find a way to remove an RFC.  As
> such, we as a community can establish our own processes for
> withdrawing an RFC.

So, clearly we need some way to withdraw documents *from the
repository*, for instance for copyright reasons, but I think that's
fundamentally a different issue from retracting them. Let's say
that document X is published at PS, but contains some purely
informational example source code. If it were later determined
that that code was improperly licensed, X would need to be
removed from the repository, but we would not treat it as if
it didn't exist. If, for instance, document Y had a normative
dependency on X, we wouldn't feel the need to go back and mark
Y HISTORIC/WITHDRAWN/whatever. We'd just go and do a noninfringing
document that obsoleted X.

By contrast, if document Z depends on document W and W is subject
to a successful appeal, we would need to withdraw Z, any documents
that depended on it, and ultimately the transitive closure of
any documents depending on W.

So, I think these cases are quite different.

-Ekr





_______________________________________________

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]