Sarah: Thank you for your comments. These are helpful. As a Shepherd, I'll help the authors address your comments in the latest revision. On #1) The nexthop chains are described in detail in draft-ietf-i2rs-rib-info-model in section 7.2.5. Would reference in the appropriate place provide the necessary detail or would you like additional comments added? On #2) Thank you for mentioning this point. I will work with the authors to reduce the Nits. On #3) Thank you for mentioning this point. The longer list of authors was vetted with the AD due to the combination of multiple drafts into 1. Since we cleared this with the AD early in the process, it seems unreasonable to change it at this point. Susan Hares -----Original Message----- From: Sarah Banks [mailto:sbanks@xxxxxxxxxxxxx] Sent: Wednesday, April 4, 2018 4:50 PM To: ops-dir@xxxxxxxx Cc: i2rs@xxxxxxxx; draft-ietf-i2rs-rib-data-model.all@xxxxxxxx; ietf@xxxxxxxx Subject: Opsdir early review of draft-ietf-i2rs-rib-data-model-10 Reviewer: Sarah Banks Review result: Has Nits 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. Upon review, I think the document is in decent shape, but needs work in the WG first. There are 3 things I'd like to point out: 1. There are areas in the document where we assume the reader knows <x>, but the document text could be helped if the authors were more concise in their wording. For example: "At the same time, nexthop chains can be used to specify multiple headers over a packet, before that particular packet is forwarded. Not every network device will be able to support all kinds of nexthop chains along with the arbitrary number of headers which are chained together." I would think that while this might often be true, it doesn't have to always be true, and depending on how wide the domain is, it might not be true. I realize this isn't written with normative language, and it's a minor point, but it lacks precision. 2. Nits has issues. Yup, a lot of authors think we'll just toss it in the queue and let the RFC Editors fix this, but I think it's our job to be sending clean docs into the queue. We pay for the RFC Editors service, why have them spending time on things we have a tool that allows the authors to do this for themselves? Fix your nits. :) 3. The document violates the number of named authors at the top - another expense of RFC Editors time and effort I don't think we should be doing. I'd prefer to see the authors/WG/WG Chairs address these items before they go into the queue. Thanks Sarah
