Spencer Dawkins wrote:
(dropping IETF discussion list)
Hi, Jari,
My apologies for not finishing the thought - when I tagged
3.2.3.2. Receiving Proxy Binding Acknowledgement
All the considerations from section 6.9.1.2 of [RFC-5213] MUST be
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.
Jari
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art