[OSPF] Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

["Alvaro Retana" <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-ospf-node-admin-tag-07: Discuss

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-node-admin-tag/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 3.2. (Elements of procedure) says that the "interpretation of tag
values is specific to the administrative domain of a particular network
operator", which makes them opaque and obviously locally significant.  I
then have an issue with the following text, which tries to (using rfc2119
keywords) specify how to interpret the tags, which doesn't make sense to
me given the text above:

   Each tag MUST be treated as an independent identifier that MAY be
   used in policy to perform a policy action.  Tags carried by the
   administrative tag TLV SHOULD be used to indicate independent
   characteristics of a node.  The administrative tag list within the
   TLV MUST be considered an unordered list.  Whilst policies may be
   implemented based on the presence of multiple tags (e.g., if tag A
   AND tag B are present), they MUST NOT be reliant upon the order of
   the tags (i.e., all policies should be considered commutative
   operations, such that tag A preceding or following tag B does not
   change their outcome).

   To avoid incomplete or inconsistent interpretations of the per-node
   administrative tags the same tag value MUST NOT be advertised by a
   router in RI LSAs of different scopes.  The same tag MAY be
   advertised in multiple RI LSAs of the same scope, for example, OSPF
   Area Border Router (ABR) may advertise the same tag in area-scope RI
   LSAs in multiple areas connected to the ABR.
. . .
   Being part of the RI LSA, the per-node administrative tag TLV must be
   reasonably small and stable.  In particular, but not limited to,
   implementations supporting the per-node administrative tags MUST NOT
   tie advertised tags to changes in the network topology (both within
   and outside the OSPF domain) or reachability of routes.
. . .
   instances of the RI LSA.  The node administrative tags associated
   with a node that originates tags for the purpose of any computation
   or processing at a receiving node SHOULD be a superset of node
   administrative tags from all the TLVs in all the received RI LSA
   instances originated by that node.When an RI LSA is received that
   changes the set of tags applicable to any originating node, a
   receiving node MUST repeat any computation or processing that is
   based on those administrative tags.

If the tags are opaque, I don't think that anything can be mandated as to
how they are interpreted or what they're used for.  That is the point I
want to talk about with this DISCUSS.


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

Related to the DISCUSS:  Section 3.2 says that the "meaning of the Node
administrative tags is generally opaque to OSPF", are there cases where
the meaning is not opaque?  Even if the application is well known there
is no indication that the tag is not opaque.  Yes, this is a nit with the
word "generally".

All the references related to rfc4970 should be changed to
draft-ietf-ospf-rfc4970bis.