Subject: [renum] Draft 6RENUM WG charter

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 May 2011 09:19:04 +1200

Hi,

After the BOF and consultation with a few people, Tim Chown, Sheng Jiang
and I came up with the attached draft charter. Ron Bonica has asked us
to send it here for comments.

Regards
   Brian Carpenter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 May 2011 22:52:10 -0400

I like most of what is there.  Based on other working groups wehre 
things seemed simple and clear, I would be amazed if we could meet the 
stated schedule.

Yours,
Joel

On 5/16/2011 5:19 PM, Brian E Carpenter wrote:
> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum

---

From: Scott Brim <[email-masked]>
Date: Wed, 18 May 2011 21:44:59 -0400

Good, but the copy editor in me wants to totally rework how the ideas
are expressed.  Take what you like of these ideas.  I
believe what I have below is clearer ...

- Start with the first three substantial paragraphs,

    As outlined in RFC 5887, renumbering, especially for medium to
    large sites and networks, is currently viewed as an expensive,
    painful, and error-prone process, avoided by network managers as
    much as possible.

    As IPv6 adoption begins to gather momentum, those managers may
    turn to PI addressing for IPv6 to attempt to minimise the need for
    future renumbering. However, such an approach would create very
    serious BGP4 scaling problems if used by millions of end sites; it
    is thus desirable to develop tools, techniques and practices that
    may make renumbering a simpler process, to reduce demand for IPv6
    PI space.  In addition, as RFC 5887 describes, there are other
    triggers that mean some cases of renumbering are unavoidable, so
    it should be considered a given that a site may need partial or
    complete renumbering at some stage.

    Strategically it is thus important to implement and deploy
    techniques that facilitate simpler IPv6 site renumbering, so that
    as IPv6 becomes universally deployed, renumbering can be viewed as
    a more routine event.  This includes consideration of how the
    initial assignment and subsequent management of address
    information is performed, as this will affect future renumbering
    operations.

  The first paragraph is okay.  The second paragraph is really three
  parts:

    - There is a problem with using PI;
    - We need new approaches;
    - Renumbering is unavoidable.

  The first part (of the second paragraph) is specific to PI.  The
  middle part really belongs with the third paragraph.  The third part
  is more general.  They don't really go together, or in this order.
  I would rework it completely as below.

  In addition, don't be so hard on PI. PI is a way to avoid
  renumbering, but it may be that we rework routing so that PI is
  valid and highly acceptable (e.g. LISP).  Changing "would" to "may",
  etc.

  So here is what I would do with these paragraphs:

    As outlined in RFC 5887, renumbering, especially for medium to
    large sites and networks, is currently viewed as an expensive,
    painful, and error-prone process, avoided by network managers as
    much as possible.

    As RFC 5887 describes, there are triggers that mean some cases of
    renumbering are unavoidable, so it should be considered a given
    that a site may need partial or complete renumbering at some
    stage.  It is thus important to implement and deploy techniques
    that facilitate simpler IPv6 site renumbering, so that as IPv6
    becomes universally deployed, renumbering can be viewed as a more
    routine event.  This includes consideration of how the initial
    assignment and subsequent management of address information is
    performed, as this will affect future renumbering operations.

    If IPv6 site renumbering continues to be considered difficult,
    network managers will turn to PI addressing for IPv6 to attempt to
    minimise the need for future renumbering. However, widespread use
    of PI may create very serious BGP4 scaling problems.  It is thus
    desirable to develop tools, techniques and practices that may make
    renumbering a simpler process, to reduce demand for IPv6 PI space.

Onward.  Editing on the next paragraph:

  Old:

    For renumbering to become more routine, a systematic address
    management approach will be essential. A large site with a short
    prefix will be divided into subnets with longer prefixes. In this
    scenario, renumbering or partial renumbering can be complicated.
    Aggregation, synchronisation, coordination, etc., need to be
    carefully managed, and the use of manually inserted address
    literals minimised. In unmanaged scenarios, consideration may need
    to be made for 'flag day' renumbering (in contrast to the
    procedure described in RFC4192).

  New:

    For renumbering to become more routine, a systematic address
    management approach will be essential.  Renumbering or partial
    renumbering can be complicated in a large site with a short prefix
    divided into subnets with longer prefixes. Aggregation,
    synchronisation, coordination, etc., need to be carefully managed,
    and the use of manually inserted address literals minimised. In
    unmanaged scenarios, consideration may need to be made for 'flag
    day' renumbering (in contrast to the procedure described in
    RFC4192).

General: I don't see a reason to have "enterprise" and "SOHO"
anywhere.  The point is managed or unmanaged, which can be of any size
or type.  I would delete them everywhere.

Goal 2: Similarly take out "(manet/autoconf)".  Don't restrict
yourself at this stage with too many specific examples.

Goal 4: too many parentheses.  Take them all out, and make the last
one a full sentence.

Scott