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

"Ben Campbell" <ben@nostrum.com> Wed, 18 November 2015 22:06 UTC

Return-Path: <ben@nostrum.com>
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 061641B305A; Wed, 18 Nov 2015 14:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] 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 prG9H5MoO5-y; Wed, 18 Nov 2015 14:06:43 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 774121B3050; Wed, 18 Nov 2015 14:06:42 -0800 (PST)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tAIM6elK017527 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 Nov 2015 16:06:41 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: "Ben Campbell" <ben@nostrum.com>
To: "Steven Barth" <cyrus@openwrt.org>
Date: Wed, 18 Nov 2015 16:06:40 -0600
Message-ID: <372D8EF8-50E8-44B3-AF6E-33290A0BC4C1@nostrum.com>
In-Reply-To: <564C92EB.8020003@openwrt.org>
References: <20151118033947.24577.54396.idtracker@ietfa.amsl.com> <564C92EB.8020003@openwrt.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.3r5164)
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/E6iYH3Av6Jeslh_68Ym0CRDdYME>
Cc: homenet-chairs@ietf.org, homenet@ietf.org, mark@townsley.net, The IESG <iesg@ietf.org>, draft-ietf-homenet-hncp@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: Wed, 18 Nov 2015 22:06:47 -0000

Thanks! A couple of remaining comments below. I removed sections that 
don't seem to need further discussion.

Ben.

On 18 Nov 2015, at 9:02, Steven Barth 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 was really wishful thinking on my part. I don't expect a change. I 
was mainly reacting to IPv4 being a MUST and IPv6 not.  OTOH, I'd be 
equally happy if neither were MUSTSs.

>
>
>> -7.4, 2nd paragraph:
>> The MUST seems to conflict with the SHOULD in the third paragraph of
>> section 8.
>
> That conflict is ruled out by the MUST in 10.1
> It MUST be set to some value between 1 and 7
> included (4 is the default) if the router is capable of proxying
> MDNS and 0 otherwise.
>
> and the election mechanism. If it doesn't support an MDNS proxy
> (disobeying the SHOULD) it MUST announce its mdns-capability as 0 and
> thus will never be elected and never be subject to the MUST in 7.4. 
> 2nd
> paragraph.

IIUC, a router that doesn't support MDNS will never be elected. So is 
the statement in 7.4 that an elected router MUST support MDNS 
constraining in any way?