From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [PATCH 0/6] [VERY RFC] Migration Stream v2
Date: Tue, 15 Apr 2014 11:38:56 +0100
Message-ID: <534D0C40.60908@eu.citrix.com>
References: <1397068104-23714-1-git-send-email-andrew.cooper3@citrix.com>	<1397126549.9862.116.camel@kazak.uk.xensource.com>	<53467EA9.1090305@citrix.com>	<CAFLBxZZCoD1GHGOiDxMXK1=+v30FGKtsZOv8iykhrBf57Y6d+A@mail.gmail.com>	<534C24BE.4070201@citrix.com>
	<21325.2925.579377.798603@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <21325.2925.579377.798603@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, David Vrabel <david.vrabel@citrix.com>
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>, Frediano Ziglio <frediano.ziglio@citrix.com>, Jan Beulich <JBeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

On 04/15/2014 11:35 AM, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] [PATCH 0/6] [VERY RFC] Migration Stream v2"):
>> On 14/04/14 18:49, George Dunlap wrote:
>>> What did you imagine might constitute an "Optional" record?
>>
>> This was something Ian Jackson asked for and it seems like a useful
>> capabilitity to have for future use.  Not sure what it might be used for
>> yet.
>
> Right.
>
> Long experience with protocol design has taught me that protocols
> should almost always have both an extensibility mechanism which is
> ignored by ignorant receivers, and one which causes ignorant receivers
> to abort.
>
> I don't know yet what we might use it for.  However, we should test
> that it works (ie is ignored by) the receiver (or it will be useless).

Yes, this is the main concern.  2 billion record types should be plenty 
for the "required" field, so the 2 billion allocated for "optional" 
shouldn't be a big loss. :-)  The main risk would be if something which 
is, in fact, required for proper operation on the far side is marked 
"optional".  I guess as long as we have an "ignore everything optional" 
test case we should be OK.

  -George