Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 30 October 2018 14:08 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CB8128CF2; Tue, 30 Oct 2018 07:08:44 -0700 (PDT)
X-Quarantine-ID: <6eZXH6aXU5Mm>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 6eZXH6aXU5Mm; Tue, 30 Oct 2018 07:08:39 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7219F127AC2; Tue, 30 Oct 2018 07:08:38 -0700 (PDT)
X-AuditID: 12074425-53fff7000000273f-c2-5bd865e22df7
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id B6.54.10047.3E568DB5; Tue, 30 Oct 2018 10:08:36 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id w9UE8Ul8007679; Tue, 30 Oct 2018 10:08:31 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9UE8PUY006360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Oct 2018 10:08:27 -0400
Date: Tue, 30 Oct 2018 09:08:24 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: The IESG <iesg@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "draft-ietf-ospf-lls-interface-id@ietf.org" <draft-ietf-ospf-lls-interface-id@ietf.org>, Yingzhen Qu <yingzhen.ietf@gmail.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Message-ID: <20181030140824.GS45914@kduck.kaduk.org>
References: <154047014077.16281.149253858167058600.idtracker@ietfa.amsl.com> <58B0C6F5-6153-4117-B214-176A9B68189C@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <58B0C6F5-6153-4117-B214-176A9B68189C@cisco.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsUixG6nrvsk9Ua0wd92cYvJb+cxW9w4tIHJ 4tr3+2wWM/5MZLZYf/Uki8WJJytYLW6tP8bswO4x5fdGVo+ds+6yeyxZ8pMpgDmKyyYlNSez LLVI3y6BK2PO0mmsBTP4K7Z8mcnSwHiNu4uRk0NCwESi/8p29i5GLg4hgTVMEjc+bmCEcDYy SvT1bGQCqRISuMskceeIPIjNIqAq8XPaJ7A4m4CKREP3ZeYuRg4OEQFNiS3vWUB6mQX2M0lc P7qBDaRGWCBZ4tGis2D1vEDbepc9YYGYWS/Rc/8dK0RcUOLkTIg4s4C6xJ95l8BmMgtISyz/ xwERlpdo3jqbGcTmFLCVuHl1GpgtKqAssbfvEPsERsFZSCbNQjJpFsKkWUgmLWBkWcUom5Jb pZubmJlTnJqsW5ycmJeXWqRroZebWaKXmlK6iREcES6qOxjn/PU6xCjAwajEw/sg+Ua0EGti WXFl7iFGSQ4mJVHe8x+vRwvxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4V3rBVTOm5JYWZValA+T kuZgURLnndSyOFpIID2xJDU7NbUgtQgmK8PBoSTBuzsFqFGwKDU9tSItM6cEIc3EwQkynAdo OEsqyPDigsTc4sx0iPwpRkUpcV5lkIQASCKjNA+uF5SwJLL317xiFAd6RZi3DWQFDzDZwXW/ AhrMBDSYix1scEkiQkqqgXHa/0UhO1uKbsa+DTarrZmYd3zq4toNGqLm7bsMV//uMqxdWLp8 IfMBqU5/jVtOvQVbJd0Vk9Y7i/+817H3ZHNh6J/jMnLvRad+ZVud1Cus8qq58840/3ubVSO8 cwImJhfbWv9vmbmr7M3/0KlHMtIrFhkfutAtVsr7tH+Pw/c19lKhDyKPXFFiKc5INNRiLipO BAASR3JYMwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/FagTxK-zd5WGGZvqvFi1ibFI0kc>
Subject: Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2018 14:08:44 -0000

Hi Acee,

On Thu, Oct 25, 2018 at 01:51:42PM +0000, Acee Lindem (acee) wrote:
> Hi Ben, 
> 
> On 10/25/18, 8:22 AM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
> 
>     Benjamin Kaduk has entered the following ballot position for
>     draft-ietf-ospf-lls-interface-id-08: No Objection
>     
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
>     
>     
>     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>     for more information about IESG DISCUSS and COMMENT positions.
>     
>     
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-ospf-lls-interface-id/
>     
>     
>     
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     Sending a new type of information to the peer usually involves a privacy
>     considerations analysis.  I don't expect there to be anything worrisome
>     here, but some text in the document indicating that the analysis has been
>     done would be reassuring.
> 
> Can you suggest some text? I was thinking:

I'm not sure that I could -- I don't have confidence that I understand the
system well enough to frame something in a complete and correct way.

>    Since the scope of the interface ID is limited to the advertising OSPF router 
>    uniquely identifying links, there are no privacy concerns associated with its
>    advertisement.

I wonder if there is a step missing to link these together -- that the
links are generally fixed and immobile, or that the scope of distribution
is limited to a set of trusted peers, perhaps?

Sorry I can't be more helpful...

-Benjamin