Skip to main content

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

Yes

(Deborah Brungard)

No Objection

(Adam Roach)
(Alexey Melnikov)
(Alvaro Retana)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)

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

Roman Danyliw
No Objection
Comment (2019-08-21 for -10) Sent
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) Not sent
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 IESG member
Yes
Yes (for -10) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2019-08-21 for -10) Not sent
I did not review this document myself but I'm balloting based on the Gen-ART review.
Alvaro Retana Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (2019-08-21 for -10) Not sent
Ben has this covered quite well...
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2019-11-17) Sent
Thank you for addressing my Discuss points!
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-08-20 for -10) Sent
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 IESG member
No Objection
No Objection (for -10) Not sent