Fernando,
Rather than repeating myself, I'll suggest a change to the Introduction
that would (IMHO) improve the message:
OLD:
1. Introduction
Most general-purpose operating systems implement and enable native
IPv6 [RFC2460] support and a number of transition/co-existence
technologies
Just picking a couple of points for further comment:
On 02/04/2013 08:46, Liubing (Leo) wrote:
> Hi, Robert
...
>> -Original Message-
>> From: Robert Sparks [mailto:rjspa...@nostrum.com]
...
>> The document currently references
>> draft-chown-v6ops-renumber-thinkabout
>> several times.
>
Kids! Remember, if we're not bright enough to do physics, we can always do
engineering, the slow younger brother of physics! But if engineering is too
difficult, there's always computer science, where terms like "bandwidth" mean
what we want them to mean. And if even that's too hard, there's a
Resending due to Richards change of address.
Stewart
On 11/02/2013 23:45, Richard Barnes wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART,
pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for
On Apr 2, 2013, at 6:41 AM, l.w...@surrey.ac.uk wrote:
> Kids! Remember, if we're not bright enough to do physics, we can always do
> engineering, the slow younger brother of physics!
Is your point that if we do an engineering solution, that will slow things down
enough that we won't have packet
Thanks for following up, and for the re-send. Just to be clear, I do not
mean these as blocking points.
On the former point, I might just suggest a minor edit to the introduction:
OLD: "This document specifies the options for determination and selection
of next-hop Ethernet MAC addressing under t
I have not yet completed a full review of this (320-page) document, and I
worry that I may not finish before the deadline, so I am bringing this
concern to your attention now.
Section 3.2.1.1 of this document ("Kerberos V5 as a security triple")
seems to indicate that it is mandatory for a con
Fine with me.
On Apr 1, 2013, at 5:41 PM, Robert Sparks wrote:
> On 3/28/13 1:17 PM, SM wrote:
>> Hi Eric,
>> At 05:13 28-03-2013, Burger Eric wrote:
>>> Rather than guessing all of the bad things that could happen, I would offer
>>> it would be better to say what we mean, like:
>>>The
Hi Russ,
Thanks for your comments, very good points.
Sorry for the delay in replying, I was out of office.
The following is my proposed text for replacing the current first
paragraph of section 1.2.
Traditional transport technologies include SONET/SDH, TDM, and ATM. There
is a transition awa
Hi, Robert
Thanks a lot for your careful and detailed review. It is very helpful to refine
the draft.
Please see replies inline.
> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Tuesday, April 02, 2013 4:47 AM
> To: 6re...@ietf.org; draft-ietf-6renum-gap-
Works for me.
--
Sent from my mobile device. Thanks be to lemonade!
http://www.standardstrack.com/ietf/lemonade/
-Original message-
From: Alexey Melnikov
To: Burger Eric
Cc: Robert Sparks , ietf@ietf.org
Sent: Tue, Apr 2, 2013 09:53:39 GMT+00:00
Subject: Re: Missing requirement in d
Hi Luyuan,
You wrote (in part):
..since multiplexing of bursty sources is far more efficient over
traditional circuit-based
TDM technologies.
Which is not true and probably not what you meant.
A better formulation might be "since packet multiplexing of traffic from bursty
sources provide
Hi, Brian
> >> The document currently references
> >> draft-chown-v6ops-renumber-thinkabout
> >> several times.
> >> That document is long expired (2006). It would be better to simply
> >> restate what is
> >> important from that document here and reference it only once in the
> >> acknowlegements
Works for me. Thanks, Paul.
Luyuan
-Original Message-
From: , "Paul (NSN - US/Irving)"
Date: Tuesday, April 2, 2013 7:58 AM
To: Luyuan Fang , Russ Housley ,
"ietf@ietf.org"
Cc: "m...@ietf.org"
Subject: RE: [mpls] Last Call:
>Hi Luyuan,
>
>You wrote (in part):
>
>..since multiple
AB,
On Apr 1, 2013, at 5:45 PM, Abdussalam Baryun
wrote:
> RFC6921>It is well known that as we approach the speed of light, time
> slows down.
> AB> I know that time slows for something when it is in speed of light,
> but communication is not something moving. If the packet is in speed
> of lig
On 4/2/2013 2:58 AM, Brian E Carpenter wrote:
Just picking a couple of points for further comment:
On 02/04/2013 08:46, Liubing (Leo) wrote:
Hi, Robert
...
-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]
...
The document currently references
draft-chown-v6ops-
On 04/01/2013 06:14 PM, SM wrote:
>> with IPv6 connectivity. However, it's inappropriate to rely on
>> pervasive implementation of Happy Eyeballs as the sole solution to
>> prevent end host impacts, since the end user may not know that IPv6 is
>> actively being disabled on this network, or that the
On Apr 2, 2013, at 7:30 PM, Fernando Gont wrote:
>> I agree with the last sentence. Happy Eyeballs is about the HTTP.
>> There are other applications protocols too. :-)
>
> Happy eyeballs is about HTTP. But part of the approach predates "Happy
> Eyeballs" -- please see RFC5461.
It's certainly
Hi Fernando,
At 16:30 02-04-2013, Fernando Gont wrote:
Happy eyeballs is about HTTP. But part of the approach predates "Happy
Eyeballs" -- please see RFC5461.
Ok.
Removing the records when you're not going to allow such
connectivity reduces the potential problem (at the end of the day, t
On Mar 30, 2013, at 11:26 PM, Christian Huitema wrote:
>> IPv6 makes publishing IP address reputations impractical. Since IP address
>> reputation has been a primary method for identifying abusive sources with
>> IPv4, imposing ineffective and flaky > replacement strategies has an effect
>>
20 matches
Mail list logo
