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

Commentary: Should the introduction contain clearly enumerated requirements ? i.e. REQ01 /  ? 
 The introduction is too abrupt . Let 's rework section 2.0 a bit . I 'll try to make a pull request for this . Let 's move 1.0 to terminology , which usually comes after the intro in most drafts . ( Also BCP14 ) 
 please push the text you would like to find . I have no strong opinion on what needs to be mentioned .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
IPv6 provides global end to end IP connectivity.  End users prefer to
use names instead of long and complex IPv6 addresses when accessing
services hosted in the home network.
RFC7368 recommends that home networks be resilient to connectivity
disruption from the ISP.  The public names should be resolvable
within the home network and on the Internet, even when there are
disruptions.  This could be achieved by a device inside the home
network that builds, publishes, and manages a Public Homenet Zone,
thus providing bindings between public names, IP addresses, and other
RR types.
A home network may have multiple CPEs.  Since management of the
Public Homenet Zone involves DNS specific mechanisms that cannot be
distributed over multiple servers (primary server), when multiple
nodes can potentially manage the Public Homenet Zone, a single node
needs to be selected per outsourced zone.  This selected node is
designated as providing the Homenet Naming Authority (HNA) function.
The process by which a single HNA is selected per zone is not in
scope for this document.
CPEs, which may host the HNA function, as well as home network
devices, are usually low powered devices not designed for terminating
heavy traffic.  As a result, hosting an authoritative DNS service
visible to the Internet may expose the home network to resource
exhaustion and other attacks.  Additionally, the names could become
unavailable during disruptions of the upstream Internet connectivity.
The Homenet Naming authority is responsible for making devices within
the home network accessible by name within the home network as well
as from outside the home network (e.g. the Internet).  IPv6
connectivity provides the possibility of global end to end IP
connectivity.  End users will be able to transparently make use of
this connectivity if they can use names to access the services they
want from their home network.
The use of a DNS zone for each home network is a reasonable and
scalable way to make the set of public names visible.  There are a
number of ways to populate such a zone.  This specification proposes
a way to do with based upon a number of assumptions about typical
home networks.
The names of the devices accessible from the Internet are stored
in the Public Homenet Zone, served by a DNS authoritative server.
It is unlikely that home networks will contain sufficiently robust
platforms designed to host a service such as the DNS on the
Internet and as such would expose the home network to DDoS
attacks.
RFC7368 emphazes that the home network is subject to connectivity
disruptions with the ISP.  But, names used within the home MUST be
resilient against such disruption.
So a goal of this specification is to make the public names
resolvable within both the home network and on the Internet, even
when there are disruptions.
This is achieved by having a device inside the home network that
builds, publishes, and manages a Public Homenet Zone, thus providing
bindings between public names, IP addresses, and other RR types.
The homenet architecture RFC7368 makes it clear that a home network
may have multiple CPEs.  The management of the Public Homenet Zone
involves DNS specific mechanisms that cannot be distributed over
multiple servers (primary server), when multiple nodes can
potentially manage the Public Homenet Zone, a single node needs to be
selected per outsourced zone.  This selected node is designated as
providing the Homenet Naming Authority (HNA) function.
The process by which a single HNA is selected per zone is not in
scope for this document.  It is envisioned that a future document
will describe an HNCP mechanism to elect the single HNA.
CPEs, which may host the HNA function, as well as home network
devices, are usually low powered devices not designed for terminating
heavy traffic.  As a result, hosting an authoritative DNS service
visible to the Internet may expose the home network to resource
exhaustion and other attacks.  On the other hand, if the only copy of
the public zone is on the Internet, then Internet connectivity
disruptions would make the names unavailable inside the homenet.
"all the good names are taken" -- current services put everyone's
names into some small set of zones, and there are often conflicts.
Distinguishing similar names by delegation of zones was among the
primary design goals of the DNS system.
"all the good names are taken" - current services put everyone's
names into some small set of zones, and there are often conflicts.
Distinguishing similar names by delegation of zones was among the
primary design goals of the DNS system.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all
capitals, as shown here.
The Public Homenet Zone is identified by the Registered Homenet
Domain Name -- example.com.
The Public Homenet Zone is identified by the Registered Homenet
Domain Name - example.com.
Setting the Homenet Zone requires the following information.