Re: [6lo] Barry Leiba's No Objection on draft-ietf-6lo-minimal-fragment-10: (with COMMENT)

[Barry Leiba <[e-mail]>]

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