"* On the procedural area:
+ Where/how should IETF WGs seek for architecture-related advice"?
I finded Dave Thaler said in "Evolution of the IP Model" (2009):
"(From the 1978 IEN, the 1980 RFC 760 to the 1981 RFC 7611:) The evolution didn’t stop there, however, and the IP model has continued to change over the years to meet new demands. Some of those changes were intentional. Some were because we found deficiencies. Others were the result of new capabilities. Often, the changes were a consequence of trying to do something else.
By 1989, there was already some confusion concerning the IP model. RFC 1122 was written in an effort to clear up some of that confusion as well as to extend the service model. There are plenty of other RFCs that offered advice on various specific aspects of the IP model, and as a result, to gain an understanding of the IP model, one needed to search many RFCs.
Another RFC appeared in 2004, which is probably the one that is closest in spirit to this work. That one-RFC 3819-offered advice for link-layer protocol designers on how to minimize the impact on layers above the link layer. Hence, it dealt with the service model at the bottom of IP, whereas the present work deals with the service model at the top of IP.
...".
Pada Jumat, 28 Februari 2020, Fernando Gont <fgont@xxxxxxxxxxxxxxx> menulis:
On 28/2/20 01:15, Bernard Aboba wrote:
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?
Yes, that's not the case, particularly for people that participate independently.
"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.
There's a big difference between a document being published, and the authors of a document crafting whatever they please into that document, and having the IETF rubberstamp it.
"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."
[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".
I'm not referring to competing technologies. I'm talking about one spec (e.g. SRv6) blatantly violating another one (IPv6).
When you have conflicting specs, you're kind of at odds with being a *standards* organization.... -- nobody knows what to expect, because one document says one thing, and another says another thing.
There's a reason for which we have the "Update" and "Obsolete" tags in RFCs...
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@xxxxxxxx
https://www.ietf.org/mailman/listinfo/architecture-discuss
