Trust me, you're better off not having done this or any other name chicanery.
My full name is Edwin Earl Freed (after my uncle), and the hiccups caused by
people not knowing Ned is a nickname for Edwin long ago ceased to be
in any way
amusing.
I thought the nickname for Edwin was Buzz :-)
Hi Sam,
I wish you had approached the PANA WG first to get clarification on your
concerns and questions. And I wish the responsible AD had said go to PANA
WG rather than don't go there when you consulted him.
Even after the PANA WG was chartered, we went through your suggested
exercise twice
Just one note on this long thread:
At present, the IETF secretariat does *not* attempt to track who has
copyright rights on what parts of the text.
Neither, as far as I know, does anyone else (WG chair or editors), apart
from following the RFC 2026 rule that significant contributions should
Bob Braden wrote:
*
* I am concerned that the current RFC Editor practice that limits the
* number of authors is in conflict with the IETF IPR policies. The RFC
* Editor currently limits the author count to five people. Recent IPR
* WG discussions make it clear to me that authors
Lucy E. Lynch wrote:
Let me try re-stating my question. Is there a one-to-one relationship
between the listed authors on an IETF document and ownership of the
given document's Intellectual Property?
I can answer that one...
No.
___
Ietf mailing
Note:
The IPOD draft says that these notes can be approved by multiple
entities - I did not see any reason to insist that the mechanism impose
a further burden on the IESG for *every* document that needs to be
issued in the course of IETF operations.
So the reason for the IETF in IETF
Call for Entries
After the major success of 'Young ART' 2005 and 'Project Calendar' 2006, artExperiments.com is presenting a series of five international curated exhibition
'Expressions in miniature size'
is first to start from the series.'Expressions in miniature size'
is an inaugural annual
Reading this, a few items caught my eye.
The POSTEDIT requirements seem to be worded as if it is desirable to
minimize the changes that the document editor makes, or even the
changes the document editor can make. The general tone of don't
mess with the words we have carefully honed is
See inline.
Stephen Hayes
-Original Message-
From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 3:17 PM
To: ietf@ietf.org
Subject: Re: LC on draft-mankin-pub-req-08.txt
Reading this, a few items caught my eye.
The POSTEDIT requirements seem to be
.
-- next part --
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/ietf/attachments/20060525/0e9ac6d5/attachment.html
--
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org
On Thu, 25 May 2006, Harald Alvestrand wrote:
Lucy E. Lynch wrote:
Let me try re-stating my question. Is there a one-to-one relationship
between the listed authors on an IETF document and ownership of the
given document's Intellectual Property?
I can answer that one...
No.
Thank you!
--
L2,
The IETF's policy here has a couple of problems I think - and that is that
it limits the number of parties that can claim control over a document and
in doing so limits the representation of legal ownership or rights to the
filing.
This is a very bad thing, since each of those authors has
--On Thursday, 25 May, 2006 07:18 -0500 Stephen Hayes (TX/EUS)
[EMAIL PROTECTED] wrote:
See inline.
Stephen Hayes
-Original Message-
From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 3:17 PM
To: ietf@ietf.org
Subject: Re: LC on
(several lists deleted)
--On Thursday, 25 May, 2006 10:44 +0200 Harald Alvestrand
[EMAIL PROTECTED] wrote:
The Last Call on draft-rfc-editor-author-lists was issued on
May 20, 2002, and the IESG approved that document on August
27, 2002, according to the tracker:
On Thu, 25 May 2006, [EMAIL PROTECTED] wrote:
On Thu, May 25, 2006 at 06:42:06AM -0700, Lucy E. Lynch wrote:
On Thu, 25 May 2006, Harald Alvestrand wrote:
Lucy E. Lynch wrote:
Let me try re-stating my question. Is there a one-to-one relationship
between the listed authors on an IETF
I finished reading the RFC editor document and have one major concern.
Ultimately, the rfc-editor function needs to be accountable to the
IETF community because we're the ones paying for it.
In particular I believe that the IETF should be able to pass a BCP
placing requirements on an
At 05:07 PM 5/24/2006, Vijay Devarapallli wrote:
On 5/24/06, Lakshminath Dondeti [EMAIL PROTECTED] wrote: **
EAP over IKEv2 seems like a more viable alternative: apparently
being proposed in 3G-WLAN interworking scenario as the access auth
protocol. the 3G-WLAN interworking scenario is
I have reviewed the PANA framework document, the PANA protocol spec, and
the PANA/IPsec document. After reading all these documents, I still do
not understand why PANA is useful.
The PANA framework document claims that it can be used along with IEEE
802.11i. However, IEEE 802.11 reviewed the
This is a Last Call for feedback on Version 02 proposed 2008 - 2010 IETF
Meeting dates. The IAOC anticipates taking action to formally adopt
dates on 1 June. These dates differ from the version 01 dates based upon
community feedback, a review of meeting dates of those organizations on
the
Sam,
Some high-level responses, and I'm sure we'll hear other
input:
1/ I think you're overlooking something in IETF pays for RFC
Editor; RFC Editor has been paid by ISOC for years, and *that*
largely comes out of contributions from corporations. We actually
have no data beyond the fact that
Leslie == Leslie Daigle [EMAIL PROTECTED] writes:
Leslie Sam,
Leslie Some high-level responses, and I'm sure we'll hear other
Leslie input:
Leslie 1/ I think you're overlooking something in IETF pays for
Leslie RFC Editor; RFC Editor has been paid by ISOC for years,
Howdy,
I think though that the community ultimately needs to have the power
to take back anything it has given. Basically, I think it is critical
that ultimately everything within the greater IETF context be
accountable to the IETF community. That is true of the IESG, the IAB
and
John Klensin wrote:
Stephen, I routinely complain about too much editing -- if not
on every document I submit for RFC publication, at least most of
them. I believe that, in the last couple of years there has
been a trend toward more editing that I consider gratuitous,
e.g., changing one
After some consideration, I can understand how the current text in
mankin-pub-req would be discouraging to the technical publisher.
If we changed refrain from to exercise restraint in making in requirements
POSTEDIT-3 and POSTEDIT-4, I assume this would solve Joel and John's concerns.
The
Hi Bernard,
-Original Message-
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 25, 2006 4:46 PM
To: ietf@ietf.org
Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?
I have reviewed the PANA framework document, the PANA protocol spec, and
the
Just below you are acknowledging the need for EAP over IP. I don't
understand how you can still claim you don't understand why PANA is
useful...
The framework doesn't seem to talk much about simple EAP over IP
scenarios, so I have assumed this is not the major focus.
You are aware that
--On Thursday, 25 May, 2006 20:27 -0500 Stephen Hayes (TX/EUS)
[EMAIL PROTECTED] wrote:
After some consideration, I can understand how the current
text in mankin-pub-req would be discouraging to the technical
publisher.
If we changed refrain from to exercise restraint in making
in
I can live with that.
And I hope so can those who want to be restrictive as to what editing
takes place.
Yours,
Joel
At 09:27 PM 5/25/2006, Stephen Hayes (TX/EUS) wrote:
After some consideration, I can understand how the current text in
mankin-pub-req would be discouraging to the technical
Hi All,
Please see the updated draft Proposed Experiment: Normative Format in
Addition to ASCII Text at
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.txt, .pdf
version available at
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.pdf.
The draft describes an RFC 3933
On Thursday 25 May 2006 18:39, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'SMTP Submission Service Extension for Future Message Release '
draft-vaudreuil-futuredelivery-03.txt as a Proposed Standard
The IESG plans to
Just below you are acknowledging the need for EAP over IP. I don't
understand how you can still claim you don't understand why PANA is
useful...
The framework doesn't seem to talk much about simple EAP over IP
scenarios, so I have assumed this is not the major focus.
I am sure you
On Thu, May 25, 2006 at 04:45:39PM -0700, Bernard Aboba wrote:
I do understand the potential need for EAP to be encapsulated over IP.
However, in practice PANA is more complex than EAP over UDP
(see draft-thomson-nacp-02.txt), which looks like it is on the road
to becoming the defacto
Yes, that individual I-D is productized as a proprietary protocol by one
company (Cisco).
As I understand it, EAP over UDP is one of the items proposed for
standardization in the NEA WG. That leads me to wonder whether the IETF
will be chartering multiple WGs to standardize EAP
I have other security-related issues on NACP. My view is that secure
enhancement of NACP will be equivalent to the EAP over UDP protocol
the IETF is standardizing, PANA.
Can you describe why the security of PANA is better than EAP over UDP
(NACP)? I had thought that they were more or less
On Thu, May 25, 2006 at 09:24:03PM -0700, Bernard Aboba wrote:
I have other security-related issues on NACP. My view is that secure
enhancement of NACP will be equivalent to the EAP over UDP protocol
the IETF is standardizing, PANA.
Can you describe why the security of PANA is better
The IESG has received a request from an individual submitter to consider the
following document:
- 'SMTP Submission Service Extension for Future Message Release '
draft-vaudreuil-futuredelivery-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
This is a Last Call for feedback on Version 02 proposed 2008 - 2010 IETF Meeting
dates. The IAOC anticipates taking action to formally adopt dates on 1 June.
These dates differ from the version 01 dates based upon community feedback, a
review of meeting dates of those organizations on the Clash
There are two (2) Internet-Draft cutoff dates for the 66th
IETF Meeting in Montreal, Quebec, Canada:
June 19th: Cutoff Date for Initial (i.e., version -00)
Internet-Draft Submissions
All initial Internet-Drafts (version -00) must be submitted by Monday,
June 19th at 9:00 AM ET. As always,
38 matches
Mail list logo
