Re: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20

Robert Sparks <rjsparks@nostrum.com> Wed, 11 April 2018 18:21 UTC

Return-Path: <rjsparks@nostrum.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 43640126CD8; Wed, 11 Apr 2018 11:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 ESYQ0-UJDBkL; Wed, 11 Apr 2018 11:21:47 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F7D126C89; Wed, 11 Apr 2018 11:21:47 -0700 (PDT)
Received: from unescapeable.local ([47.186.15.50]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w3BILi5P005403 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Apr 2018 13:21:44 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.15.50] claimed to be unescapeable.local
To: Eliot Lear <lear@cisco.com>, gen-art@ietf.org
Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org
References: <152329667548.30723.13155842895888603902@ietfa.amsl.com> <10591659-b464-ad66-a499-6567202cc782@cisco.com> <efb9927a-a0af-9578-096f-e5185316aa4f@nostrum.com> <b18d6e8f-7b31-158a-d4e8-e1e834211025@cisco.com> <8cbc1f68-488b-ac57-91c1-2a95a6446129@nostrum.com> <217a3f98-5c2e-0ade-1765-eb226fa5cd72@cisco.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <f7579588-7d31-bff4-15e0-4692097957cf@nostrum.com>
Date: Wed, 11 Apr 2018 13:21:44 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <217a3f98-5c2e-0ade-1765-eb226fa5cd72@cisco.com>
Content-Type: multipart/alternative; boundary="------------18C9CE2CB4E0657B76C4FE5F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/fx9vnEcoPHUO-1ewyDfdMY2n50k>
Subject: Re: [OPSAWG] Genart telechat review of draft-ietf-opsawg-mud-20
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: Wed, 11 Apr 2018 18:21:49 -0000


On 4/11/18 11:58 AM, Eliot Lear wrote:
>
> All the way down...
>
>
> On 11.04.18 18:15, Robert Sparks wrote:
>>
>>>
>>> Similarly, the use of the word standardized naked like that is 
>>> probably unhelpful.
>> Can I infer you plan to edit it out or dress it more?
>
> Yes.
>
>>> One could imagine, for instance, Fairhair or some other consortium 
>>> deciding to create standard classes.
>>>
>>> What I propose is two changes to facilitate better understanding:
>>>
>>>  1. To include the simple example described above.
>>>  2. To add an optional "documentation"  element in the "mud"
>>>     container that consists of a URL that points to documents for
>>>     each class, when so used.
>>>
>> Sure.
>>>
>>> Thoughts?
>>>
>> With this, I'm puzzled about the use of the word standardized at all. 
>> I think I'm hearing that you expect MUD controllers to know about 
>> some well-known classes by convention and that groups like fairhair 
>> or someone else might make a list of classes that MUD controllers 
>> might collectively decide to build in knowledge of. Am I getting 
>> closer to the right picture? (This is opposed to a set of classes 
>> that are created by a standards action and listed in a registry 
>> somewhere).
>
> The class is just a name that expands out to a bunch of IP addresses.  
> It happens to take the form of a URI, but it's really just a name.  
> There could be well known NAMES, and indeed we create a URN registry 
> just for that purpose.  Maybe I need to be a bit more clearer on that 
> point?
Probably good to do? I hope I'm not just being too thick-headed here.
>
> Eliot