Re: RFC 5006 status

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

On Fri, 19 Mar 2010 15:07:49 +0100
Rémi Després <remi.despres@free.fr> wrote:

> 
> Le 19 mars 2010 à 14:20, Mark Smith a écrit :
> 
> > The existing mechanisms work, both in theory, and in practice. I think
> > that means that the onus is on the RA for everything proponents to
> > *prove* where it doesn't work...
> 
> There is clearly no proof that it doesn't work, but there is a proof that efficiency can be improved by a very small complement.
> 

So it would seem to don't place any value on deployment costs,
troubleshooting costs, developer time spent on duplication of
functionality that could be spent on new and different functionality
or bug fixing existing functionality, functionality interaction and
duplicate information arbitration should it not match. They're the
biggest costs of new features. Comparatively, the cost of standardising
things in the IETF is minuscule.


> > ... before anybody should spend valuable time
> > redesigning the existing mechanisms.
> 
> There is no "redesign", just an optional complement for which, contributors who wish to implement it, need an approved common format.
> Those that don't want to support it are free not to: things will continue to work for them as before, just less efficiently than for those who have the complement. 
> 
> > There are better IPv6 things to
> > spend time on that are far more important to *get* working, rather than
> > spending time on changing the way existing things work.
> 
> Then, please let others doing it (it won't hurt you in any way), and the discussion will terminate.
> 

Yes it will. I'm an operator. See all those costs I mentioned before?
I, and the organisation and network end-users I work for, will be forced
to wear them either directly day to day, or embedded in the costs of
products purchased. The IETF and vendors "force" certain costs upon
people like me and my customers/end-users. I'm willing to wear them and
defend them to my end-users if I see more value in the benefit than the
cost. Partially duplicating DHCPv6 functionality in RAs doesn't
satisfy that criteria, and I'd much rather try prevent that unnecessary
cost now than have to wear it for a very long period later (either
until I die or retire from networking).

> RD
> 
> 
> >> On Fri, Mar 19, 2010 at 3:29 PM, Rémi Després <remi.despres@free.fr> wrote:
> >>> 
> >>> Le 17 mars 2010 à 16:18, Fred Baker a écrit :
> >>> 
> >>>> http://www.ietf.org/rfc/rfc5006.txt
> >>>> 
> >>>> (1) Please take a look at the document in the next few days; if you have comments on it (eg, you think it should be changed in some way), please comment to v6ops.
> >>> 
> >>> While supporting in general the idea, there is one improvement I suggest to make:
> >>> Rather than a specific RA option for Recursive DNS Servers, standardize the generic RA option to embed some stateless DHCP options, as proposed in draft-krishnan-intarea-ra-dhcp-00.
> >>> 
> >>> This is in my understanding more powerful without being more complex.
> >>> By giving to routers a general possibility to broadcast stateless DHCP parameters (in addition to their still being obtainable in DHCPv6), not only the purpose of RFC50026 is achieved but, in one shot, the same progress is made for all common parameters that may concern all or most hosts.
> >>> 
> >>> Hosts that support the RA DHCP option only have to: (1) process embedded DHCP options that they understand; (2) skip others; (3) request in DHCPv6 only options that aren't already received in RAs, if any.
> >>> 
> >>> Note that Suresh Krishnan has 15min slot scheduled at the 6man meeting of Wednesday for:
> >>> "Stateless DHCPv6 and Router Advertisements for propagating configuration information".
> >>> 
> >>> I add Suresh to the list, and Dan Wing who is known to support this approach.
> >>> 
> >>> RD
> >>> 
> >>> 
> >> 
> > 
> 
>