Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6
draft-ietf-roll-mpl-parameter-configuration-08

Write Up: draft-ietf-roll-mpl-parameter-configuration-04


Personnel
* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles

1. Summary

This draft defines a way to configure a parameter set of MPL (Multicast
Protocol for Low power  and Lossy Networks) via DHCPv6 option.  MPL has a
set of parameters to control its behavior, and the  parameter set is often
configured as a network-wide parameter because the parameter set should be
identical for each MPL forwarder in an MPL domain.  Using the MPL Parameter
Configuration Option defined in this document, a network can be configured
with a single set of MPL parameter easily.

The Intended RFC status is Proposed Standard, because this document
defines a way to distribute parameter sets for MPL forwarders as a DHCPv6 option.


2. Review and Consensus

Version 08 addresses the comments done in the IESG review.

Int-Dir review was done, ticket #171 created for this.
IESG comments and IANA should be addressed in version 06.
Gen ART, Secdir and AD comments were addressed in version 06. A reference to rfc6422 (suggested by AD) is not present in version 06

This document was reviewed in ROLL and DHC WGs, DHC Chair Bernie
Volz reviewed the document and was ok with the proposed option format.
During Last Call there were no comments gotten for this draft, but got
consensus in previous threads.


3. Intellectual Property

Yusuke Doi and Matthew Gilmore confirmed on 05-01-2014 for version
03, version 04 fixed some typos and add IANA information. 

4. Other Points

Note any downward references (see RFC 3967) and whether they appear in
the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry),
as these need to be announced during Last Call.

[I-D.ietf-roll-trickle-mcast] is as Normative Reference, which have
new issues that are being addressed by the authors.



Check the IANA Considerations for clarity and against the checklist below.
Note any registrations that require expert review, and say what's been done
to have them reviewed before last call.  Note any new registries that are created
by this document and briefly describe the working group's discussion that led
to the selection of the allocation procedures and policies (see RFC 5226) that
were selected for them. If any new registries require expert review for future allocations,
provide any public guidance that the IESG would find useful in selecting the designated
experts (private comments may be sent to the Area Director separately).

IANA Section references the specific registry and table

Explain anything else that the IESG might need to know when reviewing this document.
If there is significant discontent with the document or the process, which might result
in appeals to the IESG or especially bad feelings in the working group, explain this in
a separate email message to the responsible Area Director.

Not apply.

Idnits executed, no relevant comments.

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Have all references within this document been identified as either normative or informative, and
does the shepherd agree with how they have been classified?

Yes

Brian has agreed to upcoming changes (on e-mai), so a revised ID is needed to clear that DISCUSS.  The new text should also help clear up the DISCUSS with Barry.

[Ballot discuss]
Updated for -07...

1. Resolved

2. In section 2.3 (MPL Forwarder Behavior), there should be a brief discussion of the role of the MPL Domain Address and include a reference to [I-D.ietf-roll-trickle-mcast].

3. Resolved

Write Up: draft-ietf-roll-mpl-parameter-configuration-04


Personnel
* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles

1. Summary

This draft defines a way to configure a parameter set of MPL (Multicast
Protocol for Low power  and Lossy Networks) via DHCPv6 option.  MPL has a
set of parameters to control its behavior, and the  parameter set is often
configured as a network-wide parameter because the parameter set should be
identical for each MPL forwarder in an MPL domain.  Using the MPL Parameter
Configuration Option defined in this document, a network can be configured
with a single set of MPL parameter easily.

The Intended RFC status is Proposed Standard, because this document
defines a way to distribute parameter sets for MPL forwarders as a DHCPv6 option.


2. Review and Consensus

Int-Dir review was done, ticket #171 created for this.
IESG comments and IANA should be addressed in version 06.
Gen ART, Secdir and AD comments were addressed in version 06. A reference to rfc6422 (suggested by AD) is not present in version 06

This document was reviewed in ROLL and DHC WGs, DHC Chair Bernie
Volz reviewed the document and was ok with the proposed option format.
During Last Call there were no comments gotten for this draft, but got
consensus in previous threads.


3. Intellectual Property

Yusuke Doi and Matthew Gilmore confirmed on 05-01-2014 for version
03, version 04 fixed some typos and add IANA information. 

4. Other Points

Note any downward references (see RFC 3967) and whether they appear in
the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry),
as these need to be announced during Last Call.

[I-D.ietf-roll-trickle-mcast] is as Normative Reference, which have
new issues that are being addressed by the authors.



Check the IANA Considerations for clarity and against the checklist below.
Note any registrations that require expert review, and say what's been done
to have them reviewed before last call.  Note any new registries that are created
by this document and briefly describe the working group's discussion that led
to the selection of the allocation procedures and policies (see RFC 5226) that
were selected for them. If any new registries require expert review for future allocations,
provide any public guidance that the IESG would find useful in selecting the designated
experts (private comments may be sent to the Area Director separately).

IANA Section references the specific registry and table

Explain anything else that the IESG might need to know when reviewing this document.
If there is significant discontent with the document or the process, which might result
in appeals to the IESG or especially bad feelings in the working group, explain this in
a separate email message to the responsible Area Director.

Not apply.

Idnits executed, no relevant comments.

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Have all references within this document been identified as either normative or informative, and
does the shepherd agree with how they have been classified?

Yes

Write Up: draft-ietf-roll-mpl-parameter-configuration-04


Personnel
* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles

1. Summary

This draft defines a way to configure a parameter set of MPL (Multicast
Protocol for Low power  and Lossy Networks) via DHCPv6 option.  MPL has a
set of parameters to control its behavior, and the  parameter set is often
configured as a network-wide parameter because the parameter set should be
identical for each MPL forwarder in an MPL domain.  Using the MPL Parameter
Configuration Option defined in this document, a network can be configured
with a single set of MPL parameter easily.

The Intended RFC status is Proposed Standard, because this document
defines a way to distribute parameter sets for MPL forwarders as a DHCPv6 option.


2. Review and Consensus

Int-Dir review was done, ticket #171 created for this.
IESG comments should be addressed in version 06.
Gen ART, Secdir and AD comments were addressed in version 06. A reference to rfc6422 (suggested by AD) is not present in version 06

This document was reviewed in ROLL and DHC WGs, DHC Chair Bernie
Volz reviewed the document and was ok with the proposed option format.
During Last Call there were no comments gotten for this draft, but got
consensus in previous threads.


3. Intellectual Property

Yusuke Doi and Matthew Gilmore confirmed on 05-01-2014 for version
03, version 04 fixed some typos and add IANA information. 

4. Other Points

Note any downward references (see RFC 3967) and whether they appear in
the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry),
as these need to be announced during Last Call.

[I-D.ietf-roll-trickle-mcast] is as Normative Reference, which have
new issues that are being addressed by the authors.



Check the IANA Considerations for clarity and against the checklist below.
Note any registrations that require expert review, and say what's been done
to have them reviewed before last call.  Note any new registries that are created
by this document and briefly describe the working group's discussion that led
to the selection of the allocation procedures and policies (see RFC 5226) that
were selected for them. If any new registries require expert review for future allocations,
provide any public guidance that the IESG would find useful in selecting the designated
experts (private comments may be sent to the Area Director separately).

IANA Section references the specific registry and table

Explain anything else that the IESG might need to know when reviewing this document.
If there is significant discontent with the document or the process, which might result
in appeals to the IESG or especially bad feelings in the working group, explain this in
a separate email message to the responsible Area Director.

Not apply.

Idnits executed, no relevant comments.

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Have all references within this document been identified as either normative or informative, and
does the shepherd agree with how they have been classified?

Yes

[Ballot discuss]
In general, this draft is well-written and easy to understand.  I do have a few points of technical clarity that I think are important.

