> Nothing more from me (although I don't think that's where you query was 
> directed), all the changes look good.

The query was for you. I wanted you to agree to the changes before I posted the 
new version.

> On the IANA question, was simply a matter of if you want to require something 
> more rigid v. the most lax codepoint allocation model, but I don't have any 
> strong opinion there.

Okay, I will post right now.

Thanks all!


> -danny
> On 2016-09-19 12:06 PM, Dino Farinacci wrote:
>> Any status on this?
>> Dino
>>> On Sep 5, 2016, at 10:07 AM, Dino Farinacci <farina...@gmail.com> wrote:
>>> See responses inline. A new draft is attached (but not submitted since I 
>>> had some open questions).
>>>>> Document: draft-ietf-lisp-crypto-06.txt
>>>>> Reviewer: Danny McPherson
>>>>> Review Date: August 24, 2016
>>>>> Intended Status: Experimental
>>> Thanks for the review Danny.
>>>>> Summary:
>>>>> I have some minor concerns about this document that should be considered 
>>>>> before publication.
>>>>> Comments:
>>>>> I believe the draft is technically sound.
>>>>> Major Issues:
>>>>> I have no “Major” issues with this I-D.
>>> Good to hear.
>>>>> Minor Issues:
>>>>> In the Security Considerations section a small amount of text might be 
>>>>> useful that discusses end-end v. encryption from middle boxes, and the 
>>>>> risks therein.  There are clearly benefits to this over no encryption, 
>>>>> but there are risks about assumptions that may be made thereafter as well.
>>> I added some text. Please review.
>>>>> Nits:
>>>>> S.1: s/typically not modified.  Which means/typically not modified, which 
>>>>> means/
>>> Changed.
>>>>> S.1: Is there in fact a case where asymmetries result in the *same* 
>>>>> egress xTRs but different keys are used?  I believe this would just apply 
>>>>> to "different xTRs", no?  :
>>> Right, when the same ETR is used by different ITRs to encapsulate traffic, 
>>> different keys are used.
>>>>>       However, return traffic uses the same procedures but with different 
>>>>> key values by the same xTRs or potentially different xTRs when the paths 
>>>>> between LISP sites are asymmetric.
>>> Right, a unique set of keys are used for each {ITR, ETR} combination. Did 
>>> you want me to say something specific here?
>>>>> S.1: Regarding "[t]his document has the following requirements for the 
>>>>> solutions space", it might be useful to reference some general IETF 
>>>>> privacy work, even RFC 6973 or the like.  Given that it's Experimental I 
>>>>> think it's fine as is, but some references for the broader community may 
>>>>> be in order.  In particular, references to not requiring a separate PKI 
>>>>> (and therefore external or circular dependencies!), avoiding third party 
>>>>> trust anchor, rekeying as good operational practice, not just 
>>>>> compromises,  and other such arguments might be reinforced.
>>> I added a reference to 6973.
>>>>> S.3: Could include LCAF here, perhaps.
>>> Added plus its reference.
>>>>> S.4: You could probably strike this entire sentence and lessen confusion: 
>>>>> "When an ETR (when it is also an ITR) encapsulates packets to this ITR 
>>>>> (when it is also an ETR), a separate key exchange and shared-secret 
>>>>> computation is performed.”
>>> Okay, removed.
>>>>> S.7: It’s unclear what constitutes “Diffie-Hellman *group*”.
>>> I will change “group” to “parameters”.
>>>>> S.7: s/the the/the/
>>>>> S.7: s/integrity-check/integrity check/
>>> Changed both.
>>>>> S.8: Editors note to strike text in last paragraph here, unclear what 
>>>>> resolution was from this text.
>>> We allocated two new bits from a 3-bit reserved field now leaving 1 reserve 
>>> bit. I added that the reserved bit remaining is documented in RFC6830.
>>>>> S.12.1: A reference to the SAAG comments might be useful here?
>>> We don’t have one. But I will add a list of recommendations they provided.
>>>>> S 13: Are you sure you want a default FCFS allocation policy here and not 
>>>>> a slightly higher bar?
>>> I have no opinion. What is the benefit on not doing FCFS?
>>>>> Throughout: Consistent hyphenation in the document would help (e.g., 
>>>>> “network-byte” ..).
>>> Done.
>>>>> Throughout: Expanding on first use of each acronym would be useful, 
>>>>> perhaps with references.
>>> Done.
>>> A new revision is attached (plus a htmlized diff file). Let me know if you 
>>> like the text and then I’ll submit -07.
>>> Thanks again,
>>> Dino & Brian
>>> <rfcdiff.html><draft-ietf-lisp-crypto-07.txt>

lisp mailing list

Reply via email to