Thank you for the comments. I will post -33 with these changes on Sunday. https://github.com/anima-wg/voucher/commit/b3ade9faa824170e1d57413562a5352347975303
Amanda Baber via RT <[email protected]> wrote: > Section 12.2: > Unlike other registries (like the XML "ns" registry), YANG Module Names > has us keep older registrations in place when RFCs are obsoleted, and > instead create a new registration (with the appropriate date). The > lines that tell us to update YANG module references and “file” fields > need to be removed. okay, deleted those sentences. > Section 12.5: > 1) Which registry group does “Voucher Extensions” belong in? Uhm... I feel like it should *ALL* go under: _Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters_ > 2) Unless there’s a reason it needs to be kept, we have a strong > preference for removing “Registry” from registry names. (Because all > registry names could end with the word “Registry,” we’d rather use it > in all of them or none of them, and most registry names don’t include > it. Exceptions include HTTP registries that use “Registry” in the name > in an effort to differentiate the official registry from unofficial > lists elsewhere on the internet.) sure. Do we keep it for the title of the section, or not? So I can/should write: in the IETF YANG-SID Modules registry understanding that it's the _IETF YANG-SID Modules_ (registry) and, I coud write: Items within that list are either strings (in JSON serialization), or integers (in CBOR serialization using SIDs); both are always defined in the entries of the Voucher Extensions registry (see {{voucher-ext-reg}}). (now, "registry" instead of "Registry" > 3) The list of fields that describe the registry (name, registration > procedure) seems to have merged with the list of fields that make up > the registry. Do you want “Reference” to be the first field in the > registry? It took awhile to understand what you were saying. I've changed things to say: IANA is asked to create a registry of Voucher extensions within the _Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters_ as follows. The name is: Voucher Extensions, and the Registration Policy is Expert Review. > {:compact} > Reference: > : an optional document > > Extension name: > : UTF-8-encoded string, not to exceed 40 characters. > > Extension SID: > : the YANG module SID value that defines the extension per {{voucher-ext}}. > 4) The early allocation procedure in RFC 7120 (registrations marked > "temporary," renewed annually) isn’t available for Expert Review > registries. Permanent allocations are available at any time to anyone > if the expert approves, but the line referring to RFC 7120 needs to be > removed unless you want to change the procedure to Specification > Required (and even then, it would apply only to registrations in > IETF-stream I-Ds) or require an RFC. I have removed hte 7120 reference. Perhaps I've made it too complex. It's enough to just tell the Designated Expert this rule. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