First, a minor point on the "Reserved" bits.  In Sec 2.1, it says "Z (7 bits):  Reserved.  Should be 0." and then in Sec 2.2:
"  Clients MUST discard the MPL Parameter Configuration Option if it is invalid (e.g., it sets reserved bits)."  Frequently,
Reserved bits are available for future enhancements - so setting to zero on write and ignoring the value on read is a useful
default.  If these bits are really always going to be zero and interpreted as an error, then could you rename them to MBZ (Must Be Zero) and indicate in the field definition that a value other than zero is an error.  Also, from what I read in the rest of the draft,
if an invalid option is received, that could cause the client to be removed from the MPL region.  Could you clarify in the document what the expected behavior is if an invalid option is discarded?  Is that like having no option?  Is that pretending that the client didn't get one and staying with the previous option?  It seems like it would be pretty easy to remove a client from the MPL region by flipping a bit.  I would also like to see better clarification of how an option is considered invalid; while it may seem obvious, it's these details that impact interoperability.  In the write-up, I don't see any indications that there have been interoperable implementations yet?

Second, given that the meaning of the *_IMAX values is based on RFC6206 (as indicated in the update history) and that the *_IMAX and *_IMIN are confusing values, PLEASE have a reference to RFC6206.  To continue, it seems that DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX have different units - as is explained in RFC6206 where *_IMAX is the number of doublings and *_IMIN is the value in milliseconds.  However, in draft-ietf-roll-trickle-mcast-12, Section 5.4, the definition of DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX and C_IMIN and C_IMAX are given as:

"  DATA_MESSAGE_IMIN  The minimum Trickle timer interval, as defined in
      [RFC6206], for MPL Data Message transmissions.  DATA_MESSAGE_IMIN
      has a default value of 10 times the expected link-layer latency.

  DATA MESSAGE_IMAX  The maximum Trickle timer interval, as defined in
      [RFC6206], for MPL Data Message transmissions.  DATA_MESSAGE_IMAX
      has a default value equal to DATA_MESSAGE_IMIN.

  CONTROL_MESSAGE_IMIN  The minimum Trickle timer interval, as defined
      in [RFC6206], for MPL Control Message transmissions.
      CONTROL_MESSAGE_IMIN has a default value of 10 times the worst-
      case link-layer latency.

  CONTROL_MESSAGE_IMAX  The maximum Trickle timer interval, as defined
      in [RFC6206], for MPL Control Message transmissions.
      CONTROL_MESSAGE_IMAX has a default value of 5 minutes.
"

Clearly, if DATA_MESSAGE_IMIN is a 16 bit value and DATA_MESSAGE_IMAX is only an 8-bit value, they are expected to have different ranges.  Additionally, it's quite unclear which actually needs to be divided by TUNIT.  The draft describes this as happening for DM_IMIN and C_IMIN, but then goes on to say
  " Note that all time values (Trickle timers and expiration periods) are
  in TUNIT milliseconds precision.  For example, if TUNIT is 20 and the
  data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then
  DM_IMIN shall be set to 50."

Unfortunately, the draft doesn't describe which parameters are time values and apparently draft-ietf-roll-trickle-mcast-12
has some confusion as well.  For instance, CONTROL_MESSAGE_IMAX is defined as a time value (5 minutes).

I suspect that the solution here is to clarify/fix draft-ietf-roll-trickle-mcast-12, add references in Sec 2 to where the parameters
are defined, indicate which are considered "time values", and clean up the language in Sec 2.1.

Thanks!  It looks like a useful document to address an operational problem once these clarity issues are addressed.

[Ballot comment]
In Sec 2.1, it says: "OPTION_MPL_PARAMETERS:  DHCPv6 option identifier (not yet assigned)"
Instead of "not yet assigned", it would be better to use TBD1 and then reference TBD1 in the IANA section.
That makes it easy and clear how to update the draft as it is prepared to be an RFC.

[Ballot comment]
Thank you for addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05835.html

I'll follow along with the discussion from Stephen and Barry's comments, but don't have any additional to add.

