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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 29 March 2013 22:08 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: savi@ietfa.amsl.com
Delivered-To: savi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA5B21F901A; Fri, 29 Mar 2013 15:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1sQQJw-ySQz; Fri, 29 Mar 2013 15:08:01 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 070B521F901F; Fri, 29 Mar 2013 15:07:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DBB4F1CCC9C; Fri, 29 Mar 2013 15:07:57 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [10.10.10.104] (pool-70-106-135-52.clppva.east.verizon.net [70.106.135.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5761C1C9E48; Fri, 29 Mar 2013 15:07:56 -0700 (PDT)
Message-ID: <515610B0.2050204@joelhalpern.com>
Date: Fri, 29 Mar 2013 18:07:44 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> <51531EA4.4030504@joelhalpern.com> <8D3D17ACE214DC429325B2B98F3AE71293D366C6@MX15A.corp.emc.com> <5153222E.30202@joelhalpern.com> <8D23D4052ABE7A4490E77B1A012B6307751243D6@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751243D6@mbx-01.win.nominum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "McPherson, Danny" <dmcpherson@verisign.com>, "savi@ietf.org" <savi@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, Jean-Michel Combes <jeanmichel.combes@gmail.com>, "joel.halpern@ericsson.com" <joel.halpern@ericsson.com>, "Black, David" <david.black@emc.com>
Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2013 22:08:02 -0000

I have a draft version with this correction.
David, would adding:
           When such a move
           is done without changing the MAC address, the SAVI switches
           will need to update their state.  While the ARP may be
           helpful,
           traffic detection, switch based neighbor solicitation,
           interaction with orchestration system, or other means may be
           used.
to the end of 5.2.3 address your concern?  I am not sure whether I have 
the right end of the question here, given that SAVI can not create new 
protocol.

Yours,
Joel

On 3/27/2013 10:56 PM, Ted Lemon wrote:
> On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct <jmh.direct@joelhalpern.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.
>
>