Re: [Rats] Use case -> architecture document

"Diego R. Lopez" <diego.r.lopez@telefonica.com> Wed, 09 October 2019 13:00 UTC

Return-Path: <diego.r.lopez@telefonica.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 EB61E120105 for <rats@ietfa.amsl.com>; Wed, 9 Oct 2019 06:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.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 Ua1TYr2pVW7K for <rats@ietfa.amsl.com>; Wed, 9 Oct 2019 06:00:21 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70105.outbound.protection.outlook.com [40.107.7.105]) (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 525CD1200FB for <rats@ietf.org>; Wed, 9 Oct 2019 06:00:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C6MCTwq4Ag9F3e/iRA17EsPiHLCJle95/wj6UJKEoH2k8bpNgkl+drzb7Dxz5175BYiGrU2sZLxnaXksCWBDbEOB+/Q7Ti3Ey4Oue9Ic+Oq7txSjWGxj4cgEp0yX97FKDdJOwvdoJfdHsTpDuP7/0akHIeZ58QEwlv/P3dUOoayUB7uQJQIpiVWElp4jsQ25m77PSwEgiGXCBP9arrmbfNEVgS4g7j4BLwCsHfFoum+BpCOvfpp+a5Kl4XgfTo9bVZzfBIV2nnPGT4dUtywcqbDm+KwlykIXPEo5Lrsw1h7QdgdloYzzFX7Yfx97dEZaQVkOp/+yJmzMZ7gQw4NHXw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QtgscK6Knf6cAN7yBI5nfCxJLmikADtD/y7q4t50TUk=; b=TdM/I9ftVJ34gg6OjGs2l/DEdR6XHY8lPXXTSYZ6GeGACcePGn5NNWDQS4IjTA7Vs7RSJI2yxHExXwyA5yp1Vt/0xVdazljwOzAUjaCC2MOYjUQe9ukawDsOyRCxVW6Tsb5z3hEuPdpWYYpgK5fe7JaaBBwqImVAxVacwZyJiPqagT6KT8ghQH4ykEikoo7GINoZFdE5DfEhk+CdkC2n5vXLQ54hVrsV2LabenPnIXaUduLid5TCZmEPMhnEuCD8Ou/YXwO9I2VEyv5s87M7KCjMm5UpLk3y/grbIeycayqlvwINhMgEqehPCCD32CdzBbghHaeAEqjuDuvo/uv7Vg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QtgscK6Knf6cAN7yBI5nfCxJLmikADtD/y7q4t50TUk=; b=H0u8kS1r61y8gNgNRwjS2fnwx/hc0BSLLMIGMfyiZGA5Z6h33o91sHbJVCCJtlFCW7/E68xlmBnBcg8rEXxCU721szlz2ZMm8+KOl4tEU3UBiLkO7JQH2DIiYl4uMQCvwHqOntNAOHme9y0ssl6l8y7+Z5vZPdEwJvBK21HbSuU=
Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com (52.134.70.148) by DB3PR0602MB3724.eurprd06.prod.outlook.com (52.134.68.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.24; Wed, 9 Oct 2019 13:00:16 +0000
Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::9d2e:16e6:f054:a752]) by DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::9d2e:16e6:f054:a752%7]) with mapi id 15.20.2327.026; Wed, 9 Oct 2019 13:00:16 +0000
From: "Diego R. Lopez" <diego.r.lopez@telefonica.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Use case -> architecture document
Thread-Index: AQHVfpUrB+cR3/fhSUi4jZjwJmbP9adSM9uAgAAzfoA=
Date: Wed, 9 Oct 2019 13:00:16 +0000
Message-ID: <49962FEC-77FB-46D3-8A18-46E00C0DED33@telefonica.com>
References: <CAHbuEH7f0jjquR=iZDgof4DkgpZKgxEP86NcQ0A1NQ=SP+_FHA@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F13E9560C0@dggemm511-mbx.china.huawei.com> <CAHbuEH7WkqeyUW3sL5bdw5N25B6O7ZEF0Qkx03fE5c42Sd4M5w@mail.gmail.com> <b91baad2-2fc3-a5e4-6898-e2cddcda300d@sit.fraunhofer.de>
In-Reply-To: <b91baad2-2fc3-a5e4-6898-e2cddcda300d@sit.fraunhofer.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.e.190909
authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com;
x-originating-ip: [150.214.58.173]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3345ab7e-37f1-49fe-b8d3-08d74cb8a196
x-ms-office365-filtering-ht: Tenant
x-ms-traffictypediagnostic: DB3PR0602MB3724:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <DB3PR0602MB372433F88E13E9192F6BFD47DF950@DB3PR0602MB3724.eurprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 018577E36E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39860400002)(376002)(346002)(366004)(136003)(189003)(199004)(40134004)(99286004)(53546011)(64756008)(186003)(26005)(66066001)(76176011)(478600001)(66446008)(81156014)(66476007)(66574012)(8936002)(966005)(6306002)(6512007)(102836004)(81166006)(25786009)(11346002)(8676002)(66556008)(486006)(2616005)(476003)(45080400002)(66946007)(446003)(76116006)(91956017)(5660300002)(14454004)(36756003)(6506007)(86362001)(110136005)(561944003)(33656002)(14444005)(5024004)(256004)(3846002)(71200400001)(2906002)(7736002)(58126008)(6486002)(6436002)(71190400001)(6116002)(305945005)(786003)(316002)(6246003)(229853002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR0602MB3724; H:DB3PR0602MB3788.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: YLs7wH8C6plhVk81cfDFn/gu5vA82CiUrRJP0wxZdnh1UX0vtCo5SfVDArxqqL/sgk31EiPERTNmUEXWBZea1Yoyiy+eBWmG2Qt7B2S4tQZjImoxvPBbgFItNar3kn3PuSo6P52gD4gKsdzuW9d8XH8Y7F/IP6v97EFYmNglz5a4TKCrllpgqZmwAqxZGtFhslltVNkpYUcEgfRqeGD5vk4tTZ/m6/PSMexgxTApcwoBHaKxwSBbpzy+rou8sxMnsLf4/DZUBZn196Y9BejHmJwRUKk7MHHLgQR+WphV1gOmeBBNzq0FRU2pwObLfgW1EpjrWOoPTWzzLpI5/zWhcipGLo2b27OXiDFZCNQs2GfyR8h8RIvsbxChkijJAgZntenj7dgs9umTSRLPqrcE2NpHoOwCXOeTa4OodNxQd7gXQABA5/y+zTtSLmphl0d34Ho4SGzN74M/z7zy80pfQw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A119D1B2F144D14EBF20C7937A060FBD@eurprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: telefonica.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3345ab7e-37f1-49fe-b8d3-08d74cb8a196
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2019 13:00:16.3535 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: uYBoj81C2yTousV+F/Ysur51T1QE3b91y6bzfJLKq+50AexJN66/xSdCmau7hcexseyIom5cxvQy8APEHgBN65vRYptaF6pz8SepIfAhRcE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0602MB3724
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/FsZ7MtQUQ85iQLsyGsrPN3vQ5tI>
Subject: Re: [Rats] Use case -> architecture document
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: Wed, 09 Oct 2019 13:00:25 -0000

Hi,

Given my current close-to-outsider position (I am afraid other more pressing issues have kept me much further away from RATS that I would have liked to), let me make a proposal in the hope this could synthesize both approaches. I agree with Frank it would be difficult to rewrite a document that has gone through a long process of consensus formation, and rebuilding that consensus with the additional goal of readability may become overly complicated. In that respect, I'd support Henk's comments regarding the identification of concrete ambiguities or statements that can be misinterpreted.

But, since I also acknowledge Kathleen concern on making the architecture well understandable and therefore applicable, I'd suggest we think of preparing a more readable document (or section if you prefer) in the form of describing application scenarios, clarifying how the general (and therefore complicated for novices) architecture can be used, and the assumptions required for that. That would not change the delicate consensus fabric in the whole architecture, making at the same time easier to understand where an how to use it.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 09/10/2019, 13:56, "RATS on behalf of Henk Birkholz" <rats-bounces@ietf.org on behalf of henk.birkholz@sit.fraunhofer.de> wrote:

    Hi Kathleen,
    hi list,

    it would help everybody, if you could explicitly highlight what the
    exact issues wrt readability in the current architecture I-D are -
    always in comparison with the use-case I-D, if it is doing a better job
    in that part?

    Jürgen provided a good example of what he found confusing as a first
    time reader - and that was really helpful and is resulting in ongoing work.

    Please mind, not everything is fleshed out in the architecture (e.g. the
    workflows derived from the use-cases). The plan was to aim for a stable
    nucleus, address the issues raised by the list, go through adoption, and
    finish the document via the issue tracker in a structured process.

    In summary, without an actual understanding why you (or others!) think
    the document is still hard to read, there is no way of compare
    readability later on also. It would be really good to get more precise
    feedback on that.

    Viele Grüße,

    Henk




    On 09.10.19 13:31, Kathleen Moriarty wrote:
    > Hi Frank,
    >
    > Thank you for voicing your concern.  I think some may hold off until the
    > updates are provided, but please do voice your opinions.  I agree that
    > this work is too important and as such, readability is a high priority.
    > If you read through the TEEP and SUIT architecture drafts, they are
    > quite easy to follow and understand.  That is critical for wide spread
    > adoption.  We may be able to find a balance, but I think this exercise
    > may speed progress as we have not decided to adopt this draft yet as a
    > working group item.
    >
    > As it stands, the use case document is not an architecture document, but
    > it could be shaped as such and I'd really like to see if we can do that
    > in short order to have a comparison prior to an adoption call.
    >
    > Best regards,
    > Kathleen
    >
    > On Wed, Oct 9, 2019 at 6:53 AM Xialiang (Frank, Network Standard &
    > Patent Dept) <frank.xialiang@huawei.com
    > <mailto:frank.xialiang@huawei.com>> wrote:
    >
    >     Hi Kathleen,____
    >
    >     __ __
    >
    >     I am very concerned with this new direction and I strongly object.____
    >
    >     __ __
    >
    >     Current architecture draft goes through a lot discussions and
    >     reaches many consensus. Right now, it really helps IETF (Teep for
    >     example), FIDO, TCG and many others. The only issues are on
    >     readability, the standards track and the completeness (e.g.,
    >     passport and background check are still missing). It is an very good
    >     document and correct terminology is very important for remote
    >     attestation.____
    >
    >     __ __
    >
    >     About use cases document, Its goal is just to clarify a sample list
    >     of scenarios that remote attestation can apply to and then deduce
    >     the requirements and the following concrete protocol drafts. It is
    >     not fit to be an architecture.____
    >
    >     __ __
    >
    >     The current architecture is too important for telecom and network
    >     equipment vendors and service providers. I have strong doubts that
    >     current EAT and OTrPv2 alone is suitable for the (virtualized)
    >     network infrastructure situation.____
    >
    >     __ __
    >
    >     B.R.____
    >
    >     Frank____
    >
    >     ____
    >
    >     __ __
    >
    >     This e-mail and its attachments contain confidential information
    >     from HUAWEI, which is intended only for the person or entity whose
    >     address is listed above. Any use of the information contained herein
    >     in any way (including, but not limited to, total or partial
    >     disclosure, reproduction, or dissemination) by persons other than
    >     the intended recipient(s) is prohibited. If you receive this e-mail
    >     in error, please notify the sender by phone or email immediately and
    >     delete it!____
    >
    >     __ __
    >
    >     *发件人:*RATS [mailto:rats-bounces@ietf.org
    >     <mailto:rats-bounces@ietf.org>] *代表 *Kathleen Moriarty
    >     *发送时间:*2019年10月8日19:25
    >     *收件人:*rats@ietf.org <mailto:rats@ietf.org>
    >     *主题:*[Rats] Use case -> architecture document____
    >
    >     __ __
    >
    >     Hello!
    >
    >     I read through the latest version of the ‘use case’ document
    >     yesterday and found it very easy to read and understand, meaning I
    >     think it is written well and could be easily understood by many
    >     without having to climb up a learning curve. ____
    >
    >     __ __
    >
    >     First, this could be a very useful document to register claims for
    >     the use cases.
    >
    >     Second, if the workflow for the passport and background check were
    >     added and put in terms of the open trust protocol v2 from TEEP, we
    >     have a fairly nice architecture document that’s easy to read and may
    >     gain adoption.  The workflows cover the various interactions between
    >     roles and TEEP has actively broken up OTrP in v2 to
    >     accommodate using EAT tokens, this would help create that link and
    >     make it very clear.
    >
    >     The other thing I like about the use case document and think we
    >     should expand on is the references to other work items.  This makes
    >     it an architecture document that maps out the full plan of the WG.
    >     One like that was extremely well received by all the ADs that don’t
    >     like informational/helpful documents.
    >
    >     I’m a bit nervous with the terminology being defined and would love
    >     to see something like this that’s simplified and more easily
    >     adoptable. ____
    >
    >     __ __
    >
    >     I appreciate the work done to improve the architecture document, but
    >     I do think the structure changes to the use case document as
    >     suggested could result in an easier to understand (and therefore
    >     easier to adopt) document.____
    >
    >     __ __
    >
    >     While the architecture document is more readable, I think we can do
    >     better.  Adoption is important and our timeliness matters a lot for
    >     this work.  EATs can be used for may use cases with OTrPv2, so let's
    >     keep it as simple as we can.
    >
    >     Thoughts are appreciated.
    >
    >     Best regards,
    >     Kathleen-- ____
    >
    >     __ __
    >
    >     Best regards,____
    >
    >     Kathleen____
    >
    >
    >
    > --
    >
    > Best regards,
    > Kathleen
    >
    > _______________________________________________
    > RATS mailing list
    > RATS@ietf.org
    > https://www.ietf.org/mailman/listinfo/rats
    >

    _______________________________________________
    RATS mailing list
    RATS@ietf.org
    https://www.ietf.org/mailman/listinfo/rats



________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição