Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

bruno.decraene@orange.com Mon, 13 September 2021 09:49 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880DE3A0EE4 for <spring@ietfa.amsl.com>; Mon, 13 Sep 2021 02:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 cnFOBO_I_1jY for <spring@ietfa.amsl.com>; Mon, 13 Sep 2021 02:49:35 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 090353A0EE2 for <spring@ietf.org>; Mon, 13 Sep 2021 02:49:35 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr20.francetelecom.fr (ESMTP service) with ESMTPS id 4H7MC05bpgz2017; Mon, 13 Sep 2021 11:49:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1631526572; bh=Ix8qaWYu5H+fEycQl9vj5s1Yc12I2Uo1Gx779uO06D0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=pdVV9yY+fsmutuwQnylPpO1JDT3gqn1XwwTKe2b0yfq3D9brDcf2d+PMz3CNixePM t6K75toOlw1DFIow7+kzQg0Wdkn+othyuz+q4KnZWtVIJZJy/utx+9vO5S5khjAb9q NXWOjH6foN/7XYaQZP2ktgNeGWUxm47qaV8fw/tSKmewpY23w77ew/GKFrc8ilow4b fftp+LH4f+UFexcOeuI2GKlMIH3+8wGOdDYj3EFNdoI2T5ZGcEGhNTprOaH170Es5J TLDdTLZPq4pFNlQYSH3xdeXG3FMZY8HZAfuhz/kIlnuzeEhFBrKH8CXjk/NP7FCg4A G+UrXPyLdPDQQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr05.francetelecom.fr (ESMTP service) with ESMTPS id 4H7MC04dQGzyQ6; Mon, 13 Sep 2021 11:49:32 +0200 (CEST)
From: bruno.decraene@orange.com
To: Ron Bonica <rbonica@juniper.net>
CC: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis
Thread-Index: Adej6fEfucpaNY0DSOmZKpSUpxaE9wCjaDaQAIIZdNA=
Date: Mon, 13 Sep 2021 09:49:31 +0000
Message-ID: <28058_1631526572_613F1EAC_28058_447_1_53C29892C857584299CBF5D05346208A4CEABF02@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <15436_1631020356_61376544_15436_364_1_53C29892C857584299CBF5D05346208A4CE99E43@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <BL0PR05MB5316751D7554E56FDA5CBB30AED69@BL0PR05MB5316.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB5316751D7554E56FDA5CBB30AED69@BL0PR05MB5316.namprd05.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A4CEABF02OPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ca7JmX9nMOZtDjriwXff5uplLlI>
Subject: Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2021 09:49:41 -0000

Ron,

It looks to me that you are quite well aware of the whole IETF process; but if not [1] may be a good starting pointer.

This WG adoption call is not expected to be any different than other WG adoption calls.

You are right that WG adoption of a document means that the WG own the document and so its content. But WG adoption of a document only make sense if the wg believe that the document is a good starting point: we are not adopting the title but the whole document.

Your below email is not crystal clear to me with regards to whether or not you have a concern with the document.
If you have specific concern(s) on the document or some part/sentences in the document, could you please state those concerns on the mailing list?

>From the informational document that you have cited, below are two questions which seem related to your email. If you wish to, you are also welcome to voice your opinion on these two points.

   *  Does the document provide an acceptable platform for continued effort by the working group?

   *  What are the process or technical objections to adoption of the draft?


> If so, I support adoption of this draft.

Which one?


[1] https://www.ietf.org/standards/process/

--Bruno


From: Ron Bonica [mailto:rbonica@juniper.net]
Sent: Friday, September 10, 2021 9:16 PM
To: DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>; spring@ietf.org
Subject: RE: WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Bruno,

When a WG adopts a design team draft, I assume that the draft becomes subject to the following guidelines from RFC7221:

"Once a working group adopts a draft, the document is owned by the working group and can be changed however the working group decides, within the bounds of IETF process and the working group charter.  Absent explicit agreement, adopting a document does not automatically mean that the working group has agreed to all of its content.  So a working group (or its charter) might explicitly dictate the basis for retaining, removing, or modifying some or       all of a draft's content, technical details, or the like. However, in the absence of such constraints, it is worth having the adoption process include a sub-process of gathering working group concerns about the existing draft and flagging them explicitly."

Do I have that right?

If so, I support adoption of this draft.

                                                                Ron



Juniper Business Use Only
From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>
Sent: Tuesday, September 7, 2021 9:13 AM
To: spring@ietf.org<mailto:spring@ietf.org>
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

[External Email. Be cautious of content]

Dear WG,


The Design Team has produced two documents:
- A requirement document: draft-srcompdt-spring-compression-requirement
- A solution analysis document: draft-srcompdt-spring-compression-analysis

Both have been presented to the WG and triggered some discussions but are still individual documents.
We believe it's now time for the WG to consider taking ownership of those two documents.
Note that, especially for those two documents, WG adoption does not necessarily mean RFC publication in particular if it turns out that the benefit of long term archive would not justify the WG and IESG effort to finalize those two documents.


This message starts a 2 week WG adoption call, ending September  20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!T1i99K3HoodKT8vePZSAAOBS5cz0a3fTWlQEk5xTiZa05lP82zMKOvwMhUozCY2f$>
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis__;!!NEt6yMaO-gk!T1i99K3HoodKT8vePZSAAOBS5cz0a3fTWlQEk5xTiZa05lP82zMKOvwMhc0iIRXo$>


After review of the document(s) please indicate support (or not) for WG adoption of the document(s) to the mailing list.
Please also provide comments/reasons for your support (or lack thereof) as this is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on the document(s), please state this explicitly. This gives the chairs an indication of the energy level of people in the working group willing to work on the document.

Thanks!

Jim, Bruno & Joel


_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.