Just to keep the WG up-to date with our planes. We discussed last Friday
among other aspects:
* the title of the draft: It is not the first time but we thought that
"Simple Provisioning of Public Names for Residential Networks" described
better what we were doing.
* the security consideration
Eric Vyncke \(evyncke\) wrote:
> Daniel, thank you for the update on this draft.
> May the WG expect a revised I-D (and possibly one for the DHCPv6 draft)
in the coming days?
Hi, I posted a revised document, but there are still issues that I don't
expect to work out until Ray and I put
in
> the coming days?
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *homenet on behalf of Daniel Migault <
> mglt.i...@gmail.com>
> *Date: *Friday, 9 October 2020 at 19:22
> *To: *homenet
> *Subject: *[homenet] draft-ietf-homenet-front-end
Daniel, thank you for the update on this draft.
May the WG expect a revised I-D (and possibly one for the DHCPv6 draft) in the
coming days?
Regards
-éric
From: homenet on behalf of Daniel Migault
Date: Friday, 9 October 2020 at 19:22
To: homenet
Subject: [homenet] draft-ietf-homenet-front
Hi,
I have reviewed the draft. I have addressed some nits and clarification. I
believe the draft is in a good shape and should be ready for WGLC soon. It
seems to me that the only thing to do is to document how provisioning the
HNA can be done automatically or at least requiring a minimal
Thanks for your reply, Daniel.
> If I understand correctly the question is why do we have a Homenet Naming
> Authority responsible to outsource the Homenet Zone to the Public
> Authoritative
> Servers ( Front End architecture) instead of having each device updating their
> data directly to the
Hi Juliusz,
If I understand correctly the question is why do we have a Homenet Naming
Authority responsible to outsource the Homenet Zone to the Public
Authoritative Servers ( Front End architecture) instead of having each
device updating their data directly to the Public Authoritative Servers
What do you mean by a "trivial end to end protocol," Juliusz?
On Wed, Nov 21, 2018 at 1:32 PM Juliusz Chroboczek wrote:
> Dear Daniel,
>
> > I am planning to update the front end naming delegation draft [1] in the
> next
> > weeks. Before revisiting the draft, I am collecting comments that
Dear Daniel,
> I am planning to update the front end naming delegation draft [1] in the next
> weeks. Before revisiting the draft, I am collecting comments that need to be
> addressed.
After your talk at IETF-102, I asked what is the purpose of this rather
complex protocol, and why it is
Hi,
I am planning to update the front end naming delegation draft [1] in the
next weeks. Before revisiting the draft, I am collecting comments that need
to be addressed.
The draft has been waiting the naming architecture draft become more
advanced. I believe this now achieved.
The main comments
Juliusz Chroboczek writes:
>> Why? What is wrong with the owner of the network selecting which devices
>> / services he/she wants globally reachable
>
> I don't think this is about global reachability (which is hopefully
> managed by PCP), it's about exporting names into the global DNS. We
>
Hi,
On Mon, Jul 23, 2018 at 08:50:50PM +0200, Toke Høiland-Jørgensen wrote:
> Juliusz Chroboczek writes:
>
> > Exporting names from the Homenet into the global namespace, on the
> > other hand, should be done by the hosts, with no involvement of any
> > third party (neither the ISP nor the
> Why? What is wrong with the owner of the network selecting which devices
> / services he/she wants globally reachable
I don't think this is about global reachability (which is hopefully managed
by PCP), it's about exporting names into the global DNS. We ought to
distinguish the two -- you can
> Apparently my comment was clear as mud. I meant this:
> https://tools.ietf.org/html/draft-ietf-opsawg-mud-25
Quote, "YANG-based JSON that describes a Thing", unquote. 61 pages.
Revision 25, and still a draft. I wish you a lot of fun implementing that.
> Having a public/private zone pair
Juliusz Chroboczek writes:
> Exporting names from the Homenet into the global namespace, on the
> other hand, should be done by the hosts, with no involvement of any
> third party (neither the ISP nor the Homenet itself). This is where I
> argue for some form of end-to-end, secured, dynamic DNS
> By using DynDns are you proposing to remove the requirement of having
> a naming resolution mechanism internally in the homenet ?
No. Naming *internal* to the Homenet needs another mechanism, perhaps
what Ted is designing (and implementing), perhaps something else.
Exporting names from the
>updating a single record continuously.
Cheers
Elson
-Original Message-
From: homenet On Behalf Of Juliusz Chroboczek
Sent: Thursday, July 19, 2018 4:38 PM
To: Ted Lemon
Cc: Homenet
Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> One
Apparently my comment was clear as mud. I meant this:
https://tools.ietf.org/html/draft-ietf-opsawg-mud-25
Having a public/private zone pair where the public zone is an image of the
private zone that is constructed following rules, the default rule being
"don't copy," seems very straightforward
> One way to automate this would be using mud.
A bright light shines from the heavens, bathing you in its warm glow. An
enormous, white temple stands to the north, taking most of your view.
In order to enter the Temple of Homenet Naming, you must travel up the
large staircase that stands in
;
Juliusz Chroboczek
Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
One way to automate this would be using mud.
On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell
mailto:stephen.farr...@cs.tcd.ie>> wrote:
(with no hats...)
On 19/07/18 10:42, Juliusz Chroboczek
> On the other hand same thing using nsupdate (using TSIG and dynamic
> dns) is one command line + input file for nsupdate:
Cool.
Whichever end-to-end (host to DNS provider with no intermediate proxying)
encrypted and authentified protocol you pick, I'm with you.
-- Juliusz
Juliusz Chroboczek writes:
> And it's literally four lines of shell:
>
> while true; do
> wget --post-data 'name=gameserver.myhome.net=topsecret' \
> https://dyndns.example.com
> sleep $((24 * 3600))
> done
How does that get both IPv4 and IPv6 addresses
>> And it's literally four lines of shell:
> vs
> while true; do
> (omitted for brevity)
You're doing end-to-end dynamic update over DNS, which is fine with me.
The exact transport we end up using doesn't matter that much.
You're not doing the proxying through a hidden master mandated by
> On 19 Jul 2018, at 11:58 pm, Mark Andrews wrote:
>
>
>
>> On 19 Jul 2018, at 11:30 pm, Juliusz Chroboczek wrote:
>>
>>> I am not speaking about discovery within the Homenet. I am speaking about
>>> exporting names into the global DNS, which is what Daniel's draft is
>>> about.
>>
> On 19 Jul 2018, at 11:30 pm, Juliusz Chroboczek wrote:
>
>>I am not speaking about discovery within the Homenet. I am speaking about
>>exporting names into the global DNS, which is what Daniel's draft is
>>about.
>
>> Yes, but the problem is that you are treating this as if
One way to automate this would be using mud.
On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell
wrote:
>
> (with no hats...)
>
> On 19/07/18 10:42, Juliusz Chroboczek wrote:
>
> >> Also, think of the privacy implications if all of the services on the
> >> homenet had to be discovered from a
> I am not speaking about discovery within the Homenet. I am speaking about
> exporting names into the global DNS, which is what Daniel's draft is
> about.
> Yes, but the problem is that you are treating this as if these are two
> separate problems, but they are not.
These are two
(with no hats...)
On 19/07/18 10:42, Juliusz Chroboczek wrote:
>> Also, think of the privacy implications if all of the services on the
>> homenet had to be discovered from a shared zone like dyndns.org.
> Quite the opposite. In the trivial update protocol, the update is
> end-to-end,
On Thu, Jul 19, 2018 at 5:42 AM, Juliusz Chroboczek wrote:
> > In order for services to be discoverable on the homenet, they have to
> > publish their contact info on the homenet. The protocol that everyone
> > uses for this is DNSSD. This is how you find your printer when you want
> > to print
> In order for services to be discoverable on the homenet, they have to
> publish their contact info on the homenet. The protocol that everyone
> uses for this is DNSSD. This is how you find your printer when you want
> to print to it. Nobody uses the ad-hoc DynDNS protocol for this.
I am not
The trivial update protocol isn't a standard protocol, and doesn't do what
we need it to do. In order for services to be discoverable on the
homenet, they have to publish their contact info on the homenet. The
protocol that everyone uses for this is DNSSD. This is how you find your
printer
> All of this can be done in the DNS without resorting to any other protocol.
Excellent.
So what technical reasons are there to prefer the complexity of
draft...front-end-naming-delegation over a trivial update protocol,
whether encapsulated in HTTPS or DNS?
-- Juliusz
All of this can be done in the DNS without resorting to any other protocol.
_dns-update._udp SRV is registered with IANA for finding where to send
UPDATE request to if the SOA MNAME or the NS’s are not reasonable.
UPDATEs can be secured with TSIG (shared secret) or SIG(0) (public key
Dear all,
Since the 1990s, people have been putting their dynamically allocated IPv4
addresses into global DNS by using a family of gratuitiously incompatible
trivial protocols. The technique doesn't have an official name (let alone
a specification), and is usually referred to as DDNS, DynDNS or
Dear Homenet wg,
The draft-ietf-homenet-front-end-naming-delegation-04
sections lack needed guidance:
Section 7.3 Guidance and Recommendations
mDNS [RFC6762] DNS-SD [RFC6763] are two examples of these
services. Currently mDNS is limited to a single link
network. However, future protocols are
35 matches
Mail list logo
