Subject: [arch-d] Value system in the achitecture

From: S Moonesamy <[email-masked]>
Date: Sat, 16 Jul 2016 08:28:45 -0700

Hi Niels, Cath,

I read the following in your document:

>The main disagreement between these two academic positions lies
>mostly in the question on whether a particular value system should be
>embedded into the Internet's architecture or whether the architecture
>needs to account for a varying set of values.

Another question is whether a particular value system is part of the 
internet's architecture.  Once a value system is embedded in the 
architecture it is difficult to remove it or not use it.  For 
example, I could argue that if you do not do not like the existing 
Domain Name System you can choose another system as there isn't any 
technical limitation to prevent that.  I would be ignoring that there 
are dependencies on the Domain Name System in the architecture.

Or is the question about whether a particular ideological system 
should be embedded into the architecture, or where the architecture 
needs to account for a varying set of ideological systems, or what to 
do when there are incompatible ideologies?

Regards,
S. Moonesamy

---

From: Niels ten Oever <[email-masked]>
Date: Sun, 17 Jul 2016 09:33:15 +0200

Dear S. Moonesamy,

I suspect that you are referring to:

https://tools.ietf.org/html/draft-tenoever-hrpc-research-03

In that case I think the best place to discuss it is in hrpc:
https://www.irtf.org/mailman/listinfo/hrpc
https://irtf.org/hrpc

because the document is an active document of that research grouo.

But allow me to reply inline:

On 07/16/2016 05:28 PM, S Moonesamy wrote:
> internet's architecture.  

That is exactly the question of the draft.

> Once a value system is embedded in the
> architecture it is difficult to remove it or not use it. 

Depends how it's done. Also: Brown et al argue that currently already
values are embedded in the architecture.
https://tools.ietf.org/html/draft-tenoever-hrpc-research-03#section-4

> For example, I
> could argue that if you do not do not like the existing Domain Name
> System you can choose another system as there isn't any technical
> limitation to prevent that.  I would be ignoring that there are
> dependencies on the Domain Name System in the architecture.
> 

One can use different implementations of DNS:
https://yeti-dns.org/
http://dns.dot-bit.org/

> Or is the question about whether a particular ideological system should
> be embedded into the architecture,
> or where the architecture needs to
> account for a varying set of ideological systems, or what to do when
> there are incompatible ideologies?

The word 'ideology' is mentioned in the draft at all.

The aim is: (1) to bring forth which values are being used while
designing the protocols and (2) understand their (enabeling or adverse)
impacts on human rights, as per the charter of hrpc:
https://irtf.org/hrpc

Happy to discuss.

Best,

Niels

---

From: S Moonesamy <[email-masked]>
Date: Sun, 17 Jul 2016 02:17:28 -0700

Hi Niels,
>https://tools.ietf.org/html/draft-tenoever-hrpc-research-03

Yes.  I'll follow up on (IRTF) HRPC.

Regards,
S. Moonesamy

---

From: John Day <[email-masked]>
Date: Sun, 17 Jul 2016 06:37:38 -0400

From these two notes, it would appear that they are not about architecture, but about a construction in an architecture.

The definition of architecture we have always used (for at least 40 years) comes from the dictionary: “the set of rules that define a style of construction.”  It is important to distinguish an architecture from “buildings” built to that architecture.

Specific name spaces are not specified in an architecture. Only that a name space is needed for particular purposes. The form of the name space is a characteristic of the specific construction, not of the architecture. Many such constructions should be possible from a given architecture. (Of course, it is always possible to do it badly.) ;-)

However, that said. It is possible to define architectures that do embody certain value systems.  For example, the PTTs were quite good in defining the “beads-on-a-string” architecture so that it defined markets positive to their value system.  The original networking model (and later the internet model) defined an architecture that contradicted the “beads-on-a-string” model, which caused considerable controversy until the beads-on-a-string model finally got the upper hand.

