From ngo-bounces@ietf.org Fri Apr 06 03:23:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZimu-0006WC-22; Fri, 06 Apr 2007 03:23:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZimt-0006Vw-0B for ngo@ietf.org; Fri, 06 Apr 2007 03:23:11 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZiml-0000vM-B1 for ngo@ietf.org; Fri, 06 Apr 2007 03:23:10 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6690B20956 for ; Fri, 6 Apr 2007 09:22:46 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-74-4615f54696ea Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 48D1C2047F for ; Fri, 6 Apr 2007 09:22:46 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 09:22:45 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 09:22:45 +0200 Message-ID: <4615F544.6080602@ericsson.com> Date: Fri, 06 Apr 2007 09:22:44 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 CC: NETCONF Goes On Subject: Re: [NGO] NETCONF protocol extensions References: <45F6D924.805@andybierman.com> In-Reply-To: <45F6D924.805@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2007 07:22:45.0730 (UTC) FILETIME=[5F56F420:01C7781C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hello, 1) We support this. Ericsson actually has implemented something like "test-only". It would also clarify an important point in the original RFC: whether to use inline-configuration data in the operation which is explicitly supported by the XSD but not according to the text part. 2) A useful idea. If we do it, I strongly support the explicit indication whether defaults are requested to be returned or not. 3) Would be good. Balazs Andy Bierman wrote: > Hi Martin, > > Since we're both working on different NC extensions, as are many > others I suspect, I wonder if it would be too early to discuss > some basic extensions that make the protocol work as intended, > rather than as specified. > > I'm not going to list everything here, but 3 obvious extensions > that have been discussed already: > > 1) test-only > > Extension to parameter in operation, > which causes the agent to validate the configuration fragment > against the configuration. Processing is done in the normal > manner, > except the agent will exit the operation without actually performing the > requested edit. > > 2) with-defaults attribute > > > > The standard NETCONF operations are defined such that all values, > including default values must be returned in , , > and operations. However, it is standard NM practice > to omit generation of configuration parameters which are present > in the agent but contain a default value selected by the agent. > > If the 'with-defaults' attribute is present in the element, > with a value of 'false', and the RPC method is , , > or , then the agent will suppress output of any > configuration > parameters which contain an agent-selected default value. > > In this mode, only configuration parameters which have been > explicitly set to a value other than the default value will > be included in the output. This special filter > is applied in addition to any filter that might have been > supplied in the request. > > 3) Conventions for data model module format: > - need to convey the fact that the capability represents a module > - need to convey module meta-data (owner, name, version, namespace URI) > > I wonder if we could have a bar-BOF to see if there is some consensus > on a small number of these inter-operability details. > > thanks, > Andy > > > _______________________________________________ > NGO mailing list > NGO@ietf.org > https://www1.ietf.org/mailman/listinfo/ngo -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Fri Apr 06 12:55:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZriO-0008Eo-A7; Fri, 06 Apr 2007 12:55:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZriM-0008Ei-6h for ngo@ietf.org; Fri, 06 Apr 2007 12:55:06 -0400 Received: from omr6.networksolutionsemail.com ([205.178.146.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZriI-0008BG-9u for ngo@ietf.org; Fri, 06 Apr 2007 12:55:06 -0400 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l36Gt0sK029978 for ; Fri, 6 Apr 2007 12:55:00 -0400 Received: (qmail 22461 invoked by uid 78); 6 Apr 2007 16:54:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 6 Apr 2007 16:54:59 -0000 Message-ID: <46167B45.80603@andybierman.com> Date: Fri, 06 Apr 2007 09:54:29 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Netconf (E-mail)" Content-Type: multipart/mixed; boundary="------------080903000504050409060704" X-Spam-Score: 0.1 (/) X-Scan-Signature: 142968907492cd6b805bce4edf0aec7b Cc: NETCONF Goes On Subject: [NGO] syslog content for NETCONF stream X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org This is a multi-part message in MIME format. --------------080903000504050409060704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I translated the syslog message format as defined in draft-ietf-syslog-protocol-19.txt into XML encoding for better subtree and Xpath filtering, as well as a TEXT encoding. I doubt we can standardize any content given the level of disagreement over every little detail. But we still need to keep throwing darts at data models until there is more agreement. Simon asked an important question at the last IETF meeting: "What do you think the NETCONF data model should look like"? Debating the finer points of data modeling language design is a nice academic exercise. Debating what the XML on the wire looks like is much more important right now. I am including the XSD and the NCX source file. I hope the documentation is readable in the module header. This is an attempt at a direct translation of syslog-19 message format. If there is any interest, I will write up an I-D. Andy --------------080903000504050409060704 Content-Type: text/xml; name="syslog.xsd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="syslog.xsd" Converted from NCX module by ncxdump v0.2 Module: syslog Owner: ietf Application: syslog Version: 1 Copyright (C) Andy Bierman (2007). All Rights Reserved. Contact Info: Translated by Andy Bierman. Send comments to ietf@andybierman.com. Description: Syslog Message Structure Translated from draft-ietf-syslog-protocol-19.txt Defines XML or TEXT encoding formats for translation of syslog messages into NETCONF Notifications Note: In all examples the double-quotes have been changed to single quotes for NCX description string syntax compliance. The content of the <notification> element is either a <syslog> element of type 'SyslogTextMessage' or an <xsyslog> element of type 'SyslogXmlMessage'. Example Syslog encoding from [syslog] page 22, example 3: <165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@0 iut='3'; eventSource= 'Application' eventID='1011'] BOMAn application event log entry... NETCONF XML Encoding: <notification xmlns='netconf-notification'> <xsyslog xmlns='http://netconfcentral.org/ietf/syslog'> <pri>165</pri> <version>1</version> <timestamp>2003-10-11T22:14:15.003Z</timestamp> <hostname>mymachine.example.com</hostname> <appname>evntslog</appname> <procid>-</procid> <msgid>ID47</msgid> <sdparams> <sdparam sd-id='exampleSDID@0'> <iut>3</iut> <eventSource>Application</eventSource> <eventID>1011</eventID> </sdparam> </sdparams> <msg>An application event log entry...</msg> </xsyslog> </notification> NETCONF Text Encoding: Note that PRI field MUST NOT be enclosed in angle brackets They must be omitted instead! <notification xmlns='netconf-notification'> <syslog xmlns='http://netconfcentral.org/ietf/syslog'> 165 1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@0 iut='3' eventSource= 'Application' eventID='1011'] BOMAn application event log entry... </syslog> </notification> Revision History: Revision: 1 Initial version. Structured Data Name or ID Structured Data Name or ID PRI field from [syslog] 6.2.1: Represents both the Facility and Severity. The Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for '0') through %d57 (for '9'). Facility and Severity values are not normative but often used. They are described in the following tables for purely informational purposes. Numerical Facility Code 0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages 5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon 10 security/authorization messages 11 FTP daemon 12 NTP subsystem 13 log audit 14 log alert 15 clock daemon (note 2) 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7) Table 1. syslog Message Facilities Each message Priority also has a decimal Severity level indicator. These are described in the following table along with their numerical values. Numerical Severity Code 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages Table 2. syslog Message Severities The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a 'local use 4' message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively. Leading '0's MUST NOT be used. The VERSION field denotes the version of the syslog protocol specification. The version number MUST be incremented for any new syslog protocol specification that changes any part of the HEADER format. Changes include the addition or removal of fields, or a change of syntax or semantics of existing fields. This document uses a VERSION value of '1'. The VERSION values are IANA-assigned (Section 9.1) via the Standards Action method as described in RFC 2434 [8]. The TIMESTAMP field is a formalized timestamp derived from RFC 3339 [7]. Whereas RFC 3339 [7] makes allowances for multiple syntaxes, this document imposes further restrictions. The TIMESTAMP value MUST follow these restrictions: o The 'T' and 'Z' characters in this syntax MUST be upper case. o Usage of the 'T' character is REQUIRED. o Leap seconds MUST NOT be used. The sender SHOULD include TIME-SECFRAC if its clock accuracy and performance permit. The 'timeQuality' SD-ID described in Section 7.1 allows the sender to specify accuracy and trustworthiness of the timestamp. A syslog sender incapable of obtaining system time MUST use the NILVALUE as TIMESTAMP. The HOSTNAME field identifies the machine that originally sent the syslog message. The HOSTNAME field SHOULD contain the host name and the domain name of the originator in the format specified in STD 13 [2]. This format is called a Fully Qualified Domain Name (FQDN) in this document. In practice, not all senders are able to provide a FQDN. As such, other values MAY also be present in HOSTNAME. This document makes provisions for using other values in such situations. A sender SHOULD provide the most specific available value first. The order of preference for the contents of the HOSTNAME field is as follows: 1. FQDN 2. Static IP address 3. hostname 4. Dynamic IP address 5. the NILVALUE If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 [3]. If an IPv6 address is used, a valid textual representation as described in RFC 4291 [9], Section 2.2, MUST be used. Senders SHOULD consistently use the same value in the HOSTNAME field for as long as possible. If the sender uses IP addresses inside hostname, the following rules apply: If the sender is multihomed, this value SHOULD be one of its actual IP addresses. If a sender is running on a machine that has both statically and dynamically assigned addresses, then that value SHOULD be from the statically assigned addresses. As an alternative, the sender MAY use the IP address of the interface that is used to send the message. The NILVALUE SHOULD only be used when the sender has no way to obtain its real hostname. This situation is considered highly unlikely. The APP-NAME field SHOULD identify the device or application that generated the message. It is a string without further semantics. It is intended for filtering messages on the receiver. The NILVALUE MAY be used when the sender has no idea of its APP-NAME or cannot provide that information. It may be that a device may not be able to provide that information either because of a local policy decision, or because the information is not available, or not applicable, on the device. This field MAY be operator-assigned. The PROCID field SHOULD be used to provide the sender's process name or process ID. The field does not have any specific syntax. The NILVALUE MAY be used when the sender can not obtain its PROCID or cannot provide it. PROCID is primarily meaningful for analysis tools. Properly used, it can enable log analyzers to detect which messages were generated by the same sender process. For example, on a UNIX system the syslog daemon (syslogd) might emit messages to the log. All messages logged by the same syslogd process will bear the same PROCID. When the syslog sender is restarted, the PROCID value MAY change. That may enable the analysis script to detect the syslogd restart. This field MAY be operator-assigned. Some non-normative additional information about PROCID values can be found in Appendix A.8. The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID 'TCPIN' for incoming TCP traffic and the MSGID 'TCPOUT' for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on the receiver. The NILVALUE SHOULD be used when the sender does not intend to provide a real MSGID. This field MAY be operator-assigned. NOT REALLY USED!!! Represents one SD-PARAM entry Represents one SD-PARAM entry Represents container of SD-PARAM entries The MSG section as defined in [syslog] sec. 6.4 The top-level Syslog XML Message structure. The header contents are placed at the same nest level as the other fields in order to simplify encoding and permit NETCONF subtree filtering to work properly The top-level Syslog TEXT Message structure. --------------080903000504050409060704 Content-Type: text/plain; name="syslog.ncx" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="syslog.ncx" ncx-module syslog { header { description "Syslog Message Structure Translated from draft-ietf-syslog-protocol-19.txt Defines XML or TEXT encoding formats for translation of syslog messages into NETCONF Notifications Note: In all examples the double-quotes have been changed to single quotes for NCX description string syntax compliance. The content of the element is either a element of type 'SyslogTextMessage' or an element of type 'SyslogXmlMessage'. Example Syslog encoding from [syslog] page 22, example 3: <165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@0 iut='3'; eventSource= 'Application' eventID='1011'] BOMAn application event log entry... NETCONF XML Encoding: 165 1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 3 Application 1011 An application event log entry... NETCONF Text Encoding: Note that PRI field MUST NOT be enclosed in angle brackets They must be omitted instead! 165 1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@0 iut='3' eventSource= 'Application' eventID='1011'] BOMAn application event log entry... "; version 1; owner ietf; application syslog; copyright "Copyright (C) Andy Bierman (2007). All Rights Reserved."; contact-info "Translated by Andy Bierman. Send comments to ietf@andybierman.com."; last-update "2007-04-05"; revision-history { 1 "Initial version."; } } imports { import xsd; } definitions { type UsAsciiString { description "Structured Data Name or ID"; syntax { string pattern = "[!-~]*"; } } type SDName { description "Structured Data Name or ID"; syntax { UsAsciiString (1..32); } } type SyslogPriority { description "PRI field from [syslog] 6.2.1: Represents both the Facility and Severity. The Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for '0') through %d57 (for '9'). Facility and Severity values are not normative but often used. They are described in the following tables for purely informational purposes. Numerical Facility Code 0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages 5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon 10 security/authorization messages 11 FTP daemon 12 NTP subsystem 13 log audit 14 log alert 15 clock daemon (note 2) 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7) Table 1. syslog Message Facilities Each message Priority also has a decimal Severity level indicator. These are described in the following table along with their numerical values. Numerical Severity Code 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages Table 2. syslog Message Severities The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a 'local use 4' message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively. Leading '0's MUST NOT be used."; syntax { string pattern = "[0-9]{1,3}"; # range 0 .. 191 } } type SyslogVersion { description "The VERSION field denotes the version of the syslog protocol specification. The version number MUST be incremented for any new syslog protocol specification that changes any part of the HEADER format. Changes include the addition or removal of fields, or a change of syntax or semantics of existing fields. This document uses a VERSION value of '1'. The VERSION values are IANA-assigned (Section 9.1) via the Standards Action method as described in RFC 2434 [8]."; syntax { string pattern = "([1-9])([0-9]{0,2})"; } } type SyslogTimestamp { description "The TIMESTAMP field is a formalized timestamp derived from RFC 3339 [7]. Whereas RFC 3339 [7] makes allowances for multiple syntaxes, this document imposes further restrictions. The TIMESTAMP value MUST follow these restrictions: o The 'T' and 'Z' characters in this syntax MUST be upper case. o Usage of the 'T' character is REQUIRED. o Leap seconds MUST NOT be used. The sender SHOULD include TIME-SECFRAC if its clock accuracy and performance permit. The 'timeQuality' SD-ID described in Section 7.1 allows the sender to specify accuracy and trustworthiness of the timestamp. A syslog sender incapable of obtaining system time MUST use the NILVALUE as TIMESTAMP."; syntax { dateTime; } } type SyslogHostname { description "The HOSTNAME field identifies the machine that originally sent the syslog message. The HOSTNAME field SHOULD contain the host name and the domain name of the originator in the format specified in STD 13 [2]. This format is called a Fully Qualified Domain Name (FQDN) in this document. In practice, not all senders are able to provide a FQDN. As such, other values MAY also be present in HOSTNAME. This document makes provisions for using other values in such situations. A sender SHOULD provide the most specific available value first. The order of preference for the contents of the HOSTNAME field is as follows: 1. FQDN 2. Static IP address 3. hostname 4. Dynamic IP address 5. the NILVALUE If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 [3]. If an IPv6 address is used, a valid textual representation as described in RFC 4291 [9], Section 2.2, MUST be used. Senders SHOULD consistently use the same value in the HOSTNAME field for as long as possible. If the sender uses IP addresses inside hostname, the following rules apply: If the sender is multihomed, this value SHOULD be one of its actual IP addresses. If a sender is running on a machine that has both statically and dynamically assigned addresses, then that value SHOULD be from the statically assigned addresses. As an alternative, the sender MAY use the IP address of the interface that is used to send the message. The NILVALUE SHOULD only be used when the sender has no way to obtain its real hostname. This situation is considered highly unlikely."; syntax { UsAsciiString (1..255); } } type SyslogAppname { description "The APP-NAME field SHOULD identify the device or application that generated the message. It is a string without further semantics. It is intended for filtering messages on the receiver. The NILVALUE MAY be used when the sender has no idea of its APP-NAME or cannot provide that information. It may be that a device may not be able to provide that information either because of a local policy decision, or because the information is not available, or not applicable, on the device. This field MAY be operator-assigned."; syntax { UsAsciiString (1..48); } } type SyslogProcid { description "The PROCID field SHOULD be used to provide the sender's process name or process ID. The field does not have any specific syntax. The NILVALUE MAY be used when the sender can not obtain its PROCID or cannot provide it. PROCID is primarily meaningful for analysis tools. Properly used, it can enable log analyzers to detect which messages were generated by the same sender process. For example, on a UNIX system the syslog daemon (syslogd) might emit messages to the log. All messages logged by the same syslogd process will bear the same PROCID. When the syslog sender is restarted, the PROCID value MAY change. That may enable the analysis script to detect the syslogd restart. This field MAY be operator-assigned. Some non-normative additional information about PROCID values can be found in Appendix A.8."; syntax { UsAsciiString (1..12); } } type SyslogMsgid { description "The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID 'TCPIN' for incoming TCP traffic and the MSGID 'TCPOUT' for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on the receiver. The NILVALUE SHOULD be used when the sender does not intend to provide a real MSGID. This field MAY be operator-assigned."; syntax { UsAsciiString (1..32); } } type SyslogParam { description "NOT REALLY USED!!! Represents one SD-PARAM entry"; syntax { string; } } type SyslogParamSet { description "Represents one SD-PARAM entry"; syntax { any; } # really replacement of the abstract 'param-name' # struct { # SyslogParam param-name+; # } metadata { SDName sd-id; } } type SyslogParams { description "Represents container of SD-PARAM entries"; syntax { struct { SyslogParamSet sdparam+; } } } type SyslogMsgData { description "The MSG section as defined in [syslog] sec. 6.4"; syntax { string; } } type SyslogXmlMessage { description "The top-level Syslog XML Message structure. The header contents are placed at the same nest level as the other fields in order to simplify encoding and permit NETCONF subtree filtering to work properly"; syntax { struct { SyslogPriority pri; SyslogVersion version; SyslogTimestamp timestamp; SyslogHostname hostname; SyslogAppname appname; SyslogProcid procid; SyslogMsgid msgid; SyslogParams sdparams?; SyslogMsgData msg?; } } } type SyslogTextMessage { description "The top-level Syslog TEXT Message structure."; syntax { string; } } } } --------------080903000504050409060704 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo --------------080903000504050409060704-- From ngo-bounces@ietf.org Mon Apr 09 05:46:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaqRj-0008GB-Cv; Mon, 09 Apr 2007 05:45:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaqRh-0008G1-OA for ngo@ietf.org; Mon, 09 Apr 2007 05:45:57 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaqRg-0007XO-Fl for ngo@ietf.org; Mon, 09 Apr 2007 05:45:57 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 09 Apr 2007 05:45:55 -0400 X-IronPort-AV: i="4.14,387,1170651600"; d="scan'208"; a="1240211:sNHT7425048" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NGO] syslog content for NETCONF stream Date: Mon, 9 Apr 2007 12:45:12 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NGO] syslog content for NETCONF stream Thread-Index: Acd4bGkLlyePcOGQTsC99G0aMRE13wCHs4rA References: <46167B45.80603@andybierman.com> From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , "Netconf \(E-mail\)" X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: NETCONF Goes On X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org I am quite sure that there is enough interest to write an I-D. In the current phase of discussions and especially until a broader consensus is reached on the data modeling language it helps to document the contributions. It may also happen that in a first phase we shall rather publish Informational or Experimental RFC documents rather than going directly to standards track. In any case, I-Ds are good.=20 Dan =20 =20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Friday, April 06, 2007 7:54 PM > To: Netconf (E-mail) > Cc: NETCONF Goes On > Subject: [NGO] syslog content for NETCONF stream >=20 > Hi, >=20 > I translated the syslog message format as defined in=20 > draft-ietf-syslog-protocol-19.txt into XML encoding for=20 > better subtree and Xpath filtering, as well as a TEXT encoding. >=20 > I doubt we can standardize any content given the level of=20 > disagreement over every little detail. > But we still need to keep throwing darts at data models until=20 > there is more agreement. >=20 > Simon asked an important question at the last IETF meeting: > "What do you think the NETCONF data model should look like"? > Debating the finer points of data modeling language design is=20 > a nice academic exercise. Debating what the XML on the wire=20 > looks like is much more important right now. >=20 > I am including the XSD and the NCX source file. > I hope the documentation is readable in the module header. > This is an attempt at a direct translation of syslog-19=20 > message format. > If there is any interest, I will write up an I-D. >=20 > Andy >=20 >=20 >=20 >=20 >=20 _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Mon Apr 09 06:57:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HarYE-00041v-TM; Mon, 09 Apr 2007 06:56:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HarYC-00041n-OV for ngo@ietf.org; Mon, 09 Apr 2007 06:56:44 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HarYA-0005oR-Nl for ngo@ietf.org; Mon, 09 Apr 2007 06:56:44 -0400 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 10 Apr 2007 05:16:14 +0530 X-IronPort-AV: i="4.14,387,1170613800"; d="scan'208,217"; a="78045783:sNHT1342765166" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l39AuXQZ002977; Mon, 9 Apr 2007 18:56:33 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l39AuRjO013261; Mon, 9 Apr 2007 10:56:31 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 18:56:26 +0800 Received: from syd-rpruss-vpn5.cisco.com ([10.67.195.22]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 18:56:24 +0800 Message-ID: <461A1BD3.6060203@cisco.com> Date: Mon, 09 Apr 2007 20:56:19 +1000 From: Richard Pruss Organization: Cisco Systems User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Andy Bierman Subject: Re: [NGO] syslog content for NETCONF stream References: <46167B45.80603@andybierman.com> In-Reply-To: <46167B45.80603@andybierman.com> X-OriginalArrivalTime: 09 Apr 2007 10:56:25.0482 (UTC) FILETIME=[B7BF1EA0:01C77A95] Authentication-Results: hkg-dkim-1; header.From=ric@cisco.com; dkim=neutral ( ssp=~; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: NETCONF Goes On , "Netconf \(E-mail\)" X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ric@cisco.com List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0314310950==" Errors-To: ngo-bounces@ietf.org This is a multi-part message in MIME format. --===============0314310950== Content-Type: multipart/alternative; boundary="------------020708010609070107080700" This is a multi-part message in MIME format. --------------020708010609070107080700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yea I think some sub-areas for data models is a possible approach. I must agree with the underlying sentiment of your comment. I guess I might say it straight from my perspective. We attended this Netconf session to see if we should think about contributing the current data model work from various session based and config based efforts in our OS's but given that the working group was a two party punching match and the side group (I did not attend) went off on inventing some replacement data modelling langauge because of some implementation choices of Netconf filtering.... It does not look like we can have the discussions here. -Ric Andy Bierman wrote: > Hi, > > I translated the syslog message format as defined > in draft-ietf-syslog-protocol-19.txt into XML encoding > for better subtree and Xpath filtering, as well as a TEXT encoding. > > I doubt we can standardize any content given the > level of disagreement over every little detail. > But we still need to keep throwing darts at data models > until there is more agreement. > > Simon asked an important question at the last IETF meeting: > "What do you think the NETCONF data model should look like"? > Debating the finer points of data modeling language design is > a nice academic exercise. Debating what the XML on the wire > looks like is much more important right now. > > I am including the XSD and the NCX source file. > I hope the documentation is readable in the module header. > This is an attempt at a direct translation of syslog-19 message format. > If there is any interest, I will write up an I-D. > > Andy > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > NGO mailing list > NGO@ietf.org > https://www1.ietf.org/mailman/listinfo/ngo --------------020708010609070107080700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yea I think some sub-areas for data models is a possible approach. 

