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

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 16 Jul 2016 16:48:43 -0400

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.

IANA Section 4.2
Does the registration policy remain unchanged from rfc3575?  If so, it
would be helpful to state that since 4.1 defines the registration
policy as requiring IETF review, different from what happens for 4.2
according to the description in rfc3575.

-- 

Thank you.

Best regards,
Kathleen

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jul 2016 17:20:25 +0200

>         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.

> IANA Section 4.2
> Does the registration policy remain unchanged from rfc3575?

  Yes.

>  If so, it
> 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". 

> different from what happens for 4.2

 OK.

  Maybe adding text here would be good:

The existing registration requirements for the Attribute Type Registry
are unchanged.

  Alan DeKok.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 19 Jul 2016 11:42:45 -0400

Hi Alan,

Thanks for the quick response. inline.

>   I'm fine with the change.  I'm not sure it makes a substantive change, tho.

Thanks.
> 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.

> The existing registration requirements for the Attribute Type Registry

Perfect, thanks.

Kathleen

-- 

Best regards,
Kathleen

---

From: <[email-masked]>
Date: Tue, 19 Jul 2016 16:17:26 +0000

Hi,

Would it better to add (or repeat) such clarifications in the IANA considerations 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).

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,
> 
> > On Jul 16, 2016, at 10:48 PM, Kathleen Moriarty
> <[email-masked]> wrote:
> >>
> >> Hello,
> >>
> >   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:
> >
> I'm fine with the text you have my question was about 4.2, but included the
> above for context on the question.
> 
> >
> _______________________________________________
> 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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 Jul 2016 14:52:33 -0400

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.

> 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 pu…

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

-- 

Best regards,
Kathleen