It is not possible to define an architecture that does not impose some value system.

Take care,
John Day

> On Jul 17, 2016, at 03:33, Niels ten Oever <[email-masked]> wrote:
> 
> Dear S. Moonesamy,
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: Niels ten Oever <[email-masked]>
Date: Sun, 17 Jul 2016 12:41:56 +0200

> It is not possible to define an architecture that does not impose some value system.

+1

And the aim of the hrpc rg is to make these values more visible and
explicit and provide guidelines which could help protocol designers in
decision making.

Let's continue the discussion in hrpc:
https://www.irtf.org/mailman/listinfo/hrpc

Best,

Niels

---

From: S Moonesamy <[email-masked]>
Date: Sun, 17 Jul 2016 08:33:09 -0700

Hi John,

Thanks for the explanation.

At 03:37 17-07-2016, John Day wrote:
> From these two notes, it would appear that they are not about 
> architecture, but about a construction in an architecture.
>
>The definition of architecture we have always used (for at least 40 
>years) comes from the dictionary: "the set of rules that define a 
>style of construction."  It is important to distinguish an 
>architecture from "buildings" built to that architecture.
>
>Specific name spaces are not specified in an architecture. Only that 
>a name space is needed for particular purposes. The form of the name 
>space is a characteristic of the specific construction, not of the 
>architecture. Many such constructions should be possible from a 
>given architecture. (Of course, it is always possible to do it badly.) ;-)

One of the choices is that "a single naming structure should be used" 
as that is a way to avoid a design that requires addresses to be hard 
coded.  If I understood the above correctly, that would be under "the 
set of rules that define a style of construction".

The existence of a unique public name space is required.  From the 
above (see quoted text), I understand that it would be part of the 
construction.

Regards,
S. Moonesamy

---

From: John Day <[email-masked]>
Date: Sun, 17 Jul 2016 14:51:02 -0400

Addresses in a layer are suppose to be location-dependent and route-independent. (This we have understood since the beginning, or at least since John Shoch’s paper or to anyone from the Midwest! ;-)  ) That implies that they should be assigned by the layer, since the layer (and its management) are the only one that knows where a new member is relative to the graph of the layer. There is never a need to hard code addresses in a properly formed architecture which really just means that the architecture recognizes the enrollment phase and addresses are assigned by a layer. Obviously the scope of any address is the layer in which it is used. There is no reason for addresses to be visible outside the layer in which they are used. They would be meaningless anyway.  The assignment of addresses is a property of the layer, not of an architecture. Any structure they might have is also internal to the layer and independent of the architecture.  (Yes, I know, there is a view among some that addresses belong to protocols. This is simply incorrect.)

So-called application names are a little different story. This is, of course, something that the Internet does not have. (Domain names are simply macros for IP addresses, not names of application processes.) Application names should be location-independent. (It should be possible to move a process to a different system without changing its name.)  Of course, these must be unambiguous within some scope. How unique the naming structure has to be is another story. Clearly one needs a registration hierarchy, and different sorts of applications might fit in different places in that hierarchy, but at whatever point in the tree they do fit, any structure below that is their problem to define.

While a unique public name space can be useful, there is no requirement for one. In fact, not having one can be quite useful and is in common practice today. In fact, there is probably no means to prevent it. 

Take care,
John

> On Jul 17, 2016, at 11:33, S Moonesamy <[email-masked]> wrote:
> 
> Hi John,
> 
>> The definition of architecture we have always used (for at least 40 years) comes from the dictionary: "the set of rules that define a style of construction."  It is important to distinguish an architecture from "buildings" built to that architecture.
>> 
> One of the choices is that "a single naming structure should be used" as that is a way to avoid a design that requires addresses to be hard coded.  If I understood the above correctly, that would be under "the set of rules that define a style of construction".
> 
> The existence of a unique public name space is required.  From the above (see quoted text), I understand that it would be part of the construction.
> 
> Regards,
> S. Moonesamy