Re: [mif] Review of draft-ietf-mif-mpvd-ndp-support-01

Ian Farrer <ianfarrer@gmx.com> Wed, 19 August 2015 08:20 UTC

Return-Path: <ianfarrer@gmx.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 2D7A41ACCE9 for <mif@ietfa.amsl.com>; Wed, 19 Aug 2015 01:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 SqdMwGhODFRM for <mif@ietfa.amsl.com>; Wed, 19 Aug 2015 01:20:44 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4DA1ACF17 for <mif@ietf.org>; Wed, 19 Aug 2015 01:20:43 -0700 (PDT)
Received: from ians-mbp.lan ([62.225.30.139]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MUpI8-1ZFsiC4BlE-00Y9Or; Wed, 19 Aug 2015 10:20:41 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_92B0A4CF-4F8B-44D4-B478-127B8F95A465"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Ian Farrer <ianfarrer@gmx.com>
In-Reply-To: <55D375E1.6050707@gmail.com>
Date: Wed, 19 Aug 2015 10:20:40 +0200
Message-Id: <9DBCF0B3-3CA8-4C19-BF56-0A610F4801C7@gmx.com>
References: <66E246E2-0217-4410-BE8D-64A8F55B8E29@gmx.com> <55D375E1.6050707@gmail.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>
X-Mailer: Apple Mail (2.2102)
X-Provags-ID: V03:K0:oEzJImrTQAoR6SWNW12qjC2SSIe+k33bkWaGdi/DVkjBqnj3kcL yQxYClkgYITyjIsHOQKN7eSwhSbqga8J6bKNoFj9AOz2my/skgOecfynDx7m3q3XxPPv7ws 1v1tt8wJl8AKgsPeCNprivyuMEB66BOy9NJVPXj1049xB19HWMGvhp1Vt/lLc7lFZZr2A++ am4+mIc61XVd9aryDPA/w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:lgD+KK72dH8=:eC66uUPpvCh6QjCqr9qJIR lNqevO5jIf08gvDIGB3oObWhqpSEgHi9UHtP/h4LXEKTn2qrNU0sFhkSiWWxAl+A2Ck0zdivj FMToCnBhrIpWHoTet4mG5FektW2yT4gnNqkwgB7XDaVC+6LB8TKw4Qbqk2iTCkfRj5uSt6hqo 0HsBPNXdn6u6mGaPPD8WHsOBJIhhHHQlPwbzaHycgDoMnmWDwrMjBOcPhrgZg453lVPFMZu81 4W3j5YPK2IXMyZ8SMo4Zu2YsCbVf5pt6NyH/nd+lHnpOeRWzXWRgqqVUqfu1jLKSsZKRKUoTs +mkKVBcKoFuTPmecx8sEQfiN6E1SDKKoZE21ZOZVBS2eyQ8b5/vXCpZ315kTuDrM0vYTtqcHn Kh7Ogis1FaNPt6TuMYLdgtJVZJIsfga2Kj8r6x65FCjGVBnTxYAc8EB1fumZ5htzXjCD3RTLN vwJAE5263qe5Xj7DzGN8spampG35S8ipGZ5z/sWR2Z4SkrDkiBrTK8C+qgDIYOUK00tCv5Mtv 07oukd9FAfbzacjQaCW4Cn4iNpvSjT/ia9k5xKA73oqF6fl8r59u4c2LkbMQa9CaNgA/5rzYn g1fp0i7qBo51yq8tySXpTm9KTmpHrUXT1HtpsVSljT054xicDvcNkuEnhwkA/Qrt1st15xWVt +ytW4MLmfTk725YwSTRyD+XPrzaOb/oclRLk6wJCjqjxh20GL1vUCt2crSCsThhwN28mY97gS oSGzufkNgoeI9z+QQ/IiytNR2huncsLTPfKLNQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/lhTROS3lhrS3xtkEfKXaSOx5Ccg>
Cc: mif@ietf.org
Subject: Re: [mif] Review of draft-ietf-mif-mpvd-ndp-support-01
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: Wed, 19 Aug 2015 08:20:45 -0000

Hi Jouni,

Please see one comment below.

Also, on looking through the draft again, in Figure 1, the convention for DHCP container options is to have an ‘encapsulated options’ field, but there isn’t one in the diagram. Is this intentional?


> 
>> 
>> But, para 2 of section 3 says that the RA can also include the PVD_CO. What is this for? Do the requested
>> PVD_IDs need to be in a container, or are they listed directly in the RS options (or are both allowed)?
> 
> s/RA/RS
> 
> If the solicitator wants to sign the PVD-ID it solicits for then the container is needed.
> 

[if] OK. That’s not clear from the current text. Can you add text to clarify when the PVD_CO is/isn’t necessary?

Actually, a section that describes the PVD RS & RA process might be the clearest way of pulling this together in one place.

Cheers,
Ian