RE: Ben Campbell's Yes on draft-ietf-httpbis-alt-svc-13: (with COMMENT)

[Mike Bishop <[e-mail]>]

2.2 - Hypothetically, a more complex client might cache per network location and revive the cached entries when it returns to the network where it received them.

I think your reading of MAY/SHOULD is correct.  Using Alt-Svc itself is totally optional -- but if you choose to, this is when you SHOULD switch to a given alternative.

-----Original Message-----
From: Ben Campbell [mailto:[e-mail]] 
Sent: Tuesday, March 1, 2016 7:21 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; Mike Bishop <[e-mail]>; [e-mail]; Mike Bishop <[e-mail]>; [e-mail]
Subject: Ben Campbell's Yes on draft-ietf-httpbis-alt-svc-13: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-httpbis-alt-svc-13: Yes

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-httpbis-alt-svc/



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

Just a few minor comments:

= Substantive =

- 2.2, last paragraph:

Why might a client choose not to to remove non-persistent alternatives from cache on a network change? (i.e., why not MUST)?

- 2.4, first 2 paragraphs:

These paragraphs seem to be equivalent to saying “Clients MAY use alternative services; also they SHOULD.”  Or is the intent that, if a client uses alternative services, it SHOULD do so under these conditions?

= Editorial =

- 2.3, first paragraph:
I find "MUST only" constructions to be confusing and sometimes ambiguous due to the implied NOT. I suggest making that explicit:
OLD
   A client MUST only use a TLS-based alternative service if the client also supports TLS Server Name Indication (SNI).
NEW
   A client MUST NOT use a TLS-based alternative service unless the client supports TLS Server Name Indication (SNI).