Subject: RE: Submitted ID not by original authors (i.e., a hack/hijack)

From: "Jeffrey Hutzelman" <[email-masked]>
Date: 26 Nov 2009 22:33:00 -0500

Not at all.  The IETF in fact does not "own" documents even after they are published as RFC's.  However, it does acquire certain rights in I-D's, because those rights are granted to it via the boilerplate.  Hence the need for different boilerplate if you want to grant different (less) rights.

IANAL, but you may wish to consult one if you have any concerns, rather than relying on my interpretation or that of anyone else on this list.

-- Jeff

-----Original Message-----
From: "Glen Zorn" <[email-masked]>
Date: Thursday, Nov 26, 2009 3:33 pm
Subject: RE: Submitted ID not by original authors (i.e., a hack/hijack)
To: "'Jeffrey Hutzelman'" <[email-masked]>,        "'DRAGE, Keith \(Keith\)'" <[email-masked]>,        "'Wojciech Dec \(wdec\)'" <[email-masked]>,        "'Bernard Aboba'" <[email-masked]>
CC: <[email-masked]>

Jeffrey Hutzelman [mailto:[email-masked]] writes:
>
>> > This is news to me: I had been under the (apparently mistaken)
> impression
> > that the author(s) of an individual submission retained editorial
> control
> > until such time as they surrendered it.  I can see a lot of
> modification
> > of IPR boilerplate in my near future...
> 
> No; "individual" drafts are not automatically magical as a result of
> their
> filename or even that no WG has yet adopted them.  You can prohibit the
> creation of derivative works, up to the point where something becomes a
> WG
> document or goes to IETF Last Call as a standards-track document, but to
> do
> so you must use the appropriate boilerplate message.  I'm pretty sure
> xml2rfc knows how to generate this.
>
>So your position is that "the IETF" owns everything published by individuals through it, unless specifically prohibited?  
>
>...
>
>
>
>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 27 Nov 2009 11:19:59 +0100

Irrespective of boiler-late used, I think that there are some rather
clear (at least to me) ethical and behavioural expectations of the
authors and WG chairs which differ along the lines of WG i-d's or
individual i-d's. See if you agree. If so, it may be good to get them
captured in an updated BCP.

1. WG i-d
This is almost always a draft that is, or is meant to be, covered by an
active WG charter and effectively is meant to represent a body of work
by that WG. In embarking on the WG i-d path, the authors/editors of such
a draft are agreeing towards working on the draft in line with WG
consensus, which often goes beyond just changes that they would have
made as individuals (this is what I would see as WG i-d editing). 
The WG chair has an obligation to facilitate progress/discussion on WG
drafts, shape WG consensus, while aiming for the WG's milestones. In
cases where such WG progress is determined by the chairs to be blocked
by the authors/editors, there is the possibility of the WG chair calling
for a new WG i-d editor to progress the work. Such a change of editor
would typically be an action of last recourse. It is improper for a WG
chair to attempt to subvert current WG i-d's, or force a change of
editors, by calling for individual drafts to be submitted with identical
technical to the one in the WG-id.

Now, like others, I have also experienced a case where a draft editor
simply decided to bail on further WG progress and then refused to hand
over the XML source of the draft. This, although not catastrophic, was
certainly a fair amount of unwarranted hassle for the new editor. As
such, I think it would make a lot of sense for institutionalizing the
practice of XML source upload for wg-id's, ie when updating a WG draft,
the author/editor is required to also upload the XML file (if not just
the XML file). Access to the XML could then be restricted to the authors
and chairs.

2. Individual i-d
Irrespective of boilerplate used, plagiarism in individual (or not)
i-d's is inexcusable. 
Intentional posting of individual i-d's that are for all intents and
purposes identical (some may call this nearly full derivative work) to
existing (non-expired) drafts is IMO deplorable - it's an attempt at
hijacking the draft by other means. Furthermore, encouragement from a WG
chair for such activity cannot be condoned. It represents a serious
error of judgement on behalf of the chair, in terms of fairness, if not
perhaps ill will towards the original i-d's authors.

