Re: [i2rs] Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

[Alia Atlas <[e-mail]>]

Hi Amit,

It has been three weeks.

Can you please get the update ASAP?  I need to get it reviewed and into
IETF Last Call.
As you know, I am closing I2RS at IETF 101 - which means this draft needs
to be on the March 8 telechat.
That means it really should be in IETF Last Call by February 16 - and I am
traveling all next week
and busy.   I REALLY need it ASAP to review.

Regards,
Alia

On Thu, Jan 18, 2018 at 4:58 AM, Amit Dass <[e-mail]> wrote:

> Hi Sue,
>
> I expect to have some free time during this week.  Should be able to send
> the update by Monday next week.
>
> Best regards,
> Amit
>
> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Thursday, January 18, 2018 10:55 AM
> To: Amit Dass <[e-mail]>; 'Ebben Aries' <[e-mail]>;
> [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
>
> Amit:
>
> Do you think you and your co-authors can do this within a few days.   I
> would like to forward the publication request.
>
> Also, please remember to look at the latest Revised datastore draft and
> yang tree module drafts.
>
> Sue Hares
>
> -----Original Message-----
> From: Amit Dass [mailto:[e-mail]]
> Sent: Thursday, January 18, 2018 4:53 AM
> To: Ebben Aries; [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
>
> Thanks Ebben for reviewing the draft. I will update the same based on
> below comments and feedback.
>
>
> Best regards,
> Amit
>
> -----Original Message-----
> From: Ebben Aries [mailto:[e-mail]]
> Sent: Thursday, January 18, 2018 9:33 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
>
> Reviewer: Ebben Aries
> Review result: On the Right Track
>
> 1 module in this draft:
> - [e-mail]
>
> No YANG validation errors or warnings (from pyang 1.7.3 and yanglint
> 0.14.59)
>
> 0 examples are provided in this draft (section 3.12 of
> draft-ietf-netmod-rfc6087bis-15)
>
> Module [e-mail]:
> - yang-version statement missing - should be 1.1
> - prefix 'iir' is recommended for this module, would 'rib' suffice better?
> - import "ietf-inet-types" should reference RFC 6991 per (not as a comment)
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
> - import "ietf-interfaces" should reference RFC 7223 per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
> - import "ietf-yang-types" should reference RFC 6991 per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
> - Since this module imports "ietf-interfaces", a normative references must
> be
>   added per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-3.9
> - prefix "if" in the import "ietf-interfaces" can remove quotes to remain
>   consistent with other imports
> - Remove WG Chairs from contact information per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
> - Module description must contain most recent copyright notice per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
> - Module description should contain note to RFC Ed. and placeholder
> reference
>   to RFC when assigned
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
> - Add placeholder reference and note to RFC Ed. for RFC when assigned
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
> - Security Considerations should be updated to reflect new template at
>   https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
> - Section 1.2 should be replaced with reference to
>   draft-ietf-netmod-yang-tree-diagrams-02 rather (as-is in other i2rs YANG
>   drafts in progress) per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-
> 15#section-2.5.1
> - This module contains '12' features.  While it is understood the purpose
> of
>   these features in the module, take precaution as to complexity for
> clients
>   if they need to understand >= quantity of features per module in use on a
>   network-element.
> - A few comments exist that are either unecessary or redundant.  Encode the
>   comment intent rather in description fields if need be.
> - Per NMDA, which datastores are targeted for the module?  Will all RPC
>   operations be acting upon the dynamic/ephemeral datastore?  It is not
> clear
>   to me if the intention is to be persistent or ephemeral
>
> General comments/Nits:
> - references to 'def' could be expanded out to 'definition'
> - references to 'decap' could be expanded out to 'decapsulation' for
>   readability (across definitions and descriptions)
> - Follow consistent capitalization of 'RIB' throughout document text.
> Mixed
>   use of 'Rib' and 'rib' exists (Outside of YANG node lowercase
> definitions).
> - Is it necessary to prefix all nodes under the nexthop container with
>   "nexthop-"?
> - Section 2.5 - route-add RPC - text mentions it is required that the
> nh-add
>   RPC be called as a pre-requisite however if the nh already exists and the
>   nexthop-id is known, this should not be necessary.  In addition, the text
>   reads 'or return' which should rather be a result of querying the
>   appropriate node in the data tree.
> - In 'IANA Considerations' - s/This document requests to register/This
>   document registers/
>
>
>