[BLISS] Moving ahead with the ach-analysis draft - take 2

["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. Up till now, progress on this in BLISS had been minimal, but we now have a new draft on this topic, submitted to DISPATCH by Rifaat Shekh-Yusef:
http://datatracker.ietf.org/doc/draft-yusef-dispatch-ach-rest-api/

Prior to this, the guidance I was getting from the BLISS chairs was that we need to progress ach-analysis without this dependency. Is this still the case, or do we wish to delay ach-analysis further in anticipation of progress with the ach-rest-api draft? My assumption is that we still want to finish ach-analysis somehow, to help clear the way for closing down the BLISS WG.

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)