Re: [6lo] Intdir last call review of draft-ietf-6lo-minimal-fragment-04

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Dave :

I published 06 with all the changes we discussed. It I snow std track. The chairs will update the datatracker accordingly.

Many thanks again!

Pascal

From: Dave Thaler <[e-mail]>
Sent: jeudi 14 novembre 2019 01:09
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04

Looks good, thanks.

Dave

From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, November 13, 2019 3:09 PM
To: Dave Thaler <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Sent: jeudi 14 novembre 2019 03:33
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: Intdir last call review of draft-ietf-6lo-minimal-fragment-04



From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 12, 2019 7:50 PM
To: Dave Thaler <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Intdir last call review of draft-ietf-6lo-minimal-fragment-04
Le 13 nov. 2019 à 09:02, Dave Thaler <[e-mail]<mailto:[e-mail]>> 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…”