On 05-Jul-25 12:09, Toerless Eckert wrote:
On Thu, Jul 03, 2025 at 07:05:34PM -0400, Michael Richardson wrote:
Toerless Eckert <[email protected]> wrote:
> Was wondering: If we are writing explicit requirements into the BRSKI
> considerations documents, should they not rather be BCP instead of
> informational ? I must admit i am completely confused about when to
> choose BCP versus informational when you do use RFC2119 language.
If we are writing BCP14 language, then they are probably updates to RFC8995.
Interstingly, RFC8504 is no update to anything.
It obsoletes RFC6434, however.
Check for example section
5.2. on IPv6 refining extension header usage. If RFC8200 is the bible on
IPv6, maybe the BCP is how to read it correctly ?
The text frequently says things like "As per RFC 8200..." so yes,
there is an element of clarification.
I guess i need to learn from IPv6 experts what happens if someone
would have implemented rfc8200 and later on found out that the way she
read rfc8200 is not how rfc8504 interprets it
IMHO, implementing IPv6 without consulting the Node Requirements
document would be pretty bad engineering practice, like implementing
an IPv4 router without consulting RFC 1812.
and her IPv6 implementation
is not compatible with one that compliex with RFC8504.
This is why i am confused.
I don't see the confusion. If you implement IPv4 based only
on RFC 791, RFC1349, RFC2474 and RFC6864, I doubt that your
code would be much use either. You have to fit in the ecosystem.
Or else 8504 is not declared an update because it would be an update
to so many RFCs, and by making it BCP it's wiggling out of that
responsibility. Which would be weird too.
It isn't supposed to change the definition of any protocol element,
so it doesn't normatively update anything.
This is why i am confused.
I think/hope that most of the content will be say things like:
If you want the XYZ property to always be true when doing ABC, then
the PQRST option needs to be supported.
Right, but what if there are then possibly RFC8995 impleemnations
out there that aren't doing that and would then be non-interoperable
with a new impleemntation that does follow the considerations text ?
That is true. Interop is more than just supporting PDU formats.
With BCP we can use or not use BCP14 language, and I suggest we decide that
part later.
BCP14 language seems to be possible in whatever RFC you write i fear.
There is a strong argument against allowing it in Informational or
Experimental RFCs, but that's never been a rule, afaik.
Regards
Brian
Cheers
Toerless
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
