Hello all,
My two cents. Please see inline.
Best wishes,
alice
> -Original Message-
> From: Basavaraj Patil [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 15, 2007 4:13 AM
> To: ext Alexandru Petrescu
> Cc: ipv6@ietf.org; ietf@ietf.org; IETF-Announce; [EMAIL PROTECTED]
> Su
I mentioned "Randy Bush" when I was at the plenary mike tonight.
According to ftp://ftp.rfc-editor.org/in-notes/rfc4264.txt, it's Tim Griffin
and Geoff Huston.
I was at NANOG when Randy presented TIM'S slides -
http://www.nanog.org/mtg-0405/griffin.html. So I inadvertently mis-spoke.
I've sl
Thierry Ernst wrote:
>> When identifying yourself at the mic, it's completely useless if you
>> mumble your name, or say it at even approaching normal speed. Slow down.
>> Many of you mumble it very quickly, and after the amplification system
>> munges it, it's just a buzz.
>>
>> Even if your name
Hi Robert,
--On March 13, 2007 3:23:22 PM -0400 Robert Sayre <[EMAIL PROTECTED]>
wrote:
This text is actively misleading, because it suggests RFC 4346 is
included for informational purposes. The text should read:
"At a minimum, client and server implementations MUST be capable of
being conf
This document has some issues that need to be corrected before it can
pass an IESG last call.
In order of importance:
1) The document equates Ethernet with IEEE 802 and this is clearly
incorrect, since IEEE 802 includes also technologies like Token Ring,
DQDB, Wireless that are clearly outside th
Eric,
Inline
> -Original Message-
> From: Eric Gray (LO/EUS) [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 20, 2007 11:31 AM
> To: Silvano Gai; ietf@ietf.org
> Cc: [EMAIL PROTECTED]
> Subject: RE: [rbridge] Last Call: draft-ietf-trill-routing-reqs
> (TRILLRoutingRequirements in Support
Alex,
On 3/14/07 11:47 AM, "ext Alexandru Petrescu" <[EMAIL PROTECTED]>
wrote:
> Basavaraj Patil wrote:
>> Hello,
>>
>> A slightly revised version of the I-D is now available at:
>> http://people.nokia.net/~patil/IDs/draft-ietf-16ng-ipv6-over-ipv6cs-09.txt
>>
>> This revision incorporates cha
I have a few comments on the document.
- Section 1, Bridging Limitations: The first two paragraphs are
structured around the logic: because ethernet header doesn't have a TTL
or a hop count, the only choice was to use spanning tree. IEEE 802.1 has
defined several headers such as 802.1Q header
IETF participants,
I hope you have a safe trip if attending, otherwise join us online. I
get on a plane in about 3 hours to make the hop over the puddle.
For remote participants and local monitoring, the broadcast schedule for
the audio streaming is up on the IETF 68 streaming webpage:
http://vi
I just got through watching the DFW baggage handler that takes
checked baggage from the x-ray machine back to the conveyor belt. He
went out of his way to be rough with the bags--tossing them high in
the air to land upside down--when simply placing it on the belt would
have required less ef
Hi James,
Response inline:
On 3/14/07 11:14 AM, "ext James Carlson" <[EMAIL PROTECTED]> wrote:
> Basavaraj Patil writes:
>> A slightly revised version of the I-D is now available at:
>> http://people.nokia.net/~patil/IDs/draft-ietf-16ng-ipv6-over-ipv6cs-09.txt
>
> I've read through the docume
> -Original Message-
> From: James Carlson [mailto:[EMAIL PROTECTED]
> I've read through the document as well as (most of) the mailing list
> discussion, and I don't see anything that directly addresses one
> possible issue here.
>
> That issue is the exclusive use of IPv4 or IPv6 on Pac
Dinesh,
Thank you for your comments. Please see below...
Thanks!
--
Eric Gray
Principal Engineer
Ericsson
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dinesh G Dutt
> Sent: Tuesday, March 20, 2007 10:33 PM
> To: ietf@ietf.org
> Cc:
On Wed, 21 Mar 2007, Harald Tveit Alvestrand wrote:
--On 20. mars 2007 09:35 -0700 Silvano Gai <[EMAIL PROTECTED]> wrote:
5) Introduction - Bridging limitation. The first paragraph refers to
Ethernet networks used without Spanning Tree. This is irrelevant, since
Spanning Tree is always deplo
Harald,
As it was originally chartered, the TRILL working group allowed
scope for definition of TRILL bridges that could be cheaply produced,
modulo the inclusion of a ink-state routing protocol as a complicating
factor. It is not clear at this point that this has changed.
Conseq
--On 20. mars 2007 09:35 -0700 Silvano Gai <[EMAIL PROTECTED]> wrote:
5) Introduction - Bridging limitation. The first paragraph refers to
Ethernet networks used without Spanning Tree. This is irrelevant, since
Spanning Tree is always deployed in conjunction with Ethernet. The
correct contrast
16 matches
Mail list logo
