The YANG 1.1 Data Modeling Language
RFC 7950
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
Alvaro Retana No Objection
(Alexey Melnikov; former steering group member) Yes
I reviewed YANG 1.0 in 2010. I am glad to see YANG 1.1 in IESG review! I think this version is an improvement.
Nit:
9.12.4. Usage Example
The following is a union of an int32 an enumeration:
Typo: int32 *and* enumeration
In response to Suresh:
Section 9.4.7:
It is not clear why the following refinement is illegal. Can you clarify?
type my-base-str-type {
// illegal length refinement
length "1..999";
}
refinements must be more restrictive, 999 > 255 (the original length limit).
(Benoît Claise; former steering group member) Yes
The OPS-DIR comments need to be addressed before publication.
(Joel Jaeggli; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
Dale's Gen-ART review warrants a response.
(Kathleen Moriarty; former steering group member) No Objection
Following the discussion from Stephen's comments.
(Mirja Kühlewind; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- I'm not sure I properly understand what the rpc and action statements really do, but can an action statement result in sensitive information being in a place in the model that previously only contained non-sensitive information? If so, does that warrant a mention in the security considerations, like the existing one about RPCs? (I mean the 3rd para of section 17.) - anydata (section 7.10) is new, right? Doesn't that mean that new kinds of stuff (that might be dangerous) can be found in a module? So if it's true that before yang 1.1 a parser only had to be careful to parse XML correctly, and if the addition of anydata means that a parser (via some extension mechanism) might now be parsing say images, (say via ImageMagick:-) then that'd likely create new potential vulnerabilities and might be worth a mention in section 17.
(Suresh Krishnan; former steering group member) No Objection
Thanks authors and Benoit for the clarifications on why this does not obsolete RFC6020.
(Terry Manderson; former steering group member) No Objection