Subject: [AAA-WG]: Issue 89: Editorial comments - Mobile-IP draft-06

From: "Martin Julien (ECE)" <[email-masked]>
Date: Mon, 25 Jun 2001 10:04:07 +0200

Submitter name: Martin Julien
Submitter email address: [email-masked]
Date first submitted: 25-Jun-2001
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01446.html
Document: mobileip-06
Comment type: E
Priority: 1
Section:  2.1, 2.2, 2.3, 2.4, 3.1, 4.0, 4.7, 5.1, 6.0, 10.4
Rationale/Explanation of issue:

Requested change:

> > 1) Section 1.2, on top of page 7, I was wondering if it would be better
> > to use the DIAMETER_ERROR_AUTH_FAILURE defined in the MIP draft,
> > or to re-use the one already defined in the Base draft? The one in the
> > Base could possibly be more generic, what do you think?
>
> I agree, and an issue should be opened.

I think it would make more sense, since there is already an authentication
error in the Base that seems, at this point, only used for the NASREQ app.

> > 2) Section 2.1, I guess we could mention that the MN-AAA
> > Authentication Extension information is carried by the
> > (MIP-MN-AAA-Auth AVP), and that the Foreign Agent Challenge
> > Extension information by the (MIP-FA-Challenge AVP).
>
> that would be useful.
>
> > 5) Section 2.2, the command-code should be 260, instead of 261.
> >
> > 6) Section 2.2, in the message format, should the
> > MIP-HA-to-FA-Key AVP be included as [], in the case where the
> > the Multi-Round-Auth is used?
>
> hmmmm.... agreed.
>
> > 7) Section 2.3, could we add the [MIP-Feature-Vector] as a possible
> > AVP of the HAR message, since I see it very useful in the case where
> > the AAAF needs to allocate an Home Agent in the foreign domain?
>
> yes, I agree.
>
> > 8) Section 2.4, I don't think it is very clean, with regards to the
> > specification, to expect that the HA will be responsible of
> forwarding the
> > Session-Timeout, the Authorization-Lifetime, the
> MIP-FA-to-MN-Key and the
> > MIP-FA-to-HA-Key AVPs in the HAA. When I see those attributes
> in the HAA,
> > I always have to remind me that they are meaningless to the
> HAA, but only
> > meaningful to make easier the conversion of the HAA into a AMA in the
> AAAH,
> > which I consider not very useful anyway, since the AAAH still needs to
> check
> > that they have been included properly. Well, my opinion is that
> we should
> > remove them from there, since they are meaningless to the AAAH that
> receives
> > the HAA.
>
> ok. A few revisions of the base protocol base, less state was required on
> the AAAH. Nowadays, though, I agree that the AAAH can easily keep this
> state information (or add it to Proxy-State if it really wants to).
>
> > Also, note that the Session-Timeout AVP is {} in the HAA, but [] in the
> HAR,
> > which seems inconsistent. What the HA is supposed to put in there if not
> > received in the HAR?
>
> oops
>
> > 9) Section 2.4, the Filter-Rule and the MIP-Foreign-Agent-Host
> AVPs should
> > be removed from the message format. They are not useful at all.
> Maybe they
> > could be in the message as *[AVP], which would mean that their
> presence is
> > not a problem, but not useful neither.
>
> well, we could, but it is sort-of useful to the implementor to know what
> to expect in a message. I suspect that filters will unfortunately be more
> frequent than we want to admit :(

Yes, but why is it useful in the HAA? Can the HA return a different
Filter-Rule AVP than the one received in the HAR? If not, then I don't
see any added value of having that AVP in the HAA.

> > 10) Section 3.1, can the HA return the DIAMETER_ERROR_HA_NOT_AVAILABLE
> > when the can not provide the HA service? In that case, the AAAH, or
> > the AAAF, would be responsible for allocating an other HA, if it had
> > allocated it previously. That is the only reason why I would see the
> > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE useful, since the AAAH changes
> > the DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE into a
> > DIAMETER_ERROR_HA_NOT_AVAILABLE when answering to the FA, as described
> > in page 12.
>
> I would much prefer that DIAMETER_TOO_BUSY be returned by an HA to state
> that it cannot handle the request, and an alternative should be assigned.
> The error in question should only be used when a specific server is
> requested, and it cannot be assigned.

OK, then could we add your last sentence in the description of the error?

> > 12) Section 4.0, the Filter-Rule AVP should be referenced to section
> > 4.11 instead of 4.10. It should also be of type UTF8String, instead of
> > OctetString. The thing is that there are 2 sections 4.10, which should
> > be corrected. Also, the MIP-Foreign-Agent-Host and MIP-Previous-FA-Host
> > AVPs should be of type DiameterIdentity, instead of OctetString.
>
> right, well Filter-Rule is now a sub-type, so this will change. The
> references, though, do need to be fixed.
>
> > 13) Section 4.7, the last paragraph, we should read "Only the AAAF may
> > set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network
> > flags to one."
>
> right.
>
> > 14) Section 5.1, 4th par. last word, should be HAA instead of AMA.
>
> correct.
>
> > 15) Section 6.0, the MIP-Algorithm-Type and MIP-Replay-Mode
> AVPs should be
> > of type Enumeratedm instead of Unsigned32.
>
> correct.
>
> > 17) Section 10.4 is no longer needed and should be completely deleted.
>
> correct
>
> Thanks,
>
> PatC
>