This seems to be written by someone who spends a lot of time (and has a lot of knowledge) about high level application stuff but lacks an understanding of the existing network technology they are writing about or what purposes real world networking models need to serve. Apologies for the huge block of text, I'm not sure how to format this better.

> Data Link and Physical layers
For our purposes today, the Data Link and Physical layers are a black box (perhaps literally), to which we have an interface (the “network interface”) which looks like a transmit queue and a receive queue. These queues can store “payloads” of anywhere from 1 to 1280[1] octets (bytes).

1) The physical layer and data link layer almost always have different size and structure

2) Data link layer queues aren't defined by network layer payloads

3) IPv6 specifies a MINIMUM payload of 1280 octets

4) For most of the internet and private systems ~1500 is the standard payload limit due to the Ethernet standard.

> We would like a received payload to self-evidently be the same payload which was sent. Although the Data Link layer is supposed to provide such an assurance, various kinds of attacks on the system might invalidate this assumption. Integrity protocols mitigate these attacks:
- 1 Thermal noise, cosmic rays checksum hash TCP Checksum CRC-32C

1) TCP Checksums are not part of and do not validate the
data link layer headers.

2) Ethernet aleardy includes the FCS (CRC) as a form of check (as most data link layers have).

3) Physical layers also commonly have forms of integrity checking

> 2 Deliberate corruption cryptographic hash SHA-1 BLAKE2b
3 Spoofing of trusted contacts keyed hash HMAC-SHA1 SipHash
4 Spoofing of strangers public-key signature of cryptographic hash SHA-1 + RSA BLAKE2b + Ed25519

1) I'm not sure where these "common implementations" are comming from on the data link/physical layers, AES encryption via DTLS/MACsec or encryption via DTLS are the standards here.

> A fully implemented Availability layer should provide unicast (deliver to a unique endpoint authenticated by a given public key, wherever it may be), anycast (deliver to nearest endpoint authenticated by a given public key), and multicast (a.k.a. pub/sub: route to all endpoints who have asked to subscribe to a given ID, and provide a subscription method).

1) Multicast sounds great until you consider the billions of devices across untold number of paths on the internet and look at the line that started the paragraph "We would like networked endpoints to be available to receive packets from other endpoints in a way that is robust to unannounced changes in network topology.". It's hard enough today to announce and learn unicast paths between network aggregated endpoints and the author wants to add multicast paths/typologies to the mix while throwing out the abstraction of the port in favor of service based networking?

2) [personal opinion] moving more "work" from ports (which are supposed to be an inside the END NODE thing cough ipv4 NAT cough) into "the network" almost never seems to sell me on being a sustainable/worthwhile tradeoff. The less your layer needs to know to deliver something the more flexible and upgradable communication becomes.

> Confidentiality layer
Ideally, we would like to not transmit any information to anything other than the destination endpoint(s). This ideal is not in general achievable on a public network, but some types of mitigation are possible: ...

1) A layer has to be more than "this is the encryption algorithm we use".

2) Encryption should not be a layer high up the stack, it should be something available at any point and able to be performed multiple times to allow levels of trust or defense in depth

3) Is there anything the author doesn't like about existing solutions for this layer like IPsec other than AES is most commonly used rather than ChaCha and similar variants?

> Non-Repudiation and/or Repudiation layer
> We would like for a receiver to be sure that a message they receive was sent by a given sender, and we would like for a sender to be sure that a given message was successfully received. Sometimes, we would also like for a receiver to be unaware of the location a message was sent from

1) This layer needs to be fully option as

a) many real-time messages don't want confirmation information to bog things down

b) repudiation of origin needs to be optional unless society agrees it's more important than performance (it won't)

> Transactions layer

[personal opinion] this needs to be part of the application layer functionality to prevent the ossification of implementations and protocols.

General comment on the topic - The OSI model wasn't meant to be viewed like it is today and as a result spends a lot of time defining how to stratifying things that don't need to be stratified in the modern world. One thing I'd like to tell EVERYONE about network is "stop thinking of network models as a set of 1 dimensional abstractions".