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

[Jonas Ahlberg <[e-mail]>]

Hi Benjamin,

Sending an update of the comment about the ranges.

> , 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.
>
The systems of today are not built for input levels above -20 and would typically need external attenuators in cases where that limit is exceeded. The evolution is not expected to change that situation. Instead the systems will evolve to support lower and lower input levels going forward.
Therefore, we have decided to keep the current range for received levels as -99..-20. On the other hand, we have decided to change the associated thresholds to use that same range instead of the current range of -99..-30.

Regards
JonasA

-----Original Message-----
From: Benjamin Kaduk <[e-mail]> 
Sent: den 27 oktober 2018 04:45
To: Jonas Ahlberg <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [CCAMP] Benjamin Kaduk's Discuss on draft-ietf-ccamp-mw-yang-10: (with DISCUSS and COMMENT)

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 <[e-mail]> On Behalf Of Benjamin Kaduk
> Sent: den 24 oktober 2018 18:38
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp