Brian & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : Duplicate Address Detection Proxy
Author(s) : Fabio Costa
Xavier Pougnard
Hongyu Li
Filename: draft-ietf-6man
Brian & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : Default Address Selection for Internet Protocol
version 6 (IPv6)
Author(s) : Dave Thaler
Richard Draves
Arifumi Matsumoto
Brian & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : The Line Identification Destination Option
Author(s) : Suresh Krishnan
Alan Kavanagh
Balazs Varga
S
Jari & Ralph,
On behalf of the 6MAN Working Group, the chairs request the
advancement of:
Title : RFC3627 to Historic status
Author(s) : Wesley George
Filename : draft-ietf-6man-3627-historic-01.txt
Pages : 4
Date : 2011-12-19
as an Informational docume
Jari & Ralph,
On behalf of the 6MAN Working Group, the chairs request the
advancement of:
Title : An uniform format for IPv6 extension headers
Author(s) : Suresh Krishnan
James Woodyatt
Erik Kline
James Hoagland
For the AD's information - the suggested hash algorithm in
Appendix A definitely needs to be revised. It isn't normative
so it can be taken care of a little later, along with any AD comments.
Regards
Brian Carpenter
On 2011-06-07 02:37, Brian Haberman wrote:
> Jari & Ralph,
> On behalf of
Jari & Ralph,
On behalf of the 6MAN Working Group, the chairs request the
advancement of:
Title : IPv6 Flow Label Specification
Author(s) : Shane Amante
Brian Carpenter
Sheng Jiang
Jarno Rajahalme
Filename : draft-ietf-6ma
Jari & Ralph,
On behalf of the 6MAN Working Group, the chairs request the
advancement of:
Title : Rationale for update to the IPv6 flow label
specification
Author(s) : Shane Amante
Brian Carpenter
Sheng Jiang
Filename : dr
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : IPv6 Node Requirements
Author(s) : Ed Jankiewicz, John Loughney, Thomas Narten
Filename: draft-ietf-6man-node-req-bis-10.txt
Pages : 31
Got it. Thanks.
jari
Brian Haberman kirjoitti:
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : RPL Option for Carrying RPL Information in
Data-Plane Datagrams
Author(s) : J. Hui, J. Vasseur
Filename : draft-ietf-6
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : An IPv6 Routing Header for Source Routes with RPL
Author(s) : J. Hui, et al.
Filename : draft-ietf-6man-rpl-routing-header-03.txt
Pages : 19
Date : 2011-03-29
as a Pr
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : RPL Option for Carrying RPL Information in
Data-Plane Datagrams
Author(s) : J. Hui, J. Vasseur
Filename : draft-ietf-6man-rpl-option-03.txt
Pages : 14
Date
Thanks. I will review it and move along.
Jari
Bob Hinden kirjoitti:
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : Using 127-bit IPv6 Prefixes on Inter-Router Links
Author(s) : M. Kohno, et al.
Filename: d
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : Using 127-bit IPv6 Prefixes on Inter-Router Links
Author(s) : M. Kohno, et al.
Filename: draft-ietf-6man-prefixlen-p2p-01.txt
Pages : 9
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : IPv6 Router Advertisement Options for DNS
Configuration RFC 5006-bis
Author(s) : S. Park, et al.
Filename: draft-ietf-6man-dns-options-bis-02.txt
Pages
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : IPv6 Subnet Model: the Relationship between Links
and Subnet Prefixes
Author(s) : H. Singh, et al.
Filename : draft-ietf-6man-ipv6-subnet-model-07.txt
Pages : 13
Date
Got it. Thanks.
Jari
Bob Hinden kirjoitti:
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : A Recommendation for IPv6 Address Text Representation
Author(s) : S. Kawamura, M. Kawashima
Filename: draft-ietf-6
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : A Recommendation for IPv6 Address Text Representation
Author(s) : S. Kawamura, M. Kawashima
Filename: draft-ietf-6man-text-addr-representation-03.txt
Page
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : IANA Allocation Guidelines for the IPv6 Routing Header
Author(s) : J. Arkko, S. Bradner
Filename: draft-ietf-6man-iana-routing-header-00.txt
Pages
Jari & Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : Handling of overlapping IPv6 fragments
Author(s) : S. Krishnan
Filename : draft-ietf-6man-overlap-fragment-03.txt
Pages : 7
Date : 2009-07-03
as a Proposed Standard. A 6MAN W
Jari & Mark,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : Reserved IPv6 Interface Identifiers
Author(s) : S. Krishnan
Filename : draft-ietf-6man-reserved-iids-01.txt
Pages : 11
Date : 2008-07-14
as a proposed standard. A 6M
All,
I erroneously left the mailing list off this request.
Regards,
Brian
Original Message
Subject: Request To Advance:
Date: Tue, 22 Jan 2008 12:42:38 -0500
From: Brian Haberman <[EMAIL PROTECTED]>
To: Jari Arkko <[EMAIL PROTECTED]>, Mark Townsley
<[
On 2007-08-30 04:40, Iljitsch van Beijnum wrote:
On 27-aug-2007, at 23:21, ext ext Bob Hinden wrote:
On behalf of the IPv6 WG, the chairs request the advancement of
That was fast.
Iljitsch, I think it's a fair judgement of the rough consensus
(which is obviously going to stay rough, however
On 27-aug-2007, at 23:21, ext ext Bob Hinden wrote:
On behalf of the IPv6 WG, the chairs request the advancement of
That was fast.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf
Jari & Mark,
On behalf of the IPv6 WG, the chairs request the advancement of
Title : Deprecation of Type 0 Routing Headers in IPv6
Author(s) : J. Abley, et al.
Filename: draft-ietf-ipv6-deprecate-rh0-01.txt
Pages : 9
Date
Is the a document shepherd writeup?
See:
http://www.ietf.org/IESG/content/Doc-Writeup.html
Jari
ext Bob Hinden kirjoitti:
> Jari & Mark,
>
> On behalf of the IPv6 WG, the chairs request the advancement of
>
> Title : IPv6 Router Advertisement Flags Option
> Author(s) : B. Haberman, R. Hinden
Jari & Mark,
On behalf of the IPv6 WG, the chairs request the advancement of
Title : IPv6 Router Advertisement Flags Option
Author(s) : B. Haberman, R. Hinden
Filename : draft-ietf-ipv6-ra-flags-option-01.txt
Pages : 8
Date : 2007-6-22
as an Proposed Standard. This document reflects
Margaret & Mark,
On behalf of the IPv6 WG, the chairs request the advancement of
Title : IPv6 Node Information Queries
Author(s) : M. Crawford, B. Haberman
Filename: draft-ietf-ipngwg-icmp-name-lookups-15.txt
Pages : 15
Da
> > => Not in the main text, which is why I suggested above
> that we can add it
> > to section 7.2.
>
> I see. As I said in the previous message (see also below), we should
> first make a consensus about whether this is to be added. Then, if
> the result is positive, we should explici
> On Tue, 3 Jan 2006 14:25:52 -0500,
> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
> Sorry for the late response I was out of the office.
>> > => This can be added to the text at the beginning of 7.2.,
>> which discusses this issues.
>>
>> Hmm, so the behavior corresponding to the foll
Sorry for the late response I was out of the office.
> > => This can be added to the text at the beginning of 7.2.,
> which discusses this issues.
>
> Hmm, so the behavior corresponding to the following entry
> (shown again
> just to be accurate) is not currently described in the draft:
> On Wed, 7 Dec 2005 13:18:28 -0500,
> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
>> > => Good points. I agree with that. So to keep it
>> consistent, I'll remove this distinction
>> > between host and router.
>>
>> Okay, but please clarify my first question, too:
>>
>> >> First of a
> the change to APPENDIX C should cover the case of
> an unsolicited ND message does not contain source/target LLAO,
> AND the receiving node does not have a neighbor cache entry for
> the source/target
> (there are two conditions for a single 'case')
>
> Is this now clear
> On Fri, 2 Dec 2005 10:42:02 -0500,
> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
> => Agreed. In addition to Appendix C, we also agreed on the list to add a
> paragraph to
> section 7.2 (text from Greg Daley) to clarify the general
> handling. This was also added.
OK so far.
>So,
>
> (Sorry for the delayed response...I hope you still remember the
> context)
=> No probs, I remember it clearly.
> >> I've compared the difference of the state machine in Appendix C
> >> between the 03 and 05 versions (attached below). At
> least it doesn't
> >> seem to cover the cas
(Sorry for the delayed response...I hope you still remember the
context)
> On Thu, 17 Nov 2005 13:06:20 -0500,
> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
> Sending in hibernate mode.
>> I'm not sure if this one is correctly addressed:
>> http://www1.ietf.org/mail-archive/web/ipv6/curr
The draft editor posted a pointer to the document on the pppext
mailing list in March of 2004. The archives indicate no feedback
whatsoever.
Brian
On Nov 18, 2005, at 11:54, Mark Townsley wrote:
Sorry, answered too soon... I see the proto questionairre now. It
doesn't indicate a pppext revi
Sorry, answered too soon... I see the proto questionairre now. It
doesn't indicate a pppext review, I think it would be a good idea to
have one.
Thanks,
- Mark
Brian Haberman wrote:
Margaret & Mark,
On behalf of the IPv6 WG, the chairs request the advancement of:
Title:
May we have a proto questionairre?
Did you LC this or get a review from in pppext as well?
Thanks,
- Mark
Brian Haberman wrote:
Margaret & Mark,
On behalf of the IPv6 WG, the chairs request the advancement of:
Title: IP Version 6 over PPP
Author(s): S. Varada, et a
Margaret & Mark,
On behalf of the IPv6 WG, the chairs request the advancement of:
Title : IP Version 6 over PPP
Author(s) : S. Varada, et al.
Filename: draft-ietf-ipv6-over-ppp-v2-02.txt
Pages : 15
Date: 2005-6-15
Sending in hibernate mode.
> I'm not sure if this one is correctly addressed:
> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05107.html
> (BTW: msg05107 is a comment on version 03, and I could not get a 04
> version. Has that version been issued, or is the version number
> bumpe
Excuse me for not doing this earlier, but I finally check the 05
version to see my previous comments were addressed, and found some
points I'm not sure about.
> On Tue, 1 Nov 2005 13:04:37 -0500,
> Brian Haberman <[EMAIL PROTECTED]> said:
>> Margaret & Mark,
>> On behalf of the IPv6 WG,
Begin forwarded message:
From: Brian Haberman <[EMAIL PROTECTED]>
Date: November 1, 2005 13:04:17 EST
To: The IESG <[EMAIL PROTECTED]>, Margaret Wasserman
<[EMAIL PROTECTED]>
Cc: Mark Townsley <[EMAIL PROTECTED]>, Bob Hinden
<[EMAIL PROTECTED]>
Subject:
Margaret & Mark,
On behalf of the IPv6 WG, the chairs request the advancement of:
Title : Neighbor Discovery Proxies (ND Proxy)
Author(s) : D. Thaler, et al.
Filename: draft-ietf-ipv6-ndproxy-03.txt
Pages : 20
Date
Margaret & Mark,
On behalf of the IPv6 WG, the chairs request the advancement of
Title : Privacy Extensions for Stateless Address
Autoconfiguration in IPv6
Author(s) : T. Narten, et al.
Filename : draft-ietf-ipv6-
Christian Huitema wrote:
Don't get me wrong, I like SEND. My point was just that if we allow
"transparent" bridges at all, then we essentially allow the same
man-in-the-middle attacks that are also possible with ND proxy.
But doesn't the layering inherent in the SeND vs. IEEE make this rather
diff
> ... I spoke to the NOC about it, and found out that they had only
> allocated enough address space for 256 hosts, and there were well over
300
> people in the room, many of whom were knowledgable networking
researchers.
> Somebody was ARP spoofing, stealing addresses because not enough had
been
>
James,
In 2002, I was sitting in the conference room at Mobicom browsing one of the
papers when my 802.11/IPv4 network connection started to act up. It would go
away, then come back, then hang for a long period of time. When I looked
into the matter more deeply, I discovered that the DHCP lease on
>SEND secures the mapping between an IPv6 address and a MAC address, but
>it does nothing to guarantee that the L2 topology actually delivers the
>packets to the intended destination. When we expand all that energy
>signing neighbor discovery packets, have we really improved security?
Here's a con
Christian Huitema wrote:
The general case of proxy ND, which this specification uses, can not
provide any security against MiTM because by definition the proxy is a
MiTM. Thus it is completely unreasonably to assume that SeND will
solve this.
What do you mean, unreasonable? It is certainly possible
Christian Huitema wrote:
SEND secures the mapping between an IPv6 address and a MAC address, but
it does nothing to guarantee that the L2 topology actually delivers the
packets to the intended destination. When we expand all that energy
signing neighbor discovery packets, have we really improved se
So, thinking some more about it, I have this nasty feeling about the
usefulness of SEND. Compare the two topologies:
Host-A <---> learning bridge <---> Host-B
Host-A <---> ND-Proxy<---> Host-B
SEND will work just fine with the learning bridge topology, but will not
work wi
> The general case of proxy ND, which this specification uses, can not
> provide any security against MiTM because by definition the proxy is a
> MiTM. Thus it is completely unreasonably to assume that SeND will
solve
> this.
What do you mean, unreasonable? It is certainly possible to write and
si
Dave Thaler wrote:
The fact that SEND doesn't yet support proxy ND is not specific to
this specification, it's something for SEND to solve.
The general case of proxy ND, which this specification uses, can not
provide any security against MiTM because by definition the proxy is a
MiTM. Thus it is
Cc: Thomas Narten; Margaret Wasserman; Brian Haberman; IPv6
> Subject: Re: Request to Advance:
[RESEND]
>
> Brian E Carpenter wrote:
> > > First, lets keep in mind that this is an Informational document.
> >
> > I wonder whether Experimental wouldn't send a
Some comments on draft-ietf-ipv6-ndproxy-00.txt...
Substantive comments:
I think this document would be more appropriately published as an
Experimental RFC rather than Informational. The inconsistencies
between the requirements for securing IPv6 neighbor discovery and
allowing dynamic addition/rem
Soliman, Hesham wrote:
FWIW I don't have a problem with ndproxy being published while incompatible
with SeND. There are other examples of completely insecure experimental
RFCs, e.g. Fast handoffs. It's essential to make the document consistent though.
what is being discussed is incompatibility betw
I know NDproxy is a WG item, but I think this problem space deserves a
discussion on its own. Although it has implications on IPv6 ND, I think
stretching subnets beyond links mean further than that. And there is
already another proposal contending for a similar problem space,
Rbridging. Before we
> Alain Durand wrote:
> ...
> > The argument that NDproxy will only be used in a certain
> environments
> > where SEND is not needed is clearly bogus, The IETF is not about
> > defining standards for special cases but for the whole Internet.
>
> I disagree as a matter of principle. It i
On Jan 27, 2005, at 6:02 AM, Brian E Carpenter wrote:
Alain Durand wrote:
...
The argument that NDproxy will only be used in a certain environments
where SEND is not needed is clearly bogus, The IETF is not about
defining standards for special cases but for the whole Internet.
I disagree as a matte
Alain Durand wrote:
...
The argument that NDproxy will only be used in a certain environments
where SEND is not needed is clearly bogus, The IETF is not about
defining standards for special cases but for the whole Internet.
I disagree as a matter of principle. It is perfectly OK to have
specs that
On Jan 24, 2005, at 3:14 PM, Jari Arkko wrote:
Erik Nordmark wrote:
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
That would be better than informational.
I agree. But I also think that if the document has
inconsistencies
D]>; "Thomas Narten" <[EMAIL PROTECTED]>; "Margaret
Wasserman" <[EMAIL PROTECTED]>; "IPv6"
Sent: Tuesday, January 25, 2005 8:51 PM
Subject: Re: Request to Advance: [RESEND]
> James,
>
> >specifically, speakeasy has a program listed on thei
On Tue, 2005-01-25 at 23:51, Bob Hinden wrote:
> >specifically, speakeasy has a program listed on their web site where you get
> >credits for routing your neighbor's traffic through your .11 ap. perhaps
> >other isps too?
>
> Thanks. Could supply a link to additional information on this?
http:/
James,
specifically, speakeasy has a program listed on their web site where you get
credits for routing your neighbor's traffic through your .11 ap. perhaps
other isps too?
Thanks. Could supply a link to additional information on this?
Bob
--
James Kempf wrote:
specifically, speakeasy has a program listed on their web site where you get
credits for routing your neighbor's traffic through your .11 ap. perhaps
other isps too?
sonic.net is another case.
Erik
IETF IPv6 w
I apologize if I've missed this particular point earlier in the discussion -
Experimental seems appropriate to me unless there is widespread deployment
of some version of the protocol that this document is specifying. And I
agree about correcting any inconsistencies prior to publication...
- Ralph
Erik Nordmark wrote:
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
That would be better than informational.
I agree. But I also think that if the document has
inconsistencies those should be corrected even before
publishin
> >> The counterexample is that there are ISPs that have their home users
> >> with 802.11 run public hotspots and get some compensation from the
> >> ISP. In this case, since it is a public access 802.11, SeND would be a
> >> good thing to use. And 802.11 is also a key scenario for proxynd.
> >
>
On Jan 24, 2005, at 6:03, [EMAIL PROTECTED] wrote:
Brian H,
First, lets keep in mind that this is an Informational document.
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
I can see how this could be very useful in certain
Brian Haberman wrote:
I take it from your detailed responses below that you see it in IETF's
best interest to publish this document and protocol without any quality
improvements to neither the document nor the protocol. Did I understand
that correctly?
I never said that. I was commenting on the v
Brian E Carpenter wrote:
> First, lets keep in mind that this is an Informational document.
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
That would be better than informational.
But I still think the document should say
Brian H,
> > First, lets keep in mind that this is an Informational document.
>
> I wonder whether Experimental wouldn't send a clearer signal
> that there is some doubt about the viability of the solution.
>
> I can see how this could be very useful in certain types of
> network environment, a
> First, lets keep in mind that this is an Informational document.
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
I can see how this could be very useful in certain types of
network environment, and publishing as Experiment
Erik,
On Jan 21, 2005, at 0:34, Erik Nordmark wrote:
Hello Brian,
For the most part, there has been less than optimal public
discussion. The minutes from Seoul indicate that Thomas was less than
happy with the level of comments. However, the people who did speak
up were in favor of it.
Hmm - I'm s
Hello Brian,
For the most part, there has been less than optimal public
discussion. The minutes from Seoul indicate that Thomas was less than
happy with the level of comments. However, the people who did speak
up were in favor of it.
Hmm - I'm spoken up in more than one IPv6 WG meeting pointing ou
Hi Erik,
On Jan 18, 2005, at 14:14, Erik Nordmark wrote:
I for one missed the last call, because I was on vacation during much
of those two weeks. Given that there isn't likely to be an IETF-wide
last call, I'd wish the WG and/or ADs take these comments into
account.
I think there are several s
Bob Hinden wrote:
[Corrected error in subject line]
Margaret & Thomas,
On behalf of the IPv6 WG, the chairs request the advancement of:
Title: Bridge-like Neighbor Discovery Proxies (ND Proxy)
Author(s): D. Thaler, et al.
Filename: draft-ietf-ipv6-ndproxy-00.txt
Page
[Corrected error in subject line]
Margaret & Thomas,
On behalf of the IPv6 WG, the chairs request the advancement of:
Title : Bridge-like Neighbor Discovery Proxies (ND Proxy)
Author(s) : D. Thaler, et al.
Filename: draft-ietf-ipv6-ndproxy-00.txt
IPv6 WG,
Please note the advancement of the above draft to the IESG.
Anyone having comments can refer them to the mboned mailing list
or comment during the IETF Last Call.
Regards,
Brian & Bob
IPv6 WG co-chairs
David Meyer wrote:
David and Bert,
On behalf of the MBONED WG, I wo
Margaret, Thomas,
The chairs of the IPv6 working group, on behalf of the working group,
request that the following document be published as a Proposed Standard:
Title : IPv6 Scoped Address Architecture
Author(s) : S. Deering, B. Haberman, T. Jinmei, E. Nordmark,
Margaret, Thomas,
The chairs of the IPv6 working group, on behalf of the working group,
request that the following document be published as a Proposed Standard:
Title : IPv6 Scoped Address Architecture
Author(s) : S. Deering, B. Haberman, T. Jinmei, E. Nordmark,
Bill Manning <[EMAIL PROTECTED]> wrote:
|% Bill Manning <[EMAIL PROTECTED]> wrote:
|%
|% | be prepared to defend yourself in court(s) in any number of
|% | jurisdictions.
|%
|% Against whom exactly would he be defending? Presumably the litigation would
|% be initiated by someone who had a finan
% Bill Manning <[EMAIL PROTECTED]> wrote:
%
% | be prepared to defend yourself in court(s) in any number of
% | jurisdictions.
%
% Against whom exactly would he be defending? Presumably the litigation would
% be initiated by someone who had a financial stake in the matter. Are you
% acknowledgi
-BEGIN PGP SIGNED MESSAGE-
Dan Lanciani wrote:
> "Jeroen Massar" <[EMAIL PROTECTED]> wrote:
>
> |Dan Lanciani wrote:
> |
> |> "Jeroen Massar" <[EMAIL PROTECTED]> wrote:
> |>
> |> |I have only one note on the "unique local ipv6 address" subject:
> |> |
> |> |Organisations wanting "unconn
Thus spake "Bill Manning" <[EMAIL PROTECTED]>
> be prepared to defend yourself in court(s) in any number of jurisdictions.
> ... You should have the ISOC/IETF legal team review the creation of
> property rights by the WG chairs and the IESG. Its not going to be easy
> and its not clear the effort
"Jeroen Massar" <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|
|> "Jeroen Massar" <[EMAIL PROTECTED]> wrote:
|>
|> |I have only one note on the "unique local ipv6 address" subject:
|> |
|> |Organisations wanting "unconnected addressspace" should go to
|> |an existing organisation that they thi
-BEGIN PGP SIGNED MESSAGE-
Dan Lanciani wrote:
> "Jeroen Massar" <[EMAIL PROTECTED]> wrote:
>
> |I have only one note on the "unique local ipv6 address" subject:
> |
> |Organisations wanting "unconnected addressspace" should go to
> |an existing organisation that they think will outlast
"Jeroen Massar" <[EMAIL PROTECTED]> wrote:
|I have only one note on the "unique local ipv6 address" subject:
|
|Organisations wanting "unconnected addressspace" should go to
|an existing organisation that they think will outlast them in age
|and that already has a LIR allocation allocated. Give th
Bill Manning <[EMAIL PROTECTED]> wrote:
| be prepared to defend yourself in court(s) in any number of
| jurisdictions.
Against whom exactly would he be defending? Presumably the litigation would
be initiated by someone who had a financial stake in the matter. Are you
acknowledging that the curr
-BEGIN PGP SIGNED MESSAGE-
> Alain Durand <[EMAIL PROTECTED]> wrote:
>
> |- Permanent allocation is equivalent of selling address space,
I have only one note on the "unique local ipv6 address" subject:
Organisations wanting "unconnected addressspace" should go to
an existing organisati
Alain Durand <[EMAIL PROTECTED]> wrote:
|- Permanent allocation is equivalent of selling address space,
No, it is not. Address space could be given away at no cost just as it was
in the beginning. A fee may be a useful tool to discourage hoarding, but there
may be other equally effective (or ev
AM
% >% > To: Brian Haberman; Bob Hinden
% >% > Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas
% >% > Narten
% >% > Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses"
% >% >
% >% > Dears ADs,
% >%
On Feb 20, 2004, at 12:17 PM, Tony Hain wrote:
Alain,
The current document does not enforce a business model (earlier
versions
did), but does set technical constraints.
I disagree. There are no technical constraints that mandates that the
allocations
have to be permanent. As such, I believe it
On Feb 24, 2004, at 10:09 AM, Fred Templin wrote:
Alain,
Speaking only as an individual wg participant, I appreciate the
concerns
you are raising but am hoping that you are not contemplating a divisive
and time-consuming appeals process such as the one we have just come
through for site local de
Alain,
At 01:22 AM 2/20/2004, Alain Durand wrote:
Dears ADs,
Since the appeal process starts with the working group chairs, we
are responding as such.
I found it very unfortunate that the chair decided to request to advance
this document
without answering two major issues I raised during the
ROTECTED] On Behalf Of Alain
% > Durand
% > Sent: Friday, February 20, 2004 1:22 AM
% > To: Brian Haberman; Bob Hinden
% > Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas
% > Narten
% > Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses&q
.)
Regards,
Fred L. Templin
[EMAIL PROTECTED]
Alain Durand wrote:
Dears ADs,
I found it very unfortunate that the chair decided to request to
advance this document
without answering two major issues I raised during the last call:
- Permanent allocation is equivalent of selling address space
To: Brian Haberman; Bob Hinden
Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas
Narten
Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses"
Dears ADs,
I found it very unfortunate that the chair decided to request to
advance this document
withou
On Fri, Feb 20, 2004 at 12:17:51PM -0800, Tony Hain wrote:
> Alain,
>
> Recommending against all-zero's is not only a waste of time, it specifically
> directs people to the thing you are trying to avoid. There is nothing that a
> document can do to prevent a consultant from configuring all of his
1 - 100 of 107 matches
Mail list logo
