more pruning...
On Oct 10, 2008, at 3:25 PM, Paul Kyzivat wrote:
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.
I can still go either way on this, but would like to get it nailed
down, because it influences the language we need to use.
I think I lean toward BCP so that we *can* make real recommendations
between legal alternatives. Even then there are those "hints" where
IMO there is disagreement over what is best. So in those cases there
may continue to be just discussion, without recommendation.
Don't get me wrong, I don't hate the idea of this being a BCP. My
issue was that it didn't seem like it made many real recommendations,
with the possible exception of BYE glare conditions scenario. Given
that the majority of this is descriptive text, if it does stay a BCP
then it would be good to explicitly distinguish concrete
recommendations between said legal alternatives.
For example, would you characterize the tweaks to the state machine as
recommendation or description?
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.
See my comment above on this.
Same here :-)
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.
I'm not taking a position on this. To me these are just labels. The
connotation has *some* value, but its of necessity limited. If there
is a better alternative then I would be ok with changing it. But I
don't have a better alternative in mind.
I'm not really asking for the label to be changed--merely that the
reasoning behind the choice be given in the definition of the term,
since I did not find it obvious.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
