| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Glen As long as we stick with just two key indexes (current and next), it seems like a reasonable proposal to me. Regards Marek From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> On Behalf Of Glen Kramer I think there is a bit of over-specification in the first draft. It can be simplified, while making it more robust at the same time. The Config Encryption Key TLV contains two fields – key index and key value. The key index has a specific constraint: “The index of the key being provisioned is the opposite of the index of the currently active key. The ONU shall respond with the “Bad Parameters” code 0x86 (see 13.4.7) to a request to provision a key with the index equal to the index of the currently-active key, as indicated by the Encryption key index field (K-bit) in the received envelope header (see IEEE Std.802.3, 143.3.2).” The OAM message that carries the Config Encryption Key TLV is always encrypted, so the header of envelope that contains this OAMPDU also carries the index of the currently-active key. I think it would be better to not transmit the Key Index field as part of the TLV. The ONU can always deduce the index for the next key as the opposite of the index of the currently-active key. This way, there will never be a situation where ONU will have to respond with “Bad parameters” because of the index mismatch. Any thoughts? Glen To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1 To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1 |