IETF Logo Mail Archive

Re: [Rats] What's to EAT? - terminology clarification

"Smith, Ned" <ned.smith@intel.com> Thu, 14 November 2019 19:57 UTC

Return-Path: <ned.smith@intel.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96111200CD for <rats@ietfa.amsl.com>; Thu, 14 Nov 2019 11:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 YWeG5QeDWXc5 for <rats@ietfa.amsl.com>; Thu, 14 Nov 2019 11:57:04 -0800 (PST)
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0215812007A for <rats@ietf.org>; Thu, 14 Nov 2019 11:57:03 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2019 11:57:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.68,305,1569308400"; d="scan'208";a="235804989"
Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by fmsmga002.fm.intel.com with ESMTP; 14 Nov 2019 11:57:01 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX110.amr.corp.intel.com ([169.254.10.52]) with mapi id 14.03.0439.000; Thu, 14 Nov 2019 11:57:01 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>, Laurence Lundblade <lgl@island-resort.com>
CC: "Salz, Rich" <rsalz@akamai.com>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] What's to EAT? - terminology clarification
Thread-Index: AQHVmaxQg/JbqfbFf0mfD9c0xlySNKeIK3rwgAALoICAAAAtIIAANPyAgABD4QCAATfogIABVZSA///aYQA=
Date: Thu, 14 Nov 2019 19:57:00 +0000
Message-ID: <6D4432CB-3C86-4B86-AAF2-B9B057735615@intel.com>
References: <229E0A72-4B44-4C9A-AD0A-142A13020C9A@intel.com> <MWHPR21MB0784058F591C52EEB31E0736A3770@MWHPR21MB0784.namprd21.prod.outlook.com> <4F586E15-9CF7-4824-87F2-8E2C20D1AF1D@intel.com> <MWHPR21MB078439E9EB07E3BB72E15137A3760@MWHPR21MB0784.namprd21.prod.outlook.com> <71173EC8-A167-47B9-B0F1-05759D59890B@akamai.com> <20191113071244.onqdgo2roqt7efb6@anna.jacobs.jacobs-university.de> <B555FC8E-FF3B-468A-B3DF-9F10DD6FBBF6@island-resort.com> <20191114141138.dipzizem6a6wh6cr@anna.jacobs.jacobs-university.de>
In-Reply-To: <20191114141138.dipzizem6a6wh6cr@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-originating-ip: [10.24.10.107]
Content-Type: text/plain; charset="utf-8"
Content-ID: <DD04D5175BE6F043B9AA1C95F2E7F197@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/9nEUgnmqgwk-SAg5hkJI990w-kY>
Subject: Re: [Rats] What's to EAT? - terminology clarification
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2019 19:57:06 -0000

Protocols and binding of data to protocol can use a protocol modelling (PM) language (e.g. RAML). Another thread cited RFC-8641 which uses YANG to define subscription protocol interaction suggests YANG can be used for protocol modeling. Interestingly, RFC-8642 uses mostly XML encoding (EN) or structured text (IM) for most of its examples. 

YANG fits as a DM and a PM.
RAML is a PM for REST. (though may not be interesting in terms of current drafts).
XML is an EN that can be added. (Though it may not make sense to assume CDDL as an XML encoding).

On 11/14/19, 6:12 AM, "RATS on behalf of Schönwälder, Jürgen" <rats-bounces@ietf.org on behalf of J.Schoenwaelder@jacobs-university.de> wrote:

    On Wed, Nov 13, 2019 at 09:49:05AM -0800, Laurence Lundblade wrote:
    > 
    > Currently there are two claims encodings, CBOR and JSON. Thanks to CDDL, we get from data model to encoding in a largely mechanical way and there is little text needed.
    > 
    > 
    >                 IM: Text
    >                 |
    >                 +
    >                 |
    >                 DM: CDDL
    >                 |
    >             +---+--+
    >             |      |
    >            CBOR   JSON
    > 
    > 
    > I think this is a good, simple and effective way to proceed.
    
    This basic model works for me.
    
    /js
    
    -- 
    Juergen Schoenwaelder           Jacobs University Bremen gGmbH
    Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
    Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
    
    _______________________________________________
    RATS mailing list
    RATS@ietf.org
    https://www.ietf.org/mailman/listinfo/rats

v2.23.0 | Report a Bug | By Email