Subject: [homenet] draft-ietf-homenet-hncp-06 now in WGLC

From: Ray Bellis <[email-masked]>
Date: Tue, 23 Jun 2015 10:26:11 +0100

This email marks the commencement of a three-week Working Group Last
Call for draft-ietf-homenet-hncp.

Please get any final comments in to the authors (cc: the WG) as soon as
possible.

thanks,

Ray and Mark

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 30 Jun 2015 14:41:55 +0200 (CEST)

> Please get any final comments in to the authors (cc: the WG) as soon as

If I understand correctly, work is now ongoing to create a separate 
implementation of HNCP? This would be a good step to address my concern I 
have voiced privately to the authors that not enough people have gone 
through the document. I also find them hard to read (some parts have been 
changed after I gave this feedback) and it uses terminology that might 
benefit from further explanation and/or making examples what they mean. 
For instance, the section about "common link" (section 4). Upon reading 
this, I think I understand that this applies to for instance a shared 
ethernet segment where both can see each others HNCP packets. Having an 
example here about why things are done, what problems are solved etc, 
would probably make it easier to understand rationale for the choices.

6.2.4 "create an on-link route"? What's an on-link route? Also, why is it 
a "MAY" that it doesn't create an address for itself to this prefix? An 
explanation and rationale here would be good.

6.2.6 The list of things to do there isn't clear to me. "wait for them to 
be applied"? Applied where? How? Using the HCNP Prefix Assignment 
Algorithm? In the RIB? It implies HNCP Prefix Assignment Algo afterwards, 
but this isn't clear to me.

Section 11 about the MUST for RFC7084 compliance. What parts of RFC7084 
must be implemented? MUSTs? SHOULDs?

I personally think this WGLC is premature. I will not oppose it going 
forward, but I have concerns that the document(s) isn't ready for shipping 
off as RFCs yet due to not enough people having read them.

So I think I am basically saying that the documents are probably correct, 
but there is still very valuable information still only in the heads of 
the implementors that has not been written down in the document, that 
would be valuable to have in there and that would also help future 
implementors who might be reading the document trying to understand what's 
going on, why things are done the way they are, etc.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 30 Jun 2015 16:08:47 +0200

> implementation of HNCP?

It's just a private hack, but might end up being useful.  The initial plan
was to spend a week-end explaining DNCP to myself, but the week-end has
now become four days.

I'm doing full DNCP right now (with keepalives, without unicast endpoints,
and omitting one micro-optimisation that I happen to disagree with), and
just enough HNCP to get hnetd to speak to me.  1500 LOC, not counting MD5.

> This would be a good step to address my concern I have voiced privately
> to the authors that not enough people have gone through the document.

Yes, it would have been a good thing if some large private-sector actor
with an interest in home networking had sponsored an independent
reimplementation before the DNCP WGLC.

> I personally think this WGLC is premature.

I'm actually more concerned by DNCP.  HNCP is extensible -- if we get it
wrong, we can deprecate some TLVs and add new ones without breaking
compatibility.

Not so DNCP -- DNCP requires precise state synchronisation, so any trivial
change is likely to require a whole new protocol.  Plus there's no version
number in DNCP, so the only way to evolve it is to pick a new port
(picking a new multicast group will not be enough in case clients want to
participate in both variants).

I've got a large list of DNCP issues, which I'll probably be able to write
up today or tomorrow.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 30 Jun 2015 18:16:17 +0300

On 30.6.2015 15.41, Mikael Abrahamsson wrote:
> implementation of HNCP? This would be a good step to address my concern
> I have voiced privately to the authors that not enough people have gone
> through the document. I also find them hard to read (some parts have
> been changed after I gave this feedback) and it uses terminology that
> might benefit from further explanation and/or making examples what they
> mean. For instance, the section about "common link" (section 4). Upon
> reading this, I think I understand that this applies to for instance a
> shared ethernet segment where both can see each others HNCP packets.
> Having an example here about why things are done, what problems are
> solved etc, would probably make it easier to understand rationale for
> the choices.
>
> 6.2.4 "create an on-link route"? What's an on-link route? Also, why is
> it a "MAY" that it doesn't create an address for itself to this prefix?
> An explanation and rationale here would be good.
>
> 6.2.6 The list of things to do there isn't clear to me. "wait for them
> to be applied"? Applied where? How? Using the HCNP Prefix Assignment
> Algorithm? In the RIB? It implies HNCP Prefix Assignment Algo
> afterwards, but this isn't clear to me.
>

First of all, thanks for the feedback on the content (again).

> forward, but I have concerns that the document(s) isn't ready for
> shipping off as RFCs yet due to not enough people having read them.
>
> So I think I am basically saying that the documents are probably
> correct, but there is still very valuable information still only in the
> heads of the implementors that has not been written down in the
> document, that would be valuable to have in there and that would also
> help future implementors who might be reading the document trying to
> understand what's going on, why things are done the way they are, etc.

IETF tradition is that without WGLC or other implemenation efforts, 
there is not much action either. HNCP document is already soon 1.5 years 
old and the number of reviews is not _that_ great outside the main 
implementation crew.

Hopefully Juliusz will give us feedback on his results ASAP, and 
obviously any other reviews are welcome.

Cheers,

-Markus

---

From: Dave Taht <[email-masked]>
Date: Tue, 30 Jun 2015 08:22:15 -0700

My request was more dogfooding. a *lot* more dogfooding.

On Tue, Jun 30, 2015 at 8:16 AM, Markus Stenberg <[email-masked]> wrote:
> IETF tradition is that without WGLC or other implemenation efforts, there is
> not much action either. HNCP document is already soon 1.5 years old and the
> number of reviews is not _that_ great outside the main implementation crew.
>
> Hopefully Juliusz will give us feedback on his results ASAP, and obviously
> any other reviews are welcome.
>
> Cheers,
>
> -Markus
>
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

---

From: Steven Barth <[email-masked]>
Date: Tue, 30 Jun 2015 17:55:03 +0200

Hello Mikael,

thanks for your continuous feedback.

Am 30.06.2015 um 14:41 schrieb Mikael Abrahamsson:
> 6.2.4 "create an on-link route"? What's an on-link route? Also, why is it a "MAY" that it doesn't create an address for itself to this prefix? An explanation and rationale here would be good.
> 
> 6.2.6 The list of things to do there isn't clear to me. "wait for them to be applied"? Applied where? How? Using the HCNP Prefix Assignment Algorithm? In the RIB? It implies HNCP Prefix Assignment Algo afterwards, but this isn't clear to me.
> 
> Section 11 about the MUST for RFC7084 compliance. What parts of RFC7084 must be implemented? MUSTs? SHOULDs?

I just pushed an update to our drafts repository which should hopefully address your comments.
Please see https://github.com/fingon/ietf-drafts/compare/c82f52d...c9f5b57 and let us know if you have any further issues.

Thanks,

Steven

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 1 Jul 2015 08:56:17 +0200 (CEST)

> Please see https://github.com/fingon/ietf-drafts/compare/c82f52d...c9f5b57 and let us know if you have any further issues.

Thanks, yes, that's better.

Hm, regarding section 11, requirements for HNCP routers. How is that size 
hint calculated? Also, other kinds of behaviours like null-routing the 
delegated PD to avoid ping-pong routing when you receive packets for 
subnets currently not in use in the delegated prefix, where is that 
specified?