Re: WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

Bernie Volz (volz)
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 <[hidden email]> On Behalf Of STARK, BARBARA H
Sent: Tuesday, May 4, 2021 9:56 AM
To: '[hidden email]' <[hidden email]>
Cc: '[hidden email]' <[hidden email]>; '[hidden email]' <[hidden email]>; '[hidden email]' <[hidden email]>
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
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

Michael Richardson-11

Bernie Volz \(volz\) <volz=[hidden email]> 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 <[hidden email]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

Ted Lemon
On May 5, 2021, at 11:44 AM, Michael Richardson <[hidden email]> wrote:
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.

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.


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

Michael Richardson-11

Ted Lemon <[hidden email]> wrote:
    > On May 5, 2021, at 11:44 AM, Michael Richardson <[hidden email]>
    > wrote:
    >> 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.

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

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





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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

Daniel Migault-2
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 <[hidden email]> wrote:

Ted Lemon <[hidden email]> wrote:
    > On May 5, 2021, at 11:44 AM, Michael Richardson <[hidden email]>
    > wrote:
    >> 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.

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

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




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


--
Daniel Migault
Ericsson

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

Bernie Volz (volz)

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 <[hidden email]>
Date: Wednesday, May 12, 2021 at 1:11 PM
To: Michael Richardson <[hidden email]>
Cc: Ted Lemon <[hidden email]>, [hidden email] <[hidden email]>, [hidden email] <[hidden email]>, [hidden email] <[hidden email]>, Bernie Volz (volz) <[hidden email]>, [hidden email] <[hidden email]>
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 <[hidden email]> wrote:


Ted Lemon <[hidden email]> wrote:
    > On May 5, 2021, at 11:44 AM, Michael Richardson <[hidden email]>
    > wrote:
    >> 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.

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

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




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


 

--

Daniel Migault

Ericsson


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

Daniel Migault-2
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) <[hidden email]> 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 <[hidden email]>
Date: Wednesday, May 12, 2021 at 1:11 PM
To: Michael Richardson <[hidden email]>
Cc: Ted Lemon <[hidden email]>, [hidden email] <[hidden email]>, [hidden email] <[hidden email]>, [hidden email] <[hidden email]>, Bernie Volz (volz) <[hidden email]>, [hidden email] <[hidden email]>
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 <[hidden email]> wrote:


Ted Lemon <[hidden email]> wrote:
    > On May 5, 2021, at 11:44 AM, Michael Richardson <[hidden email]>
    > wrote:
    >> 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.

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

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




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


 

--

Daniel Migault

Ericsson



--
Daniel Migault
Ericsson

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

Daniel Migault-2
In reply to this post by Bernie Volz (volz)
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=[hidden email]> 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> 

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 <[hidden email]> On Behalf Of STARK, BARBARA H
Sent: Tuesday, May 4, 2021 9:56 AM
To: '[hidden email]' <[hidden email]>
Cc: '[hidden email]' <[hidden email]>; '[hidden email]' <[hidden email]>; '[hidden email]' <[hidden email]>
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
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg

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


--
Daniel Migault
Ericsson

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

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

RayH
In reply to this post by Ted Lemon
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 <[hidden email]> wrote:
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.

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.



_______________________________________________
homenet mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/homenet

--
regards,
RayH

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