YANG Data Model for Babel
draft-ietf-babel-yang-model-13

[Ballot comment]
Many thanks for the updates between the -10 and the -12; I'm happy to
report that they address my DISCUSS points (and all the COMMENT points
that I checked, as well)!

I'm terribly sorry to have failed to notice this previously, but when we
discuss the "cached_info" TLS extension, we mention its use in the
ClientHello and ServerHello messages.  However, for TLS 1.3 it seems
that this extension would probably not belong in the ServerHello, but
rather in the EncryptedExtensions message; unfortunately, this does not
actually seem to be formally specified anywhere (see
https://github.com/tlswg/tls13-spec/issues/1237).  If we're not
comfortable mentioning EncryptedExtensions by name, my suggestion would
be to make the change

OLD:
              "Indicates whether the cached_info extension is enabled.
                The extension is enabled for inclusion in ClientHello
                and ServerHello messages if the value is 'true'.";

NEW:
              "Indicates whether the cached_info extension is enabled.
                The extension is enabled for inclusion in TLS handshake
                messages if the value is 'true'.";

Appendix A

[Just noting that I did not review the new tree diagram or modified
examples, on the assumption that they were mechanically generated, and
the tool used to produce them is a more reliable cross-check against the
actual YANG model than a human (me).]

[Ballot discuss]
This is kind of nitpicky, and I'm sorry to pull out the heavy hammer of
DISCUSS for it, but for the "dtls-cached-info" leaf with description:

              "Indicates whether the cached_info extension is included
                in ClientHello and ServerHello packets. The extension
                is included if the value is 'true'.";

It is factually false to just say that "the extension is included if the
value is true", and it contradicts the DTLS specification to say so.  In
particular, the extension can only be included in the ServerHello
message if it was present in the ClientHello message being responded to.
So maybe we can say "enabled for inclusion" or append "when permitted by
the protocol", or something similar?

There's also a few places where we didn't quite clean up all the fallout
from switching from enumerations to identities (for MAC and
DTLS-adjacent algorithms), that really ought to get fixed before
publication.  I try to note them in the COMMENT.

I also think we need to be a bit more specific about the structure of
the (binary) private-key leaf/values provided when a certificate entry
is created.  Ideally this would just be by reference to some other spec,
but the situation is unfortunately messy.  (It doesn't help that we
allow DTLS 1.2, which allows certificates that are used for key-exchange
as opposed to signing, and those are not terribly mainstream.)  We may
need to pull in some other experts to figure out the right way to write
about this.

[Ballot comment]
Section 2.2

  In addition to information like the version number implemented by
  this device, the model contains subtrees on 'constants',
  'interfaces', 'routes' and 'security'.

I don't see a 'security' node, but rather separate 'mac-key-set' and
'dtls' nodes, both of which contain subtrees.

Section 2.3

  A router running Babel routing protocol can determine the parameters
  it needs to use for an interface based on the interface name.  [...]

Is this always true, or only sometimes?

  Transport Layer Security Version 1.2 [RFC6347], The Blake2

(DTLS 1.3 is in the RFC Editor's queue, FWIW.)

        leaf router-id {
          type binary;
          description
            "router-id of the source router for which this route is
              advertised.";

IIRC we can do length constraints in YANG, and in Babel router-ids are 8
octets.  Should we enshrine that in the YANG?

        leaf next-hop {
          type inet:ip-address;
          description
            "The next-hop address of this route. This will be empty if
              this route has no next-hop address.";

What does it mean for an inet:ip-address to be "empty"?  That the node
is absent?

              "List of supported certificate types, in order of
                preference. The values MUST be among those listed in
                dtls-cert-types. This list is used to populate the

Since the element is of type leafref to the actual list of certs, it
seems like this MUST is achieved by construction (and thus need not be
listed specifically).  Though, "dtls-cert-types" appears in this
document only as the base identity for Babel DTLS certificate types, so
this phrasing seems a bit odd...perhaps it is fallout from an
enumeration/identity conversion.

                server_certificate_type extension in a Client Hello.
                Values that are present in at least one instance in the
                certs object under dtls of a referenced dtls instance
                and that have a non-empty private-key will be used to
                populate the client_certificate_type extension in a
                Client Hello.";

Since the DTLS server picks which certificate types are actually used,
it is conceivable that the preference order in this list could also be
used as input to the server's choice of type.  That said, I don't think
there is universal API support for DTLS servers accepting a preference
list directly, so we would not want to imply that this list would always
be used in such a fashion.  But it could be used in such a fashion.

          container stats {
            config false;
            description
              "Statistics collection object for this interface.";

Often, YANG models with such statistics containers will also include a
leaf to indicate the "discontinuity time" at which the counters were
last reset.

            leaf hello-mcast-history {
              type string;
              description
                "The multicast Hello history of whether or not the
                  multicast Hello packets prior to exp-mcast-
                  hello-seqno were received, with a '1' for the most
                  recent Hello placed in the most significant bit and
                  prior Hellos shifted right (with '0' bits placed
                  between prior Hellos and most recent Hello for any
                  not-received Hellos); represented as a string using
                  utf-8 encoded hex digits where a '1' bit = Hello
                  received and a '0' bit = Hello not received.";

I'd consider adding a few more words to confirm that this is the hex
representation of a bitstring (so, all hex digits are possible), not a
string consisting of only '1' and '0' characters.
(Likewise for hello-ucast-history.)

            leaf exp-mcast-hello-seqno {
              type uint16;
              default "0";
              description
                "Expected multicast Hello sequence number of next Hello
                  to be received from this neighbor; if multicast Hello
                  packets are not expected, or processing of multicast
                  packets is not enabled, this MUST be NULL.";

It's not really clear to me that assigning semantics to a NULL leaf
makes sense when there is a default value for it (that has already
assigned semantics to an absent leaf).
(et seq)

            leaf value {
              type binary;
              mandatory true;
              description
                "The value of the MAC key. An implementation MUST NOT
                  allow this parameter to be read. This can be done by

I believe that we can incorporate this restriction in the YANG itself
with something like "nacm:default-deny-all".

              description
                "The name of the MAC algorithm used with this key. The
                  value MUST be the same as one of the enumerations
                  listed in the mac-algorithms parameter.";

It's now an identityref, not a name.  Accordingly, there are also not
any enumerations listed in the mac-algorithms parameter.

              description
                "The name of the certificate type of this object
                  instance. The value MUST be the same as one of the
                  enumerations listed in the dtls-cert-types
                  parameter. This value can only be provided when this

Similarly, this is also identityref, and also has no enumerations listed
in the dtls-cert-types parameter.

            leaf private-key {
              type binary;
              mandatory true;
              description
                "The value of the private key. If this is non-empty,
                  this certificate can be used by this implementation to
                  provide a certificate during DTLS handshaking. An
                  implementation MUST NOT allow this parameter to be
                  read. This can be done by always providing an empty

(nacm:default-deny-all could be useful here as well)

                  string, or through permissions, or other means. This
                  value can only be provided when this instance is
                  created, and is not subsequently writable.";

It is perhaps a bit limiting to require the actual private key value to
be supplied, since that would preclude the use of (e.g.) HSM-based
private keys.  But since we are basically inheriting from the
information model here, I won't press it too hard.

Section 4

It might be worth referencing the security considerations of
8966/8967/8968 as being applicable.

The security (privacy, really) considerations of RFC 7924 are also
arguably relevant, relating to the use of the TLS "cached_info"
extension.

Are there any security and/or privacy considerations relating to the
logging of babel packets?

  There are a number of data nodes defined in the YANG module which are
  writable/created/deleted (i.e., config true, which is the default).

I don't think "writable/created/deleted" is part of the template.

  'babel/hmac' and 'babel/dtls': These contain security credentials
  that influence whether packets are trusted.

I'd consider making two separate (but related) points about controlling
whether incoming packets are trusted, and whether outgoing packets are
produced in a way such that the receiver will treat them as trusted.
(Changing just the use-send/use-verify values can allow for a valid key
to be misused, without changing the actual keys being used, which could
present an interesting attack in some scenarios.)

  Some of the readable data or config false nodes in this YANG module
  may be considered sensitive or vulnerable in some network
  [...]
  'babel/hmac' and 'babel/dtls': These contain security credentials,
  include private credentials of the router.

We do require the actual secret keys to not be readable, so we might
consider phrasing this more as a reiteration of that requirement than a
statement of risk if they are read out.

  Some of the RPC operations in this YANG module may be considered
  sensitive or vulnerable in some network environments.  It is thus
  important to control access to these operations.  These are the
  operations and their sensitivity/vulnerability from a RPC operation
  perspective:

  This model does not define any RPC operations.

We do define a couple of actions, though, which are like RPCs except
"[t]he difference between an action and an rpc is that an action is tied
to a node in the datastore, whereas an rpc is not".  This is perhaps an
omission in the YANG security considerations template, but I don't think
we should let that stop us from noting the actions we define are
carefully designed to have minimal security impact and minimal
side-channel leakage.  (Well, I guess that's not hard for the
stats-reset one, but for the MAC key test one it's quite important.)

Section 6.1

I don't have a great sense for why RFC 4868 needs to be normative.

RFC 8968 seems missing as a listed reference at all (which would of
course need to be normative as 8967 is).

Section 6.2

I think RFC 7693 should be normative, since you need it in order to do
the blake2 stuff.

RFC 8341 might become normative if we add nacm:default-deny-all stanzas.

NITS

The tree diagram and the prose use different orders for the various
child elements, which is a little distracting.

Section 1

  [RFC8966].  The data model is defined using YANG 1.1 [RFC7950] data
  modeling language and is Network Management Datastore Architecture

"the YANG [data modeling language]"

Section 2.1

  Information Model and this data module.  The information model
  mandates the definition of some of the attributes, e.g.  'babel-

comma after "e.g." (as well as before).  (I'll try to only note it once,
though it appears many times.)  Likewise for "i.e."

Section 2.2

  In addition to information like the version number implemented by
  this device, the model contains subtrees on 'constants',

The actual data model (and the information model, for that matter) show
that the 'version' leaf contains "the name and version of this
implementation of the Babel protocol".  The text here suggests that it
contains the protocol version number implemented by the device, which is
different.  So I'd suggest "the implementation and version used by this
device" instead.

  The 'interfaces' subtree describes attributes such as 'interface'
  object that is being referenced, the type of link, e.g. wired,

"the 'interface'"

  wireless or tunnel, as enumerated by 'metric-algorithm' and 'split-
  horizon' and whether the interface is enabled or not.

I suggest using semicolons for the outer layer of grouping, to avoid
overloading commas for different hierarchies of separation.

  Finally, for security two subtree are defined to contain MAC keys and
  DTLS certificates.  The 'mac-key-set' subtree contains keys used with

"subtrees"

  interfaces.  The dtls subtree contains certificates used with DTLS

single quotes for 'dtls'.
"the DTLS"

Section 2.3

  Similarly, an interface that is a metered 3G link, and used for
  fallback connectivity needs much higher default time constants, e.g.

Comma after "connectivity".

  HMAC: Keyed-Hashing for Message Authentication [RFC2104], Using
  HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 [RFC4868], Datagram

The "with IPsec" part of RFC 4868's title seems to have been dropped.

        "This implementation supports two-out-of-three metric
          comp algorithm.";

"the two-out-of-three".
Also, do we really need to (silently) abbreviate "metric computation"
(multiple occurrences)?

        "This implementation supports Expected Transmission Count

"the Expected"

        "This implementation supports hmac-sha256 MAC algorithm.";

"the hmac-sha256"

        "This implementation supports x-509 certificate type.";

"the X.509"

        "This implementation supports raw-public-key certificate
          type.";

Missing article, per the theme, but I think it would also be more
conventional to spell the name as "RawPublicKey".

      base metric-comp-algorithms;
      if-feature "etx-supported";
      description
        "Expected Transmission Count.";

I'd put an "algorithm" in here somewhere

        "BLAKE2s algorithms supported. Specifically, BLAKE2-128 is
          supported.";

I'd just say "BLAKE2-128 algorithm supported."

        "Raw Public Key type.";

"certificate type"

        leaf router-id {
          type binary;

(If length constraint is applied earlier, it should apply here as well.)

            "Indicates whether statistics collection is enabled (true)
              or disabled (false) on all interfaces. When enabled,
              existing statistics values are not cleared and will be
              incremented as new packets are counted.";

I suggest "on transition to enabled".
(Also, thank you for clearly spelling out which behaviors true/false map
to!)

                A value of true indicates split horizon optimization
                is used.";
"the split"

              "List of references to the mac entries that apply
                to this interface. When an interface instance is
                created, all mac instances with default-apply 'true'

s/mac/MAC/ (twice)

              "Indicates whether the cached_info extension is included
                in ClientHello and ServerHello packets. The extension

s/packets/messages/.
Also, it's conventional to refer to TLS extension names enclosed by
double quotes, but I guess in the context of a YANG leaf description
that's not really feasible.

                dtls-cert-types. This list is used to populate the
                server_certificate_type extension in a Client Hello.

s/Client Hello/ClientHello/.

        list mac-key-set {
          key "name";

          description
            "A mac key set object. If this object is implemented, it
              provides access to parameters related to the MAC security
              mechanism.";

s/mac/MAC/

              "A string that uniquely identifies the mac object.";

s/mac/MAC key/

                If 'true', this instance is applied to new babel-
                interfaces instances at the time they are created,
                by including it in the mac-key-sets list under
                interfaces. If 'false', this instance is not applied

s/under interfaces/under the interface/

                to new interfaces instances when they are created.";

s/interfaces/interface/

                If 'true', this instance is applied to new interfaces
                instances at the time they are created, by including it
                in the dtls-certs list under interfaces. If 'false',

s/under interfaces/under the interface/

                this instance is not applied to new interfaces
                instances when they are created.";

s/interfaces/interface/

[Ballot comment]
Thank you Mahesh for the YANG syntax information, it is clear that the PYANG tool is plain wrong. I have cleared my DISCUSS position (but keeping the text below for archive purpose), I also noted that you replied/acted upon my original COMMENT

Regards

-éric

--- Start of archive (to be ignored) ---

Thank you for the work put into this document. I really like the fact that the information model is built before the data model. Congratulations !

Please find below one blocking (but trivial to fix) DISCUSS point, some non-blocking COMMENT points (but replies would be appreciated), and one nit.

Thank you to Donald Eastlake for his shepherd's write-up (including the WG consensus).

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

The YANG module does not compile correctly with PYANG, it should be easy to fix though :-) See:
https://yangcatalog.org/results/ietf-babel@2021-05-12_ietf.html
Or is it a PYANG error ?

== COMMENTS ==

The related links on should be updated. E.g., the YANG catalog entry should be:
https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-babel@2021-05-12


-- Section 2.2 --
I usually use the expanded tree view rather the YANG module itself to get a global view. Is there any reason why the full tree view is not included?

-- Section 5 --
Is there any reason why the doc shepherd is not acknowledged ?

== NITS ==

-- Section 2.3 --
s/MAC based security/MAC-based security/ ?

[Ballot comment]
(2.3)

leaf received-metric {
          type uint16;
          description
            "The metric with which this route was advertised by the
              neighbor, or maximum value (infinity) to indicate the
              route was recently retracted and is temporarily
              unreachable. This metric will be 0 (zero) if the route
              was not received from a neighbor but was generated
              through other means. At least one of
              calculated-metric or received-metric MUST be non-NULL.";
          reference
            "RFC ZZZZ: Babel Information Model, Section 3.6,
              RFC 8966: The Babel Routing Protocol, Section 2.1.";
        }

        leaf calculated-metric {
          type uint16;
          description
            "A calculated metric for this route. How the metric is
              calculated is implementation-specific. Maximum value
              (infinity) indicates the route was recently retracted
              and is temporarily unreachable. At least one of
              calculated-metric or received-metric MUST be non-NULL.";
          reference
            "RFC ZZZZ: Babel Information Model, Section 3.6,
              RFC 8966: The Babel Routing Protocol, Section 2.1.";
        }

I don't understand the relationship between these two. If the metric was calculated rather than received, why would the value be zero instead of NULL? Isn't a zero metric dangerous in a routing algorithm?

(4) "config true perspective"?

[Ballot discuss]
Thank you for the work put into this document. I really like the fact that the information model is built before the data model. Congratulations !

Please find below one blocking (but trivial to fix) DISCUSS point, some non-blocking COMMENT points (but replies would be appreciated), and one nit.

Thank you to Donald Eastlake for his shepherd's write-up (including the WG consensus).

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

The YANG module does not compile correctly with PYANG, it should be easy to fix though :-) See:
https://yangcatalog.org/results/ietf-babel@2021-05-12_ietf.html
Or is it a PYANG error ?

[Ballot discuss]
Thank you for the work put into this document. I really like the fact that the information model is built before the data model. Congratulations !

Please find below one blocking DISCUSS point, some non-blocking COMMENT points (but replies would be appreciated), and one nit.

Thank you to Donald Eastlake for his shepherd's write-up (including the WG consensus).

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

The YANG module does not compile correctly with PYANG, it should be easy to fix though :-) See:
https://yangcatalog.org/results/ietf-babel@2021-05-12_ietf.html
Or is it a PYANG error ?

[Ballot comment]
== COMMENTS ==

The related links on should be updated. E.g., the YANG catalog entry should be:
https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-babel@2021-05-12


-- Section 2.2 --
I usually use the expanded tree view rather the YANG module itself to get a global view. Is there any reason why the full tree view is not included?

-- Section 5 --
Is there any reason why the doc shepherd is not acknowledged ?

== NITS ==

-- Section 2.3 --
s/MAC based security/MAC-based security/ ?

[Ballot comment]
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.3, paragraph 4, nit:
-    connected to a wireless radio, the values can be overriden by setting
+    connected to a wireless radio, the values can be overridden by setting
+                                                            +

Section 2.1, paragraph 2, nit:
> model mandates the definition of some of the attributes, e.g. 'babel- implem
>                                  ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 2.2, paragraph 6, nit:
> ddress. Finally, for security two subtree are defined to contain MAC keys an
>                                  ^^^^^^^
Possible agreement error. The noun 'subtree' seems to be countable, so consider
using: "subtrees".

Section 2.3, paragraph 4, nit:
> gorithm' to 'etx', and 'split-horizon' to false. Similarly, an interface that
>                                        ^^
Did you mean "too"?

Section 2.3, paragraph 49, nit:
> ects. Includes received and routes routes."; reference "RFC Z
>                            ^^^^^^^^^^^^^
Possible typo: you repeated a word

Section 2.3, paragraph 67, nit:
>  description "Indicates whether or not the split horizon optimization
>                        ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean 'regardless of whether'.

Section 2.3, paragraph 86, nit:
>  the action is associated with the stats container inside an i
>                                    ^^^^^
An apostrophe may be missing.

Section 2.3, paragraph 92, nit:
>  "The multicast Hello history of whether or not the multicast Hello p
>                                  ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean 'regardless of whether'.

Section 2.3, paragraph 93, nit:
>  "The unicast Hello history of whether or not the unicast Hello pac
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean 'regardless of whether'.

Section 2.3, paragraph 105, nit:
>  MAC and include that MAC in the sent Babel packet. A MAC f
>                                  ^^^^
Did you mean "scent"?

Section 3, paragraph 1, nit:
> erations This document registers one URIs and one YANG module. 3.1. URI Regi
>                                  ^^^^^^^^
Don't use the number 'one' with plural words. Did you mean "one URI", "a URI",
or simply "URIs"?

Section 4, paragraph 8, nit:
> e whether packets are trusted. Some of the readable data or config false node
>                                ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 4, paragraph 11, nit:
> ate credentials of the router. Some of the RPC operations in this YANG module
>                                ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 4, paragraph 12, nit:
> nd their sensitivity/vulnerability from a RPC operation perspective: This
>                                        ^
Use "an" instead of 'a' if the following word starts with a vowel sound, e.g.
'an article', 'an hour'.

These URLs in the document did not return content:
* http://tools.ietf.org/wg/babel/WG
* https://www.rfc-editor.org/info/rfcXXXX

[Ballot comment]
[[ nits ]]

[ appendix A ]

* "An Appendix" is cute.  :-)

  Consider perhaps "Example Configurations" or just "Examples",
  if you haven't already.

[Ballot discuss]
There seem to be YANG errors:
e.g:
identity two-out-of-three {
      base metric-comp-algorithms;
      if-feature "two-out-of-three-supported";
      description
        "2-out-of-3 algorithm.";
      reference
        "RFC 8966: The Babel Routing Protocol, Section A.2.1.";
    }


[ EDIT]: Actually, looking further, the ABNF implies that 'base' should come before 'if-feature', so perhaps the tool is borken?!

Throws: ietf-babel@2021-05-12.yang:148: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
I believe that the 'if-feature' should sort before base...

[Ballot discuss]
There seem to be YANG errors:
e.g:
identity two-out-of-three {
      base metric-comp-algorithms;
      if-feature "two-out-of-three-supported";
      description
        "2-out-of-3 algorithm.";
      reference
        "RFC 8966: The Babel Routing Protocol, Section A.2.1.";
    }

Throws: ietf-babel@2021-05-12.yang:148: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
I believe that the 'if-feature' should sort before base...

[Ballot comment]
At the moment, the automated check is returning errors:

ietf-babel@2021-05-12.yang:148: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
ietf-babel@2021-05-12.yang:157: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
ietf-babel@2021-05-12.yang:175: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
ietf-babel@2021-05-12.yang:176: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
ietf-babel@2021-05-12.yang:186: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
ietf-babel@2021-05-12.yang:187: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
ietf-babel@2021-05-12.yang:206: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
ietf-babel@2021-05-12.yang:207: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
ietf-babel@2021-05-12.yang:214: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)
ietf-babel@2021-05-12.yang:215: error: keyword "if-feature" not in canonical order (see RFC 6020, Section 12)

draft-ietf-babel-yang-model-09

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  Proposed Standard as indicated on the title page. This draft
  specifies the standard YANG model for the Babel routing protocol
  (RFC 8966).
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document defines a data model for the Babel routing protocol
  (RFC 8966).  The data model is defined using the YANG data modeling
  language.

Working Group Summary:

  This YANG model is based on the Babel RFCs (the Base Protocol RFC
  8966 and security protcols RFCs 8967 and 8968) and the Babel
  information model (draft-ietf-babel-information-model which is in
  the RFC Editor's queue). This draft was originally last called in
  November of 2019 and approved based on the mailing list support and
  November IETF meeting discussion:
  https://mailarchive.ietf.org/arch/msg/babel/QGxLY-QsKnQClovMqi2eVVCbIjo/
  However, shortly thereafter some questions aroze on the information
  and YANG models. These were discussed over the ensuing months with
  the conclution that no significant YANG changes were required. A
  cofirmatory WG LC extension was issued resulting in further support
  and no opposition so consensus was confirmated as follows:
  https://mailarchive.ietf.org/arch/msg/babel/51ghA03etPG9UdbtSeghPDVR2qk/

Document Quality:

  The document is of good quality. An early YANG docotor review was
  done and the comments were resolved:
  https://mailarchive.ietf.org/arch/msg/babel/5CVaLWJegUC5nrN50E-2CNM1n60/
  Routing and Security Directorate reviews have found the draft Ready.

Personnel:

  Document Shepherd: Donald Eastlake
  Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

  The draft was reviewed a couple of times by the Document Shepherd
  who is not a YANG expert. No problems were found.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  An early YANG doctor review was performed.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

  Yes. See:
  https://mailarchive.ietf.org/arch/msg/babel/51ghA03etPG9UdbtSeghPDVR2qk/
  https://mailarchive.ietf.org/arch/msg/babel/kTC_mhW1qk7sUUCMmqA3Gw6uECo/

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclsoure filed on this draft.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There is a solid WG consensus for this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  There is a aring about a reference to an older vesion of
  draft-ietf-babel-information-model which is not a problem.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  Early YANG doctors review comments have been resolved. Datatracker
  shows a nice green ying-yang symbol for the draft.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  No. All references are to RFCs except for the references to
  draft-ietf-babel-information-model which is approved and in the RFC
  Editor's queue.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified.

  IANA Considerations look good, just the usual assignments for a
  YANG module.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  This document does not create any IANA registties.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

  There is YANG in this draft. It is automatically reviewed by the
  draft submission process and passes as indicated by a green
  yin-yang symbol by the draft.

(20) If the document contains a YANG module, has the module been
checked with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

  The YANG module complies with NMDA and has been checked.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-babel-yang-model-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: yang:ietf-babel
URI: urn:ietf:params:xml:ns:yang:ietf-babel
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request.  This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a new YANG module will be registered as follows:

Name: ietf-babel
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-babel
Prefix: babel
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-04-22):

From: The IESG
To: IETF-Announce
CC: Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org, d3e3e3@gmail.com, draft-ietf-babel-yang-model@ietf.org, martin.vigoureux@nokia.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for Babel) to Proposed Standard


The IESG has received a request from the Babel routing protocol WG (babel) to
consider the following document: - 'YANG Data Model for Babel'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-04-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a data model for the Babel routing protocol.
  The data model is defined using the YANG data modeling language.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/



No IPR declarations have been submitted directly on this I-D.

draft-ietf-babel-yang-model-06

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  Proposed Standard as indicated on the title page. This draft
  specifies the standard YANG model for the Babel routing protocol, a
  routing protocol that has been approved as a Proposed standard and
  is now in the RFC Editor's queue (draft-ietf-babel-rfc6126bis).
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document defines a data model for the Babel routing protocol.
  The data model is defined using the YANG data modeling language.

Working Group Summary:

  This YANG model is based on Babel drafts that have been approved as
  Proposed Standards (the base protocol and security drafts) and the
  Babel information model in draft-ietf-babel-information-model. This
  draft was originally last called in November of 2019 and approved
  based on the mailing list support and November IETF meeting
  discussion:
  https://mailarchive.ietf.org/arch/msg/babel/QGxLY-QsKnQClovMqi2eVVCbIjo/
  However, shortly thereafter some questions aroze on the
  information and yang models. These were discussed over the ensuing
  months with the conclution that no significant YANG changes were
  required. A cofirmatory WG LC extension was issued resulting in
  further support and no opposition so consensus was confirmated as
  follows:
  https://mailarchive.ietf.org/arch/msg/babel/51ghA03etPG9UdbtSeghPDVR2qk/

Document Quality:

  The document is of good quality. An early YANG docotor review was
  done and the comments were resolved:
  https://mailarchive.ietf.org/arch/msg/babel/5CVaLWJegUC5nrN50E-2CNM1n60/

Personnel:

  Document Shepherd: Donald Eastlake
  Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

  The draft was reviewed a couple of times by the Document Shepherd
  who is not a YANG expert. No problems were found.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  An early YANG doctor review was performed.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

  Yes. See:
  https://mailarchive.ietf.org/arch/msg/babel/51ghA03etPG9UdbtSeghPDVR2qk/
  https://mailarchive.ietf.org/arch/msg/babel/kTC_mhW1qk7sUUCMmqA3Gw6uECo/

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclsoure filed on this draft.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There is a solid WG consensus for this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  There are references to older vesion of two draft that will be
  updated the next time the draft is updated.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  Early YANG doctors review comments have been resolved. Datatracker
  shows a nice green ying-yang symbol for the draft.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  No. All references are to RFCs except for the references to
  draft-ietf-babel-rfc6126bis and draft-ietf-babel-information-model
  both of which drafts are approved and in the RFC Editor's queue.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified.

  IANA Considerations look good, just the usual assignments for a
  YANG module.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  This document does not create any IANA registties.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

  There is YANG in this draft. It is automatically reviewed by the
  draft submission process and passes as indicated by a green
  yin-yang symbol by the draft.

(20) If the document contains a YANG module, has the module been
checked with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

  The YANG module complies with NMDA and has been checked.

draft-ietf-babel-yang-model-06

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  Proposed Standard as indicated on the title page. This draft
  specifies the standard YANG model for the Babel routing protocol, a
  routing protocol that has been approved as a Proposed standard and
  is now in the RFC Editor's queue (draft-ietf-babel-rfc6126bis).
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  This document defines a data model for the Babel routing protocol.
  The data model is defined using the YANG data modeling language.

Working Group Summary:

  This YANG model is based on Babel drafts that have been approved as
  Proposed Standards (the base protocol and security drafts) and the
  Babel information model in draft-ietf-babel-information-model. This
  draft was originally last called in November of 2019 and approved
  based on the mailing list support and November IETF meeting
  discussion:
  https://mailarchive.ietf.org/arch/msg/babel/QGxLY-QsKnQClovMqi2eVVCbIjo/
  However, shortly thereafter some questions aroze on the
  information and yang models. These were discussed over the ensuing
  months with the conclution that no significant YANG changes were
  required. A cofirmatory WG LC extension was issued resulting in
  further support and no opposition so consensus was confirmated as
  follows:
  https://mailarchive.ietf.org/arch/msg/babel/51ghA03etPG9UdbtSeghPDVR2qk/

Document Quality:

  The document is of good quality. An early YANG docotor review was
  done and the comments were resolved:
  https://mailarchive.ietf.org/arch/msg/babel/5CVaLWJegUC5nrN50E-2CNM1n60/

Personnel:

  Document Shepherd: Donald Eastlake
  Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

  The draft was reviewed a couple of times by the Document Shepherd
  who is not a YANG expert. No problems were found.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  An early YANG doctor review was performed.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

  Yes. See:
  https://mailarchive.ietf.org/arch/msg/babel/51ghA03etPG9UdbtSeghPDVR2qk/
  https://mailarchive.ietf.org/arch/msg/babel/kTC_mhW1qk7sUUCMmqA3Gw6uECo/

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclsoure filed on this draft.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There is a solid WG consensus for this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  There are references to older vesion of two draft that will be
  updated the next time the draft is updated.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  Early YANG doctors review comments have been resolved. Datatracker
  shows a nice green ying-yang symbol for the draft.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  No. All references are to RFCs except for the references to
  draft-ietf-babel-rfc6126bis and draft-ietf-babel-information-model
  both of which drafts are approved and in the RFC Editor's queue.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified.

  IANA Considerations look good, just the usual assignments for a
  YANG module.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  This document does not create any IANA registties.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, YANG modules,
etc.

  There is YANG in this draft. It is automatically reviewed by the
  draft submission process and passes as indicated by a green
  yin-yang symbol by the draft.

(20) If the document contains a YANG module, has the module been
checked with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

  The YANG module complies with NMDA and has been checked.