Re: [sipcore] Alissa Cooper's No Objection on draft-ietf-sipcore-sip-push-21: (with COMMENT)

[Alissa Cooper <[e-mail]>]

> On Jan 9, 2019, at 2:41 PM, Ben Campbell <[e-mail]> wrote:
> 
> 
> 
>> On Jan 9, 2019, at 9:26 AM, Alissa Cooper <[e-mail]> wrote:
>> 
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-sipcore-sip-push-21: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Section 13: "MUST ... unless" is a construct worth avoiding.
>> 
>> 
> 
> Hi Alissa,
> 
> I can see why that specific "MUST... unless” may not be appropriate, given the vagueness of the condition and the way we’ve constructed “MUST support/SHOULD use” requirements for TLS in the past.
> 
> But are you suggesting that conditional MUSTs are never appropriate?  I’ve been recommended “MUST ... unless...” constructions for cases where the MUST is true except in enumerated special cases. “SHOULD” doesn’t really accomplish the same thing, since a SHOULD as defined by 2119 allows for exceptions beyond those enumerated in the spec.

I think “MUST … unless” is hard to square with how MUST is defined in 2119.

For this doc it seems like a simple re-wording would do the trick, e.g.: TLS or a mechanism that offers equivalent security properties MUST be used to secure the signaling.

Alissa

> 
> Thanks!
> 
> Ben.