Hi Adrian,
Bit disappointed that this is a Discuss.
I wrote: "Ron's point, part of the OPS-DIR review, looks valid to me.
Can we please discuss it."
More polite than this, that becomes to be difficult :-)
But let's discuss it.
Ron's point, part of the OPS-DIR review, look valid to me. Can we please
discuss it.
This document is well written and well thought out. It is almost ready
for publication with one small issue.
In Section 2.3, the authors say, " ACCEPT_OWN handling SHOULD be
controlled by configuration, and SHOULD default to being disabled. IMO,
they should say, "ACCEPT_OWN handling MUST be controlled by
configuration, and MUST default to being disabled."
AFAIKS, you would never want to build a router where ACCEPT_OWN behavior
is always on and cannot be disabled by configuration. Likewise, you would
never want to build a router where ACCEPT_OWN behavior is the default.
I reject specifications that control what one might want to build. We produce
specs to define interoperable behavior and to ensure the Internet works. We
don't legislate for people producing product in niches or that is entirely
unsalable.
However, let's separate the two SHOULDs.
Suppose one wanted to build an implementation where the feature is not
controlled by configuration and is always disabled?
In that case you would be banned from doing so if "ACCEPT_OWN handling MUST be controlled by
configuration", so I would say that "SHOULD" is correct in the first case.
I suspect the second "SHOULD" is a consequence of a compound sentence.
If we had "ACCEPT_OWN handling SHOULD be controlled by configuration, and if
controlled by configuration it MUST default to being disabled" then that might be
closer to correct according to what Ron is suggesting.
That makes sense to me (and to Ron, I just checked)
Thanks,
Adrian
PS. Would have helped if the original review had reached the AD, shepherd, and
WG. Maybe also the IETF list.
Sure.
Regards, Benoit
.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
