Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery
draft-ietf-mipshop-mos-dhcp-options-14

[Ballot discuss]
RFC Editor note address my concern which was...

I think the allocations for the registry for the Sub-Option fields in the MoS DHCPv4 Address and FQDN options called the "IEEE 802.21 Service Type" are wrong.
You have
  The values '0', and '4' to '255' are reserved. New Values can be
  allocated via Standards Action as defined in [RFC5226].
I think you mean that 0 and 4-255 are unallocated, not reserved.

Similarly for 0 and 4-65535 in the registry for the sub-option field in the MoS DHCPv6 Address and FQDN options called the "IEEE 802.21 Service Type" (Section 4 and 5).

(This issue can also be seen in the text in sections 2 through 5.)

By the way: it would be really nice if the registries had different names. But: is the intention that the same values are used in both registries, or is this just the way things have worked out?

[Ballot discuss]
I think the allocations for the registry for the Sub-Option fields in the MoS DHCPv4 Address and FQDN options called the "IEEE 802.21 Service Type" are wrong.
You have
  The values '0', and '4' to '255' are reserved. New Values can be
  allocated via Standards Action as defined in [RFC5226].
I think you mean that 0 and 4-255 are unallocated, not reserved.

Similarly for 0 and 4-65535 in the registry for the sub-option field in the MoS DHCPv6 Address and FQDN options called the "IEEE 802.21 Service Type" (Section 4 and 5).

(This issue can also be seen in the text in sections 2 through 5.)

By the way: it would be really nice if the registries had different names. But: is the intention that the same values are used in both registries, or is this just the way things have worked out?

[Ballot comment]
Notwithstanding the text at the top of section 6.1 etc., and although one might assume "normal DHCP processing" it would be nice if the error case behavior was described. For example in section 2:
  In case there is no
  MIH server available, the length is set to 0, otherwise it is a
  multiple of 4.
What if it is received as not a multiple of 4?

It would also be good to briefly describe backward compatibility even though this is also "normal DHCP processing". What does a legacy node do with an option or sub-option it does not recognise? The issue for sub-options might be particularly sensitive as you are leaving space for new sub-options to be defined within your new options.

I would like to see acronyms expanded on first use. E.g. FQDN.

[Ballot discuss]
I think the allocations for the registry for the Sub-Option fields in the MoS DHCPv4 Address and FQDN options called the "IEEE 802.21 Service Type" are wrong.
You have
  The values '0', and '4' to '255' are reserved. New Values can be
  allocated via Standards Action as defined in [RFC5226].
I think you mean that 0 and 4-255 are unallocated, not reserved.

Similarly for 0 and 4-65535 in the registry for the sub-option field in the MoS DHCPv6 Address and FQDN options called the "IEEE 802.21 Service Type" (Section 4 and 5).

(This issue can also be seen in the text in sections 2 through 5.)

By the way: it would be really nice if the registries had different names. But: is the intention that the same values are used in both registries, or is this just the way things have worked out?

[Ballot comment]
Notwithstanding the text at the top of section 6.1 etc., and
although one might assume "normal DHCP processing" it would be
nice if the error case behavior was described. For example in
section 2:
  In case there is no
  MIH server available, the length is set to 0, otherwise it is a
  multiple of 4.
What if it is received as not a multiple of 4?

It would also be good to briefly describe backward compatibility
even though this is also "normal DHCP processing". What does a
legacy node do with an option or sub-option it does not recognise?
The issue for sub-options might be particularly sensitive as you
are leaving space for new sub-options to be defined within your
new options.

I would like to see acronyms expanded on first use. E.g. FQDN.

[Ballot comment]
2. MoS IPv4 Address Option for DHCPv4
   
  If the length is followed by a list of IPv4 addresses indicating
  appropriate MIH servers available to the MN, servers MUST be listed in
  order of preference. Its minimum length is 4, and the length MUST be a
  multiple of 4.

Pedantic nit: the minimum length is 0 as per the following sentence:

  In case there is no MIH server available, the length
  is set to 0.

Is it Ok for the server to omit the suboption instead of returning it with length = 0?

[...]

  The sub-option has the following format:
 
          Code Len  IPv4 Address 1    IPv4 Address 2
        +-----+---+---+----+----+----+----+----+---
        |1..3 | n |a1 | a2 |a3  | a4 | a1 |  ...
        +-----+---+---+----+----+----+-----+----+--

The last line of the table needs deleting of 1 "-".

IANA questions/comments:

- In Action 1, what values do you need for the Data Length and Meaning
entries in the registry?

- In Actions 2 and 4, you say that values 0 and 4-255 (or 4-65535)
are reserved, but then you also specify that new values can be
allocated. Are these values reserved or available for registration?

Action 1:

Upon approval of this document, IANA will make the following
assignments in the "BOOTP Vendor Extensions and DHCP Options"
registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Tag Name Data Length Meaning Reference
--- ---- ----------- ------- ---------
[tbd] IPv4_Address-MoS ?? ??
[RFC-mipshop-mos-dhcp-options-13]
[tbd] IPv4_FQDN-MoS ?? ??
[RFC-mipshop-mos-dhcp-options-13]


Action 2:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Registry Name: IEEE 802.21 Service Type (MoS Sub-Option)
Registration Procedure: Standards Action

Initial contents of this sub-registry will be:

Value Name Reference
---- ---- ---------
0 Reserved [RFC-mipshop-mos-dhcp-options-13]
1 IS [RFC-mipshop-mos-dhcp-options-13]
2 CS [RFC-mipshop-mos-dhcp-options-13]
3 ES [RFC-mipshop-mos-dhcp-options-13]
4-255 Reserved [RFC-mipshop-mos-dhcp-options-13]


Action 3:

Upon approval of this document, IANA will make the following
assignments in the "DHCP Option Codes" registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml
sub-registry

Value Description Reference
----- ----------- ---------
[tbd] IPv6_Address-MoS [RFC-mipshop-mos-dhcp-options-13]
[tbd] IPv6_FQDN-MoS [RFC-mipshop-mos-dhcp-options-13]


Action 4:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

Registry Name: IEEE 802.21 Service Type (MoS Sub-Option)
Registration Procedure: Standards Action
Initial contents of this sub-registry will be:

Value Name Reference
---- ---- ---------
0 Reserved [RFC-mipshop-mos-dhcp-options-13]
1 IS [RFC-mipshop-mos-dhcp-options-13]
2 CS [RFC-mipshop-mos-dhcp-options-13]
3 ES [RFC-mipshop-mos-dhcp-options-13]
4-65535 Reserved [RFC-mipshop-mos-dhcp-options-13]


We understand the above to be the only IANA Actions for this
document.

My issues were resolved... but I'd positive confirmation from the DHC WG that they are fine with the syntax. I can see that the bit pattern mechanism was simplified, but "enc" still remains, and I think David complained about that in particular. If existing DHCP server software cannot deal with a conditional encoding of attributes, I'd recommend simplifying further. You do NOT want to upgrade clients and servers just to transport one additional piece of config data.

I have reviewed this draft. Its basically a very simple mechanism and can move forward soon. However, there were a number of question marks and inconsistencies in the draft. I believe these can be addressed easily, please try to spin a new version before Christmas so that I can send this off to IETF Last Call. I also have one big question around client's requests to the server and how that should be done. Hopefully the DHC WG chairs will be able to help us with that question.

Issues:

> The option MAY contain multiple domain names, but these SHOULD refer
> to different NAPTR records, rather than different A records.
... and then later ...
> Use of multiple domain names is not meant to replace NAPTR and SRV
> records, but rather to allow a single DHCP server to indicate MIH
> servers operated by multiple providers.

I think I understand this, but I would rephrase it to be more clear. Put everything in one place.

For instance: The option MAY contain multiple domain names, but these should refer to the NAPTR records of different providers, rather than different A records within the same provider. That is, the use of multiple domain names is not meant to replace NAPTR and SRV records, but rather to allow a single DHCP server to indicate MIH servers operated by multiple providers.

> In order to acquire the MoS information, the mobile node MUST send
> either a DHCPDISCOVER or DHCPINFORM message to a subnet broadcast or
> a unicast server address, respectively. In this message the mobile
> node (DHCP client) MUST include the sub-opt Type for the MoS
> Discovery in the sub-options field.

What sub-options field? Do you mean that the MOS Discovery option must be included, and that within that option the sub-option field(s) must be set in a specific way? Or that the client uses the Parameter Request List from RFC 2132 and adds the option code for MOS Discovery?

I was assuming the later, but that does not match the text. Also, 4.1.2 talks about the server looking at the sub-option type.

If you are doing the former, is that according to existing practices of DHCP? If it is, how should the length fields, enc, etc. be set in the option?

How do the DHC WG chairs recommend this be done?

>    In order to acquire the MoS address, the mobile node MUST send either
>    a REQUEST or INFORMATION_REQUEST message to the All_DHCP_Servers
>    multicast address. In this message the mobile node (DHCP client)
>    MUST include the Option Code for the MoS Discovery option in the
>    option_code.

What "option_code"? Can't find this from RFC 3115 or the draft.


>    In order to acquire the MoS address, the mobile node MUST send either
>    a REQUEST or INFORMATION_REQUEST message to the All_DHCP_Servers
>    multicast address. In this message the mobile node (DHCP client)
>    MUST include the Option Code for the MoS Discovery option in the
>    option_code.
... and then later ...
>
>    may provide the matching information from the preconfigured
>    information available locally. The DHCP server MUST always
>    construct the response according to the Sub-Opt Type requested
>    by the DHCP client.

The text v6 client does not talk about sub-Opt types, yet the server text talks.

>  This document defines a number of Dynamic Host Configuration Protocol
> (DHCPv4 and DHCPv6) options that contain a list of domain names
>  or IP addresses that can be mapped to servers providing IEEE 802.21

Indentation error.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Vijay Devarapalli is the Document Shepherd for this document. I
have reviewed the document and it is ready for forwarding to the
IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

This document has had adequate reviews from the members in the MIPSHOP
WG. Reviews were also sought from the DHC directorate. Bernie Volz
responded and reviewed the document. I have no concerns about the depth
or breadth of the reviews that have been performed.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

None.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No specific concerns.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is WG consensus in advancing this document.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The document uses the boilerplate from RFC 3978 instead of RFC 4748.
Expect this to get fixed in the next version. No other nits were found.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document splits the references into normative and
informative references. There are two downward references, but both
the corresponding documents are already with the IESG.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The IANA considerations section exists and is consistent with
the body of the document.  The document requests reservations in
the appropriate IANA registries. The IANA registries that need to
be modified/created are clearly identified.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Does not apply.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

The document defines the necessary Dynamic Host Configuration
Protocol (DHCPv4 and DHCPv6) options that contain a list of domain
name or IP addresses that can be mapped to servers providing IEEE
802.21 type of Mobility Services [MSFD]. These Mobility Services
are used to assist an MN in handover preparation (network discovery)
and handover decision (network selection). The services addressed
in this document are the Media Independent Handover Services
defined in [IEEE802.21].

          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

None.

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

There are no known implementations or vendor plans to implement
the specification.

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

Document shepherd: Vijay Devarapalli
Responsible AD: Jari Arkko/Mark Townsley