Babel Information Model
draft-ietf-babel-information-model-14

[Ballot comment]
Thanks for the updates in the -12

The following point was previously a discuss-level point, and I would still very much
like to see textual changes to the document to either remove the restriction or justify it,
but since it in practice seems like it will not impose an artificial limitation on achievable
security I will drop to "no objection" for expediency:

The current text limits the length of HMAC keys to be between 0 and the block length of
the underlying hash function (e.g., 64 bytes for SHA-256).  This limitation was previously
present in the draft that became RFC 8967 but was removed in draft-ietf-babel-hmac-10.
I do not know of a security or usability reason that justifies this restriction, and feel that
having the information model diverge from the protocol spec requires some justification.

[Ballot comment]
The shepherd writeup is more than a year old.  I wonder if we should get into the habit of asking that these be refreshed before they're scheduled on telechats.

Please fix the boilerplate text from BCP 14 (your Section 1.1).

Lastly, +1 to Barry's comments.

[Ballot comment]
Thank you for this document.

I support Ben's discuss regarding reusing the terminology from NMDA.  I think that the document should have a normative reference to RFC 8342, and probably explain that in some places the information model is using the same concepts of configuration and operational data separation described in NMDA.

I also support Alvaro's question about whether the source-routing component should be included.

This is just a comment, and I'm not proposing that you change tack, but I have to confess that I question how beneficial publishing an Information Model really is.  I understand that the goal here is to be able to publish two different data models,  one based on YANG and other based on BBF's [TR-181].    But what we end up with is an information model defined in a custom ad hoc language, which will naturally necessitate for the YANG and TR-181 models to be generated by hand, and for all three models to be kept up to date and consistent with each other.  Hence, I wonder whether retrospectively it would have been better to just define the YANG model in IETF and ask BBF to use that as source reference to construct the TR-181 model from, ideally as a programmatic conversion, or failing that by hand.  At least that way there are only two things to keep in sync rather than three.

Regards,
Rob

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points, and some nits.

I also second Alvaro's question about the source-routing component.

I hope that this helps to improve the document,

Regards,

-éric
== COMMENTS ==

I have a slight concern that draft-ietf-babel-yang-model is not reviewed at the same time as the information model but, at least, they will be reviewed in the right order ;-)

-- Section 3 --
For an informational document, I wonder whether the use of normative "MAY" is required.

-- Section 3.2 --
About the UDP port, should the Babel default be part of the information model description ? I would prefer to leave it to the protocol specifications. Same remark applies to other objects/properties when the Babel default value is repeated in the information model. What is the usefulness of repeating it ?

== NITS ==

-- Section 2 --
It is probably a matter of taste ;-) but I do not like too much the fact that all the objects names start with "babel-" as it is implicit.

[Ballot comment]
I want to revisit the question about including support for source-specific
routing in the Information model.

This topic came up already, but the discussion focused only on whether
source-specific routing needed to be enabled or not, with one implementor
mentioning that their implementation required it [1].

In addition to enabling the functionality, and because "most of the
information model is focused on reporting Babel protocol operational state"
(§1), I am interested in the reporting side.  It seems to me that the
incremental cost to add this support is trivial (as described in
§3/draft-ietf-babel-source-specific: "Data Structures").

Why is source-specific routing not supported?  I find it to be a significant
omission, especially considering that the source-specific routing spec is in
IESG Evaluation at the same time.


[1] https://mailarchive.ietf.org/arch/msg/babel/F7tlCQk8IeTaHN_rKHbsoKF3urE/

[Ballot discuss]
Section 2 says that the "DTLS certificate values" are required to return
no value when read, but this property seems to be intended for private
data such as DTLS private key values, not the certificates themselves
(which are public).

While I appreciate that IPv6 is the current version of the internet
protocol, I do see that 6126bis allows for Babel to run over both IPv6
and IPv4, yet this document in multiple places implicitly assumes that
Babel runs over IPv6, to the exclusion of IPv4.  Such a restriction from
the core protocol spec should only be undertaken by an information model
with clear reasoning and loud disclaimer.

Similarly (as Roman notes), we are putting requirements on the key
length for MAC keys (relative to the block size of the underlying hash
function) that have were once present in draft-ietf-babel-hmac but have
been removed as of draft-ietf-babel-hmac-10.  I assume that the intent
is not to impose additional restrictions compared to the protocol spec,
thus we need to catch up to those changes.

The description of the babel-mac-key-test and babel-cert-test operations
need to be tightened up, as the secdir reviewer noted.  (See COMMENT.)

We seem to be using terminology from the Network Management Datastore
Architecture without reference or otherwise introducing the concepts.
This is a Discuss point because the only candidate reference I know of,
RFC 8342, is specific to YANG and data models, so it's applicability for
use in an information model may be subject to discussion.  (Hopefully
this only reflects my ignorance and not a fundamental lack of datastore
architecture for information models.)

[Ballot comment]
Section 1.1

Please use the specific RFC 8174 boilerplate (in particular, it includes
"NOT RECOMMENDED").

Section 2

We have separate MAC/DTLS-enablement nodes at a per-interface
level, so not having them at the global level is perhaps suprising.

I'm happy to see babel-dtls-cert-types, given that the babel/DTLS spec
leaves much open as to how to authenticate peers.  Even more specificity
could be useful.

  Most parameters are read-only.  Following is a descriptive list of
  the parameters that are not required to be read-only:

It's suprising to not see router-id on this list; 6126bis says only that
"every Babel speaker is assigned a router-id" without saying how.  In
the absence of a "how", it seems reasonable to assume "assigned by the
administrator" as a valid option.

How do I configure which prefixes to advertise as originated from this
router?  Do I just add something to the babel-routes list with NULL
received metric?  But if that's how I do it, then the babel-route-obj
can't be 'ro'...

  o  Interface: Metric algorithm

  o  Interface: Split horizon

  o  Interface: enable/disable Babel on this interface
  [...]

It might be useful to list these in the same order as they appear in the
tree diagram.

  o  Interface: MAC algorithm

What node in the tree does this correspond to?

Section 3.1

  babel-enable:  When written, it configures whether the protocol
      should be enabled (true) or disabled (false).  A read from the
      running or intended datastore indicates the configured
      administrative value of whether the protocol is enabled (true) or
      not (false).  A read from the operational datastore indicates

Perhaps it's just me, but running/intended/operational datastores feels
like a YANG/NMDA thing and is surprising to see in a nominally generic
information model, absent further reference.
(Similarly for subsequent usage of the terms.)

  babel-self-router-id:  The router-id used by this instance of the
      Babel protocol to identify itself.  [I-D.ietf-babel-rfc6126bis]
      describes this as an arbitrary string of 8 octets.  The router-id
      value MUST NOT consist of all zeroes or all ones.

Why is the MUST NOT a requirement of the information model rather than
the protocol?

  babel-metric-comp-algorithms:  List of supported cost computation
      algorithms.  Possible values include "2-out-of-3", and "ETX". "2-
      out-of-3" is described in [I-D.ietf-babel-rfc6126bis], section
      A.2.1.  "ETX" is described in [I-D.ietf-babel-rfc6126bis], section
      A.2.2.

Perhaps this is just me, but the way this is written implies that the
specific string values are to be used, which may be overly prescriptive
for an information model.  Also, is there a registry for these
algorithms that could be referenced?

  babel-security-supported:  List of supported security mechanisms.
      Possible values include "MAC" and "DTLS".

  babel-mac-algorithms:  List of supported MAC computation algorithms.
      Possible values include "HMAC-SHA256", "BLAKE2s".

  babel-dtls-cert-types:  List of supported DTLS certificate types.
      Possible values include "X.509" and "RawPublicKey".

Likewise, are there registries for these?  (D)TLS does have an existing
certificate types registry
(https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3
is the one to use), but for the MAC algorithms that's pretty inherently
a very flexible extension point so it's easy to add a new algorithm with
no or a very minimal written spec.

Section 3.2

  babel-mcast-group:  Multicast group for sending and listening to
      multicast announcements on IPv6.  Default is ff02::1:6.  An

IIRC the core protocol only has it as RECOMMENDED for control traffic to
be over IPv6; the "on IPv6" here seems unnecessarily limiting.

Section 3.3

  babel-interface-reference:  Reference to an interface object that can
      be used to send and receive IPv6 packets, as defined by the data

[again the implicit IPv6 requirement]

  babel-mcast-hello-interval:  The current interval in use for
      multicast Hellos sent on this interface.  Units are centiseconds.
      This is a 16-bit unsigned integer.

Perhaps it is better to discuss that the units need to have sufficient
precision to represent centisecond granularity rather than to enforce a
specific unit and constrain data models/implementations.
(Similarly for other mentions of units.)

  babel-dtls-cached-info:  Indicates whether the cached_info extension
      is included in ClientHello and ServerHello packets.  The extension

Please reference RFC 7924 here.

      is included if the value is "true".  An implementation MAY choose
      to expose this parameter as read-only ("ro").

I wonder if we can/should give a bit more guidance on what to include in
the extension, as currently it would be compliant with this spec (but
not very useful) to emit a cached_information extension that is highly
unlikely to result in any packet size savings.

  babel-dtls-cert-prefer:  List of supported certificate types, in
      order of preference.  The values MUST be among those listed in the
      babel-dtls-cert-types parameter.  This list is used to populate
      the server_certificate_type extension in a Client Hello.  Values

An RFC 7250 reference is probably in order.

  babel-packet-log:  A reference or url link to a file that contains a
      timestamped log of packets received and sent on babel-udp-port on
      this interface.  The [libpcap] file format with .pcap file
      extension SHOULD be supported for packet log files.  Logging is

Does there need to be a mechanism for content-type
negotiation/indication?

Section 3.4

Shouldn't these all be 'counter's, not 'uint's?

Section 3.5

  babel-hello-mcast-history:  The multicast Hello history of whether or
      not the multicast Hello packets prior to babel-exp-mcast-hello-
      seqno were received.  A binary sequence where the most recently
      received Hello is expressed as a "1" placed in the left-most bit,

This seems to indicate that the leftmost bit is always '1', and thus
that we cannot be in a situation where we missed one expected multicast
hello and are already expecting "the one after it".  Is that correct?

Also, should we say anything about truncating the bitstring at some
arbitrary point?

(Similarly for the unicast case, on both counts.)

  babel-exp-ucast-hello-seqno:  Expected unicast Hello sequence number
      of next Hello to be received from this neighbor.  If unicast Hello
      packets are not expected, or processing of unicast packets is not
      enabled, this MUST be NULL.  This is a 16-bit unsigned integer; if

(We haven't defined "NULL" semantics yet.)

Section 3.6

  babel-route-neighbor:  Reference to the babel-neighbors entry for the
      neighbor that advertised this route.

Wouldn't that make this a "reference" type rather than "string"?

  babel-route-seqno:  The sequence number with which this route was
      advertised.  This is a 16-bit unsigned integer.

Is this text correct for locally originated routes?

Section 3.7

I don't wish to revisit the decision, but it might have been interesting
to record some of the reasoning for having an additional abstraction for
"key set" and having a list of key-sets, vs just having a list of keys
directly.  (Similarly for the DTLS cert sets.)

Section 3.8

  babel-mac-key-use-sign:  Indicates whether this key value is used to
      sign sent Babel packets.  Sent packets are signed using this key
      if the value is "true".  If the value is "false", this key is not

I agree with the secdir reviewer that the "sign" terminology is
problematic here, and would prefer something like
"babel-mac-key-use-generate" and a similar wording in the prose.

  babel-mac-key-value:  The value of the MAC key.  An implementation
      MUST NOT allow this parameter to be read.  This can be done by
      always providing an empty string when read, or through
      permissions, or other means.  This value MUST be provided when
      this instance is created, and is not subsequently writable.  This
      value is of a length suitable for the associated babel-mac-key-
      algorithm.  If the algorithm is based on the HMAC construction
      [RFC2104], the length MUST be between 0 and the block size of the
      underlying hash inclusive (where "HMAC-SHA256" block size is 64
      bytes as described in [RFC4868]).  If the algorithm is "BLAKE2s",
      the length MUST be between 0 and 32 bytes inclusive, as described
      in [RFC7693].

[Per the Discuss, this key-length guidance is not aligned with
draft-ietf-babel-hmac.]

  babel-mac-key-test:  An operation that allows the MAC key and hash
      algorithm to be tested to see if they produce an expected outcome.
      Input to this operation is a binary string.  The implementation is
      expected to create a hash of this string using the babel-mac-key-
      value and the babel-mac-key-algorithm.  The output of this
      operation is the resulting hash, as a binary string.

s/create a hash of/create a MAC over/
s/resulting hash/resulting MAC value/
Given that the intent is to test the MAC operation, it seems like we
might want to say that the input string is treated as a babel packet,
getting the pseudo-header added per draft-ietf-babel-hmac §4.1, etc.
It would be in keeping with cryptographic best practice to continue to
use the same pseudo-header (and possibly even include a disambiguating
context string) to avoid the risk of being an oracle for generating the
MAC of arbitrary text that could then be used to forge other packets
elsewhere.

As the secdir review noted, the MAC output length is not necessarily
fixed by the algorithm, so some indicatino of the output length is also
in order.

Section 3.10

  babel-cert-name:  A unique name for this DTLS certificate that can be
      used to identify the certificate in this object instance, since
      the value is too long to be useful for identification.  This value

Some guidance on whether or not it is expected to be useful to draw
naming information from the certificate's Subject information, vs an
arbitrary or fingerprint-based naming scheme, might be in order.

Also, it's somewhat unusual to talk about "(D)TLS certificates" as
opposed to X.509 certificate, raw public key, etc..

  babel-cert-test:  An operation that allows a hash of the provided
      input string to be created using the certificate public key and
      the SHA-256 hash algorithm.  Input to this operation is a binary
      string.  The output of this operation is the resulting hash, as a
      binary string.

This is problematic in several ways, as noted by the secdir reviewer.
For one, if we want to test a certificate, we usually would do that by
producing a signature, not a hash over the public key and some other
input.  Furthermore, not all the signatures produced by X.509 certificates
compatible with DTLS require a hash at all or are allowed to use SHA-256
within the signature operation.  It may be possible to require SHA-256
always by having the input to the signature operation be the SHA-256
output, which would then be hashed again during the process of computing
an (e.g., RSA) signature, but that is also a bit weird.
The purpose of the operation needs to be made more clear (is it to
verify the public key?  The private key?) as well as how the input is
structured; if the certificate private key is used to generate a
signature we must take care to avoid producing a signing oracle that can
be used to produce signatures valid in other contexts.

Section 5

We do expose an operation to get a packet dump, but it's not clear that
there are particularly noteworthy security considerations regarding that
-- the dump would appear to be the ciphertext based on the language
used, so it would not be a way to bypass DTLS encryption, for example.

  This information model defines objects that can allow credentials
  (for this device, for trusted devices, and for trusted certificate
  authorities) to be added and deleted.  Public keys may be exposed
  through this model.  This model requires that private keys never be

It might be worth another sentence indicating the scale of the
consequences of erroneously/maliciously setting such credentials.

  exposed.  The Babel security mechanisms that make use of these
  credentials (e.g., [I-D.ietf-babel-dtls], [I-D.ietf-babel-hmac])
  identify what credentials can be used with those mechanisms.

The DTLS one really doesn't, though -- it says only something like
"details of identity management are left to deployment profiles", and
there's a wide variety of DTLS credentials that are possible.
The MAC mechanism has a much clearer picture about what is allowed by
virtue of using the raw crypto primitive (though the allowed MAC
algorithms are negotiated out-of-band there as well).

  algorithm associated with the key.  Short (and zero-length) keys and
  keys that make use of only alphanumeric characters are highly
  susceptible to brute force attacks.

I don't think it's true to say that "keys that make use of only
alphanumeric characters are highly susceptible to brute force attacks".
Even if I stick to a 32-byte key, `dd if=/dev/random bs=1
count=24|openssl base64` is giving me 192 bits of randomness, which is
plenty for a modern security protocol.  I think you mean to say that
short keys are especially susceptible to brute-force when they only use
alphanumeric characters.

Section 8.2

Per https://www.ietf.org/iesg/statement/normative-informative.html even
optional features like DTLS, MAC, RFC 3339 timestasmps, etc., should be
listed as normative references.

[Ballot comment]
Thank you for the SECDIR review from Valery Smyslov.  Please review and respond to the remaining items.  In particular, I concur with the recommendations about precise language around the names of the parameters.

Section 3.1.  babel-implementation-version.  Is there any guidance on the format of this string (or is it free form like a Server: in HTTP)?

Section 3.1.  babel-metric-comp-algorithms, babel-mac-algorithms,    babel-dtls-cert-types.  Is there any guidance to provide on the delimiter between a list of values, or is that explicitly a data model issue?

Section 3.1. babel-security-supported, babel-mac-algorithms, babel-dtls-cert-types.  Consider providing citations on “MAC” and “DTLS”; and “HMAC-SHA256” and “BLAKE2s”; and “X.509” and “RawPublicKey” (just like was done for babel-metric-comp-algorithms).

Section 3.8.  babel-mac-key-value. 

If the algorithm is based on the HMAC construction
      [RFC2104], the length MUST be between 0 and the block size of the
      underlying hash inclusive (where "HMAC-SHA256" block size is 64
      bytes as described in [RFC4868]).  If the algorithm is "BLAKE2s",
      the length MUST be between 0 and 32 bytes inclusive, as described
      in [RFC7693].

I was under the impression that this was an information model to encode generic Babel protocol parameter and that the underlying protocol documents fully specified the normative behavior.  However, this guidance appears to be introducing more restrictive configuration guidance not found in draft-ietf-babel-hmac making this document an information model + profile.  Was this intentional?

Section 3.8 and 3.9.  babel-mac-key-test and babel-cert-test.  It would be useful to explain the use case for this testing API.

Section 5.  Note that operations are also exposed in the information model.

OLD
This document defines a set of information model objects and
  parameters that may be exposed to be visible from other devices

NEW
This document defines a set of information model objects,    parameters, and operations that may be exposed to be visible from other devices

Section 5.  Per:

MAC keys are allowed to be as short as zero-length.  This is useful
  for testing.  Network operators are advised to follow current best
  practices for key length and generation of keys related to the MAC
  algorithm associated with the key.  Short (and zero-length) keys and
  keys that make use of only alphanumeric characters are highly
  susceptible to brute force attacks.

Add clarifying text that the information model explicitly enables this brute force attack where most of the workload is pushed onto the server (since it computes the hash).  Also add a mitigation.  Perhaps something like “This information model provides an oracle via the babel-mac-key-test operation that would enable such a brute force attack.  Operators SHOULD rate limit access to this operation.”

[Ballot comment]
Just a couple of minor comments here:

— Section 1.1 —
Please use the exact BCP 14 boilerplate from RFC 8174.

— Section 1.2 —
For “datetime”, I suggest adding “Section 5.6” to the reference to RFC 3339, to make the specific format easier to find.  And I think the use of 3339 in the definition of the type makes it a normative reference.

Similarly, the use of ISO.10646 to define “string” makes it normative.

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

The IANA Functions Operator has reviewed draft-ietf-babel-information-model-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-10-27):

From: The IESG
To: IETF-Announce
CC: martin.vigoureux@nokia.com, babel-chairs@ietf.org, draft-ietf-babel-information-model@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Babel Information Model) to Informational RFC


The IESG has received a request from the Babel routing protocol WG (babel) to
consider the following document: - 'Babel Information Model'
  as Informational RFC

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 2020-10-27. 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 Babel Information Model provides structured data elements for a
  Babel implementation reporting its current state and may allow
  limited configuration of some such data elements.  This information
  model can be used as a basis for creating data models under various
  data modeling regimes.




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



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

(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?

Informational as indicated on the title page.

(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:

The Babel Information Model document provides structured data elements
for a Babel implementation reporting its current state and may allow
limited configuration of some such data elements.  This information
model can be used as a basis for creating data models under various
data modeling regimes.

  Working Group Summary:

There was continuing active discussion and improvement to the draft
for an extended after the initial Working Group Last Call so no
consensus judgement was made for that Last call. The list of
outstanding issues was updated and then presented and reviewed at WG
meeting at a number of IETF meeting, resolving many issues. Based on
the discussions and consensus on issue resolution shown on the mailing
list and at WG meetings, after a brief call for objections at
https://mailarchive.ietf.org/arch/msg/babel/JLunyZA9YdXXVm7S3wxGklavcCY
the draft was declared to have consensus.

  Document Quality:

The draft has been extensively reviewed by the community of interest
and is of good quality.

  Personnel:
Document Shepherd:  Donald Eastlake, 3rd
Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed
    by the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

Document Shepherd review at
https://mailarchive.ietf.org/arch/msg/babel/kgvbBpp1iCYCi6KgPx2CVLo89cs
Response, which was accepted, at
https://mailarchive.ietf.org/arch/msg/babel/e_bMNw7KrnnaAVQNw_sZwmskL8c

(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.

A routing review was performed. See
https://mailarchive.ietf.org/arch/msg/babel/UKxCP97gJhjF5Rln3LXIewxX2lY
Initial response is here
https://mailarchive.ietf.org/arch/msg/babel/qSCbwgrnLvsx84ctJABKbEWcCjA
Note that a separate YANG Model draft is progressing and about to
enter WG Last Call. See
https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/

(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?

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/mzwyXc_C-7YX_pZxy_9MDkuKQ4c
https://mailarchive.ietf.org/arch/msg/babel/qUXjl_2lYNKRCqWzu74SC4gw9S0

(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 disclosures.

(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 was a strong consensus among the subset of WG members that are
interested in data modeling for BABEL.

(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.

The nits checker gives 7 warnings, all of which are false alarms. Six
cases of "weird spacing" that are OK and one regular expression
character set misinterpreted as a reference.

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

No such formal review required.

(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?

There are normative references to draft-ietf-babel-rfc6126bis and to
the Wireshark Libpcap File Format document. The rfc6126bis draft is
through IETF last call and in the process of resolving IESG COMMENTs
and DISCUSSes. The Wireshark Libpcap File Format document is akin to a
standard of an SDO other than the IETF and is available at
https://wiki.wireshark.org/Development/LibpcapFileFormat

(15) Are there downward normative 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? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction? If the
    RFCs are not listed in the Abstract and Introduction, explain
    why, and point to the part of the document where the relationship
    of this document to the other RFCs is discussed. If this
    information is not in the document, explain why the WG considers
    it unnecessary.

This document does not change the status of any existing RFC.

(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. Confirm
    that newly created IANA registries include a detailed
    specification of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and
    a reasonable name for the new registry has been suggested (see
    RFC 5226).

This document requires no IANA actions.

(18) List any new IANA registries that require Expert Review for
    future allocations.

No IANA registries created.

(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, etc.

There is no such formal language in the draft although there is some
programming language-like notation in the draft.

(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?

Informational as indicated on the title page.

(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:

The Babel Information Model document provides structured data elements
for a Babel implementation reporting its current state and may allow
limited configuration of some such data elements.  This information
model can be used as a basis for creating data models under various
data modeling regimes.

  Working Group Summary:

There was continuing active discussion and improvement to the draft
for an extended after the initial Working Group Last Call so no
consensus judgement was made for that Last call. The list of
outstanding issues was updated and then presented and reviewed at WG
meeting at a number of IETF meeting, resolving many issues. Based on
the discussions and consensus on issue resolution shown on the mailing
list and at WG meetings, after a brief call for objections at
https://mailarchive.ietf.org/arch/msg/babel/JLunyZA9YdXXVm7S3wxGklavcCY
the draft was declared to have consensus.

  Document Quality:

The draft has been extensively reviewed by the community of interest
and is of good quality.

  Personnel:
Document Shepherd:  Donald Eastlake, 3rd
Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed
    by the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

Document Shepherd review at
https://mailarchive.ietf.org/arch/msg/babel/kgvbBpp1iCYCi6KgPx2CVLo89cs
Response, which was accepted, at
https://mailarchive.ietf.org/arch/msg/babel/e_bMNw7KrnnaAVQNw_sZwmskL8c

(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.

A routing review was performed. See
https://mailarchive.ietf.org/arch/msg/babel/UKxCP97gJhjF5Rln3LXIewxX2lY
Initial response is here
https://mailarchive.ietf.org/arch/msg/babel/qSCbwgrnLvsx84ctJABKbEWcCjA
Note that a separate YANG Model draft is progressing and about to
enter WG Last Call. See
https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/

(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?

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/mzwyXc_C-7YX_pZxy_9MDkuKQ4c
https://mailarchive.ietf.org/arch/msg/babel/qUXjl_2lYNKRCqWzu74SC4gw9S0

(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 disclosures.

(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 was a strong consensus among the subset of WG members that are
interested in data modeling for BABEL.

(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.

The nits checker gives 7 warnings, all of which are false alarms. Six
cases of "weird spacing" that are OK and one regular expression
character set misinterpreted as a reference.

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

No such formal review required.

(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?

There are normative references to draft-ietf-babel-rfc6126bis and to
the Wireshark Libpcap File Format document. The rfc6126bis draft is
through IETF last call and in the process of resolving IESG COMMENTs
and DISCUSSes. The Wireshark Libpcap File Format document is akin to a
standard of an SDO other than the IETF and is available at
https://wiki.wireshark.org/Development/LibpcapFileFormat

(15) Are there downward normative 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? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction? If the
    RFCs are not listed in the Abstract and Introduction, explain
    why, and point to the part of the document where the relationship
    of this document to the other RFCs is discussed. If this
    information is not in the document, explain why the WG considers
    it unnecessary.

This document does not change the status of any existing RFC.

(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. Confirm
    that newly created IANA registries include a detailed
    specification of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and
    a reasonable name for the new registry has been suggested (see
    RFC 5226).

This document requires no IANA actions.

(18) List any new IANA registries that require Expert Review for
    future allocations.

No IANA registries created.

(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, etc.

There is no such formal language in the draft although there is some
programming language-like notation in the draft.

(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?

Informational as indicated on the title page.

(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:

The Babel Information Model document provides structured data elements
for a Babel implementation reporting its current state and may allow
limited configuration of some such data elements.  This information
model can be used as a basis for creating data models under various
data modeling regimes.

  Working Group Summary:

There was continuing active discussion and improvement to the draft
for an extended after the initial Working Group Last Call so no
consensus judgement was made for that Last call. The list out
outstanding issues was updated and then presented and reviewed,
resolving many of them, at a number of WG meeting. Based on the
discussions and consensus on issue resolution shown on the mailing
list and at WG meetings, after a brief call for objections at
https://mailarchive.ietf.org/arch/msg/babel/JLunyZA9YdXXVm7S3wxGklavcCY
the draft was declared to have consensus.

  Document Quality:

The draft has been extensively reviewed by the community of interest
and is of good quality.

  Personnel:
Document Shepherd:  Donald Eastlake, 3rd
Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed
    by the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

Document Shepherd review at
https://mailarchive.ietf.org/arch/msg/babel/kgvbBpp1iCYCi6KgPx2CVLo89cs
response which was accepted at
https://mailarchive.ietf.org/arch/msg/babel/e_bMNw7KrnnaAVQNw_sZwmskL8c

(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.

A routing review was performed. See
https://mailarchive.ietf.org/arch/msg/babel/UKxCP97gJhjF5Rln3LXIewxX2lY
Initial Response is here
https://mailarchive.ietf.org/arch/msg/babel/qSCbwgrnLvsx84ctJABKbEWcCjA
Note that a separate YANG Model draft is progressing and about to
enter WG Last Call. See
https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/

(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?

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/mzwyXc_C-7YX_pZxy_9MDkuKQ4c
https://mailarchive.ietf.org/arch/msg/babel/qUXjl_2lYNKRCqWzu74SC4gw9S0

(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 disclosures.

(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 was a strong consensus among the subset of WG members that are
interested in data modeling for BABEL.

(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.

The nits checker gives 7 warnings, all of which are false alarms. Six
cases of "weird spacing" that are OK and one regular expression
character set misinterpreted as a reference.

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

No such formal review required.

(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?

There are normative references to draft-ietf-babel-rfc6126bis and to
the Wireshark Libpcap File Format document. The rfc6126bis draft is
through IETF last call and in the process of resolving IESG COMMENTs
and DISCUSSes. The Wireshark Libpcap File Format document is akin to a
standard of an SDO other than the IETF and is available at
https://wiki.wireshark.org/Development/LibpcapFileFormat

(15) Are there downward normative 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? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction? If the
    RFCs are not listed in the Abstract and Introduction, explain
    why, and point to the part of the document where the relationship
    of this document to the other RFCs is discussed. If this
    information is not in the document, explain why the WG considers
    it unnecessary.

This document does not change the status of any existing RFC.

(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. Confirm
    that newly created IANA registries include a detailed
    specification of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and
    a reasonable name for the new registry has been suggested (see
    RFC 5226).

This document requires no IANA actions.

(18) List any new IANA registries that require Expert Review for
    future allocations.

No IANA registries created.

(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, etc.

There is no such formal language in the draft although there is some
programming language-like notation in the draft.