Re: [Anima] naming of constrained voucher YANG model
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
On Tue, Jun 05, 2018 at 01:58:25PM -0400, Michael Richardson wrote:
>
> Toerless Eckert 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.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks
> [
> ] Michael Richardson, Sandelman Software Works| network architect
> [
> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
> [
>
--
---
t...@cs.fau.de
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] naming of constrained voucher YANG model
Toerless Eckert 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.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] naming of constrained voucher YANG model
what is wrong with going simple: “constrained voucher request” ?
- max
> On Jun 1, 2018, at 9:10 AM, Michael Richardson wrote:
>
>
> Michael Richardson 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
> [
> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
> [
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
