Skip to main content

RIB Information Model
draft-ietf-i2rs-rib-info-model-17

Revision differences

Document history

Date Rev. By Action
2018-08-30
17 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-08-06
17 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-07-17
17 (System) RFC Editor state changed to RFC-EDITOR from REF
2018-06-27
17 (System) RFC Editor state changed to REF from EDIT
2018-05-08
17 (System) RFC Editor state changed to EDIT
2018-05-08
17 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-05-08
17 (System) Announcement was received by RFC Editor
2018-05-08
17 (System) IANA Action state changed to No IC from In Progress
2018-05-08
17 (System) IANA Action state changed to In Progress
2018-05-08
17 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-05-08
17 Amy Vezza IESG has approved the document
2018-05-08
17 Amy Vezza Closed "Approve" ballot
2018-05-08
17 Amy Vezza Ballot approval text was generated
2018-05-08
17 Martin Vigoureux IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2018-05-07
17 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-17.txt
2018-05-07
17 (System) New version approved
2018-05-07
17 (System) Request for posting confirmation emailed to previous authors: Jan Medved , Nitin Bahadur , Sriganesh Kini
2018-05-07
17 Nitin Bahadur Uploaded new revision
2018-05-02
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-05-02
16 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-16.txt
2018-05-02
16 (System) New version approved
2018-05-02
16 (System) Request for posting confirmation emailed to previous authors: Jan Medved , Nitin Bahadur , Sriganesh Kini
2018-05-02
16 Nitin Bahadur Uploaded new revision
2018-04-22
15 Mahesh Jethanandani Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Mahesh Jethanandani.
2018-04-05
15 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2018-04-05
15 Alissa Cooper
[Ballot comment]
I don't see any response in email to the Gen-ART review, although some of the changes he proposed seemed to have been taken …
[Ballot comment]
I don't see any response in email to the Gen-ART review, although some of the changes he proposed seemed to have been taken on board in the -15 version. These comments of his do not seem to have been addressed, however:

Sec. 2.2, 1st paragraph after bullet list, last sentence: Routing instances are
identified by ROUTER_IDs anyhow, so this sentence seems superfluous.  Perhaps
you are trying to get across the point that the ROUTER_ID (which is definitely
present for the router) is not *used* by this routing instance.

I think there's a discussion missing that may or may not be within scope of
this document.  RIBs appear to be typically divided according to the protocol
for which they are providing routing (IPv4, MPLS, etc.)  Section 7.1 discusses
routing preferences, with an example of OSPF route and a route from some other
protocol.  When the OSPF route is withdrawn, the other route is installed in
the FIB.  What's not clear is what makes the decision to do this and cause a
specific RIB to push its route into the FIB.  Is that the routing instance or
the RIB manager?  A routing instance is described as a set of interfaces, RIBs,
and routing parameters.  It's description does not make it clear that it
arbitrates among the RIBs or the routing protocols which are using the
northbound interface to talk to the RIB manager.  Figure 1 makes it seem like
there is a RIB manger per RIB, in which case how can the RIB manager make
decisions between multiple RIBs?

Sec. 5: there are unstated assumptions about needing a
subscription mechanism for subscribing to notifications, particularly
notifications from RIBs that were not created by the entity.  (This goes back
to the concept on the previous page that entities may possibly read to or write
from RIBs they did not create.)  The discussion of notifications could use some
fleshing out here.
2018-04-05
15 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-04-05
15 Ignas Bagdonas
[Ballot comment]
A few nits:

Terminology: rib family vs address family. Address family term is more widely used in the industry.

VPLS is a subset …
[Ballot comment]
A few nits:

Terminology: rib family vs address family. Address family term is more widely used in the industry.

VPLS is a subset of L2VPN.

