Subject: [sipcore] Fwd: AD Evaluation of draft-ietf-sipcore-refer-explicit-subscription-02

From: "Ben Campbell" <[email-masked]>
Date: Wed, 03 Jun 2015 18:45:11 -0500

Oops, meant to include working group:

Forwarded message:

> From: Ben Campbell <[email-masked]>
> To: [email-masked]
> Subject: AD Evaluation of 
> draft-ietf-sipcore-refer-explicit-subscription-02
> Date: Wed, 03 Jun 2015 18:27:07 -0500
>
> Hi,
>
> This is my AD Evaluation of 
> draft-ietf-sipcore-refer-explicit-subscription-02.
>
> Summary: This is ready for IETF LC. I have a few comments/questions, 
> but nothing that need block the last call.
>
> Substantive Comments:
>
> -- 4.3, 4th paragraph: "... return a 200 response containing ..."
>
> Containing where? This should probably mention Refer-Events-At. If 
> there's other text that says you MUST put it in that header field, I 
> missed it.
>
> -- 6:
>
> Did I miss a prohibition about putting both tags in Require at the 
> same time?
>
> -- 10, last sentence:
>
> Isn’t this redundant to similar text in refer-clarifications? Why 
> does it need to be in both?
>
> -- 8, third paragraph: "... the URI should be constructed so that it 
> is not easy to guess..."
>
> Is this intentionally non-normative? (Seems odd that the following 
> “for instance” about TLS or DTLS _is_ normative but this sentence 
> is not.)
>
> Editorial:
>
> -- 4.3, third paragraph:
>
> s/recieved/received

---

From: Robert Sparks <[email-masked]>
Date: Wed, 03 Jun 2015 22:07:04 -0500

-------- Forwarded Message --------

 > there's other text that says you MUST put it in that header field, I

I will add a clause saying "As the Refer-Events-At header field value"

 > Did I miss a prohibition about putting both tags in Require at the

It's at "In particular, a UA can only invoke the use of one of the
extensions in a request."
I don't think we need a 2119 word here.

 >
 > -- 10, last sentence:
 >
 > Isn’t this redundant to similar text in refer-clarifications? Why does
 > it need to be in both?

I assume from context you meant 7 here, not 10.
Section 5 in -clarifications was added late in the game (only in the
current version).
It would probably be ok to remove the 2119 word from this document and
point into
clarifications instead.

 > “for instance” about TLS or DTLS _is_ normative but this sentence is
 > not.)

I try hard to not put 2119 into security considerations sections. I find
they are more helpful if they discuss security considerations, not add
more to the protocol. The SHOULD that's there is something that I wish I
hadn't done (I wasn't paying close enough attention at the time) - it
should have been up in the protocol part of the body. Unless you think
this will cause an implementation flaw, though, I'd prefer to not touch
it unless later review makes me do major surgery to the section.

 > s/recieved/received

ack.