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 |