Re: [Anima] join proxy documents

Sheng Jiang <jiangsheng@huawei.com> Mon, 28 September 2020 02:02 UTC

Return-Path: <jiangsheng@huawei.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A373A0C26 for <anima@ietfa.amsl.com>; Sun, 27 Sep 2020 19:02:33 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GC1Ud3Dx9Ich for <anima@ietfa.amsl.com>; Sun, 27 Sep 2020 19:02:31 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 72CBC3A0C0A for <anima@ietf.org>; Sun, 27 Sep 2020 19:02:31 -0700 (PDT)
Received: from lhreml716-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B85B039E8504D3DB56DA; Mon, 28 Sep 2020 03:02:26 +0100 (IST)
Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by lhreml716-chm.china.huawei.com (10.201.108.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 28 Sep 2020 03:02:26 +0100
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 28 Sep 2020 10:02:23 +0800
Received: from nkgeml708-chm.china.huawei.com ([10.98.57.160]) by nkgeml708-chm.china.huawei.com ([10.98.57.160]) with mapi id 15.01.1913.007; Mon, 28 Sep 2020 10:02:23 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, "Michael Richardson" <mcr+ietf@sandelman.ca>
CC: Toerless Eckert <tte@cs.fau.de>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: [Anima] join proxy documents
Thread-Index: AQHWkRv+wGQpoUeF0kmDvt3g3ZlNQql3yZKAgABFTYCAA8Q2AIABf+tQ
Date: Mon, 28 Sep 2020 02:02:23 +0000
Message-ID: <82b4ad9c67804f5dbf844607e8d46ad1@huawei.com>
References: <160079703540.29540.367719454414521470@ietfa.amsl.com> <7598.1600805209@localhost> <20200924212331.GA59677@faui48f.informatik.uni-erlangen.de> <22480.1600997493@localhost> <4e4a610e9ef9a6d3ebe2f106f6573f78@bbhmail.nl>
In-Reply-To: <4e4a610e9ef9a6d3ebe2f106f6573f78@bbhmail.nl>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.181.26]
Content-Type: multipart/alternative; boundary="_000_82b4ad9c67804f5dbf844607e8d46ad1huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/2L1R6CFbtpcZDfDOfMD9pv2QmYc>
Subject: Re: [Anima] join proxy documents
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Sep 2020 02:02:34 -0000

Hi, Peter,

Thanks for your email. With my chair-hat on, I can confirm that join-proxy is in the scope and interest of ANIMA WG. The chairs have a plan to adopt several documents after we completed the long-delayed RFC-tobe documents. Now, we are in the last step of it, hopefully: ACP document has last two small DISCUSSes, which in my opinion has been addressed by the latest update and we are waiting the ADs to clean them.

Thanks for your efforts and patient.

Sheng

From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Peter van der Stok
Sent: Sunday, September 27, 2020 7:03 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Toerless Eckert <tte@cs.fau.de>de>; anima@ietf.org
Subject: Re: [Anima] join proxy documents

Dear all,

After a long silence, I want to manifest my interest in both documents:
- constrained-voucher that extends and completes [ace]est-coaps to cover all non-est brski cases using coap,
- contrained-join-proxy that standardizes the stateless proxy using coap and coap discovery.

The first document is an anima WG document, which has progressed very slowly waiting for keyinfra to conclude.
The second was intended as anima WG document once the new anima charter was adopted.

The separation in two documents makes sense in my opinion.
I don't know why the join-proxy document has slided over the WG horizon. I still hope that the WG wants to adopt join-proxy.
Implementations of both douments are in progress at this moment.

cheerio, and thanks,

Peter van ders Stok


Michael Richardson schreef op 2020-09-25 03:31:

Toerless Eckert <tte@cs.fau.de<mailto:tte@cs.fau.de>> wrote:
    >> I have changed occurances of EST Server to "BRSKI Registrar", as I
    >> think that is more accurate.

    > Not in draft-richardson-anima-state-for-joinrouter from my quick read.

No, that document is background and it is not intended for publication, and I
didn't change anything in it.

    >> Did we really want to standardize the StateFUL join proxy?

    > Uhmm... isn;t that what we're doing with BRSKI proper ? That's a
    > stateful join proxy, right ? Aka: your question seems to be missing
    > some more context (stndardize stateful join proxy for context
    > XXXX... ?)


Title:        Constrained Join Proxy for Bootstrapping Protocols
Document date:    2020-09-22
Group:        Individual Submission

The stateful method is same as BRSKI, but over CoAP, rather than HTTPS.
That's why I'm asking if it is at all useful to specify anything.

    >> Is it really interesting or relevant?  It seems trivial.  If we are,
    >> then we should contrast it.  An important clue is that it does not
    >> behave any differently, FROM THE PLEDGE point of view.
    >>
    >> The WG had expressed an interest in adopting this document, but the WG
    >> chairs have not provided any clear guidance on where they we go.

    > I thought we primarily had the issue of the named author having
    > unfortunate issues to drive the document. If you want to take on the
    > ditors helm for it, then the chairs will be happy to proactively see
    > how to progress the document in the WG...

Peter, Panos and I are authors.
Yes, some of the authors had time constraints, but that's why we have more
than one author, isn't it?

    >> This document could be merged into ietf-constrained-voucher, but I
    >> think we made it a separate document because it is not needed on all
    >> networks, just *constrained* multihop/MESH networks.

    > Yes, we have some decisions to make wrt. how much to merge into fewer
    > documents and how much to keep the solution definition modular.

    > Given how we went through half a decade of probably too-big-documents
    > in ANIMA, as an individual conributor i would err on the side of more
    > smaller documents, but i guess as a WG chair i should just leave it to
    > authors and rough consensus of the WG.

Well, constrained-voucher started out as being constrained-RFC8366,
with the intention of having a constrained-BRSKI document.
(Direction towards: more documents).
During that period, we managed to split of est-coaps-ace, which is in the
RFC-editor queue.

Then constrained-voucher ate up constrained-BRSKI, and now it is bigger.

I would say, that the WG should adopt the work based upon what things it
wants to solve, and then if content needs to be shifted around, merged,
split, etc. then the WG can decide that.

--
Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr+IETF@sandelman.ca>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
Anima mailing list
Anima@ietf.org<mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima