Advertising Node Administrative Tags in OSPF
draft-ietf-ospf-node-admin-tag-09

I am clearing my DISCUSS because we seem to be going around in circles in my exchanges with the authors.

I still have some concerns about the normative language in section 3.2 (some of it has been updated as a result of our discussions) — I think that some of the text is not in line with what seems to be the intent of the extension: "…allows simplification, ease of management and control over…policies. …node-tags can be used to express and apply locally-defined network policies."

Specifically, I have strong concerns about the ability (or not, as defined in the text) to flood the same tag value with different scopes, and about potential instability caused by sources other than topology changes.

To all this, I trust the responsible AD and hope that the WG had the appropriate discussions, so I'm changing my ballot and not standing in the way.

The abstract reads a bit oddly, repeating "This document describes an extension to OSPF protocol".  Perhaps while you're making changes to address the other IESG comments, you could re-word the abstract to avoid that repetition.

The shepherd write up says that there have been no IPR disclosures, but there has in fact been a disclosure on an earlier version. Wast he working group aware of this disclosure?

3.2, paragraph 4: "Each tag MUST be treated as an independent identifier that MAY be
used in policy to perform a policy action."

Given the context of the previous MUST, the MAY seems more descriptive than  normative.

- "Tags carried by the
   administrative tag TLV SHOULD be used to indicate independent
   characteristics of a node."

I was initially confused by that sentence.
So there are tags carried by a different TLV than the administrative one? Actually, no (I checked with one of the authors).
I would simply write:
   "Administrative tag TLV SHOULD be used to indicate independent
   characteristics of a node."

This would be in line with the definition:
   An administrative Tag is a 32-bit integer value that can be used to
   identify a group of nodes in the OSPF domain.

- Router information LSA [RFC4970] can have link, area or AS
   level flooding scope.  Choosing the flooding scope to flood the group
   tags are defined by the policies and is a local matter.

"and is a local matter". Hopefully there is some sort of centralized management application that checks consistency.

I support Alvaro's DISCUSS position.  I also wonder why we are turning OSPF into a generic container protocol.  That approach has caused issues with BGP and I don't see it being any better doing it in OSPF.

David Black did the opsdir / genart review

updates were applied to the reviewed version

Thanks for your responsive and helpful feedback to the SecDir review.  The suggested and agreed changes look good and I'll continue to watch the thread as the discussion seems to be going very well and is managed very well on both ends.

Thank you!
https://mailarchive.ietf.org/arch/msg/secdir/FT81G3Iml0J1alWq5wdVaBYXiao

I share Alvero's Discuss about whether these tags are opaque.

- I think Alavaro and Brian make some good points. I'll be
interested in how that discussion turns out.

- Good to see that you recognise that even opaque tag values
can expose sensitive information (the attacker isn't limited
in how they are allowed interpret what they see). However,
given that we recognise that confidentiality ought be provided
sometimes, isn't there an onus on us to actually provide some
usable way to get that service? If so, then who is looking at
that problem? If not, then why is that acceptable? (This isn't
a discuss as I don't think there is any PII or similar
information being transferred, and the confidentiality
requirement here really relates to network topology etc. But
please do correct me if one of these tags could be PII-like
and I'll make this a discuss if that's better.)