Hello Mališa, > Thank you for summarizing the discussion we had and proposing these changes. > I have modified the text in order to reflect the email below by:
I'm not sure I understand the distinction between "unsupported" and "unexpected" parameters. Are they about having an unknown code vs. having an unknown value? If so, the unexpected additional info should include the full value in the diagnostic, and not only the label. I don't quite see how the arrays come in here, especially given that I didn't find the Diagnostic CDDL used anywhere in the updated document (JoinRequest still only has Error). Is the intention here that there is only one Diagnostic, with only one code and a list of values? With that a pledge could say that it won't understand options X and Y, but it can't say that it won't understand option X and can't use the link-layer key Y. (On an editorial note, the "Additional info type" could go away in #table_diagnostic_codes, but given the above I think they should rathe stay uint / uint (key_id) / Configuration, and have at some point a `? 8: [ +Diagnostic ]` or so). > - renaming of Error object to Diagnostic, if you have a better naming > proposal, please let me know I'd call it UnsupportedConfigurations, but that's really a matter of overall document terminology which I'm unfamiliar with. Kind regards Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
