Number of Pages: 391

Number of Tables and Figures: 450

Report Overview:

The term =93Wirel= ess Network Infrastructure=94 has conventionally been associated with macro= cell Radio Access Network (RAN) and mobile core network infrastructure, whi= ch SNS Research estimates to account for nearly $52 Billion in spending by = the end of 2014.

However, the scop= e of the term is expanding as wireless carriers increase their investments = in Heterogeneous Network or HetNet infrastructure encompassing WiFi, = small cells, Distributed Antenna Systems (DAS), Remote Radio Heads (RRH) an= d the emerging Cloud RAN concept. Driven by the promise of added capacity a= nd coverage with minimum investment in additional spectrum, HetNet infrastr= ucture is expected to account for nearly $17 Billion in spending by the end= of 2014.

While macrocell R= AN spending is forecast to decline at a CAGR of 3% over the next 6 years, S= NS Research estimates that the overall wireless network infrastructure mark= et encompassing macrocell RAN, HetNet, mobile core and backhaul infrastruct= ure will witness tremendous growth over the coming years. Growing at a CAGR= of over 5%, the market will account for over $104 Billion in annual spendi= ng by the end of 2020.

Complimenting thi= s growth would be over $1 Billion worth of annual R&D investments on 5G= mobile technology by wireless carriers, vendors and vertical market player= s alike, in a bid to further enhance the capacity, speed and performance of= future mobile networks.

The =93Wireless N= etwork Infrastructure Bible: 2014 =96 2020 - Macrocell RAN, Small Cells, RR= H, DAS, Cloud RAN, Carrier WiFi, Mobile Core & Backhaul=94 report prese= nts an in-depth assessment of 9 individual submarkets of the wireless netwo= rk infrastructure opportunity. Besides analyzing the key market drivers, ch= allenges, operator revenue potential, regional CapEx commitments, expert in= terviews and vendor strategies, the report also presents revenue and unit s= hipment forecasts for the market from 2014 to 2020 at a regional as well as= a global scale. Historical figures are also provided for 2010, 2011 and 20= 13.

The report comes = with an associated Excel datasheet suite covering quantitative data from ov= er 400 numeric forecasts presented in the report.

Key Finding= s:

The report has th= e following key findings:

Between 2014= and 2020, the 2G, 3G & 4G wireless network infrastructure market is ex= pected to grow at a CAGR of nearly 5%
Vendors are = increasing their focus on profit margins. Many are already cutting staff, e= mbracing operational excellence, evolving their new business models, acquir= ing niche businesses and expanding their managed services offerings<= /SPAN>
New CapEx co= mmitment avenues such as HetNet infrastructure and virtualization will ushe= r industry restructuring. The wireless network infrastructure market will c= onsolidate so as to eliminate one of the current global players by 2020

As wireless = carriers look to offload traffic from their overburdened macrocell infrastr= ucture, HetNet infrastructure will represent a market worth $43 Billion in = 2020

Operators wi= ll ramp up on backhaul, aggregation, transport, routing based on IP and Eth= ernet technologies for offering mobile broadband services

Developing m= arket growth will be a significant factor during the forecast period, with = China and India seeing some of the highest levels of growth, both in terms = of shipments and in the size of their installed base. After 2014, developin= g countries and their requirements will begin to shape future infrastructur= e technologies and architectures

Due to the i= nvestments in a single RAN technology, future LTE investments will cost muc= h less than early investments of the technology

Supplemented= with a drive towards virtualization, a limited amount of hardware installa= tion will be needed when wireless carriers upgrade to LTE in the future

From 2016 on= wards wireless carriers and vendors will spend at least $1 Billion per annu= m in R&D spending to drive standardization and commercialization of 5G = technology

Voice over L= TE (VoLTE) subscriptions will surpass 700 Million by 2020

Topics Cove= red:

The report covers= the following topics:

Up-to-date c= overage of market dynamics allowing wireless network infrastructure vendors= to analyze the opportunities and challenges of selling to wireless carrier= s in different regional markets
Analysis of = demand and supply of wireless infrastructure and the strategies of the key = vendors. Research includes quantitative and qualitative market assessments = as well as the forecasts of market trends, technology requirements and depl= oyment strategies
Market analy= sis and forecasts for 9 individual submarkets and their subcategories: macr= ocell Radio Access Network (RAN), mobile core, macrocell backhaul, Remote R= adio Heads (RRH), Distributed Antenna Systems (DAS), small cell RAN, cloud = RAN, small cell backhaul and carrier WiFi
Exclusive in= terview transcripts from 2 of the largest wireless network infrastructure v= endors; Ericsson and NSN
Mobile netwo= rk CapEx commitments per region
Mobile netwo= rk subscriptions, traffic projections and service revenue by technology and= region
An assessmen= t of 5G technology, initiatives and R&D commitments

Historical Rev= enue & Forecast Segmentation:

Market forecasts = and historical revenue/unit shipment figures are provided for each of the f= ollowing submarkets and their subcategories:

Submarkets

Macrocell RA= N

Small Cell R= AN

Remote Radio= Heads (RRH)

Distributed = Antenna Systems (DAS)

Cloud RAN

Carrier WiFi=

Mobile Core<= /FONT>

Macrocell Ba= ckhaul

Small Cell B= ackhaul
The following regional and technology markets are a= lso covered:

Regional Mar= kets

Asia Pacific=

Eastern Euro= pe

Latin & = Central America

Middle East = & Africa

North Americ= a

Western Euro= pe

Technology M= arkets

GSM

CDMA/CDMA200= 0/EV-DO

W-CDMA/HSPA<= /FONT>

LTE FDD

TD-LTE

WiMAX=

WiFi<= /SPAN>

Key Questio= ns Answered:

=

The report provid= es answers to the following key questions:

What are the key market drivers and challenges for SDN, NFV= and the wider network virtualization ecosystem=3F

How is the 2G, 3G & 4G wireless infrastructure market e= volving by segment and region=3F What will the market size be in 2020 and a= t what rate will it grow=3F

What trends, challenges and barriers are influencing its gr= owth=3F

How will the market shape for small cell infrastructure and= other HetNet deployments such as DAS and cloud RAN=3F

How will WiFi fit into future mobile network architectures = for access and offload=3F

Who are the key vendors in the market, what is their market= share and what are their strategies=3F

What strategies should be adopted by wireless carriers and = infrastructure vendors to remain a dominant market force=3F
Which 2G, 3G & 4G technology constitutes the highest am= ount of spending and how will this evolve overtime=3F

How will LTE deployments proceed, and how long will GSM, HS= PA and CDMA technologies co-exist with LTE=3F

When will WiMAX infrastructure spending diminish=3F<= /SPAN>

What is the global and regional outlook for each individual= sub-market including macrocell RAN, small cells, RRH, DAS, cloud RAN, carr= ier WiFi, mobile core, macrocell backhaul and small cell backhaul=3F=

What is the opportunity for the mobile backhaul market, and= what new backhaul solutions are evolving=3F

Do emerging virtualization technologies such as Network Fun= ctions Virtualization (NFV) pose a threat to traditional wireless infrastru= cture vendors=3F

How much will vendors and operators invest in 5G R&D=3F=

How low is the Total Cost of Ownership (TCO) of a HetNet de= ployment in comparison to a homogeneous macrocell only RAN network=3F

Report Pricing:

Single User License: USD 2,500

Company Wide License: USD 3,500

Ordering Process:

Please contact Emily Hall a= t e.hall@snsreports.com

And provide the following information:
= Report Title:
Report License (Single User/Company Wide):
Name:
Ema= il:
Job Title:
Company:
Invoice Address:

Please contact me if you have any que= stions, or wish to purchase a copy.

I look forward to hearing from you.=

Kind Regards,

Emily Hall

Sales Director

Signals and Systems Telecom

<= FONT face=3D"Verdana, Arial, Helvetica, sans-serif">Email: e.hall@snsre= ports.com

<= FONT face=3D"Verdana, Arial, Helvetica, sans-serif">Address: Reef Tower
= Jumeirah Lake Towers
Sheikh Zayed Road
Dubai, UAE

www.snstelecom.com=

To unsubscribe please click on = the link below or send an email with unsubscribe in the subject line to: unsubcribe@snsreports.com

