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

[Robert Sparks <[e-mail]>]

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






On 6/3/15 6:27 PM, Ben Campbell wrote:
 > 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.

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

 >
 > -- 6:
 >
 > Did I miss a prohibition about putting both tags in Require at the
 > same time?

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.

 >
 > -- 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.)

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.

 >
 > Editorial:
 >
 > -- 4.3, third paragraph:
 >
 > s/recieved/received

ack.