Re: [homenet] naming drafts

[Daniel Migault]

Thank you very much for the feed backs. I will have a look at the comments
today and should be able to implement them by early next week.
Yours,
Daniel

On Thu, Jun 9, 2022 at 7:44 PM Kiran M  wrote:

> Hi Daniel,
>
> I finally managed to finish the review of front-end naming document. My
> apologies for the delay. Many thanks for addressing the first round of
> comments, the readability has improved quite a bit. The remainder of the
> comments are in the Github. Hope we will see a revision soon.
>
> Cheers,
> Kiran
>
>
> --
> *From:* Daniel Migault [mailto:mglt.i...@gmail.com ]
> *Sent:* Thursday, June 2, 2022, 6:36 AM
> *To:* Eric Vyncke (evyncke)
> *Cc:* Eric Vyncke (evyncke); homenet@ietf.org; kiran.i...@gmail.com;
> Michael Richardson; Stephen Farrell
> *Subject:* [homenet] naming drafts
>
> We are working on it with Kiran, I actually started yesterday to consider
> her latest feedback (2nd round) - not yet being pushed, but that should
> happen very soon.
>
> Yours,
> Daniel
>
> On Thu, Jun 2, 2022 at 7:30 AM Eric Vyncke (evyncke) 
> wrote:
>
>> As we are halfway between IETF-113 and IETF-114, it is time to make a
>> check as I have seen no revised version for those 2 ‘naming’ drafts.
>>
>>
>>
>> You may also have noticed that Ted’s ‘stub networking’ work is going in a
>> SNAC BoF at IETF-114 (please attend and contribute to the s...@ietf.org
>> mailing list).
>>
>>
>>
>> Therefore, the plan is to close Homenet early July 2022 if nothing
>> changes.
>>
>>
>>
>> Hoping to see you in “Philly” to celebrate the achievments of Homenet !
>>
>>
>>
>> Regards
>>
>>
>>
>> -éric
>>
>>
>>
>> *From: *homenet  on behalf of "Eric Vyncke
>> (evyncke)" 
>> *Date: *Thursday, 14 April 2022 at 09:16
>> *To: *"homenet@ietf.org" 
>> *Cc: *"kiran.i...@gmail.com" , Michael Richardson <
>> mcr+i...@sandelman.ca>, Daniel Migault , Stephen
>> Farrell 
>> *Subject: *Re: [homenet] naming drafts
>>
>>
>>
>> Dear Homenet,
>>
>>
>>
>> After 9 months, it is time to resurrect this email thread and move
>> forward with the 'naming drafts', which are still in WG Last Call since May
>> 2021:
>>
>> -  draft-ietf-homenet-front-end-naming-delegation
>>
>> -  draft-ietf-homenet-naming-architecture-dhc-options
>>
>>
>>
>> AT IETF-113, there was a meeting with two authors, the chairs, and I (as
>> the responsible AD for Homenet). The plan is to give the authors a chance
>> to issue a revised I-D considering Chris Blox's review as well as trying to
>> improve the readability and flow of the text (which suffers from multiple
>> revisions that have rendered the I-D difficult to read). Once done, the
>> chairs will close the WGLC and will request publication to continue the
>> process. This should be done by IETF-114 (July 2022) if not earlier.
>>
>>
>>
>> About the DynDNS discussion of last year, I am in favor of going forward
>> anyway with the homenet drafts and wait for the IETF Last Call + IESG
>> evaluation to get a broader scope than the Homenet WG on this very specific
>> topic.
>>
>>
>>
>> Final point, the chairs and I have decided that once those 2 drafts have
>> been approved by the IESG [1], then the Homenet WG can be closed after 11
>> years [2].
>>
>>
>>
>> Of course, feedback and comments on the above are welcome.
>>
>>
>>
>> Regards
>>
>>
>>
>> -éric
>>
>>
>>
>> [1] or if the publication is not requested before IETF-114, then I will
>> declare those two I-D as "dead" and proceed anyway with the closing of
>> Homenet.
>>
>> [2] a new home will need to be found for Ted Lemon's drafts on "stub
>> networking"
>>
>>
>>
>> *From: *homenet  on behalf of Daniel Migault <
>> mglt.i...@gmail.com>
>> *Date: *Tuesday, 13 July 2021 at 23:28
>> *To: *Chris Box 
>> *Cc: *"homenet@ietf.org" 
>> *Subject: *Re: [homenet] naming drafts
>>
>>
>>
>> Hi,
>>
>>
>>
>> Thanks for the follow up Chris. I apologize for the delay.
>>
>>
>>
>> Yours,
>>
>> Daniel
>>
>>
>>
>> On Tue, Jun 22, 2021 at 12:31 PM Chris Box 
>> wrote:
>>
>> Daniel,
>>
>>
>>
>> On Wed, 16 Jun 2021 at 01:27, Daniel Migault  wrote:

Re: [homenet] naming drafts

[Kiran M]

Hi Daniel,

I finally managed to finish the review of front-end naming document. My 
apologies for the delay. Many thanks for addressing the first round of 
comments, the readability has improved quite a bit. The remainder of the 
comments are in the Github. Hope we will see a revision soon.


Cheers,
Kiran



*From:* Daniel Migault [mailto:mglt.i...@gmail.com]
*Sent:* Thursday, June 2, 2022, 6:36 AM
*To:* Eric Vyncke (evyncke)
*Cc:* Eric Vyncke (evyncke); homenet@ietf.org; kiran.i...@gmail.com; 
Michael Richardson; Stephen Farrell

*Subject:* [homenet] naming drafts

We are working on it with Kiran, I actually started yesterday to 
consider her latest feedback (2nd round) - not yet being pushed, but 
that should happen very soon.


Yours,
Daniel

On Thu, Jun 2, 2022 at 7:30 AM Eric Vyncke (evyncke) 
 wrote:


As we are halfway between IETF-113 and IETF-114, it is time to
make a check as I have seen no revised version for those 2
‘naming’ drafts.

You may also have noticed that Ted’s ‘stub networking’ work is
going in a SNAC BoF at IETF-114 (please attend and contribute to
the s...@ietf.org mailing list).

Therefore, the plan is to close Homenet early July 2022 if nothing
changes.

Hoping to see you in “Philly” to celebrate the achievments of
Homenet !

Regards

-éric

*From: *homenet  on behalf of "Eric
Vyncke (evyncke)" 
*Date: *Thursday, 14 April 2022 at 09:16
*To: *"homenet@ietf.org" 
*Cc: *"kiran.i...@gmail.com" , Michael
Richardson mailto:mcr%2bi...@sandelman.ca>>, Daniel Migault
, Stephen Farrell 
*Subject: *Re: [homenet] naming drafts

Dear Homenet,

After 9 months, it is time to resurrect this email thread and move
forward with the 'naming drafts', which are still in WG Last Call
since May 2021:

-draft-ietf-homenet-front-end-naming-delegation

-draft-ietf-homenet-naming-architecture-dhc-options

AT IETF-113, there was a meeting with two authors, the chairs, and
I (as the responsible AD for Homenet). The plan is to give the
authors a chance to issue a revised I-D considering Chris Blox's
review as well as trying to improve the readability and flow of
the text (which suffers from multiple revisions that have rendered
the I-D difficult to read). Once done, the chairs will close the
WGLC and will request publication to continue the process. This
should be done by IETF-114 (July 2022) if not earlier.

About the DynDNS discussion of last year, I am in favor of going
forward anyway with the homenet drafts and wait for the IETF Last
Call + IESG evaluation to get a broader scope than the Homenet WG
on this very specific topic.

Final point, the chairs and I have decided that once those 2
drafts have been approved by the IESG [1], then the Homenet WG can
be closed after 11 years [2].

Of course, feedback and comments on the above are welcome.

Regards

-éric

[1] or if the publication is not requested before IETF-114, then I
will declare those two I-D as "dead" and proceed anyway with the
closing of Homenet.

[2] a new home will need to be found for Ted Lemon's drafts on
"stub networking"

*From: *homenet  on behalf of Daniel
Migault 
*Date: *Tuesday, 13 July 2021 at 23:28
*To: *Chris Box 
    *Cc: *"homenet@ietf.org" 
*Subject: *Re: [homenet] naming drafts

Hi,

Thanks for the follow up Chris. I apologize for the delay.

Yours,

Daniel

On Tue, Jun 22, 2021 at 12:31 PM Chris Box
 wrote:

Daniel,

On Wed, 16 Jun 2021 at 01:27, Daniel Migault
 wrote:

The HNA SHOULD drop any packets arriving on the
WAN interface that are not issued from the DM.
Depending how the communications between the HNA
and the DM are secured, only packets associated to
that protocol SHOULD be allowed.

The separation looks good, but I'd like to tweak the
second paragraph. By "only packets associated to that
protocol" do you mean destination port filtering?

To me IP and port filtering are implemented by the
previous line. "only packets associated with that
protocol" to me means that only TLS packets are allowed. 
 The reason we are not mentioning TLS explicitly is that
other protocols may be used.

Ah, I see, so this is about the payload of the packets. But
surely intelligent validation of the incoming packets is
always going to happen? This is a key property of any security
protocol.

If the DM is listening on TCP 443, and the incoming packet is
not a TLS Client 

Re: [homenet] naming drafts

