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

[Dmitry Anipko <[e-mail]>]

Hi Ian,

Thank you for the comments.

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

[danipko] Thank you for the offer and that would be great. I'll send you the text after addressing the WGLC comments.

>> I think that this really blurs the overall architecture of containing PvD configuration and think that it should be removed.

[danipko] Will do.

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

[danipko] I'll change the text so that it would allow this approach.

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

[danipko] OK.

Thank you,
Dmitry

From: mif [mailto:[e-mail]] On Behalf Of Ian Farrer
Sent: Friday, July 25, 2014 7:02 AM
To: Hui Deng
Cc: Margaret Wasserman; MIF Mailing List
Subject: Re: [mif] WGLC for draft-ietf-mif-mpvd-arch-02

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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mif