Early Review of draft-ietf-i2rs-rib-info-model-12
|Requested rev.||11 (document currently at 17)|
|Team||Ops Directorate (opsdir)|
|Requested by||Susan Hares|
|Authors||Nitin Bahadur, Sriganesh Kini, Jan Medved|
|Draft last updated||2018-01-12|
Rtgdir Early review of -08 by Ravi Singh
Rtgdir Early review of -11 by Henning Rogge (diff)
Opsdir Early review of -12 by Mahesh Jethanandani (diff)
Genart Last Call review of -14 by Peter Yee (diff)
Secdir Last Call review of -14 by Paul Wouters (diff)
Opsdir Last Call review of -12 by Mahesh Jethanandani (diff)
Chair urgent request for brief review prior to last call review from OPS-DIR, RTG-DIR, and YANG doctors. If the appropriate directorates could give advise to the chair, shepherd and authors in a brief first past review, we can go forward. As it is, this draft passed WG LC in June, and is stuck. Your gracious aid is appreciated. For Yang Doctors: This informational yang model did not recieve a Yang doctor's review for the informational model. The data model has received a yang doctor's review. These are synced. These are revised datastore models. Do the yang doctors want to see the following revised datastore guidelines followed: https://datatracker.ietf.org/doc/draft-dsdt-nmda-guidelines/. What is lacking in this informational model? For OPS-DIR/RTG-DIR: The RTG-DIR / OPS-DIR needs to check the security considerations and appropriate issues. It appears that John Scudder's review of the data model pointed out these areas related to the informational model.
|Reviewed rev.||12 (document currently at 17)|
|Review result||Not Ready|
I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-i2rs-rib-info-model-12 Summary: 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. Document Status: Not ready Comments: This document is a information model, and as such does not define a data model that is directly used by a protocol. Therefore it has no operational or management impact. Having tried to read the document, I believe a lot can be done to improve its readability. At times it appears that different people took a crack at different sections of the document, without agreeing on the overall structure of the document. There is also something funny about how the section numbers have been given and the diagrams placed within them. Section 2. Figure 2 shows the RIB model. By putting it where it is, I would have expected that all the elements of the diagram would be explained in that section. One has to read section 2.1 and 2.2 to figure the details. Even then it is difficult to comprehend by reading all sections what the diagram is trying to convey. First of all, it appears that there can be multiple routing instances, but the diagram refers to one routing instance. If the idea is to refer to one routing instance in the RIB model, then as the name suggests, it is not the RIB model, but one routing instance of the RIB model. Either change the name or show the diagram with multiple instances. Also if each RIB consists of 0..N routes, that is not clear from the diagram. It appears that each routing-instance has 1..N RIBs and 0..N routes with no relationship to each other. Section 2.3 Similarly for Figure 3, the diagram is in section 2.3, but if one has to understand the diagram, one has to read section 2.4 to understand the diagram. Figure 3 shows the route model. It specifies 6 match conditions, but shows only 5 in the diagram. What happened to IP multicast match? Section 2.4 Figure 4 is titled Nexthop model. There is no explanation of the figure in Section 2.4 and what the different pieces of the diagram mean. Instead, it talks about how nexthop points to a BGP peer, a reference which is not clear by looking at the diagram. I would have expected at least an explanation of the rest of the diagram. The next section gets into Nexthop types, with no apparent ties to the diagram. Section 3 and 4. There is a lot of common text between the two sections. I do not know if there is a way to combine it. There is no word like modify-able or even modifiable. s/are modify-able objects/can be modified/ Section 6. RIB grammar The section says the grammar is intended to help the reader better understand the english text description. But it then goes on to say that if there is lack of clarify in the grammar the english text will take precedence. So what gives - english text or grammar? Also where is the english text? At this point I stopped and could not comprehend the rest of the document or its organization.