Re: [homenet] [DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6
Some time back Tony Finch proposed a 2317bis - https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2317bis-00 which the WG adopted but died for lack of interest. It would be useful to revise this document tim On Thu, Dec 8, 2022 at 5:14 AM Havard Eidnes wrote: > > Hi, while editing draft-ietf-homenet-front-end-naming-delegation, it > occured > > to me that the automatic reverse that > > draft-ietf-homenet-naming-architecture-dhc-options could enable > > better/simpler RFC2317 delegation for IPv4 subnets. > > > > My experience is that some of the pushback for doing 2317 is that there > is > > sane way to automate it, and too many confusing ways to do it. > > > > So, I wrote: > > > https://datatracker.ietf.org/doc/draft-richardson-ipv4-reverse-in-v6/ > > > > which basically says to point the CNAMEs into the IPv6 delegation that is > > "already" (will have been) being done. > > The actual convention to use isn't really specified by 2317, only > a few examples are given. This one should work just as well as > any other convention, and if this makes it easier to use, I'm all > for it. > > Best regards, > > - Håvard > > ___ > DNSOP mailing list > dn...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-19
Reviewer: Tim Wicinski Review result: Ready Hi As one of the assigned reviewers of this document for DNS Directorate for this draft. I have read the other DNS Directorate reviews for this draft, and I agree with how the comments raised are being addressed.I do appreciate the examples in the appendix. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [dnsdir] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18
On Thu, Oct 13, 2022 at 9:48 AM Michael Richardson via dnsdir < dns...@ietf.org> wrote: > > as> Reviewer: Anthony Somerset > as> Review result: Ready with Nits > > as> Section 3.2 = "SHOULD remain pointing at the cloud provider's > server IP address > as> - which in many cases will be an anycast addresses." > > as> I don't believe its correct to include this assumption about > anycast addresses > as> and is largely irrelevant to the content of the draft so i don't > believe there > as> is value in keeping the text after the hyphen > > I see your point. > I feel that there is some relevance to pointing this out. > > One of important aspect of reminding people about this is to indicate that > it > should be surprising if queries to these addresses actually return > different > time views of the zone. It can take some minutes for all anycast hosts to > update. > > A second important aspect is that the address that queries go to is not, > because of anycast, the same as the place where the updates go. > > I don't feel strongly about this, I just think that we wrote this down for > a reason. > > > The intro is very long and talks about things that don't get > explained until > > much later in document and could cause some confusion, it may be > better to make > > the intro more concise and move some of these aspects into the > relevant > > sections. > > It grew as a result of reviews. > you are saying we overshot, sure. > > > Section 1.2 - to me this would flow better if it was its own section > after the > > solution is explained > > okay. > > To second Anthony's comment about the Introduction being long I have to concur. The first part of the Introduction nicely lays out the document. Could you do this: Introduction Terminology Selecting Names to Publish Dynamic DNS Alternative solutions Envisioned deployment scenarios Each of these sections seem solid enough to stand on their own I always like getting the terminology lined up right away so the reader isn't reading ahead, but that is probably just me. tim (working on my dnsdir review also!) > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > -- > dnsdir mailing list > dns...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsdir > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] writeup of my 2018 homenet experience on openwrt
Apologies, I should never use the phone to send emails, I always hit send to do this. I was trying to say cmake on OSX is a real pain, I had this problem a year ago and I ended up doing it in a container. I went back to my computer to find the container, and it's gone, and then I remember it was a year ago because when while @ IETF100 I had to have my have my work laptop reimaged and container lost. But agree on all counts on cmake. again apologies. On Thu, Nov 8, 2018 at 9:01 PM Ted Lemon wrote: > What’s your point? > > On Fri, Nov 9, 2018 at 8:23 AM tjw ietf wrote: > >> I heard of some fancy new technology. I think the kids call them >> “containers” >> >> From my high tech gadget >> >> On Nov 8, 2018, at 20:07, Ted Lemon wrote: >> >> It doesn’t build or work on Ubuntu either. >> >> On Fri, Nov 9, 2018 at 7:58 AM Michael Thomas wrote: >> >>> On 11/8/18 4:03 PM, Ted Lemon wrote: >>> > The issue with the code (IIRC) is that it requires cmake to compile, >>> > for no obvious reason, and cmake is hard to get working, so e.g. >>> > building it on MacOS X is a major porting task. And it depends on >>> > libraries that I don't have. And there's no layering of the >>> > configuration system aspect of the architecture—it just goes and >>> > bashes on interfaces and stuff (this is my recollection—I haven't >>> > looked at it in a year or so). >>> >>> >>> Sometimes the easiest thing to do in these cases is just give in and >>> create a linux vm. they work really well these days. >>> >>> Mike >>> >>> ___ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> >> ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] (no subject)
Instead of calling it a "DNS Server" perhaps call it the "declarative data store"? it could be a git repo, tim On Mon, Jul 23, 2018 at 10:43 PM, Ted Lemon wrote: > The DNS server in the cloud doesn't have to answer queries. Indeed, it > probably shouldn't. It's really just a backing store. The > public/private primary with selective publication is just a functional > block—you can put it where it makes the most sense. Juliusz is saying > that he wants a nearly stateless homenet; for him, putting the > public/primary functional block in the cloud makes sense because it keeps > his homenet stateless. I would not want that configuration because it > exposes the internals of my network to the cloud provider (unless it's also > encrypted, but then you have a keying problem). > > On Mon, Jul 23, 2018 at 9:02 PM, Michael Thomas wrote: > >> On 07/23/2018 05:45 PM, STARK, BARBARA H wrote: >> >>> You're concerned with the homenet losing state when the master is > unplugged. By having the master in the cloud, this problem is > eliminated. > I can't speak for Juliusz, but my first question was "what if i don't want it in the cloud"? For one thing, what if it's a cloudless day? >>> I was starting to accept the idea that selecting a subset of my devices >>> to exist in global DNS. But absolutely, positively, not all. Any design I >>> could buy into will *not* push all my DNS into the cloud. >>> >> >> As usual i'm probably behind, but I kind of thought this was more about >> provisioning/configs. The way I've thought >> about this is that where I decide is the ultimate repository for truth >> for my configs is really a deeply personal >> decision. The easy case is when i delegate it to "the cloud" since it >> then becomes somebody else's $DAYJOB to >> figure out how to back it up, etc. But if I want to keep things local -- >> for whatever reason, including tin foil hats -- >> i'd really like my homenet to have the property that i can take one >> router and throw it in the trash, and plug in >> another, and with minimal fuss it takes over for the old one. >> >> For naming, that implies that i want to distribute the naming database >> such that there isn't a single point of failure. >> While this isn't exactly new territory, it is in the context of my home >> networking. Better would be to use already >> standardized mechanisms so that everybody's sanity is preserved, if only >> a little bit. >> >> Mike >> >> >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] About ULAs in Ted's draft
If you have no ULA, then you may have to fall back to manual creation of the homenet domain in 4.7, which is less than ideal. tim ps - i've read the draft and think it's ready for adoption. Needs some fleshing out, but it's has a good foundation. On 7/19/16 11:22 AM, Ted Lemon wrote: Yeah, I think this is the right approach. I think a homenet with no ULA is broken, but I don't want to insist. Things just get a lot more brittle if you don't have ULAs. On Jul 19, 2016 11:05, "Juliusz Chroboczek" mailto:j...@pps.univ-paris-diderot.fr>> wrote: Ted, I've read the draft again, and I think that there's only one place where you rely on having a ULA. So I'd suggest: Section 3.3 point 2, replace "the homenet's ULA prefix" with "the homenet's ULA prefix (if any)". In Section 5.5, change "Homenets have at least one ULA prefix" with "Homenets usually have exactly one non-deprecated ULA prefix". The only place where you actually rely on a ULA is Section 4.7, paragraph 2. I have no idea what to do about that. Alternatives to this include making ULA generation a MUST in the HNCP RFC, or making naming support a SHOULD that depends on having a ULA. I hold a mild distaste for either of these possibilities, but I suppose I could live with either. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] RFC 7788-bis
On 6/16/16 2:48 PM, Ralph Droms wrote: On Jun 16, 2016, at 1:26 PM 6/16/16, Ray Bellis wrote: As was alluded to in my email of 9th June, we have been asked to replace RFC 7788 (HNCP) with an RFC 7788-bis as soon as possible to incorporate the errata raised by the DNSOP chair regarding the unintended apparent reservation of ".home" as the default domain TLV within HNCP. We should also take that opportunity to fix the error in the diagrams for the DHCPv4_DATA and DHCPv6_DATA TLVs where the numbers shown conflict with the IANA registrations for those TLVs. Those two changes will be the only ones made, unless any further errata are made in the meantime. Slightly longer term, and notwithstanding our previously stated desire to wait until Ted Lemon's Naming Architecture was further progressed, we would like to obtain WG consensus on whether ".home" is indeed a suitable default domain for HNCP. In the meantime, implementors are hereby advised that ".home" is potentially subject to change. In my opinion, it is important for the exact requirements and semantics for the default domain be defined, perhaps even before the default domain itself is selected. It's not clear to me whether the domain carried in the Domain-Name TLV can be a delegated domain or it has to be a special use domain name for location-relative name resolution like .local, or if either type of name is OK. - Ralph +1 on this. tim ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Technical Errata Reported] RFC7788 (4677)
Of course the Corrected Text should not say "Sn administrator" but "An administrator. tim On 4/26/16 1:45 PM, RFC Errata System wrote: The following errata report has been submitted for RFC7788, "Home Networking Control Protocol". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7788&eid=4677 -- Type: Technical Reported by: Tim Wicinski Section: 8 Original Text - A network-wide zone is appended to all single labels or unqualified zones in order to qualify them. ".home" is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) for the network to use a different one. Corrected Text -- A network-wide zone is appended to all single labels or unqualified zones in order to qualify them. Sn administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) for the network. Notes - It may appear that the use of the label ".home" is unofficially assigning this to be added to the Special Use Domain Registry. That registry can only be updated using the process outlined in RFC6761, therefore the text identifying ".home" as the default network-wide zone is in error. It is unclear of the IESG and the IETF in publishing this proposed standard if the intent was to use ".home" as an example or placeholder until a name can be reserved. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -- RFC7788 (draft-ietf-homenet-hncp-10) -- Title : Home Networking Control Protocol Publication Date: April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category: PROPOSED STANDARD Source : Home Networking Area: Internet Stream : IETF Verifying Party : IESG ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WG adoption of draft-stenberg-homenet-hncp-00
On 3/26/14, 5:30 PM, Michael Richardson wrote: I have read the HNCP draft, and while it is very rough, and lacks greatly in the area of "how", being focused on the "what", I am happy with the WG adopting it, and then improving it. After reading the draft again, I agree the WG should adopt this, with the knowledge the draft is rough and needs some iterations to make whole. tim ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet