Re: recourse if our rules are violated?

[John C Klensin <john-ietf at jck.com>]

--On Thursday, 12 April, 2007 05:29 -0400 Scott W Brim
<sbrim at cisco.com> wrote:

> On 04/12/2007 03:56 AM, Brian E Carpenter wrote:
>> 
>>> "An approved standards track RFC identified to specify
>>> 'patented' technology after its approval, where contributors
>>>  neglected their duties to disclose IPR under BCP 79, MAY be
>>>  removed from standards track, if there's no IETF consensus
>>>  for a different approach."
>> 
>> Why would we write that down, when it's already true? I
>> believe this is well within the IESG's power under RFC 2026.
> 
> I tend to agree.  Consider ... If an IPR disclosure glitch is
> discovered for an RFC, there needs to be IETF consensus on
> what to do with it, where removing it from standards track is
> one option.  The obvious first step in IETF consensus is
> Working Group reevaluation. When they are done there can be an
> IETF last call on their decision, but their decision could be
> anything at all.  I seem to recall that we have done this with
> other RFCs based on other discoveries not related to IPR.
> 
> The procedure described here is already in place in 2026.  If a
> problem is discovered with something that's standards track,
> the WG will consider how to revise it, where the "revision"
> may be a new RFC to replace it (in which case it is moved to
> different status, even Historic).
> 
> So if you want to add a new sentence, it should not be about
> procedure, since we already have all the procedure we need.
> What is special here is the particular reason for invoking
> that process.  If you want to add a sentence, I would just
> note that one possible reason for a major revision or
> replacement of a standards track document would be discovery
> of new IPR claims against it.

Let me slightly disagree by asking some questions whose answers
really push the boundaries of existing documented procedures.
First we have no mechanism for forcing the review that we seem
to all agree is possible and appropriate.  Is that review
automatic?  Does it require AD (or WG) approval to initiate it?
Does it require some sort of community consensus to start the
review process?  Could an AD who some might suspect of having
other motives block such a review (at least absent an appeal)?

And can the review, or the IESG in response to a review, do
something unusual, such as moving an existing, published,
standards-track RFC to some other category (not necessarily only
Historic) while a replacement RFC is being developed, moved
toward consensus, and published?   It might be much easier (and
lots quicker) for the community to reach the conclusion "given
those encumbrances, this document is not suitable for the
standards track" than to develop a replacement RFC.   If the
conclusion is that one --or the presumably more extreme "this
never would have been standardized and might not even have been
published, had the encumbrance been known"-- do we really want
to leave the document on the standards track until a replacement
makes it way through the works?   

    john


_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg