Subject: [netmod] yang 1.1 status summary (pre IETF 92)

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Mar 2015 12:00:59 +0100

Hi,

here is where we are with the YANG 1.1 effort right before the start
of IETF 92:

  | Status | Description                            | Count |
  |--------+----------------------------------------+-------|
  | NEW    | new issue                              |     1 |
  | DEAD   | issue has been rejected                |    26 |
  | OPEN   | open to discuss                        |     3 |
  | VRFY   | proposal to verify on the list         |     2 |
  | EDIT   | waiting for Martin to do the edits     |     3 |
  | REVIEW | waiting for the WG to review the edits |    25 |
  | DONE   | review has completed                   |     0 |
  |--------+----------------------------------------+-------|

Here is the list of issues that we should resolve during the IETF-92
meeting. Ideally, we leave Dallas will no issues left in NEW or OPEN
state.

* VRFY :Y34: remove/deprecate/replace the 'anyxml' statement

  The first question is whether we want to support alternate encodings
  (JSON/CBOR). If so, we need to have a mechanism that can handle any
  data that can be defined in YANG and that can be encoded in and
  interoperable way in all encodings without having to resort to an
  XML parser. It seems Y34-05 is the obvious answer if we want to
  support alternate encodings and people on the last virtual interim
  meeting seemed to be fine with it.

* VRFY :Y45: better conformance mechanism

  It seems Y45-02 is the best solution we could find so far and people
  on the last virtual interim meeting seemed to be fine with it. There
  are two corner cases to think about, namely enumerations and bits,
  where Y45-02 would be stricter than SMIv2 (and hence RFC 6643 would
  not easily work with YANG 1.1). Need to discuss what to do about it
  (e.g., whether we treat enums and bits similar to identities where
  the type also does not give you the precise value set).

* OPEN :Y26: allow mandatory nodes in augment

  This is waiting for someone to draft text to relax the current rules
  in situations where this is safe.

* OPEN :Y36: associate a notification with a data node

  This was reopened as a consequence of adopting Y58-02. This is
  waiting for someone to draft concrete proposal text.

* OPEN :Y57: non-unique leaf-list

  This has seen several revisions and discussions on the mailing
  list. The latest solution proposal is Y57-03.

* NEW :Y60: coexistence with YANG 1.0

  This was added during the discussions and it is right now a place
  holder to collect things we need discuss in a YANG 1.0 / YANG 1.1
  coexistence section. This should be moved to OPEN and we should work
  out what this section needs to cover.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>