Re: [secdir] Secdir review of draft-ietf-trill-multilevel-unique-nickname-05

[Roman Danyliw <[e-mail]>]

Hello Donald!

Thanks for making these changes in -07.

This addresses all of my feedback.

Roman

> -----Original Message-----
> From: Donald Eastlake [mailto:[e-mail]]
> Sent: Wednesday, March 14, 2018 9:31 PM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-trill-multilevel-unique-
> [e-mail]; Zhangmingui (Martin) <[e-mail]>
> Subject: Re: Secdir review of draft-ietf-trill-multilevel-unique-nickname-05
> 
> Hi Roman,
> 
> A -07 version of draft-ietf-trill-multilevel-unique-nickname has been uploaded.
> I believe this resolves all of your comments.
> 
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA  [e-mail]
> 
> 
> On Tue, Mar 6, 2018 at 10:15 PM, Zhangmingui (Martin)
> <[e-mail]> wrote:
> > Hi Roman,
> >
> > All changes you suggested in item (8) are fair. I've made these changes into
> the 07 version. Awaiting for uploading.
> >
> > Thanks,
> > Mingui
> >
> >> -----Original Message-----
> >> From: Roman Danyliw [mailto:[e-mail]]
> >> Sent: Wednesday, March 07, 2018 12:32 AM
> >> To: [e-mail]; [e-mail];
> >> [e-mail]
> >> Subject: RE: Secdir review of
> >> draft-ietf-trill-multilevel-unique-nickname-05
> >>
> >> Hi Donald and Mingui!
> >>
> >> Thanks for the changes in -06.  Any thoughts on item (8)?
> >>
> >> Roman
> >>
> >> > -----Original Message-----
> >> > From: Roman Danyliw
> >> > Sent: Friday, March 02, 2018 9:01 PM
> >> > To: [e-mail]; [e-mail];
> >> > draft-ietf-trill-multilevel-unique-
> >> > [e-mail]
> >> > Subject: Secdir review of
> >> > draft-ietf-trill-multilevel-unique-nickname-05
> >>
> >> [snip]
> >>
> >> > (8) There appear to be a few instances of key protocol behavior not
> >> > using
> >> > RFC2119 language.  I'd suggest:
> >> >
> >> > Section 3.2.2, Global Distribution Tree, Page 6
> >> > (old) Also, this border RBridge needs to advertise the set of local
> >> > distribution trees by providing another set of nicknames
> >> > (new) Also, this border RBridge MUST advertise the set of local
> >> > distribution trees by providing another set of nicknames
> >> >
> >> > Section 3.2.2, Global Distribution Tree, Page 6
> >> > (old) If a border RBridge has been assigned both as a global tree
> >> > root and a local tree root, it has to acquire both a global tree
> >> > root
> >> > nickname(s) and local tree root nickname(s)
> >> > (new) If a border RBridge has been assigned both as a global tree
> >> > root and a local tree root, it MUST acquire both a global tree root
> >> > nickname(s) and local tree root nickname(s)
> >> >
> >> > Section 4.3, Nickname Announcements, Page 9
> >> > (old) Besides its own nickname(s), a border RBridge needs to
> >> > announce, in its area, the ownership of all external nicknames that
> >> > are reachable from this border RBridge.
> >> > (new) Besides its own nickname(s), a border RBridge MUST announce,
> >> > in its area, the ownership of all external nicknames that are
> >> > reachable from this border RBridge.
> >> >
> >> > Section 4.3, Nickname Announcements, Page 9
> >> > (old) Also, a border RBridge needs to announce, in Level 2, the
> >> > ownership of all nicknames within its area. From listening to these
> >> > Level 2 announcements, border RBridges can figure out the nicknames
> >> > used
> >> by other areas.
> >> > (new) Also, a border RBridge MUST announce, in Level 2, the
> >> > ownership of all nicknames within its area. From listening to these
> >> > Level 2 announcements, border RBridges can figure out the nicknames
> >> > used by other
> >> areas.
> >> >
> >> > Section 4.3, Nickname Announcements, Page 9
> >> > (old) To address this issue, border RBridges should make use of the
> >> > NickBlockFlags APPsub-TLV to advertise into the Level 1 area the
> >> > inclusive range of nicknames that are available or not for self
> >> > allocation by the Level 1 RBridges in that area.
> >> > (new) To address this issue, border RBridges SHOULD use the
> >> > NickBlockFlags APPsub-TLV to advertise into the Level 1 area the
> >> > inclusive range of nicknames that are available or not for self
> >> > allocation by the Level 1 RBridges in that area.
> >> >
> >> > Section 4.4, Capability Indication, Page 11
> >> > (old) If there are RBridges that do not understand the
> >> > NickBlockFlags APPsub-TLV, border RBridges of the area will also
> >> > use the traditional Nickname Sub-TLV [RFC7176] to announce into the
> >> > area those nicknames covered by the nickname blocks of the
> >> > NickBlockFlags APPsub-TLV whose OK is 0.
> >> > (new) If there are RBridges that do not understand the
> >> > NickBlockFlags APPsub-TLV, border RBridges of the area MUST also
> >> > use the traditional Nickname Sub-TLV [RFC7176] to announce into the
> >> > area those nicknames covered by the nickname blocks of the
> >> > NickBlockFlags APPsub-TLV whose OK is 0.
> >> >
> >> > Section 5, Mix with Aggregated nickname Areas, Page 11
> >> > (old) Usage of nickname space must be planed so that nicknames used
> >> > in any one unique nickname area and Level 2 are never used in any
> >> > other areas which includes unique nickname areas as well as
> >> > aggregated nickname
> >> areas