Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)
draft-ietf-bliss-shared-appearances-15

A clear and well-written document. Thanks you.

---

Section 7

I think you need to add a reference to RFC 5234 when you mention ABNF.

Updated for version -14:
Version -14 resolves all the issues I brought up -- thanks very much for dealing with them.  In particular, I like the changes in Section 5.3, especially about the appearance numbers... and I'm surprised that it took so few text changes to take care of that.

Good work, and, again, thanks.

1. I agree with Stephen's DISCUSS point on the meaning of "in a secure way".

2.I assume that the lower-case 2119 keywords used in the requirements statements are only descriptive.  If not, I would suggest addressing the inconsistency in capitalization.

Robert addressed my discuss points on the call.  Thanks.

1) s4.1, REQ-3: Same question as Stephen.

2) s4.2: Tripped over the fact that the section is informative, the intro of s4.2 para says s5 is normative, but the definition of the appearance parameter is in s7.  Maybe add a forward pointer to s7 when you start to discuss the parameter?

3) s4.2m step 2: State Agent or Appearance Agent?

4) s5.2.2/s5.3: call-id or Call-ID, From tag or from-tag, local tag or local-tag?

5) s5.3: There's a couple of paragraphs that are indented - was this done purposely?  Are these supposed to be notes?

6) s5.3: If a UA does insert an 'appearance' parameter what happens?

7) s7/s5.3: probably worth driving home again that the 'appearance' parameter is only inserted by an appearance agent (then again maybe 3261 already says this?).

8) s11: Pretty please can we have one example with security!?

- I can't see where (in the mail archive) the WG are ok
with the IPR declaration here. All I found so far is the
announcement of the declaration and nothing else. Did
the WG in fact consider this IPR declaration and decide
they were ok with it? (It may have happened, I didn't
read the list, just searched the on-line archive for the
string "IPR.") 

Some of my comments below are probably down to not 
being familiar with the terminology/use-cases but then that
will be true of other RFC readers so may be worth
considering.

- 4.1: lower case "must" in the requirements confused
me, better to use MUST if you mean 2119 MUST or explain
if you don't 

- 4.1, REQ-3: I also wondered how you'd setup a group
over the public Internet and whether that's addressed
here or not - the use cases don't clarify but I can
imagine home workers using this 

- 4.1, REQ-5: introducing the n,N notation here seems
like wrong and isn't really needed

- 4.1, REQ-6: I wondered why I couldn't have an
appearance name, icon or avatar and why it must be a
number

- 4.1, REQ-7: I don't know what appearance contention
means exactly.

- section 5: what's the max appearance number that
MUST be supported? Can I seize line [1]? :-) That
may be caught by some generic SIP thing, I dunno.

   [1] http://primes.utm.edu/primes/page.php?id=85527

- p14, s/Increading/Increasing/

- p15, Is this not a repeated MUST about emergency
calling from some other RFC(s)? If so, is that needed
here or not? Repeating normative language is usually
not such a good plan.

- p17, s/not have/not having/

- section 7, 3rd para: I don't get what "If an
appearance number parameter is already present
(associated with another AOR or by mistake), the value
is rewritten adding the new appearance number" means.
Can't two AORs use appearance=1 via the same proxy or
something?  That's a surprise.

- section 7, I'm surprised that ring-tones need to
be mentioned here.

I am taking a position of no objection on the basis of a quick read to determine that there were no apparent routing considerations and my confidence in the shepherding AD.