[rfc-i] LC for draft-braden-independent-submission-00
Joel M. Halpern
jmh at joelhalpern.com
Tue Sep 15 15:31:58 PDT 2009
I think I understand your objective. I certainly understand the case
However, it is not the intention of this proposal that such documents
would be published under IETF rules. Rather, they would need to be
re-submitted with boilerplate (rights grant) suitable for the
After all, once the IETF has chosen not to pursue the work, and given
the authors permission to seek independent publication, the IETF no
longer has special rights with regard to the text.
Note that if the IETF wants to publish using IETF rules, then the
Individual Submission mechanism, by which an AD approves the draft for
publication in the IETF stream, is still available.
Joel M. Halpern
Alfred ? wrote:
> I also support this draft.
> However, considering a typical flow of events in the evolution
> of an I-D that ends up in the Independent Submission stream,
> I would appreciate if it would be possible to put a bit more
> emphasis on the necessary overlap and compatibility with the
> rules for IETF stream submissions:
> [[ Note that, for simplicity, I disregard below the existence
> of the other, 'minority' streams (IAB, IRTF). ]]
> Some draft will be submitted to a WG for consideration.
> It may happen then that the WG is chartered narrowly and does
> not adopt the work, or that the material is presented mainly
> for educational purposes, to distribute knowledge on existing
> propriatary solutions for a problem area that the WG is
> chartered to work on.
> In other cases, a WG might be disbanded but work originally
> targetted to it shall anyway be brought to the knowledge of the
> Internet engineering community at large.
> Or the overloaded IESG does not have the cycles to sponsor a
> specific draft as an Individual Submission on the IETF stream
> and redirects the author(s) to the Independent Submission stream
> after the draft already has been discussed in the IETF.
> Etc., etc.
> In such cases, it is likely not always clear from the beginning
> which path a draft will follow, i.e. which stream it might end in.
> However, the draft has to be submitted with boilerplate text
> accommodating the requirements of any stream it might end in.
> This only makes sense if the rights to be granted are as similar
> as possible in all cases, and can be covered by a single instance
> of boilerplate text. Since it is very unlikely that a draft
> submitted to the Independent Submission stream will subsequently
> be re-targetted to the IETF stream, the rights to be granted
> for Independent Submission stream should be a superset of the
> rights granted for the IETF stream, or even better, be the same.
> (In the case of a proper superset, additional rights could be
> granted to the IETF Trust as soon as the Independent Submission
> stream target has been fixed, but the converse does not make
> much sense -- revoking rights once granted.)
> The current Ind. Subm. Rights draft already has adopted much of
> the rules and procedures regarding patents and patent applications
> set in force for the IETF stream.
> Clearly, to keep the Ind. Subm. stream *independent* from the IETF,
> the rules and procedures should not be tied blindly to current or
> future IETF rules and/or procedures.
> However, I would appreciate if wording could be added in order to
> make it a distinguished goal for the Trustees to establish legal
> boilerplate text for the Ind. Subm. stream as compatible as
> possible with the one applicable for common IETF targeted drafts.
> I have leave it to native English speakers with the necessary
> background of legalese experience to identify the proper places
> in the draft, and the appropriate wording that needs to be added
> for this purpose.
> Kind regards,
> Alfred H?nes.
> P.S. -- editorials:
> a) I suggest making precise and uniform use of the terms also
> adopted in the headers & boilerplates IAB draft (et al.),
> and always talk about the "Independent Submission Stream"
> or "Independent Submission RFC Stream".
> (Some parts of the draft currently use the shortened form
> "Independent Stream".)
> b) Typo in Section 1, 2nd para: s!the the!the!
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest