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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 17 Nov 2015 19:39:47 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-homenet-hncp-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

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

-7.4, 2nd paragraph:
The MUST seems to conflict with the SHOULD in the third paragraph of
section 8.

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

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

- 5.1:"Internal category":"HNCP traffic MUST be sent and received."
What must send and receive it? (Similar comments for External Category).

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

- 14.3:
Looks like neither URL will be cited once the RFC editor removes the
appendices marked for deletion.

---

From: Steven Barth <[email-masked]>
Date: Wed, 18 Nov 2015 16:02:03 +0100

Hello Ben,

thanks for the review.

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.

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

> The MUST seems to conflict with the SHOULD in the third paragraph of

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.

> definition, or are otherwise required to fully understand this draft:

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

> Editorial Comments:
Yes, clarified.

> What must send and receive it? (Similar comments for External Category).
Changed to "The interface MUST (NOT) operate as a DNCP endpoint"

> Please expand "ULA" on first mention.
Done.

> The scheme SHOULD NOT be used unless in conjunction...
Staged for next revision.

> 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

Cheers,

Steven

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 18 Nov 2015 16:06:40 -0600

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:

[...]
> I can't really remember the argument for or against either but I will

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.

> thus will never be elected and never be subject to the MUST in 7.4. 

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?

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 20 Nov 2015 09:30:15 +0200

> I can't really remember the argument for or against either but I will

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

> for removal somehow. Otherwise we probably need to manually modify the

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 20 Nov 2015 10:47:30 +0100

> I am not fine with SHOULD for IPv4 as it will essentially break it;

Agreed, but I don't feel strongly about it.

> I can live with MUST for IPv6 but consider it unneccessary.

Agreed, announcing your IPv6 address, if it's chosen randomly, just wastes
24 bytes * prefixes * nodes * interfaces.  That's 2.4kB of uselessly
flooded data in a mere 10 node network with two prefixes.  (Recall that
HNCP doesn't have link-local signalling or delayed flooding -- anything
that's announced must be flooded throughout the network in a timely manner.)

-- Juliusz

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 20 Nov 2015 09:03:26 -0600

On 20 Nov 2015, at 1:30, Markus Stenberg wrote:

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

Your answer makes perfect sense. My wishful thinking was just wishful.

Ben.

[...]