Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06

[Joel Halpern <[e-mail]>]

I will try to come up with a way to address the MAC move topic.  The challenge is to word it in such a way that it does not imply a new protocol for communicating such a move (Savi was/is prohibited by charter from doing protocol development.)
Yours,
Joel

> -----Original Message-----
> From: Ted Lemon [mailto:[e-mail]] 
> Sent: Wednesday, March 27, 2013 10:57 PM
> To: Joel Halpern Direct
> Cc: Black, David; Joel M. Halpern; McPherson, Danny; 
> [e-mail]; [e-mail]; [e-mail]; Jean-Michel 
> Combes; Joel Halpern
> Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06
> 
> On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct 
> <[e-mail]> wrote:
> 
> > Then it will be done.  I will wait for the AD to decide 
> what other changes are needed, and then will either make this 
> change or include it in an RFC Editor note.
> 
> > Old:
> >   If the bridging topologies which connects the switches changes, or
> >   if LACP [IEEE802.3ad] changes which links are used to deliver
> >   traffic, the switch may need to move the SAVI state to a different
> >   port, are the state may need to be moved or reestablished on a
> >   different switch.
> > New:
> >   If the bridging topologies which connects the switches changes, or
> >   if LACP [IEEE802.3ad], VRRP, or other link management
> >   operations, change which links are used to deliver
> >   traffic, the switch may need to move the SAVI state to a different
> >   port, are the state may need to be moved or reestablished on a
> >   different switch.
> 
> I think you probably meant "or", not "are", in the second 
> word of the second-to-last line of the new text.
> 
> As far as I am concerned, given that David is happy with your 
> recent change, I'm happy with it too.   However, since you 
> are asking, if you were willing to also accommodate David's 
> other request (see below) by adding some text to the document 
> in section 5, that would be an added bonus:
> 
> > A paragraph has been added to 5.2.3 to address all three of 
> the above concerns.   I guess that's ok, but I would have 
> liked to see some text pointing out that a MAC move can be 
> detected by the switches and used to update SAVI state about 
> which port(s) a MAC is accessed through.
> 
> So if you can do this, it would be much appreciated; if you 
> can't do it, I think the document is valuable enough to move 
> forward without this additional work.
> 
>