Re: [renum] Late gap in the gap analysis

OK, I can update it accordingly. 
The original text implying the solutions might be difficult, but we need to make it clear that the gap is definite.

B.R.
Bing

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Thursday, January 10, 2013 4:53 PM
> To: Liubing (Leo)
> Cc: renum@ietf.org
> Subject: Re: [renum] Late gap in the gap analysis
> 
> 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>,
> >> 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
> >