RADIUS EXTensions
charter-ietf-radext-07
Yes
(Kathleen Moriarty)
No Objection
(Alvaro Retana)
(Deborah Brungard)
(Joel Jaeggli)
(Martin Stiemerling)
(Stephen Farrell)
(Terry Manderson)
- Ready for external review (04-04)
- Ready for external review (05-00)
- Ready for external review (06-01)
- Approve (06-03)
Note: This ballot was opened for revision 05-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
Jari Arkko Former IESG member
Yes
Yes
(2015-07-08 for -05-01)
Unknown
Question. Will NASes be running a normalisation process for EAP identities, and if, so, do they need any context information, or is all information that they need in the EAP packets?
Kathleen Moriarty Former IESG member
Yes
Yes
(for -05-01)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -05-01)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2015-07-07 for -05-01)
Unknown
I agree with Benoît's suggestion about the intended status of the documents. "Verbatimly"? I suppose we can make up adverbs on the fly, but you might consider just deleting that (non-)word as unnecessary.
Ben Campbell Former IESG member
No Objection
No Objection
(2015-07-08 for -05-01)
Unknown
My comments have all already been made by others.
Benoît Claise Former IESG member
No Objection
No Objection
(2015-07-06 for -05-01)
Unknown
Editorial improvement: Remove "Furthermore" in the second paragraph.
Instead of duplicating the RFC type ( "This will be a standards track document.") in the charter and the milestones , consider mentioning it only in the milestones ("Nov 2016 - Data Types as Informational RFC")
advantage #1: strong AD advice, it can still be changed if the WG has got a good reason
advantage #2: it avoids discrepancies between the charter text and the milestones. Look at the data types document :-)
Brian Haberman Former IESG member
No Objection
No Objection
(2015-07-08 for -05-01)
Unknown
2119 keywords in a charter?
Deborah Brungard Former IESG member
No Objection
No Objection
(for -05-01)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -05-01)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -05-01)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-07-09 for -05-02)
Unknown
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.
Stephen Farrell Former IESG member
No Objection
No Objection
(for -05-01)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -05-01)
Unknown