Re: [radext] radius-fragmentation: New flag T field for the Long Extended Type

> -----Original Message-----
> From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok
> Sent: Tuesday, March 04, 2014 7:34 AM
> To: lionel.morand@orange.com
> Cc: Sam Hartman; Stefan Winter; Alejandro Perez Mendez; radext@ietf.org
> Subject: Re: [radext] radius-fragmentation: New flag T field for the Long
> Extended Type
> 
> lionel.morand@orange.com wrote:
> > The question is simple: how do we ensure that another draft will not
> allocate the same 2nd bit to another feature? It would mean that the same
> Long-extended-type attribute would have two possible
> interpretations/process...
> 
>   I think we're safe with manual tracking.  I don't see any other draft
allocating
> the same bit.
> 
> > Are we only relying on living memories? :)
> 
>   The documents are available on a public web page as part of the RFC
> process.
> 
> > Maybe we don't care because it is an experimental document... or maybe
> this doc will update the RFC6929 to indicate that the 2nd bit is used for
"T".
> 
>   We can't have an experimental draft update a standards track document.

For this type of update, I see no reason this draft cannot  update  the
standards track document.  It is not changing any significant content in
that draft.

Jim

> 
>   Alan DeKok.
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext