|
In general, it is the job of the editor to work with the Issue filters to resolve review comments. While it is possible to issue a formal WG consensus call to resolve contentious issues, it is neither practical or necessary to go through this process for each of the open issues. We have already had to engage that formal consensus process twice -- and that proved to be extremely time consuming. In looking at the open issues, in most cases the remaining areas of dispute are relatively minor, so that they are readily resolvable between the editor and the Issue proposers. In one or two cases the issues are more substantial, but discussion has not yet clarified the problem. In these situations more discussion is probably required. Here is my take on where each of the current open issues stands and what could be done to move things along. Given the current status, it is hard to see why the majority of these issues could not be closed by the IETF 74 submission deadline.
Issue 225 -- It would appear that the major point of contention here relates to the length field and fragmentation. I believe that this comment could be resolved by addition of some advice (a SHOULD might suffice) on fragmentation usage for senders and support on receivers. The ability to include multiple attributes inside a VSA was allowed in RFC 2865, and so should not be a subject of dispute for this document. Given that this issue is nearly resolved, I would suggest that you and Alan work out appropriate text. Issue 251 -- This relates to the need for IANA considerations text. I can post a suggestion. Issue 278 -- The remaining portion of this issue relates to whether IANA can allocate Extended Attributes 0-255, and if by doing so, confusion would be created with respect to existing RADIUS attributes. What is interesting about this discussion is that it only arose once the size of the type field was expanded to 16 bits. In general, we have not seen confusion relating to use of VSAs with Type Code values which overlap the standards range (which most do). For example, do people confuse Example.com VSA #32 with the RADIUS NAS-Identifier attribute (32)? Maybe this issue could be resolved by suggestion of appropriate nomenclature. For example, the term "<Attribute name> Extended Attribute (#)" instead of today's usage "NAS-Identifier Attribute (32)". Issue 279 -- Stefan has made concrete suggestions for resolving the remaining aspects of this issue. My suggestion would be to either incorporate them or make a counter-proposal. Issue 290 -- This relates to the issue of Diameter support for non-standard VSA formats (which this document now uses). During IETF 73, we discussed one potential avenue for addressing this, which would be to update RFC 4005 to enable use of Diameter AVP 26 for translation of RADIUS VSAs of non-standard type. This document would then normatively reference RFC 4005bis for a discussion on translation of Extended Attributes. Dave Mitton has expressed interest in working on the RFC 4005 revision, so my suggestion would be to work with him on that. Issue 298 -- This issue relates to whether Extended Attributes are treated like VSAs or not. For implementations of this document, the answer is probably "no" -- they are treated like any other standard attribute. However, for implementations that don't support Extended Attributes, the answer is probably "yes" -- which has implications for Accounting-Responses (where VSAs are permitted, but few standard attributes) and Disconnect-Responses (where VSAs may only be used for session identification). So one question is whether this implies that a NAS should signal its support for Extended Attributes in the Access-Request in some way -- so as to make it clear to the RADIUS server how those attributes would be interpretted. Given that the implications of this issue (and therefore consensus) are still somewhat unclear, my recommendation would to continue discussion in hope of achieving clarity. Glen Zorn said: > Hi, guys. I would _really_ like to get this draft done, but none of the > outstanding issues are owned by myself & the issue owners haven't been very > forthcoming w/text. So, in the interest alacrity, could I talk you into > doing a little more Chair-stuff? Specifically, if you have comprehended WG > consensus on any/all of the issues, can you provide editing instructions to > me so that the issues may be closed & the document progressed? TIA! |