Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

[Mach Chen]

Hi Tom,

> -Original Message-
> From: t.petch [mailto:ie...@btconnect.com]
> Sent: Sunday, April 08, 2018 7:42 PM
> To: Mach Chen ; Alissa Cooper
> ; The IESG 
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org; 
> i2rs-cha...@ietf.org;
> sha...@ndzh.com
> Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-
> model-10: (with COMMENT)
> 
>  Original Message -
> From: "Mach Chen" 
> To: "Alissa Cooper" ; "The IESG" 
> Cc: ; ;
> ; 
> Sent: Sunday, April 08, 2018 9:23 AM
> 
> > Hi Alissa,
> >
> > Thanks for your comments!
> >
> > Please see my responses inline...
> >
> > > -Original Message-
> > > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Alissa Cooper
> > > Sent: Tuesday, April 03, 2018 11:10 PM
> > > To: The IESG 
> > > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org;
> i2rs-cha...@ietf.org;
> > > sha...@ndzh.com
> > > Subject: [i2rs] Alissa Cooper's No Objection on
> draft-ietf-i2rs-rib-data-model-10:
> > > (with COMMENT)
> > >
> > > Alissa Cooper has entered the following ballot position for
> > > draft-ietf-i2rs-rib-data-model-10: No Objection
> > >
> > > When responding, please keep the subject line intact and reply to
> all email
> > > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > > paragraph, however.)
> > >
> > >
> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
> > >
> > >
> > >
> >
> > --
> > > COMMENT:
> >
> > --
> > >
> > > Sec 1.2:
> > >
> > > "YANG tree diagrams provide a concise representation of a YANG
> module,
> > >and SHOULD be included to help readers understand YANG module
> > >structure."
> > >
> > > This document does not seem like an appropriate place to have
> normative
> > > guidance about this. And if this sentence is removed, I don't see
> the point of
> > > including Section 1.2 otherwise. This would also imply deleting the
> reference to
> > > I-D.ietf-netmod-yang-tree-diagrams.
> >
> > This results from a YANG doctor review.  I saw it also occurs in other
> published documents. I personally think it's no harm to keep it, how do you
> think?
> 
> Mach
> 
> I think that this is very odd.
> 
> YANG guidelines rfc6087bis says
> "   YANG tree diagrams provide a concise representation of a YANG
> module,
>and SHOULD be included to help readers understand YANG module
>structure.  Guidelines on tree diagrams can be found in Section 3 of
>[I-D.ietf-netmod-yang-tree-diagrams].
> "
> which I think is the correct guidance in the correct place.
> 
> A quick look at the recently published RFC8343, RFC8344, RFC8345,
> RFC8346 contain no text of the kind you suggest so if it occurs in other I-D, 
> then
> I would regard those other I-D as being in error.
> 
> If I look back at a thread from Ebben for a yang doctor review of an earlier
> version of this I-D, the text I see proposed is
> 
> "
> >A simplified graphical representation of the data model is used in
> >this document.  The meaning of the symbols in these diagrams is
> >defined in [I-D.ietf-netmod-yang-tree-diagrams].
> "
> which I think is rather different.

Indeed, my fault, I just checked Ebben's suggestion, it's as above quoted. 

To Alissa:
If change to following text, is it OK for you?

"A simplified graphical representation of the data model is used in
this document.  The meaning of the symbols in these diagrams is
defined in [I-D.ietf-netmod-yang-tree-diagrams]."


Best regards,
Mach
> 
> Tom Petch
> (not a YANG doctor)
> 
> > >
> > > Sec 2.1: Again here I'm confused about the use of normative
> language. Why do
> > > you need to specify normative requirements for what this very
> document is
> > > specifying? Or are these supposed to be requirements on
> implementations?
> >
> > OK, how about this:
> >
> > "...a RIB data model needs to specify a way for an external entity to
> learn about the functional capabilities of a network device." And
> >
> > " The RIB data model needs a way to expose the nexthop chaining
> capability supported by a given network device."
> >
> > >
> > > Sec 2.5: s/causes/caused/
> >
> > Done
> >
> > The above updates will be reelected in version-11.
> >
> > Thanks,
> > Mach
> > >

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

[t.petch]

 Original Message -
From: "Mach Chen" 
To: "Alissa Cooper" ; "The IESG" 
Cc: ; ;
; 
Sent: Sunday, April 08, 2018 9:23 AM

> Hi Alissa,
>
> Thanks for your comments!
>
> Please see my responses inline...
>
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Alissa Cooper
> > Sent: Tuesday, April 03, 2018 11:10 PM
> > To: The IESG 
> > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org;
i2rs-cha...@ietf.org;
> > sha...@ndzh.com
> > Subject: [i2rs] Alissa Cooper's No Objection on
draft-ietf-i2rs-rib-data-model-10:
> > (with COMMENT)
> >
> > Alissa Cooper has entered the following ballot position for
> > draft-ietf-i2rs-rib-data-model-10: No Objection
> >
> > When responding, please keep the subject line intact and reply to
all email
> > addresses included in the To and CC lines. (Feel free to cut this
introductory
> > paragraph, however.)
> >
> >
> > Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
> >
> >
> >
>
> --
> > COMMENT:
>
> --
> >
> > Sec 1.2:
> >
> > "YANG tree diagrams provide a concise representation of a YANG
module,
> >and SHOULD be included to help readers understand YANG module
> >structure."
> >
> > This document does not seem like an appropriate place to have
normative
> > guidance about this. And if this sentence is removed, I don't see
the point of
> > including Section 1.2 otherwise. This would also imply deleting the
reference to
> > I-D.ietf-netmod-yang-tree-diagrams.
>
> This results from a YANG doctor review.  I saw it also occurs in other
published documents. I personally think it's no harm to keep it, how do
you think?

Mach

I think that this is very odd.

YANG guidelines rfc6087bis says
"   YANG tree diagrams provide a concise representation of a YANG
module,
   and SHOULD be included to help readers understand YANG module
   structure.  Guidelines on tree diagrams can be found in Section 3 of
   [I-D.ietf-netmod-yang-tree-diagrams].
"
which I think is the correct guidance in the correct place.

A quick look at the recently published RFC8343, RFC8344, RFC8345,
RFC8346 contain no text of the kind you suggest so if it occurs in other
I-D, then I would regard those other I-D as being in error.

If I look back at a thread from Ebben for a yang doctor review of an
earlier version of this I-D, the text I see proposed is

"
>A simplified graphical representation of the data model is used in
>this document.  The meaning of the symbols in these diagrams is
>defined in [I-D.ietf-netmod-yang-tree-diagrams].
"
which I think is rather different.

Tom Petch
(not a YANG doctor)

> >
> > Sec 2.1: Again here I'm confused about the use of normative
language. Why do
> > you need to specify normative requirements for what this very
document is
> > specifying? Or are these supposed to be requirements on
implementations?
>
> OK, how about this:
>
> "...a RIB data model needs to specify a way for an external entity to
learn about the functional capabilities of a network device." And
>
> " The RIB data model needs a way to expose the nexthop chaining
capability supported by a given network device."
>
> >
> > Sec 2.5: s/causes/caused/
>
> Done
>
> The above updates will be reelected in version-11.
>
> Thanks,
> Mach
> >

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] FW: Ignas Bagdonas' Discuss on draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)

[Zhuangyan (Yan)]

Hi Ignas,

Thanks for your responses and sorry for the delay due to a local holiday. 
Please see replies inline.

From: Ignas Bagdonas [mailto:ibagd...@gmail.com]
Sent: Thursday, April 05, 2018 2:38 AM
To: Susan Hares ; 'The IESG' 
Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org; 
i2rs-cha...@ietf.org
Subject: Re: FW: Ignas Bagdonas' Discuss on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)




On 04/04/2018 16:22, Susan Hares wrote:

Ignas:



I’m forwarding Yan’s specific answers to each of your questions. I had held 
this response back until I tried to learn more about what specific questions 
were tag with specific DISCUSS quality comments

per the IESG 2014 DISCUSS criteria comments:

