Common YANG Data Types for Traffic Engineering
draft-ietf-teas-yang-te-types-13

Note: This ballot was opened for revision 10 and is now closed.

Alvaro Retana No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-11-17)
Thank you for addressing my Discuss points!

Martin Vigoureux No Objection

Roman Danyliw No Objection

Comment (2019-08-21 for -10)
I concur with Ben Kaduk and Mirja Kühlewind comments about the utility of additional context for the model. 

Section 7.  Other models will import this one, and specific security considerations will have to be written for them.  Nevertheless, the general caution provided here could be a bit more specific perhaps on the order of:

-- Per “Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations”, doesn’t seem to adequately cover security/privacy issues such as misrouting of traffic for eavesdropping/inspection, circumventing existing defenses, modification or replay; and business operation issues such as increased transit bills due to inappropriate/malicious configuration.

-- Per “The access to such data nodes may be considered sensitive or vulnerable in some network environments” doesn’t explain the rationale such as that revealing detailed information about network configuration could exploited in future attacks.

Warren Kumari No Objection

Comment (2019-08-21 for -10)
No email
send info
I'm balloting NoObjection, but I do strongly support Benjamin's comment -- it's really very hard to understand how this will be used / understand the meaning of many of the types.

I do understand that much of this is because this is largely because of the nature of the document, but I think that the document would benefit from a large disclaimer / description explaining that this isn't something that can just be read and implemented from, and that it is instead a collection...

(Deborah Brungard; former steering group member) Yes

Yes ( for -10)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2019-08-21 for -10)
No email
send info
I did not review this document myself but I'm balloting based on the Gen-ART review.

(Barry Leiba; former steering group member) No Objection

No Objection (2019-08-21 for -10)
No email
send info
Ben has this covered quite well...

(Ignas Bagdonas; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2019-08-20 for -10)
Maybe it's just me but I think for this yang model I would have appreciated a little bit more intro text given some more context on how and when these models and types are used. 

Especially I would have appreciated more context what normality means and is used for. Not sure I fully understand normality. Can you maybe briefly explain what it is used for?

Also one more concrete comment on available-bandwidth and utilized-bandwidth (e.g. p. 47): you say that this is the measured bandwidth and later on you give an interval config value as well. However, I think it would be good to be more concrete. I believe you have in mind the _average_ value over the measurement interval, right? If so, maybe write it down like this in the description. Is there maybe a reference you can provide? Or maybe you can even point at some IPPM documents...?

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -10)
No email
send info