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

Steven Barth <> Wed, 18 November 2015 15:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 62EA41B323E; Wed, 18 Nov 2015 07:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_FAIL=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jiSxmgfUxEL3; Wed, 18 Nov 2015 07:02:08 -0800 (PST)
Received: from ( [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFE891B323A; Wed, 18 Nov 2015 07:02:07 -0800 (PST)
Received: from localhost ([]) by id 1Zz4FH-0000Mp-UL with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Wed, 18 Nov 2015 16:02:04 +0100
To: Ben Campbell <>, The IESG <>
References: <>
From: Steven Barth <>
Message-ID: <>
Date: Wed, 18 Nov 2015 16:02:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Icedove/40.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [homenet] Ben Campbell's No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Nov 2015 15:02:09 -0000

Hello Ben,

thanks for the review.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Minor Issues:
> ===========
> -4, 1st paragraph, last sentence:
> I confused by the fact this sentence says nodes MUST include
> HNCP-Version, then goes on to talk about nodes _not_ including it.

I added a note that the presence of the TLV indicates the support for
the currently defined HNCP version. The idea is that in case there are
other DNCP nodes that speak a different HNCP version their information
is still spread in the DNCP sense, but not interpreted.

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

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

> -14.2:
> It looks like some, maybe most, of the informative references  need to be
> normative. They are cited with 2119 language,  cited in other protocol
> definition, or are otherwise required to fully understand this draft:
> 3004, 2131, 3315, 3633, 4291, 1321, 6762, 6763, 2132, 4193, 7084, 7217,
> 4861, and 6092.

Ok we will reevaluate the references in the coming days and see which of
those should be promoted.

> Editorial Comments:
> =================
> -4, 2nd paragraph: "Any node announcing the value 0 is considered to not
> advertise the respective capability and thus does not take part in the
> respective election."
> Am I correct to assume this means "any node announcing the value 0 for a
> particular capability..."?
Yes, clarified.

> - 5.1:"Internal category":"HNCP traffic MUST be sent and received."
> What must send and receive it? (Similar comments for External Category).
Changed to "The interface MUST (NOT) operate as a DNCP endpoint"

> -6.5:
> Please expand "ULA" on first mention.

> - 9, 1st paragraph: "The scheme SHOULD be used only in conjunction"
> "SHOULD ... only" is a subtle way of saying SHOULD NOT. I suggest the
> following:
> OLD:
> The scheme SHOULD be used only in conjunction...
> NEW:
> The scheme SHOULD NOT be used unless in conjunction...
Staged for next revision.

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