[rfc-i] LC for draft-braden-independent-submission-00

Joel M. Halpern jmh at joelhalpern.com
Wed Sep 16 16:35:36 PDT 2009


If your point is that in making the transition from a WG document to an 
Independent document it is practically impossible to chose the "no 
derivatives works" path, I agree.  I did not say that, but it would take 
some interesting jiggering and one heck of an explanation for that to occur.

For the "Unlimited Derivative Works" grant, since that still allows the 
IETF to do what it wants if it decides later to work on the document, 
there is no problem.

Yours,
Joel


Brian E Carpenter wrote:
> On 2009-09-16 10:31, Joel M. Halpern wrote:
>> I think I understand your objective.  I certainly understand the case 
>> you describe.
>>
>> 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 
>> Independent Stream.
>> 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.
> 
> Er, I think the rights granted to the IETF by an IETF Contributor
> are irrevocable. Any rights granted subsequently to the Independent
> Stream would be additional. The same would be true in the converse
> case too, I suppose.
> 
>     Brian
> 
>> 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.
>>
>> Yours,
>> 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
>>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
>>
> 


More information about the rfc-interest mailing list