Re: [nat66] Comments on draft-mrw-nat66-12

[JFC Morfin <[e-mail]>]

At 23:51 15/03/2011, Fred Baker wrote:
>  Rather than quote RFC 3439 on the topic, I'll simply encourage 
> people to read its comments on complexity, amplification, and 
> especially coupling, which may be found at 
> http://tools.ietf.org/html/rfc3439#section-2. When you couple 
> layers together, things go belly up. Instead of complaining about 
> the fact, which the IETF makes a grand past-time of and this thread 
> is a case in point, start thinking about how to not couple them.

Amen.

This is, however, IPv6 built-in. From designers' point of view there 
is an IPv6 address.

 From a user point of view, there are three address layers supported 
by three address segments in an "IPv6 address", that are rather 
similar to domain name levels (and that can be supported by domain 
name levels):

- the IDv6 user defined regional addressing plan (64 bits)
- the GRIDv6 user announced regional ID (the extension to 64 bits of 
the network address below ­ or the leading bits of the IDv6 segment 
if the network address is 64 bits)
- the IPv6 network address, i.e. the leading block provided by the 
ISP - the part you want to change.

The most difficult part for us is obviously the fuzzy GRIDv6 
identification. There could be a negotiation or the use of bit 65, to 
be set to 0 or 1 in order to indicate where the GRIDv6 info is located.

To better accept this, please remember that the IDNA2008 resolution 
has introduced subsidiarity as the way to address diversity. The 
English language actually lacks two words to fully describe 
subsidiarity in this case:

- what could be translated as "active subsidiarity" from French 
"subsidiarité active", which is a poor word for the concept of 
"matching unity and diversity", I would prefer to translate as 
"progressive or layered subsidiarity". This is what happens in the 
Internet. Introducing subsidiarity in higher (new) fringe to fringe 
layers is the way to protect unity in the lower (most, if not all) 
end to end layers.

- what I do not know how to translate in English is the "principe de 
suppléance", which means that when subsidiarity fails, the upper 
level or collaterals or even the lower level are to provide help 
while respecting the subsidiarity principle. This is the way 
subsidiarity scales. Beware: this is not by solidarity, as it is 
sometimes translated. Solidarity is centered on each subsidiary level 
that needs cooperation because something failed and it requires a 
patched solution, which is to be carried out together on the 
occasion.  Suppléance is a built-in governance mechanism that 
everyone can rely upon as acting as necessary, but not more than 
necessary, when and only when needed. Solidarity is occasional, and 
suppleance capacity is permanent. Suppleance is a governance 
principle, while solidarity is a survival solution.

For example, this should be the role of ICANN in naming and 
addressing. Hierarchy is based on ruling, and subsidiarity is based 
on serving. Suppleance is the way that this serving scales. When I 
say that IDv6 can be supported by domain names translated into IIDs, 
this is by the suppleance of the inability of IPv4 to support local 
IIDs. When Fred proposes NPTv6, this is the simplest (RFC 3439) way 
to apply the suppleance principle among collaterals.

jfc