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

Ian Farrer <ianfarrer@gmx.com> Sat, 25 July 2015 12:46 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 EA98D1AC3E0 for <mif@ietfa.amsl.com>; Sat, 25 Jul 2015 05:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 ugA9XY8Q-_x5 for <mif@ietfa.amsl.com>; Sat, 25 Jul 2015 05:46:47 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 53D611A9147 for <mif@ietf.org>; Sat, 25 Jul 2015 05:46:47 -0700 (PDT)
Received: from ians-mbp.fritz.box ([89.0.144.132]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MV30j-1ZQWpk0DgT-00YQLe for <mif@ietf.org>; Sat, 25 Jul 2015 14:46:45 +0200
From: Ian Farrer <ianfarrer@gmx.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <66E246E2-0217-4410-BE8D-64A8F55B8E29@gmx.com>
Date: Sat, 25 Jul 2015 14:46:46 +0200
To: mif@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
X-Mailer: Apple Mail (2.2102)
X-Provags-ID: V03:K0:P9pVlUes4gT6lpJOWlIZQRgsk+RoxAptdkRhBHvTG9Qy52L2Yh7 mrnHf7d4CnniSntfNuedDy+g5CFK1C63e4PORwmodqkf32tPAe9iL2aeJMcbTWsN9Jm6aQu bl5lOeYwp3YDppdrDNLdNKAk3+UvzrR4ZME11+fPa3nHfCYrOwzcYNbarN0kZwdwpL6Ny2V xc2ZufMouTO7Np257z1ow==
X-UI-Out-Filterresults: notjunk:1;V01:K0:u9hifiRd4Yw=:s8rzwsD5N8e/WR4Irytezs XcmyAaGbtSNS9OzufLbhS5XwRmSznxbaVgQplFBPQsMs5RDxjdBkyji/pL3cmjPSPkecC2/rZ VtH8uv0hrAFmmyeBRF6+a+/kRr+Gx011jUgNlz3ts15Dy+nMVYL8G8WPFytV9mZGCIK3ym4d0 IkU/tgGOV6Vig8vzKEJyBEv7s8QxoWmNTWJeVV4oU8ViMr5Dj6Q38ayRnVjZpOqfyTBllEwQJ giGqMFgxS6dr6AIQbu8hG7Cg9ipB0nANn9Fpqmay6ixfwMcvZKpZWaSX+J4DGuDFlT23ljoj6 VP+PR6SZtDbQCD7yhK46lQ+fBIqPcz7iJTJLIj74EEEp2zktYOjTy2pWeewBjdtjwX798Czab qJaaHeL1KDqppc4XJSDBLzOqeB4Aiu2z6toMsTQYHof/tIo8BZtVaVmP9+K8/3DHsTHqjjDzH WeOl0F2uhP8+MBPTDbzT0nH9Z7OxtmZAqqBNpyYWpqoK2dQZWozYf5HLqK8HiE7JI9pqvZi+j 9z1bw+O5J+F4s7cQOTsbix1lCHce8y+ds8q4U9IqwjxlmMewK1qnKTZxbkKYpIkRYPUbkZ42U 9HOHhnzDVP1maN3fQ9JAjvq7j36cQ+UHSgMh06Z99o+fzZGLpM/Dvbw5+St5R0Fyj5fBeRQTp hrWeoQO64NWN6HD/78Vbd/l++C80khBP9LF5GM7YTDmystDxiBGByBp1lWVkpmgUjm+I=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/r8sl_NOi5wHu2QSPPgCduD5M7EQ>
Subject: [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: Sat, 25 Jul 2015 12:46:50 -0000

Hi,

Here’s my review of the draft.

Cheers,
Ian

Please note - I’m going to be on holiday for the next couple of weeks so if I am slow in responding to any replies, then this is why.

-----------

These comments are in addition to the one that I have raised in the mail thread https://mailarchive.ietf.org/arch/msg/mif/3LQ6W1kj7nwOIvI_KGfbKoyOkCs
Depending on the outcome of this discussion, other changes to this document may be necessary.


Section 3

a) Which NDP messages can include this option? RA and RS messages are mentioned, but is it envisaged
that e.g. a host may make an NS request which contains the PVD_ID option, in order to 
find other hosts which are configured for the same PVD? My feeling is that in this document
and at this stage of the development, they should be restricted to RS with requested PvDs
and RAs with advertised PvD NDP messages only.


b) I’m not clear on what the intended solicitation process for a host requesting information for a specific PvD. 
The behaviour seems to be that in an RA, a client includes a list of the PVD_ID options which it is interested in receiving.

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)?

c) Para 2
The PVD container MUST NOT be fragmented"
RFC6980 prevents NDP messages from being fragmented at all, so perhaps this should be 
referenced?
Would it also help to describe how to correctly handle this situation (i.e. send two RAs with
un-fragmented PvD containers)


Section 5
"The PVD container option MAY be used to encapsulate any allocated IPv6 NDP options, which may appear more than once in a NDP message."

Ambiguous text - Is the intention to say that the PVD container, or the encapsulated options may appear more than once in the NDP message?
If it is the encapsulated options, then the sentence restricts the allowable options to only those options which can appear more than once
(i.e. an option which can only appear once can not be encapsulated). I guess that this is not the intention.


Section 6
Per PVD certificates/sigs sound like they are going to cause problems with the NDP message length.
In the appendix of RFC6980, there’s some information about message sizes when carrying 
certificates. 864 bytes is given as the smallest size for the certificate itself (1024 bytes), so for a 1280 v6 MTU, 
2 and you’re bust.





Language / grammar nits etc.

Throughout: s/a NDP/an NDP
Reason: With acronyms, ‘a’ or ‘an’ before a consonant/vowel is chosen based on the sound of the letter when spoken (i.e. ’n’ is pronounced ‘en’)

Section 1
Old
This document describes an IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] mechanism for explicitly indicating
provisioning domain information along with any configuration that will be provided.

New
This document describes an IPv6 Neighbor Discovery Protocol (NDP) [RFC4861] mechanism for explicitly indicating
provisioning domain information along with any configuration which is associated with that provisioning domain.

Reason: new wording more clearly associates the configuration with the PVD it is being provisioned for.

Section 3
Old:
Implementations that do not recognize  the PVD container option plain ignore it and also skip PVD container
option "encapsulated" NDP options normally without associating them into any provisioning domain (since the
implementation has no notion of provisioning domains).

New:
Implementations that do not recognize the PVD container option will ignore it, and any PVD container
option "encapsulated" NDP options without associating them into any provisioning domain (since the
implementation has no notion of provisioning domains).

Reason: Old version reads a little ‘colloquially’ :-)

Old:
certificates needed to sign PVD containers) belong

New:
 
certificates needed to sign PVD containers belong

Reason: ) with no corresponding (


Old:
the length of the PVD identifier option and the optional Key Hash/Digital Signature/Padding.

New:
the length of the PVD identifier option, and the optional Key Hash/Digital Signature/Padding.

Reason: Oxford comma. Might as well put it in now and save the editor the job.

Section 4
Old: …  the natural NDP options’ alignment.

New: ... the natural NDP option’s alignment.

Reason: Option is singular and doesn’t end with an ’s'

Section 5
Old:
If the receiver of the PVD identity option does not understand any of the ID-Types,
then anything belonging to this provisioning domain  MUST be silently discarded.  
This would mean the PVD identity option, the PVD container option and all other options.
 
New: 
If the receiver of a PVD identity option does not have one (or more) of the received
ID-Type format’s implemented, then all configuration and options which are associated with
the unimplemented PvD(s) MUST be silently discarded.

Reason: Original wording could be mis-interpreted to mean that the entire NDP message, including
options associated with implemented ID-types must be discarded


Section 7
Old: The options TBD1 and TBD2 are described in Section 3 and Section 4

New: Options TBD1 and TBD2 are described in Section 3 and Section 4 respectively.

Reason: Clarity