Re: [i2rs] Opsdir early review of draft-ietf-i2rs-rib-data-model-10

["Susan Hares" <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, April 4, 2018 4:50 PM
To: [e-mail]
Cc: [e-mail]; [e-mail];
[e-mail]
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