Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?

[Brian E Carpenter <[e-mail]>]

On 16/12/2017 02:21, Ole Troan wrote:
>>> Please review and send any new comments to the list, and please confirm whether
>>> earlier comments have been addressed.
>>
>> It continue to describe the entity delegating the prefix as a "Delegating Router 'D'". The IPAM (IP address Management, and by extension IP Prefix Management) software can be implemented in a computer sold as a router, but there is no requirement that it be, and it usually is not. As a matter of fact, if a router is a system that forwards messages directed to addresses other than its own, in the context of an application such as a DHCPv6 address/prefix management process, it is acting as a host, not a router.
> 
> Prefix delegation, more so than address assignment is coupled with the routing system.
> Which is why RFC3633 only described a model where the delegating router and requesting router was directly connected.

They're coupled, but it isn't logically required that the entity that gives
prefix P to a device is also the upstream router that will include P in an
aggregate. I agree that's a natural implementation, but it isn't the only one.
IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-management,
are alternatives.

So I agree - it is a false assumption that the prefix delegator is
a router, and that the delegation mechanism is RFC3633.

As far as the draft goes, I'd like to see this qualified:

"An example IPv6 PD service is the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633].  An
alternative service based solely on IPv6 ND messaging has also
been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]."

Maybe by adding that other, non-router, mechanisms may exist,
such as proprietary IPAMs, draft-ietf-anima-prefix-management
and draft-sun-casm-address-pool-management-yang (expired).

   Brian