RE: [PATCH bpf-next] bpf, docs: Use RFC 2119 language for ISA requirements

[dthaler1968@googlemail.com]

> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Monday, May 20, 2024 4:18 PM
> To: Dave Thaler <dthaler1968@googlemail.com>
> Cc: bpf@vger.kernel.org; bpf@ietf.org; Dave Thaler <dthaler1968@gmail.com>
> Subject: Re: [PATCH bpf-next] bpf, docs: Use RFC 2119 language for ISA
> requirements
> 
> On Fri, May 17, 2024 at 09:58:55AM -0700, Dave Thaler wrote:
> > Per IETF convention and discussion at LSF/MM/BPF, use MUST etc.
> > keywords as requested by IETF Area Director review.  Also as
> > requested, indicate that documenting BTF is out of scope of this
> > document and will be covered by a separate IETF specification.
> >
> > Added paragraph about the terminology that is required IETF
> > boilerplate and must be worded exactly as such.
> >
> > Signed-off-by: Dave Thaler <dthaler1968@googlemail.com>
> 
> Acked-by: David Vernet <void@manifault.com>
> 
> We still have "may" in a couple of places, as in e.g.:
> 
> Note that there are two flavors of ``JA`` instructions. The ``JMP`` class
permits a
> 16-bit jump offset specified by the 'offset' field, whereas the ``JMP32``
class
> permits a 32-bit jump offset specified by the 'imm' field. A > 16-bit
conditional jump
> may be converted to a < 16-bit conditional jump plus a 32-bit
unconditional jump.
> 
> Also in the "Helper functions" and "Maps" sections.
> 
> Do we need to fix those as well? Or are they considered semantically
different
> than how RFC 2119 would define the terms?

Those are semantically different (i.e., I left them intentionally) as they
are not
normative statements about what an ISA implementer would choose to do or not
do, but rather informative statements to the reader that would be synonymous
with
"can" or "might" in my reading.

Dave
> 
> Thanks,
> David