From owner-netconf@ops.ietf.org Tue Jun 1 16:28:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22210 for ; Tue, 1 Jun 2004 16:28:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVFdq-0002M4-Cq for netconf-data@psg.com; Tue, 01 Jun 2004 20:13:46 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVFdo-0002Lf-LV for netconf@ops.ietf.org; Tue, 01 Jun 2004 20:13:44 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2004 13:14:27 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i51KDfXl014535; Tue, 1 Jun 2004 13:13:41 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-142.cisco.com [10.21.96.142]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUV78931; Tue, 1 Jun 2004 13:13:40 -0700 (PDT) Message-Id: <6.1.1.1.2.20040601115616.039a7550@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 01 Jun 2004 13:08:33 -0700 To: Nathan Sowatskey From: Andy Bierman Subject: Re: NETCONF modelled in UML Cc: netconf@ops.ietf.org In-Reply-To: <1085388397.1839.23.camel@nsowatsk-lnx-t40.cisco.com> References: <1085388397.1839.23.camel@nsowatsk-lnx-t40.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 01:46 AM 5/24/2004, Nathan Sowatskey wrote: >All > >This email details an attempt by me to model the NETCONF specification in UML in preparation for implementing the specification. My basic conclusion was that the specification can not be implemented as it currently stands. I welcome challenges to that conclusion. > >Viewing the project and using Together >-------------------------------------- > >This is the first step in modelling NETCONF, which is to represent the >entities and their relationships in UML. For those who want to play with >the Together project itself, I have attached the whole thing zipped. > >If you want to edit the project, you will need to get Together 6.1 from Borland.com (just fill in the >evaluation form and download it) an apply for an evaluation licence if you need it. > >You don't need Together to view the diagrams, which are gifs, or the code, all of which are in the attached zip file. > >Once you have done that, open the attached file somewhere convenient, >windows or Linux/Unix. Open the NETCONF.tpr file, and you will be away! > >If you just want to look at the diagrams, then they are in the diagrams >directory of the attached file. There are two diagrams, netconf.gif and >rpc.gif. There are also many notes in the source files also, which are >under src, which you can look at with the aid of a normal editor. > >Discussion of the model - Operations and arguments >-------------------------------------------------- > >Whilst this is a UML *model*, and is thus distinct from any specific >implementation, implementation concerns always play a role in modelling, >much as normalization does in data base modelling. I have thus >approached this modelling exercise as though I were going to implement >the specification, as indeed I am, from a top down perspective, rather >than the bottom up approach that the specification takes. IMO, although interesting, development of a UML model is out of scope for the NETCONF v1.0 document set. We will focus on the document clarity issues you are raising instead. >One of the first challenges that I encountered with reverse engineering >a model from the specification was separating the RPC implementation >from the operations. > >Having the rpc-reply element as part of the signature of the operations, >the fact that some arguments are parameters, whilst others are >attributes, and the use of '<>'s everywhere couples the operations to >the underlying XML implementation. This coupling is probably not the >intention of the specification writers, but it is there nevertheless. Not sure what this comment means. If it means we are putting a stake in the ground wrt/ XML syntax and XSD representation (at a minimum) of protocol messages data models, then it is intentional. That's in the charter, and IMO it's important that we try to stay within that scope. >Another challenge was the inconsistent declaration of "format" argument. >It is implied in the text descriptions, so I have included a Format >object as an operation parameter which is an enumeration of two types: >XML and Text. I suspect that there may be more types, and using an >enumeration is intrinsically extensible. format is gone in -03. We will use namespaces to identify content format. We may also want to create some conventions for elements at some point (not coupled to v1.0 work). >The next challenge was to decide what the Configuration type should look >like. I have used a nested structure. This is a common design idiom >where a top level container contains a collection of something - >ConfigurationElement - that is a name/value pair, or a collection of >more of itself. Again, this is intrinsically extensible. Do you mean the data model structure or a model of the NETCONF protocol operations? The data model work is out of scope. The and elements are the the top-level containers. >I then needed to think about what the naming and types of the parameters >should be. I wasn't sure what the notation used in the specification was >meant to convey. An example being "source: @config-name". I took this to >mean that there was a parameter called source, which is the name of a >configuration, though the explanation refers to this being the name of a >configuration datastore. We need to fix this in the document. That shorthand I made up on the fly should be replaced with something else, like an ABNF. >In general I took the first part of the parameter name for the arguments >for the operations where that made sense. I also used String types by >default, except where the type was more specifically defined, either >because my modelling interpretation introduced it, or because it was >later specified by the Capabilities. The data types are (or should be) defined in the accompanying XSD, not in this text, and the document says that somewhere. >With the "config: @element-subtree" parameter, I made the decision that >this was actually the scope of the operation, that being the implication >of the explanation. In any case, I was able to use the same >Configuration type as the argument and the value of the configuration in >the reply, which was a useful modelling outcome, and may be what the >specification writers intended. This is the data model specific XML representation of the desired configuration changes. >The RPCreply type is a common pattern for RPCs where the encoding and/or >the implementation don't support exceptions. In this case we have a >container for the configuration, state and rpc-error elements. This can >be used over any RPC encoding scheme, which I believe was the intention of the specification writers. > >The State type posed a problem as it clearly exists in the >specification, but there is no indication of what it consists of. For >now I have included the type as a place holder, but I am unable to give >it any structure. Do you mean the netconf-state XSD in the draft? Not sure what State is in the protocol operations. >The RPCError type probably has more members than it needs. A minimum for >such a type would normally be the error code, non internationalised >error text, and a namespace to define the resource bundle that the >internationalised text would come from. The specification writers might >want to consider whether all of the other elements are really needed. The -03 version will have the updated section I sent to the mailing list a couple weeks ago. We will refine it from there. The -02 version has some problems that have hopefully been addressed. >The edit-config operation specifies attributes as well as parameters. >This is XML specific. I have modelled the "operation" attribute as a >parameter to the operation and created an enumerated type, >EditOperation. This also illustrates that having a parameter to an >operation called "operation" is not a good thing. It might have been >better to have three separate edit operations instead, which is another >modelling option that I considered, but have left out for now. We know it's XML-specific and that's not a concern of the WG. I'm more concerned that we document guidelines for writing XSDs that account for the operation attribute. >The copy-config operation has a source parameter which could be a name >of a configuration or a configuration itself. Since these are two >different types, I have had to create two arguments in the operation for >both cases. This is also the only operation where the format parameter >is explicitly specified, but it is also suggested that the format be >omitted for this operation. I wasn't sure what to make of that, so I >included format as a parameter anyway. The XSD is still kind of rough. We are still finalizing the semantics and the syntax hasn't caught up yet. The copy-config parameter is supposed to take on of: std config: , , local config example: file://foo-config.xml remote config example: ftp://example.com/configs/v1.1/foo-config.xml >The get-all operation specifies a state parameter which could be an >element-subtree (which I have modelled as a Configuration type >specifying the scope of the operation) or text. This led me to conclude >that the specification writers intended for there to be a format >parameter, so I have created one for this operation. text is out in -03 -- see above -- the config has to be valid XML >The kill-session operation specified the type of session-id to be an >integer. This is the first type definition in the specification. I can >see that the session-id is elsewhere specified as an int, but it might >better be a float, or a BIGINT. There is no guarantee on how big an int can be, but at least we can decide on an IEEE defined float as a number with a well specified range. Further, a positive integer means that we can't use -1 as a session-id which can sometimes be useful. this is more clarified in the -03 version. IMO, we don't need to make the SessionID a float. Billions of session IDs seems pretty sufficient to me. >Discussion of the model - Capabilities etc. >------------------------------------------- > >The next step in the modelling exercise is to decide how to model >Capabilities and the different operations associated with devices that >have them. > >The first point of difficulty is that the capabilities of a device are >determined during the transport set up when the session is first >established as part of the "hello" handshake. This is not a good thing. why not? They can also be read later from the netconf-state data model. >I have added an operation to the Device type (more on that later) which >supports the explicit discovery of capabilities after the transport has been established. This should be just more data available via the operation, not a special operation. The capabilities exchange is very important at session startup. If the capabilities don't meet application needs, then it's better to shut down the session and report the incompatibility problem to the user. >The Device type could have been called Server as the specification uses >both interchangeably. This is not a good idea. Typically the "server" >would, for most people, be the management software managing the device. >Since this is a peer-to-peer model, moreover, neither is really a server >in the client-server sense. The specification writers seem to have taken >the stance that the entity implementing the operations is the server. I >have chosen "Device" as that is much clearer. I'd suggest that the >specification writers do the same. We are trying to stick to manager and agent. We need to clean up this text. There is text that says we use client and server to mean manager and agent. This should be removed and the terminology cleaned up. >The Capability type is modelled with a namespace and a type which is >modelled as an enumeration. A Device has a collection of Capability(s). > >Each capability has associated with it a set of operations which are >additive in that a device can have the base operations, and the extra >operations associated with the additional capabilities. > >A problem arises in that some base operations are overloaded, i.e. >redefined, in a device that has a capability. Normally this would be >modelled by inheritance which would allow an operation in an inherited >type to redefine what the base operation does. Some capabilities represent the reality of massive quantities of deployed network devices with specific characteristics. Our prime directive is to create something vendors can implement and operators can use. Some capabilities represent a trade-off between complexity and scale. Certain features like rollback or XPath are expensive enough to be optional (at least for now). Tiny SOHO boxes may not have the resources to provide complex features like this. >In this case, as the capabilities are additive, but not mutually >exclusive, it is not clear how this would work. What happens, for >example, if a device has both the URL capability and the Candidate >capability? Both these capabilities define different versions of >edit-config. Which would apply? both -- I'm concerned that the spec describes the functionality, but not particular implementation strategies. Lots of capabilities work independently. This is no different than the current situation for developers. We are just trying to provide a mechanism to expose the operational capabilities in a standard protocol exchange. >For the time being I have chosen to model the operations as a collection >in the Device conceptually keyed by the capability that the operations >are associated with. This really makes the notion of a capability more >like that of a role. If that were the case, then one could decide what >role the device was fulfilling, and then choose the set of operations >that matched that role/capability. > >As things stand I am not sure if the model is correct or not, or whether >the specification writers have simply left this aspect unspecified. > >The specification defines an Agent capability, but all this seems to >indicate is that a peer is willing to be managed, which makes it a >Device. I think that the Manager and Agent capabilities are not >capabilities at all, but roles. It is also not clear what difference >they make in an implementation, except perhaps at the transport security >level. > >Where the capabilities modify existing operations, this is typically in a way that defines what the values of the arguments should be. In these cases this is not a modification of the operation, it is an implementation detail of how the operation should work. The edit-config and copy-config operations for the Writeable-Running capability are examples of this. I disagree. The XML syntax is not an implementation detail. We are defining an XML API, not an abstract information model. There is clear WG consensus that the use of XML syntax and XSD data modelling capabilities, as stated in the charter, is the right decision for the NETCONF protocol. >A slightly different case is the modification to the copy-config >operation for the Distinct Startup capability, which appears to specify >a completely different behaviour from the base operations. Yes, as documenting in the draft. This is the first type of capability -- aligning the protocol with reality instead of the other way around. >I have tried to capture the new and modified operations by redefining >the operations on a specific derived Operations type for the associated >capability. The diagram only reveals part of the story, so the notes in >the code will help to see what I have done here. > >The discard-changes operation for the Candidate Configuration capability >doesn't appear to have a return value, but I have added one as it is >clearly required. It should be or . What else is needed? >The get-config and edit-config modified operations for the Candidate >capability are specified to have a default target of the candidate >configuration. This should probably be the only value allowed. We discussed this and though we should keep the #candidate and #writable-running capabilities independent. I agree that it would be bad for an implementation to actually do this, so maybe we should make these capabilities mutually exclusive. >For it to >be described as "default" implies that there is a choice of some other >configuration, which wouldn't make sense for this capability. Also, >"target" probably means source for get-config, and target for >edit-config only. I think we discussed this and decided we can't really have a default in the XSD because XSD doesn't support it and the dual-target issue above. IMO, we should make this parameter mandatory because there's no way to keep implementations consistent on the default. I think Wes already brought this issue up and we agreed the default attribute in the XSD and this default text in the description should be removed. >As per the modelling question above, it is not clear whether a device >can have the Validate and Candidate capabilities at the same time. On a >point of consistency, the section for the Validate capability doesn't >mention any modifications to existing operations at all. Sure -- validate is independent of candidate. We do not have a database-like transaction model. We understand that edit-config operations can succeed on the and the can still fail because didn't check everything that can possibly go wrong during actual application of the desired config changes to the running state. >Summary >------- > >This review has highlighted some shortcomings in the specification from >an implementation perspective, and also from a system model perspective. >Ideally these would be addressed so that a definitive model could be >produced. thanks for your comments -- we will try to clarify the documents in the areas that are still rough or broken. Here's my list of issues your email has generated in this area: >That's all for now. I'd appreciate some feedback on this discussion. > >Many thanks > >Nathan Andy > >-- >Nathan Sowatskey - Technical Leader, NMTG CTO Engineering - Desk >+44-208-824-4259/+1-408-527-2595 - Mobile +44-7740-449794 - AIM id NathanCisco - >nsowatsk@cisco.com -- 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: From owner-netconf@ops.ietf.org Tue Jun 1 16:41:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23196 for ; Tue, 1 Jun 2004 16:41:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVFx8-0005U6-Fh for netconf-data@psg.com; Tue, 01 Jun 2004 20:33:42 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVFx5-0005Tk-Td for netconf@ops.ietf.org; Tue, 01 Jun 2004 20:33:39 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2004 13:33:28 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i51KXbls029920; Tue, 1 Jun 2004 13:33:38 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-142.cisco.com [10.21.96.142]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUV81728; Tue, 1 Jun 2004 13:33:36 -0700 (PDT) Message-Id: <6.1.1.1.2.20040601131602.03b1b110@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 01 Jun 2004 13:28:30 -0700 To: Nathan Sowatskey , netconf@ops.ietf.org From: Andy Bierman Subject: Re: NETCONF modelled in UML In-Reply-To: <6.1.1.1.2.20040601115616.039a7550@fedex.cisco.com> References: <1085388397.1839.23.camel@nsowatsk-lnx-t40.cisco.com> <6.1.1.1.2.20040601115616.039a7550@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 01:08 PM 6/1/2004, Andy Bierman wrote: oops -- fat-fingered 'send' before adding the summary of action items at the end: - replace ad-hoc parameter syntax in the operation descriptions like '@config-name' to something more precise, like ABNF - need to add new and error code text to -03 and review/refine it from there - document guidelines for writing XSDs that account for the operation attribute - cleanup XSDs in the protocol draft to align with the related text about the protocol operation syntax elsewhere in the draft - cleanup terminology related to manager/agent vs. client/server; don't use client/server terminology at all - decide if #candidate and #writable-running should be mutually exclusive capabilities instead of independent of each other - remove defaults for edit-config (and other) target parameter Hope I got them all. thanks, Andy >At 01:46 AM 5/24/2004, Nathan Sowatskey wrote: >>All >> >>This email details an attempt by me to model the NETCONF specification in UML in preparation for implementing the specification. My basic conclusion was that the specification can not be implemented as it currently stands. I welcome challenges to that conclusion. >> >>Viewing the project and using Together >>-------------------------------------- >> >>This is the first step in modelling NETCONF, which is to represent the >>entities and their relationships in UML. For those who want to play with >>the Together project itself, I have attached the whole thing zipped. >> >>If you want to edit the project, you will need to get Together 6.1 from Borland.com (just fill in the >>evaluation form and download it) an apply for an evaluation licence if you need it. >> >>You don't need Together to view the diagrams, which are gifs, or the code, all of which are in the attached zip file. >> >>Once you have done that, open the attached file somewhere convenient, >>windows or Linux/Unix. Open the NETCONF.tpr file, and you will be away! >> >>If you just want to look at the diagrams, then they are in the diagrams >>directory of the attached file. There are two diagrams, netconf.gif and >>rpc.gif. There are also many notes in the source files also, which are >>under src, which you can look at with the aid of a normal editor. >> >>Discussion of the model - Operations and arguments >>-------------------------------------------------- >> >>Whilst this is a UML *model*, and is thus distinct from any specific >>implementation, implementation concerns always play a role in modelling, >>much as normalization does in data base modelling. I have thus >>approached this modelling exercise as though I were going to implement >>the specification, as indeed I am, from a top down perspective, rather >>than the bottom up approach that the specification takes. > >IMO, although interesting, development of a UML model is out >of scope for the NETCONF v1.0 document set. We will focus on >the document clarity issues you are raising instead. > > >>One of the first challenges that I encountered with reverse engineering >>a model from the specification was separating the RPC implementation >>from the operations. >> >>Having the rpc-reply element as part of the signature of the operations, >>the fact that some arguments are parameters, whilst others are >>attributes, and the use of '<>'s everywhere couples the operations to >>the underlying XML implementation. This coupling is probably not the >>intention of the specification writers, but it is there nevertheless. > >Not sure what this comment means. If it means we are putting >a stake in the ground wrt/ XML syntax and XSD representation >(at a minimum) of protocol messages data models, then it is >intentional. That's in the charter, and IMO it's important >that we try to stay within that scope. > > >>Another challenge was the inconsistent declaration of "format" argument. >>It is implied in the text descriptions, so I have included a Format >>object as an operation parameter which is an enumeration of two types: >>XML and Text. I suspect that there may be more types, and using an >>enumeration is intrinsically extensible. > >format is gone in -03. We will use namespaces to identify >content format. We may also want to create some conventions >for elements at some point (not coupled to v1.0 work). > > >>The next challenge was to decide what the Configuration type should look >>like. I have used a nested structure. This is a common design idiom >>where a top level container contains a collection of something - >>ConfigurationElement - that is a name/value pair, or a collection of >>more of itself. Again, this is intrinsically extensible. > >Do you mean the data model structure or a model of the NETCONF >protocol operations? The data model work is out of scope. >The and elements are the the top-level containers. > > >>I then needed to think about what the naming and types of the parameters >>should be. I wasn't sure what the notation used in the specification was >>meant to convey. An example being "source: @config-name". I took this to >>mean that there was a parameter called source, which is the name of a >>configuration, though the explanation refers to this being the name of a >>configuration datastore. > >We need to fix this in the document. >That shorthand I made up on the fly should be replaced with >something else, like an ABNF. > > >>In general I took the first part of the parameter name for the arguments >>for the operations where that made sense. I also used String types by >>default, except where the type was more specifically defined, either >>because my modelling interpretation introduced it, or because it was >>later specified by the Capabilities. > >The data types are (or should be) defined in the accompanying XSD, >not in this text, and the document says that somewhere. > > >>With the "config: @element-subtree" parameter, I made the decision that >>this was actually the scope of the operation, that being the implication >>of the explanation. In any case, I was able to use the same >>Configuration type as the argument and the value of the configuration in >>the reply, which was a useful modelling outcome, and may be what the >>specification writers intended. > >This is the data model specific XML representation of the desired >configuration changes. > > >>The RPCreply type is a common pattern for RPCs where the encoding and/or >>the implementation don't support exceptions. In this case we have a >>container for the configuration, state and rpc-error elements. This can >>be used over any RPC encoding scheme, which I believe was the intention of the specification writers. >> >>The State type posed a problem as it clearly exists in the >>specification, but there is no indication of what it consists of. For >>now I have included the type as a place holder, but I am unable to give >>it any structure. > >Do you mean the netconf-state XSD in the draft? >Not sure what State is in the protocol operations. > > >>The RPCError type probably has more members than it needs. A minimum for >>such a type would normally be the error code, non internationalised >>error text, and a namespace to define the resource bundle that the >>internationalised text would come from. The specification writers might >>want to consider whether all of the other elements are really needed. > >The -03 version will have the updated section I sent >to the mailing list a couple weeks ago. We will refine it from there. >The -02 version has some problems that have hopefully been addressed. > > >>The edit-config operation specifies attributes as well as parameters. >>This is XML specific. I have modelled the "operation" attribute as a >>parameter to the operation and created an enumerated type, >>EditOperation. This also illustrates that having a parameter to an >>operation called "operation" is not a good thing. It might have been >>better to have three separate edit operations instead, which is another >>modelling option that I considered, but have left out for now. > >We know it's XML-specific and that's not a concern of the WG. >I'm more concerned that we document guidelines for writing XSDs >that account for the operation attribute. > > >>The copy-config operation has a source parameter which could be a name >>of a configuration or a configuration itself. Since these are two >>different types, I have had to create two arguments in the operation for >>both cases. This is also the only operation where the format parameter >>is explicitly specified, but it is also suggested that the format be >>omitted for this operation. I wasn't sure what to make of that, so I >>included format as a parameter anyway. > >The XSD is still kind of rough. We are still finalizing the semantics >and the syntax hasn't caught up yet. The copy-config >parameter is supposed to take on of: > std config: , , > local config example: file://foo-config.xml > remote config example: > ftp://example.com/configs/v1.1/foo-config.xml > > > >>The get-all operation specifies a state parameter which could be an >>element-subtree (which I have modelled as a Configuration type >>specifying the scope of the operation) or text. This led me to conclude >>that the specification writers intended for there to be a format >>parameter, so I have created one for this operation. > >text is out in -03 -- see above -- the config has to be valid XML > > >>The kill-session operation specified the type of session-id to be an >>integer. This is the first type definition in the specification. I can >>see that the session-id is elsewhere specified as an int, but it might >>better be a float, or a BIGINT. There is no guarantee on how big an int can be, but at least we can decide on an IEEE defined float as a number with a well specified range. Further, a positive integer means that we can't use -1 as a session-id which can sometimes be useful. > >this is more clarified in the -03 version. >IMO, we don't need to make the SessionID a float. >Billions of session IDs seems pretty sufficient to me. > > >>Discussion of the model - Capabilities etc. >>------------------------------------------- >> >>The next step in the modelling exercise is to decide how to model >>Capabilities and the different operations associated with devices that >>have them. >> >>The first point of difficulty is that the capabilities of a device are >>determined during the transport set up when the session is first >>established as part of the "hello" handshake. This is not a good thing. > >why not? They can also be read later from the netconf-state data model. > >>I have added an operation to the Device type (more on that later) which >>supports the explicit discovery of capabilities after the transport has been established. > >This should be just more data available via the operation, >not a special operation. The capabilities exchange is very >important at session startup. If the capabilities don't meet >application needs, then it's better to shut down the session >and report the incompatibility problem to the user. > > >>The Device type could have been called Server as the specification uses >>both interchangeably. This is not a good idea. Typically the "server" >>would, for most people, be the management software managing the device. >>Since this is a peer-to-peer model, moreover, neither is really a server >>in the client-server sense. The specification writers seem to have taken >>the stance that the entity implementing the operations is the server. I >>have chosen "Device" as that is much clearer. I'd suggest that the >>specification writers do the same. > >We are trying to stick to manager and agent. >We need to clean up this text. There is text that >says we use client and server to mean manager and agent. >This should be removed and the terminology cleaned up. > > >>The Capability type is modelled with a namespace and a type which is >>modelled as an enumeration. A Device has a collection of Capability(s). >> >>Each capability has associated with it a set of operations which are >>additive in that a device can have the base operations, and the extra >>operations associated with the additional capabilities. >> >>A problem arises in that some base operations are overloaded, i.e. >>redefined, in a device that has a capability. Normally this would be >>modelled by inheritance which would allow an operation in an inherited >>type to redefine what the base operation does. > >Some capabilities represent the reality of massive quantities >of deployed network devices with specific characteristics. >Our prime directive is to create something vendors can implement >and operators can use. > >Some capabilities represent a trade-off between complexity and scale. >Certain features like rollback or XPath are expensive enough to be optional >(at least for now). Tiny SOHO boxes may not have the resources >to provide complex features like this. > > >>In this case, as the capabilities are additive, but not mutually >>exclusive, it is not clear how this would work. What happens, for >>example, if a device has both the URL capability and the Candidate >>capability? Both these capabilities define different versions of >>edit-config. Which would apply? > >both -- I'm concerned that the spec describes the functionality, >but not particular implementation strategies. Lots of capabilities >work independently. This is no different than the current >situation for developers. We are just trying to provide a >mechanism to expose the operational capabilities in a standard >protocol exchange. > > >>For the time being I have chosen to model the operations as a collection >>in the Device conceptually keyed by the capability that the operations >>are associated with. This really makes the notion of a capability more >>like that of a role. If that were the case, then one could decide what >>role the device was fulfilling, and then choose the set of operations >>that matched that role/capability. >> >>As things stand I am not sure if the model is correct or not, or whether >>the specification writers have simply left this aspect unspecified. >> >>The specification defines an Agent capability, but all this seems to >>indicate is that a peer is willing to be managed, which makes it a >>Device. I think that the Manager and Agent capabilities are not >>capabilities at all, but roles. It is also not clear what difference >>they make in an implementation, except perhaps at the transport security >>level. >> >>Where the capabilities modify existing operations, this is typically in a way that defines what the values of the arguments should be. In these cases this is not a modification of the operation, it is an implementation detail of how the operation should work. The edit-config and copy-config operations for the Writeable-Running capability are examples of this. > >I disagree. The XML syntax is not an implementation detail. >We are defining an XML API, not an abstract information model. >There is clear WG consensus that the use of XML syntax and XSD >data modelling capabilities, as stated in the charter, is the >right decision for the NETCONF protocol. > > >>A slightly different case is the modification to the copy-config >>operation for the Distinct Startup capability, which appears to specify >>a completely different behaviour from the base operations. > >Yes, as documenting in the draft. >This is the first type of capability -- aligning the protocol >with reality instead of the other way around. > > >>I have tried to capture the new and modified operations by redefining >>the operations on a specific derived Operations type for the associated >>capability. The diagram only reveals part of the story, so the notes in >>the code will help to see what I have done here. >> >>The discard-changes operation for the Candidate Configuration capability >>doesn't appear to have a return value, but I have added one as it is >>clearly required. > >It should be or . What else is needed? > > >>The get-config and edit-config modified operations for the Candidate >>capability are specified to have a default target of the candidate >>configuration. This should probably be the only value allowed. > >We discussed this and though we should keep the #candidate >and #writable-running capabilities independent. I agree >that it would be bad for an implementation to actually do >this, so maybe we should make these capabilities mutually >exclusive. > > >>For it to >>be described as "default" implies that there is a choice of some other >>configuration, which wouldn't make sense for this capability. Also, >>"target" probably means source for get-config, and target for >>edit-config only. > >I think we discussed this and decided we can't really have a default >in the XSD because XSD doesn't support it and the dual-target >issue above. IMO, we should make this parameter mandatory because >there's no way to keep implementations consistent on the default. >I think Wes already brought this issue up and we agreed the >default attribute in the XSD and this default text in the >description should be removed. > > >>As per the modelling question above, it is not clear whether a device >>can have the Validate and Candidate capabilities at the same time. On a >>point of consistency, the section for the Validate capability doesn't >>mention any modifications to existing operations at all. > >Sure -- validate is independent of candidate. We do not have >a database-like transaction model. We understand that edit-config >operations can succeed on the and the can >still fail because didn't check everything that >can possibly go wrong during actual application of the desired config >changes to the running state. > > >>Summary >>------- >> >>This review has highlighted some shortcomings in the specification from >>an implementation perspective, and also from a system model perspective. >>Ideally these would be addressed so that a definitive model could be >>produced. > >thanks for your comments -- we will try to clarify the documents >in the areas that are still rough or broken. Here's my list of >issues your email has generated in this area: > > > >>That's all for now. I'd appreciate some feedback on this discussion. >> >>Many thanks >> >>Nathan > >Andy > > >> >>-- >>Nathan Sowatskey - Technical Leader, NMTG CTO Engineering - Desk >>+44-208-824-4259/+1-408-527-2595 - Mobile +44-7740-449794 - AIM id NathanCisco - >>nsowatsk@cisco.com > > >-- >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: -- 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: From owner-netconf@ops.ietf.org Wed Jun 2 12:42:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02032 for ; Wed, 2 Jun 2004 12:42:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVYa5-0005tW-W1 for netconf-data@psg.com; Wed, 02 Jun 2004 16:27:09 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVYa3-0005sV-5M for netconf@ops.ietf.org; Wed, 02 Jun 2004 16:27:07 +0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 02 Jun 2004 18:35:50 +0200 X-BrightmailFiltered: true Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i52GR21P019259; Wed, 2 Jun 2004 18:27:03 +0200 (MEST) Received: from XFE-LON-301.cisco.com ([64.103.98.17]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Jun 2004 17:27:43 +0100 Received: from lon-nsowatsk-3002-2.cisco.com ([10.53.65.195]) by XFE-LON-301.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Jun 2004 17:26:59 +0100 Subject: Re: NETCONF modelled in UML From: Nathan Sowatskey To: Andy Bierman Cc: netconf@ops.ietf.org In-Reply-To: <6.1.1.1.2.20040601131602.03b1b110@fedex.cisco.com> References: <1085388397.1839.23.camel@nsowatsk-lnx-t40.cisco.com> <6.1.1.1.2.20040601115616.039a7550@fedex.cisco.com> <6.1.1.1.2.20040601131602.03b1b110@fedex.cisco.com> Content-Type: text/plain Organization: Cisco Systems Message-Id: <1086193580.2215.514.camel@nsowatsk-lnx-t40.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 02 Jun 2004 18:26:20 +0200 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2004 16:26:59.0526 (UTC) FILETIME=[6DBC4E60:01C448BE] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit All Andy's replies to my original UML model email are below. Andy replied to his own email as well, so the nesting is slightly strange. To avoid more nesting, my replies are not nested. Why a UML Model? --------------- The point of creating a model from the specification was not the model itself, but to see whether a complete and well-formed model *could* be derived from the specification. This is always a good way to identify the strengths and weaknesses of a written specification. Secondly, the model, using Together, is a development artefact which I use to derive Java code (the binding from UML to Java is a well defined standard). From the Java code I use a tool from Axis (java2WSDL) to define WSDL descriptors for the Java interfaces (another well defined standard), and JAX-RPC (http://java.sun.com/xml/jaxrpc/) for the XML RPC encoding. The point is that I an use standard tools and specifications to produce the XML RPCs for the operations once I have successfully modelled them. I have argued that this approach should be used to define the RPC encoding for NETCONF as it is well specified, and well supported by tools, already. Mixing interface and encoding ----------------------------- I noted that the definition of the operations was mixed with the encoding style. This appeared to be contrary to the intention of the specification which declared a layered approach to be its goal. If that were the case, then the definition of the operations should not expose the encoding style. This will probably be a moot point if the interface is declared in a well formed language like BNF, though more on that later. Format, Configuration and State data types ----------------------------------- I have removed the Format data type. I noted that there were two data types, Configuration and State, that were important in the RPCs. I used one XML example to infer that the Configuration data type was nested, and modelled it like that. In fact, both data types should be explicitly undefined, i.e. they are opaque to the specification. The model has been changed to reflect this. Interface declarations ---------------------- Andy suggested using BNF to declare the interfaces. I suggest IDL. This is what it could look like (generated from the model by Together and slightly tidied up): interface BaseOperations : Operations{ RPCReply getConfig( string source, Object configScope); RPCReply editConfig( EditOperation operation, string target, string testOption, string errorOption, Object configScope); RPCReply copyConfig( string sourceName, Object sourceConfig, string target); RPCReply deleteConfig( string target); RPCReply lock( string target); RPCReply unlock( string target); RPCReply getAll( Object configScope); RPCReply killSession( long sessionId); interface RPCReply { Object getConfigResults(); Object getStateResults(); RPCError getError(); long getMessageId(); boolean isOK(); }; interface RPCError { string getDetails(); string getTag(); long getErrorCode(); string getSeverity(); Object getEditPath(); string getStatement(); string getMessage(); string getAction(); }; Note that the data types are defined here, as are the interfaces for the RPCReply and RPCError types. This is clearly independent of encoding. Further, the mapping from these types to XSD types is well defined by the JAX-RPC specification. Scope? ------ I suggested that the desired configuration changes might be termed the "scope" of the operation. It is not clear if that was understood. RPCReply and RPCError types ----------------------------- I suggested the structures indicated above for the RPCReply and RPCError types. It is not clear if that was understood. The RPCError type will change, but I have left it alone in the model for now. The edit-config and copy-config operations ------------------------------------------ I suggested that the use of the XML specific attribute type be hidden. As before, if the language used to declare the interfaces changes, that is moot. I further suggested that it might be better to have separate edit-config operations so that the meaning was clear in the name of the operation. It is not clear if that was understood. The copy-config operation is still in flux. Determining capabilities ------------------------ I argued that determining capabilities should be done at the application layer, not the transport layer. The application layer is where the capabilities matter. I don't think that this changes the ability of the peers to negotiate on capabilities, bit it does make for a cleaner separation of layers. Device, manager, agent etc. --------------------------- I am not clear on which is which yet, though agent makes me think of an SNMP agent for a managed element, which is not, I believe, the impression we want to convey if NETCONF is supposed to be implemented natively. Capabilities and mutual exclusivity ----------------------------------- I argued that having capabilities that were additive but not mutually exclusive would not work. I don't believe that specific capabilities can be simply declared exclusive of each other since there is no way to know which future capabilities might also need to be exclusive. I think that a general property of a capability that lists the capabilities that must be excluded if the capability is active must be supported. Agent and Roles --------------- I made a detailed point here which I don't believe was understood. The discard-changes operation ----------------------------- Doesn't have a return type defined. Whilst it is clear what it should be, the specification doesn't say that. Summary ------- This is progress :-) - replace ad-hoc parameter syntax in the operation descriptions like '@config-name' to something more precise, like ABNF NS - I suggested IDL and gave an example above. - need to add new and error code text to -03 and review/refine it from there NS - OK - document guidelines for writing XSDs that account for the operation attribute NS - I suggested different operation names - cleanup XSDs in the protocol draft to align with the related text about the protocol operation syntax elsewhere in the draft - cleanup terminology related to manager/agent vs. client/server; don't use client/server terminology at all NS - I don't like agent, too SNMP like. - decide if #candidate and #writable-running should be mutually exclusive capabilities instead of independent of each other NS - I suggested treating exclusivity as a property of a capability. - remove defaults for edit-config (and other) target parameter NS - OK The remaining points are still outstanding from my understanding: - Why invent an XML RPC encoding when there are standards available? - Keep interface declaration and encoding scheme completely separate. - Scope? - I don't think capabilities should be determined at the transport layer. - Agents and roles. I'll work on some example encodings now with the Axis and JAX-RPC tools and some sample data to see what that will look like. Many thanks Nathan On Tue, 2004-06-01 at 22:28, Andy Bierman wrote: > At 01:08 PM 6/1/2004, Andy Bierman wrote: > > oops -- fat-fingered 'send' before adding the summary of > action items at the end: > - replace ad-hoc parameter syntax in the operation descriptions > like '@config-name' to something more precise, like ABNF > - need to add new and error code text to -03 and > review/refine it from there > - document guidelines for writing XSDs that account for the > operation attribute > - cleanup XSDs in the protocol draft to align with the related > text about the protocol operation syntax elsewhere in the draft > - cleanup terminology related to manager/agent vs. client/server; > don't use client/server terminology at all > - decide if #candidate and #writable-running should be mutually > exclusive capabilities instead of independent of each other > - remove defaults for edit-config (and other) target parameter > > Hope I got them all. > > thanks, > Andy > > > > > >At 01:46 AM 5/24/2004, Nathan Sowatskey wrote: > >>All > >> > >>This email details an attempt by me to model the NETCONF specification in UML in preparation for implementing the specification. My basic conclusion was that the specification can not be implemented as it currently stands. I welcome challenges to that conclusion. > >> > >>Viewing the project and using Together > >>-------------------------------------- > >> > >>This is the first step in modelling NETCONF, which is to represent the > >>entities and their relationships in UML. For those who want to play with > >>the Together project itself, I have attached the whole thing zipped. > >> > >>If you want to edit the project, you will need to get Together 6.1 from Borland.com (just fill in the > >>evaluation form and download it) an apply for an evaluation licence if you need it. > >> > >>You don't need Together to view the diagrams, which are gifs, or the code, all of which are in the attached zip file. > >> > >>Once you have done that, open the attached file somewhere convenient, > >>windows or Linux/Unix. Open the NETCONF.tpr file, and you will be away! > >> > >>If you just want to look at the diagrams, then they are in the diagrams > >>directory of the attached file. There are two diagrams, netconf.gif and > >>rpc.gif. There are also many notes in the source files also, which are > >>under src, which you can look at with the aid of a normal editor. > >> > >>Discussion of the model - Operations and arguments > >>-------------------------------------------------- > >> > >>Whilst this is a UML *model*, and is thus distinct from any specific > >>implementation, implementation concerns always play a role in modelling, > >>much as normalization does in data base modelling. I have thus > >>approached this modelling exercise as though I were going to implement > >>the specification, as indeed I am, from a top down perspective, rather > >>than the bottom up approach that the specification takes. > > > >IMO, although interesting, development of a UML model is out > >of scope for the NETCONF v1.0 document set. We will focus on > >the document clarity issues you are raising instead. > > > > > >>One of the first challenges that I encountered with reverse engineering > >>a model from the specification was separating the RPC implementation > >>from the operations. > >> > >>Having the rpc-reply element as part of the signature of the operations, > >>the fact that some arguments are parameters, whilst others are > >>attributes, and the use of '<>'s everywhere couples the operations to > >>the underlying XML implementation. This coupling is probably not the > >>intention of the specification writers, but it is there nevertheless. > > > >Not sure what this comment means. If it means we are putting > >a stake in the ground wrt/ XML syntax and XSD representation > >(at a minimum) of protocol messages data models, then it is > >intentional. That's in the charter, and IMO it's important > >that we try to stay within that scope. > > > > > >>Another challenge was the inconsistent declaration of "format" argument. > >>It is implied in the text descriptions, so I have included a Format > >>object as an operation parameter which is an enumeration of two types: > >>XML and Text. I suspect that there may be more types, and using an > >>enumeration is intrinsically extensible. > > > >format is gone in -03. We will use namespaces to identify > >content format. We may also want to create some conventions > >for elements at some point (not coupled to v1.0 work). > > > > > >>The next challenge was to decide what the Configuration type should look > >>like. I have used a nested structure. This is a common design idiom > >>where a top level container contains a collection of something - > >>ConfigurationElement - that is a name/value pair, or a collection of > >>more of itself. Again, this is intrinsically extensible. > > > >Do you mean the data model structure or a model of the NETCONF > >protocol operations? The data model work is out of scope. > >The and elements are the the top-level containers. > > > > > >>I then needed to think about what the naming and types of the parameters > >>should be. I wasn't sure what the notation used in the specification was > >>meant to convey. An example being "source: @config-name". I took this to > >>mean that there was a parameter called source, which is the name of a > >>configuration, though the explanation refers to this being the name of a > >>configuration datastore. > > > >We need to fix this in the document. > >That shorthand I made up on the fly should be replaced with > >something else, like an ABNF. > > > > > >>In general I took the first part of the parameter name for the arguments > >>for the operations where that made sense. I also used String types by > >>default, except where the type was more specifically defined, either > >>because my modelling interpretation introduced it, or because it was > >>later specified by the Capabilities. > > > >The data types are (or should be) defined in the accompanying XSD, > >not in this text, and the document says that somewhere. > > > > > >>With the "config: @element-subtree" parameter, I made the decision that > >>this was actually the scope of the operation, that being the implication > >>of the explanation. In any case, I was able to use the same > >>Configuration type as the argument and the value of the configuration in > >>the reply, which was a useful modelling outcome, and may be what the > >>specification writers intended. > > > >This is the data model specific XML representation of the desired > >configuration changes. > > > > > >>The RPCreply type is a common pattern for RPCs where the encoding and/or > >>the implementation don't support exceptions. In this case we have a > >>container for the configuration, state and rpc-error elements. This can > >>be used over any RPC encoding scheme, which I believe was the intention of the specification writers. > >> > >>The State type posed a problem as it clearly exists in the > >>specification, but there is no indication of what it consists of. For > >>now I have included the type as a place holder, but I am unable to give > >>it any structure. > > > >Do you mean the netconf-state XSD in the draft? > >Not sure what State is in the protocol operations. > > > > > >>The RPCError type probably has more members than it needs. A minimum for > >>such a type would normally be the error code, non internationalised > >>error text, and a namespace to define the resource bundle that the > >>internationalised text would come from. The specification writers might > >>want to consider whether all of the other elements are really needed. > > > >The -03 version will have the updated section I sent > >to the mailing list a couple weeks ago. We will refine it from there. > >The -02 version has some problems that have hopefully been addressed. > > > > > >>The edit-config operation specifies attributes as well as parameters. > >>This is XML specific. I have modelled the "operation" attribute as a > >>parameter to the operation and created an enumerated type, > >>EditOperation. This also illustrates that having a parameter to an > >>operation called "operation" is not a good thing. It might have been > >>better to have three separate edit operations instead, which is another > >>modelling option that I considered, but have left out for now. > > > >We know it's XML-specific and that's not a concern of the WG. > >I'm more concerned that we document guidelines for writing XSDs > >that account for the operation attribute. > > > > > >>The copy-config operation has a source parameter which could be a name > >>of a configuration or a configuration itself. Since these are two > >>different types, I have had to create two arguments in the operation for > >>both cases. This is also the only operation where the format parameter > >>is explicitly specified, but it is also suggested that the format be > >>omitted for this operation. I wasn't sure what to make of that, so I > >>included format as a parameter anyway. > > > >The XSD is still kind of rough. We are still finalizing the semantics > >and the syntax hasn't caught up yet. The copy-config > >parameter is supposed to take on of: > > std config: , , > > local config example: file://foo-config.xml > > remote config example: > > ftp://example.com/configs/v1.1/foo-config.xml > > > > > > > >>The get-all operation specifies a state parameter which could be an > >>element-subtree (which I have modelled as a Configuration type > >>specifying the scope of the operation) or text. This led me to conclude > >>that the specification writers intended for there to be a format > >>parameter, so I have created one for this operation. > > > >text is out in -03 -- see above -- the config has to be valid XML > > > > > >>The kill-session operation specified the type of session-id to be an > >>integer. This is the first type definition in the specification. I can > >>see that the session-id is elsewhere specified as an int, but it might > >>better be a float, or a BIGINT. There is no guarantee on how big an int can be, but at least we can decide on an IEEE defined float as a number with a well specified range. Further, a positive integer means that we can't use -1 as a session-id which can sometimes be useful. > > > >this is more clarified in the -03 version. > >IMO, we don't need to make the SessionID a float. > >Billions of session IDs seems pretty sufficient to me. > > > > > >>Discussion of the model - Capabilities etc. > >>------------------------------------------- > >> > >>The next step in the modelling exercise is to decide how to model > >>Capabilities and the different operations associated with devices that > >>have them. > >> > >>The first point of difficulty is that the capabilities of a device are > >>determined during the transport set up when the session is first > >>established as part of the "hello" handshake. This is not a good thing. > > > >why not? They can also be read later from the netconf-state data model. > > > >>I have added an operation to the Device type (more on that later) which > >>supports the explicit discovery of capabilities after the transport has been established. > > > >This should be just more data available via the operation, > >not a special operation. The capabilities exchange is very > >important at session startup. If the capabilities don't meet > >application needs, then it's better to shut down the session > >and report the incompatibility problem to the user. > > > > > >>The Device type could have been called Server as the specification uses > >>both interchangeably. This is not a good idea. Typically the "server" > >>would, for most people, be the management software managing the device. > >>Since this is a peer-to-peer model, moreover, neither is really a server > >>in the client-server sense. The specification writers seem to have taken > >>the stance that the entity implementing the operations is the server. I > >>have chosen "Device" as that is much clearer. I'd suggest that the > >>specification writers do the same. > > > >We are trying to stick to manager and agent. > >We need to clean up this text. There is text that > >says we use client and server to mean manager and agent. > >This should be removed and the terminology cleaned up. > > > > > >>The Capability type is modelled with a namespace and a type which is > >>modelled as an enumeration. A Device has a collection of Capability(s). > >> > >>Each capability has associated with it a set of operations which are > >>additive in that a device can have the base operations, and the extra > >>operations associated with the additional capabilities. > >> > >>A problem arises in that some base operations are overloaded, i.e. > >>redefined, in a device that has a capability. Normally this would be > >>modelled by inheritance which would allow an operation in an inherited > >>type to redefine what the base operation does. > > > >Some capabilities represent the reality of massive quantities > >of deployed network devices with specific characteristics. > >Our prime directive is to create something vendors can implement > >and operators can use. > > > >Some capabilities represent a trade-off between complexity and scale. > >Certain features like rollback or XPath are expensive enough to be optional > >(at least for now). Tiny SOHO boxes may not have the resources > >to provide complex features like this. > > > > > >>In this case, as the capabilities are additive, but not mutually > >>exclusive, it is not clear how this would work. What happens, for > >>example, if a device has both the URL capability and the Candidate > >>capability? Both these capabilities define different versions of > >>edit-config. Which would apply? > > > >both -- I'm concerned that the spec describes the functionality, > >but not particular implementation strategies. Lots of capabilities > >work independently. This is no different than the current > >situation for developers. We are just trying to provide a > >mechanism to expose the operational capabilities in a standard > >protocol exchange. > > > > > >>For the time being I have chosen to model the operations as a collection > >>in the Device conceptually keyed by the capability that the operations > >>are associated with. This really makes the notion of a capability more > >>like that of a role. If that were the case, then one could decide what > >>role the device was fulfilling, and then choose the set of operations > >>that matched that role/capability. > >> > >>As things stand I am not sure if the model is correct or not, or whether > >>the specification writers have simply left this aspect unspecified. > >> > >>The specification defines an Agent capability, but all this seems to > >>indicate is that a peer is willing to be managed, which makes it a > >>Device. I think that the Manager and Agent capabilities are not > >>capabilities at all, but roles. It is also not clear what difference > >>they make in an implementation, except perhaps at the transport security > >>level. > >> > >>Where the capabilities modify existing operations, this is typically in a way that defines what the values of the arguments should be. In these cases this is not a modification of the operation, it is an implementation detail of how the operation should work. The edit-config and copy-config operations for the Writeable-Running capability are examples of this. > > > >I disagree. The XML syntax is not an implementation detail. > >We are defining an XML API, not an abstract information model. > >There is clear WG consensus that the use of XML syntax and XSD > >data modelling capabilities, as stated in the charter, is the > >right decision for the NETCONF protocol. > > > > > >>A slightly different case is the modification to the copy-config > >>operation for the Distinct Startup capability, which appears to specify > >>a completely different behaviour from the base operations. > > > >Yes, as documenting in the draft. > >This is the first type of capability -- aligning the protocol > >with reality instead of the other way around. > > > > > >>I have tried to capture the new and modified operations by redefining > >>the operations on a specific derived Operations type for the associated > >>capability. The diagram only reveals part of the story, so the notes in > >>the code will help to see what I have done here. > >> > >>The discard-changes operation for the Candidate Configuration capability > >>doesn't appear to have a return value, but I have added one as it is > >>clearly required. > > > >It should be or . What else is needed? > > > > > >>The get-config and edit-config modified operations for the Candidate > >>capability are specified to have a default target of the candidate > >>configuration. This should probably be the only value allowed. > > > >We discussed this and though we should keep the #candidate > >and #writable-running capabilities independent. I agree > >that it would be bad for an implementation to actually do > >this, so maybe we should make these capabilities mutually > >exclusive. > > > > > >>For it to > >>be described as "default" implies that there is a choice of some other > >>configuration, which wouldn't make sense for this capability. Also, > >>"target" probably means source for get-config, and target for > >>edit-config only. > > > >I think we discussed this and decided we can't really have a default > >in the XSD because XSD doesn't support it and the dual-target > >issue above. IMO, we should make this parameter mandatory because > >there's no way to keep implementations consistent on the default. > >I think Wes already brought this issue up and we agreed the > >default attribute in the XSD and this default text in the > >description should be removed. > > > > > >>As per the modelling question above, it is not clear whether a device > >>can have the Validate and Candidate capabilities at the same time. On a > >>point of consistency, the section for the Validate capability doesn't > >>mention any modifications to existing operations at all. > > > >Sure -- validate is independent of candidate. We do not have > >a database-like transaction model. We understand that edit-config > >operations can succeed on the and the can > >still fail because didn't check everything that > >can possibly go wrong during actual application of the desired config > >changes to the running state. > > > > > >>Summary > >>------- > >> > >>This review has highlighted some shortcomings in the specification from > >>an implementation perspective, and also from a system model perspective. > >>Ideally these would be addressed so that a definitive model could be > >>produced. > > > >thanks for your comments -- we will try to clarify the documents > >in the areas that are still rough or broken. Here's my list of > >issues your email has generated in this area: > > > > > > > >>That's all for now. I'd appreciate some feedback on this discussion. > >> > >>Many thanks > >> > >>Nathan > > > >Andy > > > > > >> > >>-- > >>Nathan Sowatskey - Technical Leader, NMTG CTO Engineering - Desk > >>+44-208-824-4259/+1-408-527-2595 - Mobile +44-7740-449794 - AIM id NathanCisco - > >>nsowatsk@cisco.com > > > > > >-- > >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: -- Nathan Sowatskey - Technical Leader, NMTG CTO Engineering - Desk +44-208-824-4259/+1-408-527-2595 - Mobile +44-7740-449794 - AIM id NathanCisco - nsowatsk@cisco.com -- 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: From owner-netconf@ops.ietf.org Wed Jun 2 13:30:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04812 for ; Wed, 2 Jun 2004 13:30:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVZPR-000F4f-Dd for netconf-data@psg.com; Wed, 02 Jun 2004 17:20:13 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVZPP-000F4F-Kl for netconf@ops.ietf.org; Wed, 02 Jun 2004 17:20:11 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2004 10:21:04 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i52HK8ls009958; Wed, 2 Jun 2004 10:20:08 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-679.cisco.com [10.21.66.167]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUW71533; Wed, 2 Jun 2004 10:20:06 -0700 (PDT) Message-Id: <6.1.1.1.2.20040602095332.03e59938@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 02 Jun 2004 10:14:56 -0700 To: Nathan Sowatskey From: Andy Bierman Subject: Re: NETCONF modelled in UML Cc: netconf@ops.ietf.org In-Reply-To: <1086193580.2215.514.camel@nsowatsk-lnx-t40.cisco.com> References: <1085388397.1839.23.camel@nsowatsk-lnx-t40.cisco.com> <6.1.1.1.2.20040601115616.039a7550@fedex.cisco.com> <6.1.1.1.2.20040601131602.03b1b110@fedex.cisco.com> <1086193580.2215.514.camel@nsowatsk-lnx-t40.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 09:26 AM 6/2/2004, Nathan Sowatskey wrote: >All replies inline >Andy's replies to my original UML model email are below. Andy replied to >his own email as well, so the nesting is slightly strange. To avoid more >nesting, my replies are not nested. > >Why a UML Model? >--------------- > >The point of creating a model from the specification was not the model >itself, but to see whether a complete and well-formed model *could* be >derived from the specification. This is always a good way to identify >the strengths and weaknesses of a written specification. > >Secondly, the model, using Together, is a development artefact which I >use to derive Java code (the binding from UML to Java is a well defined >standard). From the Java code I use a tool from Axis (java2WSDL) to >define WSDL descriptors for the Java interfaces (another well defined >standard), and JAX-RPC (http://java.sun.com/xml/jaxrpc/) for the XML RPC >encoding. > >The point is that I an use standard tools and specifications to produce >the XML RPCs for the operations once I have successfully modelled them. >I have argued that this approach should be used to define the RPC >encoding for NETCONF as it is well specified, and well supported by >tools, already. > >Mixing interface and encoding >----------------------------- > >I noted that the definition of the operations was mixed with the >encoding style. This appeared to be contrary to the intention of the >specification which declared a layered approach to be its goal. If that >were the case, then the definition of the operations should not expose >the encoding style. > >This will probably be a moot point if the interface is declared in a >well formed language like BNF, though more on that later. > >Format, Configuration and State data types >----------------------------------- > >I have removed the Format data type. > >I noted that there were two data types, Configuration and State, that >were important in the RPCs. I used one XML example to infer that the >Configuration data type was nested, and modelled it like that. In fact, >both data types should be explicitly undefined, i.e. they are opaque to >the specification. The model has been changed to reflect this. > >Interface declarations >---------------------- > >Andy suggested using BNF to declare the interfaces. I suggest IDL. This >is what it could look like (generated from the model by Together and >slightly tidied up): > >interface BaseOperations : Operations{ > RPCReply getConfig( string source, > Object configScope); > > RPCReply editConfig( EditOperation operation, > string target, > string testOption, > string errorOption, > Object configScope); > > RPCReply copyConfig( string sourceName, > Object sourceConfig, > string target); > > RPCReply deleteConfig( string target); > > RPCReply lock( string target); > > RPCReply unlock( string target); > > RPCReply getAll( Object configScope); > > RPCReply killSession( long sessionId); > >interface RPCReply { > Object getConfigResults(); > Object getStateResults(); > RPCError getError(); > long getMessageId(); > boolean isOK(); > }; > >interface RPCError { > string getDetails(); > string getTag(); > long getErrorCode(); > string getSeverity(); > Object getEditPath(); > string getStatement(); > string getMessage(); > string getAction(); > }; > >Note that the data types are defined here, as are the interfaces for the >RPCReply and RPCError types. This is clearly independent of encoding. >Further, the mapping from these types to XSD types is well defined by >the JAX-RPC specification. These remind me of the ASI stuff in the SNMPv3 documents. We should focus only on the semantics and syntax of messages on the wire, and stay away from implementation interfaces >Scope? >------ > >I suggested that the desired configuration changes might be termed the >"scope" of the operation. It is not clear if that was understood. I think scope is an overloaded term, and it doesn't seem to fit here. >RPCReply and RPCError types >----------------------------- > >I suggested the structures indicated above for the RPCReply and RPCError >types. It is not clear if that was understood. We have an XSD for that in the document. The WG consensus is that XSD representation of NETCONF syntax is sufficient. >The RPCError type will change, but I have left it alone in the model for >now. > >The edit-config and copy-config operations >------------------------------------------ > >I suggested that the use of the XML specific attribute type be hidden. >As before, if the language used to declare the interfaces changes, that >is moot. Not sure what you're talking about here. The syntax of NETCONF messages is encoded in XML. This is not going to change. >I further suggested that it might be better to have separate edit-config >operations so that the meaning was clear in the name of the operation. >It is not clear if that was understood. This was discussed at length on the mailing list and WG consensus is that separate edit commands for create, modify, delete, etc. make the protocol operations harder to use for operators. >The copy-config operation is still in flux. > >Determining capabilities >------------------------ > >I argued that determining capabilities should be done at the application >layer, not the transport layer. The application layer is where the >capabilities matter. > >I don't think that this changes the ability of the peers to negotiate on >capabilities, bit it does make for a cleaner separation of layers. I have to check the text -- maybe its still unclear or wrong -- the protocol document should describe the capabilities exchange in a transport-independent manner. The concern is that the NETCONF peers should exchange capabilities before they start sending protocol messages. This was a more significant concern when we had notifications, optional channels, etc. I agree that it is not desirable to have a potentially different capabilities exchange for each transport mapping. >Device, manager, agent etc. >--------------------------- > >I am not clear on which is which yet, though agent makes me think of an >SNMP agent for a managed element, which is not, I believe, the >impression we want to convey if NETCONF is supposed to be implemented >natively. The manager sends messages and listens for messages. The agent listens for messages and sends messages. What do you mean, implemented natively? The manager/agent model is what we want here. >Capabilities and mutual exclusivity >----------------------------------- > >I argued that having capabilities that were additive but not mutually >exclusive would not work. I don't believe that specific capabilities can >be simply declared exclusive of each other since there is no way to know >which future capabilities might also need to be exclusive. Future capabilities will explain how they interact with existing ones. >I think that a general property of a capability that lists the >capabilities that must be excluded if the capability is active must be >supported. This can be in documentation. I don't think it needs to be retrieved from the agent at runtime. >Agent and Roles >--------------- > >I made a detailed point here which I don't believe was understood. > >The discard-changes operation >----------------------------- > >Doesn't have a return type defined. Whilst it is clear what it should >be, the specification doesn't say that. > >Summary >------- > >This is progress :-) > >- replace ad-hoc parameter syntax in the operation descriptions like >'@config-name' to something more precise, like ABNF > >NS - I suggested IDL and gave an example above. > >- need to add new and error code text to -03 and >review/refine it from there > >NS - OK > >- document guidelines for writing XSDs that account for the operation >attribute > >NS - I suggested different operation names > >- cleanup XSDs in the protocol draft to align with the related text >about the protocol operation syntax elsewhere in the draft > >- cleanup terminology related to manager/agent vs. client/server; don't >use client/server terminology at all > >NS - I don't like agent, too SNMP like. > >- decide if #candidate and #writable-running should be mutually >exclusive capabilities instead of independent of each other > >NS - I suggested treating exclusivity as a property of a capability. > >- remove defaults for edit-config (and other) target parameter > >NS - OK > >The remaining points are still outstanding from my understanding: > >- Why invent an XML RPC encoding when there are standards available? > >- Keep interface declaration and encoding scheme completely separate. > >- Scope? > >- I don't think capabilities should be determined at the transport >layer. > >- Agents and roles. > >I'll work on some example encodings now with the Axis and JAX-RPC tools >and some sample data to see what that will look like. > >Many thanks > >Nathan thanks, Andy >On Tue, 2004-06-01 at 22:28, Andy Bierman wrote: >> At 01:08 PM 6/1/2004, Andy Bierman wrote: >> >> oops -- fat-fingered 'send' before adding the summary of >> action items at the end: >> - replace ad-hoc parameter syntax in the operation descriptions >> like '@config-name' to something more precise, like ABNF >> - need to add new and error code text to -03 and >> review/refine it from there >> - document guidelines for writing XSDs that account for the >> operation attribute >> - cleanup XSDs in the protocol draft to align with the related >> text about the protocol operation syntax elsewhere in the draft >> - cleanup terminology related to manager/agent vs. client/server; >> don't use client/server terminology at all >> - decide if #candidate and #writable-running should be mutually >> exclusive capabilities instead of independent of each other >> - remove defaults for edit-config (and other) target parameter >> >> Hope I got them all. >> >> thanks, >> Andy >> >> >> >> >> >At 01:46 AM 5/24/2004, Nathan Sowatskey wrote: >> >>All >> >> >> >>This email details an attempt by me to model the NETCONF specification in UML in preparation for implementing the specification. My basic conclusion was that the specification can not be implemented as it currently stands. I welcome challenges to that conclusion. >> >> >> >>Viewing the project and using Together >> >>-------------------------------------- >> >> >> >>This is the first step in modelling NETCONF, which is to represent the >> >>entities and their relationships in UML. For those who want to play with >> >>the Together project itself, I have attached the whole thing zipped. >> >> >> >>If you want to edit the project, you will need to get Together 6.1 from Borland.com (just fill in the >> >>evaluation form and download it) an apply for an evaluation licence if you need it. >> >> >> >>You don't need Together to view the diagrams, which are gifs, or the code, all of which are in the attached zip file. >> >> >> >>Once you have done that, open the attached file somewhere convenient, >> >>windows or Linux/Unix. Open the NETCONF.tpr file, and you will be away! >> >> >> >>If you just want to look at the diagrams, then they are in the diagrams >> >>directory of the attached file. There are two diagrams, netconf.gif and >> >>rpc.gif. There are also many notes in the source files also, which are >> >>under src, which you can look at with the aid of a normal editor. >> >> >> >>Discussion of the model - Operations and arguments >> >>-------------------------------------------------- >> >> >> >>Whilst this is a UML *model*, and is thus distinct from any specific >> >>implementation, implementation concerns always play a role in modelling, >> >>much as normalization does in data base modelling. I have thus >> >>approached this modelling exercise as though I were going to implement >> >>the specification, as indeed I am, from a top down perspective, rather >> >>than the bottom up approach that the specification takes. >> > >> >IMO, although interesting, development of a UML model is out >> >of scope for the NETCONF v1.0 document set. We will focus on >> >the document clarity issues you are raising instead. >> > >> > >> >>One of the first challenges that I encountered with reverse engineering >> >>a model from the specification was separating the RPC implementation >> >>from the operations. >> >> >> >>Having the rpc-reply element as part of the signature of the operations, >> >>the fact that some arguments are parameters, whilst others are >> >>attributes, and the use of '<>'s everywhere couples the operations to >> >>the underlying XML implementation. This coupling is probably not the >> >>intention of the specification writers, but it is there nevertheless. >> > >> >Not sure what this comment means. If it means we are putting >> >a stake in the ground wrt/ XML syntax and XSD representation >> >(at a minimum) of protocol messages data models, then it is >> >intentional. That's in the charter, and IMO it's important >> >that we try to stay within that scope. >> > >> > >> >>Another challenge was the inconsistent declaration of "format" argument. >> >>It is implied in the text descriptions, so I have included a Format >> >>object as an operation parameter which is an enumeration of two types: >> >>XML and Text. I suspect that there may be more types, and using an >> >>enumeration is intrinsically extensible. >> > >> >format is gone in -03. We will use namespaces to identify >> >content format. We may also want to create some conventions >> >for elements at some point (not coupled to v1.0 work). >> > >> > >> >>The next challenge was to decide what the Configuration type should look >> >>like. I have used a nested structure. This is a common design idiom >> >>where a top level container contains a collection of something - >> >>ConfigurationElement - that is a name/value pair, or a collection of >> >>more of itself. Again, this is intrinsically extensible. >> > >> >Do you mean the data model structure or a model of the NETCONF >> >protocol operations? The data model work is out of scope. >> >The and elements are the the top-level containers. >> > >> > >> >>I then needed to think about what the naming and types of the parameters >> >>should be. I wasn't sure what the notation used in the specification was >> >>meant to convey. An example being "source: @config-name". I took this to >> >>mean that there was a parameter called source, which is the name of a >> >>configuration, though the explanation refers to this being the name of a >> >>configuration datastore. >> > >> >We need to fix this in the document. >> >That shorthand I made up on the fly should be replaced with >> >something else, like an ABNF. >> > >> > >> >>In general I took the first part of the parameter name for the arguments >> >>for the operations where that made sense. I also used String types by >> >>default, except where the type was more specifically defined, either >> >>because my modelling interpretation introduced it, or because it was >> >>later specified by the Capabilities. >> > >> >The data types are (or should be) defined in the accompanying XSD, >> >not in this text, and the document says that somewhere. >> > >> > >> >>With the "config: @element-subtree" parameter, I made the decision that >> >>this was actually the scope of the operation, that being the implication >> >>of the explanation. In any case, I was able to use the same >> >>Configuration type as the argument and the value of the configuration in >> >>the reply, which was a useful modelling outcome, and may be what the >> >>specification writers intended. >> > >> >This is the data model specific XML representation of the desired >> >configuration changes. >> > >> > >> >>The RPCreply type is a common pattern for RPCs where the encoding and/or >> >>the implementation don't support exceptions. In this case we have a >> >>container for the configuration, state and rpc-error elements. This can >> >>be used over any RPC encoding scheme, which I believe was the intention of the specification writers. >> >> >> >>The State type posed a problem as it clearly exists in the >> >>specification, but there is no indication of what it consists of. For >> >>now I have included the type as a place holder, but I am unable to give >> >>it any structure. >> > >> >Do you mean the netconf-state XSD in the draft? >> >Not sure what State is in the protocol operations. >> > >> > >> >>The RPCError type probably has more members than it needs. A minimum for >> >>such a type would normally be the error code, non internationalised >> >>error text, and a namespace to define the resource bundle that the >> >>internationalised text would come from. The specification writers might >> >>want to consider whether all of the other elements are really needed. >> > >> >The -03 version will have the updated section I sent >> >to the mailing list a couple weeks ago. We will refine it from there. >> >The -02 version has some problems that have hopefully been addressed. >> > >> > >> >>The edit-config operation specifies attributes as well as parameters. >> >>This is XML specific. I have modelled the "operation" attribute as a >> >>parameter to the operation and created an enumerated type, >> >>EditOperation. This also illustrates that having a parameter to an >> >>operation called "operation" is not a good thing. It might have been >> >>better to have three separate edit operations instead, which is another >> >>modelling option that I considered, but have left out for now. >> > >> >We know it's XML-specific and that's not a concern of the WG. >> >I'm more concerned that we document guidelines for writing XSDs >> >that account for the operation attribute. >> > >> > >> >>The copy-config operation has a source parameter which could be a name >> >>of a configuration or a configuration itself. Since these are two >> >>different types, I have had to create two arguments in the operation for >> >>both cases. This is also the only operation where the format parameter >> >>is explicitly specified, but it is also suggested that the format be >> >>omitted for this operation. I wasn't sure what to make of that, so I >> >>included format as a parameter anyway. >> > >> >The XSD is still kind of rough. We are still finalizing the semantics >> >and the syntax hasn't caught up yet. The copy-config >> >parameter is supposed to take on of: >> > std config: , , >> > local config example: file://foo-config.xml >> > remote config example: >> > ftp://example.com/configs/v1.1/foo-config.xml >> > >> > >> > >> >>The get-all operation specifies a state parameter which could be an >> >>element-subtree (which I have modelled as a Configuration type >> >>specifying the scope of the operation) or text. This led me to conclude >> >>that the specification writers intended for there to be a format >> >>parameter, so I have created one for this operation. >> > >> >text is out in -03 -- see above -- the config has to be valid XML >> > >> > >> >>The kill-session operation specified the type of session-id to be an >> >>integer. This is the first type definition in the specification. I can >> >>see that the session-id is elsewhere specified as an int, but it might >> >>better be a float, or a BIGINT. There is no guarantee on how big an int can be, but at least we can decide on an IEEE defined float as a number with a well specified range. Further, a positive integer means that we can't use -1 as a session-id which can sometimes be useful. >> > >> >this is more clarified in the -03 version. >> >IMO, we don't need to make the SessionID a float. >> >Billions of session IDs seems pretty sufficient to me. >> > >> > >> >>Discussion of the model - Capabilities etc. >> >>------------------------------------------- >> >> >> >>The next step in the modelling exercise is to decide how to model >> >>Capabilities and the different operations associated with devices that >> >>have them. >> >> >> >>The first point of difficulty is that the capabilities of a device are >> >>determined during the transport set up when the session is first >> >>established as part of the "hello" handshake. This is not a good thing. >> > >> >why not? They can also be read later from the netconf-state data model. >> > >> >>I have added an operation to the Device type (more on that later) which >> >>supports the explicit discovery of capabilities after the transport has been established. >> > >> >This should be just more data available via the operation, >> >not a special operation. The capabilities exchange is very >> >important at session startup. If the capabilities don't meet >> >application needs, then it's better to shut down the session >> >and report the incompatibility problem to the user. >> > >> > >> >>The Device type could have been called Server as the specification uses >> >>both interchangeably. This is not a good idea. Typically the "server" >> >>would, for most people, be the management software managing the device. >> >>Since this is a peer-to-peer model, moreover, neither is really a server >> >>in the client-server sense. The specification writers seem to have taken >> >>the stance that the entity implementing the operations is the server. I >> >>have chosen "Device" as that is much clearer. I'd suggest that the >> >>specification writers do the same. >> > >> >We are trying to stick to manager and agent. >> >We need to clean up this text. There is text that >> >says we use client and server to mean manager and agent. >> >This should be removed and the terminology cleaned up. >> > >> > >> >>The Capability type is modelled with a namespace and a type which is >> >>modelled as an enumeration. A Device has a collection of Capability(s). >> >> >> >>Each capability has associated with it a set of operations which are >> >>additive in that a device can have the base operations, and the extra >> >>operations associated with the additional capabilities. >> >> >> >>A problem arises in that some base operations are overloaded, i.e. >> >>redefined, in a device that has a capability. Normally this would be >> >>modelled by inheritance which would allow an operation in an inherited >> >>type to redefine what the base operation does. >> > >> >Some capabilities represent the reality of massive quantities >> >of deployed network devices with specific characteristics. >> >Our prime directive is to create something vendors can implement >> >and operators can use. >> > >> >Some capabilities represent a trade-off between complexity and scale. >> >Certain features like rollback or XPath are expensive enough to be optional >> >(at least for now). Tiny SOHO boxes may not have the resources >> >to provide complex features like this. >> > >> > >> >>In this case, as the capabilities are additive, but not mutually >> >>exclusive, it is not clear how this would work. What happens, for >> >>example, if a device has both the URL capability and the Candidate >> >>capability? Both these capabilities define different versions of >> >>edit-config. Which would apply? >> > >> >both -- I'm concerned that the spec describes the functionality, >> >but not particular implementation strategies. Lots of capabilities >> >work independently. This is no different than the current >> >situation for developers. We are just trying to provide a >> >mechanism to expose the operational capabilities in a standard >> >protocol exchange. >> > >> > >> >>For the time being I have chosen to model the operations as a collection >> >>in the Device conceptually keyed by the capability that the operations >> >>are associated with. This really makes the notion of a capability more >> >>like that of a role. If that were the case, then one could decide what >> >>role the device was fulfilling, and then choose the set of operations >> >>that matched that role/capability. >> >> >> >>As things stand I am not sure if the model is correct or not, or whether >> >>the specification writers have simply left this aspect unspecified. >> >> >> >>The specification defines an Agent capability, but all this seems to >> >>indicate is that a peer is willing to be managed, which makes it a >> >>Device. I think that the Manager and Agent capabilities are not >> >>capabilities at all, but roles. It is also not clear what difference >> >>they make in an implementation, except perhaps at the transport security >> >>level. >> >> >> >>Where the capabilities modify existing operations, this is typically in a way that defines what the values of the arguments should be. In these cases this is not a modification of the operation, it is an implementation detail of how the operation should work. The edit-config and copy-config operations for the Writeable-Running capability are examples of this. >> > >> >I disagree. The XML syntax is not an implementation detail. >> >We are defining an XML API, not an abstract information model. >> >There is clear WG consensus that the use of XML syntax and XSD >> >data modelling capabilities, as stated in the charter, is the >> >right decision for the NETCONF protocol. >> > >> > >> >>A slightly different case is the modification to the copy-config >> >>operation for the Distinct Startup capability, which appears to specify >> >>a completely different behaviour from the base operations. >> > >> >Yes, as documenting in the draft. >> >This is the first type of capability -- aligning the protocol >> >with reality instead of the other way around. >> > >> > >> >>I have tried to capture the new and modified operations by redefining >> >>the operations on a specific derived Operations type for the associated >> >>capability. The diagram only reveals part of the story, so the notes in >> >>the code will help to see what I have done here. >> >> >> >>The discard-changes operation for the Candidate Configuration capability >> >>doesn't appear to have a return value, but I have added one as it is >> >>clearly required. >> > >> >It should be or . What else is needed? >> > >> > >> >>The get-config and edit-config modified operations for the Candidate >> >>capability are specified to have a default target of the candidate >> >>configuration. This should probably be the only value allowed. >> > >> >We discussed this and though we should keep the #candidate >> >and #writable-running capabilities independent. I agree >> >that it would be bad for an implementation to actually do >> >this, so maybe we should make these capabilities mutually >> >exclusive. >> > >> > >> >>For it to >> >>be described as "default" implies that there is a choice of some other >> >>configuration, which wouldn't make sense for this capability. Also, >> >>"target" probably means source for get-config, and target for >> >>edit-config only. >> > >> >I think we discussed this and decided we can't really have a default >> >in the XSD because XSD doesn't support it and the dual-target >> >issue above. IMO, we should make this parameter mandatory because >> >there's no way to keep implementations consistent on the default. >> >I think Wes already brought this issue up and we agreed the >> >default attribute in the XSD and this default text in the >> >description should be removed. >> > >> > >> >>As per the modelling question above, it is not clear whether a device >> >>can have the Validate and Candidate capabilities at the same time. On a >> >>point of consistency, the section for the Validate capability doesn't >> >>mention any modifications to existing operations at all. >> > >> >Sure -- validate is independent of candidate. We do not have >> >a database-like transaction model. We understand that edit-config >> >operations can succeed on the and the can >> >still fail because didn't check everything that >> >can possibly go wrong during actual application of the desired config >> >changes to the running state. >> > >> > >> >>Summary >> >>------- >> >> >> >>This review has highlighted some shortcomings in the specification from >> >>an implementation perspective, and also from a system model perspective. >> >>Ideally these would be addressed so that a definitive model could be >> >>produced. >> > >> >thanks for your comments -- we will try to clarify the documents >> >in the areas that are still rough or broken. Here's my list of >> >issues your email has generated in this area: >> > >> > >> > >> >>That's all for now. I'd appreciate some feedback on this discussion. >> >> >> >>Many thanks >> >> >> >>Nathan >> > >> >Andy >> > >> > >> >> >> >>-- >> >>Nathan Sowatskey - Technical Leader, NMTG CTO Engineering - Desk >> >>+44-208-824-4259/+1-408-527-2595 - Mobile +44-7740-449794 - AIM id NathanCisco - >> >>nsowatsk@cisco.com >> > >> > >> >-- >> >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: >-- >Nathan Sowatskey - Technical Leader, NMTG CTO Engineering - Desk >+44-208-824-4259/+1-408-527-2595 - Mobile +44-7740-449794 - AIM id NathanCisco - >nsowatsk@cisco.com -- 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: From owner-netconf@ops.ietf.org Wed Jun 2 14:05:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06331 for ; Wed, 2 Jun 2004 14:05:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVa1E-000Ksg-EA for netconf-data@psg.com; Wed, 02 Jun 2004 17:59:16 +0000 Received: from [207.217.120.84] (helo=gull.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVa1A-000Krr-Fv for netconf@ops.ietf.org; Wed, 02 Jun 2004 17:59:12 +0000 Received: from h-68-164-76-5.snvacaid.dynamic.covad.net ([68.164.76.5] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BVa19-0005AX-00 for netconf@ops.ietf.org; Wed, 02 Jun 2004 10:59:11 -0700 Message-ID: <006d01c44802$34fac280$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <1085388397.1839.23.camel@nsowatsk-lnx-t40.cisco.com> <6.1.1.1.2.20040601115616.039a7550@fedex.cisco.com> <6.1.1.1.2.20040601131602.03b1b110@fedex.cisco.com> <1086193580.2215.514.camel@nsowatsk-lnx-t40.cisco.com> <6.1.1.1.2.20040602095332.03e59938@fedex.cisco.com> Subject: Re: NETCONF modelled in UML Date: Tue, 1 Jun 2004 10:59:38 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Andy Bierman" > To: "Nathan Sowatskey" > Cc: > Sent: Wednesday, June 02, 2004 10:14 AM > Subject: Re: NETCONF modelled in UML ... > These remind me of the ASI stuff in the SNMPv3 documents. > We should focus only on the semantics and syntax of messages > on the wire, and stay away from implementation interfaces ... Although this is a tangential issue, this statement is too easily read in a way leading to serious misconceptions. The ASIs are *NOT* implementation interfaces. RFC 3411 is abundantly clear on this point: The abstract service interfaces are intended to help clarify the externally observable behavior of SNMP entities, and are not intended to constrain the structure or organization of implementations in any way. Most specifically, they should not be interpreted as APIs or as requirements statements for APIs. Randy -- 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: From owner-netconf@ops.ietf.org Thu Jun 3 11:16:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19472 for ; Thu, 3 Jun 2004 11:16:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVtkW-0008JL-3o for netconf-data@psg.com; Thu, 03 Jun 2004 15:03:20 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVtkU-0008Iq-03 for netconf@ops.ietf.org; Thu, 03 Jun 2004 15:03:18 +0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2004 17:12:19 +0200 X-BrightmailFiltered: true Received: from xbe-lon-302.cisco.com (xbe-lon-302.cisco.com [64.103.98.21]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i53F3D1P021047; Thu, 3 Jun 2004 17:03:13 +0200 (MEST) Received: from XFE-LON-301.cisco.com ([64.103.98.17]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Jun 2004 16:03:54 +0100 Received: from dhcp-rea-gp250-64-103-64-235.cisco.com ([64.103.64.235]) by XFE-LON-301.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 3 Jun 2004 16:03:12 +0100 Subject: Re: NETCONF modelled in UML From: Nathan Sowatskey To: Randy Presuhn Cc: netconf@ops.ietf.org In-Reply-To: <006d01c44802$34fac280$7f1afea9@oemcomputer> References: <1085388397.1839.23.camel@nsowatsk-lnx-t40.cisco.com> <6.1.1.1.2.20040601115616.039a7550@fedex.cisco.com> <6.1.1.1.2.20040601131602.03b1b110@fedex.cisco.com> <1086193580.2215.514.camel@nsowatsk-lnx-t40.cisco.com> <6.1.1.1.2.20040602095332.03e59938@fedex.cisco.com> <006d01c44802$34fac280$7f1afea9@oemcomputer> Content-Type: text/plain Organization: Cisco Systems Message-Id: <1086266861.1721.30.camel@nsowatsk-lnx-t40.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 03 Jun 2004 17:02:34 +0200 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2004 15:03:12.0700 (UTC) FILETIME=[E3ED47C0:01C4497B] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Indeed, and not tangential, this is equally true of CORBA IDL. More to the point though, I believe that the specification should focus on the semantics and syntax of the operations. The focus on the wire format is where I feel the specification is weakest. The software industry is not short of well defined XML RPC encodings with readily available tool support, why invent another? Regards Nathan On Tue, 2004-06-01 at 19:59, Randy Presuhn wrote: > Hi - > > > > From: "Andy Bierman" > > To: "Nathan Sowatskey" > > Cc: > > Sent: Wednesday, June 02, 2004 10:14 AM > > Subject: Re: NETCONF modelled in UML > ... > > These remind me of the ASI stuff in the SNMPv3 documents. > > We should focus only on the semantics and syntax of messages > > on the wire, and stay away from implementation interfaces > ... > > Although this is a tangential issue, this statement > is too easily read in a way leading to serious > misconceptions. > > The ASIs are *NOT* implementation interfaces. > RFC 3411 is abundantly clear on this point: > > The abstract service interfaces are intended to help clarify > the externally observable behavior of SNMP entities, and are not > intended to constrain the structure or organization of > implementations in any way. Most specifically, they should not be > interpreted as APIs or as requirements statements for APIs. > > Randy > > > > -- > 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: -- Nathan Sowatskey - Technical Leader, NMTG CTO Engineering - Desk +44-208-824-4259/+1-408-527-2595 - Mobile +44-7740-449794 - AIM id NathanCisco - nsowatsk@cisco.com -- 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: From owner-netconf@ops.ietf.org Thu Jun 3 11:47:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21609 for ; Thu, 3 Jun 2004 11:47:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVuJF-000DEf-IC for netconf-data@psg.com; Thu, 03 Jun 2004 15:39:13 +0000 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVuJE-000DEQ-MG for netconf@ops.ietf.org; Thu, 03 Jun 2004 15:39:12 +0000 Received: from d55py901 (h00104b8ce2a3.ne.client2.attbi.com[24.128.13.174]) by comcast.net (sccrmhc11) with SMTP id <20040603153911011003lrgme>; Thu, 3 Jun 2004 15:39:12 +0000 Reply-To: From: "David Harrington" To: "'Nathan Sowatskey'" , "'Randy Presuhn'" Cc: Subject: RE: NETCONF modelled in UML Date: Thu, 3 Jun 2004 11:39:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRJfT03LgqBzceVRImGnS8uzzGtcQAAvF/A In-Reply-To: <1086266861.1721.30.camel@nsowatsk-lnx-t40.cisco.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Hi, > -----Original Message----- > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Nathan Sowatskey > The focus on the wire format is where I feel the > specification is weakest. > I'm having a bit of trouble parsing this sentence unambiguously. Are you saying the specification is weak BECAUSE it is focused on the wire format rather than the operations, or are you saying the focus on the wire format is too weak? Thanks, Dave Harrington dbharrington@comcast.net -- 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: From owner-netconf@ops.ietf.org Thu Jun 3 12:10:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23105 for ; Thu, 3 Jun 2004 12:10:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVug8-000Glw-5d for netconf-data@psg.com; Thu, 03 Jun 2004 16:02:52 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVug7-000Gld-64 for netconf@ops.ietf.org; Thu, 03 Jun 2004 16:02:51 +0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2004 18:11:53 +0200 X-BrightmailFiltered: true Received: from xbe-lon-312.cisco.com (xbe-lon-312.cisco.com [64.103.99.72]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i53G2i1R001891; Thu, 3 Jun 2004 18:02:47 +0200 (MEST) Received: from XFE-LON-301.cisco.com ([64.103.98.17]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Jun 2004 17:03:28 +0100 Received: from dhcp-rea-gp250-64-103-64-235.cisco.com ([64.103.64.235]) by XFE-LON-301.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 3 Jun 2004 17:02:46 +0100 Subject: RE: NETCONF modelled in UML From: Nathan Sowatskey To: dbharrington@comcast.net Cc: "'Randy Presuhn'" , netconf@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: Cisco Systems Message-Id: <1086278527.3458.78.camel@nsowatsk-lnx-t40.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 03 Jun 2004 18:02:08 +0200 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2004 16:02:46.0355 (UTC) FILETIME=[35FDC230:01C44984] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Because it is focused on the wire format. You don't need to do that I feel. It is the operations that are important, wire encodings for XML RPC are already well defined. You don't need to define another one. Regards Nathan On Thu, 2004-06-03 at 17:39, David Harrington wrote: > Hi, > > > -----Original Message----- > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Nathan Sowatskey > > The focus on the wire format is where I feel the > > specification is weakest. > > > I'm having a bit of trouble parsing this sentence unambiguously. Are you > saying the specification is weak BECAUSE it is focused on the wire format > rather than the operations, or are you saying the focus on the wire format > is too weak? > > Thanks, > Dave Harrington > dbharrington@comcast.net > > > > -- > 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: -- Nathan Sowatskey - Technical Leader, NMTG CTO Engineering - Desk +44-208-824-4259/+1-408-527-2595 - Mobile +44-7740-449794 - AIM id NathanCisco - nsowatsk@cisco.com -- 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: From owner-netconf@ops.ietf.org Thu Jun 3 14:38:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01673 for ; Thu, 3 Jun 2004 14:38:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BVwzt-000A0o-1U for netconf-data@psg.com; Thu, 03 Jun 2004 18:31:25 +0000 Received: from [80.185.77.29] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BVwzp-000A0R-Ps for netconf@ops.ietf.org; Thu, 03 Jun 2004 18:31:22 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 538E782E6; Thu, 3 Jun 2004 16:43:25 +0200 (CEST) Date: Thu, 3 Jun 2004 16:43:25 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040603144325.GA1988@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, May 28, 2004 at 02:56:05PM -0700, Andy Bierman wrote: > > A) Issue 14.1: Subset specification > > A.1) Extensibility > > The and operations should be modified to > allow for the utilization of different types of standard, > proprietary, and experimental filter mechanisms in an extensible > way. > - An additional containment layer (called ) is needed > above the user data model content in the get operation > message. > - The element can appear zero or one times > - There is one attribute defined, called 'filter-type', which > identifies the type of filter processing requested by the manager > - The content type is 'any' (any element outside the netconf > namespace) Any specific reason why you want to put the element into the element? Why not just do the following: 7 > B) Issue 14.1.2: Subtree Filtering > ---------------------------------- [...] Out of curiosity, I am wondering how this subtree matching relates to XPATH filters or a subset thereof. So I started a little exercise to write XPATH expressions for your examples. In fact, it might be useful if the subtree filtering actually can be translated into XPATH expressions automatically on boxes that are capable to do XPATH filtering (so you just have one piece of filtering logic). Some open issues are listed at the end. Perhaps someone with more XPATH experience can answer some of them. > C) Examples > ----------- > > C.1: No filter > > Request: > > > > > > > > > Reply: > > > > ... entire set of data models returned ... > > > > Notes: > > - Since the sub-tree filter is inclusive, and the start state > is the empty set, the best way to get everything on the > agent is to leave out the filter. Not sure the best way > to fit this into and operations though. The equivalent XPATH expression might be "//*". > C.2: Empty filter > > Request: > > > > > > > > > > > Reply: > > > > > > > Notes: > > - Nothing is selected because no content match or selection > nodes are present. This is not an error. I think there are several XPATH expressions that produce an empty result - not sure yet which is the nicest (not that this is really important). > C.3) Select the entire sub-tree > > Request: > > > > > > > > > > > > Reply: > > > > > > root > superuser > Charlie Root > > 1 > 1 > > > > fred > admin > Fred Flintstone > > 2 > 2 > > > > barney > admin > Barney Rubble > > 2 > 3 > > > > > > > Notes: > > - The filter contains one selection node (), so just > that sub-tree is selected by the filter > - This example represents the fully-populated data model > in most of the filter examples that follow. In a real > data model, the 'company-info' would not likely be returned > with the list of users for a particular host or network. The equivalent XPATH expression might be "//users" or "/users" (not sure yet what precisely your semantics are here). > - The following filter request would have produced the same > result, but only because the container defines one > child element () > > > > > > > > > > > > The equivalent XPATH expression might be "//users/user" or "/users/user" (not sure yet what precisely your semantics are here). > C.4) Select all 'name' elements within the 'users' sub-tree > > Request: > > > > > > > > > > > > > > > > Reply: > > > > > > root > > > fred > > > barney > > > > > > Notes: > > - This filter contains two containment nodes (users, user), > and one selector node (name). > - All instances of the 'name' element in the same sibling set > are selected in the filter output. > - The manager may need to know that 'name' is used as an > instance identifier in this particular data structure, > but the agent does not need to know that meta-data in > order to process the request. The equivalent XPATH expression might be "//users/user/name". > C.5) One specific entry > > Request: > > > > > > > > fred > > > > > > > > Reply: > > > > > > fred > admin > Fred Flintstone > > 2 > 2 > > > > > > > Notes: > > - This filter contains two containment nodes (users, user) > and one content match node (name). > - All instances of the sibling set containing 'name', > for which the value of 'name' equals "fred", are selected > in the filter output. The equivalent XPATH expression might be "//users/user[name="fred"]". > C.6) Specific elements from a specific entry > > Request: > > > > > > > > fred > > > > > > > > > > Reply: > > > > > > fred > admin > Fred Flintstone > > > > > > Notes: > > - This filter contains two containment nodes (users, user), > one content match node (name), and two selector nodes > (type, full-name). > - All instances of the 'type' and 'full-name' elements in > the same siibling set containing 'name', for which the value > of 'name' equals "fred", are selected in the filter output. > The 'company-info' element is not included because the > sibling set contains selection nodes. The XPATH expression "//users/user[name="fred"]/name" will just return the name element - not sure how one can select multiple elements with XPATH in this case (but I am an XPATH beginner - perhaps someone out there knows the answer). > C.7) Multiple sub-trees > > Request: > > > > > > > > root > > > > fred > > > > > > barney > superuser > > > > > > > > > > > Reply: > > > > > > root > > 1 > 1 > > > > fred > > 2 > > > > > > > Notes: > > - This filter contains three sub-trees (name=root, fred, barney) > - The "root" sub-tree filter contains two containment nodes (users, > user), one content match node (name), and one selector node > (company-info). The sub-tree selection criteria is met, and just > the company-info sub-tree for "root" is selected in the filter > output. //users/user[name="root"]/company-info > - The "fred" sub-tree filter contains three containment nodes > (users, user, company-info), one content match node (name), and > one selector node (id). The sub-tree selection criteria is met, > and just the 'id' element within the company-info sub-tree for > "fred" is selected in the filter output. //users/user[name="fred"]/company-info/id > - The "barney" sub-tree filter contains three containment nodes (users, > user, company-info), two content match nodes (name, type), and one > selector node (dept). The sub-tree selection criteria is not met > because user "barney" is not a "superuser", and the entire sub-tree > for "barney" (including its parent 'user' entry) is excluded from > the filter output. //users/user[name="barney" and type="superuser"]/company-info You can combine these these expressions using a pipe character: //users/user[name="root"]/company-info | //users/user[name="fred"]/company-info/id | //users/user[name="barney" and type="superuser"]/company-info > C.8) Table with attribute naming > > Request: > > > > > > > > > > > > > > Reply: > > > > > > 45621 > 774344 > > > > > > Notes: > > - This filter contains one containment node (interfaces), one > attribute match expression (ifName), and one selector node > (interface). > - All instances of the 'interface' sub-tree which have an > ifName attribute equal to "eth0" are selected in the > filter output. > - The filter data elements and attributes must be qualified > because the 'ifName' attribute will not be considered part > of the 'schema-2' namespace if it is unqualified. > - If 'ifName' were a child node instead of an attribute, then > the following request would produce the same results: > > > > > > > > eth0 > > > > > > interfaces/interface/[@ifName="eth0"] OPEN ISSUES: - I have ignored namespaces so far. I am sure XPATH will have a way to deal with them. Not sure though how that looks like in concrete syntax (and how ugly it will be). - I do not yet know how to select several elements (kind of doing a projection on elements) (see example C.6 above). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Thu Jun 3 18:52:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01841 for ; Thu, 3 Jun 2004 18:52:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BW0pH-00020Y-3m for netconf-data@psg.com; Thu, 03 Jun 2004 22:36:43 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BW0pF-000208-Ug for netconf@ops.ietf.org; Thu, 03 Jun 2004 22:36:41 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 Jun 2004 15:37:49 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i53Madls021640; Thu, 3 Jun 2004 15:36:39 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-358.cisco.com [10.21.97.102]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUY26207; Thu, 3 Jun 2004 15:36:37 -0700 (PDT) Message-Id: <6.1.1.1.2.20040603152739.037a21d8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 03 Jun 2004 15:31:23 -0700 To: j.schoenwaelder@iu-bremen.de From: Andy Bierman Subject: Re: sub-tree filtering proposals Cc: netconf@ops.ietf.org In-Reply-To: <20040603144325.GA1988@iu-bremen.de> References: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> <20040603144325.GA1988@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 07:43 AM 6/3/2004, Juergen Schoenwaelder wrote: >On Fri, May 28, 2004 at 02:56:05PM -0700, Andy Bierman wrote: >> >> A) Issue 14.1: Subset specification >> >> A.1) Extensibility >> >> The and operations should be modified to >> allow for the utilization of different types of standard, >> proprietary, and experimental filter mechanisms in an extensible >> way. >> - An additional containment layer (called ) is needed >> above the user data model content in the get operation >> message. >> - The element can appear zero or one times >> - There is one attribute defined, called 'filter-type', which >> identifies the type of filter processing requested by the manager >> - The content type is 'any' (any element outside the netconf >> namespace) > >Any specific reason why you want to put the element into >the element? Why not just do the following: > > > > > > > > > > > > 7 > > I guess this would be fine. You still need to "get everything", but that can be if filter is missing, then get everything. >> B) Issue 14.1.2: Subtree Filtering >> ---------------------------------- > >[...] > >Out of curiosity, I am wondering how this subtree matching relates to >XPATH filters or a subset thereof. So I started a little exercise to >write XPATH expressions for your examples. In fact, it might be useful >if the subtree filtering actually can be translated into XPATH >expressions automatically on boxes that are capable to do XPATH >filtering (so you just have one piece of filtering logic). The problem with XPath (as we went through before) is that we are not going to specify a NETCONF-only subset of XPath. We are not going to require every box to implement XPath. This subtree filtering is intentionally very limited so it's easy to implement. >Some open issues are listed at the end. Perhaps someone with more XPATH >experience can answer some of them. > >> C) Examples >> ----------- >> >> C.1: No filter >> >> Request: >> >> >> >> >> >> >> >> >> Reply: >> >> >> >> ... entire set of data models returned ... >> >> >> >> Notes: >> >> - Since the sub-tree filter is inclusive, and the start state >> is the empty set, the best way to get everything on the >> agent is to leave out the filter. Not sure the best way >> to fit this into and operations though. > >The equivalent XPATH expression might be "//*". > >> C.2: Empty filter >> >> Request: >> >> >> >> >> >> >> >> >> >> >> Reply: >> >> >> >> >> >> >> Notes: >> >> - Nothing is selected because no content match or selection >> nodes are present. This is not an error. > >I think there are several XPATH expressions that produce an empty result >- not sure yet which is the nicest (not that this is really important). > >> C.3) Select the entire sub-tree >> >> Request: >> >> >> >> >> >> >> >> >> >> >> >> Reply: >> >> >> >> >> >> root >> superuser >> Charlie Root >> >> 1 >> 1 >> >> >> >> fred >> admin >> Fred Flintstone >> >> 2 >> 2 >> >> >> >> barney >> admin >> Barney Rubble >> >> 2 >> 3 >> >> >> >> >> >> >> Notes: >> >> - The filter contains one selection node (), so just >> that sub-tree is selected by the filter >> - This example represents the fully-populated data model >> in most of the filter examples that follow. In a real >> data model, the 'company-info' would not likely be returned >> with the list of users for a particular host or network. > >The equivalent XPATH expression might be "//users" or "/users" >(not sure yet what precisely your semantics are here). > >> - The following filter request would have produced the same >> result, but only because the container defines one >> child element () >> >> >> >> >> >> >> >> >> >> >> >> > >The equivalent XPATH expression might be "//users/user" or "/users/user" >(not sure yet what precisely your semantics are here). > >> C.4) Select all 'name' elements within the 'users' sub-tree >> >> Request: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Reply: >> >> >> >> >> >> root >> >> >> fred >> >> >> barney >> >> >> >> >> >> Notes: >> >> - This filter contains two containment nodes (users, user), >> and one selector node (name). >> - All instances of the 'name' element in the same sibling set >> are selected in the filter output. >> - The manager may need to know that 'name' is used as an >> instance identifier in this particular data structure, >> but the agent does not need to know that meta-data in >> order to process the request. > >The equivalent XPATH expression might be "//users/user/name". > >> C.5) One specific entry >> >> Request: >> >> >> >> >> >> >> >> fred >> >> >> >> >> >> >> >> Reply: >> >> >> >> >> >> fred >> admin >> Fred Flintstone >> >> 2 >> 2 >> >> >> >> >> >> >> Notes: >> >> - This filter contains two containment nodes (users, user) >> and one content match node (name). >> - All instances of the sibling set containing 'name', >> for which the value of 'name' equals "fred", are selected >> in the filter output. > >The equivalent XPATH expression might be "//users/user[name="fred"]". > >> C.6) Specific elements from a specific entry >> >> Request: >> >> >> >> >> >> >> >> fred >> >> >> >> >> >> >> >> >> >> Reply: >> >> >> >> >> >> fred >> admin >> Fred Flintstone >> >> >> >> >> >> Notes: >> >> - This filter contains two containment nodes (users, user), >> one content match node (name), and two selector nodes >> (type, full-name). >> - All instances of the 'type' and 'full-name' elements in >> the same siibling set containing 'name', for which the value >> of 'name' equals "fred", are selected in the filter output. >> The 'company-info' element is not included because the >> sibling set contains selection nodes. > >The XPATH expression "//users/user[name="fred"]/name" will just return >the name element - not sure how one can select multiple elements with >XPATH in this case (but I am an XPATH beginner - perhaps someone out >there knows the answer). > >> C.7) Multiple sub-trees >> >> Request: >> >> >> >> >> >> >> >> root >> >> >> >> fred >> >> >> >> >> >> barney >> superuser >> >> >> >> >> >> >> >> >> >> >> Reply: >> >> >> >> >> >> root >> >> 1 >> 1 >> >> >> >> fred >> >> 2 >> >> >> >> >> >> >> Notes: >> >> - This filter contains three sub-trees (name=root, fred, barney) >> - The "root" sub-tree filter contains two containment nodes (users, >> user), one content match node (name), and one selector node >> (company-info). The sub-tree selection criteria is met, and just >> the company-info sub-tree for "root" is selected in the filter >> output. > >//users/user[name="root"]/company-info > >> - The "fred" sub-tree filter contains three containment nodes >> (users, user, company-info), one content match node (name), and >> one selector node (id). The sub-tree selection criteria is met, >> and just the 'id' element within the company-info sub-tree for >> "fred" is selected in the filter output. > >//users/user[name="fred"]/company-info/id > >> - The "barney" sub-tree filter contains three containment nodes (users, >> user, company-info), two content match nodes (name, type), and one >> selector node (dept). The sub-tree selection criteria is not met >> because user "barney" is not a "superuser", and the entire sub-tree >> for "barney" (including its parent 'user' entry) is excluded from >> the filter output. > >//users/user[name="barney" and type="superuser"]/company-info > >You can combine these these expressions using a pipe character: > >//users/user[name="root"]/company-info | >//users/user[name="fred"]/company-info/id | >//users/user[name="barney" and type="superuser"]/company-info > >> C.8) Table with attribute naming >> >> Request: >> >> >> >> >> >> >> >> >> >> >> >> >> >> Reply: >> >> >> >> >> >> 45621 >> 774344 >> >> >> >> >> >> Notes: >> >> - This filter contains one containment node (interfaces), one >> attribute match expression (ifName), and one selector node >> (interface). >> - All instances of the 'interface' sub-tree which have an >> ifName attribute equal to "eth0" are selected in the >> filter output. >> - The filter data elements and attributes must be qualified >> because the 'ifName' attribute will not be considered part >> of the 'schema-2' namespace if it is unqualified. >> - If 'ifName' were a child node instead of an attribute, then >> the following request would produce the same results: >> >> >> >> >> >> >> >> eth0 >> >> >> >> >> >> > >interfaces/interface/[@ifName="eth0"] > >OPEN ISSUES: > >- I have ignored namespaces so far. I am sure XPATH will have a way > to deal with them. Not sure though how that looks like in concrete > syntax (and how ugly it will be). >- I do not yet know how to select several elements (kind of doing a > projection on elements) (see example C.6 above). > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Thu Jun 3 18:54:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02507 for ; Thu, 3 Jun 2004 18:54:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BW0xa-00049M-5R for netconf-data@psg.com; Thu, 03 Jun 2004 22:45:18 +0000 Received: from [80.185.76.54] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BW0xZ-00048k-1N for netconf@ops.ietf.org; Thu, 03 Jun 2004 22:45:17 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 713AB82A6; Fri, 4 Jun 2004 00:45:15 +0200 (CEST) Date: Fri, 4 Jun 2004 00:45:15 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040603224515.GA5980@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> <20040603144325.GA1988@iu-bremen.de> <6.1.1.1.2.20040603152739.037a21d8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040603152739.037a21d8@fedex.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Thu, Jun 03, 2004 at 03:31:23PM -0700, Andy Bierman wrote: > The problem with XPath (as we went through before) > is that we are not going to specify a NETCONF-only subset > of XPath. We are not going to require every box to > implement XPath. This subtree filtering is intentionally > very limited so it's easy to implement. You do not want to subset XPATH to reduce the implementation costs and at the same time you propose a different filter mechanism to reduce the implementation cost (which at the end might map to a subset of XPATH). OK, lets not restart this discussion without a beer. Lets see whether there are any other technical comments on your proposal. It seems this mailing list is way too quiet. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Thu Jun 3 20:30:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12982 for ; Thu, 3 Jun 2004 20:30:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BW2VE-000NV4-MQ for netconf-data@psg.com; Fri, 04 Jun 2004 00:24:08 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BW2VC-000NUb-QM for netconf@ops.ietf.org; Fri, 04 Jun 2004 00:24:06 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 03 Jun 2004 17:22:41 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i540O1Mr029697; Thu, 3 Jun 2004 17:24:04 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-358.cisco.com [10.21.97.102]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUY38522; Thu, 3 Jun 2004 17:24:00 -0700 (PDT) Message-Id: <6.1.1.1.2.20040603165052.03af1e28@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 03 Jun 2004 17:18:45 -0700 To: j.schoenwaelder@iu-bremen.de From: Andy Bierman Subject: Re: sub-tree filtering proposals Cc: netconf@ops.ietf.org In-Reply-To: <20040603224515.GA5980@iu-bremen.de> References: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> <20040603144325.GA1988@iu-bremen.de> <6.1.1.1.2.20040603152739.037a21d8@fedex.cisco.com> <20040603224515.GA5980@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 03:45 PM 6/3/2004, Juergen Schoenwaelder wrote: >On Thu, Jun 03, 2004 at 03:31:23PM -0700, Andy Bierman wrote: > >> The problem with XPath (as we went through before) >> is that we are not going to specify a NETCONF-only subset >> of XPath. We are not going to require every box to >> implement XPath. This subtree filtering is intentionally >> very limited so it's easy to implement. > >You do not want to subset XPATH to reduce the implementation costs and >at the same time you propose a different filter mechanism to reduce the >implementation cost (which at the end might map to a subset of XPATH). > >OK, lets not restart this discussion without a beer. Lets see whether >there are any other technical comments on your proposal. It seems this >mailing list is way too quiet. I agree the list is too quiet! Note that sub-tree filtering has been in the spec all along, but it hasn't been documented yet (except in examples). I tried to document the behavior the document examples have shown but never explained in detail. I would be in favor of standardizing both subtree and Xpath filtering at this time. The only extra work: - #xpath capability: if set, the agent supports filter-type="xpath" for any operation that takes the parameter - ... xpath expression ... I don't want to make Xpath mandatory, but I think we should still use it for complex filtering. >/js 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: From owner-netconf@ops.ietf.org Fri Jun 4 01:47:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29074 for ; Fri, 4 Jun 2004 01:47:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BW7Jk-000OY5-R2 for netconf-data@psg.com; Fri, 04 Jun 2004 05:32:36 +0000 Received: from [66.127.127.227] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BW7Jk-000OXk-0v for netconf@ops.ietf.org; Fri, 04 Jun 2004 05:32:36 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id C8CF811EBFD; Thu, 3 Jun 2004 22:32:36 -0700 (PDT) To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals References: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> <20040603144325.GA1988@iu-bremen.de> <6.1.1.1.2.20040603152739.037a21d8@fedex.cisco.com> <20040603224515.GA5980@iu-bremen.de> From: Wes Hardaker Organization: Sparta Date: Thu, 03 Jun 2004 22:32:36 -0700 In-Reply-To: <20040603224515.GA5980@iu-bremen.de> (Juergen Schoenwaelder's message of "Fri, 4 Jun 2004 00:45:15 +0200") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Fri, 4 Jun 2004 00:45:15 +0200, Juergen Schoenwaelder said: Juergen> You do not want to subset XPATH to reduce the implementation Juergen> costs and at the same time you propose a different filter Juergen> mechanism to reduce the implementation cost (which at the end Juergen> might map to a subset of XPATH). Juergen has a perfect point here. You're creating something new, which will take new code to implement something that doesn't yet exist because you don't want to use something else which is potentially more complex but yet code exists for it. Don't you think it will take significantly less work for implementations to implement partial XPath for which there is a plethora of pre-existing code than it will be to implement (and get right) something entirely new? The whole point behind using XML in the first place for this initiative was to make use of existing tools, but yet for this one you're throwing out the existing tools and libraries. Seems odd. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- 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: From owner-netconf@ops.ietf.org Fri Jun 4 03:41:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18336 for ; Fri, 4 Jun 2004 03:41:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BW9Cd-000EVO-1P for netconf-data@psg.com; Fri, 04 Jun 2004 07:33:23 +0000 Received: from [196.14.124.43] (helo=srv-mailrnd.azisa.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BW9CR-000EPr-40 for netconf@ops.ietf.org; Fri, 04 Jun 2004 07:33:13 +0000 Received: from srv-mailct.azisa.co.za ([10.189.128.47]) by srv-mailrnd.azisa.co.za with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Jun 2004 09:32:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Subject: RE: sub-tree filtering proposals MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Jun 2004 09:32:56 +0200 Message-ID: <395F89B355756C4188231F50659A48AD078D3B@srv-mailct.azisa.co.za> Thread-Topic: sub-tree filtering proposals Thread-Index: AcRKA7i2cC7vKCkhSO66Mb8/psSUvwAANZRA From: "Michael Walton" To: "Andy Bierman" , Cc: X-OriginalArrivalTime: 04 Jun 2004 07:32:59.0997 (UTC) FILETIME=[2983A8D0:01C44A06] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi I've been following netconf for a couple of weeks now. Hopefully I can add a bit of noise to a quiet list.=20 For now - I experimented a little with XPath expressions in PyXML and found one possible answer to Juergen's question: >> C.6) Specific elements from a specific entry >>=20 >> Request: >>=20 >> >> >> >> >> >> >> fred >> >> >> >> >> >> >> >> >>=20 >> Reply: >>=20 >> >> >> >> >> fred >> admin >> Fred Flintstone >> >> >> >> >> =20 >> Notes: >>=20 >> - This filter contains two containment nodes (users, user), >> one content match node (name), and two selector nodes >> (type, full-name). >> - All instances of the 'type' and 'full-name' elements in >> the same siibling set containing 'name', for which the value=20 >> of 'name' equals "fred", are selected in the filter output. >> The 'company-info' element is not included because the >> sibling set contains selection nodes. > >The XPATH expression "//users/user[name=3D"fred"]/name" will just = return >the name element - not sure how one can select multiple elements with >XPATH in this case (but I am an XPATH beginner - perhaps someone out >there knows the answer). > An expression that returns name, type and full-name looks like this: //users/user[name=3D"fred"]/*[name()=3D"name" or name()=3D"type" or name()=3D"full-name] ... which is somewhat ugly, or you could use the "pipeline" operator as suggested by Juergen: //users/user[name=3D"fred"]/name | //users/user[name=3D"fred"]/type | //users/user[name=3D"fred"]/full-name ... but that seems inefficient. Michael Walton Flextronics South Africa C301 Warehouse Building Black River Park, Fir Street Observatory, 7925, South Africa +27 21 442 1240 Main +27 21 442 1253 Direct +27 21 442 1264 Fax +27 83 233 1226 Mobile mailto:michael.walton@za.flextronics.com -- 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: From owner-netconf@ops.ietf.org Fri Jun 4 10:26:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13569 for ; Fri, 4 Jun 2004 10:26:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWFTS-0005pI-4n for netconf-data@psg.com; Fri, 04 Jun 2004 14:15:10 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWFTP-0005p0-MP for netconf@ops.ietf.org; Fri, 04 Jun 2004 14:15:07 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Jun 2004 07:14:50 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i54EF5ls000889; Fri, 4 Jun 2004 07:15:05 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-519.cisco.com [10.21.98.7]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUY75258; Fri, 4 Jun 2004 07:15:04 -0700 (PDT) Message-Id: <6.1.1.1.2.20040604064035.03949020@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Fri, 04 Jun 2004 07:04:21 -0700 To: Wes Hardaker From: Andy Bierman Subject: Re: sub-tree filtering proposals Cc: netconf@ops.ietf.org In-Reply-To: References: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> <20040603144325.GA1988@iu-bremen.de> <6.1.1.1.2.20040603152739.037a21d8@fedex.cisco.com> <20040603224515.GA5980@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 10:32 PM 6/3/2004, Wes Hardaker wrote: >>>>>> On Fri, 4 Jun 2004 00:45:15 +0200, Juergen Schoenwaelder said: > >Juergen> You do not want to subset XPATH to reduce the implementation >Juergen> costs and at the same time you propose a different filter >Juergen> mechanism to reduce the implementation cost (which at the end >Juergen> might map to a subset of XPATH). > >Juergen has a perfect point here. You're creating something new, I'm documenting something that has been in the spec since it was called XMLCONF. >which will take new code to implement something that doesn't yet exist >because you don't want to use something else which is potentially more >complex but yet code exists for it. I am extremely confident that implementation of this subtree filtering will take less code space and dev-effort than a full Xpath implementation. You can't just point to the equivalent Xpath for subtree filters and ignore the rest of the Xpath feature set. > Don't you think it will take >significantly less work for implementations to implement partial XPath Repetition is the key to learning... There will be no NETCONF standard subset of Xpath. Compare subtree to full Xpath implementation only. The WG already decided that implementation of full Xpath for NETCONF conformance is not appropriate for most devices, and will not be required. >for which there is a plethora of pre-existing code than it will be to >implement (and get right) something entirely new? The whole point >behind using XML in the first place for this initiative was to make >use of existing tools, but yet for this one you're throwing out the >existing tools and libraries. Seems odd. See the previous thread on Xpath, especially Phil's "closing arguments". IMO, we would keep NETCONF out of most network devices for years because the agent implementation cost and runtime resource requirements would be too high. What is it about subtree filtering that is so hard to implement? Clearly, all existing embedded implementations can handle containment nodes and leaf nodes with simple content. There are implementations from multiple vendors of all of these features because they are simple and intuitive: -- retrieve only the subtrees that exactly match the criteria presented in the search -- return a subtree starting at an empty leaf node (e.g. ) These are the fundamental filter operations that we need for NETCONF. IMO, Xpath is overkill for these fundamental needs. >-- >"In the bathtub of history the truth is harder to hold than the soap, > and much more difficult to find." -- Terry Pratchett 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: From owner-netconf@ops.ietf.org Fri Jun 4 11:22:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16634 for ; Fri, 4 Jun 2004 11:22:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWGNM-000ESQ-8V for netconf-data@psg.com; Fri, 04 Jun 2004 15:12:56 +0000 Received: from [66.127.127.227] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWGNL-000ESD-8C for netconf@ops.ietf.org; Fri, 04 Jun 2004 15:12:55 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id CA4B811EBFD; Fri, 4 Jun 2004 08:12:55 -0700 (PDT) To: Andy Bierman Cc: Wes Hardaker , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals References: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> <20040603144325.GA1988@iu-bremen.de> <6.1.1.1.2.20040603152739.037a21d8@fedex.cisco.com> <20040603224515.GA5980@iu-bremen.de> <6.1.1.1.2.20040604064035.03949020@fedex.cisco.com> From: Wes Hardaker Organization: Sparta Date: Fri, 04 Jun 2004 08:12:55 -0700 In-Reply-To: <6.1.1.1.2.20040604064035.03949020@fedex.cisco.com> (Andy Bierman's message of "Fri, 04 Jun 2004 07:04:21 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Fri, 04 Jun 2004 07:04:21 -0700, Andy Bierman said: Andy> I'm documenting something that has been in the spec since Andy> it was called XMLCONF. No one was debating what you were doing. Andy> What is it about subtree filtering that is so hard to implement? I never said it would be hard to implement, but you do have to implement it. Heck, XPath isn't hard to implement it just takes time. So would this. Anyway, you don't need to respond to this as you've already "declared it so", so continuing this would probably not be worth your time. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- 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: From owner-netconf@ops.ietf.org Fri Jun 4 11:43:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17779 for ; Fri, 4 Jun 2004 11:43:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWGkP-000Idj-Qs for netconf-data@psg.com; Fri, 04 Jun 2004 15:36:45 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWGkO-000IdG-Jf for netconf@ops.ietf.org; Fri, 04 Jun 2004 15:36:44 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 04 Jun 2004 08:35:26 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i54FaeXl017832; Fri, 4 Jun 2004 08:36:41 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-519.cisco.com [10.21.98.7]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUY81401; Fri, 4 Jun 2004 08:36:39 -0700 (PDT) Message-Id: <6.1.1.1.2.20040604082734.0399a150@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Fri, 04 Jun 2004 08:31:23 -0700 To: Wes Hardaker From: Andy Bierman Subject: Re: sub-tree filtering proposals Cc: netconf@ops.ietf.org In-Reply-To: References: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> <20040603144325.GA1988@iu-bremen.de> <6.1.1.1.2.20040603152739.037a21d8@fedex.cisco.com> <20040603224515.GA5980@iu-bremen.de> <6.1.1.1.2.20040604064035.03949020@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 08:12 AM 6/4/2004, Wes Hardaker wrote: >>>>>> On Fri, 04 Jun 2004 07:04:21 -0700, Andy Bierman said: > >Andy> I'm documenting something that has been in the spec since >Andy> it was called XMLCONF. > >No one was debating what you were doing. > >Andy> What is it about subtree filtering that is so hard to implement? > >I never said it would be hard to implement, but you do have to >implement it. Heck, XPath isn't hard to implement it just takes >time. So would this. It's not just the implementation time and runtime resources. As Rob pointed out, the operators would need to learn how to use Xpath. It's debatable whether operators will find Xpath or this subtree filtering more complicated. >Anyway, you don't need to respond to this as you've already "declared >it so", so continuing this would probably not be worth your time. Sorry for over-reacting. I got upset at the prospect of rehashing the entire "Xpath subset" thread over again. >-- >"In the bathtub of history the truth is harder to hold than the soap, > and much more difficult to find." -- Terry Pratchett 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: From owner-netconf@ops.ietf.org Fri Jun 4 14:00:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27435 for ; Fri, 4 Jun 2004 14:00:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWItG-000GMU-TP for netconf-data@psg.com; Fri, 04 Jun 2004 17:54:02 +0000 Received: from [207.17.137.105] (helo=juniper.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWItF-000GM1-Dq for netconf@ops.ietf.org; Fri, 04 Jun 2004 17:54:01 +0000 Received: from ([172.24.18.109]) by jaffa.juniper.net with ESMTP ; Fri, 04 Jun 2004 10:53:21 -0700 Received: from photon.jnpr.net ([172.24.18.198]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Jun 2004 10:53:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: startup datastore Date: Fri, 4 Jun 2004 10:53:20 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D44053ABC7F@photon.jnpr.net> Thread-Topic: startup datastore thread-index: AcREHRjhrE8qkQYPQHmjssQTQlMPaAGNDZgg From: "Rob Enns" To: "Andy Bierman" , "Cristian Cadar" Cc: X-OriginalArrivalTime: 04 Jun 2004 17:53:21.0952 (UTC) FILETIME=[D3874200:01C44A5C] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable One slight correction, the configuration is only available on devices with the #startup capability (not the #writable-running capability). thanks,=20 Rob=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, May 27, 2004 11:46 AM > To: Cristian Cadar > Cc: netconf@ops.ietf.org > Subject: Re: startup datastore >=20 > At 03:27 AM 5/27/2004, Cristian Cadar wrote: >=20 > >Hi, > > > >I'm trying to understand the use of the startup datastore=20 > when used toghether > >with the running datastore. > > From the draft: "Running: The complete configuration=20 > currently active on the > >network device..." should I understand that the device is=20 > configured at boot time with the content of the startup > >datastore and after a while is configured by the content of=20 > the running datastore?=20 >=20 > no. The configuration datastore is simply the > sum of all current configuration settings. The > configuration is only visible on devices that have the=20 > #writable-running > (sec. 6.4.1) capability set. This means that the active > configuration and the next-reboot configuration are not > kept in sync automatically by the agent. Instead, the > next-reboot config (called ) is updated with > the copy-config operation (copy to ). > Devices without this capability do not need a > config because it will always be identical to , > so it's redundant. >=20 > >what happens if=20 > >their content differ? When and in which situations the=20 > startup datastore may be used? For the time being I cannot > >see any win having a startup datastore. >=20 > The value of a separate startup config is to provide the=20 > operator some control as when it is safe to overwrite the=20 > next-reboot config. Since existing technology (as well as=20 > NETCONF) doesn't provide mechanisms for the agent to identity=20 > actual transaction boundaries for , the agent doesn't > know when the running config is stable. >=20 >=20 >=20 > >TNX > >Cristian > > > > > >-- > >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: =20 >=20 >=20 > -- > 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: >=20 >=20 -- 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: From owner-netconf@ops.ietf.org Fri Jun 4 14:00:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27465 for ; Fri, 4 Jun 2004 14:00:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWItF-000GLz-9s for netconf-data@psg.com; Fri, 04 Jun 2004 17:54:01 +0000 Received: from [207.17.137.104] (helo=juniper.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWItE-000GLM-DH for netconf@ops.ietf.org; Fri, 04 Jun 2004 17:54:00 +0000 Received: from ([172.24.18.126]) by tokra.juniper.net with ESMTP ; Fri, 04 Jun 2004 10:53:22 -0700 Received: from photon.jnpr.net ([172.24.18.198]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Jun 2004 10:53:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: security issues Date: Fri, 4 Jun 2004 10:53:20 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D44053ABC80@photon.jnpr.net> Thread-Topic: security issues thread-index: AcRExWzlNCVyAtI8TPmYbxcTFW5oxgFjDHEg From: "Rob Enns" To: "Cristian Cadar" , X-OriginalArrivalTime: 04 Jun 2004 17:53:22.0363 (UTC) FILETIME=[D3C5F8B0:01C44A5C] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At the NETCONF meeing in Seoul, the WG indicated that SSH should be the mandatory substrate for NETCONF. The draft will be cleaned up to reflect this decision. thanks,=20 Rob=20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Cristian Cadar > Sent: Friday, May 28, 2004 8:02 AM > To: netconf@ops.ietf.org > Subject: security issues >=20 > Hi, >=20 > In order to have a secure communication between peers the=20 > draft mentions > the usage of the Radius, TLS or SSH protocol. Why IPsec is=20 > not taken into account here?=20 > Which one of the protocols above is preferred/mandatory in=20 > NETCONF, if any? >=20 >=20 > TNX > Cristian >=20 >=20 > -- > 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: >=20 >=20 -- 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: From owner-netconf@ops.ietf.org Fri Jun 4 16:33:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08206 for ; Fri, 4 Jun 2004 16:33:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWLDo-000Ntg-50 for netconf-data@psg.com; Fri, 04 Jun 2004 20:23:24 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWLDm-000NtD-TH for netconf@ops.ietf.org; Fri, 04 Jun 2004 20:23:22 +0000 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i54KN9X01049; Fri, 4 Jun 2004 16:23:09 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jun 2004 16:23:09 -0400 Message-ID: From: "Glenn Waters" To: Andy Bierman , Wes Hardaker Cc: netconf@ops.ietf.org Subject: RE: sub-tree filtering proposals Date: Fri, 4 Jun 2004 16:23:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44A71.C02DF054" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44A71.C02DF054 Content-Type: text/plain I guess the point around the XPath proposal has always been why don't we line up with an existing standard, even if we only select a subset of that standard. That way we get the best of both worlds -- we get just the features we want and we don't have to reinvent the wheel. Further, if at some point down the road we decide we want more powerful filtering/selection then we can go back to the trough and sip a bit more of the XPath juice. With the approach I mention above the opportunity at least exists to attempt to use some existing tools and open source. Regards, /gww > -----Original Message----- > From: Andy Bierman [mailto:abierman@cisco.com] ... [lots of comments by Andy, Wes, Jeurgen, et. al.] ------_=_NextPart_001_01C44A71.C02DF054 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: sub-tree filtering proposals

