Looks good, thanks. Dave
From: Pascal Thubert (pthubert) <[email protected]> Sent: Wednesday, November 13, 2019 3:09 PM To: Dave Thaler <[email protected]> Cc: [email protected]; [email protected] Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04 Thanks a bunch Dave The final paragraph would looks like this: “ A 6LoWPAN Fragment Forwarding technique makes the routing decision on the first fragment, which is always the one with the IPv6 address of the destination. Upon a first fragment, a forwarding node (e.g. node B in a A->B->C sequence) that does fragment forwarding MUST attempt to create a state and forward the fragment. This is an atomic operation, and if the first fragment cannot be forwarded then the state MUST be removed. When a forwarding node receives a fragment other than a first fragment, it MUST look up state based on the source Link-Layer address and the datagram_tag in the received fragment. If no such state is found, the fragment MUST be dropped; otherwise the fragment MUST be forwarded using the information in the state found. Since the datagram_tag is uniquely associated to the source Link-Layer address of the fragment, the forwarding node MUST assign a new datagram_tag from its own namespace for the next hop and rewrite the fragment header of each fragment with that datagram_tag. “ Works? Pascal From: Dave Thaler <[email protected]<mailto:[email protected]>> Sent: jeudi 14 novembre 2019 03:33 To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04 From: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Sent: Tuesday, November 12, 2019 7:50 PM To: Dave Thaler <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: Intdir last call review of draft-ietf-6lo-minimal-fragment-04 Le 13 nov. 2019 à 09:02, Dave Thaler <[email protected]<mailto:[email protected]>> a écrit : Pascal wrote: […] of the destination. Upon a first fragment, a node creates a state and forwards the fragment. I’d recommend “a node *attempts to* create state and forward the fragment”, since either of those could potentially fail, right? Also should this use normative language (“a node MUST…”)? The state is then used to forward the next fragments of the datagram. Ø I’d suggest MAY attempt to create the state and if successful MUST use it to forward the next fragments. To me, that sounds like an inappropriate use of MAY. MAY means an implementer can choose to ignore it. Do you really mean that an implementer can choose NOT to attempt to create the state? If it doesn’t implement attempting to create the state, then how could the mechanism work at all? I intended the MAY to indicate that the FF mechanism is optional. The node can always do what it did so far and either recompose the full packet to forward it or drop the packet for reasons of its own. It could split in 2 sentences; say that the mechanism is OPTIONAL and then that when it is used the node MUST attempt to create the state; would that clarify ? Yes. Of course your entire document is optional, so I’m not sure you need to explicitly say it’s OPTIONAL as long as you don’t Obsolete any other RFC. You could just say that “An implementation that does fragment forwarding MUST attempt to create the state…”
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
