draft-ymbk-opcode-discover-02.txt

[Thomas Narten <[e-mail]>]

The RFC editor recently received a request to publish
draft-ymbk-opcode-discover-02.txt as an Experimental RFC. As with all
RFC submissions, the IESG was asked whether it related to on-going WG
activity and whether it was appropriate to publish the document at
this time. The IESG, in consultation with the DNSEXT chairs, has
recommended that it not be published at this time, as the document
clearly relates to work that would be in-scope for the DNSEXT WG.  The
authors should take the document to the DNSEXT WG for further
consideration.

Quoting from the document:

> Per instructions from a chair of the IETF DNSEXT WG to the moderator of 
> the [e-mail] mailing list, it is forbidden to discuss 
> this draft on that list or in the context of that IETF working
> group.

Per the June 19 note from the Internet ADs (appended below), this
document may be discussed on the namedroppers mailing list. However,
because the document has a non-derivative rights clause, and thus
doesn't give the IETF change control, the WG needs to be careful to
not invest significant resources on the document, so long as there is
question whether the WG has adequate change control rights over the
document.

Note that there are at least two issues that need to be resolved
before this document can be published as an RFC. First, the WG needs
to agree that it is OK to publish the document based on its content.
Second, the non-derivative rights clause will likely have to be
removed in order to give the IETF change control over the
document. IETF change control is needed, if the IETF is ever to revise
the document, e.g., to fix bugs, clarify text, or put it on the
Standards Track. Thus, it is an open question whether the IESG should
ever support publication of this draft as an RFC if the IETF does not
retain change control.

The quickest way to get past the above issues is to reissue the
document with Statement 1 boilerplate and build support for it within
the DNSEXT WG to publish the document.

Thomas & Erik

From: Thomas Narten <[e-mail]>
To: Robert Elz <[e-mail]>
cc: [e-mail], [e-mail],
    namedroppers <[e-mail]>, Randy Bush <[e-mail]>,
    Olafur Gudmundsson <[e-mail]>
Date: Wed, 20 Jun 2001 07:53:30 -0400
Subject: Re: Inactivity appeal 

The Internet ADs have reviewed the set of events related to the
posting of draft-ymbk-opcode-discover-01.txt to the namedroppers
mailing list and the subsequent decision to block discussion of the ID
on the namedroppers list. This note requests that discussion of the
draft resume on the WG mailing list and notes that one significant
issue with the document has apparently been rectified in the
just-submitted -02 ID.

Background:

On June 3, 2001, Bill Manning posted a message to the namedroppers
mailing list that included the entire contents of
draft-opcode-discover-01.txt. That ID contains boilerplate text that
includes the words:

> This document is an Internet-Draft and is NOT offered in accordance
> with Section 10 of RFC2026, and the author does not provide the IETF
> with any rights other than to publish as an Internet-Draft. This
> document is a submission to the domain name system extentions
> (DNSEXT) working group of the Internet Engineering Task Force
> (IETF).

At that time, the Internet and other ADs noted and discussed the
boilerplate text, and then pointed out to the WG chairs that a
document with such boilerplate was not appropriate for discussion on
an IETF WG mailing list. There main reason for this is:

  - The above boilerplate indicates that the contribution is not
    subject to all the rules in Section 10 of RFC 2026. WGs should not
    spend significant cycles on documents with such risks, lest they
    invest cycles working on a technology for which IPR issues are
    discovered at a later time that should have been disclosed
    earlier. Furthermore, allowing significant WG discussion of such
    documents raises serious issues as to whether the IETF is
    following its own rules for openness. Such an issue could, for
    example, adversly impact the IETF's insurance coverage.

Consequently, the WG chairs were asked to limit discussion on the
document. In retrospect, the decision to prohibit all discussion of
the draft (e.g., including whether it was relevant to the WG) was too
strong. With this note, we request that that WG chairs allow
discussion of the draft on the WG mailing list, with the following
caveats.

The document cannot become a WG document until/unless it is submitted
with boilerplate statement 1. Statement 2 & 3 boilerplates do not
grant the IETF/WG any rights to produce a followup ID, excerpt text,
modify text, etc., as is necessary for IETF WGs to do their work. Note
that there have been cases in the past where a document author has
included a restricted copyright clause in a document, had the WG
invest cycles in the ID, and then subsequently refused to make
specific changes requested by the WG, forcing the WG to rewrite a
document from scratch in order to avoid copyright infringement
issues. This can waste significant time and WG resources and should be
avoided.  The Chairs and the WG should keep this in mind as discussion
takes place.

The WG & WG chairs should note that with a statement 3 boilerplate,
the author is specifically disclaiming the need to adhere to the IPR
portions of section 10 of 2026. This is at odds with the IETF's own
stated rules for a WG contribution and is unacceptable for a document
for which there is a reasonable expectation that its contents might be
incorporated into a WG document.  Discussion of such documents on IETF
mailing lists should be undertaken carefully and limited to a context
that takes into considerations the reasons why statement 3 boilerplate
was used and the limitations that implies. Note that the recent
submission of a -02 version of the document (posted 6/19/01) contains
a statement 2 boilerplate, apparently making the issue moot in this
particular case.

Thomas & Erik


to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.