[Michael Richardson]

Eric Vyncke (evyncke)  wrote:
> As we are halfway between IETF-113 and IETF-114, it is time to make a
> check as I have seen no revised version for those 2 ‘naming’ drafts.

Yes... I think that *I* said that I wouldn't have time.

> You may also have noticed that Ted’s ‘stub networking’ work is going in
> a SNAC BoF at IETF-114 (please attend and contribute to the
> s...@ietf.org mailing list).

> Therefore, the plan is to close Homenet early July 2022 if nothing 
changes.
> Hoping to see you in “Philly” to celebrate the achievments of Homenet !

will be there.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Daniel Migault]

We are working on it with Kiran, I actually started yesterday to consider
her latest feedback (2nd round) - not yet being pushed, but that should
happen very soon.

Yours,
Daniel

On Thu, Jun 2, 2022 at 7:30 AM Eric Vyncke (evyncke) 
wrote:

> As we are halfway between IETF-113 and IETF-114, it is time to make a
> check as I have seen no revised version for those 2 ‘naming’ drafts.
>
>
>
> You may also have noticed that Ted’s ‘stub networking’ work is going in a
> SNAC BoF at IETF-114 (please attend and contribute to the s...@ietf.org
> mailing list).
>
>
>
> Therefore, the plan is to close Homenet early July 2022 if nothing changes.
>
>
>
> Hoping to see you in “Philly” to celebrate the achievments of Homenet !
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *homenet  on behalf of "Eric Vyncke
> (evyncke)" 
> *Date: *Thursday, 14 April 2022 at 09:16
> *To: *"homenet@ietf.org" 
> *Cc: *"kiran.i...@gmail.com" , Michael Richardson <
> mcr+i...@sandelman.ca>, Daniel Migault , Stephen
> Farrell 
> *Subject: *Re: [homenet] naming drafts
>
>
>
> Dear Homenet,
>
>
>
> After 9 months, it is time to resurrect this email thread and move forward
> with the 'naming drafts', which are still in WG Last Call since May 2021:
>
> -  draft-ietf-homenet-front-end-naming-delegation
>
> -  draft-ietf-homenet-naming-architecture-dhc-options
>
>
>
> AT IETF-113, there was a meeting with two authors, the chairs, and I (as
> the responsible AD for Homenet). The plan is to give the authors a chance
> to issue a revised I-D considering Chris Blox's review as well as trying to
> improve the readability and flow of the text (which suffers from multiple
> revisions that have rendered the I-D difficult to read). Once done, the
> chairs will close the WGLC and will request publication to continue the
> process. This should be done by IETF-114 (July 2022) if not earlier.
>
>
>
> About the DynDNS discussion of last year, I am in favor of going forward
> anyway with the homenet drafts and wait for the IETF Last Call + IESG
> evaluation to get a broader scope than the Homenet WG on this very specific
> topic.
>
>
>
> Final point, the chairs and I have decided that once those 2 drafts have
> been approved by the IESG [1], then the Homenet WG can be closed after 11
> years [2].
>
>
>
> Of course, feedback and comments on the above are welcome.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> [1] or if the publication is not requested before IETF-114, then I will
> declare those two I-D as "dead" and proceed anyway with the closing of
> Homenet.
>
> [2] a new home will need to be found for Ted Lemon's drafts on "stub
> networking"
>
>
>
> *From: *homenet  on behalf of Daniel Migault <
> mglt.i...@gmail.com>
> *Date: *Tuesday, 13 July 2021 at 23:28
> *To: *Chris Box 
> *Cc: *"homenet@ietf.org" 
> *Subject: *Re: [homenet] naming drafts
>
>
>
> Hi,
>
>
>
> Thanks for the follow up Chris. I apologize for the delay.
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Tue, Jun 22, 2021 at 12:31 PM Chris Box 
> wrote:
>
> Daniel,
>
>
>
> On Wed, 16 Jun 2021 at 01:27, Daniel Migault  wrote:
>
>
>
> The HNA SHOULD drop any packets arriving on the WAN interface that are
> not issued from the DM.
>
> Depending how the communications between the HNA and the DM are secured,
> only packets associated to that protocol SHOULD be allowed.
>
>
> The separation looks good, but I'd like to tweak the second paragraph. By
> "only packets associated to that protocol" do you mean destination port
> filtering?
>
>
>
> To me IP and port filtering are implemented by the previous line. "only
> packets associated with that protocol" to me means that only TLS packets
> are allowed.   The reason we are not mentioning TLS explicitly is that
> other protocols may be used.
>
>
>
> Ah, I see, so this is about the payload of the packets. But surely
> intelligent validation of the incoming packets is always going to happen?
> This is a key property of any security protocol.
>
> If the DM is listening on TCP 443, and the incoming packet is not a TLS
> Client Hello that it is happy with, it'll get ignored.
>
> If the DM is listening on UDP 500, and the incoming packet is not an
> IKE_SA_INIT that it is happy with, it'll get ignored.
>
>
>
> So I'm not disagreeing with you, I'm just questioning whether the sentence
> is needed. I don't really mind if it stays.
>
> This may not be necessary, but the reason I would pr

Re: [homenet] naming drafts

[Eric Vyncke (evyncke)]

As we are halfway between IETF-113 and IETF-114, it is time to make a check as 
I have seen no revised version for those 2 ‘naming’ drafts.

You may also have noticed that Ted’s ‘stub networking’ work is going in a SNAC 
BoF at IETF-114 (please attend and contribute to the 
s...@ietf.org<mailto:s...@ietf.org> mailing list).

Therefore, the plan is to close Homenet early July 2022 if nothing changes.

Hoping to see you in “Philly” to celebrate the achievments of Homenet !

Regards

-éric

From: homenet  on behalf of "Eric Vyncke (evyncke)" 

Date: Thursday, 14 April 2022 at 09:16
To: "homenet@ietf.org" 
Cc: "kiran.i...@gmail.com" , Michael Richardson 
, Daniel Migault , Stephen Farrell 

Subject: Re: [homenet] naming drafts

Dear Homenet,

After 9 months, it is time to resurrect this email thread and move forward with 
the 'naming drafts', which are still in WG Last Call since May 2021:

-  draft-ietf-homenet-front-end-naming-delegation

-  draft-ietf-homenet-naming-architecture-dhc-options

AT IETF-113, there was a meeting with two authors, the chairs, and I (as the 
responsible AD for Homenet). The plan is to give the authors a chance to issue 
a revised I-D considering Chris Blox's review as well as trying to improve the 
readability and flow of the text (which suffers from multiple revisions that 
have rendered the I-D difficult to read). Once done, the chairs will close the 
WGLC and will request publication to continue the process. This should be done 
by IETF-114 (July 2022) if not earlier.

About the DynDNS discussion of last year, I am in favor of going forward anyway 
with the homenet drafts and wait for the IETF Last Call + IESG evaluation to 
get a broader scope than the Homenet WG on this very specific topic.

Final point, the chairs and I have decided that once those 2 drafts have been 
approved by the IESG [1], then the Homenet WG can be closed after 11 years [2].

Of course, feedback and comments on the above are welcome.

Regards

-éric

[1] or if the publication is not requested before IETF-114, then I will declare 
those two I-D as "dead" and proceed anyway with the closing of Homenet.
[2] a new home will need to be found for Ted Lemon's drafts on "stub networking"

From: homenet  on behalf of Daniel Migault 

Date: Tuesday, 13 July 2021 at 23:28
To: Chris Box 
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] naming drafts

Hi,

Thanks for the follow up Chris. I apologize for the delay.

Yours,
Daniel

On Tue, Jun 22, 2021 at 12:31 PM Chris Box 
mailto:chris.box.i...@gmail.com>> wrote:
Daniel,

On Wed, 16 Jun 2021 at 01:27, Daniel Migault 
mailto:mglt.i...@gmail.com>> wrote:

The HNA SHOULD drop any packets arriving on the WAN interface that are not 
issued from the DM.
Depending how the communications between the HNA and the DM are secured, only 
packets associated to that protocol SHOULD be allowed.
The separation looks good, but I'd like to tweak the second paragraph. By "only 
packets associated to that protocol" do you mean destination port filtering?

To me IP and port filtering are implemented by the previous line. "only packets 
associated with that protocol" to me means that only TLS packets are allowed.   
The reason we are not mentioning TLS explicitly is that other protocols may be 
used.

Ah, I see, so this is about the payload of the packets. But surely intelligent 
validation of the incoming packets is always going to happen? This is a key 
property of any security protocol.
If the DM is listening on TCP 443, and the incoming packet is not a TLS Client 
Hello that it is happy with, it'll get ignored.
If the DM is listening on UDP 500, and the incoming packet is not an 
IKE_SA_INIT that it is happy with, it'll get ignored.

So I'm not disagreeing with you, I'm just questioning whether the sentence is 
needed. I don't really mind if it stays.
This may not be necessary, but the reason I would prefer to keep it is to head 
up that additional checks - when possible - may be performed in addition to 
port filtering. So unless you have a strong preference, I would prefer to keep 
this additional check that could be performed by the terminating node or a 
firewall.


I'm not concerned about the additional round trip. I was more concerned that 
the DM could be implemented as a frontend/backend architecture. The FQDN would 
resolve to the front end, and this is likely to be a small list of addresses, 
or even a single address. But the backend servers would have distinct, 
different addresses. Connections from the DM to the HNA might be initiated from 
the backend. If the HNA only looked up the FQDN, it would drop legitimate 
connections. This suggests we need a way to inform the HNA of the set of 
legitimate source addresses.


What did you think of this last point?

I see your point.   The architecture document envisioned this case by 
specifying the dm_acl parame

Re: [homenet] naming drafts

[Eric Vyncke (evyncke)]

Dear Homenet,

After 9 months, it is time to resurrect this email thread and move forward with 
the 'naming drafts', which are still in WG Last Call since May 2021:

  *   draft-ietf-homenet-front-end-naming-delegation

-  draft-ietf-homenet-naming-architecture-dhc-options

AT IETF-113, there was a meeting with two authors, the chairs, and I (as the 
responsible AD for Homenet). The plan is to give the authors a chance to issue 
a revised I-D considering Chris Blox's review as well as trying to improve the 
readability and flow of the text (which suffers from multiple revisions that 
have rendered the I-D difficult to read). Once done, the chairs will close the 
WGLC and will request publication to continue the process. This should be done 
by IETF-114 (July 2022) if not earlier.

About the DynDNS discussion of last year, I am in favor of going forward anyway 
with the homenet drafts and wait for the IETF Last Call + IESG evaluation to 
get a broader scope than the Homenet WG on this very specific topic.

Final point, the chairs and I have decided that once those 2 drafts have been 
approved by the IESG [1], then the Homenet WG can be closed after 11 years [2].

Of course, feedback and comments on the above are welcome.

Regards

-éric

[1] or if the publication is not requested before IETF-114, then I will declare 
those two I-D as "dead" and proceed anyway with the closing of Homenet.
[2] a new home will need to be found for Ted Lemon's drafts on "stub networking"

From: homenet  on behalf of Daniel Migault 

Date: Tuesday, 13 July 2021 at 23:28
To: Chris Box 
Cc: "homenet@ietf.org" 
Subject: Re: [homenet] naming drafts

Hi,

Thanks for the follow up Chris. I apologize for the delay.

Yours,
Daniel

On Tue, Jun 22, 2021 at 12:31 PM Chris Box 
mailto:chris.box.i...@gmail.com>> wrote:
Daniel,

On Wed, 16 Jun 2021 at 01:27, Daniel Migault 
mailto:mglt.i...@gmail.com>> wrote:

The HNA SHOULD drop any packets arriving on the WAN interface that are not 
issued from the DM.
Depending how the communications between the HNA and the DM are secured, only 
packets associated to that protocol SHOULD be allowed.
The separation looks good, but I'd like to tweak the second paragraph. By "only 
packets associated to that protocol" do you mean destination port filtering?

To me IP and port filtering are implemented by the previous line. "only packets 
associated with that protocol" to me means that only TLS packets are allowed.   
The reason we are not mentioning TLS explicitly is that other protocols may be 
used.

Ah, I see, so this is about the payload of the packets. But surely intelligent 
validation of the incoming packets is always going to happen? This is a key 
property of any security protocol.
If the DM is listening on TCP 443, and the incoming packet is not a TLS Client 
Hello that it is happy with, it'll get ignored.
If the DM is listening on UDP 500, and the incoming packet is not an 
IKE_SA_INIT that it is happy with, it'll get ignored.

So I'm not disagreeing with you, I'm just questioning whether the sentence is 
needed. I don't really mind if it stays.
This may not be necessary, but the reason I would prefer to keep it is to head 
up that additional checks - when possible - may be performed in addition to 
port filtering. So unless you have a strong preference, I would prefer to keep 
this additional check that could be performed by the terminating node or a 
firewall.


I'm not concerned about the additional round trip. I was more concerned that 
the DM could be implemented as a frontend/backend architecture. The FQDN would 
resolve to the front end, and this is likely to be a small list of addresses, 
or even a single address. But the backend servers would have distinct, 
different addresses. Connections from the DM to the HNA might be initiated from 
the backend. If the HNA only looked up the FQDN, it would drop legitimate 
connections. This suggests we need a way to inform the HNA of the set of 
legitimate source addresses.


What did you think of this last point?

I see your point.   The architecture document envisioned this case by 
specifying the dm_acl parameter in the informative section 14.
We did not include it into the DHCP option as we were requested to implement 
the simplest use case that is envisioned. My understanding was that DHCP 
Options had some history where complex options had been designed but hardly 
used.
That said, if that is something you believe is really needed, we may bring this 
discussion and add this parameter to the current DHCP Options. It still 
represents a minor change as already considered in the architecture document.

Another alternative may also consider adding an extension so the acl may be 
negotiated through the control channel, which I see more scalable than 
designing large DHCP options. At that point, I would rather keep the 
architecture as it is a let such option for future wo

Re: [homenet] naming drafts

[Daniel Migault]

Hi,

Thanks for the follow up Chris. I apologize for the delay.

Yours,
Daniel

On Tue, Jun 22, 2021 at 12:31 PM Chris Box  wrote:

> Daniel,
>
> On Wed, 16 Jun 2021 at 01:27, Daniel Migault  wrote:
>
>>
>>> The HNA SHOULD drop any packets arriving on the WAN interface that are
 not issued from the DM.


 Depending how the communications between the HNA and the DM are
 secured, only packets associated to that protocol SHOULD be allowed.


>>> The separation looks good, but I'd like to tweak the second paragraph.
>>> By "only packets associated to that protocol" do you mean destination port
>>> filtering?
>>>
>>
>> To me IP and port filtering are implemented by the previous line. "only
>> packets associated with that protocol" to me means that only TLS packets
>> are allowed.   The reason we are not mentioning TLS explicitly is that
>> other protocols may be used.
>>
>
> Ah, I see, so this is about the payload of the packets. But surely
> intelligent validation of the incoming packets is always going to happen?
> This is a key property of any security protocol.
> If the DM is listening on TCP 443, and the incoming packet is not a TLS
> Client Hello that it is happy with, it'll get ignored.
> If the DM is listening on UDP 500, and the incoming packet is not an
> IKE_SA_INIT that it is happy with, it'll get ignored.
>
> So I'm not disagreeing with you, I'm just questioning whether the sentence
> is needed. I don't really mind if it stays.
>
This may not be necessary, but the reason I would prefer to keep it is to
head up that additional checks - when possible - may be performed in
addition to port filtering. So unless you have a strong preference, I would
prefer to keep this additional check that could be performed by the
terminating node or a firewall.

>
>
>>
>>> I'm not concerned about the additional round trip. I was more concerned
>>> that the DM could be implemented as a frontend/backend architecture. The
>>> FQDN would resolve to the front end, and this is likely to be a small list
>>> of addresses, or even a single address. But the backend servers would have
>>> distinct, different addresses. Connections from the DM to the HNA might be
>>> initiated from the backend. If the HNA only looked up the FQDN, it would
>>> drop legitimate connections. This suggests we need a way to inform the HNA
>>> of the set of legitimate source addresses.
>>>
>>>
> What did you think of this last point?
>

I see your point.   The architecture document envisioned this case by
specifying the dm_acl parameter in the informative section 14.
We did not include it into the DHCP option as we were requested to
implement the simplest use case that is envisioned. My understanding was
that DHCP Options had some history where complex options had been designed
but hardly used.
That said, if that is something you believe is really needed, we may bring
this discussion and add this parameter to the current DHCP Options. It
still represents a minor change as already considered in the architecture
document.

Another alternative may also consider adding an extension so the acl may be
negotiated through the control channel, which I see more scalable than
designing large DHCP options. At that point, I would rather keep the
architecture as it is a let such option for future work - though fairly
easy to set.




> Chris
>


-- 
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Chris Box]

Daniel,

On Wed, 16 Jun 2021 at 01:27, Daniel Migault  wrote:

>
>> The HNA SHOULD drop any packets arriving on the WAN interface that are
>>> not issued from the DM.
>>>
>>>
>>> Depending how the communications between the HNA and the DM are
>>> secured, only packets associated to that protocol SHOULD be allowed.
>>>
>>>
>> The separation looks good, but I'd like to tweak the second paragraph. By
>> "only packets associated to that protocol" do you mean destination port
>> filtering?
>>
>
> To me IP and port filtering are implemented by the previous line. "only
> packets associated with that protocol" to me means that only TLS packets
> are allowed.   The reason we are not mentioning TLS explicitly is that
> other protocols may be used.
>

Ah, I see, so this is about the payload of the packets. But surely
intelligent validation of the incoming packets is always going to happen?
This is a key property of any security protocol.
If the DM is listening on TCP 443, and the incoming packet is not a TLS
Client Hello that it is happy with, it'll get ignored.
If the DM is listening on UDP 500, and the incoming packet is not an
IKE_SA_INIT that it is happy with, it'll get ignored.

So I'm not disagreeing with you, I'm just questioning whether the sentence
is needed. I don't really mind if it stays.


>
>> I'm not concerned about the additional round trip. I was more concerned
>> that the DM could be implemented as a frontend/backend architecture. The
>> FQDN would resolve to the front end, and this is likely to be a small list
>> of addresses, or even a single address. But the backend servers would have
>> distinct, different addresses. Connections from the DM to the HNA might be
>> initiated from the backend. If the HNA only looked up the FQDN, it would
>> drop legitimate connections. This suggests we need a way to inform the HNA
>> of the set of legitimate source addresses.
>>
>>
What did you think of this last point?

