Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2024-01-26
14 Gunter Van de Velde Request closed, assignment withdrawn: Tina Tsou Last Call OPSDIR review
2024-01-26
14 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2021-06-30
14 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-06-03
14 (System) RFC Editor state changed to AUTH48
2021-04-23
14 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-04-09
14 (System) RFC Editor state changed to EDIT
2021-04-09
14 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-04-09
14 (System) Announcement was received by RFC Editor
2021-04-09
14 (System) IANA Action state changed to No IANA Actions from In Progress
2021-04-09
14 (System) IANA Action state changed to In Progress
2021-04-09
14 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-04-09
14 Cindy Morgan IESG has approved the document
2021-04-09
14 Cindy Morgan Closed "Approve" ballot
2021-04-09
14 Cindy Morgan Ballot approval text was generated
2021-03-19
14 Martin Vigoureux IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2021-03-19
14 Martin Vigoureux Ballot approval text was generated
2021-03-11
14 Barbara Stark New version available: draft-ietf-babel-information-model-14.txt
2021-03-11
14 (System) New version accepted (logged-in submitter: Barbara Stark)
2021-03-11
14 Barbara Stark Uploaded new revision
2021-03-08
13 Donald Eastlake Added to session: IETF-110: babel  Tue-1530
2021-02-22
13 Barbara Stark New version available: draft-ietf-babel-information-model-13.txt
2021-02-22
13 (System) New version accepted (logged-in submitter: Barbara Stark)
2021-02-22
13 Barbara Stark Uploaded new revision
2021-02-09
12 Benjamin Kaduk
[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 …
[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.
2021-02-09
12 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2021-01-26
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-01-26
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-01-26
12 Barbara Stark New version available: draft-ietf-babel-information-model-12.txt
2021-01-26
12 (System) New version accepted (logged-in submitter: Barbara Stark)
2021-01-26
12 Barbara Stark Uploaded new revision
2020-11-05
11 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-11-05
11 Cindy Morgan Changed consensus to Yes from Unknown
2020-11-04
11 Murray Kucherawy
[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 …
[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.
2020-11-04
11 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-11-04
11 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-11-04
11 Robert Wilton
[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 …
[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
2020-11-04
11 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-11-04
11 Éric Vyncke
[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 …
[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.
2020-11-04
11 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-11-03
11 Erik Kline [Ballot comment]
[[ nits ]]

[ section 3.1 ]

* s/running and operational/running any operational/?
2020-11-03
11 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-11-03
11 Alvaro Retana
[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 …
[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/
2020-11-03
11 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-11-02
11 Benjamin Kaduk
[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 …
[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.)
2020-11-02
11 Benjamin Kaduk
[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 …
[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.
2020-11-02
11 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-11-02
11 Roman Danyliw
[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 …
[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.”
2020-11-02
11 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-10-31
11 Barry Leiba
[Ballot comment]
Just a couple of minor comments here:

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

— …
[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.
2020-10-31
11 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-10-28
11 Amy Vezza Placed on agenda for telechat - 2020-11-05
2020-10-28
11 Martin Vigoureux Ballot has been issued
2020-10-28
11 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2020-10-28
11 Martin Vigoureux Created "Approve" ballot
2020-10-28
11 Martin Vigoureux IESG state changed to IESG Evaluation from Waiting for Writeup
2020-10-28
11 Martin Vigoureux Ballot writeup was changed
2020-10-27
11 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-10-26
11 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2020-10-26
11 Sabrina Tanamal
(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 …
(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
2020-10-26
11 Valery Smyslov Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Valery Smyslov. Sent review to list.
2020-10-22
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Valery Smyslov
2020-10-22
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Valery Smyslov
2020-10-22
11 Roni Even Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list.
2020-10-20
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tina Tsou
2020-10-20
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tina Tsou
2020-10-20
11 Min Ye Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Geoff Huston.
2020-10-19
11 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Geoff Huston
2020-10-19
11 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Geoff Huston
2020-10-19
11 Luc André Burdet Assignment of request for Last Call review by RTGDIR to He Jia was rejected
2020-10-19
11 Luc André Burdet Request for Last Call review by RTGDIR is assigned to He Jia
2020-10-19
11 Luc André Burdet Request for Last Call review by RTGDIR is assigned to He Jia
2020-10-15
11 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2020-10-15
11 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2020-10-13
11 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-10-13
11 Amy Vezza
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 …
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.




2020-10-13
11 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-10-13
11 Martin Vigoureux Requested Last Call review by RTGDIR
2020-10-13
11 Martin Vigoureux Last call was requested
2020-10-13
11 Martin Vigoureux Ballot approval text was generated
2020-10-13
11 Martin Vigoureux Ballot writeup was generated
2020-10-13
11 Martin Vigoureux IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-10-13
11 Martin Vigoureux Last call announcement was generated
2020-09-29
11 Martin Vigoureux IESG state changed to AD Evaluation::AD Followup from AD Evaluation
2020-08-14
11 Barbara Stark New version available: draft-ietf-babel-information-model-11.txt
2020-08-14
11 (System) New version approved
2020-08-14
11 (System) Request for posting confirmation emailed to previous authors: Mahesh Jethanandani , Barbara Stark
2020-08-14
11 Barbara Stark Uploaded new revision
2020-08-14
10 Martin Vigoureux IESG state changed to AD Evaluation from Publication Requested
2020-07-27
10 Donald Eastlake Added to session: IETF-108: babel  Mon-1300
2019-10-13
10 Donald Eastlake

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the …

(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.
2019-10-13
10 Donald Eastlake Responsible AD changed to Martin Vigoureux
2019-10-13
10 Donald Eastlake IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-10-13
10 Donald Eastlake IESG state changed to Publication Requested from I-D Exists
2019-10-13
10 Donald Eastlake IESG process started in state Publication Requested
2019-10-13
10 Donald Eastlake

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the …

(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.
2019-10-13
10 Donald Eastlake

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the …

(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.
2019-10-09
10 Donald Eastlake https://mailarchive.ietf.org/arch/browse/babel/?q=consensus
2019-10-09
10 Donald Eastlake IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-10-09
10 Barbara Stark New version available: draft-ietf-babel-information-model-10.txt
2019-10-09
10 (System) New version approved
2019-10-09
10 (System) Request for posting confirmation emailed to previous authors: Mahesh Jethanandani , Barbara Stark
2019-10-09
10 Barbara Stark Uploaded new revision
2019-08-22
09 Barbara Stark New version available: draft-ietf-babel-information-model-09.txt
2019-08-22
09 (System) New version approved
2019-08-22
09 (System) Request for posting confirmation emailed to previous authors: Mahesh Jethanandani , Barbara Stark
2019-08-22
09 Barbara Stark Uploaded new revision
2019-08-04
08 Barbara Stark New version available: draft-ietf-babel-information-model-08.txt
2019-08-04
08 (System) New version approved
2019-08-04
08 (System) Request for posting confirmation emailed to previous authors: Mahesh Jethanandani , Barbara Stark
2019-08-04
08 Barbara Stark Uploaded new revision
2019-07-21
07 Barbara Stark New version available: draft-ietf-babel-information-model-07.txt
2019-07-21
07 (System) New version approved
2019-07-21
07 (System) Request for posting confirmation emailed to previous authors: Mahesh Jethanandani , Barbara Stark
2019-07-21
07 Barbara Stark Uploaded new revision
2019-07-20
06 Donald Eastlake Added to session: IETF-105: babel  Wed-1550
2019-07-08
06 Barbara Stark New version available: draft-ietf-babel-information-model-06.txt
2019-07-08
06 (System) New version approved
2019-07-08
06 (System) Request for posting confirmation emailed to previous authors: Mahesh Jethanandani , Barbara Stark
2019-07-08
06 Barbara Stark Uploaded new revision
2019-03-24
05 Donald Eastlake Added to session: IETF-104: babel  Thu-0900
2019-03-10
05 Donald Eastlake IETF WG state changed to In WG Last Call from WG Document
2019-03-10
05 Donald Eastlake Notification list changed to Donald Eastlake <d3e3e3@gmail.com>
2019-03-10
05 Donald Eastlake Document shepherd changed to Donald E. Eastlake 3rd
2019-03-05
05 Barbara Stark New version available: draft-ietf-babel-information-model-05.txt
2019-03-05
05 (System) New version approved
2019-03-05
05 (System) Request for posting confirmation emailed to previous authors: babel-chairs@ietf.org, Barbara Stark
2019-03-05
05 Barbara Stark Uploaded new revision
2018-12-20
04 Donald Eastlake Intended Status changed to Informational from None
2018-10-24
04 Donald Eastlake Added to session: IETF-103: babel  Wed-1540
2018-10-22
04 Barbara Stark New version available: draft-ietf-babel-information-model-04.txt
2018-10-22
04 (System) New version approved
2018-10-22
04 (System) Request for posting confirmation emailed to previous authors: Barbara Stark
2018-10-22
04 Barbara Stark Uploaded new revision
2018-09-24
03 Min Ye Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Acee Lindem.
2018-08-27
03 Min Ye Request for Early review by RTGDIR is assigned to Acee Lindem
2018-08-27
03 Min Ye Request for Early review by RTGDIR is assigned to Acee Lindem
2018-08-27
03 Donald Eastlake Requested Early review by RTGDIR
2018-07-17
03 Donald Eastlake Added to session: IETF-102: babel  Tue-0930
2018-06-05
03 Barbara Stark New version available: draft-ietf-babel-information-model-03.txt
2018-06-05
03 (System) New version approved
2018-06-05
03 (System) Request for posting confirmation emailed to previous authors: Barbara Stark
2018-06-05
03 Barbara Stark Uploaded new revision
2018-04-05
02 Barbara Stark New version available: draft-ietf-babel-information-model-02.txt
2018-04-05
02 (System) New version approved
2018-04-05
02 (System) Request for posting confirmation emailed to previous authors: Barbara Stark
2018-04-05
02 Barbara Stark Uploaded new revision
2018-01-02
01 Barbara Stark New version available: draft-ietf-babel-information-model-01.txt
2018-01-02
01 (System) New version approved
2018-01-02
01 (System) Request for posting confirmation emailed to previous authors: Barbara Stark
2018-01-02
01 Barbara Stark Uploaded new revision
2017-07-03
00 (System) This document now replaces draft-stark-babel-information-model instead of None
2017-07-03
00 Barbara Stark New version available: draft-ietf-babel-information-model-00.txt
2017-07-03
00 (System) New version approved
2017-07-03
00 Barbara Stark Request for posting confirmation emailed  to submitter and authors: Barbara Stark
2017-07-03
00 Barbara Stark Uploaded new revision