Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt

S Moonesamy <sm+ietf@elandsys.com> Sat, 12 January 2013 18:24 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E641621F8713 for <ietf@ietfa.amsl.com>; Sat, 12 Jan 2013 10:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.495
X-Spam-Level:
X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 tAz3vcwQCgk5 for <ietf@ietfa.amsl.com>; Sat, 12 Jan 2013 10:24:29 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D398B21F8830 for <ietf@ietf.org>; Sat, 12 Jan 2013 10:24:28 -0800 (PST)
Received: from SUBMAN.elandsys.com ([197.224.141.182]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0CIOC80029581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jan 2013 10:24:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1358015065; bh=gozRoE4e8jhiQ8HMutMvOAmbhCUFj0rB4FZLjpc+95U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OqMaQikxFZzc+iWYqihQkGUmhBbSuKltyLllPp3IblVQD9Nesqq9DByA+CUDw33UJ RSJG3lj9bBrP+szG3M7ScOpJAKLFPd80zqCcl/Uf5eXIPY53GhscV0Yn/5t7ABKDXD +63dGGTNhJWnqpE98kw+Vr6FKoIx5CQZ6Y0RMicM=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1358015065; i=@elandsys.com; bh=gozRoE4e8jhiQ8HMutMvOAmbhCUFj0rB4FZLjpc+95U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=q81jce6aXXGYl/3GQNg8yvaD/mveFa1zIZUR/78G0SbqntfZib47eSVMbAfPxl1px n4a1IW8LbfZGL+z8TOvCH+HfLQoK4/8HjxWz8QciEXY5bpxn6z5vYkg2dTdasr0y0S PvoP6Qa69O2ujNJCCxS9W/y8PFBN3ycslTxeJjMM=
Message-Id: <6.2.5.6.2.20130112064815.05ffc568@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 12 Jan 2013 10:18:10 -0800
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Abdussalam Baryun <abdussalambaryun@gmail.com>
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt
In-Reply-To: <50F12E80.8080007@gmail.com>
References: <20130112085109.7357.35960.idtracker@ietfa.amsl.com> <50F12E80.8080007@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Jan 2013 18:24:30 -0000

At 01:36 12-01-2013, Brian E Carpenter wrote:
>I object to making RFC 2050 historic without retaining at least the
>content of its Section 1 as an IETF BCP.

 From Section 1 of RFC 2050:

   "Currently there are three regional IRs established;
    InterNIC serving North America, RIPE NCC serving Europe,
    and APNIC serving the Asian Pacific region."

The above information is outdated.

>While the IETF did formally hand over details of address
>allocation policy to IANA, we did so knowing that the RIRs
>themselves, and IANA, considered themselves bound by RFC 2050
>(see the list of authors of that document).

That was in 1996.  The question is whether BCP 12 reflects current practices.

>An update of RFC 2050, within the scope set by the IETF-IANA
>MoU, would be reasonable. Abrogation is not reasonable.

Noted.

At 03:44 12-01-2013, Abdussalam Baryun wrote:
>I also think similar with Carpenter, why reclassify to historic.
>rfc2050 is still valid, and why limiting the ietf?

IETF participants have not decided about policies regarding IP 
address allocation since well over 10 years.  Such matters are 
determined within other communities.  It would only be limiting to 
the IETF if it is a matter directly related to IETF protocols.

Regards,
S. Moonesamy