Subject: [tcpm] Alexey Melnikov's No Objection on draft-ietf-tcpm-converters-17: (with COMMENT)

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Thu, 05 Mar 2020 07:25:24 -0800

Alexey Melnikov has entered the following ballot position for
draft-ietf-tcpm-converters-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It is not very clear whether the WG expects many future version of this
protocol. Version compatibility story is not very clear in this document, so
the WG should think about it.

---

From: <[email-masked]>
Date: Thu, 5 Mar 2020 16:44:18 +0000

Hi Alexey,

Thank you for the comment. 

We do already have the following for version negotiation:

   o  Unsupported Version (0): The version number indicated in the fixed
      header of a message received from a peer is not supported.

      This error code MUST be generated by a peer (e.g.,  Transport
      Converter) when it receives a request having a version number that
      it does not support.

      The value field MUST be set to the version supported by the peer.
      When multiple versions are supported by the peer, it includes the
      list of supported version in the value field; each version is
      encoded in 8 bits.  The list of supported versions MUST be padded
      with zeros to end on a 32 bits boundary.

      Upon receipt of this error code, the remote peer (e.g., Client)
      checks whether it supports one of the versions returned by the
      peer.  The highest common supported version MUST be used by the
      remote peer in subsequent exchanges with the peer.

Should a future version be defined but with a different message format, the version field and the above procedure can help to agree on version to be used if there is a match. If no match is found, the communication will fail. 

Are there other backward compatibly considerations we need to record? Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Alexey Melnikov via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 5 mars 2020 16:25
> À : The IESG
> Cc : [email-masked]; [email-masked];
> [email-masked]; Michael Scharf; [email-masked]
> Objet : Alexey Melnikov's No Objection on draft-ietf-tcpm-converters-
> 17: (with COMMENT)
>