Remove
From miriam.ortseifen@bundesbank.de Tue Dec 17 06:38:40 2013 Return-Path: X-Original-To: urn-nid@ietfa.amsl.com Delivered-To: urn-nid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CC11AE182; Tue, 17 Dec 2013 06:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 nmnrVnhZ5NxL; Tue, 17 Dec 2013 06:38:37 -0800 (PST) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4BF1AE17A; Tue, 17 Dec 2013 06:38:36 -0800 (PST) Received: from [85.158.143.35:50151] by server-1.bemta-4.messagelabs.com id 96/28-02132-BE160B25; Tue, 17 Dec 2013 14:38:35 +0000 X-Env-Sender: miriam.ortseifen@bundesbank.de X-Msg-Ref: server-4.tower-21.messagelabs.com!1387291114!6454655!1 X-Originating-IP: [217.110.59.174] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10180 invoked from network); 17 Dec 2013 14:38:34 -0000 Received: from unknown (HELO s504pmgwz2.bundesbank.de) (217.110.59.174) by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Dec 2013 14:38:34 -0000 Received: from m504evgw01p.in.bundesbank.de (lb-extranet-inc2 [192.168.168.12]) by s504pmgwz2.bundesbank.de (Merkur) with ESMTP id 8902EA4C1; Tue, 17 Dec 2013 15:38:34 +0100 (MET) Subject: Re: Gen-ART review of draft-bundesbank-eurosystem-namespace-02 From: iso20022@bundesbank.de X-Priority: 3 (Normal) Importance: Normal X-KeepSent: 96C0304D:84369D1C-C1257C44:0048EA75; type=4; name=$KeepSent To: david.black@emc.com X-Mailer: Lotus Notes Release 8.5.3FP4 SHF39 May 13, 2013 Message-ID: Sender: miriam.ortseifen@bundesbank.de Date: Tue, 17 Dec 2013 15:38:33 +0100 X-MIMETrack: Serialize by Router on NT999SP23/SRV/BBK/DE(Release 8.5.2FP3|July 10, 2011) at 17.12.2013 15:38:34 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Cc: urn-nid@ietf.org, gen-art@ietf.org, ietf@ietf.org, iso20022@bundesbank.de X-BeenThere: urn-nid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: discussion of new namespace identifiers for URNs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 14:38:40 -0000 David, thanks for the Gen-ART review [1] you have performed on our draft, and = our apologies for the delay in responding to it. We have been surprised by your concerns regarding the application for a= Formal URN Namespace, which we'd have expected being raised by someone during the two stages of URN-NID Expert Review the draft has undergone since August 2013. Apparently, the URN experts active on the urn-nid list did not share your concerns. The (prospective) 'eurosystem' URN Namespace is modeled after the very similar 'swift' Formal URN namespace registered per RFC 3615, and there= have been allocated quite a couple of other Formal URN Namespaces to national institutions and international treaty organizations, which see= m to have similar usage profiles; we are not aware of similar arguments havi= ng been raised against the allocation of these Formal URN Namespaces. 'eurosystem' URNs will be used together with already standardized URNs,= in particular ISO Std 20022 URNs; it is important for their use that the r= ole of these URNs and the authority behind these URNs be easily and clearly= identified, and be at a perceived "equivalent" standards level -- paral= lel to the 'swift' URNs that are managed by an older international treaty organization with similar purpose but smaller scope and less consumer friendly targets (regarding timeliness of transaction execution and cos= t effectiveness). Therefore, an Informal URN Namespace would not meet the= target objectives of the supporting countries and financial institution= s. Admittedly, it is true that, at the first stage of usage of the 'eurosystem' namespace, the mass production use of the assigned URNs wi= ll be contained in messages carried in cryptographic digital envelopes or Vitual Private Networks. However, the transparency requirements (neede= d for establishing and maintaining public trust into the subject financia= l transaction systems), open software development processes, and software= deployment require the origin and authority for the URNs to be easily identified, and the URNs to be resolved on the public Internet. Therefore we claim that a Formal URN Namespace is warranted for the intended purpose. We will confer with the sponsoring AD on possible amendments to the Community Considerations in our draft. (Based on previous feedback, thi= s section has been kept relatively short and concise.) Kind regards, Miriam [1] http://www.IETF.ORG/mail-archive/web/ietf/current/msg84600.html -- Diese E-Mail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-M= ail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugt= e Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet.= Wir haben alle verkehrs=FCblichen Ma=DFnahmen unternommen, um das Risik= o der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoc= h raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anh=E4nge an die= ser Nachricht durchzuf=FChren. Wir schlie=DFen au=DFer f=FCr den Fall von V= orsatz oder grober Fahrl=E4ssigkeit die Haftung f=FCr jeglichen Verlust oder Sch=E4= den durch virenbefallene Software oder E-Mails aus. Jede von der Bank versendete E-Mail ist sorgf=E4ltig erstellt worden, d= ennoch schlie=DFen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu e= iner irgendwie gearteten Verpflichtung zu Lasten der Bank ausgelegt werden. ______________________________________________________________________ This e-mail may contain confidential and/or privileged information. If = you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in th= is e-mail or of parts hereof is strictly forbidden. We have taken precautions to minimize the risk of transmitting software= viruses but nevertheless advise you to carry out your own virus checks = on any attachment of this message. We accept no liability for loss or dama= ge caused by software viruses except in case of gross negligence or willfu= l behaviour. Any e-mail messages from the Bank are sent in good faith, but shall not= be binding or construed as constituting any kind of obligation on the part= of the Bank.= From david.black@emc.com Tue Dec 17 07:06:40 2013 Return-Path: X-Original-To: urn-nid@ietfa.amsl.com Delivered-To: urn-nid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893951AE184; Tue, 17 Dec 2013 07:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham 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 wKf_-_19NDSZ; Tue, 17 Dec 2013 07:06:37 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 64EE01ADF5E; Tue, 17 Dec 2013 07:06:37 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBHF6PPv028212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Dec 2013 10:06:28 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com rBHF6PPv028212 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1387292789; bh=IjtC2zQuywURpB6Tj35U+AArfmg=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=tYcpli5hMxLiF0hU3AA+184EA/ewFlY1q+HsZx9ODW0nTtoZZhiAgtK3E8GNwh/07 Fevo6kloRjRShrNMGQoKln0nNKtQBZ4ayPywkWy5OAOYw4RJTu5UStStbKh41V7mxg YnoUsavONzGgmVAGfcNLns4Mng5LJFeJhLxcpego= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com rBHF6PPv028212 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor); Tue, 17 Dec 2013 10:06:22 -0500 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBHF6Mnl001460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Dec 2013 10:06:22 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Tue, 17 Dec 2013 10:06:21 -0500 From: "Black, David" To: "iso20022@bundesbank.de" Date: Tue, 17 Dec 2013 10:06:21 -0500 Subject: RE: Gen-ART review of draft-bundesbank-eurosystem-namespace-02 Thread-Topic: Gen-ART review of draft-bundesbank-eurosystem-namespace-02 Thread-Index: Ac77Na4/gSUGsHhLT628HUL+yunqIAAAFEkw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ECD3977@MX15A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: DLM_1, public Cc: "urn-nid@ietf.org" , "gen-art@ietf.org" , "ietf@ietf.org" , "Black, David" X-BeenThere: urn-nid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: discussion of new namespace identifiers for URNs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 15:06:40 -0000 Miriam, > We have been surprised by your concerns regarding the application for a > Formal URN Namespace, which we'd have expected being raised by someone > during the two stages of URN-NID Expert Review the draft has undergone > since August 2013. Apparently, the URN experts > active on the urn-nid list did not share your concerns. IETF operates a multi-round review process that encourages reviews of drafts by people beyond the experts in the specific technology. This review is an expected part of that process; I suggest that you consult with your sponsoring AD (Barry) on any process concerns. > The (prospective) 'eurosystem' URN Namespace is modeled after the very > similar 'swift' Formal URN namespace registered per RFC 3615, and there > have been allocated quite a couple of other Formal URN Namespaces to > national institutions and international treaty organizations, which seem = to > have similar usage profiles; we are not aware of similar arguments having > been raised against the allocation of these Formal URN Namespaces. For clarity, I am not opposed to the allocation of the namespace. However, I would like to see a Community Considerations section that is actually responsive to RFC 3406's stated requirement. [... snip ...] > We will confer with the sponsoring AD on possible amendments to the > Community Considerations in our draft. (Based on previous feedback, this > section has been kept relatively short and concise.) Much of the contents of your response would be useful explanatory text to add to the draft. Thanks, --David > -----Original Message----- > From: miriam.ortseifen@bundesbank.de [mailto:miriam.ortseifen@bundesbank.= de] > On Behalf Of iso20022@bundesbank.de > Sent: Tuesday, December 17, 2013 9:39 AM > To: Black, David > Cc: gen-art@ietf.org; ietf@ietf.org; urn-nid@ietf.org; iso20022@bundesban= k.de > Subject: Re: Gen-ART review of draft-bundesbank-eurosystem-namespace-02 >=20 >=20 > David, >=20 > thanks for the Gen-ART review [1] you have performed on our draft, and ou= r > apologies for the delay in responding to it. >=20 > We have been surprised by your concerns regarding the application for a > Formal URN Namespace, which we'd have expected being raised by someone > during the two stages of URN-NID Expert Review the draft has undergone > since August 2013. Apparently, the URN experts > active on the urn-nid list did not share your concerns. >=20 > The (prospective) 'eurosystem' URN Namespace is modeled after the very > similar 'swift' Formal URN namespace registered per RFC 3615, and there > have been allocated quite a couple of other Formal URN Namespaces to > national institutions and international treaty organizations, which seem = to > have similar usage profiles; we are not aware of similar arguments having > been raised against the allocation of these Formal URN Namespaces. >=20 > 'eurosystem' URNs will be used together with already standardized URNs, i= n > particular ISO Std 20022 URNs; it is important for their use that the rol= e > of these URNs and the authority behind these URNs be easily and clearly > identified, and be at a perceived "equivalent" standards level -- paralle= l > to the 'swift' URNs that are managed by an older international treaty > organization with similar purpose but smaller scope and less consumer > friendly targets (regarding timeliness of transaction execution and cost > effectiveness). Therefore, an Informal URN Namespace would not meet the > target objectives of the supporting countries and financial institutions. >=20 > Admittedly, it is true that, at the first stage of usage of the > 'eurosystem' namespace, the mass production use of the assigned URNs will > be contained in messages carried in cryptographic digital envelopes or > Vitual Private Networks. However, the transparency requirements (needed > for establishing and maintaining public trust into the subject financial > transaction systems), open software development processes, and software > deployment require the origin and authority for the URNs to be easily > identified, and the URNs to be resolved on the public Internet. > Therefore we claim that a Formal URN Namespace is warranted for the > intended purpose. >=20 > We will confer with the sponsoring AD on possible amendments to the > Community Considerations in our draft. (Based on previous feedback, this > section has been kept relatively short and concise.) >=20 > Kind regards, > Miriam >=20 >=20 > [1] > http://www.IETF.ORG/mail-archive/web/ietf/current/msg84600.html >=20 > -- > Diese E-Mail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mai= l > irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender un= d > vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. >=20 > Wir haben alle verkehrs=FCblichen Ma=DFnahmen unternommen, um das Risiko = der > Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch > raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anh=E4nge an diese= r > Nachricht durchzuf=FChren. Wir schlie=DFen au=DFer f=FCr den Fall von Vor= satz oder > grober Fahrl=E4ssigkeit die Haftung f=FCr jeglichen Verlust oder Sch=E4de= n durch > virenbefallene Software oder E-Mails aus. >=20 > Jede von der Bank versendete E-Mail ist sorgf=E4ltig erstellt worden, den= noch > schlie=DFen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu ein= er > irgendwie gearteten Verpflichtung zu Lasten der Bank ausgelegt werden. > ______________________________________________________________________ >=20 > This e-mail may contain confidential and/or privileged information. If yo= u > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail or of parts hereof is strictly forbidden. >=20 > We have taken precautions to minimize the risk of transmitting software > viruses but nevertheless advise you to carry out your own virus checks on > any attachment of this message. We accept no liability for loss or damage > caused by software viruses except in case of gross negligence or willful > behaviour. >=20 > Any e-mail messages from the Bank are sent in good faith, but shall not b= e > binding or construed as constituting any kind of obligation on the part o= f > the Bank. >=20 From jari.arkko@piuha.net Tue Dec 17 08:56:13 2013 Return-Path: X-Original-To: urn-nid@ietfa.amsl.com Delivered-To: urn-nid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDF61AE02D; Tue, 17 Dec 2013 08:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham 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 lljZ4gaqxm-B; Tue, 17 Dec 2013 08:56:12 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 33EBF1AE00E; Tue, 17 Dec 2013 08:56:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C9C6A2CCD0; Tue, 17 Dec 2013 18:56:10 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60EcebVtWvuR; Tue, 17 Dec 2013 18:56:10 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 85D492CC48; Tue, 17 Dec 2013 18:56:08 +0200 (EET) Subject: Re: [Gen-art] Gen-ART review of draft-bundesbank-eurosystem-namespace-02 Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) Content-Type: text/plain; charset=iso-8859-1 From: Jari Arkko X-Priority: 3 (Normal) In-Reply-To: Date: Tue, 17 Dec 2013 11:56:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <54DC3E00-C69C-4DB2-8F76-EAABBEEE39BE@piuha.net> References: To: iso20022@bundesbank.de, Barry Leiba , david.black@emc.com X-Mailer: Apple Mail (2.1510) Cc: urn-nid@ietf.org, gen-art@ietf.org, ietf@ietf.org X-BeenThere: urn-nid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: discussion of new namespace identifiers for URNs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 16:56:13 -0000 David: thank you for your review. I thought that > Admittedly, it is true that, at the first stage of usage of the > 'eurosystem' namespace, the mass production use of the assigned URNs = will > be contained in messages carried in cryptographic digital envelopes or > Vitual Private Networks. However, the transparency requirements = (needed > for establishing and maintaining public trust into the subject = financial > transaction systems), open software development processes, and = software > deployment require the origin and authority for the URNs to be easily > identified, and the URNs to be resolved on the public Internet. > Therefore we claim that a Formal URN Namespace is warranted for the > intended purpose. would be good material to add to the draft, it made the situation clear = at least for me. And I did think the community section was a bit short. Barry/Miriam, can you coordinate some suggested text before the IESG = approval telechat on Thursday? Jari From worley@shell01.TheWorld.com Tue Dec 17 19:06:08 2013 Return-Path: X-Original-To: urn-nid@ietfa.amsl.com Delivered-To: urn-nid@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182BF1AE04C for ; Tue, 17 Dec 2013 19:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=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 IQtMjbC7gGYa for ; Tue, 17 Dec 2013 19:06:06 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 584A21ADF47 for ; Tue, 17 Dec 2013 19:06:03 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id rBI358oM009845; Tue, 17 Dec 2013 22:05:10 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id rBI2xJ0L1004241; Tue, 17 Dec 2013 21:59:19 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id rBI2x6VK1002982; Tue, 17 Dec 2013 21:59:06 -0500 (EST) Date: Tue, 17 Dec 2013 21:59:06 -0500 (EST) Message-Id: <201312180259.rBI2x6VK1002982@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: iso20022@bundesbank.de In-reply-to: (iso20022@bundesbank.de) Subject: Re: Gen-ART review of draft-bundesbank-eurosystem-namespace-02 References: Cc: urn-nid@ietf.org, david.black@emc.com, iso20022@bundesbank.de, gen-art@ietf.org, ietf@ietf.org X-BeenThere: urn-nid@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: discussion of new namespace identifiers for URNs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 03:06:08 -0000 > From: iso20022@bundesbank.de > Date: Tue, 17 Dec 2013 15:38:33 +0100 > Cc: urn-nid@ietf.org, gen-art@ietf.org, ietf@ietf.org, iso20022@bundesbank.de > We have been surprised by your concerns regarding the application for a > Formal URN Namespace, which we'd have expected being raised by someone > during the two stages of URN-NID Expert Review the draft has undergone > since August 2013. Apparently, the URN experts > active on the urn-nid list did not share your concerns. I believe that you do not fully grasp the social dynamics -- the de-facto constitution -- of the IETF. In this instance, the "URN experts" perform one round of evaluation of the proposal, from their particular point of view. But the approval of the IETF as a whole for URN matters is not *delegated* to the URN experts; the IETF as a whole must independently achieve consensus that this is a desirable proposal. In regard to the objections raised regarding the proposed namespace, I will extract a portion of your message and then expand on it in a way that I think expresses your intention, but in a way that more directly addresses the objections: > Admittedly, it is true that, at the first stage of usage of the > 'eurosystem' namespace, the mass production use of the assigned URNs will > be contained in messages carried in cryptographic digital envelopes or > Vitual Private Networks. However, the transparency requirements (needed > for establishing and maintaining public trust into the subject financial > transaction systems), open software development processes, and software > deployment require the origin and authority for the URNs to be easily > identified, and the URNs to be resolved on the public Internet. What it seems to me that you are saying is that in the ordinary usage of these URNs, they will be confined to particular VPNs that are tightly associated with the Eurosystem. (Of course, the usage may be expanded in the future.) But even initially, there are expected to be situations where, at least for particular URNs and particular messages containing those URNs, it is necessary to be able to identify in much more public contexts that the URNs have particular defined (standardized) meanings. At least, this is the meaning I attribute to your use of "transparency": that various facts can be established *to outsiders*. And if it is true that the meanings of these URNs must be provable to outsiders, outsiders who at least partially operate on the global Internet, then this is a reason to establish a formal registration of the URN namespace. Dale

The Wireless= Network Infrastructure Bible: 2014 =96 2020 - Macrocell RAN, Small Cells, = RRH, DAS, Cloud RAN, Carrier WiFi, Mobile Core & Backhaul