https://www.ietf.org/blog/discuss-criteria-iesg-review/



I’m sure Yan will be glad to make adjustments in the draft (see below).

Thank you Yan, this seems to be a practical way forward in bringing clarity to 
the scope of the document.





You will note that you are asking us to put back in RPCs that others had us 
take out.

I will note that I am not asking for anything like that. Please re-read my 
DISCUSS notes.





This leads me to back to my questions as a Shepherd. My concern is that many of 
your requested changes

I recall raising questions, not requesting changes.



are counter to agreements in discussions with WG, TE WG, NETCONF/NETMOD, and 
previous ADS (OPS, RTG) regarding I2RS drafts.   Since these drafts were 
delayed due to the reading load of the IESG, it seems we are working under 
different rules.  So, please specify how your comments match the DISCUSS 
criteria.  If you are setting new rules for I2RS documents, please detail the 
new rules of review.



It is too bad that we could not have reviewed these documents during their 
originally scheduled telechat with previous  ADs.



Susan Hares



-Original Message-
From: Ignas Bagdonas [mailto:ibagd...@gmail.com]
Sent: Tuesday, April 03, 2018 7:40 PM
To: The IESG >
Cc: 
draft-ietf-i2rs-yang-dc-fabric-network-topol...@ietf.org;
 Susan Hares >; 
i2rs-cha...@ietf.org; 
sha...@ndzh.com; i2rs@ietf.org
Subject: Ignas Bagdonas' Discuss on 
draft-ietf-i2rs-yang-dc-fabric-network-topology-08: (with DISCUSS and COMMENT)



Ignas Bagdonas has entered the following ballot position for

draft-ietf-i2rs-yang-dc-fabric-network-topology-08: Discuss



When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-dc-fabric-network-topology/







--

DISCUSS:

--



I have concerns about the practical usability of this proposed model as it is 
specified now.



The intended decoupling of fabric implementation properties (what is termed as 
"underlay network infrastructure" in the document) and its topology seems to be 
contradicting to general operational practices of fabric based networks. It is 
generally true for the context of the overlay but that is not what the document 
seems to be focusing on. Fabric defines and implements the underlay, not the 
other way around.

[Y] The intention of this model is to represent the entire topology of a data 
center fabric network.

Yan, can you be specific here - the topology of what? Are we talking about the 
underlay topology, or an overlay instance topology? That is a major difference 
and many other comments will depend on this answer. The terminology does not 
help here too much - data center fabric network may mean many different things 
if viewed from different contexts.


[Y] We provide an entire topology for a dc fabric. This fabric contains several 
PODs as its “node”, each of which is composed of a set of underlay nodes (which 
are device nodes) and their interconnection links, and may implement different 
overlays. The links of this fabric can be connections between PODs, 
interconnections within a POD or connections to WANs.


The whole network can be considered as a single fabric network which is 
composed by several PODs defined as “node” in this module. Under these “nodes”, 
there are supporting-nodes (reference to device-nodes belonged to the POD) and 
connections.



The term of POD/fabric is a bit confusing in the draft. How about we updating 
the Terminology section as below?

Re: [i2rs] Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

[Mach Chen]

Hi Ignas,

Thanks for your comments!

Please see my replies inline...

> -Original Message-
> From: Ignas Bagdonas [mailto:ibagd...@gmail.com]
> Sent: Thursday, April 05, 2018 7:14 PM
> To: The IESG 
> Cc: draft-ietf-i2rs-rib-data-mo...@ietf.org; Susan Hares ;
> i2rs-cha...@ietf.org; sha...@ndzh.com; i2rs@ietf.org
> Subject: Ignas Bagdonas' No Objection on draft-ietf-i2rs-rib-data-model-10:
> (with COMMENT)
> 
> Ignas Bagdonas has entered the following ballot position for
> draft-ietf-i2rs-rib-data-model-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I2RS use cases document seems to be abandoned, and generally use case
> documents best fit the purpose of tracking the work on specification 
> documents.
> Is the reference really needed?

I am OK to remove it.

