Subject: [Int-dir] Review of draft-ietf-roll-mpl-parameter-configuration

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 09 Jul 2015 13:27:57 +0200

Hi,

Brian asked me to review draft-ietf-roll-mpl-parameter-configuration-06.
I'm not sure if I was an officially designated reviewer or not, so
please treat my comments as regular IETF comments.

Disclaimer: I'm DHCP guy and don't have any experience with MPL.

Executive Summary: I do not feel the document is ready. It is of high
quality, but there are several DHCP issues that should be addressed.

I find this document well written, clear and easy to understand. There
are certain DHCP aspects that should be improved. I particularly dislike
the conditional formatting.

Section 1:
This document is intended to follow [RFC7227] the guideline. =>
This document is intended to follow the guideline of [RFC7227].

Section 2:
Parameters listed should be described or a reference to their
definition or description should be provided. As a DHCP implementor
and someone completely unfamiliar with MPL, I'd like to have
some basic description of those parameters. They don't need
to be very thorough, but if I code support for them, I need to
describe them somehow in the software documentation. Also, considering
the bounds mentioned in Section 4, it would be useful to have
recommended boundaries here.

Unnumbered figure in Section 2.1. It should be numbered for easier
reference.

For fields that spawn multiple lines, DHCP drafts typically omit
the inner lines. It's a bit difficult to see the boundaries of
MPL Domain Address field. See figure in section 7 of RFC3315 for
a nice example.

Section 2.1:
OPTION_MPL_PARAMETERS:  DHCPv6 option identifier (not yet assigned) =>
OPTION_MPL_PARAMETERS:  DHCPv6 option identifier (TBD).

IANA finds it very useful to have values yet to be assigned designated
as TBD. If there are more than one, please use TBD1, TBD2 etc.

Generic question:
I'm not familiar with the MPL protocol. Do you envision that there
will be additional extensions or refinements defined in the future?
Are those extensions likely to be configurable over DHCP? If that
is so, you may consider adding support for encapsulated options.
To do so, define extra field of unspecified length called
encapsulated-options and add a text that encapsulated options MAY
be included there. It's good to add a note that although currently
there are no such options defined yet, but they may be defined in the
future.

That's actually pretty important as you allow multiple MPL domains.
If you allowed only one, you could get away with simply defining new
top level options, but then it would be impossible to say to which
MPL domain they apply.

I would do it to make the option processing simpler. You have one
optional field: MPL Domain Address. Convert it to an encapsulated
option. The option, as it stands now, uses conditional formatting
(if len=32 parse domain address; else skip it). That's discouraged.
See section 6 of RFC7227.

As an implementor, I can tell you that adding new options, including
encapsulated options is easy. That's something you very often can
do with configuration file in existing implementations. That makes
your options easier to adopt. Now, if you stick to the conditional
formatting, you need dedicated code change. That's something frown
upon. And it slows down adoption.

Section 2.2
It was mentioned elsewhere, but it would be convenient to add text
similar to this: Client MUST be able to process more than one instance
in the server's responses.

There are multiple uses of SHALL. As a non-native speaker, I think
using MUST is easier to understand, especially be those less
fluent in English. But I don't insist on it, if you want to keep the
text as it is.

Section 2.3
  "MPL parameters may be updated occasionally.  With stateful DHCPv6,
   updates can be done when the renewal timer expires.  Information
   Refresh Time Option [RFC4242] shall be used to keep each forwarder
   updated."
Is MPL client expected to use stateful (addresses and/or prefixes),
stateless (just options) DHCP or both? Information Refresh Time Option
is typically used for stateless. If your client gets prefixes or
addresses, the renewal time is governed by T1 timer in respective
IA containers (IA_NA or IA_PD), so there's no need for Information
Refresh Time Option.

Section 2.6
  "A parameter set for an MPL domain SHOULD NOT be updated more often
   than twice of Information Refresh Time, even if the clients use
   longer Information Refresh Time to reduce DHCPv6 load on the
   network."
That's doesn't seem right. If you don't want the parameters to be
updated frequently, use lower T1 or Info Refrest Time values. May
existing DHCP clients are flexible and could handle processing new
options like this one without the source code being altered. They
typically have the option format defined in their configuration file and
call external script when the option is received. They can't do anything
like ignore every second reception of the option. It doesn't make sense
anyway.

Section 4, second paragraph
As a DHCP implementor, I don't understand what bounds I'm supposed to
implement for the parameters.

Section 4, third paragraph
  "The DHCP server or the network itself should be trusted by some means
   such as DHCPv6 authentications described in Section 21 of RFC3315
   [RFC3315]."
I'm not sure if you're aware of the RFC3315bis intiative (see
draft-ietf-dhc-rfc3315bis for details). Please note the absence of
delayed authentication protocol, that is in the process of being
deprecated. Currently there's work in progress to define strong
authentication in DHCPv6 in draft draft-ietf-dhc-sedhcpv6-08. It's with
IESG now and should hopefully be published soon. You may reference that
as well.

Hope that helps.

Tomek

---

From: Brian Haberman <[email-masked]>
Date: Thu, 9 Jul 2015 12:25:00 -0400

Thanks, Tomek!

Brian