Re: [secdir] SECDIR Reveiw of draft-ietf-hip-dex-11

[Robert Moskowitz <[e-mail]>]

Donald,

Thanks for the catch.  I got a little too rambunctious in my indenting.  :)

On 2/7/20 12:29 AM, Donald Eastlake wrote:
> Hi Bob,
>
> Sorry to delay in response...
>
> Changes look good to me with one little exception: On page 52, after 
> the line beginning "Section 6", the next three lines are nicely 
> indented but I believe the fourth line of text is sort of a 
> continuation of the line beginning "Section 6" and so should not be 
> specially indented but should be left justified lining up with the 
> words "Section 6".
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
> [e-mail] <mailto:[e-mail]>
>
>
> On Mon, Jan 27, 2020 at 11:25 AM Robert Moskowitz 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Donald,
>
>     This is a partial update which I believe addresses your comments
>     plus a strong request to justify no PFS.
>
>     Please check that I have indeed addressed your comments.
>
>     More edits for other comments next.
>
>     Bob
>
>     On 1/20/20 11:18 PM, Donald Eastlake wrote:
>>     I have reviewed this document as (a very late) part of the security
>>     directorate's ongoing effort to review all IETF documents being
>>     processed by the IESG.
>>
>>     The summary of the review is Ready with Nits.
>>
>>     Sorry to get this review in so late but, while approved by the IESG,
>>     the draft is still in revised draft needed state so this may do some
>>     good. On the security front, although the draft is pretty complex and
>>     I am not that familiar with HIP, I did not see any significant
>>     security issues that were not already called out in the draft. So I
>>     concentrated on possible editorial issues.
>>
>>     Editorial:
>>
>>     Section 1.1, 3rd paragraph, page 5. Delete "However," a the beginning
>>     of the 2nd sentence. It doesn't make sense.
>>
>>     Section 2.3, Definitions should be in alphabetic order.
>>
>>     Section 2.3: It seems to me that people who are puzzled about what
>>     something means are most likely to be puzzled by the acronym. So I
>>     would put the acronym first, where there is an acronym or acronym-like
>>     term to use, then the expansion in parenthesis or in the body of the
>>     definition. This done for a couple of entries like CMAC and CKDF but
>>     most are the other way.
>>
>>     Section 3 last paragraph and Section 12.10 5th bullet: "to use" -> "use of"
>>
>>     I think OGA  and KEYMAT should be in the Definitions list and KEYMAT,
>>     which I assume just is short for "keying material", should be expanded
>>     on first use in Section 6.3. Alternatively, you could just replace all
>>     occurrences of KEYMAT with "Keying Material".
>>
>>     Section 5.3.2, page 23. The first sentence of the first paragraph
>>     starting on that page has problems. Maybe "chose" should be "choses"
>>     but I'm not sure:
>>        "The DH_GROUP_LIST parameter contains the Responder's order of
>>         preference based on which the Responder chose the ECDH key contained
>>         in the HOST_ID parameter (see below)."
>>
>>     Appendix A, first sentence, "allows to identify" -> "allows identifying"
>>
>>     Appendix B, "IEDG" -> "IESG"
>>
>>     Appendix B, around the middle of page 51, right after the line
>>     beginning with "Section 6," there are three line with a blank line
>>     before and after. I found this confusing at first. I suggest those
>>     three line also be indented.
>>
>>     Appendix B, page 52, "SHOUDS" -> "SHOUDs"
>>
>>     Thanks,
>>     Donald
>>     ===============================
>>       Donald E. Eastlake 3rd   [phone] (cell)
>>       2386 Panoramic Circle, Apopka, FL 32703 USA
>>       [e-mail]  <mailto:[e-mail]>
>
>     -- 
>     Robert Moskowitz
>     Owner
>     HTT Consulting
>     C: 248-219-2059
>     F: 248-968-2824
>     E: [e-mail] <mailto:[e-mail]>
>
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit