Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02

Ian Farrer <> Fri, 25 July 2014 14:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 47BF51A0336 for <>; Fri, 25 Jul 2014 07:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tiigFcQOJkl5 for <>; Fri, 25 Jul 2014 07:20:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EEF81A0316 for <>; Fri, 25 Jul 2014 07:20:23 -0700 (PDT)
Received: from ([]) by (mrgmxus002) with ESMTPSA (Nemesis) id 0M6ArU-1WHEC03ImA-00yDAQ; Fri, 25 Jul 2014 16:20:18 +0200
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ian Farrer <>
In-Reply-To: <>
Date: Fri, 25 Jul 2014 10:20:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.1878.6)
X-Provags-ID: V03:K0:2lb8Tqb/ePcRfhsqdshb+nDWkaIr/j4Tq/+dBTY3tjd9N1KBHZ+ NhcT+aQHKzFeIs7cm9AcLrsvQb4Tt7XoIXGj0RN8K7cX6aPzyTLSppcuGHy3VNwsh1KK1Sr R2AC70IKwUUctyK2x8cR6pCauIEQK5HzbPJwXwcS/Cdk4VgISlUvx1T4lEEo0myce2HV0Rm ZoZCbR/47ibLIsmb3KiqQ==
Cc: MIF Mailing List <>, Margaret Wasserman <>
Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Jul 2014 14:20:39 -0000

>> This may be too prescriptive about the format which is used for the PvD. Of the 6 formats proposed in kkbg-mpvd-id, only three of them are potentially meaningfully human-readable (UTF-8, FQDN, NAI). What would be good here is to place no expectation on the PvD ID itself being readable, but allow for additional PvD ID specific meta-data to be added which is human readable. Additional meta-data types can the be defined as required for other PvD selection mechanisms.
>> This avoids 'overloading' the function PvD ID itself, which should just be a unique id.
> This can be used as a sort of social engineering attack.  Not clear that it's a good idea.
[ian] I think the format / contents of the meta-data is a separate discussion. What I mean is that the PVD ID shouldn’t be trying to convey anything apart from a unique identifier for the PVD. Using a human readable format as the unique PvD ID also provides the potential for a social engineering attack.