Hello Warren:
Super! We're getting there already.
>
> Great.
>
> > I wanted to point out that NCEs that are not in use can be flushed, so I
> > also
> meant to limit the need of memory to IP addresses that are currently in active
> conversations via this router.
> > If there are more conversations than NCEs then caching/flushing becomes
> ineffective. What about:
> > "for all directly connected addresses to which it is currently forwarding
> packets , but entries that do not appear to in use may be flushed."
>
> Sounds good, or "for all directly connected addresses to which it is currently
> forwarding packets (entries that do not appear to in use may be flushed)."
> I'm fine with either.
[PT>] Done; the section now reads as
In IPv6 ND <xref target="RFC4861"/>, a router needs enough storage
to hold NCEs for all directly connected addresses to which it is currently
forwarding packets (entries that do not appear to be in use may be flushed).
In contrast, a router serving the Address Registration mechanism
needs enough storage to hold NCEs for all the addresses that may be
registered to it, regardless of whether or not they are actively
communicating.
> >
> >> Nits:
> >> Section 4.2.1. Comparing TID values
> >> "In order to keep this document self-contained and yet compatible,
> >> the text below is an exact copy from section 7.2. "Sequence Counter
> >> Operation" of [RFC6550]."" I think that it would be helpful to
> >> delimit the copied text (perhaps by indenting it) -- it was unclear
> >> to me where the copied text started and ended, and so I had to go
> >> read RFC6550 (which kind of defeats the purpose of copying it).
> > [PT>] This text quoted above was discussed at the meeting. The group
> wanted to detach from RFC 6550 and not give an impression that this spec
> would inherit RPL's evolution should the referred behavior change. The text
> was replaced by:
> > "
> > As a note to the implementer, the operation of the TID is fully
> > compatible with that of the RPL Path Sequence counter as described
> > in
> > the "Sequence Counter Operation" section of the "IPv6 Routing
> > Protocol
> > for Low-Power and Lossy Networks [RFC6550] specification.
> > "
> >
>
> Sorry, I guess I was unclear in my note -- I was suggesting something like:
> "In order to keep this document self-contained and yet compatible, the text
> below (to the end of the section) is an exact copy from section 7.2."
> or
> "In order to keep this document self-contained and yet compatible, the text
> below (from <BEGIN> to <END> is an exact copy from section 7.2."
> or something.
> But, this was just a suggestion - I'm fine with the original too.
>
>
[PT>] yes but the WG wanted the whole sentence away. We do not mention the act
of copy any more, just the fact that we are compatible.
>
> >>
> >> Section Appendix B. Requirements (Not Normative) "This section lists
> >> requirements that were discussed discussed by the 6lo WG..."
> >> I guess that they were discussed at length? :-P
> >>
> > [PT>] to death as https://tools.ietf.org/html/draft-thubert-6lo-rfc6775-
> update-reqs-07 but for the section I added based on Juergen's comments for
> manageability "Requirements Related to Operations and Management". This
> one came in late and I need your and Juergen's comments on it.
> >
>
> Sorry, I was overly terse -- I was just referring to the "discussed
> discussed".
[PT>] Oups, done : )
> > [PT>] done! Please let me know if you are OK with the changes above
> > and I'll publish rev-17
>
> Yup, I'm a happy camper. Thank you very much for such a quick turnaround.
> W
[PT>] Will publish right now : )
Take care,
Pascal
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
