The YANG 1.1 Data Modeling Language
RFC 7950

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

(Benoît Claise) Yes

Comment (2016-05-19 for -12)
No email
send info
The OPS-DIR comments need to be addressed before publication.

(Joel Jaeggli) Yes

Alexey Melnikov Yes

Comment (2016-05-19 for -12)
No email
send info
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).

(Jari Arkko) No Objection

Comment (2016-05-18 for -12)
No email
send info
Dale's Gen-ART review warrants a response.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

(Stephen Farrell) No Objection

Comment (2016-05-18 for -12)
No email
send info
- 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 No Objection

Comment (2016-05-19 for -12)
No email
send info
Thanks authors and Benoit for the clarifications on why this does not obsolete RFC6020.

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2016-05-18 for -12)
No email
send info
Following the discussion from Stephen's comments.

Alvaro Retana No Objection