Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

Mark Andrews <marka@isc.org> Thu, 19 November 2015 22:56 UTC

Return-Path: <marka@isc.org>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5489C1B36B5 for <homenet@ietfa.amsl.com>; Thu, 19 Nov 2015 14:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level:
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F04EwfVbQ3O for <homenet@ietfa.amsl.com>; Thu, 19 Nov 2015 14:56:08 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0398D1B36CD for <homenet@ietf.org>; Thu, 19 Nov 2015 14:56:07 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 6BAE83493EF; Thu, 19 Nov 2015 22:56:04 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E134A160042; Thu, 19 Nov 2015 22:57:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CD650160088; Thu, 19 Nov 2015 22:57:07 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ulK6uV0LyFdp; Thu, 19 Nov 2015 22:57:07 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 85936160042; Thu, 19 Nov 2015 22:57:07 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B51303D2D96A; Fri, 20 Nov 2015 09:56:02 +1100 (EST)
To: Ted Lemon <mellon@fugue.com>
From: Mark Andrews <marka@isc.org>
References: <20151117235034.24927.22561.idtracker@ietfa.amsl.com> <87poz7qw2k.wl-jch@pps.univ-paris-diderot.fr> <1447858576159-79d51c78-b96c8c38-55ec1307@fugue.com> <8737w3qozs.wl-jch@pps.univ-paris-diderot.fr> <1447863094928-7e8a26f0-271186df-921ed76e@fugue.com> <87vb8zp903.wl-jch@pps.univ-paris-diderot.fr> <1447884395403-59f7ba69-4ce68f01-0794a090@fugue.com> <87egfmq35o.wl-jch@pps.univ-paris-diderot.fr> <1447906468890-334068f2-9e166c9c-ff8d872f@fugue.com> <564D70DC.7050701@gmail.com> <1447953139625-fadd659d-49861c14-8098fd86@fugue.com>
In-reply-to: Your message of "Thu, 19 Nov 2015 17:12:19 -0000." <1447953139625-fadd659d-49861c14-8098fd86@fugue.com>
Date: Fri, 20 Nov 2015 09:56:02 +1100
Message-Id: <20151119225602.B51303D2D96A@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/CCSVAw5EgkQt5ge2cGytbecxZAM>
Cc: homenet@ietf.org
Subject: Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2015 22:56:10 -0000

In message <1447953139625-fadd659d-49861c14-8098fd86@fugue.com>;, Ted Lemon writ
es:
>
> Thursday, Nov 19, 2015 1:49 AM Brian E Carpenter wrote:
> >> Just to clarify, mandatory to implement doesn't mean you have to write
> >> the code.   It means the functionality has to be present in the deployed
> >> implementation so that two communicating partners can be configured to
> >> use it.
> >
> > Um, where is that defined? Is there a BCP that says that?
>
> It's not codified into law, but what else could it mean?   Why would we
> specify something as mandatory to implement if an expression of that
> implementation in running code did not actually contain the
> implementation?
>
> > I don't think a protocol spec can say that feature X cannot be ifdeffed.
> > It can say that a protocol must be capable of X and that implementations
> > must therefore be capable of X. But if you tell implementors that they
> > can't
> > ifdef unused stuff when building images for highly constrained nodes, I
> > don't think they will take you seriously.
>
> The protocol spec would just say MUST implement.   If the implementor
> wants to conditionalize the compilation of the code, we can't stop them
> from doing that, but then they don't have an implementation of the
> specification, and they shouldn't say "supports RFC XXX".   "supports RFC
> XXX" means that anything that is specified in the RFC is asserted to be
> functional in the implementation.
>
> They can perfectly well say "supports a subset of RFC XXX," and I can't
> imagine that anybody would object to that.

Unless they say what the subset they support / don't support, then
I object.  "partial support" is meaningless unless it is qualified.

> --
> Sent from Whiteout Mail - https://whiteout.io
> 
> My PGP key: https://keys.whiteout.io/mellon@fugue.=
> com
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org