Re: draft-ymbk-opcode-discover-02.txt

[[e-mail]]

 Thank you for a prompt response. While the AD's did instruct the
 WG chairs that discussion could continue, the WG chairs have made
 no such statements to the list.  As long as the prohibition is in
 force, it will be impossible to take this work to the DNSEXT wg and
 allow them to conside the work, as you suggest.

 If the prohibition is released, then the document, with boilerplate #2,
 can be considered by the WG to gauge their reaction as to its applicability.
 Once the WG determines that this really is work that would be in-scope
 (not to disparage the IESG & the DNSEXT chairs thoughts on this matter)
 then there will be no problem changing the boilerplate to give
 the IETF change control. 

 Leaving the prohibition in place, and then recommending that it not
 be published w/o WG review places the work in limbo.

 
 
> 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.