Re: [L2sm] Proposed Liaison to 3GPP SA5

"Roque Gagliano (rogaglia)" <> Tue, 05 June 2018 19:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FBD013114D for <>; Tue, 5 Jun 2018 12:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N2idYWjoSP89 for <>; Tue, 5 Jun 2018 12:53:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1059513116C for <>; Tue, 5 Jun 2018 12:53:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4086; q=dns/txt; s=iport; t=1528228405; x=1529438005; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5zfErwpE8MsMQRbJOMDIPJfemNfeUI4InOtdaleKLYk=; b=drXsONEdF/Wxfd5dmYarYspbrLK53Nfjk91fDuv0dG7fEYO4v+UHyDvE Ff70cMlwj/RJ2i8TBBgZQs2iG9PLDoB6LbPKkkVfxaInqBvE1d5cSfLMM ze5wgNwZ7OWP2wfS3chTbge4j+8Hd14SIAWgtzhdu7pjzjN828x5zTabK I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.49,479,1520899200"; d="scan'208";a="409324379"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2018 19:53:24 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w55JrNGB023082 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jun 2018 19:53:24 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Jun 2018 15:53:23 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Tue, 5 Jun 2018 15:53:23 -0400
From: "Roque Gagliano (rogaglia)" <>
To: "" <>, "" <>
Thread-Topic: [L2sm] Proposed Liaison to 3GPP SA5
Thread-Index: AdP77mZy+ziBQucgTuOCdr0I0+8PugABou9AADovkiAACnVnAAAFuTuA///tvQCAACL1gP//8I4AgAA0NYA=
Date: Tue, 5 Jun 2018 19:53:23 +0000
Message-ID: <>
References: <000901d3fbf5$5648d790$02da86b0$> <7ee2d1342bf6403583d834a1ae3f2d7d@TELMBXB02RM001.telecomitalia.local> <01a901d3fce6$00486b20$00d94160$> <> <01c401d3fcf3$c389b230$4a9d1690$> <> <01c901d3fcfd$856d13c0$90473b40$>
In-Reply-To: <01c901d3fcfd$856d13c0$90473b40$>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.c.0.180410
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [L2sm] Proposed Liaison to 3GPP SA5
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Jun 2018 19:53:28 -0000

Hi Adrian,

Independently if RFC 8309 was approved following the correct process (which I believe is your latest point), we cannot refer to it as the IETF community consensual opinion on how service models should be interpreted as it was expressed in your original statement but just a recompilation of possible examples.

Please consider my contribution for a modified text:
"RFC 8199 and RFC 8309 are informational documents developed by the IETF community to show examples on how service models could be implemented."



On 05/06/18 20:46, "Adrian Farrel" <> wrote:

    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 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.
    > 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