[dhcwg] draft-ietf-dhc-dhcpv6-vendor-message-01

[Alfred Hönes <[e-mail]>]

I have reviewed draft-ietf-dhc-dhcpv6-vendor-message-01
and have only a few editorial comments.


(1)  Abstract
[[ same as for draft-ietf-dhc-dhcpv4-vendor-message-01 ]]

                 vvvvvvvv
   This document requests a vendor-specific DHCPv6 message assignment.
   [...]

This text will be OBE by the publication of the memo as an RFC
and should be replaced by words still valid then (see my notes
on dhc-dhcpv4-vendor-message-01).


(2)  Section 2  vs. Section 5

Below the first diagram in Section 2, the draft says:

      msg-type             VENDOR-SPECIFIC (TBD)
                                            ^^^

However, the IANA considerations in Section 5 say:

|  IANA is requested to assign DHCPv6 Message type 254 to the Vendor-
|  specific Message in the registry maintained in [DHCPv6Params]:
|
|     254 VENDOR-SPECIFIC
      ^^^

The draft should be made consistent, either prescribing the value to
be assigned or leaving it to the IANA.

(3)  Section 2, editorial

In the paragraph below the first diagram and the related field
explanations, the draft says:

   The options MUST be encoded as a sequence of code/length/value fields
|  of identical format to the DHCPv6 options field.  [...]
      ^^^^^^^^^^^^^^^^^^^

Again, "identical to" should be brought together:

   The options MUST be encoded as a sequence of code/length/value fields
|  of format identical to the DHCPv6 options field.  [...]
      ^^^^^^^^^^^^^^^^

(My notes on dhc-dhcpv4-vendor-message-01 contain an alternative
for a similar issue, which could be applied here as well.)


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+