ietf
[Top] [All Lists]

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

2013-03-28 10:10:52
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:Ted(_dot_)Lemon(_at_)nominum(_dot_)com] 
Sent: Wednesday, March 27, 2013 10:57 PM
To: Joel Halpern Direct
Cc: Black, David; Joel M. Halpern; McPherson, Danny; 
savi(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
gen-art(_at_)ietf(_dot_)org; 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 
<jmh(_dot_)direct(_at_)joelhalpern(_dot_)com> 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.