Re: [Edm] On Section 3.2. At what level should versioning occur?

[Martin Thomson <[e-mail]>]

On Thu, Aug 5, 2021, at 19:00, Eliot Lear wrote:
> I really like your section 3.2, but it does presume that the lower 
> layers are able to accommodate exposing of version information.  Below 
> the IP layer, when IEEE 802 is used, we are in very good shape; but does 
> everything below that hourglass neck have that attribute, and do we want 
> to demand that in order to implement v4/v6?  To that end, my suggestion 
> is that you simply note this as an issue when we interact with other 
> technologies.

More on this below, but I don't read Section 3.2 as declaring a mandate, but just as making a suggestion.
 
> Interestingly, when we do port allocations, we generally say that 
> applicants SHOULD include versioning information in their protocols 
> because the IANA will not allocate new port numbers for existing 
> services.  But is that the right approach, and what is meant by an 
> existing service?  

The idea that port == service is largely a dead idea, so I don't see port numbers are relevant to this discussion.  (I think that we should probably not accept more allocations, without exceptional justification.  We have SRV and SVCB and other discovery/configuration things in ample measure.)

Your advice is very much valid there.  You are saying that TCP/UDP port numbers are not good for versioning.  That's right because they aren't.  That's not what they were designed for and that is not how they are used in practice.

> If the service is accomplishing the same thing, but 
> the encoding of the underlying protocol has shifted, should we really be 
> so strict?  While some quickly envision the world moving to QUIC, let's 
> agree that there are some applications that won't find QUIC to be The 
> Answer, and that port numbers may remain a somewhat scarce resource.  
> And so maybe a version field ISN'T such a big deal, but requires 
> additional protections for future use for those who are keeping score, 
> yes I'm arguing both sides of the issue].  

This is probably a different question now, and outside the scope of this work.  (I'll note that you said "strict" here, but I don't see anything that mandates a particular design direction in the draft. It seems pretty clearly optional advice to me.)

FWIW, as you mention ports, my position on *transport-level* versioning goes something like:

1. port numbers are not for versioning
2. consequently new transport protocols need versioning (this includes transport-adjacent protocols like TLS) or some way to allow for their eventual replacement; this is because there is no functioning facility in the IP layer (or UDP or TCP for that matter)
3. new transport protocols are expensive to build and should be rare (the difficulty of building a versioning scheme is part of that)
4. new uses of transport protocols should be secured and should use TLS or QUIC
5. new uses of transport protocols that use TLS or QUIC can use ALPN to manage their own versioning and so do not need their own versioning design

This document covers points 2 and 3 and talks generically about point 5, which is all it can really do.

> One example might be that 
> two-party protocols never FAIL when they see a greased version but 
> simply come back with "version not supported" or "I see grease" or some 
> such.

That is essentially how QUIC and TLS work (though "I see grease" => "grease is just ignored").