[Ballot discuss]
Some of these points come from Bernie Volz's INT-Dir review...

1. This is one of the few options that is not a singleton, as defined in section 16 of RFC 7227. While the use of multiple options seems appropriate here, it would be best to clarify that clients (section 2.2) and servers (section 2.4) must be able to support multiple instances of this option. Given the discussion around supporting multiple MPL domains in draft-ietf-roll-trickle-mcast, I would expect there to be situations where the option appears multiple times.

2. In section 2.3 (MPL Forwarder Behavior), there should be a brief discussion of the role of the MPL Domain Address and include a reference to [I-D.ietf-roll-trickle-mcast].

3. In section 2.6 (Operational Considerations), the text is a bit odd. Why should a parameter set not be updated more often than twice the Information Refresh Time? How does the failure to refresh the option play with text in section 2.3 that indicates a missing option means the node should leave the MPL domain? Perhaps defining what "failure to refresh" means (i.e., I think it refers to lack of a DHCPv6 server response to a Renew or Information Request). Note also that Information Refresh Time is only applicable to Information-Request messages (see RFC 4242) so work may be needed as to how this this sections relate to Renew/Rebind operations? I am also not sure why 2.6 is a standalone section when it appears to be only applicable to clients and should be in either section 2.2 or 2.3.

[Ballot comment]
1. I support Barry's DISCUSS on the lack of an option potentially forcing a node to leave an MPL domain.

2. Why is the text in Appendix B not in the Operational Considerations section?

3. Please be consistent with the use of MUSTs and SHALLs.  Pick one.

4. In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph - why would a client discard the option if the reserved bits are set? I would think you'd want to use a new option if you're changing things drastically? But it certainly is your choice as to whether you want to do that. Perhaps a better reason is if one of the not-permitted values is used (such as 0 and 'all-bits-set') where are clearly reserved? 0 in many of these case could be bad since that would yield 0 time values? This really is up to you, but do think about what you might want to do any maintain backwards compatibility. Adding a new flag bit to the reserved field is probably not going to break things if existing implementations ignore the bit(s).

[Ballot comment]
From the OPS-DIR review done by Menachem:

The document is quite readable.

Section 2.1 could be improved if for each parameter defined a reference would be given to indicate where the parameter is defined. I found most of them in: draft-ietf-roll-trickle-mcast-12 but for example, I'm not sure what the Proactive_Forwarding flag is used for.

Section 4 discusses Security Considerations but I think that some phrases in the paragraph are too general.
Example:  "other methods for security should be applied" does not indicate what these methods are or where to look for them.
Another Example: "To protect attacks from outside of
the network, unneccessary DHCPv6 packets should be filtered on the
border router between the ROLL network and the Internet"  - what is meant by "unnecessary DHCPv6 packets"?


NITS
====

Section 2.3 First Paragraph Second Sentence - Remove 'is'

OLD          ==> Note that there may be cases in which a node may fail is to join a domain
SUGGEST ==> Note that there may be cases in which a node may fail to join a domain

Section 2.3 Last Paragraph is not clear.

Perhaps the last sentence should read "In this case" (instead of "In the case").


Section 2.6 - First Sentence - Not Clear

Is the update rate not to be more than twice the Information Refresh Time? Not clear to me how many updates are allowed in an Information Refresh Time.

Should the word 'of' be replaced by 'the'.

"more often than twice the Information Refresh Time".

Suggest rephrasing this paragraph.

[Ballot comment]

- I don't get the update model - if all MPL forwarders have
to use the same parameters but they don't all do DHCPv6 at
the same time, then won't new parameter settings take a
while to propagate to most of the network? And won't that
cause a problem? Don't you need a "start using this set of
parameters in N seconds" field in the dhcp option to handle
that? This is not a DISCUSS as I think it relats to Barry's
so please try address this when addressing that.

