Hi Albert, thanks for submitting the updated document.
I have have a few residual nits listed below. Fixed those we can move to LC IMO. Ciao L. > > LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is > randomly generated by an ITR when the N-bit is set to 1. Nonce > generation algorithms are an implementation matter but are > required to generate different nonces when sending to different > destinations. [Luigi] As stated for -07: What is a destination? Should be different RLOCs, for clarity. The Clock Sweep mechanism is just about management should go in AOM. The following document are not Normative: [RFC4086 <>] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106 <https://tools.ietf.org/html/bcp106>, RFC 4086 <https://tools.ietf.org/html/rfc4086>, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086 <https://www.rfc-editor.org/info/rfc4086>>. [RFC6275 <>] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275 <https://tools.ietf.org/html/rfc6275>, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275 <https://www.rfc-editor.org/info/rfc6275>>. > On 5 Mar 2018, at 22:33, Albert Cabellos <albert.cabel...@gmail.com> wrote: > > Hi > > I'll post a new version without such sections shortly. > > I volunteer to help writing the OAM document. > > Albert > > On Mon, Mar 5, 2018 at 9:35 PM, Dino Farinacci <farina...@gmail.com > <mailto:farina...@gmail.com>> wrote: > >> On 5 Mar 2018, at 19:06, Dino Farinacci <farina...@gmail.com > >> <mailto:farina...@gmail.com>> wrote: > >> > >>> Hi all > >>> > >>> This document should address all the comments except this one: > >>> > >>> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement > >>> Considerations), 18 (Traceroute Consideration) to a new OAM document > >>> > >>> The authors would like to have a better understanding of where this text > >>> will go. > >> > >> Right, we concluded to not remove the valuable text. > > > > Nobody wants to lose valuable text. > > Glad you feel that way. > > > > >> A lot of time and thought went into writing it and we didn’t want to lose > >> it. There was no where that was agreed upon to put it. > > > > That is not accurate. There was clear indication to move it to a new OAM > > document, without any change in the text. > > Purpose was to have just a different placeholder that make more sense. > > This is an half an hour task. > > But there was also concerns about slowing the process down. And the > co-authors (Albert and I) don’t think it should move from RFC6833. > > So there isn’t concensus. And I don’t believe it is even rough concensus. > > > > >> > >> So since we felt there was no concensus on Sections 16-18, we didn’t make > >> any change. > > > > Again not accurate, please spend half an hour to create the OAM document. > > If you do not have time we can appoint other editors for the task. > > Authorship will be anyway preserved. > > > Section 16 is “Mobility Considerations” that discusses various forms of how > EIDs can change RLOCs. And it sets up for different designs that are already > documented in various documents. But Mobility certainly shouldn’t go in an > OAM document. > > Section 17 discusses where xTRs (data-plane boxes) should reside in the > network. And sets up for a more detail discussion which is in the Deployment > RFC. > > Section 18 is “Traceroute Considerations”, this arguably can go into an OAM > document. But it would be 3 pages. And then one would argue there are other > OAM mechanisms spread across LISP documents that could go in an OAM document. > > This will not take 1/2 hour. > > And I’m finding it hard to see the value in doing all this busy work. We have > already accomplished separating data-plane text from control-plane text. We > achieved that goal from the charter. > > Dino > >
_______________________________________________ lisp mailing list email@example.com https://www.ietf.org/mailman/listinfo/lisp