Salut
Vi vi
--
Yves Miezan Ezo
www.chala.biz
www.isoc.fr
www.fossfa.net
www.aprelia.org
Thomas Narten nar...@us.ibm.com a écrit :
Total of 124 messages in the last 7 days.
script run at: Fri Oct 7 00:53:02 EDT 2011
Messages | Bytes | Who
- Original Message -
From: Huub van Helvoort huubatw...@gmail.com
To: ietf@ietf.org
Sent: Friday, September 30, 2011 8:47 AM
All,
Section 1.1 contains the following text:
An analysis of the technical options for OAM solutions was carried
out by a design team (the MEAD team)
Dave,
could you be more precise about what you think the utility of this document is
in this particular situation. I mean, what will its effect be in the current
situation. What will change after this document has been published. It seems
everybody believes the situation will be resolved once
I wanted to pass on some information regarding a BoF that is planned
for Taipei that is relevant to
participants of this mailing list/WG area.
The IAB and IESG met today to discuss BoFs for Taipei and agreed that
we will hold a BoF
SDN with a goal of discussing the
While it is not perfect, I too support publication...
W
On Oct 5, 2011, at 7:11 PM, David Sinicrope wrote:
I concur with Dave's comment and support publication of the draft.
Dave
On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com
wrote:
I think it is unfortunate
Hi all,
I concur with both parts of Dave's message :-( and support publication of the
draft.
I have an editorial/factual comment regarding Section 4.2 of the draft.
Let's begin with the fact that SAToP (i.e. RFC 4553) is not a Draft Standard,
it is a Proposed Standard RFC.
Further, I am not
Hi, all,
I've reviewed this document as a part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to allow
them to address
IMO it is a statement of principle going forward. As such it does not fix or
make go away the current situation, but it would be an IETF consensus
position on a way forward. And I agree with that position.
Lots of folks do proprietary deployments, squat on code points etc. That cannot
be fixed
IMO it is a statement of principle going forward. As such it does not
fix or make go away the current situation, but it would be an IETF
consensus position on a way forward. And I agree with that position.
Lots of folks do proprietary deployments, squat on code points
etc. That cannot be
On 10/7/11 02:36 , t.petch wrote:
I had been waiting a while for a quiet moment on the list to express my regret
at the passing of Watersprings - R.I.P.
Apart from I-D announcements that made to a WG list I track, then watersprings
was my primary source for all I-D, simply because the web
On 7 October 2011 11:36, t.petch wrote:
No thousands of .gif to spend ages downloading, no Megabytes of XML
that take half an hour to process, no https that locks up the
workstation more often than not, no need for a user manual to
explain how to do what; just a simple, self-evident
On 10/7/11 15:32 , Frank Ellermann wrote:
On 7 October 2011 11:36, t.petch wrote:
No thousands of .gif to spend ages downloading, no Megabytes of XML
that take half an hour to process, no https that locks up the
workstation more often than not, no need for a user manual to
explain how to do
Ben,
Thank you for the review .
Some comments below.
Luca
On 10/04/11 16:13, Ben Campbell wrote:
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
The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document:
- 'LFA applicability in SP networks'
draft-ietf-rtgwg-lfa-applicability-03.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
14 matches
Mail list logo