- please do not pretend rfc 3315 is a solution for anything
unless you mean it and I don't think you do. 3315 is I think
the canonical example for mythical security:-(

[Ballot comment]
-- section 2.6, 1st sentence :" A parameter set for an MPL domain SHOULD NOT be updated more often
  than twice of Information Refresh Time"

The preposition "of" is incorrect. Normally I would say leave that for the RFC editor, but it's not clear to me if this means "twice the information refresh time" or "twice during an information refresh time (interval)". (I assume the former, but it could be more clear.)

[Ballot discuss]
This should be a very easy discussion to resolve:

-- Section 2.3 --

  A node SHOULD leave an MPL domain if it receives an updated MPL
  Parameter Configuration Option without a configuration for the MPL
  domain, unless it has overriding manual configuration on the MPL
  domain.  In other words, if a node is configured to work as a MPL
  Forwarder for a MPL domain regardless of DHCPv6 Options, the node MAY
  stay on the MPL domain even if it receives an MPL Parameter
  Configuration Option without configuration for the MPL domain.

I'm confused by this, because it appears to contradict itself.

Some questions might help he understand:

If I receive an updated MPL PCO that lacks a config for the MPL domain, then there are two possible situations:

Case 1: I do *not* have an overriding manual config for the domain.  In this case, the text says that I SHOULD leave the domain.  Is that correct?  Is it OK in this case for me to decide to stay on the domain anyway, even if I have no manual configuration for it?

Case 2: I *do* have an overriding manual config for the domain.  In this case, the text seems to say that it's entirely my choice ("MAY") whether or not I stay on the domain or leave it.  Is that correct?

Please discuss this with me, so I can suggest how to make the text clearer, depending upon the answers to those questions.

[Ballot comment]
-- Section 2.1 --

  option_len:  Length of the option.  It SHOULD be 16 (without MPL
      domain address) or 32 (with MPL domain address).

"SHOULD", really?  What else *can* it be, and still be valid?  Is there any legitimate reason I might make it something else?  Or should this just say this?:

NEW?
  option_len:  Length of the option, which is 16 if no MPL domain
      address is present, or 32 if there is an MPL domain address.
END

Write Up: draft-ietf-roll-mpl-parameter-configuration-04


Personnel
* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles

1. Summary

This draft defines a way to configure a parameter set of MPL (Multicast
Protocol for Low power  and Lossy Networks) via DHCPv6 option.  MPL has a
set of parameters to control its behavior, and the  parameter set is often
configured as a network-wide parameter because the parameter set should be
identical for each MPL forwarder in an MPL domain.  Using the MPL Parameter
Configuration Option defined in this document, a network can be configured
with a single set of MPL parameter easily.

The Intended RFC status is Proposed Standard, because this document
defines a way to distribute parameter sets for MPL forwarders as a DHCPv6 option.


2. Review and Consensus

Gen ART, Secdir and AD comments were addressed in version 06. A reference to rfc6422 (suggested by AD) is not present in version 06

This document was reviewed in ROLL and DHC WGs, DHC Chair Bernie
Volz reviewed the document and was ok with the proposed option format.
During Last Call there were no comments gotten for this draft, but got
consensus in previous threads.


3. Intellectual Property

Yusuke Doi and Matthew Gilmore confirmed on 05-01-2014 for version
03, version 04 fixed some typos and add IANA information. 

4. Other Points

Note any downward references (see RFC 3967) and whether they appear in
the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry),
as these need to be announced during Last Call.

[I-D.ietf-roll-trickle-mcast] is as Normative Reference, which have
new issues that are being addressed by the authors.



Check the IANA Considerations for clarity and against the checklist below.
Note any registrations that require expert review, and say what's been done
to have them reviewed before last call.  Note any new registries that are created
by this document and briefly describe the working group's discussion that led
to the selection of the allocation procedures and policies (see RFC 5226) that
were selected for them. If any new registries require expert review for future allocations,
provide any public guidance that the IESG would find useful in selecting the designated
experts (private comments may be sent to the Area Director separately).

IANA Section references the specific registry and table

