Julian Reschke wrote:
Roy T. Fielding wrote:
...
What the IETF should be doing is restricting the number of editors to 5,
list only the editors on the front page (clearly marked as such), place
the editors' addresses in a section called Editors (if they differ from
the complete set of authors),
--On Thursday, January 29, 2009 16:26 -0500 Dean Anderson
wrote:
>...
> You comment explains exactly the problems with RFC5378. This
> is why we, Glassey, myself, others advocated for having the
> contributor hold the copyright, as is done in other standards
> groups, like the ITU, The Open Gr
On Jan 21, 2009, at 12:16 PM, Bob Braden wrote:
At 11:58 PM 1/20/2009, Dean Willis wrote:
Given that we've historically weeded out the contributor-list on a
document to "four or less", even if there were really dozens of
"contributors" at the alleged insistence of the RFC Editor, I don't
Brian E Carpenter writes:
> Simon,
>
> My recollection, without doing an archive search, is that our counsel
> took the opposite view, i.e. that the parenthesis expanded the scope
> beyond "ISOC and the IETF". IANAL and YMMV.
Ah, I didn't recall the IETF counsel had made that analysis. When the
Simon,
My recollection, without doing an archive search, is that our counsel
took the opposite view, i.e. that the parenthesis expanded the scope
beyond "ISOC and the IETF". IANAL and YMMV.
Brian
On 2009-01-23 23:20, Simon Josefsson wrote:
> Brian E Carpenter writes:
>
>> Ted,
>>
>> On 200
Brian E Carpenter writes:
> Ted,
>
> On 2009-01-23 10:30, Theodore Tso wrote:
> ...
>> Ultimately, I suspect the list of contributors is a good and polite
>> thing to do out of courtesy, but it's not all that useful from an IPR
>> point of view. Even if there was code that you wanted to use from
Ted,
On 2009-01-23 10:30, Theodore Tso wrote:
...
> Ultimately, I suspect the list of contributors is a good and polite
> thing to do out of courtesy, but it's not all that useful from an IPR
> point of view. Even if there was code that you wanted to use from a
> pre-RFC5378 text, you wouldn't ne
On Fri, Jan 23, 2009 at 09:43:23AM +1300, Brian E Carpenter wrote:
> > Because of the IPR implications, that probably should also include
> > contact info, just as for authors.
>
> That would only arise for pre-RFC5378 text that is subject to the
> disclaimer clause *and* fails a "fair use" test.
Julian,
On 2009-01-23 05:40, Julian Reschke wrote:
...
> That leaves us with the question whether any contributor (IPR-wise)
> needs to be called "author". Not sure about that. But if we don't call
> them authors, they should be listed in a agreed-upon place in the spec.
For minor contributors, t
Roy T. Fielding wrote:
...
What the IETF should be doing is restricting the number of editors to 5,
list only the editors on the front page (clearly marked as such), place
the editors' addresses in a section called Editors (if they differ from
the complete set of authors), and then have another s
On Jan 21, 2009, at 10:16 AM, Bob Braden wrote:
Whoa! This contains several errors of fact and implication. The
number authors named
on the front page of an RFC are generally limited to 5 (there are
occasional exceptions for
good cause). This rule was arrived at after discussions in
the I
At 11:58 PM 1/20/2009, Dean Willis wrote:
Given that we've historically weeded out the contributor-list on a
document to "four or less", even if there were really dozens of
"contributors" at the alleged insistence of the RFC Editor, I don't
see how any older document or even a majority of ne
Dean:
The RFC Editor is asking the authors. That is the list of people
that is readily available. If the authors cannot speak for all
Contributors, then the document will have to wait until a work-
around is found.
Given that we've historically weeded out the contributor-list on a
document
Given that we've historically weeded out the contributor-list on a
document to "four or less", even if there were really dozens of
"contributors" at the alleged insistence of the RFC Editor, I
don't see how any older document or even a majority of new
documents-in-progress could be adapted to
Marshall Eubanks replied to Dean Willis:
Given that we've historically weeded out the contributor-list on a
document to "four or less", even if there were really dozens of
"contributors" at the alleged insistence of the RFC Editor, I don't
see how any older document or even a majority of new
--On Wednesday, January 21, 2009 7:39 -0500 Marshall Eubanks
wrote:
> On Jan 21, 2009, at 2:58 AM, Dean Willis wrote:
>...
>> Given that we've historically weeded out the contributor-list
>> on a document to "four or less", even if there were really
>> dozens of "contributors" at the all
On Jan 21, 2009, at 2:58 AM, Dean Willis wrote:
On Jan 12, 2009, at 4:15 PM, Russ Housley wrote:
The RFC Editor is asking the authors. That is the list of people
that is readily available. If the authors cannot speak for all
Contributors, then the document will have to wait until a
On Jan 12, 2009, at 4:15 PM, Russ Housley wrote:
The RFC Editor is asking the authors. That is the list of people
that is readily available. If the authors cannot speak for all
Contributors, then the document will have to wait until a work-
around is found.
Given that we've histor
Tom:
What then is post-5378? Is it material published on or after November 10th?
Yes.
Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
- Original Message -
From: "Russ Housley"
To: "Tom.Petch" sisyp...@dial.pipex.com
Sent: Wednesday, January 14, 2009 10:36 PM
> Correction: RFC 5378 was published on 10 November 2008.
> http://mailman.rfc-editor.org/pipermail/rfc-dist/2008-November/002142.html
Thanks for the correction.
Correction: RFC 5378 was published on 10 November 2008.
http://mailman.rfc-editor.org/pipermail/rfc-dist/2008-November/002142.html
Russ
At 11:20 AM 1/14/2009, Russ Housley wrote:
Tom:
RFC 5378 was published on 11 November 2008, and it went into effect
on that date. Pre-5378 material refers
Tom:
RFC 5378 was published on 11 November 2008, and it went into effect
on that date. Pre-5378 material refers to contributions that were
made before the BCP went into effect. I do not believe that anyone
tracked the posting time at a finer granularity than a day.
Russ
The At 04:41 AM 1/
> The RFC Editor is asking the authors. That is the list of people
> that is readily available. If the authors cannot speak for all
> Contributors, then the document will have to wait until a work-around is
> found.
In this case, wouldn't it make sense to (temporarily?) suspend the rule that
Russ Housley wrote:
Russ the phrase COUNSEL reviewed the text is meaningless from a legal
standpoint without specifically asking particular questions. So what is
it exactly that the Counsel reviewed and is willing to issue a formal
opinion on?
Todd Glassey
John:
> I think that the cover n
John:
> I think that the cover note from the Chair of the IETF Trust,
> Ed Juskevicius, included the vast bulk of the information that
> you are requesting.
Russ, I think your note addresses several more of the issues I
was concerned about than Ed's note did. Assuming that your note
represent
Hi Russ,
On 1/12/09 2:15 PM, "Russ Housley" wrote:
[...]
>
> The RFC Editor is asking the authors. That is the list of people
> that is readily available. If the authors cannot speak for all
> Contributors, then the document will have to wait until a work-around is
> found.
>
In this case, w
e-
From: trustees-boun...@ietf.org [mailto:trustees-boun...@ietf.org] On Behalf
Of John C Klensin
Sent: January 12, 2009 7:01 PM
To: Russ Housley
Cc: trust...@ietf.org; ietf@ietf.org
Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review
and comments on a proposed Work-Around to the Pr
--On Monday, January 12, 2009 17:24 -0500 Russ Housley
wrote:
> John:
>
> I think that the cover note from the Chair of the IETF Trust,
> Ed Juskevicius, included the vast bulk of the information that
> you are requesting.
Russ, I think your note addresses several more of the issues I
was c
Ed,
I'd like to thank the Trustees for working to resolve this
situation. Unfortunately, after reviewing the new text, I don't think
it's really adequate.
To recap, the the old text required the contributor to affirm (and
consequently to verify) that adequate permissions had been obtained to
pub
John:
I think that the cover note from the Chair of the IETF Trust, Ed
Juskevicius, included the vast bulk of the information that you are
requesting. Let's look at all three parts of your request.
(1) "this is the problem we are trying to solve"
> Some I-D authors are having difficulty im
John:
>...
> If the document is approved without change, then the RFC
> Editor will ask each of the authors to grant the additional
> rights required by RFC 5378. If this cannot be done, then the
> document will sit in the queue until some work-around like the
> one being discussed on this thre
--On Monday, January 12, 2009 16:07 -0500 Russ Housley
wrote:
>...
> If the document is approved without change, then the RFC
> Editor will ask each of the authors to grant the additional
> rights required by RFC 5378. If this cannot be done, then the
> document will sit in the queue until som
Doug:
I hope this response answers your pragmatic questions.
1. What do I, as editor of an I-D and previously editor of a
related RFC that is not quoted in the current I-D, need to do in
order to allow the WG chairs to move my draft forward into IETF Last Call?
You can proceed to IETF Last
On 2009-01-11 10:55, Dave CROCKER wrote:
>
>
> Brian E Carpenter wrote:
>> Er, is that a Last Call comment on draft-ietf-ipr-outbound-rights
>> and draft-ietf-ipr-3978-incoming? A bit late, if so.
>
> Brian, "too late" makes sense for stray comments.
>
> It doesn't make sense when we discover t
Brian E Carpenter wrote:
Er, is that a Last Call comment on draft-ietf-ipr-outbound-rights
and draft-ietf-ipr-3978-incoming? A bit late, if so.
Brian, "too late" makes sense for stray comments.
It doesn't make sense when we discover that a spec doesn't work. There have been
quite a few comm
> --On Sunday, January 11, 2009 9:31 +1300 Brian E Carpenter
> wrote:
> > +1.
> >
> > Which is why I suggest that we should support the Trustees'
> > proposed short term fix, to allow normal work to continue +/-
> > cutting and pasting some boilerplate. We do have a glitch in
> > 5378 to mend,
On 2009-01-11 09:52, Dave CROCKER wrote:
>
>
> Brian E Carpenter wrote:
>> Which is why I suggest that we should support the Trustees' proposed
>> short term fix, to allow normal work to continue +/- cutting and pasting
>> some boilerplate. We do have a glitch in 5378 to mend, but let's get that
--On Saturday, January 10, 2009 12:52 -0800 Dave CROCKER
wrote:
>...
> I can't begin to guess at the logic that uses Larry's somewhat
> bizarre assertion as a basis for trying to press approval of
> this clearly and substantially problematic proposal.
>
> To create a paraphrase, what part of "
Brian E Carpenter wrote:
Which is why I suggest that we should support the Trustees' proposed
short term fix, to allow normal work to continue +/- cutting and pasting
some boilerplate. We do have a glitch in 5378 to mend, but let's get that
off the critical path.
I can't begin to guess at th
--On Sunday, January 11, 2009 9:31 +1300 Brian E Carpenter
wrote:
> +1.
>
> Which is why I suggest that we should support the Trustees'
> proposed short term fix, to allow normal work to continue +/-
> cutting and pasting some boilerplate. We do have a glitch in
> 5378 to mend, but let's get t
+1.
Which is why I suggest that we should support the Trustees' proposed
short term fix, to allow normal work to continue +/- cutting and pasting
some boilerplate. We do have a glitch in 5378 to mend, but let's get that
off the critical path.
Brian
On 2009-01-11 09:12, John C Klensin wrote:
>
Joel,
Yes. I'll accept any solution in the range covered by my draft and your
and John's messages.
Brian
On 2009-01-10 12:52, Joel M. Halpern wrote:
> My own take has been that the code reuse problem is the dominant
> problem. Document transfer outside the IETF is sufficiently rare that I
>
--On Thursday, January 08, 2009 02:49:16 PM -0800 Fred Baker
wrote:
From my perspective, the best approach involves keeping the general case
simple. The documents that have been transferred outside the IETF in the
past five years is a single digit number, a tenth of a percent of all
RFCs if n
John,
On 2009-01-10 07:15, John Leslie wrote:
...
>> In other words, remove the new requirement and we no longer have a
>> crisis. We have an issue to pursue -- the same one that prompted
>> the new requirement -- but no crisis.
>
>Alas, I must disagree. We have an IETF Consensus document (53
Dave CROCKER wrote:
>
> A number of the comments, so far, appear to hinge on a rather basic
> cost/benefit model that is clearly quite different from what the proposal
> is based. I suspect that difference comes from a different sense of the
> problem, per John Klensin's posting.
Agreed.
Fred Baker wrote:
From my perspective, the best approach involves keeping the general
case simple. The documents that have been transferred outside the IETF
in the past five years is a single digit number, a tenth of a percent of
all RFCs if not a smaller fraction. From my perspective, the s
> From my perspective, the best approach involves keeping the general
> case simple. The documents that have been transferred outside the IETF
> in the past five years is a single digit number, a tenth of a percent
> of all RFCs if not a smaller fraction. From my perspective, the
> simpl
You asked me to make this comment publicly, so here it is.
In my opinion, we need a 5378-bis that keeps the good bits but
corrects the issue that has been problematic. The question before the
house is how best to achieve that. The proposal here is to provide a
work-around that enables an in
"Ed Juskevicius" writes:
> The new legend text, if implemented, would do the following:
> a. Provide Authors and Contributors with a way to identify (to the
> IETF Trust) that their contributions contain material from pre-5378
> documents for which RFC 5378 rights to modify the mat
On 2009-01-09 13:59, Stephen Farrell wrote:
> +1 to fred's proposal, let the exceptions be just that and don't bother
> most I-D authors,
> Stephen.
>
> On 8 Jan 2009, at 22:49, Fred Baker wrote:
>
>> You asked me to make this comment publicly, so here it is.
>>
>> In my opinion, we need a 5378
Stephen and Fred,
One of the interesting issues with 5378 is that there has never
been consensus about what problem(s) it was trying to solve.
The WG reached consensus on the two documents without, IMO,
reaching consensus on the problem statement. Nothing in our
procedures prohibits that, whether
gards,
Ed J.
-Original Message-
From: TSG [mailto:tglas...@earthlink.net]
Sent: January 8, 2009 6:21 PM
To: Ed Juskevicius
Cc: 'IETF Discussion'; ietf-annou...@ietf.org; i...@ietf.org; i...@iab.org;
rfc-edi...@rfc-editor.org; wgcha...@ietf.org; 'Trustees'
Subjec
+1 to fred's proposal, let the exceptions be just that and don't
bother most I-D authors,
Stephen.
On 8 Jan 2009, at 22:49, Fred Baker wrote:
You asked me to make this comment publicly, so here it is.
In my opinion, we need a 5378-bis that keeps the good bits but
corrects the issue that h
Ed Juskevicius wrote:
Ed - you nor the rest of this list is going to like this retort but I
would ask that you read all of it prior to flushing the response.
The purpose of this message is twofold:
1) To summarize the issues that some members of our community
have experienced since the pub
Ed,
Thanks for this.
As I understand it, the proposal boils down to adding a disclaimer to
affected documents that reads:
"This document contains material from IETF Documents or IETF Contributions
published before November 10, 2008 and, to the Contributor’s knowledge,
the person(s) controlling t
55 matches
Mail list logo
