Fernando said:
"If that were the case, anything and everything would be published as an RFC."
[BA] So you're saying that this is not the case already?
"Among other things, the specs we publish are supposed to be subject to a
decent level of review, and are also supposed to be coherent groups of
specifications."
"Among other things, the specs we publish are supposed to be subject to a
decent level of review, and are also supposed to be coherent groups of
specifications."
[BA] Please feel free to design a process that can accomplish this, given the level of participation we have within the IETF.
The IESG members have a near-impossible job, so they have to rely on Directorates, who in turn do the best they can. But the IETF process exercises much of its restraint at the beginning of the process (*before* a WG is chartered). Once Chartered, it is rare for a WG document with sufficient energy behind it to fail to get through the process. The review process does not guarantee that drafts conform to BCPs or IAB statements, let alone consistency with other RFCs.
"If you have one spec that says one thing, and then you have another, from the same Std Org, that says the opposite, without "obsoleting" the former, then you end up with something that won't have a single bit of coherence, virtually impossible to digest by anybody else other by than a limited group of people that just happens to know how everyone
violates each others specs."
violates each others specs."
[BA] This has been the case from the earliest days. For example, as documented in RFC 4840, back in the early 1980s, there were 3+ approaches to the encapsulation of IP on Ethernet/IEEE 802.1. Yet the marketplace sorted things out then, as they did later when some of the same issues arose with WiMax/802.16 (RIP). If there are dueling approaches, it is often best to document them; rather than relying on standards bodies to "choose a winner".
On Thu, Feb 27, 2020 at 5:41 PM Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
On 27/2/20 22:05, Bernard Aboba wrote:
> Fernando said:
>
> "May I ask what is the point of bothering publishing specs if they are
> going to be violated at will *within the same organization that
> published the specs*."
>
> [BA] The point of publishing specifications is to make them available
> for evaluation and potential implementation. It's a contribution to the
> "marketplace of ideas".
It would seem to me there's much more than that.
If that were the case, anything and everything would be published as an RFC..
Among other things, the specs we publish are supposed to be subject to a
decent level of review, and are also supposed to be coherent groups of
specifications.
If you have one spec that says one thing, and then you have another,
from the same Std Org, that says the opposite, without "obsoleting" the
former, then you end up with something that won't have a single bit of
coherence, virtually impossible to digest by anybody else other by than
a limited group of people that just happens to know how everyone
violates each others specs.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
