Hi Benjamin,
Thanks for your comment.
Please find some inline answers.
I'm doing the changes as part of the -41.
Stephane
-Original Message-
From: Benjamin Kaduk via Datatracker
Sent: mercredi 2 octobre 2019 03:17
To: The IESG
Cc: draft-ietf-isis-yang-isis-...@ietf.org; Yingzhen Qu
; aretana.i...@gmail.com; lsr-cha...@ietf.org;
yingzhen.i...@gmail.com; lsr@ietf.org
Subject: Benjamin Kaduk's Discuss on draft-ietf-isis-yang-isis-cfg-40: (with
DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-isis-yang-isis-cfg-40: 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-isis-yang-isis-cfg/
--
DISCUSS:
--
Perhaps the most minor thing that could be Discuss-level, and should be trivial
to resolve, but:
The "i-e" leaf in groupings prefix-ipv4-std and neighbor does not say whether
boolean value true corresponds to internal or external.
[SLI] Right, I have added the following statement in the description:
"Set to false to indicate an internal metric"
--
COMMENT:
--
Section 1
This document defines a YANG [RFC7950] data model for IS-IS routing
protocol.
nit: "the IS-IS routing protocol"
[SLI] Fixed
Section 2.8
This YANG module supports LFA (Loop Free Alternates) [RFC5286] and
remote LFA [RFC7490] as IP Fast Re-Route (FRR) techniques. The
"fast-reroute" container may be augmented by other models to support
other IP FRR flavors (MRT, TI-LFA, etc.).
If we're going to give examples of other flavors, do we want to have
informative references for them? (This is particularly relevant since we
define enumeration values for them in the "alternate-type"
enumeration.)
[SLI] Sounds good, I have added some references.
Section 6
identity lsp-attached-default-metric-flag {
base lsp-flag;
description "Set when originator is attached to
another area using the referred metric.";
nit(?): I'm not sure whether the "referred" in the description is appropriate
given the "default" in the identity name.
[SLI] Fixed
feature ldp-igp-sync {
description
"LDP IGP synchronization.";
nit: the surrounding context suggests that "Support for" would give a more
consistent style. Maybe for auto-cost, te-rid, max-ecmp, lsp-refresh, and
admin-control as well.
[SLI] Fixed
feature nlpid-control {
description
"This feature controls the advertisement
of support NLPID within IS-IS configuration.";
nit: "support for"
[SLI] Fixed
feature maximum-area-addresses {
description
"Support of maximum-area-addresses config.";
nit: s/of/for/
[SLI] Fixed
leaf alternate-type {
type enumeration {
[...]
enum other {
description
"Unknown alternate type.";
Do I remember correctly that enumerations are not extensible in the future? I
don't know how relevant that would be here, though.
[SLI] Right, I have changed to identity
In the "protection-available" container, is there some sort of constraint that
two of the alternate-metrics add up to the third?
[SLI] It is not really a constraint from a YANG point of view, these are
operational counters.
container unprotected-routes {
config false;
list address-family-stats {
nit: the name/description of address-family-stats doesn't match up with the
parent container that just claims to be a list of unprotected prefixes (no
stats).
[SLI] I agree, I have changed the address-family-stats to "prefixes"
list protection-statistics {
side note: I wonder whether the various uint32 leaves are better as
gauge32 than plain uint32.
Also, perhaps the description could mention a relationship bteween
total-routes/protected-routes+unprotected-routes, and/or
protected-routes/link-protected-routes+node-protected-routes.
grouping route-content {
[...]
leaf-list tag {
type uint64;
description
"List of tags associated with the route. The leaf
describes both 32-bit and 64-bit tags.";
Are these the admin tags from RFC 5130? Where is it specified that the
32- and 64-bit variants are just different views into a single consolidated tag
namespace?
[SLI] Right, I have added a better description.