Subject: [radext] Spencer Dawkins' No Objection on charter-ietf-radext-05-02: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 09 Jul 2015 06:32:39 -0700

Spencer Dawkins has entered the following ballot position for
charter-ietf-radext-05-02: No Objection

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

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-radext/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This text is garbled:

    When a	
 	NAS is simply performs an exact copy of an EAP-Identity into a
User-Name,	
 	invalid packets might be produced.
    
In this text:
    
 	- Data Types. RFC 2865 defines a number of data types, but later	
	  documents do not use those types in a consistent way.  This work
item	
      will define data types, and update the IANA RADIUS Attribute Type	
 	  registry so that each attribute has a data type.  Where necessary,
it	
 	  will correct issues with previous specifications.  This will be a	
 	  standards track document.
      
I'm not understanding if there are are constraints about backward
compatibility between data types from this work and RFC 2865. If that's
unknown, or obvious, that's fine, of course.

In this text:

 Larger Packets. Support RADIUS packets greater than 4096-octets over	
 RADIUS transports with this capability.
 
Is this doing anything that would benefit from TSVWG review? I'm guessing
not, but wanted to ask.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 9 Jul 2015 09:57:26 -0400

> unknown, or obvious, that's fine, of course.

  The data types are wire compatible, and have identical meaning to those defined in RFC 2865.  The spec is required because data types are being promoted to well-defined, and IANA managed entities.  This spec has no impact on existing implementations.  It mainly affects how RFCs are written.

> Is this doing anything that would benefit from TSVWG review? I'm guessing

  The large packet support is limited to RADIUS over TCP.  So it's just more application data over TCP, which means TSVWG review is probably unnecessary.

  Alan DeKok.

---

From: <[email-masked]>
Date: Thu, 9 Jul 2015 13:59:18 +0000

Hi Spencer,

please below.

regards,

Lionel

-----Message d'origine-----
De : radext [mailto:[email-masked]] De la part de Spencer Dawkins
Envoyé : jeudi 9 juillet 2015 15:33
À : The IESG
Cc : [email-masked]
Objet : [radext] Spencer Dawkins' No Objection on charter-ietf-radext-05-02: (with COMMENT)

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

This text is garbled:

    When a	

[LM] obviously, the text should be: "When a NAS simply performs an exact copy of an EAP-Identity into a User-Name, invalid packets might be produced."
    
In this text:

I'm not understanding if there are are constraints about backward compatibility between data types from this work and RFC 2865. If that's unknown, or obvious, that's fine, of course.

[LM] There is no backward compatibility issues. It is more about clarifying the data type used for each existing attribute (to avoid some ambiguities) and update accordingly the current attribute type registry to add a new column with the data type. And this will be also useful for the creation of new attributes.

In this text:

Is this doing anything that would benefit from TSVWG review? I'm guessing not, but wanted to ask.

[LM] Not sure to understand why there would be the need for a specific review of TSVWG, which might be anyway be involved during the IETF last call.  For clarification, in the present case, we are not over UDP but over TCP

_______________________________________________
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: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 9 Jul 2015 09:14:29 -0500

I also saw Alan's response ... thanks for both.

On Thu, Jul 9, 2015 at 8:59 AM, <[email-masked]> wrote:

> Objet : [radext] Spencer Dawkins' No Objection on
> charter-ietf-radext-05-02: (with COMMENT)
>
> [LM] obviously, the text should be: "When a NAS simply performs an exact
> copy of an EAP-Identity into a User-Name, invalid packets might be
> produced."

Thanks.

> [LM] There is no backward compatibility issues. It is more about
> clarifying the data type used for each existing attribute (to avoid some
> ambiguities) and update accordingly the current attribute type registry to
> add a new column with the data type. And this will be also useful for the
> creation of new attributes.

That wasn't clear to me (both documents were defining data types). Saying
that this work is clarifying, rather than defining, would be clearer.

> [LM] Not sure to understand why there would be the need for a specific
> review of TSVWG, which might be anyway be involved during the IETF last
> call.  For clarification, in the present case, we are not over UDP but over
> TCP

That's what I hoped. My reason for asking was to avoid late surprises that
could happen earlier :-)

Thanks,

Spencer

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 9 Jul 2015 10:18:55 -0400

Thanks for the catch, Spencer...

>> copy of an EAP-Identity into a User-Name, invalid packets might be

This has been fixed and I am responsible for the wording, thanks for
catching it!

I think the charter now addresses all comments.
Kathleen

-- 

Best regards,
Kathleen