Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt

[Spencer Dawkins at IETF <[e-mail]>]

I don't want to read ahead of the assignment, of course :D ...

On Wed, Jul 25, 2018 at 10:21 AM Black, David <[e-mail]> wrote:

> > I don’t know what « updates RFC 6363 » implies exactly. If « updates »
> > implies « replaces » then the
> > answer is no. RFC 6363 will remain as is, without any change, we just
> add a
> > new capability to it.
>
> Here, "updates" means "extends or modifies."    Looking at the two drafts,
> there appear to be two different outcomes.
>
> 1) The fecframe-ext draft clearly extends the RFC 6363 framework.   In
> addition, Section 5.3 definitely modifies RFC 6363, as indicated by the
> first paragraph in that section:
>
>    The FEC Scheme requirements of [RFC6363], Section 5.6, mostly apply
>    to this FECFRAME extension and are not repeated here.  An exception
>    though is the "full specification of the FEC code", item (4), that is
>    specific to block FEC codes.  The following item (4) applies in case
>    of Sliding Window FEC schemes:
>
> So, it looks like the fecframe-ext draft need an "Updates: 6363" header,
> and the draft will need a section summarizing changes to RFC 6363 - at
> least the section 5.3 change, and also identifying any normative text in
> RFC 6363 that doesn't apply to Sliding Window Codes.
>
> 2) In contrast, the rlc-fec-scheme draft appears to use the RFC 6363
> framework as extended by the fecframe-ext draft without modifying that
> framework.  If that is correct, it does not need an "Updates: 6363" header,
> as all the changes & extensions to RFC 6363 ought to be in the fecframe-ext
> draft.
>

I've served on six different IESGs, and I'm pretty sure I've never served
on one that didn't talk about what "Updates" REALLY means. But I think
David's conclusion is very defensible.

And if the Updates header is the only change that Wes identifies while
doing his Shepherd Write-up, I'm fine if you wait until after I do AD
Evaluation to submit a new version.

Thanks for talking this through.

Spencer

Thanks, --David
>
> > -----Original Message-----
> > From: tsvwg [mailto:[e-mail]] On Behalf Of Vincent Roca
> > Sent: Wednesday, July 25, 2018 11:00 AM
> > To: Wesley Eddy
> > Cc: [e-mail]
> > Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt
> >
> > > Le 25 juil. 2018 à 16:34, Wesley Eddy <[e-mail]> a écrit :
> > >
> > > On 7/25/2018 6:10 AM, Vincent Roca wrote:
> > >> Hello Wes, all,
> > >>
> > >> We have just updated the FECFRAME extension and RLC FEC Scheme for
> > FECFRAME I-Ds as
> > >> discussed during IETF 102 meeting. Those updates fix a few typos,
> slightly
> > improve text, add
> > >> an acknowledgment section. We authors do not think it requires a new
> > WGLC.
> > >
> > > Hi Vincent, one part of the shepherd write-up asks us to make sure
> that if
> > any other RFCs are updated, obsoleted, etc., that it's indicated
> properly.
> > >
> > > As this document explains, it extends but doesn't replace RFC 6363.
> > >
> > > One could see this as a definite case for having it say "Updates:
> 6363" in the
> > header.  Do you agree, or was there a reason I've forgotten why we
> decided
> > not to indicate that?
> >
> > I think the question has never been asked like that.
> >
> > My first idea, back in 2016, was to replace RFC 6363 altogether.
> > Then David had this key remark that in fact we just want to extend RFC
> 6363
> > and the title reflects this.
> >
> > I don’t know what « updates RFC 6363 » implies exactly. If « updates »
> > implies « replaces » then the
> > answer is no. RFC 6363 will remain as is, without any change, we just
> add a
> > new capability to it.
> >
> > The new FECFRAME standard should now be understood as the combination:
> >       RFC 6363 + RFC XXX (this doc).
> >
> > Does it answer?
> > Cheers,
> >
> >   Vincent
>
>