ROUTER_ID usage is orthogonal to router virtualization. MUST restriction for the domain is factually incorrect - it is typically per source protocol, not per domain.
2018-04-05
15 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-04-05
15 Martin Vigoureux Ballot approval text was generated
2018-04-04
15 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-04-04
15 Suresh Krishnan
[Ballot comment]
* Section 2.3.

Regarding the OSPF route for 2001:DB8::1/32

Did you mean 2001:DB8::1/128 for the host route? If not, this example is wrong …
[Ballot comment]
* Section 2.3.

Regarding the OSPF route for 2001:DB8::1/32

Did you mean 2001:DB8::1/128 for the host route? If not, this example is wrong since 2001:DB8::1/32 expands to 2001:DB8:0000:0000:0000:0000:0000:1/32 -> 2001:DB8::/32 as the route

* Figure 4.

Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into nexthop processing just like the derived nexthops do?

* Section 6

I would have expected the match type to have some indication about whether it requires an exact match or LPM (e.g. A MAC route uses an exact match but an IPv6 route uses LPM). Has the WG discussed this?
2018-04-04
15 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-04-04
15 Benjamin Kaduk
[Ballot comment]
I share Warren's question (and, IIRC, asked a similar one about
the associated data-model document).

Just one other minor question: in Section 4 …
[Ballot comment]
I share Warren's question (and, IIRC, asked a similar one about
the associated data-model document).

Just one other minor question: in Section 4

  Route programming in the RIB MUST result in a return code that
  contains the following attributes:

  o  Installed - Yes/No (Indicates whether the route got installed in
      the FIB)

  o  Active - Yes/No (Indicates whether a route is fully resolved and
      is a candidate for selection)

  o  Reason - e.g., Not authorized

Is the Reason only relevant when one of the other two is "No"?
2018-04-04
15 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-04-04
15 Ben Campbell
[Ballot comment]
[I do not expect a change this late in the process due to the following comment; I make more in hopes it will …
[Ballot comment]
[I do not expect a change this late in the process due to the following comment; I make more in hopes it will be helpful in the future]

I don't think the use of 2119/8174 in this draft adds value, and may even be counterproductive. Many of the instances use keywords to make definitions rather than normative requirements. For example, a statement of the form "Foo MUST contain these mandatory fields" is equivalent to "Foo contains these mandatory fields". In most cases, a draft of this nature is better off just using descriptive language.
2018-04-04
15 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-04-04
15 Warren Kumari
[Ballot comment]
I think that this document would make a really nice introduction to how RIBs work for a University type class and / or …
[Ballot comment]
I think that this document would make a really nice introduction to how RIBs work for a University type class and / or required reading for new hires at many network vendors.

I do have a large question, a comment,  and a bunch of nits:
1: Question:
o  NEXTHOP_LB_WEIGHT: This is used for load-balancing.  Each list
      member MUST be assigned a weight between 1 and 99.  The weight
      determines the proportion of traffic to be sent over a nexthop
      used for forwarding as a ratio of the weight of this nexthop
      divided by the weights of all the nexthops of this route that are
      used for forwarding.  To perform equal load-balancing, one MAY
      specify a weight of "0" for all the member nexthops.  The value
      "0" is reserved for equal load-balancing and if applied, MUST be
      applied to all member nexthops.

I'm confused what makes 0 special -- if I have e.g 17 links and I assign a weight of e.g 42 to each of them I'll still get equal load-balancing, yes?
Why is 0 reserved? I get that having one link with a weigh of e.g 12 and another link with a weight of 0 that would cause issues, but perhaps 0 should simply be unusable?
I a: really don't understand and b: thing the document should have some text answering this.

2: Comment: Section 7.1.  Using route preference
The entire "Route preference can also be used..." paragraph, while true, feels very out of place. I'd suggest jsut removing it.

I do have a bunch of nits -- I took these while reading the document, most of them are truly nits...

Section 1:
O:"populate the Routing information base (RIB) "
P:"populate the Routing Information Base (RIB)"
C: If it is an acronym, might as make it clear...

Section 2.1.  RIB definition
O: "even have two or more RIBs of the same rib family"
P: "even have two or more RIBs of the same RIB family"
C: Consistency

Section 2.2.  Routing instance
O: "It allows different logical slices; across a set of routers; to communicate with each  other."
P: "It allows different logical slices, across a set of routers, to communicate with each  other."
C: I'm guessing the semicolons were from before this sentence was rewritten.

O: "The RIBs specify how incoming traffic is to be forwarded.  And the routing parameters control the information in the RIBs."
P: "The RIBs specify how incoming traffic is to be forwarded, and the routing parameters control the information in the RIBs."
C: Flow.

O: "A routing instance MUST contain the following mandatory fields."
P: "A routing instance MUST contain the following mandatory fields:"
C: Colon instead (and below).

O: "Future RIB events can cause an unresolved nexthop to get resolved (like that IP address being advertised by an IGP neighbor)."
P: "Future RIB events can cause an unresolved nexthop to get resolved (for example that IP address being advertised by an IGP neighbor)."

Section 2.4.2.  Derived nexthops
O: "Nexthop chains (See Section 7.2.5 for usage), is a way to perform"
P: "Nexthop chains (See Section 7.2.5 for usage), are a way to perform"

Section 2.4.2.1.  Nexthop list attributes
There is a random extra '*' between bullets.
2018-04-04
15 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-04-04
15 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-04-04
15 Jean Mahoney Closed request for Last Call review by GENART with state 'Team Will not Review Version'
2018-04-04
15 Martin Vigoureux sorry, forgot to move that in proper state
2018-04-04
15 Martin Vigoureux IESG state changed to IESG Evaluation from Waiting for Writeup
2018-04-03
15 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2018-04-03
15 Alvaro Retana
[Ballot comment]
(1) Even if just Informative, it would be nice to have a reference to draft-ietf-i2rs-rib-data-model.

(2) I think that the use of some …
[Ballot comment]
(1) Even if just Informative, it would be nice to have a reference to draft-ietf-i2rs-rib-data-model.

(2) I think that the use of some Normative Language is not as expected.

(2.1) For example, in S2.1 (RIB definition): "There MAY be many routing instances and each routing instance MAY contain RIBs."  In both cases "MAY" seems to be a statement of fact, and not a normative statement to indicate that a routing instance can optionally include RIBs.  Note that S2.2 (Routing instance) identifies a rib-list as a mandatory component of a routing instance, and there's no clear indication that the list may be empty.

(2.2) S2.1: "A routing instance MAY even have two or more RIBs of the same rib family (e.g., IPv6)."  This use of "MAY" also seems to be stating a fact.

(2.3) "MAY be optionally", "MAY contain the following optional fields" are redundant phrases as MAY already means optional.
2018-04-03
15 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-04-02
15 Martin Vigoureux Ballot has been issued
2018-04-02
15 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2018-04-02
15 Martin Vigoureux Created "Approve" ballot
2018-04-02
15 Martin Vigoureux Ballot writeup was changed
2018-03-30
15 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-03-29
15 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-03-29
15 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-03-29
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-03-29
15 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-15.txt
2018-03-29
15 (System) New version approved
2018-03-29
15 (System) Request for posting confirmation emailed to previous authors: Jan Medved , Nitin Bahadur , Sriganesh Kini
2018-03-29
15 Nitin Bahadur Uploaded new revision
2018-03-21
14 Amy Vezza Shepherding AD changed to Martin Vigoureux
2018-03-01
14 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-i2rs-rib-info-model-14, which is currently in Last Call, and has the following comments:

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

The IANA Services Operator has reviewed draft-ietf-i2rs-rib-info-model-14, 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
2018-03-01
14 Paul Wouters Request for Last Call review by SECDIR Completed: Ready. Reviewer: Paul Wouters.
2018-02-23
14 Peter Yee Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. Sent review to list.
2018-02-23
14 Amy Vezza
The following Last Call announcement was sent out (ends 2018-03-30):

From: The IESG
To: IETF-Announce
CC: i2rs@ietf.org, Susan Hares , i2rs-chairs@ietf.org, akatlas@gmail.com, …
The following Last Call announcement was sent out (ends 2018-03-30):

From: The IESG
To: IETF-Announce
CC: i2rs@ietf.org, Susan Hares , i2rs-chairs@ietf.org, akatlas@gmail.com, shares@ndzh.com, draft-ietf-i2rs-rib-info-model@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Routing Information Base Info Model) to Informational RFC


