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

Jouni Korhonen <jouni.nospam@gmail.com> Tue, 18 August 2015 18:13 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 887651A904F for <mif@ietfa.amsl.com>; Tue, 18 Aug 2015 11:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 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, GB_I_LETTER=-2, 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 ik_SEnEmFtk9 for <mif@ietfa.amsl.com>; Tue, 18 Aug 2015 11:13:57 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 33E5F1A9051 for <mif@ietf.org>; Tue, 18 Aug 2015 11:13:56 -0700 (PDT)
Received: by pabyb7 with SMTP id yb7so137889662pab.0 for <mif@ietf.org>; Tue, 18 Aug 2015 11:13:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=hdu8yOAHY7m25LJ3xalZzW039hX9Uh2uzhDhEoWw7j8=; b=HaOzLqdh18a0XvZUKaSJqCMe/Roi6CLtFNXTrnhvI1ylOevZi17C3JcD2xKxebp+uM iyrHnPLwozkwxzUd+Meetb2Wt9CeSVb9cjZ7TJNuxT581F6zLS/utXzp/pX5DP5iPq/U u+pe/OeFJF9CpRlBW/DZ+yWYd8tBcCITWLjJ1rRVQb+fFaMkP/vVfXIKiQCr4KNoeI3H 1VAEVEKH/bWIMe3nMTOmQYQg7ykC98nBVTqY3skIHcOzSirw/K1HknHnuueXD7+FQt7Z pLTCymsbh4xOUtGLy7zOEdcYAf9LPQhfypb/IzXKdAWKobzdJF0XZijEXiVuwNkEMmlz vbbA==
X-Received: by 10.66.141.141 with SMTP id ro13mr16105863pab.68.1439921635895; Tue, 18 Aug 2015 11:13:55 -0700 (PDT)
Received: from ?IPv6:2601:647:4204:228b:d5a2:2855:8297:4b1c? ([2601:647:4204:228b:d5a2:2855:8297:4b1c]) by smtp.googlemail.com with ESMTPSA id ay10sm18822657pbd.13.2015.08.18.11.13.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Aug 2015 11:13:54 -0700 (PDT)
To: Ian Farrer <ianfarrer@gmx.com>, mif@ietf.org
References: <66E246E2-0217-4410-BE8D-64A8F55B8E29@gmx.com>
From: Jouni Korhonen <jouni.nospam@gmail.com>
Message-ID: <55D375E1.6050707@gmail.com>
Date: Tue, 18 Aug 2015 11:13:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <66E246E2-0217-4410-BE8D-64A8F55B8E29@gmx.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/ABHDqdlP12RaJ_1zZXA9ni5876c>
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: Tue, 18 Aug 2015 18:13:59 -0000

Ian,

Thanks for a detailed review! See my initial comments inline.

7/25/2015, 5:46 AM, Ian Farrer kirjoitti:
> 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.

Same here.. back now ;-)

>
> -----------
>
> 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.

RA and RS are what were in my mind.. I will clarify this and limit the 
PDVs to RA/RS 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.

You probably mean RS not RA?  One of the ideas was to allow "clever" 
unicast RA type of PVD information delivery.. i.e. the router would 
typically advertise just the normal stuff that would go under implicit 
PVD. Once some end host solicits for a specific PVD or PVDs that 
information could be unicasted to that specific end host.

>
> 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.

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

Fragmentation part is outdated and has to be done according to RFC6980.

>
>
> 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.

I'll revise the text. Did you check Appendix A.1? It shows what is meant 
with this. For example, it is OK one RA to contain PIOs inside and 
outside the container. Also, if the RA has multiple containers same NDP 
options (like PIO) can be used in every of those.

>
> 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.

There is no need to carry certificates around. The key hash in the 
container is there for to purpose of locating a proper public key for 
verification. How you learn the public key / certificate is outside this 
specification.


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

Ack.

>
> 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.

Ack.

>
> 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’ :-)

Ack.

>
> Old:
> certificates needed to sign PVD containers) belong
>
> New:
>
> certificates needed to sign PVD containers belong
>
> Reason: ) with no corresponding (

Ack.

>
>
> 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.

Ack ;-)

>
> 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'

Ack.

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

Ack.

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

Ack.

Thanks a lot,
	Jouni


>
>
>
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>