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

"Bernie Volz (volz)" <> Mon, 16 January 2017 13:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E45C5129487; Mon, 16 Jan 2017 05:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mz0HALubk8rj; Mon, 16 Jan 2017 05:17:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 13E64129431; Mon, 16 Jan 2017 05:17:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9114; q=dns/txt; s=iport; t=1484572666; x=1485782266; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pPCGTQRYVJKJcJBSbc+wyLYTBvkXsbXe4Sk9nE5svWE=; b=YneKAp3oxamuZ9onQvBQinkFe89PNhpBT69Xwtzq2k6y+Nz6PVRQ/uQQ K9dil0CxG1vDCdjCCjLSIeNXluR7b1nIm4kLX3GfKykvhK/1PiEKWuq3p 9B7Dr4cmG2zBkT6pOob+qDEaRJIREwaz7vkEondmWLqZQrZdmW+Cq/HIx I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.33,239,1477958400"; d="scan'208,217";a="372517686"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jan 2017 13:17:45 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v0GDHjIo030823 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Jan 2017 13:17:45 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 16 Jan 2017 07:17:44 -0600
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 16 Jan 2017 07:17:44 -0600
From: "Bernie Volz (volz)" <>
To: Charlie Perkins <>
Subject: Re: [Int-dir] Review of draft-ietf-dmm-4283mnids-03
Thread-Topic: [Int-dir] Review of draft-ietf-dmm-4283mnids-03
Thread-Index: AQHSaFBRXgHG4F7CUkmyt5JN4S/GpKE7ASmAgAAkDkc=
Date: Mon, 16 Jan 2017 13:17:43 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_BBD02A847AAA4632B5C3C3ADC10A3ED2ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: Tatuya Jinmei <>, "" <>, "" <>, "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jan 2017 13:17:48 -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<> [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<> [2<>]."

- Bernie (from iPad)

On Jan 16, 2017, at 12:09 AM, Charlie Perkins <<>> wrote:

Hello Tatuya,

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

On 1/6/2017 11:08 AM, Tatuya Jinmei wrote:
- Section 4.1: I guess the MNID is generally supposed to be unique
  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
  want to impose some restrictions on the type of address that can be
  used as an MNID.

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

   2000, modulo 2^32.  Since the link-layer address can be of
   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.

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.

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

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

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

Charlie P.

Int-dir mailing list<>