[Teas] Roman Danyliw's No Objection on draft-ietf-teas-gmpls-signaling-smp-11: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-teas-gmpls-signaling-smp-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-signaling-smp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to David Mandelberg for the SECDIR review.

** Section 6.3

   In order to indicate the SMP preemption priority, the 16-bit Reserved
   field [RFC4873] of the PROTECTION object is redefined.  The last 32
   bits in the PROTECTION object defined in [RFC4873] are updated as
   follows:

I had trouble following the references in the above text to understand what
exactly was being updated.  John Scudder help me understand the follow:

RFC 4872 reserved a 32-bit field in the PROTECTION object header. Subsequently,
RFC 4873 allocated several fields from that field, and left the remainder of
the bits reserved. This specification further allocates the preemption priority
field from those formerly-reserved bits.

I’d recommend included text to this effect.

** Concur with Paul and Francesca that a registry for LSP (Protection Type)
Flag would be helpful.

** Section 8.

For this reason, it is important not only to use security
   mechanisms as discussed in [RFC4872] but also to preserve privacy of
   information about protecting LSPs within the network.

How would one "preserve the privacy of information about protecting LSPs"?  Is
this equivalent to acknowledging that detailed knowledge of a network's
topology can help an attacker better target or improve the efficacy of an
attack?