Ballot for charter-ietf-radext
Block
Yes
No Objection
No Record
Summary: Has 2 BLOCKs. Has enough positions to pass once BLOCK positions are resolved.
Ballot question: "Is this charter ready for external review?"
I support Roman's block here for the reasons he states. The statement "support the work of those organizations": - Inverts the normal relationship between the IETF and external bodies (the IETF produces standards; others may choose to adopt them) - Could be used to justify work items that lack genuine IETF community consensus by claiming external demand - Is inconsistent with RFC 2026 and BCP 9 principles of individual participation Secondly, none of the work items specifies an intended publication type (PS, BCP, Informational, or Experimental). Eric noted he was about to block on this issue. You could say I am enabling that. Finally, the four multi-hop work items, the roaming best-practices document, and the minor extensions work all require different tracks (likely PS for protocol extensions, BCP for best practices).
Paragraph 1 > To ensure backward compatibility with existing RADIUS implementations, > as well as compatibility between RADIUS and Diameter, all documents produced must specify > means of interoperation with legacy RADIUS. Any non-backwards compatibility changes > with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673, > 4675, 5080, 5090, 5176, 6158, 6929, 8044 and the RadSec RFC (when published) must be justified. The existing RADIUS/TLS RFC (RFC 6614) and RADIUS/DTLS RFC (RFC 7360) are absent from the backward-compatibility list — if the bis supersedes them, the list should be updated to reflect that.
** Working on behalf of other organizations. The charter says: “The radext WG will publish minor RADIUS extensions, best-practices documents and clarifications, as needed to support the work of those organizations.” “Define and publish minor extensions to RADIUS, such as new attribute definitions, needed by external organizations or other IETF WGs.” I’m not sure what the inclusion of these statements is intended to do regarding scope or process, but it was unexpected and seems to suggest an alternative to the current standards process of consensus and participation as individuals. -- The introductory text says that this WG will focus on maintenance of RADIUS. The above text caveats working on extensions on behalf of others in the first clause. Is this suggesting that WG couldn’t self-initiate extension work? -- How is the standards process guiding the WG changed at all by the fact that an outside group needs an extension? -- How are these organizations given standing to ask for extension (e.g., who gets to ask since this is a scope criteria)? Typically, a decision to do work (e.g., an extension) and publish is done via WG (and then later IETF) consensus. What’s the alternative being proposed here? Even if the request came from another IETF WG, the same procedures would apply (i.e., there would need to be consensus in RADEXT to do the work). Could the intended scope of work be written as follows: OLD “The radext WG will publish minor RADIUS extensions, best-practices documents and clarifications, as needed to support the work of those organizations.” NEW The radext WG will publish minor RADIUS extensions, best-practices documents and clarifications. OLD “Define and publish minor extensions to RADIUS, such as new attribute definitions, needed by external organizations or other IETF WGs.” NEW Define and publish minor extensions to RADIUS.
* In what way is this text providing scoping: “Information from operators shows that anywhere from 20% to 90% of authentications are for accounts which are always rejected.”? Is this a target that the future solution from need to improve upon directly written into the charter text? What, if anything, would be lost if it was removed? * Significant new scope has been added. What are the associated milestones?
Hi all, Thanks for the charter refresh to keep maintenance of this important technology for many operations. Please find some few comments below: # Not all RADIUS attributes are/will be defined in RADEXT CURRENT: Define and publish minor extensions to RADIUS, such as new attribute definitions, needed by external organizations or other IETF WGs. I think that we need some text that says (and which actually reflects the practice so far), that RADIUS attributes can be defined in the WGs that own the technololgy. RADEXT will be responsible for reviewing those. # (nit) As this is a long-life maintenance, I would make this change: OLD: The immediate goals of the RADEXT working group are to: NEW: The goals of the RADEXT working group are to: For example, defining new attributes defines that there is actually a need for it. Which is not "immediate". # (nit) The formatting of sub-bullet is broken. # Not sure I would keep the following in the charter CURRENT: Information from operators shows that anywhere from 20% to 90% of authentications are for accounts which are always rejected. Cheers, Med
I agree with Eric's comment on stating the intended publication status of all work items.
Just a couple of easy suggestions: Para 2: Spell out WBA, and remove 'as needed to support the work of those organizations'. Para 3: I think the sentence that starts, 'Any non-backwards compatibility...' could be streamlined by removing the long list of RFCs, leaving 'Any non-backwards compatibility changes with existing RADIUS RFCs, including the RadSec RFC (when published) must be justified.' Work items: Some of these could be turned into milestones. I have no earthly idea what a 'roaming consortia' is, hopefully the working group knows.
Thanks for doing the rechartering as RADIUS is important. Some minor comment though: - introduce the WG acronym at the beginning - expand WBA (and provide a reference ?) - the 2nd level bullet list is wrongly formatted as it appears as first level - s/The immediate goals of the RADEXT working group/The goals of the WG/ - unsure whether `Information from operators shows that anywhere from 20% to 90% of authentications are for accounts which are always rejected.` belongs to a charter rather than in a draft introduction/justification *I am trusting the responsible AD to formally state the intended publication status of all work items (I was about to BLOCK on this issue).*