Subject: [radext] Pete Resnick's Discuss on draft-ietf-radext-radius-fragmentation-11: (with DISCUSS)

From: "Pete Resnick" <[email-masked]>
Date: Wed, 21 Jan 2015 22:15:16 -0800

Pete Resnick has entered the following ballot position for
draft-ietf-radext-radius-fragmentation-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have no concerns with the technical content of the document; I did a
quick review, and nothing causes concern. But I do want to briefly
DISCUSS a procedural point. I am quite sure I will clear the DISCUSS on
the call.

The issue of "Updates" worries me a bit. Here's the part that concerned
me:

   Note that if this experiment does not succeed, the
   "T" flag allocation would not persist, as it is tightly associated to
   this document.

That's true, but using Updates will mean that RFC 6929 will *always* have
an "Updated By" pointer pointing to this Experimental RFC. That itself
could cause serious confusion, and would likely result in the "T"
allocation never being able to be used again.

I really don't think this document needs to, or should, update the other
documents. 2865 and 6158 are only being updated because this document
violates a MUST and a SHOULD. But it's an experiment. Any implementation
of 2865 or 6158 not participating in the experiment is going to need to
honor those MUSTs and SHOULDs. There's no real reason to call out this
update to people who are only looking at those two documents. 6929 is a
bit trickier, because of the issue of other folks trying to use the
reserved value, but as you say in the document: "not such a great number
of specifications extending that field are expected." If/when this
document goes to Standards Track, that's the time to let people know. If
there's a real fear of this experiment interfering with other
implementations, it really is time to make the registry. Finally, I'm
concerned about the precedent of Experimental documents updating
Standards Track and BCP docs, especially on the grounds provided. Perhaps
there's a case for that to happen once in a while, but we don't want
pointers to possibly failed experiments to be in the meta-data forever.

Like I said, we can sort this on the call pretty quickly. But I want to
make sure we understand the implications here.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 22 Jan 2015 12:39:05 +0100

Hi Pete,

For completeness, this was discussed on the RADEXT mailing list.
See http://www.ietf.org/mail-archive/web/radext/current/msg09079.html
Let's discuss during the IESG telechat.

Regards, Benoit
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
> .
>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 22 Jan 2015 19:21:11 +0100

Dear all,

This document was discussed during the IESG telechat today.

There are 2 "update" types.

1. Update RFC 2865: Remote Authentication Dial In User Service (RADIUS) 
and RFC 6158: Radius design guidelines
The question is: when an experimental RFC violates sentences from a 
standard track doc, do we want a forward pointer to that EXP RFC? The 
discussion went in the direction of not "updating" the standards RFCs. 
This is an experiment after all.

2. Update RFC 6929: Remote Authentication Dial-In User Service (RADIUS)  
Protocol Extensions
Here we have the issue of the T flag assignment.
The IESG understands that this document effectively allocates a bit from 
the structure in RFC 6929.
We evaluated multiple options: registry, "update" and then requiring yet 
another RFC if the experiment fails, no update.
In the end, the propose solution is that this experimental RFC should 
not "update" RFC 6929. We should rely on the collective mind of the WG 
to recall that this T flag is used. When/if the experiment will be 
successful, the T flag will be properly assigned.

So the next step is to publish a new revision without the 3 "updates", 
and including Kathleen's DISCUSS.

Thanks and regards, Benoit

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 27 Jan 2015 11:19:50 +0100

Dear Benoit,

a new version has been submitted including the requested changes.

Best regards,
Alejandro

El 22/01/15 a las 19:21, Benoit Claise escribió:
> 1. Update RFC 2865: Remote Authentication Dial In User Service 
> (RADIUS) and RFC 6158: Radius design guidelines
> 2. Update RFC 6929: Remote Authentication Dial-In User Service 
> (RADIUS)  Protocol Extensions
> The IESG understands that this document effectively allocates a bit 
> from the structure in RFC 6929.
> We evaluated multiple options: registry, "update" and then requiring 
> yet another RFC if the experiment fails, no update.