Re: [renum] Late gap in the gap analysis

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 10 January 2013 08:52 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: renum@ietfa.amsl.com
Delivered-To: renum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAD521F890E for <renum@ietfa.amsl.com>; Thu, 10 Jan 2013 00:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.372
X-Spam-Level:
X-Spam-Status: No, score=-100.372 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, MANGLED_PAIN=2.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 aXzYnqM5aPma for <renum@ietfa.amsl.com>; Thu, 10 Jan 2013 00:52:48 -0800 (PST)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 681F421F86CE for <renum@ietf.org>; Thu, 10 Jan 2013 00:52:47 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hq4so144456wib.8 for <renum@ietf.org>; Thu, 10 Jan 2013 00:52:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lIx51jJJikm22c48exGdMJpTAbzlQ5wfDkRk4o78Ges=; b=jDFRiSCe1uAlnpeHgIsJu1FnqHJSNTm3PEqX9dgk/OaYdcdOnOc41cvPnubl9N2YBW PFEE24niYGrNgzPQCrYakUqK4C5v6pGe0YlC0i1JrESOkFT03g9rSOxmzkl2TQ0J72ah c5CTBLhYrr/P4OGb64vNIUpMmlVjDhd+nz3JHXmyVIGitKlQpEGIMUOPBjgmLtcsJgr8 YlreGVyXm00gyngB7JIMx29Vk8Z1KkHlQ+hzFApJO5uDik5CgpG5gQIdP+G+zHVTVL7+ hWIw+j5ktwVxi3pRR7/0R4lMgLFNsz2N+IaWDkCv+eYHfLQQDQoSep5+IEbWEsT79zqJ oPDA==
X-Received: by 10.194.78.207 with SMTP id d15mr112922741wjx.52.1357807966233; Thu, 10 Jan 2013 00:52:46 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-216-229.as13285.net. [2.102.216.229]) by mx.google.com with ESMTPS id t17sm1276307wiv.6.2013.01.10.00.52.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jan 2013 00:52:45 -0800 (PST)
Message-ID: <50EE8167.2000205@gmail.com>
Date: Thu, 10 Jan 2013 08:52:55 +0000
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Liubing (Leo)" <leo.liubing@huawei.com>
References: <50EE7145.5040406@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453CD00A4A@szxeml509-mbx>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453CD00A4A@szxeml509-mbx>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "renum@ietf.org" <renum@ietf.org>
Subject: Re: [renum] Late gap in the gap analysis
X-BeenThere: renum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Renumbering discussion mailing list." <renum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/renum>, <mailto:renum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/renum>
List-Post: <mailto:renum@ietf.org>
List-Help: <mailto:renum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/renum>, <mailto:renum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2013 08:52:49 -0000

Well,I think it is wrong to say "may be needed" - I would prefer
to make a stronger statement such as "are needed". Actually the text
is pessimistic - it doesn't seem hard to check that the old prefix is
no longer announced, for example.

Regards
   Brian