Chris
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Daniel Migault]

Hi Chris,

Thanks for the follow-up. Please find more details and specific responses
to your questions and comments below. I also just pushed the changes you
recommended for the DHCP options.

Thanks!

Yours,
Daniel

On Tue, Jun 15, 2021 at 1:10 PM Chris Box  wrote:

> Hi Daniel.  Responses inline below.
>
> On Tue, 15 Jun 2021 at 02:58, Daniel Migault  wrote:
>
>>
>>>
>> """
>> Limited exchanges:
>> : the purpose of the Hidden Primary Server is to synchronize with the DM,
>> not to serve any zones to end users, or the public Internet.
>> This results in a limited exchanges (AXFR/IXFR) with a small number of IP
>> address and such limitations SHOULD be enforced by policies describe din
>>  {{sec-cpe-sec-policies}}.
>> """
>>
>
> I'm happy with that.
>
>
>> 7 I'd prefer not to use the word "packets" when it's really messages that
>>> we considering. Also in my opinion invalid messages to/from the DM ought to
>>> be rejected rather than simply dropped.
>>>
>>> Here's my suggested version, with changes highlighted in red:
>>>The Hidden Primary SHOULD drop any packets arriving on
>>>the WAN interface that are not issued from the DM.  The Hidden
>>>Primary SHOULD NOT send DNS messages other than DNS NOTIFY query,
>>>SOA response, IXFR response or AXFR responses.  The Hidden Primary
>>>SHOULD reject any incoming messages other than DNS NOTIFY response,
>>> SOA
>>>query, IXFR query or AXFR query.  The Hidden Primary SHOULD reject
>>> any
>>>non protected IXFR or AXFR exchange, depending on how the
>>>synchronization is secured.
>>>
>>>
>> My interpretation between drop and reject is that drop does not provide
>> any response and acts as if the service does not exist while reject allows
>> responding with an error which in this case indicates the service exists
>> and has blocked the traffic.
>>
>
> I have the same interpretation.
>
>
>> The way we envisioned these policies is enforced by a firewall (as
>> opposed to the HNA itself) so the intention is to protect the HNA -
>> including hiding the HNA, in which case dropping seems the most obvious way
>> to implement these policies.
>> Now, since the traffic is protected by TLS, the rules associated with the
>> HNA are more application specific rules, and we can envision that with a
>> trusted peer, rejection might be more appropriate.
>>
>
> Agree, rejection is better when the trusted peer sends an invalid message.
>
>
>>
>> To address your comment I propose to differentiate the DNS rules from
>> what can be implemented by a firewall and take a large part of the text you
>> proposed resulting in the following text:
>>
>> """
>> The HNA SHOULD drop any packets arriving on the WAN interface that are
>> not issued from the DM.
>>
>>
>> Depending how the communications between the HNA and the DM are secured,
>> only packets associated to that protocol SHOULD be allowed.
>>
>>
>>
>>
>> At the DNS level, the HNA SHOULD NOT send DNS messages other than DNS
>> NOTIFY query, SOA response, IXFR response or AXFR responses.
>>
>> The HNA SHOULD reject any incoming messages other than DNS NOTIFY
>> response, SOA query, IXFR query or AXFR query.
>> """
>>
>
> The separation looks good, but I'd like to tweak the second paragraph. By
> "only packets associated to that protocol" do you mean destination port
> filtering?
>

To me IP and port filtering are implemented by the previous line. "only
packets associated with that protocol" to me means that only TLS packets
are allowed.   The reason we are not mentioning TLS explicitly is that
other protocols may be used.

>
> 12 This acknowledges that it's a little risky to publish names of home
>>> devices publicly, and notes that often it's only the home owner or
>>> immediate family that ought to be able to query these names. It says that
>>> limiting ability to query can be done by IP source (IMHO tricky), or VPN.
>>> To which I think, if the home owner is using a VPN to the home to query the
>>> public zone, why do we need external publication at all? Some words to
>>> explain that better might be useful.
>>>
>>>
>> I have added some text to provide some explanations. It is correct that
>> if all your traffic is redirected in the home network, then there is little
>> interest in publishing all the names as they will only be accessed
>> internally. The text was trying to mention that a node may be willing to
>> set different policies for its traffic. Typically the web traffic is not
>> tunneled while the traffic to the homenet is tunneled. In this case, the
>> ability to define which IP address needs to be tunneled and which IP
>> address does not need to be tunneled requires to have this IP address so to
>> be able to publicly perform a DNS resolution.   The added text is as
>> follows:
>>
>> """
>> In such cases, the routing policy is likely to be defined by the
>> destination IP address.
>> This IP address potentially results from a DNS resolution over the
>> Internet.
>> """
>>
>
> So let's 

Re: [homenet] naming drafts

[Chris Box]

Hi Daniel.  Responses inline below.

On Tue, 15 Jun 2021 at 02:58, Daniel Migault  wrote:

>
>>
> """
> Limited exchanges:
> : the purpose of the Hidden Primary Server is to synchronize with the DM,
> not to serve any zones to end users, or the public Internet.
> This results in a limited exchanges (AXFR/IXFR) with a small number of IP
> address and such limitations SHOULD be enforced by policies describe din
>  {{sec-cpe-sec-policies}}.
> """
>

I'm happy with that.


> 7 I'd prefer not to use the word "packets" when it's really messages that
>> we considering. Also in my opinion invalid messages to/from the DM ought to
>> be rejected rather than simply dropped.
>>
>> Here's my suggested version, with changes highlighted in red:
>>The Hidden Primary SHOULD drop any packets arriving on
>>the WAN interface that are not issued from the DM.  The Hidden
>>Primary SHOULD NOT send DNS messages other than DNS NOTIFY query,
>>SOA response, IXFR response or AXFR responses.  The Hidden Primary
>>SHOULD reject any incoming messages other than DNS NOTIFY response,
>> SOA
>>query, IXFR query or AXFR query.  The Hidden Primary SHOULD reject any
>>non protected IXFR or AXFR exchange, depending on how the
>>synchronization is secured.
>>
>>
> My interpretation between drop and reject is that drop does not provide
> any response and acts as if the service does not exist while reject allows
> responding with an error which in this case indicates the service exists
> and has blocked the traffic.
>

I have the same interpretation.


> The way we envisioned these policies is enforced by a firewall (as opposed
> to the HNA itself) so the intention is to protect the HNA - including
> hiding the HNA, in which case dropping seems the most obvious way to
> implement these policies.
> Now, since the traffic is protected by TLS, the rules associated with the
> HNA are more application specific rules, and we can envision that with a
> trusted peer, rejection might be more appropriate.
>

Agree, rejection is better when the trusted peer sends an invalid message.


>
> To address your comment I propose to differentiate the DNS rules from what
> can be implemented by a firewall and take a large part of the text you
> proposed resulting in the following text:
>
> """
> The HNA SHOULD drop any packets arriving on the WAN interface that are
> not issued from the DM.
>
> Depending how the communications between the HNA and the DM are secured,
> only packets associated to that protocol SHOULD be allowed.
>
>
>
>
> At the DNS level, the HNA SHOULD NOT send DNS messages other than DNS
> NOTIFY query, SOA response, IXFR response or AXFR responses.
>
> The HNA SHOULD reject any incoming messages other than DNS NOTIFY
> response, SOA query, IXFR query or AXFR query.
> """
>

The separation looks good, but I'd like to tweak the second paragraph. By
"only packets associated to that protocol" do you mean destination port
filtering?

12 This acknowledges that it's a little risky to publish names of home
>> devices publicly, and notes that often it's only the home owner or
>> immediate family that ought to be able to query these names. It says that
>> limiting ability to query can be done by IP source (IMHO tricky), or VPN.
>> To which I think, if the home owner is using a VPN to the home to query the
>> public zone, why do we need external publication at all? Some words to
>> explain that better might be useful.
>>
>>
> I have added some text to provide some explanations. It is correct that if
> all your traffic is redirected in the home network, then there is little
> interest in publishing all the names as they will only be accessed
> internally. The text was trying to mention that a node may be willing to
> set different policies for its traffic. Typically the web traffic is not
> tunneled while the traffic to the homenet is tunneled. In this case, the
> ability to define which IP address needs to be tunneled and which IP
> address does not need to be tunneled requires to have this IP address so to
> be able to publicly perform a DNS resolution.   The added text is as
> follows:
>
> """
> In such cases, the routing policy is likely to be defined by the
> destination IP address.
> This IP address potentially results from a DNS resolution over the
> Internet.
> """
>

So let's consider this use case where access to homenet devices is required
to be via VPN to the home. In theory, only one address needs to be
published externally. This is the current WAN IP of the home's VPN
termination point. Then the steps to access a particular smart device would
be:
1. Look up address of the home's VPN server.
2. Establish VPN.
3. From the VPN, the client learns the set of home-specific routes, and the
address of the Homenet Resolver that it should use.
4. Client queries the Homenet Resolver (over the VPN) for the address of
the smart device.
5. Client establishes connection to the smart device, over the VPN.

For this use case, 

Re: [homenet] naming drafts

[Daniel Migault]

Thank you very much Chris for the review. That was very useful.  I have
updated the two documents according to your reviews. The resulting
architecture document is available here [1] and the resulting DHCP document
is available here [2].

You can also find a more detailed response inline.

Thanks again for the review!

Yours,
Daniel

[1]
https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/f1cb4c679b8b8f96bdeddcf056cdbe4e80f91c25

[2]
https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/f4608d0ee2718c7d3747c848b5cbba028653c2e0

On Thu, Jun 10, 2021 at 1:21 PM Chris Box  wrote:

> Hi everyone
>
> I have belatedly reviewed both drafts. I missed the WGLC due to both
> $dayjob and the IETF having a plethora of interesting working groups. But
> still, I hope this feedback is useful
>
> In general, I appreciate the aim of the drafts which I will paraphrase as
> creating a way to automatically and reliably publish a home zone containing
> a number (n) of smart devices. This makes a lot of sense when we know n is
> going to carry on growing, and of course renumbering can be frequent.
>
> My specific feedback is below, organised by section number.
>
> *draft-ietf-homenet-front-end-naming-delegation-15*
> 1 It would be useful if the introductory text in the Abstract also
> appeared here in the Introduction.
>
>

we added the text at the beginning of the introduction


> 1.1 Typos: "humuan" and "addressees "
>

corrected. Thanks.


>
> 3.1 I'd prefer the diagram to be located at the beginning of this section.
>

The figure has been moved at the beginning of the section.


> 4.7 This section should also state, as it does in section 7, that the
> Hidden Primary Server be firewalled such that only the known address range
> of the DMs are permitted to connect to it.
>

Good catch.  Looking at the two sections, it looks these are a little bit
redundant, so rather than repeating the rules I prefered to suggest
firewalling as detailed in section 7.

This basically results by the text below:
"""
Limited exchanges:
: the purpose of the Hidden Primary Server is to synchronize with the DM,
not to serve any zones to end users, or the public Internet.
This results in a limited exchanges (AXFR/IXFR) with a small number of IP
address and such limitations SHOULD be enforced by policies describe din
 {{sec-cpe-sec-policies}}.
"""

>
> 7 I'd prefer not to use the word "packets" when it's really messages that
> we considering. Also in my opinion invalid messages to/from the DM ought to
> be rejected rather than simply dropped.
>
> Here's my suggested version, with changes highlighted in red:
>The Hidden Primary SHOULD drop any packets arriving on
>the WAN interface that are not issued from the DM.  The Hidden
>Primary SHOULD NOT send DNS messages other than DNS NOTIFY query,
>SOA response, IXFR response or AXFR responses.  The Hidden Primary
>SHOULD reject any incoming messages other than DNS NOTIFY response, SOA
>query, IXFR query or AXFR query.  The Hidden Primary SHOULD reject any
>non protected IXFR or AXFR exchange, depending on how the
>synchronization is secured.
>
>
My interpretation between drop and reject is that drop does not provide any
response and acts as if the service does not exist while reject allows
responding with an error which in this case indicates the service exists
and has blocked the traffic.

The way we envisioned these policies is enforced by a firewall (as opposed
to the HNA itself) so the intention is to protect the HNA - including
hiding the HNA, in which case dropping seems the most obvious way to
implement these policies.
Now, since the traffic is protected by TLS, the rules associated with the
HNA are more application specific rules, and we can envision that with a
trusted peer, rejection might be more appropriate.

To address your comment I propose to differentiate the DNS rules from what
can be implemented by a firewall and take a large part of the text you
proposed resulting in the following text:

"""
The HNA SHOULD drop any packets arriving on the WAN interface that are not
issued from the DM.

Depending how the communications between the HNA and the DM are secured,
only packets associated to that protocol SHOULD be allowed.



At the DNS level, the HNA SHOULD NOT send DNS messages other than DNS
NOTIFY query, SOA response, IXFR response or AXFR responses.

The HNA SHOULD reject any incoming messages other than DNS NOTIFY response,
SOA query, IXFR query or AXFR query.
"""


> 12 This acknowledges that it's a little risky to publish names of home
> devices publicly, and notes that often it's only the home owner or
> immediate family that ought to be able to query these names. It says that
> limiting ability to query can be done by IP source (IMHO tricky), or VPN.
> To which I think, if the home owner is using a VPN to the home to query the
> public zone, why do we need external publication at all? Some words to
> explain that 

Re: [homenet] naming drafts

[Chris Box]

Hi everyone

I have belatedly reviewed both drafts. I missed the WGLC due to both
$dayjob and the IETF having a plethora of interesting working groups. But
still, I hope this feedback is useful

In general, I appreciate the aim of the drafts which I will paraphrase as
creating a way to automatically and reliably publish a home zone containing
a number (n) of smart devices. This makes a lot of sense when we know n is
going to carry on growing, and of course renumbering can be frequent.

My specific feedback is below, organised by section number.

*draft-ietf-homenet-front-end-naming-delegation-15*
1 It would be useful if the introductory text in the Abstract also appeared
here in the Introduction.

1.1 Typos: "humuan" and "addressees "

3.1 I'd prefer the diagram to be located at the beginning of this section.

4.7 This section should also state, as it does in section 7, that the
Hidden Primary Server be firewalled such that only the known address range
of the DMs are permitted to connect to it.

7 I'd prefer not to use the word "packets" when it's really messages that
we considering. Also in my opinion invalid messages to/from the DM ought to
be rejected rather than simply dropped.

Here's my suggested version, with changes highlighted in red:
   The Hidden Primary SHOULD drop any packets arriving on
   the WAN interface that are not issued from the DM.  The Hidden
   Primary SHOULD NOT send DNS messages other than DNS NOTIFY query,
   SOA response, IXFR response or AXFR responses.  The Hidden Primary
   SHOULD reject any incoming messages other than DNS NOTIFY response, SOA
   query, IXFR query or AXFR query.  The Hidden Primary SHOULD reject any
   non protected IXFR or AXFR exchange, depending on how the
   synchronization is secured.

12 This acknowledges that it's a little risky to publish names of home
devices publicly, and notes that often it's only the home owner or
immediate family that ought to be able to query these names. It says that
limiting ability to query can be done by IP source (IMHO tricky), or VPN.
To which I think, if the home owner is using a VPN to the home to query the
public zone, why do we need external publication at all? Some words to
explain that better might be useful.


*draft-ietf-homenet-naming-architecture-dhc-options-14*

3 In both American and British English I think the word "collocate" should
be "colocate" (or alternatively "co-locate").

3 What exactly is meant by "(eventually by a self signed certificate)"?

4.2 I think the HNA also needs to learn the set of IP addresses that the DM
might legitimately use in order to contact the HNA, so that these IPs can
be whitelisted in the CPE's firewall. Simply looking up the FQDN doesn't
provide that. Should it be added to this DHCP option?


Hope that's useful.

Thanks,
Chris


On Fri, 4 Jun 2021 at 20:45, STARK, BARBARA H  wrote:

> Hi homenet WG,
> Stephen and I have been chatting about the status of the 2 naming drafts
> (draft-ietf-homenet-front-end-naming-delegation and
> draft-ietf-homenet-naming-architecture-dhc-options).
>
> We started a 3-week WGLC about a month ago (04 May). Both drafts received
> comprehensive review from Med. Stephen reviewed
> front-end-naming-delegation. Bernie reviewed the formatting of the DHC
> option.
> The authors provided updates to resolve these comments. Bernie
> acknowledged satisfactory resolution of his comments.
> Requests to change terminology were satisfactorily resolved -- but that
> discussion doesn't count as really being part of anyone's review of the
> drafts.
> Stephen and Juliusz expressed that they're still not convinced that DDNS
> isn't a good enough solution for the use case.
>
> Stephen and I do not believe these drafts have received enough review or
> support to put them forward as representing WG consensus.
>
> But the authors have spent significant effort in creating these drafts and
> the associated implementation. We will work with Éric V (as INT area AD)
> and the authors to determine next steps.
>
> Barbara and Stephen
>
> ___
> 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] naming drafts

[Michael Richardson]

sf> Sure, and as I said I'm not opposed to that. I suspect the
sf> best thing is for the authors to chat with our AD and see
sf> if he's either willing to AD-sponsor it, or to ask another
sf> WG to adopt, or try find a dispatch-like process to see if
sf> enough interest/review can be found that way.

It's the WG's document, and the WG can abandon it if it likes.
That would require some consensus seeking discussing.

If it turns out the WG isn't interested in the document, I sure wish that the
WG had said so a year ago though.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Daniel Migault]

Hi Stephen,

I am just replying to clarify I am not complaining about you personally or
even your review. If further discussions are needed I am happy to set a
call at any time as email does not seem to me the most constructive path.

Yours,
Daniel

On Tue, Jun 8, 2021 at 10:10 AM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 08/06/2021 14:55, Daniel Migault wrote:
> > I disagree that discussing whether the proposal will take over DDNS
> > is a side discussion that unfortunately happens at a bad time.
>
> Sorry, I don't get what you mean.
>

Let me try to provide more background. I am reading or interpreting your
response to Ray (quoted below) that the discussion on whether the proposal
will take over DDNS is a simple discussion that does not have any
consequences. I disagree with that. It seems that raising such discussion
during a WGLC has consequences, perhaps because I do not see the technical
aspect of the discussion.

"""
It was one amongst a bunch of personal comments I sent. And that I'm happy
to discuss with the authors without wearing any chair or other hat.
"""

>
> > If I
> > interpret the WGLC report, it is clearly noted as a lack of support.
>
> No. It's me being critical of the text. I neither support
> nor oppose this stuff, but the arguments presented for that
> part aren't convincing IMO, which is what my comment said.
>

The lack of support appeared to me in the WGLC quoted below which mentions
"not enough support". I interpreted this as partly resulting from
challenging the proposal but maybe I am mis-interpreting this, though I
understand it also included partly a number of reviews.

"""
Stephen and I do not believe these drafts have received enough review or
support to put them forward as representing WG consensus.
"""

If I interprete "neither support nor oppose" of your response as being
neutral, I do have hard time to read it from the WGLC report which describe
your position as follows:

"""
Stephen and Juliusz expressed that they're still not convinced that DDNS
isn't a good enough solution for the use case.
"""

That said, I am fine that there are different opinions and people have
different predictions, as long as we agree these remain personal opinions
that should not influence moving the document forward. This is not clear to
me this is the way it is interpreted.


> >
> > Predictions are not a technical discussion and can be very wrong (
> > "we will never make a 32 bit operating system", "there is no reason
> > anyone would want a computer in their home"... the list can be as
> > long as we wish). It should not be considered in the decision to move
> > the document forward. Will it replace DDNS - I do not know. Not more
> > than Stephen or Juliusz. I am happy to have this discussion in 2
> > years. Today it gives a toxic tone to the discussion.
>
> Toxic? That's seems quite overblown. And plain wrong, if
> you mean it to describe my review. I can understand the
> frustration of working on something like this and not
> seeing it progress as planned, but accusing me of creating
> toxicity is not a fair accusation for you to make.
>
> I am not accusing anyone. The discussion is toxic in my point of view
because at this point it is very hard to engage someone into reviewing the
doc, as it is asking him to take a position in favor of or against some
parties. I do not believe that this results from your review, but rather
how your review has been summarized and has influenced the chair's
decision. Reviews are always welcome.


> > I agree that more reviews is always preferred, but I am wondering how
> > many reviews would have been considered sufficient.
>
> Oh come on - we've tried a number of times to get people
> to review these documents and we've never really gotten
> that to happen. The level of review is nowhere near
> sufficient to declare some meaningful WG consensus.
>

The question concerned the number of reviews that would have been
considered sufficient. I do not understand how this can be interpreted as
chairs not making enough effort to get reviews. It was not my intent. That
said, I remember that people committed to review, and maybe a reminder
would have been welcome.


>
> > Looking at the
> > homenet mailing list we can see that the number of reviews reflects
> > the participation of the mailing list.
>
> That's true. I think it may be time to recognise reality
> and close the WG perhaps.
>
>
I do not think that was not predictable, nor something that we learned
during this WGLC. If we had some other specific expectations, those should
have been clearly provided. And it is still unclear to me how many reviews
were expected for example.


> > Though I really value your
> > review, I am not sure that (even with no hat) it encourages
> > additional reviews, as it forces the potential reviewer to take
> > position against the opinion of the chair. It seems to me that, if
> > the number of reviews were an issue, this could have been addressed
> > otherwise.
>
> Sorry, 

Re: [homenet] naming drafts

[Michael Richardson]

Juliusz Chroboczek  wrote:
> Michael, it would probably take you 20 minutes to write up an I-D
> describing a reasonable REST-based DDNS protocol, another 5 minutes to
> write a client implementation in Javascript, and one hour to write
> a robust server that is well integrated with Bind.

Yes, I did that.  It's in front of you.
As you said, there are three different specifications: why didn't you pick one?

We went back and forth multiple times as to REST vs AXFR from the HNA.
The feedback *FROM DNS OPERATORS* (which you aren't) was that they preferred 
AXFR.

>> If the device renumbers, or experiences a flash renumbering, how does it
>> know to re-register?

> All of these are interesting issues.  However, I don't see how they depend
> on whether the update is carried over HTTPS or AXFR.

It sure does, because DDNS as described by you is done by the end-device,
which can't see the IPv4 renumber, which btw, is all those devices support.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Stephen Farrell]

Hiya,

On 08/06/2021 14:55, Daniel Migault wrote:

I disagree that discussing whether the proposal will take over DDNS
is a side discussion that unfortunately happens at a bad time. 


Sorry, I don't get what you mean.


If I
interpret the WGLC report, it is clearly noted as a lack of support.


No. It's me being critical of the text. I neither support
nor oppose this stuff, but the arguments presented for that
part aren't convincing IMO, which is what my comment said.



Predictions are not a technical discussion and can be very wrong (
"we will never make a 32 bit operating system", "there is no reason
anyone would want a computer in their home"... the list can be as
long as we wish). It should not be considered in the decision to move
the document forward. Will it replace DDNS - I do not know. Not more
than Stephen or Juliusz. I am happy to have this discussion in 2
years. Today it gives a toxic tone to the discussion.


Toxic? That's seems quite overblown. And plain wrong, if
you mean it to describe my review. I can understand the
frustration of working on something like this and not
seeing it progress as planned, but accusing me of creating
toxicity is not a fair accusation for you to make.


I agree that more reviews is always preferred, but I am wondering how
many reviews would have been considered sufficient.


Oh come on - we've tried a number of times to get people
to review these documents and we've never really gotten
that to happen. The level of review is nowhere near
sufficient to declare some meaningful WG consensus.


Looking at the
homenet mailing list we can see that the number of reviews reflects
the participation of the mailing list.


That's true. I think it may be time to recognise reality
and close the WG perhaps.


Though I really value your
review, I am not sure that (even with no hat) it encourages
additional reviews, as it forces the potential reviewer to take
position against the opinion of the chair. It seems to me that, if
the number of reviews were an issue, this could have been addressed
otherwise.


Sorry, that doesn't make sense. As chair I wouldn't ask
for it to be published without doing my own personal review.
And I refuse to guarantee all such reviews will be positive.


From my perspective all comments have been responded to, and
technical

comments have been addressed.


Personally, I don't agree. As chair, I think it's moot,
as we don't have sufficient review to declare consensus
either way. (To be clear - the DDNS point is also moot
in terms of whether or not the technical comments have
been handled - that was a non-nit editorial point.)


Regarding the support, the proposal was initiated by an ISP. Today, I
am interested in this proposal because we have some demand for it.
That some folks prefer using DDNS for their own purpose is orthogonal
to us. This is why we want it to be published.


Sure, and as I said I'm not opposed to that. I suspect the
best thing is for the authors to chat with our AD and see
if he's either willing to AD-sponsor it, or to ask another
WG to adopt, or try find a dispatch-like process to see if
enough interest/review can be found that way.

Cheers,
S.




Yours, Daniel

On Tue, Jun 8, 2021 at 6:06 AM Stephen Farrell
 wrote:



Hiya,

On 08/06/2021 10:29, Ray Hunter (v6ops) wrote:


Just trying to understand this hurdle/ line of reasoning.

So in addition to achieving "rough consensus", the IETF
standardization process must also produce drafts that are very
likely to gain traction to displace non-IETF non-standardised
products that are already widely commercially deployed?


No. This is not a process hurdle. It was one amongst a bunch of
personal comments I sent. And that I'm happy to discuss with the
authors without wearing any chair or other hat.

The process problem with these drafts is the lack of review means
there's no way to claim they represent any useful level of WG
consensus.

Cheers, S.

___ homenet mailing
list homenet@ietf.org 
https://www.ietf.org/mailman/listinfo/homenet







OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Daniel Migault]

I disagree that discussing whether the proposal will take over DDNS is a
side discussion that unfortunately happens at a bad time. If I interpret
the WGLC report, it is clearly noted as a lack of support.

Predictions are not a technical discussion and can be very wrong ( "we will
never make a 32 bit operating system", "there is no reason anyone would
want a computer in their home"... the list can be as long as we wish). It
should not be considered in the decision to move the document forward. Will
it replace DDNS - I do not know. Not more than Stephen or Juliusz. I am
happy to have this discussion in 2 years. Today it gives a toxic tone to
the discussion.

I agree that more reviews is always preferred, but I am wondering how many
reviews would have been considered sufficient. Looking at the homenet
mailing list we can see that the number of reviews reflects the
participation of the mailing list. Though I really value your review, I am
not sure that (even with no hat) it encourages additional reviews, as it
forces the potential reviewer to take position against the opinion of the
chair. It seems to me that, if the number of reviews were an issue, this
could have been addressed otherwise.

>From my perspective all comments have been responded to, and technical
comments have been addressed.

Regarding the support, the proposal was initiated by an ISP. Today, I am
interested in this proposal because we have some demand for it. That some
folks prefer using DDNS for their own purpose is orthogonal to us. This is
why we want it to be published.

Yours,
Daniel

On Tue, Jun 8, 2021 at 6:06 AM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 08/06/2021 10:29, Ray Hunter (v6ops) wrote:
> >
> > Just trying to understand this hurdle/ line of reasoning.
> >
> > So in addition to achieving "rough consensus", the IETF standardization
> > process must also produce drafts that are very likely to gain traction
> > to displace non-IETF non-standardised products that are already widely
> > commercially deployed?
>
> No. This is not a process hurdle. It was one amongst
> a bunch of personal comments I sent. And that I'm happy
> to discuss with the authors without wearing any chair
> or other hat.
>
> The process problem with these drafts is the lack of
> review means there's no way to claim they represent any
> useful level of WG consensus.
>
> Cheers,
> S.
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>


-- 
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Juliusz Chroboczek]

