You can't change your earlier public statement; that would be tampering
with the historical record.
You can, however, file a new statement that updates the old one, as you
have already done by filing #954, listed as an update of #201, and #955,
#956, #957, #958, #959, #960, #961, #962 and
IETF Chair wrote:
From the discussion just prior to the recent appeal by John Klensin, it
was clear that the guidance regarding example domain names in IETF
documents provided in the ID-Checklist needed to be updated. This point
was emphasized further during the discussion of the Klensin
I beleiev that the IESG approved the 1.8 version for which Russ called
for review on the IETF list.
Anyway, the 1,8 version (with change) is online as
http://www.ietf.org/ID-Checklist.html
Meanwhile I am working on revision 1.9 and I am making changes as I
have been posting to the ietf list
Harald Alvestrand [EMAIL PROTECTED] writes:
You can't change your earlier public statement; that would be
tampering with the historical record.
The IETF appears to permit patent disclosures to be removed at the
request of submitters. Search for 'remove' on the list if disclosures.
Is this
The revision 1.8 of the ID-Checklist is at
http://www.ietf.org/ID-Checklist.html
Sect 3, item 6 in that revision states:
6. Addresses used in examples SHOULD use fully qualified
domain names instead of literal IP addresses, and SHOULD
use example fqdn's such as
Harald Alvestrand [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
Harald Alvestrand [EMAIL PROTECTED] writes:
You can't change your earlier public statement; that would be
tampering with the historical record.
The IETF appears to permit patent disclosures to be removed at the
Simon Josefsson wrote:
Harald Alvestrand [EMAIL PROTECTED] writes:
At least one of the removed patent licenses promises to make available
patent licenses on fair, reasonable, reciprocal and non-discriminatory
terms. It seems unfortunate that IETF allows organizations to file such
claims
Harald Alvestrand [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
Harald Alvestrand [EMAIL PROTECTED] writes:
At least one of the removed patent licenses promises to make available
patent licenses on fair, reasonable, reciprocal and non-discriminatory
terms. It seems unfortunate that
good stuff
---
From [EMAIL PROTECTED] Wed Aug 13 06:54:56 2008
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.359
X-Spam-Level:
Hi Rubin,
Can you provide the documents in a readable format? Did you look at
SIGTRAN protocols?
You might want to send an e-mail also to the SIGTRAN mailing list...
Best regards
Michael
On Aug 13, 2008, at 2:29 PM, Rubin Rose wrote:
Dear members,
I was inspired to submit content in order
Isn't it a little too redundant to include the parenthetical
RFC 2606 or its successors along with BCP 32?
--
Eric Gray
Principal Engineer
Ericsson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Bert Wijnen (IETF)
Sent: Wednesday, August 13,
Scott Kitterman [EMAIL PROTECTED] writes:
My suggestion is adopt a rule that code snippets in any RFC MUST include a
comment to the effect that This code was derived from IETF RFC . If
it's in the code snipppet as a comment to copy/paste virtually everyone will
copy/paste it. I
Looks good. My only comment is about where the justification is to be
provided - the PROTO writeup is at least an alternative to putting
this into the document itself, and IMO it's a better alternative.
Lars
On 2008-8-13, at 12:21, ext Bert Wijnen (IETF) wrote:
The revision 1.8 of the
Not having it actually in the RFC itself means that it effectively
disappears on publication. This is both a feature and a flaw.
If the justification is included in the published RFC, the precedent
is very much clearer (and - thus - much less likely to be the cause
of confusion and discussion in
On Wed, 13 Aug 2008 15:24:19 +0200 Simon Josefsson [EMAIL PROTECTED]
wrote:
Scott Kitterman [EMAIL PROTECTED] writes:
My suggestion is adopt a rule that code snippets in any RFC MUST include
a
comment to the effect that This code was derived from IETF RFC .
If
it's in the code
At 04:59 13-08-2008, Harald Alvestrand wrote:
On the other hand (trying to play devil's advocate), if the promise
was made by someone in the organization that did not have authority
to commit the organization to that statement, I could see why the
responsible persons for that organization
--On Wednesday, August 13, 2008 3:27 PM +0200 Lars Eggert
[EMAIL PROTECTED] wrote:
Looks good. My only comment is about where the justification
is to be provided - the PROTO writeup is at least an
alternative to putting this into the document itself, and IMO
it's a better alternative.
On Tue, 12 Aug 2008, Scott Brim wrote:
On 8/12/08 12:02 PM, TS Glassey allegedly wrote:
As to the IPR Page - it does not
allow for updates of already filed IPR Statement's to include new IETF
documents which violate the patent rights after the posting of the IPR
Notice.
How can a
--On Wednesday, August 13, 2008 8:13 AM -0500 Eric Gray
[EMAIL PROTECTED] wrote:
Isn't it a little too redundant to include the parenthetical
RFC 2606 or its successors along with BCP 32?
This is really a separate topic and one that it would be nice
if, after all these years, the IESG,
Somebody claiming to be Rubin Rose wrote:
Any review, retransmission, dissemination, or other use of
this information, or taking of any action in reliance upon
it by persons or entities other than the intended recipient
is prohibited.
Further PDFs or other communications claiming to be mail
--On Wednesday, August 13, 2008 2:21 PM +0200 Simon Josefsson
[EMAIL PROTECTED] wrote:
If the IETF removes patent disclosures, I believe the IETF
will find itself in the position of evaluating the
_correctness_ of patent related claims. This seems like the
wrong approach.
Or the authority
At 3:21 AM -0700 8/13/08, Bert Wijnen (IETF) wrote:
John Klensin has proposed new text, whcih was amended by
Ted Hardie and the resulting text (if I understood it correctly) is:
6. Addresses used in I-Ds SHOULD use fully qualified
domain names (FQDNs) instead of literal IP
At 5:46 AM -0700 8/13/08, Scott Kitterman wrote:
The copyright statement cannot be removed (and that is fine with any license
that I'm aware of), so it will always be clear that the code came from an
RFC. I believe that the IETF is sufficiently notable that the IETF standard
copyright notice is
Bert Wijnen (IETF) wrote:
- Original Message - From: Dave Crocker [EMAIL PROTECTED]
RFC 3979 says what is to be in an RFC, not what isn't. The Checklist says
what isn't.
The proble we saw in the IESG (when we started ID_Checklist) was that we saw
A LOT OF I-Ds that requested
Bert Wijnen (IETF) wrote:
- Original Message - From: Dave Crocker [EMAIL PROTECTED]
RFC 3979 says what is to be in an RFC, not what isn't. The Checklist says
what isn't.
The proble we saw in the IESG (when we started ID_Checklist) was that we saw
A LOT OF I-Ds that requested
Hi, Dave,
While it is vastly more convenient, for the IESG, to have it take
initiative and
decide on its own to make a more strict rule and issue it in a document
that
does not go through public vetting, it isn't the way things are supposed
to be
done in the IETF.
Just to ring one of the
At 03:21 13-08-2008, Bert Wijnen \(IETF\) wrote:
John Klensin has proposed new text, whcih was amended by
Ted Hardie and the resulting text (if I understood it correctly) is:
6. Addresses used in I-Ds SHOULD use fully
qualifieddomain names (FQDNs) instead of literal IP
How can a description of how to use a technology infringe on a patent?
A standard isn't merely a description, as in a magazine article, but
also represents an industry agreement on the definition of a product. A
draft or WG could encourage persons to violate a patent, which is
indirect
I think it would be better to use phrasing like this:
BCP 32 (currently RFC 2606)
Tony Hansen
[EMAIL PROTECTED]
John C Klensin wrote:
--On Wednesday, August 13, 2008 8:13 AM -0500 Eric Gray
[EMAIL PROTECTED] wrote:
Isn't it a little too redundant to include the parenthetical
RFC
For the RTP media, your PON is a tunnel, and there needs to be a way to bring
up the tunnel and do some VJ-like compression of the IP/UDP/RTP headers. You
should look at ROHC http://tools.ietf.org/wg/rohc, ECRTP (RFC3545), and
TCRTP (RFC4170) to see what has been proposed in this area to date.
On 2008-08-14 05:10, John C Klensin wrote:
--On Wednesday, August 13, 2008 2:21 PM +0200 Simon Josefsson
[EMAIL PROTECTED] wrote:
If the IETF removes patent disclosures, I believe the IETF
will find itself in the position of evaluating the
_correctness_ of patent related claims. This
On Wed, 13 Aug 2008 12:48:07 -0400 (EDT)
Dean Anderson [EMAIL PROTECTED] wrote:
On Tue, 12 Aug 2008, Scott Brim wrote:
On 8/12/08 12:02 PM, TS Glassey allegedly wrote:
As to the IPR Page - it does not
allow for updates of already filed IPR Statement's to include new
IETF documents
Steven M. Bellovin wrote:
On Wed, 13 Aug 2008 12:48:07 -0400 (EDT)
Dean Anderson [EMAIL PROTECTED] wrote:
On Tue, 12 Aug 2008, Scott Brim wrote:
On 8/12/08 12:02 PM, TS Glassey allegedly wrote:
As to the IPR Page - it does not
allow for updates of already filed IPR Statement's to include
Date:Wed, 13 Aug 2008 13:13:46 -0500
From:Spencer Dawkins [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| I'm actually OK with the process that Dave is not OK with, because I'm
| assuming that public vetting can also be retroactive - as long as the
| IESG
The IESG has approved the following document:
- 'A Two-way Active Measurement Protocol (TWAMP) '
draft-ietf-ippm-twamp-09.txt as a Proposed Standard
This document is the product of the IP Performance Metrics Working Group.
The IESG contact persons are Lars Eggert and Magnus Westerlund.
A
A new Request for Comments is now available in online RFC libraries.
RFC 5213
Title: Proxy Mobile IPv6
Author: S. Gundavelli, Ed.,
K. Leung, V. Devarapalli,
K. Chowdhury, B. Patil
Status: Standards
A new Request for Comments is now available in online RFC libraries.
RFC 5215
Title: RTP Payload Format for Vorbis
Encoded Audio
Author: L. Barbato
Status: Standards Track
Date: August 2008
A new Request for Comments is now available in online RFC libraries.
RFC 5276
Title: Using the Server-Based Certificate Validation
Protocol (SCVP) to Convey Long-Term Evidence
Records
Author: C. Wallace
38 matches
Mail list logo
