Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support

Steven Barth <cyrus@openwrt.org> Thu, 23 July 2015 14:22 UTC

Return-Path: <cyrus@openwrt.org>
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 65B881ACE78 for <mif@ietfa.amsl.com>; Thu, 23 Jul 2015 07:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.95
X-Spam-Level:
X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6] autolearn=no
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 xZ1WFg_bKygq for <mif@ietfa.amsl.com>; Thu, 23 Jul 2015 07:22:42 -0700 (PDT)
Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (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 261F21ACE60 for <mif@ietf.org>; Thu, 23 Jul 2015 07:22:36 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZIHON-0002VN-Ea with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Thu, 23 Jul 2015 16:22:35 +0200
To: Jouni Korhonen <jouni.nospam@gmail.com>
References: <55AF52F1.2040802@openwrt.org> <55B0CB0C.1010301@gmail.com> <55B0D2A8.4060807@openwrt.org> <55B0EFC1.4080502@gmail.com>
From: Steven Barth <cyrus@openwrt.org>
Message-ID: <55B0F8A9.4060203@openwrt.org>
Date: Thu, 23 Jul 2015 16:22:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55B0EFC1.4080502@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/T2v0B24Su1jmt9RaEXulcFQ1evQ>
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 23 Jul 2015 14:22:43 -0000

>
> Since the PVD-ID option is like any ND option out there it can be in an RS with or without the container. If the end host wants to e.g. sign the PVD-ID, then it would use the container.

The latter is to my understanding not really mentioned yet. Personally I would not have imagined that this was intended. In any case I do not see the point in allowing both behaviors (with and without container). Aside my doubts in general about your use of RSs, I think you should decide that whether you want these signed requests then require that the PVD-ID must always be inside a container otherwise only allow them to be on top-level. Allowing both doesn't really give you anything aside unnecessarily bloating implementations.


>
> The text currently says "the PVD container and the accompanying PVD identity MUST both be inside the same fragment."
>
> I find this quite clear what it means. If you have a better way to describe this I am happy to see a text proposal and incorporate it.
Both parts of the sentence make sense to me but not in the "i.e."-combination.
The MUST NOT be fragmented parts sounds to me as if the whole container must not be fragmented but in the "i.e." you only talk about ID but not other encaps'ed options which is what confused me.

Also what do you mean by fragmentation in the first place? IPv6-level fragmentation? If yes, (again aside ND and fragmentation issues in general) there should be an explanation for the MUST here since at least to me its not obvious.



Cheers,

Steven