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

From: Benoit Claise <[email-masked]>
Date: Tue, 03 Feb 2015 13:54:15 +0100

Hi Kathleen,

Can you please let us know if your DISCUSS is solved.

Regards, Benoit
> 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ó:
>> 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
>>
>>> 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.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> radext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/radext
>>> .
>>>
>>
>
> .
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 9 Feb 2015 18:23:18 -0500

Sorry, I didn't see this as the thread was on Pete's Discuss.  I'll take a
look now.

Thanks,
Kathleen

On Tue, Feb 3, 2015 at 7:54 AM, Benoit Claise <[email-masked]> wrote:

>>> 1. Update RFC 2865: Remote Authentication Dial In User Service (RADIUS)
>>> and RFC 6158: Radius design guidelines
>>> 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
>>> 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.
>>> 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.
>>>
>>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.
>>>> html
>>>>     "T" flag allocation would not persist, as it is tightly associated
>>>> to
>>>>     this document.
>>>>
>>>> I really don't think this document needs to, or should, update the other
>>>> violates a MUST and a SHOULD. But it's an experiment. Any implementation
>>>> reserved value, but as you say in the document: "not such a great number
>>>> document goes to Standards Track, that's the time to let people know. If

-- 

Best regards,
Kathleen