[Gen-art] Gen-ART and OPS-Dir review of draft-ietf-ospf-node-admin-tag-06: A-D issues

["Black, David" <[e-mail]>]

David> Inline.  I'll deal with the A-D issues here and the editorial
David> items/nits in a separate message.

> David,
> 
> Thanks a lot for your detailed review and comments.
> 
 
[... snip ...]

> --- Minor issues: ----
> 
> -- 3.2 Elements of procedure:
> 
> [A] I see what look like some underspecified requirements:
> 
>    Each tag SHOULD be treated as an independent identifier that MAY be
>    used in policy to perform a policy action.
> 
>    The administrative tag list within the
>    TLV SHOULD be considered an unordered list.
> 
> Why are those two not "MUST" requirements?  What happens if either is not
> done?
> 
> <Shraddha> It's perfectly valid for the receiver of the node admin tag to
> ignore a certain tag or set of tags if there are no local policies.
> I think MUST will be too restrictive statement.

David> Please add that statement, specifically that a receiver may have to
David> ignore tags that do not match any local policies.  That still doesn't
David> explain why "MUST" is inappropriate in either case.

David> For the first requirement, I was expecting
David> the "MUST" to apply only to "independent identifier," i.e.:

    Each tag MUST be treated as an independent identifier that MAY be
    used in policy to perform a policy action.

David> The "SHOULD" in the second requirement appears to be asking for
David> interoperability problems if it's ignored.  I think that ought to be: 

    The administrative tag list within the
    TLV MUST be considered an unordered list.

> ------------------------------------------------------------------------------
> --------------------------------------------
> 
> [B] Tag set completeness:
> 
>    Multiple node administrative tag TLVs MAY appear in an RI LSA or
>    multiple node administrative tag TLVs MAY be contained in different
>    instances of the RI LSA.  The node administrative tags associated
>    with a node for the purpose of any computation or processing SHOULD
>    be a superset of node administrative tags from all the TLVs in all
>    instances of the RI LSA originated by that node.
> 
> This paragraph is about processing at that node.  It's easy to misread, as
> that implication
> 
> is buried in the word "originated" in the last line.
> Suggested change:
> 
> 	"for the purpose of any computation or processing SHOULD" ->
> 	"for the purpose of any computation or processing performed
> 		at that node SHOULD"
> 
> Also, it looks like it's acceptable for other nodes to perform such computation or
> processing based on a partial tag set for this node (e.g., when some other node has not
> received all the RI LSAs with all the tags).  That should be stated.
> 
> <Shraddha> This is talking about processing at the receiver. Will update as below.
> 
> 
>    Multiple node administrative tag TLVs MAY appear in an RI LSA or
>    multiple node administrative tag TLVs MAY be contained in different
>    instances of the RI LSA.  The node administrative tags associated
>    with a node for the purpose of any computation or processing at the receiver SHOULD
>    be a superset of node administrative tags from all the TLVs in all
>    instances of the RI LSA originated by that node. Receiver MAY perform the processing on
>    administrative node tags when only a partial set is receieved but the receiver
>    node MUST repeat the computation or processing when the complete set of node
>    administrative tags for that node is received.

David> That's much clearer.  Some minor editorial suggestions:

	- "associated with a node" -> "associated with a node that originates tags"
	- "processing at the receiver" -> "processing at a receiving node"
	- "instances of the RI LSA" -> "received RI LSA instances"

David> The last sentence appears to still have a problem:  How does a receiving
David> node determine when it has a complete set of tags?  Suggested rephrase:

	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.

David> I think that captures the underlying point that processing MUST always
David> be based on current tag information.

> ------------------------------------------------------------------------------
> ---------------------------------------------------
> [C] Tag change/removal:
> 
>    When there is a change in the node administrative tag TLV or removal/
>    addition of a TLV in any instance of the RI-LSA, implementations MUST
>    take appropriate measures to update its state according to the
>    changed set of tags.  Exact actions depend on features working with
>    administrative tags and is outside of scope of this specification.
> 
> Inability to interoperably remove a tag value (e.g., distribute the update that tag X no
> longer applies to node Q) seems like a significant omission, but I'm not a routing expert,
> so I'll defer to the WG's and ADs' judgment on the importance of this.  At a minimum, the
> rationale for not specifying an interoperable tag value removal mechanism ought to be added
> to this document.
> 
> <Shraddha> Added the tag updations at the origination.
> 
> When there is a change or removal of an adminstrative affiliation of a node,
> the node MUST
> 
> re-originate the RI LSA with the latest set of node administrative tags.
> On the receiver, When there is a change in the node administrative tag TLV or
> removal/
>    addition of a TLV in any instance of the RI-LSA, implementations MUST
>    take appropriate measures to update its state according to the
>    changed set of tags.  Exact actions depend on features working with
>    administrative tags and is outside of scope of this specification.

David> I don't understand how a receiving node can be certain that a tag has
David> been removed based on this sentence in Section 2:

   Multiple TLVs MAY be added in same RI-LSA or in a different instance
   of the RI LSA as defined in [I-D.acee-ospf-rfc4970bis].

David> How does a receiving node determine that it has seen all the relevant
David> RI LSAs and hence that absence of a previously seen tag renders that
David> tag no longer applicable?  The "seen all the relevant RI LSAs" portion
David> of this answer probably belongs in Section 2.

> ------------------------------------------------------------------------------
> -----------------------------------------------------------
> 
> [D] No management support
> 
> From OPS-Dir Q&A: At a minimum, reporting of tag values ought to be defined
> via an OSPF MIB extension or analogous functionality.
> 
> <shraddha> I think this should be taken separately as part of OSPF MIB RFC
> update, which will combine multiple features which require new definitions.
> 
> Acee, How do we go about this?

David> At the very least, the draft that updates that MIB should be referenced.

[... Nits/editorial comments snipped - will send separate email ...]

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------