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

From: Dmitry Anipko <[email-masked]>
Date: Sun, 21 Jul 2013 22:08:32 +0000

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Jul 2013 00:07:07 +0000

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

If the working group chairs request it, I can ask the secretariat to post a late draft.   I'm not convinced it's necessary in this case, so I'm not proposing that they do so, but they are welcome to do so if they think it's worthwhile.

---

From: Hui Deng <[email-masked]>
Date: Mon, 22 Jul 2013 18:12:27 +0800

I personally feel that we would better to post it with AD approval if that is still possible.
because there are lots of people haven't read this draft before IETF meeting.

 -Hui
 
> From: [email-masked]
> To: [email-masked]
> Date: Mon, 22 Jul 2013 00:07:07 +0000
> CC: [email-masked]
> Subject: Re: [mif-arch-dt] draft-anipko-mif-mpvd-arch-01 for Monday teleconf
> 
> _______________________________________________
> mif-arch-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif-arch-dt

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 22 Jul 2013 07:35:27 -0400

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Dmitry Anipko
Sent: Sunday, July 21, 2013 6:09 PM
To: [email-masked]
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

---

From: Tim Chown <[email-masked]>
Date: Fri, 26 Jul 2013 23:14:05 +0100

Hi,

Is there any plan to have a discussion before Thursday's mif session?

It seems the mif agenda is purely 1 hour for this topic though.

Thanks,
Tim

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 26 Jul 2013 22:23:49 +0000

As far as arch draft is concerned, I'm working on the draft update based on recent comments and Monday discussion, will send out before IETF starts, and respond to those comments over email as well.

Hopefully it will help to generate more discussion :)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Chown
Sent: Friday, July 26, 2013 3:14 PM
To: [email-masked]
Subject: [mif-arch-dt] discussion prior to mif wg slot?

Hi,

Thanks,
Tim