>> https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA/

> I didn't find any clear definition of how DDNS works in that email.

[...]
> What's the Performance Specification that describes this process?  Yes,
> I know where the vendor specific documentation is.

As far as I'm aware, all the REST-like DDNS protocols are vendor-specific.
However, they are widely deployed.  To give a data point, the ISP-provided
CPE I'm using right now implements no less than three distinct vendor
protocols for name registration (disabled by default, thankfully).

Michael, it would probably take you 20 minutes to write up an I-D
describing a reasonable REST-based DDNS protocol, another 5 minutes to
write a client implementation in Javascript, and one hour to write
a robust server that is well integrated with Bind.

> Second, how are the credentials for that communication established?
> [...]  What name does your NAS pick?  [...] Once the 14 year old in the
> house does this, how does the parent find out about the name that was
> used?

[...]

> If the device renumbers, or experiences a flash renumbering, how does it
> know to re-register?

All of these are interesting issues.  However, I don't see how they depend
on whether the update is carried over HTTPS or AXFR.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Stephen Farrell]

Hiya,

On 08/06/2021 10:29, Ray Hunter (v6ops) wrote:


Just trying to understand this hurdle/ line of reasoning.

So in addition to achieving "rough consensus", the IETF standardization 
process must also produce drafts that are very likely to gain traction 
to displace non-IETF non-standardised products that are already widely 
commercially deployed?


No. This is not a process hurdle. It was one amongst
a bunch of personal comments I sent. And that I'm happy
to discuss with the authors without wearing any chair
or other hat.

The process problem with these drafts is the lack of
review means there's no way to claim they represent any
useful level of WG consensus.

Cheers,
S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Ray Hunter (v6ops)]

Stephen Farrell wrote on 07/06/2021 21:32:


Hi Michael,

On 05/06/2021 19:46, Michael Richardson wrote:

Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.


Just to clarify: I don't think/claim DDNS is "better" than
the proposal here, rather I don't find the arguments as to
why this is "better" convincing, and so, given that DDNS is
deployed, and has some similarity, I'm wondering if this
spec really has much of a chance at gaining traction.

As a result, I don't really think there's that much value
in attempting a point-scoring exercise comparing the two,
the question for me is really whether or not this spec is
so much better than DDNS that it could displace DDNS, and
I'm not convinced as of now. (But I'm often wrong of course.)

Cheers,
S.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


Just trying to understand this hurdle/ line of reasoning.

So in addition to achieving "rough consensus", the IETF standardization 
process must also produce drafts that are very likely to gain traction 
to displace non-IETF non-standardised products that are already widely 
commercially deployed?


If that is the case, then perhaps the WG should have steered the draft 
to have been "DDNS, but standardised" or "a TR-069 compatible interface 
for DNS zone delegation".


--
regards,
RayH

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Michael Richardson]

Stephen Farrell  wrote:
> On 05/06/2021 19:46, Michael Richardson wrote:
>> Well, I'd be happy to discuss with this them again, but they'd have to
>> actually tell us what "DDNS" really is for them.

> Just to clarify: I don't think/claim DDNS is "better" than
> the proposal here, rather I don't find the arguments as to
> why this is "better" convincing, and so, given that DDNS is
> deployed, and has some similarity, I'm wondering if this
> spec really has much of a chance at gaining traction.

I don't think that they solve the same problem, nor do they have the same 
audience.

In particular, DDNS is very IPv4 specific and very divorced from ISP
operations, while the front-end naming is very IPv6 focused and integrates
much better with ISP operations.

Nothing we've done in Homenet has gained any traction, why do the chairs
suddenly care?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Stephen Farrell]

Hi Michael,

On 05/06/2021 19:46, Michael Richardson wrote:

Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.


Just to clarify: I don't think/claim DDNS is "better" than
the proposal here, rather I don't find the arguments as to
why this is "better" convincing, and so, given that DDNS is
deployed, and has some similarity, I'm wondering if this
spec really has much of a chance at gaining traction.

As a result, I don't really think there's that much value
in attempting a point-scoring exercise comparing the two,
the question for me is really whether or not this spec is
so much better than DDNS that it could displace DDNS, and
I'm not convinced as of now. (But I'm often wrong of course.)

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Michael Richardson]

Juliusz Chroboczek  wrote:
>>> Stephen and Juliusz expressed that they're still not convinced that
>>> DDNS isn't a good enough solution for the use case.

>> Well, I'd be happy to discuss with this them again, but they'd have to
>> actually tell us what "DDNS" really is for them.

> https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA/

Hi, thanks for that email, let me paste parts of it in.
I didn't find any clear definition of how DDNS works in that email.


>> In particular, I'd like to know if it's okay with them if an arbitrary 
device
>> in their home automatically signs up with a DDNS provider, disclosing 
their
>> IPv6 address to the world.

> No; unless the user has explicitly requested that a device be accessible
> from the Global Internet, it has no business publishing its IP address.
> I've tried to be very clear on that specific point in the mail linked 
above.

jc> Oh, nothing that geeky.  I copy my vacation photographs onto my NAS. I
jc> click the "share over the Internet" button on the NAS's web
jc> interface. The NAS performs DynDNS registration,

So, explain to me that this part works: "the NAS performs DynDNS registration"?

First, are you talking about RFC3007? No, I don't think so.  What's the
Performance Specification that describes this process?  Yes, I know where
the vendor specific documentation is.

Second, how are the credentials for that communication established?
What name does your NAS pick?   How did you communicate the credential to the
NAS?
Once the 14 year old in the house does this, how does the parent find out
about the name that was used?

Was it IPv4, IPv6 (and from which ISP, as our homenet architecture says we
can have more than one ISP. That's why we did all that BABEL stuff, right?),
and did the device publish a SLAAC derived IP, a privacy IP, a stable IPv6?

If the device renumbers, or experiences a flash renumbering, how does it know
to re-register?

So, let me know the details here, as these are the kind of things the HNA
mediated zone is dealing with.

> Sure.  Just like you, I'm expecting dynamic updates.  But I don't expect
> dynamic updates to be dependent on my CPE, which is buggy (it was provided
> by the major competitor of your employer) and isn't available at the

All sorts of devices can be buggy.
I don't expect to be dependent upon a buggy NAS either.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Juliusz Chroboczek]

Hi Michael,

>> Stephen and Juliusz expressed that they're still not convinced that
>> DDNS isn't a good enough solution for the use case.

> Well, I'd be happy to discuss with this them again, but they'd have to
> actually tell us what "DDNS" really is for them.

https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA/

> In particular, I'd like to know if it's okay with them if an arbitrary device
> in their home automatically signs up with a DDNS provider, disclosing their
> IPv6 address to the world.

No; unless the user has explicitly requested that a device be accessible
from the Global Internet, it has no business publishing its IP address.
I've tried to be very clear on that specific point in the mail linked above.

Hope that clarifies things,

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] naming drafts

[Michael Richardson]

STARK, BARBARA H  wrote:
> Stephen and Juliusz expressed that they're still not convinced that
> DDNS isn't a good enough solution for the use case.

Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.

What specific solution are they talking about?  Tell us the whole story,
including how the credential gets into the device.

In particular, I'd like to know if it's okay with them if an arbitrary device
in their home automatically signs up with a DDNS provider, disclosing their
IPv6 address to the world.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] naming drafts

[STARK, BARBARA H]

Hi homenet WG,
Stephen and I have been chatting about the status of the 2 naming drafts 
(draft-ietf-homenet-front-end-naming-delegation and 
draft-ietf-homenet-naming-architecture-dhc-options). 

We started a 3-week WGLC about a month ago (04 May). Both drafts received 
comprehensive review from Med. Stephen reviewed front-end-naming-delegation. 
Bernie reviewed the formatting of the DHC option. 
The authors provided updates to resolve these comments. Bernie acknowledged 
satisfactory resolution of his comments.
Requests to change terminology were satisfactorily resolved -- but that 
discussion doesn't count as really being part of anyone's review of the drafts.
Stephen and Juliusz expressed that they're still not convinced that DDNS isn't 
a good enough solution for the use case.

Stephen and I do not believe these drafts have received enough review or 
support to put them forward as representing WG consensus.

But the authors have spent significant effort in creating these drafts and the 
associated implementation. We will work with Éric V (as INT area AD) and the 
authors to determine next steps.

Barbara and Stephen

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet naming drafts "terminology"

[Daniel Migault]

Sounds good to me. Anyone objecting DIstribution Manager ? If not I will
consider this terminology.
Yours,
Daniel

On Wed, May 12, 2021 at 5:11 PM Michael Richardson 
wrote:

>
> Daniel Migault  wrote:
> > "Distribution Primary" is probably my preferred alternative as the
> > replacement of Master by Primary makes a smooth transition from what
> is
> > currently used. If that is fine with everyone I will update the
> > document with it as well as the DHCP option draft. If not feel free
> to
> > provide a better alternative.
>
> I'm okay with that, but would list "Distribution Manager" as a nice TLA
> preserving of "DM"
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>

