On Mon, May 19, 2025 at 7:57 AM Marc Petit-Huguenin <[email protected]> wrote:
> On 5/19/25 7:21 AM, Wes Hardaker wrote: > > Nico Williams <[email protected]> writes: > > > >> ASN.1 is much better, though of course you still need a ton of normative > >> natural language. The example RFC regarding ASN.1 as normative would be > >> RFC 5912. It's not possible to write all of RFC 5912's contents as > >> normative natural language text. The _semantics_ of all the things in > >> RFC 5912 require normative natural language text, but the OIDs, the > >> types, the object sets, etc. should be kept in ASN.1. > > > > When trying to improve the quantity and quality of encodable information > > in network management models when moving from MIBs (ASN.1-like) to YANG > > we ran into this sort of issue. Though YANG allows for greater formal > > definition of things, it was very clear that text descriptions would > > always be needed to describe additional semantics of objects and the > > restrictions on their use, beyond just a description (aka "what is it"). > > > TL;DR: it's impossible to formally encode many SHOULDs/MUSTs. > > Let's keep the use of the word “impossible” for things that are really > impossible, and not just very difficult. It may confuse people who do not > understand that “impossible” here is just a figure of speech. > Depending on the formal language, there really are some SHOULD/MUSTS that can't be encoded in it. For example: RFC 8446 https://www.rfc-editor.org/rfc/rfc8446#section-4.6.1 says: ticket_age_add: A securely generated, random 32-bit value that is used to obscure the age of the ticket that the client includes in the "pre_shared_key" extension. The client-side ticket age is added to this value modulo 2^32 to obtain the value that is transmitted by the client. The server MUST generate a fresh value for each ticket it sends. This is not enforceable within the TLS 1.3 language, both and I suspect not within ABNF either. Another example, https://datatracker.ietf.org/doc/html/rfc8829#section-3.5.2.1 If the MID field is present in a received IceCandidate, it MUST be used for identification; otherwise, the "m=" section index is used instead. Implementations MUST be prepared to receive objects with some fields missing, as mentioned above. AFAIK, neither of these MUSTs is plausibly enforceable within any specification language the IETF uses. -Ekr
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
