Re: [Gen-art] review of draft-ietf-opsawg-sdi-02.txt

[Alissa Cooper <[e-mail]>]

Francis, thanks for your review. Warren, thanks for addressing Francis’ comments. I entered a No Objection ballot.

Alissa


> On Mar 6, 2020, at 12:13 PM, Warren Kumari <[e-mail]> wrote:
> 
> Whoops, apologies, I just realized that I forgot to mention that I've
> posted a new version (-05) addressing these / hit send too soon.
> 
> Thank you again, Francis.
> W
> 
> 
> On Fri, Mar 6, 2020 at 12:09 PM Warren Kumari <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Wow, apologies, I had completely missed this email -- I have a complex
>> set of filtering rules to allow me to focus on drafts on the upcoming
>> telechats, and this fell into the cracks.
>> 
>> On Tue, Feb 18, 2020 at 10:57 AM Francis Dupont
>> <[e-mail]> wrote:
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair.  Please treat these comments just
>>> like any other last call comments.
>>> 
>>> For more information, please see the FAQ at
>>> 
>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>> 
>>> Document: draft-ietf-opsawg-sdi-02.txt
>>> Reviewer: Francis Dupont
>>> Review Date: 20200212
>>> IETF LC End Date: 20200218
>>> IESG Telechat date: unknown
>>> 
>>> Summary: Almost Ready
>>> 
>>> Major issues: None
>>> 
>>> Minor issues: crypto use details are missing. IMHO it is a problem of
>>> presentation, I propose:
>>> - make only requirements in the first/normative part
>>> - put all details in the appendix/demo part
>> 
>> Thank you.
>> 
>> I have attempted to do this - where I have crypto discussion I am
>> clarifying that this is just illustrative, and that the vendor should
>> figure out what is best for their environment. I also suggest vendors
>> may want to consider draft-gutmann-scep.
>> 
>>> 
>>> Nits/editorial comments:
>>>  - ToC page 2 and 8 page 11: Acknowledgements -> Acknowledgments
>> 
>> Thank you, done.
>> 
>>> 
>>>  - 2 page 4: there are two kinds of certificates so I suggest at the
>>>   first occurrence to put "public key certificate".
>> 
>> Done. Thank you.
>> 
>>> 
>>>  - 2 page 5, 2.2 page 5, 4.2 page 6, 5.3 page 10, 7 page 11: e.g -> e.g.,
>> 
>> Done (x8!)
>> Thank you.
>> 
>> 
>>> 
>>>  - 3.1 page 5: as an example of something which could be specified but
>>>   IMHO should not be: the certificate has (extended) key usages and
>>>   other policy parameters.
>> 
>> I added:  :The vendor's Certificate Publication
>> Server should only accept certificates from the manufacturing facility,
>> and which match vendor defined policies (for example, extended key usage,
>> extensions, etc.)"
>> 
>> Does this address your concern? I suspect that this section (and
>> others :-)) will get a fair but of discussion / feedback during IETF
>> LC, and SecDir / IESG review :-)
>> 
>>> 
>>>  - 4.2 page 6: in "The operator will then encrypt the
>>>   initial configuration to the key in the certifcate"
>>>    * the "to" seems a bit strange to me (I expected "with" but I am
>>>      not a native English speaker)
>>>    * public key crypto does not provide a way to directly encrypt
>>>      a large amount of data. IMHO it is not a real problem: just
>>>      require the key is used to protect the initial configuration
>>>    * it will be fine to have a bit more than confidentiality, for
>>>      instance to protect integrity or at least the data length.
>>>    Last both points are handled by SMIME so again it is only a
>>>    presentation problem.
>> 
>> Thank you -- the example uses SMIME specifically for this reason. I
>> was trying to word it in a way that was neither too prescriptive, nor
>> too convoluted. How is:
>> "The operator will then encrypt the initial
>> configuration (for example, using SMIME) using the key in the certificate,
>> and place it on their TFTP server. "
>> 
>>> 
>>>  - 4.3 page 7: Add that DHCP option 66 is TFTP server name and
>>>    option 150 is TFTP server address.
>> 
>> Oooh, thank you. Done.
>> 
>>> 
>>>  - 5.1 page 10: I've checked (googled it) the TPM abbrev and it seems
>>>    the common usage in the context is the expected one (BTW it is
>>>    not in the RFC editor abbrev table).
>> 
>> Thank you - I expanded it.
>> 
>>> 
>>>  - B.1.1 page 13: IMHO it is a good diea to give the OpenSSL command
>>>    line (OpenSSL man pages are more than cryptic :-).
>> 
>> Thank you - OpenSSL CLI processing is indeed, um, cryptic. I somewhat
>> think that this is by design - if someone accidentally publishes their
>> key, it doesn't actually matter, because no-one will figure out how to
>> invoke OpenSSL to *do* anything with it :-P
>> 
>>> 
>>>  - B.2.2 page 14: I support the choice of S/MIME: it does the job
>>>    (including length check) and it is commonly available.
>>>    Of course there should be better ways but it is clearly far
>>>    better than a home made solution. BTW as it is encoded ASN.1 it
>>>    is trivial to recognize (i.e., no ambiguity with ASCII text).
>> 
>> Thank you!
>> 
>>> 
>>> - B.3 page 15: then then -> then
>> 
>> Oooh, good catch, fixed, thank you.
>> W
>> 
>> 
>>> Regards
>>> 
>>> [e-mail]
>>> 
>>> PS: I removed spelling errors which were fixed in version 03.
>> 
>> 
>> 
>> --
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expressing
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>   ---maf
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>