> 
> Please address RTG-DIR comments on RIB/Rib/rib consistency,
> encap/encapsulation, decap/decapsulation consisteny.

OK, done.

> 
> s/nexthop-replicates/nexthop-replicate, or change the description of base
> nexthop.

OK, s/nexthop-replicates/nexthop-replicate.


> 
> s/blow/below

Fixed.

> 
> s/VxLAN/VXLAN throughout the document.

Fixed.

> 
> nexthop-lb-weight-definition: divided by the sum of weights. Or, to simplify 
> the
> text, representing a proportion. Value of 0 is not in the range.

This is align with the current info model description, will discuss with the 
info model authors to address it. 

Thanks,
Mach 
> 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)

[Mach Chen]

Thanks Suresh, Martin and Sue,

The issues will be addressed in verion-11.

Best regards,
Mach

> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Thursday, April 05, 2018 10:08 PM
> To: 'Martin Bjorklund' 
> Cc: sur...@kaloom.com; i...@ietf.org; i2rs@ietf.org; draft-ietf-i2rs-rib-data-
> mo...@ietf.org; i2rs-cha...@ietf.org
> Subject: RE: [i2rs] Suresh Krishnan's Discuss on 
> draft-ietf-i2rs-rib-data-model-10:
> (with DISCUSS and COMMENT)
> 
> Martin:
> 
> Thank you for the proactive response on the types.  I'll work with the
> authors to change to these standard types.
> 
> Sue
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: Thursday, April 5, 2018 10:06 AM
> To: sha...@ndzh.com
> Cc: sur...@kaloom.com; i...@ietf.org; i2rs@ietf.org; draft-ietf-i2rs-rib-data-
> mo...@ietf.org; i2rs-cha...@ietf.org
> Subject: Re: [i2rs] Suresh Krishnan's Discuss on
> draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)
> 
> Hi,
> 
> There are standard types for IPv6 flow label and for MAC addresses defined in
> RFC 6991:
> 
>inet:ipv6-flow-label
>yang:mac-address
> 
> 
> /martin
> 
> 
> "Susan Hares"  wrote:
> > Suresh:
> >
> > Thank you for catching these issues.   I missed these as a Shepherd (as
> did
> > the other reviewers) and AD.  See my answers below.
> >
> > Would you or Martin hold a discuss until these critical issues are
> > resolved and checked with the YANG doctors?  I will work with the
> > authors
> to resolve
> > these issues.   This revision will take some time as we seek advice from
> the
> > YANG doctors and from the community on the IEEE MAC Address being an
> > index or a full MAC Address.
> >
> > Susan Hares
> >
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Suresh Krishnan
> > Sent: Wednesday, April 4, 2018 12:39 AM
> > To: The IESG
> > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org;
> > i2rs-cha...@ietf.org; sha...@ndzh.com
> > Subject: [i2rs] Suresh Krishnan's Discuss on
> > draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)
> >
> > Suresh Krishnan has entered the following ballot position for
> > draft-ietf-i2rs-rib-data-model-10: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > This model tries to squeeze the 20 bit IPv6 flow label into a 16 bit
> field.
> > This will result in a loss of data and needs to be fixed before the
> > document is published.
> >
> >
> > --
> > COMMENT:
> > --
> >
> > * Section 3
> >
> > => Under
> >
> > identity ipv6-decapsulation {
> >
> > it looks like the description is wrong ("IPv4 tunnel decapsulation.")
> > 
> > You are correct.  It will be replaced with the following =
> >identity ipv6-decapsulation {
> >  base "tunnel-decapsulation-action";
> >  description
> >"IPv6 tunnel decapsulation.";
> >}
> >
> > =>  What use case is the ttl-action decrease-and-copy-to-inner used for?
> > 
> > Good catch!
> > This feature may be used for tunnels (7.2.1 of
> > draft-ietf-i2rs-rib-info-model) or nexthops chains (section 7.2.5 of
> > draft-ietf-i2rs-rib-info-model).   Good catch in that it does not provide
> > enough detail in this version.
> >
> > We've had comments over the last years to put this level of detail in
> > or out of the YANG model.  I believe the latest wisdom from
> > NETMOD/NETCONF is to put the level of detail back in
> >
> > => Under case egress-interface-mac-nexthop {
> >
> > It is not clear to me how you fit a MAC address into a 32 bit space
> > ,or am
> I
> > misreading this somehow and this is some form of index?
> >
> > Good Catch.
> >
> > Early on it was a holding place for a the official IEEE:MAC table, and
> > should have been transferred to either the IEEE:MAC-ADDRESS (see page
> > 17 RIB-INFO draft). However, this definitely needs to get fixed.  I
> > need to check with the YANG Doctors to determine which is the
> > preferred fix for this reference at this time.  I'm sure implementers
> > have been using a fully qualified IEEE_MAC_ADDRESS or a reference to
> > the
> Table.
> >
> > High level - case points to an outgoing interface, ieee-mac address -
> >
> >  

Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

[Mach Chen]

Hi Alissa,

Thanks for your comments!

Please see my responses inline...

> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Alissa Cooper
> Sent: Tuesday, April 03, 2018 11:10 PM
> To: The IESG 
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-mo...@ietf.org; 
> i2rs-cha...@ietf.org;
> sha...@ndzh.com
> Subject: [i2rs] Alissa Cooper's No Objection on 
> draft-ietf-i2rs-rib-data-model-10:
> (with COMMENT)
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-i2rs-rib-data-model-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Sec 1.2:
> 
> "YANG tree diagrams provide a concise representation of a YANG module,
>and SHOULD be included to help readers understand YANG module
>structure."
> 
> This document does not seem like an appropriate place to have normative
> guidance about this. And if this sentence is removed, I don't see the point of
> including Section 1.2 otherwise. This would also imply deleting the reference 
> to
> I-D.ietf-netmod-yang-tree-diagrams.

This results from a YANG doctor review.  I saw it also occurs in other 
published documents. I personally think it's no harm to keep it, how do you 
think?

> 
> Sec 2.1: Again here I'm confused about the use of normative language. Why do
> you need to specify normative requirements for what this very document is
> specifying? Or are these supposed to be requirements on implementations?

OK, how about this:

"...a RIB data model needs to specify a way for an external entity to learn 
about the functional capabilities of a network device." And 

" The RIB data model needs a way to expose the nexthop chaining capability 
supported by a given network device."

> 
> Sec 2.5: s/causes/caused/

Done

The above updates will be reelected in version-11.

Thanks,
Mach
> 
> 
> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

[Mach Chen]

Hi Alvaro,

Thanks for the comments, please see my replies inline...

> -Original Message-
> From: Alvaro Retana [mailto:aretana.i...@gmail.com]
> Sent: Tuesday, April 03, 2018 3:15 PM
> To: The IESG 
> Cc: draft-ietf-i2rs-rib-data-mo...@ietf.org; Susan Hares ;
> i2rs-cha...@ietf.org; sha...@ndzh.com; i2rs@ietf.org
> Subject: Alvaro Retana's No Objection on draft-ietf-i2rs-rib-data-model-10:
> (with COMMENT)
> 
> Alvaro Retana has entered the following ballot position for
> draft-ietf-i2rs-rib-data-model-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
> 
> 
> 
> --
> COMMENT:
> --
> 
> (1) "This document defines a YANG data model for Routing Information Base
> (RIB) that aligns with the I2RS RIB information model."  That and the multiple
> references to the information model (in the text and on the e-mail archive)
> make it a required document to understand for the implementation of the data
> model.  draft-ietf-i2rs-rib-info-model should then be a Normative reference.

I am OK with it.

> 
> I am not making this point a DISCUSS because I think it is easy to solve: just
> move the reference.
> 
> (2) In Figure 1: s/route-reason-definition/route-change-reason-definition

Done.

> 
> (3) For completeness: in S2.3, the Reason attribute is missing (from S4 in 
> draft-
> ietf-i2rs-rib-info-model).
Add the following item:

"REASON - Indicates the specific reason that causes the failure, E.g.  Not 
authorized."

Hope this address your comments!

Thanks,
Mach
> 

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs