[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>,        ops-dir@ietf.org <ops-dir@ietf.org>,        leo.liubing@huawei.com
<leo.liubing@huawei.com>,        jiangsheng@huawei.com <jiangsheng@huawei.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA03B08B@AZ-FFEXMB04.global.avaya.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