Subject: [homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt

From: [email-masked]
Date: Fri, 08 Jul 2016 07:20:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Home Networking of the IETF.

        Title           : Home Networking Control Protocol
        Authors         : Markus Stenberg
                          Steven Barth
                          Pierre Pfister
	Filename        : draft-ietf-homenet-hncp-bis-00.txt
	Pages           : 38
	Date            : 2016-07-08

Abstract:
   This document describes the Home Networking Control Protocol (HNCP),
   an extensible configuration protocol, and a set of requirements for
   home network devices.  HNCP is described as a profile of and
   extension to the Distributed Node Consensus Protocol (DNCP).  HNCP
   enables discovery of network borders, automated configuration of
   addresses, name resolution, service discovery, and the use of any
   routing protocol that supports routing based on both the source and
   destination address.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp-bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-homenet-hncp-bis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jul 2016 12:25:20 -0400

I took a quick look at draft-ietf-homenet-hncp-bis-00, including a diff; seems the only change is to solve the .home problem.  I don't think I quite understand the new text and here's a suggested clarification:

OLD:

  A default value for this TLV MUST be set, although
  the default value of the Domain-Name TLV (Section 10.6) is out of
  scope of this document, and an administrator MAY configure the
  announcement of a Domain-Name TLV for the network.

NEW:

  The administrator MUST configure the announcement of a network-wide
  zone suffix through the Domain-Name TLV.

As far as I can tell, draft-ietf-homenet-hncp-bis-00 does not address errata 4718.  While this errata has not yet been verified, in my opinion *something* has to be done to correct the text around "Multicast DNS Proxy".  If "Multicast DNS Proxy" is intended to refer to "Hybrid Proxy" in draft-ietf-dnssd-hybrid-03, the appropriate normative reference will constitute a downref in draft-ietf-homenet-hncp-bis-00.

- Ralph

> On Jul 8, 2016, at 10:20 AM 7/8/16, [email-masked] wrote:
> 
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Ray Bellis <[email-masked]>
Date: Fri, 8 Jul 2016 17:30:15 +0100

On 08/07/2016 17:25, Ralph Droms wrote:
> I took a quick look at draft-ietf-homenet-hncp-bis-00, including a
> diff; seems the only change is to solve the .home problem.  I don't
> think I quite understand the new text and here's a suggested
> clarification:
> 
> OLD:
> 
> A default value for this TLV MUST be set, although the default value
> of the Domain-Name TLV (Section 10.6) is out of scope of this
> document, and an administrator MAY configure the announcement of a
> Domain-Name TLV for the network.
> 
> NEW:
> 
> As far as I can tell, draft-ietf-homenet-hncp-bis-00 does not address
> errata 4718.  While this errata has not yet been verified, in my
> opinion *something* has to be done to correct the text around
> "Multicast DNS Proxy".  If "Multicast DNS Proxy" is intended to refer
> to "Hybrid Proxy" in draft-ietf-dnssd-hybrid-03, the appropriate
> normative reference will constitute a downref in
> draft-ietf-homenet-hncp-bis-00.

The instruction to the authors were to incorporate the original .home
errata verbatim, and also to fix the error with options 37/38 being the
wrong way around in two diagrams.

If there is to be further wordsmithing on that we'd need to take that up
with our AD.

As for errata 4718, I fully expect that it will be incorporated in a
further revision just as soon as it has been verified (and subject to a
resolution of any resulting downref issue).

kind regards,

Ray

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jul 2016 18:45:42 -0400

> On Jul 8, 2016, at 12:30 PM 7/8/16, Ray Bellis <[email-masked]> wrote:
> 
> 
> 

I honestly can't understand the new text.  Why a friendly suggestion for a simplification need AD intervention?

> resolution of any resulting downref issue).

OK. As an aside, *something* will have to be done with the text regarding "Multicast DNS Proxy" regardless of whether or not the errata is verified.  I see a couple of ways to read the existing text and the citations of RFC 6762.

One way to read RFC 7788 is to assume "Multicast DNS Proxy" refers to the "Multicast DNS Proxy Servers" defined in RFC 6762, in which case RFC 7788 is specifying that an HNCP device should participate in whatever election protocol "Multicast DNS Proxy Servers" use to elect the proxy server for a link.  That election protocol would need a normative reference.

Another way to read RFC 7788 is that there is no citation for a definition of "Multicast DNS Proxy" at all (assuming the citations of RFC 6762 apply just to mDNS and not "proxy"), in which case RFC 7788 needs to be amended to include that definition of "Multicast DNS Proxy".

Seems like the WG might want to go ahead and figure out which way it wants to fix this issue as doing nothing isn't an option.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jul 2016 18:47:25 -0400

One way to read RFC 7788 is to assume "Multicast DNS Proxy" refers to the "Multicast DNS Proxy Servers" defined in RFC 6762, in which case RFC 7788 is specifying that an HNCP device should participate in whatever election protocol "Multicast DNS Proxy Servers" use to elect the proxy server for a link.  That election protocol needs a reference

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jul 2016 18:45:15 -0400

OLD:

NEW:

- Ralph

kind regards,

Ray

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Jul 2016 16:04:18 -0700

A small reminder: while there was clearly a mistake made in including
".home" in this document, from a process perspective an updated document
being worked on by the working group is a working group document, and the
working group can make changes to it.   The document doesn't get published
as a working group document if there isn't consensus to publish it.

So the chairs do not need to "check with the AD" about other changes that
are proposed.   The AD may have specified an accelerated timeline for the
work, so the chairs may say "look, we don't have time for that," but if we
do have time for that, and there is consensus to do it, why on earth would
we not?   If there is a time limit, just say that the change doesn't go in
if there's no consensus to make it before the time limit.

ADs do not get to say what is in documents.   They can refuse to publish,
and they can publish individual submissions if they get IETF consensus, and
they can threaten to close working groups, but any other changes are the
purview of the working group.

On Fri, Jul 8, 2016 at 3:45 PM, Ralph Droms <[email-masked]> wrote:

> OK. As an aside, *something* will have to be done with the text regarding
> "Multicast DNS Proxy" regardless of whether or not the errata is verified.
> I see a couple of ways to read the existing text and the citations of RFC
> 6762.
>
> One way to read RFC 7788 is to assume "Multicast DNS Proxy" refers to the
> "Multicast DNS Proxy Servers" defined in RFC 6762, in which case RFC 7788
> is specifying that an HNCP device should participate in whatever election
> protocol "Multicast DNS Proxy Servers" use to elect the proxy server for a
> link.  That election protocol needs a reference
>
> Another way to read RFC 7788 is that there is no citation for a definition
> of "Multicast DNS Proxy" at all (assuming the citations of RFC 6762 apply
> just to mDNS and not "proxy"), in which case RFC 7788 needs to be amended
> to include that definition of "Multicast DNS Proxy".
>
> Seems like the WG might want to go ahead and figure out which way it wants
> to fix this issue as doing nothing isn't an option.
>
> - Ralph
>
>
> kind regards,
>
> Ray
>
>
>

---

From: Terry Manderson <[email-masked]>
Date: Sat, 16 Jul 2016 08:56:00 +0000

>If there is to be further wordsmithing on that we'd need to take that up

So let me clarify a point, the direction from me was to use the errata
wording verbatim in the initial BIS as that forms the start point of the
discussion.

Beyond that, if the WG comes to a consensus to either use that text or
other text after fuller discussion, that will be a WG decision and not
explicitly my decision. The solution must be a WG solution yet respect
IETF processes.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Sat, 16 Jul 2016 08:57:30 +0000

On 9/07/2016, 9:04 AM, "homenet on behalf of Ted Lemon"
<[email-masked] on behalf of [email-masked]> wrote:
>and they can publish individual submissions if they get IETF consensus,
>and they can threaten to close working groups, but any other changes are
>the purview of the working group.
>

Correct.

:)

Terry