On 2012-05-11 21:16, Randy Bush wrote:
>>> i beg to differ. i have used the restrictive clause for years exactly
>>> as fernando states. if the wg does not adopt, then i may take *my*
>>> marbles and go home.
>> Thanks for saying it so clearly. I choose to not do that as do many
>> others. I al
>> i beg to differ. i have used the restrictive clause for years exactly
>> as fernando states. if the wg does not adopt, then i may take *my*
>> marbles and go home.
> Thanks for saying it so clearly. I choose to not do that as do many
> others. I allow my contributions to be used by others in
Randy,
>>>
>> It is allowed and I don't want to start a big IPR thread here, but I
>> think the intent for this clause (no derivative works) is for work
>> that someone wants to present to a w.g. that was not intended to be an
>> IETF work item. My opinion is that it's not appropriate for docume
i have scanned and support adoption of the draft as a wg item.
>> My understanding is that this is perfectly compatible with the IETF
>> standards process, as long as this restriction is removed before posting
>> as draft-ietf (for instance, I guess that's why it's allowed in the
>> first place).
Earlier, Bob Hinden wrote:
> It is allowed and I don't want to start a big IPR thread here,
> but I think the intent for this clause (no derivative works)
> is for work that someone wants to present to a w.g. that
> was not intended to be an IETF work item. My opinion is
> that it's not appropriat
Hi, Bob,
On 05/10/2012 08:36 AM, Bob Hinden wrote:
>>> - The current draft is written to not allow the IETF to create
>>> derivative works. This is incompatible with the IETF standards
>>> process. See section 4 of
>>> http://www.ietf.org/id-info/1id-guidelines.txt
>>
>> My understanding is that
Fernando,
On May 9, 2012, at 7:50 PM, Fernando Gont wrote:
> Hi, Ole,
>
> On 05/08/2012 02:42 PM, Ole Trøan wrote:
>> The discussion brought up some issues that we will work with the author to
>> resolve, in particular:
>>
>> - The current draft is written to not allow the IETF to create deriva
Hi, Ole,
On 05/08/2012 02:42 PM, Ole Trøan wrote:
> The discussion brought up some issues that we will work with the author to
> resolve, in particular:
>
> - The current draft is written to not allow the IETF to create derivative
> works.
>This is incompatible with the IETF standards proce
All,
Based on the feedback received, the 6man chairs believe there is consensus
for 6MAN to work on creating a new type of IPv6 interface identifiers,
as described in draft-gont-6man-stable-privacy-addresses-01.
The discussion brought up some issues that we will work with the author to
resolve, i
On 04/21/2012 06:10 AM, Mohacsi Janos wrote:
>>> The client application
>>> based on the policy should pick pivate or EUI-64 addresses.
>>
>> Just curious: Is there a specific use case for IEEE-derived addresses
>> that cannot be satisfied with draft-gont-6man-stable-privacy-addresses?
>
> The exi
On Fri, 20 Apr 2012, Fernando Gont wrote:
Hi, Mohacsi,
On 04/20/2012 10:09 AM, Mohacsi Janos wrote:
I support to have a semi stable private address. But very much
against the idea of replacing EUI-64 addresses.
You mean "against replacing addresses embedding IEEE identifiers"?
yes.
Hi, Mohacsi,
On 04/20/2012 10:09 AM, Mohacsi Janos wrote:
> I support to have a semi stable private address. But very much
> against the idea of replacing EUI-64 addresses.
You mean "against replacing addresses embedding IEEE identifiers"?
> The client application
> based on the policy shou
Dear All,
I support to have a semi stable private address. But very much
against the idea of replacing EUI-64 addresses. The client application
based on the policy should pick pivate or EUI-64 addresses.
Note: - Nothing stops me to pick MAC addresses from no longer existing
vendor e.g DEC
I
Personally I support this draft. But would like to see stable privacy
enhanced addresses as a replacement for IEEE-based addresses since
they allow an attacker to infer to the vendor of a NIC. On OUIs of
Apple Inc. they also allow conclusion to the operating system.
Thus an attacker gets more info
On 04/19/2012 10:34 AM, Eliot Lear wrote:
>> It's not an argument against RFc4941, but rather an argument that even
>> with RFC4941, you still need to do something about the IEEE-based IIDs.
>> At the Paris IETF, some folks argued that if you have RFC 4941 in place,
>> you don't need draft-gont-6ma
On 4/18/12 5:43 PM, Fernando Gont wrote:
> Hi, Eliot,
>
> On 04/18/2012 06:37 AM, Eliot Lear wrote:
>>> On 04/13/2012 10:09 AM, Eliot Lear wrote:
At one point you write that the intent is to replace EUI-64-based
addresses (Section 5).
>>> Exactly.
> [Correcting myself]
>
> The intent
Hi, Eliot,
On 04/18/2012 06:37 AM, Eliot Lear wrote:
>> On 04/13/2012 10:09 AM, Eliot Lear wrote:
>>> At one point you write that the intent is to replace EUI-64-based
>>> addresses (Section 5).
>> Exactly.
[Correcting myself]
The intent is to have draft-gont-6man-stable-privacy-addresses used
Dear Fernando,
My apologies for the delayed response:
On 4/13/12 2:31 PM, Fernando Gont wrote:
> hI, Eliot,
>
> On 04/13/2012 10:09 AM, Eliot Lear wrote:
>> At one point you write that the intent is to replace EUI-64-based
>> addresses (Section 5).
> Exactly.
>
>
>> But that doesn't seem to jib
Dear all,
I support this document to be an official working group document.
IPv6 is being considered to be a protocol providing Internet access from
vehicles. When we consider vehicular communications, location privacy
becomes vital. The described mechanism "stable-privacy-addresses" would
help f
Speaking for myself, I don't understand the fixation on MAC addresses. Yes,
Ethernet and other IEEE standards are widely used. They are not used on serial
links (we seem to mostly use /127 prefixes for that), they are not used on the
air side of 3G etc, and so on. And as a matter of fact, for al
On 14 Apr 2012, at 01:36, Karl Auer wrote:
> On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote:
>> Additionally, I'd argue that in order to have such thing, then
>> 1) You'd need to manually configure your address each time you move from
>> one network to another (as with manual configuratio
On Sat, 2012-04-14 at 14:24 +0800, Washam Fan wrote:
> So what is the next step if the autoconfiguration fails? static
> configure? If yes. Will the next reboot try autoconfiguration again?
> If yes, you may have non-stable addresses within the same network. If
> no, when you move to another networ
Hi,
>> > 5: Duplicate address detection is not mentioned explicitly, but probably
>> > should be - what happens if a host does DAD and determines that its
>> > stable address is already in use?
>>
>> Address configuration fails.
>
> That should be in the spec.
>
>> That said, if deemed appropriate
On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote:
> "IPv6 implementations conforming to this specification MUST generate
> interface identifiers using the algorithm specified in this section in
> replacement of Modified EUI-64 format identifiers."
> ?
While that is good, it would be clearer
Hi, Tim,
Thanks so much for your feedback! Please find my comments inline...
On 04/13/2012 12:37 PM, Tim Chown wrote:
> Extensions. If I understand it correctly, essentially what you are
> defining is randomised stable-per-prefix public interface
> identifiers,
Exactly.
> On 3484bis, if stab
Hi, Karl,
Thanks so much for your feedback! Please find my comments inline...
["Subject" changed so that this discussion doesn't mix up with the poll]
On 04/13/2012 02:14 AM, Karl Auer wrote:
> That said, I have some comments. My apologies if I have missed some
> discussion where these were cov
hI, Eliot,
On 04/13/2012 10:09 AM, Eliot Lear wrote:
> At one point you write that the intent is to replace EUI-64-based
> addresses (Section 5).
Exactly.
> But that doesn't seem to jibe with what you
> write in the intro about RFC-4941.
Could you please cite the "conflicting" text?
> I
On 13 Apr 2012, at 08:14, Brian E Carpenter wrote:
> On 2012-04-12 22:28, Bob Hinden wrote:
>> All,
>>
>> This is a consensus call on adopting:
>>
>>Title : A method for Generating Stable Privacy-Enhanced Addresses with
>>IPv6 Sta
A question for the draft author:
At one point you write that the intent is to replace EUI-64-based
addresses (Section 5). But that doesn't seem to jibe with what you
write in the intro about RFC-4941. I am concerned that adopting this
mechanism will make matters worse if this mechanism is being
On 2012-04-12 22:28, Bob Hinden wrote:
> All,
>
> This is a consensus call on adopting:
>
> Title : A method for Generating Stable Privacy-Enhanced Addresses with
> IPv6 Stateless Address Autoconfiguration (SLAAC)
> Author(s) : Fernando Gont
&g
On Thu, 2012-04-12 at 14:28 -0700, Bob Hinden wrote:
> This is a consensus call on adopting:
>
> Title : A method for Generating Stable Privacy-Enhanced Addresses with
> IPv6 Stateless Address Autoconfiguration (SLAAC)
> Author(s) : Fernando Gont
, I'd be in favor of pursuing this.
Bert
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Bob
Hinden
Sent: Thursday, April 12, 2012 5:29 PM
To: IPv6 WG Mailing List
Cc: 6man Chairs
Subject: Consensus call on adopting:
All,
This is a cons
All,
This is a consensus call on adopting:
Title : A method for Generating Stable Privacy-Enhanced Addresses with
IPv6 Stateless Address Autoconfiguration (SLAAC)
Author(s) : Fernando Gont
Filename : draft-gont-6man-stable-privacy-addresses-01
Pages : 15
All,
There is consensus to adopt this document as a 6MAN draft. The
authors are instructed to post the next version as a 6MAN draft.
Regards,
Brian, Bob, & Ole
On 2/24/12 8:21 AM, Brian Haberman wrote:
All,
This is a consensus call on adopting:
Filename: draft-hsingh-6man-enhanced
On 2/24/12 5:21 AM, Brian Haberman wrote:
All,
This is a consensus call on adopting:
Filename: draft-hsingh-6man-enhanced-dad
Revision: 04
Title: Enhanced Duplicate Address Detection
as a 6MAN WG document. Statements of support or opposition should be
sent to the mailing list. This last call
i scanned draft-hsingh-6man-enhanced-dad-04.txt and it certainly looks
like 6man fodder to me. i would have suggested v6ops until i got to
section 3, which proposes protocol change.
randy
IETF IPv6 working group mailing list
ipv
I support the adoption of draft-hsingh-6man-enhanced-dad as a 6MAN WG
document.
Thanks,
--eli
On 2/24/12 5:21 AM, Brian Haberman wrote:
All,
This is a consensus call on adopting:
Filename: draft-hsingh-6man-enhanced-dad
Revision: 04
Title: Enhanced Duplicate Address
All,
This is a consensus call on adopting:
Filename: draft-hsingh-6man-enhanced-dad
Revision: 04
Title:Enhanced Duplicate Address Detection
as a 6MAN WG document. Statements of support or opposition should be
sent to the mailing list. This last call will end on March
All,
I saw strong support for adopting the draft as a WG document. The
authors should post the next version of the document as 6man working
group document.
Regards,
Brian
On 2/8/12 2:51 PM, Brian Haberman wrote:
All,
This is a consensus call on adopting:
Title : Representing IPv6
On Wed, Feb 8, 2012 at 8:51 PM, Brian Haberman wrote:
> All,
> This is a consensus call on adopting:
>
> Title : Representing IPv6 Zone Identifiers in
> Uniform Resource Identifiers
> Author(s) : Brian Carpenter
> Robert M.
Adopt.
On 8 Feb 2012, at 20:07, Kerry Lynn wrote:
> Aye, -K-
>
> On Wed, Feb 8, 2012 at 2:51 PM, Brian Haberman
> wrote:
>> All,
>> This is a consensus call on adopting:
>>
>> Title : Representing IPv6 Zone Identifiers in
>>
Aye, -K-
On Wed, Feb 8, 2012 at 2:51 PM, Brian Haberman wrote:
> All,
> This is a consensus call on adopting:
>
> Title : Representing IPv6 Zone Identifiers in
> Uniform Resource Identifiers
> Author(s) : Brian Carpenter
>
All,
This is a consensus call on adopting:
Title : Representing IPv6 Zone Identifiers in
Uniform Resource Identifiers
Author(s) : Brian Carpenter
Robert M. Hinden
Filename : draft-carpenter-6man-uri-zoneid-01.txt
Pages : 6
All,
On 1/16/12 3:23 PM, Brian Haberman wrote:
> All,
> This is a consensus call on adopting:
>
> Title : Processing of IPv6 "atomic" fragments
> Author(s) : Fernando Gont
> Filename : draft-gont-6man-ipv6-atomic-fragments-00.txt
>
Brian,
I support this work.
Tim Hartrick
On Mon, Jan 16, 2012 at 12:23 PM, Brian Haberman
wrote:
> All,
> This is a consensus call on adopting:
>
> Title : Processing of IPv6 "atomic" fragments
> Author(s) : Fernando Gont
> Filename :
* Brian Haberman
> This is a consensus call on adopting:
>
> Title : Processing of IPv6 "atomic" fragments
> Author(s) : Fernando Gont
> Filename : draft-gont-6man-ipv6-atomic-fragments-00.txt
> Pages : 12
> Date : 20
Thanks. It is clear now.
.as
On 26 Jan 2012, at 12:00, Fernando Gont wrote:
> [Subject changed so that this doesn't "mix" with the poll]
>
> Hi, Arturo,
>
> On 01/26/2012 09:59 AM, Arturo Servin wrote:
>> When you say "Namely, they try to perform IPv6 reassembly with the
>> "atomic fr
[Subject changed so that this doesn't "mix" with the poll]
Hi, Arturo,
On 01/26/2012 09:59 AM, Arturo Servin wrote:
> When you say "Namely, they try to perform IPv6 reassembly with the
> "atomic fragment" and any other fragments already queued with the
> same set {IPv6 Source Address, IPv6 Destin
estination
(i.e., a packet that undergoes translation from IPv6 to IPv4) …" I wonder
if there is any negative implication for IPv4/IPv6 translators if atomic
fragments are forbidden as proposed.
Regards,
.as
On 16 Jan 2012, at 18:23, Brian Haberman wrote:
> All,
>
+1
Sent from my iPad
On Jan 25, 2012, at 6:14 AM, "RJ Atkinson" wrote:
>
> I support adopting this as a WG document.
>
> Ran
>
>
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.
I support adopting this as a WG document.
Ran
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
On 2012-01-16 15:23, Brian Haberman wrote:
This is a consensus call on adopting:
Title : Processing of IPv6 "atomic" fragments
Author(s) : Fernando Gont
Filename : draft-gont-6man-ipv6-atomic-fragments-00.txt
Pages : 12
Date : 2011-1
All,
This is a consensus call on adopting:
Title : Processing of IPv6 "atomic" fragments
Author(s) : Fernando Gont
Filename : draft-gont-6man-ipv6-atomic-fragments-00.txt
Pages : 12
Date : 2011-12-15
as a 6MAN working group document. Please
All,
Sorry for the delay... The consensus of the WG is to adopt this
draft. I will instruct the authors to publish the next version as a
6MAN WG draft.
Regards,
Brian
On 10/11/11 1:05 PM, Brian Haberman wrote:
> All,
> This is a consensus call on adopting:
>
>
All,
Any dissenting opinions on the adoption of this draft?
Regards,
Brian
On 10/11/11 1:05 PM, Brian Haberman wrote:
> All,
> This is a consensus call on adopting:
>
> Title : RFC3627 to Historic status
> Author(s) : Wesley George
> Filename :
I support adoption of this draft as a 6MAN WG document.
-K-
On Tue, Oct 11, 2011 at 1:05 PM, Brian Haberman wrote:
> All,
> This is a consensus call on adopting:
>
> Title : RFC3627 to Historic status
> Author(s) : Wesley George
> Filename : draft-george-
alf Of
> George, Wes
> Sent: mardi 11 octobre 2011 21:34
> To: Brian Haberman; IPv6 WG Mailing List
> Subject: RE: Consensus call on adopting: draft-lynn-6man-6lobac
>
> Support adoption
>
> Thanks,
>
> Wes
>
>
>> -Original Message-
>>
+1
Cheers,
Pascal
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
George, Wes
Sent: mardi 11 octobre 2011 21:34
To: Brian Haberman; IPv6 WG Mailing List
Subject: RE: Consensus call on adopting: draft-lynn-6man-6lobac
Support adoption
Thanks
Support adoption
Thanks,
Wes
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Brian Haberman
> Sent: Tuesday, October 11, 2011 1:06 PM
> To: IPv6 WG Mailing List
> Subject: Consensus call on adopting: draft-lynn-6
I support adopting this document.
Thanks,
Hemant
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Brian Haberman
Sent: Tuesday, October 11, 2011 1:06 PM
To: IPv6 WG Mailing List
Subject: Consensus call on adopting: draft-george-6man-3627
All,
This is a consensus call on adopting:
Title : Transmission of IPv6 over MS/TP Networks
Author(s) : Kerry Lynn
Jerry Martocci
Carl Neilson
Stuart Donaldson
Filename : draft-lynn-6man-6lobac-02.txt
Pages : 14
All,
This is a consensus call on adopting:
Title : RFC3627 to Historic status
Author(s) : Wesley George
Filename : draft-george-6man-3627-historic-01.txt
Pages : 4
Date : 2011-10-10
as a 6MAN working group document. Please state your opinion, positive
All,
Sorry for the delay in posting this, but there is no consensus to
adopt this draft as a 6MAN document.
Regards,
Brian
On 5/18/11 1:44 PM, Brian Haberman wrote:
> All,
> This starts a 2-week consensus call on adopting:
>
> Title : Naming IPv6 address parts
&g
I do not support this draft too.
--
From: "Christian Huitema"
Sent: Sunday, May 22, 2011 12:03 PM
To: "Brian Haberman" ; "IPv6 WG Mailing List"
Subject: RE: Consensus call on adopting: draft-hartmann-6man-addressn
> This starts a 2-week consensus call on adopting ...
> draft-hartmann-6man-addresspartnaming-01.txt
> as a 6MAN WG document. Please state your opinion (either for or
> against) on making this draft a WG draft either on the mailing list or to the
> chairs. This call will end
>> This starts a 2-week consensus call on adopting:
>> Title : Naming IPv6 address parts
>> Author(s) : L. Donnerhacke, et al.
>> Filename : draft-hartmann-6man-addresspartnaming-01.txt
to be my usual tactful self, i find this an embarrassment.
On Wed, May 18, 2011 at 01:44:34PM -0400, Brian Haberman wrote ipv6:
> All,
> This starts a 2-week consensus call on adopting:
>
> Title : Naming IPv6 address parts
> Author(s) : L. Donnerhacke, et al.
> Filename : draft-hartmann-6man-addresspartnaming-
Brian Carpenter
On 2011-05-19 05:44, Brian Haberman wrote:
> All,
> This starts a 2-week consensus call on adopting:
>
> Title : Naming IPv6 address parts
> Author(s) : L. Donnerhacke, et al.
> Filename : draft-hartmann-6man-addresspartnaming-01.txt
>
l Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian
Haberman
Sent: Wednesday, May 18, 2011 1:45 PM
To: IPv6 WG Mailing List
Subject: Consensus call on adopting: draft-hartmann-6man-addressnaming
All,
This starts a 2-week consensus call on adopting:
All,
This starts a 2-week consensus call on adopting:
Title : Naming IPv6 address parts
Author(s) : L. Donnerhacke, et al.
Filename : draft-hartmann-6man-addresspartnaming-01.txt
Pages : 8
Date : 2011-05-06
as a 6MAN WG document. Please state your
@ietf.org; Suresh Krishnan
Subject: Re: Consensus call on adopting
On 29 October 2010 14:09, Alan Kavanagh
mailto:alan.kavan...@ericsson.com>> wrote:
Yes I fully agree Olaf and as David has also noted these N:1 VLAN deployment
models exist in a lot of places and are not disappearing. It
o: otr...@employees.org; David Allan I
> Cc: ipv6@ietf.org; br...@innovationslab.net; bob.hin...@gmail.com; Suresh
> Krishnan
> Subject: AW: Consensus call on adopting
>
>
> I appreciate the decision of the WG chairs to accept the I-D as v6ops
> working item since it reflects
onslab.net; bob.hin...@gmail.com; Suresh
Krishnan
Subject: AW: Consensus call on adopting
I appreciate the decision of the WG chairs to accept the I-D as v6ops working
item since it reflects the majority of the raised opinions and acknowledges the
need for a solution to make IPv6 happen in a ve
> -Ursprüngliche Nachricht-
> Von: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] Im
> Auftrag von Ole Troan
> Gesendet: Freitag, 29. Oktober 2010 10:33
> An: David Allan I
> Cc: Bob Hinden; Brian Haberman; IPv6 WG Mailing List; Suresh Krishnan
> Betreff:
Hinden wrote:
>
> > Correction: The consensus call will end on October 28, 2010.
> >
> > Bob
> >
> >
> >
> > On Thu, Oct 21, 2010 at 11:46 AM, Bob Hinden
> wrote:
> >> 6MAN WG,
> >>
> >> This is a consensus call on a
David,
good point indeed.
perhaps it is time for the IETF to acknowledge the fact that these link types
are common and to take a more architectural and wide approach to solving and
adapting its protocols to this subnet model.
I'm concerned that we are standardising point solutions without unde
A quick comment on the soapbox statement...
: I'm biased against this subnet model (N:1)... recreating
PPP functionality over Ethernet, trying to create user isolation on a shared
IPv6 link, which after all IPv6 protocols are not designed for.
I appreciate the IETF has been kind of blind to thi
feedback on this work.
Regards,
Bob & Brian
On Oct 22, 2010, at 8:01 AM, Bob Hinden wrote:
> Correction: The consensus call will end on October 28, 2010.
>
> Bob
>
>
>
> On Thu, Oct 21, 2010 at 11:46 AM, Bob Hinden wrote:
>> 6MAN WG,
>>
>> This is a
Hi Ole,
Thanks for your comments.
On 10-10-28 05:45 AM, Ole Troan wrote:
Comments/Questions:
1) N:1 deployment model. reference 5517, 3069, 4562 perhaps
OK. Will do.
2) I don't think the deployment model, i.e where you are using a single link
that you are trying to create some level
o
Comments/Questions:
1) N:1 deployment model. reference 5517, 3069, 4562 perhaps
2) I don't think the deployment model, i.e where you are using a single link
that you are trying to create some level
of 'subscriber isolation on, and require "routing (e.g. on line-ids" in a
middlebox, is restric
Hi Suresh, All,
the initial requirements/constrains were not clear, and as they begun to
come to the surface after the solution was first proposed, the morphing of
the solution appears to have begun affecting some of the requirements to fit
the needs of the solution.
Technically, the mechanism de
ist; Brian Haberman; Bob Hinden
Subject: Re: Consensus call on adopting
Hi Woj,
On 10-10-26 10:27 AM, Wojciech Dec wrote:
> Hello,
>
> I would like to state that I am very much not in favour of the WG
> adopting this document, due to a number of reasons presented below.
>
Hi Woj,
On 10-10-26 10:27 AM, Wojciech Dec wrote:
Hello,
I would like to state that I am very much not in favour of the WG
adopting this document, due to a number of reasons presented below.
1. Requirements and architecture
These were never clear to start with, and the requirements/context
ived IPinIP tunneling solution
instead of just using what is already there. This point probably also comes
down to "requirements", and it would appear that the draft's driving, and
unstated requirement is a "MUST not use DHCPv6" without giving cause.
Thanks,
Wojtek.
On
In your letter dated Mon, 25 Oct 2010 08:30:37 -0700 you wrote:
>Philip Homburg wrote:
>> This implies that the end-device has to be able to match RS messages
>> using timestamp, i.e. its clock has to be sufficiantly accurate (to withi=
>n
>> 5 minutes, according to the SEND RFC) to do that or (in
Philip Homburg wrote:
>
> In your letter dated Fri, 22 Oct 2010 10:25:45 -0700 you wrote:
> >Philip Homburg wrote:
> >> In your letter dated Fri, 22 Oct 2010 11:05:42 -0400 you wrote:
> >> I wonder what to make of that. If the SEND protected RS messages can
> >> be replaced with AN-initiated (unpr
ist
> Cc: Brian Haberman; Bob Hinden
> Betreff: Re: Consensus call on adopting
>
>
> Correction: The consensus call will end on October 28, 2010.
>
> Bob
>
>
>
> On Thu, Oct 21, 2010 at 11:46 AM, Bob Hinden
> wrote:
> > 6MAN WG,
> >
> &
In your letter dated Fri, 22 Oct 2010 10:25:45 -0700 you wrote:
>Philip Homburg wrote:
>> In your letter dated Fri, 22 Oct 2010 11:05:42 -0400 you wrote:
>> I wonder what to make of that. If the SEND protected RS messages can be
>> replaced with AN-initiated (unprotected) RS messages, then what pur
Yes. There is certainly sufficient interest in the WG on this topic.
On 10/21/2010 2:46 PM, Bob Hinden wrote:
6MAN WG,
This is a consensus call on adopting:
Title : Line identification in IPv6 Router Solicitation
messages
Author(s) : S. Krishnan, et al
Philip Homburg wrote:
>
> In your letter dated Fri, 22 Oct 2010 11:05:42 -0400 you wrote:
> >On 10-10-22 11:01 AM, Philip Homburg wrote:
> >> Then I guess the obvious next question is how this interacts with
> >> SEND if the original 3 RS messages are lost.
> >
> >The AN-initiated RSs in this case
In your letter dated Fri, 22 Oct 2010 11:05:42 -0400 you wrote:
>On 10-10-22 11:01 AM, Philip Homburg wrote:
>> Then I guess the obvious next question is how this interacts with SEND if
>> the original 3 RS messages are lost.
>
>The AN-initiated RSs in this case will not be SEND protected RSs (sin
Hi Philip,
On 10-10-22 11:01 AM, Philip Homburg wrote:
In your letter dated Fri, 22 Oct 2010 10:45:57 -0400 you wrote:
But now I'm a bit confused. Given that the AN now has to ability to originat
e
RS messages, why is it forwarding the end-device' RS at all? Is that only to
support SEND?
Exac
Correction: The consensus call will end on October 28, 2010.
Bob
On Thu, Oct 21, 2010 at 11:46 AM, Bob Hinden wrote:
> 6MAN WG,
>
> This is a consensus call on adopting:
>
> Title : Line identification in IPv6 Router Solicitation
> messages
> Au
In your letter dated Fri, 22 Oct 2010 10:45:57 -0400 you wrote:
>> But now I'm a bit confused. Given that the AN now has to ability to originat
>e
>> RS messages, why is it forwarding the end-device' RS at all? Is that only to
>> support SEND?
>
>Exactly. The ability to send host-initiated RSs thro
Hi Philip,
On 10-10-22 10:25 AM, Philip Homburg wrote:
In your letter dated Fri, 22 Oct 2010 10:08:15 -0400 you wrote:
On 10-10-22 10:06 AM, Philip Homburg wrote:
Maybe this draft should say something about what happens if the 3 router
solicitations sent by the host are lost.
Certainly. We hav
In your letter dated Fri, 22 Oct 2010 10:08:15 -0400 you wrote:
>On 10-10-22 10:06 AM, Philip Homburg wrote:
>> Maybe this draft should say something about what happens if the 3 router
>> solicitations sent by the host are lost.
>
>Certainly. We have added Section 5.3 to version -08 of the draft t
Hi Philip,
On 10-10-22 10:06 AM, Philip Homburg wrote:
Maybe this draft should say something about what happens if the 3 router
solicitations sent by the host are lost.
Certainly. We have added Section 5.3 to version -08 of the draft to
account for the case where the host-initiated RSs are lo
Maybe this draft should say something about what happens if the 3 router
solicitations sent by the host are lost.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo
> I think the title should be changed to something like "Line
> Identification Destination Option" as it is proposing to create a new
> destination option and uses tunneling. In other words, it is no
> longer adding line identification to RS messages.
makes sense. but should not be a prereq for
- Original Message
> From: Bob Hinden
> To: IPv6 WG Mailing List
> Cc: Bob Hinden
> Sent: Thu, October 21, 2010 1:56:00 PM
> Subject: Re: Consensus call on adopting
>
> One personal comment,
>
> I think the title should be changed to something
1 - 100 of 169 matches
Mail list logo
