Hello Eliot,
Thank you for reading the document. Pleas efind some comments in-line.
2011/3/2, Eliot Lear l...@cisco.com:
Thank you for the opportunity to review this draft. I do so merely as
an individual. It might be a good idea to provide some additional
clarity on when to market
Hello Brian,
You wrote:
Not to mention including the canard that the IETF unilaterally disbanded
its group assigned to work with ITU in 2009. Others with more detailed
knowledge can explain exactly why this is, er, a lie.
Here are some facts:
===
I was member of the MEAD
On Thu, Mar 03, 2011 at 11:27:21AM +0200, Mykyta Yevstifeyev wrote:
2011/3/2, Eliot Lear l...@cisco.com:
imprecise. For one, it is hard to observe what is going on on the
Internet, and those who do don't usually share their data (there is
some, but it is often regionally based, like the
Huub,
Good that you mention that you were part of the design team! That is correct.
You were also part of the team that worked in the face-to-face MEAD team
meeting in Stockholm, July 2009, on the design and the technical direction for
OAM in MPLS-TP. You were part of the team that presented the
03.03.2011 13:56, Andrew Sullivan wrote:
On Thu, Mar 03, 2011 at 11:27:21AM +0200, Mykyta Yevstifeyev wrote:
2011/3/2, Eliot Learl...@cisco.com:
imprecise. For one, it is hard to observe what is going on on the
Internet, and those who do don't usually share their data (there is
some, but it
There are, in my opinion, two problems with Mr. Yevstifeyev's assertion
below that it is easy to determine when things are out of use.
The first point, to echo Andrew Sullivan, is that even if a protocol is
in use on the public Internet, it is not always easy to detect. It may
be used in only
On 3/3/2011 7:11 AM, Joel M. Halpern wrote:
The first point, to echo Andrew Sullivan, is that even if a protocol is in use
on the public Internet, it is not always easy to detect.
...
The second point is that enterprise uses and other private network uses are
still valid uses. The fact that
On 3/3/11 8:18 AM, Dave CROCKER wrote:
On 3/3/2011 7:11 AM, Joel M. Halpern wrote:
The first point, to echo Andrew Sullivan, is that even if a protocol
is in use
on the public Internet, it is not always easy to detect.
...
The second point is that enterprise uses and other private
Joel,
I agree with you that it is really hard and even impossible to determine
what is going on in the Internet regarding some technology, protocol,
etc. If we set the impossible criterion for the Historic documents,
this will really make very few sense. So, as I have been pointed out, I
No, I do not agree with you.
Our current definition for historic, and our current choices for when to
move things, have worked sufficiently well.
I have not seen any evidence that there is a problem that needs solving.
I have also not seen any evidence that the changes you propose to the
Earlier, Joel Halpern wrote:
The first point, to echo Andrew Sullivan, is that even if a protocol
is in use on the public Internet, it is not always easy to detect.
It may be used in only some portions of the net. It may be used
inside some other protocol that makes detection ahrder.
The
--On Thursday, March 03, 2011 10:41 -0500 Joel M. Halpern
j...@joelhalpern.com wrote:
No, I do not agree with you.
Our current definition for historic, and our current choices
for when to move things, have worked sufficiently well.
I have not seen any evidence that there is a problem that
On Thu, Mar 03, 2011 at 04:57:39PM +0200, Mykyta Yevstifeyev wrote:
Andrew, in this case how do you propose to formulate this? Mykyta
Not? The goal you appear to have in this is to make the RFC series
tidy. As the co-chair of a WG with an old and decidedly messy set of
protocol documents, I
FYI. Please direct follow-ups to the apps-discuss list:
https://www.ietf.org/mailman/listinfo/apps-discuss
Original Message
Subject: [apps-discuss] timezone database maintenance
Date: Thu, 03 Mar 2011 09:45:35 -0700
From: Peter Saint-Andre stpe...@stpeter.im
To:
Dear colleagues:
Please find below my (modest) comments on draft-herzog-static-ecdh-05 (an
update of the document that occurred since the moment
of issuing the LC).
Best regards, Rene
==
I. Editorial comments:
(E-a) p. 1, Disclaimer, l. 3: conclusions and should read conclusions, and.
(E-b)
Nurit:
Not to mention including the canard that the IETF unilaterally disbanded
its group assigned to work with ITU in 2009. Others with more detailed
knowledge can explain exactly why this is, er, a lie.
Here are some facts:
===
I was member of the MEAD team.
A meeting
On 2011-03-04 06:51, Russ Housley wrote:
Nurit:
Not to mention including the canard that the IETF unilaterally disbanded
its group assigned to work with ITU in 2009. Others with more detailed
knowledge can explain exactly why this is, er, a lie.
Here are some facts:
===
I
On Thu, 3 Mar 2011, Russ Housley wrote:
It does not sound like the shutdown of the MEAD team was smooth.
However, the closure of a design team when their output is being handled
by a working group is quite normal.
From following this thread, it sounds like the wrong IETF organization
unit
Total of 88 messages in the last 7 days.
script run at: Fri Mar 4 00:53:02 EST 2011
Messages | Bytes| Who
+--++--+
7.95% |7 | 6.82% |37672 | sh...@isc.org
4.55% |4 | 5.22% |28851 | evniki...@gmail.com
The IESG has approved the following document:
- 'HTTP State Management Mechanism'
(draft-ietf-httpstate-cookie-23.txt) as a Proposed Standard
This document is the product of the HTTP State Management Mechanism
Working Group.
The IESG contact persons are Peter Saint-Andre and Alexey Melnikov.
A new Request for Comments is now available in online RFC libraries.
RFC 6058
Title: Transient Binding for Proxy Mobile
IPv6
Author: M. Liebsch, Ed.,
A. Muhanna, O. Blume
Status: Experimental
A new Request for Comments is now available in online RFC libraries.
RFC 6080
Title: A Framework for Session Initiation
Protocol User Agent Profile Delivery
Author: D. Petrie, S. Channabasappa, Ed.
Status: Standards
A new Request for Comments is now available in online RFC libraries.
RFC 6140
Title: Registration for Multiple Phone Numbers
in the Session Initiation Protocol (SIP)
Author: A.B. Roach
Status: Standards Track
A new Request for Comments is now available in online RFC libraries.
RFC 6141
Title: Re-INVITE and Target-Refresh Request Handling
in the Session Initiation Protocol (SIP)
Author: G. Camarillo, Ed.,
C. Holmberg,
A new Request for Comments is now available in online RFC libraries.
RFC 6154
Title: IMAP LIST Extension for Special-Use
Mailboxes
Author: B. Leiba, J. Nicolson
Status: Standards Track
Stream: IETF
25 matches
Mail list logo