I must agree with the underlying sentiment of your comment.  I guess I might say it straight from my perspective. We attended this Netconf session to see if we should think about contributing the current data model work from various session based and config based efforts in our OS's but given that the working group was a two party punching match and the side group (I did not attend) went off on inventing some replacement data modelling langauge because of some implementation choices of Netconf filtering.... 

It does not look like we can have the discussions here.

-Ric

Andy Bierman wrote:
Hi,

I translated the syslog message format as defined
in draft-ietf-syslog-protocol-19.txt into XML encoding
for better subtree and Xpath filtering, as well as a TEXT encoding.

I doubt we can standardize any content given the
level of disagreement over every little detail.
But we still need to keep throwing darts at data models
until there is more agreement.

Simon asked an important question at the last IETF meeting:
"What do you think the NETCONF data model should look like"?
Debating the finer points of data modeling language design is
a nice academic exercise.  Debating what the XML on the wire
looks like is much more important right now.

I am including the XSD and the NCX source file.
I hope the documentation is readable in the module header.
This is an attempt at a direct translation of syslog-19 message format.
If there is any interest, I will write up an I-D.

Andy 





_______________________________________________
NGO mailing list
NGO@ietf.org
https://www1.ietf.org/mailman/listinfo/ngo
--------------020708010609070107080700-- --===============0314310950== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo --===============0314310950==-- From ngo-bounces@ietf.org Mon Apr 09 10:04:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HauUA-0006Ma-V9; Mon, 09 Apr 2007 10:04:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HauU9-0006ML-SQ for ngo@ietf.org; Mon, 09 Apr 2007 10:04:45 -0400 Received: from omr3.networksolutionsemail.com ([205.178.146.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HauU5-0004mI-Ga for ngo@ietf.org; Mon, 09 Apr 2007 10:04:45 -0400 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l39E4f27030801 for ; Mon, 9 Apr 2007 10:04:41 -0400 Received: (qmail 28930 invoked by uid 78); 9 Apr 2007 14:04:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 9 Apr 2007 14:04:41 -0000 Message-ID: <461A47DA.5000003@andybierman.com> Date: Mon, 09 Apr 2007 07:04:10 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" Subject: Re: [NGO] syslog content for NETCONF stream References: <46167B45.80603@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: NETCONF Goes On , "Netconf \(E-mail\)" X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Romascanu, Dan (Dan) wrote: > I am quite sure that there is enough interest to write an I-D. In the > current phase of discussions and especially until a broader consensus is > reached on the data modeling language it helps to document the > contributions. It may also happen that in a first phase we shall rather > publish Informational or Experimental RFC documents rather than going > directly to standards track. In any case, I-Ds are good. > I should be clear that I would not be including the NCX module in the draft. I just included it because the header is easier to read without character entities in the examples. The real XSD would have a substititionGroup defined for the sdparam element, instead of type 'any'. I think we would have better luck discussing data models instead of data modeling languages. If you don't know what the XML on the wire should look like, then you don't need a data modeling language yet. A DML only helps if you already understand the data model you are designing. > Dan Andy > > > > > >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] >> Sent: Friday, April 06, 2007 7:54 PM >> To: Netconf (E-mail) >> Cc: NETCONF Goes On >> Subject: [NGO] syslog content for NETCONF stream >> >> Hi, >> >> I translated the syslog message format as defined in >> draft-ietf-syslog-protocol-19.txt into XML encoding for >> better subtree and Xpath filtering, as well as a TEXT encoding. >> >> I doubt we can standardize any content given the level of >> disagreement over every little detail. >> But we still need to keep throwing darts at data models until >> there is more agreement. >> >> Simon asked an important question at the last IETF meeting: >> "What do you think the NETCONF data model should look like"? >> Debating the finer points of data modeling language design is >> a nice academic exercise. Debating what the XML on the wire >> looks like is much more important right now. >> >> I am including the XSD and the NCX source file. >> I hope the documentation is readable in the module header. >> This is an attempt at a direct translation of syslog-19 >> message format. >> If there is any interest, I will write up an I-D. >> >> Andy >> >> >> >> >> > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Mon Apr 09 10:56:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavIV-0007U5-AT; Mon, 09 Apr 2007 10:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavIS-0007Tn-R7 for ngo@ietf.org; Mon, 09 Apr 2007 10:56:45 -0400 Received: from omr3.networksolutionsemail.com ([205.178.146.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HavIP-00083b-SB for ngo@ietf.org; Mon, 09 Apr 2007 10:56:44 -0400 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l39EufJb016618 for ; Mon, 9 Apr 2007 10:56:41 -0400 Received: (qmail 18035 invoked by uid 78); 9 Apr 2007 14:56:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 9 Apr 2007 14:56:41 -0000 Message-ID: <461A540A.30407@andybierman.com> Date: Mon, 09 Apr 2007 07:56:10 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Balazs Lengyel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: NETCONF Goes On Subject: [NGO] multi-session locks X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hi Balazs, I am very interested in the partial database locking problem that we discussed at the last interim. I think that you are right wrt/ your concerns about the "1 user global lock" design for large devices. There are many issues with implicit locking, especially given our current architecture and lock operations. This approach won't work on the target unless operations are added to make it work like the model instead. This would defeat the purpose of having both and targets in the protocol. IMO it will take a lot of work to re-define either the or the write models to allow for collision-proof multi-user write access, using implicit locking. Yet, explicit locking doesn't look so great either. Is the agent going to reject an edit-config operation if part of it touches a locked sub-tree and part of it touches an unlocked sub-tree? The edit-config operation is designed to work with or without locks, so rejecting an edit-config operation this way seems wrong. What happens if another session comes along and locks the altered but unlocked sub-tree? At least explicit locking works the same whether the target is or . One workaround that occurred to me: Why not let the managers worry about database collisions with a multi-session lock mechanism that works like an access control list, except the resource is the lock, not the data itself. In other words, the manager configures which sessions can share a lock, based on data outside the scope of the standard. For example, what if the group-id was used by the agent instead of the session-id, when checking lock access? (Access control, users and groups, etc. out of scope for now.) The grouping could also be an internal implementation detail, such as all 'sibling' virtual routers associated with one real router. IMO, this approach is better than not using locks at all, because unwanted edit-config access will be rejected if the 'group' is configured correctly. Also, no other application will be able to grab the global lock, ruining the cooperative locking in progress. How do you think the protocol should support multi-session locks? thanks, Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Apr 10 04:50:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbC2v-0004fS-VY; Tue, 10 Apr 2007 04:49:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbC2u-0004cQ-On for ngo@ietf.org; Tue, 10 Apr 2007 04:49:48 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbC2m-0004Lh-5l for ngo@ietf.org; Tue, 10 Apr 2007 04:49:48 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8D2DF2138D; Tue, 10 Apr 2007 10:49:35 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-cd-461b4f9f2a02 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 740EF213B2; Tue, 10 Apr 2007 10:49:35 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 10:49:35 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 10:49:34 +0200 Message-ID: <461B4F9E.3030401@ericsson.com> Date: Tue, 10 Apr 2007 10:49:34 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Andy Bierman References: <461A540A.30407@andybierman.com> In-Reply-To: <461A540A.30407@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 08:49:34.0620 (UTC) FILETIME=[29BB7DC0:01C77B4D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: NETCONF Goes On Subject: [NGO] Re: multi-session locks X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hello Andy, For us the question is even more interesting, as parts of our big node configuration might be administered by different people/organizations using different management tools; so allowing operator A to deny configuration operations for operator B sounds really bad. IMO we have here two separate questions: - What can be locked: full data-store, a sub-tree, any group of managed objects? - Who can used a locked entity: one session, any session connected to one userId or groupId? IMO the first step in any lock related work is to allow the node to reject the global lock, else some old manager application will come and lock the whole node. The next step (as you point out below) is that partial locking has a difficulty with candidate configurations. At least commit, discard-changes, delete-config and copy-config needs a full lock (or rather an absence of any lock on any part of the datastore). Theoretically we could have a partitioned candidate data-store with partial commit etc. but I think that's too complicated to be usable. All in all I see the following possibilities: - A complete SQL-database-like implicit locking mechanism works well, but might be a heavy task for small nodes - I also see an important use-case in dividing up the configuration into disjunct parts and locking those (e.g. a sub-tree). This way each operator could configure his own part. It is not feasible to define the sub-trees at design time. - Multi-session locks can also be useful, if it is the same person/group using the same lock simultaneously. We could utilize something like the groupId or userId for this purpose. In our implementation we will have just a writable running config. The size of this will be so big, that that alone precludes keeping a candidate. The running datastore will work somewhat like a normal SQL database. It locks what is needed without explicit lock operations. See also some comments below: Andy Bierman wrote: > Hi Balazs, > > I am very interested in the partial database locking problem > that we discussed at the last interim. I think that you are > right wrt/ your concerns about the "1 user global lock" design > for large devices. > > There are many issues with implicit locking, especially given > our current architecture and lock operations. This approach > won't work on the target unless operations are added > to make it work like the model instead. This > would defeat the purpose of having both and > targets in the protocol. > > IMO it will take a lot of work to re-define either the > or the write models to allow for collision-proof multi-user > write access, using implicit locking. [Balazs]: One solution is to say locking is a completely internal, implementation specific issue, so we can avoid redefining most parts of the protocol. If part or the whole of an operation (edit-config, copy-config, etc.) fails due to internal locking, that is handled the same way as any other internal error. Even today we can not guarantee that all set/create sub-operations will succeed. Still it would be good to tell the client that the operation failed (temporarily?) due to locking, so he will not try to find bugs in the operation's data. > > Yet, explicit locking doesn't look so great either. Is the agent > going to reject an edit-config operation if part of it touches > a locked sub-tree and part of it touches an unlocked sub-tree? [Balazs}: IMHO failure due to locking can be handled as just any other internal failure. E.g. one due to running out of memory. In my understanding the edit-config error-option will be able to handle this. Do you agree? > The edit-config operation is designed to work with or without locks, > so rejecting an edit-config operation this way seems wrong. > What happens if another session comes along and locks the altered > but unlocked sub-tree? At least explicit locking works the same > whether the target is or . > > One workaround that occurred to me: > > Why not let the managers worry about database collisions with a > multi-session > lock mechanism that works like an access control list, except the > resource is the lock, not the data itself. In other words, the > manager configures which sessions can share a lock, based on data > outside the scope of the standard. For example, what if the group-id > was used by the agent instead of the session-id, when checking lock access? > (Access control, users and groups, etc. out of scope for now.) > > The grouping could also be an internal implementation detail, > such as all 'sibling' virtual routers associated with one real router. > > IMO, this approach is better than not using locks at all, > because unwanted edit-config access will be rejected if the 'group' > is configured correctly. Also, no other application will be able > to grab the global lock, ruining the cooperative locking in progress. > > How do you think the protocol should support multi-session locks? [Balazs]: Multi-session locks are useful, but they solve only part of the problem. We already have big nodes where different people configure different parts of the system, so we would like to be able to lock just part of the node. If the involved people are geographically separated multi-session locks don't solve this problem. > > thanks, > Andy > > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Apr 10 10:36:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHSj-0006L7-9q; Tue, 10 Apr 2007 10:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHSh-0006Kz-Ap for ngo@ietf.org; Tue, 10 Apr 2007 10:36:47 -0400 Received: from omr8.networksolutionsemail.com ([205.178.146.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbHSd-0003rH-UK for ngo@ietf.org; Tue, 10 Apr 2007 10:36:47 -0400 Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l3AEahBv007086 for ; Tue, 10 Apr 2007 10:36:43 -0400 Received: (qmail 4832 invoked by uid 78); 10 Apr 2007 14:36:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 10 Apr 2007 14:36:43 -0000 Message-ID: <461BA0DB.6090500@andybierman.com> Date: Tue, 10 Apr 2007 07:36:11 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Balazs Lengyel References: <461A540A.30407@andybierman.com> <461B4F9E.3030401@ericsson.com> In-Reply-To: <461B4F9E.3030401@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: NETCONF Goes On Subject: [NGO] Re: multi-session locks X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Balazs Lengyel wrote: > Hello Andy, > For us the question is even more interesting, as parts of our big node > configuration might be administered by different people/organizations > using different management tools; so allowing operator A to deny > configuration operations for operator B sounds really bad. > > IMO we have here two separate questions: > - What can be locked: full data-store, a sub-tree, any group of managed > objects? Related config data can be spread around the entire XML tree. Limiting access to a single subtree will be too restrictive. Locking access by namespace or 'namespace owner' may also be too restrictive, given the various ways namespaces are used. You end up with an arbitrary Xpath expression for the lock, which can include all kinds of bizarre corner-cases where parts of the config transition in and out of locked state, as different clauses in the Xpath expression change value over time. (Not a fan of this 12 pound hammer for every job!) > - Who can used a locked entity: one session, any session connected to > one userId or groupId? Clearly the unit of measure is the session. The group of writers is an integral number of NETCONF sessions. > > IMO the first step in any lock related work is to allow the node to > reject the global lock, else some old manager application will come and > lock the whole node. Yes, but this falls out for free if the reason the agent is denying the lock is because some form of lock is already held. The logic for explicit locking is simple, and fits in with the current scheme: - If no-locks-held then grant lock request - If global lock held then deny lock request - If partial lock held then deny global lock request, but analyze partial lock request to determine if it can be granted - Dropped session only releases the lock held by that session, so if it is partial then other partial locks by other sessions are not affected. (This makes lock discovery an issue.) > > The next step (as you point out below) is that partial locking has a > difficulty with candidate configurations. At least commit, > discard-changes, delete-config and copy-config needs a full lock (or > rather an absence of any lock on any part of the datastore). > Theoretically we could have a partitioned candidate data-store with > partial commit etc. but I think that's too complicated to be usable. I think partial locking on a global candidate is very problematic. I don't want to rewrite any text in RFC 4741 related to commit, discard-changes, and confirmed-commit. We would need to introduce a candidate-per-session architecture, which is very TBD. > > All in all I see the following possibilities: > - A complete SQL-database-like implicit locking mechanism works well, > but might be a heavy task for small nodes > - I also see an important use-case in dividing up the configuration into > disjunct parts and locking those (e.g. a sub-tree). This way each > operator could configure his own part. It is not feasible to define the > sub-trees at design time. > - Multi-session locks can also be useful, if it is the same person/group > using the same lock simultaneously. We could utilize something like the > groupId or userId for this purpose. > > In our implementation we will have just a writable running config. The > size of this will be so big, that that alone precludes keeping a > candidate. The running datastore will work somewhat like a normal SQL > database. It locks what is needed without explicit lock operations. Even with implicit locking, it is important that the manager give explicit indications to the agent that it is: - starting a transaction - canceling a transaction - committing a transaction We already have the candidate model work this way for a global config, and changing the running config model to also work that way seems complicated and redundant. > > See also some comments below: > > Andy Bierman wrote: >> Hi Balazs, >> >> I am very interested in the partial database locking problem >> that we discussed at the last interim. I think that you are >> right wrt/ your concerns about the "1 user global lock" design >> for large devices. >> >> There are many issues with implicit locking, especially given >> our current architecture and lock operations. This approach >> won't work on the target unless operations are added >> to make it work like the model instead. This >> would defeat the purpose of having both and >> targets in the protocol. >> >> IMO it will take a lot of work to re-define either the >> or the write models to allow for collision-proof multi-user >> write access, using implicit locking. > [Balazs]: One solution is to say locking is a completely internal, > implementation specific issue, so we can avoid redefining most parts of > the protocol. If part or the whole of an operation (edit-config, > copy-config, etc.) fails due to internal locking, that is handled the > same way as any other internal error. Even today we can not guarantee > that all set/create sub-operations will succeed. Still it would be good > to tell the client that the operation failed (temporarily?) due to > locking, so he will not try to find bugs in the operation's data. >> >> Yet, explicit locking doesn't look so great either. Is the agent >> going to reject an edit-config operation if part of it touches >> a locked sub-tree and part of it touches an unlocked sub-tree? > [Balazs}: IMHO failure due to locking can be handled as just any other > internal failure. E.g. one due to running out of memory. In my > understanding the edit-config error-option will be able to handle this. > Do you agree? >> The edit-config operation is designed to work with or without locks, >> so rejecting an edit-config operation this way seems wrong. >> What happens if another session comes along and locks the altered >> but unlocked sub-tree? At least explicit locking works the same >> whether the target is or . >> >> One workaround that occurred to me: >> >> Why not let the managers worry about database collisions with a >> multi-session >> lock mechanism that works like an access control list, except the >> resource is the lock, not the data itself. In other words, the >> manager configures which sessions can share a lock, based on data >> outside the scope of the standard. For example, what if the group-id >> was used by the agent instead of the session-id, when checking lock >> access? >> (Access control, users and groups, etc. out of scope for now.) >> >> The grouping could also be an internal implementation detail, >> such as all 'sibling' virtual routers associated with one real router. >> >> IMO, this approach is better than not using locks at all, >> because unwanted edit-config access will be rejected if the 'group' >> is configured correctly. Also, no other application will be able >> to grab the global lock, ruining the cooperative locking in progress. >> >> How do you think the protocol should support multi-session locks? > [Balazs]: Multi-session locks are useful, but they solve only part of > the problem. We already have big nodes where different people configure > different parts of the system, so we would like to be able to lock just > part of the node. If the involved people are geographically separated > multi-session locks don't solve this problem. >> >> thanks, >> Andy >> >> > Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Apr 10 11:06:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHvT-0002Y8-8B; Tue, 10 Apr 2007 11:06:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHvR-0002Y2-Tu for ngo@ietf.org; Tue, 10 Apr 2007 11:06:29 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbHvH-0005eF-SS for ngo@ietf.org; Tue, 10 Apr 2007 11:06:29 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 439C520822; Tue, 10 Apr 2007 17:06:17 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-df-461ba7e9d4dd Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2C5CE2061F; Tue, 10 Apr 2007 17:06:17 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 17:06:16 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 17:06:16 +0200 Message-ID: <461BA7E8.7070201@ericsson.com> Date: Tue, 10 Apr 2007 17:06:16 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Andy Bierman References: <461A540A.30407@andybierman.com> <461B4F9E.3030401@ericsson.com> <461BA0DB.6090500@andybierman.com> In-Reply-To: <461BA0DB.6090500@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 15:06:16.0492 (UTC) FILETIME=[C97F76C0:01C77B81] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: NETCONF Goes On Subject: [NGO] Re: multi-session locks X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Hello Andy, Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello Andy, >> For us the question is even more interesting, as parts of our big node >> configuration might be administered by different people/organizations >> using different management tools; so allowing operator A to deny >> configuration operations for operator B sounds really bad. >> >> IMO we have here two separate questions: >> - What can be locked: full data-store, a sub-tree, any group of >> managed objects? > > Related config data can be spread around the entire XML tree. > Limiting access to a single subtree will be too restrictive. > Locking access by namespace or 'namespace owner' may also > be too restrictive, given the various ways namespaces are used. [Balazs]: It can be spread out, but often it is not. I believe a subtree based locking could be useful for many users. E.g. our node includes both a gateway and a router. In this case there is a natural division of config data into sub-trees. Also while working with British Telecom I saw that they had separate (human) operators for performance management. In many nodes administering PM data was in a separate sub-tree from the rest of configuration. > > You end up with an arbitrary Xpath expression for the lock, > which can include all kinds of bizarre corner-cases where > parts of the config transition in and out of locked state, > as different clauses in the Xpath expression change value over time. > (Not a fan of this 12 pound hammer for every job!) [Balazs]: I agree that the full XPATH is a heavy hammer, but we could leave it to the implementors to decide if they want just sub-trees, or the full heavy hammer or nothing. > >> - Who can used a locked entity: one session, any session connected to >> one userId or groupId? > > Clearly the unit of measure is the session. > The group of writers is an integral number of NETCONF sessions. [Balazs]: Agree. > >> >> IMO the first step in any lock related work is to allow the node to >> reject the global lock, else some old manager application will come >> and lock the whole node. > > Yes, but this falls out for free if the reason the agent is denying > the lock is because some form of lock is already held. The logic > for explicit locking is simple, and fits in with the current scheme: > > - If no-locks-held then grant lock request > - If global lock held then deny lock request > - If partial lock held then deny global lock request, but > analyze partial lock request to determine if it can be granted > - Dropped session only releases the lock held by that session, > so if it is partial then other partial locks by other sessions > are not affected. (This makes lock discovery an issue.) [Balazs]: I might want to disallow global locking, because I always want the partial lock to be always available, but maybe this can be left to the specific access control model. > > >> >> The next step (as you point out below) is that partial locking has a >> difficulty with candidate configurations. At least commit, >> discard-changes, delete-config and copy-config needs a full lock (or >> rather an absence of any lock on any part of the datastore). >> Theoretically we could have a partitioned candidate data-store with >> partial commit etc. but I think that's too complicated to be usable. > > > I think partial locking on a global candidate is very problematic. > I don't want to rewrite any text in RFC 4741 related to commit, > discard-changes, and confirmed-commit. We would need to introduce > a candidate-per-session architecture, which is very TBD. [Balazs]: Agree, it would be too complicated. > >> >> All in all I see the following possibilities: >> - A complete SQL-database-like implicit locking mechanism works well, >> but might be a heavy task for small nodes >> - I also see an important use-case in dividing up the configuration >> into disjunct parts and locking those (e.g. a sub-tree). This way each >> operator could configure his own part. It is not feasible to define >> the sub-trees at design time. >> - Multi-session locks can also be useful, if it is the same >> person/group using the same lock simultaneously. We could utilize >> something like the groupId or userId for this purpose. >> >> In our implementation we will have just a writable running config. The >> size of this will be so big, that that alone precludes keeping a >> candidate. The running datastore will work somewhat like a normal SQL >> database. It locks what is needed without explicit lock operations. > > > Even with implicit locking, it is important that the manager > give explicit indications to the agent that it is: > - starting a transaction > - canceling a transaction > - committing a transaction > > We already have the candidate model work this way for a global config, > and changing the running config model to also work that way seems > complicated and redundant. [Balazs]: You don't need explicit transactions for this. You just lock the config and handle each edit-config as a separate transaction. IMO we already have 2 transaction models in Netconf. One with the candidate configuration the other without. Without all you have is: one operation is one transaction with roll-back-on-error. Also there are nodes out there that already work with explicit start-cancel-commit transaction operations (not yet on Netconf). I know of a company (not mine) who is already implementing explicit start-cancel-commit transaction Netconf operations. > > >> >> See also some comments below: >> >> Andy Bierman wrote: >>> Hi Balazs, >>> >>> I am very interested in the partial database locking problem >>> that we discussed at the last interim. I think that you are >>> right wrt/ your concerns about the "1 user global lock" design >>> for large devices. >>> _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Tue Apr 10 13:38:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKIQ-0003mx-Qc; Tue, 10 Apr 2007 13:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKIQ-0003ms-40 for ngo@ietf.org; Tue, 10 Apr 2007 13:38:22 -0400 Received: from omr7.networksolutionsemail.com ([205.178.146.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbKIN-00058J-OF for ngo@ietf.org; Tue, 10 Apr 2007 13:38:22 -0400 Received: from mail.networksolutionsemail.com (ns-omr7.mgt.hosting.dc2.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l3AHcJeK010848 for ; Tue, 10 Apr 2007 13:38:19 -0400 Received: (qmail 4297 invoked by uid 78); 10 Apr 2007 17:38:19 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 10 Apr 2007 17:38:19 -0000 Message-ID: <461BCB6B.8000906@andybierman.com> Date: Tue, 10 Apr 2007 10:37:47 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Balazs Lengyel References: <461A540A.30407@andybierman.com> <461B4F9E.3030401@ericsson.com> <461BA0DB.6090500@andybierman.com> <461BA7E8.7070201@ericsson.com> In-Reply-To: <461BA7E8.7070201@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: NETCONF Goes On Subject: [NGO] Re: multi-session locks X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Balazs Lengyel wrote: > Hello Andy, > > Andy Bierman wrote: >> Balazs Lengyel wrote: >>> Hello Andy, >>> For us the question is even more interesting, as parts of our big >>> node configuration might be administered by different >>> people/organizations using different management tools; so allowing >>> operator A to deny configuration operations for operator B sounds >>> really bad. >>> >>> IMO we have here two separate questions: >>> - What can be locked: full data-store, a sub-tree, any group of >>> managed objects? >> >> Related config data can be spread around the entire XML tree. >> Limiting access to a single subtree will be too restrictive. >> Locking access by namespace or 'namespace owner' may also >> be too restrictive, given the various ways namespaces are used. > [Balazs]: It can be spread out, but often it is not. I believe a subtree > based locking could be useful for many users. E.g. our node includes > both a gateway and a router. In this case there is a natural division of > config data into sub-trees. Also while working with British Telecom I > saw that they had separate (human) operators for performance management. > In many nodes administering PM data was in a separate sub-tree from the > rest of configuration. >> >> You end up with an arbitrary Xpath expression for the lock, >> which can include all kinds of bizarre corner-cases where >> parts of the config transition in and out of locked state, >> as different clauses in the Xpath expression change value over time. >> (Not a fan of this 12 pound hammer for every job!) > [Balazs]: I agree that the full XPATH is a heavy hammer, but we could > leave it to the implementors to decide if they want just sub-trees, or > the full heavy hammer or nothing. What if the Xpath expression include sub-expressions that have nothing to do with identifying the conceptual objects and instances being locked? If it was limited to an absolute path expression, that simply identified a single XML element within the tree, or an Instance Identifier that just included the XML elements that made up the key, then I would like it much better. Using a 12 lb. hammer drives the little finishing nail real quick, but it leaves a big dent in the furniture if slightly misused. IMO, arbitray Xpath locks will create many unintended consequences than we should avoid rather than cope with forever. >> >>> - Who can used a locked entity: one session, any session connected to >>> one userId or groupId? >> >> Clearly the unit of measure is the session. >> The group of writers is an integral number of NETCONF sessions. > [Balazs]: Agree. >> >>> >>> IMO the first step in any lock related work is to allow the node to >>> reject the global lock, else some old manager application will come >>> and lock the whole node. >> >> Yes, but this falls out for free if the reason the agent is denying >> the lock is because some form of lock is already held. The logic >> for explicit locking is simple, and fits in with the current scheme: >> >> - If no-locks-held then grant lock request >> - If global lock held then deny lock request >> - If partial lock held then deny global lock request, but >> analyze partial lock request to determine if it can be granted >> - Dropped session only releases the lock held by that session, >> so if it is partial then other partial locks by other sessions >> are not affected. (This makes lock discovery an issue.) > [Balazs]: I might want to disallow global locking, because I always want > the partial lock to be always available, but maybe this can be left to > the specific access control model. >> >> What session-id do you put in the when you reject the lock request for no reason? IMO, the partial lock has to work in a way that is compatible with the global lock, in every way, even the required fields in the info. >>> >>> The next step (as you point out below) is that partial locking has a >>> difficulty with candidate configurations. At least commit, >>> discard-changes, delete-config and copy-config needs a full lock (or >>> rather an absence of any lock on any part of the datastore). >>> Theoretically we could have a partitioned candidate data-store with >>> partial commit etc. but I think that's too complicated to be usable. >> >> >> I think partial locking on a global candidate is very problematic. >> I don't want to rewrite any text in RFC 4741 related to commit, >> discard-changes, and confirmed-commit. We would need to introduce >> a candidate-per-session architecture, which is very TBD. > [Balazs]: Agree, it would be too complicated. >> >>> >>> All in all I see the following possibilities: >>> - A complete SQL-database-like implicit locking mechanism works well, >>> but might be a heavy task for small nodes >>> - I also see an important use-case in dividing up the configuration >>> into disjunct parts and locking those (e.g. a sub-tree). This way >>> each operator could configure his own part. It is not feasible to >>> define the sub-trees at design time. >>> - Multi-session locks can also be useful, if it is the same >>> person/group using the same lock simultaneously. We could utilize >>> something like the groupId or userId for this purpose. >>> >>> In our implementation we will have just a writable running config. >>> The size of this will be so big, that that alone precludes keeping a >>> candidate. The running datastore will work somewhat like a normal SQL >>> database. It locks what is needed without explicit lock operations. >> >> >> Even with implicit locking, it is important that the manager >> give explicit indications to the agent that it is: >> - starting a transaction >> - canceling a transaction >> - committing a transaction >> >> We already have the candidate model work this way for a global config, >> and changing the running config model to also work that way seems >> complicated and redundant. > [Balazs]: You don't need explicit transactions for this. You just lock > the config and handle each edit-config as a separate transaction. The whole point of locking is to have an edit transaction that includes multiple edit-configs, maybe some operations, etc. > IMO we already have 2 transaction models in Netconf. One with the > candidate configuration the other without. Without all you have is: one > operation is one transaction with roll-back-on-error. > Also there are nodes out there that already work with explicit > start-cancel-commit transaction operations (not yet on Netconf). I know > of a company (not mine) who is already implementing explicit > start-cancel-commit transaction Netconf operations. >> >> >>> >>> See also some comments below: >>> >>> Andy Bierman wrote: >>>> Hi Balazs, >>>> >>>> I am very interested in the partial database locking problem >>>> that we discussed at the last interim. I think that you are >>>> right wrt/ your concerns about the "1 user global lock" design >>>> for large devices. >>>> > > Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Wed Apr 11 03:24:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXBc-0000cn-3m; Wed, 11 Apr 2007 03:24:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXBa-0000ci-MI for ngo@ietf.org; Wed, 11 Apr 2007 03:24:10 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbXBR-0005hq-QM for ngo@ietf.org; Wed, 11 Apr 2007 03:24:10 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 01897214C3; Wed, 11 Apr 2007 09:23:49 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-5c-461c8d047d3f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D5FD8214A5; Wed, 11 Apr 2007 09:23:48 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 09:23:48 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 09:23:48 +0200 Message-ID: <461C8CFF.5050400@ericsson.com> Date: Wed, 11 Apr 2007 09:23:43 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Andy Bierman References: <461A540A.30407@andybierman.com> <461B4F9E.3030401@ericsson.com> <461BA0DB.6090500@andybierman.com> <461BA7E8.7070201@ericsson.com> <461BCB6B.8000906@andybierman.com> In-Reply-To: <461BCB6B.8000906@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2007 07:23:48.0247 (UTC) FILETIME=[58AB0A70:01C77C0A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: NETCONF Goes On Subject: [NGO] Re: multi-session locks X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Andy Bierman wrote: > Balazs Lengyel wrote: >> Hello Andy, >> >> Andy Bierman wrote: >>> Balazs Lengyel wrote: >>>> Hello Andy, >>>> For us the question is even more interesting, as parts of our big >>>> node configuration might be administered by different >>>> people/organizations using different management tools; so allowing >>>> operator A to deny configuration operations for operator B sounds >>>> really bad. >>>> >>>> IMO we have here two separate questions: >>>> - What can be locked: full data-store, a sub-tree, any group of >>>> managed objects? >>> >>> Related config data can be spread around the entire XML tree. >>> Limiting access to a single subtree will be too restrictive. >>> Locking access by namespace or 'namespace owner' may also >>> be too restrictive, given the various ways namespaces are used. >> [Balazs]: It can be spread out, but often it is not. I believe a >> subtree based locking could be useful for many users. E.g. our node >> includes both a gateway and a router. In this case there is a natural >> division of config data into sub-trees. Also while working with >> British Telecom I saw that they had separate (human) operators for >> performance management. In many nodes administering PM data was in a >> separate sub-tree from the rest of configuration. >>> >>> You end up with an arbitrary Xpath expression for the lock, >>> which can include all kinds of bizarre corner-cases where >>> parts of the config transition in and out of locked state, >>> as different clauses in the Xpath expression change value over time. >>> (Not a fan of this 12 pound hammer for every job!) >> [Balazs]: I agree that the full XPATH is a heavy hammer, but we could >> leave it to the implementors to decide if they want just sub-trees, or >> the full heavy hammer or nothing. > > What if the Xpath expression include sub-expressions that have nothing > to do with identifying the conceptual objects and instances being locked? > If it was limited to an absolute path expression, that simply identified > a single XML element within the tree, or an Instance Identifier > that just included the XML elements that made up the key, > then I would like it much better. > > Using a 12 lb. hammer drives the little finishing nail real quick, > but it leaves a big dent in the furniture if slightly misused. > IMO, arbitray Xpath locks will create many unintended consequences > than we should avoid rather than cope with forever. [Balazs]: I agree that the filter can become dangerously complicated. So selecting just one element and the underlying sub-tree is a good choice. I would also allow selecting multiple disjoint sub-trees as I believe thats not so complicated, but nothing more complicated. In Hungary we also have 40 lb hammers at least better locksmiths :-) > >>> >>>> - Who can used a locked entity: one session, any session connected >>>> to one userId or groupId? >>> >>> Clearly the unit of measure is the session. >>> The group of writers is an integral number of NETCONF sessions. >> [Balazs]: Agree. >>> >>>> >>>> IMO the first step in any lock related work is to allow the node to >>>> reject the global lock, else some old manager application will come >>>> and lock the whole node. >>> >>> Yes, but this falls out for free if the reason the agent is denying >>> the lock is because some form of lock is already held. The logic >>> for explicit locking is simple, and fits in with the current scheme: >>> >>> - If no-locks-held then grant lock request >>> - If global lock held then deny lock request >>> - If partial lock held then deny global lock request, but >>> analyze partial lock request to determine if it can be granted >>> - Dropped session only releases the lock held by that session, >>> so if it is partial then other partial locks by other sessions >>> are not affected. (This makes lock discovery an issue.) >> [Balazs]: I might want to disallow global locking, because I always >> want the partial lock to be always available, but maybe this can be >> left to the specific access control model. >>> >>> > > > What session-id do you put in the when you reject the lock > request for no reason? IMO, the partial lock has to work in a way > that is compatible with the global lock, in every way, even the > required fields in the info. [Balazs]: I will say access-denied and provide no session info. This also indicates that the denial is not temporary. > > >>>> >>>> The next step (as you point out below) is that partial locking has a >>>> difficulty with candidate configurations. At least commit, >>>> discard-changes, delete-config and copy-config needs a full lock (or >>>> rather an absence of any lock on any part of the datastore). >>>> Theoretically we could have a partitioned candidate data-store with >>>> partial commit etc. but I think that's too complicated to be usable. >>> >>> >>> I think partial locking on a global candidate is very problematic. >>> I don't want to rewrite any text in RFC 4741 related to commit, >>> discard-changes, and confirmed-commit. We would need to introduce >>> a candidate-per-session architecture, which is very TBD. >> [Balazs]: Agree, it would be too complicated. >>> >>>> >>>> All in all I see the following possibilities: >>>> - A complete SQL-database-like implicit locking mechanism works >>>> well, but might be a heavy task for small nodes >>>> - I also see an important use-case in dividing up the configuration >>>> into disjunct parts and locking those (e.g. a sub-tree). This way >>>> each operator could configure his own part. It is not feasible to >>>> define the sub-trees at design time. >>>> - Multi-session locks can also be useful, if it is the same >>>> person/group using the same lock simultaneously. We could utilize >>>> something like the groupId or userId for this purpose. >>>> >>>> In our implementation we will have just a writable running config. >>>> The size of this will be so big, that that alone precludes keeping a >>>> candidate. The running datastore will work somewhat like a normal >>>> SQL database. It locks what is needed without explicit lock operations. >>> >>> >>> Even with implicit locking, it is important that the manager >>> give explicit indications to the agent that it is: >>> - starting a transaction >>> - canceling a transaction >>> - committing a transaction >>> >>> We already have the candidate model work this way for a global config, >>> and changing the running config model to also work that way seems >>> complicated and redundant. >> [Balazs]: You don't need explicit transactions for this. You just lock >> the config and handle each edit-config as a separate transaction. > > > The whole point of locking is to have an edit transaction > that includes multiple edit-configs, maybe some operations, etc. [Balazs]: Agree, but having a one-operation transaction is better then nothing, and for some nodes using candidate-configuration is simply not possible; but we still love Netconf :-). The explicit transaction operations will also help. > > >> IMO we already have 2 transaction models in Netconf. One with the >> candidate configuration the other without. Without all you have is: >> one operation is one transaction with roll-back-on-error. >> Also there are nodes out there that already work with explicit >> start-cancel-commit transaction operations (not yet on Netconf). I >> know of a company (not mine) who is already implementing explicit >> start-cancel-commit transaction Netconf operations. >>> >>> >>>> >>>> See also some comments below: >>>> >>>> Andy Bierman wrote: >>>>> Hi Balazs, >>>>> >>>>> I am very interested in the partial database locking problem >>>>> that we discussed at the last interim. I think that you are >>>>> right wrt/ your concerns about the "1 user global lock" design >>>>> for large devices. >>>>> >> >> > > Andy -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Sun Apr 15 01:11:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcx0H-0006Xt-BU; Sun, 15 Apr 2007 01:10:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcx0F-0006Xc-S5; Sun, 15 Apr 2007 01:10:19 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcx0E-0007Tz-Hr; Sun, 15 Apr 2007 01:10:19 -0400 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 15 Apr 2007 01:10:17 -0400 X-IronPort-AV: i="4.14,411,1170651600"; d="txt'?scan'208"; a="3771386:sNHT9611070" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C77F1C.5B631236" Date: Sun, 15 Apr 2007 08:10:17 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [New-work] OMA New Work - 1 New Work Item Approved] Thread-Index: Acd/GTHohag0tBXbRYS+G5lJitVfRAAAudYQ From: "Romascanu, Dan \(Dan\)" To: , "NETCONF Goes On" X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Subject: [NGO] FW: [Fwd: [New-work] OMA New Work - 1 New Work Item Approved] X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C77F1C.5B631236 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that this may be of some interest.=20 Dan =20 -----Original Message----- From: Loa Andersson [mailto:loa@pi.se]=20 Sent: Sunday, April 15, 2007 7:47 AM To: IAB; Iesg (E-mail) Subject: [Fwd: [New-work] OMA New Work - 1 New Work Item Approved] FYI /Loa -------- Original Message -------- Subject: [New-work] OMA New Work - 1 New Work Item Approved Date: Thu, 12 Apr 2007 16:06:16 +0200 From: Victoria Gray To: Dear All, OMA would like to inform all the organisations subscribed to the IETF new-work list of the approval of 1 revised work item: 1 Lock and Wipe Management Object WI: http://www.openmobilealliance.org/ftp/Public_documents/TP/Permanent_docu ments/OMA-WID_0144-LAWMO-V1_0-20070410-A.zip The overall goal of the LAWMO is, to provide Management Authorities (e.g. Operators, Device Manufacturers and 3rd party service providers) an effective way to help their subscribers protect their devices and data. Based on the above, it is proposed that the work item will address the following areas: 1) Support the capability to lock terminal interface functions. In the case of lock all terminal interface functionality the terminal should only allow: incoming calls, emergency calls and data sessions. 2) Support capability to unlock the user interface on the device. 3) When the phone is in the lock state the terminal must accept remote management only from the Authorised DM Server that invoked the Lock function in the first place. No user input will be required to action these operations. 4) Support capability to wipe user data from the device. 5) Support resetting the terminal to a factory clean state. This means clearing of memory and initialisation of the file systems and databases in the terminal. 6) The LAWMO will indicate the lock, unlock or wipe operation which needs to be executed but the actual operation processing and which part of user data to be locked, unlocked or wiped is out of scope of this work item.. This work item has been allocated to the OMA DM (Device Management WG) for specification development. Best regards, Victoria Gray on behalf of OMA. Victoria Gray FORApolis / DSO Tel +33 (0)4 92 94 49 23 Fax +33 (0)4 92 38 49 23 GSM +33 (0)6 73 99 62 90 victoria.gray@forapolis.com MSN: victoria.gray@forapolis.com Yahoo!: bluevicci Skype: victoria-gray Google: vics.gray@gmail.com -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se ------_=_NextPart_001_01C77F1C.5B631236 Content-Type: text/plain; name="ATT578925.txt" Content-Transfer-Encoding: base64 Content-Description: ATT578925.txt Content-Disposition: attachment; filename="ATT578925.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldy13b3Jr IG1haWxpbmcgbGlzdA0KTmV3LXdvcmtAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldy13b3JrDQoNCg== ------_=_NextPart_001_01C77F1C.5B631236 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo ------_=_NextPart_001_01C77F1C.5B631236-- From ngo-bounces@ietf.org Fri Apr 20 05:24:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepM3-0000w5-Md; Fri, 20 Apr 2007 05:24:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepM2-0000vz-3N for ngo@ietf.org; Fri, 20 Apr 2007 05:24:34 -0400 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HepM0-0004Ok-3K for ngo@ietf.org; Fri, 20 Apr 2007 05:24:33 -0400 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id 1C4D41B80C3; Fri, 20 Apr 2007 11:24:29 +0200 (CEST) Date: Fri, 20 Apr 2007 11:24:15 +0200 (CEST) Message-Id: <20070420.112415.01034119.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [NGO] multi-session locks From: Martin Bjorklund In-Reply-To: <461A540A.30407@andybierman.com> References: <461A540A.30407@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Andy Bierman wrote: > Hi Balazs, > > I am very interested in the partial database locking problem > that we discussed at the last interim. So am I. > Yet, explicit locking doesn't look so great either. Is the agent > going to reject an edit-config operation if part of it touches > a locked sub-tree and part of it touches an unlocked sub-tree? No. > The edit-config operation is designed to work with or without locks, > so rejecting an edit-config operation this way seems wrong. I agree. > What happens if another session comes along and locks the altered > but unlocked sub-tree? Nothing special. > At least explicit locking works the same > whether the target is or . Yes, IMO explicit partial locking with no special semantics (like rolling back uncommitted changes) is sufficient. > I think partial locking on a global candidate is very problematic. > I don't want to rewrite any text in RFC 4741 related to commit, > discard-changes, and confirmed-commit. We would need to introduce a > candidate-per-session architecture, which is very TBD. Could you elaborate on this a bit? Why is partial locking on the global candidate problematic? IMO, the semantics of edit-configs should be the same with a partial lock as without a lock when noone else is modifying the datastore. I also like the idea of using the xpath-based instance identifier syntax to lock subtrees. /martin _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Fri Apr 20 07:49:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Herc4-0001N2-Cg; Fri, 20 Apr 2007 07:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Herc2-0001Mn-PA for ngo@ietf.org; Fri, 20 Apr 2007 07:49:14 -0400 Received: from smtp101.sbc.mail.mud.yahoo.com ([68.142.198.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Herc1-0001YF-CE for ngo@ietf.org; Fri, 20 Apr 2007 07:49:14 -0400 Received: (qmail 62219 invoked from network); 20 Apr 2007 11:49:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.217 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 20 Apr 2007 11:49:12 -0000 X-YMail-OSG: O4WGzVMVM1kTFhCmLUi4l.k8upW88doQnIBMCjJ8kG.zdplE Message-ID: <4628A89B.9070208@andybierman.com> Date: Fri, 20 Apr 2007 04:48:43 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [NGO] multi-session locks References: <461A540A.30407@andybierman.com> <20070420.112415.01034119.mbj@tail-f.com> In-Reply-To: <20070420.112415.01034119.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi Balazs, >> >> I am very interested in the partial database locking problem >> that we discussed at the last interim. > > So am I. > >> Yet, explicit locking doesn't look so great either. Is the agent >> going to reject an edit-config operation if part of it touches >> a locked sub-tree and part of it touches an unlocked sub-tree? > > No. > >> The edit-config operation is designed to work with or without locks, >> so rejecting an edit-config operation this way seems wrong. > > I agree. > >> What happens if another session comes along and locks the altered >> but unlocked sub-tree? > > Nothing special. > >> At least explicit locking works the same >> whether the target is or . > > > Yes, IMO explicit partial locking with no special semantics (like > rolling back uncommitted changes) is sufficient. > >> I think partial locking on a global candidate is very problematic. >> I don't want to rewrite any text in RFC 4741 related to commit, >> discard-changes, and confirmed-commit. We would need to introduce a >> candidate-per-session architecture, which is very TBD. > > Could you elaborate on this a bit? Why is partial locking on the > global candidate problematic? > The transaction sequence (lock+edit+commit+unlock) does not work independently like it would if the candidate config was per-session, instead of global. Once the first writer does a commit, the entire config is committed, not just the part that this writer locked (or wrote). Also, the way candidate is written, once the candidate is written with an edit, nobody else can take out the lock, even if that first writer didn't take out a lock at all. There is also a access control deadlock concern with candidate, that gets a little worse with partial locks. Let's say session A can modify one sub-tree and session B can modify a different subtree, but not the other way around. If both sessions write to the candidate config, then neither one of them will be able to commit it, because it contains edits in an area each one is denied write access. If this data is also locked, then a third session with write access to everything cannot undo part of the edits and commit the rest. The operations are applied rather unevenly, since you can configure access control to allow a 'root' user to commit another user's edits, but there is no way for root to undo another user's lock. There is only 'kill-session', which causes the entire candidate config to to a discard-changes when the session is killed. > IMO, the semantics of edit-configs should be the same with a partial > lock as without a lock when noone else is modifying the datastore. > > I also like the idea of using the xpath-based instance identifier > syntax to lock subtrees. > > > > /martin > > Andy _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo From ngo-bounces@ietf.org Fri Apr 20 08:00:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hern7-0004Cs-Se; Fri, 20 Apr 2007 08:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hern6-0004CX-EY for ngo@ietf.org; Fri, 20 Apr 2007 08:00:40 -0400 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hern5-0004M1-W4 for ngo@ietf.org; Fri, 20 Apr 2007 08:00:40 -0400 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id 4A2CC1B80C3; Fri, 20 Apr 2007 14:00:37 +0200 (CEST) Date: Fri, 20 Apr 2007 14:00:24 +0200 (CEST) Message-Id: <20070420.140024.114376807.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [NGO] multi-session locks From: Martin Bjorklund In-Reply-To: <4628A89B.9070208@andybierman.com> References: <461A540A.30407@andybierman.com> <20070420.112415.01034119.mbj@tail-f.com> <4628A89B.9070208@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ngo@ietf.org X-BeenThere: ngo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ngo-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> I think partial locking on a global candidate is very problematic. > >> I don't want to rewrite any text in RFC 4741 related to commit, > >> discard-changes, and confirmed-commit. We would need to introduce a > >> candidate-per-session architecture, which is very TBD. > > > > Could you elaborate on this a bit? Why is partial locking on the > > global candidate problematic? > > > > The transaction sequence (lock+edit+commit+unlock) does not > work independently like it would if the candidate config was > per-session, instead of global. Once the first writer > does a commit, the entire config is committed, not just the > part that this writer locked (or wrote). > > Also, the way candidate is written, once the candidate is written > with an edit, nobody else can take out the lock, even if that > first writer didn't take out a lock at all. > > There is also a access control deadlock concern with candidate, > that gets a little worse with partial locks. Let's say session A can > modify one sub-tree and session B can modify a different subtree, > but not the other way around. If both sessions write to the > candidate config, then neither one of them will be able > to commit it, because it contains edits in an area each > one is denied write access. > > If this data is also locked, then a third session with write access > to everything cannot undo part of the edits and commit the rest. > The operations are applied rather unevenly, since you can configure > access control to allow a 'root' user to commit another user's edits, > but there is no way for root to undo another user's lock. The same situation occurs if no partial locks are involved - user A modifies parts of the shared candidate, and B some other parts. Neither A or B can commit. So 'root' comes in and either commits or reverts. > There is only 'kill-session', which causes the entire candidate > config to to a discard-changes when the session is killed. ...provided that the session which is killed has the *global* lock. My point is that IMO we don't have to use this semantics for the partial lock mechanism. That's what I meant when I wrote: > > IMO, the semantics of edit-configs should be the same with a partial > > lock as without a lock when noone else is modifying the datastore. and > > Yes, IMO explicit partial locking with no special semantics (like > > rolling back uncommitted changes) is sufficient. /martin _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo