Re: [homenet] [DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6

[Tim Wicinski]

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

[Tim Wicinski via Datatracker]

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

[Tim Wicinski]

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

[Tim Wicinski]

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)

[Tim Wicinski]

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

[Tim Wicinski]

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

[Tim Wicinski]

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)

[Tim Wicinski]

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=4677

--
Type: Technical
Reported by: Tim Wicinski <tjw.i...@gmail.com>

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

[Tim Wicinski]

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