The IESG has received a request from the Interface to the Routing System WG
(i2rs) to consider the following document: - 'Routing Information Base Info
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
ietf@ietf.org mailing lists by 2018-03-30. 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


  Routing and routing functions in enterprise and carrier networks are
  typically performed by network devices (routers and switches) using a
  routing information base (RIB).  Protocols and configuration push
  data into the RIB and the RIB manager installs state into the
  hardware; for packet forwarding.  This draft specifies an information
  model for the RIB to enable defining a standardized data model, and
  it was used by the IETF's I2RS WG to design the I2RS RIB data model.
  It is being published to record the higher level informational model
  decisions for RIBs so that other developers of RIBs may benefit from
  the design concepts.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/ballot/


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




2018-02-23
14 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-02-23
14 Amy Vezza Last call announcement was changed
2018-02-23
14 Amy Vezza Last call announcement was generated
2018-02-23
14 Alia Atlas Last call was requested
2018-02-23
14 Alia Atlas IESG state changed to Last Call Requested from Waiting for Writeup
2018-02-23
14 Alia Atlas Last call announcement was changed
2018-02-23
14 Alia Atlas Telechat date has been changed to 2018-04-05 from 2018-03-08
2018-02-23
14 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-02-20
14 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-02-20
14 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-i2rs-rib-info-model-13, which is currently in Last Call, and has the following comments:

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

The IANA Services Operator has reviewed draft-ietf-i2rs-rib-info-model-13, 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
2018-02-16
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani
2018-02-16
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani
2018-02-16
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2018-02-16
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2018-02-15
14 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-02-15
14 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-02-13
14 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-14.txt
2018-02-13
14 (System) New version approved
2018-02-13
14 (System) Request for posting confirmation emailed to previous authors: Jan Medved , Nitin Bahadur , Sriganesh Kini
2018-02-13
14 Nitin Bahadur Uploaded new revision
2018-02-09
13 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-02-09
13 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-02-23):

From: The IESG
To: IETF-Announce
CC: i2rs@ietf.org, Susan Hares , i2rs-chairs@ietf.org, akatlas@gmail.com, …
The following Last Call announcement was sent out (ends 2018-02-23):

From: The IESG
To: IETF-Announce
CC: i2rs@ietf.org, Susan Hares , i2rs-chairs@ietf.org, akatlas@gmail.com, shares@ndzh.com, draft-ietf-i2rs-rib-info-model@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Routing Information Base Info Model) to Informational RFC


The IESG has received a request from the Interface to the Routing System WG
(i2rs) to consider the following document: - 'Routing Information Base Info
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
ietf@ietf.org mailing lists by 2018-02-23. 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


  Routing and routing functions in enterprise and carrier networks are
  typically performed by network devices (routers and switches) using a
  routing information base (RIB).  Protocols and configuration push
  data into the RIB and the RIB manager installs state into the
  hardware; for packet forwarding.  This draft specifies a information
  model for the RIB to enable defining a standardized data model.  Such
  a data model can be used to define an interface to the RIB from an
  entity that may even be external to the network device.  This
  interface can be used to support new use-cases being defined by the
  IETF I2RS WG.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/ballot/


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




2018-02-09
13 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-02-09
13 Alia Atlas Last call was requested
2018-02-09
13 Alia Atlas Last call announcement was generated
2018-02-09
13 Alia Atlas Ballot approval text was generated
2018-02-09
13 Alia Atlas Ballot writeup was generated
2018-02-09
13 Alia Atlas IESG state changed to Last Call Requested from Publication Requested
2018-02-09
13 Alia Atlas Placed on agenda for telechat - 2018-03-08
2018-02-09
13 Susan Hares Intended Status changed to Informational from Proposed Standard
2018-02-09
13 Susan Hares
Shepherd's open issues:  (2/9/2018)
1) suggested -14.txt for authors with additional change based on
  a) Henning Rogge's - 2 and 3rd comments,
  b) …
Shepherd's open issues:  (2/9/2018)
1) suggested -14.txt for authors with additional change based on
  a) Henning Rogge's - 2 and 3rd comments,
  b) Mahesh Jethanandani - comments.

I have forwarded you copies of my comments. I believe these can be processed in parallel with your reading. 
In the interest of catching the AD's time, I am running these two processes in parallel.
Sue Hares

=============
Shepherd's review is Required by RFC 4858, template date: 2/24/2012.
======
(1) What type of RFC: Informational
Why: Yang Informational model

(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
Routing and routing functions in enterprise and carrier networks are
  typically performed by network devices (routers and switches) using a
  routing information base (RIB).  Protocols and configuration push
  data into the RIB and the RIB manager installs state into the
  hardware; for packet forwarding.  This draft specifies a information
  model for the RIB to enable defining a standardized data model.  Such
  a data model can be used to define an interface to the RIB from an
  entity that may even be external to the network device.  This
  interface can be used to support new use-cases being defined by the
  IETF I2RS WG.

Working Group Summary

The I2RS WG and the authors have survived all
IETF processes and patient waiting on the
NETMOD/NETCONF WG to complete its work on
revising the nework management datastore architecture.
The 13 revisions over 5 years are testimony to the
the continue support.  At last, all the
network management datastore architectures are complete.
Now, perhaps we can approve the IM which has
not changed for 4 years.

Document Quality

This is an informational model which
helped form the draft-ietf-i2rs-rib-data-model.

The document has been through repeated reviews
and debates within netmod/I2rs.
It is worth publishing because we see repeatly additional
attempts to do a RIB model without the same thought.
This model can support NMDA dynamic datastores or
normal datastores.  It depends on where it is mounted.

Personnel

  Who is the Document Shepherd?: Susan Hares
Who is the Responsible Area Director? Alia Atlas
RTG-DIR: Henning Rouge
https://datatracker.ietf.org/doc/review-ietf-i2rs-rib-info-model-11-rtgdir-early-rogge-2017-08-01/
OPS-DIR: Mahesh Jethanandani
https://datatracker.ietf.org/doc/review-ietf-i2rs-rib-info-model-12-opsdir-early-jethanandani-2018-01-12/

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

1) Reviewed the ID-nits
2) Requested early OPS-DIR and Routing-DIR review of this model.
  Reviewed -13.txt to determine if these suggestions were followed.
  Sent author suggested changes for version -14.txt of this model.
3) Read this document repeatedly over 5 years

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

Not after 5 years.  The information model was debated and
discussed by the WG as things changed.  At a certain point,
we switched to debating the subset of the features that
draft-ietf-i2rs-rib-data-model contained and their
impact on NMDA yang model architecture and netconf/restcont.  This informational
model needs to be published because several of the high
level ideas were not able to be followed-up on in I2RS.

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

As a Informational model, it would be good to have Yang doctors and
RTG-DIR review these models again.  We've pushed toward publication
because follow-up on the requests for review of changs have not occurred. 

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

I am comfortable with this document as a summary of a great deal of
work that went on in the I2RS WG.

