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

Ted Lemon <> Fri, 08 July 2016 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED42A12D945 for <>; Fri, 8 Jul 2016 16:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SXp9nmcCECTR for <>; Fri, 8 Jul 2016 16:05:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6854212D8D9 for <>; Fri, 8 Jul 2016 16:05:06 -0700 (PDT)
Received: by with SMTP id q132so36546704lfe.3 for <>; Fri, 08 Jul 2016 16:05:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8sERR0oEdVQh4L+IgCvY04YUcqyXf0yXjG7YwH4Q0gM=; b=Ok+2EoWokzrooW5utayzhW3jke7mpG6Xxe1ShdgrVbLvs2CnGRnA+4dAJlqojofUE3 ZapjhvLKD+/yhvVRT4iiub5q/oQt0+7cI1j5Imjx5gqg7TdP0LiNQWhAcpip7gvLoo/m hYvv2hss4cf0je8qeRq1CFa9Q2UFyE4VPfAPRBWHSqB6v0qdzahvVwmfA/cPhcEbVHfO LMQOZpDqRHaH2Q0stqjOy3wWQN2/Z0klJtKN6ZaV5RPYa9wJpLU+kn6TTCU7LbNoIaJE BXRoq2cfaQDiMPqxzGFqqTD4etHVKs3Aew0j5r0o6+PPpdxXaQ7iH+bxANyuqWHS8oUd ZxYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8sERR0oEdVQh4L+IgCvY04YUcqyXf0yXjG7YwH4Q0gM=; b=bOcf595qcSR9M+ycNcwdu3nxEjxMZQAHWSSP06XAD7hzd8l2Gt/Y6JLOOoYxrHbZJ0 xybWtYMOtEUt8IJIo3Yfl2dLqBaTj14u4wbr4+UNkFcxccSPtmtXJxxdOajz+sVoBlPb x1WI2DSZCqomA/vFwCWCQaO7zY/6TVbPr1WW9+YYwtDtDwgFf0QPovlhDhIdn/JFHQ82 zT/WZsHCAZtYTsjoJzTF4hl+Rw0WgTAVoej6+h+hOlCJL+ZMLBS56Zuf0/JlCSKSN/Zv 2WhqnJ6YXt9NtcraQv3PL54NyU7/2k3ebx7lQQBIhVjYmp7AoT7SyKAYYLKK14Agv9pB H79Q==
X-Gm-Message-State: ALyK8tLdXpaI4OTW8qSjg4nRGy4k1b6dRDqanV+wmfiwPUBS/LNbEfLCQdp+AtW30rzJNujZS0ZsyMxsSEgRGw==
X-Received: by with SMTP id p103mr1768384lfg.226.1468019104618; Fri, 08 Jul 2016 16:05:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 8 Jul 2016 16:04:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Ted Lemon <>
Date: Fri, 8 Jul 2016 16:04:18 -0700
Message-ID: <>
To: Ralph Droms <>
Content-Type: multipart/alternative; boundary=001a1140d0ca413372053727d50a
Archived-At: <>
Cc: HOMENET <>,, Ray Bellis <>
Subject: Re: [homenet] I-D Action: draft-ietf-homenet-hncp-bis-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2016 23:05:12 -0000

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 <>; wrote:

> On Jul 8, 2016, at 12:30 PM 7/8/16, Ray Bellis <>; wrote:
> 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:
> 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.
> 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.
> I honestly can't understand the new text.  Why a friendly suggestion for a
> simplification need AD intervention?
> 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).
> 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
> _______________________________________________
> homenet mailing list