Explain anything else that the IESG might need to know when reviewing this document.
If there is significant discontent with the document or the process, which might result
in appeals to the IESG or especially bad feelings in the working group, explain this in
a separate email message to the responsible Area Director.

Not apply.

Idnits executed, no relevant comments.

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Have all references within this document been identified as either normative or informative, and
does the shepherd agree with how they have been classified?

Yes

Write Up: draft-ietf-roll-mpl-parameter-configuration-04


Personnel
* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles

1. Summary

This draft defines a way to configure a parameter set of MPL (Multicast
Protocol for Low power  and Lossy Networks) via DHCPv6 option.  MPL has a
set of parameters to control its behavior, and the  parameter set is often
configured as a network-wide parameter because the parameter set should be
identical for each MPL forwarder in an MPL domain.  Using the MPL Parameter
Configuration Option defined in this document, a network can be configured
with a single set of MPL parameter easily.

The Intended RFC status is Proposed Standard, because this document
defines a way to distribute parameter sets for MPL forwarders as a DHCPv6 option.


2. Review and Consensus

Currently there are some comments that should be addressed by the author.

This document was reviewed in ROLL and DHC WGs, DHC Chair Bernie
Volz reviewed the document and was ok with the proposed option format.
During Last Call there were no comments gotten for this draft, but got
consensus in previous threads.


3. Intellectual Property

Yusuke Doi and Matthew Gilmore confirmed on 05-01-2014 for version
03, version 04 fixed some typos and add IANA information. 

4. Other Points

Note any downward references (see RFC 3967) and whether they appear in
the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry),
as these need to be announced during Last Call.

[I-D.ietf-roll-trickle-mcast] is as Normative Reference, which have
new issues that are being addressed by the authors.



Check the IANA Considerations for clarity and against the checklist below.
Note any registrations that require expert review, and say what's been done
to have them reviewed before last call.  Note any new registries that are created
by this document and briefly describe the working group's discussion that led
to the selection of the allocation procedures and policies (see RFC 5226) that
were selected for them. If any new registries require expert review for future allocations,
provide any public guidance that the IESG would find useful in selecting the designated
experts (private comments may be sent to the Area Director separately).

IANA Section references the specific registry and table

Explain anything else that the IESG might need to know when reviewing this document.
If there is significant discontent with the document or the process, which might result
in appeals to the IESG or especially bad feelings in the working group, explain this in
a separate email message to the responsible Area Director.

Not apply.

Idnits executed, no relevant comments.

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Have all references within this document been identified as either normative or informative, and
does the shepherd agree with how they have been classified?

Yes

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-roll-mpl-parameter-configuration-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which must be completed.

In the DHCPv6 Option Codes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) located at:

http://www.iana.org/assignments/dhcpv6-parameters

a single new option code will be registered as follows:

Value: [ TBD-at-Registration ]
Description: OPTION_MPL_PARAMETERS
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (MPL Parameter Configuration Option for DHCPv6) to Proposed Standard


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'MPL Parameter Configuration Option for DHCPv6'
  as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This draft defines a way to configure a parameter set of MPL
  (Multicast Protocol for Low power and Lossy Networks) via DHCPv6
  option.  MPL has a set of parameters to control its behavior, and the
  parameter set is often configured as a network-wide parameter because
  the parameter set should be identical for each MPL forwarder in an
  MPL domain.  Using the MPL Parameter Configuration Option defined in
  this document, a network can be configured with a single set of MPL
  parameter easily.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-roll-mpl-parameter-configuration/ballot/


No IPR declarations have been submitted directly on this I-D.

Write Up: draft-ietf-roll-mpl-parameter-configuration-04


Personnel
* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles

1. Summary

This draft defines a way to configure a parameter set of MPL (Multicast
Protocol for Low power  and Lossy Networks) via DHCPv6 option.  MPL has a
set of parameters to control its behavior, and the  parameter set is often
configured as a network-wide parameter because the parameter set should be
identical for each MPL forwarder in an MPL domain.  Using the MPL Parameter
Configuration Option defined in this document, a network can be configured
with a single set of MPL parameter easily.

