Wobei die Frage nicht so ganz unberechtigt war ... mich würde auch mal interessieren, wie es möglich ist, im KDG-Netz auch heute noch eine 6360 mit 06.06 zu betreiben und da habe ich jemanden in der Familie, der so eine 6360 (vom Provider) betreibt.
Ich dachte ja mal, daß die von VF angekündigten Updates der 6360 (neben anderen Problemen) dann auch das Zertifikate-Thema angehen würden (mit demselben Mechanismus - Speicherung in /nvram und nie wieder löschen - wie er bei den älteren 6490 auch improvisiert wurde) und daß die Updates auch deshalb erfolgen sollten (praktisch "in der Deckung" der Meldung zum Telefonmißbrauch).
Nachdem die nun aber (bisher zumindest) doch nicht stattgefunden haben, müssen wohl wenigstens einige CMTS bei KDG auch noch ältere Boxen akzeptieren - die erwähnte 6360 wurde jedenfalls in den letzten 12 Monaten nicht aktualisiert, denn meine eigenen Zusätze zur Firmware (ein "heartbeat" beim DynDNS-Server alle 5 Minuten) sind dort immer noch aktiv. Wenn da also neue Zertifikate in /nvram liegen sollten (ich schaue heute abend mal drauf, dort ist nur keine Fernwartung aktiviert), dann müßten die irgendwie ohne ein Firmware-Update (zumindest ohne eines, das ein neues Filesystem geschrieben hat) auf die Box gekommen sein.
Da KDG/VF die 6360 auch schon anhand der MAC-Adresse identifizieren können sollte, wenn ein Kunde versucht, eine solche im Webformular zu registrieren (ich habe hier auf die Schnelle die OUID 9C:C7:A6 gefunden in den vorliegenden alten Support-Dateien), wird das aber wohl ohnehin nichts werden ... ich will also nur wissen, wie sich die 6360 mit der alten Firmware authentifiziert und nicht irgendwie andeuten, daß da KDG/VF dem Kunden irgendwie entgegenkommen müßte (oder sollte), ganz im Gegenteil, ich würde "eine Lanze brechen" wollen für die Forderung der KNB nach einem (heute) aktuellen Gerät für 24+8 Kanäle.
Wenn ein Gerät nicht genügend Kanäle beherrscht, schränkt das den KNB bei der Zusammensetzung seiner US/DS-Kanäle für die unterschiedlichen Service- und Bonding-Groups entsprechend ein und während er bei den eigenen Geräten ja jederzeit einen Austausch vornehmen kann und so irgendwann keine 8+4, 16+4 oder was auch immer mehr bedienen muß (wenn hinter dem betroffenen CMTS keine solchen Geräte aus seinen Altbeständen mehr existieren), kann er später dem Kunden ja schlecht vorschreiben, der solle sich jetzt gefälligst auch ein neues Gerät besorgen.
Also sieht die Schnittstellenbeschreibung gleich einen "Mindeststandard" vor, der ein wenig auf die Zukunft ausgerichtet ist (trotzdem erprobt und auch in diversen Geräten unterstützt ist, es ist ja nicht so, daß es nur die 6490 gäbe - rein von der Existenz der Geräte her, was der Handel da anbietet, weiß ich nicht) und auch das halte ich durchaus für legitim. Wenn jeder Kunde mit so einem alten Gerät einen "Haftungsausschluß" dahingehend akzeptiert, daß der Betreiber jederzeit die Unterstützung solcher älteren Modelle einstellen kann und der Kunde sich dann um ein neueres Modell selbst kümmern muß, ist das wieder etwas anderes - wenn ein KNB sich da aber auf nichts einlassen will (das ist ein Massen- und kein Individualgeschäft), kann man das sicherlich auch nachvollziehen.
Ohne eine (zumindest ähnliche) Vereinbarung sind ältere Kundengeräte früher oder später ein Hemmschuh bei der Umkonfiguration des Segments, weil im schlechtesten Falle am Ende 8+4 Kanäle in einer Service-Group für einen einzelnen Kunden "reserviert" werden müßten (auch wenn ein Channel in mehr als einer Bonding-Group sein darf) oder sogar die Technik für EuroPacketCable 1 (auch 1.5 ist noch "1", nur etwas erweitert, deshalb heißt es wohl auch nicht gleich "2") weitergeführt werden müßte, auch wenn die eigene Technik irgendwann komplett auf SIP-Signalisierung umgestellt ist.
Wer sich heute kein wirklich aktuelles DOCSIS-Gerät selbst beschaffen will, kann ja eines vom Provider nehmen (einige Provider sollen das ja für "Prüfzwecke" ohnehin beim Kunden lagern, spart auch ungemein an Lagerkapazitäten (und -kosten) bei den Logistik-Dienstleistern) ... jetzt irgendwelche alten Krücken als eigene Geräte dort zuzulassen, macht m.E. auch nicht wirklich Sinn.
Bei anderer Anschlußart ist das wieder etwas anderes ... bei der DSL-CuDA ist es den anderen Kunden (und dem Provider) schnuppe, wie alt das Modem beim Kunden ist. Das ist ein wenig wie mit dem 802.11b beim WLAN, auch dessen Einsatz auf nur einem Client bremst dann alle anderen (auch nach anderen Standards verbundenen) Clients ebenfalls aus. Selbst wenn hier kein anderer Kunde wirklich "ausgebremst" würde (weil der eben auf anderen Kanälen arbeitet), liegen diese Kanäle dann doch am Ende brach und könnten (ggf. mit anderen) wieder zu einer neuen SG oder BG zusammengesetzt werden, womit man dann die Kunden auch wieder anders verteilen könnte, wenn es enger wird im Segment.
Auch die Frage, welche Modulation ein Gerät auf einem Kanal beherrscht (die unterschiedlichen Standardrevisionen verwenden ja auch unterschiedliche QAM-Verfahren, selbst wenn spätere Versionen die früheren einschließen), spielt für einen "Mischbetrieb" dann wieder eine Rolle. Wenn irgendeine Krücke unbedingt einen US-Channel mit QPSK oder QAM16 braucht, muß es eben so einen Kanal geben, der kann dann auch für andere (neuere) Geräte nur mit dieser Modulation genutzt werden (was Kapazität verschenkt, wenn alle angeschlossenen Geräte auch Modulationen mit mehr Symbolen pro Schritt beherrschen würden).
