[Looks like my first attempt got caught in moderation. Sorry for the repeat]

I am the assigned RAI-ART reviewer for draft-ietf-sipping-sip-offeranswer-13.

For background on RAI-ART, please see the FAQ at
<http://www.softarmor.com/rai/art/FAQ.html>.

Please resolve these comments along with any other comments you may receive.

Summary:

This draft claims an intended status of "informational". I believe this needs to be standards track, or a BCP. For that purpose, I think it's on the right track, but I have some other minor comments and questions that I think should be addressed first.

And BTW, I think this is a great document to have, as it is correct in pointing out our current offer/answer rules are scattered all over the place.

Major Comments:


-- The draft is listed as informational, and goes to great lengths to pretend to make no normative changes. I am not convinced. There are a number of places where it has the practical effect of  updating or adding normative constraints to existing proposed standards. I think it would be best to make this standards or BCP track and drop the pretense of being non-normative.


Minor Comments:

-- section 1.1: 

The need for normative language in a draft that states it is not making any normative changes is telling.

-- section 2.2, 5th paragraph, last sentence: "The 488 response is another proposed solution, UAS may respond with a 488 response and then UAC should send again a PRACK request without an offer."

What do you mean by "proposed solution"? Is this solution allowed, recommended, etc?

-- 2.2, Paragraph 8 (in NOTE):

Please elaborate on "401 response cannot be avoided". Perhaps something to the effect of "For example, the UAS may need to send an authentication challenge in a 401 response."

--2.2, paragraph 9:

Please elaborate on "...a UA should take care not to cause an infinite offer/answer loop."

-- 2.2, Table 2, (**)

Please elaborate -- how can a UA know the mind of the receiver?

-- 3.1.1

Are you certain there are no normative changes here? Can all the assertions be supported unambiguously by existing specs? 

-- UAC Behavior, item 1: "... not a real answer...

Does that make it a fake answer? I don't think "real" is the property you are looking for. Perhaps " not a final answer" or "preliminary answer" would be. Ore descriptive?

-- 3.1.1, paragraph before figure 1: "Therefore, a UAS should send a SDP answer reliably (if possible) before it starts sending media."

This  really sounds like either normative or BCP material.

-- 3.1.2, last paragraph, last sentence: "The UAC should take care to avoid this situation when it sends the INVITE request without SDP."

How? Are you suggesting that you shouldn't send an empty invite unless you can accept any answer without user intteraction?

-- section 4.1, paragraph after figure 4:

Can you elaborate on "should not send...at this point"? For example, should not send the reINVITE until...

Comment repeats for most of the following scenarios.

-- 5.1, first paragraph: "...without regard for what the other party in the call may have indicated previously."

This is not universally true. For example, the sender may have access to the recipient's presence information, which it generally shouldn't ignore.

5.2.3, first paragraph: "The media lines that are accepted should typically be those with types and formats the UAS would have included if it were the offerer"

I'm not sure how to apply that advice to make any useful decision. For example, if I might not have offered video, should I reject a media stream in someone else's offer?




Nits and Editorial Comments:

-- Please proofread for the following recurring errors: comma-spliced run-on sentences, missing articles, and incorrect selection of "a/an" vs "the".

-- s/"can not"/"cannot" throughout.

-- 3.1.1, figure 1:

The discussion talked about endpoints that do not support 100rel, but the example uses it.

-- 3.1.2, 2nd paragraph (Note): 

Please reference the figure number when you first start talking about messages from that figure.

-- 3.3, last paragraph, last sentence: "Otherwise, some 3pcc flows will break."

Expand 3pcc on first mention. Also, please provide a reference.

-- 3.4, first paragraph: "...newer specifications..."

Please specify which specs you are talking about.

-- 4, 3rd paragraph:

What do you mean by "...rules are guaranteed"?

No need for quotes around "exceptional".

I'm not sure what you mean by " carefully restricted in the RFCs" Are you suggesting a change in existing or future RFCs?

-- 4.2, paragraph after figure 11: "At best it..."

What is the antecedent for "it"?

-- 5.1, general:

I find it curious to ascribe wants and interests to the UA. This leads to some awkward constructions when discussing how a UA may not know what it wants.