Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

Jon Mitchell <jrmitche@puck.nether.net> Thu, 13 December 2012 21:07 UTC

Return-Path: <jrmitche@puck.nether.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0BE21F8B96 for <idr@ietfa.amsl.com>; Thu, 13 Dec 2012 13:07:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.507
X-Spam-Level:
X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVB34nS1HaJE for <idr@ietfa.amsl.com>; Thu, 13 Dec 2012 13:07:39 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4430A21F8B92 for <idr@ietf.org>; Thu, 13 Dec 2012 13:07:39 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by puck.nether.net (8.14.4/8.14.4) with ESMTP id qBDL7bEp000415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2012 16:07:37 -0500
Received: (from jrmitche@localhost) by puck.nether.net (8.14.4/8.14.4/Submit) id qBDL7bwp000414; Thu, 13 Dec 2012 16:07:37 -0500
Date: Thu, 13 Dec 2012 16:07:37 -0500
From: Jon Mitchell <jrmitche@puck.nether.net>
To: David Farmer <farmer@umn.edu>
Message-ID: <20121213210737.GA23120@puck.nether.net>
References: <FA7751F7-820B-41E4-AB56-BAB9D44BB353@kumari.net> <CA1705A3-1F62-46E4-999F-2F9DBE2E7378@puck.nether.net> <CAL9jLaYg+3vnOzwGLdpJCvB1obkUv_ZVa-p92z1FFg_T=8yNTw@mail.gmail.com> <FB0C298A-D18A-454C-B910-141B9ED853A2@puck.nether.net> <CAL9jLab6+PpLEw8oBV6-_mLVTCzG2P-64z3Q+JtJGFneG1QBGQ@mail.gmail.com> <50C93B5D.4010607@umn.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E1118AD@eusaamb109.ericsson.se> <50C94133.9060805@umn.edu> <20121213140913.GA4524@puck.nether.net> <50C9EF56.5050204@umn.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <50C9EF56.5050204@umn.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 13 Dec 2012 16:07:37 -0500 (EST)
Cc: IETF IDR Working Group <idr@ietf.org>
Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2012 21:07:40 -0000

On Thu, Dec 13, 2012 at 09:08:06AM -0600, David Farmer wrote:
> Thanks for the excellent reference.
> 
> With that, I think keeping the current title and using the term
> "private use" in most of instances is appropriate.  However, I'd
> would like to suggest the phrase "local or private use" be used in
> the first sentence of the abstract and introduction sections,
> keeping "private use" only elsewhere.  And, I think it would be
> great if you could add the reference below in the first sentence of
> the introduction as well.

I think the use of "local" has a less exact definition (local to what)
and don't feel this adds significant value to the draft.  Further, I
think the motivation paragraph saying this is for a single organization
addresses the scope that private ASNs are meant to have already (as well
as many of the concerns expressed about people using this for ISP
customers which I'm not sure could be called the same organization by
any definition as the entity allocating the ASNs).  All other parts of
the draft appear to use the term "private use" consistently.

> 
> Pulling something out of my other message, I think adding "by
> replacing Section 10 in its entirety." to the end of the abstract
> clarifies how this draft intends to updates RFC 1930.

I think this adds clarity on what parts of RFC 1930 this impacts and am
willing to make this change to the abstract.  I don't think this
represents an actual content change to the draft however... 

Jon


> 
> Thanks
>