On 5/19/25 8:03 AM, Eric Rescorla wrote: > 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. >
My point is that the tl;dr should have been: it's impossible to formally encode many SHOULDs/MUSTs within any specification language the IETF currently uses. -- Marc Petit-Huguenin Email: [email protected] Blog: https://medium.com/@petithug Profile: https://www.linkedin.com/in/petithug
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
