Re: [secdir] secdir review of draft-ietf-ospf-node-admin-tag-05

[Benjamin Kaduk <[e-mail]>]

On Wed, 14 Oct 2015, Shraddha Hegde wrote:

>
> I completely missed looking at editorial comments and the diff in
> previous mail. Sorry about that.
>
> Have taken your changes in the latest version and diff (-06 to -08)
> attached. Pls take a look.

The new version seems improved; I'll skip line-by-line discussion of the
grammar changes since the IESG teleconference call is fast approaching.

The diagram for the TLV format in Figure 1 still has a 15-bit type and
17-bit length; both should be 16 bits.

> Editorial comments:
>
> >
> > I also have some editorial comments unrelated to the secdir review:
> >
> > Section 3.2 reads rather like a jumbled list and could benefit from some
> > additional structure.
> <Shraddha.>Updated. Pls refer diff.
> >
> > Similarly, I would find it helpful if there was some text motivating the
> > "middle patch" mentioned above, towards the beginning of the technical
> > (non-example) portion of the document.
>
> <Shraddha> I could not get this comment. Could you pls elaborate?

This is related to Alvaro's DISCUSS.  Basically, there is conflict between
saying that the interpretation of tag values is entirely local, and
imposing restirctions on how the tags should be interpreted.  It is
helpful to the reader to discuss why the document does not pick one
extreme of completely-local interpretation and a fully specified protocol
that dictates the meaning of all tags.  Instead, the document picks
something in-between, with tag interpretation mostly a matter of local
policy, but some restrictions on their use.  Describing why this choice
was made early in the text gives the reader a better picture of what the
goals of the protocol are, to better understand the details of the
protocol itself.

> > For a construction as weakly structured as these administrative tags,
> > preventing any internal structure or dependencies between tags (as this
> > document attempts to do) seems correct.  However, this sentiment seems to
> > be expressed differently in several different places in the document, and
> > it would be good to consolidate and coordinate them.  In particular,
> > paragraph 3 of section 3.2 explicitly says that tag order has no meaning,
> > but paragraph 4 has the weaker "SHOULD be considered an unordered list".
> > (The word "set" might be appropriate here.)
>
> <shraddha>Below is the latest text. SHOULD is changed to MUST
>
> " Each tag MUST be treated as an independent
> identifier that MAY be used in policy to perform a policy
> action. Each tag carried by the administrative tag TLV SHOULD be used to
> indicate a characteristic of a node that is independent of the
> characteristics indicated by other administrative tags.
> 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)."

This seems okay in a quick read, but again, the resolution of Alvaro's
DISCUSS will be relevant to this text.

> > Paragraph 7 of section 3.2 seems to be trying to say that the
> > administrative tags must indicate inherent or administratively configured
> > properties of a node and must not be used to convey attributes of the
> > routing topology.  (The word "tie" seems insufficiently clear.)
>
> <Shraddha>Changed to text below.
>
> "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 per-node
> administrative tags MUST NOT be used to convey attributes of the
> routing topology or associate tags with
> changes in the network topology (both within and outside
> the OSPF domain) or reachability of routes."

That's an improvement, thanks.  ("but not limited to" is still bad
grammar, but the best fix is not immediately obvious.)

> > The last paragraph of section 3.2 could probably be written more clearly.
> > In particular, "in any instance of the RI-LSA" is not entirely clear to me
> > (but then again, I don't really understand how LSAs normally work).  Is it
> > enough to just say that implementations MUST detect when the
> > administrative tags associated with a given node change, and update their
> > state accordingly?
> >
> <Shraddha> hope this issue is resolved in other mail thread.

I think so, yes.

-Ben