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

[Shraddha Hegde <[e-mail]>]

Ben,

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

<Shraddha> done

> > 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.


<Shraddha> Although , the actual values of node admin tags do not need to be standardized and is left to the operator's discretion to allocate values and assign meanings to it, It's necessary to layout certain rules/regulations and guidelines on how the tags can be used and how
they cannot be used. That will help in getting interoperable implementations from vendors and avoid surprises in the field.
For ex:  We have a statement administrative tag order has no meaning. If this document does not specify such a statement, there is every possibility some implementation will have policies that will look at the order in which the tags are encoded. Some other implementation which does not care about the order of the tag might keep changing it at every LSA refresh so it's hard to get them to interoperate.

Added below text in section 3.2.1
" This section describes general rules/ regulations 
and guidelines for using and interpreting an administrative tag which will
 facilitate interoperable implementations by vendors."

Rgds
Shraddha

-----Original Message-----
From: Benjamin Kaduk [mailto:[e-mail]] 
Sent: Thursday, October 15, 2015 6:26 AM
To: Shraddha Hegde <[e-mail]>
Cc: Acee Lindem (acee) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: RE: secdir review of draft-ietf-ospf-node-admin-tag-05

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.

<Shraddha> done

> 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.


<Shraddha> Although , the actual values of node admin tags do not need to be standardized and is left to the operator's discretion to allocate values and assign meanings to it, It's necessary to layout certain rules/regulations and guidelines on how the tags can be used and how
they cannot be used. That will help in getting interoperable implementations from vendors and avoid surprises in the field.

Added below text in section 3.2.1
" This section describes general rules/ regulations 
and guidelines for using and interpreting an administrative tag which will
 facilitate interoperable implementations by vendors."

> > 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