[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-narten-ipv6-3177bis-48boundary-04.txt



Folks,

I've requested and been granted agnenda time for this document in
Thursday's v6ops session.

Some background:

The document was discussed in Philly, but none of the authors could be
in the session. It was also discussed on the list just before and
after Philly.

My goal for the Thursday session will be to review the purpose of the
document, and see if the WG is willing to take it on as a WG document.

I will be sending out some followup mail, commenting on the dialog
that took place during the Philly session (I just reviewed the audio
again).

Some points:

1) This document is NOT trying to set or specify policy and say what
   the actual boundary should be. The main reason for that is that the
   policy decision is for the RIRs to make. Although we may have
   opinions (I do!), that discussion should be taken to the
   RIRs.

   Also, going back through the previous comments, while a number of
   people have agreed that a default of /48 is not appropriate, there
   has been far less agreement on what an appropriate default should
   be.  Thus, I have doubts we'd be able to come up with a consensus
   recommendation on a particular value.

2) This document is trying to make clear what (if any) the
   architectural issues are w.r.t. a boundary choice. As the document
   itself states, the only issues appear to be minor. If you disagree,
   please be specific about what issues need to be added to the
   document.

3) Most of the issues about where the end site boundary should be are
   operational, not architectural (hence, bringing the document to
   v6ops). I.e, things like using nibble boundaries to facilitate
   delegation of PTR records, renumbering considerations, etc.

4) The RIRs have already moved away from a single /48 for all. So,
   this document is not really about getting the RIRs to change their
   existing policies (that has already effectively been done), than to
   show that those changes are consistent with the IPv6 archtecture.

If folk want to review the previous thread, have a look here:

http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00395.html

Thomas