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

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 14 September 2021 05:47 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 68B933A1391 for <l2sm@ietfa.amsl.com>; Mon, 13 Sep 2021 22:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 KrdmUOz1VJvB for <l2sm@ietfa.amsl.com>; Mon, 13 Sep 2021 22:47:15 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B97C3A138A for <l2sm@ietf.org>; Mon, 13 Sep 2021 22:47:15 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 552B5F409A9; Mon, 13 Sep 2021 22:46:38 -0700 (PDT)
To: rfc-editor@rfc-editor.org
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: mohamed.boucadair@orange.com, bin_wen@comcast.com, giuseppe.fioccola@tim.it, xiechf.bri@chinatelecom.cn, luay.jalil@verizon.com, l2sm@ietf.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20210914054638.552B5F409A9@rfc-editor.org>
Date: Mon, 13 Sep 2021 22:46:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/INRdqTCIwGs53cMGlwwe50ckIs4>
Subject: [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 05:47:22 -0000

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