[OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-encapsulation-cap-06: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-ospf-encapsulation-cap-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think there's a normative conflict in these two pieces of text; the first one
from Section 3, and the second from Section 5:

   ...If the Encapsulation Capability
   TLV appears more than once in an OSPF Router Information LSA, only
   the first occurrence MUST be processed and others MUST be ignored.

...

   Any unknown Sub-TLVs MUST be ignored and skipped upon receipt.

   If a Sub-TLV is invalid, its Tunnel Encapsulation TLV MUST be ignored
   and skipped.  However, other Tunnel Encapsulation TLVs MUST be
   considered.

The text from Section 3 says that only the first TLV [*] is to be processed --
but during such processing the receiver may find an invalid sub-TLV, which then
mandates (in Section 5) for other TLVs to be considered.

I think that the easy solution is to change the second "MUST" from Section 3
for a "SHOULD".

It would be nice to describe what is an "invalid" sub-TLV, and that "invalid"
is not the same as "unknown" (right?)...but that an "unknown [tunnel] types are
to be ignored and skipped upon receipt", which would result in processing the
second (if any) TLV.

[*] Benoit's ballot pointed at the need for consistency in the names.