Re: [Anima] Michael: IANA request for GRASP registry missing from BRSKI text

[Toerless Eckert <[e-mail]>]

Kiding aside: Who needs to take which action now ? 

On Fri, Nov 06, 2020 at 04:15:21PM -0500, Michael Richardson wrote:
> 
> Toerless Eckert <[e-mail]> wrote:
>     > Am i completeley confused, or did we miss until now the IANA request in BRSKI for
>     > the new entries AN_Proxy and AN_join_registrar ?
> 
> I dunno what happened.
> But, you are exactly right.
> Who to blame? when in doubt? clearly, BLAME CANADA.
> 
> It wasn't until my third reading of:
>   grasp-15, section 6, https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-15#section-6
> 
> that I saw that GRASP actually does create a _GRASP Objective Names Tables_.
> I was going to complain that there was no registry created, but it just
> didn't have it's own heading:
> 
>    GRASP Objective Names Table.  The values in this table are UTF-8
>    strings which MUST NOT include a colon (":"), according to
>    Section 2.10.1.  Future values MUST be assigned using the
>    Specification Required policy defined by [RFC8126].
> 
>    To assist expert review of a new objective, the specification should
>    include a precise description of the format of the new objective,
>    with sufficient explanation of its semantics to allow independent
>    implementations.  See Section 2.10.3 for more details.  If the new
>    objective is similar in name or purpose to a previously registered
>    objective, the specification should explain why a new objective is
>    justified.
> 
>     > I was just checking IANA actions for ACP and did not see these two in the GRASP
>     > registry:
> 
>     > https://www.ietf.org/archive/id/draft-ietf-anima-bootstrapping-keyinfra-44.txt
> 
>     > Not sure about the process, e.g.: if "specification required" (GRASP registry)
>     > mandates the IANA text in the BRSKI RFC... I fear it does ? If three is an easier
>     > way as having Warren approve another rev... ?
> 
> I think that the text has to go in.
> Warren needs to approve the change, and IANA needs to review, and then the
> text needs to go in now or at AUTH48, depending upon where the RPC really is.
> 
> I have version -45 ready to post, diffs are at:
> 
> I think that this is non-constroversial, does not require a WG LC, and can
> slide in at AUTH48, but as it required IANA review, it's better if it happens
> sooner.
> 
> It looks like the YANG is now 2-3 characters too long in places, so I've also
> rewrapped that.  The base64 in the examples will also need to be reflowed
> ick.
> 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-44&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/master/dtbootstrap-anima-keyinfra.txt
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 



-- 
---
[e-mail]