Re: [Anima] Iotdir telechat review of draft-ietf-anima-bootstrapping-keyinfra-17

[Russ Housley <[e-mail]>]

>> Section 3.1 shows the YANG tree model of the Voucher-Request.  I am far
>> from a YANG expert, but I expected a subsequent section to describe the
>> semantics of each field.  The examples in Section 3.2 are useful, but
>> they are not a replacement.  Some fields (like voucher/expires-on) are
>> not described in Section 3.3.  I assume that this is building on another
>> module because this one contains "import ietf-voucher", but this does
>> not say what RFC contains the imported module to learn the rest of the
>> semantics.
> 
> I think that the sentence:
>  The notation used in this diagram is described in [RFC8366].
> 
> should be changed to say:
>   The voucher-request builds upon
>   the voucher artifact described in <xref target="RFC8366" />.
>   The tree diagram is described in <xref target="RFC8340" />.
> 
> (we described tree-diagrams in 8366 at one point, because we didn't know if
> 8340 would get published in time)

Okay.  That works for me.

> 
>> I think that the CDDL in Sections 4.1.1 and 4.3 are supposed to be
>> structures.  If that is correct, the structure should look something
>> like the following, which includes type information:
>> 
>>   basic-header = [
>>     field1: int,
>>     field2: text,
>>   ]
>> 
>>   advanced-header = [
>>     ~basic-header,
>>     field3: bytes,
>>     field4: ~time,
>>   ]
> 
> We are filling in the gaps for the definition in GRASP M_FLOOD
> mechanism.  We aren't defining a new structure.
> I'm not sure if we can do this any other way.

Something needs to be done to set the context.  Clearly, I misunderstood the intent.

>> I have no idea what the boxes in Figure 10 represent.
> 
> Hmm. I guess we chopped the boxes off of the flow from section 2.4.
> Would a reference back to section 2.4 help?
> Maybe we should not repeat the boxes.

I reference to Section 2.4 with no boxes would be more helpful than the current figure.

>> Section 7.2 does not contain enough information to make the needed
>> object identifier assignments.
> 
> Right we had a note to fix that. It's: SMI Security for PKIX Certificate Extension
>  https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1.3.6.1.5.5.7.1

I guessed that, but no guessing should be needed for IANA registry assignment.

Russ