Hi Jari/Spencer,
Just one comment below. Will respond to the other comments
later, to most part, agree to all the comments. Will try
to resolve them.
On Mon, 18 May 2009, Jari Arkko wrote:
> > applied with the following exceptions.
> >
> > Spencer (minor): not sure why the next two bullets are SHOULD NOTs -
> > we
> > usually provide at least one example of why an implementation would
> > choose
> > not to perform SHOULD NOTs, for background.
> >
> > o If the received Proxy Binding Acknowledgement message has the
> > Status field value set to
> > NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
> > mobile node is not authorized for IPv4 home address), the mobile
> > access gateway SHOULD NOT send a Proxy Binding Update message
> > including the IPv4 Home Address option [ID-DSMIP6] till an
> > administrative action is taken.
> >
> > o If the received Proxy Binding Acknowledgement message has the
> > Status field value set to
> > NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
> > mobile node is not authorized for the requesting IPv4 home
> > address), the mobile access gateway SHOULD NOT request for the
> > same address again, but MAY request the local mobility anchor to
> > do the assignment of address by including exactly one instance of
> > IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address
> > and the prefix length fields in the option set to ALL_ZERO value.
>
> While adding rules about when taking a SHOULD is useful, I do not think
> it is an absolute rule. Generally speaking, SHOULD says that you can
> disobey it but only if you fully understand the implications.
I should have also asked if it's clear what the other party does when the
SHOULD NOT is violated. A MUST NOT is a clear protocol violation, so the
choices are usually something like (1) send appropriate error response, or
(2) drop silently. An implmentation that violates a SHOULD NOT is still
conforming to the specification, so these choices aren't the right answers
- is the appropriate reaction obvious?
I'm not smart enough about PMIP6 to know whether it's clear or not - but I
should have asked the question. If you guys tell me "no problem", no
problem.
The authors should tell us how it really is, but my understanding is that the
above issues are related to management (mis)configurations that you generally
do not want to repeatedly attempt to ask for.
If the request is rejected with a specific reason, there is not point
for the requester to continue to send the messages for the exact same
service. Its ok to resend the message when some thing changes. Ex: An
administrative action allowing the user for that service.
So, the "SHOULD NOT" is with the goal to avoid unnecessary messaging.
Otherwise, the requester will recv the same error code.
Sri
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
