[core] CORE-SID and SX:structure and draft-ietf-anima-rfc8366bis-01.txt

[Michael Richardson <[e-mail]>]

TL;DR> we can not use augment to get the behaviour that we want of being to
       extend existing YANG modules with new attributes.  We have to revise
       8366 each time we want extend things.  This email details the work to
       make that occur.

[e-mail] wrote:
    > Title           : A Voucher Artifact for Bootstrapping Protocols
    > Authors         : Kent Watsen

    > A diff from the previous version is available at:
    > https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-rfc8366bis-01

* I have revised the ietf-voucher YANG module to use sx:structure (RFC8971)
  rather than YANG-DATA (RFC8040).  I seem to have missed doing this for
  voucher-request, which I'll fix in the next revision.

* I have worked on pyang so that it will produce SID values for the
  sx:structure extension. The pull request is at:
  https://github.com/mbj4668/pyang/pull/839
  As I suspected, it was about five lines of changes.
  I have some test cases for pyang for this, but I'm struggling to get
  pyang's "make test" to finish period.

* It seems that the assignment of SID values between YANG-DATA and
  sx:structure is consistent, which is really good.

* As discussed at some of the design team meetings, and I think at IETF115, I
  have merged into the rfc8366bis the ietf-voucher-request content from RFC8995.

* yes, there seem to be duplicate SID values for ietf-voucher-request, and
  I'll sort that out, now that I notice I didn't update it to sx:structure.
  That will be -02.

* I will merge in the changes to ietf-voucher and ietf-voucher-request from
  draft-ietf-anima-constrained-voucher.  At which point, the document title
  will *really really* be wrong, since it won't even contain the voucher,
  just constrained-BRSKI.  But, we fixed the title awhile ago.
  I propose to do this in -03, so one can see a clear progression of changes.

* I will merge in the changes from PRM in -04.

* Since we have to revise rfc8366bis whenever we want to extend or amend the
  YANG module, there seems to be no point in having the
  iana-voucher-assertion-type submodule.  I propose to remove that, and just
  leave it all as a flat enumeration.

* I don't think we can attempt to get to Internet Standard with this
  document.  There will be, I think, too many changes which have not gone through
  interoperability tests.  Perhaps in two years, this could occur via IESG Action.

* The document will need a significant re-edit, and I would ask everyone to
  please read it with the view to: what should we omit, or just reference
  RFC8366, and what do we need to revise given the additional pieces that are
  being merged in.

One thought is that we change our mind about making this a Obsoletes, and
go back to making this document an Updates:, but I am still stting on the
fence for this.






--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide