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

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

> 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.

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