It's all in the timing...

["Nelson, David" <dnelson@enterasys.com>]

I have a general concern, or meta-issue, to raise regarding the WGLC of
draft-ietf-radext-ieee802-00.txt.  The VLAN, Priority and Filtering
Attributes draft proposes new RADIUS attributes of base data type String
(Octet String) that are, in fact, multi-field structures a.k.a. complex
data types.  The prose of the draft describes the content and
delimitation of the various fields.  This seems clear enough.

My concern is that RADEXT is prepared to send this draft to the IESG for
approval and publication before another WG work item, Design Guidelines
for RADIUS Attributes, has been completed.  My sincere thanks go to Greg
Weber for stepping up to work on this document.  The new attributes
specified in the VLAN, Priority and Filtering Attributes draft may very
well fall within the design guidelines that are eventually set for
complex data types in Design Guidelines for RADIUS Attributes.  However,
if they are not, then RADEXT will be in the position of publishing a
Standards Track RFC that introduces attributes that do not follow its
own design guidelines.  IMHO, this would be a Very Bad Thing (tm).  It
would be at least inconsistent and at most down right embarrassing.

My frustration is that I don't see a good solution.  The Design
Guidelines for RADIUS Attributes must be given time to mature and obtain
consensus.  It does not seem reasonable to delay the VLAN, Priority and
Filtering Attributes draft until the design guidelines are ready.  I
guess the best I can hope for is that work on the design guidelines
progresses rapidly, and that any substantial disconnects between the
design guidelines and the VLAN, Priority and Filtering Attributes draft
can be reconciled before it goes out for IETF Last Call.

Other suggestions are more than welcome...

The WG's initial schedule, as captured in the charter, was to complete
the design guidelines work early on.  Had that happened as planned, this
sort of dependency problem would not have arisen.  But we are where we
are.

-- Dave


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>