[Trimming down a bit]
On 6 Sep 2016, at 22:57, Suresh Krishnan wrote:
OLD: If a client wants to refresh an existing allocation and
update its
time-to-expiry or delete an existing allocation, it will send a
Refresh
Request as described in Section 7.1 of [RFC5766]
NEW:
If a client wants to refresh an existing allocation and update
its
time-to-expiry or delete an existing allocation, it MUST send a
Refresh
Request as described in Section 7.1 of [RFC5766] and MUST NOT
include a
MOBILITY-TICKET attribute.
I will try to explain my line of reasoning. Let me know where you
disagree.
If the client includes a MOBILTY-TICKET attribute in the refresh
method, the
refresh will fail. So, the MUST NOT is aimed at preventing the client
from
sending a useless packet that will be rejected anyway.
"Useless" seems not a good reason for a "MUST NOT". Perhaps Tiru's
explanation of "will cause an extra retransmission" is a better reason.
But as I said, this isn't one that I will complain too vociferously
about: What this says is "don't include the attribute; it will be
rejected and you'll have to retransmit"; if you want a "MUST NOT" for
that, so be it. But:
The MUST stresses that
the original Refresh procedure from RFC5766 needs to be used instead
of the
Refresh procedure with the MOBILITY-TICKET described in this one.
Ah! If that's was meant, that's not what was said. It sounds like you're
saying that the client *can't* refresh a request by simply sending an
allocate request with the old MOBILITY-TICKET. And then I get a bit
confused about the MUST NOT: The next sentence after this bit says:
If the client wants to retain
the existing allocation in case of IP change, it will include the
MOBILITY-TICKET attribute received in the Allocate Success response.
The previous sentence says that you MUST NOT include the attribute. This
sentence says that you do include it. I suspect that what was intended
was, "If you *just* want to refresh to retain the existing allocation in
case of an IP change, you can send an allocate request including the old
MOBILITY-TICKET attribute. If you need to update time-to-expiry or
delete the allocation, then you *can't* just send a new allocate request
with the attribute; that will get rejected. You instead *have to* use
the refresh request in 5766." Do I have that right? If so, the paragraph
could use a rewrite; it's not the MUST and the MUST NOT that are the
problem.
Anyway, I
am not wedded to keeping the MUST as long as the MUST NOT prevents the
sending of a packet that is certain to be rejected.
Ack. See above.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
