That expert assignment is probably a case of https://en.wiktionary.org/wiki/shanghai
On Sat, Nov 07, 2020 at 11:33:41AM +1300, Brian E Carpenter wrote: > Yes, the registry has been there for some time: > https://www.iana.org/assignments/grasp-parameters/grasp-parameters.xhtml#objective-names > and guess who is the expert? > > Regards > Brian > > On 07-Nov-20 10:15, Michael Richardson wrote: > > > > Toerless Eckert <[email protected]> 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 > > [ > > ] [email protected] http://www.sandelman.ca/ | ruby on rails > > [ > > > > > > > > > > > > > > > > -- > > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > > > > > > > > _______________________________________________ > > Anima mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/anima > > -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
