Subject: Re: [dns-privacy] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 5 May 2021 14:53:27 +0000

Hi:

Looking at this primarily from the DHCP perspective ... regarding https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/, these DHCPv6 options are formatted properly (as per RFC7227 and standard practices).

I just have some nits:
- In 4.2, in the "option-code" description "DM Option" is used (only use). Probably best if this was replaced with "Distributed Master Option"? (Yes, DM is used in plenty of other places, but it seems odd to use it here as the "name" of the option.) Also, "TDB3" in the IANA section does not use "DM". Also, 4.3 "option-code" uses "Reverse Distributed Master Option (TBD4)".
- In 4.3, the "Supported Transport" description says "DM". Should this be "RDM", as this is the Reverse Distributed Master Server Option?

And, something to ponder:
- In 5.3, is there any value in potentially allowing a Relay Agent to supply these options to a server to potentially return to a client via the RSOO option (RFC6422)? I raise this question as it seems no documents have mentioned this and there was a case that recently came up where this was useful for another option, so just want to remind folks that it exists and to consider whether it could be used for these options.

I do plan to take a closer look at the other I-D as well, so may have additional comments thereafter.

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of STARK, BARBARA H
Sent: Tuesday, May 4, 2021 9:56 AM
To: [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: [dhcwg] WGLC started

Hi homenet, intarea, dhc, and dprive,
Homenet has started WGLC for draft-ietf-homenet-front-end-naming-delegation-14 and draft-ietf-homenet-naming-architecture-dhc-options-12.

https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ (Simple Provisioning of Public Names for Residential Networks) https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/ (DHCPv6 Options for Home Network Naming Authority)

We're including intarea, dhc, and dprive to get a slightly wider audience for the technical aspects of these drafts (dhc is specifically asked to look at the dhc-options draft).
The drafts do also need some editorial fixing-up. I'll be focusing on that so the technical experts can focus on the technical aspects.

I've made the WGLCs for 3 weeks instead of the normal 2. I'm doing this because
- we're reaching out to WGs that haven't seen this before and asking them for comments
- there are 2 drafts
- I'm on vacation next week and was getting stressed out by everything I need to get done by this Friday

The meeting minutes (from the homenet April 23 interim) list intarea, dprive, and dhc as other groups to request comments from. Is this the right list? Are there others?
Please let me know if I should broaden this.
Thx,
Barbara

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 May 2021 11:44:11 -0400

Bernie Volz \(volz\) <volz=[email-masked]> wrote:
    > And, something to ponder: - In 5.3, is there any value in potentially
    > allowing a Relay Agent to supply these options to a server to
    > potentially return to a client via the RSOO option (RFC6422)?
    > I raise this question as it seems no documents have mentioned this and there
    > was a case that recently came up where this was useful for another
    > option, so just want to remind folks that it exists and to consider
    > whether it could be used for these options.

We expect that most of the time, these options will be returned for the
reverse zone at the time that a IPv6 PD is initially done.
(And the rest of the time, it will be because forward zone is *also* configured
by the ISP)

Do Relay Agents delegated PD?  Alas, no.
So I can't see a use case for putting those options there.

One thing that I just thought of, and I don't remember if we discussed it at
all, was whether there was a need to synchonize these returned options with
the IA_PD lifetimes.    I think not: because if the ISP renumbers the end
user (whether a flash number or controlled), then they can also just stop
synchronizing the reverse zone, and that effectively kills the reverse zone
content.   The end user might suffer slightly by having locally served
reverse names that are no longer connected: they should obsolete that zone
when they realize that their PD hasn't been renewed, until such time,
(if it was a flash renumber), they would be right to think that they
legitimately control them.

(I'm still miffed that Relay Agents have to snoof to learn PD, and nobody
seems to think this a problem)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 May 2021 12:42:31 -0400

On May 5, 2021, at 11:44 AM, Michael Richardson <[email-masked]> wrote:
> The end user might suffer slightly by having locally served

In practice I don’t think this is an issue. The reverse lookup is usually triggered by receipt of a message from an IP address, so as long as the IP address is still in use internally, the presence of the reverse zone is wanted. When the address changes, the old zone becomes obsolete whether it continues to be served or not. The likelihood of the zone being re-allocated to some other network for which the original network will then do a reverse lookup is very small, so I don’t think there’s any reason to be concerned about this.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 May 2021 15:10:31 -0400

Ted Lemon <[email-masked]> wrote:
    >> The end user might suffer slightly by having locally served reverse
    >> names that are no longer connected: they should obsolete that zone

    > In practice I don’t think this is an issue. The reverse lookup is
    > usually triggered by receipt of a message from an IP address, so as
    > long as the IP address is still in use internally, the presence of the
    > reverse zone is wanted. When the address changes, the old zone becomes
    > obsolete whether it continues to be served or not. The likelihood of
    > the zone being re-allocated to some other network for which the
    > original network will then do a reverse lookup is very small, so I
    > don’t think there’s any reason to be concerned about this.

I agree with you completely.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 12 May 2021 13:10:44 -0400

Hi,

Thank you all for the feedbacks. I will perform the editorial once we have
settled the terminology.
Regarding the use of a DHCP Relay, we could of course make a use case of
it, but I believe it would go beyond the simplicity of the targeted
architecture and I would rather not consider this as RSOO enabled.

Yours,
Daniel

On Wed, May 5, 2021 at 3:10 PM Michael Richardson <[email-masked]>
wrote:

>     > On May 5, 2021, at 11:44 AM, Michael Richardson <
> [email-masked]>
>     > wrote:

-- 
Daniel Migault
Ericsson

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 May 2021 17:46:27 +0000

Regarding RSOO, that’s fine if it doesn’t meet your needs. Just wanted to raise it as it probably isn’t considered as often as it should be.

  *   Bernie

From: Daniel Migault <[email-masked]>
Date: Wednesday, May 12, 2021 at 1:11 PM
To: Michael Richardson <[email-masked]>
Cc: Ted Lemon <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Bernie Volz (volz) <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12
Hi,

Thank you all for the feedbacks. I will perform the editorial once we have settled the terminology.
Regarding the use of a DHCP Relay, we could of course make a use case of it, but I believe it would go beyond the simplicity of the targeted architecture and I would rather not consider this as RSOO enabled.

Yours,
Daniel

On Wed, May 5, 2021 at 3:10 PM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
    > On May 5, 2021, at 11:44 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>>
    > wrote:

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

--
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 12 May 2021 21:47:53 -0400

Thanks Bernie, in any case for raising this. It is always good information
to process and think of carefully before bringing any conclusion.
Yours,
Daniel

On Wed, May 12, 2021 at 1:46 PM Bernie Volz (volz) <[email-masked]> wrote:

> Regarding RSOO, that’s fine if it doesn’t meet your needs. Just wanted to
> raise it as it probably isn’t considered as often as it should be.
>
>
>
>    - Bernie
>
>
>
> *From: *Daniel Migault <[email-masked]>
> *Date: *Wednesday, May 12, 2021 at 1:11 PM
> *To: *Michael Richardson <[email-masked]>
> *Cc: *Ted Lemon <[email-masked]>, [email-masked] <[email-masked]>,
> [email-masked] <[email-masked]>, [email-masked] <
> [email-masked]>, Bernie Volz (volz) <[email-masked]>,
> [email-masked] <[email-masked]>
> *Subject: *Re: [dhcwg] WGLC started --
> draft-ietf-homenet-naming-architecture-dhc-options-12
>
> Hi,
>
>
>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Thu, 13 May 2021 11:39:00 -0400

Hi Bernie,

Please find the update of the current draft. I am publishing a new version
very shortly. Thanks for the review!

Yours,
Daniel

On Wed, May 5, 2021 at 10:53 AM Bernie Volz (volz) <volz=
[email-masked]> wrote:

> Hi:
>
> Looking at this primarily from the DHCP perspective ... regarding
> https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/,
> these DHCPv6 options are formatted properly (as per RFC7227 and standard
> practices).
>
> I just have some nits:
> - In 4.2, in the "option-code" description "DM Option" is used (only use).
> Probably best if this was replaced with "Distributed Master Option"? (Yes,
> DM is used in plenty of other places, but it seems odd to use it here as
> the "name" of the option.)

<mglt> done</mglt>

> Also, "TDB3" in the IANA section does not use "DM".

 <mglt>changed to TBD2</mglt>

> Also, 4.3 "option-code" uses "Reverse Distributed Master Option (TBD4)".
>
<mglt>changed to TBD3</mglt>

> - In 4.3, the "Supported Transport" description says "DM". Should this be
> "RDM", as this is the Reverse Distributed Master Server Option?
>
<mglt>correct, this has been changed to RDM.</mglt>

> - In 5.3, is there any value in potentially allowing a Relay Agent to
> supply these options to a server to potentially return to a client via the
> RSOO option (RFC6422)? I raise this question as it seems no documents have
> mentioned this and there was a case that recently came up where this was
> useful for another option, so just want to remind folks that it exists and
> to consider whether it could be used for these options.
>
>
> Cc: [email-masked]' <[email-masked]>; [email-masked]' <
> [email-masked]>; [email-masked]' <[email-masked]>
> Homenet has started WGLC for
> draft-ietf-homenet-front-end-naming-delegation-14 and
> draft-ietf-homenet-naming-architecture-dhc-options-12.
>
>
> https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/
> (Simple Provisioning of Public Names for Residential Networks)
> https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/
> (DHCPv6 Options for Home Network Naming Authority)
>
> We're including intarea, dhc, and dprive to get a slightly wider audience
> for the technical aspects of these drafts (dhc is specifically asked to
> look at the dhc-options draft).
> The drafts do also need some editorial fixing-up. I'll be focusing on that
> so the technical experts can focus on the technical aspects.
>
> The meeting minutes (from the homenet April 23 interim) list intarea,
> dprive, and dhc as other groups to request comments from. Is this the right
> list? Are there others?

-- 
Daniel Migault
Ericsson

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 May 2021 21:13:10 +0000

Changes look good (reviewed published draft).

- Bernie (from iPad)

On May 13, 2021, at 11:39 AM, Daniel Migault <[email-masked]> wrote:

Hi Bernie,

Please find the update of the current draft. I am publishing a new version very shortly. Thanks for the review!

Yours,
Daniel

On Wed, May 5, 2021 at 10:53 AM Bernie Volz (volz) <volz=[email-masked]<mailto:[email-masked]>> wrote:
Hi:

I just have some nits:
- In 4.2, in the "option-code" description "DM Option" is used (only use). Probably best if this was replaced with "Distributed Master Option"? (Yes, DM is used in plenty of other places, but it seems odd to use it here as the "name" of the option.)
<mglt> done</mglt>

- Bernie

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 28 May 2021 08:42:11 +0200

Hi Ted, thanks for the comment.

I agree.

Plus one more point.

The ISP hosts the reverse zone.
The ISP also controls any reverse zone to customer assignments, and is 
in control of any renumbering.
The ISP may therefore choose to simply wipe any reverse zone content 
after renumbering occurs.
That would mitigate any re-use or privacy concerns.

Otherwise the HNA may no longer have authority over the content after a 
flash renumbering (e.g. if the ISP is simply authenticating customers 
based on source address of the updates)

regards,

Ted Lemon wrote on 05/05/2021 18:42:
> On May 5, 2021, at 11:44 AM, Michael Richardson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>