I guess the point around the XPath proposal has = always been why don't we line up with an existing standard, even if we = only select a subset of that standard. That way we get the best of both = worlds -- we get just the features we want and we don't have to = reinvent the wheel. Further, if at some point down the road we decide = we want more powerful filtering/selection then we can go back to the = trough and sip a bit more of the XPath juice.

With the approach I mention above the opportunity at = least exists to attempt to use some existing tools and open = source.

Regards, /gww

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]=
...
[lots of comments by Andy, Wes, Jeurgen, et. = al.]

------_=_NextPart_001_01C44A71.C02DF054-- -- 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: From owner-netconf@ops.ietf.org Fri Jun 4 16:45:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09696 for ; Fri, 4 Jun 2004 16:45:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWLUt-00022h-NT for netconf-data@psg.com; Fri, 04 Jun 2004 20:41:03 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWLUs-000221-I5 for netconf@ops.ietf.org; Fri, 04 Jun 2004 20:41:02 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Jun 2004 13:40:48 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i54Kf0Mp027436; Fri, 4 Jun 2004 13:41:00 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-519.cisco.com [10.21.98.7]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUZ17413; Fri, 4 Jun 2004 13:40:59 -0700 (PDT) Message-Id: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Fri, 04 Jun 2004 13:34:55 -0700 To: "Glenn Waters" From: Andy Bierman Subject: RE: sub-tree filtering proposals Cc: Wes Hardaker , netconf@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 01:23 PM 6/4/2004, Glenn Waters wrote: >I guess the point around the XPath proposal has always been why don't we line up with an existing standard, even if we only select a subset of that standard. That way we get the best of both worlds -- we get just the features we want and we don't have to reinvent the wheel. Further, if at some point down the road we decide we want more powerful filtering/selection then we can go back to the trough and sip a bit more of the XPath juice. There are two problems with this approach: 1) It might not be easy to get the WG to agree on a minimal subset 2) An "arbitrary" subset of Xpath isn't likely to be easily supported by off-the-shelf Xpath tools >With the approach I mention above the opportunity at least exists to attempt to use some existing tools and open source. > >Regards, /gww Andy >> -----Original Message----- >> From: Andy Bierman [mailto:abierman@cisco.com] >... >[lots of comments by Andy, Wes, Jeurgen, et. al.] -- 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: From owner-netconf@ops.ietf.org Fri Jun 4 17:04:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12071 for ; Fri, 4 Jun 2004 17:04:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWLlV-0006CX-8x for netconf-data@psg.com; Fri, 04 Jun 2004 20:58:13 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWLlT-0006B3-U2 for netconf@ops.ietf.org; Fri, 04 Jun 2004 20:58:12 +0000 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i54KvaX03173; Fri, 4 Jun 2004 16:57:37 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jun 2004 16:57:37 -0400 Message-ID: From: "Glenn Waters" To: Andy Bierman Cc: Wes Hardaker , netconf@ops.ietf.org Subject: RE: sub-tree filtering proposals Date: Fri, 4 Jun 2004 16:57:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44A76.90EF1340" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44A76.90EF1340 Content-Type: text/plain > -----Original Message----- > From: Andy Bierman [mailto:abierman@cisco.com] > Sent: Friday, June 04, 2004 16:35 > To: Waters, Glenn [CAR:IO47:EXCH] > Cc: Wes Hardaker; netconf@ops.ietf.org > Subject: RE: sub-tree filtering proposals > > At 01:23 PM 6/4/2004, Glenn Waters wrote: > > >I guess the point around the XPath proposal has always been why don't we > line up with an existing standard, even if we only select a subset of that > standard. That way we get the best of both worlds -- we get just the > features we want and we don't have to reinvent the wheel. Further, if at > some point down the road we decide we want more powerful > filtering/selection then we can go back to the trough and sip a bit more > of the XPath juice. > > There are two problems with this approach: > 1) It might not be easy to get the WG to agree on a minimal subset Like it's easy to get any IETF WG to agree to anything. Seriously, at least with the XPath approach we have something that is already well defined to select from. The current approach is us trying to define and understand something new. Further, we have to "debug" the spec. > 2) An "arbitrary" subset of Xpath isn't likely to be easily supported > by off-the-shelf Xpath tools I suspect it will be easier to take open source and make it conform to the NetConf "XPath" than it will be to create completely new code. I've said my bit. If others are interested in the XPath approach then speak up now. I also don't want to rehash the XPath discussion any more than I just did in the last two emails. Regards, /gww ------_=_NextPart_001_01C44A76.90EF1340 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: sub-tree filtering proposals

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]=
> Sent: Friday, June 04, 2004 16:35
> To: Waters, Glenn [CAR:IO47:EXCH]
> Cc: Wes Hardaker; netconf@ops.ietf.org
> Subject: RE: sub-tree filtering = proposals
>
> At 01:23 PM 6/4/2004, Glenn Waters = wrote:
>
> >I guess the point around the XPath proposal = has always been why don't we
> line up with an existing standard, even if we = only select a subset of that
> standard. That way we get the best of both = worlds -- we get just the
> features we want and we don't have to reinvent = the wheel. Further, if at
> some point down the road we decide we want more = powerful
> filtering/selection then we can go back to the = trough and sip a bit more
> of the XPath juice.
>
> There are two problems with this = approach:
> 1) It might not be easy to get the WG to agree = on a minimal subset

