I'd suggest capturing Phil's issue in the writeup used by the
chairs to advance the document as per:
http://www.ietf.org/IESG/content/Doc-Writeup.html
That way we can invite discussion from the IESG on this item.
While it is always a good thing to obtain input from the IESG, I
don't think delegating this issue to the IESG during document
submission is the right approach here.
The WG is the domain expert on the kind of network we are discussing
here.
The WG should come to a conclusion.
The IESG can then check that we followed process and that the
document fits into the wider IETF picture (which is *not* dominated
by the relevant considerations here).
<wg-chair hat="off">
On the reassembly issue, I see two approaches:
1) keep with the reassembly at destination
2) open up the sequence such that reassembly-before-forwarding
becomes an alternative, chosen by the sender.
3) only allow reassembly before forwarding, i.e. forward only full
datagrams.
(As far as I can see, nobody argues for 3, that's why I see *two*
approaches.)
The advantage of 2 is more options (Philip has explained why this
can be a good thing).
The obvious disadvantage of 2 is more options (i.e., increased
burden on an implementation).
With 2, the sender gets to decide whether a forwarder has to
reassemble before forwarding; the forwarder has to play with that
decision.
(Reassembly at the forwarder also means different fragments cannot
choose different paths; maybe a more theoretical consideration.)
</wg-chair>
I'd like to hear more people taking sides on 1 or 2 before we declare
consensus.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
