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

From: Zihao He <[email-masked]>
Date: Thu, 9 May 2019 14:41:14 +0800

Hi,

I highly support the adoption of this document, which introduces the multi-demand extension of DHCPv6. Specifically, it analyzes the current extended instance, defines the generic DHCP model, articulates what can be extended in DHCPv6 and provides an extension case. So I think it is rather worthwhile for the WG to adopt this document.

Best,

Zihao

发件人： Tomek Mrugalski <[email-masked]>
Date: 2019年4月19日周五 上午3:37
Subject: [dhcwg] Adoption call for draft-ren-dhc-problem-statement-of-mredhcpv6-01 - respond by May 9th
To: <[email-masked]>

Hi,

This message initiates a three weeks long DHC WG adoption call on:

Title: Problem Statement of Multi-requirement Extensions for DHCPv6

Pages: 11

Date: 2019-03-10

Document: draft-ren-dhc-problem-statement-of-mredhcpv6-01

Link:

https://tools.ietf.org/html/draft-ren-dhc-problem-statement-of-mredhcpv6-01

Please respond by May 9th.

This document has been presented several times in DHC. In Prague it was

presented again and there was a reasonable interest in the room.

If you support this document to be adopted, please say so. If you don't,

say so as well (and preferably explain your objections).

Note to people who voiced support for this work in Prague - it is

necessary to confirm your support on the mailing list.

Bernie & Tomek

_______________________________________________

dhcwg mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/dhcwg

--

Yours Sincerely,

Lin He

---

From: Tim Chown <[email-masked]>
Date: Fri, 10 May 2019 08:07:16 +0000

Hi,

I confirm my support in Prague for adopting this draft.

Tim

From: Tomek Mrugalski <[email-masked]<mailto:[email-masked]>>
Subject: [dhcwg] Adoption call for draft-ren-dhc-problem-statement-of-mredhcpv6-01 - respond by May 9th
To: <[email-masked]<mailto:[email-masked]>>

Hi,

Bernie & Tomek

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 15 May 2019 18:17:27 +0200

>> From: *Tomek Mrugalski* <[email-masked]>
>> Subject: [dhcwg] Adoption call for
>> draft-ren-dhc-problem-statement-of-mredhcpv6-01 - respond by May 9th
>> To: <[email-masked] <mailto:[email-masked]>>
>>
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

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 15 May 2019 21:19:10 +0200

Bernie and I discussed them matter and we determined the DHC WG is
interested in adopting this draft.

Authors, please upload it as

draft-ietf-dhc-mredhcpv6-problem-statement-00

Thanks,
Bernie & Tomek
DHC co-chairs