Regards,
Woj.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
> Sent: 27 November 2009 04:33
> To: [email-masked]
> Cc: [email-masked]
> Not at all.  The IETF in fact does not "own" documents even 
> after they are published as RFC's.  However, it does acquire 
> certain rights in I-D's, because those rights are granted to 
> it via the boilerplate.  Hence the need for different 
> boilerplate if you want to grant different (less) rights.
> 
> IANAL, but you may wish to consult one if you have any 
> concerns, rather than relying on my interpretation or that of 
> anyone else on this list.
> 
> -- Jeff
> 
> To: "'Jeffrey Hutzelman'" <[email-masked]>,        "'DRAGE, 
> Keith \(Keith\)'" <[email-masked]>,        
> "'Wojciech Dec \(wdec\)'" <[email-masked]>,        "'Bernard 
> Aboba'" <[email-masked]>
> CC: <[email-masked]>
> 
> > their filename or even that no WG has yet adopted them.  You can 
> > prohibit the creation of derivative works, up to the point where 
> > something becomes a WG document or goes to IETF Last Call as a 
> > standards-track document, but to do so you must use the appropriate 
> > boilerplate message.  I'm pretty sure xml2rfc knows how to generate 
> > this.
> >
> >So your position is that "the IETF" owns everything 
> published by individuals through it, unless specifically prohibited?  
> >
> >...
> >
> >
> >
> >
> 
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 27 Nov 2009 13:40:36 +0100

My fundamental concern with the way this thread is drifting is that people seem to be looking for ways of not having text available for WG charter items.

Apart from internet-drafts that are submitted on non-IETF streams (e.g. RFC editor stream), the whole purpose of submitting an internet draft is to contribute towards something that must obtain IETF consensus. 

It is therefore perfectly reasonable for a WG chair to assume that any text in any draft submitted as IETF stream (be it WG draft or individual) is available for the purpose of obtaining consensus supported text in any document in the scope of their WG. (and in this statement I am assuming due acknowledgement is made).

If people are submitting internet drafts that are not in this direction, then I'm afraid I'm not interested in supporting them, and remember it is my money and my company's money that is supporting the administration and storage of these submissions.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
> Sent: Friday, November 27, 2009 10:20 AM
> To: Jeffrey Hutzelman
> Cc: [email-masked]
> Irrespective of boiler-late used, I think that there are some 
> rather clear (at least to me) ethical and behavioural 
> expectations of the authors and WG chairs which differ along 
> the lines of WG i-d's or individual i-d's. See if you agree. 
> If so, it may be good to get them captured in an updated BCP.
> 
> 1. WG i-d
> This is almost always a draft that is, or is meant to be, 
> covered by an active WG charter and effectively is meant to 
> represent a body of work by that WG. In embarking on the WG 
> i-d path, the authors/editors of such a draft are agreeing 
> towards working on the draft in line with WG consensus, which 
> often goes beyond just changes that they would have made as 
> individuals (this is what I would see as WG i-d editing). 
> The WG chair has an obligation to facilitate 
> progress/discussion on WG drafts, shape WG consensus, while 
> aiming for the WG's milestones. In cases where such WG 
> progress is determined by the chairs to be blocked by the 
> authors/editors, there is the possibility of the WG chair 
> calling for a new WG i-d editor to progress the work. Such a 
> change of editor would typically be an action of last 
> recourse. It is improper for a WG chair to attempt to subvert 
> current WG i-d's, or force a change of editors, by calling 
> for individual drafts to be submitted with identical 
> Now, like others, I have also experienced a case where a 
> draft editor simply decided to bail on further WG progress 
> and then refused to hand over the XML source of the draft. 
> This, although not catastrophic, was certainly a fair amount 
> of unwarranted hassle for the new editor. As such, I think it 
> would make a lot of sense for institutionalizing the practice 
> of XML source upload for wg-id's, ie when updating a WG 
> draft, the author/editor is required to also upload the XML 
> file (if not just the XML file). Access to the XML could then 
> be restricted to the authors and chairs.
> 
> 2. Individual i-d
> Irrespective of boilerplate used, plagiarism in individual 
> (or not) i-d's is inexcusable. 
> Intentional posting of individual i-d's that are for all 
> intents and purposes identical (some may call this nearly 
> full derivative work) to existing (non-expired) drafts is IMO 
> deplorable - it's an attempt at hijacking the draft by other 
> means. Furthermore, encouragement from a WG chair for such 
> activity cannot be condoned. It represents a serious error of 
> judgement on behalf of the chair, in terms of fairness, if 
> not perhaps ill will towards the original i-d's authors.
> 
> Regards,
> Woj.
> 
> after they 
> > are published as RFC's.  However, it does acquire certain rights in 
> > I-D's, because those rights are granted to it via the boilerplate.  
> > Hence the need for different boilerplate if you want to grant 
> > different (less) rights.
> > 
> > IANAL, but you may wish to consult one if you have any concerns, 
> > rather than relying on my interpretation or that of anyone else on 
> > this list.
> > 
> > -- Jeff
> >

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 27 Nov 2009 14:20:41 +0100

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: 27 November 2009 13:41
> To: Wojciech Dec (wdec); Jeffrey Hutzelman
> Cc: [email-masked]
> My fundamental concern with the way this thread is drifting 
> is that people seem to be looking for ways of not having text 
> available for WG charter items.

