Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT)

[Russ Housley <[e-mail]>]

Ben:

Responding to just one comment in this message ...

>>>               TaggedContentInfo and it includes a bodyPartID element
>>>               and a contentInfo.  The contentInfo is a SignedData
>>>               encapsulating a PKIData with one reqSequence element
>>>               and no cmsSequence or otherMsgSequence elements. The
>>>               reqSequence is the TaggedRequest and it is the tcr
>>>               CHOICE. The tcr is the TaggedCertificationRequest and
>>>               it a bodyPartId and the certificateRequest elements.
>>>               [...]
>>> 
>>> ... since this reqSequence seems to refer to the PKIData inside the
>>> SignedData in the contentInfo in the cmsSequence.  Should we say
>>> anything about the presence/absence of reqSequence in the toplevel
>>> PKIData (since we do in the other two cases)?
>> 
>> Yes, the authors propose:
>> 
>> OLD: […]
>> 
>> NEW:   PKIData contains one cmsSequence element and no
>>            controlSequence, reqSequence, or otherMsgSequence
>>            elements. […]
>> 
>> 
>> Good?
> 
> I don't think we mention controlSequence anywhere else at present (though
> it is mentioned in the "NEW" text above).  I don't think the omission
> seemed noteworthy when I was doing my original review, so my primary
> consideration here is just that we give it consistent treatment everywhere
> (in terms of whether or not we mention it).

When looking at the text to address your comment, I could see not a role for controlSequence in this situation; however, I think there might possibly be a role in some of the other places.  For that reason, I thik it should be allowable in other places.  That is, the text should not exclude it.  If for consistency, you would rather not exclude controlSequence anywhere, I am fine with that too.

Russ