Subject: [homenet] WGLC started

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 4 May 2021 13:56:07 +0000

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

---

From: <[email-masked]>
Date: Wed, 5 May 2021 12:33:34 +0000

Hi all,

FWIW, some comments to be considered by the authors as part the WGLC can be seen at:

* draft-ietf-homenet-naming-architecture-dhc-options:
- pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-homenet-naming-architecture-dhc-options-12-rev%20Med.pdf 
- doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-homenet-naming-architecture-dhc-options-12-rev%20Med.docx 

* draft-ietf-homenet-front-end-naming-delegation:
- pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-homenet-front-end-naming-delegation-14-rev%20Med.pdf 
- doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-homenet-front-end-naming-delegation-14-rev%20Med.docx  

Cheers,
Med

> -----Message d'origine-----
> De : dns-privacy [mailto:[email-masked]] De la part de
> STARK, BARBARA H
> Envoyé : mardi 4 mai 2021 15:56
> À : [email-masked]' <[email-masked]>
> Cc : [email-masked]' <[email-masked]>; [email-masked]' <dns-
> [email-masked]>; [email-masked]' <[email-masked]>
> Objet : [dns-privacy] WGLC started
> 
> 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'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?
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 5 May 2021 09:33:00 -0400

Thank you very much Med for the comments! That is very useful and we will
address them very soon!

Yours,
Daniel

On Wed, May 5, 2021 at 8:33 AM <[email-masked]> wrote:

> - pdf:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-homenet-naming-architecture-dhc-options-12-rev%20Med.pdf
> - doc:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-homenet-naming-architecture-dhc-options-12-rev%20Med.docx
>
> - pdf:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-homenet-front-end-naming-delegation-14-rev%20Med.pdf
> - doc:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-homenet-front-end-naming-delegation-14-rev%20Med.docx
>
>
> Cheers,
> Med
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Thu, 13 May 2021 13:58:50 -0400

Hi Med,

Thanks for the review, please find some responses to your comments inline.
I will publish shortly a new version that addresses your comments.

Yours,
Daniel

In this context agnostic is used to mention the CE router can learn
everything from the network without requiring interaction from the end
user.
[1] https://dictionary.cambridge.org/dictionary/english/agnostic

[BMT17]: Do you assume that default ports are used? If not, how this is
discovered?

> Yes, we currently only configure the most simple configuration. There is
no discovery. Non default parameters might be defined out of bound, or
other mechanisms such as SVCB for example.

[BMT18]: Why not returning a list of IP addresses? Or do you need it for
authentication?

> this has been extensively discussed but I agree a long time ago. As far
as I remember, we used the FQDN for compactness and we assumed the CE is
able to resolve the name.

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Thu, 13 May 2021 14:25:32 -0400

Hi Med,

Thanks for the very careful review of the HNA architecture. I believe the
new published version addresses your concerns but please find some
complementary responses.

Yours,
Daniel

IPv6 connectivity provides the possibility of global end to end IP
connectivity.

[BMT2]: As firewalls may be enabled on the RG, the same issues as per IPv4
will be encountered (need to open pinholes). There is also a requirement on
stable IP addresses, unless a mechanism is enabled to update the records
dynamically.

> I agree with the comment, but I think that IPv6 and the use of global IP
addresses ease the end to end connectivity. It is not impossible with IPv4
but way more difficult than just opening an IP address.
This is also correct: the mechanism provides the zone to be dynamically
sync.
Currently, I think it is better to keep that sentence. Now going to the
next comment I have the impression the removal was requested to avoid
redundancies.

3. {{!RFC7368}} emphasizes that the home network is subject to connectivity
disruptions with the ISP.
But, names used within the home MUST be resilient against such disruption.

[BMT5]: The LAN connectivity is resilient against WAN failure. Reaching a
device based on a local name is just factural.

> Correct. Here we were listing the constraints of the homenet. I think the
comment is addressed by the sentence right after the enumeration:

This specification makes the public names resolvable within both the home
network and on the Internet, even when there are disruptions.

[BMT6]: Unless you define what is meant by a “public name” vs. “private
name”.

We clarified the public name is the name of the device by which it is
reachable from outside as well as from within the home network.

[BMT8]: Also, please note that rfc6092 says the following: “REC-8: By
DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be
processed by any integrated DNS resolving server.”

> I think that is interesting but I am not sure this is clarifying. This
case is considered bad in our scenario since it exposes the interface on
the interface.
We have never - at least in my case - considered having a single server
inside and outside, so I prefer not to introduce this potential confusion.

[BMT12]: Why not other device identifiers?
[BMT14]: How is this known/configured? Or do you expect this to be handled
by an administrator. That said, I don’t see this as case is worth to be
discussed here as VPN setups do not involve CPEs.

> The type of IP address is expected to be selected by the administrator
which will determine what can be outsourced to the DOI.
The idea of the VPN was to mention that there are some cases where non
global IP addresses may be published globally.

[BMT17]: I’m not sure this is needed.
> The section is not intended to describe an alternative way, it is
expected to position the architecture toward what is believed to be a more
common mechanism.

[BMT18]: How this is supposed to work for IPv4 even when no failure is
experienced? I’m asking this as given that the same IP address is shared
and that a port number is needed to map to an internal host.
The CPE should be involved, otherwise failures will be observed.

> I now understand the earlier comments. The scope of homenet is IPv6 so we
were basically translating the mechanism to IPv6 use case. I clarified
this, but did not consider the IPv4 issues.

"""On the other hand, to provide resilience to the Public Homenet Zone in
case of WAN connectivity disruption, the Homenet DNSSEC Resolver SHOULD be
able to perform the resolution on the Homenet Authoritative Servers. These
servers are not expected
"""
[BMT21]: MUST?

I understand why MUST is suggested. The reason It would rather stay with
SHOULD is that it is not given that homenet have authoritative servers.

"""
How the Homenet Authoritative Servers are provisioned is also out of scope
of this specification.
It could be implemented using primary and secondary servers, or via rsync.
In some cases, the HNA and Homenet Authoritative Servers may be combined
together which would result in a common instantiation of an authoritative
server on the WAN and inner homenet interface.
Note that {{?RFC6092}} REC-8 states this must not be the default
configuration.
Other mechanisms may also be used.
"""

> I added the reference to RFC6092 there.

"""communications between the HNA and the DM SHOULD be protected and..."""

[BMT23]: MUST?

> For the reverse zone, there are some situations where the use of strong
authentication may not necessarily be needed. We however updated it to MUST
to avoid specific unsecured implementations to be deployed.

-- 
Daniel Migault
Ericsson