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

Reply via email to