Re: [Iotops] Automatically connecting to stub networks...

[Ted Lemon <[e-mail]>]

On Dec 3, 2020, at 12:49 PM, Toerless Eckert <[e-mail]> wrote:
> What's a CBDA ? Is that a badge of honor to wear ? I have a Van-o-Gram from the
> 1990'th. Maybe i can upgrade by breast plating with a CBDA ? What do i need to do to get one ?

It’s me being a jerk. Sorry about that.

> Back to business.  Some high level suggestions for your doc:
> 
> - Move your rants about HNCP to an appendix

They aren’t rants. There is no deployable HNCP. HNCP was the first solution we thought of, and was my original preference for a solution, but it isn’t a solution for the reasons stated. That’s part of the problem statement. If you have specific text that you think is a rant, and not a problem statement, please propose changes.

> - Maybe also the rant about service discovery being an integral part of the problem to an appendix.
>  although i agree that a good part of the IETF community may not have gotten the message how it is,
>  but its still disturbing the flow of reading when preaching to the choir like me.

In what sense is this a rant? How do you discover hosts on the stub network without some kind of service discovery protocol? How do hosts on the stub network discover services on the infrastructure network? Consider this: is your internet connection useful if DNS is not available? (I mean _really_ not available, not just that you didn’t get the IP address of a resolver from your ISP).

> - Put IPv6 into the title if all you care about is really only IPv6.
>  Before this gets adopted by a WG, native support for also IPv4 should be a key scope discussion.
>  Not everybody may have the same IP6 centric only business goal.
>  (I Have No Opinion. Just saying).

I don’t know of a way to solve this with IPv4 without HNCP or something like it. That is, there’s no automatic mechanism that we could use in IPv4 that’s similar to what’s available in IPv6.

> - It would be nice to start section 2 with a description of a generic model
>  without being specific to the protocol so one can check if/what protocol options
>  do meet the model - as opposed to only the two ones you think are in your interest.

Fair point.

> - For example: Why not simply start with DHCP-PD ? IMHO, every home router getting
>  a prefix via DHCP-PD from a service provider is a provider of such a stub network.
>  Of course, service discovery as you expect does usually not work in that environment,
>  so that would need to be added.

We didn’t start with DHCPv6-PD because we needed something that will work in any network, not just in networks where DHCPv6-PD is present.

> - Would be lovely to detail exaple use-cases such as that Apple device (e.g.: in an appendix)
>  to provide better motivation and also justification for the proposed protocol choices…


That sounds like a good idea. When I submitted the draft, this wasn’t an option because the product hadn’t yet been announced… :)

Thanks for the review and feedback. Sorry about being a jerk, and please let me know if there’s specific text that feels like it’s a rant.