Subject: RE: [AAA-WG]: Text needed for: Applicaiton ID in the header

From: "Pat R. Calhoun" <[email-masked]>
Date: Tue, 2 Jul 2002 06:11:44 -0700

> As vendors & carriers are all involved in this process in 3GPP, it
> may be enough for 3GPP specific networks - but I think we need to
> bring the 3GPP specifications into the IETF to ensure interoperability
> with the Internet.  I think we just need a good plan on how to do this.

And of what value would this be to 3GPP? What are the chances that the IETF
rubber stamps their spec without any modifications? How willing to change
their
"blessed" standard from comments received from folks in the IETF?

Seems like a nightmare situation to me :(

PatC

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Jul 2002 12:01:18 +0300

Hi John,

> with the Internet.  I think we just need a good plan on how to do this.

That's a nice goal.

But on closer look, I'm really unsure what it means. Let's think
about possible meanings of your words "interoperability with the Internet"
above:

1. It means that the 3GPP specifications MUST use the base protocol as it is,
    don't break the protocol, etc. [And as Miguel pointed out, 3GPP is being
    a good citizen by doing this.]

2. It means that the 3GPP specifications MUST NOT have any other features
    than those already available in the "Internet". For instance, if
    the IETF specifications only support dial-in authentication, then
    3GPP should not offer anything else than dial-in authentication.
    [I hope we are not debating about this.]

3. It means that the 3GPP specifications can have new features, but those
    features MUST be released in a lock-step with the IETF, and both parties
    MUST run the full standardization process through before the result is usable.
    For instance, shouldn't release a multimedia system before there's a standard
    IETF multimedia AAA protocol. [Hmm...]

4. It means that the 3GPP specifications can have new features even before they
    are IETF standards, but we need a transition plan to get back to a single
    standard by the time IETF produces a specification of the same thing. [E.g.,
    multimedia aaa.]

It seems to me that we, the WG and other SDOs have been assuming model 1 is good
enough. It also looks to me that Randy would like to be in model 3, but he realizes
the time pressures and wants to allow model 4 [forgive me if I didn't read you
correctly].

So, what should we do? I think this debate is less about the specific technical
mechanisms than the higher-level approach. I actually think the original Diameter
VSC and VSA rules are excellent technical solutions. They also work very well
if one assumes that many different AAA applications are really needed. If one
assumes that only few applications are needed and fears that there will be competing
vendor-specific schemes even for these applications -- then they might not
be perfect.

I think the WG still follows the former assumption, and would like to have model 1.
However, if we take the latter assumption and try to establish model 4, then one
way to deal with the above concerns is to retain the original protocol mechanisms,
but add a rule that VSCs that do not belong to a IANA registry MUST NOT be accepted
i.e. lead to a specific error code. Then the rules for the IANA registry will be
something like "Expert Review, resulting in a registration with a specific lifetime".
This would ensure that apps developed due to temporary lack of an internet standard
would time out, and the standard would replace the VSCs later.  The lifetimes need
to take in account the time to develop an internet standard for the thing
AND the time needed to upgrade all the equipment in the network to support this
new standard. Finally, it would be good to have text that says new Diameter implementations
MUST support an Internet standard Diameter extension, if the standard is available AND
they support an earlier VSC for the same application. This is needed during the
transition period.

Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 3 Jul 2002 11:15:30 -0400

Hi,

>    standard by the time IETF produces a specification of the same thing. 

I have a transition plan in my mind.  During the transition period,
just assigning two different values for the same command name, i.e.,
one is assigned from the temporal space and another is assigned from
the standard space, and the implementation interprets both values 
as that command name.  Very simple.  An issue is how long the 
transition period should be.  Not too long not to short.

I believe this is the win-win solution between IETF and other SDOs,
and the VSC approach does not outperform this approach in terms of
interoperability.  (VSA is different, I agree that we need VSA to
carry vendor-specific information and does not affect interoperability
so much.)

> they support an earlier VSC for the same application. This is needed during 

Yoshihiro Ohba