Hi, Pascal, and thanks for the quick reply and for addressing my comments. For anything I don't mention further below, all is OK.
> > I think this makes FRAG-ILE a normative reference (necessary security > > issues). > > It would also be useful to have a “see Section 7” forward pointer here, so > > it’s > > clear that the specific issues are discussed later in this document. > > It was never published and never will be, so procedure-wise that's calling > for trouble. > The paragraph now looks like: > " > "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security > threats that are linked to using IP fragmentation. The 6LoWPAN > fragmentation takes place underneath, but some issues described there > may still apply to 6LoWPAN fragments (as discussed in further details > in Section 7). > " > Works? Ah, OK, I didn't realize it wasn't meant to be published formally. Yes, I think this works, because section 7 has enough detail that it can stand as its own normative reference. Thanks. > > I think this makes 4919 a normative reference (necessary terminology and > > concepts). > > A downref but OK, I'll trust an IESG review on this : ) Yes, not a problem: downrefs are now common, unremarkable, and not problematic, as we often publish terminology and architecture/concepts documents as Informational. >> This specification uses the following terms: >> >> I would say it “defines” these terms, no? > > Not really, they appear in RFC 4944, but ok OK, no... I hadn't realized (and didn't check) that they were defined in 4944. Sorry; leave as is. > Which gives: > " > 6LoWPAN endpoints: The 6LoWPAN endpoints are the first and last > nodes in an unbroken string of 6LoWPAN nodes. They are in charge > of generating or expanding a 6LoWPAN header from/to a full IPv6 > packet. They are also the points where the fragmentation and > reassembly operations take place. > " I like it. > > Should this be “limitations”, rather than “limits”? It seems so. Also > > throughout Section 6. ... > And later, changed to caveats on occasion, see: Yes; "caveats" works too; thanks. > > — Section 6 — > > (Change “limits” to “limitations” throughout the section.) Doesn’t this > > section need LWIG-VRB to be a normative reference? > > I do not think so. The whole idea in this section was that the text would be > self-describing. > People are free to dig in the LWIG spec but that is not needed to understand > this text. OK; that makes sense. -- Barry _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
