At 16:33 -0400 6/1/11, Andrew Sullivan wrote:
I believe that nothing anywhere in the document suggests that one
ought to guage conformance of software against the registry, and if
you think it says that somewhere, I'd like a pointer to where. It
would need to be fixed if it said that, but as
I do not find any IPR disclosures against draft-ietf-pwe3-segmented-pw, the
Internet-Draft that became RFC 6073. As a result, I am very concerned by the
extremely late notice of patents by Alcatel Lucent, especially since RFC 6073
and the patent have a common author. This fact makes it very
On Wed, Jun 1, 2011 at 11:03 AM, Edward Lewis ed.le...@neustar.biz wrote:
At 8:22 -0700 5/26/11, The IESG wrote:
The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA
Hi Yaron,
Thanks for the comments.
Please see inline [VC].
-Violeta
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron
Sheffer
Sent: Sunday, May 22, 2011 2:38 PM
To: ietf@ietf.org
Cc: IPsecme WG;
The IESG is considering making this statement on the
processing of RFC Errata concerning RFC Metadata.
We would appreciate community feedback.
Please can we have feedback by Thursday 9th June.
Thanks
Stewart
==
Draft text for IESG Statement on RFC Metadata
Date: xx-xxx-
This IESG
At 14:10 -0400 6/2/11, Scott Rose wrote:
Then perhaps a wording change? It seems that it is confusion over the
language rather than the purpose.
A wording change is probably needed, but I can't suggest one because
I can't determine what the goal is from what's currently written. I
know
The IESG is considering making this statement on the IESG Handling of
Historic status.
We would appreciate community feedback.
Please can we have feedback by Thursday 9th June.
Thanks
spt
statement begins
RFC 2026 states the following:
A specification that has been superseded by a more
I'd prefer that we not clutter abstracts with instructions to the RFC
editor and prefer that the IESG only recommend such statements in the
introduction.
I'm OK with whatever here though: the IESG should go do something
intelligent in this space.
___
Sean,
Seems fine to me but, like Sam, I'd prefer to not clutter
abstracts For a specification RFC that is rendered Historic by
a new specification, the combination of an Obsoletes header
and a note in the Introduction ought to be sufficient.
While the IESG is considering this, I would encourage
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sam
Hartman
Sent: Thursday, June 02, 2011 12:47 PM
To: Sean Turner
Cc: ietf@ietf.org; The IESG
Subject: Re: Proposed text for IESG Handling of Historic Status
I'd prefer that we not
On Jun 2, 2011 4:05 PM, John C Klensin john-i...@jck.com wrote:
While the IESG is considering this, I would encourage you to
also consider the model used to make a specification that is
simply and obviously obsolete (and in A/S terms not
recommended) Historic without having to have an I-D
On 6/2/11 4:45 PM, Scott Brim wrote:
On Jun 2, 2011 4:05 PM, John C Klensin john-i...@jck.com
mailto:john-i...@jck.com wrote:
But for the no one cares about it any more cases, it seems like a
lighter-weight procedure, such as a Last Call on the question
does anyone believe that our
At 01:04 PM 6/2/2011, John C Klensin wrote:
While the IESG is considering this, I would encourage you to
also consider the model used to make a specification that is
simply and obviously obsolete (and in A/S terms not
recommended) Historic without having to have an I-D written and
processed into
--On Thursday, June 02, 2011 17:51 -0500 Pete Resnick
presn...@qualcomm.com wrote:
Agree, but producing such a no one cares anymore RFC and
getting it through the process should be lightweight enough
already. It should slide right through.
For better or worse, I don't believe that has
Total of 68 messages in the last 7 days.
script run at: Fri Jun 3 00:53:01 EDT 2011
Messages | Bytes| Who
+--++--+
17.65% | 12 | 53.78% | 632993 | jason_living...@cable.comcast.com
8.82% |6 | 4.38% |51500 |
A new IETF working group has been proposed in the Operations and
Management Area. The IESG has not made any determination as yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list
(i...@ietf.org) by
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Advisory Guidelines for 6to4 Deployment'
draft-ietf-v6ops-6to4-advisory-01.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments
81st IETF Meeting
Quebec City, Canada
July 24 - 29, 2011
Host: Research In Motion (RIM)
Register online at: http://www.ietf.org/meetings/81/
1. Registration
2. Social Event - Musee de la civilisation
3. Meeting and Training Schedule
4. Visas Letters of Invitation
5. Accommodations,
This document is now a Draft Standard Protocol.
RFC 5591
Title: Transport Security Model for the
Simple Network Management Protocol (SNMP)
Author: D. Harrington, W. Hardaker
Status: Standards Track
Stream:
This document is now a Draft Standard Protocol.
RFC 5590
Title: Transport Subsystem for the Simple
Network Management Protocol (SNMP)
Author: D. Harrington, J. Schoenwaelder
Status: Standards Track
Stream:
This document is now a Draft Standard Protocol.
RFC 5343
Title: Simple Network Management Protocol (SNMP)
Context EngineID Discovery
Author: J. Schoenwaelder
Status: Standards Track
Stream: IETF
21 matches
Mail list logo