The Intended RFC status is Proposed Standard, because this document
defines a way to distribute parameter sets for MPL forwarders as a DHCPv6 option.


2. Review and Consensus


This document was reviewed in ROLL and DHC WGs, DHC Chair Bernie
Volz reviewed the document and was ok with the proposed option format.
During Last Call there were no comments gotten for this draft, but got
consensus in previous threads.


3. Intellectual Property

Yusuke Doi and Matthew Gilmore confirmed on 05-01-2014 for version
03, version 04 fixed some typos and add IANA information. 

4. Other Points

Note any downward references (see RFC 3967) and whether they appear in
the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry),
as these need to be announced during Last Call.

[I-D.ietf-roll-trickle-mcast] is as Normative Reference, which have
new issues that are being addressed by the authors.



Check the IANA Considerations for clarity and against the checklist below.
Note any registrations that require expert review, and say what's been done
to have them reviewed before last call.  Note any new registries that are created
by this document and briefly describe the working group's discussion that led
to the selection of the allocation procedures and policies (see RFC 5226) that
were selected for them. If any new registries require expert review for future allocations,
provide any public guidance that the IESG would find useful in selecting the designated
experts (private comments may be sent to the Area Director separately).

IANA Section references the specific registry and table

Explain anything else that the IESG might need to know when reviewing this document.
If there is significant discontent with the document or the process, which might result
in appeals to the IESG or especially bad feelings in the working group, explain this in
a separate email message to the responsible Area Director.

Not apply.

Idnits executed, no relevant comments.

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Have all references within this document been identified as either normative or informative, and
does the shepherd agree with how they have been classified?

Yes

Write Up: draft-ietf-roll-mpl-parameter-configuration-04


Personnel
* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles

1. Summary

This draft defines a way to configure a parameter set of MPL (Multicast
Protocol for Low power  and Lossy Networks) via DHCPv6 option.  MPL has a
set of parameters to control its behavior, and the  parameter set is often
configured as a network-wide parameter because the parameter set should be
identical for each MPL forwarder in an MPL domain.  Using the MPL Parameter
Configuration Option defined in this document, a network can be configured
with a single set of MPL parameter easily.

The Intended RFC status is Proposed Standard, because this document
defines a way to distribute parameter sets for MPL forwarders as a DHCPv6 option.


2. Review and Consensus


This document was reviewed in ROLL and DHC WGs, DHC Chair Bernie
Volz reviewed the document and was ok with the proposed option format.
During Last Call there were no comments gotten for this draft, but got
consensus in previous threads.


3. Intellectual Property

Yusuke Doi and Matthew Gilmore confirmed on 05-01-2014 for version
03, version 04 fixed some typos and add IANA information. 

4. Other Points

Note any downward references (see RFC 3967) and whether they appear in
the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry),
as these need to be announced during Last Call.

[I-D.ietf-roll-trickle-mcast] is as Normative Reference, which have
new issues that are being addressed by the authors.



Check the IANA Considerations for clarity and against the checklist below.
Note any registrations that require expert review, and say what's been done
to have them reviewed before last call.  Note any new registries that are created
by this document and briefly describe the working group's discussion that led
to the selection of the allocation procedures and policies (see RFC 5226) that
were selected for them. If any new registries require expert review for future allocations,
provide any public guidance that the IESG would find useful in selecting the designated
experts (private comments may be sent to the Area Director separately).

IANA Section references the specific registry and table

Explain anything else that the IESG might need to know when reviewing this document. If there
is significant discontent with the document or the process, which might result in appeals to the
IESG or especially bad feelings in the working group, explain this in a separate email message to
the responsible Area Director.

Not apply.

Idnits executed, no relevant comments.

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Have all references within this document been identified as either normative or informative, and
does the shepherd agree with how they have been classified?

Yes

Write Up: draft-ietf-roll-mpl-parameter-configuration-04


