Re: [L2sm] Proposed Liaison to 3GPP SA5

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 05 June 2018 18:46 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: l2sm@ietfa.amsl.com
Delivered-To: l2sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E355A126F72 for <l2sm@ietfa.amsl.com>; Tue, 5 Jun 2018 11:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 OEKNfWw2XKfM for <l2sm@ietfa.amsl.com>; Tue, 5 Jun 2018 11:46:40 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 14A18120049 for <l2sm@ietf.org>; Tue, 5 Jun 2018 11:46:39 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w55IkYnd032697; Tue, 5 Jun 2018 19:46:34 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5684C220A4; Tue, 5 Jun 2018 19:46:34 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id 411CC220A3; Tue, 5 Jun 2018 19:46:34 +0100 (BST)
Received: from 950129200 (243.125.113.87.dyn.plus.net [87.113.125.243]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id w55IkWfp006122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2018 19:46:33 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Roque Gagliano (rogaglia)'" <rogaglia@cisco.com>, l2sm@ietf.org
References: <000901d3fbf5$5648d790$02da86b0$@olddog.co.uk> <7ee2d1342bf6403583d834a1ae3f2d7d@TELMBXB02RM001.telecomitalia.local> <01a901d3fce6$00486b20$00d94160$@olddog.co.uk> <2717B04F-A52D-4F07-BCD6-54672978429E@cisco.com> <01c401d3fcf3$c389b230$4a9d1690$@olddog.co.uk> <D14DDD23-258C-4839-9CF8-4A9E989878F9@cisco.com>
In-Reply-To: <D14DDD23-258C-4839-9CF8-4A9E989878F9@cisco.com>
Date: Tue, 05 Jun 2018 19:46:30 +0100
Message-ID: <01c901d3fcfd$856d13c0$90473b40$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIOf7qJKx24xl1w/pQ68zsvGbGRtQGs1yWjAcptn+ICAJuhNwG6lm/OAV6uH4ujmGIl0A==
Content-Language: en-gb
X-Originating-IP: 87.113.125.243
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23890.002
X-TM-AS-Result: No--3.810-10.0-31-10
X-imss-scan-details: No--3.810-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23890.002
X-TMASE-Result: 10--3.810400-10.000000
X-TMASE-MatchedRID: y/2oPz6gbviPrjM/ltMU+f3NPiyUzKzdfiuvKi9huaZpqha3YpyKAehX LEExrIL/kR9MOvz8VqEYDMVArrOpeNkrWtCrI2IZk3ewifG2MNP4qCLIu0mtIDyC5ddG2Jcgwlo iM2+R0bfYgJy0r7VcQp45RxC2/QwFe2AvRmABnavpnOP6QxEGtgvxMaV6x4s8PcFkClcmQNtIQA ER+BbtZkRVGYDKxLuZPvVXY0wrjf0zbFnmpCkYKZVRzPxemJL0QKuv8uQBDjosugxReYWqZmwqS TpOVkRPZrQgkV2QKyrzzLgvahRmiwzyMxeMEX6wgxsfzkNRlfL+VmoNXJ/8FNRnEQCUU+jzjocz muoPCq1oSsz4v/0QoEFHBROZNx1dClQDk14pJwRBhxObBOHyWLwOJrejHY0qt87/yguFckdZgHZ o3m1ooI/NBH9y6s4SCElU2rFM982vY4BboIs67rHhMA9aDpuh/WyINg5Mqdqespy8+E36a0PhZp 6NP5kf
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/NaY5lwg6Kq3Qj40jrApIMCY_iSY>
Subject: Re: [L2sm] Proposed Liaison to 3GPP SA5
X-BeenThere: l2sm@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <l2sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2sm>, <mailto:l2sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2sm/>
List-Post: <mailto:l2sm@ietf.org>
List-Help: <mailto:l2sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2sm>, <mailto:l2sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jun 2018 18:46:44 -0000

Hi again,

It has been a while since anyone quoted 2026 at me :-)

I think you have interpreted the text you quote the wrong way around. It is true that you cannot take an Informational RFC and make any assumption of IETF consensus. That is, it is possible to have Informational RFCs that have or do not have IETF consensus. The second paragraph describes documents that are produced under what is now called the Independent Submissions stream: they are Informational RFCs that do not (cannot) have IETF consensus.

You might find RFC 7841 helpful in understanding how IETF consensus can be applied across a range of documents: mandatory for some; optional for others.

The IESG Statement at https://www.ietf.org/blog/last-call-guidance-community/?secondary_topic=22&primary_topic=7& makes clear that the IESG considers it reasonable to IETF last call an Informational RFC. I believe that the current IESG continues the practice of issuing IETF last call and so judging IETF consensus on all RFCs on the IETF stream.

Cheers,
Adrian

> The definition of IETF informational models can be found in RFC 2026 section
> 4.2.2:
> 
> --------
> 4.2.2  Informational
> 
>    An "Informational" specification is published for the general
>    information of the Internet community, and does not represent an
>    Internet community consensus or recommendation.  The Informational
>    designation is intended to provide for the timely publication of a
>    very broad range of responsible informational documents from many
>    sources, subject only to editorial considerations and to verification
>    that there has been adequate coordination with the standards process
>    (see section 4.2.3).
> 
>    Specifications that have been prepared outside of the Internet
>    community and are not incorporated into the Internet Standards
>    Process by any of the provisions of section 10 may be published as
>    Informational RFCs, with the permission of the owner and the
>    concurrence of the RFC Editor.
> --------
> 
> That is my point, you can't call it consensus as the purpuse of an informational
> model is not to reach consensus.
> 
> Roque