Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.txt

Joe Clarke <jclarke@cisco.com> Mon, 14 August 2017 20:41 UTC

Return-Path: <jclarke@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB977132425 for <opsawg@ietfa.amsl.com>; Mon, 14 Aug 2017 13:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 MYzOrgVlCkRz for <opsawg@ietfa.amsl.com>; Mon, 14 Aug 2017 13:41:23 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E104D126E64 for <opsawg@ietf.org>; Mon, 14 Aug 2017 13:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2954; q=dns/txt; s=iport; t=1502743282; x=1503952882; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=VGFXvLBvymxvN537vYSanMmN349RPnCrQOidTZ49H40=; b=QrbyhtbAuo6ZQtjPc5kXt0NNRh8oC/FP4M7EikExkatdioUlqfIrwSPM INsqfSA7PjLEB7cOk07FICxzLtHK5gqJyOtj0f2KcsercuGBCYU/cu5jX 5IdYOKh6CufEFyLzc4N2qa3W+fBC42PjtIBOlZr/pxfj2bjF7sMJ8HQ/J E=;
X-IronPort-AV: E=Sophos;i="5.41,374,1498521600"; d="scan'208";a="280428494"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2017 20:41:22 +0000
Received: from [10.118.87.86] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7EKfMig022465; Mon, 14 Aug 2017 20:41:22 GMT
To: Eliot Lear <lear@cisco.com>
Cc: opsawg@ietf.org
References: <150248175729.24498.16927681607334663849@ietfa.amsl.com> <9956db24-0a43-c739-d729-c580ff037cc7@cisco.com> <0994d0ba-714d-3b5c-8542-06ee19dceef1@cisco.com> <d5792b03-266f-5d93-d9db-f39d2605869d@cisco.com>
From: Joe Clarke <jclarke@cisco.com>
Organization: Cisco
Message-ID: <f8d42656-a7eb-743c-fe8e-17b17b0e4721@cisco.com>
Date: Mon, 14 Aug 2017 16:41:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <d5792b03-266f-5d93-d9db-f39d2605869d@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/oEo1ejPUgIVgglthduSpNIjjw4s>
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Aug 2017 20:41:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/14/17 16:07, Eliot Lear wrote:
>> Section 1.6:
>> 
>> A MUD file is more than just a behavior.  It lists details about
>> a Thing such as whether or not it's supported, details about it
>> from a reference URL, etc.  Perhaps the definition of a MUD file
>> should be "...JSON that describes a Thing and its required
>> network behavior."
> 
> I would prefer to run with "suggested" than "required".  The
> analogy has always been an indications label that comes with
> medicine.  You can go off label if you want, Mme. Administrator,
> even if it isn't recommended.

Yes, I agree.  Very good distinction.

>> Section 6:
>> 
>> Should the timers for last-update and cache-validity be
>> mandatory?  As it stands now, nothing in metainfo is mandatory,
>> and I think some things (like the timers) should be.  I also
>> think is-supported is key.
> 
> That's a good question and I like the list that you identified.  I
> think this requires some additional discussion, though, just to
> confirm model structure.  I'll come back to you on this.

Count me in.  I thought about this section for a little bit before
writing this, and I got really comfortable with the notation of the
timers and is-supported being the only mandatory elements.

>> 
>> Sections 7.1 and 7.2:
>> 
>> I would imagine at some level these names would have to be
>> resolved. Perhaps what you mean as to when they are resolved is
>> left to the implementation?  That is to say, some vendors may
>> resolve at the time of configuration whereas others may resolve
>> more dynamically.
> 
> I think I want to say more than that.
> 
> What I'm thinking about is as follows:
> 
>> A number of    means may be used to resolve hosts.  What is 
>> important is that such resolutions be consistent with ACLs
>> required by devices  to properly operate.

I like this text.  I would only add some element of time to this to
indicate that hosts may be resolved at different points in the packet
processing path, and attention should be paid to how this is done to
ensure any changes that may occur in resolution.

Ugh, that just made me think.  Maybe there should be a manufacturer
considerations blurb that says that different vendors may do
resolution differently, and if a manufacturer uses DNS with a
round-robin set of addresses, it may cause discrepancies in what ACLs
will allow (based on the controller/network device that does the
resolution).

I feel this kind of thing should be made more explicit to ensure that
The Right Thing gets done on the network.

Thanks for your attention, Eliot.  Like I said, I continue to enjoy
the readability of this document.

Joe
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWZIK7gAKCRBvaI+K/hTP
h1ZTAJ95fS/ntTC/niRALDNy350krVo8wACfZbPg7SPWTFHCXHrS62UeAnzJFyg=
=Bhr7
-----END PGP SIGNATURE-----