Re: [trill] Ben Campbell's No Objection on draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)

[Mingui Zhang <[e-mail]>]

Hi Ben,

I will upload a new version to address the comments we've received recently. 
The statement you suggested will be added. The terms will be updated to remove the confusion. Thanks!

Mingui


> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Tuesday, September 22, 2015 12:46 AM
> To: Mingui Zhang
> Cc: The IESG; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: Ben Campbell's No Objection on
> draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)
> 
> 
> 
> On 16 Sep 2015, at 2:10, Mingui Zhang wrote:
> 
> > Hi Ben,
> >
> > Thanks for the comments. Please refer to the in-line responses.
> >
> >> -----Original Message-----
> >> From: Ben Campbell [mailto:[e-mail]]
> >> Sent: Wednesday, September 16, 2015 3:31 AM
> >> To: The IESG
> >> Cc: [e-mail];
> >> [e-mail]; [e-mail];
> >> [e-mail]; [e-mail];
> >> [e-mail]
> >> Subject: Ben Campbell's No Objection on
> >> draft-ietf-trill-pseudonode-nickname-06: (with COMMENT)
> >>
> >> Ben Campbell has entered the following ballot position for
> >> draft-ietf-trill-pseudonode-nickname-06: No Objection
> >>
> >>
> >> Please refer to
> >> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> for more information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> https://datatracker.ietf.org/doc/draft-ietf-trill-pseudonode-nickname
> >> /
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> COMMENT:
> >> ---------------------------------------------------------------------
> >> -
> >>
> >> -- section 12, last paragraph:
> >>
> >> Elaboration on the details would be useful. This draft adds new
> >> procedures; what analysis was done to show those new procedures have
> >> no new security impact?
> >
> > This document relies on the security provided by IS-IS, TRILL ESADI
> > protocol and RFC 6325. The authentication mechanism has been used as a
> > counter measurement to bogus messages. With the use of the
> > authentication, there would be no security exposure. This still holds.
> 
> That statement implies that the new procedures in this draft do not add any
> new consideration beyond those already considered in those drafts.
> It would be helpful to say that explicitly.
> 
> >
> >>
> >> Editorial:
> >>
> >> -- 1.1, definition of AAE, "AAE is also referred to as edge group or
> >> Virtual RBridge in this document"
> >> Why use multiple terms for the same thing? This seems to create
> >> awkward wording in several places, where the text  repeats things
> >> like “In an AAE group (i.e. RBv)…”
> >>
> >
> > RBv is an handy conception to ease the understanding of the solution.
> > From the view of non AAE RBridges, the group of RBridges in the AAE
> > act just like a single RBridge.
> > However, it would be concise to remove the concurrent appearance.
> >
> 
> I personally found the use of two different terms a bit confusing. But that may
> just be me. I will not complain further if you keep it as is.
> 
> > Thanks,
> > Mingui