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

Ian Farrer <ianfarrer@gmx.com> Fri, 25 July 2014 14:03 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A791B2923 for <mif@ietfa.amsl.com>; Fri, 25 Jul 2014 07:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NICkrdHLCva for <mif@ietfa.amsl.com>; Fri, 25 Jul 2014 07:03:09 -0700 (PDT)
Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A43D1B292B for <mif@ietf.org>; Fri, 25 Jul 2014 07:02:18 -0700 (PDT)
Received: from dhcp-b86f.meeting.ietf.org ([31.133.184.111]) by mail.gmx.com (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 <ianfarrer@gmx.com>
In-Reply-To: <CANF0JMCKAM2htrjFHM+76cZ+agW9Z1JbfrDaFxcmFz5_z=RPTw@mail.gmail.com>
Date: Fri, 25 Jul 2014 10:02:14 -0400
Message-Id: <E96BEAE3-909A-4D6B-BF41-FD45E155A4FE@gmx.com>
References: <CANF0JMCKAM2htrjFHM+76cZ+agW9Z1JbfrDaFxcmFz5_z=RPTw@mail.gmail.com>
To: Hui Deng <denghui02@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
X-Provags-ID: V03:K0:uABaE4bj/FPs8UgqUdxLV9ywR8dXdsHTz63JupTlTHWs6Pq1d7G WjwKJlbrI6RbOnmTrEjvXNIEQksBhqPPpSSiEdlKwZ70t+ckpxfTatUWfT23czmzL4o6j1Q Rs85tYq+vzPjXLDFPFfi+78HIT99urVZTq9ri4f1qFGAIkNGkPeldRISzzKbe/wkVfsM2AA PtZHCJf38LaAwlZdW9PhA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mif/JVx8GxjP2BESXVQH3yRZ8sFBarg
Cc: Margaret Wasserman <margaretw42@gmail.com>, MIF Mailing List <mif@ietf.org>
Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jul 2014 14:03:13 -0000

Hi,

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):

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

2.1
"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.

2.4 
"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.

3.3
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.

Cheers,
Ian



On 4 Jul 2014, at 02:13, Hui Deng <denghui02@gmail.com> wrote:

> Hello all
> 
> We issue 2 weeks WGLC for the Architecture document, please kindly help to review and comment on the document.
> http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02
> 
> Best regards,
> 
> -Co-chairs.
> 
> 
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif