From nobody Sat Jul 16 08:29:52 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E4812D0B0 for ; Sat, 16 Jul 2016 08:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.077 X-Spam-Level: X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=XKIcDmfW; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=4i61xIV1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd-XJNf1HKD9 for ; Sat, 16 Jul 2016 08:29:48 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A368E127077 for ; Sat, 16 Jul 2016 08:29:48 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.227.85.212]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u6GFTKEl009680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Jul 2016 08:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1468682973; x=1468769373; bh=Sc0gMkoWA3xmOogtQsfr4NBavQo4PcQyCBxnVj48tq0=; h=Date:To:From:Subject:Cc; b=XKIcDmfWrjIugjE5/X2MwGWIMj6PINF32ciMQxasl6LSmB51f4imxfRXJ3t5gC+4g maTaUA/dd+d787N0qwEAnoh+fJOboGjnpVJdMe62jc6LYbqQE9Yy4meip4sIs09CWg /M0HqtabdDtrDucWUgt3wdbu5fOPVITCNv0+NT0k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1468682973; x=1468769373; i=@elandsys.com; bh=Sc0gMkoWA3xmOogtQsfr4NBavQo4PcQyCBxnVj48tq0=; h=Date:To:From:Subject:Cc; b=4i61xIV1cez9CCHRPxDgX+60DVTks2nSsFSfvZjE97GFz1uzj5hJdPPUst3i+ahE+ TBx9VRKcJU/0v7+CWvGwHwSAxqroZNl8foCHCRcChB2OW+PgKkETOc5Speurn5yfFa NkhOtYWaNZt020dqbzl101vPnmUlKsVV0qk5bUnQ= Message-Id: <6.2.5.6.2.20160716034140.0a180b60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 16 Jul 2016 08:28:45 -0700 To: Niels ten Oever , Corinne Cath From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: architecture-discuss@ietf.org Subject: [arch-d] Value system in the achitecture X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 15:29:49 -0000 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 nobody Sun Jul 17 00:33:23 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB76712D19F for ; Sun, 17 Jul 2016 00:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0vrxbndsK3c for ; Sun, 17 Jul 2016 00:33:19 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7249912D18E for ; Sun, 17 Jul 2016 00:33:18 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 5560FF394C; Sun, 17 Jul 2016 07:33:17 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 34072226E18; Sun, 17 Jul 2016 07:33:17 +0000 (UTC) Received: from [192.168.11.174] (pD9EA9FE5.dip0.t-ipconnect.de [217.234.159.229]) by mail.article19.io (Postfix) with ESMTPSA id DE133226E0B; Sun, 17 Jul 2016 07:33:16 +0000 (UTC) To: S Moonesamy , Corinne Cath References: <6.2.5.6.2.20160716034140.0a180b60@elandnews.com> From: Niels ten Oever X-Enigmail-Draft-Status: N1110 Message-ID: <9ac33307-4c1d-4d95-a79a-4392f5fc0268@article19.org> Date: Sun, 17 Jul 2016 09:33:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20160716034140.0a180b60@elandnews.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="F36MsTJrlq7q1aid9aqKV41AVSb10hdne" Archived-At: Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] Value system in the achitecture X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 07:33:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F36MsTJrlq7q1aid9aqKV41AVSb10hdne Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: > Hi Niels, Cath, >=20 > I read the following in your document: >=20 >> 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. >=20 > Another question is whether a particular value system is part of the > internet's architecture. =20 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.=20 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. >=20 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 >=20 > Regards, > S. Moonesamy --F36MsTJrlq7q1aid9aqKV41AVSb10hdne Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXizS7AAoJEAi1oPJjbWjpwA4H/A3OGJdmy5H7uOmKdRpQZB+n 8d4iw/0N0gwej0pE3e0iPvpQ7Nwx8rsN/vpIMJNFsgYHdTJx5XR/ku+8OIDQDfYl a1IFOsOpzApswKQuXXkommZuF749kxGctWXvRG9ZP9D0fU9sw3Q2tLHF8oHDLY5i VIqOdkYL23GHRmIhOUJfHIabParcUIUKcwFDuKsT+a0jn8r4/3C8fIhdaHjN9vC6 ZI2vGOiOKWdiML0EOOIRl45kBfZJcs4A1vZfEl2IaxxWMM0qnFoPSRqjPe9cYWgt BGVtJiMi2XPzqFYhfORVul2mVnAh4yw+UHjuclD+XqcMfInV1OttCW9SpnSPX/M= =W92T -----END PGP SIGNATURE----- --F36MsTJrlq7q1aid9aqKV41AVSb10hdne-- From nobody Sun Jul 17 02:19:06 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEA312D507 for ; Sun, 17 Jul 2016 02:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opendkim.org header.b=s6+8Tdjc; dkim=pass (1024-bit key) header.d=elandsys.com header.b=qNby2e3M Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-O4gXDqkV6I for ; Sun, 17 Jul 2016 02:19:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E13812B01B for ; Sun, 17 Jul 2016 02:19:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.227.85.212]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u6H9Iex6023335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jul 2016 02:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1468747135; x=1468833535; bh=bl2p63rwAHbqOuaphlmZr1uHW/LygNmL3HzWIWDBL/o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=s6+8TdjcNcCh8TBYxhiKk/K5A/wsN+KEkSmQ7pU3wyPNyJxloukYMTFRKBlGZqp9h mejZbvv9jRcqyjs03Y2hTryFLC/2ZD4mjONlrNxaS4vO9cB11UzKU1Lj5TjV8NC873 AkimZgJeM3rPhcp7+e6qFHi62nYTyMIRUzYb4ScQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1468747135; x=1468833535; i=@elandsys.com; bh=bl2p63rwAHbqOuaphlmZr1uHW/LygNmL3HzWIWDBL/o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qNby2e3MW2vPFjqKpxaWc5ixk8A/4+I4azUhMWyE4FaxCK5GOhdbN/GBXgZXGtN13 zazavHzVEH/olUwptKav5HAhZT3PHdfIzRcV+eusAhOORHBvnDAP8WBkFrzkdwTbQ8 0jo0n+SlTAikhAI1O0Xmypi7POuxjbzMifWl71Ww= Message-Id: <6.2.5.6.2.20160717021611.0ccb14e0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 17 Jul 2016 02:17:28 -0700 To: Niels ten Oever From: S Moonesamy In-Reply-To: <9ac33307-4c1d-4d95-a79a-4392f5fc0268@article19.org> References: <6.2.5.6.2.20160716034140.0a180b60@elandnews.com> <9ac33307-4c1d-4d95-a79a-4392f5fc0268@article19.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] Value system in the achitecture X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 09:19:04 -0000 Hi Niels, At 00:33 17-07-2016, Niels ten Oever wrote: >I suspect that you are referring to: > >https://tools.ietf.org/html/draft-tenoever-hrpc-research-03 Yes. I'll follow up on (IRTF) HRPC. Regards, S. Moonesamy From nobody Sun Jul 17 03:37:35 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C5E12D590 for ; Sun, 17 Jul 2016 03:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nh3qDkhgB3X for ; Sun, 17 Jul 2016 03:37:31 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C76012D58A for ; Sun, 17 Jul 2016 03:37:31 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-11v.sys.comcast.net with SMTP id OjRyb3dmWlSxsOjRybS9Qi; Sun, 17 Jul 2016 10:37:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1468751850; bh=SLTRKgBsvDunSCNIQk11LCNC2rH7LCvGrLiXJ3tEfUg=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=VIS9pfGPMHsK8PtFnFssO7KVrj/1amfIS4D9As6PMvps8bW1Xu6KX1Z27wsar747/ 3CfnfEi2c4qEU5IWgNnFqpBAw5sY7KjSys5JdXB2Smb6bxB7Zr09S0n/5vWmicKMrD FACOedPWfhFbUTEMUIiT9TZkhP5tjOxE7wggRKF8bGn1qJuaaSiO7aioU/pwDJEWto /uj6OGexvnGYLEVww+V9xHKrZ/TwqZwXAe67dwxentua9ZWDvhHD8ZgmRyWVYjyyyM LiBfLFJntdiWJ7SuMwP3KfBQEjqHuFU44RZZvc7AB7aoLWMeGXVwhbRqtbOEiRkQWR koprRQ8Ek2OaQ== Received: from [10.0.1.38] ([50.187.231.125]) by comcast with SMTP id OjRwbgSPEX5ezOjRwbZvJI; Sun, 17 Jul 2016 10:37:30 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Day In-Reply-To: <9ac33307-4c1d-4d95-a79a-4392f5fc0268@article19.org> Date: Sun, 17 Jul 2016 06:37:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20160716034140.0a180b60@elandnews.com> <9ac33307-4c1d-4d95-a79a-4392f5fc0268@article19.org> To: Niels ten Oever X-Mailer: Apple Mail (2.3124) X-CMAE-Envelope: MS4wfKtgRGgbSNoN3RzPOWOu5eRmJ375o3wAIM4dTXA1R0JT9zN5Ct4VdRIZ6RjzoHiakuQZ588aR8vupI7uQ8lsOtptsZ5pnT44nWXNU9Xq8n0SWaGMU04S DpVDBmKExDPFCxZmQ5cPcMonnwCUCrSD4/HNxC6cS5svgV8gSDy9Avvvrt/LOlQBYD39FvVvZ54lknvz63UDtRGgf/XowmqqKqypQssk1tREMZmJUcXml6Wg g7x7FIybG/gQ6yxGCfHl1JiX79NzycuNr6Fw/OajNds= Archived-At: Cc: Corinne Cath , S Moonesamy , architecture-discuss@ietf.org Subject: Re: [arch-d] Value system in the achitecture X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 10:37:33 -0000 =46rom 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: =93the set of rules that define a = style of construction.=94 It is important to distinguish an = architecture from =93buildings=94 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 =93beads-on-a-string=94 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 =93beads-on-a-string=94 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 = wrote: >=20 > Dear S. Moonesamy, >=20 > I suspect that you are referring to: >=20 > https://tools.ietf.org/html/draft-tenoever-hrpc-research-03 >=20 > 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 >=20 > because the document is an active document of that research grouo. >=20 > But allow me to reply inline: >=20 > On 07/16/2016 05:28 PM, S Moonesamy wrote: >> Hi Niels, Cath, >>=20 >> I read the following in your document: >>=20 >>> 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. >>=20 >> Another question is whether a particular value system is part of the >> internet's architecture. =20 >=20 > That is exactly the question of the draft. >=20 >> Once a value system is embedded in the >> architecture it is difficult to remove it or not use it.=20 >=20 > 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 >=20 >> 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. >>=20 >=20 > One can use different implementations of DNS: > https://yeti-dns.org/ > http://dns.dot-bit.org/ >=20 >> 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? >=20 > The word 'ideology' is mentioned in the draft at all. >=20 > 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 >=20 > Happy to discuss. >=20 > Best, >=20 > Niels >>=20 >> Regards, >> S. Moonesamy >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Sun Jul 17 03:42:04 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95DC12D56E for ; Sun, 17 Jul 2016 03:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1QESdc6pagf for ; Sun, 17 Jul 2016 03:42:00 -0700 (PDT) Received: from mail.article19.io (vps784.greenhost.nl [213.108.108.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A486D12D552 for ; Sun, 17 Jul 2016 03:41:59 -0700 (PDT) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 5CDE8F394C; Sun, 17 Jul 2016 10:41:58 +0000 (UTC) Received: from mail.article19.io (localhost [127.0.0.1]) by mail.article19.io (Postfix) with ESMTPS id 3EA5D226E19; Sun, 17 Jul 2016 10:41:58 +0000 (UTC) Received: from [192.168.11.174] (pD9EA9FE5.dip0.t-ipconnect.de [217.234.159.229]) by mail.article19.io (Postfix) with ESMTPSA id 07AE3226E18; Sun, 17 Jul 2016 10:41:57 +0000 (UTC) To: John Day References: <6.2.5.6.2.20160716034140.0a180b60@elandnews.com> <9ac33307-4c1d-4d95-a79a-4392f5fc0268@article19.org> From: Niels ten Oever Message-ID: <64b0b8dd-0294-2eec-f255-99c6dd7b56c1@article19.org> Date: Sun, 17 Jul 2016 12:41:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oRN2Qmu85A32c8uF5bcI7A5nRwS29w4tC" Archived-At: Cc: Corinne Cath , S Moonesamy , architecture-discuss@ietf.org Subject: Re: [arch-d] Value system in the achitecture X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 10:42:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oRN2Qmu85A32c8uF5bcI7A5nRwS29w4tC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07/17/2016 12:37 PM, John Day wrote: > 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 --oRN2Qmu85A32c8uF5bcI7A5nRwS29w4tC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXi2D0AAoJEAi1oPJjbWjpzMoH/jA2c5qVdns3Vx90bLvch6YW cOhfQTm8ENue/8i5ueFgr4ltqivoFqalDj8IczaGBYmUUwOjIwgLhGnRT7jYUthc rBGsWEaw8+xMMGVPJxB7XjuQuWyg0ydoefiislTj/NE65ul1knA0MohiQKo343e0 W8JZbPut0+1P7n4ystTmOzXsZ3lPE41SM/fJtx4Jx4g/Re9XHOcNGXNGI5Lzdz81 X6xJElaq8/X4dPxKL1Esdf4vMwTrd7TQBjH3lbrPVRi1GuhGblLoZN3NeeVoRnpY kOpI36xtoboO/tFHq/RHLgXp8oVEmmue4uNzDklMR03309noB7JmDLLx/GqTIbg= =Ca9R -----END PGP SIGNATURE----- --oRN2Qmu85A32c8uF5bcI7A5nRwS29w4tC-- From nobody Sun Jul 17 08:36:42 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A558E12B068 for ; Sun, 17 Jul 2016 08:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.077 X-Spam-Level: X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=kPbdkqQU; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=uUZBV+u3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1LUx3cv9WMq for ; Sun, 17 Jul 2016 08:36:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7525612B010 for ; Sun, 17 Jul 2016 08:36:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.227.85.212]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u6HFa4G6010531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jul 2016 08:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1468769782; x=1468856182; bh=/oIDUXW7cq9qWMcfpyPwhsKHh8EHDa9hU64UYvrsN4I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kPbdkqQUD8sWmdffgYqiYBYgp6wNmPopAImkI3gN3kj5VKLwMERuRvn3brvz3ed3J Xf9GduhflGqvYgh7mUBt0Z17xYpIR4uE5yZ4WNuFNgkkvzmOBKNfRZsMQQ3lSfxb4E oHNYD/46RaLBFFRoo6zkiY2YLMpSIj3kgq2OKY5M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1468769782; x=1468856182; i=@elandsys.com; bh=/oIDUXW7cq9qWMcfpyPwhsKHh8EHDa9hU64UYvrsN4I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uUZBV+u35oBoHBEPp/pvvLOyENTiXY79LXHUHQEX2Q3AOZaRkb1wVuzD5F9/noonQ tbUXE83vdAEVhIsIIKQ1kVyWZLPQvdTTxoS8essb2fukWVv1CeCcoq2rMFMDhzVnDG 3iIzfgEvrUi/qMDKYOisFifW4frh2ow8AD+2Os14= Message-Id: <6.2.5.6.2.20160717074250.0c2c1108@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 17 Jul 2016 08:33:09 -0700 To: John Day From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20160716034140.0a180b60@elandnews.com> <9ac33307-4c1d-4d95-a79a-4392f5fc0268@article19.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: Corinne Cath , Niels ten Oever , architecture-discuss@ietf.org Subject: Re: [arch-d] Value system in the achitecture X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 15:36:41 -0000 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 nobody Sun Jul 17 11:50:59 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439C312D0E2 for ; Sun, 17 Jul 2016 11:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfr-N-xijM4a for ; Sun, 17 Jul 2016 11:50:55 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A10E12D0C2 for ; Sun, 17 Jul 2016 11:50:55 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-12v.sys.comcast.net with SMTP id Or8MbnNMdxBKTOr9SbR0FU; Sun, 17 Jul 2016 18:50:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1468781454; bh=NWWHsNyHAzCngIrmMDUNYhg0EmwW5LMCk9NupsSMppA=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=fA0pWJjt7RxmSuQeUH3VEw7FBecOZNg7A0fuisfKKKcBxKrRi63Bib1OiUqSDdYgf Zfu3S/5Hl4+EP82bU3EF87jx2PtYaL0ribRo5E56Gl+TUdT6R8eoGCBQvMk7SIBD2L V9Q75q9GzAYmMlcQSibgC/bLlNf/i0RHOngMeqx+YWm70ZUP1QOZdBHOEbPraCMzOs ulzapqxiUwnF0/V2RMJbEM52Au70Fuj/RS9my/NKjhvJZzWSRX9eKxI+5C5YXJWxVI e6WEBtK/M58wVjuOeKM4SMMfP3EKHNINtsqBcobzaahf8VGwtVUMpJY/C1lKCVaxbw 6hNnB3daiN0hQ== Received: from [10.0.1.38] ([50.187.231.125]) by comcast with SMTP id Or9QbKvNGOEhWOr9QbIdH3; Sun, 17 Jul 2016 18:50:54 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_030394F8-02DB-443F-8295-F49425AA204C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Day In-Reply-To: <6.2.5.6.2.20160717074250.0c2c1108@elandnews.com> Date: Sun, 17 Jul 2016 14:51:02 -0400 Message-Id: <56F732AE-12EA-460B-AF02-D4AF72031EED@comcast.net> References: <6.2.5.6.2.20160716034140.0a180b60@elandnews.com> <9ac33307-4c1d-4d95-a79a-4392f5fc0268@article19.org> <6.2.5.6.2.20160717074250.0c2c1108@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.3124) X-CMAE-Envelope: MS4wfLUi2dgIZTUfDukGzqLjcZvEx1y8r6SqwpKdEVK+1plGCVwtfNWXl1qE+ZrkeOhoeiI3gN+o24PIH72GfTdOqi2y0Zd51AVjbkktwaB85H7RD7GXdSC4 MYlDcUOPSfzsO786gfhkc1Q9yZ+y1PLDL1jUx6ecvLRupRBkcf5vfjlRMT4U+oOD+Fq/2vTtwecEzkRp8iN/+Auo5cNWvcpLw8N3SsTKrCx9pBRfws5k96sR gbLssWsrYJJIStXQyu7OvkRBSxLxQUh88RfqFYU/RA8= Archived-At: Cc: Corinne Cath , Niels ten Oever , architecture-discuss@ietf.org Subject: Re: [arch-d] Value system in the achitecture X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 18:50:58 -0000 --Apple-Mail=_030394F8-02DB-443F-8295-F49425AA204C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99s 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.=20 Take care, John > On Jul 17, 2016, at 11:33, S Moonesamy wrote: >=20 > Hi John, >=20 > Thanks for the explanation. >=20 > At 03:37 17-07-2016, John Day wrote: >> =46rom these two notes, it would appear that they are not about = architecture, but about a construction in an architecture. >>=20 >> 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. >>=20 >> 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.) ;-) >=20 > 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". >=20 > The existence of a unique public name space is required. =46rom the = above (see quoted text), I understand that it would be part of the = construction. >=20 > Regards, > S. Moonesamy =20 --Apple-Mail=_030394F8-02DB-443F-8295-F49425AA204C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99s 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 <sm+ietf@elandsys.com> wrote:

Hi = John,

Thanks for the explanation.

At 03:37 17-07-2016, John Day wrote:
=46rom 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.  =46rom the above (see quoted = text), I understand that it would be part of the construction.

Regards,
S. Moonesamy  

= --Apple-Mail=_030394F8-02DB-443F-8295-F49425AA204C--