Hi Spencer,
Thanks, We will update the document according to your other comments.
thanks
ryuji
On 2009/05/18, at 12:38, Spencer Dawkins wrote:
Hi, Ryuji,
Thanks for explaining - SHOULD NOTs will be fine (with me).
Spencer
Hi Spencer,
Thanks for the detailed comment.
On 2009/05/18, at 12:02, Spencer Dawkins wrote:
Hi, Sri,
(Thanks to everyone for the quick responses - I can still
remember the review without having to re-read it ;-)
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.
I'm sorry, I'm not asking the question clearly - I'm asking why
these SHOULD NOTs aren't MUST NOTs. Is there a reason why the
requestor would resend the messages for the same service, without
changing anything?
If there's a reason, SHOULD NOT would be appropriate. If there's
not a reason, perhaps MUST NOTs would be more appropriate.
The "MUST NOT" is too strict in this case.
As Sri mentioned, it is just for optimization by skipping
unnecessary messaging.
After operational action is taken by LMA and error is fixed, MAG
should be able to retry the registration of the home address which
was previously rejected with NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS.
The retry timing depends on operation and administrative matter.
It might be the next registration or 1 hour later..
That's why we just put SHOULD NOT here.
We will work on the other comments.
regards,
ryuji
Thanks,
Spencer
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
