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

[Ben Campbell]

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


On 18.11.2015, at 17.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 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.

[...]

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Juliusz Chroboczek]

> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Steven Barth]

Hello Ben,

thanks for the review.


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

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


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

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



Cheers,

Steven

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ben Campbell]

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?


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet