Re: [renum] Late gap in the gap analysis

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>,
> 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.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