Hi Spencer,
Sorry for the lag.. sometimes holidays interfere working ;) See more
comments inline.
On Aug 6, 2009, at 8:02 PM, Spencer Dawkins wrote:
Hi, Jouni,
Thanks for the quick response. If I wasn't still jet-lagged, I could
remember what I was thinking when I did the review :-)
Responses inline... and I deleted stuff we already agreed on.
Ack.
Spencer
1. Introduction
This specification defines the Diameter support for PMIPv6. In the
context of this specification the location of the subscriber policy
profile equals to the home Diameter server, which is also referred
as
Spencer (clarity): this sentence is difficult to parse - is it
saying "In this specification, the home Diameter server, which is
also referred to as the home AAA server (HAAA), contains the
subscriber policy profile"? If it doesn't, I'm too confused to
make a suggestion...
How about:
In the context of this specification the home AAA server (HAAA)
functionality is co-located with the subscriber policy profile.
Much clearer - thanks!
Ok. Will change the text according to this.
the home AAA server (HAAA). The NAS functionality of the MAG may be
co-located or an integral part of the MAG.
4.5. MIP6-Feature-Vector AVP
LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000)
Direct routing of IP packets between MNs anchored to the same MAG
is supported. When a MAG sets this bit in the MIP6-Feature-
Vector, it indicates that routing IP packets between MNs anchored
to the same MAG is supported, without reverse tunneling packets
via the LMA or requiring any Route Optimization related signaling
(e.g. the Return Routability Procedure in [RFC3775]) prior direct
routing. If this bit is unset in the returned MIP6-Feature-
Vector
Spencer (clarity): I'd say "if this bit is cleared".
OK.
AVP, the HAAA does not authorize direct routing of packets
between
MNs anchored to the same MAG. This policy feature SHOULD be
supported per MN and subscription basis.
Spencer (minor): it's not clear who SHOULD be supporting this
feature - who does the 2119 SHOULD apply to? I would guess it
applies to the MAG, but I'm guessing. Is this "supported on a per-
MN and per-subscription basis"? And I'm not sure why this SHOULD
isn't a MUST.
"supported on a per-MN and per-subscription basis" is what the
text tries to say.
If people think it's clear enough, that's fine. I was just getting
lost.
I'll change the text according to "supported per-MN and per-
subscription basis" as it definitely clearer.
It is SHOULD as the RFC5213 does not mandate whether the local
routing is per-MN (uses MAY in RFC5213) or applies to whole MAG.
Therefore, we felt SHOULD is enough and final decision is then
left for the deployment/system.
That's fine.
Sorry for asking three questions back-to-back.
The question that may have gotten lost is "who is required to
support this?" - the MAG, or the HAAA, or both? This statement
occurs in text that describes the message flow. I'm understanding
your response as saying that the requirement applies to the MAG, but
one reasonable interpretation is that it applies to both the MAG and
HAAA (since they exchange messages with this AVP).
Suggest "The MAG SHOULD support this policy feature on a per MN and
subscription basis".
This is OK.
5.1. MAG-to-HAAA Interface
Whenever the MAG sends a Diameter request message to the HAAA the
User-Name AVP SHOULD contain the MN's identity. The MN identity, if
Spencer (minor): what is this SHOULD conditional on?
In case of identity hiding is applied, the User-Name can be absent.
Ah - if my understanding is correct, the text might be clearer as
"Whenever the MAG sends a Diameter request message to the HAAA and
identity hiding is not in effect, the User-Name MUST contain the
MN's identity".
I am still a bit hesitant with the MUST here. Anyway, if other authors
don't disagree I am ok with the proposed change.
available, MUST be in Network Access Identifier (NAI) [RFC4282]
format. At minimum the home realm of the MN MUST be available at
the
MAG when the network access authentication takes place. Otherwise
the MAG is not able to route the Diameter request messages towards
the correct HAAA. The MN identity used on the MAG-to-HAAA interface
and in the User-Name AVP MAY entirely be related to the network
access authentication, and therefore not suitable to be used as the
MN-ID mobility option value in the subsequent PBU/PBA messages. See
the related discussion on MN's identities in Section 4.6 and in
Section 5.2.1
Cheers,
Jouni
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