Like it's easy to get any IETF WG to agree to = anything. Seriously, at least with the XPath approach we have something = that is already well defined to select from. The current approach is us = trying to define and understand something new. Further, we have to = "debug" the spec.

> 2) An "arbitrary" subset of Xpath = isn't likely to be easily supported
>    by off-the-shelf Xpath = tools

I suspect it will be easier to take open source and = make it conform to the NetConf "XPath" than it will be to = create completely new code.

I've said my bit. If others are interested in the = XPath approach then speak up now. I also don't want to rehash the XPath = discussion any more than I just did in the last two emails.

Regards, /gww

------_=_NextPart_001_01C44A76.90EF1340-- -- 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: From owner-netconf@ops.ietf.org Fri Jun 4 17:06:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12181 for ; Fri, 4 Jun 2004 17:06:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWLou-0007L3-Bz for netconf-data@psg.com; Fri, 04 Jun 2004 21:01:44 +0000 Received: from [64.165.72.146] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWLot-0007KR-ES for netconf@ops.ietf.org; Fri, 04 Jun 2004 21:01:43 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 414C611EBFD; Fri, 4 Jun 2004 14:01:40 -0700 (PDT) To: Andy Bierman Cc: "Glenn Waters" , Wes Hardaker , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> From: Wes Hardaker Organization: Sparta Date: Fri, 04 Jun 2004 14:01:40 -0700 In-Reply-To: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> (Andy Bierman's message of "Fri, 04 Jun 2004 13:34:55 -0700") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk >>>>> On Fri, 04 Jun 2004 13:34:55 -0700, Andy Bierman said: Andy> 2) An "arbitrary" subset of Xpath isn't likely to be easily supported Andy> by off-the-shelf Xpath tools It's likely most xpath implementations will support the subset you need (as opposed to the worse case of trying to get all xpath implementations to support all the xpath functionality in an interoperable way). vendors that want to only include the minimal part of xpath to reduce size, which I suspect is your point, could quite possibly find the sections of code they don't want and remove it [requires code access or a vendor willing to do the work for you of course]. In general, It's a heck of a lot easier to remove something from something you have too much of than create something for something you don't yet have or don't yet have all of. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- 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: From owner-netconf@ops.ietf.org Fri Jun 4 17:36:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15759 for ; Fri, 4 Jun 2004 17:36:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWMFg-000D2m-UI for netconf-data@psg.com; Fri, 04 Jun 2004 21:29:24 +0000 Received: from [209.128.82.1] (helo=shell4.bayarea.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWMFf-000D2C-Mr for netconf@ops.ietf.org; Fri, 04 Jun 2004 21:29:23 +0000 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i54LSsr11523; Fri, 4 Jun 2004 14:28:54 -0700 Message-Id: <5.2.0.9.2.20040604142140.02429d20@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 04 Jun 2004 14:28:45 -0700 To: Wes Hardaker , Andy Bierman From: "David T. Perkins" Subject: Re: sub-tree filtering proposals Cc: "Glenn Waters" , Wes Hardaker , netconf@ops.ietf.org In-Reply-To: References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, On the subseting, you just need to make sure that there is an error code that says that the XPATH might be valid, but the agent implementation doesn't support it. (And, of course, there will be people that will say that subsetting must not be allowed, since memory, CPU, and network bandwidth is free, and, thus, subsetting require more work to be done in figuring out how to take a "perfectly reasonable XPATH specification" and splitting it into several XPATH specifications, and combining the results.) At 02:01 PM 6/4/2004 -0700, Wes Hardaker wrote: >>>>>> On Fri, 04 Jun 2004 13:34:55 -0700, Andy Bierman said: > >Andy> 2) An "arbitrary" subset of Xpath isn't likely to be easily supported >Andy> by off-the-shelf Xpath tools > >It's likely most xpath implementations will support the subset you >need (as opposed to the worse case of trying to get all xpath >implementations to support all the xpath functionality in an >interoperable way). > >vendors that want to only include the minimal part of xpath to reduce >size, which I suspect is your point, could quite possibly find the >sections of code they don't want and remove it [requires code access >or a vendor willing to do the work for you of course]. In general, >It's a heck of a lot easier to remove something from something you >have too much of than create something for something you don't yet >have or don't yet have all of. Regards, /david t. perkins -- 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: From owner-netconf@ops.ietf.org Fri Jun 4 18:27:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24036 for ; Fri, 4 Jun 2004 18:27:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWN3U-000ONn-Aa for netconf-data@psg.com; Fri, 04 Jun 2004 22:20:52 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWN3R-000OND-H1 for netconf@ops.ietf.org; Fri, 04 Jun 2004 22:20:49 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 04 Jun 2004 15:21:10 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i54MKkls008276; Fri, 4 Jun 2004 15:20:47 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-519.cisco.com [10.21.98.7]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AUZ29040; Fri, 4 Jun 2004 15:20:45 -0700 (PDT) Message-Id: <6.1.1.1.2.20040604151132.03be7e00@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Fri, 04 Jun 2004 15:15:28 -0700 To: "David T. Perkins" From: Andy Bierman Subject: Re: sub-tree filtering proposals Cc: Wes Hardaker , "Glenn Waters" , netconf@ops.ietf.org In-Reply-To: <5.2.0.9.2.20040604142140.02429d20@127.0.0.1> References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <5.2.0.9.2.20040604142140.02429d20@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 02:28 PM 6/4/2004, David T. Perkins wrote: >Hi, > >On the subseting, you just need to make sure that there is an error code >that says that the XPATH might be valid, but the agent implementation >doesn't support it. > >(And, of course, there will be people that will say that subsetting >must not be allowed, since memory, CPU, and network bandwidth is >free, and, thus, subsetting require more work to be done in figuring >out how to take a "perfectly reasonable XPATH specification" >and splitting it into several XPATH specifications, and combining >the results.) How about if you, Glenn, and Wes write up a detailed specification of the exact Xpath subset a NETCONF agent must support, with rationale and examples? We need concrete proposals to consider this approach any further. If nobody's willing to write up a solution proposal, then the issue is moot. Andy >At 02:01 PM 6/4/2004 -0700, Wes Hardaker wrote: >>>>>>> On Fri, 04 Jun 2004 13:34:55 -0700, Andy Bierman said: >> >>Andy> 2) An "arbitrary" subset of Xpath isn't likely to be easily supported >>Andy> by off-the-shelf Xpath tools >> >>It's likely most xpath implementations will support the subset you >>need (as opposed to the worse case of trying to get all xpath >>implementations to support all the xpath functionality in an >>interoperable way). >> >>vendors that want to only include the minimal part of xpath to reduce >>size, which I suspect is your point, could quite possibly find the >>sections of code they don't want and remove it [requires code access >>or a vendor willing to do the work for you of course]. In general, >>It's a heck of a lot easier to remove something from something you >>have too much of than create something for something you don't yet >>have or don't yet have all of. >Regards, >/david t. perkins -- 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: From owner-netconf@ops.ietf.org Sat Jun 5 03:32:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29315 for ; Sat, 5 Jun 2004 03:32:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWVUf-000Om0-Uk for netconf-data@psg.com; Sat, 05 Jun 2004 07:21:29 +0000 Received: from [80.185.75.247] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWVUe-000Olf-7v for netconf@ops.ietf.org; Sat, 05 Jun 2004 07:21:28 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 1F5B082DD; Sat, 5 Jun 2004 09:21:27 +0200 (CEST) Date: Sat, 5 Jun 2004 09:21:27 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Wes Hardaker , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040605072127.GA1760@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Wes Hardaker , netconf@ops.ietf.org References: <6.1.1.1.2.20040528144708.03e31190@fedex.cisco.com> <20040603144325.GA1988@iu-bremen.de> <6.1.1.1.2.20040603152739.037a21d8@fedex.cisco.com> <20040603224515.GA5980@iu-bremen.de> <6.1.1.1.2.20040604064035.03949020@fedex.cisco.com> <6.1.1.1.2.20040604082734.0399a150@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040604082734.0399a150@fedex.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Jun 04, 2004 at 08:31:23AM -0700, Andy Bierman wrote: > It's not just the implementation time and runtime resources. > As Rob pointed out, the operators would need to learn how > to use Xpath. It's debatable whether operators will find > Xpath or this subtree filtering more complicated. I bet that several operators know XPATH better than we do. I am talking about the operators that actually automate their processes. The other crowd will continue using the CLI anyway. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Sat Jun 5 03:34:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29404 for ; Sat, 5 Jun 2004 03:34:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWVaQ-000PeF-Lt for netconf-data@psg.com; Sat, 05 Jun 2004 07:27:26 +0000 Received: from [80.185.75.247] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWVaP-000Pdy-I9 for netconf@ops.ietf.org; Sat, 05 Jun 2004 07:27:25 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 85C5182DD; Sat, 5 Jun 2004 09:27:25 +0200 (CEST) Date: Sat, 5 Jun 2004 09:27:25 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040605072725.GB1760@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Jun 04, 2004 at 01:34:55PM -0700, Andy Bierman wrote: > 2) An "arbitrary" subset of Xpath isn't likely to be easily supported > by off-the-shelf Xpath tools Off-the-shelf XPATH tools will most likely support more than the subset so I fail to see why this is a problem. In fact, I would like to support full XPATH in an implementation since we have XPATH anyway (since we use libxml). Having to support another subtree filtering mechanism is just added code and complexity for no gain. So hopefully the subtree filtering maps to an XPATH subset (in which case we can just map and use XPATH for everything). (But if it maps to an XPATH subset, then of course the question is why we do subtree filtering in the first place...) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Sat Jun 5 07:47:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08491 for ; Sat, 5 Jun 2004 07:47:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWZO7-000LUo-FV for netconf-data@psg.com; Sat, 05 Jun 2004 11:30:59 +0000 Received: from [80.185.88.103] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWZO5-000LUP-QT for netconf@ops.ietf.org; Sat, 05 Jun 2004 11:30:58 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 48BFF82A6; Fri, 4 Jun 2004 09:41:10 +0200 (CEST) Date: Fri, 4 Jun 2004 09:41:10 +0200 From: Juergen Schoenwaelder To: Michael Walton Cc: Andy Bierman , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040604074110.GA1670@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Michael Walton , Andy Bierman , netconf@ops.ietf.org References: <395F89B355756C4188231F50659A48AD078D3B@srv-mailct.azisa.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <395F89B355756C4188231F50659A48AD078D3B@srv-mailct.azisa.co.za> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Jun 04, 2004 at 09:32:56AM +0200, Michael Walton wrote: > For now - I experimented a little with XPath expressions in PyXML and > found one possible answer to Juergen's question: [...] > An expression that returns name, type and full-name looks like this: > > //users/user[name="fred"]/*[name()="name" or name()="type" or > name()="full-name] > > ... which is somewhat ugly, or you could use the "pipeline" operator as > suggested by Juergen: > > //users/user[name="fred"]/name | //users/user[name="fred"]/type | > //users/user[name="fred"]/full-name > > ... but that seems inefficient. Thanks. I knew this must be possible to do somehow. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Sat Jun 5 07:54:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08885 for ; Sat, 5 Jun 2004 07:54:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWZcs-000NiJ-DQ for netconf-data@psg.com; Sat, 05 Jun 2004 11:46:14 +0000 Received: from [80.185.88.103] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWZcr-000Nhz-BB for netconf@ops.ietf.org; Sat, 05 Jun 2004 11:46:13 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 1151882A6; Sat, 5 Jun 2004 13:46:11 +0200 (CEST) Date: Sat, 5 Jun 2004 13:46:11 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040605114611.GA1773@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Fri, Jun 04, 2004 at 01:34:55PM -0700, Andy Bierman wrote: > 1) It might not be easy to get the WG to agree on a minimal subset So here is a proposal. Netconf implementations must support filter expressions that are the following subset of XPATH expressions. The subset consists of the following features: 1) Absolute and relative paths (where path elements are element names): //users/user/name /users/user/name //name 2) Element value selectors: //users/user/name //users/user[name="fred"] //users/user[name="fred"]/name 3) Attributes selectors: //interface[@ifName="eth0"] 4) Expressions may contain multiple path expressions, separated by a | symbol //users/user[name="root"]/type | //interface[@ifName="eth0"] This set of features covers all the examples Andy posted and thus seems to be sufficient. ;-) What it boils down to is to select stuff by path, element values and attribute values. Sure, this needs to be written down more formally and in a way that is consistent with the XPATH specification. I am willing to give that a try if people can agree that this is indeed a reasonable XPATH subset that is easy to implement and serves our purpose. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Sat Jun 5 22:09:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20157 for ; Sat, 5 Jun 2004 22:09:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BWmn0-00043K-4P for netconf-data@psg.com; Sun, 06 Jun 2004 01:49:34 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BWmmz-000434-45 for netconf@ops.ietf.org; Sun, 06 Jun 2004 01:49:33 +0000 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 85466 for netconf@ops.ietf.org; Sat, 05 Jun 2004 21:48:05 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: Date: Sat, 5 Jun 2004 21:46:47 -0400 To: netconf@ops.ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi All, There is a new version of the Netconf over SSH draft available. It can be found at: http://www.ietf.org/internet-drafts/draft-ietf-netconf-ssh-01.txt Your review and comments would be appreciated. If possible, I'd like to get some feedback within the next couple of weeks so that I can update the draft again before San Diego. Thanks, Margaret -- 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: From owner-netconf@ops.ietf.org Mon Jun 7 05:54:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04632 for ; Mon, 7 Jun 2004 05:54:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXGad-000MZc-Ra for netconf-data@psg.com; Mon, 07 Jun 2004 09:38:47 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXGad-000MZD-6W for netconf@ops.ietf.org; Mon, 07 Jun 2004 09:38:47 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2004 02:39:03 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i579cjls004203 for ; Mon, 7 Jun 2004 02:38:45 -0700 (PDT) Received: from [10.61.124.221] (ams-clip-equant-dhcp-220.cisco.com [10.61.124.221]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id CAA10844 for ; Mon, 7 Jun 2004 02:38:43 -0700 (PDT) Message-ID: <40C437A6.5090704@cisco.com> Date: Mon, 07 Jun 2004 11:38:46 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: updated BEEP draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit will appear tomorrow. Eliot -- 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: From owner-netconf@ops.ietf.org Mon Jun 7 10:20:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18467 for ; Mon, 7 Jun 2004 10:20:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXKi1-000DSm-Qr for netconf-data@psg.com; Mon, 07 Jun 2004 14:02:41 +0000 Received: from [66.127.127.227] (helo=wes.hardakers.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXKhz-000DSM-Cb for netconf@ops.ietf.org; Mon, 07 Jun 2004 14:02:39 +0000 Received: by wes.hardakers.net (Postfix, from userid 274) id 8104911EBFD; Mon, 7 Jun 2004 07:02:38 -0700 (PDT) To: Andy Bierman Cc: Wes Hardaker , netconf@ops.ietf.org Subject: Re: Misc security considerations on the current netconf draft References: <6.0.3.0.2.20040521094759.02ae80c8@fedex.cisco.com> From: Wes Hardaker Organization: Sparta Date: Mon, 07 Jun 2004 07:02:34 -0700 Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,USERPASS autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Wes> I've had the chance again to review a recent copy of the protocol Wes> draft again, and have a few questions regarding what I read. Some of Wes> them are technical, some are nit-picks or clarification in nature, and Wes> some are security related. I'll split those categories into separate Wes> mail messages. Andy> thanks for your detailed review -- we need it! Sorry for the delay in responding too you. My clients aren't prioritizing netconf at the moment, so real work gets in the way sometimes.... Wes> One of the fundamental difficult parts of security with respect to the Wes> current netconf protocol is it has a large number of commands which Wes> are specific to portions of a given configuration set, but other Wes> commands that operate on the whole of the set. This Wes> mixing-and-matching is going to inherently cause problems (that I'm Wes> not at all convinced we can for-see them all which is what scares me Wes> more than anything else). Andy> Can you provide more details or an example that explains this more? Andy> I don't see why the agent implementation would have a problem here. Andy> Do you mean the manager will have problems? The rest of the message was about examples of the types of problems I was thinking about. I apparently didn't make that clear though. Andy> I decided to stop worrying about all the corner cases Andy> we have that result from misuse of the protocol operations. It's issues of misuse that I'm worried about. It's the cases where the misuse can lead to security compromises of some kind. Wes> Quick background on the documents current access-control: Some of the Wes> commands, like edit-config, operate on specific elements of a Wes> configuration set. These are subject to, currently, the access Wes> provided to the operator which has logged in over the "session". IE, Wes> if user A can't modify an interface on the console, he can't modify it Wes> over the netconf channel via edit-config. Wes> Wes> - Issue -1: Section 1.4.1 specifies that at least one netconf session Wes> must be supported. So it's possible to tie up a lame box using a Wes> single connection. Or its possible to tie up a medium box by Wes> logging in 10 times (its max)? Does a connection mean the initial Wes> connection to the port, or a successful login through the transport? Wes> (I hope just opening a TCP connection doesn't qualify and that a Wes> full session must be established) Andy> We aren't setting maximum limits, we're setting minimum limits. Andy> DOS attacks at the transport level are dealt with by the Andy> transport protocol, not NETCONF. It was the minimum level I was worried about. Actually, the whole statement seems kind of an odd "no-duh" to me and seems kind of silly to even state it, but hey... whatever. Wes> - Issue 0: section 2 does not discuss authentication of the server. Wes> EG, currently the only transports defined make use of certificates Wes> and section 2 doesn't talk about the need for the manager to Wes> validate the certificate of the TLS connection or ssh host key to Wes> ensure it is talking to who it thinks it is. Since the transport Wes> security requirements are not defined, it is important to talk Wes> (generically) about both identification of *both* sides in both Wes> cases (2 identities or a shared secret-key type identity) Andy> Can you work with Rob to fix the text? Sure. Wes> Wes> - Issue 1: current access control vs current protocol operations: Andy> I don't like all the fuzzy coupling to CLI in the document, but Andy> I agree with the design goal of leveraging access control Andy> technology already in place for CLI-based configuration> We need Andy> to specify this in detail or remove these 'console' references. IMHO, you have 2 choices: 1) remove it entirely and add a note in the security section stating that this protocol must not be implemented unless an adequate access control mechanism is implemented along with it and that no standardized access control model exists yet today. 2) Leave it in and better document it. Either way, all my points I think still remain a problem. If you don't specify *where* access control checks are important in the protocol, it worries me people will get it wrong when they actually implement it with their own access control mechanisms. My examples showed a number of hard cases to think about. I'm very convinced that without such guidelines, this protocol will be implemented in insecure ways. I suspect you disagree that it is a problem or are not willing to expend the energy at this point in fixing this problem since you're working so hard to move forward. Wes> Currently the document specifies that netconf commands must be Wes> subject to access control restrictions as if the same user was at Wes> the console. IE, if you can't change the IP address at the console Wes> you must not be able to change it via netconf. Wes> Wes> What is missing in this approach is what should be legal remotely Wes> over what protocols and what isn't. There are many cases where an Wes> operator in hardened security environments may only want to Wes> configure some aspect of a device if he can physically touch it. Wes> Let alone the ability to specify the minimum "protection level" a Wes> protocol must support before a operator can legally modify or view Wes> some aspect of it. I know that interoperable access-control hasn't Wes> been dealt with from a standards point of view, but the protocol Wes> as-is seems dangerous to me as currently specified. Wes> Wes> A fundamental problem here is that existing access control Wes> mechanisms weren't necessarily designed to accommodate Wes> over-the-network modifications. They weren't necessarily designed Wes> to say "don't let people do things without at least encryption Wes> turned on". They weren't necessarily designed that way because it Wes> wasn't expected that some future protocol would call on them that Wes> way. This issue will, hopefully, go away once a standardized access Wes> control system can be properly applied. But in the mean time Wes> implementation of the netconf system means opening avenues of Wes> operation that you can't turn off or didn't even know you were Wes> allowing in. Wes> Wes> Also, when new standardized data models get deployed, will they Wes> be required to check their existing ACLs against the newer data Wes> models? This is a potentially non-trivial mapping which could even Wes> be incompatible. Wes> Wes> When a standardized access control model gets figured out, will it Wes> be required to check both the local ACL implementation along with Wes> the standardized one (it should be, IMHO, because to do otherwise Wes> would potentially allow stuff through which was not expected to Wes> succeed). Wes> Wes> One of the ACL issues that will likely come up in the future is the Wes> frequent re-treeing issue as it applies to access control. It has Wes> been frequently said that one of the advantages of XML is that Wes> anytime a change needs to be made to how the data is displayed or Wes> arranged, all you have to do is retree it and deploy the new Wes> structure. Because its in xml, translating among old and new data Wes> models will be a snap. What I think, however, will be difficult Wes> will be ensuring that an ACL setting defined by a NOC for a given Wes> operational environment. If re-treeing happens frequently, its Wes> possible that access control "holes" will appear when new updates Wes> are applied to a network. Doing access control by offering Wes> inclusion only rather than exclusion is going to be critical here to Wes> protect against this problem. Andy> Response to all comments related to granular access control: Andy> We are not chartered to work on the issue at this time. Andy> How does the agent know who can do what to which objects? Andy> First you standardize a data definition language that Andy> includes mechanisms to describe the access control requirements Andy> for all objects and attributes (e.g., MAX-ACCESS, MIN-ACCESS), Andy> standardize data naming, and standardize an overall data model Andy> framework. Then you can design an access control model and Andy> a data model to configure and monitor it. Andy> I don't really want to throw in a temporary access control model Andy> that provides a little bit of granularity. I think this is big Andy> enough and important enough that a WG spend the time to get it Andy> right the first time. You do realize that you *have* specified access control in the current document, right? Andy> Of course, nothing is stopping anyone from writing an I-D Andy> proposing an access control model, to get this work started. As I mentioned 2 years ago when this work was first getting going, I suggested that security and data modeling be started immediately. I'm still sad that it hasn't been started. At least the data modeling has almost begun... Wes> - Issue 2: Data modification style types (cli vs xml) with access control Wes> Wes> Current access control mechanisms are potentially designed for CLI Wes> usage. They may not all be designed with the ability to figure out Wes> that if user A is trying to set an IP address trough netconf that it Wes> maps to one of a potentially few CLI requests that might effect the Wes> same data. netconf operates on the data directly, where many access Wes> control models within CLI systems may model their ACL approach on the Wes> commands themselves instead. This means that implementations will Wes> have to do a potentially complex and error-prone analysis of current Wes> CLI access control settings to data modification access control Wes> settings. It makes implementing the current user-based ACL setting Wes> requirement difficult, only because of the difference in how things Wes> are done: data vs cli vs xxx? Wes> Wes> - Issue 3: global operations vs specific access control Wes> Wes> Operations such as lock, commit, validate, copy-config, etc operate Wes> on an entire collection of configuration data. But no where does Wes> the document specify how access control is treated in these cases. Wes> The fundamental issue here, which I've raised before specific to Wes> just the "lock" operation, is that the protocol is designed from a Wes> "root"-only mode perspective. There has been a general goal all Wes> along to offer a more limited-role-oriented approach as well, parts Wes> of which exist now (the documentation describing the use of existing Wes> access control mechanisms) and parts of which are not yet specified Wes> (future access control, for which there has always been a desire to Wes> implement a localized modification limitation (user A can do this, Wes> but not that)). Wes> Wes> The problem is that no where in the document does it say where Wes> access control (current or future) is applied. There are hints, but Wes> nothing explicit and complete. This leads to questions which I'm Wes> not sure about the answers to, like: Wes> Wes> setup: lets say a user A can modify value X but not Y (if you want Wes> a hard core example to think about, consider the case where Y Wes> might be an IP address of an interface, and X might be the link Wes> up/down status). Lets also say he can't even see the value Z (EG, Wes> firewall policy rules). Wes> Wes> - Can a user modify the value Y in the candidate vs running Wes> config? (one or neither?) Wes> - Can a user modify the value Y in a file/URL config store? Wes> - Can a user validate all of the candidate config including value Wes> Z even if he couldn't see Z normally. Wes> - If a user copy's the running config to the candidate config, Wes> does it copy the candidate's value for Y and Z. Wes> - Can a user create a file containing Y and Z settings, and then Wes> use copy-config to candidate? Wes> Wes> This is not an exhaustive list. I'll leave it to an exercise to Wes> the reader to generate a complete list for these cases. Wes> Wes> - Issue 4: global operations vs multiple users Wes> Wes> The above list was just a starting list for a problem which only Wes> gets significantly compounded when you start involving multiple Wes> users. Wes> Wes> Further setup: B is a root-level operator than can do everything. Wes> Wes> - If B doesn't hold a lock on the candidate config and wants to Wes> modify restricted values Y or Z, can user A issue a Wes> discard-changes operation in the middle of B's edit stream, but Wes> before he does a commit (consider B deleting user A and A Wes> rolling it back before B commits it). sub: what happens with Wes> A's session if his user is deleted in mid-stream, by the way. Wes> - If B does hold a lock on the candidate config, can A Wes> discard-changes to it? I'd assume not, but I'd have to just Wes> hope that everyone implementing it would also realize this. Wes> - If B does hold a lock on the candidate config, can A copy it to Wes> running in the middle of his edits? (bad if B just opened up an Wes> access control or firewall setting where his next operation was Wes> going to close a particularly bad operation or port in the next Wes> operation). Hopefully the copy-config would validate access Wes> control settings of all of the source first against whoever was Wes> actually committing? Wes> - If B modifies the candidate config for value Z (which A can't Wes> see), and A runs on the candidate config and there is Wes> a syntax error in Z's value, did the implementation ensure that Wes> the error message doesn't contain information about the exact Wes> nature of the problem (which would include the value, and Wes> possibly the configuration path (which can frequently contain Wes> valuable information)? Wes> - If B temporarily modifies the running config value Y, can A Wes> copy-config the running config to the startup data store thus Wes> making the change persistent? Wes> - If B does a confirmed commit and blows it and does something Wes> stupid, can A issue a ? Wes> Wes> Wes> - Issue 5: protocol chaining: Wes> - We've discussed this before, but as long as I was writing stuff up Wes> anyway: the use of the url capability implies that authentication Wes> information must be passed from the netconf session to the URL Wes> session. This could be done within the url for cases where that Wes> is possible and the URL supports it (http://user:password@host/ if Wes> I remember correctly), (note the drop in protocol protection in Wes> this case, which was a deliberate example). If done properly Wes> through https using TLS, how do you specify which server certs or Wes> parent certificates are acceptable to avoid a spoofing attack? Wes> Some of this, of course, needs to be handled by the data model Wes> (like certificate authorization configuration). Andy> these issues need to be worked out in the draft If you mean the issues 2-5, I'm happy to hear that. I'm not sure from your sentence which issues you're referring to. It could have been you only were talking about #5. Wes> - Issue 6: security considerations are not mandatory to implement. Wes> Users won't read them. Cheap management systems may not implement Wes> them. Wes> Wes> EG: its written in many places you "should" use a lock, but that Wes> doesn't mean that everyone will have read the document entirely and Wes> that everyone implementing management stations will implement the Wes> lock "should". Users won't be able to have an easy basis of Wes> understanding to enable them to pick between secure management Wes> stations which properly use locking techniques and those that do Wes> not. Wes> Wes> User's know that they need to pick tools with appropriate Wes> authentication and encryption, and they know that they may know that Wes> they need to pick tools that prevent multiple interacting managers Wes> from conflicting with each other (IE, they need locking). However, Wes> locking is generally not considered necessary for security by users Wes> but the netconf protocol states in many places that you should use Wes> it for security reasons. I don't think end-users will be able to Wes> make intelligent security choices about this. Wes> Wes> In summary: It bothers me that the solution to netconf security Wes> potential problems is to just "document it in the security Wes> considerations". I suspect this will make the protocol harder to Wes> deploy and more vulnerable to future problems. Andy> These security concerns are no different than for any other Andy> protocol you could name. Operators and developers need to Andy> be aware of security details. My problem is that the issues are complex and not discussed anywhere. It vaguely states that you should use locks, but doesn't state how critical they are. Wes> Many of these issues and their examples are only initial quickly Wes> thought up examples. What scares me is not the examples themselves, Wes> but rather how each company might decide what to do in a different Wes> way. Or even worse, miss some of the critical things to get right Wes> that are subtle (the copy-config or commit to running during mid-edit Wes> by someone else with greater power is a good example, as well as the Wes> discard-changes in mid-edit). Access control will likely need to be Wes> checked at multiple points, and it is critical to get all those points Wes> right regardless of whether this applies to existing access control Wes> mechanisms or future ones. IE, you can't discard describing how Wes> access control is applied just because you're leveraging existing Wes> mechanisms. You still need to state how and when it is applied. Andy> We can state where access control (in the processing flow) is Andy> applied. We can specify a standard access control model as Andy> follow-up work. Not unlike how VACM was added to SNMP. I'd very much like to see where access control is applied. This would alleviate many of my concerns. Wes> I'm not convinced we could enumerate all the tricky things to get Wes> right with 100% certainty. I'm also not looking forward to the many Wes> rules that will have to be stated when we get to the standardized Wes> access control model. I don't believe implementations will correctly Wes> map their access control settings to the current protocol operations Wes> properly. 1-1 mappings are fairly easy to get right. M-N mappings Wes> are quite a bit harder to get right, which is where this is currently Wes> left. Andy> We aren't creating an access control model now, but when we do, Andy> I'm sure we won't get it 100% perfect on the first try. Well, I hope future netconf customers read this ;-) They should wait for a few revisions I guess :-) -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett -- 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: From owner-netconf@ops.ietf.org Mon Jun 7 13:38:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00683 for ; Mon, 7 Jun 2004 13:38:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXNvS-0000TV-Hs for netconf-data@psg.com; Mon, 07 Jun 2004 17:28:46 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXNvP-0000T0-KB for netconf@ops.ietf.org; Mon, 07 Jun 2004 17:28:43 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2004 10:28:01 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i57HScls017460; Mon, 7 Jun 2004 10:28:38 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-82.cisco.com [10.21.96.82]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AVA31415; Mon, 7 Jun 2004 10:28:37 -0700 (PDT) Message-Id: <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 07 Jun 2004 10:23:17 -0700 To: j.schoenwaelder@iu-bremen.de From: Andy Bierman Subject: Re: sub-tree filtering proposals Cc: netconf@ops.ietf.org In-Reply-To: <20040605114611.GA1773@iu-bremen.de> References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 04:46 AM 6/5/2004, Juergen Schoenwaelder wrote: >On Fri, Jun 04, 2004 at 01:34:55PM -0700, Andy Bierman wrote: I have asked the XML Directorate to consider the subtree proposal and this Xpath subset proposal, and give their opinion. If they think we should use this Xpath subset, then I don't mind choosing Xpath subset over subtree filtering. >> 1) It might not be easy to get the WG to agree on a minimal subset > >So here is a proposal. Netconf implementations must support filter >expressions that are the following subset of XPATH expressions. The >subset consists of the following features: > >1) Absolute and relative paths (where path elements are element > names): > > //users/user/name > /users/user/name > //name > >2) Element value selectors: > > //users/user/name > //users/user[name="fred"] > //users/user[name="fred"]/name > >3) Attributes selectors: > > //interface[@ifName="eth0"] How can multiple element and/or attribute selectors be combined? >4) Expressions may contain multiple path expressions, separated by > a | symbol > > //users/user[name="root"]/type | //interface[@ifName="eth0"] > >This set of features covers all the examples Andy posted and thus seems >to be sufficient. ;-) What it boils down to is to select stuff by path, >element values and attribute values. I think this is a good minimal subset. It's actually way more powerful than what we have now with SNMP or CLI. >Sure, this needs to be written down more formally and in a way that is >consistent with the XPATH specification. I am willing to give that a >try if people can agree that this is indeed a reasonable XPATH subset >that is easy to implement and serves our purpose. > >/js 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: From owner-netconf@ops.ietf.org Mon Jun 7 17:16:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20744 for ; Mon, 7 Jun 2004 17:16:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXRGu-000KkO-2R for netconf-data@psg.com; Mon, 07 Jun 2004 21:03:08 +0000 Received: from [80.185.77.98] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXRGs-000Kjv-PN for netconf@ops.ietf.org; Mon, 07 Jun 2004 21:03:07 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id B47C287B5; Mon, 7 Jun 2004 23:03:05 +0200 (CEST) Date: Mon, 7 Jun 2004 23:03:05 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040607210305.GA1781@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Jun 07, 2004 at 10:23:17AM -0700, Andy Bierman wrote: > How can multiple element and/or attribute selectors be combined? As Joel M. Halpern already pointed out in private email, you can have multiple [] selections, for example: //interface[type="ethernet"][connector="present"] I am assuming here an interface representation such as: eth0 ethernet present The same works for attributes and things can even be nested. Assuming an SNMP message in XML format, a valid expression would be: //snmp[version="1"][community="public"]/pdu[@type="getnext"] This would match a document such as the following: 1 public 1804289385 0 0 1.3.6.1.2.1.1.3 [Don't worry about the strange example - this is simply copied from some stuff I am working on today and by no means represents any reasonable data model for netconf.] /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Mon Jun 7 17:18:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21033 for ; Mon, 7 Jun 2004 17:18:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXRKt-000ME1-BJ for netconf-data@psg.com; Mon, 07 Jun 2004 21:07:15 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXQ1n-00027z-NI for netconf@ops.ietf.org; Mon, 07 Jun 2004 19:43:27 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11205; Mon, 7 Jun 2004 15:43:25 -0400 (EDT) Message-Id: <200406071943.PAA11205@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-soap-02.txt Date: Mon, 07 Jun 2004 15:43:25 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Over SOAP Author(s) : T. Goddard Filename : draft-ietf-netconf-soap-02.txt Pages : 20 Date : 2004-6-7 The device management protocol NETCONF is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of SOAP over HTTP. NETCONF finds many benefits in this environment: from the re-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe a SOAP over HTTP binding that, when used with persistent HTTP connections, yields an application protocol sufficient for NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-soap-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-soap-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-7154507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-soap-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-soap-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-7154507.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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: From owner-netconf@ops.ietf.org Mon Jun 7 18:05:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21032 for ; Mon, 7 Jun 2004 17:18:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXRLb-000MPH-UB for netconf-data@psg.com; Mon, 07 Jun 2004 21:07:59 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXQ1j-00027a-27 for netconf@ops.ietf.org; Mon, 07 Jun 2004 19:43:23 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11198; Mon, 7 Jun 2004 15:43:20 -0400 (EDT) Message-Id: <200406071943.PAA11198@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-beep-01.txt Date: Mon, 07 Jun 2004 15:43:20 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : BEEP Application Protocol Mapping for NETCONF Author(s) : E. Lear, K. Crozier Filename : draft-ietf-netconf-beep-01.txt Pages : 15 Date : 2004-6-7 This document specifies an application protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-beep-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-beep-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-7154501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-beep-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-beep-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-7154501.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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: From owner-netconf@ops.ietf.org Tue Jun 8 06:46:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17577 for ; Tue, 8 Jun 2004 06:46:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXdso-0007xC-3Q for netconf-data@psg.com; Tue, 08 Jun 2004 10:31:06 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXdsl-0007vv-9e for netconf@ops.ietf.org; Tue, 08 Jun 2004 10:31:03 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Jun 2004 03:30:29 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i58AV1Xl003882 for ; Tue, 8 Jun 2004 03:31:01 -0700 (PDT) Received: from [144.254.23.201] (dhcp-data-vlan10-23-201.cisco.com [144.254.23.201]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id DAA21109 for ; Tue, 8 Jun 2004 03:31:00 -0700 (PDT) Message-ID: <40C59563.5070804@cisco.com> Date: Tue, 08 Jun 2004 12:30:59 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: locking and teardown Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A colleague of mine points out some holes in the BEEP mapping regarding locking and teardown. Let's be clear: an agent MUST NOT under normal circumstances initiate a teardown, unless directed to do so by an administrator. In addition, when a connection is closed is a transport matter, and so the various mappings must make mention of it. I will have an updated draft out soon. Before I update it, do we need to add any additional words in the mappings for "confirm commit"? Eliot -- 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: From owner-netconf@ops.ietf.org Tue Jun 8 06:47:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17615 for ; Tue, 8 Jun 2004 06:47:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXdy0-0008oH-Ve for netconf-data@psg.com; Tue, 08 Jun 2004 10:36:28 +0000 Received: from [134.169.34.18] (helo=agitator.ibr.cs.tu-bs.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXdxx-0008nw-1u for netconf@ops.ietf.org; Tue, 08 Jun 2004 10:36:25 +0000 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i58AaNKI001173 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 8 Jun 2004 12:36:23 +0200 Date: Tue, 08 Jun 2004 12:36:23 +0200 From: =?ISO-8859-1?Q?Frank_Strau=DF?= To: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> In-Reply-To: <20040607210305.GA1781@iu-bremen.de> References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> X-Mailer: Mulberry/3.1.4 (Linux/x86) X-PGP-Key: 1024D/3B8A33AA 2000-08-03 Frank Strauss X-PGP-Fingerprint: F6CD 195C F141 4CF8 72AD 0CB0 CD24 F033 3B8A 33AA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IBRFilter-SpamReport: -1.524 () BAYES_01 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On Mon, Jun 07, 2004 at 10:23:17AM -0700, Andy Bierman wrote: > >> How can multiple element and/or attribute selectors be combined? I'm not sure, whether the question is about XPath in general or a proposed specific subset/derivation functionality. In case of true XPath, I'd like to add this information... > As Joel M. Halpern already pointed out in private email, you can > have multiple [] selections, for example: > > //interface[type="ethernet"][connector="present"] This kind of operation first builds the set of all s which is then limited to those with type="ethernet" and this subset is then limited to those with connector="present". This means a sequence of predicates is not commutative, in contrast to the logical AND operator. An example where this would be signifcant is this: //interface[type="ethernet"][position()=last()] would address the last ethernet interface, while //interface[position()=last()][type="ethernet"] would address the last interface, if it is an ethernet interface, otherwise an empty node set. Xpath predicates (the parts in brackets) may contain boolean operators ("expr1 and expr2","expr1 or expr2", "not(expr)"). -- 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: From owner-netconf@ops.ietf.org Tue Jun 8 12:16:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05866 for ; Tue, 8 Jun 2004 12:16:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXj5c-000M6y-Cq for netconf-data@psg.com; Tue, 08 Jun 2004 16:04:40 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXj5b-000M6l-Ir for netconf@ops.ietf.org; Tue, 08 Jun 2004 16:04:39 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 08 Jun 2004 09:05:39 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i58G4ZtV016516; Tue, 8 Jun 2004 09:04:36 -0700 (PDT) Received: from sberl-w2k.cisco.com (sjc-vpn1-309.cisco.com [10.21.97.53]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATY89049; Tue, 8 Jun 2004 09:03:23 -0700 (PDT) Message-Id: <4.3.2.7.2.20040608090154.031e4328@mira-sjcm-1.cisco.com> X-Sender: sberl@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jun 2004 09:04:32 -0700 To: j.schoenwaelder@iu-bremen.de, Michael Walton From: Steve Berl Subject: Re: sub-tree filtering proposals Cc: Andy Bierman , netconf@ops.ietf.org In-Reply-To: <20040604074110.GA1670@iu-bremen.de> References: <395F89B355756C4188231F50659A48AD078D3B@srv-mailct.azisa.co.za> <395F89B355756C4188231F50659A48AD078D3B@srv-mailct.azisa.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Does it bother anyone else that the 1 filter expression is actually doing 2 things? First, it identifies the root of a tree of XML elements in the document and second it tells which subelements of those elements are to be returned. Aren't these 2 distinct functions that should better be represented by 2 separate expressions? -steve At 12:41 AM 6/4/2004, Juergen Schoenwaelder wrote: >On Fri, Jun 04, 2004 at 09:32:56AM +0200, Michael Walton wrote: > >> For now - I experimented a little with XPath expressions in PyXML and >> found one possible answer to Juergen's question: > >[...] > >> An expression that returns name, type and full-name looks like this: >> >> //users/user[name="fred"]/*[name()="name" or name()="type" or >> name()="full-name] >> >> ... which is somewhat ugly, or you could use the "pipeline" operator as >> suggested by Juergen: >> >> //users/user[name="fred"]/name | //users/user[name="fred"]/type | >> //users/user[name="fred"]/full-name >> >> ... but that seems inefficient. > >Thanks. I knew this must be possible to do somehow. > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > >-- >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: -- 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: From owner-netconf@ops.ietf.org Tue Jun 8 12:50:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07655 for ; Tue, 8 Jun 2004 12:50:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXjcM-0002hr-7h for netconf-data@psg.com; Tue, 08 Jun 2004 16:38:30 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXjcL-0002hM-2H for netconf@ops.ietf.org; Tue, 08 Jun 2004 16:38:29 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Jun 2004 09:37:57 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i58GcPAX025882; Tue, 8 Jun 2004 09:38:25 -0700 (PDT) Received: from sberl-w2k.cisco.com (sjc-vpn1-309.cisco.com [10.21.97.53]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ATY92016; Tue, 8 Jun 2004 09:37:13 -0700 (PDT) Message-Id: <4.3.2.7.2.20040608091659.03cdce88@mira-sjcm-1.cisco.com> X-Sender: sberl@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jun 2004 09:38:22 -0700 To: lear@cisco.com, kcrozier@cisco.com From: Steve Berl Subject: Re: I-D ACTION:draft-ietf-netconf-beep-01.txt Cc: netconf@ops.ietf.org In-Reply-To: <200406071943.PAA11198@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Ken and Eliot, A few little comments on the draft. Section 2.1 Session Initiation In the 3rd paragraph it says that the initiator starts the SASL exchange to authenticate itself. Is there also a way for the listener to authenticate itself? Is that part of the TLS exchange that happened earlier or is it part of the SASL exchange which is not mentioned here? This is important because in the next paragraph you say that there is no longer a need to distinguish initiator from listener. But for purposes of authorization of commands, it is important that the agent know the identity of the manager. So I think there should be some text in here to help keep straight that somehow during the setup of the channel, whoever it is that is going to end up being the manager, whther they are initiator or listener, must have authenticated themselves. In paragraph 5 of section 2.1 there needs to be a space in "capabilitiesexchange". Also in that same paragraph, my web browser didn't properly expand the &dquot; around the word "operational". Not sure if this is my web browser or the document that has a problem. - pg 6 in "Profile summaries" there seems to be a tab or space issue where the data doesn't line up in the columns properly. Again this could be an issue with the web browser. - pg 6 in "Entity Definitions "PRC" should probably be "RPC". Have fun, -steve At 12:43 PM 6/7/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Network Configuration Working Group of the IETF. > > Title : BEEP Application Protocol Mapping for NETCONF > Author(s) : E. Lear, K. Crozier > Filename : draft-ietf-netconf-beep-01.txt > Pages : 15 > Date : 2004-6-7 > >This document specifies an application protocol mapping for the >NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-01.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-netconf-beep-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-netconf-beep-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >------------------------------------------------------------------------- >In order to maintain computing infrastructure integrity, Cisco Systems >Enterprise Messaging Services and InfoSec teams have set a mail policy >disallowing executable attachments in email. > >This message contained an executable attachment type that is prohibited >by this policy. The attachment has been removed from this message and >copied to quarantine by our systems. It will be held in quarantine for >seven days in the event that the content needs to be retrieved. > > >------------------------------------------------------------------------- >For further reference information about viruses and email antivirus >efforts within Cisco, please visit: > >http://wwwin.cisco.com/it/ems/services/antiviral > > >If your concern isn't addressed by the information in this notification >or the above web page, you may open a support request: > >http://wwwin.cisco.com/support/ > >Select "Messaging", "Email-Related", "Mail Routing" > >Please include in the text of your case the following information: > >* Full headers of the message. Documentation on displaying the full >headers is available at this URL: > >http://wwwin.cisco.com/support/library/faqs/solution002471.html > >* This unique quarantine identifier: i57L9MXl028403 > >If the matter is urgent, you may follow up by calling one of the below >referenced numbers. Please make every effort to provide the above >requested information via the support web tool prior to calling as it >will greatly aid the resolution of your issue. > >Americas: >1 408 526 8888 > >Asiapac >+61 2 8446 8888 > >EMEA >+31 20 485 4888 > >Japan >+81 3 5549 6888 > >US (Toll Free) >1| 800| 888| 8187| (ext.68888) > >Thank you for your cooperation, > >Enterprise Messaging Services >Cisco Systems, Inc >Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > >NextPart >s, Inc > Services > >f your issue. >rior to calling as it >e >sage. > >--OtherAccess-- >c > Services > >f your issue. >rior to calling as it >e >sage. -- 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: From owner-netconf@ops.ietf.org Tue Jun 8 14:39:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15355 for ; Tue, 8 Jun 2004 14:39:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXlNM-0002kr-8E for netconf-data@psg.com; Tue, 08 Jun 2004 18:31:08 +0000 Received: from [80.185.93.33] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXlNI-0002kB-Re for netconf@ops.ietf.org; Tue, 08 Jun 2004 18:31:05 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 0AF1E87B4; Tue, 8 Jun 2004 20:31:02 +0200 (CEST) Date: Tue, 8 Jun 2004 20:31:02 +0200 From: Juergen Schoenwaelder To: Steve Berl Cc: Michael Walton , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040608183102.GA1863@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Steve Berl , Michael Walton , netconf@ops.ietf.org References: <395F89B355756C4188231F50659A48AD078D3B@srv-mailct.azisa.co.za> <395F89B355756C4188231F50659A48AD078D3B@srv-mailct.azisa.co.za> <4.3.2.7.2.20040608090154.031e4328@mira-sjcm-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20040608090154.031e4328@mira-sjcm-1.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Jun 08, 2004 at 09:04:32AM -0700, Steve Berl wrote: > Does it bother anyone else that the 1 filter expression is actually > doing 2 things? > > First, it identifies the root of a tree of XML elements in the document > and second it tells which subelements of those elements are to be returned. > Aren't these 2 distinct functions that should better be represented by 2 > separate expressions? An XPATH expression always identifies a nodeset (in XML speak) and the examples I showed are AFAIK valid XPATH expressions. You can match against element names, element contents and attribute contents with the restricted subset I have proposed. Full XPATH allows you to do much more fancy selection of nodesets. But at the end, it all boils down to selecting nodeset when using XPATH, so I fail to understand your concern. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Tue Jun 8 16:33:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22225 for ; Tue, 8 Jun 2004 16:33:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXn62-0003fD-LL for netconf-data@psg.com; Tue, 08 Jun 2004 20:21:22 +0000 Received: from [47.129.242.157] (helo=zcars0m9.nortelnetworks.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXn61-0003eq-EZ for netconf@ops.ietf.org; Tue, 08 Jun 2004 20:21:21 +0000 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i58KJmr27784; Tue, 8 Jun 2004 16:19:49 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jun 2004 16:19:49 -0400 Message-ID: From: "Glenn Waters" To: j.schoenwaelder@iu-bremen.de, Andy Bierman Cc: netconf@ops.ietf.org Subject: RE: sub-tree filtering proposals Date: Tue, 8 Jun 2004 16:19:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44D95.F2809D3C" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44D95.F2809D3C Content-Type: text/plain I'm happy with the set that is proposed. Provides enough power, is simple enough, and it's in line with XPATH. Regards, /gww > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Saturday, June 05, 2004 07:46 > To: Andy Bierman > Cc: netconf@ops.ietf.org > Subject: Re: sub-tree filtering proposals > > On Fri, Jun 04, 2004 at 01:34:55PM -0700, Andy Bierman wrote: > > > 1) It might not be easy to get the WG to agree on a minimal subset > > So here is a proposal. Netconf implementations must support filter > expressions that are the following subset of XPATH expressions. The > subset consists of the following features: > > 1) Absolute and relative paths (where path elements are element > names): > > //users/user/name > /users/user/name > //name > > 2) Element value selectors: > > //users/user/name > //users/user[name="fred"] > //users/user[name="fred"]/name > > 3) Attributes selectors: > > //interface[@ifName="eth0"] > > 4) Expressions may contain multiple path expressions, separated by > a | symbol > > //users/user[name="root"]/type | //interface[@ifName="eth0"] > > This set of features covers all the examples Andy posted and thus seems > to be sufficient. ;-) What it boils down to is to select stuff by path, > element values and attribute values. > > Sure, this needs to be written down more formally and in a way that is > consistent with the XPATH specification. I am willing to give that a > try if people can agree that this is indeed a reasonable XPATH subset > that is easy to implement and serves our purpose. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, > Germany > > -- > 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: ------_=_NextPart_001_01C44D95.F2809D3C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: sub-tree filtering proposals

I'm happy with the set that is proposed. Provides = enough power, is simple enough, and it's in line with XPATH.

Regards, /gww

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-b= remen.de]
> Sent: Saturday, June 05, 2004 07:46
> To: Andy Bierman
> Cc: netconf@ops.ietf.org
> Subject: Re: sub-tree filtering = proposals
>
> On Fri, Jun 04, 2004 at 01:34:55PM -0700, Andy = Bierman wrote:
>
> > 1) It might not be easy to get the WG to = agree on a minimal subset
>
> So here is a proposal. Netconf implementations = must support filter
> expressions that are the following subset of = XPATH expressions. The
> subset consists of the following = features:
>
> 1) Absolute and relative paths (where path = elements are element
>    names):
>
>    //users/user/name
>    /users/user/name
>    //name
>
> 2) Element value selectors:
>
>    //users/user/name
>    = //users/user[name=3D"fred"]
>    = //users/user[name=3D"fred"]/name
>
> 3) Attributes selectors:
>
>    = //interface[@ifName=3D"eth0"]
>
> 4) Expressions may contain multiple path = expressions, separated by
>    a | symbol
>
>    = //users/user[name=3D"root"]/type | = //interface[@ifName=3D"eth0"]
>
> This set of features covers all the examples = Andy posted and thus seems
> to be sufficient. ;-) What it boils down to is = to select stuff by path,
> element values and attribute values.
>
> Sure, this needs to be written down more = formally and in a way that is
> consistent with the XPATH specification. I am = willing to give that a
> try if people can agree that this is indeed a = reasonable XPATH subset
> that is easy to implement and serves our = purpose.
>
> /js
>
> --
> Juergen Schoenwaelder =             = International University Bremen
> <http://www.eecs.iu-bremen.de/>   = ;        P.O. Box 750 561, 28725 = Bremen,
> Germany
>
> --
> 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: <http://ops.ietf.org/lists/netconf/>

