be prepared to defend yourself in court(s) in any number of
 jurisdictions.  You should check w/ the RIRs on their role/position
 wrt legal precident on address/prefix ownership.  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 justifies the exposure, at least to me.

 If you do this, I will have to rethink my use of IPv6 as tainted
 goods.  The IETF should stick to -PROTOCOL- development, not create
 property rights to be fought over in courts.

YMMV

--bill
 


% Bill,
% 
% Whether or not this would be new and untrodden, I believe
% we need to step forward together into the unknown - under
% the confidence that careful monitoring and any necessary
% course-corrections will see us through the uncharted waters.
% 
% Regards,
% 
% Fred L. Templin
% [EMAIL PROTECTED]
% 
% Bill Manning wrote:
% 
% >% Alain,
% >% 
% >% The current document does not enforce a business model (earlier versions
% >% did), but does set technical constraints. Personally I don't think it is
% >% possible to 'Provide mechanisms that prevent hoarding', so the requirement
% >% 'without any procedure for de-allocation' creates a problem once hoarding
% >% has been detected. I do not object to the current document as this specific
% >% issue will be resolved by an update once the system is in operation and
% >% practical experience exposes that flaw. 
% >
% >     its not that the document "enforces" a business model,
% >     it that it creates "property rights" e.g. owned address
% >     space.  this is -NEW- and is an area untrodden by the 
% >     IESG/IAB.
% >
% >% mechanism which solves them if used as directed. As much as some people want
% >% to, it is not the IETF's job to legislate operational behavior. The language
% >% in this document is appropriate and it should be published.
% >
% >     Operational behaviour is one thing, creating legal assests
% >     is something else.  This is a -VERY- bad idea.
% >
% >--bill 
% >
% >
% >% Tony
% >% 
% >% > -----Original Message-----
% >% > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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"
% >% > 
% >% > 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, which is
% >% > very different from
% >% >    the notion of stewardship that are now in place for any IP address
% >% > allocation today.
% >% >    There are a number of legal questions not answered around this point.
% >% >    More, this is imposing a business model to the entity that will be in
% >% > charge of the allocations,
% >% >    and I believe that the IETF should refrain from imposing business
% >% > model.
% >% > 
% >% > - The document does not contain any wording recommending against the
% >% > 'all zero' self allocation.
% >% >    It merely say that:
% >% >    "Locally assigned global IDs MUST be generated with a pseudo-random
% >% >     algorithm consistent with [RANDOM].". However, it should be noted
% >% > that  [RANDOM]
% >% >     or RFC1750 does not contain any mandate, just provide ideas on how
% >% > to do things.
% >% >     An 'all zero' self allocation would create the prefix FD00::/48 and
% >% > will be very tempting
% >% >     to use by many.
% >% >    This working group just spend more than a year to deprecate the site
% >% > local
% >% >    fec0::/10 prefixes, just to reinvent it here.
% >% > 
% >% > As the request to advance this document came from the Ipv6 wg chairs,
% >% > representing the wg,
% >% > it is my opinion that the IPv6 Working Groug has made an incorrect
% >% > technical choice which
% >% > places the quality and/or integrity of the Working Group's product(s)
% >% > in significant
% >% > jeopardy.
% >% > 
% >% > As the request to advance this document has already been sent to you,
% >% > ADs,
% >% > this is my appeal to you to reject it and send it back to the working
% >% > group.
% >% > 
% >% >  - Alain.
% >% > 
% >% > 
% >% > 
% >% > 
% >% > 
% >% > On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote:
% >% > 
% >% > > Margaret & Thomas,
% >% > >      On behalf of the IPv6 working group, the chairs request the
% >% > > advancement of:
% >% > >
% >% > >        Title           : Unique Local IPv6 Unicast Addresses
% >% > >        Author(s)       : R. Hinden, B. Haberman
% >% > >        Filename        : draft-ietf-ipv6-unique-local-addr-03.txt
% >% > >        Pages           : 16
% >% > >        Date            : 2004-2-13
% >% > >
% >% > > as a Proposed Standard.  The -02 version completed working group last
% >% > > call on 02/02/2004.  This version addresses issues raised during the
% >% > > last call period.
% >% > >
% >% > > Regards,
% >% > > Brian & Bob
% >% > > IPv6 WG co-chairs
% >% > >
% >% > >
% >% > >
% >% > > --------------------------------------------------------------------
% >% > > IETF IPv6 working group mailing list
% >% > > [EMAIL PROTECTED]
% >% > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
% >% > > --------------------------------------------------------------------
% >% > 
% >% > 
% >% > --------------------------------------------------------------------
% >% > IETF IPv6 working group mailing list
% >% > [EMAIL PROTECTED]
% >% > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
% >% > --------------------------------------------------------------------
% >% 
% >% 
% >% --------------------------------------------------------------------
% >% IETF IPv6 working group mailing list
% >% [EMAIL PROTECTED]
% >% Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
% >% --------------------------------------------------------------------
% >% 
% >
% >
% >  
% >
% 
% 


-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to