Re: [netmod] Stephen Farrell's No Objection on draft-ietf-netmod-yang-json-09: (with COMMENT)

On Tue, Mar 22, 2016 at 9:23 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Mar 22, 2016 at 05:12:24PM +0100, Eliot Lear wrote:
> > Hi Juergen,
> >
> > On 3/22/16 4:42 PM, Juergen Schoenwaelder wrote:
> > > I think such considerations belongs into documents making use of
> > > object signatures and close to 100% of the YANG models today don't
> > > so I do not even think this qualifies for RFC6087bis.
> > >
> >
> > I think there are AT LEAST two areas where signatures are going to be
> > necessary:
> >
> >   * There exist multi-level authorization schemes today that rely on
> >     signatures.  Those have to be transported.
> >   * Manufacturer usage descriptions (MUDs) have extremely broad scope in
> >     terms of the number of devices that are intended to use the same
> >     description (think thousands to millions).  And so an unauthorized
> >     change could have a similarly broad impact.
> >
> >
> > Thus, wherever the YANG experts think signatures should happen in each
> > encoding case is fine with me; but I'd suggest that I'm not the only
> > person who's going to want to know.  Is it THAT hard to at least add a
> > reference?  Because if it is, that would cause me to wonder if the
> > mechanisms are really in place to do the right thing.
> >
>
> Eliot,
>
> I simply fail to understand what the problem is and I fail to see
> which addition (ideally in concrete words) is proposed to fix the
> problem.
>
>

This seems like a protocol issue, not a data modeling issue.
NETCONF and RESTCONF both have very strict security requirements
to protect the instance documents which are intended to conform to YANG
schema.

> /js
>

Andy

>
> --
> 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/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>