Re: [GNAP] Concerns with the lack of progression of GNAP after 20 months of work

Denis <denis.ietf@free.fr> Tue, 01 March 2022 13:30 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217333A092B for <txauth@ietfa.amsl.com>; Tue, 1 Mar 2022 05:30:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.128
X-Spam-Level:
X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 Tyk9UZjuY0-J for <txauth@ietfa.amsl.com>; Tue, 1 Mar 2022 05:30:30 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (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 AE3FB3A0925 for <txauth@ietf.org>; Tue, 1 Mar 2022 05:30:29 -0800 (PST)
Received: from [192.168.1.11] ([82.121.202.228]) by smtp.orange.fr with ESMTPA id P2aAnnD2GVKleP2aAnJar5; Tue, 01 Mar 2022 14:30:27 +0100
X-ME-Helo: [192.168.1.11]
X-ME-Auth: OWU3ZmVkYWM0M2UwZWM1YifxM2Q3ZDk1YiUzNWJiZTM2MiliMTI0N2YxZmQ=
X-ME-Date: Tue, 01 Mar 2022 14:30:27 +0100
X-ME-IP: 82.121.202.228
Content-Type: multipart/alternative; boundary="------------Igdbm0000VR6wE8cEh0De008"
Message-ID: <58fdd803-00ad-519c-0781-b0b7259d4098@free.fr>
Date: Tue, 01 Mar 2022 14:30:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
Content-Language: en-GB
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: GNAP Mailing List <txauth@ietf.org>
References: <5d89f969-2e67-32f4-e06b-e230453a906f@free.fr> <CAM8feuQ84ECPZnTsWcbrt4sqR2kS5bgP8m3=RSO9bq-4qJngFg@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
In-Reply-To: <CAM8feuQ84ECPZnTsWcbrt4sqR2kS5bgP8m3=RSO9bq-4qJngFg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/Q7dZrOffyJoi_wfelVCd2BS2kXM>
Subject: Re: [GNAP] Concerns with the lack of progression of GNAP after 20 months of work
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2022 13:30:32 -0000

Fabien,

It is not useful to send flames.

It would be much better that you spend time to respond to the issues 
raised on draft-ietf-gnap-resource-servers-01
and publish a new draft that addresses these issues and in the mean time 
provide a summary of the way these issues have
been addressed (including the issues you don't agree with).

"Stabilizing the core draft" and "focusing on real world 
implementations" without progressing the resource-servers draft
looks like a headlong rush.

Denis


> Dear Denis,
>
> Sorry I have to say this, but repeating your misconceptions don't make 
> them true. That's currently not helping anyone going forward.
>
> The editors and chairs welcome anyone with helpful contribution.
> Already the spec had many great improvements, from many outstanding 
> individuals cited in the text. Including on security and privacy.
>
> We are now stabilizing the core draft and focusing on real world 
> implementations to demonstrate the value and interoperability.
>
> Best regards,
> Fabien (speaking only in my own name)
>
>
>
>
> On Tue, 1 Mar 2022, 12:49 Denis, <denis.ietf@free.fr> wrote:
>
>     Hello everybody,
>
>     GNAP has four main components : users, clients, ASs and RSs.
>
>     GNAP is supposed to describe a protocol. A protocol is a set of
>     rules that control the way data is exchanged between computers.
>     A reader would expect to find the description of the data sent by
>     a client to a RS (which are indeed described in
>     ietf-wg-gnap/core-protocol),
>     but also find how that data *shall be handled by a RS* which is
>     supposed to be described in draft-ietf-gnap-resource-servers.
>     Unfortunately,
>     this is not the case.
>
>     The focus has been placed on the "core" protocol, leaving aside
>     the the RS.
>
>     The core document (ietf-wg-gnap/core-protocol) has now got more
>     than 400 issues !
>
>     Besides the editors (and the chair), very few members are active
>     and at this time it is unlikely that more members will participate
>     since *the main driving line for the construction of GNAP has been
>     los**t*.
>
>     The recent message called "embedding GNAP" got no reply from the
>     WG, except one from a co-editor.
>     IMO, this demonstrates that *GNAP is still a **moving target*
>     *after 20 months of work.*
>
>     Does this mean that all the WG members agree with the very few
>     emails that are exchanged or that the WG members are
>     no longer really able to participate to the discussion since such
>     participation would involve a lot of days to get "up to speed"
>     again ?
>     I would guess that the right answer is the latter.
>
>     The core document has still *no security model *and hence its
>     security is more than questionable.
>
>     The core document is AS centric and hence *the **privacy concerns
>     of the users cannot be addressed*. Is this deliberate ?
>     When the work started, privacy was supposed to be a major concern
>     to be taken into consideration, but in practice, this is not the case.
>
>     The core document still does not address the general use case.
>
>     There are so many options that *interoperability will not be
>     possible*.
>
>     *draft-ietf-gnap-resource-servers-01**expired on 13 January
>     2022*.  We are now close to an IETF meeting and no draft is available.
>
>     The milestones are outdated and, anyway, are not observed
>     (seehttps://datatracker.ietf.org/doc/charter-ietf-gnap/writeup/)
>
>     Milestones:
>
>        Jul 2021 - Core delegation protocol in WGLC
>
>        Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to WGLC
>
>        Oct 2021 - Key presentation mechanism binding to the core protocol, detached HTTP signatures, to WGLC
>
>        Oct 2021 - Key presentation mechanism binding to the core protocol, embedded HTTP signature, to WGLC
>
>        Dec 2021 - Guidelines for use of protocol extension points to WGLC
>
>        Feb 2022 - Guidelines on migration paths, implementation, and operations to WGLC
>
>     At the next IETF meeting, rather than addressing, /as usual,/ the
>     last technical issues that no one or very few people will be able
>     to follow or understand,
>     I would suggest that the editors address the following topics:
>     *interoperability*, *privacy *and *security *at a level that will
>     allow everybody to understand
>     the real issues behind these three words and by presenting *a
>     balanced view*.
>
>     Denis
>
>     PS: If we were working within ISO, this WG would already have been
>     closed.
>
>     -- 
>     TXAuth mailing list
>     TXAuth@ietf.org
>     https://www.ietf.org/mailman/listinfo/txauth
>