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

[Sean Turner <[e-mail]>]

Prefer the latter.

spt

> On Jan 24, 2022, at 09:41, Russ Housley <[e-mail]> wrote:
> 
> Kent:
> 
> I like NEW, but I can live with either one.
> 
> Russ
> 
>> On Jan 21, 2022, at 6:44 AM, Kent Watsen <[e-mail]> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netconf
>> 
>