Re: [CCAMP] Benjamin Kaduk's Discuss on draft-ietf-ccamp-mw-yang-10: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 26 October 2018 21:45 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711EB1276D0; Fri, 26 Oct 2018 14:45:18 -0700 (PDT)
X-Quarantine-ID: <RlM_KS6sZ4E4>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 RlM_KS6sZ4E4; Fri, 26 Oct 2018 14:45:16 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 7A820127148; Fri, 26 Oct 2018 14:45:15 -0700 (PDT)
X-AuditID: 12074425-679ff70000001d62-51-5bd38ae8a2fa
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id A6.2A.07522.8EA83DB5; Fri, 26 Oct 2018 17:45:13 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id w9QLjAoA031467; Fri, 26 Oct 2018 17:45:11 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9QLj5de013795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Oct 2018 17:45:08 -0400
Date: Fri, 26 Oct 2018 16:45:05 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jonas Ahlberg <jonas.ahlberg@ericsson.com>
Cc: The IESG <iesg@ietf.org>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, "draft-ietf-ccamp-mw-yang@ietf.org" <draft-ietf-ccamp-mw-yang@ietf.org>
Message-ID: <20181026214505.GR45914@kduck.kaduk.org>
References: <154039909284.6959.3022479150712399029.idtracker@ietfa.amsl.com> <AM6PR07MB451713B047FE3E9A37312DC389F70@AM6PR07MB4517.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AM6PR07MB451713B047FE3E9A37312DC389F70@AM6PR07MB4517.eurprd07.prod.outlook.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixCmqrPuy63K0wYoOaYulOzYxWTyZc4PF 4sjmWUwWM/5MZLZYP/U2kwOrx6+vV9k8liz5yRTAFMVlk5Kak1mWWqRvl8CV0TPJrKDNpOL7 pz72BsbTGl2MnBwSAiYSS87fZOli5OIQEljDJHHq0WpWCGcjo8Tr16uZIJy7TBJPV21hAWlh EVCVONh2iRXEZhNQkWjovswMYosI6Emc2bSCEaSBWeA0o8TGzu9gDcICWRLbz34Fa+AF2vd2 ziWoqfMZJa5d+cgCkRCUODnzCZjNLKAlcePfS6AiDiBbWmL5Pw6QMKdArMSxVYuYQGxRAWWJ vX2H2CcwCsxC0j0LSfcshO4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJTSjcx gsKY3UV1B+Ocv16HGAU4GJV4eBcYXI4WYk0sK67MPcQoycGkJMo7sQMoxJeUn1KZkVicEV9U mpNafIhRgoNZSYT3WgFQjjclsbIqtSgfJiXNwaIkzjupZXG0kEB6YklqdmpqQWoRTFaGg0NJ gndeJ1CjYFFqempFWmZOCUKaiYMTZDgP0PBJIDW8xQWJucWZ6RD5U4yKUuK8asBEISQAksgo zYPrBaUZiez9Na8YxYFeEeY1AqniAaYouO5XQIOZgAbPULgAMrgkESEl1cAopHvnYrX17bnx l34yBxYuL0syeJ02Zb/2u10V+4x3ui+du27KtvsfCycwl3CzrPm9KjO8pOBvUVrROdXfzPN3 7nv2c+4ls8T33kvDG4WWb+m/7FFXcjR4Vn56gYP4ssl5kx88ZQjyfjdrS9RXk06L+lWKPL0u Dk4ZG22upjxVnNEWcrJJlJNDiaU4I9FQi7moOBEAGIeKkg4DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/6XYS95_gGLqZ-7AHPTdTBrefSZ0>
Subject: Re: [CCAMP] Benjamin Kaduk's Discuss on draft-ietf-ccamp-mw-yang-10: (with DISCUSS and COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Oct 2018 21:45:19 -0000

