Subject: [renum] I-D Action: draft-ietf-6renum-enterprise-05.txt

From: [email-masked]
Date: Fri, 21 Dec 2012 00:57:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Site Renumbering Working Group of the IETF.

	Title           : IPv6 Enterprise Network Renumbering Scenarios, Considerations and Methods
	Author(s)       : Sheng Jiang
                          Bing Liu
                          Brian Carpenter
	Filename        : draft-ietf-6renum-enterprise-05.txt
	Pages           : 17
	Date            : 2012-12-21

Abstract:
   This document analyzes events that cause renumbering and describes
   the current renumbering methods. These are described in three
   categories: those applicable during network design, those applicable
   during preparation for renumbering, and those applicable during the
   renumbering operation.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6renum-enterprise

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6renum-enterprise-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6renum-enterprise-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2012 13:54:09 +0000

WG,

This update is in response to Last Call and IESG comments. Here are a few notes:

Reacting to several reviewers, we clarified scope (analysis and description of
current methods) and reduced "BCP" language that confused the scope. Also
numerous editorial corrections.

Substantial reorganisation of the DNS section to improve logic and readability.

Apps Area review - clarified comments on application servers
and use of FQDN.

Martin Stiemerling's review - clarified discussion of black list
issue according to security area review.

OPS-DIR review -
 "[RFC4057] needs to be a Normative Reference" - not possible, it's an Informational RFC.

 "Have suggestions for verifying correct operation been discussed?" - paragraph added to
 section 4.3.

Benoit Claise's review - clarified scope, then

 "Section 1, paragraph 1

   However, widespread use of PI might
   create serious BGP4 scaling problems

 A reference, or a small explanation, would be welcome "

It's unfortunate that the RRG did not produce an RFC on BGP scaling problems.
We can refer to RFC 4116 but it isn't ideal.

SECDIR review - all points have been adopted

Regards
   Brian, Sheng, Bing

On 21/12/2012 08:57, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "George, Wes" <[email-masked]>
Date: Fri, 21 Dec 2012 09:42:55 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf

> It's unfortunate that the RRG did not produce an RFC on BGP scaling
[WEG] They didn't? While RRG didn't come to consensus on a *solution*, there was consensus documented about several aspects of the problem space that should serve as the necessary level of background reading to support this assertion.

> We can refer to RFC 4116 but it isn't ideal.
[WEG]
You may find better reference points in RFC4984, 6227, or even 6115.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2012 15:00:05 +0000

Wes,

> [WEG] They didn't? While RRG didn't come to consensus on a *solution*, there was consensus documented about several aspects of the problem space that should serve as the necessary level of backgrou…

Personally I wish that draft-narten-radir-problem-statement had
become an RFC. The published RRG documents say rather little about
the root causes of the scaling problem.

> You may find better reference points in RFC4984, 6227, or even 6115.

I think that 6227 is the best of those for this purpose.

Thanks
    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 21 Dec 2012 09:45:19 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Friday, December 21, 2012 7:00 AM
> To: George, Wes
> Cc: [email-masked]
> Subject: Re: [renum] I-D Action: draft-ietf-6renum-enterprise-05.txt
> 
> Wes,
> 
> > [WEG] They didn't? While RRG didn't come to consensus on a *solution*,
> there was consensus documented about several aspects of the problem space
> that should serve as the necessary level of background reading to support
> this assertion.
> 

Agree.

> I think that 6227 is the best of those for this purpose.

Also agree. IMHO, RFC6115 shows bias and was a snapsot-in-time
before all ideas were fully developed.

Thanks - Fred
[email-masked]
 
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum