- Original Message -
From: Ronald Bonica rbon...@juniper.net
To: Noel Chiappa j...@mercury.lcs.mit.edu; ietf@ietf.org
Cc: v6...@ietf.org
Sent: Monday, July 18, 2011 10:20 PM
Noel,
Given that each of us reads something different into the definition of
HISTORIC, is there any hope that
On Jul 19, 2011, at 3:21 AM, t.petch wrote:
What is needed is some lateral thinking, such as the proposal that instead of
trying to shoehorn an RFC into an inappropriate, closed set of maturity
levels,
we use a completely different option, namely an Appplicability Statement that
spells out
On Tue Jul 19 12:51:16 2011, Iñaki Baz Castillo wrote:
2011/7/11 The IESG iesg-secret...@ietf.org:
The IESG has received a request from the BiDirectional or
Server-Initiated HTTP WG (hybi) to consider the following
document:
- 'The WebSocket protocol'
Content-disposition: noise.
Harald, I was about to say the same thing but you beat me to it. Unless we're
prepared to talk about defining a general format for such notices (and I'm
pretty sure we're not interested in doing that), this doesn't fit as a media
type - I can easily envision using
Given that each of us reads something different into the definition of
HISTORIC, is there any hope that this thread will ever converge?
I don't see any progress.
We may just have to blacklist any resolvers that have 6to4 clients
behind them and leave it at that.
Hi all,
The following is the list of 10 Nomcom volunteers selected randomly
from this list: https://datatracker.ietf.org/ann/nomcom/2991/
118. Lianshu Zheng, Huawei Technologies;
35. Stephen Hanna, Juniper Networks;
100. Simo Veikkolainen, Nokia;
44. Sheng Jiang, Huawei Technologies Co. Ltd.;
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please wait for direction from your document shepherd or AD before posting a
new version of the draft.
Document:
In your letter dated Tue, 19 Jul 2011 08:26:26 +0900 you wrote:
Given that each of us reads something different into the definition of HISTO
RIC, is there any hope that this thread will ever converge?
I don't see any progress.
We may just have to blacklist any resolvers that have 6to4 clients
2011/7/11 The IESG iesg-secret...@ietf.org:
The IESG has received a request from the BiDirectional or
Server-Initiated HTTP WG (hybi) to consider the following document:
- 'The WebSocket protocol'
draft-ietf-hybi-thewebsocketprotocol-10.txt as a Proposed Standard
Hi, I assume there is no
As said before, making such DNS SRV specification an extension (so
present in other document) will mean no success at all, as WebSocket
client implementors (i.e. webbrowser vendors) will not be mandated to
implement it and service providers could not rely on the support of
DNS SRV in web
Erik == Erik Kline e...@google.com writes:
Given that each of us reads something different into the
definition of HISTORIC, is there any hope that this thread will
ever converge?
Erik I don't see any progress.
Erik We may just have to blacklist any resolvers that have
On 17 Jul 2011, at 01:52, John C Klensin wrote:
--On Saturday, July 16, 2011 16:03 -0400 Ronald Bonica
rbon...@juniper.net wrote:
A more likely interpretation is as follows:
the IETF is not likely to invest effort in the technology in
the future the IETF does not encourage (or discourage)
On 07/19/2011 14:01, Sabahattin Gucukoglu wrote:
Clearly, the view that making something historic when it's in active use is
offensive. No standards body could seek to stand behind their
specifications, or to give the impression of doing so, with such a position.
Define active use.
--
On 19 Jul 2011, at 02:26, Erik Kline wrote:
Given that each of us reads something different into the definition of
HISTORIC, is there any hope that this thread will ever converge?
I don't see any progress.
We may just have to blacklist any resolvers that have 6to4 clients
behind them and
On Jul 19, 2011, at 2:34 PM, Doug Barton wrote:
On 07/19/2011 14:01, Sabahattin Gucukoglu wrote:
Clearly, the view that making something historic when it's in active use is
offensive. No standards body could seek to stand behind their
specifications, or to give the impression of doing so,
On 20 Jul 2011, at 00:34, Doug Barton wrote:
On 07/19/2011 14:01, Sabahattin Gucukoglu wrote:
Clearly, the view that making something historic when it's in active use is
offensive. No standards body could seek to stand behind their
specifications, or to give the impression of doing so, with
After all, we moved RIPv1 to Historic when it was still widely
implemented, and used in many networks.
Yours,
Joel
On 7/19/2011 5:34 PM, Doug Barton wrote:
On 07/19/2011 14:01, Sabahattin Gucukoglu wrote:
Clearly, the view that making something historic when it's in active use is
offensive.
On 20 Jul 2011, at 01:41, Joel Jaeggli wrote:
On Jul 19, 2011, at 2:34 PM, Doug Barton wrote:
On 07/19/2011 14:01, Sabahattin Gucukoglu wrote:
Clearly, the view that making something historic when it's in active use is
offensive. No standards body could seek to stand behind their
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'Supporting Authentication Trailer for OSPFv3'
draft-ietf-ospf-auth-trailer-ospfv3-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and
The IESG has approved the following document:
- 'Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP
Virtual Private Networks (VPNs)'
(draft-ietf-l3vpn-ibgp-08.txt) as a Proposed Standard
This document is the product of the Layer 3 Virtual Private Networks
Working Group.
The
A new IETF working group has been formed in the Internet Area. For
additional information, please contact the Area Directors or the WG
Chair.
Home Networks (homenet)
---
Current Status: Active Working Group
Chair:
Mark Townsley townsley at
The Protocol Independent Multicast (pim) working group in the Routing
Area of the IETF has been rechartered. For additional information,
please contact the Area Directors or the working group Chairs.
Protocol Independent Multicast (pim)
---
Current Status:
The IESG has approved the following document:
- 'IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast
VPN'
(draft-ietf-l3vpn-mvpn-infra-addrs-05.txt) as a Proposed Standard
This document is the product of the Layer 3 Virtual Private Networks
Working Group.
The IESG contact
The IESG has approved the following document:
- 'CA Key Rollover in the RPKI'
(draft-ietf-sidr-keyroll-08.txt) as a BCP
This document is the product of the Secure Inter-Domain Routing Working
Group.
The IESG contact persons are Stewart Bryant and Adrian Farrel.
A URL of this Internet Draft
The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Flow Aware Transport of Pseudowires over an MPLS Packet Switched
Network'
draft-ietf-pwe3-fat-pw-07.txt as a Proposed Standard
This is a second last call. The last call is
A new Request for Comments is now available in online RFC libraries.
RFC 6283
Title: Extensible Markup Language Evidence Record
Syntax (XMLERS)
Author: A. Jerman Blazic, S. Saljic,
T. Gondrom
Status:
A new Request for Comments is now available in online RFC libraries.
RFC 6319
Title: Issues Associated with Designating Additional
Private IPv4 Address Space
Author: M. Azinger, L. Vegoda
Status: Informational
A new Request for Comments is now available in online RFC libraries.
RFC 6336
Title: IANA Registry for Interactive Connectivity
Establishment (ICE) Options
Author: M. Westerlund, C. Perkins
Status: Standards Track
The Long-Term Archive and Notary Services (ltans) working group in the
Security Area has concluded. The IESG contact persons are Sean Turner
and Stephen Farrell.
The ltans working group has completed its primary charter items, and is
officially closing. The mailing list will be retained for
30 matches
Mail list logo
