I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review HAS ISSUES (might be minor) The security considerations section only lists those considerations of other documents it references. While that likely covers most issues, I'm not sure it covers all issues. The introduction of this document tells us the goal of this new "Generalized SCSI" value only in a somewhat vague way: [...] can be used with routing protocols that define GMPLS ISCDs, and any specific technology. Since it does not explain _how_ it can be used, it is a bit difficult to figure out what the security impact of this new field could be when it is abused. What happens when this new field contains wrong or malicious information? And when I read: SCSI-TLVs MUST be processed in the order received and, if re-originated, ordering MUST be preserved. What happens if someone maliciously re-orders these? Unknown SCSI-TLVs MUST be ignored What happens when someone mangles a valid SCSI-TLV value so it becomes ignored? Another issue that could use clarification is the padding. It is only said "may contain padding", but it is not specified how to pad. Prefix with leading zeros? Append with FFs? NITS: "[RFC7138] introduced a " This reference is broken In diagrams we tend to use "~" and not "..." to indicate variable length I tend to use +--------+------+ rather then +-+-+-+-+-+-+ I would not explain "octets (bytes)". IETF tends to use octets as term. "The value of the field MUST" -> "The value MUST" corollary - A word harder for non-native english speakers "MAY contain a sequence of zero or more SCSI- TLVs." MAY and "zero or more" is a little odd.