Subject: [radext] Update RFC 6929 in draft-ietf-radext-radius-fragmentation

From: Benoit Claise <[email-masked]>
Date: Tue, 18 Mar 2014 15:53:22 +0100

Dear all,

Following Lionel's question during the RADEXT meeting regardingthe 
"update RFC 6929" in draft-ietf-radext-radius-fragmentation-04, I was 
asked to look into this question.

RFC 3967 and RFC 4897 are about the reverse, i.e. normative downref, so 
no problem here.
The question is:does it even make sense for an experimental RFC to 
update another RFC?

Checking with one fellow IESG member, we don't think this the draft 
Updates 6929. Nobody implementing 6929 has to look at this document. And 
we think an Experimental document updating a standards track document is 
bad form, even if not specifically forbidden. There's a normative 
reference to 6929; Updates is not needed.

Regards, Benoit

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Mar 2014 10:56:52 -0400

Benoit Claise wrote:
> The question is: does it even make sense for an experimental RFC to
> update another RFC?

  Only if the other one is also experimental.

> reference to 6929; Updates is not needed.

  That sounds good to me.

  Alan DeKok.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 18 Mar 2014 16:07:39 +0100

Alan,
>    Only if the other one is also experimental.
Good point.
I checked the last 100 published experimental RFCs, and when an "Update" 
was used, it was always updating an experimental RFC.

Regards, Benoit
> .

---

From: <[email-masked]>
Date: Tue, 18 Mar 2014 15:27:17 +0000

On the same line, it should be highlighted for information that the field assigned for "T" in this document was available at the time of publication but it could conflict in the future with a normative document that would reuse the same field with another meaning.

Regards,

Lionel

Envoyé depuis mon Sony Xperia SP d'Orange

Benoit Claise <[email-masked]> a écrit :

Alan,
Good point.

Regards, Benoit
>> reference to 6929; Updates is not needed.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 18 Mar 2014 10:50:49 -0700

While it is true that an implementer of 6929 does not need to see this
document, it is also true that this document is effectively allocating a bit
from a structure that is in that document.  If this document does not update
6929, then it is possible that the next document to update that structure
will fail to notice this and allocate the same bit for a different purpose.

I believe that this update relationship needs to be retained.

Jim

From: radext [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Tuesday, March 18, 2014 7:53 AM
To: [email-masked]
Cc: [email-masked]; <[email-masked]>
Subject: [radext] Update RFC 6929 in draft-ietf-radext-radius-fragmentation

Dear all,

Following Lionel's question during the RADEXT meeting regarding the "update
RFC 6929" in draft-ietf-radext-radius-fragmentation-04, I was asked to look
into this question. 

RFC 3967 and RFC 4897 are about the reverse, i.e. normative downref, so no
problem here. 
The question is: does it even make sense for an experimental RFC to update
another RFC? 

Checking with one fellow IESG member, we don't think this the draft Updates
6929. Nobody implementing 6929 has to look at this document. And we think an
Experimental document updating a standards track document is bad form, even
if not specifically forbidden. There's a normative reference to 6929;
Updates is not needed.

Regards, Benoit

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Mar 2014 17:58:10 -0400

Jim Schaad wrote:
> document, it is also true that this document is effectively allocating a
> bit from a structure that is in that document.  If this document does
> not update 6929, then it is possible that the next document to update
> that structure will fail to notice this and allocate the same bit for a
> different purpose.

  I hope we're all smart enough to remember that the bit is allocated.
If we're not... the WG should be shut down.

> I believe that this update relationship needs to be retained.

  It may be useful, but IETF process may forbid it.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 19 Mar 2014 11:15:35 +0100

>   It may be useful, but IETF process may forbid it.

In my opinion, this draft does update 6929, as it updates 2865, since
6929 specifies the reserved field MUST be set to 0, and SHOULD be
ignored by recipients, and we change that.

However, following the same reasoning than with 2865, probably it should
not be actually specified until the fragmentation document is re-issued
as a standards track document (if it does).

Regards

>
>   Alan DeKok.
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Mar 2014 10:22:35 -0400

>> not update 6929, then it is possible that the next document to update

It's not just the document/WG, it is also users of the protocol who think
that they are in a walled garden, and can abuse reserved fields.

    > It may be useful, but IETF process may forbid it.

An Experimental document can allocate bits from a standard... on an
experimental basis.  ECN bits were done that way.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Alan DeKok <[email-masked]>
Date: Thu, 20 Mar 2014 10:51:47 -0400

> that they are in a walled garden, and can abuse reserved fields.

  I have zero sympathy for such people.

> The WG will be shutdown at some point,

  Never!

> experimental basis.  ECN bits were done that way.

  OK.

  I'm not sure we want an IANA registry for these bits.  It seems
overkill.  But it would be a way to track their allocation.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Mar 2014 12:26:01 -0400

My preference is that we try publishing with the updates on 6929, and if
that fails, then we just ignore things.

I would rather not create an IANA registry for these bits.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Mar 2014 14:12:01 -0400

> I have zero sympathy for such people.

Without the pointer, they won't know they are being stupid.

    > overkill.  But it would be a way to track their allocation.

I'm not 100% sure you need to have an IANA registry, but I'm sure that
the document needs to update the previous document.

RFC6929 did not say what kind of specifications:

      Future specifications may define additional meaning for this
      field.  Implementations therefore MUST NOT treat this field as
      invalid if it is non-zero.

I think it's a call for your AD to make.
I think that it's reasonable for it to be an experimental document,
and I think that ECN *repurposed* the ToS bits without an IANA registration.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 20 Mar 2014 14:15:28 -0400

> Without the pointer, they won't know they are being stupid.

  Not entirely.  RFC 6929 says that the bits are reserved, and allocated
via IETF consensus.  Any vendor "poaching" on those bits knows a priori
that it's wrong.

  They don't need to read the fragmentation document to know that.

> I think that it's reasonable for it to be an experimental document,

  I agree.

  I'm OK with this doc saying "updates 6929".

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 24 Mar 2014 15:22:42 +0100

Hello,

> If we're not... the WG should be shut down.

I believe it's a bad idea to rely on collective memory or a mailing list
archive.

So, regardless of what the consensus will be: try an "Updates" or not;
create an IANA registry or not - the fact that a loosely-knit
relationship to RFC6929 exists, and where the pitfalls are, should be
reflected inside the draft itself.

As for where - I think it helps to keep in mind that that there will be
numerous rounds of reviewing going on after the document has cleared WGLC.

In particular, the Operations Area will conduct an ops-dir review as
part of the IETF LC. There are very specific questions in the ops-dir
review template, one of which is:

"Are there any coexistence issues?"

The probability that an ops-dir reviewer will pick up the T-Bit
allocation coexistence issue during his reading are very high
(especially if the proto write-up mentions this as one of the
contentious points :-) ); so if that issue is not explicitly documented,
it will probably surface at that point, and we'll need to deal with it.

We can of course wait for that to happen, but I'd rather preempt such a
useless extra round and fix the issue in the draft right now.

Another question in the ops-dir review is

"Is an operational considerations and/or manageability section part of
the document?"

I believe the best way forward is to add such a section to the draft (it
could be a sub-section of Introduction, or be a section of its own). The
section would document what was argued on the mailing list, where the
pitfalls are, and that an "Updates" would be a reasonable possiblity to
avoid them if allowed by process.

With that text in the document, the WG can then try to use Updates or
not - and the reason for doing so can then be found in the document
itself. If the actual Updates relationship later doesn't fly, the text
highlighting the issue will at least still be in there - and not in
someone's brain or deep down in the ML archives. I realise that the text
then wouldn't necessarily be found by someone implementing a follow-up
spec to RFC6929 due to lack of an Updated-By, but chances are at least
way better.

(And as an individual: if we have an Operations/Manageability section
anyway at that point - wouldn't it be a good idea to move the "formal
violation of RFC2865" into that section as well? )

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 25 Mar 2014 09:29:39 +0100

> violation of RFC2865" into that section as well? )

I think it is a good idea to have such a section, specially is you think
it will be requested by ops-dir reviewers if not present. I would place
it as section 10, right before "Security considerations" section,
instead of in the Introduction section, to avoid basing the explanations
on something that has not been described yet.

I also think that the "formal violation..." discussion should be moved
here. We could also include the "proxying based on User-Name"
restriction too.

Regards,
Alejandro

---

From: Stefan Winter <[email-masked]>
Date: Tue, 25 Mar 2014 10:08:19 +0100

Hi,

> on something that has not been described yet.

Great, please go ahead.

> here. We could also include the "proxying based on User-Name"

Sounds like a reasonable move to me.

Note that none of this removes the need for the working group to settle
on the questions:

- should we try to achieve an "Updates" relationship to RFC6929?
- should there be an IANA registry for the flags of extended attributes?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Tue, 25 Mar 2014 15:52:09 -0400

> - should we try to achieve an "Updates" relationship to RFC6929?

  I'm OK with or without the "Updates".  It would probably be best to
have it, unless the IETF process forbids Experimental drafts from
updating Standards track documents.

> - should there be an IANA registry for the flags of extended attributes?

  If we have an "Updates", there's no need.  Because people would be
expected to read the docs.

  If we don't have an "Updates", maybe.  RFC 6929 marks the reserved
fields as allocated via IETF consensus.  So anyone uses the excuse of
"no IANA registry" to "poach" on them is 100% at fault.

  For IETF consensus, I hope that the WG can track 2 documents, and
ensure that any new specification doesn't overlap with the fragmentation
doc.

  Alan DeKok.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 25 Mar 2014 13:56:03 -0700

> -----Original Message-----
> From: radext [mailto:[email-masked]] On Behalf Of Stefan Winter
> Sent: Tuesday, March 25, 2014 2:08 AM
> To: [email-masked]
> Subject: Re: [radext] Update RFC 6929 in draft-ietf-radext-radius-
> fragmentation
> 
> Hi,
> 
> > I think it is a good idea to have such a section, specially is you
> > think it will be requested by ops-dir reviewers if not present. I
> > would place it as section 10, right before "Security considerations"
> > section, instead of in the Introduction section, to avoid basing the
> > explanations on something that has not been described yet.
> 
> Great, please go ahead.
> 
> Note that none of this removes the need for the working group to settle on
> the questions:
> 

yes

> - should there be an IANA registry for the flags of extended attributes?

no - unless the updates fails for some reason.  A registry seems like
overkill unless we think there are going to be a number of updates

jim

> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de
> la Recherche 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> 
> Tel: +352 424409 1
> Fax: +352 422473
> 
recipient's key
> is known to me