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

["Ben Campbell" <[e-mail]>]

On 4 Jun 2015, at 17:46, Adam Roach wrote:

> On 6/3/15 18:45, Ben Campbell wrote:
>> -- 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?
>
> Yes, this should point to RFC 6665. I presume we can fix this with an 
> RFC editor's note.

Sure.

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

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