Subject: Re: [radext] AD review of https://www.ietf.org/id/draft-ietf-radext-datatypes-04.txt

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 3 Aug 2016 10:33:16 -0400

Hello,

Is there any chance we could get the abstract updated so I can put
this in IETF last call in time for the telechat in 2 weeks?  That
means the update would be needed by today.

Thank you,
Kathleen

On Thu, Jul 28, 2016 at 2:52 PM, Kathleen Moriarty
<[email-masked]> wrote:
> Hi,
>
> Sorry I didn't see this sooner.  In reading the shepherd report, I see
> that the abstract should also list the RFCs this updates.  Could that
> be added and then I'll kick off last call?  I'll put it on the
> telechat in 3 weeks now.
>
> On Tue, Jul 19, 2016 at 12:17 PM,  <[email-masked]> wrote:
>> Hi,
>>
>> Would it better to add (or repeat) such clarifications in the IANA considerations section?
>
> I think it's fine to refer back to a single location since there are
> no changes.  It's a rather complex IANA section.
>>
>> As a new version (simple update so far) is required anyway, I think it is OK to wait for this new version and launch the IETF LC with a normal 2-week period at least the next week (or ASAP after publication of the draft).
>
> OK, thanks!  I'll start last call as soon as the abstract fix is in as
> that should be very simple and I'd rather avoid more people commenting
> on the same thing.
>
> Thanks,
> Kathleen
>
>>
>> Regards,
>>
>> Lionel
>>
>>> -----Message d'origine-----
>>> De : radext [mailto:[email-masked]] De la part de Kathleen Moriarty
>>> Envoyé : mardi 19 juillet 2016 17:43
>>> À : Alan DeKok
>>> Cc : [email-masked]
>>> Objet : Re: [radext] AD review of https://www.ietf.org/id/draft-ietf-radext-
>>> datatypes-04.txt
>>>
>>> Hi Alan,
>>>
>>> Thanks for the quick response. inline.
>>>
>>> On Tue, Jul 19, 2016 at 11:20 AM, Alan DeKok <[email-masked]>
>>> wrote:
>>> > On Jul 16, 2016, at 10:48 PM, Kathleen Moriarty
>>> <[email-masked]> wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> Thank you for another very well written draft that serves a clear
>>> >> purpose and is easy to read and understand.  I just have 2 questions
>>> >> that should be really easy and then would like to know when the WG
>>> >> prefers me to start IETF last call.  And if you'd like IETF last call
>>> >> to start this week, should it be extended for a 3rd week?
>>> >>
>>> >> Comments/questions:
>>> >> Section 2.1.1
>>> >> Should this say "be of a valid data type"
>>> >>  Attr-Data
>>> >>
>>> >>         The "Value" field of an Attribute as defined in [RFC2865]
>>> >>         Section 5.  The contents of this field MUST be a valid data
>>> >>         type as defined in the RADIUS Data Type registry.
>>> >
>>> >   I'm fine with the change.  I'm not sure it makes a substantive change, tho.
>>>
>>> Thanks.
>>> >
>>> >> IANA Section 4.2
>>> >> Does the registration policy remain unchanged from rfc3575?
>>> >
>>> >   Yes.
>>> >
>>> >>  If so, it
>>> >> would be helpful to state that since 4.1 defines the registration
>>> >> policy as requiring IETF review,
>>> >
>>> >   The intent there is that new data types requires IETF review with Standards
>>> Action.  It doesn't change the registration requirements for the RADIUS
>>> attributes registry.
>>> >
>>> >    Maybe this is clearer:
>>> >
>>> > This section defines a new RADIUS registry, called "Data Type".
>>> > Allocation in this registry requires IETF Review.  The "Registration
>>> > Procedures" for the Data Type Registry are "Standards Action".
>>> >
>>>
>>> I'm fine with the text you have my question was about 4.2, but included the
>>> above for context on the question.
>>>
>>> >
>>> >> different from what happens for 4.2
>>> >> according to the description in rfc3575.
>>> >
>>> >  OK.
>>> >
>>> >   Maybe adding text here would be good:
>>> >
>>> > The existing registration requirements for the Attribute Type Registry
>>> > are unchanged.
>>>
>>> Perfect, thanks.
>>>
>>> Kathleen
>>>
>>> >
>>> >   Alan DeKok.
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>> _______________________________________________
>>> radext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/radext
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
>
>
>
> --
>
> Best regards,
> Kathleen

-- 

Best regards,
Kathleen