Re: [RAM] First cut at routing & addressing problem statement

At 22:24 31/07/2007, Thomas Narten wrote:
>We intended the term "site" to be a fairly general term, one that
>includes pretty much any topologically distinct thing that connects to
>the internet. This includes home users. It is also NOT restricted to
>just larger enterprises or ASes. We'll add a clarifying definition to
>the document.

Dear Thomas,
I am sorry but "5. Provides meaningful benefits to the parties who 
bear the costs of deploying and maintaining the technology." is an 
error. What we want is to provide meaningful benefits to the users. 
The users are those who have the money but no incentive today. Their 
satisfaction is the benefit for the parties who beat the costs, 
because they will pay. Not the IETF.

The incentives for them the users are:

- to get presentation layer warranties. Each network application 
tries to build its own virtual presentation layer features. IDNs and 
200 languages. ccTLD with 193 countries. RFC4646 and 7,500 languages. 
Addressing does not, while there is an unlimited need.

- as a result SNHN (small networks/home networks) have not been 
considered and their addressing area has not been protected and 
supported by the addressing format which is for them no better than a NAT.

- privacy, security, national policies require that the "sites" can 
decide of their routing.

Addressing is to point fixed, mobile, virtual targets on "the 
semantic distributed networks of the decentralized logical network of 
the centralized ISP/Corp/SNHN bandwidth networks" in order to flow a 
traffic of fractal natue. To match the resulting diversity and 
routing constraints (path, access, and content) presentation layer 
equivalence is of the essence (whatever you name it: presentations, 
externets, groups/classes, views, closed user groups, etc.) I looked 
for "presentation layer" in the list's archive. I did not find it a 
single occurence.

Such a layer could be implemented in part through the addressing 
structure. Multi-level addressing also can help it. May be there are 
other possibilities. This should also be investigated through a 
"smart NIMROD"? It could be involved in getting some control on 
routing? Whatever the solution retained, it should provide the best 
addressing and operational environment to "plug-and-play" 
standardized sub-addresses.
jfc

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram