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

Kent:

I like NEW, but I can live with either one.

Russ

> On Jan 21, 2022, at 6:44 AM, Kent Watsen <kent+ietf@watsen.net> wrote:
> 
> [top-posting for clarity]
> 
> Russ and Ben,
> 
> Picking up on this thread, it looks like a coin-flip to me.  Should we have:
> 
> NEW:   PKIData contains one cmsSequence element and no
>          controlSequence, reqSequence, or otherMsgSequence
>          elements. […]
> 
> NEWER:   PKIData contains one cmsSequence element and no
>          reqSequence or otherMsgSequence elements. […]
> 
> Or something else?
> 
> Thanks,
> Kent
> 
> 
> 
>> On Dec 24, 2021, at 10:22 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>> 
>> Hi Russ,
>> 
>> On Thu, Dec 23, 2021 at 01:12:18PM -0500, Russ Housley wrote:
>>> 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.
>> 
>> I have no strong preference here.  If you have looked at all the cases and
>> think this one is "different enough" that controlSequence is not needed, I
>> do not object to having it mentioned here.
>> Thanks,
>> 
>> Ben
>> 
>> _______________________________________________
>> netconf mailing list
>> netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
> 