Albert,
That all works for me.
Regards,
BrianOn 1/20/15 8:00 AM, Albert Cabellos wrote: > Hi > > Thanks, please see inline my replies (removed text for which we all agree): > > >> [snip] >> > > >>> >>>>> * The discussion of SMR should contain a reference to 6830 or a >>>>> brief discussion of how the SMR is used. >>>>> >>> >>> Could you please elaborate further this comment? >>> >>> "Solicit-Map-Request (SMR): SMR is an explicit mechanism to update >>> mapping information. In particular a special type of Map-Request can >>> be sent on demand by ETRs to request refreshing a mapping. Upon >>> reception of a SMR message, the ITR must refresh the bindings by >>> sending a Map-Request to the Mapping System." >> >> There are more interesting conditions/rules for the use of SMR that are >> only found in RFC 6830. I am suggesting adding a reference to 6830 at >> this point so readers know where to go to find more info on the SMR. >> >> > Agreed, I´ll add a sentence. > > Further uses of SMRs are documented in [RFC6830]. > > >>> >>>>> 8. Section 5 >>>>> >>>>> * I would suggest having a reference to both the MIP and the NEMO >>>>> specs when discussing mobility. LISP has the potential to >>>>> operate in a manner conducive with NEMO if the xTR acts as the >>>>> NEMO Mobile Router. >>>> >>>> Well if we do that then there are a ton of other cases where a xTR >>>> can be co-located with other functions (i.e. a simple reference is >>>> say a wifi AP). So singlingly out MIP/NEMO seems to be favoring >>>> these technologies versus others. Why would we want to do that? >>>> >>>> Plus, it raises questions more than simplifies the understanding of >>>> LISP. This is an intro document. >>> >>> What about adding the following sentence at the end of section 5? >>> >>> The decoupled identity and location provided by LISP allows it to >>> operate with other layer 2 and layer 3 mobility solutions. >> >> The text talks about both network (NEMO) and host (MIP) mobility. I am >> not concerned with LISP interacting with those protocols, I am thinking >> of how LISP replaces those protocols. The descriptions in Section 5 >> align with very well (i.e., the first paragraph describes LISP replacing >> NEMO and the second paragraph describes LISP replacing MIP). My >> proposal was to simply add references in those paragraphs to the >> mobility protocol that LISP is approximately. >> >> I do like your proposed addition in order to highlight that LISP will >> not interfere with other mobility solutions. >> >> > What about adding two sentences at the end of each paragraph: > > This functionality is similar to [RFC NEMO]. > This functionality is similar to [RFC MIP] [RFC MIPv6]. > > [snip] > >>>> 10. I am surprised that there are 2 Security Consideration >>>>> sections (7 & 9). I am even more surprised that one says >>>>> "Nothing new here" and the other actually discusses potential >>>>> issues with the LISP approach. >>>>> >>> >>> My fault, Section 7 should be “LISP Security Considerations” >>> >>> Section 9 describes the security considerations for the document >>> itself. >> >> I think maintaining two security consideration sections will be >> confusing. Either document that *this* document introduces no new >> security issues or have the security considerations section summarize >> the security impacts of LISP. >> >> > Agreed, will do the latter (so Section 9 is now Section 7). > > > >> Regards, >> Brian >> >> >> >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
