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 <denghu...@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
_______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
