Subject: [netmod] Comments on draft-lear-ietf-netmod-mud-02

From: Cullen Jennings <[email-masked]>
Date: Tue, 7 Jun 2016 15:57:47 -0600

I like how this is evolving ... few things 

Few small  things ....

If you use CMS, I think you need to deal with how the JSON in canonicalized before being signed. I will suggest that the standards the IETF created for signing JSON would be a better choice for signing JSON than CMS - that's how most other JSON based stuff does it. 

Putting the last updated and cache validity in the file may not be a good plan. More importantly putting it inside the stuff that is singed seems problematic. 

The "ietf-mud:direction"  stuff seems a bit under specified. Does from-device mean that if the device imitates the flow, responses to the flow also need to flow to the device? It seems like the ietf-netmod-acl-model draft might be a better place to specify this. 

Use of "ietf-mud" as prefix in the JSON for "ietf-mud:direction" is not how JSON typically does this. You don't need a namespace because we know this is a mud file thus know the namespace. A big reason some people moved from XML to JSON was exactly to get rid of namespace. 

It's not a great practice to put ":" in the names of json attributes because the way people use them in some languages often have them unquoted which you can't do if there is a : in the name. You can do it, but "-" or "_" might be better than ":" here. 

It would be great to have an simple example JSON file in the introduction instead of (as well as a complete example in section 6)

PS 

this as a PS because I view the odds of anything changing here to be about zero but from the peanut gallery ... The JSON for the MUD file is hideous. It's crap like this from the IETF that causes people to go no, thanks, I'll just made a standard on github with some open source. It as awful as Cisco's IOS CLI. Wait, it is the IOS CLI moved to have lots of angles brackets then translated to be JSON. If you were designing a JSON representation to describe the network flows of a device, this is not what it would be.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Jun 2016 12:07:13 +0200

Hi Cullen,

Generic answer to your message: please send text.  More specifics below.

> If you use CMS, I think you need to deal with how the JSON in canonicalized before being signed. I will suggest that the standards the IETF created for signing JSON would be a better choice for sig…

Within the bounds of widely available tooling I'm open to it, but would
need to be convinced.  I am somewhat comfortable with the CMS approach
in which what we are signing is a file – the fact that it is JSON in
incidental.  What I would want see is a tool that can sign a JSON object
and another one that can validate a signature through a chain of trust. 
In addition, there is a relationship between the signer of the MUD file
and, if 802.1AR is in play, the signer of that certificate that should –
somehow– be demonstrated.  Ptrs welcome.

> Putting the last updated and cache validity in the file may not be a good plan. More importantly putting it inside the stuff that is singed seems problematic. 
"Cache Validity" may be a misnomer here.  The intent is that because
there may be millions of Things out there in tens of thousands of
deployment, the manufacturers can hint at how long they do NOT wish to
hear from a requester.  View this as a minimum validity period, but by
no means a maximum.  Last-updated is just that, but I don't understand
your concern.

> The "ietf-mud:direction"  stuff seems a bit under specified. Does from-device mean that if the device imitates the flow, responses to the flow also need to flow to the device? It seems like the iet…

Personally I would be happy for it to go into the ACL model, if that is
netmod's wish.  The only issue with that, and it is not a big issue, is
that we chose terminology that was slightly mud-oriented so as to avoid
confusion as to what "in" and "out" might mean.  This can also be
included as a separate augmentation in a separate module if people think
that's appropriate but it is necessary for MUD, and so that's why it is
where it is at the moment.  Again, happy to go with other approaches so
long as the WG is okay with them.

> Use of "ietf-mud" as prefix in the JSON for "ietf-mud:direction" is not how JSON typically does this. You don't need a namespace because we know this is a mud file thus know the namespace. A big re…

What's in there is what validates against pyang and yang2xml.  No
namespace is assumed on the outside, but rather the outer is ACL, and
then on use where inner comes in, you need to name the namespace, or the
tools will assume that MUD is invalid, as I understand it.  Again, I am
not a YANG expert.  If the YANG people tell me I'm off base, I'd be
happy to fix what's there.

> It's not a great practice to put ":" in the names of json attributes because the way people use them in some languages often have them unquoted which you can't do if there is a : in the name. You c…

I'm concerned about tool breakage as well, then.  However, this is how
things are specified in draft-ietf-netmod-yang-json-10.  We would need
to revisit that there, and I'm happy with whatever outcome of that
discussion would be.

> It would be great to have an simple example JSON file in the introduction instead of (as well as a complete example in section 6)

Good idea.

Eliot