Thanks for the response--comments inline. I removed sections that I
think we are in agreement on.
On Oct 10, 2008, at 3:57 AM, Miki HASEBE wrote:
[...]
This version backs away from "recommending" the "hints" I reference
in
item 2 above, and now correctly references the essential correction
draft in item 1. It seems to me that this version steps further back
from recommending specific practices than the previous version--
thus I
still wonder why it is a BCP rather than an informational.
I've kept the draft's intended track as it is and related text
unchanged,
because it's still undecided whether it is going to be BCP or
Informational.
I'll follow AD's judgment.
Okay, that is reasonable. While the ADs certainly have the final say
in the matter, I would suggest that if the purpose is to describe race
conditions that can occur, this would be an informational. On the
other hand, if the purpose is to suggest that implementors take
specific actions to avoid or mitigate the conditions, then it might be
a BCP.
Section 1.1, paragraph 2:
You say that these use cases are not specific to the transport
protocol. Should I infer from that that all of these cases are the
same for TCP as for UDP? I am skeptical that this is true for cases
that indicate a dropped packet.
No change or response.
Dropped packets need to be considered even if the UA uses TCP, because
intermediate element may use UDP as a transport protocol.
Understood--see my comment to Paul's email on the subject.
Section 2, first paragraph after Figure 1: "The caller MAY send a
BYE in the Early state, even though this behavior is NOT
RECOMMENDED."
It's not clear to me whether this is a new recommendation made by
this draft, or a description of a recommendation in RFC 3261. (I
find this to be true of much of the normative language in this
draft.)
The NOT RECOMMENDED part is now changed to lower case, but it is
still
not clear to me if this draft is introducing the MAY or simply
reporting on it.
It is "simply reporting". Reason for recommendation is written in the
draft.
Okay. It would be less ambiguous if it said something to the effect
of "...not recommended by RFC 3261".
By the way, this is really bound up with the question about whether
this is a BCP or an informational RFC. If it's just an informational,
then I tend to assume statements like this are merely describing
statements in the relevant specs. If it's a BCP, then I assume the RFC
makes recommendations above and beyond those in the protocol specs, so
it becomes more important to be unambiguous.
First paragraph after figure 2: "A CANCEL request does not cause a
dialog state transition."
I can see that being true for the UAC, but is it really true for the
UAS? You go on to say that the "callee terminates the dialog"; how
is that not a state transition?
No change or response
Yes, it is true for the UAS.
A CANCEL doesn't directly influence the dialog state of UAS and
it only influences the INVITE transaction. The trigger that changes
the
dialog state of UAS is a 487 response to the INVITE.
(Refer to Section 9.6 in RFC3261.)
Okay.
Definition of Moratorium State:
It's not clear to me from the description what the "conceptual"
meaning is for the moratorium state? Can you mention why you chose
the term "moratorium"?
No change or response
The reason to select the name of Moratorium is a temporary period to
the
arrival at the perfect condition because of cutting
with BYE though this state is in the Confirmed state.
I'm sorry, but I am having trouble understanding that sentence.
The dictionary definition of "moratorium" is a temporary prohibition
of an activity. I understand that in this case, the state is
temporary--but what activity is being prohibited? It would be helpful
to have explicit text on that in the definition in section 2.
[3.1.4, 3rd paragraph (formerly 4th)]
"This example recommends that 200 be sent
instead of 491 because it does not have an influence on the
session.
However, a 491 response can also lead to the same outcome, so
either
response can be used."
I'm confused--the text just said 419 is recommended, now it says 200
is better, but then again it really doesn't matter?
The conflict with preceding paragraph is fixed (that paragraph was
removed), but I'm still not sure I understand why you recommend 200,
but then go on to say that either response can be used. I'd suggest
either making a stronger recommendation, or removing the
recommendation entirely.
The reason to recommend 200 is that there is no pending offer in
this case.
However, UA should be prepared to see a 491 response because 3261
isn't clear
on whether the sending of the 491 or the 200.
Ah, that makes sense. It would be clearer to say something to the
effect of "However, since a 491 response can also lead to the same
outcome, an implementation should be prepared to accept either
response."
[3.1.4] 4th paragraph:
"The UA should not reject or drop the ACK on grounds of the CSeq
number."
Normative?
No change or response
This is not stating anything beyond what is stated unambiguously in
3261.
Its just reiteration.
I think for a reader not intimately familiar with CSeq handling for
ACK may read more into that sentence than you intend. I propose
changing the word "should" to "will". On reflection, I think you could
drop the sentence completely, since the previous sentence already
points out that the CSeq is _supposed_ to match that of the INVITE.
3.2.1, 2nd paragraph:
"shall return 200" Are you saying that 3261 compliant UAs will do
this, or suggesting a new requirement?
No change or response
There is no new requirement. The problem is that 3261 isn't clear on
whether
the sending of the BYE or the receiving of the response to the BYE
terminates
the dialog. I think that RFC3261 allows both a 200 and an error (ex.
481) to
the BYE request. As a BCP I think this is a best practice but one
must be
prepared to see a 481 response.
Also what do you mean by "exchange reports about the session" with
simultaneous BYE requests?
Wording is changed, but it is still not clear to me what you mean
by a
exchanging reports about a session when it is terminated.
I mean in this sentence that UAs will exchange the information
that the BYE request has been processed properly and
that session has been successfully terminated.
I think the current language is very confusing.
Does the following capture the intent?
"A UA in the Mortal state will return an error response to any request
that normally operates within a dialog, such as re-INVITE, UPDATE, or
REFER. But in this example, the UA returns a 200 OK when it receives
the BYE request while in the Mortal state. This communicates to the
sender that a dialog has been properly terminated. If, for example,
the UA returned a 481 response, the sender would not be able to tell
whether the dialog had been terminated properly, or whether the BYE
was incorrectly sent for a non-existent dialog.
While the 200 OK response is more useful in this scenario, the sender
of the BYE request must be prepared to receive other responses."
Appendices (all)
It's not clear to me why the information in the appendices is in
scope for this draft. None of it seems to be about race conditions.
They are, however, good discussions of interesting corner cases, and
maybe worthy of drafts in themselves. This is certainly not a big
deal; I just have a mild fear that relegating them to appendices of
a draft on a different subject may not get them the reader attention
they deserve.
No change or response
I guess the other appendices could be deferred to a separate draft.
But
are they worthy of the effort needed to progress a separate draft?
I think it would be better to keep these things together.
Can we just let it slide?
On reflection, it is probably not worth the effort to change this at
this point in the process.
Thank you,
Miki
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
