Subject: [mif] I-D Action: draft-ietf-mif-mpvd-dhcp-support-01.txt

From: [email-masked]
Date: Wed, 04 Mar 2015 08:14:42 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiple Interfaces Working Group of the IETF.

        Title           : Support for multiple provisioning domains in DHCPv6
        Authors         : Suresh Krishnan
                          Jouni Korhonen
                          Shwetha Bhandari
	Filename        : draft-ietf-mif-mpvd-dhcp-support-01.txt
	Pages           : 10
	Date            : 2015-03-04

Abstract:
   The MIF working group is producing a solution to solve the issues
   that are associated with nodes that can be attached to multiple
   networks.  One part of the solution requires associating
   configuration information with provisioning domains.  This document
   details how configuration information provided through DHCPv6 can be
   associated with provisioning domains.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-dhcp-support/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-dhcp-support-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 04 Mar 2015 08:21:43 -0800

Folks,

Some minor updates and adding text about the relay agent behavior based 
on the comments we received. More specifically we discuss how the RSOO 
could be used in the context of PVDs and DHCPv6.

- Jouni

3/4/2015, 8:14 AM, [email-masked] kirjoitti:
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Ian Farrer <[email-masked]>
Date: Mon, 23 Mar 2015 10:52:32 -0500

Hi Jouni,

Thanks for making the update.

One case that is possible that isn’t currently covered in section 7.3 is where the client requests a specific PvD(s) and the RSOO also appends a request for a different PvD(s) on behalf of that client. If the requested PVD-IDs are different between the client and the relay, how does the server respond?  i.e. does one take precedence over the other? do they get combined? Are specific preferred to general requests (or vice-versa)? etc.?

My suggestion is to add text to make this as policy configurable on the server.

There’s also a question here about what the client’s behaviour should be if it has requested a specific set of PVDs, but the response contains configuration for PVD-IDs that it hasn’t requested. Again, I would suggest it’s client configurable.

Cheers,
Ian

> On 04 Mar 2015, at 17:21, Jouni Korhonen <[email-masked]> wrote:
> 
> Folks,
> 
> Some minor updates and adding text about the relay agent behavior based on the comments we received. More specifically we discuss how the RSOO could be used in the context of PVDs and DHCPv6.
> 
> - Jouni
>

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 23 Mar 2015 17:25:08 -0700

Hi Ian,

3/23/2015, 8:52 AM, Ian Farrer kirjoitti:
> One case that is possible that isn’t currently covered in section 7.3 is where the
 > client requests a specific PvD(s) and the RSOO also appends a request
> for a  different PvD(s) on behalf of that client. If the requested PVD-IDs
 > are different between the client and the relay, how does the server 
respond?
 > i.e. does one take precedence over the other? do they get combined? Are
 > specific preferred to general requests (or vice-versa)? etc.?

Good point. I would say the server responds to both the it can. The 
server cannot really know why the client is interested in a specific 
PVD. The server might have a good idea why the relay asks for some PVD. 
At the end the client is responsible handling the config information 
from all PVDs it receives, solicited or unsolicited.

> My suggestion is to add text to make this as policy configurable on the server.

Will do.

> There’s also a question here about what the client’s behaviour should be
 > if it has requested a specific set of PVDs, but the response contains
 > configuration for PVD-IDs that it hasn’t requested. Again, I would
 > suggest it’s client configurable.

Agree with the solution approach. The client might be aware of more PVDs 
that is requests at some specific time. Whether the client then finds 
the unsolicited PVD information useful is another thing.

- Jouni