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 Wednesday, January 21, 2009 7:39 -0500 Marshall Eubanks
t...@multicasttech.com 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
Marshall Eubanks tme at multicasttech dot com 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
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
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
represents
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
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
John Klensin wrote:
The intent, as ekr and I understand it and as I think your and Ed's
note indicated, was to eliminate the requirement that authors make any
assertions at all about work other than their own, much less requiring
that they guarantee those assertions.
Correct! That is
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
+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:
--On Sunday, January 11, 2009 9:31 +1300 Brian E Carpenter
brian.e.carpen...@gmail.com 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
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
--On Saturday, January 10, 2009 12:52 -0800 Dave CROCKER
d...@dcrocker.net 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,
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
off the
--On Sunday, January 11, 2009 9:31 +1300 Brian E Carpenter
brian.e.carpen...@gmail.com 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
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
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 that a spec
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
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
simplest
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
Dave CROCKER d...@dcrocker.net 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.
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 (5378),
--On Thursday, January 08, 2009 02:49:16 PM -0800 Fred Baker
f...@cisco.com 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
+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 f...@cisco.com 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
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,
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 f...@cisco.com wrote:
You asked me to make this comment publicly, so here it is.
In my opinion, we need a
26 matches
Mail list logo