------_=_NextPart_001_01C44D95.F2809D3C-- -- 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: From owner-netconf@ops.ietf.org Tue Jun 8 18:25:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01092 for ; Tue, 8 Jun 2004 18:25:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BXovU-0005My-5u for netconf-data@psg.com; Tue, 08 Jun 2004 22:18:36 +0000 Received: from [209.55.107.55] (helo=mauve.mrochek.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXosA-0004Ar-6X for netconf@ops.ietf.org; Tue, 08 Jun 2004 22:15:10 +0000 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LB11S2VFKG00005R@mauve.mrochek.com> for netconf@ops.ietf.org; Tue, 08 Jun 2004 15:15:09 -0700 (PDT) Date: Tue, 08 Jun 2004 14:50:48 -0700 (PDT) From: ned.freed@mrochek.com Subject: Re: sub-tree filtering proposals In-reply-to: "Your message dated Tue, 08 Jun 2004 20:31:02 +0200" <20040608183102.GA1863@iu-bremen.de> To: Juergen Schoenwaelder Cc: Steve Berl , Michael Walton , netconf@ops.ietf.org Message-id: <01LB24Y646XY00005R@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Virus-test: FALSE References: <395F89B355756C4188231F50659A48AD078D3B@srv-mailct.azisa.co.za> <4.3.2.7.2.20040608090154.031e4328@mira-sjcm-1.cisco.com> <20040608183102.GA1863@iu-bremen.de> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > On Tue, Jun 08, 2004 at 09:04:32AM -0700, Steve Berl wrote: > > Does it bother anyone else that the 1 filter expression is actually > > doing 2 things? > > > > First, it identifies the root of a tree of XML elements in the document > > and second it tells which subelements of those elements are to be returned. > > Aren't these 2 distinct functions that should better be represented by 2 > > separate expressions? > An XPATH expression always identifies a nodeset (in XML speak) and the > examples I showed are AFAIK valid XPATH expressions. You can match > against element names, element contents and attribute contents with the > restricted subset I have proposed. Full XPATH allows you to do much more > fancy selection of nodesets. But at the end, it all boils down to > selecting nodeset when using XPATH, so I fail to understand your > concern. Just a guess, but perhaps the idea is to do this the same way xs:keyref and xs:unique work in XML schema, that is, there's both an xs:selector and an xs:field XPath. I've never found the field/selector split to be particularly useful myself, but YMMV. Ned -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 07:12:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09001 for ; Wed, 9 Jun 2004 07:12:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY0o2-000ASJ-OB for netconf-data@psg.com; Wed, 09 Jun 2004 10:59:42 +0000 Received: from [212.201.44.27] (helo=merkur.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY0o1-000ARx-1U for netconf@ops.ietf.org; Wed, 09 Jun 2004 10:59:41 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by merkur.iu-bremen.de (Postfix) with ESMTP id 480C99F293; Wed, 9 Jun 2004 12:59:40 +0200 (CEST) Received: from merkur.iu-bremen.de ([212.201.44.27]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 26996-02; Wed, 9 Jun 2004 12:59:39 +0200 (CEST) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.64]) by merkur.iu-bremen.de (Postfix) with ESMTP id 41F259F4CC; Wed, 9 Jun 2004 12:59:34 +0200 (CEST) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id CAB0C87BD; Wed, 9 Jun 2004 12:54:00 +0200 (CEST) Date: Wed, 9 Jun 2004 12:54:00 +0200 From: Juergen Schoenwaelder To: Frank Strau? Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040609105400.GB2735@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strau? , netconf@ops.ietf.org References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Jun 08, 2004 at 12:36:23PM +0200, Frank Strau? wrote: > > > > //interface[type="ethernet"][connector="present"] > > This kind of operation first builds the set of all s which is > then limited to those with type="ethernet" and this subset is then limited > to those with connector="present". This means a sequence of predicates is > not commutative, in contrast to the logical AND operator. An example where > this would be signifcant is this: > //interface[type="ethernet"][position()=last()] would address the last > ethernet interface, while > //interface[position()=last()][type="ethernet"] would address the last > interface, if it is an ethernet interface, otherwise an empty node set. > > Xpath predicates (the parts in brackets) may contain boolean operators > ("expr1 and expr2","expr1 or expr2", "not(expr)"). True in general. However, the proposed required minimal subset does not include things like last() or position() - only simple comparisons of element/attribute values (no other operators). Do you think the fact that sequences of predicates are not commutative is still important in this special restricted case? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 07:52:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10348 for ; Wed, 9 Jun 2004 07:52:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY1VQ-000J12-OP for netconf-data@psg.com; Wed, 09 Jun 2004 11:44:32 +0000 Received: from [134.169.34.18] (helo=agitator.ibr.cs.tu-bs.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY1VP-000J0P-9C for netconf@ops.ietf.org; Wed, 09 Jun 2004 11:44:31 +0000 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i59BiUKI021036 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 9 Jun 2004 13:44:30 +0200 Date: Wed, 09 Jun 2004 13:44:30 +0200 From: =?ISO-8859-1?Q?Frank_Strau=DF?= To: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> In-Reply-To: <20040609105400.GB2735@iu-bremen.de> References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> <20040609105400.GB2735@iu-bremen.de> X-Mailer: Mulberry/3.1.4 (Linux/x86) X-PGP-Key: 1024D/3B8A33AA 2000-08-03 Frank Strauss X-PGP-Fingerprint: F6CD 195C F141 4CF8 72AD 0CB0 CD24 F033 3B8A 33AA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IBRFilter-SpamReport: -0.908 () BAYES_10 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On Tue, Jun 08, 2004 at 12:36:23PM +0200, Frank Strau? wrote: > >> > >> > //interface[type="ethernet"][connector="present"] >> >> This kind of operation first builds the set of all s which is >> then limited to those with type="ethernet" and this subset is then limited >> to those with connector="present". This means a sequence of predicates is >> not commutative, in contrast to the logical AND operator. An example where >> this would be signifcant is this: >> //interface[type="ethernet"][position()=last()] would address the last >> ethernet interface, while >> //interface[position()=last()][type="ethernet"] would address the last >> interface, if it is an ethernet interface, otherwise an empty node set. >> >> Xpath predicates (the parts in brackets) may contain boolean operators >> ("expr1 and expr2","expr1 or expr2", "not(expr)"). > > True in general. > > However, the proposed required minimal subset does not include things > like last() or position() - only simple comparisons of element/attribute > values (no other operators). Do you think the fact that sequences of > predicates are not commutative is still important in this special > restricted case? I'm sorry, I did not follow the discussion and reasoning on the proposed XPath subset. From the operator's point of view I would deeply regret if netconf would come up with such a derivation from the standard. It reminds me on a phrase from the (earlier) SMI specs: "...using an adapted subset..." which caused many misunderstandings in the past and made it impossible to use existing tool chains. I hope we have learned enough from those problems, especially since probably the most important advantage of XML based protocols is the ease of application and broad knowledge on its base specs. In general, a service might (be required to) supply *more* than a standard, and a client implementation might make use of less than the standard. But if a service is allowed to support *less* than the standard, it is simply not supporting that standard and causes trouble to client implementors. To (kind of) answer the question: In order to (a) make the expressions look more like what people who are familiar with XPath would expect, and to (b) support also an "or" operator (and a "not" operator), I would prefer the notation with the according operators over the sequence of predicates. If only an "and" operator would be required, I wouldn't care, since it would not be XPath, anyway. -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 11:58:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24112 for ; Wed, 9 Jun 2004 11:58:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY5Id-0009aN-Om for netconf-data@psg.com; Wed, 09 Jun 2004 15:47:35 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY5Ic-0009a8-Tt for netconf@ops.ietf.org; Wed, 09 Jun 2004 15:47:34 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2004 08:47:15 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i59FlWtV008132; Wed, 9 Jun 2004 08:47:32 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn2-213.cisco.com [10.21.112.213]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AVC38977; Wed, 9 Jun 2004 08:47:31 -0700 (PDT) Message-Id: <6.1.1.1.2.20040609074514.03840ed0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 09 Jun 2004 08:42:04 -0700 To: Frank =?iso-8859-1?Q?Strau=DF?= From: Andy Bierman Subject: Re: sub-tree filtering proposals Cc: netconf@ops.ietf.org In-Reply-To: <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> <20040609105400.GB2735@iu-bremen.de> <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 04:44 AM 6/9/2004, Frank Strau=DF wrote: >Juergen Schoenwaelder wrote: > >> On Tue, Jun 08, 2004 at 12:36:23PM +0200, Frank Strau? wrote: >>=20 >>> >=20 >>> > //interface[type=3D"ethernet"][connector=3D"present"] >>>=20 >>> This kind of operation first builds the set of all s which is >>> then limited to those with type=3D"ethernet" and this subset is then= limited >>> to those with connector=3D"present". This means a sequence of predicates= is >>> not commutative, in contrast to the logical AND operator. An example= where >>> this would be signifcant is this: >>> //interface[type=3D"ethernet"][position()=3Dlast()] would address the= last >>> ethernet interface, while >>> //interface[position()=3Dlast()][type=3D"ethernet"] would address the= last >>> interface, if it is an ethernet interface, otherwise an empty node set. >>>=20 >>> Xpath predicates (the parts in brackets) may contain boolean operators >>> ("expr1 and expr2","expr1 or expr2", "not(expr)"). >>=20 >> True in general.=20 >>=20 >> However, the proposed required minimal subset does not include things=20 >> like last() or position() - only simple comparisons of element/attribute >> values (no other operators). Do you think the fact that sequences of=20 >> predicates are not commutative is still important in this special=20 >> restricted case? > >I'm sorry, I did not follow the discussion and reasoning on the proposed= XPath >subset. From the operator's point of view I would deeply regret if netconf >would come up with such a derivation from the standard. It reminds me on a >phrase from the (earlier) SMI specs: "...using an adapted subset..." which >caused many misunderstandings in the past and made it impossible to use >existing tool chains. I hope we have learned enough from those problems, >especially since probably the most important advantage of XML based= protocols >is the ease of application and broad knowledge on its base specs. Juergen is not proposing an adapted subset. It is a pure subset. The main argument for Xpath subset here is that it will be easier to adapt existing tools than to build new ones from scratch. Eventually, more platforms will be able to support full Xpath, so the minimum subset may become a non-factor over time.=20 Clearly, every NETCONF developer would need to know about the Xpath subset. Limiting usage to the NETCONF subset is not an issue=20 for developers generating Xpath expressions themselves or writing them manually. If an NMS developer (using an application to generate Xpath expressions) limits the selection criteria to the subset that NETCONF supports, then what is the likelihood that the application will generate expressions outside the subset? Obviously, an application that supports full Xpath will be capable of offering more sophisticated selection features than NETCONF supports. In theory, if the developer avoids those features, the application should inter-operate with the NETCONF agent. In practice, it's not going to be this simple. >In general, a service might (be required to) supply *more* than a standard,= and >a client implementation might make use of less than the standard. But if a >service is allowed to support *less* than the standard, it is simply not >supporting that standard and causes trouble to client implementors. > >To (kind of) answer the question: In order to (a) make the expressions look >more like what people who are familiar with XPath would expect, and to (b) >support also an "or" operator (and a "not" operator), I would prefer the >notation with the according operators over the sequence of predicates. If= only >an "and" operator would be required, I wouldn't care, since it would not be >XPath, anyway. We do not have WG consensus that all devices can support, and all applications need, full Xpath. I think we have consensus for a limited set of features: - select all nodes matching specified attribute or simple content values - select a specific instance of an object, in a manner independent of any instance naming scheme - select specific nodes by name - select by any combination of the above This is the feature set we have been assuming via the subtree filtering examples all along. If some people think we need more powerful selection criteria as the minimum feature set, then speak up. Juergen's Xpath subset seems to be enough to support this feature set. I think the subtree filtering supports it as well. My biggest concern is that we forget that the target platforms for NETCONF agent are embedded operating systems within network=20 devices, and small devices don't need the same complex features=20 that large devices may need. IMO, we should do the following (yet another proposal :-) - mandatory-to-implement subtree node selection - optional-to-implement "full Xpath 1.0" node selection - #xpath capability set if this is supported The XML Directorate consensus seems to be leaning to partial Xpath, but there are strong concerns that an Xpath subset will be=20 incompatible with standard tools, and therefore pointless. The advantages of the proposal above are: - subtree filtering is easy to implement on agents; only XML parser needed, not XML and Xpath parsers - subtree expressions are valid XML which look identical to the data models (XML content) that operators will need to know anyways. Xpath should not be mandatory-to-know in order to use NETCONF. - Vendors are encouraged to also support full Xpath 1.0, if it is appropriate for the platform and data model size - We avoid definition and deployment of a NETCONF-only Xpath subset 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: From owner-netconf@ops.ietf.org Wed Jun 9 12:33:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26726 for ; Wed, 9 Jun 2004 12:33:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY5u1-000GuM-No for netconf-data@psg.com; Wed, 09 Jun 2004 16:26:13 +0000 Received: from [207.217.120.74] (helo=falcon.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY5ty-000Gu3-Kt for netconf@ops.ietf.org; Wed, 09 Jun 2004 16:26:10 +0000 Received: from h-68-164-76-103.snvacaid.dynamic.covad.net ([68.164.76.103] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BY5tx-0002UN-00 for netconf@ops.ietf.org; Wed, 09 Jun 2004 09:26:10 -0700 Message-ID: <004901c44d75$6849dcc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> <20040609105400.GB2735@iu-bremen.de> <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> <6.1.1.1.2.20040609074514.03840ed0@fedex.cisco.com> Subject: Re: sub-tree filtering proposals Date: Tue, 8 Jun 2004 09:26:51 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Andy Bierman" > To: "Frank Strauß" > Cc: > Sent: Wednesday, June 09, 2004 8:42 AM > Subject: Re: sub-tree filtering proposals ... > - Vendors are encouraged to also support full Xpath 1.0, if it > is appropriate for the platform and data model size ... I think this helps a lot, since it permits agent developers to use off-the-shelf code with little or no modification. The downside is that management applications would probably be written to work with the minimum subset, and not take advantage of the additional features. Would it make sense for there to be a capability that indicates whether the filter support is the basic subset or full Xpath? (If absent, the assumption would be "basic subset.") Randy -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 12:38:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26924 for ; Wed, 9 Jun 2004 12:38:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY60G-000I6i-Kk for netconf-data@psg.com; Wed, 09 Jun 2004 16:32:40 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY60D-000I5n-9a for netconf@ops.ietf.org; Wed, 09 Jun 2004 16:32:37 +0000 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i59GVCR13658; Wed, 9 Jun 2004 12:31:12 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jun 2004 12:31:13 -0400 Message-ID: From: "Glenn Waters" To: Andy Bierman , =?iso-8859-1?Q?Frank_Strau=DF?= Cc: netconf@ops.ietf.org Subject: RE: sub-tree filtering proposals Date: Wed, 9 Jun 2004 12:31:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44E3F.2CE67164" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44E3F.2CE67164 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: Andy Bierman [mailto:abierman@cisco.com] > Sent: Wednesday, June 09, 2004 11:42 > To: Frank Strau=DF > Cc: netconf@ops.ietf.org > Subject: Re: sub-tree filtering proposals =20 > IMO, we should do the following (yet another proposal :-) >=20 > - mandatory-to-implement subtree node selection Is the mandatory to implement based on what Jeurgen proposed? > - optional-to-implement "full Xpath 1.0" node selection > - #xpath capability set if this is supported >=20 > The XML Directorate consensus seems to be leaning to partial > Xpath, but there are strong concerns that an Xpath subset will be > incompatible with standard tools, and therefore pointless. It's not pointless. Some reasons that an XPath subset is useful are: - compatability with full XPath which allows developers to learn one = set of filtering=20 - code reuse between subset and full implementation - training will be easier -- can leverage existing training for the = bits we support - a clean migration path from "XPath-lite" to "XPath-full" >=20 > The advantages of the proposal above are: > - subtree filtering is easy to implement on agents; > only XML parser needed, not XML and Xpath parsers > - subtree expressions are valid XML which look identical > to the data models (XML content) that operators will > need to know anyways. Xpath should not be mandatory-to-know > in order to use NETCONF. > - Vendors are encouraged to also support full Xpath 1.0, if it > is appropriate for the platform and data model size > - We avoid definition and deployment of a NETCONF-only Xpath subset >=20 > Andy Regards, /gww=20 ------_=_NextPart_001_01C44E3F.2CE67164 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: sub-tree filtering proposals

> From: Andy Bierman [mailto:abierman@cisco.com]=
> Sent: Wednesday, June 09, 2004 11:42
> To: Frank Strau=DF
> Cc: netconf@ops.ietf.org
> Subject: Re: sub-tree filtering = proposals
 
> IMO, we should do the following (yet another = proposal :-)
>
>   - mandatory-to-implement subtree = node selection

Is the mandatory to implement based on what Jeurgen = proposed?

>   - optional-to-implement "full = Xpath 1.0" node selection
>     - #xpath capability set = if this is supported
>
> The XML Directorate consensus seems to be = leaning to partial
> Xpath, but there are strong concerns that an = Xpath subset will be
> incompatible with standard tools, and therefore = pointless.

It's not pointless. Some reasons that an XPath subset = is useful are:
- compatability with full XPath which allows = developers to learn one set of filtering
- code reuse between subset and full = implementation
- training will be easier -- can leverage existing = training for the bits we support
- a clean migration path from "XPath-lite" = to "XPath-full"

>
> The advantages of the proposal above = are:
>   - subtree filtering is easy to = implement on agents;
>     only XML parser needed, = not XML and Xpath parsers
>   - subtree expressions are valid XML = which look identical
>     to the data models (XML = content) that operators will
>     need to know = anyways.  Xpath should not be mandatory-to-know
>     in order to use = NETCONF.
>   - Vendors are encouraged to also = support full Xpath 1.0, if it
>     is appropriate for the = platform and data model size
>   - We avoid definition and = deployment of a NETCONF-only Xpath subset
>
> Andy

Regards, /gww

------_=_NextPart_001_01C44E3F.2CE67164-- -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 12:51:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27989 for ; Wed, 9 Jun 2004 12:51:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY6DU-000KyZ-RI for netconf-data@psg.com; Wed, 09 Jun 2004 16:46:20 +0000 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY6DT-000Ky9-Vi for netconf@ops.ietf.org; Wed, 09 Jun 2004 16:46:20 +0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i59Gk063014339; Wed, 9 Jun 2004 09:46:00 -0700 (MST) Received: from motorola.com ([173.23.235.140]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i59GiEvq021609; Wed, 9 Jun 2004 11:44:14 -0500 Message-ID: <40C73EA4.EF6A41FE@motorola.com> Date: Wed, 09 Jun 2004 11:45:25 -0500 From: Sandeep Adwankar Organization: Motorola Labs X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andy Bierman CC: Frank =?iso-8859-1?Q?Strau=DF?= , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> <20040609105400.GB2735@iu-bremen.de> <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> <6.1.1.1.2.20040609074514.03840ed0@fedex.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy Bierman wrote: > > Juergen is not proposing an adapted subset. It is a pure subset. > The main argument for Xpath subset here is that it will be easier > to adapt existing tools than to build new ones from scratch. The argument to adapt existing tools is weak. It means that I need to rebuild xerces parser to support this subset while still struggling to keep it within the device memory limits. I rather prefer using xerces as it is or not to use it at all. > > We do not have WG consensus that all devices can support, > and all applications need, full Xpath. I think we have > consensus for a limited set of features: > - select all nodes matching specified attribute or simple content values > - select a specific instance of an object, in a manner independent > of any instance naming scheme > - select specific nodes by name > - select by any combination of the above > I wonder if (future) NetConf Data model will support all these features, or should it be part of the protocol specification. Won't these be requirements for NetConf data model? > > IMO, we should do the following (yet another proposal :-) > > - mandatory-to-implement subtree node selection > - optional-to-implement "full Xpath 1.0" node selection > - #xpath capability set if this is supported I like second part: #xpath capability set that supports full XPath for devices that can house it. Thanks Sandeep -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 12:58:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28693 for ; Wed, 9 Jun 2004 12:58:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY6JQ-000MMq-1d for netconf-data@psg.com; Wed, 09 Jun 2004 16:52:28 +0000 Received: from [207.217.120.50] (helo=avocet.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY6JO-000MMC-KF for netconf@ops.ietf.org; Wed, 09 Jun 2004 16:52:26 +0000 Received: from h-68-164-76-103.snvacaid.dynamic.covad.net ([68.164.76.103] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BY6JN-0004Ni-00 for netconf@ops.ietf.org; Wed, 09 Jun 2004 09:52:26 -0700 Message-ID: <001201c44d79$13b495c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> <20040609105400.GB2735@iu-bremen.de> <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> <6.1.1.1.2.20040609074514.03840ed0@fedex.cisco.com> <004901c44d75$6849dcc0$7f1afea9@oemcomputer> Subject: Re: sub-tree filtering proposals Date: Tue, 8 Jun 2004 09:53:08 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Randy Presuhn" > To: > Sent: Tuesday, June 08, 2004 9:26 AM > Subject: Re: sub-tree filtering proposals ... > Would it make sense for there to be a capability that indicates > whether the filter support is the basic subset or full Xpath? > (If absent, the assumption would be "basic subset.") ... Doh. That's what Andy proposed a couple of lines earlier. They say short-term memory is the first to go. :-) Randy -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 13:06:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29057 for ; Wed, 9 Jun 2004 13:06:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY6Qv-000O9B-3l for netconf-data@psg.com; Wed, 09 Jun 2004 17:00:13 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY6Qu-000O8u-9Y for netconf@ops.ietf.org; Wed, 09 Jun 2004 17:00:12 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i59GxC917162; Wed, 9 Jun 2004 09:59:12 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i59Gx6J07584; Wed, 9 Jun 2004 09:59:06 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id i59Gx6BE094299; Wed, 9 Jun 2004 12:59:06 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200406091659.i59Gx6BE094299@idle.juniper.net> To: "Glenn Waters" cc: Andy Bierman , =?iso-8859-1?Q?Frank_Strau=DF?= , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals In-Reply-To: Your message of "Wed, 09 Jun 2004 12:31:11 EDT." Date: Wed, 09 Jun 2004 12:59:06 -0400 From: Phil Shafer X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk "Glenn Waters" writes: >It's not pointless. Some reasons that an XPath subset is useful are: >- compatability with full XPath which allows developers to learn one >set of filtering ... and then be fustrated when the full xpath doesn't work.... >- a clean migration path from "XPath-lite" to "XPath-full" I don't see this happening. If you start with a subset and grow it over time, clients will never know what subset the device supports and will break on devices that don't match their requirements. Given that high-end devices are likely to just pick up a full implementation (libxml2), the subset will be broken day one. Even then, the ability of the device to implement arbitrary bits of XPath logic and expressions will be an immense and changing burden. Unless we're all switching over to XML databases on the device, the act of doing something like: following-sibling::security-associations[preceding-sibling::sa-tunnel-information[1]/sa-tunnel-index=$xpath-tunnel-number] won't be simple. Thanks, Phil -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 13:34:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01326 for ; Wed, 9 Jun 2004 13:34:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY6t5-0003aM-KH for netconf-data@psg.com; Wed, 09 Jun 2004 17:29:19 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY6t4-0003a8-TE for netconf@ops.ietf.org; Wed, 09 Jun 2004 17:29:18 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Jun 2004 10:29:00 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i59HTFIn013364; Wed, 9 Jun 2004 10:29:15 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn2-213.cisco.com [10.21.112.213]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AVC51784; Wed, 9 Jun 2004 10:29:12 -0700 (PDT) Message-Id: <6.1.1.1.2.20040609101718.03ad9648@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 09 Jun 2004 10:23:46 -0700 To: "Glenn Waters" From: Andy Bierman Subject: RE: sub-tree filtering proposals Cc: Frank =?iso-8859-1?Q?Strau=DF?= , netconf@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 09:31 AM 6/9/2004, Glenn Waters wrote: >> From: Andy Bierman [mailto:abierman@cisco.com]= =20 >> Sent: Wednesday, June 09, 2004 11:42=20 >> To: Frank Strau=DF=20 >> Cc: netconf@ops.ietf.org=20 >> Subject: Re: sub-tree filtering proposals=20 > =20 >> IMO, we should do the following (yet another proposal :-)=20 >>=20 >> - mandatory-to-implement subtree node selection=20 > >Is the mandatory to implement based on what Jeurgen proposed?=20 this is the subtree filtering already in the draft and documented in my original email on this thread. This is not partial Xpath >> - optional-to-implement "full Xpath 1.0" node selection=20 >> - #xpath capability set if this is supported=20 >>=20 >> The XML Directorate consensus seems to be leaning to partial=20 >> Xpath, but there are strong concerns that an Xpath subset will be=20 >> incompatible with standard tools, and therefore pointless.=20 > >It's not pointless. Some reasons that an XPath subset is useful are:=20 >- compatability with full XPath which allows developers to learn one set of= filtering=20 >- code reuse between subset and full implementation=20 >- training will be easier -- can leverage existing training for the bits we= support=20 >- a clean migration path from "XPath-lite" to "XPath-full"=20 I think the WG is still split on this point. I agree with Phil. We will have a lot of variance between minimal subset and full Xpath, and application writers will have difficulty managing this variance. If we had mandatory subtree plus optional full Xpath, there is less variance possible (just 2 choices: full=20 subtree, full Xpath). Or we could make both filtering mechanisms optional and let the market decide which ones are useful. =20 >>=20 >> The advantages of the proposal above are:=20 >> - subtree filtering is easy to implement on agents;=20 >> only XML parser needed, not XML and Xpath parsers=20 >> - subtree expressions are valid XML which look identical=20 >> to the data models (XML content) that operators will=20 >> need to know anyways. Xpath should not be mandatory-to-know=20 >> in order to use NETCONF.=20 >> - Vendors are encouraged to also support full Xpath 1.0, if it=20 >> is appropriate for the platform and data model size=20 >> - We avoid definition and deployment of a NETCONF-only Xpath subset=20 >>=20 >> Andy=20 > >Regards, /gww=20 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: From owner-netconf@ops.ietf.org Wed Jun 9 13:55:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04132 for ; Wed, 9 Jun 2004 13:55:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY7DO-0007gE-SS for netconf-data@psg.com; Wed, 09 Jun 2004 17:50:18 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY7DN-0007fm-V1 for netconf@ops.ietf.org; Wed, 09 Jun 2004 17:50:18 +0000 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i59HmFR25132; Wed, 9 Jun 2004 13:48:15 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jun 2004 13:48:16 -0400 Message-ID: From: "Glenn Waters" To: Phil Shafer Cc: Andy Bierman , =?iso-8859-1?Q?Frank_Strau=DF?= , netconf@ops.ietf.org Subject: RE: sub-tree filtering proposals Date: Wed, 9 Jun 2004 13:48:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44E49.F01FF7A4" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44E49.F01FF7A4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Wednesday, June 09, 2004 12:59 > To: Waters, Glenn [CAR:IO47:EXCH] > Cc: Andy Bierman; Frank Strau=DF; netconf@ops.ietf.org > Subject: Re: sub-tree filtering proposals >=20 > "Glenn Waters" writes: > >It's not pointless. Some reasons that an XPath subset is useful are: > >- compatability with full XPath which allows developers to learn one > >set of filtering >=20 > ... and then be fustrated when the full xpath doesn't work.... I agree that they will be frustrated when the full XPath doesn't work. = BUT, will they be any less frustrated using a solution that we invent and = that has far fewer tools available? Let's not call it XPath-lite then. Let's call it subtree filtering and = it will be an exact subset of the XPath spec that the NetConf group thinks = is useful. And, when we want to improve the subtree filtering in NetConf = we go back to the XPath spec and pick a few more interesting features to add = to the NetConf spec. > >- a clean migration path from "XPath-lite" to "XPath-full" >=20 > I don't see this happening. If you start with a subset and > grow it over time, clients will never know what subset the > device supports and will break on devices that don't match > their requirements. Given that high-end devices are likely > to just pick up a full implementation (libxml2), the subset > will be broken day one. Even then, the ability of the > device to implement arbitrary bits of XPath logic and > expressions will be an immense and changing burden. Unless > we're all switching over to XML databases on the device, > the act of doing something like: >=20 > = following-sibling::security-associations[preceding-sibling::sa-tunnel- > information[1]/sa-tunnel-index=3D$xpath-tunnel-number] >=20 > won't be simple. I don't believe that growing this over time is any more an issue than = when we make other protocol changes. We have rule and guidelines that we = follow when we change protocols (look at SNMP v1/2/3 for example). When we = improve the subtree filtering in a new revision of the protocol the protocol = spec will define exactly what you can do and will define how to = differentiate versions of the protocol. Oh yeah, the new subtree filtering will just happen to look like a subset of XPath -- but we don't need to tell = anyone that. >=20 > Thanks, > Phil Regards, /gww=20 ------_=_NextPart_001_01C44E49.F01FF7A4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: sub-tree filtering proposals

> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]
> Sent: Wednesday, June 09, 2004 12:59
> To: Waters, Glenn [CAR:IO47:EXCH]
> Cc: Andy Bierman; Frank Strau=DF; = netconf@ops.ietf.org
> Subject: Re: sub-tree filtering = proposals
>
> "Glenn Waters" writes:
> >It's not pointless. Some reasons that an = XPath subset is useful are:
> >- compatability with full XPath which = allows developers to learn one
> >set of filtering
>
> ... and then be fustrated when the full xpath = doesn't work....

