URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)
draft-ietf-salud-alert-info-urns-14

Note: This ballot was opened for revision 12 and is now closed.

(Richard Barnes) (was Discuss, Yes) Yes

(Jari Arkko) No Objection

Comment (2014-05-15 for -12)
No email
send info
The Gen-ART review from Alexey and comments from Ben indicated that the unclear MUST requirement text needs a change. I can see that the authors are working on that. I think the text really needs to change, but since you have already taken on the task to do the changes, I am not raising a Discuss and are expecting Richard and others to make sure that the change happens.

(Benoît Claise) No Objection

Comment (2014-05-13 for -12)
No email
send info
Nothing to add to the current AD reviews.

Alissa Cooper (was Discuss) No Objection

Comment (2014-08-13 for -13)
No email
send info
Thanks for addressing all of my DISCUSS points.

--------------

Section 5:
"REQ-4: has been deleted.  To avoid confusion, the number will not be
   reused."

This reads oddly. If you want to keep this in, something like this would be better: 
"REQ-4: This requirement appeared in earlier versions of the document, but has been deleted. To avoid confusion, the number will not be reused."

On the other hand, the REQs are never referenced again in the document as far as I can tell, so is it really that hard to re-number them? Or is REQ-4 left in because the requirements are referenced in other documents?

REQ-10:
s/uncomon set/uncommon set/

REQ-16:
s/not subject of/not the subject of/

REQ-18:
s/not subject of/not the subject of/

Section 6.2.1:
"Because the call-waiting information may be subject to the
   callee's privacy concerns, the exposure of this information shall be
   done only if explicitly required by the callee."

Agree with Barry's comment here. Seems like if any of the parties would be "requiring" this, it would be the caller, not the callee. But in any event it should be up to the callee to decide whether to expose this info.

Section 7:
s/ and [RFC3406]/ and [RFC3406]./

Section 8.2:
s/no-operation"alert" URN/no-operation "alert" URN/

Section 8.2.2:
The inclusion of "friend" and "family" made me wonder why an indication of "work" or "professional" (as opposed to friend/family) was not included. Work colleagues may be internal or external, so this would be a separate classification from all of the ones already listed. I would guess usage of this would be desirable if "friend" and "family" are as well.

Section 10.1:
s/an new <alert-category>/a new <alert-category>/ 

Section 10.2:
"Within a URN, all <alert-label> components that follow a <private-
   name> but are before any following <private-name>s are additional
   private extensions whose meaning is defined by the organization
   defining the <private-name>."

The phrase "the <private-name>" is possibly ambiguous. I think what is meant at the end of this sentence is "the organization defining the <private-name> immediately prior in the hierarchy."

"(In either
   case, the organization SHOULD use the existing URN for its purposes.)"
   
This seems a bit superfluous. It's like saying organizations should use the URNs they mint, but there are cases where they shouldn't. Isn't that what will happen anyway regardless of what this draft says?

Section 14:
s/A A SIP proxy/A SIP proxy/

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-05-13 for -12)
No email
send info
- I agree with Alissa's discuss point on section 16 and with
the secdir review [1] on that topic.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04753.html

- The private name + date thing seems over-complex really.

- 9.2.6: you mean you want to add each country code to the
IANA registry? Seems like a bad plan if so.

(Brian Haberman) No Objection

Comment (2014-05-12 for -12)
No email
send info
I support Alissa's and Barry's DISCUSS points.

(Joel Jaeggli) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2014-07-20 for -13)
No email
send info
Thanks very much for addressing all my concerns, including those that came up in the conversation with Alissa.  I'm happy with the result... and I hope the working group is as well.

(Ted Lemon) No Objection

Comment (2014-05-13 for -12)
No email
send info
In the abstract: "The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted."   Rendering of what?   The abstract shouldn't assume that the reader knows.

In 8.2.2, it seems weird that the recipient would accept the "family" or "friend" indication from the sender.   The security considerations address the larger point of trusting the sender generally, but I think this is different because it can only make sense when the sender has knowledge about the recipient's relationships.   It seems like the wrong way to do this, and I am not convinced that it belongs here.

I'm not raising it as a DISCUSS because it's not an interop issue and probably won't break the internet, but it seems weird and seems to have potential for abuse.   What was the motivation for adding this?   If it's to codify existing practice, it might be worth putting text in the security considerations addressing these specific indicators and saying that they are a bad idea, and are not recommended, but are included to address current practice.

Otherwise (and modulo some other IESG review comments) the document is well written, easy to follow, and looks good.   Thanks for doing it!

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2014-08-12 for -13)
No email
send info
Thanks for addressing my discuss point in 8.2.2 with a clarifying sentence as well as overhauling the security considerations section to address the SecDir review, Stephen, & Alissa's comments.  The updated Security considerations section works for me.

(Pete Resnick) No Objection

Comment (2014-05-13 for -12)
No email
send info
Ah, it's so nice to be late and just agree with Alissa and Barry's DISCUSS points.

Section 5 should be removed or moved to an appendix.

(Martin Stiemerling) No Objection