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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 53A791B2923 for <>; Fri, 25 Jul 2014 07:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 5NICkrdHLCva for <>; Fri, 25 Jul 2014 07:03:09 -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 9A43D1B292B for <>; Fri, 25 Jul 2014 07:02:18 -0700 (PDT)
Received: from ([]) by (mrgmxus002) with ESMTPSA (Nemesis) id 0MbP98-1Wu7801xUS-00IoOI; Fri, 25 Jul 2014 16:02:16 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_C53CB8C7-0803-402A-8128-E6EA212F1F1D"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ian Farrer <>
In-Reply-To: <>
Date: Fri, 25 Jul 2014 10:02:14 -0400
Message-Id: <>
References: <>
To: Hui Deng <>
X-Mailer: Apple Mail (2.1878.6)
X-Provags-ID: V03:K0:uABaE4bj/FPs8UgqUdxLV9ywR8dXdsHTz63JupTlTHWs6Pq1d7G WjwKJlbrI6RbOnmTrEjvXNIEQksBhqPPpSSiEdlKwZ70t+ckpxfTatUWfT23czmzL4o6j1Q Rs85tYq+vzPjXLDFPFfi+78HIT99urVZTq9ri4f1qFGAIkNGkPeldRISzzKbe/wkVfsM2AA PtZHCJf38LaAwlZdW9PhA==
Cc: Margaret Wasserman <>, MIF Mailing List <>
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:03:13 -0000


Sorry for my late review. Overall, I think this update has made a lot of improvements on the last version. Some comments below (most of them also raised in the MIF WG  session):

The document needs a language review. I'll volunteer for this, if you like.

"It shall be possible for sources of PVD information to communicate that some of their configuration elements could be used within a context of other networks/PVDs.  PVD-aware nodes, based on such declaration and their policies, may choose to inject such elements into some or all other PVDs they connect to."

I'm concerned about this for a couple of reasons. It brings up a requirement for a very complex mechanism between the PvDs so that individual PvD configuration paramaters can indictate their applicability to other PvDs and also for a PvD to accept parameters from other PvDs. Then, there's the security implications of this.
I think that this really blurs the overall architecture of containing PvD configuration and think that it should be removed.

"PVD-aware node may use these IDs to choose a PVD with matching ID for special-purpose connection requests, in accordance with node policy or choice by advanced applications, and/or to present human-readable representation of the IDs to the end-user for selection of Internet-connected PVDs."

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.

I would like to see some advice in here saying that 'configuration without any PvD information should continue to be advertised for non PvD-aware hosts unless it is the explicit intention to exclude such hosts from obtaining configuration', or something similar.

5.1 Again, I think this has the same problems as my comment for 2.1 above. How does an administrator indicate that a particular config parameter is globally applicable, or restricted to a specific subset of available PvDs?
Although duplicating configuration between PvDs may be less efficient than import/export policies between PvD parameters, it's going to be a lot easier to implement and manage.


On 4 Jul 2014, at 02:13, Hui Deng <> wrote:

> Hello all
> We issue 2 weeks WGLC for the Architecture document, please kindly help to review and comment on the document.
> Best regards,
> -Co-chairs.
> _______________________________________________
> mif mailing list