[BLISS] Moving ahead with the ach-analysis draft

["Elwell, John" <[e-mail]>]

One of the issues holding up this draft is the need for a reference to a solution for a UA to query and modify its ACH configuration at a proxy. There had been an expectation of specifying a RESTful solution to this, and referencing that. However, it seems that such work is not progressing, will not get chartered in BLISS, and in the foreseeable future probably won't get done elsewhere. So it seems to me (and this is the guidance I am getting from the chairs), is that we need to progress ach-analysis without this dependency.

So looking at section 7 "Best Practices for ACH" of draft-ietf-bliss-ach-analysis-06, this makes normative statements in 4 areas (7.1 to 7.4).

In the absence of a reference to a RESTful solution to ACH configuration at a proxy, section 7.3 disappears, and we would need to state in 6.6 that for this purpose a RESTful approach could be taken, but that is outside the scope of this document.

Having removed 7.3, the fate of 7.4 "Notifying a UA of an ACH configuration change at the proxy" is in doubt. The intention was to reference draft-roach-sip-http-subscribe, which is in the RFC Editor's queue, so no problem in principle. The question is, whether it makes sense to specify a way of being notified of changes, without specifying anything about how to view or modify ACH configuration at the proxy. The http-subscribe draft is intimately tied up with HTTP, in particular using the Link header to convey the SIP URI to send the SUBSCRIBE request to. So specifying the use of http-subscribe alone doesn't seem to make sense.

Alternatively we could take a similar approach to that in draft-lawrence-sipforum-user-agent-config, and specify a little bit on basic assumptions of HTTP usage, including the Link header, Etag and Last-Modified.

Or alternatively, we could also remove section 7.4, leaving only 7.1 and 7.2 as best practices. Is this sufficient material to justify a BCP RFC?

Or is the whole document past its sell-by date?

So I would like opinions, particularly on whether to:
- Option 1 - replace 7.3 and 7.4 with just a simple reference to http-subscribe (but saying nothing about HTTP usage).
- Option 2 - replace 7.3 and 7.4 with something that references http-subscribe and says some generic stuff about HTTP usage for accessing configuration at the proxy and how notifications work.
- Option 3 - remove 7.3 and 7.4 altogether, just leaving 7.1 and 7.2 as the only normative part of the BCP.
- Option 4 - as option 3, but change to Informational, i.e., focus on publishing the analysis part and play down the BCP part.
- Option 5 - abandon the work item if there is insufficient interest in the WG.

As a matter of interest, who would anticipate implementing the recommended practices?

John (as editor)