Re: [Gen-art] [DMM] Review of draft-ietf-dmm-4283mnids-04 (Dale R. Worley) Wed, 15 February 2017 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8312012953B for <>; Tue, 14 Feb 2017 17:04:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.933
X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qjH8Q54D0doT for <>; Tue, 14 Feb 2017 17:04:24 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 253DC12994F for <>; Tue, 14 Feb 2017 17:04:23 -0800 (PST)
Received: from ([]) by with SMTP id do0DcFwyQ6RIndo18ci5zq; Wed, 15 Feb 2017 01:04:22 +0000
Received: from ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by with SMTP id do16cIP3uanCido17cdSBQ; Wed, 15 Feb 2017 01:04:22 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id v1F14K3c028393; Tue, 14 Feb 2017 20:04:20 -0500
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id v1F14JIs028390; Tue, 14 Feb 2017 20:04:19 -0500
X-Authentication-Warning: worley set sender to using -f
To: Charlie Perkins <>
In-Reply-To: <> (
Date: Tue, 14 Feb 2017 20:04:19 -0500
Message-ID: <>
X-CMAE-Envelope: MS4wfKS5k4ydAZv1A456HK1fKqO6j5y19L1ZpbVVuQFDzw5RJynsm4EAMW/wcjOfIV/X2s1VMEvayTR3vLd+fyExBbJ4s+untlG2qrb6SFcan1fbUFhjyWJi BuWJ2XhXWcrJM9lz9/6nA+ONc7YRHvEIZzAN6p6B9Mj+SD33E4czqMy3Q/LYHEvDJI+QY3qSNkzvw2XpIoLuwqBEyYtWSo35V6QdQZOBWEt02DkGEokD6VkX qaVRCcr4CJFrMjY+moCAJVvIRT2bi5AXh8g2OMgkykVP8wp5PlSLFJlZv7DcnV7T
Archived-At: <>
Subject: Re: [Gen-art] [DMM] Review of draft-ietf-dmm-4283mnids-04
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Feb 2017 01:04:25 -0000

Charlie Perkins <> writes:
> I am hesitant to replace so many MNID types by a single URN type with 
> substructure.  What would you think about replacing the existing 
> RFID-*-URI types with a single URN type, but leaving the existing binary 
> types?  This gets the benefit you suggest for future extensibility, but 
> retains the shorter forms that may often be advantageous.

Suddenly today I realized something I should have realized in the
review, which would have saved us much time in discussion.  Viz.,
consider this proposal:

- one MNID type for *all* the EPC binary schemes

- one MNID type for *all* URNs, *including* the EPC URI forms

This would work, since (1) (not surprisingly) the EPC binary schemes are
all differentiated by their first 8 bits.  (see table on page 19 of the
tag-data standard,
and (2) all URNs are differentiated by their namespace part.

(This parallels using one MNID number for all DUID types, since DUIDs
have an internal indicator for the four types.)

This approach has all the desirable properties anyone has mentioned so

- includes all EPC binary and URI forms
- automatically includes all existing and future EPC binary forms
- automatically includes all existing and future URN forms *including*
  all existing and future EPC URI forms
- doesn't have a proliferation of MNID type numbers which duplicate
  information that can be fairly easily extracted from the
  identifier itself
- includes all the short EPC forms, allowing brevity when that is

This seems to be practical, simple, and almost as elegant as possible.
What do you think?

> I changed the text as follows:
>>     Some MNIDs contain sensitive identifiers which, as used in protocols
>>     specified by other SDOs, are only used for signaling during initial
>>     network entry.  In such protocols, subsequent exchanges then rely on
>>     a temporary identifier allocated during the initial network entry.
>>     Managing the association between long-lived and temporary identifiers
>>     is outside the scope of this document.
> I can't remember exactly why this text was added - it was a long time 
> ago.  But anyway the main point is to simply mention that there may be 
> associations between some of the MNID types that might be important from 
> a security standpoint, without meaning to go into examples.

Certainly the new text is clear enough.