Subject: [netmod] minutes of the NETMOD 2015-02-04 virtual interim meeting

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Feb 2015 17:54:35 +0100

Hi,

attached are the minutes of the 2015-02-04 virtual interim meeting.
Please let me know if something needs fixing.

You can find all the virtual interim meeting minutes next to the YANG
1.1 issue list in the NETMOD WG subversion repository:

     http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

/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/>

---

From: Phil Shafer <[email-masked]>
Date: Wed, 4 Feb 2015 14:32:27 -0500

Juergen Schoenwaelder writes:
>* Y34 remove/deprecate/replace the 'anyxml' statement
>
>  JS: Solution Y34-05
>	
>      Same as Y34-02 plus two guidelines adopted from Y34-04:
>	
>      - For YANG 1.0 backward compatibility, allow anyxml to be used,
>        except implementations MAY restrict the XML; document that
>        anyxml is not considered interoperable.
>      - The guidelines document should say that YANG Doctors will review
>        each use of anyxml in IETF modules when YANG 1.1 is adopted to
>        avoid its use whenever possible

Do we have a list of what makes anyxml not interoperable?  Can JSON
just encode this as a string?  Is the concern just namespace issues?
Can the JSON encoder be responsible for including any required xmlns
attributes with the contents?

>* Y57 non-unique leaf-list
>  BL: I will revise the proposal and post an updated solution to the
>      mailing list.

Okay, I'm completely biased in that I think non-unique leaf-list is
a mostly evil idea, but.....

A simpler fix might be added "position" as a value for "ordered-by".

    leaf-list bytes {
        ordered-by position;
    }

would also allow:

    list note {
        ordered-by position;
        choice note {
            leaf a { type empty; }
            ...
            leaf g { type empty; }
        }
        choice flat-or-sharp {
            leaf flat { type empty; }
            leaf sharp { type empty; }
        }
    }

Allowing:

    <note><b/><flat/></note>
    <note><c/></note>
    <note><a/><flat/></note>
    <note><a/><flat/></note>
    <note><e/><flat/></note>

(Yeah, long way to go for that, eh?)

But long term, this is still a horrible idea, since positions aren't
constant and require a "fetch before change" that isn't otherwise
vital.  It's setting clients up to trample on each other, which
affects stability and interoperability.

>* Y58 associate actions with a data node
>
>  JS to get final confirmation from NETCONF chairs, then try to close
>  the VRFY phase on the mailing list.

I'm still opposed to this, given that it's not needed.  Nothing can
be done with this feature that can't be done without it.

It's really the first step in attempting to turn YANG into an
object-oriented data modeling language, which it's not set up to
be.  And shouldn't be.  There's an ocean of OO facilities that we
don't have/need/want, including inheritance, polymorphism, interfaces,
etc.

There's a strong desire to keep extending a technology to allow it
to address all sorts of it wasn't designed for.  "Yeah we could do
that too if we just added this little bit".  The results are fairly
predictable; the simple little system turns into a complex, fragile
system.

Consider YAML, where 1.2 added more complex but useless features
that after five years, only one implementation (in Haskell) supports
it.  Or XSLT, where the 2.0 spec exploded with lots of features
that aren't used because only saxon implements them.

Addon features decrease interoperability, and impact the stability
and "done"-ness of our technologies.  I'm fine with fixing bugs,
clarifying the spec, and removing opportunities for errors, but
adding new features is imho a non-starter.

Sorry, that turned into a rant somewhere along the way, but, well....

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 4 Feb 2015 12:17:06 -0800

> affects stability and interoperability.

I am not convinced that the "ordered-by" statement is a good idea.
It does not map well across different APIs, such as CLI.
(e.g., ACE ordering in ACL discussion last year).

It is not likely that constrained devices will support an "insert"
operation. The ordered-by user option seems to require a lot
of added code to avoid using an explicit key leaf.

> predictable; the simple little system turns into a complex, fragile

It was never that simple to implement, but I agree that the language
should be expanded with caution.  This is clearly a new feature,
not a bugfix as required in the YANG 1.1 charter. But I believe Martin
when he says it is a very popular tail-f extension.

It does allow more granular access control, so it is not quite true
that we can do the exact same thing with rpc-stmt.  However, it
is not clear how to constrain the "instances" of a particular action
within a module.

Is /foo/bar/reset required to be exactly the same syntax and
behavior as /foo/baz/reset?  Is it good to have
this text (entire action-stmt) cut-and-paste all over the module?
Each one with slightly different (or way different) description-stmts?
This might be confusing to readers and unwarranted complexity
for developers.

> Sorry, that turned into a rant somewhere along the way, but, well....

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Feb 2015 10:31:15 +0100 (CET)

> > affects stability and interoperability.

+1

> behavior as /foo/baz/reset?

No; just like leafs /foo/bar/xxx and /foo/baz/xxx are not required to
be the same syntax and/or semantics.

> Is it good to have

Just like with data nodes, reusable actions can be put in a grouping
and resused insetad of copy&pasted.

> > adding new features is imho a non-starter.

There are certainly examples where the added features made a successor
fail, but there are also examples where that did not happen.  One such
example from the IETF is SMIv2.  But you are right that adding
features must be done carefully.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Feb 2015 15:00:42 +0100

Hi,

it would be helpful if people comment on different issues in separate
emails that have the issue number in the subject line. Concerning
anyxml, I have heard that implementations support different subsets of
XML as content below anyxml. If your concern is the JSON handling of
anyxml, then this belongs into a threat discussing the json mapping
document.

/js