Nut upsuser - Mar 2022 - ISE review of I-D: deprecate command VER?

On 20.03.22 16:02, Roger Price wrote:
>I received the following comment from the Independent Submissions Editor
(ISE):
>
> The command VER is hazardous because it encourages exploiting of
> implementation peculiarities that are not well documented in a
> protocol.? The best example of such a failure is the browser version
> field in HTTP.? A complete disaster.? You should warn against use of
> this command, or even better, deprecate it.
>
>I was not aware of the disaster in the browser version field, but I 
>will warn against use of VER, and deprecate it, if you agree.
Isn't this designed for announcing protocol version for compatibility?

-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"To Boot or not to Boot, that's the question." [WD1270 Caviar]

Matus UHLAR - fantomas <uhlar at fantomas.sk> writes:
> On 20.03.22 16:02, Roger Price wrote:
>>I received the following comment from the Independent Submissions Editor
(ISE):
>>
>> The command VER is hazardous because it encourages exploiting of
>> implementation peculiarities that are not well documented in a
>> protocol.? The best example of such a failure is the browser version
>> field in HTTP.? A complete disaster.? You should warn against use of
>> this command, or even better, deprecate it.
>>
>> I was not aware of the disaster in the browser version field, but I
>> will warn against use of VER, and deprecate it, if you agree.
>
> Isn't this designed for announcing protocol version for compatibility?
Protocol version is one thing and should be defined by the RFC.  All
implementations of the protocol should advertise the same version.

Software type/version of the implementation is something else.


Yes, everything may be from nut sources, but having a protocol RFC is
about moving from "the protocol is defined by the code" to "the
protocol
is defined by the spec".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220321/18017995/attachment-0001.sig>

On 3/21/22 15:08, Greg Troxel wrote:
> Matus UHLAR - fantomas<uhlar at fantomas.sk>  writes:
>
>> On 20.03.22 16:02, Roger Price wrote:
>>> I received the following comment from the Independent Submissions
Editor (ISE):
>>>
>>> The command VER is hazardous because it encourages exploiting of
>>> implementation peculiarities that are not well documented in a
>>> protocol.? The best example of such a failure is the browser
version
>>> field in HTTP.? A complete disaster.? You should warn against use
of
>>> this command, or even better, deprecate it.
>>>
>>> I was not aware of the disaster in the browser version field, but I
>>> will warn against use of VER, and deprecate it, if you agree.
>> Isn't this designed for announcing protocol version for
compatibility?
> Protocol version is one thing and should be defined by the RFC.  All
> implementations of the protocol should advertise the same version.
That is 
https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-07.html#name-protver
...

>
> Software type/version of the implementation is something else.
... versus 
https://www.ietf.org/archive/id/draft-rprice-ups-management-protocol-07.html#name-ver
which is a different beast

> Yes, everything may be from nut sources, but having a protocol RFC is
> about moving from "the protocol is defined by the code" to
"the protocol
> is defined by the spec".

I agree with that. But I still see no problem in advertising the 
software version. After all, each time I boot I see:

    Mar 20 22:19:03 wolfy3 kernel: Linux version
    3.10.0-1160.59.1.el7.x86_64 (mockbuild at kbuilder.bsys.centos.org)
    (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Wed
    Feb 23 16:47:03 UTC 2022

I know not only the kernel version and distribution but even the 
compiler version that was in use. Which, incidentally, is important in 
some contexts

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220321/2478ff7a/attachment.htm>

>> On 20.03.22 16:02, Roger Price wrote:
>>> I received the following comment from the Independent Submissions
Editor (ISE):
>>>
>>> The command VER is hazardous because it encourages exploiting of
>>> implementation peculiarities that are not well documented in a
>>> protocol.? The best example of such a failure is the browser
version
>>> field in HTTP.? A complete disaster.? You should warn against use
of
>>> this command, or even better, deprecate it.
>>>
>>> I was not aware of the disaster in the browser version field, but I
>>> will warn against use of VER, and deprecate it, if you agree.
Thanks very much for the helpful discussion.

1. I will not deprecate VER, but I will explain to the ISE that NUT is very 
different to the HTTP disaster situation, and that we do not have millions of 
users of broken clients.

2. I will explain that "current practice" is for a client, known as a
Management
Daemon, to fall back to an earlier command form if a command fails.  E.g. if 
PRIMARY fails, fall back to MASTER.

3. The ISE requires that the I-D state clearly which version of NUT, as returned
in response to command VER, is documented by the I-D.  I have written the I-D in
terms of NUT 2.7.4, but it would probably be better if the ID referred to 
upcoming 2.8.0.  This will make it clearer what "current practice"
means.

Do you agree that the I-D should refer to 2.8.0?

4. The I-D must also say which protocol version it documents, as returned in 
response to command PROTVER (formerly NETVER).

Will this stll be 1.2 in NUT 2.8.0, or will it move to 1.3?

Roger