Code change:
Second round on this one, small tweaks and a small amount of restructuring.
LGTM, made a few smallish comments

Related discussion:
text: 5.1. <del> An insecure origin can commit to providing a secured alternative by including a "commit" member in the http-opportunistic well-known resource (see well-known), whose value is a number representing an </del> <ins> An origin can reduce the risk of attacks on opportunistically secured connections by committing to provide an secured, authenticated alternative service.  This is done by including the optional "commit" member in the http-opportunistic well-known resource (see well- known).  This feature is optional due to the requirement for server authentication and the potential risk entailed (see pinrisks). The value of the "commit" member is the duration of the commitment </ins> interval in seconds. <del> The value of the "commit" member MUST be ignored unless the alternative service can be strongly authenticated.  Minimum authentication requirements for HTTP over TLS are described in Section 2.1 of I-D.ietf-httpbis-alt-svc and Section 3.1 of RFC2818. As noted in I-D.ietf-httpbis-alt-svc, clients can impose other checks in addition to this minimum set.  For instance, a client might choose to apply key pinning RFC7469. If a client is able to obtain a valid http-opportunistic resource (as per well-known) containing a "commit" member and a strongly authenticated alternative service is available, it can assume that such an alternative will remain available for the indicated number of seconds past the current time, less the current age of the http- opportunistic response (as defined in Section 4.2.3 of RFC7234).  A client SHOULD NOT fall back to cleartext protocols prior to that interval elapsing.  Note however that relying on a commitment creates some potential operational hazards (see pinrisks). A commitment only applies to the origin of the http-opportunistic well-known resource that was retrieved; all origins listed in the "origins" member need to independently discovered and validated. Note that the commitment is not bound to a particular alternative service.  Clients can and SHOULD use alternative services that they become aware of.  However, once a valid and authenticated commitment has been received, clients SHOULD NOT use an unauthenticated alternative service.  Where there is an active commitment, clients SHOULD ignore advertisements for unsecured alternative services. </del> <ins> Including "commit" creates a commitment to provide a secured alternative service for the advertised period.  Clients that receive this commitment can assume that a secured alternative service will be available for the indicated period.  Clients might however choose to limit this time (see pinrisks). </ins> 5.2. <del> To avoid situations where a commitment to use authenticated TLS causes a client to be unable to contact a site, clients MAY limit the time over which a commitment is respected for a given origin.  A lower limit might be appropriate for initial commitments; the certainty that a site has set a correct value - and the corresponding limit on persistence - might increase as a commitment is renewed multiple times. </del> <ins> The value of the "commit" member MUST be ignored unless the alternative service can be strongly authenticated.  The same requirements that apply to "https://" resources SHOULD be applied to authenticating the alternative.  Minimum authentication requirements for HTTP over TLS are described in Section 2.1 of I-D.ietf-httpbis- alt-svc and Section 3.1 of RFC2818.  As noted in I-D.ietf-httpbis- alt-svc, clients can impose other checks in addition to this minimum set.  For instance, a client might choose to apply key pinning RFC7469. A client that receives a commitment and that successfully authenticates the alternative service can assume that a secured alternative will remain available for the commitment interval.  The commitment interval starts when the commitment is received and authenticated and runs for a number of seconds equal to value of the "commit" member, less the current age of the http-opportunistic response (as defined in Section 4.2.3 of RFC7234.  A client SHOULD avoid sending requests via cleartext protocols or to unauthenticated alternative services for the duration of the commitment interval, except to discover new potential alternatives. A commitment only applies to the origin of the http-opportunistic well-known resource that was retrieved; other origins listed in the "origins" member MUST be independently discovered and authenticated. A commitment is not bound to a particular alternative service. Clients are able to use alternative services that they become aware of.  However, once a valid and authenticated commitment has been received, clients SHOULD NOT use an unauthenticated alternative service.  Where there is an active commitment, clients SHOULD ignore advertisements for unsecured alternative services.  A client MAY send requests to an unauthenticated origin in an attempt to discover potential alternative services, but these requests SHOULD be entirely generic and avoid including credentials. 5.3. Errors in configuration of commitments has the potential to render even the unsecured origin inaccessible for the duration of a commitment.  Initial deployments are encouraged to use short duration commitments so that errors can be detected without causing the origin to become inaccessible to clients for extended periods. To avoid situations where a commitment causes errors, clients MAY limit the time over which a commitment is respected for a given origin.  A lower limit might be appropriate for initial commitments; the certainty that a site has set a correct value - and the corresponding limit on persistence - might increase as a commitment is renewed multiple times. </ins> 6.