Re: [dhcwg] Adoption call for draft-ren-dhc-problem-statement-of-mredhcpv6-01 - respond by May 9th

[Tomek Mrugalski <[e-mail]>]

>> From: *Tomek Mrugalski* <[e-mail]>
>> Subject: [dhcwg] Adoption call for
>> draft-ren-dhc-problem-statement-of-mredhcpv6-01 - respond by May 9th
>> To: <[e-mail] <mailto:[e-mail]>>
>>
>> This message initiates a three weeks long DHC WG adoption call on:
>>
>> Title: Problem Statement of Multi-requirement Extensions for DHCPv6
>> https://tools.ietf.org/html/draft-ren-dhc-problem-statement-of-mredhcpv6-01
>>
>> Please respond by May 9th.
With my co-chair hat off, I support adoption of this document.

Here's a couple comments.

1. Section 1: update references to from 3315bis to RFC8415.

2. Section 1: IPv6 hosts => IPv6 nodes. DHCPv6 often provisions PD to
routers.

3. Fig.1 says a relay does message processing functions. Yes, it does
encapsulation and forwards the packets further (sometimes adding extra
options to the encapsulation layer), but it doesn't process the packet.
I would rephase this as "message relaying functions".

4. Section 4.2.4: "DHCPv6 servers try to generate random addresses".
That's not true. Each implementation uses its own allocation strategy.
It may be something simple or very complex and almost always it's
influenced with various policies configured by the sysadmin. It would be
better to say "Currently, the DHCPv6 servers assign addresses, prefixes
and other configuration options according to their configured policies."

5. Section 5 The motivation talking about countries wanting to control
resources outside of its domain is a bit risky and may raise some
eyebrows if this I-D goes to IESG. I would recommend using more generic
language here that would talk about enforcing local policies. As an
example you may give allowing access for students of the university and
preventing access for guests unless they sign up for some guest
registration system.

Besides the extensions mentioned in the text, there are many other
administrative mechanisms available in most DHCP implementations. One
popular feature is a host reservation, where you can reserve certain
parameters (IP addresses, prefixes, options) to specific devices. Some
deployments choose to not serve any addresses unless your device is on
their customer/student/employer list. Another  popular and powerful
feature is client classification. Many servers, including Kea, allow
defining classes, associating certain parameters or grant addresses from
restricted pools and then assigning incoming packets to those classes.
Host reservations and classes are often used together.

For example, you can define 3 pools: guests, students and professors.
And there would be a list of known devices with each assigned to certain
class. Once a device does DHCP, it is being looked up in host
reservations database and then assigned to specific class (with students
getting access to lab and e-learning platform, and professors getting
extra access to additional faculty services). All of those can be done
without writing any line of API extensions or hooks. It's just a
configuration of existing policy mechanisms.

Anyway, the I-D looks good. I look forward for the WG to expand and
improve this document in the future.

Tomek