You seem to be describing an attempt by a WG to hijack an individual
draft whose authors at all costs do not want it to become a WG item.
That would be a rather uncommon, but perhaps still valid option for a
non-standards track doc. Can't think of a case when I saw it happen
though.
The whole reason for anyone publishing a draft in good faith is to have
some form of community feedback on it. If the authors choose that they
do not want feedback or do not want it to constitute any form of IETF
standard, than why bother forcing the issue?
Thankfully more often that not, I'd expect (and witnessed) the opposite
to be more common, with authors being open to collaboration, something
that cannot be always said of some chairs. Thus for me the latter part
of thread has been about this opposite case, i.e. hijacking of drafts
published in good faith without a change of their track.

-Woj.

> 
> Apart from internet-drafts that are submitted on non-IETF 
> streams (e.g. RFC editor stream), the whole purpose of 
> submitting an internet draft is to contribute towards 
> something that must obtain IETF consensus. 
> 
> It is therefore perfectly reasonable for a WG chair to assume 
> that any text in any draft submitted as IETF stream (be it WG 
> draft or individual) is available for the purpose of 
> obtaining consensus supported text in any document in the 
> scope of their WG. (and in this statement I am assuming due 
> acknowledgement is made).
> 
> If people are submitting internet drafts that are not in this 
> direction, then I'm afraid I'm not interested in supporting 
> them, and remember it is my money and my company's money that 
> is supporting the administration and storage of these submissions.
> 
> regards
> 
> Keith
> 
> 
> > individual i-d's. See if you agree.
> covered by 
> > an active WG charter and effectively is meant to represent 
> a body of 
> > work by that WG. In embarking on the WG i-d path, the 
> authors/editors 
> > of such a draft are agreeing towards working on the draft 
> in line with 
> > WG consensus, which often goes beyond just changes that they would 
> > have made as individuals (this is what I would see as WG 
> i-d editing).
> progress/discussion on WG 
> > by the authors/editors, there is the possibility of the WG chair 
> > calling for a new WG i-d editor to progress the work. Such 
> a change of 
> > editor would typically be an action of last recourse. It is 
> improper 
> > for a WG chair to attempt to subvert current WG i-d's, or force a 
> > change of editors, by calling for individual drafts to be submitted 
> > with identical technical to the one in the WG-id.
> > 
> draft editor 
> > over the XML source of the draft.
> > This, although not catastrophic, was certainly a fair amount of 
> > unwarranted hassle for the new editor. As such, I think it 
> would make 
> > a lot of sense for institutionalizing the practice of XML source 
> > upload for wg-id's, ie when updating a WG draft, the 
> author/editor is 
> > required to also upload the XML file (if not just the XML file). 
> > Access to the XML could then be restricted to the authors 
> and chairs.
> > 
> > 2. Individual i-d
> intents and 
> > hijacking the draft by other means. Furthermore, 
> encouragement from a 
> > WG chair for such activity cannot be condoned. It 
> represents a serious 
> > error of judgement on behalf of the chair, in terms of fairness, if

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 27 Nov 2009 10:53:34 -0800

Hi -

> From: "Wojciech Dec (wdec)" <[email-masked]>
> To: "Jeffrey Hutzelman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, November 27, 2009 2:19 AM

Without getting bogged down in point-by-point analysis, it seems to
me that the expectations you  outlined diverge both subtly and significantly
from what is spelled out in RFC 2418.  I don't see enough of a problem
to make such an effort worthwhile, and would oppose starting yet another
process update process update process....

