[radext] Fwd: Re: Experimental doc updating a Standard Track doc (draft-ietf-radext-radius-fragmentation)

Benoit Claise <bclaise@cisco.com> Fri, 28 November 2014 10:19 UTC

Message-ID: <54784C45.4010406@cisco.com>
Date: Fri, 28 Nov 2014 11:19:49 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>, draft-ietf-radext-radius-fragmentation@tools.ietf.org, 'Barry Leiba' <barryleiba@computer.org>
References: <CALaySJ+h1XFna64x9twHQm+o2PSrfdLWOH0qRaLU4Ast-wzO+Q@mail.gmail.com>
In-Reply-To: <CALaySJ+h1XFna64x9twHQm+o2PSrfdLWOH0qRaLU4Ast-wzO+Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------030104060109080804050109"
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/Ul2su-hyHrrM8xdxDtv6ekxj-bo
Subject: [radext] Fwd: Re: Experimental doc updating a Standard Track doc (draft-ietf-radext-radius-fragmentation)
Precedence: list

Dear all,

Here is Barry's answer, supporting your "update".
One more good suggestion at the end of his email.

Regards, Benoit


-------- Original Message --------
Subject: 	Re: Experimental doc updating a Standard Track doc
Date: 	Thu, 27 Nov 2014 10:32:43 -0500
From: 	Barry Leiba <barryleiba@computer.org>
To: 	Benoit Claise <bclaise@cisco.com>
CC: 	IESG IESG <iesg@ietf.org>, "radext-chairs@tools.ietf.org" 
<radext-chairs@tools.ietf.org>



> I'm currently busy with the AD review of
> draft-ietf-radext-radius-fragmentation-08
> As mentioned in the writeup, this experimental document update a standard
> track document
> See the reasoning at
> http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-08#section-11.1
>
> See also the RADEXT archive.
> http://www.ietf.org/mail-archive/web/radext/current/msg08854.html
> I pushed back initially, but the WG has some valid arguments.
>
> What do you think?
> Have you faced this issue already?

I think it absolutely makes sense (in the right circumstances) for an
Experimental spec to "update" a Standards Track document: it's
reasonable to consider something as an experimental update.  In those
cases, I think it's very important for the Experimental document to be
very clear about what the update is, and that it's experimental.

I think the same is true for Informational: Standards Track documents
contain material that is informational, and it's reasonable for an
Informational document to update that.

We just need to use our judgment about what's right in a particular
situation.  For this "T" flag, I think it makes sense.  I might add to
Section 11.1 something about what happens to the "T" flag if this
experiment flops and goes away.  If this is reserving the "T" flag
forevermore, regardless of whether the protocol defined herein sticks
around, it would help for the document to be clear about that, so no
one wonders someday, when this document becomes Historic, whether the
"T" flag can be reused.

Barry
.

[radext] Fwd: Re: Experimental doc updating a Sta… Benoit Claise