Many IESG members do not like publishing Informational Models, so
I would make a specific plea for this informational model.
We had a substantial amount of discussion that produced insights
regarding RIBS.  I am seeing these same discussion start to reoccur in
other WGs regarding RIBs.  This informational model captures the
high-level concepts that any RIB will want to consider.  Rather than
waste time of other groups to re-do this effort, I ask that the IESG
publish this informational model. 

The high level RIB model was not specifically ephemeral dynamic datastores, but
designed to work in any  datastore (configuration or dynamic).

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

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

Nitin Bhandura
https://mailarchive.ietf.org/arch/msg/i2rs/O_ypXeOuu1llF1GBnaLyBDzG5lA

Sriganesh Kini
https://mailarchive.ietf.org/arch/msg/i2rs/MjDY8zV7ShMV10kLAznmM1ERQ-4

Jan Medved
https://mailarchive.ietf.org/arch/msg/i2rs/3YeQ0hDoxz-rmm0o6F5tg4w26XU


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

We have talk about this model for 5 years, and there
has been 4 WG LC pulled back.  So, if you are looking for strong
indications in email - see 5 years ago.

The network management datastore architecture has delayed this
over and over.  It is strong agreement 5 years ago and wanning interest
due to the long period of time it has taken to work through the
NMDA architecture.  The NMDA design is sound, but this
WGs active actions on the last calls is a casuality of the IETF process.
If it sounds like this WG Chair and the WG are tired after this process,
let this be a lesson to future IESGs.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

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

Only 3 nits - which appear to be problems with he idnits tool.

  == Line 409 has weird spacing: '...  base  load...'

  == Line 426 has weird spacing: '...thop-id  egres...'

  == Line 434 has weird spacing: '...l-encap  tunne...'

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

Yang informational model should go to RTG-DIR and Yang doctors for follow-up.

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

yes.

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

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

no


(16) Will publication of this document change the status of any
existing RFCs? 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.

no.

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

No IANA action needed in this document.

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

No IANA action needed in this document.

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

