idnits 2.17.1
draft-atarashi-xmlconf-architecture-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 28, 2002) is 7844 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
-- Possible downref: Non-RFC (?) normative reference: ref. '4'
Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group R. Atarashi
3 Internet-Draft Communications Research Laboratory
4 Expires: April 28, 2003 T. Shimojo
5 Nara Institute of Science and
6 Technology
7 Y. Atarashi
8 S. Miyake
9 M. Kitani
10 Hitachi, Ltd.,
11 F. Baker
12 Cisco Systems
13 M. Wasserman
14 Wind River
15 October 28, 2002
17 XML Configuration Architecture
18 draft-atarashi-xmlconf-architecture-00
20 Status of this Memo
22 This document is an Internet-Draft and is in full conformance with
23 all provisions of Section 10 of RFC2026.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF), its areas, and its working groups. Note that
27 other groups may also distribute working documents as Internet-
28 Drafts.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 The list of current Internet-Drafts can be accessed at http://
36 www.ietf.org/ietf/1id-abstracts.txt.
38 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html.
41 This Internet-Draft will expire on April 28, 2003.
43 Copyright Notice
45 Copyright (C) The Internet Society (2002). All Rights Reserved.
47 Abstract
49 For the new network configuration concept discussed at XMLCONF, we
50 mention the importance of building new network architecture. We can
51 not develop and discuss the concept using XML because it is only
52 tools but the concept is confusable. The consensus of architecture
53 is required to clarify the items and technologies that should be
54 discussed and standardized at IETF.
56 1. Introduction
58 For the new network configuration concept discussed at XMLCONF, we
59 mention the importance of building new network architecture. We can
60 not develop and discuss the concept using XML because it is only
61 tools but the concept is confusable. The consensus of architecture
62 is required to clarify the items and technologies that should be
63 discussed and standardized at IETF.
65 As such, we will make specific recommendations for all applications.
66 In doing so, we will use the language described in RFC 2119 [1]. The
67 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
69 document are to be interpreted as described in RFC 2119 [1].
71 2. Proposal
73 In the discussion for XML configuration at XMLCONF, a global
74 architecture SHOULD be developed to arrange the technology components
75 and make common image for configuration. Since XML is only tool, it
76 can not be defined concept and architecture. The configuration tool
77 using XML tag without consideration of architecture may be useful at
78 once, it will obsolete by new technology and standard.
80 It is useful for the network operator to configure network equipments
81 and to see MIB information and network configuration using XML. It
82 is important to discuss SOAP, MIB, security, and so on as tools for
83 configuration, but is difficult to share the whole image of
84 requirements. We need to review the global network architecture to
85 check and confirm the action item.
87 XML is only tools based on the concept of metadata and RDF, and have
88 many possibilities for network architecture. We are required to
89 understand the concept of XML related technologies and to discuss the
90 application of these technologies for standard. Since XML
91 technologies are originally defined for contents and applications, it
92 is also suitable for contents delivery network. We can describe the
93 network policy using XML. The Distributed Management Task Force,
94 inc. Distributed Management Task Force, inc. [2] (DMTF) discuss the
95 XML mapping tool of Common Information Model (CIM). We develop the
96 whole architecture by including existing concepts and technologies
97 related network configuration and management.
99 The global architecture including next generation internet
100 technologies such as IPv6 and QoS also involve the new network
101 architecture. The Migration strategy is required for the new
102 architecture. Since XML is developed for contents and application,
103 it has not been considered to apply to the network control. There
104 are not tools and implementations for network. It is required to
105 implement some technologies for network configuration such as tools,
106 APIs, and so on using XML.
108 3. Current Tools
110 This is the list for current tools and technologies that is available
111 for network configuration. See reference for details.
113 o Resource Description
115 * Resource Description Framework Resource Description Framework
116 [3]
118 * XML Scheme
120 * Metadata work
122 o Description of network devices of policies
124 * Distributed Management Task Force, inc. (DMTF), Common
125 Information Model (CIM)
127 o Topology
129 * Visual Design Tool (VISIO)
131 * Unified Modeling Language (UML) Unified Modeling Language [4]
133 o Configuration Protocol
135 * SOAP
137 o Security Protection
139 * ssh
141 * SSL
143 * IPsec
145 * XML Signature
147 4. Architecture
149 Figure 1 presents a proposed architecture for network configuration
150 using XML and related concepts and technologies.
152 +------------------------------------------------------------+
153 | XML +------+ +--------+ Data |
154 | Configuration |Visual|<------------->|XML | Model |
155 | System |Design| +--------+ |Database| and |
156 | |Tool | |RDF | |(Policy,| Description|
157 | +--+---+ |Metadata| | rules, | |
158 | | +--------+ | Device,| |
159 | | | etc. | |
160 | | +---+----+ |
161 | | | |
162 | | +----------+ | |
163 | +---->|XML Config|<-----+ |
164 | |Controller| |
165 | +-+---+--+-+ |
166 +-------------------------/-----\--\-------------------------+
167 / \ \ Config by
168 / \ \ XML +-----+
169 ISP Service +----V--+ \ +--------->/ \
170 Area |Router/| +V------+ / \
171 |Switch | |Router/| +---------+
172 +-------+ |Switch | |Home/SOHO|
173 ^ +----+--+ | -PDA |
174 | | | -Video |
175 | +-------+ | | -Devices|
176 | |Router/| | +---------+
177 | >Switch | |
178 | /+---+---+ |
179 | / | |
180 | / | |
181 +----------------------/-------------------------------------+
182 | | / | | |
183 | Current +------+++ | +---+----+ |
184 | Management |BB/ | | |SNMP/MIB| |
185 | System |PolicyDB| | +---+----+ |
186 | +--------+ | | |
187 | | | |
188 | | +---V----+ |
189 | +--->| NMS | Monitoring/ |
190 | +--------+ Observation |
191 +------------------------------------------------------------+
192 Figure 1: XML configuration architecture (possibilities)
194 5. Deployment Story
196 The deployment story is required to deploy the architecture. This is
197 our proposal.
199 o Phase 1: router and switch conf for ISP/career.
201 o Phase 1.5: router and switch conf for enterprise.
203 o Phase 2: SOHO home router and appliance control.
205 o Phase 3: mobile application and so on.
207 6. IANA Considerations
209 No action has been requested of IANA.
211 7. Security Considerations
213 This document discusses motivation and architecture of XML network
214 management. If implemented as described, it should ask the network
215 to do nathing that the network has already allowd. If that is the
216 case, no new security issues should arise from the use of such a
217 architecture.
219 References
221 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
222 Levels", BCP 14, RFC 2119, March 1997.
224 [2]
226 [3]
228 [4]
230 Authors' Addresses
232 Ray S. Atarashi
233 Communications Research Laboratory
234 4-2-1 Nukui-Kitamachi
235 Koganei, Tokyo 184-8795
236 JP
238 Phone: +81-42-327-6243
239 Fax: +81-42-327-9041
240 EMail: ray@crl.go.jp
242 Toshio Shimojo
243 Nara Institute of Science and Technology
244 8916-5 Takayama
245 Ikoma, Nara 630-0101
246 JP
248 Phone: +81-743-72-5210
249 Fax: +81-743-72-5291
250 EMail: toshio-s@is.aist-nara.ac.jp
252 Yoshifumi Atarashi
253 Hitachi, Ltd.,
254 1 Horiyamashita
255 Hadano, Kanagawa 259-1392
256 JP
258 Phone: +81-463-87-7496
259 Fax: +81-463-88-8062
260 EMail: atarashi@ebina.hitachi.co.jp
261 Shigeru Miyake
262 Hitachi, Ltd.,
263 292 Yoshida-cho
264 Totsuka, Kanagawa 244-0817
265 JP
267 Phone: +81-45-860-3093
268 Fax: +81-463-88-8062
269 EMail: yake@sdl.hitachi.co.jp
271 Makoto Kitani
272 Hitachi, Ltd.,
273 1 Horiyamashita
274 Hadano, Kanagawa 259-1392
275 JP
277 Phone: +81-463-87-7496
278 Fax: +81-463-88-8062
279 EMail: kitanim@crl.hitachi.co.jp
281 Fred Baker
282 Cisco Systems
283 1121 Via Del Rey
284 Santa Barbara, CA 93117
285 US
287 Phone: +1-408-526-4257
288 Fax: +1-413-473-2403
289 EMail: fred@cisco.com
291 Margaret Wasserman
292 Wind River
293 10 Tara Blvd., Suite 330
294 Nashua, NH 03062
295 US
297 Phone: +1-603-897-2067
298 Fax:
299 EMail: mrw@windriver.com
301 Full Copyright Statement
303 Copyright (C) The Internet Society (2002). All Rights Reserved.
305 This document and translations of it may be copied and furnished to
306 others, and derivative works that comment on or otherwise explain it
307 or assist in its implementation may be prepared, copied, published
308 and distributed, in whole or in part, without restriction of any
309 kind, provided that the above copyright notice and this paragraph are
310 included on all such copies and derivative works. However, this
311 document itself may not be modified in any way, such as by removing
312 the copyright notice or references to the Internet Society or other
313 Internet organizations, except as needed for the purpose of
314 developing Internet standards in which case the procedures for
315 copyrights defined in the Internet Standards process must be
316 followed, or as required to translate it into languages other than
317 English.
319 The limited permissions granted above are perpetual and will not be
320 revoked by the Internet Society or its successors or assigns.
322 This document and the information contained herein is provided on an
323 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
324 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
325 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
326 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
327 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
329 Acknowledgement
331 Funding for the RFC Editor function is currently provided by the
332 Internet Society.