Re: RADEXT WG Charter, Take 10

[Jari Arkko <jari.arkko@piuha.net>]

Hi Dave,

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

I think we agree on the general requirement. I guess
how specific the charter gets in this matter is a matter
of taste and judgement. My opinion of making it very
specific was based on technical and process views that
I explain below.

The technical views are that application translation is best
handled in an application specific way rather than as
a generic translation document, and that attribute-only
applications should work as-is. The process view is that
I'd like to have the translation available at the time
when the RADIUS application is published rather than
later (which also implies that translation design can
have an effect in the application design.)

Of course, most of this can take place even if the
charter just includes the general statement. But if the
charter includes a specific work item for translation,
however, it seems to imply a separate document rather
than a section.

> > 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)?

Yes. (Indeed, this is not a very hard requirement.)
Conflicts with existing AVPs are one possible problem.
I can't list other problems, but I can't guarantee
that there aren't any.

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

Ok.

> > f. Specify what the Digest work has to be compatible
> >    with (RFC 2617/3261/3310).
>
>
> Could you please elaborate a little on this?

Digest has been originally defined in RFC 2617
for HTTP. It has since then applied in SIP context
in RFC 3261, and in addition to the original MD5
algorithm, a new algorithm was defined in RFC 3310.
In some cases products have to support all of them.
I think whatever RFC we make for RADIUS SIP/Digest
support, it should be compatible with these RFCs.

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

Yes.

Btw, I think charter 10 had a general compatibility
*requirement*:

> - All RADIUS work MUST be compatible with equivalent facilities in
>   Diameter.

But it lacks the *work item*, from charter 8:

> - RADIUS/Diameter translation.  This document will describe the
>   best current practices for RADIUS/Diameter translation.

Personally, I think per-application (e.g. prepaid) translation
discussion would be more appropriate. But it may also be
that I have misunderstood the item, and the specific translation
discussion is still in the applications and this is just some
general discussion & guidelines document?

--Jari

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