I agree that they will be frustrated when the full = XPath doesn't work. BUT, will they be any less frustrated using a = solution that we invent and that has far fewer tools = available?

Let's not call it XPath-lite then. Let's call it = subtree filtering and it will be an exact subset of the XPath spec that = the NetConf group thinks is useful. And, when we want to improve the = subtree filtering in NetConf we go back to the XPath spec and pick a = few more interesting features to add to the NetConf spec.

> >- a clean migration path from = "XPath-lite" to "XPath-full"
>
> I don't see this happening.  If you start = with a subset and
> grow it over time, clients will never know what = subset the
> device supports and will break on devices that = don't match
> their requirements.  Given that high-end = devices are likely
> to just pick up a full implementation = (libxml2), the subset
> will be broken day one.  Even then, the = ability of the
> device to implement arbitrary bits of XPath = logic and
> expressions will be an immense and changing = burden.  Unless
> we're all switching over to XML databases on = the device,
> the act of doing something like:
>
>    = following-sibling::security-associations[preceding-sibling::sa-tunnel-
> = information[1]/sa-tunnel-index=3D$xpath-tunnel-number]
>
> won't be simple.

I don't believe that growing this over time is any = more an issue than when we make other protocol changes. We have rule = and guidelines that we follow when we change protocols (look at SNMP = v1/2/3 for example). When we improve the subtree filtering in a new = revision of the protocol the protocol spec will define exactly what you = can do and will define how to differentiate versions of the protocol. = Oh yeah, the new subtree filtering will just happen to look like a = subset of XPath -- but we don't need to tell anyone that.

