[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Proposed Resolution to Issue 180: Misuse of Data Types



Bernard and Glen stated: 

> Bernard Aboba <> supposedly scribbled:
> 
> > The text of Issue 180 (and some of the subsequent discussion) is 
> > enclosed below.
> > 
> > The proposed resolution is to change "VLAN Tag" to "VLAN Flag"
> > everywhere in the document. 
> 
> Sounds reasonable to me.

I concur. 

> 
> > 
> > In looking at the mailing list discussion, I did not detect 
> consensus 
> > for making other changes.
> 
> Although I don't think that the discussion is altogether 
> complete, I would agree with your assessment of its progress thus far.

We've got a chicken and egg problem here.   Agreement on what to do with
complex/compound/whatever-you-want-to-call-them RADIUS attributes is not
going to get solved using the VLAN draft as the vehicle.  It's something
that Dave pointed out is best addressed in design guidelines draft.
Yet, the design guideline draft and its associated discussion are only
really going to happen after the VLAN draft milestone.  

While I do agree that it would be admirable if we could come to a
suitable general solution to the data problem, I don't think we're going
to get to one quick enough.  It does appear, however, that people do
agree that the past design behavior for RADIUS attributes, while ad-hoc
and non-optimal, has worked so far.  

Can we agree, with whatever associated cringing, and accept the current
state of the VLAN draft data types as acceptable?  They are at best a
continuation of the ad-hoc design legacy and at worst an ugly wart that
will stand out once clear design guidelines are defined.  I don't think
anyone can pragmatically disagree that going forward with the VLAN
draft's data types will cause insurmountable pain to implementers. It's
only business as usual for RADIUS.

My vote is to accept the draft as is on this matter.

Cheers,
MS


--
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/>