-- 
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet naming drafts "terminology"

[Michael Richardson]

Daniel Migault  wrote:
> "Distribution Primary" is probably my preferred alternative as the
> replacement of Master by Primary makes a smooth transition from what is
> currently used. If that is fine with everyone I will update the
> document with it as well as the DHCP option draft. If not feel free to
> provide a better alternative.

I'm okay with that, but would list "Distribution Manager" as a nice TLA
preserving of "DM"

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet naming drafts "terminology"

[Daniel Migault]

"Distribution Primary" is probably my preferred alternative as the
replacement of Master by Primary makes a smooth transition from what is
currently used. If that is fine with everyone I will update the document
with it as well as the DHCP option draft. If not feel free to provide a
better alternative.

Yours,
Daniel

On Thu, May 6, 2021 at 1:16 AM Carsten Bormann  wrote:

> On 6. May 2021, at 00:06, Michael Richardson  wrote:
> >
> >
> > Ole Troan  wrote:
> >> Is this the same as a hidden primary name server?
> >
> > That's Stealth Primary.
> > The DM is not a stealth primary, because it's not primary.
> > It hasn't got the DNSSEC signing keys, for instance.
>
> Distribution hub
> Distribution leader
> Distribution manager
> Distribution head
> Distribution director
> Distribution controller
> Distribution governor
> Distribution center
> Distribution central
>
> Grüße, Carsten
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>


-- 
Daniel Migault
Ericsson
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet naming drafts "terminology"

[Carsten Bormann]

On 6. May 2021, at 00:06, Michael Richardson  wrote:
> 
> 
> Ole Troan  wrote:
>> Is this the same as a hidden primary name server?
> 
> That's Stealth Primary.
> The DM is not a stealth primary, because it's not primary.
> It hasn't got the DNSSEC signing keys, for instance.

Distribution hub
Distribution leader
Distribution manager
Distribution head
Distribution director
Distribution controller
Distribution governor
Distribution center
Distribution central

Grüße, Carsten

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet naming drafts "terminology"

[Michael Richardson]

Ole Troan  wrote:
> Is this the same as a hidden primary name server?

That's Stealth Primary.
The DM is not a stealth primary, because it's not primary.
It hasn't got the DNSSEC signing keys, for instance.

>> On 5 May 2021, at 21:09, Michael Richardson 
>> wrote:
>>
>>  Ted Lemon  wrote:
 On May 5, 2021, at 11:51 AM, Michael Richardson 
 wrote: 3) We would be happy to go with another term, but we don't
 want to invent another term.  So, if the DNS anycast operator has
 another term, then I'd go with it.
>>
>>> Authority database?
>>
>> I thought that you were asking who was an authoritive database of
>> operators.  Then I understood that you are suggesting "authority
>> database" as the term.
>>
>> Some ascii art, (so pick a sensible mono-spaced font, or use the
>> archive link):
>>
>> .-.  .-.  | S P | ---> | D M |\---\--\ `-'
>> `-' | | | V V V .-. .. ..  | Sec | | Sec| |Sec |
>> `-' `' `'
>>
>> S.P. = Stealth Primary Sec = Secondary D M = Distribution M*
>>
>> Note that the "DM" is usually not listed as an NS, but rather, two or
>> more "Sec" are what is listed.
>>
>> So, maybe "Distribution Authority" would make us both happy.
>>
>> --
>> Michael Richardson  . o O ( IPv6 IøT consulting
>> ) Sandelman Software Works Inc, Ottawa and Worldwide
>> ___ 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] homenet naming drafts "terminology"

[Ted Lemon]

Or “Distribution Primary?” I think given this chart that “Distribution 
Authority” is less clear, since the real authority is the stealth primary.

> On May 5, 2021, at 3:09 PM, Michael Richardson  wrote:
> 
> 
> Ted Lemon  wrote:
>> On May 5, 2021, at 11:51 AM, Michael Richardson 
>> wrote:
>>> 3) We would be happy to go with another term, but we don't want to
>>> invent another term.  So, if the DNS anycast operator has another
>>> term, then I'd go with it.
> 
>> Authority database?
> 
> I thought that you were asking who was an authoritive database of operators.
> Then I understood that you are suggesting "authority database" as the term.
> 
> Some ascii art, (so pick a sensible mono-spaced font, or use the archive 
> link):
> 
> .-.  .-.
> | S P | ---> | D M |\---\--\
> `-'  `-'|   |  |
>V   V  V
> .-. .. ..
> | Sec | | Sec| |Sec |
> `-' `' `'
> 
> S.P. = Stealth Primary
> Sec  = Secondary
> D M  = Distribution M*
> 
> Note that the "DM" is usually not listed as an NS, but rather,
> two or more "Sec" are what is listed.
> 
> So, maybe "Distribution Authority" would make us both happy.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet naming drafts "terminology"

[Ole Troan]

Is this the same as a hidden primary name server?

Cheers 
Ole

> On 5 May 2021, at 21:09, Michael Richardson  wrote:
> 
> 
> Ted Lemon  wrote:
>>> On May 5, 2021, at 11:51 AM, Michael Richardson 
>>> wrote:
>>> 3) We would be happy to go with another term, but we don't want to
>>> invent another term.  So, if the DNS anycast operator has another
>>> term, then I'd go with it.
> 
>> Authority database?
> 
> I thought that you were asking who was an authoritive database of operators.
> Then I understood that you are suggesting "authority database" as the term.
> 
> Some ascii art, (so pick a sensible mono-spaced font, or use the archive 
> link):
> 
> .-.  .-.
> | S P | ---> | D M |\---\--\
> `-'  `-'|   |  |
>V   V  V
> .-. .. ..
> | Sec | | Sec| |Sec |
> `-' `' `'
> 
> S.P. = Stealth Primary
> Sec  = Secondary
> D M  = Distribution M*
> 
> Note that the "DM" is usually not listed as an NS, but rather,
> two or more "Sec" are what is listed.
> 
> So, maybe "Distribution Authority" would make us both happy.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> ___
> 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] homenet naming drafts "terminology"

[Michael Richardson]

Ted Lemon  wrote:
> On May 5, 2021, at 11:51 AM, Michael Richardson 
> wrote:
>> 3) We would be happy to go with another term, but we don't want to
>> invent another term.  So, if the DNS anycast operator has another
>> term, then I'd go with it.

> Authority database?

I thought that you were asking who was an authoritive database of operators.
Then I understood that you are suggesting "authority database" as the term.

Some ascii art, (so pick a sensible mono-spaced font, or use the archive link):

.-.  .-.
| S P | ---> | D M |\---\--\
`-'  `-'|   |  |
V   V  V
 .-. .. ..
 | Sec | | Sec| |Sec |
 `-' `' `'

S.P. = Stealth Primary
Sec  = Secondary
D M  = Distribution M*

Note that the "DM" is usually not listed as an NS, but rather,
two or more "Sec" are what is listed.

So, maybe "Distribution Authority" would make us both happy.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet naming drafts "terminology"

[Ted Lemon]

On May 5, 2021, at 11:51 AM, Michael Richardson  wrote:
> 3) We would be happy to go with another term, but we don't want to invent
>   another term.  So, if the DNS anycast operator has another term, then
>   I'd go with it.

Authority database?

RFC 8499 appears to have deprecated the term “master” to some extent, although 
it’s not perfect. “Master server” just says “see Primary Server.”

The server on the home router really is the primary authoritative server for 
the zone from a DNS perspective, even if it doesn’t show up in a public NS 
record.

FWIW I fully support using different terminology.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet naming drafts "terminology"

[Michael Richardson]

STARK, BARBARA H  wrote:
> I'm hoping not to start divisive discussion, but think it's better to
> discuss inside the WG rather than wait until IETF LC.

> Might the authors consider whether a word other than "Master" could be
> used in the terms Distribution Master, Reverse Distribution Master,

Yes, the authors discussed this at length, and we actually reached out to
quite a number of people for the terminology.  There were even emails on this
ML, I think.

1) DM is a term used in the DNS operational community.  It's not ubiquitous,
   but it is understood in many of the anycast DNS groups.

2) The term "stealth primary" is also used, but according to how it is used,
   that term would apply to the HNA, not the DM function.

3) We would be happy to go with another term, but we don't want to invent
   another term.  So, if the DNS anycast operator has another term, then
   I'd go with it.

> Perhaps "Primary" could be used? Or something else?

Nope, because that's confusing in the DNS space.
It's not a primary.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] homenet naming drafts "terminology"

[STARK, BARBARA H]

I'm hoping not to start divisive discussion, but think it's better to discuss 
inside the WG rather than wait until IETF LC.

Might the authors consider whether a word other than "Master" could be used in 
the terms Distribution Master, Reverse Distribution Master, 
Distribution/Distributed Master Option [BTW, I notice that there are several 
instances of the "Distributed" instead of "Distribution" in the DHC option 
draft], Reverse Distribution Master Option, OPTION_DIST_MASTER, 
OPTION_REVERSE_DIST_MASTER?

Perhaps "Primary" could be used? Or something else?

If anyone needs context for my comment, I'm happy to provide it. Otherwise, 
I'll just leave it at this request for the authors to consider this question.
Thx,
Barbara

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet