IETF Logo Mail Archive

Re: [trill] Review of draft-ietf-trill-oam-framework-01.txt

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Thu, 04 April 2013 09:46 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2A121F9644 for <trill@ietfa.amsl.com>; Thu, 4 Apr 2013 02:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.453
X-Spam-Level:
X-Spam-Status: No, score=-103.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 bSX6wkDeoqpJ for <trill@ietfa.amsl.com>; Thu, 4 Apr 2013 02:46:48 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8318521F9643 for <trill@ietf.org>; Thu, 4 Apr 2013 02:46:48 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAHpXMFGHCzI1/2dsb2JhbABEgma/Tn8Wc4IfAQEBAQIBEig/DAQCAQgNAQMEAQELFAkHMhQJCAIEAQ0FCBqHawYBpGGcQ45jJgsHBoJZYQOcWopRgwiCJw
X-IronPort-AV: E=Sophos;i="4.84,760,1355115600"; d="scan'208";a="5530894"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Apr 2013 05:46:47 -0400
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Apr 2013 05:44:21 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0328.009; Thu, 4 Apr 2013 05:46:46 -0400
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Donald Eastlake <d3e3e3@gmail.com>, gayle noble <windy_1@skyhighway.com>
Thread-Topic: [trill] Review of draft-ietf-trill-oam-framework-01.txt
Thread-Index: AQHOMK8ru+5fmdrbvUO6aG0U+pbvy5jFz7Sw
Date: Thu, 04 Apr 2013 09:46:45 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C16F6@AZ-FFEXMB04.global.avaya.com>
References: <CAF4+nEEWsA6Lt6f3dTMG7RJDVa0Q+p3MWySUAgnLjWMZU9QX-g@mail.gmail.com> <CAF4+nEG3H-UoaF=atise2E0dFDBEnkjNXauZ3sXC1_=tsCd0_g@mail.gmail.com> <201304010513.r315DbDx076312@skyhighway.com> <CAF4+nEFf27q0D3W+rf+yN46NV8YaZ2aWji3jjRDng_TexmzDSQ@mail.gmail.com>
In-Reply-To: <CAF4+nEFf27q0D3W+rf+yN46NV8YaZ2aWji3jjRDng_TexmzDSQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Review of draft-ietf-trill-oam-framework-01.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 09:46:49 -0000

> -----Original Message-----
> From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf
> Of Donald Eastlake
> Sent: Thursday, April 04, 2013 12:06 AM
> To: gayle noble
> Cc: trill@ietf.org
> Subject: Re: [trill] Review of draft-ietf-trill-oam-framework-01.txt

> 
> > Perhaps even add in that if the OAM message fails authentication, the
> > switch should log the attempt and notify the sys admin. Or maybe that
> is obvious?
> 
> I don't think the IETF is complete consistent on this point but
> generally IETF specifications concentrate on the bits on the wire and
> the state machines at the end points so they frequently omit saying
> anything explicit about logging...
> 

[[DR]] As Donald says (politely) the IETF is not completely consistent on this point. My preference is for an Operational and Manageability Considerations section (as recommended by RFC 5706) which would among other list the recommended tools to be  implemented in the routers or hosts for administration purposes. Logging security incidents would be such a function. See also my review of the same document, a few more items may be included in such a section. There is no need to define all the details here, but to list the issues to the attention of implementers and operators, and as subject for future work. 

Regards,

Dan

v2.23.0 | Report a Bug | By Email