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

[Toerless Eckert <[e-mail]>]

On Thu, Dec 03, 2020 at 01:31:57PM -0500, Ted Lemon wrote:
> > Back to business.  Some high level suggestions for your doc:
> > 
> > - Move your rants about HNCP to an appendix
> 
> They aren???t rants.

I was just referring to the style, not payload
 "long passionate explanation, i am sure was given repeatedly already" ;-)).

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

I probably don't disagree with whats said in the text, except that i am
only aware of all the discussion and alternatives back when it was designed,
but i lost track for the past few years,so i'd need to upgrade my current
status before i could say i fully agree. Just don't make it disturb the
flow and move it down into some appendix or the like.

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

IMHO, its a rant because everybody should know and agree.
And explanations for those not in the know should be in an appendix.

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

To pick on on HNCP for example: The generic part could raise requirements, e.e.:


     Clients ---infra-network---- infra-router [A]

     Clients ----stub-network ---stub-router --- (new)-signaling --- infra-router [B]
                                                 infra-network

Goal of the document (IMHO) would be to:

a) make stub-network in [B] perform as much as possible equally to  infra-network in [A]
   ideally no changes. Of course,we'd need to define infra-network accordingly to
   support all required functions. Such as DNS-SD.

b) focus on defining the information elements on the [B] infra elements between
   infra-router and stub-router, so that stub-router can create  stub network.

b) is IMHO fundamental, because it would allow for supporters of protocols, let's say
HNCP that is not considered in this draf to equally build their own extension draft
also implementing the information elements from b) in a separate draft.

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

Given how seemingly new signaling extensions are required, the question is
what protocol is the best basis to extend, and DHCPv6 with PD seems like a good
basis. I understand how there are religious DHCP lower and haters though,
but from past work with SPs, i just know a lot of things DHCP can much more
nicely do than just RA. for example transparently passing through additional
DHCP options from the infra router through the stub-router to the clients.
So in doubt count me in as weak DHCP lover...

Of course, if the information elements are embodied into DHCP, then it is of course
also much easier to support IPv4 natively.

> > - 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. I am always motivated by real world data/needs.

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

I am sure carsten isn't worried and i do appreciate to have folks (such as him) in the community that help to improve our technologies for their field of expertise, even if that turns out to be a pain in unnamed body parts. Wouldn't want security folks to have a monopoloy on that role.

Wrt. "rant", consider it to be term of friendly stylistic nitpicking..

Cheers
    Toerless


-- 
---
[e-mail]