Hi,
As requested by Fernando and the WG chairs, I've performed a detailed review of
draft-gont-6man-stable-privacy-addresses.
Suggested changes highlighted by pairs of '|'
Abstract
~~
* nit: Perhaps
" This method is meant to be an
alternative to generating Interface Identifiers based
Hi Tim,
- Original Message -
> From: Tim Chown
> To: Fernando Gont
> Cc: Mark ZZZ Smith ; "6man-cha...@tools.ietf.org
> Chairs" <6man-cha...@tools.ietf.org>; 6man WG
> Sent: Friday, 23 August 2013 8:56 PM
> Subject: Re: 6MAN WG Last Call:
>
>
Hi Fernando,
- Original Message -
> From: Fernando Gont
> To: Mark ZZZ Smith
> Cc: Ole Troan ; 6man WG ;
> "6man-cha...@tools.ietf.org Chairs" <6man-cha...@tools.ietf.org>
> Sent: Friday, 23 August 2013 7:58 AM
> Subject: Re: 6MAN WG Last Call:
>
- Original Message -
> From: Mikael Abrahamsson
> To: Erik Kline
> Cc: 6man WG
> Sent: Wednesday, 21 August 2013 3:35 PM
> Subject: Re: 6MAN WG Last Call:
>
> On Tue, 20 Aug 2013, Erik Kline wrote:
>
>> To support this scheme as I understand it, the Linux kernel ipv6 code
>> wo
Hi,
I haven't had a chance to do a thorough read though, however I haven't been
able to find where the following scenarios is dealt with.
In a pure energy efficient scenario, say there are two NEAR routers on the link
(NEAR1, NEAR2). An EAH host (EAH1) at bootstrap chooses NEAR1, registers its
Hi,
Going by the title, it seems my comment was missed about not implying that this
address generation technique is limited to SLAAC slack scenarios, but could be
useful with any address configuration method (i.e, SLAAC, DHCPv6, static,
+future.) There seemed to be some support for decoupling t
Hi,
- Original Message -
> From: Ole Troan
> To: Brian E Carpenter
> Cc: Fernando Gont ; "6...@ietf.org" <6...@ietf.org>;
> Dave Thaler
> Sent: Monday, 12 August 2013 6:59 PM
> Subject: Re: draft-ietf-6man-stable-privacy-addresses: Document title
>
>>>
>>> I will observe that Aliss
- Original Message -
> From: Mark ZZZ Smith
> To: C. M. Heard ; IPv6
> Cc:
> Sent: Friday, 2 August 2013 2:55 PM
> Subject: Re: UDP+Fragmentation (was: "Deprecate")
>
> Hi,
>
>
> - Original Message -
>> From: C. M. Heard
>
Hi,
- Original Message -
> From: C. M. Heard
> To: IPv6
> Cc:
> Sent: Friday, 2 August 2013 3:11 AM
> Subject: Re: UDP+Fragmentation (was: "Deprecate")
>
> On Thu, 1 Aug 2013, RJ Atkinson wrote:
>> I agree that C.M. Heard's ideas should be explored
>> in more detail by the IETF.
>
- Original Message -
> From: Robert Cragie
> To: r...@ietf.org; 6...@ietf.org
> Cc:
> Sent: Wednesday, 24 July 2013 3:44 AM
> Subject: Re: [Roll] trickle-mcast-04 - Clarify scope value of 3 -
> subnet-local
>
> +1
>
> So "subnet" is not the right term. I think "network" as
> R
Hi Brian,
- Original Message -
> From: Brian E Carpenter
> To: Mark ZZZ Smith
> Cc: IPv6 IPv6 List
> Sent: Tuesday, 23 July 2013 8:00 AM
> Subject: Re: 6MAN WG Last Call:
>
> On 23/07/2013 09:12, Mark ZZZ Smith wrote:
>> Hi,
>>
>>
>
- Original Message -
> From: Brian E Carpenter
> To: 6man
> Cc:
> Sent: Tuesday, 23 July 2013 6:41 AM
> Subject: Re: 6MAN WG Last Call:
>
>T he draft contains one open issue, in section 7:
>
>> OPEN ISSUE: Alternatively, we could decide to close the reserved IID
>> registr
Hi,
Firstly, I support advancing this draft.
Some suggested changes:
" This has no known harmful effect as long as the
replicated MAC addresses and IIDs are used on different layer 2
links. If they are used on the same link, of course there will be a
problem, to be detected by duplica
- Original Message -
> From: Karl Auer
> To: IETF IPv6
> Cc:
> Sent: Friday, 28 June 2013 10:32 AM
> Subject: Re: question re REBIND in RFC 3315 (DHCPv6)
>
> On Thu, 2013-06-27 at 17:13 -0700, Mark ZZZ Smith wrote:
>> Perhaps a DHCPv6 server could have
- Original Message -
> From: Karl Auer
> To: IETF IPv6
> Cc:
> Sent: Friday, 28 June 2013 12:09 AM
> Subject: Re: question re REBIND in RFC 3315 (DHCPv6)
>
> On Thu, 2013-06-27 at 07:17 -0400, Ralph Droms wrote:
>> There is another difference between REBIND and RENEW: the client
>>
- Original Message -
> From: Fred Baker (fred)
> To: Randy Bush
> Cc: IPv6 Deployment Prevention
> Sent: Wednesday, 26 June 2013 1:30 PM
> Subject: Re: New Version Notificationfor
draft-bonica-6man-frag-deprecate-00.txt
>
>
> On Jun 25, 2013, at 12:42 PM, Randy Bus
Hi,
Here's a new version of my stateless neighbor discovery draft. Changes:
- make it more obvious that hosts don't need to be changed
- more informative introduction/problem definition text
- allow low end/embedded platforms to consider all traffic sources untrusted if
a DoS attack is occurring
Hi,
- Original Message -
> From: Carsten Bormann
> To: Samita Chakrabarti
> Cc: 6man Mailing List
> Sent: Friday, 12 October 2012 5:23 PM
> Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-00.txt
>
>T wo quick comments:
>
> Clearly, mitigating the external ND table DoS is
Hi,
I agree with Ray, I think this is fundamentally just re-inventing the wheel.
I notice that one of the justifications for this is that "DHCPv6 is not
required in all 3GPP releases." Why isn't it? Based on this statement,
it seems to me that the 3GPP architecture doesn't recognise that there
Hi,
- Original Message -
> From: Rui Paulo
> To: "ipv6@ietf.org Mailing List"
> Cc:
> Sent: Wednesday, 10 October 2012 6:25 AM
> Subject: Re: 6MAN WG Last Call:
>
> On 4 Oct 2012, at 14:53, Bob Hinden wrote:
>
>> All,
>>
>> This message starts a two week 6MAN Working Group on ad
Hi,
I'd be interested if people think the idea has merit, and is worth putting more
time into.
Thanks very much,
Mark.
- Forwarded Message -
> From: "internet-dra...@ietf.org"
> To: markzzzsm...@yahoo.com.au
> Cc:
> Sent: Sunday, 7 October 2012 11:41 AM
> Subject: New Version Notific
21 matches
Mail list logo
