[sidr] New version draft-ietf-sidr-bgpsec-protocol

Matthew Lepinski <mlepinski.ietf@gmail.com> Fri, 04 July 2014 22:16 UTC

Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC291A005F for <sidr@ietfa.amsl.com>; Fri, 4 Jul 2014 15:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMsllxMZzCLD for <sidr@ietfa.amsl.com>; Fri, 4 Jul 2014 15:16:19 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FC91A003B for <sidr@ietf.org>; Fri, 4 Jul 2014 15:16:19 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id r20so4442052wiv.10 for <sidr@ietf.org>; Fri, 04 Jul 2014 15:16:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yY0mvgDkfK3MGlYXExp56ot+FGBtqlC8cM4FPqwXgsY=; b=Yr0sK0lOdV8tkP5t/cG4HMkzKnED/BpDlSnWYukP03YTEchSp7AijtnfRi609CgMGX 5DhswlechJbB49BjkLdE4zBpvlKVNyAEX/OTqwN8DpJmMwfEqiE08UEVJ1r9hYH4X9uf 1gJaqqRB7QXmmJcGG0f6L8uwXSos14KaI18dawlZCrn0yFQw+w7KZhqn1WwVYWi3WS+5 45NKm4IhxZq2qjDCDx6PxkYqIoTMAjtAIhLrjkfaezyyFeUb59ixqiuxIUK//NdOiXl0 UXLCIhaZcSykPlnBpctNp612xvSJcXUS5Rxm9oIY+50gkpUj5Fdi18JNk9bmvxdsbYQ4 y98g==
MIME-Version: 1.0
X-Received: by 10.195.13.79 with SMTP id ew15mr14192660wjd.19.1404512178011; Fri, 04 Jul 2014 15:16:18 -0700 (PDT)
Received: by 10.216.170.137 with HTTP; Fri, 4 Jul 2014 15:16:17 -0700 (PDT)
Date: Fri, 04 Jul 2014 18:16:17 -0400
Message-ID: <CANTg3aC2z=YiTbMMr3XXQZjfjiQM0=55Odt_8Ci9OT=7RpB-pQ@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: "sidr@ietf.org" <sidr@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bfd093a74042104fd657907"
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/wznSILixMDQiCX4w0gzVtcUl3Jk
Subject: [sidr] New version draft-ietf-sidr-bgpsec-protocol
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jul 2014 22:16:21 -0000

I submitted a new version of the bgpsec protocol document. This revision
includes a fair number of editorial changes but does not include any
normative changes.

Now that the BGPSEC requirements document is essentially done, I look
forward to discussing the protocol document again in Toronto. In
particular, between now and the Toronto meeting I will write up (and send
to the list) a brief comparison between the requirements in the final
version of the reqs draft and what we deliver in the protocol document.

The only open issue in the protocol document that I am aware of is the
following:

* It was suggested in a review that we should explicitly specify (when we
discuss error handling) that an implementation send a BGP NOTIFICATION
message when an error occurs.

Personally, I don't think this is necessary. (In particular, my reading
of draft-ietf-idr-error-handling-13 is that in the "treat as withdrawal"
case that a NOTIFICATION message is not required.

That being said, I am very willing to defer to the BGP experts in the group
on this issue. In particular, does anyone know if the intention of
draft-ietf-idr-error-handling is for a NOTIFICATION to be sent when an
error is "treat as withdrawal"? (I am concerned that sending a NOTIFICATION
message in a case where we are not closing the session is not a good idea,
but I am certain that others know more about these details than I do.)