§4 The presence of a TLV (or sub-TLV) with content which does not conform to the relevant specification MUST NOT cause the LSP itself to be rejected.
Again, thank you for your effort to clarify the specification. Given the "MUST", I feel that this sentence may be read as contradicting with some other text. E.g " An implementation that implements HMAC-MD5 authentication and receives HMAC-MD5 Authentication Information MUST discard the PDU if the Authentication Value is incorrect." https://tools.ietf.org/html/rfc5304#section-2 Do you think it could be slightly rephrased? May be something along :s/rejected/considered invalid [or incorrect, although 10589 seems to use the term "invalid PDU"] (as "rejected" could be read as similar to "discarded") Thanks, --Bruno From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com Sent: Friday, March 22, 2019 11:41 AM To: lsr@ietf.org; draft-ginsberg-lsr-isis-invalid-...@ietf.org Cc: Alvaro Retana Subject: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv Hi all, To be clear, I support that document. Thanks for writing it. I have some comments, mostly asking for even more of this/such document. (although I expect that some comments will trigger a discussion ;-) ) ---- §3.1 "Any codes in a received PDU that are not recognised shall be ignored." Therefore the presence of TLVs in a PDU which are not allowed MUST NOT cause the PDU itself to be rejected by the receiving IS. I don't think that "not recognized" is the same as "not allowed". IMHO, the fact that unknown TLV are to be ignored seem rather obvious as this is a designed goal of the TLV format. Yet, it's good that [ISO10589<https://tools.ietf.org/html/draft-ginsberg-lsr-isis-invalid-tlv-01#ref-ISO10589>] explicitly stated it. I definitely support that LSR defines the behavior for TLV (and sub-TLV) which are not allowed. But I find the justification and reference debatable. I'd rather prefer that we remove it, or at least remove the "Therefore". I'd favor something along OLD: Therefore NEW: In addition, this document specifies that ---- §3.3 Registries associated with sub-TLVs are associated with the TLV Codepoints Registry and specify in which TLVs a given sub-TLV is allowed. As with TLVs, it is required that sub- TLVs which are NOT allowed MUST be ignored on receipt. In addition to "not recognized" and "not allowed by the registry" I believe that there are others cases that would benefit from been clarified. Such as: - not allowed by the specification (in a given case/condition) - REQUIRED (MUST) but not present e.g. "it MUST include this sub-TLV on point-to-point adjacencies" https://tools.ietf.org/html/rfc5305#section-3.3 - Malformed (bad syntax) - Correctly formed but illegal value (in a given case/condition) I would like LSR to specify all types of error handling. Either in this document, or in another document if general error handling is considered out of scope of this document. --- §1 " PDUs which are valid MUST be accepted even if an individual TLV contained within that PDU is invalid in some way." I wish "valid" be further defined. E.g. do you mean from a syntax/parsing point of view? Or do you mean something else? In particular [ISO10589<https://tools.ietf.org/html/draft-ginsberg-lsr-isis-invalid-tlv-01#ref-ISO10589>] use the terms "invalid PDU syntax". If you mean the same, I'd favor using the same terms. If you mean something different, please clarify the differences. --- " Nevertheless, a certain degree of "common knowledge" is assumed on the part of implementors in regards to these behaviors." What do you mean by that? That some "common knowledge" are required for the protocol to (correctly) work but that this knowledge is not written in a specification? If so, I believe LSR should write down such behavior. " This document serves to make explicit what is expected. While it does not alter any existing protocol behavior or specifications, it is intended to close any gaps between what is explicitly stated and what has been "commonly understood"." Same comment. A behavior is either specified or not specified. I don't understand the meaning of the term "commonly understood". Thank you, Regards, --Bruno PS: To clarify, I'm copying Alvaro as an individual contributor, as he expressed interest in error handling in BGP-LS which for some code points may be related to error handing in IS-IS. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