On Thu, Oct 25, 2018 at 12:52:59PM +0000, Jonas Ahlberg wrote:
> Hi Benjamin,
> 
> Thank you for the review and valuable feedback.
> 
> Please see our response in line in your mail below.
> 
> We plan to make an update of the draft once we have received feedback from the rest of the review team.
> 
> Regards
> JonasA, on behalf of the group of authors
> 
> 
> -----Original Message-----
> From: CCAMP <ccamp-bounces@ietf.org> On Behalf Of Benjamin Kaduk
> Sent: den 24 oktober 2018 18:38
> To: The IESG <iesg@ietf.org>
> Cc: ccamp-chairs@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-mw-yang@ietf.org
> Subject: [CCAMP] Benjamin Kaduk's Discuss on draft-ietf-ccamp-mw-yang-10: (with DISCUSS and COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ccamp-mw-yang-10: Discuss
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mw-yang/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> A fairly minor point, really, but several of the nodes within "container error-performance-statistics" discuss "the interval" or "a fixed measurement interval".  These values are not interoperable unless the interval (or the way to determine it) is specified.  My understanding is that normally this sort of counter would be using the interval since last startup, and would also track the time of last discontinuity (i.e., startup), but I am not really an expert in this area.
> 
> [JonasA] The interval is intended to be the same interval as used for the statistics data nodes in RFC 8343, which is described as "Discontinuities in the value of this counter can occur at re-initialization of the management system and at other times as indicated by the value of 'discontinuity-time'." We plan to update the descriptions of the data nodes in error-performance-statistics to make this clear.

Excellent; thank you!

The proposed disposition for my other comments all sound good as well.

-Benjamin

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Please expand TDM on first usage.
> [JonasA] We will update chapter 1.1 Terminology and Definitions to make sure that all acronyms in the document are covered.
> 
> 
>        leaf carrier-id {
>          type string;
>          default "A";
>          description
>            "ID of the carrier. (e.g. A, B, C or D)
>             Used in XPIC & MIMO configurations to check that
>             the carrier termination is connected to the correct
>             far-end carrier termination. Should be the same
>             carrier ID on both sides of the hop.
>             Defaulted when not MIMO or XPIC.";
>        }
> 
> nit: I think the "Defaulted when" statement might be better as "Left as default value when MIMO and XPIC are not in use"
> Alternately, only expose the node under the appropriate if-features?
> [JonasA] We will change the last sentence in the description to the one you propose above.
> 
> 
>        choice freq-or-distance {
>          [...]
>          description
>            "A choice to configure rx-frequency directly or by computing
>             it as tx-frequency subtracted with the configured
>             duplex-distance." ;
>        }
> 
> nit: what does "subtracted with" mean?  Normally I see "subtract A from B"
> to indicate which operand is added with negation.
> [JonasA] We will update the wording to make it clear how rx-frequency is computed.
> 
> 
> , but I am not really an expert in this area.ow was the range of -99 to 99 dBm for the maximum-nominal-power/actual-transmitted-level/etc. nodes selected?
> Similarly, is there a physical limit that makes -20dBm the cap for actual-received-level?  Even if I have an unrealistic situation of the antennas separated by just a meter or two?  (Other nodes, e.g., max-rltm, may have similar questions posed, too.)
> [JonasA] We will check this in more detail and come back with a clarification and/or update of the ranges specified.
> 
> 
>          leaf bbe {
>            type yang:counter32;
>            units "number of block errors";
>            description
>              "Number of Background Block Errors (BBE) during the
>              interval. A BBE is an errored block not occurring as
>              part of an SES.";
> 
> SES is not expanded until two leafs later.
> [JonasA] We will update chapter 1.1 Terminology and Definitions to make sure that all acronyms in the document are covered.
> 
> 
> Section 7
> 
> nit: I know this is the standard boilerplate, but in:
> 
>    The YANG module specified in this document defines a schema for data
>    that is designed to be accessed via network management protocols such
> 
> we have a singular/plural mismatch, since this document specifies multiple YANG modules, which define schemas for data, and are designed to be accessed[...].
> [JonasA] We will update this section accordingly.
> 
> 
>    Interfaces of type radio-link-terminal:
>       /if:interfaces/if:interface/carrier-terminations,
>       /if:interfaces/if:interface/rlp-groups,
>       /if:interfaces/if:interface/xpic-pairs,
>       /if:interfaces/if:interface/mimo-groups, and
>       /if:interfaces/if:interface/tdm-connections:
> 
> not the 'mode' sibling as well?
> [JonasA] Correct. We will add 'mode' to the list.
> 
> 
> Appendix A
> 
> I guess this is really a matter of style, so arguably I shouldn't be saying anything, but it is a bit confusing to me to have the '-' present in the identifiers for the boxes in the figures (e.g., "Carrier Termination -1", "Radio Link Terminal -B") -- I see that the '-' is present as a separator in the actual YANG field data, but humans can typically add/remove the separator as needed.  (Also, the figures are inconsistent about whether it's "- A" or "-A".)
> [JonasA] We will remove '-' from the pictures.
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp