Ballot for charter-ietf-radext
Yes
No Objection
Note: This ballot was opened for revision 05-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
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?
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.
My comments have all already been made by others.
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 :-)
2119 keywords in a charter?
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.