Subject: [calsify] Ben Campbell's No Objection on draft-ietf-calext-availability-03: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 06 Jul 2016 13:13:34 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-calext-availability-03: 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-calext-availability/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- General: I agree with Stephen's discuss comment. (And have some
additional comments on that section, below.)

- 7.1.1, first paragraph: "A value of "calendar-availability" in the
   DAV response header MUST indicate that the server supports all MUST
   level requirements specified in this document."

The nested MUSTs are confusing. Do I correctly understand the intent to
be that a value of “calendar-availability”  means the server supports
this document? (It’s not necessary to say “supports all the MUSTs”,
because that is the definition of supporting this document.)

-7.2.2, first paragraph:  Does this draft need to update 4791?

- 7.2.4, conformance: "Support for this
      property is REQUIRED."

What is required to support it? Does this mean something more than
“Servers that support it are REQUIRED to support it?”

"only a single "VAVAILABILITY" component
      MUST be present in the property."

Language of the form of “only one MUST be present” is ambiguous. Does
this mean the property MUST have exactly one? MUST NOT have more than
one? 

-8, first paragraph:"servers MAY limit
   the complexity"
Is MAY strong enough here? Does it make since to ever allow arbitrarily
complex information?

-9, first paragraph: Does this imply a requirement for confidentiality
protection on the wire? (Does caldae already require that?)

- 2nd paragraph: Seems like this could say more. For example. doesn’t
this imply that a system needs to give users a way to specify who should
get more or less information?

- last paragraph: I don't think this is an appropriate use of a 2119
"MUST". Please consider something of the form of "Privacy Considerations
in [refs] also apply."

- 10.1 and 10.2: The referenced sections of 5545 do not contain the
registry definitions. (Rather, they contain the initial populations.)

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 07 Jul 2016 10:41:28 -0400

Hi Ben,
Thanks for your review. My comments are below.

I have changed that text to:

   A server supporting the features described in this document MUST
   include "calendar-availability" as a field in the DAV response header
   from an OPTIONS request.  A value of "calendar-availability" in the
   DAV response header indicates to clients that the server supports all
   the requirements specified in this document.

> -7.2.2, first paragraph:  Does this draft need to update 4791?

Yes. I already made that change in response to a similar comment in the 
OPS-DIR review.

> “Servers that support it are REQUIRED to support it?”

We've been using that terminology since RFC 4791. It basically relates back 
to the statement about the DAV header "capability" - i.e., if that 
"capability" is advertised then the server has to support all the 
requirements related to the property.

> this mean the property MUST have exactly one? MUST NOT have more than

I removed that sentence, and instead adjusted a prior sentence to read:

      The value of this property MUST be a valid
      iCalendar object containing only one "VAVAILABILITY" component,
      and optionally, "VTIMEZONE" components - other iCalendar
      components MUST NOT be present.

> Is MAY strong enough here? Does it make since to ever allow arbitrarily

Agreed. I think a MUST makes sense here to force implementors to think 
about what limits they need to apply. I will make that change.

> protection on the wire? (Does caldae already require that?)

This statement was not about TLS (which CalDAV only requires if basic auth 
is in use as per RFC4791). It is about verifying who is requesting 
free-busy and only processing the request if they are authorized to be 
given such information.

As far as CalDAV security/privacy issues are concerned, I know Stephen is 
keen to start a general discussion on that to see if we can tighten up the 
specs (though I am pretty sure nearly every service already uses TLS 
everywhere).

> get more or less information?

I think that is covered by the last sentence in the changes I proposed in 
response to Stephen's review:

    Thus, calendaring systems allowing "VAVAILABILITY" components to be
    sent or shared to other calendar users, MUST provide a way for
    non-essential properties to be removed (e.g., "SUMMARY", "LOCATION",
    and "DESCRIPTION").

> "MUST". Please consider something of the form of "Privacy Considerations

Um OK. But draft-ietf-calext-extensions-05 was approved with exactly the 
same language. So to clarify, you would like me to change that text in both 
this draft and the other, and in both Security and Privacy section?

> registry definitions. (Rather, they contain the initial populations.)

Again, the same references were used in draft-ietf-calext-extensions-05. 
Practcally speaking, RFC5545 does not formally define the registries. 
Instead, section 8.2 defines the overal process for the various registries 
that are needed. The sub-sections of 8.2 then define templates for use with 
various registries. The items in section 8.3 are really what IANA keyed off 
for the creation of the registries.

-- 
Cyrus Daboo

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 08 Jul 2016 16:43:17 -0500

Hi, thanks for your response. More discussion inline--I removed sections 
that don't appear to need further discussion.

Thanks!

Ben.

> --On July 6, 2016 at 1:13:34 PM -0700 Ben Campbell <[email-masked]> 

[...]

>   the requirements specified in this document.

That works for me.

[...]

> We've been using that terminology since RFC 4791. It basically relates 
> back to the statement about the DAV header "capability" - i.e., if 
> that "capability" is advertised then the server has to support all the 

Okay. Who am I to argue with history :-)

>      components MUST NOT be present.

That helps, but I think it would be more precise to change "only one" to 
"one", and mention "zero or more" (if that's the right thing) for 
VTIMEZONE

[...]

> This statement was not about TLS (which CalDAV only requires if basic 
> auth is in use as per RFC4791). It is about verifying who is 
> requesting free-busy and only processing the request if they are 
> authorized to be given such information.
>
> As far as CalDAV security/privacy issues are concerned, I know Stephen 
> is keen to start a general discussion on that to see if we can tighten 
> up the specs (though I am pretty sure nearly every service already 
> uses TLS everywhere).

I realize the intent wasn't about TLS per se. But it seems like you need 
some protection against evesdroppers to ensure that only the authorized 
recipient gets the information. But I'll accept your judgement on the 
matter.

> I think that is covered by the last sentence in the changes I proposed 
> in response to Stephen's review:
>

Okay, that works for me.

> Um OK. But draft-ietf-calext-extensions-05 was approved with exactly 
> the same language. So to clarify, you would like me to change that 
> text in both this draft and the other, and in both Security and 
> Privacy section?

Well, maybe. My heartburn over the MUST is, if the referenced sections 
also contain 2119 language, you get layered MUSTs. But that's more an 
issue of aesthetics, and not a huge deal either way.

> Again, the same references were used in 
> draft-ietf-calext-extensions-05. Practcally speaking, RFC5545 does not 
> formally define the registries. Instead, section 8.2 defines the 
> overal process for the various registries that are needed. The 
> sub-sections of 8.2 then define templates for use with various 
> registries. The items in section 8.3 are really what IANA keyed off 

It seems to me that the process for registration is relevant here, so 
maybe a reference to both 8.2 and 8.3 makes sense.