Personnel
* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles

1. Summary

This draft defines a way to configure a parameter set of MPL (Multicast Protocol for Low power
and Lossy Networks) via DHCPv6 option.  MPL has a set of parameters to control its behavior, and the
parameter set is often configured as a network-wide parameter because the parameter set should be
identical for each MPL forwarder in an MPL domain.  Using the MPL Parameter Configuration Option
defined in this document, a network can be configured with a single set of MPL parameter easily.

The Intended RFC status is Proposed Standard, because this document defines a way to distribute
parameter sets for MPL forwarders as a DHCPv6 option.


2. Review and Consensus


This document was reviewed in ROLL and DHC WGs, DHC Chair Bernie Volz reviewed the
document and was ok with the proposed option format. During Last Call there were no comments
gotten for this draft, but got consensus in previous threads.


3. Intellectual Property

Yusuke Doi and Matthew Gilmore confirmed on 05-01-2014 for version 03, version 04 fixed
some typos and add IANA information. 

4. Other Points

Note any downward references (see RFC 3967) and whether they appear in the DOWNREF Registry
(http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as these need to be announced during Last Call.

[I-D.ietf-roll-trickle-mcast] is as Normative Reference, which have new issues that are being
addressed by the authors.



Check the IANA Considerations for clarity and against the checklist below. Note any registrations
that require expert review, and say what's been done to have them reviewed before last call.
Note any new registries that are created by this document and briefly describe the working
group's discussion that led to the selection of the allocation procedures and policies (see RFC 5226)
that were selected for them. If any new registries require expert review for future allocations,
provide any public guidance that the IESG would find useful in selecting the designated experts
(private comments may be sent to the Area Director separately).

IANA Section references the specific registry and table

Explain anything else that the IESG might need to know when reviewing this document. If there
is significant discontent with the document or the process, which might result in appeals to the
IESG or especially bad feelings in the working group, explain this in a separate email message to
the responsible Area Director.

Not apply.

Idnits executed, no relevant comments.

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Have all references within this document been identified as either normative or informative, and
does the shepherd agree with how they have been classified?

Yes

Write Up: draft-ietf-roll-mpl-parameter-configuration-04


Personnel
* Responsible Area Director: Alvaro Retana
* Document Shepherd: Ines Robles

1. Summary

This draft defines a way to configure a parameter set of MPL (Multicast Protocol for Low power and Lossy Networks) via DHCPv6 option.  MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain.  Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameter easily.

The Intended RFC status is Proposed Standard, because this document defines a way to distribute parameter sets for MPL forwarders as a DHCPv6 option.


2. Review and Consensus


This document was reviewed in ROLL and DHC WGs, DHC Chair Bernie Volz reviewed the document and was ok with the proposed option format. During Last Call there were no comments gotten for this draft, but got consensus in previous threads.


3. Intellectual Property

Yusuke Doi and Matthew Gilmore confirmed on 05-01-2014 for version 03, version 04 fixed some typos and add IANA information. 

4. Other Points

Note any downward references (see RFC 3967) and whether they appear in the DOWNREF Registry (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as these need to be announced during Last Call.

[I-D.ietf-roll-trickle-mcast] is as Normative Reference, which have new issues that are being addressed by the authors.



Check the IANA Considerations for clarity and against the checklist below. Note any registrations that require expert review, and say what's been done to have them reviewed before last call. Note any new registries that are created by this document and briefly describe the working group's discussion that led to the selection of the allocation procedures and policies (see RFC 5226) that were selected for them. If any new registries require expert review for future allocations, provide any public guidance that the IESG would find useful in selecting the designated experts (private comments may be sent to the Area Director separately).

IANA Section references the specific registry and table

Explain anything else that the IESG might need to know when reviewing this document. If there is significant discontent with the document or the process, which might result in appeals to the IESG or especially bad feelings in the working group, explain this in a separate email message to the responsible Area Director.

Not apply.

Idnits executed, no relevant comments.

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

Yes