If we *did* understake changes, I'd strongly prefer going towards the
IEEE / ITU / ISO approach to document editorship, making documents
explicitly the product of the working group rather than an individual.  I'd
also like to change the process to make it explicit that editors serve at
the pleasure of the WG chairs.  (I know that this is how some have operated,
but it's not really supported by RFC 2418 6.3.)

Randy

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 27 Nov 2009 20:07:23 +0100

> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: 27 November 2009 19:54
> To: [email-masked]
> Subject: Re: Submitted ID not by original authors (i.e., a 
> hack/hijack)
> 
> Hi -
> 
> Without getting bogged down in point-by-point analysis, it 
> seems to me that the expectations you  outlined diverge both 
> subtly and significantly from what is spelled out in RFC 
> 2418.  I don't see enough of a problem to make such an effort 
> worthwhile, and would oppose starting yet another process 
> update process update process....

The version of 2418 I have does not deal with the topic of document
hijaking nor solictiations there-of nor shed much light on the topic of
a change of editors... Given that BCPs evolve over time along with
aquired expereinces of the community, not considering such a change for
no other reason than it being a change would appear to be rather
disingenious...

-Woj.

> 
> If we *did* understake changes, I'd strongly prefer going 
> towards the IEEE / ITU / ISO approach to document editorship, 
> making documents explicitly the product of the working group 
> rather than an individual.  I'd also like to change the 
> process to make it explicit that editors serve at the 
> pleasure of the WG chairs.  (I know that this is how some 
> have operated, but it's not really supported by RFC 2418 6.3.)
> 
> Randy
> 
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 27 Nov 2009 11:30:05 -0800

Mr Dec:

> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Friday, November 27, 2009 11:07 AM
...
> no other reason than it being a change would appear to be rather

Those are fighting words.  I do not appreciate being called a liar.
I stand by my statement, and challenge you to demonstrate any
misrepresentations or errors of fact in my statement.

Randy

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 27 Nov 2009 20:44:07 +0100

> Sent: 27 November 2009 20:30
> To: [email-masked]
> > > me that the expectations you  outlined diverge both subtly and 
> > > significantly from what is spelled out in RFC 2418.  I don't see 
> > > enough of a problem to make such an effort worthwhile, and would 
> > > oppose starting yet another process update process update 
> > > process....
> >
> > hijaking nor solictiations there-of nor shed much light on 
> the topic 
> > of a change of editors... Given that BCPs evolve over time 
> along with 
> > aquired expereinces of the community, not considering such a change 
> > for no other reason than it being a change would appear to 
> be rather 
> > disingenious...
> 

How did you reach this assertion I don't know, but my intent was not for
calling you anything so am apologies if you took it that way. 
The thread is/was about document hijacking and I see no BCPs which
addresses such cases. If it's otherwise, I'd appreciate being educated.
In any case, not discussing the matter just because it may result in a
BCP evolving doesn't seem to be a good approach for dealing with such
issues in the future.

-Woj.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 27 Nov 2009 15:01:39 -0500

On Fri, Nov 27, 2009 at 08:44:07PM +0100, Wojciech Dec (wdec) wrote:

> addresses such cases.

I'm not exactly sure how anyone would come to conclusions about "best"
practice for something that happens so rarely that people were
surprised it was possible at all.  Part of the reason any culture
works is because there are things that aren't strictly illegal, but
that are impolite and that people therefore don't do.  (Indeed, part of
the reason the law works is because of that: if we had to rely on
traffic court actually enforcing "don't go through red lights", for
instance, the roads would be even more chaotic than they otherwise
are.  People follow the "red means stop" convention because we need a
convention and because it only works if most of us follow the
conventions.)

I don't believe we need a document in this area.  More strongly, I
think it would do active harm to start trying to write down these
rules more specifically than they are already written down.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 27 Nov 2009 13:53:52 -0800

Hi -

Well said.

Randy

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 27 Nov 2009 17:42:32 -0500

See below.

> > update process update process....

I'm not sure where exactly everything should be documented by see Slide 60
of
http://www.ietf.org/proceedings/69/slides/leadership-0.pdf

See more below.

> > have operated, but it's not really supported by RFC 2418 6.3.)

I've always had the understanding the WG Chair need to consult their AD
before involuntarily replacing a Working Group document editor. This is
probably reasonable because you are going to create some hard feelings if
you replace an Editor who does not want to be replaced.

Of course, Chairs and ADs vary a lot. Some chair may be have a lot of
experience and initiative and hardly ever ask for advice/help from their AD.
Others may be uncertain and aks for lots of advice and help. I suppose in
some cases, the AD could pre-approve the WG Chair(s) replacing Editors
whenever they thought it necessary.

Donald