The RIB information in section 6 uses: Routing Backus-Naur Form [RFC5511].
As far as I know, there is no automated tests for this form.
2018-02-09
13 Susan Hares Responsible AD changed to Alia Atlas
2018-02-09
13 Susan Hares IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-02-09
13 Susan Hares IESG state changed to Publication Requested
2018-02-09
13 Susan Hares IESG process started in state Publication Requested
2018-02-09
13 Susan Hares Changed document writeup
2018-02-09
13 Susan Hares Changed document writeup
2018-02-09
13 Susan Hares Changed document writeup
2018-02-09
13 Susan Hares Notification list changed to Susan Hares <shares@ndzh.com>
2018-02-09
13 Susan Hares Document shepherd changed to Susan Hares
2018-02-09
13 Susan Hares Changed document writeup
2018-02-06
13 Alia Atlas Changed consensus to Yes from Unknown
2018-01-24
13 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-13.txt
2018-01-24
13 (System) New version approved
2018-01-24
13 (System) Request for posting confirmation emailed to previous authors: Jan Medved , Nitin Bahadur , Sriganesh Kini
2018-01-24
13 Nitin Bahadur Uploaded new revision
2018-01-12
12 Mahesh Jethanandani Request for Early review by OPSDIR Completed: Not Ready. Reviewer: Mahesh Jethanandani. Sent review to list.
2017-12-15
12 Jonathan Hardwick Closed request for Early review by RTGDIR with state 'Overtaken by Events'
2017-11-22
12 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-12.txt
2017-11-22
12 (System) New version approved
2017-11-22
12 (System) Request for posting confirmation emailed to previous authors: Jan Medved , Nitin Bahadur , Sriganesh Kini
2017-11-22
12 Nitin Bahadur Uploaded new revision
2017-11-09
11 Susan Hares Changed document writeup
2017-10-22
11 Mehmet Ersue Closed request for Early review by YANGDOCTORS with state 'Team Will not Review Document'
2017-10-05
11 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Patrice Brissette
2017-10-05
11 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Patrice Brissette
2017-10-04
11 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Mahesh Jethanandani
2017-10-04
11 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Mahesh Jethanandani
2017-10-04
11 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Les Ginsberg
2017-10-04
11 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Les Ginsberg
2017-09-28
11 Min Ye Request for Early review by RTGDIR is assigned to John Scudder
2017-09-28
11 Min Ye Request for Early review by RTGDIR is assigned to John Scudder
2017-09-27
11 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Ladislav Lhotka
2017-09-27
11 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Ladislav Lhotka
2017-09-27
11 Mehmet Ersue Closed request for Early review by YANGDOCTORS with state 'Withdrawn'
2017-09-27
11 Susan Hares Requested Early review by YANGDOCTORS
2017-09-27
11 Susan Hares Requested Early review by RTGDIR
2017-09-27
11 Susan Hares Requested Early review by OPSDIR
2017-09-20
11 Gunter Van de Velde Closed request for Early review by OPSDIR with state 'No Response'
2017-08-01
11 Jonathan Hardwick Request for Early review by RTGDIR Completed: Has Nits. Reviewer: Henning Rogge. Sent review to list.
2017-08-01
11 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Tina Tsou
2017-08-01
11 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Tina Tsou
2017-07-31
11 Jouni Korhonen Assignment of request for Early review by OPSDIR to Jouni Korhonen was rejected
2017-07-20
11 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Henning Rogge
2017-07-20
11 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Henning Rogge
2017-07-18
11 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Giles Heron
2017-07-18
11 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Giles Heron
2017-07-17
11 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Jouni Korhonen
2017-07-17
11 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Jouni Korhonen
2017-07-17
11 Susan Hares Requested Early review by YANGDOCTORS
2017-07-17
11 Susan Hares Requested Early review by RTGDIR
2017-07-17
11 Susan Hares Requested Early review by OPSDIR
2017-06-16
11 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-11.txt
2017-06-16
11 (System) New version approved
2017-06-16
11 (System) Request for posting confirmation emailed to previous authors: Jan Medved , Nitin Bahadur , Sriganesh Kini
2017-06-16
11 Nitin Bahadur Uploaded new revision
2016-12-22
10 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-10.txt
2016-12-22
10 (System) New version approved
2016-12-21
10 (System) Request for posting confirmation emailed to previous authors: "Sriganesh Kini" , "Nitin Bahadur" , "Jan Medved"
2016-12-21
10 Nitin Bahadur Uploaded new revision
2016-07-07
09 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-09.txt
2016-05-19
08 Xian Zhang Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Ravi Singh.
2016-05-03
08 Xian Zhang Request for Early review by RTGDIR is assigned to Ravi Singh
2016-05-03
08 Xian Zhang Request for Early review by RTGDIR is assigned to Ravi Singh
2016-05-03
08 Xian Zhang Closed request for Early review by RTGDIR with state 'No Response'
2016-04-25
08 Xian Zhang Request for Early review by RTGDIR is assigned to Michael Richardson
2016-04-25
08 Xian Zhang Request for Early review by RTGDIR is assigned to Michael Richardson
2015-10-28
08 Susan Hares IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2015-10-28
08 Susan Hares Intended Status changed to Proposed Standard from None
2015-10-19
08 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-08.txt
2015-09-30
07 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-07.txt
2015-03-08
06 Sriganesh Kini New version available: draft-ietf-i2rs-rib-info-model-06.txt
2015-01-27
05 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-05.txt
2014-12-03
04 Sriganesh Kini New version available: draft-ietf-i2rs-rib-info-model-04.txt
2014-05-27
03 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-03.txt
2014-02-13
02 Sriganesh Kini New version available: draft-ietf-i2rs-rib-info-model-02.txt
2013-10-18
01 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-01.txt
2013-09-16
00 Nitin Bahadur New version available: draft-ietf-i2rs-rib-info-model-00.txt