Subject: [Int-dir] Review of draft-ietf-dmm-4283mnids-03

From: Tatuya Jinmei <[email-masked]>
Date: Fri, 06 Jan 2017 11:08:44 -0800

Reviewer: Tatuya Jinmei
Review result: Ready with Nits

I am an assigned INT directorate reviewer for
draft-ietf-dmm-4283mnids.
These comments were written primarily for the benefit of the Internet
Area Directors. Document editors and shepherd(s) should treat these
comments just like they would treat comments from any other IETF
contributors and resolve them along with any other Last Call comments
that have been received. For more details on the INT Directorate,
see http://www.ietf.org/iesg/directorate.html.

I've reviewed the 03 version of the draft.  I didn't find anything
obviously wrong/incorrect, and it's generally well-written.  So I
think it's basically ready for ship.  But I'd have to note that I'm
not familiar with many of the lower-layer technologies referenced in
the draft, so my review and conclusion are somewhat superficial.

I found some minor points.  The authors may want to address them:

- Section 4.1: I guess the MNID is generally supposed to be unique
(at
  least in the realm the ID is used), but not all IPv6 addresses are
  guaranteed to be unique (a link-local or unspecified address is an
  obvious example, an ULA may also be inappropriate depending on the
  usage context).  It may be better to note the fact, and you may
also
  want to impose some restrictions on the type of address that can be
  used as an MNID.

- Section 4.5

   2000, modulo 2^32.  Since the link-layer address can be of
variable
   length [RFC2464], the DUID-LLT is of variable length.

  I don't understand why RFC2464 is referenced in this context.  This
  RFC is about IPv6 over Ethernet, and assumes a fixed (6 bytes)
  length of hardware address.

- Section 4.9: s/is (GRAI)/(GRAI)/

   The Global Returnable Asset Identifier is (GRAI) is defined by the

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 15 Jan 2017 21:08:41 -0800

Hello Tatuya,

Thank you for the careful review.  Follow-up below:

>    want to impose some restrictions on the type of address that can be

This is correct.  I will fashion some language as suggested.  I think it 
is appropriate to allow ULAs, but multicast and unspecified addresses 
seem clearly inappropriate, and I am i favor of disallowing link-local 
addresses.
>    length of hardware address.

I don't quite know what to do about this.  I actually just copied this 
language from RFC 3315.  I think that the citation is also wrong in RFC 
3315, for the same reason as given here.  I could simply delete the 
reference to RFC 2464.

>     The Global Returnable Asset Identifier is (GRAI) is defined by the

Fixed.  I also checked for other similar instances and did not find any.

Regards,
Charlie P.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 16 Jan 2017 13:17:43 +0000

FYI: The RFC2464 reference in RFC3315 is about canonical order, not the link-layer address length.

"This type of DUID consists of a two octet type field containing the
   value 1, a two octet hardware type code, four octets containing a
   time value, followed by link-layer address of any one network
   interface that is connected to the DHCP device at the time that the
   DUID is generated.  The time value is the time that the DUID is
   generated represented in seconds since midnight (UTC), January 1,
   2000, modulo 2^32.  The hardware type MUST be a valid hardware type
   assigned by the IANA as described in RFC 826<https://tools.ietf.org/html/rfc826> [14<https://tools.ietf.org/html/rfc3315#ref-14>].  Both the time and
   the hardware type are stored in network byte order.  The link-layer
   address is stored in canonical form, as described in RFC 2464<https://tools.ietf.org/html/rfc2464> [2<https://tools.ietf.org/html/rfc3315#ref-2>]."

- Bernie (from iPad)

On Jan 16, 2017, at 12:09 AM, Charlie Perkins <[email-masked]<mailto:[email-masked]>> wrote:

Hello Tatuya,

This is correct.  I will fashion some language as suggested.  I think it is appropriate to allow ULAs, but multicast and unspecified addresses seem clearly inappropriate, and I am i favor of disallowing link-local addresses.

- Section 4.5

I don't quite know what to do about this.  I actually just copied this language from RFC 3315.  I think that the citation is also wrong in RFC 3315, for the same reason as given here.  I could simply delete the reference to RFC 2464.

Regards,
Charlie P.

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

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 16 Jan 2017 07:22:56 -0800

Hello again Tatuya,

Here is an updated description of the IPv6 address type when used as a MNID:

> 4.1.  Description of the IPv6 address type
>
>     The IPv6 address [RFC4291] is encoded as a 16 octet string containing
>     the full IPv6 address.  The IPv6 address MUST be a unicast routable
>     IPv6 address.  Multicast addresses, link-local addresses, and the
>     unspecified IPv6 address MUST NOT be used.  IPv6 Unique Local
>     Addresses (ULAs) MAY be used, as long as any security operations
>     making use of the ULA also take into account the domain in which the
>     ULA is guaranteed to be unique.

Please let me know if this resolves your concern.

Regards,
Charlie P.

On 1/15/2017 9:08 PM, Charlie Perkins wrote:
> This is correct.  I will fashion some language as suggested.  I think 
> it is appropriate to allow ULAs, but multicast and unspecified 
> addresses seem clearly inappropriate, and I am i favor of disallowing 
> link-local addresses.
.....

---

From: 神明達哉 <[email-masked]>
Date: Mon, 16 Jan 2017 10:30:01 -0800

At Mon, 16 Jan 2017 07:22:56 -0800,

> Please let me know if this resolves your concern.

Looks good to me.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 16 Jan 2017 10:40:39 -0800

At Sun, 15 Jan 2017 21:08:41 -0800,

> 3315, for the same reason as given here.  I could simply delete the

I don't see "Since the link-layer address can be of variable length
[RFC2464], the DUID-LLT is of variable length." in RFC3315.  See also
the followup comment by Bernie.  Deleting the reference will certainly
address my concern, and I personally don't mind not having a reference
here.

--
JINMEI, Tatuya