| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 |
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature