Francesca, Sean, > Section 6.1: AT_PUB_ECDHE. The way Length is defined in RFC4187 (specifying > the > length of the attribute in multiple of 4 bytes), and given the length of the > ECDHE public key in the attribute value (currently 32 or 33 bytes), you > probably should mention something about padding. I expect something analogous > to what RFC4187 defines for AT_IDENTITY "Because the length of the attribute > must be a multiple of 4 bytes, the sender pads the identity with zero bytes > when necessary."
Yes, of course. Thanks! > Section 8: IANA Considerations. The section doesn't spell out the fields of > the > "EAP-AKA' AT_KDF_FS Key Derivation Function Values" registry (Value, > Description, Reference), although those are pretty obvious from the table > itself. What I think is really missing is the expert guidelines - as RFC8126 > specifies, the policy "Specification required" still requires review and > approval by a designated expert. "As with Expert Review, clear guidance to the > designated expert should be provided when defining the registry". What > criteria > is the expert supposed to base their decision on when deciding if a new value > should be registered? We’re not sure there’s any specific guidance that we can give, beyond the generic ones about ensuring the specification is of suitable stable type and that making the allocation is a reasonable thing for what is being defined. Do you have other suggested guidance? Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
