>> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP
