Extensions to OSPF for Advertising Prefix Administrative Tags
draft-ietf-lsr-ospf-admin-tags-29

Mostly nits: 

Section 1:  Spell out AS, LSA on first use.  Consider an acronym list.
Section 4, para 2:   'speficified' should be 'specified'. 
Section 8, para 1:  '(subtle denial or service)' should be '(subtle denial of service)'

Thanks for addressing my DISCUSS and COMMENTs.

(resending ballot as I didn't select "No Objection" on the position)

Thank you to Robert Sparks for the GENART review.

** Consider if it would make the document more readable to name the registry group since there are three OSPF Parameter registry groups.  For example:

OLD
   The following values should be allocated from the "OSPF Extended
   Prefix TLV Sub-TLV" Registry [RFC7684]:

NEW
The following values should be allocated from the "OSPF Extended Prefix TLV Sub-TLV" Registry [RFC7684] in the "Open Shortest Path First v2 (OSPFv2) Parameters" group.

OLD
   The following values should be allocated from the "OSPFv3 Extended-
   LSA Sub-TLV" Registry [RFC8362]:
NEW
The following values should be allocated from the "OSPFv3 Extended-LSA Sub-TLV" Registry [RFC8362] in the "Open Shortest Path First v2 (OSPFv2) Parameters" group:

OLD
   The following values should be allocated from the "OSPFv3 SRv6
   Locator LSA Sub-TLVs" Registry [RFC9513]:
NEW
The following values should be allocated from the "OSPFv3 SRv6 Locator LSA Sub-TLVs" Registry [RFC9513] in the "Open Shortest Path First v2 (OSPFv2) Parameters" group:

Thanks for this document. I have just a few questions and comments, below.

- In Section 4, "An OSPF router supporting this specification MAY be able to advertise and propagate multiple tags." Does "propagate" have some well-known meaning in OSPF that is different from "flood"? Because I assume that any OSPF router MUST flood (propagate!) whatever it's given. (I do see paragraph 4, which hints that the answer is "yes in OSPF 'propagate' always means 'between areas'" but I'd appreciate a confirmation.)

- In Section 4, "Depending on the application, the number of tags supported by the OSPF routers in the OSPF routing domain MAY limit deployment of that application." That seems like a misuse of RFC 2119 MAY -- aren't you just stating a possibility, not giving permission for an implementation choice?

- In Section 4, "When tags are advertised for AS External or NSSA LSA prefixes, the existing tag in the OSPFv2 and OSPFv3 AS-External-LSA and NSSA-LSA encodings MUST be utilized for the first tag." I almost never do this, but... couldn't this be a SHOULD? The case I can think of where you might want to use the Administrative Tag Sub-TLV even as the first tag, is in some future time when Administrative Tag Sub-TLV is ubiquitous and you are looking toward deprecating the old encoding. I suppose a new RFC could be written at that time, to permit the variance, but why not just allow it here with a SHOULD?

## Nits

### Contact IESG?

```
766	   URI: urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags
767	   Registrant Contact: The IESG.
768	   XML: N/A, the requested URI is an XML namespace
```

Is this one of the registries that requires the IESG to be the contact point?

It would be nice to specify a better point of contact where possible, see:

https://www.rfc-editor.org/rfc/rfc6087#section-5

Thanks for working on this specification. Please address Orie's comment on IESG as contact in the IANA section.