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

From: Hui Deng <[email-masked]>
Date: Fri, 4 Jul 2014 14:13:53 +0800

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.

---

From: Zhen Cao <[email-masked]>
Date: Thu, 17 Jul 2014 21:59:02 +0800

Hi Everyone,

Supportive of moving forward the document, and this is an important
architecture work.

Two more cents for consideration:
- Do we or Does the working group need any next step /gap analysis in
this document? Although the document is theoretically abundant, I do
not see much engineering implications though.

- @Co-chairs, This is a design team work, do we need to list the all
contributors as well?

Many thanks,
zhen
Chinamobile

On Fri, Jul 4, 2014 at 2:13 PM, Hui Deng <[email-masked]> wrote:
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Dapeng Liu <[email-masked]>
Date: Thu, 17 Jul 2014 22:57:37 +0800

Hello all,  

I support moving forward of this document.

One comment: In Section 6 (http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-02#section-6). PVD support in APIs:

Should we add MIF API document as reference?  

--  
Dapeng Liu

在 2014年7月4日 星期五，14:13，Hui Deng 写道：

> Hello all
>  
> We issue 2 weeks WGLC for the Architecture document, please kindly help to review and comment on the document.
> [email-masked] (mailto:[email-masked])

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Jul 2014 11:07:17 -0400

>  Should we add MIF API document as reference?

That would mean that the MPVD doc would be blocked until the API doc was done, or else that we'd have an informative reference to a draft.

---

From: Ian Farrer <[email-masked]>
Date: Fri, 25 Jul 2014 10:02:14 -0400

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Jul 2014 10:12:04 -0400

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

+1

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

---

From: Ian Farrer <[email-masked]>
Date: Fri, 25 Jul 2014 10:20:16 -0400

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

Cheers,
Ian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Jul 2014 10:23:41 -0400

> [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. Usin…

Yup.   I think this is a problem that needs to be addressed.

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 30 Jul 2014 17:42:27 +0000

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 exclu…

[danipko] OK.

Thank you,
Dmitry

From: mif [mailto:[email-masked]] 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,

Overall:

2.1

2.4

3.3

Cheers,
Ian

On 4 Jul 2014, at 02:13, Hui Deng <[email-masked]<mailto:[email-masked]>> wrote:

Hello all

Best regards,

-Co-chairs.

_______________________________________________
mif mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mif