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
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
