Re: [L2sm] [Editorial Errata Reported] RFC8466 (6683)

Qin Wu <bill.wu@huawei.com> Tue, 14 September 2021 12:14 UTC

Return-Path: <bill.wu@huawei.com>
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 39EA43A18D1 for <l2sm@ietfa.amsl.com>; Tue, 14 Sep 2021 05:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 40_Yh0XhD9vv for <l2sm@ietfa.amsl.com>; Tue, 14 Sep 2021 05:14:35 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DE63A18CE for <l2sm@ietf.org>; Tue, 14 Sep 2021 05:14:34 -0700 (PDT)
Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4H82KF4fB1z67l0J for <l2sm@ietf.org>; Tue, 14 Sep 2021 20:12:17 +0800 (CST)
Received: from dggeml702-chm.china.huawei.com (10.3.17.135) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Tue, 14 Sep 2021 14:14:30 +0200
Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml702-chm.china.huawei.com (10.3.17.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Tue, 14 Sep 2021 20:14:28 +0800
Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2308.008; Tue, 14 Sep 2021 20:14:28 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'RFC Errata System' <rfc-editor@rfc-editor.org>
CC: "xiechf.bri@chinatelecom.cn" <xiechf.bri@chinatelecom.cn>, "giuseppe.fioccola@tim.it" <giuseppe.fioccola@tim.it>, "l2sm@ietf.org" <l2sm@ietf.org>, "luay.jalil@verizon.com" <luay.jalil@verizon.com>, "bin_wen@comcast.com" <bin_wen@comcast.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Thread-Topic: [L2sm] [Editorial Errata Reported] RFC8466 (6683)
Thread-Index: AdepYWVcxkk4TMeoSR+rPuDLMeAZ5Q==
Date: Tue, 14 Sep 2021 12:14:28 +0000
Message-ID: <64dba599980243158328c2e881ec4c46@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.123.117]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/JLupneOs-JfdpDzzh3DUqCmU390>
Subject: Re: [L2sm] [Editorial Errata Reported] RFC8466 (6683)
X-BeenThere: l2sm@ietf.org
X-Mailman-Version: 2.1.29
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, 14 Sep 2021 12:14:40 -0000

Yes, agree with this change.

-Qin
-----邮件原件-----
发件人: L2sm [mailto:l2sm-bounces@ietf.org] 代表 Adrian Farrel
发送时间: 2021年9月14日 16:10
收件人: 'RFC Errata System' <rfc-editor@rfc-editor.org>
抄送: xiechf.bri@chinatelecom.cn; giuseppe.fioccola@tim.it; l2sm@ietf.org; luay.jalil@verizon.com; bin_wen@comcast.com; mohamed.boucadair@orange.com
主题: Re: [L2sm] [Editorial Errata Reported] RFC8466 (6683)

Looks right to me.

Adrian

-----Original Message-----
From: L2sm <l2sm-bounces@ietf.org> On Behalf Of RFC Errata System
Sent: 14 September 2021 06:47
To: rfc-editor@rfc-editor.org
Cc: l2sm@ietf.org; giuseppe.fioccola@tim.it; xiechf.bri@chinatelecom.cn; luay.jalil@verizon.com; bin_wen@comcast.com; mohamed.boucadair@orange.com
Subject: [L2sm] [Editorial Errata Reported] RFC8466 (6683)

The following errata report has been submitted for RFC8466, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6683

--------------------------------------
Type: Editorial
Reported by: Mohamed Boucadair <mohamed.boucadair@orange.com>

Section: 5.10.2.1

Original Text
-------------
   QoS classification rules are handled by "qos-classification-policy".
   qos-classification-policy is an ordered list of rules that match a
   flow or application and set the appropriate target CoS
   (target-class-id).  The user can define the match using a
   more specific flow definition (based on Layer 2 source and
   destination MAC addresses, cos, dscp, cos-id, color-id, etc.).  A
   "color-id" will be assigned to a service frame to identify its QoS
   profile conformance.  A service frame is "green" if it is conformant
   with the "committed" rate of the bandwidth profile.  A service frame
   is "yellow" if it exceeds the "committed" rate but is conformant with
   the "excess" rate of the bandwidth profile.  Finally, a service frame
   is "red" if it is conformant with neither the "committed" rate nor
   the "excess" rate of the bandwidth profile.

Corrected Text
--------------
   QoS classification rules are handled by "qos-classification-policy".
   qos-classification-policy is an ordered list of rules that match a
   flow or application and set the appropriate target CoS
   (target-class-id).  The user can define the match using a
   more specific flow definition (based on Layer 2 source and
   destination MAC addresses, dscp, color-type, etc.).  A
   "color-type" will be assigned to a service frame to identify its QoS
   profile conformance.  A service frame is "green" if it is conformant
   with the "committed" rate of the bandwidth profile.  A service frame
   is "yellow" if it exceeds the "committed" rate but is conformant with
   the "excess" rate of the bandwidth profile.  Finally, a service frame
   is "red" if it is conformant with neither the "committed" rate nor
   the "excess" rate of the bandwidth profile.

Notes
-----
There is no "color-id" under "qos-classification-policy". The text should refer to "color-type" given that the "qos-classification-policy" substree is as follows:

        +--rw service
        |  +--rw qos {qos}?
        |  |  +--rw qos-classification-policy
        |  |  |  +--rw rule* [id]
        |  |  |     +--rw id                   string
        |  |  |     +--rw (match-type)?
        |  |  |     |  +--:(match-flow)
        |  |  |     |  |  +--rw match-flow
        |  |  |     |  |     +--rw dscp?           inet:dscp
        |  |  |     |  |     +--rw dot1q?          uint16
        |  |  |     |  |     +--rw pcp?            uint8
        |  |  |     |  |     +--rw src-mac?        yang:mac-address
        |  |  |     |  |     +--rw dst-mac?        yang:mac-address
        |  |  |     |  |     +--rw color-type?     identityref
        |  |  |     |  |     +--rw target-sites*
        |  |  |     |  |     |               svc-id {target-sites}?
        |  |  |     |  |     +--rw any?            empty
        |  |  |     |  |     +--rw vpn-id?         svc-id
        |  |  |     |  +--:(match-application)
        |  |  |     |     +--rw match-application?   identityref
        |  |  |     +--rw target-class-id?     string

The same applies for "cos" and "cos-id". 

The corrected text uses "color-type" instead of "color-id" and removes "cos"
and "cos-id" from the flow definition examples.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8466 (draft-ietf-l2sm-l2vpn-service-model-10)
--------------------------------------
Title               : A YANG Data Model for Layer 2 Virtual Private Network
(L2VPN) Service Delivery
Publication Date    : October 2018
Author(s)           : B. Wen, G. Fioccola, Ed., C. Xie, L. Jalil
Category            : PROPOSED STANDARD
Source              : L2VPN Service Model
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
L2sm mailing list
L2sm@ietf.org
https://www.ietf.org/mailman/listinfo/l2sm

_______________________________________________
L2sm mailing list
L2sm@ietf.org
https://www.ietf.org/mailman/listinfo/l2sm