Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00

[Andy Bierman <[e-mail]>]

On Mon, Sep 4, 2017 at 12:29 AM, Martin Bjorklund <[e-mail]> wrote:

> Andy Bierman <[e-mail]> wrote:
> > On Fri, Sep 1, 2017 at 10:43 AM, Kent Watsen <[e-mail]>
> wrote:
>
> [Re: moving the definition of rc:yang-data to a new document]
>
> > >
> > > > We went through that issue at least twice before RFC 8040.
> > >
> > > > There was no concern about this extension being in the RESTCONF spec.
> > >
> > >
> > >
> > > I don't think people understood what was at stake at the time -
> yang-data
> > > has since taken on more prominence.    You write "no concern", but I
> think
> > > it was more like "no response", and the solution just rolled on.
> > >
> >
> > I think I explained it well enough at the time.
> > There is a normative reference to RESTCONF to use yang-data.
> > This is just an RFC detail. In a server, the yang-library can indicate
> > that ietf-restconf is just imported (not implemented). It really does not
> > matter
> > that this extension is in ietf-restconf.yang.
> >
> >
> >
> > >
> > >
> > >
> > >
> > > > We really have to try to keep the documents stable, and not
> republish an
> > > RFC
> > >
> > > > just to move definitions around.
> > >
> > >
> > >
> > > We are talking about a new RFC (this draft).  I don't care if 8040 ever
> > > uses the new yang-data statement, it can forever have its own private
> > > definition.  I do care that we introduce a long-term solution (again,
> > > augment alone seems limited) and would like to make an incremental
> > > improvement for normative references.
> > >
> > >
> > >
> >
> > IMO it is not worth the trouble.
>
> If it wasn't for the new 'augment-yang-data' statement, I'd agree.
>
> But if we're doing a new standalone document for 'augment-yang-data',
> I think we should also define 'yang-data' in that document.  The cost
> is minimal, and we get one self-contained document with all things
> related to 'yang-data'.
>
>
So you are saying I was right 2 years ago when I brought this issue up
repeatedly?  ;-)
I don't agree that moving YANG definitions around for minor reasons is
helpful.
The larger YANG community (outside the IETF) are not asking for the
foundation
to be constantly replaced. They are not appreciative of constant churn in
the standards.

It seems we have already reached a point where we understand that modules
are cheap.
In some cases a new module does not even cost the length of a namespace
string in a packet.
We should learn to use YANG modularity, because it is almost free.  The
cost of high coupling
and low cohesion is much worse that the cost of splitting up YANG modules
at the start.




> /martin
>

Andy