Update to the Session Initiation Protocol (SIP) Preconditions Framework
draft-ietf-sip-rfc3312-update-03

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART. Review added as comment to document.
I am somewhat worried by one point from his review:

It is not clear why this is an update and not a replacement. The more "updates" we do, the more labyrinthine the web of references becomes for our users.

But that's an overall concern, and shouldn't be blocking for this particular document.

Review by Spencer Dawkins, Gen-ART

I'm reviewing this document as a Working Group submission for Proposed
Standard.

Please take this as a compliment - I think most of the problems with
this document stem from having very knowledgeable authors who forget
how little some of us know about SIP! I'd say "headed the right
direction, but considerable work is needed before publishing".

Overall - I'm wondering why we're doing this document as an update to
RFC 3312, instead of as a replacement for RFC 3312. We really aren't
very good at saying what a standard is, and if a standard can
reasonably be published as a single document, instead of as a set of
documents published over time, I'd prefer to see that. We ended up
with an entire working group chartered to figure out what TCP really
is, and I'm sure we'll see more SIP documents in the next 23 years
than we've seen published on TCP in the last 23 years (since RFC 793).

If there's a good reason for publishing an update (and not something
silly like "we want to republish as a draft standard and don't want to
reset our clock"), there should at least be a summary section that
says "these are the things we changed". It is possible to figure this
out by reading the entire document, but that means people may be
reading a document that doesn't affect them, and they can't figure out
that they don't need to read it until they finish it :-(

Section 3.4 - "In general, the called user is not alterted until the
preconditions are met" - "alterted" is typoed, but that's a nit. I'd
really like to understand why this isn't "is never alerted until" - is
this always true, but that's not what the draft says? Is there a
well-known case where called users ARE alerted before the
preconditions are met? (If there is, should we change the specÊfor
consistency?)

second paragraph in 3.4 - "Still" isn't needed and is confusing.

third paragraph in 3.4, and following - this section is way too
confusing - at the minimum, the indented text should be NEW text,
reflecting the updated concept, because indentation draws the reader's
eyes to the old text that is no longer completely true!

Section 4 - s/oft/of/, but that's a nit. Paragraphs three and four
seem to say "the specification has been misleading up to this point,
so now we'll tell you what we should have said in the first place".

Section 5 - the end of the fourth paragraph explains that moving a
media stream is like setting it up in the first place, from a
precondition point of view. This statement should appear a LOT higher
in section 4, because it is key to understanding what's going on.

sixth paragraph in 4.1 - I THINK s/answer/answerer/, but might be
confused. The following table doesn't seem to be required (some ideas
really justify prose).

Section 6 - "no IANA considerations", but preconditions ARE registered
by IANA (as pointed out in 3.1). I think this is saying "3312 had IANA
considerations, but the parts that we're changing don't" - I'd still
like to see this draft contain all of 3312...

Extremely minor nit throughout - reference identifiers are attached to
a lot of occurrences, not just the first one. RFC 3312 is tagged as
[3] about twelve times.

[Ballot comment]
In section 3.4: s/not alerting the user/not alerting the called user/

  In section 4: s/Section 5 oft RFC 3312/Section 5 of RFC 3312/