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

RE: RADEXT WG Charter, Take 10



Jari Arkko writes...

> ... But the original proposal from
> me was not exactly that. It was a group of things:
> 
> a. Have the name reflect the already agreed scope.

It appears that there is no consensus to change the name, because the
current proposed name, RADEXT, does reflect the agreed scope.  While
there are constraints on the RADIUS work items, to address Diameter
compatibility, there does not seem to be consensus to do any
Diameter-only work in the proposed WG.  Does that sound right?

> c. Delete separate item for R/D compatibility and
>     handle that per application, in the work items.
>     Add specific text to this effect.

I'm not sure why a general compatibility requirement is not sufficient.
While the exact nature of the compatibility provisions in each draft may
vary by application, it would not seem to be necessary to "outline" the
specific form in the charter -- only to require its presence.  The
specific form of the compatibility provisions, to meet the general
requirement, ought to be part of the WG's work product. Or so it seems
to me, anyway.

> d. Add a requirement that when plain attributes are
>     added (as in LAN), they should be directly R/D
>     compatible.

Hmm...  Can you give an example of a "plain" attribute that would not
automatically be directly compatible (unless, of course it conflicted
with an existing Diameter AVP)?

> e. Change the description of 2486bis a bit to
>     include fixing errors and handling privacy.

This seems reasonable.

> f. Specify what the Digest work has to be compatible
>     with (RFC 2617/3261/3310).

Could you please elaborate a little on this?

<snip>

> So where does that leave us? None of my proposals
> got into version 10 of the charter, except point
> c sort of half-way: R/D item was deleted from the
> charter but not replaced by a requirement to have
> a Diameter Translation Considerations section :-(

I tend to think that some general level of Diameter compatibility
requirement should be added back into the charter.

> I still do believe points c through f are important
> technical requirements to state in the charter, and
> I did not see an opposition for these points -- can
> we include at least them in the version 11?

See comments, above.

> Regarding points a and b I don't know what to
> do. I still think its important, but I'm getting
> tired of arguing. Would it help to ask the issue
> again, making it clearer what the proposal is
> (i.e. no scope extension)?

I think that the focus is clear from the discussion on the list, and the
name probably appropriate, given that the scope of work does not include
new Diameter work.  Diameter compatibility is required (in some
appropriate fashion) and the WG name doesn't change that, IMHO.

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