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

Jouni Korhonen <jouni.nospam@gmail.com> Tue, 24 March 2015 00:25 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888F11A90C7 for <mif@ietfa.amsl.com>; Mon, 23 Mar 2015 17:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7hOwwUG3CR6 for <mif@ietfa.amsl.com>; Mon, 23 Mar 2015 17:25:12 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAFC1A90C8 for <mif@ietf.org>; Mon, 23 Mar 2015 17:25:12 -0700 (PDT)
Received: by wibdy8 with SMTP id dy8so61582955wib.0 for <mif@ietf.org>; Mon, 23 Mar 2015 17:25:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3DRk2TSj11BgPel97yBZIAF38HCNBAWTFOJgrl2uzTs=; b=sO8S0HFRCMmuSG4rOQ65uu4VWC2gvHdjsWHQevkUQbM9ifUGwWkgCmjUPuXCLSLdRp Y9sy4yW/enJ8XNpoRV7Xz/k/4SUmMhXg8ewxpAcoCHqCirY0V8NTVcYFjD2Spk6weNht dqF73qeZukbDK1I5tz/FoPlHUsuxcauIWR4BBc8rB1kp0+i65ybKANf1wVj8wC7/UpYg 5Cjshfd4h2zZMYyjiQsLQjMc83ZqZdnvPfvzyJ8KrQcaEP60U215wfcAbSPhl3j2/vaZ PG2j81q+48QIfJ7FR861Z5FsTqAj04fP68VIPnXKfs4dMGfe92z27o3w6PCswddhmBJX EGig==
X-Received: by 10.194.63.16 with SMTP id c16mr2694290wjs.117.1427156710900; Mon, 23 Mar 2015 17:25:10 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:144:6c95:fd58:3218:43f4? ([2001:67c:370:144:6c95:fd58:3218:43f4]) by mx.google.com with ESMTPSA id fo8sm13387225wib.14.2015.03.23.17.25.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 17:25:10 -0700 (PDT)
Message-ID: <5510AEE4.9030306@gmail.com>
Date: Mon, 23 Mar 2015 17:25:08 -0700
From: Jouni Korhonen <jouni.nospam@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Ian Farrer <ianfarrer@gmx.com>
References: <20150304161442.9624.98525.idtracker@ietfa.amsl.com> <54F73117.9050608@gmail.com> <1EC282FE-E813-408A-B666-5EE781A35A8A@gmx.com>
In-Reply-To: <1EC282FE-E813-408A-B666-5EE781A35A8A@gmx.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/Ag5AKoSbL-MFKneeaJ2y062bj0k>
Cc: mif@ietf.org
Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-dhcp-support-01.txt
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2015 00:25:14 -0000

Hi Ian,


3/23/2015, 8:52 AM, Ian Farrer kirjoitti:
> 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.?

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

>
> Cheers,
> Ian
>
>> On 04 Mar 2015, at 17:21, Jouni Korhonen <jouni.nospam@gmail.com> 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
>>
>> 3/4/2015, 8:14 AM, internet-drafts@ietf.org kirjoitti:
>>>
>>> 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/
>>>
>>> _______________________________________________
>>> 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
>