[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] RRG process clarification

Faceting classification (http://www.miskatonic.org/library/facet-web-howto.html , very interesting ) :
In my last email, see also below, replace the term "architecturally" with "from the point of view of faceting classfication" ! The Type of Operation/Service/Process is a perfect fit for Faceting Classification.
In einer eMail vom 03.05.2008 15:31:56 Westeuropäische Normalzeit schreibt HeinerHummel@aol.com:
On this thread I suggested to relax the IPv4 depletion issue by replacing the Multicast addresses with a new "Multicast" Protocol Type combined with the sender's Unicast address. Indeed, the reaction was absolute silence. I expected at least opposition by referring to backward compatability (what is taken, is taken) and that it may need some flag day, announced well in advance. IMO, who can check for class D, may as well check for a new protocol type. But the reaction was a storm of unsent messages.
I also meant it architecturally: I think the type of operation (or should I say TOS ?) is worth to be indicated in the header. It could be p2p-Unicast as well as p2p-Anycast, p2mp-Multicast, p2mp-Broadcast, mp2mp-Multicast, mp2mp-Broadcast, and (who knows ) mp2p. Indicating the type of operation by means of different address ranges is a bad design.
Imagine, at some point in time in the future, there were some desire for multiple address families.
Should then each AFI be combined with a respectively special address range as to indicate the type of processing? It would even be worse -architecturally.