This makes me feel a lot better. Thanks. On Thu, Oct 9, 2014 at 11:50 PM, Pierre Pfister <pierre.pfis...@darou.fr> wrote:
> Hello Brian and James, > > Thanks for the heads up. CANs will be replaced in next version. > > So I’m clarifying the two first points in 4.3 > > o It can be delegated by a service provider (DHCPv6 PD, 6rd > [RFC5969], etc..). > > o It can be provisioned by an administrative authority (user > configuration, netconf [RFC6241], etc... ). > > And changing the last paragraph of the ULA generation section. > > Note as well that this section doesn't prevent multiple ULA prefixes > from existing simultaneously. ULA prefixes may be provided by > different means, as specified in Section 4.3. Delegated prefixes > that are delegated by a service provider or provisioned by an > authority differ from 'spontaneously' generated prefixes. They MUST > NOT be withdrawn if another ULA delegated prefix is observed. > > > Cheers, > > - Pierre > > > Le 9 oct. 2014 à 22:49, James Woodyatt <j...@nestlabs.com> a écrit : > > On Thu, Oct 9, 2014 at 12:26 PM, Pierre Pfister <pierre.pfis...@darou.fr> > wrote: > >> >> But I’m going to change it and making it more clear that authorities can >> provide their own prefixes. Even ULAs. >> > > Thanks! I'm very pleased to see this agreement. > > > -- > james woodyatt <j...@nestlabs.com> > Nest Labs, Communications Engineering > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > -- james woodyatt <j...@nestlabs.com> Nest Labs, Communications Engineering
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
