Hi, Pascal, On Fri, Sep 30, 2016 at 4:36 AM, Pascal Thubert (pthubert) < [email protected]> wrote:
> Hello Spencer; > > Thanks a bunch for your review. Please see in line; > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I found this text > > A Page (say Page N) is said to be active once the Page N Paging > Dispatch is parsed, and as long as no other Paging Dispatch is > parsed. > > somewhat unclear. Is it saying > > A Page (say Page N) is said to be active once the Page N Paging > Dispatch is parsed, and remains active until another Paging > Dispatch is parsed. > > ? > > [Pascal Thubert (pthubert)] Yes, and I like your sentence above better > than the original. The temporal aspect (your "until") still remains to be > clarified, as meaning "as the packet headers are being processed from the > first to the last octet. Do we need to indicated that or is the implicit > good enough? > It's good enough for me :-) > I wasn't quite sure what "so far" meant in this text (and temporal > references in RFCs that live forever are somewhat confusing, anyway). > > As a result, there is no need so far for restoring the Page 0 > parsing context after a context was switched to Page 1, so the > value for the Page 0 Paging Dispatch of 11110000 may not actually > occur in those packets that adhere to 6LoWPAN specifications > available at the time of writing this specification. > > Would this be just as correct with "so far" deleted, or am I not > understanding the point you're making? > > [Pascal Thubert (pthubert)] I meant at the time of this publication, there > is no known standard that has a case where page 0 would need to be restored > after switching to page one. Does removing the so far express that > correctly? I think so. > Thanks for explaining why you're choosing "Specification Required" as your > IANA policy. > > [Pascal Thubert (pthubert)] The bottom line is that for most of these 6Lo > networks, there is no equivalent to ethertype. We were already cornered > with the ITU that started using some escape codes without IETF agreement. > Now we are opening a very large namespace, we want it to be used by many > communities beyond IETF, but we also indicate that we wish the IANA to > manage that namespace like the IEEE does for ethertypes; and we wish that > non experimental values are registered based on some standard action not > just anyone asking for one. Now, this question leads to another. Should we > reserve one page, say page 15, for experimentations? That sounds reasonable to this outsider. Do the right thing, of course :-) Spencer
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
