Subject: [Anima] naming of constrained voucher YANG model

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Jun 2018 11:10:57 -0400

Michael Richardson <[email-masked]> wrote:
    > Also, a related question is whether ietf-cwt-voucher-request to inherit
    > from BRSKI's ietf-voucher-request, or from ietf-voucher... It's not
    > clear to me that it's a 100% subclass yet.

So, the name started at "cwt-voucher-request", because it was originally
thought that it would use CWT directly (RFC8392), using the Claim keys from
there.

Then after some distraction, the process is now a COSE signed SID generated
YANG, which isn't exactly CWT at all.

The name "cwt-voucher"{,-request} is no longer appropriate.
Some constraction of "constrained" is probably now appropriate, looking for
suggestions.  

It's also reasonable to say that we use CWT concepts when they map, and
introduce new key ids via the YANG/SID mechanism.  That's a significant
design change, but it's not that huge.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 1 Jun 2018 15:29:01 +0000

what is wrong with going simple: “constrained voucher request” ? 

- max

> On Jun 1, 2018, at 9:10 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Jun 2018 19:43:05 +0000

[CC-ing Joe and Benoit who are closer to this than I am]

The only official source is the RFC, on which folks are expected to use a module extraction tool [1].

For a while there, YangModels [2] had a following, but it doesn't seem to have the last voucher module in its DB, so I'm guessing its `cron` job is stuck or something.

YangCatalog is a more recent entrant.  It actually does have the latest module version in its DB [3], so there appears to be some other issue causing the stale DataTracker link.

Regardless how the modules are obtained, I always find myself needing to make local copies of them to satisfy tooling.  Is your idea to use `wget` in the draft's build scripts to do a just-in-time fetch?

[1] https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.11
[2] https://github.com/YangModels
[3] https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-voucher

Kent

===== original message =====

Now that RFC8366 is published, BRSKI should be importing the module from an
official source, rather than from ../voucher as I do now on my computer.

As far as I can understand, includes seem to come from the pyang source tree,
in modules/ietf, and if you want new modules, you have to get a new pyang,
and so we should send a pull request against the pyang source.

However, we also have the yangcatalog.org, and maybe the makefile in
BRSKI should wget something, but I'm unclear what exactly I should wget!

Also, https://datatracker.ietf.org/doc/rfc8366/ has a link for:
      Yang catalog entry for [email-masked]
pointing at the entry for 2017-10-25, while the RFC has 2018-05-09,
and in fact, there is an entry at:
  https://www.yangcatalog.org/yang-search/module_details.php?module=[email-masked]

I feel that I'm missing a place to wget the modules from.

====

Also, a related question is whether ietf-cwt-voucher-request to inherit from BRSKI's
ietf-voucher-request, or from ietf-voucher... It's not clear to me that
it's a 100% subclass yet.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Jun 2018 17:46:16 -0400

Kent Watsen <[email-masked]> wrote:
    > Regardless how the modules are obtained, I always find myself needing
    > to make local copies of them to satisfy tooling.  Is your idea to use
    > `wget` in the draft's build scripts to do a just-in-time fetch?

yeah... just looking for some option to wget to grab if newer, but i see
nothing that uses ETAG or something.

I guess
  [ -f  [email-masked] ] || wget ...
  
would work. (but, obviously, with the correct version)

For now, I've just commited the above file into BRSKI so that the travis-ci works.

---

From: Joe Clarke <[email-masked]>
Date: Sat, 2 Jun 2018 11:52:58 -0400

> [3] https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-voucher

Like you said, part of the Yang Catalog automation is to take the
modules from RFCs (and drafts) and extract them to the YangModels GH
repo.  Unfortunately, there are some issues with that piece of the
automation.

We're in the process of getting support from ISOC to continue the
development around Yang Catalog, so in near future, you should see
YangModels more up to date.  I think in the meantime, Benoit has been
doing some point updates with extracted YANG modules.

Joe

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Jun 2018 18:42:23 -0400

> [2] https://github.com/YangModels

okay, so at this point, my I think that pulls from YangModels github
(directly, or wget'ing the rawusercontent file...) is the simplest.

Kent, doeds 8366 replace:
   https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-zerotouch-ownership-voucher.yang
??

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Benoit Claise <[email-masked]>
Date: Sun, 3 Jun 2018 06:24:11 +0200

Hi,

Yes, cron jobs inserted the YANG module (out of the RFC) in the yangcatalog.
However, it's still a manual process to insert your YANG module (out of 
a fresh RFC) in 
https://github.com/YangModels/yang/tree/master/standard/ietf/RFC
I'm (still) shooting for IANA to be the repository in the future. From 
there, it will be trivial.

Regards, Benoit

---

From: Peter van der Stok <[email-masked]>
Date: Sun, 03 Jun 2018 16:15:00 +0200

constrained-voucher(-request) seems reasonable to me

Peter
Max Pritikin (pritikin) schreef op 2018-06-01 17:29:

> what is wrong with going simple: "constrained voucher request" ? 
> 
> - max
> 
> Michael Richardson <[email-masked]> wrote: Also, a related question is whether ietf-cwt-voucher-request to inherit

---

From: Kent Watsen <[email-masked]>
Date: Mon, 4 Jun 2018 14:11:16 +0000

[moving anima list to BCC]

> (directly, or wget'ing the rawusercontent file...) is the simplest.

seems sensible.

>   https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT\
>   /ietf-zerotouch-ownership-voucher.yang
> ??

Yes.  That module is a stale holdover from back before when we moved the voucher module into its own draft, and moved that draft to the ANIMA WG.

Joe/Benoit, maybe the scripts could somehow track modules extracted from I-Ds (not RFCs) to see when old modules go away, and then delete those old modules?   

Consider this history:
  zerotouch-08 (April 2016) is the last draft to define ietf-zerotouch-ownership-voucher
  zerotouch-09 (July 2016) renamed the module to "example-zerotouch-ownership-voucher"
  zerotouch-10 (October 2016) no longer had the module at all
  draft-kwatsen-netconf-voucher-00 (October 2016) is when "ietf-voucher" began
  draft-kwatsen-anima-voucher-00 (December 2016) replaced draft-kwatsen-netconf-voucher
  draft-ietf-anima-voucher-00 (January 2017) replaced draft-kwatsen-anima-voucher
  RFC 8366 (May 2018) replaced draft-ietf-anima-voucher

Kent

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Jun 2018 13:58:25 -0400

Toerless Eckert <[email-masked]> wrote:
    > I've always found reverse order naming better for browsing hierarchically
    > related items. Not sure if there is any current common practice about
    > this in Yang models. Probably not...

I've renamed it to ietf-constrained-voucher{,-request} a day or so ago.

I hear your suggestion for ietf-voucher-constrained{,-request}, and
unless there is a groundswell against that, another rename will occur.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 5 Jun 2018 21:29:46 +0200

Thanks, Richardson, Michael.

Just remembered we had early yang docotr review, so posted question
of best current practices for naming on that thread.

Cheers
    Toerless

-- 
---
[email-masked]