Re: [pcp] Alissa Cooper's No Objection on draft-ietf-pcp-anycast-07: (with COMMENT)

Sebastian Kiesel <ietf-pcp@skiesel.de> Mon, 14 September 2015 21:45 UTC

Return-Path: <sebi@gw01.ehlo.wurstkaes.de>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8E91A90DA; Mon, 14 Sep 2015 14:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level:
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 oAcbX5RuczKr; Mon, 14 Sep 2015 14:45:24 -0700 (PDT)
Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49CD1A8A63; Mon, 14 Sep 2015 14:45:15 -0700 (PDT)
Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.80) (envelope-from <sebi@gw01.ehlo.wurstkaes.de>) id 1ZbbYl-0003RP-LX; Mon, 14 Sep 2015 23:45:11 +0200
Date: Mon, 14 Sep 2015 23:45:11 +0200
From: Sebastian Kiesel <ietf-pcp@skiesel.de>
To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <20150914214511.GA2310@gw01.ehlo.wurstkaes.de>
References: <20150914180105.32262.68626.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150914180105.32262.68626.idtracker@ietfa.amsl.com>
Accept-Languages: en, de
Organization: my personal mail account
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/i4piSTmwf7TW6fnKd9kBxdVEuLI>
Cc: draft-ietf-pcp-anycast.ad@ietf.org, draft-ietf-pcp-anycast.shepherd@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-pcp-anycast@ietf.org, pcp@ietf.org, pcp-chairs@ietf.org
Subject: Re: [pcp] Alissa Cooper's No Objection on draft-ietf-pcp-anycast-07: (with COMMENT)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2015 21:45:25 -0000

Hi Alissa,

On Mon, Sep 14, 2015 at 11:01:05AM -0700, Alissa Cooper wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-pcp-anycast-07: No Objection
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Given the issue described in 5.1, I'm curious about this text:
> 
> "PCP clients usually send PCP requests to these addresses if
>    no other PCP server addresses are known or after communication
>    attempts to such other addresses have failed."
> 
> Would it make more sense to make a normative recommendation about the
> order in which addresses should be tried, to help minimize the frequency
> of cases where PCP requests to the anycast address(es) leak out
> unnecessarily?

thanks for your feedback!

our draft specifies (in Sec. 2.1) that the anycast addresses are
appended to the list of (candidate) PCP server addresses and that this
list is processed as specified in RFC 7488, which says that the list has
to be sorted as specified in RFC 6724, sec. 6.  This sorting causes
that the anycast addresses are tried after the default routers and
other addresses in topological vicinity of the client, which might be
known from other sources such as DHCP or configuration files.

I must admit that this chain of normative references may be somewhat
confusing.  I was trying to write a short self-contained specification
but gave up - would have to copy too much text from the existing RFCs.
On the other hand, a plus of the current situation is that if an
implementor already has an implementation of RFC 6724, (s)he can just
include/link/call it.

Regrads,
Sebastian