Subject: [sipcore] Fwd: AD Evaluation of draft-ietf-sipcore-6665-clarification-00

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

Oops, meant to include working group:

Forwarded message:

> From: Ben Campbell <[email-masked]>
> To: [email-masked]
> Subject: AD Evaluation of draft-ietf-sipcore-6665-clarification-00
> Date: Wed, 03 Jun 2015 17:25:11 -0500
>
> Hi
>
> This is my AD Evaluation of draft-ietf-sipcore-6665-clarification-00.
>
> Summary: This is ready for IETF Last Call. I will kick that off 
> shortly.
>
> Comments:
>
> -- section 1: "... clarity in [2119]"
>
> Do you really mean 2119, not 6665? That is, are you suggesting a lack 
> of clarity on what MUST means, or the lack of clarity in 6665 
> mentioned in section 2?
>
> -- section 2, last paragraph : "regardless of whether such
> subscription would be created by a SUBSCRIBE or a REFER message. "
>
> I suggest you consider adding "or any other method", to future proof 
> against people coming up with new ways to create subscriptions.
>
> Thanks!
>
> Ben.

---

From: Adam Roach <[email-masked]>
Date: Thu, 04 Jun 2015 17:46:30 -0500

> of clarity on what MUST means, or the lack of clarity in 6665 

Yes, this should point to RFC 6665. I presume we can fix this with an 
RFC editor's note.

> against people coming up with new ways to create subscriptions.

Section 4.2.1 of RFC 6665 is pretty clear about normatively forbidding 
new ways to create subscriptions. This was one of a small set of key 
flaws in the original 3265 mechanism that prompted work on a bis draft. 
I fear that adding "or any other method" would dilute the absolute 
prohibition on adding new methods by implying that some other method may 
somehow be allowed.

For easy reference: https://tools.ietf.org/html/rfc6665#section-4.2.1

/a

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 04 Jun 2015 19:48:11 -0500

> Yes, this should point to RFC 6665. I presume we can fix this with an 

Sure.

> flaws in the original 3265 mechanism that prompted work on a bis 
> draft. I fear that adding "or any other method" would dilute the 
> absolute prohibition on adding new methods by implying that some other 
> method may somehow be allowed.
>

Okay.

(It's hard to forbid new things when all we have to do is update or 
obsolete 6665 to remove the prohibition. But that logic could equally 
apply to any attempt to future-proof this draft as well, and I take your 
point about making sure both docs are in solidarity.)