Re: [mif-arch-dt] draft-anipko-mif-mpvd-arch-01 for Monday teleconf

["Zuniga, Juan Carlos" <[e-mail]>]

Hi Dmtry, all,

 

Very nice start. Some comments after reading the draft:

 

Section 2.  Definitions and types of PVDs

 

   As an example, node administrator could inject a not ISP-specific DNS

   server into PVDs for any of the networks the node could become

   attached to.  Such creation / augmentation of PVD(s) could be static

   or dynamic.  The particular implementation mechanisms are outside of

   the scope of this document.

 

[JCZ] I believe we should mention ANDSF as one of such policy
configuration policy implementations. Later on MMS/APN is also mentioned
as an example and it helps understanding the meaning.

 

Section 2.1.  Explicit and implicit PVDs

 

  It is likely that for a long time there may be networks which do not

   advertise any explicit PVD information, since deployment of any new

   features in networking protocols is a relatively slow process.  When

   connected to such networks, PVD-aware nodes may still provide

   benefits to their users, compared to non-PVD aware nodes, by creating

   separate PVDs for configuration received on different interfaces.

   Such PVDs are referred to in this document as "implicit".  This

   allows the node to manage and use network information from different

   interfaces separately and consistently use the configuration to serve

   network connection requests.

 

[JCZ] Seems to me that out-of-band PVD advertisements can also be
considered in this "implicit" category, especially if the statement is
from the IETF-protocols' point of view. If so (and even if it is not),
we should add some clarifying text. 

 

 

   In the mixed mode, where e.g.  multiple networks are available on the

   link the interface is attached to, and only some of the networks

   advertize PVD information, the PVD-aware node shall create explicit

   PVDs based on explicitly learned PVD information, and associate the

   rest of the configuration with an implicit PVD created for that

   interface.

 

[JCZ] Can we support multiple PVDs in this mode? Should we say "one or
multiple implicit PVDs"?

 

 

   It shall be possible for networks to communicate...

 

[JCZ] Since this is an Informational document, I believe we need to use
"should" instead of "shall". There are several occurrences throughout
the document.

 

Section 2.3.  PVD identity/naming

 

   For explicit PVDs, PVD ID (globally unique ID, that possibly is

   human-readable) is received as part of that information.  For

   implicit PVDs, the node assigns a locally generated globally unique

   ID to each implicit PVD.

 

   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

   IDs to the end-user for selection of Internet-connected PVDs.

 

[JCZ] This is understandable, but very challenging and difficult to
enforce. I think more discussion is needed amongst us, and more text to
explain and justify the recommendation.

 

Regards,

 

Juan-Carlos 

 

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Dmitry Anipko
Sent: Sunday, July 21, 2013 6:09 PM
To: [e-mail]
Subject: [mif-arch-dt] draft-anipko-mif-mpvd-arch-01 for Monday teleconf

 

Hi all, 

 

The submission tool is closed, if there is a way to submit a revision
before IETF starts, please let me know.

 

Meanwhile, sending the updated text, with Ted's comments incorporated,
attached.

 

Thanks,

Dmitry