Re: [tsvwg] SCE / L4S and fragmentation

["Black, David" <[e-mail]>]

Internal Use - Confidential

> > However, the -10 revision (which appears to be current) still contains the
> > section and some language covering fragmentation and reassembly.  To be
> > consistent with this approach, you need to update it to simply refer to RFC-3168
> > for the relevant semantics.  Then I think it will be possible to make progress.

> I am waiting for David on that. After his email asking me to reaffirm
> RFC3168 behaviour in ecn-encap and rfc6040update-shim, I said I'd rather
> just say fragmentation is out of scope. So I'm waiting for David's
> response as doc shepherd before I commit any changes to the draft.

I've sent that response in a separate email thread entitled "Fragmentation & ECN encapsulation drafts, one more try" - please refer to that thread.  I will summarize an important reminder from that thread here, just in case it's been overlooked:

Note to the wise: A wise WG participant will review draft-ietf-intarea-frag-fragile before responding to this note to the wise (hint) - see  https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/ .  That draft is IESG-approved to become a BCP (Best Current Practice), and is currently in the RFC Editor Queue.

Thanks, --David

> -----Original Message-----
> From: Bob Briscoe <[e-mail]>
> Sent: Monday, March 16, 2020 4:51 AM
> To: Jonathan Morton; Black, David
> Cc: [e-mail]
> Subject: Re: SCE / L4S and fragmentation
> 
> 
> [EXTERNAL EMAIL]
> 
> Jonathan, [David, this one's for you too]
> 
> On 15/03/2020 23:35, Jonathan Morton wrote:
> > Isolating one key point:
> >
> >> On 15 Mar, 2020, at 8:14 pm, Bob Briscoe <[e-mail]> wrote:
> >>
> >> I (and David Black) have argued that a separate draft is needed to update
> fragment reassembly in RFC3168. Can you please accept that we are not going
> to update ECN fragmentation and reassembly in rfc6040update-shim. Then it
> can unblock and be published.
> >>
> >> rfc6040update-shim is meant to be about encap and decap. It would allow
> this draft to become unstuck if it just said fragmentation and re-assembly is out
> of scope (which it is).
> > I have said several times in the past few days that I agree with that approach,
> and I'm sure David Black is well aware of that.
> >
> > However, the -10 revision (which appears to be current) still contains the
> section and some language covering fragmentation and reassembly.  To be
> consistent with this approach, you need to update it to simply refer to RFC-3168
> for the relevant semantics.  Then I think it will be possible to make progress.
> I am waiting for David on that. After his email asking me to reaffirm
> RFC3168 behaviour in ecn-encap and rfc6040update-shim, I said I'd rather
> just say fragmentation is out of scope. So I'm waiting for David's
> response as doc shepherd before I commit any changes to the draft.
> 
> 
> Bob
> >
> > We can discuss separately what, if anything, should be done to RFC-3168 on
> this topic.
> >
> >   - Jonathan Morton
> >
> 
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/