[Ops] Note draft: "Operational Identification"

[Mark Taylor]

Pierre,

thank you for your comments.

On Mon, 1 Mar 2021, Pierre Fernique wrote:

> Dear Ops IG,
> 
> The idea of encouraging VO customers to use a sufficiently 
> discriminating User-Agent is an excellent initiative. And at CDS, we are 
> particularly in favour of such a evolution. Many thanks for all people 
> involve in this effort,
> 
> Concerning the "pre-note" itself, it seems very clear to me.
> 
> I have noted a technical point that I raise. The document mentions three 
> types of op-purpose: validate, monitor, harvest.I think the first two 
> will be not so easy to differentiate. In practice, they are usually the 
> same tools that perform both functions, and it is unlikely that 
> developers will modify the User-agent to suit the use that the user will 
> be made of it. Maybe keep only one term: "check" ? Also, the notion of 

I agree that there will be grey areas between validation and monitoring,
though e.g. most of the activities that I can recall being presented 
in recent Ops IG sessions fall fairly clearly into one or the other
category (e.g. the weather reports carried out by VO-Paris and ESAC,
and taplint are validation activities, while the servicemon tool
presented by Tom Donaldson at the last interop was monitoring).
But it's true that the distinction is not that important for the
purposes that I'd envisage - identifying which queries are
non-science ones.  I'd be inclined to keep the terms "validate"
and "monitor", but I don't have very strong feelings about it,
so if others think "check" would be better, we can change it.

> "harvest" may be too "VO registry" oriented and very limited in 
> practice. I'm afraid it won't be used for other inter-center data 
> synchronization operations. It would probably be interesting to enlarge 
> its usage by giving some other examples for the use of this 
> "op-purpose": Synchronizing data from one server to another server => 
> notably Hipsgen MIRROR could use this term, or Simbad's recurring global 
> queries for populating partner DBs. I was also wondering about the 

That sounds reasonable, maybe a more neutral term like "mirror" would
be better?  Markus as more of a registry expert than me might want to
comment.

> possibility of adding a term such as "proxy" to list clients acting only 
> as relays - usually to bypass a technical access restriction (ie: 
> javascript)

Do we have examples of this?  Are there use cases where services
would want to distinguish proxies from direct client access?
Even if not, or if there's only a weak argument for its usefuless,
we could add this option to the document for possible future use,
since it's not really costly to do so (if nobody uses it, no harm
is done).

> Concerning the identification of servers (section 3), I was wondering 
> about the ease/difficulty of its application. Very concretely, it would 
> imply that each data provider in the IVOA would have to modify their 
> servers in order to generate the appropriate header. In the case of the 
> CDS, some HTTP servers have multiple functions and this will require 
> intervention on each component (CGI level, library level, tomcat level, 
> etc.). A probably delicate operation to plan for the long term - 
> probably following the upgrades of these different components.
> 
> This is why I think that we should stay at the level of suggestion as 
> mentioned in the document, and not be tempted to go towards a strict 
> recommendation that might in practice be very constraining for some IVOA 
> members.

Absolutely.  This is only intended as a guide for best practice, so
that if people feel they can or should do something along these lines,
it gives specific guidance for how to go about it.
I can imagine that in many cases fixing your server software to
insert custom response headers would be a major technical challenge,
and it would be impractical to try to require people to do that.
Perhaps we should emphasise this point in the text.

> Finally, I draw attention to the fact that modifying existing 
> User-agents will necessarily require an adjustment of the tools 
> (filters/scripts/...) used by the different centers to perform their 
> statistics. In the case of the CDS (server side), such a unilateral 
> modification will cause a lack of measurements, the time to identify the 
> modifications and to adapt the processing tools. Symmetrically, I 
> suppose that the modification of the User-agents used by our clients and 
> CDS libraries could not be done without warning the different known 
> actors. I suggest that in the note, modalities to warn the different 
> actors should be indicated: planned date for the modification, old 
> User-agent and new User-agent. Possibly by using IVOA mailing list, or a 
> dedicated page in the IVOA twiki, or other adapted channels.

Are you saying that if clients/services adopt the practices
outlined in the Note, you envisage negative impacts for existing
services/clients?  To a large extent the guidelines are just
emphasising existing HTTP best practice, and some software is
already following these recommendations.

Mark

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/