On 10/01/2013 08:15, Liubing (Leo) wrote:
> Hi, Brian
> 
> I think the current section 7.3 in gap draft covering that, however, it is not so explicit.
> But I think it is sufficient. How do you think about it?
> 
> /* 7.3. Renumbering Monitoring
>    While treating renumbering as a network event, mechanisms to monitor
>    the renumbering process may be needed. Considering the address
>    configuration operation may be stateless (if ND is used for
>    renumbering), it is difficult for monitoring. But for the DNS and
>    filter update, it is quite possible to monitor the whole process. */
> 
> B.R.
> Bing
> 
> 
>> -----Original Message-----
>> From: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On Behalf
>> Of Brian E Carpenter
>> Sent: Thursday, January 10, 2013 3:44 PM
>> To: renum@ietf.org
>> Subject: [renum] Late gap in the gap analysis
>>
>> I know this comes late in the process, but the attached comment
>> on draft-ietf-6renum-enterprise actually identifies a gap
>> in the gap analysis.
>>
>>     Brian
>>
>> -------- Original Message --------
>> Subject: Re: [OPS-DIR] OPS-DIR review of draft-ietf-6renum-enterprise-04
>> Date: Wed, 09 Jan 2013 18:23:25 +0100
>> From: Benoit Claise <bclaise@cisco.com>
>> To: Brian E Carpenter <brian.e.carpenter@gmail.com>
>> CC: Romascanu, Dan (Dan) <dromasca@avaya.com>om>,
>> ops-dir@ietf.org <ops-dir@ietf.org>rg>,        leo.liubing@huawei.com
>> <leo.liubing@huawei.com>om>,        jiangsheng@huawei.com
>> <jiangsheng@huawei.com>
>> References:
>> <9904FB1B0159DA42B0B887B7FA8119CA03B08B@AZ-FFEXMB04.global.ava
>> ya.com> <50C866F0.9050607@gmail.com>
>>
>> Brian,
>>> Dan,
>>>
>>> Thanks. At the moment we definitely don't have a mandate to make
>>> this a BCP; I agree that its status needs to be a bit clearer.
>>>
>>> Your other comments are useful.
>>>
>>>> 7. From the list of operational issues to be verified as per RFC 5706 I
>> believe that the following applies: Have suggestions for verifying correct
>> operation been discussed? In this case this translates into the question
>> whether there are any recommended practices to ensure that the
>> renumbering process was fully completed and the transformation that
>> occurred is exactly what the operators planned.
>>> That's a very interesting point. For example one could monitor
>>> RA and ND messages to check that the old prefixes had really died.
>>> I suspect that in the scope of this draft we can only really mention
>>> the problem, but maybe you have found a gap in the gap analysis
>>> draft.
>> Yes, this should be covered in the gap analysis draft.
>>
>> Regards, Benoit
>>> Regards
>>>     Brian Carpenter
>>>
>>> On 11/12/2012 15:58, Romascanu, Dan (Dan) wrote:
>>>> Please find below the OPS-DIR review of draft-ietf-6renum-enterprise-04.
>>>>
>>>> This review is performed for the benefit of the OPS ADs and focuses on
>> operational and manageability issues. RFC 5706 was used as a reference for
>> this review.
>>>> The document targets Informational RFC status and provides a useful set
>> of scenarios and guidelines to network operators on best renumbering
>> practices. It is almost ready for publication, a few glitches are mentioned
>> below and the ADs may decide whether they consider these as blocking and
>> include in a DISCUSS or nice-to-fix and then they could be part of a
>> COMMENT or may be completely ignore.
>>>> 1. the language used in this document in some places sounds like BCP-ish.
>> It is fine as it stands because the document has Intended Status of
>> Informational, but in case the IESG has any thoughts about changing the
>> Intended Status and approving this I-D as a BCP, then it needs revisiting for
>> consistency of the language and possible usage of RFC 2119 keywords.
>>>> 2. [RFC4057] needs to be a Normative Reference. All the document is
>> about the Enterprise Networks, a clear definition is thus required in order to
>> understand its scope, and document where this definition is taken from is
>> essential for the understanding of the document.
>>>> 3. In Section 2 I see:
>>>>> Figure 1 provides a sample enterprise network architecture. Those
>>>>     entities relevant to renumbering are highlighted.
>>>> I do not understand what 'are highlighted' means on Figure 1 which is
>> ASCII art
>>>> 4. Some acronyms are not expanded at first occurrence - for example PD,
>> PA in Section 4.1, etc.
>>>> 5. 'ND is considered easier to renumber' (where ND is Network Discovery)
>> - I could not understand what this means
>>>> - Section 5 starts with the following statement:
>>>>> As noted, a site that is listed by IP address in a black list can
>>>>     escape that list by renumbering itself.
>>>> I am uncertain where this was noted, as this seems to be the first
>> occurrence of the issue of black list in the document.
>>>> 6. The document can benefit from a pass with a native English speaker. I
>> spotted several grammar and vocabulary problems which I did not list as
>> these are our of the scope of an OPS-DIR review, and the RFC Editor will
>> certainly do a fine job, but in some cases these problems distort the sense of
>> the sentences - for example ' This work is illuminated by RFC5887, so thank
>> for RFC 5887 authors' this is probably ' This work is inspired by (or derived
>> from)  RFC5887, so thanks to RFC 5887 authors'
>>>>
>>>> 7. From the list of operational issues to be verified as per RFC 5706 I
>> believe that the following applies: Have suggestions for verifying correct
>> operation been discussed? In this case this translates into the question
>> whether there are any recommended practices to ensure that the
>> renumbering process was fully completed and the transformation that
>> occurred is exactly what the operators planned.
>>>> Thanks and Regards,
>>>>
>>>> Dan
>>>>
>>>>
>>> _______________________________________________
>>> OPS-DIR mailing list
>>> OPS-DIR@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ops-dir
>>>
>>>
>>
>>
>> --
>> Regards
>>    Brian Carpenter
>>
>>
>> _______________________________________________
>> renum mailing list
>> renum@ietf.org
>> https://www.ietf.org/mailman/listinfo/renum
>