Hi Paul, I am doing the follow-up and would like to check if there are any specific questions regarding the current version of the document.
Yours, Daniel On Mon, Oct 31, 2022 at 10:34 PM Daniel Migault <mglt.i...@gmail.com> wrote: > Ray implemented the front end naming architecture but I am unaware if > there is any link to an open source implementation. > > I am unable to figure out what you believe is out of scope of the document > (or not), as gaps you believe are under specified. If stated explicitly we > will be able to address those or clarify them. I propose you start > mentioning what you believe are unspecified gaps that could lead to > interoperability issues. As you mentioned earlier you can start with one. > > Note that the current version 22 has been published today with all > addressable concerns: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > Yours, > Daniel > > On Mon, Oct 31, 2022 at 5:56 PM Paul Wouters <paul.wout...@aiven.io> > wrote: > >> On Oct 31, 2022, at 09:39, Daniel Migault <mglt.i...@gmail.com> wrote: >> >> >> >> Hi Paul, >> >> This is just a follow-up regarding the remaining concerns that need to be >> solved. Does Michael's response address your questions, if not please >> let us know what remains unclear as well as what other clarification is >> needed. >> >> >> It does clarify some of the process, but sadly adds more to the “this >> part is out of scope of this document”, still resulting in unspecified gaps >> in the solution that this document claims to facilitate. >> >> Has anyone implemented this? Maybe a reference opensource one that could >> help my understanding ? >> >> Paul >> >> >> >> >> Yours, >> Daniel >> >> On Tue, Oct 25, 2022 at 8:08 AM Michael Richardson <mcr+i...@sandelman.ca> >> wrote: >> >>> >>> Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org> wrote: >>> > These two sentences I think show the core of my lack of >>> understanding. >>> > Let's say I want to put my sauna on my public home net so I can >>> access it >>> > remotely and turn it on before I get home? >>> >>> > Is this envisioned as a goal of the homenet architecture? >>> >>> You say, "homenet architecture", but our document is not the homenet >>> architecture. >>> It's about the homenet naming architecture, and I'm sorry to be >>> pedantic, but >>> the subtle difference includes a whole bunch of possible sins. >>> I have no idea if your sauna can be remotely controlled, or if if your >>> home >>> router will let the traffic through, and it's not the job of this >>> document to >>> standardize either of those things. >>> >>> So, let's take a simpler version of this: >>> >>> Your sauna can connect to an IRC server to tell you about it's >>> temperature, >>> and the number of people currently in it. But, IRC being what it is, it >>> would like to have a valid reverse name, and for that reverse name to >>> match >>> the forward name before it will let you in. >>> >>> > Is it envisioned that this would be done by talking to the device, >>> using a >>> > name served by the "homenet public zone" ? >>> >>> No, your sauna would not be involved at all. >>> >>> > If so, can I determine the name of this zone, or is it only CPE >>> > auto-generated? >>> >>> You would inform your CPE to please publish the IP address of your sauna >>> under a name that you decide. How your CPE does this is not the concern >>> of >>> the specification, but here are some ideas: >>> * CPE identifies your sauna by MAC address, publishes the IPv6 that >>> the NCE >>> says is associated with it. >>> * CPE identifies your sauna by mDNS name >>> * you have told your CPE to give the sauna a specific IPv6 via DHCPv6, >>> and >>> it publishes that >>> * something else >>> >>> > If I can determine the name, I am confused how this all would hook >>> into >>> > existing DNS infrastructure. It could be in my personal subdomain, >>> a custom >>> > generic domain in .com ? >>> >>> You could have obtained a domain, yes, perhaps in .com, for your CPE. >>> "paulshome.nohat.ca" if you desire. >>> >>> We suggest, non-normatively in Appendix C of a JSON blob that could be >>> copy >>> and pasted from your domain provider/DOI to your CPE in order to >>> configure >>> everything. We imagine flows where this actually all happens via >>> browser/OAUTH2 >>> flow, but that's not a normative part of the specification. >>> >>> Your CPE could have been provisioned with a name (probably ugly) by the >>> maker >>> of the CPE device. I have been involved in two proofs of concept for >>> this. >>> The ISP that provided the CPE to you, or some other party that sold you >>> service. >>> >>> > Then we get to my sauna device. It calls itself "tylo". How does >>> this end >>> > up as a FQDN in the homenet public zone ? How does my home end up >>> being >>> > able to query for it? >>> > How do the queries go when not at home? >>> >>> All of this is really in the document. >>> 1) How your CPE publishes the name tylo is up to the CPE. >>> >>> 2) the CPE is authoriative for the homenet public zone >>> >>> 3) the CPE tells the Domain Outsourcing Infrastructure (DOI) about the >>> localtion of the zone, and the DOI does a DoX to transfer it. The DOI >>> has some resilient infrastructure to publish things. Whether it's >>> ns1/ns2 on different subnets, or some multi-continent anycast system >>> depends upon what you pay. >>> >>> 4) when you aren't at home, the queries go to the ns1/ns2 that the DNS >>> has published. >>> >>> 5) When you are at home, we expect the CPE to answer authoritatively >>> itself. A well designed CPE would have cached the DS/NS/DNSKEY that >>> leads >>> to it's domain so that it can answer a secure chain even when the >>> Internet >>> connection is broken. >>> >>> > So I am guessing. The only known method for hostnames publishing >>> their >>> > names into a zone I know of is with Dynamic Updates on a local >>> zone. But >>> > perhaps what homenet >>> > envisions is that I give my sauna a static IP and configure some >>> webgui on >>> > my CPE to add it to my "zone" ? >>> >>> No, and the document explains why this is a non-starter. >>> >>> >>> -- >>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works >>> -= IPv6 IoT consulting =- >>> >>> >>> >>> >> >> -- >> Daniel Migault >> Ericsson >> >> > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