>
> Thanks,
>  Phil

Regards, /gww

------_=_NextPart_001_01C44E49.F01FF7A4-- -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 13:55:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04172 for ; Wed, 9 Jun 2004 13:55:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY7Bg-0007D7-TE for netconf-data@psg.com; Wed, 09 Jun 2004 17:48:32 +0000 Received: from [80.185.75.40] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY7Bf-0007CC-BN for netconf@ops.ietf.org; Wed, 09 Jun 2004 17:48:31 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 1E17787C3; Wed, 9 Jun 2004 19:48:30 +0200 (CEST) Date: Wed, 9 Jun 2004 19:48:30 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Glenn Waters , Frank Strau? , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040609174830.GA4378@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Glenn Waters , Frank Strau? , netconf@ops.ietf.org References: <6.1.1.1.2.20040609101718.03ad9648@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040609101718.03ad9648@fedex.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Jun 09, 2004 at 10:23:46AM -0700, Andy Bierman wrote: > I think the WG is still split on this point. > I agree with Phil. We will have a lot of variance > between minimal subset and full Xpath, and application > writers will have difficulty managing this variance. > If we had mandatory subtree plus optional full Xpath, > there is less variance possible (just 2 choices: full > subtree, full Xpath). subtree filter + full XPATH = 2 XPATH subset + full XPATH = 2 > Or we could make both filtering mechanisms optional and > let the market decide which ones are useful. The market will decide anyway. But making both filtering schemes optional just means the mandatory is no filtering (kind of introducing a third option and I bet this is what applications end up doing - sucking the whole thing and running xslt (which uses xpath) locally. I tend to agree with Phil that agreeing on a single approach would indeed by the best approach. I probably differ with him (not sure though) that XPATH is the right way to go. Probably the solution is indeed XPATH or no filtering at all. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 13:59:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04721 for ; Wed, 9 Jun 2004 13:59:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY7G8-0008Qq-7A for netconf-data@psg.com; Wed, 09 Jun 2004 17:53:08 +0000 Received: from [207.217.120.12] (helo=harrier.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY7G7-0008QX-Bm for netconf@ops.ietf.org; Wed, 09 Jun 2004 17:53:07 +0000 Received: from h-68-164-76-103.snvacaid.dynamic.covad.net ([68.164.76.103] helo=oemcomputer) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BY7G6-0006f7-00 for netconf@ops.ietf.org; Wed, 09 Jun 2004 10:53:06 -0700 Message-ID: <000b01c44d81$8dea9ee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.1.1.1.2.20040609101718.03ad9648@fedex.cisco.com> Subject: Re: sub-tree filtering proposals Date: Tue, 8 Jun 2004 10:53:49 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Andy Bierman" > To: "Glenn Waters" > Cc: "Frank Strauß" ; > Sent: Wednesday, June 09, 2004 10:23 AM > Subject: RE: sub-tree filtering proposals ... > >Is the mandatory to implement based on what Jeurgen proposed? > > this is the subtree filtering already in the draft and > documented in my original email on this thread. This > is not partial Xpath I'm sorry to hear this. Implementation and validation would be easier if the mandatory-to-implement subtree filtering were a strict subset of Xpath. Implementations with full Xpath support wouldn't need to do anything special. ... > I agree with Phil. We will have a lot of variance > between minimal subset and full Xpath, and application > writers will have difficulty managing this variance. > If we had mandatory subtree plus optional full Xpath, > there is less variance possible (just 2 choices: full > subtree, full Xpath). ... The variance is a problem only if we permit it to happen. Even having two choices is not good, but if those happen to be a well-specified strict subset and the whole enchilada, I think it would be manageable. Allowing various shades of grey would not be. Randy -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 13:59:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04791 for ; Wed, 9 Jun 2004 13:59:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY7GH-0008Sk-Nz for netconf-data@psg.com; Wed, 09 Jun 2004 17:53:17 +0000 Received: from [80.185.75.40] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY7GG-0008Ru-MH for netconf@ops.ietf.org; Wed, 09 Jun 2004 17:53:17 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 1552987C1; Wed, 9 Jun 2004 18:40:53 +0200 (CEST) Date: Wed, 9 Jun 2004 18:40:53 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040609164053.GF3566@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Randy Presuhn , netconf@ops.ietf.org References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> <20040609105400.GB2735@iu-bremen.de> <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> <6.1.1.1.2.20040609074514.03840ed0@fedex.cisco.com> <004901c44d75$6849dcc0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004901c44d75$6849dcc0$7f1afea9@oemcomputer> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Tue, Jun 08, 2004 at 09:26:51AM -0700, Randy Presuhn wrote: > Would it make sense for there to be a capability that indicates > whether the filter support is the basic subset or full Xpath? > (If absent, the assumption would be "basic subset.") This is what was under discussion as far as I remember. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 14:15:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06198 for ; Wed, 9 Jun 2004 14:15:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY7WO-000C6K-14 for netconf-data@psg.com; Wed, 09 Jun 2004 18:09:56 +0000 Received: from [80.185.75.40] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY7WN-000C65-2J for netconf@ops.ietf.org; Wed, 09 Jun 2004 18:09:55 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 2190B87C2; Wed, 9 Jun 2004 19:12:55 +0200 (CEST) Date: Wed, 9 Jun 2004 19:12:55 +0200 From: Juergen Schoenwaelder To: Phil Shafer Cc: Glenn Waters , Andy Bierman , Frank Strau? , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040609171255.GB3999@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Phil Shafer , Glenn Waters , Andy Bierman , Frank Strau? , netconf@ops.ietf.org References: <200406091659.i59Gx6BE094299@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406091659.i59Gx6BE094299@idle.juniper.net> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Jun 09, 2004 at 12:59:06PM -0400, Phil Shafer wrote: > [...] Given that high-end devices are likely > to just pick up a full implementation (libxml2), the subset > will be broken day one. Even then, the ability of the > device to implement arbitrary bits of XPath logic and > expressions will be an immense and changing burden. Please elaborate. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 14:41:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07875 for ; Wed, 9 Jun 2004 14:41:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY7tU-000HEM-AU for netconf-data@psg.com; Wed, 09 Jun 2004 18:33:48 +0000 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY7tT-000HDr-DX for netconf@ops.ietf.org; Wed, 09 Jun 2004 18:33:47 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i59IWLBm052957; Wed, 9 Jun 2004 11:32:21 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i59IWKJ25021; Wed, 9 Jun 2004 11:32:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.12.6/8.11.3) with ESMTP id i59IWJBE095188; Wed, 9 Jun 2004 14:32:19 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200406091832.i59IWJBE095188@idle.juniper.net> To: j.schoenwaelder@iu-bremen.de cc: Glenn Waters , Andy Bierman , Frank Strau? , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals In-Reply-To: Your message of "Wed, 09 Jun 2004 19:12:55 +0200." <20040609171255.GB3999@iu-bremen.de> Date: Wed, 09 Jun 2004 14:32:19 -0400 From: Phil Shafer X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Juergen Schoenwaelder writes: >> [...] Given that high-end devices are likely >> to just pick up a full implementation (libxml2), the subset >> will be broken day one. Even then, the ability of the >> device to implement arbitrary bits of XPath logic and >> expressions will be an immense and changing burden. >Please elaborate. Here's a recent elaboration: >Message-Id: <200404082233.i38MX0BE011229@idle.juniper.net> >To: j.schoenwaelder@iu-bremen.de >cc: Andy Bierman , netconf@ops.ietf.org >Subject: Re: Proposal to do away with netconf attributes in data model payloads >In-Reply-To: Your message of "Thu, 08 Apr 2004 23:45:28 +0200." > <20040408214528.GA1702@iu-bremen.de> >Date: Thu, 08 Apr 2004 18:33:00 -0400 >From: Phil Shafer > >Juergen Schoenwaelder writes: >>> >I think all approaches require changes to retrieved data >>> >to compose a meaningful arguments. > >I think the only change required is to add the 'operation="replace"' >attribute to the top-level element of the configuration tree returned >from . > >>I do fail to understand why creating something new for all netconf >>boxes instead of subsetting XPATH only for small devices will at >>the end be a winning situation. > >Subsetting will lead to differing subsets. You won't know what you >can do until you know what implementation you're talking to. Unless >you believe users will restrain themselves and stay within the >defined subset. > >Your other mail asked about the cost of xpath and why it's easier to >parse elements than xpath expressions. I don't think there's much >difference between parsing the following: > > >(a) > set interfaces so-0/0/0 unit 0 family inet address 10.1.2.3/24 > >(b) > > > > so-0/0/0 > > 0 > > >
> 10.1.2.3/24 >
> > > > > > > >(c) > interfaces/interface[name='so-0/0/0']/unit[name='0']/family/inet/address[name='10.1.2.3/24'] > > >But there is an order of mangnitude difference in handling: > > interfaces/interface/unit/family/inet[starts-with(../../../name, 'so-') and string-length(../../name) = 1]/address[substring(name,3) != '/24' and (not(@inactive) or disable)] > >If I subset most of xpath out of netconf-xpath, why use it? Just >because slashes are more stylish that xml elements? If we're making >an xml api, it makes no sense to prefer strings to real xml. > >The element sub-tree is a good match between what the device can >do easily and what the app writer needs. > >Also worth noting that the use of xpath implies that the intermediate >nodes already exist, which isn't always the case. In JUNOS, we >effectively remove empty levels from the database when an empty >level would be meaningless, so a could remove levels that >were not it's target and a that is depending on the existence >of that level would fail. > >I'm looking to make an API that contains the abilities of the CLI >so that we can stamp out screen scraping, not to create new >technology that can be implemented six months after the MIB is >implemented (and twelve months after the feature ships). > >Thanks, > Phil -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 14:46:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08250 for ; Wed, 9 Jun 2004 14:46:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY81A-000IyK-6P for netconf-data@psg.com; Wed, 09 Jun 2004 18:41:44 +0000 Received: from [80.185.88.24] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY818-000Ixg-NE for netconf@ops.ietf.org; Wed, 09 Jun 2004 18:41:43 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 899F187BE; Wed, 9 Jun 2004 15:42:22 +0200 (CEST) Date: Wed, 9 Jun 2004 15:42:22 +0200 From: Juergen Schoenwaelder To: Frank Strau? Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040609134222.GA3566@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strau? , netconf@ops.ietf.org References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> <20040609105400.GB2735@iu-bremen.de> <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Jun 09, 2004 at 01:44:30PM +0200, Frank Strau? wrote: > I'm sorry, I did not follow the discussion and reasoning on the proposed XPath > subset. From the operator's point of view I would deeply regret if netconf > would come up with such a derivation from the standard. It reminds me on a > phrase from the (earlier) SMI specs: "...using an adapted subset..." which > caused many misunderstandings in the past and made it impossible to use > existing tool chains. I hope we have learned enough from those problems, > especially since probably the most important advantage of XML based protocols > is the ease of application and broad knowledge on its base specs. First, I believe a subset of XPATH (not an adapted subset) is still better than something homegrown. (The most vocal members of the WG do not seem to buy full XPATH as a requirement.) Personally, I believe that the operators using netconf will ask for full XPATH anyway, so the subset requirement will likely not be a real issue in practice. > In general, a service might (be required to) supply *more* than a standard, > and a client implementation might make use of less than the standard. But > if a service is allowed to support *less* than the standard, it is simply > not supporting that standard and causes trouble to client implementors. I think the general idea is that boxes announce whether they do support full XPATH or just a reduced subset. I do not see that there is anything wrong with this. The alternative, a home grow filter format which implementations are required to support, seems worse to me. Bottom line is that either (a) the netconf WG makes a decision to require XPATH full stop, or (b) the WG makes a decision to support XPATH and require a subset of it, or (c) the WG makes a decision to support XPATH and to require another home-grown filter format. Since (a) does not seem to be getting WG concensus, I believe (b) is the best we can do. > To (kind of) answer the question: In order to (a) make the expressions look > more like what people who are familiar with XPath would expect, and to (b) > support also an "or" operator (and a "not" operator), I would prefer the > notation with the according operators over the sequence of predicates. If > only an "and" operator would be required, I wouldn't care, since it would > not be XPath, anyway. Point taken. I can live either way. I just do not want to see (c) happen. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 15:05:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10349 for ; Wed, 9 Jun 2004 15:05:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY8H6-000N7s-3w for netconf-data@psg.com; Wed, 09 Jun 2004 18:58:12 +0000 Received: from [80.185.88.24] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY8H4-000N6e-4R for netconf@ops.ietf.org; Wed, 09 Jun 2004 18:58:10 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 464A987C0; Wed, 9 Jun 2004 18:22:47 +0200 (CEST) Date: Wed, 9 Jun 2004 18:22:47 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Frank Strau? , netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040609162247.GC3566@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , Frank Strau? , netconf@ops.ietf.org References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> <20040609105400.GB2735@iu-bremen.de> <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> <6.1.1.1.2.20040609074514.03840ed0@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040609074514.03840ed0@fedex.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Jun 09, 2004 at 08:42:04AM -0700, Andy Bierman wrote: > We do not have WG consensus that all devices can support, > and all applications need, full Xpath. I think we have > consensus for a limited set of features: > - select all nodes matching specified attribute or simple content values > - select a specific instance of an object, in a manner independent > of any instance naming scheme > - select specific nodes by name > - select by any combination of the above > > This is the feature set we have been assuming via the subtree filtering > examples all along. If some people think we need more powerful > selection criteria as the minimum feature set, then speak up. > Juergen's Xpath subset seems to be enough to support this feature set. > I think the subtree filtering supports it as well. > > My biggest concern is that we forget that the target platforms > for NETCONF agent are embedded operating systems within network > devices, and small devices don't need the same complex features > that large devices may need. > > IMO, we should do the following (yet another proposal :-) > > - mandatory-to-implement subtree node selection > - optional-to-implement "full Xpath 1.0" node selection > - #xpath capability set if this is supported So what is "subtree node selection" compared to "subtree filtering"? I am confused now. Do you refer to your original selection proposal now? > The XML Directorate consensus seems to be leaning to partial > Xpath, but there are strong concerns that an Xpath subset will be > incompatible with standard tools, and therefore pointless. > The advantages of the proposal above are: > - subtree filtering is easy to implement on agents; > only XML parser needed, not XML and Xpath parsers Come on, parsing Xpath expression is really not that complicated. I am really wondering on which basis you calculate how much you save on embedded boxes... > - subtree expressions are valid XML which look identical > to the data models (XML content) that operators will > need to know anyways. Xpath should not be mandatory-to-know > in order to use NETCONF. In case "subtree expressions" means just expressions of the form "/foo/bar", then we are back in SNMP stone age where everything you want to select on has to be part of the name (OID). > - Vendors are encouraged to also support full Xpath 1.0, if it > is appropriate for the platform and data model size > - We avoid definition and deployment of a NETCONF-only Xpath subset At the price of creating another totally incompatible beast. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 15:27:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12589 for ; Wed, 9 Jun 2004 15:27:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY8ba-0001mt-Dv for netconf-data@psg.com; Wed, 09 Jun 2004 19:19:22 +0000 Received: from [80.185.88.24] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY8bZ-0001m3-AR for netconf@ops.ietf.org; Wed, 09 Jun 2004 19:19:21 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 2058087BB; Wed, 9 Jun 2004 21:19:20 +0200 (CEST) Date: Wed, 9 Jun 2004 21:19:20 +0200 From: Juergen Schoenwaelder To: Phil Shafer Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals Message-ID: <20040609191920.GB1792@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Phil Shafer , netconf@ops.ietf.org References: <20040609171255.GB3999@iu-bremen.de> <200406091832.i59IWJBE095188@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406091832.i59IWJBE095188@idle.juniper.net> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Wed, Jun 09, 2004 at 02:32:19PM -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >> [...] Given that high-end devices are likely > >> to just pick up a full implementation (libxml2), the subset > >> will be broken day one. Even then, the ability of the > >> device to implement arbitrary bits of XPath logic and > >> expressions will be an immense and changing burden. > >Please elaborate. > > Here's a recent elaboration: > >Subsetting will lead to differing subsets. You won't know what you > >can do until you know what implementation you're talking to. Unless > >you believe users will restrain themselves and stay within the > >defined subset. Either the filter mechanism is standardized or not. I fail to see why an ad-hoc subtree filtering mechanism is any better or worse compared to an XPATH subset as long as it is well defined and standardized. [ The rest of the quoted email does not seem to give any additional insights why chosing a subset of xpath "will be an immense and changing burden". Sorry if I missed the important piece. ] /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 16:50:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19789 for ; Wed, 9 Jun 2004 16:50:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BY9mj-000HF3-Kp for netconf-data@psg.com; Wed, 09 Jun 2004 20:34:57 +0000 Received: from [134.169.34.18] (helo=agitator.ibr.cs.tu-bs.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BY9mi-000HEq-KI for netconf@ops.ietf.org; Wed, 09 Jun 2004 20:34:56 +0000 Received: from [10.0.1.2] (p508E609D.dip.t-dialin.net [80.142.96.157]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i59KYrKI007570 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 9 Jun 2004 22:34:54 +0200 In-Reply-To: <20040609134222.GA3566@iu-bremen.de> References: <6.1.1.1.2.20040604132619.0368b1f8@fedex.cisco.com> <20040605114611.GA1773@iu-bremen.de> <6.1.1.1.2.20040607101623.0371fcf0@fedex.cisco.com> <20040607210305.GA1781@iu-bremen.de> <317389791CADF77E74A16CD9@hansa.ibr.cs.tu-bs.de> <20040609105400.GB2735@iu-bremen.de> <6EDDF3C4B28EDF82C05DF83A@hansa.ibr.cs.tu-bs.de> <20040609134222.GA3566@iu-bremen.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <75F0AA52-BA54-11D8-91C0-000A95909448@ibr.cs.tu-bs.de> Content-Transfer-Encoding: 7bit Cc: netconf@ops.ietf.org From: =?ISO-8859-1?Q?Frank_Strau=DF?= Subject: Re: sub-tree filtering proposals Date: Wed, 9 Jun 2004 22:34:52 +0200 To: j.schoenwaelder@iu-bremen.de X-Mailer: Apple Mail (2.618) X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 09. Jun 2004, at 15:42, Juergen Schoenwaelder wrote: > [...] > First, I believe a subset of XPATH (not an adapted subset) is still > better > than something homegrown. I agree. > (The most vocal members of the WG do not seem > to buy full XPATH as a requirement.) Maybe the reason is, that there are still not many operators and developers of manager software raising their voice. (I'm just guessing.) > Personally, I believe that the > operators using netconf will ask for full XPATH anyway, so the subset > requirement will likely not be a real issue in practice. However, a netconf standard should have the purpose to come to a common sense on what agents support and what managers can rely on. If we have reasons to assume that operators and others will ask for full XPath (and I do think so, too) we should address this need *now* (and BTW not in a subsequent revision as long as we did not even find rough consensus for the initial revision). > I think the general idea is that boxes announce whether they do > support full > XPATH or just a reduced subset. I do not see that there is anything > wrong > with this. In general, I agree. > The alternative, a home grow filter format which implementations are > required to support, seems worse to me. Bottom line is that either > (a) the netconf WG makes a decision to require XPATH full stop, or > (b) the WG makes a decision to support XPATH and require a subset of > it, or > (c) the WG makes a decision to support XPATH and to require another > home-grown filter format. > > Since (a) does not seem to be getting WG consensus, I believe (b) is > the > best we can do. First to say, my preference would be (a). If there are reasons against (a) (I guess, I missed a discussion on this), I would also favor (b) over (c). On 09. Jun 2004, at 18:22, Juergen Schoenwaelder wrote: >> The advantages of the proposal above are: >> - subtree filtering is easy to implement on agents; >> only XML parser needed, not XML and Xpath parsers > > Come on, parsing Xpath expression is really not that complicated. I am > really wondering on which basis you calculate how much you save on > embedded boxes... I would also like to see a clear reasoning, not just on the pure code size. These aspects come to my mind: - We should take into account that many XPath implementations exist. My expectation would be that deriving a subset implementation would need some time (not much, but more that just picking an existing full implementation) just to shrink the code size for a small percentage. - An XPath subset would most probably *not* reduce CPU load compared to full XPath. - Building a new XPath (subset) implementation from scratch could be required by some vendors' policies. A full implementation would fit in the idea of reusability, while a netconf subset would be limited netconf only. - Same is true for a home-grown filtering mechanism. - A less powerful filtering mechanism would cause more network traffic and thus increase network and CPU load, since managers would have to retrieve more data than required if the required filtering cannot be done on the agent side. Furthermore, nowadays even the cheapest APs, switches and other devices come with an HTTP server, SSH, SNMP, syslog, and much more stuff. Firmware resides in relatively large, however cheap enough flash memory. The ease of usability and manageability through such features often makes it an attractive and successful product. This generally weighs more than the costs to develop and build such features. At least, this is my impression. -- 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: From owner-netconf@ops.ietf.org Wed Jun 9 23:40:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16450 for ; Wed, 9 Jun 2004 23:40:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYGBz-0000SB-Fm for netconf-data@psg.com; Thu, 10 Jun 2004 03:25:27 +0000 Received: from [216.148.227.85] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYGBw-0000Rd-FF for netconf@ops.ietf.org; Thu, 10 Jun 2004 03:25:24 +0000 Received: from d55py901 (h00095bd4b8bb.ne.client2.attbi.com[24.128.66.196]) by comcast.net (rwcrmhc12) with SMTP id <2004061003252201400c5c4fe>; Thu, 10 Jun 2004 03:25:22 +0000 Reply-To: From: "David Harrington" To: Subject: RE: sub-tree filtering proposals Date: Wed, 9 Jun 2004 23:25:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <75F0AA52-BA54-11D8-91C0-000A95909448@ibr.cs.tu-bs.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcROYu/KaUgOCAtXRzirkc5M+5NfmQANtcrg X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: quoted-printable Hi, From a vendor-neutral application development standpoint (and presumably from a vendor-neutral operations standpoint), a combination of mandatory/optional filtering features will need to be supported to = manage a heterogeneuos network of devices, and it will be much simpler to support full Xpath and a well-defined subset of Xpath than it would be to = support full Xpath plus another filtering mechanism.=20 Would operators prefer to have two mechanisms to learn, or just one mechanism with two well-defined variations? Dave Harrington dbharrington@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Frank Strau=DF > Sent: Wednesday, June 09, 2004 4:35 PM > To: j.schoenwaelder@iu-bremen.de > Cc: netconf@ops.ietf.org > Subject: Re: sub-tree filtering proposals >=20 > On 09. Jun 2004, at 15:42, Juergen Schoenwaelder wrote: >=20 > > [...] > > First, I believe a subset of XPATH (not an adapted subset) is still=20 > > better than something homegrown. >=20 > I agree. >=20 > > (The most vocal members of the WG do not seem to buy full=20 > XPATH as a=20 > > requirement.) >=20 > Maybe the reason is, that there are still not many operators=20 > and developers of manager software raising their voice. (I'm=20 > just guessing.) >=20 > > Personally, I believe that the > > operators using netconf will ask for full XPATH anyway, so=20 > the subset=20 > > requirement will likely not be a real issue in practice. >=20 > However, a netconf standard should have the purpose to come=20 > to a common sense on what agents support and what managers=20 > can rely on. If we have reasons to assume that operators and=20 > others will ask for full XPath (and I do think so, too) we=20 > should address this need *now* (and BTW not in a subsequent=20 > revision as long as we did not even find rough consensus for=20 > the initial revision). >=20 > > I think the general idea is that boxes announce whether they do=20 > > support full XPATH or just a reduced subset. I do not see=20 > that there=20 > > is anything wrong with this. >=20 > In general, I agree. >=20 > > The alternative, a home grow filter format which=20 > implementations are=20 > > required to support, seems worse to me. Bottom line is that either > > (a) the netconf WG makes a decision to require XPATH full stop, or > > (b) the WG makes a decision to support XPATH and require a=20 > subset of=20 > > it, or > > (c) the WG makes a decision to support XPATH and to require another > > home-grown filter format. > > > > Since (a) does not seem to be getting WG consensus, I=20 > believe (b) is=20 > > the best we can do. >=20 > First to say, my preference would be (a). If there are reasons against > (a) > (I guess, I missed a discussion on this), I would also favor=20 > (b) over (c). >=20 >=20 > On 09. Jun 2004, at 18:22, Juergen Schoenwaelder wrote: >=20 > >> The advantages of the proposal above are: > >> - subtree filtering is easy to implement on agents; > >> only XML parser needed, not XML and Xpath parsers > > > > Come on, parsing Xpath expression is really not that=20 > complicated. I am=20 > > really wondering on which basis you calculate how much you save on=20 > > embedded boxes... >=20 > I would also like to see a clear reasoning, not just on the=20 > pure code size. These aspects come to my mind: >=20 > - We should take into account that many XPath implementations exist. > My expectation would be that deriving a subset implementation would > need some time (not much, but more that just picking an existing > full implementation) just to shrink the code size for a small > percentage. > - An XPath subset would most probably *not* reduce CPU load compared > to full XPath. > - Building a new XPath (subset) implementation from scratch could be > required by some vendors' policies. A full implementation would fit > in the idea of reusability, while a netconf subset would be limited > netconf only. > - Same is true for a home-grown filtering mechanism. > - A less powerful filtering mechanism would cause more network traffic > and thus increase network and CPU load, since managers would have > to retrieve more data than required if the required=20 > filtering cannot > be done on the agent side. >=20 > Furthermore, nowadays even the cheapest APs, switches and=20 > other devices come with an HTTP server, SSH, SNMP, syslog,=20 > and much more stuff.=20 > Firmware > resides in relatively large, however cheap enough flash=20 > memory. The ease of usability and manageability through such=20 > features often makes it an attractive and successful product.=20 > This generally weighs more than the costs to develop and=20 > build such features. At least, this is my impression. >=20 >=20 > -- > 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: >=20 -- 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: From owner-netconf@ops.ietf.org Thu Jun 10 03:22:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09865 for ; Thu, 10 Jun 2004 03:22:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYJht-000Krp-VZ for netconf-data@psg.com; Thu, 10 Jun 2004 07:10:37 +0000 Received: from [196.14.124.43] (helo=srv-mailrnd.azisa.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYJhr-000KrD-VC for netconf@ops.ietf.org; Thu, 10 Jun 2004 07:10:36 +0000 Received: from srv-mailct.azisa.co.za ([10.189.128.47]) by srv-mailrnd.azisa.co.za with Microsoft SMTPSVC(6.0.3790.0); Thu, 10 Jun 2004 09:09:09 +0200 Content-class: urn:content-classes:message Subject: RE: sub-tree filtering proposals MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Jun 2004 09:09:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: <395F89B355756C4188231F50659A48AD078FB0@srv-mailct.azisa.co.za> Thread-Topic: sub-tree filtering proposals Thread-Index: AcROY1fFpstjO8vVQs21oagw9gKK4gAVLlXw From: "Michael Walton" To: =?iso-8859-1?Q?Frank_Strau=DF?= , Cc: X-OriginalArrivalTime: 10 Jun 2004 07:09:09.0975 (UTC) FILETIME=[D3A21E70:01C44EB9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Regarding code size of XPath: for interest and discussion's sake, I did = a little footprint test using libxml2. xpath.c seems to contain all the required processing, and is a fairly = hefty source file at 324K. Compiled and stripped it produces an object file of 88K. I tried = gcc-i386 and gcc-ppc and both produce similar results. Compressed (using mkcramfs for compressed ROM filesystem) it ends up at = 36K. I haven't checked whether it incurs additional library = requirements, etc. but I think it illustrates a point.=20 YMMV :-) Mike -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On = Behalf Of Frank Strau=DF Sent: Wednesday, June 09, 2004 10:35 PM To: j.schoenwaelder@iu-bremen.de Cc: netconf@ops.ietf.org Subject: Re: sub-tree filtering proposals On 09. Jun 2004, at 15:42, Juergen Schoenwaelder wrote: > [...] > First, I believe a subset of XPATH (not an adapted subset) is still=20 > better > than something homegrown. I agree. > (The most vocal members of the WG do not seem > to buy full XPATH as a requirement.) Maybe the reason is, that there are still not many operators and=20 developers of manager software raising their voice. (I'm just guessing.) > Personally, I believe that the > operators using netconf will ask for full XPATH anyway, so the subset > requirement will likely not be a real issue in practice. However, a netconf standard should have the purpose to come to a common sense on what agents support and what managers can rely on. If we have reasons to assume that operators and others will ask for full XPath (and I do think so, too) we should address this need *now* (and BTW not in a subsequent revision as long as we did not even find rough consensus for the initial revision). > I think the general idea is that boxes announce whether they do=20 > support full > XPATH or just a reduced subset. I do not see that there is anything=20 > wrong > with this. In general, I agree. > The alternative, a home grow filter format which implementations are > required to support, seems worse to me. Bottom line is that either > (a) the netconf WG makes a decision to require XPATH full stop, or > (b) the WG makes a decision to support XPATH and require a subset of=20 > it, or > (c) the WG makes a decision to support XPATH and to require another > home-grown filter format. > > Since (a) does not seem to be getting WG consensus, I believe (b) is=20 > the > best we can do. First to say, my preference would be (a). If there are reasons against=20 (a) (I guess, I missed a discussion on this), I would also favor (b) over=20 (c). On 09. Jun 2004, at 18:22, Juergen Schoenwaelder wrote: >> The advantages of the proposal above are: >> - subtree filtering is easy to implement on agents; >> only XML parser needed, not XML and Xpath parsers > > Come on, parsing Xpath expression is really not that complicated. I am > really wondering on which basis you calculate how much you save on > embedded boxes... I would also like to see a clear reasoning, not just on the pure code size. These aspects come to my mind: - We should take into account that many XPath implementations exist. My expectation would be that deriving a subset implementation would need some time (not much, but more that just picking an existing full implementation) just to shrink the code size for a small percentage. - An XPath subset would most probably *not* reduce CPU load compared to full XPath. - Building a new XPath (subset) implementation from scratch could be required by some vendors' policies. A full implementation would fit in the idea of reusability, while a netconf subset would be limited netconf only. - Same is true for a home-grown filtering mechanism. - A less powerful filtering mechanism would cause more network traffic and thus increase network and CPU load, since managers would have to retrieve more data than required if the required filtering cannot be done on the agent side. Furthermore, nowadays even the cheapest APs, switches and other devices come with an HTTP server, SSH, SNMP, syslog, and much more stuff.=20 Firmware resides in relatively large, however cheap enough flash memory. The ease of usability and manageability through such features often makes it an attractive and successful product. This generally weighs more than the costs to develop and build such features. At least, this is my=20 impression. -- 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: -- 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: From owner-netconf@ops.ietf.org Thu Jun 10 05:56:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15841 for ; Thu, 10 Jun 2004 05:56:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1BYM4z-0007Yq-4M for netconf-data@psg.com; Thu, 10 Jun 2004 09:42:37 +0000 Received: from [134.169.34.18] (helo=agitator.ibr.cs.tu-bs.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BYM4v-0007YK-Io for netconf@ops.ietf.org; Thu, 10 Jun 2004 09:42:33 +0000 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5A9gGKI025262 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 10 Jun 2004 11:42:16 +0200 Date: Thu, 10 Jun 2004 11:42:16 +0200 From: =?ISO-8859-1?Q?Frank_Strau=DF?= To: netconf@ops.ietf.org Subject: RE: sub-tree filtering proposals Message-ID: In-Reply-To: <395F89B355756C4188231F50659A48AD078FB0@srv-mailct.azisa.co.za> References: <395F89B355756C4188231F50659A48AD078FB0@srv-mailct.azisa.co.za> X-Mailer: Mulberry/3.1.4 (Linux/x86) X-PGP-Key: 1024D/3B8A33AA 2000-08-03 Frank Strauss X-PGP-Fingerprint: F6CD 195C F141 4CF8 72AD 0CB0 CD24 F033 3B8A 33AA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michael Walton wrote: > Regarding code size of XPath: for interest and discussion's sake, I did a > little footprint test using libxml2. > > xpath.c seems to contain all the required processing, and is a fairly hefty > source file at 324K. > > Compiled and stripped it produces an object file of 88K. I tried gcc-i386 and > gcc-ppc and both produce similar results. > > Compressed (using mkcramfs for compressed ROM filesystem) it ends up at 36K. > I haven't checked whether it incurs additional library requirements, etc. but > I think it illustrates a point. Thank you very much, Michael! So the difference in (compressed) size compared to an XPath subset or another limited home-grown filtering mechanism is probably less than 25kB. I don't see the point in saving this amount of memory compared to all the disadvantages (enumerated in my last message) that a non-(full)-Xpath solution would cause. -- 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: From owner-netconf@ops.ietf.org Thu Jun 10 12:34:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17521 for ; Thu, 10 Jun 2004 12:34:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYSI3-000O22-Nu for netconf-data@psg.com; Thu, 10 Jun 2004 16:20:31 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYSI2-000O1R-Ar for netconf@ops.ietf.org; Thu, 10 Jun 2004 16:20:30 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2004 09:21:25 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5AGKRIn026292; Thu, 10 Jun 2004 09:20:27 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-396.cisco.com [10.21.65.140]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AVD56289; Thu, 10 Jun 2004 09:20:25 -0700 (PDT) Message-Id: <6.1.1.1.2.20040610090526.03aedda8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 10 Jun 2004 09:15:08 -0700 To: "Michael Walton" From: Andy Bierman Subject: RE: sub-tree filtering proposals Cc: Frank =?iso-8859-1?Q?Strau=DF?= , , In-Reply-To: <395F89B355756C4188231F50659A48AD078FB0@srv-mailct.azisa.co .za> References: <395F89B355756C4188231F50659A48AD078FB0@srv-mailct.azisa.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 12:09 AM 6/10/2004, Michael Walton wrote: >Regarding code size of XPath: for interest and discussion's sake, I did a= little footprint test using libxml2. > >xpath.c seems to contain all the required processing, and is a fairly hefty= source file at 324K. > >Compiled and stripped it produces an object file of 88K. I tried gcc-i386= and gcc-ppc and both produce similar results. > >Compressed (using mkcramfs for compressed ROM filesystem) it ends up at= 36K. I haven't checked whether it incurs additional library requirements,= etc. but I think it illustrates a point.=20 The code size at runtime, on the runtime platform, is the first interesting number. The size of the compressed file on disk is irrelevant. You don't show the most interesting number, which is the static and dynamic data memory usage during the processing=20 of a or operation. Memory is a precious resource=20 on small embedded devices, which do networking as their primary task,=20 not Xpath. No customers are asking for Xpath on small devices --=20 there isn't enough config there to worry so much about retrieval filtering. IMO, it is unacceptable to make Xpath mandatory because not all devices=20 need it nor can support it without impacting manufacturing cost. >YMMV :-) > >Mike Andy >-----Original Message----- >From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On= Behalf Of Frank Strau=DF >Sent: Wednesday, June 09, 2004 10:35 PM >To: j.schoenwaelder@iu-bremen.de >Cc: netconf@ops.ietf.org >Subject: Re: sub-tree filtering proposals > >On 09. Jun 2004, at 15:42, Juergen Schoenwaelder wrote: > >> [...] >> First, I believe a subset of XPATH (not an adapted subset) is still=20 >> better >> than something homegrown. > >I agree. > >> (The most vocal members of the WG do not seem >> to buy full XPATH as a requirement.) > >Maybe the reason is, that there are still not many operators and=20 >developers >of manager software raising their voice. (I'm just guessing.) > >> Personally, I believe that the >> operators using netconf will ask for full XPATH anyway, so the subset >> requirement will likely not be a real issue in practice. > >However, a netconf standard should have the purpose to come to a common >sense on what agents support and what managers can rely on. If we have >reasons to assume that operators and others will ask for full XPath (and >I do think so, too) we should address this need *now* (and BTW not in a >subsequent revision as long as we did not even find rough consensus for >the initial revision). > >> I think the general idea is that boxes announce whether they do=20 >> support full >> XPATH or just a reduced subset. I do not see that there is anything=20 >> wrong >> with this. > >In general, I agree. > >> The alternative, a home grow filter format which implementations are >> required to support, seems worse to me. Bottom line is that either >> (a) the netconf WG makes a decision to require XPATH full stop, or >> (b) the WG makes a decision to support XPATH and require a subset of=20 >> it, or >> (c) the WG makes a decision to support XPATH and to require another >> home-grown filter format. >> >> Since (a) does not seem to be getting WG consensus, I believe (b) is=20 >> the >> best we can do. > >First to say, my preference would be (a). If there are reasons against=20 >(a) >(I guess, I missed a discussion on this), I would also favor (b) over=20 >(c). > > >On 09. Jun 2004, at 18:22, Juergen Schoenwaelder wrote: > >>> The advantages of the proposal above are: >>> - subtree filtering is easy to implement on agents; >>> only XML parser needed, not XML and Xpath parsers >> >> Come on, parsing Xpath expression is really not that complicated. I am >> really wondering on which basis you calculate how much you save on >> embedded boxes... > >I would also like to see a clear reasoning, not just on the pure code >size. These aspects come to my mind: > >- We should take into account that many XPath implementations exist. > My expectation would be that deriving a subset implementation would > need some time (not much, but more that just picking an existing > full implementation) just to shrink the code size for a small > percentage. >- An XPath subset would most probably *not* reduce CPU load compared > to full XPath. >- Building a new XPath (subset) implementation from scratch could be > required by some vendors' policies. A full implementation would fit > in the idea of reusability, while a netconf subset would be limited > netconf only. >- Same is true for a home-grown filtering mechanism. >- A less powerful filtering mechanism would cause more network traffic > and thus increase network and CPU load, since managers would have > to retrieve more data than required if the required filtering cannot > be done on the agent side. > >Furthermore, nowadays even the cheapest APs, switches and other devices >come with an HTTP server, SSH, SNMP, syslog, and much more stuff.=20 >Firmware >resides in relatively large, however cheap enough flash memory. The ease >of usability and manageability through such features often makes it an >attractive and successful product. This generally weighs more than the >costs to develop and build such features. At least, this is my=20 >impression. > > >-- >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: > >-- >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: =20 -- 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: From owner-netconf@ops.ietf.org Thu Jun 10 13:56:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21417 for ; Thu, 10 Jun 2004 13:56:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYTeo-000Aoo-Jx for netconf-data@psg.com; Thu, 10 Jun 2004 17:48:06 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYTel-000AoN-Q6 for netconf@ops.ietf.org; Thu, 10 Jun 2004 17:48:03 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 10 Jun 2004 10:48:07 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5AHlxdL005299 for ; Thu, 10 Jun 2004 10:48:01 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-396.cisco.com [10.21.65.140]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AVD68497; Thu, 10 Jun 2004 10:47:58 -0700 (PDT) Message-Id: <6.1.1.1.2.20040610090355.03aeda48@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 10 Jun 2004 10:42:41 -0700 To: netconf@ops.ietf.org From: Andy Bierman Subject: retrieval filtering decision points Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi, The WG is deeply divided over subtree filtering vs. partial Xpath for the solution to retrieval filtering for the and operations. The XML Directorate seemed to be divided as well on the value of our Xpath subset or the potential harm of our subtree filtering. I am going to try to separate out the various decision points, some of which appear to have WG consensus already. D1) Applicability and scale There seems to be consensus that not every device has the same need for retrieval filtering, or the ability to support various SW solutions. Therefore, any mandatory-to-implement filtering mechanism must take this into account. Very small devices do not have large configurations, and the amount of state data contained in a single namespace can be controlled by the vendor to a large degree. It is therefore quite reasonable for this type of device not to need any further retrieval filtering at all. Very large devices can have huge configurations and a huge amount of state data as well. Only full Xpath (of our choices) will likely be suitable for this type of device. There are 3 levels of retrieval filtering being considered for NETCONF devices: Level 1: namespace - specify the target namespace to retrieve Level 2: something other than full Xpath 1.0 Level 3: Xpath 1.0 D2) Explicit vs. Implicit Filters There is WG consensus that the and operations should use a parameter called to identify the filter type and hold the filter contents, instead of directly placing the filter contents in the or parameters. The mechanism allows the NETCONF protocol to easily support multiple retrieval mechanisms, and/or different versions of retrieval mechanisms over time. D3) Full Xpath support The seems to be WG consensus that v1.0 should utilize full Xpath 1.0, although there is not consensus that this should be mandatory for all devices. - A string (or perhaps URI) to identify Xpath as a supported NETCONF filter type should be defined. - The #xpath capability should be defined, which indicates that the agent supports full Xpath 1.0, and allows filter-type="" (value TBD) in and operations. - The WG must decide if full Xpath support MAY or SHOULD be supported by every NETCONF agent. D4) Decoupling the protocol document from the retrieval filtering mechanism(s) There seems to be WG consensus that definition of any XML subtree filtering mechanisms is not a core task for the NETCONF WG, and not critical to protocol operation. It does not appear that the WG will reach consensus on which new filtering mechanism (subtree or Xpath subset) to develop. It is also not clear that agreement on the exact features or details of either proposal will be easy to achieve. - The WG must decide if all definition of XML filter mechanisms should be removed from the protocol document. - If so, the WG must also decide if either (or both) of the filter proposals should be developed as RFCs, and their type (Proposed Standard, Informational, Experimental). thanks, 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: From owner-netconf@ops.ietf.org Thu Jun 10 14:05:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21753 for ; Thu, 10 Jun 2004 14:05:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYTof-000Cvb-DS for netconf-data@psg.com; Thu, 10 Jun 2004 17:58:17 +0000 Received: from [134.169.34.18] (helo=agitator.ibr.cs.tu-bs.de) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYToe-000CvG-EO for netconf@ops.ietf.org; Thu, 10 Jun 2004 17:58:16 +0000 Received: from [10.0.1.2] (p508E7C9F.dip.t-dialin.net [80.142.124.159]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5AHwDKI020410 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 10 Jun 2004 19:58:14 +0200 In-Reply-To: <6.1.1.1.2.20040610090526.03aedda8@fedex.cisco.com> References: <395F89B355756C4188231F50659A48AD078FB0@srv-mailct.azisa.co.za> <6.1.1.1.2.20040610090526.03aedda8@fedex.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Frank_Strau=DF?= Subject: Re: sub-tree filtering proposals Date: Thu, 10 Jun 2004 19:58:11 +0200 To: netconf@ops.ietf.org X-Mailer: Apple Mail (2.618) X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_NJABL autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10. Jun 2004, at 18:15, Andy Bierman wrote: > The code size at runtime, on the runtime platform, is the first > interesting number. The size of the compressed file on disk is > irrelevant. You don't show the most interesting number, which > is the static and dynamic data memory usage during the processing > of a or operation. Memory is a precious resource As far as I know, RAM is much cheaper than flash memory. > on small embedded devices, which do networking as their primary task, > not Xpath. No customers are asking for Xpath on small devices -- Customers are asking for consistent specs without too many options, since every options might have to be handled differently and cause trouble. > there isn't enough config there to worry so much about retrieval > filtering. That *might* be true. The manager might not know in advance. > IMO, it is unacceptable to make Xpath mandatory because not all devices > need it nor can support it without impacting manufacturing cost. In situations where resources are really that limited, XML is the wrong choice anyway. My expectation would be that devices that implement netconf will not have such limited resources. Another questions comes to my mind: If limited devices would receive a request with an unsupported XPath predicate, would it (a) return an error message or would it (b) return a result document that might be larger than the document returned by a full XPath implementation (e.g., by just stripping any occurance of "[...]")? I just started thinking about (b). And at first glance, it could probably be a reasonable compromise: The client would not have to care about the agent's #xpath capability and the fact that the returned document contains unrequested nodes would probably not cause any problems. The response should probably signal somehow that the request contained an unsupported filtering expression. What do you think? -- 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: From owner-netconf@ops.ietf.org Thu Jun 10 14:41:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23280 for ; Thu, 10 Jun 2004 14:41:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYUNk-000HSJ-Cx for netconf-data@psg.com; Thu, 10 Jun 2004 18:34:32 +0000 Received: from [80.185.90.49] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYUNj-000HRp-7X for netconf@ops.ietf.org; Thu, 10 Jun 2004 18:34:31 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id AA2B487BB; Thu, 10 Jun 2004 20:34:29 +0200 (CEST) Date: Thu, 10 Jun 2004 20:34:29 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: retrieval filtering decision points Message-ID: <20040610183429.GA1711@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <6.1.1.1.2.20040610090355.03aeda48@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040610090355.03aeda48@fedex.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Thu, Jun 10, 2004 at 10:42:41AM -0700, Andy Bierman wrote: > The WG is deeply divided over subtree filtering vs. partial Xpath > for the solution to retrieval filtering for the and > operations. The XML Directorate seemed to be divided as > well on the value of our Xpath subset or the potential harm of our > subtree filtering. I am going to try to separate out the various > decision points, some of which appear to have WG consensus already. [...] Are you saying that the netconf protocol only supports an empty filter (which does not filter at all) and full xpath filtering becomes a capability? I think this pretty much makes sense as a way out of this deadlock situation. Of course, it leaves it to the vendors and the market to decide where the boundary between small and not so small devices is. And by saying no filtering is the lowest bound common denominator, not so smart applications will always do a full dump and filter on the manager side to avoid dealing with different capabilities. (But something like that will happen whenever we have different filtering capabilities.) What I do not yet understand is how namespaces play with this. I guess this needs more thought and investigation. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Thu Jun 10 15:13:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25318 for ; Thu, 10 Jun 2004 15:13:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYUpj-000MZQ-UJ for netconf-data@psg.com; Thu, 10 Jun 2004 19:03:27 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYUpj-000MZB-4b for netconf@ops.ietf.org; Thu, 10 Jun 2004 19:03:27 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2004 12:03:21 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5AJ3OtV009492; Thu, 10 Jun 2004 12:03:25 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-396.cisco.com [10.21.65.140]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AVD80812; Thu, 10 Jun 2004 12:03:22 -0700 (PDT) Message-Id: <6.1.1.1.2.20040610113947.03ae53a8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 10 Jun 2004 11:58:05 -0700 To: j.schoenwaelder@iu-bremen.de From: Andy Bierman Subject: Re: retrieval filtering decision points Cc: netconf@ops.ietf.org In-Reply-To: <20040610183429.GA1711@iu-bremen.de> References: <6.1.1.1.2.20040610090355.03aeda48@fedex.cisco.com> <20040610183429.GA1711@iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 11:34 AM 6/10/2004, Juergen Schoenwaelder wrote: >On Thu, Jun 10, 2004 at 10:42:41AM -0700, Andy Bierman wrote: > >> The WG is deeply divided over subtree filtering vs. partial Xpath >> for the solution to retrieval filtering for the and >> operations. The XML Directorate seemed to be divided as >> well on the value of our Xpath subset or the potential harm of our >> subtree filtering. I am going to try to separate out the various >> decision points, some of which appear to have WG consensus already. > >[...] > >Are you saying that the netconf protocol only supports an empty filter >(which does not filter at all) and full xpath filtering becomes a >capability? I think this pretty much makes sense as a way out of this >deadlock situation. yes -- I'm saying the protocol should be independent of the filter mechanism(s) used. I am split myself on subtree vs. Xpath subset. Neither one is clearly better than the other, and neither one comes close to full Xpath. >Of course, it leaves it to the vendors and the market to decide where >the boundary between small and not so small devices is. And by saying >no filtering is the lowest bound common denominator, not so smart >applications will always do a full dump and filter on the manager side >to avoid dealing with different capabilities. (But something like that >will happen whenever we have different filtering capabilities.) Namespace filtering is some amount of filtering. A vendor (or SDO) could purposely group management information, just like we do with MIB modules. This is much better than all or nothing, but not good enough for bigger devices. I don't think there is an optimal solution for all situations possible here, so it's not a problem if multiple solutions are pursued, or we migrate to better solutions when they exist in the future. From the WG POV, we should push full Xpath 1.0, but allow for other types of filtering as well. If people are willing to act as document editors, I think the WG should pursue either new approach, with the understanding that the deliverable is not coupled to NETCONF v1.0, in case the WG bogs down on these other documents. >What I do not yet understand is how namespaces play with this. I guess >this needs more thought and investigation. Either: or: http://example.com/schema-1 >/js Andy >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Thu Jun 10 15:18:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25780 for ; Thu, 10 Jun 2004 15:18:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYUv7-000Nli-7x for netconf-data@psg.com; Thu, 10 Jun 2004 19:09:01 +0000 Received: from [80.185.90.49] (helo=james.eecs.iu-bremen.de) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYUv6-000NlO-9y for netconf@ops.ietf.org; Thu, 10 Jun 2004 19:09:00 +0000 Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 4159A87BC; Thu, 10 Jun 2004 21:08:59 +0200 (CEST) Date: Thu, 10 Jun 2004 21:08:59 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: netconf@ops.ietf.org Subject: Re: retrieval filtering decision points Message-ID: <20040610190859.GB2039@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Andy Bierman , netconf@ops.ietf.org References: <6.1.1.1.2.20040610090355.03aeda48@fedex.cisco.com> <20040610183429.GA1711@iu-bremen.de> <6.1.1.1.2.20040610113947.03ae53a8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.1.1.2.20040610113947.03ae53a8@fedex.cisco.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Thu, Jun 10, 2004 at 11:58:05AM -0700, Andy Bierman wrote: > >What I do not yet understand is how namespaces play with this. I guess > >this needs more thought and investigation. > > Either: > > > > > > > > or: > > > > > > http://example.com/schema-1 > > > > I am not sure as long as I do not know the details how xpath works together with namespaces. As I said, this needs more thoughts (at least on my side). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- 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: From owner-netconf@ops.ietf.org Thu Jun 10 18:30:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04626 for ; Thu, 10 Jun 2004 18:30:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.34 (FreeBSD)) id 1BYXt7-000MFy-Q0 for netconf-data@psg.com; Thu, 10 Jun 2004 22:19:09 +0000 Received: from [134.169.34.18] (helo=agitator.ibr.cs.tu-bs.de) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BYXt6-000MFg-OU for netconf@ops.ietf.org; Thu, 10 Jun 2004 22:19:09 +0000 Received: from [10.0.1.2] (p508E7C9F.dip.t-dialin.net [80.142.124.159]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5AMHrKI030498 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 11 Jun 2004 00:17:54 +0200 In-Reply-To: <20040610190859.GB2039@iu-bremen.de> References: <6.1.1.1.2.20040610090355.03aeda48@fedex.cisco.com> <20040610183429.GA1711@iu-bremen.de> <6.1.1.1.2.20040610113947.03ae53a8@fedex.cisco.com> <20040610190859.GB2039@iu-bremen.de> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03C45A80-BB2C-11D8-91C0-000A95909448@ibr.cs.tu-bs.de> Content-Transfer-Encoding: 7bit Cc: Andy Bierman , netconf@ops.ietf.org From: =?ISO-8859-1?Q?Frank_Strau=DF?= Subject: Re: retrieval filtering decision points Date: Fri, 11 Jun 2004 00:17:52 +0200 To: j.schoenwaelder@iu-bremen.de X-Mailer: Apple Mail (2.618) X-IBRFilter-SpamReport: -4.9 () BAYES_00 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_NJABL autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10. Jun 2004, at 21:08, Juergen Schoenwaelder wrote: > On Thu, Jun 10, 2004 at 11:58:05AM -0700, Andy Bierman wrote: > >>> What I do not yet understand is how namespaces play with this. I >>> guess >>> this needs more thought and investigation. >> >> Either: >> >> >> >> >> >> >> >> or: >> >> >> >> >> >> http://example.com/schema-1 >> >> >> >> > > I am not sure as long as I do not know the details how xpath works > together with namespaces. As I said, this needs more thoughts (at > least on my side). The native way to filter based on a namespace could simply be achieved through XPath and look like this: -- 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: From owner-netconf@ops.ietf.org Mon Jun 14 13:06:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15397 for ; Mon, 14 Jun 2004 13:06:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZum0-0003Lr-3p for netconf-data@psg.com; Mon, 14 Jun 2004 16:57:28 +0000 Received: from [144.189.100.101] (helo=motgate2.mot.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZuln-0003Jh-UU for netconf@ops.ietf.org; Mon, 14 Jun 2004 16:57:16 +0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i5EGr6vR007872; Mon, 14 Jun 2004 09:53:06 -0700 (MST) Received: from motorola.com ([173.23.235.140]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i5EGti8Z022542; Mon, 14 Jun 2004 11:55:45 -0500 Message-ID: <40CDD8E4.4EF877BA@motorola.com> Date: Mon, 14 Jun 2004 11:57:09 -0500 From: Sandeep Adwankar Organization: Motorola Labs X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Enns CC: Cristian Cadar , netconf@ops.ietf.org Subject: Re: security issues References: <062B922B6EC55149B5A267ECE78E5D44053ABC80@photon.jnpr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Is it possible to document reasons behind mandating ssh in the NetConf draft. Particularly, I will like to understand reasons behind mandating ssh over TLS. TLS has wide support and can provide ubiquitous substrate on most platforms. For example, it's trivial to build management application that uses TLS with support of Java APIs but there are no Java API's for SSH. There are no published RFC's on SSH, so it's relatively early to expect support on all platforms. Thanks Sandeep Rob Enns wrote: > At the NETCONF meeing in Seoul, the WG indicated that SSH should > be the mandatory substrate for NETCONF. The draft will be cleaned > up to reflect this decision. > > thanks, > Rob > > > -----Original Message----- > > From: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Cristian Cadar > > Sent: Friday, May 28, 2004 8:02 AM > > To: netconf@ops.ietf.org > > Subject: security issues > > > > Hi, > > > > In order to have a secure communication between peers the > > draft mentions > > the usage of the Radius, TLS or SSH protocol. Why IPsec is > > not taken into account here? > > Which one of the protocols above is preferred/mandatory in > > NETCONF, if any? > > > > > > TNX > > Cristian > > > > > > -- > > 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: > > > > > > -- > 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: -- 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: From owner-netconf@ops.ietf.org Mon Jun 14 14:57:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20747 for ; Mon, 14 Jun 2004 14:57:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BZwUh-000HmJ-ME for netconf-data@psg.com; Mon, 14 Jun 2004 18:47:43 +0000 Received: from [207.17.137.104] (helo=juniper.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BZwUe-000Hlq-OR for netconf@ops.ietf.org; Mon, 14 Jun 2004 18:47:40 +0000 Received: from ([172.24.245.25]) by tokra.juniper.net with ESMTP ; Mon, 14 Jun 2004 11:46:59 -0700 Received: from photon.jnpr.net ([172.24.18.198]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 14 Jun 2004 11:46:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: security issues Date: Mon, 14 Jun 2004 11:46:57 -0700 Message-ID: <062B922B6EC55149B5A267ECE78E5D44053AC09C@photon.jnpr.net> Thread-Topic: security issues thread-index: AcRSMMV09DqCH3XjQv62/Rov3TifUwADkV5g From: "Rob Enns" To: "Sandeep Adwankar" Cc: "Cristian Cadar" , X-OriginalArrivalTime: 14 Jun 2004 18:46:59.0025 (UTC) FILETIME=[F92F2410:01C4523F] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The big reason SSH was chosen is that operators said they preferred it. Operators are already doing key management for SSH, they know how to administer it, there are already holes in their firewalls for it (where appropriate), and they are=20 comfortable with scripting via SSH. thanks, Rob > -----Original Message----- > From: Sandeep Adwankar [mailto:sandeep.adwankar@motorola.com]=20 > Sent: Monday, June 14, 2004 9:57 AM > To: Rob Enns > Cc: Cristian Cadar; netconf@ops.ietf.org > Subject: Re: security issues >=20 > Is it possible to document reasons behind mandating ssh in the NetConf > draft. Particularly, I will like to understand reasons behind=20 > mandating > ssh > over TLS. TLS has wide support and can provide ubiquitous substrate > on most platforms. For example, it's trivial to build management > application that uses TLS with support of Java APIs but there are no > Java API's for SSH. There are no published RFC's on SSH, so > it's relatively early to expect support on all platforms. >=20 > Thanks > Sandeep >=20 > Rob Enns wrote: >=20 > > At the NETCONF meeing in Seoul, the WG indicated that SSH should > > be the mandatory substrate for NETCONF. The draft will be cleaned > > up to reflect this decision. > > > > thanks, > > Rob > > > > > -----Original Message----- > > > From: owner-netconf@ops.ietf.org > > > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Cristian Cadar > > > Sent: Friday, May 28, 2004 8:02 AM > > > To: netconf@ops.ietf.org > > > Subject: security issues > > > > > > Hi, > > > > > > In order to have a secure communication between peers the > > > draft mentions > > > the usage of the Radius, TLS or SSH protocol. Why IPsec is > > > not taken into account here? > > > Which one of the protocols above is preferred/mandatory in > > > NETCONF, if any? > > > > > > > > > TNX > > > Cristian > > > > > > > > > -- > > > 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: > > > > > > > > > > -- > > 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: >=20 >=20 >=20 -- 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: From owner-netconf@ops.ietf.org Tue Jun 22 17:58:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01347 for ; Tue, 22 Jun 2004 17:58:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bct3b-0004RI-BY for netconf-data@psg.com; Tue, 22 Jun 2004 21:43:55 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcsqL-0002zF-8o for netconf@ops.ietf.org; Tue, 22 Jun 2004 21:30:14 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24534; Tue, 22 Jun 2004 15:58:28 -0400 (EDT) Message-Id: <200406221958.PAA24534@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-prot-03.txt Date: Tue, 22 Jun 2004 15:58:28 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Configuration Protocol Author(s) : R. Enns Filename : draft-ietf-netconf-prot-03.txt Pages : 77 Date : 2004-6-22 There is a need for standardized mechanisms to manipulate, install, edit, and delete the configuration of a network device. In addition, there is a need to retrieve device state information and receive asynchronous device state messages in a manner consistent with the configuration mechanisms. There is great interest in using an XML-based data encoding because a significant set of tools for manipulating ASCII text and XML encoded data already exists. Please send comments to netconf@ops.ietf.org. To subscribe, use netconf-request@ops.ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-prot-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-prot-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-22152300.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-prot-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-prot-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-22152300.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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: From owner-netconf@ops.ietf.org Fri Jun 25 08:27:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26063 for ; Fri, 25 Jun 2004 08:27:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bdpec-000Glz-5Q for netconf-data@psg.com; Fri, 25 Jun 2004 12:18:02 +0000 Received: from [164.164.31.6] (helo=wiproecmx2.wipro.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BdpeM-000Gkr-M4 for netconf@ops.ietf.org; Fri, 25 Jun 2004 12:17:47 +0000 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i5PCHcJr029156 for ; Fri, 25 Jun 2004 17:47:41 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Fri, 25 Jun 2004 17:47:37 +0530 Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Jun 2004 17:46:58 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45AAD.84BEA3F8" Subject: Pipelining and Timeout queries Date: Fri, 25 Jun 2004 17:41:17 +0530 Message-ID: <184E80410B37F54F8FAFE5CF9AD757C40128A7F7@blr-m2-msg.wipro.com> Thread-Topic: Pipelining and Timeout queries Thread-Index: AcRasmMyIQB5t48nQguVJlwgpeQgnA== From: To: X-OriginalArrivalTime: 25 Jun 2004 12:16:58.0803 (UTC) FILETIME=[501BE030:01C45AAE] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C45AAD.84BEA3F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have been following the netconf mailing list. I have some doubts regarding the following issues.=20 =20 1.Pipelining: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D section 3.6 of ID:draft-ietf-netconf-prot-03 states: =20 "NETCONF requests are processed serially by the managed device. Additional requests MAY be sent before previous ones have been completed. The managed device MUST send responses only in the order the requests were received." =20 whether the managed device (Agent) is required to send responses sequentially for requests recieved per session or is it for all requests across all sessions ? =20 What are operational scenarios for this requirement? =20 2.RPC request Time out: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Once the netconf manager sends a rpc request to the managed device,=20 how long should it wait for the rpc-reply? =20 Can the netconf manager time-out after a specified time interval? =20 Thanks & Regards, V.Sarma =20 ------_=_NextPart_001_01C45AAD.84BEA3F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 All,
     I  have = been=20 following the netconf mailing list. I have some doubts = regarding the=20 following issues.
 
1.Pipelining:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
sect= ion 3.6 of=20 ID:draft-ietf-netconf-prot-03 states:
 
"NETCONF <rpc> requests are = processed=20 serially by the managed device.
   Additional <rpc> = requests=20 MAY be sent before previous ones have been
   = completed.  The=20 managed device MUST send responses only in the order
   the = requests were received."
 
whether the managed device (Agent) is = required to=20 send responses sequentially for requests recieved per session or is it = for all=20 requests across all sessions ?
 
What are operational scenarios for this = requirement?
 
2.RPC request Time=20 out:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Once the netconf manager sends a rpc request=20 to the managed device,
how long should it wait for the=20 rpc-reply?
 
Can the netconf manager time-out after = a specified=20 time interval?
 
Thanks = &=20 Regards,
V.Sarma         &nb= sp;           &nbs= p;    =20
------_=_NextPart_001_01C45AAD.84BEA3F8-- -- 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: