idnits 2.17.1 draft-chen-i2rs-identifier-management-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 20 instances of too long lines in the document, the longest one being 22 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-i2rs-architecture]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 20, 2015) is 3318 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) == Unused Reference: 'RFC2119' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC6243' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC6536' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-restconf' is defined on line 361, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-09 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-04 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group R. Chen 3 Internet-Draft lin. Jiao 4 Intended status: Standards Track Frank. Feng 5 Expires: September 21, 2015 ZTE Corporation 6 March 20, 2015 8 Identifier Management for I2RS Protocol 9 draft-chen-i2rs-identifier-management-00 11 Abstract 13 An I2RS Agent may communicate with multiple clients. Two (or more) 14 client may attempt to manipulate the same piece of data on the I2RS 15 Agent. In order to solve this collision, the proposal is to have a 16 simple priority associated with each I2RS Client. 18 In addition, if the hold timer for an I2RS session expires, the I2RS 19 Agent should delete the I2RS data associated with the I2RS Client. 20 In order to delete the related I2RS data correctly, it is important 21 to identify the client on the I2RS Agent. 23 This document describes how to deploy identifier and priority 24 associated with each I2RS Client based on 25 [I-D.ietf-i2rs-architecture]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 21, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions used in this document . . . . . . . . . . . . . . 2 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 5. NETCONF Extensions . . . . . . . . . . . . . . . . . . . . . 4 66 6. RESTCONF Extensions . . . . . . . . . . . . . . . . . . . . . 5 67 7. I2RS-IDM YANG Data model . . . . . . . . . . . . . . . . . . 6 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10.1. Normative references . . . . . . . . . . . . . . . . . . 8 72 10.2. Informative references . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 An I2RS Agent may communicate with multiple clients. Two (or more) 78 client may attempt to manipulate the same piece of data on the I2RS 79 Agent. In order to solve this collision, the proposal is to have a 80 simple priority associated with each I2RS Client. 82 In addition, if the hold timer for an I2RS session expires, the I2RS 83 Agent should delete the I2RS data associated with the I2RS Client. 84 In order to delete the related I2RS data correctly, it is important 85 to identify the client on the I2RS Agent. 87 This document describes how to deploy identifier and priority 88 associated with each I2RS Client based on 89 [I-D.ietf-i2rs-architecture]. 91 2. Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC2119. 97 3. Terminology 99 The following terminology is used in this document. 101 Client identifier: An I2RS Client's identifier is a string of 1 to 31 102 characters, used to uniquely identify a client. The first character 103 of a client identifier should be a letter or "_", and the rest of it 104 can only be numbers, letters, or "_". The data of an I2RS session 105 will be maintained within a hold time after the I2RS session is 106 terminated, and it will be restored if the client uses the same 107 client identifier to reconnect to the agent during the hold time. 109 Priority: Priority is defined as an integer between 0 and 255, in 110 which, number 0 is with the highest priority and 255 is with the 111 lowest priority. A client is associated with a priority, which 112 determines whether the client has the authority to modify data of a 113 specific I2RS session. A client with higher priority can modify I2RS 114 data distributed by a client with lower priority. A client can 115 always modify I2RS data distributed by itself. Once the I2RS data is 116 modified by a client, the client identifier associated with the I2RS 117 data will be changed to the client identifier of the client that 118 modified the I2RS data. 120 4. Approach 122 When the I2RS session is opened, An I2RS Client should advertise to 123 an I2RS Agent that the I2RS Client's identifier and priority. The 124 I2RS Client's identifier and priority should be managed by the I2RS 125 Agent, and associated with its I2RS session. 127 If the hold timer for an I2RS session expires, the I2RS Agent should 128 delete the I2RS Client's identifier and priority associated with the 129 I2RS session. 131 When the I2RS session is active, the I2RS Client can only update its 132 own priority, and it must not update other client's priority. 134 In addition, I2RS Client's identifier management data model MUST be 135 supported by the I2RS Agent. 137 YANG Tree Diagram for "ietf-i2rs-idm" module: 139 module: ietf-i2rs-idm 140 +--ro identifiers 141 +--ro identifier [name] 142 +--ro name identifier 143 +--ro priority? uint8 144 +--ro session-id? uint32 145 rpcs: 146 +---x set-priority 147 | +--ro input 148 | +--ro priority? uint8 149 +---x advertise-identifier 150 +--ro input 151 +--ro identifier? identifier 152 +--ro priority? uint8 154 5. NETCONF Extensions 156 This approach extends hello message to the Network Configuration 157 Protocol (NETCONF) defined in [RFC6241]. More precisely, it defines 158 capability-based extension that an I2RS Client can use to advertise 159 to an I2RS Agent that the I2RS Client's identifier and priority 160 during I2RS session establishment.I2RS Client's identifier and 161 priority are only advertised in hello messages sent by Clients during 162 I2RS session establishment. The following will describe the 163 procedure in detail: 165 o When the I2RS session is opened, An I2RS Client sends a 166 element containing I2RS Client's identifier and priority. 168 o When the I2RS session is successfully established, An I2RS Agent 169 receiving a message with I2RS Client's identifier and 170 priority stores it and associated with its I2RS session. 172 o The client can modify the client's priority by RPC 173 operation. 175 o The I2RS Agent will allocate an initial priority to the I2RS 176 Client which does not send the client priority to the Agent. 178 In the following example, An I2RS Client advertises element 179 containing I2RS Client's identifier and priority. 181 182 183 184 urn:ietf:params:netconf:base:1.1 185 186 187 urn:ietf:params:xml:ns:yang:ietf-i2rs:idm?client identifier=test&priority=10 188 189 190 192 In order to modify the client's priority, the client might send the 193 following RPC message: 195 197 198 10 199 200 202 6. RESTCONF Extensions 204 This approach extends RESTCONF protocol. When a new I2RS session is 205 established, the I2RS Client's identifier and priority must be 206 advertised to the I2RS Agent. To handle the Client's update, the 207 I2RS Agent must associate the I2RS session with the I2RS Client's 208 identifier and priority. In addition, if the hold timer for an I2RS 209 session expires, the I2RS Agent should delete the I2RS Client's 210 identifier and priority associated with the I2RS session. 212 In order to advertise the I2RS client's identifier and priority to 213 the I2RS Agent, the client might send the following message: 215 POST http://localaddress:8080/restconf/operations/i2rs-idm:advertise-identifier 216 name: Content-Type value: application/yang.data+json 217 name: Accept value: application/xml 218 { 219 "input" : 220 { 221 "identifier":"test", 222 "priority":"50" 223 } 224 } 225 In order to update the I2RS client's identifier and priority to the 226 I2RS Agent, the client might send the following message: 228 POST http://localaddress:8080/restconf/operations/i2rs-idm:set-priority 229 name: Content-Type value: application/yang.data+json 230 name: Accept value: application/xml 231 { 232 "input" : 233 { 234 "priority":"10" 235 } 236 } 238 7. I2RS-IDM YANG Data model 240 module ietf-i2rs-idm { 241 namespace "urn:ietf:params:xml:ns:yang:ietf-i2rs:idm"; 242 prefix "i2rs-idm"; 244 revision 2015-03-06 { 245 description "Initial revision"; 246 } 248 typedef identifier { 249 description "The typedef of identifier."; 250 type string { 251 length 1..31; 252 pattern "([a-zA-Z_])([0-9a-zA-Z_]{0,30})"; 253 } 254 } 256 rpc set-priority { 257 description "This rpc can be used to update priority when 258 session is active. A client can only update its own 259 priority."; 260 input { 261 leaf priority { 262 description "The priority of the identifier associated 263 with this session. 0 indicates the highest priority, 264 and 255 indicates the lowest priority."; 265 type uint8; 266 } 267 } 268 } 270 rpc advertise-identifier { 271 description "This rpc can be used to advertise identifier associated 272 with this session. If the identifier has been exist and the 273 session-id associated with it is not zero, agent MUST report an 274 error and SHOULD terminate the session immediately. Otherwise, 275 Agent MUST store this identifier and assocoate it with its session-id."; 276 input { 277 leaf identifier { 278 description "The identifer advertised by this session. Identifier 279 can be used to indicate data, when a client create or update 280 data of i2rs datastore, these data will be associated with 281 the identifier of this client."; 282 type identifier; 283 } 285 leaf priority { 286 description "The priority of the identifier associated 287 with this session. 0 indicates the highest priority, 288 and 255 indicates the lowest priority."; 289 type uint8; 290 } 291 } 292 } 293 container identifiers { 294 description "This tree contains all detail information of identifiers 295 supported by agent. This is a read-only tree"; 296 config false; 297 list identifier { 298 description "The detail information of an identifier. When the 299 session is terminated, the session-id will be set by zero, 300 and other identifier information associated with this session 301 will be held until the hold time is out."; 302 key name; 303 unique session-id; 304 leaf name { 305 type identifier; 306 } 308 leaf priority { 309 type uint8; 310 } 312 leaf session-id { 313 description "The session id associated with identifier. Zero indicates 314 none."; 315 type uint32; 316 } 317 } 319 } 321 } 323 8. Security Considerations 325 TBD. 327 9. IANA Considerations 329 TBD. 331 10. References 333 10.1. Normative references 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 339 Network Configuration Protocol (NETCONF)", RFC 6020, 340 October 2010. 342 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 343 Bierman, "Network Configuration Protocol (NETCONF)", RFC 344 6241, June 2011. 346 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 347 NETCONF", RFC 6243, June 2011. 349 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 350 Protocol (NETCONF) Access Control Model", RFC 6536, March 351 2012. 353 10.2. Informative references 355 [I-D.ietf-i2rs-architecture] 356 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 357 Nadeau, "An Architecture for the Interface to the Routing 358 System", draft-ietf-i2rs-architecture-09 (work in 359 progress), March 2015. 361 [I-D.ietf-netconf-restconf] 362 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 363 Protocol", draft-ietf-netconf-restconf-04 (work in 364 progress), January 2015. 366 Authors' Addresses 368 Ran Chen 369 ZTE Corporation 370 No.50 Software Avenue 371 Yuhuatai District,Nanjing 210012 372 P.R.China 374 Phone: +86 025 88014636 375 Email: chen.ran@zte.com.cn 377 lin Jiao 378 ZTE Corporation 379 No.86 Zijinghua Rd 380 Yuhuatai District,Nanjing 210012 381 P.R.China 383 Email: Jiao.lin@zte.com.cn 385 Frank Feng 386 ZTE Corporation 387 No.86 Zijinghua Rd 388 Yuhuatai District,Nanjing 210012 389 P.R.China 391 Phone: +86 021 68896273 392 Email: feng.chong33@zte.com.cn