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
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
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
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
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
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
+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
27 matches
Mail list logo
