Subject: Re: [lp-wan] review draft-ietf-lpwan-ipv6-static-context-hc-03 (part II)

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 5 Jun 2017 15:47:25 +0200

Hi Diego,

Thanks a lot for your review.

The fragmentation part has been updated (now in github, and hopefully in
the -04 to be published soon). Your comments should hopefully be addressed
in the updated version.

On the other hand, please find below inline responses to your questions or
to comments that needed discussion. (Everything else is agreed or done and
snipped.)

> - "If the datagram does not fit within a single L2 data unit, it SHALL
>
>    be broken into fragments."
>
>
> And if not broken into fragments, the alternative is to
>
> drop the packet?

Yes.

> - "provides flow control"
>
>
> I don't know if this is exactly flow control in the terms
>
> of what it is known in TCP. For TCP, one lost packet signals
>
> that the bandwidth limit for the flow is full (probably due
>
> to congestion), and there is no congestion at the lpwan level.
>
> What is true is that this mechanism stops

'Flow control' is used here to refer to the fact that a receiver ACKing a
window of fragments means that it has been able to perform the
corresponding operations on the received (or missing) fragments.

> Fragmentation header formats
>
>
>
> I am worried about the "SHALL" term. The header MUST be
>
> as described, if not, there will be no interoperability.

Well, RFC 2119 defines use of "SHALL" for the same purpose as "MUST". (It
is true that "MUST" is more common, though...)

> I can understand you have to create a rule for each
>
> fragmentation reliability option used. Am I right?

Yes (this is mentioned in the document, and hopefully clearer now).

Cheers,

Carles