Re: [homenet] Ben Campbell's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

Markus Stenberg <markus.stenberg@iki.fi> Fri, 20 November 2015 07:30 UTC

Return-Path: <markus.stenberg@iki.fi>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DF51A898B; Thu, 19 Nov 2015 23:30:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 amin5CeT4cSV; Thu, 19 Nov 2015 23:30:29 -0800 (PST)
Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.231]) by ietfa.amsl.com (Postfix) with ESMTP id 975E51A8989; Thu, 19 Nov 2015 23:30:28 -0800 (PST)
Received: from poro.lan (80.220.86.47) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 5613C7B101389E12; Fri, 20 Nov 2015 09:28:36 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <564C92EB.8020003@openwrt.org>
Date: Fri, 20 Nov 2015 09:30:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0006AA88-EBFD-4EE4-B8F0-212ABE730FBF@iki.fi>
References: <20151118033947.24577.54396.idtracker@ietfa.amsl.com> <564C92EB.8020003@openwrt.org>
To: Steven Barth <cyrus@openwrt.org>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/US1HOeiXjkIbnSXyJhHjC643OIw>
Cc: homenet-chairs@ietf.org, Ben Campbell <ben@nostrum.com>, Mark Townsley <mark@townsley.net>, draft-ietf-homenet-hncp@ietf.org, The IESG <iesg@ietf.org>, HOMENET <homenet@ietf.org>
Subject: Re: [homenet] Ben Campbell's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2015 07:30:31 -0000

On 18.11.2015, at 17.02, Steven Barth <cyrus@openwrt.org> wrote:
>> -6.4, first paragraph: "Each HNCP node SHOULD announce an IPv6 address
>> and - if it supports IPv4 - MUST announce an IPv4 address,"
>> I don't suppose there's any way we can make IPv6 a MUST?
> I guess we could unify both and make them both SHOULD or MUST. Right now
> I can't really remember the argument for or against either but I will
> discuss it with Markus.

This current MUST + SHOULD is actually result of developments during summer (not sure if it was this summer, but I suspect so). Note that it does NOT say that you MUST assign IPv4 and SHOULD assign IPv6; it talkes entirely about announcing the said assignment. The assignment is also used for conflict resolution, but (at the time) the people who discussed these noted that RFC7217 is unlikely to conflict, and therefore announcing the assignments is nice to have, but not mandatory (and you could also use e.g. DAD if you really wanted to as this is simply local state on a link). In case of IPv4, where we essentially pick out of /26, 1 in 64 chance of collision (1 in ~8 due to birthday paradox) was not considered as good odds and therefore it was made a MUST; there is no IPv4 DAD as fallback either.

I am not fine with SHOULD for IPv4 as it will essentially break it; I can live with MUST for IPv6 but consider it unneccessary. Let me know how you feel about it (or if we should add the justification text to the document).

>> - 14.3:
>> Looks like neither URL will be cited once the RFC editor removes the
>> appendices marked for deletion.
> Okay, will try to see if we can convince xml2rfc to mark this section
> for removal somehow. Otherwise we probably need to manually modify the
> .txt

I removed erefs and just left the URLs in place in the appendix. As it is to be removed soon anyway, little worse formatting won’t hurt. (staged for -13)

Cheers,

-Markus