[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