> 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! Dino > > > -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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lisp
