Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Jul 2021 18:13:25 -0400

Hi, I have converted RFC8366.xml to Markdown, and switched to the latest MT
makefile, and after a bit of small massage to remove "8366" from the page,
and point to RFCs which are published, the result is at:

https://www.ietf.org/rfcdiff?url1=rfc8366&url2=draft-richardson-anima-rfc8366bis.txt

Rob Wilton (rwilton) <[email-masked]> wrote:
    Rob> More seriously though, this can't be done as an errata.

    Rob> An RFC8366bis is the right option.  If the changes are minor then I
    Rob> may be able to ease the passage through the IESG, but I can't do
    Rob> much to affect the elapsed time.

I propose that the WG adopt this as the -00, and then we change the document
to change this into an RFC7224-style IANA-maintained YANG module.
(In DHC WG, when we did RFC3315bis to make RFC8415 we did a -00 which was
whitespace equivalent to RFC3315 first, and then we amended it)

As I understand it, we would be creating a Registry with IANA Considerations,
and when documents extend the Registry, that IANA writes a new YANG module
(with a new date) for us.

I believe that given that the module gets revised, that we don't have to
worry about enumeration vs leaf/choice/empty.  But, if there is some
advantage to doing it the non-enumeration way, it would be good to understand
that.

I also think that in our enumeration/Registry, that we should include the
"value" parameter, so that constrained-voucher can consistently set values
even if the enumeration changes order.

Subject: New Version Notification for draft-richardson-anima-rfc8366bis-00.txt
Date: Sun, 04 Jul 2021 15:03:18 -0700

A new version of I-D, draft-richardson-anima-rfc8366bis-00.txt
has been successfully submitted by Michael C. Richardson and posted to the
IETF repository.

Name:		draft-richardson-anima-rfc8366bis
Revision:	00
Title:		A Voucher Artifact for Bootstrapping Protocols
Document date:	2021-07-04
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/archive/id/draft-richardson-anima-rfc8366bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/
Html:           https://www.ietf.org/archive/id/draft-richardson-anima-rfc8366bis-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-richardson-anima-rfc8366bis

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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Jul 2021 18:17:18 -0400

Fries, Steffen <[email-masked]> wrote:
    >> I thought I wrote a really nice ASCII art version of what documents inherit from
    >> RFC8366.  I can't find it in my outbox... I wonder if I nuked the draft by mistake.
    >>
    >> The short of it:
    >> RFC8366 -> RFC8995 (voucher-request)
    -> constrained-voucher (voucher-request, voucher)
    -> brski-async-enroll (voucher-request)

    > Would it make sense to also state the voucher for BRSKI-AE as it also
    > uses the voucher and tries to argue for a new assertion type
    > (agent-proximity)?

I am of two feelings here.
On the one hand, it would be IANA proceedurally simpler to include the new
assertion type into the 8366bis document.

On the other hand, this means having some kind of explanation in RFC8366bis
for the new choice, and that might force a lot of text to enter and get reviewed.

Once RFC8366bis is published, then async-enroll can make use of the IANA
Considerations to allocate that new enum value.  That won't slow async-enroll
down, because either way, it has to wait for RFC8366bis.

Where I'm a bit blurry is how stuff like the YANG in RFC8995, which uses
RFC8366 gets updated when IANA revises the module.  I think, it mostly
doesn't matter because none of are generating code from YANG... AT THIS TIME.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Jul 2021 19:21:01 -0400

> advantage to doing it the non-enumeration way, it would be good to understand

But, we might want to do a WG Consensus call on the differences.
We might also want to ask a YANG Doctor to come to the ANIMA WG meeting
at the end of the Month, to explain the differences.

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 5 Jul 2021 09:37:57 +0000

> From: Michael Richardson <[email-masked]>
> Sent: Montag, 5. Juli 2021 00:17
Yes true. Having the option doing it via an IANA considerations will be simpler for other drafts like async-enroll extending the assertions in the voucher. 

> RFC8366 gets updated when IANA revises the module.  I think, it mostly doesn't
> matter because none of are generating code from YANG... AT THIS TIME.
> 
> --

---

From: tom petch <[email-masked]>
Date: Mon, 5 Jul 2021 11:52:34 +0000

From: netmod <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Sent: 05 July 2021 00:21

<tp>
I would love to know what the problem is (rather than possible solutions to potential problems:-)

enum and identity are solutions with different characteristics as others have spelt out.  Which is better depends on the problem, how easy it should be to make changes or to prevent people from  making changes:-)

Likewise involving IANA.  They maintain registries which anyone can access.  They perform updates, on request, according to the policy of the registry, which is set when the registry is set up and can range from requiring a Standards Track RFC to First Come First Served, depending on how easy you want it to be to make changes.  See 'IANA Considerations' RFC for the range of options.  And they can turn updates to a registry into an update to a code module (such as an SMI MIB). 

So the IANA Considerations section in an RFC creates the registry but what it takes to  update it varies depending on what they say.

What I am missing is how easy or difficult you want it to be to make changes, who will make changes, (IETF only, another SDO, a manufacturer ....), what review you want for changes by whom, how frequent changes will be (usually a guess and usually wrong but it helps to have the assumptions about the requirements spelt out) and such like.

As an engineer, I do like to know the requirements before working on the design!

Tom Petch

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Jul 2021 11:17:54 -0400

tp> Likewise involving IANA.  They maintain registries which anyone can
    tp> access.  They perform updates, on request, according to the policy of
    tp> the registry, which is set when the registry is set up and can range
    tp> from requiring a Standards Track RFC to First Come First Served,
    tp> depending on how easy you want it to be to make changes.  See 'IANA
    tp> Considerations' RFC for the range of options.  And they can turn
    tp> updates to a registry into an update to a code module (such as an SMI
    tp> MIB).

Probably Standards Track RFC to update the voucher types.

    tp> What I am missing is how easy or difficult you want it to be to make
    tp> changes, who will make changes, (IETF only, another SDO, a manufacturer
    tp> ....), what review you want for changes by whom, how frequent changes
    tp> will be (usually a guess and usually wrong but it helps to have the
    tp> assumptions about the requirements spelt out) and such like.

    tp> As an engineer, I do like to know the requirements before working on the design!

We need to be able to write RFCs that extend the voucher types.
Not that often though.