From owner-netconf@ops.ietf.org Mon Apr 02 00:06:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYDoo-0004IY-Og for netconf-archive@lists.ietf.org; Mon, 02 Apr 2007 00:06:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYDok-00082C-Or for netconf-archive@lists.ietf.org; Mon, 02 Apr 2007 00:06:58 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYDhZ-0009Fv-Aj for netconf-data@psg.com; Mon, 02 Apr 2007 03:59:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [207.17.137.120] (helo=kremlin.juniper.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYDhV-0009Fc-Bj for netconf@ops.ietf.org; Mon, 02 Apr 2007 03:59:27 +0000 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 01 Apr 2007 20:59:24 -0700 X-IronPort-AV: i="4.14,359,1170662400"; d="scan'208"; a="680047310:sNHT50064652" Received: from idle.juniper.net ([172.25.4.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l323xGJ85400 for ; Sun, 1 Apr 2007 20:59:24 -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 l3242YFE055081 for ; Mon, 2 Apr 2007 00:02:38 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200704020402.l3242YFE055081@idle.juniper.net> To: netconf@ops.ietf.org Subject: Review of draft-ietf-netconf-notification-06 Date: Mon, 02 Apr 2007 00:02:34 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Here are my comments in the notification draft. Apologies that they are so late. These are comments from before ietf68, so some of them were raised at the WG meeting, but others were not. Thanks, Phil --------------------- > NETCONF Event Notifications > draft-ietf-netconf-notification-06.txt Here are my comments on this draft. They fall into four categories: (1) The subscription metaphor is unnecessary and confusing. There's no win from introducing it, since the subscription isn't a visible protocol element, nor is it visible to the client application. Use something like instead. (2) The element shouldn't be a top-level tag. The first netconf add-on should not require modification to the simple RPC protocol we put in netconf. It's both a bad precedent and unnecessary. The content can live inside a normal . This draft introduces a modality into the netconf session which is both subtle and disturbing. When a request for notification is issued, the session moves from netconf-rpc mode into netconf-notification mode. When the notifications are complete, the session silently reverts back to rpc mode. The transition is not signaled by any top-level operation. (3) The draft as written does not provide a solution to the notification problem. It is a wrapper. The meat is in the notifications themselves, and the draft does nothing to define a standard way of carrying the common notification formats. In particular, a syslog and an snmp trap mapping are needed. (4) Other editorial issues with the draft. In general, the draft is poorly organized, with numerous forward references to content that has not been discussed, often in vague terms without a concrete reference. I'd also like to re-address the .vs. inconsistency, hoping for a better interest than the handful of people that voted in the working group meeting. Are so few people really interested in this draft? > [NETCONF] can be conceptually partitioned into four layers: > > Layer Example > +-------------+ +----------------------------------------+ > | Content | | Configuration data | > +-------------+ +----------------------------------------+ > | | > +-------------+ +-------------------------------------------+ > | Operations | | , | > +-------------+ +-------------------------------------------+ > | | | > +-------------+ +-----------------------------+ | > | RPC | | , | | > +-------------+ +-----------------------------+ | > | | | > +-------------+ +------------------------------------------+ > | Transport | | BEEP, SSH, SSL, console | > | Protocol | | | > +-------------+ +------------------------------------------+ I was originally quite confused about why this picture was included in this draft, since I missed the addition. Looking at the new picture, the layer violation becomes more obvious. I find it particularly disturbing when I think that this draft modifies all four of these layers. My preference is for something that lives within the netconf framework, without requiring changes throughout it. > Managed Object: A collection of one of more Elements that define an > abstract thing of interest. This term is never referenced. > Subscription: A concept related to the delivery of notifications (if > any to send) involving destination and selection of notifications. > It is bound to the lifetime of a session. This definition is very weak. See above comments re: subscriptions. > Operation: This term is used to refer to NETCONF protocol > operations. Specifically within this document, operation refers > to NETCONF protocol operations defined in support of NETCONF > notifications. Can we include terms from the base spec implicitly? There are _many_ terms missing here, including replay, streams, profiles, and filters (maybe?). > An event is something that happens which may be of interest - a > configuration change, a fault, a change in status, crossing a > threshold, or an external input to the system, for example. Often > this results in an asynchronous message, sometimes referred to as a > notification or event notification, being sent out to interested > parties to notify them that this event has occurred. s/sent out/sent/ s/ to notify them that this event has occurred// > This memo defines a mechanism whereby the NETCONF client indicates > interest in receiving event notifications from a NETCONF server by > creating a subscription to receive event notifications. The NETCONF > server replies to indicate whether the subscription request was > successful and, if it was successful, begins sending the event > notifications to the NETCONF client as the events occur within the > system. These event notifications will continue to be sent until > either the NETCONF session is terminated or the subscription to > terminate for some other reason. The event notification subscription > allows a number of options to enable the NETCONF client to specify > which events are of interest. These are specified when the > subscription is created. s/subscription to/subscription/ > An NETCONF server is not required to process RPC requests on the > session associated with the subscription until the notification > subscription is done and may silently discard these requests. A > capability may be advertised to announce that a server is able to > process RPCs while a notification stream is active on a session. s/An NETCONF/A NETCONF/ >1.3. Motivation > > The motivation for this work is to enable the sending of asynchronous > messages that are consistent with the data model (content) and > security model used within a NETCONF implementation. This section seems odd, since the more detailed model given in 1.2. > o solution should provide a subscription mechanism (A NETCONF server > does not send notifications before being asked to do so and the > NETCONF client initiates the flow of notifications) Use of subscriptions isn't the requirement; the parenthetical sentence is the real requirement. >2. Notification-Related Operations The underlaying model from Section 3 (Supporting concepts) should appear before this section. Diving straight into operations without giving the reader a framework into which those operations fit puts syntax over semantics. >2.1.1. > Description: > This operation initiates an event notification subscription which > will send asynchronous event notifications to the initiator of the > command until the subscription to terminates. s/to terminates/is terminated/ or /terminates/ Can this description be improved? The subscription doesn't send notifications, but instructs the server to initiate sending notifications for events that match the given criteria. > Stream: > An optional parameter that indicates which stream of events is > of interest. If not present, then events in the default > NETCONF stream will be sent. Streams are not defined at the point in the draft. > Filter: > An optional parameter that indicates which subset of all > possible events are of interest. The format of this parameter > is the same as that of the filter parameter in the NETCONF > protocol operations. If not present, all events not precluded > by other parameters will be sent. This is mutually exclusive > with the named profile parameter. Include a reference to the section on filters. > Named Profile: > An optional parameter that points to a separately defined > filter profile. If not present, no additional filtering will > be applied. Note that changes to the profile after the > subscription has been created will have no effect. This is > mutually exclusive with the filter parameter This needs a forward reference also. Changes "points to" to "refers to". Missing period on last sentence. > Start Time: > A parameter used to trigger the replay feature and indicates > that the replay should start at the time specified. If start > time is not present, this is not a replay subscription. Why not refer to parameters by their real names, like start-time? Talk about the acceptable formats for this parameter. >2.2. Sending Event Notifications > Once the subscription has been set up, the NETCONF server sends the > event notifications asynchronously along the connection. s/along/over/ >2.2.1. > > Description: > > An event notification is sent to the initiator of a subscription> command asynchronously when an event of interest > (i.e. meeting the specified filtering criteria) to them has > occurred. An event notification is a complete and well-formed XML > document. Note that is not an RPC method but > rather the top level element identifying the one way message as a > notification. It should mention that the encoding of this element is transport specific, which I guess means we need to rev all the transport RFCs. Use ""client" instead of "initiator". It's confusing. It's not clear that "filtering criteria" refers to more than . The contents of the element are never discussed. It should at least say that the draft is not concerned with content. >2.3. Terminating the Subscription > Closing of the event notification subscription can be done by > terminating the NETCONF session ( ) or the underlying > transport session. If a stop time is provided when the subscription > is created, then the subscription will terminate after the stop time > is reached. In this case, the Netconf session will still be an > active session. This introduces a modality into netconf sessions that I dislike, especially since the triggers that switch the modes are buried inside the content. There's nothing at the layer to tell you that you've moved from mode to mode. The reference to is odd, since I can't see this being used in any real way. Are we expecting people to open a second session to kill their first session? This is the way the text reads but I can't imagine that's the intention. >3. Supporting Concepts Supporting concepts (semantics) should appear before syntactic content. Otherwise the reader is lost. >3.2. Event Streams > An event stream is defined herein as a set of event notifications > matching some forwarding criteria. s/herein// since all definitions are specific to this document. s/forwarding// since it doesn't make sense. > +----+ > | c1 |---+ available streams > +----+ | +---------+ > +----+ | |central |-> stream 1 > | c2 | +--->|event |-> stream 2 filter +-------+ > +----+ | |processor|-> netconf stream --->|netconf| > ... | | |-> stream n |server | see > System | +---------+ +-------+ below > Components| | // > ... | | // > +----+ | | (------------) > | cn |---+ | (notification) > +----+ +-----> ( logging ) > ( service ) > (------------) What are the "//" marks for? The "see below" is confusing, since the "below" boxes look like orphans. >3.2.1. Event Stream Definition > > Event streams are predefined on the managed device. The > configuration of event streams is outside the scope of this document. > However, it is envisioned that event streams are either pre- > established by the vendor (pre-configured) or user configurable (e.g. > part of the device's configuration) or both. Device vendors may > allow event stream configuration via NETCONF protocol (i.e. edit- > config operation) 3.2 starts with the definition of event streams. This section doesn't read well. It would be better to start with the event model, add event streams, add netconf, and then draw a picture of the final world view. >3.2.2. Event Stream Content Format > The contents of all event streams made available to a NETCONF client > (i.e. the notification sent by the NETCONF server) must be encoded in > XML. XML, but what sort? Can I just put a string under ? Do I need my own container tag? Can I put multiple elements in a ? Are there any rules? >3.2.3. Default Event Stream > A NETCONF server implementation supporting the notification > capability must support the "NETCONF" notification event stream. > This stream contains all NETCONF XML event notifications supported by > the NETCONF server. The definition of the event notification and > their contents for this event stream is outside the scope of this > document. We define a stream without a notification data model? How does this work? What possible purpose could it serve? Clients spontaneously "know" how to interpret these events? s/event notification/event notifications/ ? >3.2.4. Event Stream Sources > With the exception of the default event stream (NETCONF > notifications) specification of additional event stream sources (e.g. > SNMP, syslog, etc.) is outside the scope of this document. NETCONF > server implementations may leverage any desired event stream source > in the creation of supported event streams. I don't understand this section. Is it placing any sort of limitation on an NETCONF implementation? What should be NETCONF implementor read into it? Just that they can do what they want? Do we need to tell them that explicitly? >3.2.5.1. Name Retrieval using operation > > The list of available event streams is retrieved by requesting the > subtree via a operation. Available event streams > for the requesting session are returned in the reply containing the > and elements, where element is mandatory > and its value is unique. The returned list must only include the > names of those event streams for which the NETCONF session has > sufficient privileges. The NETCONF session privileges are determined > via access control mechanisms which are beyond the scope of this > document. An empty reply is returned if there are no available event > streams. The information is retrieved by requesting the > subtree via a operation. s/operation/ operation/ > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > What is "netmod"? Should this be under ":netconf:notification:1.0"? Are we intentionally making "netmod" .vs. "netconf" distinctions? Can you explain the distinction? >3.2.5.2. Event Stream Subscription > A NETCONF client may request from the NETCONF server the list of > available event streams to this session and then issue a subscription> request with the desired event stream name. Omitting > the event stream name from the request results > in subscription to the default NETCONF event stream. Why is this a feature, rather than a bug in the client code? Are we expecting an overwhelming use of the NETCONF stream that it makes sense to use it as the default? I skipped the schema, but will note that there normative text in the schema that is not in the real text. I don't know if this is intentional or not, but it's a bit confusing, especially given that people don't tend to read the schemas. elements are a poor source of specificiation. Better to move these discussion into the text. In particular, the bits about profiledata imply that it's configuration data, but there's no data model to go with it. For example, how to I change the of a named-profile? Also there are some odd rules about timestamps, and the interaction between fielded requests and the profiles. IMHO, this is best left to the implementation because (a) it's a corner case and (b) it's expensive to treat corner cases in ways that your implementation considered unnatural. If you force rigid behavior, you're likely to be ignored anyway. Best to leave it undefined. >3.4. Subscriptions not Configuration Data s/not/are not/ >While it may be possible to retrieve information about subscriptions >via a get operation, subscriptions are not stored configuration. This makes it sound like you can get configuration via , which is not true. Better to just explain that subscriptions are not configuration data, and their lifetime is defined by their session. > Named profiles, if used, are considered configuration data. Profiles may also be built into the device, right? >3.5. Filter Dependencies s/Dependencies/Mechanics/? >3.5.1. Named Profiles > A named profile is a filter that is created ahead of time and applied > at the time an event notification subscription is created . Note > that changes to the profile after the subscription has been created > will have no effect on the subscription. Since named profiles exist > outside of the subscription, they persist after the subscription has > been torn down. s/created ./created./ Again, the "changes" part is better seen as implementation-specific behavior. >4. XML Schema for Event Notifications Why are some imports documented and other not? >6. Notification Replay FWIW, I found this section much better laid out and easier to read. >6.1. Overview > > Replay is the ability to create an event subscription that will > resend recently sent notifications. These notifications are sent the > same way as normal notifications. s/recently sent/recently generated/ since they may not have been sent anywhere. > The actual number of stored notifications available for retrieval at > any given time is an NETCONF server implementation specific matter. > Control parameters for this aspect of the feature are outside the > scope of the current work. s/the current work/this document/ > This feature is dependent on a notification stream supporting some > form of notification logging, although it puts no restrictions on the > size or form of the log, nor where it resides within the device. s/This feature/Replay/ >6.2. Creating a Subscription with Replay > This feature uses optional parameters to the > command called 'startTime' and 'stopTime'. 'startTime' identifies the > earliest date and time of interest for event notifications being > replayed and also indicates that a subscription will be providing > replay of notifications. Events generated before this time are not > matched. 'stopTime' specifies the latest date and time of interest > for event notifications being replayed. If it is not present, then > notifications will continue to be sent until the subscription is > terminated. Talk about the transition to live events. > Note that while a notification has three potential times associated > it - the time it was generated, the time it was logged and the time > it was sent out by the NETCONF server - the startTime and stopTime > parameters are related to generation time. This paragraph should just say event time should be relative to the time the event occurred and the notification was generated. Discussing the other times is confusing. Is there a way to say now to avoid waiting for live events? > Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing > their input into the early work on this document. In addition, the > editors would like to acknowledge input at the Vancouver editing > session from the following people: Orly Nicklass, James Balestriere, > Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, > Dave Partain, Ray Atarashi and Dave Perkins and the following > additional people from the Montreal editing session: Balazs Lengyel, > Phil Shafer, Rob Ennes, Andy Bierman, Dan Romascanu, Bert Wijnen, > Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, > Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William > Chow. s/Ennes/Enns/ So my final comment is just this: This draft doesn't seem to follow in the same mold as netconf. Namespaces are different, tags are different, content is different, and the general feel is completely different. Is that a good thing? Are these differences viewed as "things netconf got wrong that need repaired"? Why is this draft so far afield from the original netconf RFCs? Shouldn't there be more harmony, consistency, and cohesiveness between the documents? 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 Mon Apr 02 00:53:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYEYI-0002rm-Eb for netconf-archive@lists.ietf.org; Mon, 02 Apr 2007 00:53:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYEYC-0001d6-Cr for netconf-archive@lists.ietf.org; Mon, 02 Apr 2007 00:53:58 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYEUQ-000LFf-76 for netconf-data@psg.com; Mon, 02 Apr 2007 04:49:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HYEUJ-000LF1-GX for netconf@ops.ietf.org; Mon, 02 Apr 2007 04:49:56 +0000 Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l324no5x004965 for ; Mon, 2 Apr 2007 00:49:51 -0400 Received: (qmail 17739 invoked by uid 78); 2 Apr 2007 04:49:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 2 Apr 2007 04:49:50 -0000 Message-ID: <46108B52.9020203@andybierman.com> Date: Sun, 01 Apr 2007 21:49:22 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Phil Shafer CC: netconf@ops.ietf.org Subject: Re: Review of draft-ietf-netconf-notification-06 References: <200704020402.l3242YFE055081@idle.juniper.net> In-Reply-To: <200704020402.l3242YFE055081@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: e9eeacd7fe925d5f7faae01ed8f85b97 Phil Shafer wrote: > Here are my comments in the notification draft. Apologies that > they are so late. These are comments from before ietf68, so some > of them were raised at the WG meeting, but others were not. > I can tell you have a lot of concerns about this draft. There has been a clash of design philosophy from the start I think. You and I want to deliver notifications while changing the protocol as little as possible, while the design in the notifications draft all along seems to want to change as much as possible. Most importantly, we seem to have strayed very far from our original design for notifications (use RFC 3195 syslog over beep), to what we have now. We seem to have started out trying to have little or no protocol overhead and 100% operationally useful feature (syslog content). We ended up with a 100% architectural solution with little or no operational value. The notification replay feature was not even in the charter, yet most of the complexity is related to that. We started out saying we at least need a config-change notification, and we don't even have that. I would really like to know if anybody is implementing this draft and if so, whether the draft is complete enough to produce an implementation. If nobody is implementing, then that is a warning sign in itself. > Thanks, > Phil Andy > > > --------------------- > > > >> NETCONF Event Notifications >> draft-ietf-netconf-notification-06.txt > > Here are my comments on this draft. They fall into four categories: > > (1) The subscription metaphor is unnecessary and confusing. There's > no win from introducing it, since the subscription isn't a visible > protocol element, nor is it visible to the client application. > Use something like instead. > > (2) The element shouldn't be a top-level tag. The > first netconf add-on should not require modification to the simple > RPC protocol we put in netconf. It's both a bad precedent and > unnecessary. The content can live inside a normal . > > This draft introduces a modality into the netconf session which is > both subtle and disturbing. When a request for notification is > issued, the session moves from netconf-rpc mode into > netconf-notification mode. When the notifications are complete, > the session silently reverts back to rpc mode. The transition is > not signaled by any top-level operation. > > (3) The draft as written does not provide a solution to the > notification problem. It is a wrapper. The meat is in the > notifications themselves, and the draft does nothing to define a > standard way of carrying the common notification formats. In > particular, a syslog and an snmp trap mapping are needed. > > (4) Other editorial issues with the draft. In general, the draft is > poorly organized, with numerous forward references to content that > has not been discussed, often in vague terms without a concrete > reference. > > I'd also like to re-address the .vs. inconsistency, > hoping for a better interest than the handful of people that voted in > the working group meeting. Are so few people really interested in > this draft? > >> [NETCONF] can be conceptually partitioned into four layers: >> >> Layer Example >> +-------------+ +----------------------------------------+ >> | Content | | Configuration data | >> +-------------+ +----------------------------------------+ >> | | >> +-------------+ +-------------------------------------------+ >> | Operations | | , | >> +-------------+ +-------------------------------------------+ >> | | | >> +-------------+ +-----------------------------+ | >> | RPC | | , | | >> +-------------+ +-----------------------------+ | >> | | | >> +-------------+ +------------------------------------------+ >> | Transport | | BEEP, SSH, SSL, console | >> | Protocol | | | >> +-------------+ +------------------------------------------+ > > I was originally quite confused about why this picture was included in > this draft, since I missed the addition. Looking at > the new picture, the layer violation becomes more obvious. I find it > particularly disturbing when I think that this draft modifies all four > of these layers. > > My preference is for something that lives within the netconf > framework, without requiring changes throughout it. > >> Managed Object: A collection of one of more Elements that define an >> abstract thing of interest. > > This term is never referenced. > >> Subscription: A concept related to the delivery of notifications (if >> any to send) involving destination and selection of notifications. >> It is bound to the lifetime of a session. > > This definition is very weak. See above comments re: subscriptions. > >> Operation: This term is used to refer to NETCONF protocol >> operations. Specifically within this document, operation refers >> to NETCONF protocol operations defined in support of NETCONF >> notifications. > > Can we include terms from the base spec implicitly? > > There are _many_ terms missing here, including replay, streams, > profiles, and filters (maybe?). > >> An event is something that happens which may be of interest - a >> configuration change, a fault, a change in status, crossing a >> threshold, or an external input to the system, for example. Often >> this results in an asynchronous message, sometimes referred to as a >> notification or event notification, being sent out to interested >> parties to notify them that this event has occurred. > > s/sent out/sent/ > s/ to notify them that this event has occurred// > >> This memo defines a mechanism whereby the NETCONF client indicates >> interest in receiving event notifications from a NETCONF server by >> creating a subscription to receive event notifications. The NETCONF >> server replies to indicate whether the subscription request was >> successful and, if it was successful, begins sending the event >> notifications to the NETCONF client as the events occur within the >> system. These event notifications will continue to be sent until >> either the NETCONF session is terminated or the subscription to >> terminate for some other reason. The event notification subscription >> allows a number of options to enable the NETCONF client to specify >> which events are of interest. These are specified when the >> subscription is created. > > s/subscription to/subscription/ > >> An NETCONF server is not required to process RPC requests on the >> session associated with the subscription until the notification >> subscription is done and may silently discard these requests. A >> capability may be advertised to announce that a server is able to >> process RPCs while a notification stream is active on a session. > > s/An NETCONF/A NETCONF/ > >> 1.3. Motivation >> >> The motivation for this work is to enable the sending of asynchronous >> messages that are consistent with the data model (content) and >> security model used within a NETCONF implementation. > > This section seems odd, since the more detailed model given in 1.2. > >> o solution should provide a subscription mechanism (A NETCONF server >> does not send notifications before being asked to do so and the >> NETCONF client initiates the flow of notifications) > > Use of subscriptions isn't the requirement; the parenthetical sentence > is the real requirement. > >> 2. Notification-Related Operations > > The underlaying model from Section 3 (Supporting concepts) should > appear before this section. Diving straight into operations without > giving the reader a framework into which those operations fit puts > syntax over semantics. > >> 2.1.1. >> Description: >> This operation initiates an event notification subscription which >> will send asynchronous event notifications to the initiator of the >> command until the subscription to terminates. > > s/to terminates/is terminated/ or /terminates/ > > Can this description be improved? The subscription doesn't send > notifications, but instructs the server to initiate sending > notifications for events that match the given criteria. > >> Stream: >> An optional parameter that indicates which stream of events is >> of interest. If not present, then events in the default >> NETCONF stream will be sent. > > Streams are not defined at the point in the draft. > >> Filter: >> An optional parameter that indicates which subset of all >> possible events are of interest. The format of this parameter >> is the same as that of the filter parameter in the NETCONF >> protocol operations. If not present, all events not precluded >> by other parameters will be sent. This is mutually exclusive >> with the named profile parameter. > > Include a reference to the section on filters. > >> Named Profile: >> An optional parameter that points to a separately defined >> filter profile. If not present, no additional filtering will >> be applied. Note that changes to the profile after the >> subscription has been created will have no effect. This is >> mutually exclusive with the filter parameter > > This needs a forward reference also. > > Changes "points to" to "refers to". > > Missing period on last sentence. > >> Start Time: >> A parameter used to trigger the replay feature and indicates >> that the replay should start at the time specified. If start >> time is not present, this is not a replay subscription. > > Why not refer to parameters by their real names, like start-time? > Talk about the acceptable formats for this parameter. > >> 2.2. Sending Event Notifications >> Once the subscription has been set up, the NETCONF server sends the >> event notifications asynchronously along the connection. > > s/along/over/ > >> 2.2.1. >> >> Description: >> >> An event notification is sent to the initiator of a > subscription> command asynchronously when an event of interest >> (i.e. meeting the specified filtering criteria) to them has >> occurred. An event notification is a complete and well-formed XML >> document. Note that is not an RPC method but >> rather the top level element identifying the one way message as a >> notification. > > It should mention that the encoding of this element is transport > specific, which I guess means we need to rev all the transport RFCs. > > Use ""client" instead of "initiator". It's confusing. > > It's not clear that "filtering criteria" refers to more than . > > The contents of the element are never discussed. It should at > least say that the draft is not concerned with content. > >> 2.3. Terminating the Subscription >> Closing of the event notification subscription can be done by >> terminating the NETCONF session ( ) or the underlying >> transport session. If a stop time is provided when the subscription >> is created, then the subscription will terminate after the stop time >> is reached. In this case, the Netconf session will still be an >> active session. > > This introduces a modality into netconf sessions that I dislike, > especially since the triggers that switch the modes are buried inside > the content. There's nothing at the layer to tell you that > you've moved from mode to mode. > > The reference to is odd, since I can't see this being > used in any real way. Are we expecting people to open a second > session to kill their first session? This is the way the text reads > but I can't imagine that's the intention. > >> 3. Supporting Concepts > > Supporting concepts (semantics) should appear before syntactic > content. Otherwise the reader is lost. > >> 3.2. Event Streams >> An event stream is defined herein as a set of event notifications >> matching some forwarding criteria. > > s/herein// since all definitions are specific to this document. > s/forwarding// since it doesn't make sense. > >> +----+ >> | c1 |---+ available streams >> +----+ | +---------+ >> +----+ | |central |-> stream 1 >> | c2 | +--->|event |-> stream 2 filter +-------+ >> +----+ | |processor|-> netconf stream --->|netconf| >> ... | | |-> stream n |server | see >> System | +---------+ +-------+ below >> Components| | // >> ... | | // >> +----+ | | (------------) >> | cn |---+ | (notification) >> +----+ +-----> ( logging ) >> ( service ) >> (------------) > > What are the "//" marks for? The "see below" is confusing, since the > "below" boxes look like orphans. > >> 3.2.1. Event Stream Definition >> >> Event streams are predefined on the managed device. The >> configuration of event streams is outside the scope of this document. >> However, it is envisioned that event streams are either pre- >> established by the vendor (pre-configured) or user configurable (e.g. >> part of the device's configuration) or both. Device vendors may >> allow event stream configuration via NETCONF protocol (i.e. edit- >> config operation) > > 3.2 starts with the definition of event streams. > > This section doesn't read well. It would be better to start with the > event model, add event streams, add netconf, and then draw a picture > of the final world view. > >> 3.2.2. Event Stream Content Format >> The contents of all event streams made available to a NETCONF client >> (i.e. the notification sent by the NETCONF server) must be encoded in >> XML. > > XML, but what sort? Can I just put a string under ? Do I need > my own container tag? Can I put multiple elements in a ? Are > there any rules? > >> 3.2.3. Default Event Stream >> A NETCONF server implementation supporting the notification >> capability must support the "NETCONF" notification event stream. >> This stream contains all NETCONF XML event notifications supported by >> the NETCONF server. The definition of the event notification and >> their contents for this event stream is outside the scope of this >> document. > > We define a stream without a notification data model? How does this > work? What possible purpose could it serve? Clients spontaneously > "know" how to interpret these events? > > s/event notification/event notifications/ ? > >> 3.2.4. Event Stream Sources >> With the exception of the default event stream (NETCONF >> notifications) specification of additional event stream sources (e.g. >> SNMP, syslog, etc.) is outside the scope of this document. NETCONF >> server implementations may leverage any desired event stream source >> in the creation of supported event streams. > > I don't understand this section. Is it placing any sort of limitation > on an NETCONF implementation? What should be NETCONF implementor read > into it? Just that they can do what they want? Do we need to tell > them that explicitly? > >> 3.2.5.1. Name Retrieval using operation >> >> The list of available event streams is retrieved by requesting the >> subtree via a operation. Available event streams >> for the requesting session are returned in the reply containing the >> and elements, where element is mandatory >> and its value is unique. The returned list must only include the >> names of those event streams for which the NETCONF session has >> sufficient privileges. The NETCONF session privileges are determined >> via access control mechanisms which are beyond the scope of this >> document. An empty reply is returned if there are no available event >> streams. The information is retrieved by requesting the >> subtree via a operation. > > s/operation/ operation/ > >> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> >> > > What is "netmod"? Should this be under ":netconf:notification:1.0"? > Are we intentionally making "netmod" .vs. "netconf" distinctions? Can > you explain the distinction? > >> 3.2.5.2. Event Stream Subscription >> A NETCONF client may request from the NETCONF server the list of >> available event streams to this session and then issue a > subscription> request with the desired event stream name. Omitting >> the event stream name from the request results >> in subscription to the default NETCONF event stream. > > Why is this a feature, rather than a bug in the client code? Are we > expecting an overwhelming use of the NETCONF stream that it makes > sense to use it as the default? > > I skipped the schema, but will note that there normative text in the > schema that is not in the real text. I don't know if this is > intentional or not, but it's a bit confusing, especially given that > people don't tend to read the schemas. elements > are a poor source of specificiation. Better to move these discussion > into the text. > > In particular, the bits about profiledata imply that it's > configuration data, but there's no data model to go with it. > For example, how to I change the of a named-profile? > > Also there are some odd rules about timestamps, and the interaction > between fielded requests and the profiles. IMHO, this is best left to > the implementation because (a) it's a corner case and (b) it's > expensive to treat corner cases in ways that your implementation > considered unnatural. If you force rigid behavior, you're likely to > be ignored anyway. Best to leave it undefined. > >> 3.4. Subscriptions not Configuration Data > > s/not/are not/ > >> While it may be possible to retrieve information about subscriptions >> via a get operation, subscriptions are not stored configuration. > > This makes it sound like you can get configuration via , which is > not true. Better to just explain that subscriptions are not > configuration data, and their lifetime is defined by their session. > >> Named profiles, if used, are considered configuration data. > > Profiles may also be built into the device, right? > >> 3.5. Filter Dependencies > > s/Dependencies/Mechanics/? > >> 3.5.1. Named Profiles >> A named profile is a filter that is created ahead of time and applied >> at the time an event notification subscription is created . Note >> that changes to the profile after the subscription has been created >> will have no effect on the subscription. Since named profiles exist >> outside of the subscription, they persist after the subscription has >> been torn down. > > s/created ./created./ > > Again, the "changes" part is better seen as implementation-specific behavior. > >> 4. XML Schema for Event Notifications > > Why are some imports documented and other not? > >> 6. Notification Replay > > FWIW, I found this section much better laid out and easier to read. > >> 6.1. Overview >> >> Replay is the ability to create an event subscription that will >> resend recently sent notifications. These notifications are sent the >> same way as normal notifications. > > s/recently sent/recently generated/ since they may not have been sent > anywhere. > >> The actual number of stored notifications available for retrieval at >> any given time is an NETCONF server implementation specific matter. >> Control parameters for this aspect of the feature are outside the >> scope of the current work. > > s/the current work/this document/ > >> This feature is dependent on a notification stream supporting some >> form of notification logging, although it puts no restrictions on the >> size or form of the log, nor where it resides within the device. > > s/This feature/Replay/ > >> 6.2. Creating a Subscription with Replay >> This feature uses optional parameters to the >> command called 'startTime' and 'stopTime'. 'startTime' identifies the >> earliest date and time of interest for event notifications being >> replayed and also indicates that a subscription will be providing >> replay of notifications. Events generated before this time are not >> matched. 'stopTime' specifies the latest date and time of interest >> for event notifications being replayed. If it is not present, then >> notifications will continue to be sent until the subscription is >> terminated. > > Talk about the transition to live events. > >> Note that while a notification has three potential times associated >> it - the time it was generated, the time it was logged and the time >> it was sent out by the NETCONF server - the startTime and stopTime >> parameters are related to generation time. > > This paragraph should just say event time should be relative to the > time the event occurred and the notification was generated. > Discussing the other times is confusing. > > Is there a way to say now to avoid waiting for > live events? > >> Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing >> their input into the early work on this document. In addition, the >> editors would like to acknowledge input at the Vancouver editing >> session from the following people: Orly Nicklass, James Balestriere, >> Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, >> Dave Partain, Ray Atarashi and Dave Perkins and the following >> additional people from the Montreal editing session: Balazs Lengyel, >> Phil Shafer, Rob Ennes, Andy Bierman, Dan Romascanu, Bert Wijnen, >> Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, >> Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William >> Chow. > > s/Ennes/Enns/ > > So my final comment is just this: This draft doesn't seem to follow > in the same mold as netconf. Namespaces are different, tags are > different, content is different, and the general feel is completely > different. Is that a good thing? Are these differences viewed as > "things netconf got wrong that need repaired"? Why is this draft so > far afield from the original netconf RFCs? Shouldn't there be more > harmony, consistency, and cohesiveness between the documents? > > 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: > > -- 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 Apr 04 10:13:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6Et-0001Ri-IA for netconf-archive@lists.ietf.org; Wed, 04 Apr 2007 10:13:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6Es-0007U7-7S for netconf-archive@lists.ietf.org; Wed, 04 Apr 2007 10:13:31 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ64y-000M1R-LA for netconf-data@psg.com; Wed, 04 Apr 2007 14:03:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ64p-000LzO-7e for netconf@ops.ietf.org; Wed, 04 Apr 2007 14:03:11 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l34E36d5013826 for ; Wed, 4 Apr 2007 10:03:06 -0400 Received: (qmail 1058 invoked by uid 78); 4 Apr 2007 14:03:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 4 Apr 2007 14:03:06 -0000 Message-ID: <4613AFFE.1020505@andybierman.com> Date: Wed, 04 Apr 2007 07:02:38 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Notification Implementations? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi, As we get ready to submit the NETCONF Notifications draft to the IESG, the issue of implementations and document completeness will come up. I would like to know if anybody is implementing the notifications draft, or has definite plans to implement it when it becomes an RFC. It certainly helps the approval process to say people are interested and implementing, and even better to say the draft is complete enough that some people already implemented it. Please answer privately if you do not want to announce product plans on a mailing list. 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 Wed Apr 04 11:23:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7KN-0005yi-AQ for netconf-archive@lists.ietf.org; Wed, 04 Apr 2007 11:23:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7KJ-0001mE-0d for netconf-archive@lists.ietf.org; Wed, 04 Apr 2007 11:23:15 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ7Fn-00026Q-62 for netconf-data@psg.com; Wed, 04 Apr 2007 15:18:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ7Fh-00025w-D1 for netconf@ops.ietf.org; Wed, 04 Apr 2007 15:18:29 +0000 Received: from localhost (c213-100-166-193.swipnet.se [213.100.166.193]) by mail.tail-f.com (Postfix) with ESMTP id 5CB041B80C3; Wed, 4 Apr 2007 17:18:23 +0200 (CEST) Date: Wed, 04 Apr 2007 17:18:12 +0200 (CEST) Message-Id: <20070404.171812.130203205.mbj@tail-f.com> To: ietf@andybierman.com Cc: netconf@ops.ietf.org Subject: Re: Notification Implementations? From: Martin Bjorklund In-Reply-To: <4613AFFE.1020505@andybierman.com> References: <4613AFFE.1020505@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Andy Bierman wrote: > Hi, > > As we get ready to submit the NETCONF Notifications draft > to the IESG, the issue of implementations and document completeness > will come up. > > I would like to know if anybody is implementing the notifications draft, > or has definite plans to implement it when it becomes an RFC. > It certainly helps the approval process to say people are interested > and implementing, and even better to say the draft is complete enough > that some people already implemented it. We plan to implement it. I also think the draft (07 I hope) is implementable. /martin -- 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 Apr 04 11:50:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7l6-0008BD-NH for netconf-archive@lists.ietf.org; Wed, 04 Apr 2007 11:50:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7l0-0005yi-Tc for netconf-archive@lists.ietf.org; Wed, 04 Apr 2007 11:50:52 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ7gh-0004Uz-4j for netconf-data@psg.com; Wed, 04 Apr 2007 15:46:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.7 Received: from [155.54.212.109] (helo=mail.um.es) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZ7gV-0004TO-0d for netconf@ops.ietf.org; Wed, 04 Apr 2007 15:46:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id F10B924097; Wed, 4 Apr 2007 15:46:05 +0000 (UTC) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon3 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05163-01-70; Wed, 4 Apr 2007 15:46:02 +0000 (UTC) Received: from [155.54.205.232] (inf-205-232.um.es [155.54.205.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 889568B2C7; Wed, 4 Apr 2007 15:45:52 +0000 (UTC) Message-ID: <4613C826.3010206@dif.um.es> Date: Wed, 04 Apr 2007 17:45:42 +0200 From: Gregorio Martinez Organization: University of Murcia (UMU) User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Andy Bierman Cc: "Netconf (E-mail)" Subject: Re: Notification Implementations? References: <4613AFFE.1020505@andybierman.com> In-Reply-To: <4613AFFE.1020505@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi Andy, hi all, we plan to implement it in one/two months in the latest version available by that time. The work will be done by someone who has already implemented the WS-Eventing specification, so possibly some feedback could be provided. Kind regards, Gregorio Gregorio Martinez, PhD University of Murcia (UMU), Spain Andy Bierman wrote: > Hi, > > As we get ready to submit the NETCONF Notifications draft > to the IESG, the issue of implementations and document completeness > will come up. > > I would like to know if anybody is implementing the notifications draft, > or has definite plans to implement it when it becomes an RFC. > It certainly helps the approval process to say people are interested > and implementing, and even better to say the draft is complete enough > that some people already implemented it. > > Please answer privately if you do not want to announce product plans > on a mailing list. > > 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: > -- 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 Apr 05 12:02:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUPw-0006lT-DT for netconf-archive@lists.ietf.org; Thu, 05 Apr 2007 12:02:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZUPv-0002y9-2y for netconf-archive@lists.ietf.org; Thu, 05 Apr 2007 12:02:32 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZUJg-000HiQ-Vw for netconf-data@psg.com; Thu, 05 Apr 2007 15:56:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZUJY-000HhN-5u for netconf@ops.ietf.org; Thu, 05 Apr 2007 15:55:59 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l35FtpL18268 for ; Thu, 5 Apr 2007 15:55:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Notification Implementations? Date: Thu, 5 Apr 2007 11:55:38 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40E530E18@zcarhxm2.corp.nortel.com> In-Reply-To: <4613AFFE.1020505@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notification Implementations? Thread-Index: Acd2w+BkfldL7Bk6QfSm7cyil3msxgA1sOag References: <4613AFFE.1020505@andybierman.com> From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi We have two implementations of a much earlier version of the draft. We are planning migrating those implementations as well supporting this version in additional products as schedules permit. Sharon=20 -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, April 04, 2007 10:03 AM To: Netconf (E-mail) Subject: Notification Implementations? Hi, As we get ready to submit the NETCONF Notifications draft to the IESG, the issue of implementations and document completeness will come up. I would like to know if anybody is implementing the notifications draft, or has definite plans to implement it when it becomes an RFC. It certainly helps the approval process to say people are interested and implementing, and even better to say the draft is complete enough that some people already implemented it. Please answer privately if you do not want to announce product plans on a mailing list. 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: -- 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 Apr 05 12:39:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUzT-0001zZ-TE for netconf-archive@lists.ietf.org; Thu, 05 Apr 2007 12:39:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZUzS-00084x-HM for netconf-archive@lists.ietf.org; Thu, 05 Apr 2007 12:39:15 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZUuA-000L4c-VX for netconf-data@psg.com; Thu, 05 Apr 2007 16:33:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.59] (helo=omr9.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZUu1-000L3x-H7 for netconf@ops.ietf.org; Thu, 05 Apr 2007 16:33:43 +0000 Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l35GXanH017040 for ; Thu, 5 Apr 2007 12:33:37 -0400 Received: (qmail 2503 invoked by uid 78); 5 Apr 2007 16:33:36 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 5 Apr 2007 16:33:36 -0000 Message-ID: <461524C3.3000409@andybierman.com> Date: Thu, 05 Apr 2007 09:33:07 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Notification Implementations? References: <4613AFFE.1020505@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40E530E18@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40E530E18@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Sharon Chisholm wrote: > Hi > > We have two implementations of a much earlier version of the draft. We > are planning migrating those implementations as well supporting this > version in additional products as schedules permit. > good. It is also great to be able to say 2 non-authors are also independently implementing it soon. We will hopefully get some feedback on the operational factors and any holes in the spec. My biggest concern is that we have some overly-complicated features for logging and replay of notifications, and somehow do not have any notification content at all to put in the NETCONF stream. I guess when implementations show up, we will see where there is commonality in the content and perhaps manage to design a standard config-change notification, and maybe even a couple more configuration related notifications. > Sharon Andy > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Andy Bierman > Sent: Wednesday, April 04, 2007 10:03 AM > To: Netconf (E-mail) > Subject: Notification Implementations? > > Hi, > > As we get ready to submit the NETCONF Notifications draft to the IESG, > the issue of implementations and document completeness will come up. > > I would like to know if anybody is implementing the notifications draft, > or has definite plans to implement it when it becomes an RFC. > It certainly helps the approval process to say people are interested and > implementing, and even better to say the draft is complete enough that > some people already implemented it. > > Please answer privately if you do not want to announce product plans on > a mailing list. > > 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: > > -- > 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 Apr 05 12:46:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZV6k-0000Gw-Or for netconf-archive@lists.ietf.org; Thu, 05 Apr 2007 12:46:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZV6j-000135-Dp for netconf-archive@lists.ietf.org; Thu, 05 Apr 2007 12:46:46 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZV1V-000Lsr-P1 for netconf-data@psg.com; Thu, 05 Apr 2007 16:41:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZV1F-000LrZ-Kd for netconf@ops.ietf.org; Thu, 05 Apr 2007 16:41:14 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Apr 2007 09:41:05 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l35Gf55p001903; Thu, 5 Apr 2007 09:41:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l35GeuMJ007218; Thu, 5 Apr 2007 16:41:05 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:40:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-netconf-notification-06 Date: Thu, 5 Apr 2007 09:40:54 -0700 Message-ID: <6E21698722408147BEA594E073E2B0AB038ECE4B@xmb-sjc-223.amer.cisco.com> In-Reply-To: <46108B52.9020203@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-notification-06 Thread-Index: Acd04n6nfXNS2JhQQ0GEvm6EtPQOTQCvjgQA References: <200704020402.l3242YFE055081@idle.juniper.net> <46108B52.9020203@andybierman.com> From: "Hector Trevino \(htrevino\)" To: "Andy Bierman" Cc: X-OriginalArrivalTime: 05 Apr 2007 16:40:59.0992 (UTC) FILETIME=[310FFD80:01C777A1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=362; t=1175791265; x=1176655265; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=htrevino@cisco.com; z=From:=20=22Hector=20Trevino=20\(htrevino\)=22=20 |Subject:=20RE=3A=20Review=20of=20draft-ietf-netconf-notification-06 |Sender:=20; bh=6jl0UqNccyoaIpoPqsuLzB9Xy0gP2AMhnge5AC1R0VQ=; b=YqRR3WR4q7JYRzd71FXtQJGRMcTXU79WAkAtpsHylB0AcZITb4USYdq5r1lIEzbZTxRBjGsE TvtiQmjXWlElxIZ2e7jnSXLB6KMWGiispfDro2XjbGX51ttCDn+8cm39; Authentication-Results: sj-dkim-4; header.From=htrevino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 =20 Andy, We have implemented notifications based on earlier versions of the draft.=20 Hector =20 ----------- I would really like to know if anybody is implementing this draft and if so, whether the draft is complete enough to produce an implementation. If nobody is implementing, then that is a warning sign in itself. Andy >=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 Apr 06 13:03:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZrqm-0004vq-BQ for netconf-archive@lists.ietf.org; Fri, 06 Apr 2007 13:03:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZrqk-0001bY-6O for netconf-archive@lists.ietf.org; Fri, 06 Apr 2007 13:03:48 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZriM-000GXa-2v for netconf-data@psg.com; Fri, 06 Apr 2007 16:55:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZriG-000GVi-PZ for netconf@ops.ietf.org; Fri, 06 Apr 2007 16:55:03 +0000 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l36Gt0Bk029977 for ; Fri, 6 Apr 2007 12:55:00 -0400 Received: (qmail 22461 invoked by uid 78); 6 Apr 2007 16:54:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 6 Apr 2007 16:54:59 -0000 Message-ID: <46167B45.80603@andybierman.com> Date: Fri, 06 Apr 2007 09:54:29 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Netconf (E-mail)" CC: NETCONF Goes On Subject: syslog content for NETCONF stream Content-Type: multipart/mixed; boundary="------------080903000504050409060704" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3595cdc4facf5cd9f085f547e103d0ed This is a multi-part message in MIME format. --------------080903000504050409060704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I translated the syslog message format as defined in draft-ietf-syslog-protocol-19.txt into XML encoding for better subtree and Xpath filtering, as well as a TEXT encoding. I doubt we can standardize any content given the level of disagreement over every little detail. But we still need to keep throwing darts at data models until there is more agreement. Simon asked an important question at the last IETF meeting: "What do you think the NETCONF data model should look like"? Debating the finer points of data modeling language design is a nice academic exercise. Debating what the XML on the wire looks like is much more important right now. I am including the XSD and the NCX source file. I hope the documentation is readable in the module header. This is an attempt at a direct translation of syslog-19 message format. If there is any interest, I will write up an I-D. Andy --------------080903000504050409060704 Content-Type: text/xml; name="syslog.xsd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="syslog.xsd" Converted from NCX module by ncxdump v0.2 Module: syslog Owner: ietf Application: syslog Version: 1 Copyright (C) Andy Bierman (2007). All Rights Reserved. Contact Info: Translated by Andy Bierman. Send comments to ietf@andybierman.com. Description: Syslog Message Structure Translated from draft-ietf-syslog-protocol-19.txt Defines XML or TEXT encoding formats for translation of syslog messages into NETCONF Notifications Note: In all examples the double-quotes have been changed to single quotes for NCX description string syntax compliance. The content of the <notification> element is either a <syslog> element of type 'SyslogTextMessage' or an <xsyslog> element of type 'SyslogXmlMessage'. Example Syslog encoding from [syslog] page 22, example 3: <165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@0 iut='3'; eventSource= 'Application' eventID='1011'] BOMAn application event log entry... NETCONF XML Encoding: <notification xmlns='netconf-notification'> <xsyslog xmlns='http://netconfcentral.org/ietf/syslog'> <pri>165</pri> <version>1</version> <timestamp>2003-10-11T22:14:15.003Z</timestamp> <hostname>mymachine.example.com</hostname> <appname>evntslog</appname> <procid>-</procid> <msgid>ID47</msgid> <sdparams> <sdparam sd-id='exampleSDID@0'> <iut>3</iut> <eventSource>Application</eventSource> <eventID>1011</eventID> </sdparam> </sdparams> <msg>An application event log entry...</msg> </xsyslog> </notification> NETCONF Text Encoding: Note that PRI field MUST NOT be enclosed in angle brackets They must be omitted instead! <notification xmlns='netconf-notification'> <syslog xmlns='http://netconfcentral.org/ietf/syslog'> 165 1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@0 iut='3' eventSource= 'Application' eventID='1011'] BOMAn application event log entry... </syslog> </notification> Revision History: Revision: 1 Initial version. Structured Data Name or ID Structured Data Name or ID PRI field from [syslog] 6.2.1: Represents both the Facility and Severity. The Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for '0') through %d57 (for '9'). Facility and Severity values are not normative but often used. They are described in the following tables for purely informational purposes. Numerical Facility Code 0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages 5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon 10 security/authorization messages 11 FTP daemon 12 NTP subsystem 13 log audit 14 log alert 15 clock daemon (note 2) 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7) Table 1. syslog Message Facilities Each message Priority also has a decimal Severity level indicator. These are described in the following table along with their numerical values. Numerical Severity Code 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages Table 2. syslog Message Severities The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a 'local use 4' message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively. Leading '0's MUST NOT be used. The VERSION field denotes the version of the syslog protocol specification. The version number MUST be incremented for any new syslog protocol specification that changes any part of the HEADER format. Changes include the addition or removal of fields, or a change of syntax or semantics of existing fields. This document uses a VERSION value of '1'. The VERSION values are IANA-assigned (Section 9.1) via the Standards Action method as described in RFC 2434 [8]. The TIMESTAMP field is a formalized timestamp derived from RFC 3339 [7]. Whereas RFC 3339 [7] makes allowances for multiple syntaxes, this document imposes further restrictions. The TIMESTAMP value MUST follow these restrictions: o The 'T' and 'Z' characters in this syntax MUST be upper case. o Usage of the 'T' character is REQUIRED. o Leap seconds MUST NOT be used. The sender SHOULD include TIME-SECFRAC if its clock accuracy and performance permit. The 'timeQuality' SD-ID described in Section 7.1 allows the sender to specify accuracy and trustworthiness of the timestamp. A syslog sender incapable of obtaining system time MUST use the NILVALUE as TIMESTAMP. The HOSTNAME field identifies the machine that originally sent the syslog message. The HOSTNAME field SHOULD contain the host name and the domain name of the originator in the format specified in STD 13 [2]. This format is called a Fully Qualified Domain Name (FQDN) in this document. In practice, not all senders are able to provide a FQDN. As such, other values MAY also be present in HOSTNAME. This document makes provisions for using other values in such situations. A sender SHOULD provide the most specific available value first. The order of preference for the contents of the HOSTNAME field is as follows: 1. FQDN 2. Static IP address 3. hostname 4. Dynamic IP address 5. the NILVALUE If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 [3]. If an IPv6 address is used, a valid textual representation as described in RFC 4291 [9], Section 2.2, MUST be used. Senders SHOULD consistently use the same value in the HOSTNAME field for as long as possible. If the sender uses IP addresses inside hostname, the following rules apply: If the sender is multihomed, this value SHOULD be one of its actual IP addresses. If a sender is running on a machine that has both statically and dynamically assigned addresses, then that value SHOULD be from the statically assigned addresses. As an alternative, the sender MAY use the IP address of the interface that is used to send the message. The NILVALUE SHOULD only be used when the sender has no way to obtain its real hostname. This situation is considered highly unlikely. The APP-NAME field SHOULD identify the device or application that generated the message. It is a string without further semantics. It is intended for filtering messages on the receiver. The NILVALUE MAY be used when the sender has no idea of its APP-NAME or cannot provide that information. It may be that a device may not be able to provide that information either because of a local policy decision, or because the information is not available, or not applicable, on the device. This field MAY be operator-assigned. The PROCID field SHOULD be used to provide the sender's process name or process ID. The field does not have any specific syntax. The NILVALUE MAY be used when the sender can not obtain its PROCID or cannot provide it. PROCID is primarily meaningful for analysis tools. Properly used, it can enable log analyzers to detect which messages were generated by the same sender process. For example, on a UNIX system the syslog daemon (syslogd) might emit messages to the log. All messages logged by the same syslogd process will bear the same PROCID. When the syslog sender is restarted, the PROCID value MAY change. That may enable the analysis script to detect the syslogd restart. This field MAY be operator-assigned. Some non-normative additional information about PROCID values can be found in Appendix A.8. The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID 'TCPIN' for incoming TCP traffic and the MSGID 'TCPOUT' for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on the receiver. The NILVALUE SHOULD be used when the sender does not intend to provide a real MSGID. This field MAY be operator-assigned. NOT REALLY USED!!! Represents one SD-PARAM entry Represents one SD-PARAM entry Represents container of SD-PARAM entries The MSG section as defined in [syslog] sec. 6.4 The top-level Syslog XML Message structure. The header contents are placed at the same nest level as the other fields in order to simplify encoding and permit NETCONF subtree filtering to work properly The top-level Syslog TEXT Message structure. --------------080903000504050409060704 Content-Type: text/plain; name="syslog.ncx" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="syslog.ncx" ncx-module syslog { header { description "Syslog Message Structure Translated from draft-ietf-syslog-protocol-19.txt Defines XML or TEXT encoding formats for translation of syslog messages into NETCONF Notifications Note: In all examples the double-quotes have been changed to single quotes for NCX description string syntax compliance. The content of the element is either a element of type 'SyslogTextMessage' or an element of type 'SyslogXmlMessage'. Example Syslog encoding from [syslog] page 22, example 3: <165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@0 iut='3'; eventSource= 'Application' eventID='1011'] BOMAn application event log entry... NETCONF XML Encoding: 165 1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 3 Application 1011 An application event log entry... NETCONF Text Encoding: Note that PRI field MUST NOT be enclosed in angle brackets They must be omitted instead! 165 1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@0 iut='3' eventSource= 'Application' eventID='1011'] BOMAn application event log entry... "; version 1; owner ietf; application syslog; copyright "Copyright (C) Andy Bierman (2007). All Rights Reserved."; contact-info "Translated by Andy Bierman. Send comments to ietf@andybierman.com."; last-update "2007-04-05"; revision-history { 1 "Initial version."; } } imports { import xsd; } definitions { type UsAsciiString { description "Structured Data Name or ID"; syntax { string pattern = "[!-~]*"; } } type SDName { description "Structured Data Name or ID"; syntax { UsAsciiString (1..32); } } type SyslogPriority { description "PRI field from [syslog] 6.2.1: Represents both the Facility and Severity. The Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for '0') through %d57 (for '9'). Facility and Severity values are not normative but often used. They are described in the following tables for purely informational purposes. Numerical Facility Code 0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages 5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon 10 security/authorization messages 11 FTP daemon 12 NTP subsystem 13 log audit 14 log alert 15 clock daemon (note 2) 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7) Table 1. syslog Message Facilities Each message Priority also has a decimal Severity level indicator. These are described in the following table along with their numerical values. Numerical Severity Code 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages Table 2. syslog Message Severities The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a 'local use 4' message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively. Leading '0's MUST NOT be used."; syntax { string pattern = "[0-9]{1,3}"; # range 0 .. 191 } } type SyslogVersion { description "The VERSION field denotes the version of the syslog protocol specification. The version number MUST be incremented for any new syslog protocol specification that changes any part of the HEADER format. Changes include the addition or removal of fields, or a change of syntax or semantics of existing fields. This document uses a VERSION value of '1'. The VERSION values are IANA-assigned (Section 9.1) via the Standards Action method as described in RFC 2434 [8]."; syntax { string pattern = "([1-9])([0-9]{0,2})"; } } type SyslogTimestamp { description "The TIMESTAMP field is a formalized timestamp derived from RFC 3339 [7]. Whereas RFC 3339 [7] makes allowances for multiple syntaxes, this document imposes further restrictions. The TIMESTAMP value MUST follow these restrictions: o The 'T' and 'Z' characters in this syntax MUST be upper case. o Usage of the 'T' character is REQUIRED. o Leap seconds MUST NOT be used. The sender SHOULD include TIME-SECFRAC if its clock accuracy and performance permit. The 'timeQuality' SD-ID described in Section 7.1 allows the sender to specify accuracy and trustworthiness of the timestamp. A syslog sender incapable of obtaining system time MUST use the NILVALUE as TIMESTAMP."; syntax { dateTime; } } type SyslogHostname { description "The HOSTNAME field identifies the machine that originally sent the syslog message. The HOSTNAME field SHOULD contain the host name and the domain name of the originator in the format specified in STD 13 [2]. This format is called a Fully Qualified Domain Name (FQDN) in this document. In practice, not all senders are able to provide a FQDN. As such, other values MAY also be present in HOSTNAME. This document makes provisions for using other values in such situations. A sender SHOULD provide the most specific available value first. The order of preference for the contents of the HOSTNAME field is as follows: 1. FQDN 2. Static IP address 3. hostname 4. Dynamic IP address 5. the NILVALUE If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 [3]. If an IPv6 address is used, a valid textual representation as described in RFC 4291 [9], Section 2.2, MUST be used. Senders SHOULD consistently use the same value in the HOSTNAME field for as long as possible. If the sender uses IP addresses inside hostname, the following rules apply: If the sender is multihomed, this value SHOULD be one of its actual IP addresses. If a sender is running on a machine that has both statically and dynamically assigned addresses, then that value SHOULD be from the statically assigned addresses. As an alternative, the sender MAY use the IP address of the interface that is used to send the message. The NILVALUE SHOULD only be used when the sender has no way to obtain its real hostname. This situation is considered highly unlikely."; syntax { UsAsciiString (1..255); } } type SyslogAppname { description "The APP-NAME field SHOULD identify the device or application that generated the message. It is a string without further semantics. It is intended for filtering messages on the receiver. The NILVALUE MAY be used when the sender has no idea of its APP-NAME or cannot provide that information. It may be that a device may not be able to provide that information either because of a local policy decision, or because the information is not available, or not applicable, on the device. This field MAY be operator-assigned."; syntax { UsAsciiString (1..48); } } type SyslogProcid { description "The PROCID field SHOULD be used to provide the sender's process name or process ID. The field does not have any specific syntax. The NILVALUE MAY be used when the sender can not obtain its PROCID or cannot provide it. PROCID is primarily meaningful for analysis tools. Properly used, it can enable log analyzers to detect which messages were generated by the same sender process. For example, on a UNIX system the syslog daemon (syslogd) might emit messages to the log. All messages logged by the same syslogd process will bear the same PROCID. When the syslog sender is restarted, the PROCID value MAY change. That may enable the analysis script to detect the syslogd restart. This field MAY be operator-assigned. Some non-normative additional information about PROCID values can be found in Appendix A.8."; syntax { UsAsciiString (1..12); } } type SyslogMsgid { description "The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID 'TCPIN' for incoming TCP traffic and the MSGID 'TCPOUT' for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on the receiver. The NILVALUE SHOULD be used when the sender does not intend to provide a real MSGID. This field MAY be operator-assigned."; syntax { UsAsciiString (1..32); } } type SyslogParam { description "NOT REALLY USED!!! Represents one SD-PARAM entry"; syntax { string; } } type SyslogParamSet { description "Represents one SD-PARAM entry"; syntax { any; } # really replacement of the abstract 'param-name' # struct { # SyslogParam param-name+; # } metadata { SDName sd-id; } } type SyslogParams { description "Represents container of SD-PARAM entries"; syntax { struct { SyslogParamSet sdparam+; } } } type SyslogMsgData { description "The MSG section as defined in [syslog] sec. 6.4"; syntax { string; } } type SyslogXmlMessage { description "The top-level Syslog XML Message structure. The header contents are placed at the same nest level as the other fields in order to simplify encoding and permit NETCONF subtree filtering to work properly"; syntax { struct { SyslogPriority pri; SyslogVersion version; SyslogTimestamp timestamp; SyslogHostname hostname; SyslogAppname appname; SyslogProcid procid; SyslogMsgid msgid; SyslogParams sdparams?; SyslogMsgData msg?; } } } type SyslogTextMessage { description "The top-level Syslog TEXT Message structure."; syntax { string; } } } } --------------080903000504050409060704-- -- 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 Apr 06 13:52:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZsby-0002G4-5C for netconf-archive@lists.ietf.org; Fri, 06 Apr 2007 13:52:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZsbw-0003tg-Rm for netconf-archive@lists.ietf.org; Fri, 06 Apr 2007 13:52:34 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZsYI-000KE3-NH for netconf-data@psg.com; Fri, 06 Apr 2007 17:48:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.56] (helo=omr6.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HZsYG-000KDm-3K for netconf@ops.ietf.org; Fri, 06 Apr 2007 17:48:45 +0000 Received: from mail.networksolutionsemail.com (ns-omr6.mgt.netsol.com [10.49.6.69]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l36Hmhmb028779 for ; Fri, 6 Apr 2007 13:48:43 -0400 Received: (qmail 31983 invoked by uid 78); 6 Apr 2007 17:48:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr6.lb.hosting.dc2.netsol.com with SMTP; 6 Apr 2007 17:48:43 -0000 Message-ID: <461687DD.9040304@andybierman.com> Date: Fri, 06 Apr 2007 10:48:13 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: startup errors notification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi, Let's say an agent implementation saves any error and warning messages that were generated when the config was loaded into the config at boot-time. The default mode is to continue (if possible) instead of halting. There is no notification to package these errors so they can be delivered in a notification. Therefore, I'm making one up on the fly, hope my XSD is right :-) XML: ... ... XSD: 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 sgddfhtt2353@yahoo.co.uk Sun Apr 08 07:56:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaW03-0002eZ-16 for NETCONF-ARCHIVE@LISTS.IETF.ORG; Sun, 08 Apr 2007 07:56:03 -0400 Received: from [221.206.55.234] (helo=so-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaW00-00048U-FW for NETCONF-ARCHIVE@LISTS.IETF.ORG; Sun, 08 Apr 2007 07:56:03 -0400 Received: from jrfc9 (unknown [66.92.179.189]) by smtp98 (Coremail) with SMTP id 7LVtFd7oDLKacBq7.1 for ; Sun, 08 Apr 2007 19:55:58 +0800 (CST) X-Originating-IP: [66.92.179.189] Subject: =?iso-2022-jp?B?GyRCJCokOCRjJF4kNyReJDkhKhsoQg==?= From: =?shift-jis?B?bWlrYQ==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0254_01C776E5.81DD49A0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d This is a multi-part message in MIME format. ------=_NextPart_000_0254_01C776E5.81DD49A0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B=P2q$$$J$I$K:$$C$F$^$;$s$+!):#;~=P2q$$7O%5%$%H$@$HAj
=1B$B=3DP2q$$$J$I$K:$$C$F$^$;$s$+!):#;~=3DP2q$$7O%5%$%H$@= $HAj
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
=1B$B6=3DL#$,$J$$J}$O!"$*
saki_honda19@yahoo.fr

 
------=_NextPart_000_0254_01C776E5.81DD49A0-- From owner-netconf@ops.ietf.org Mon Apr 09 05:53:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaqYx-0005Lg-NM for netconf-archive@lists.ietf.org; Mon, 09 Apr 2007 05:53:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaqYw-0002Ne-CT for netconf-archive@lists.ietf.org; Mon, 09 Apr 2007 05:53:27 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HaqRe-000IVP-Ir for netconf-data@psg.com; Mon, 09 Apr 2007 09:45:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HaqRc-000IV0-HR for netconf@ops.ietf.org; Mon, 09 Apr 2007 09:45:53 +0000 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 09 Apr 2007 05:45:50 -0400 X-IronPort-AV: i="4.14,387,1170651600"; d="scan'208"; a="1317124:sNHT7258932" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NGO] syslog content for NETCONF stream Date: Mon, 9 Apr 2007 12:45:12 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NGO] syslog content for NETCONF stream Thread-Index: Acd4bGkLlyePcOGQTsC99G0aMRE13wCHs4rA References: <46167B45.80603@andybierman.com> From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , "Netconf \(E-mail\)" Cc: "NETCONF Goes On" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 I am quite sure that there is enough interest to write an I-D. In the current phase of discussions and especially until a broader consensus is reached on the data modeling language it helps to document the contributions. It may also happen that in a first phase we shall rather publish Informational or Experimental RFC documents rather than going directly to standards track. In any case, I-Ds are good.=20 Dan =20 =20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Friday, April 06, 2007 7:54 PM > To: Netconf (E-mail) > Cc: NETCONF Goes On > Subject: [NGO] syslog content for NETCONF stream >=20 > Hi, >=20 > I translated the syslog message format as defined in=20 > draft-ietf-syslog-protocol-19.txt into XML encoding for=20 > better subtree and Xpath filtering, as well as a TEXT encoding. >=20 > I doubt we can standardize any content given the level of=20 > disagreement over every little detail. > But we still need to keep throwing darts at data models until=20 > there is more agreement. >=20 > Simon asked an important question at the last IETF meeting: > "What do you think the NETCONF data model should look like"? > Debating the finer points of data modeling language design is=20 > a nice academic exercise. Debating what the XML on the wire=20 > looks like is much more important right now. >=20 > I am including the XSD and the NCX source file. > I hope the documentation is readable in the module header. > This is an attempt at a direct translation of syslog-19=20 > message format. > If there is any interest, I will write up an I-D. >=20 > Andy >=20 >=20 >=20 >=20 >=20 -- 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 Apr 09 10:11:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HauaJ-0001kI-Ji for netconf-archive@lists.ietf.org; Mon, 09 Apr 2007 10:11:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HauaI-0005tN-2E for netconf-archive@lists.ietf.org; Mon, 09 Apr 2007 10:11:07 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HauU9-0009Q5-BH for netconf-data@psg.com; Mon, 09 Apr 2007 14:04:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from [205.178.146.53] (helo=omr3.networksolutionsemail.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HauU6-0009Pg-02 for netconf@ops.ietf.org; Mon, 09 Apr 2007 14:04:43 +0000 Received: from mail.networksolutionsemail.com (ns-omr3.mgt.netsolmail.com [10.49.6.66]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id l39E4f6t030800 for ; Mon, 9 Apr 2007 10:04:41 -0400 Received: (qmail 28930 invoked by uid 78); 9 Apr 2007 14:04:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@andybierman.com@75.83.33.198) by ns-omr3.lb.hosting.dc2.netsol.com with SMTP; 9 Apr 2007 14:04:41 -0000 Message-ID: <461A47DA.5000003@andybierman.com> Date: Mon, 09 Apr 2007 07:04:10 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" CC: "Netconf (E-mail)" , NETCONF Goes On Subject: Re: [NGO] syslog content for NETCONF stream References: <46167B45.80603@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Romascanu, Dan (Dan) wrote: > I am quite sure that there is enough interest to write an I-D. In the > current phase of discussions and especially until a broader consensus is > reached on the data modeling language it helps to document the > contributions. It may also happen that in a first phase we shall rather > publish Informational or Experimental RFC documents rather than going > directly to standards track. In any case, I-Ds are good. > I should be clear that I would not be including the NCX module in the draft. I just included it because the header is easier to read without character entities in the examples. The real XSD would have a substititionGroup defined for the sdparam element, instead of type 'any'. I think we would have better luck discussing data models instead of data modeling languages. If you don't know what the XML on the wire should look like, then you don't need a data modeling language yet. A DML only helps if you already understand the data model you are designing. > Dan Andy > > > > > >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] >> Sent: Friday, April 06, 2007 7:54 PM >> To: Netconf (E-mail) >> Cc: NETCONF Goes On >> Subject: [NGO] syslog content for NETCONF stream >> >> Hi, >> >> I translated the syslog message format as defined in >> draft-ietf-syslog-protocol-19.txt into XML encoding for >> better subtree and Xpath filtering, as well as a TEXT encoding. >> >> I doubt we can standardize any content given the level of >> disagreement over every little detail. >> But we still need to keep throwing darts at data models until >> there is more agreement. >> >> Simon asked an important question at the last IETF meeting: >> "What do you think the NETCONF data model should look like"? >> Debating the finer points of data modeling language design is >> a nice academic exercise. Debating what the XML on the wire >> looks like is much more important right now. >> >> I am including the XSD and the NCX source file. >> I hope the documentation is readable in the module header. >> This is an attempt at a direct translation of syslog-19 >> message format. >> If there is any interest, I will write up an I-D. >> >> Andy >> >> >> >> >> > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- 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 Apr 10 11:05:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHur-0002S4-68 for netconf-archive@lists.ietf.org; Tue, 10 Apr 2007 11:05:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbHuo-0005ak-L7 for netconf-archive@lists.ietf.org; Tue, 10 Apr 2007 11:05:53 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HbHjG-0008R3-2r for netconf-data@psg.com; Tue, 10 Apr 2007 14:53:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,HTML_30_40, HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.7 Received: from [64.104.129.195] (helo=ind-iport-1.cisco.com) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HarYT-000Mwv-VA for netconf@ops.ietf.org; Mon, 09 Apr 2007 10:57:03 +0000 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 10 Apr 2007 05:16:14 +0530 X-IronPort-AV: i="4.14,387,1170613800"; d="scan'208,217"; a="78045783:sNHT1342765166" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l39AuXQZ002977; Mon, 9 Apr 2007 18:56:33 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l39AuRjO013261; Mon, 9 Apr 2007 10:56:31 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 18:56:26 +0800 Received: from syd-rpruss-vpn5.cisco.com ([10.67.195.22]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 18:56:24 +0800 Message-ID: <461A1BD3.6060203@cisco.com> Date: Mon, 09 Apr 2007 20:56:19 +1000 From: Richard Pruss Reply-To: ric@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Andy Bierman CC: "Netconf (E-mail)" , NETCONF Goes On Subject: Re: [NGO] syslog content for NETCONF stream References: <46167B45.80603@andybierman.com> In-Reply-To: <46167B45.80603@andybierman.com> Content-Type: multipart/alternative; boundary="------------020708010609070107080700" X-OriginalArrivalTime: 09 Apr 2007 10:56:25.0482 (UTC) FILETIME=[B7BF1EA0:01C77A95] Authentication-Results: hkg-dkim-1; header.From=ric@cisco.com; dkim=neutral ( ssp=~; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 This is a multi-part message in MIME format. --------------020708010609070107080700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yea I think some sub-areas for data models is a possible approach. I must agree with the underlying sentiment of your comment. I guess I might say it straight from my perspective. We attended this Netconf session to see if we should think about contributing the current data model work from various session based and config based efforts in our OS's but given that the working group was a two party punching match and the side group (I did not attend) went off on inventing some replacement data modelling langauge because of some implementation choices of Netconf filtering.... It does not look like we can have the discussions here. -Ric Andy Bierman wrote: > Hi, > > I translated the syslog message format as defined > in draft-ietf-syslog-protocol-19.txt into XML encoding > for better subtree and Xpath filtering, as well as a TEXT encoding. > > I doubt we can standardize any content given the > level of disagreement over every little detail. > But we still need to keep throwing darts at data models > until there is more agreement. > > Simon asked an important question at the last IETF meeting: > "What do you think the NETCONF data model should look like"? > Debating the finer points of data modeling language design is > a nice academic exercise. Debating what the XML on the wire > looks like is much more important right now. > > I am including the XSD and the NCX source file. > I hope the documentation is readable in the module header. > This is an attempt at a direct translation of syslog-19 message format. > If there is any interest, I will write up an I-D. > > Andy > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > NGO mailing list > NGO@ietf.org > https://www1.ietf.org/mailman/listinfo/ngo --------------020708010609070107080700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yea I think some sub-areas for data models is a possible approach. 

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

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

-Ric

Andy Bierman wrote:
Hi,

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

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

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

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

Andy 





_______________________________________________
NGO mailing list
NGO@ietf.org
https://www1.ietf.org/mailman/listinfo/ngo
--------------020708010609070107080700-- -- 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 Apr 11 15:51:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbirE-0001rt-5T for netconf-archive@lists.ietf.org; Wed, 11 Apr 2007 15:51:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbirD-0002pX-B0 for netconf-archive@lists.ietf.org; Wed, 11 Apr 2007 15:51:56 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HbilZ-000G60-SD for netconf-data@psg.com; Wed, 11 Apr 2007 19:46:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HbilN-000G51-2m for netconf@ops.ietf.org; Wed, 11 Apr 2007 19:45:59 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3BJjlh21924 for ; Wed, 11 Apr 2007 19:45:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Netconf Notifications WC LC: Issues & Proposed Resolutions - Part 1 Date: Wed, 11 Apr 2007 15:45:45 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40E6AF21A@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notifications WC LC: Issues & Proposed Resolutions - Part 1 Thread-Index: Acd8PhwFkZVxZFKWREWj9itd5sP28wAC8njw From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 hi Here are proposed resolutions to the first set of issues on the working group last call list. More to come. 1. Section 1.2 (Source Ken) The spec says that a capability can be used to announce that the netconf server can process rpcs while sending notifications. I think that it very important that the device NOT process any new requests while sending notifications as there is no per-notification subscription-identifier - thus it is not impossible for the client to differentiate which subscription its receiving a notification for Proposed Resolution: If the client is unable to support any optional features that are advertised, it does not need to use them. Add text at the end of the third paragraph that says "The behaviour of such a capability is outside the scope of this document. =20 2. Section 2.1.1 (Source Ken) The "negative response" section should clearly indicate what happens when either the start-time is set but the stream doesn't support replay or when the stop-time is set without having the start-time set - both of these conditions are marked as illegal by the spec without any clear statement about what will happen (i.e. what rpc-error will be returned) Proposed Resolution:=20 Add the following text to Section 2.1.1 under Negative Response "If a stop-time is specified in a request without having specified a start-time the following error is returned Tag: bad-element Error-type: protocol Severity: error Error-info: =20 Description: An element value is not correct; e.g., wrong type, out of range, pattern mismatch. If the optional replay feature is requested but it is not supported by the NETCONF server, the following error is returned: Tag: operation-failed Error-type: protocol Severity: error Error-info: none Description: Request could not be completed because the requested operation failed for some reason not covered by any other error condition." Note these are currently defined in section 6.3, but with the merge of section 6 to this one (and section 3), this becomes the correct place to update them. 3. Section 3.3 (Source Ken) It doesn't make sense for the namedProfile to include the "lastModified" element - as it is not usable without any API to discover which subscriptions are active and when they began... Proposed resolution: You can query independently for subscription information. Propose no change.=20 4. Section 3.4 (Source Ken) It is very unfortunate that only allows at most one stream at a time (i.e. its not maxOccurs=3D0) - as the only alternative is for the client to open a separate netconf session for each stream, but this is both awkward and not efficient for either the client or the server. I fear that, unless this is fixed, implementations will only support the required "netconf" stream and use subscription filters to select what to receive, effectively rendering the "stream" concept useless Proposed Resolution: While I agree this is unfortunate, it does reflect working group consensus. Propose no change. 5. Section 5.2 (Source Ken) The spec does not indicate if XPATH filters must be supported - this would be surprising to me as the base netconf protocol lets XPATH be an optional capability. Maybe :notifications can use XPATH filters if and only if the :xpath capability is advertised? Proposed Resolution: Add text to section 3.2.5.2.1 which says "XPATH support for the Notification capability is advertised as part of the normal XPATH capability advertisement. If XPATH support is advertised via the XPATH capability then XPATH is supported for notification filtering and if this capability is not advertised, then XPATH is not supported for notification filtering." 6. Section 6.3 (Source Ken) In addition to the special replayCompleteNotification notification, it would be nice for there to also be a special eventsDroppedNotification (or something) that can be used whenever a device drops an event (i.e. buffer full, etc.) Proposed Resolution: Given that events are often dropped due to resource constraints, this does not seem like a good plan. Propose no change. 7. pg 3, ToC: Suggest title change of sec. 3.4 'Subscriptions not Configuration Data' (Source Andy) Proposed Resolution: Replace title section of 3.4 of 'Subscriptions not Configuration Data' with 'Subscriptions Data' 8. pg 3, ToC: Sec. 5 title : Capitalize examples (Source Andy) Proposed Resolution: Substitute title of section 5 from 'Filtering examples' to "Filtering Examples' 9. ToC: No entry for IANA Considerations (no section either) (Source Andy) Proposed Resolution: Add an 'IANA Considerations' section to request allocation of namespaces for the Schemas.=20 "This document registers two URIs for the NETCONF XML namespace in the IETF XML registry [7]. Following the format in RFC 3688, IANA has made the following registration. URI: urn:ietf:params:netconf:capability:notification:1.0 =20 URI: urn:ietf:params:xml:ns:netmod:notification Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace." Update various references to content namespace to use this tag. 10. pg 4, middle of page: Move 'Figure 1' above the para, and directly below the figure (Source Andy) Proposed resolution, in section 1, move the label 'Figure 1' to be just under the picture. 11. p4 4. sec. 1.1 Terms Managed Object is unclear, not used anywhere, should be removed (Source Andy) Proposed Resolution: In section 1.2, delete the term Managed Object. 12. p5 Terms Operation: 2nd sentence is not true. Term used as stated only in sentence 1. (Source Andy)=20 Proposed Resolution: As this was added at someone's request. I'd like to verify there is consensus to remove it. 13. p5 sec1.2: Put first para in Terms section as 'Event' (Source Andy) Proposed Resolution: Move definition of event in first paragraph section 1.2 to section 1.1 as a definition. 14. pg 7, bottom: missing period after parameter (Source Andy) Proposed Resolution: In section 2.1.1, in the named profile text, complete the final sentence with a period. 15. pg 7 - 8: General comments on create-subscription (Source Andy) a. need to specify conceptual data types for all parameters in this section b. need to show usage examples in this section c. need to combine entire section 6 (Replay) into this section since it is confusing to introduce just the parameters but not the feature d. once again, we are creating parameter dependencies that XSD cannot represent. (Just as happy to rant against XSD than change things though ;-) Proposed resolution: In section 2.1.1, add the following usage example Also move section 6 into section 2.1.1 as makes sense and the rest into section 3 (supporting concepts). While we can represent more in XSD then we are, I'm not exactly sure what the specific issue is. Propose no change. 16. pg 8, Start Time and Stop Time comments (Source Andy) a. What if a legal start-time (or start/stop pair) specifies some time in the future? b. What if the timezone is given and it is not the same as the agent's timezone? c. What if a time change (e.g., daylight savings time) happens? d. Explain how both parameters handle forward and backward boundary conditions Proposed Resolution: According to the discussion in the working group meeting, future start times are now allowed. Add text to section 3 (in the text merged from section 6) that says "It is valid to specify start and stop times that are later than the current time." For the other points. I'm not sure what we want to say about these. I think it is up to the system to support time properly. I'd suggest either no change or a statement to that effect.=20 17. pg 8, sec 2.1.1, Negative Response (Source Andy)=20 a. This section is correct, but inconsistent with the text in sec. 6.1, para 3. b. There is no mention of a 'warning-and-continue' mode of operation here. (More reason why sec 6. create-sub. details needs to be integrated into this section.) Proposed Resolution: I think we briefly discussed this in Prague, but I don't remember the consensus, if any. An edit is definitely required to make these consistent with each other. The reasons why warn and continue is required it to allow the client to create a replay request without actually needing to know the exact time of the earliest available log. Propose adding text to section 2.1.1 to reflect the warn and continue method discussed in section 6. Create a new section between "Positive Response" and "Negative Response" called "Warn and Continue" with the following text "If the NETCONF server can satisfy the request, but the start time specified is too early then the element will be included a warning message, but the client can expect to be along the Netconf session. " 18. pg 9, sec 2.3, Terminating the Subscription (Source Andy) a. Does the have to come from another session? (I think so) b. IMO, since we do not have an endless RPC reply model, it is not a burden to the agent to accept a from the session getting notifications=20 c. Does sentence 2 mean after the last replayed notification that meets the stop time criteria, the session is terminated? last sentence, capitalize Netconf to NETCONF Proposed Resolution: If you don't have an interactive session does have to come from another session, but I don't think we need to discuss this. If we are not processing commands then we are not processing commands. It seems to add unnecessary complexity to say we are not processing commands, except ... Propose no change. Note that The session is not terminated when the subscription is done. The text already says "In this case, the Netconf session will still be an active session". Propose no change.=20 =20 In section 2.3, last sentence, replace Netconf with NETCONF. 19. pg 10, sec 3.1.2, cap. exchange example (Source Andy) IMO, this section should be removed. Sec. 3.1.1 defines the capability identifier. Just say that RFC 4741 defines the capability exchange. Proposed resolution: I think the example adds value. Propose no change. 20. pg 11, diagram (Source Andy) This is a good diagram but there should be text following it explaining all the boxes, why they are there, and where in this document the relevant definitions can be found Proposed Resolution: In section 3.2, add figure caption: Figure 2. Replace the second and third paragraph as indicated and add some new text. Replace: 'System components generate event notifications which are passed to a central component for classification and distribution. The central component inspects each event notification and matches the event notification against the set of stream definitions. When a match occurs, the event notification is considered to be a member of that event stream. An event notification may be part of multiple event streams. When a NETCONF client subscribes to a given event stream, user- defined filters, if applicable, are applied to the event stream and matching event notifications are forwarded to the NETCONF server for distribution to subscribed NETCONF clients.' with=20 "The diagram depicted in Figure 2 illustrates the notification flow and concepts identified in this document. The following is observed from the diagram below: =20 System components (c1..cn) generate event notifications which are passed to a central component for classification and distribution. The central component inspects each event notification and matches the event notification against the set of stream definitions. When a match occurs, the event notification is considered to be a member of that event stream (stream 1..stream n). An event notification may be part of multiple=20 event streams. When a NETCONF client subscribes to a given event stream, user- defined filters (filter - see filter in ), if applicable, are applied to the event stream and matching event notifications are forwarded to the NETCONF server for distribution to subscribed NETCONF clients. " Add new text following this as follows: "A Notification Logging Service (see replay under ) may also be available, in which case, the central component logs notifications. The NETCONF server may later retrieve logged notifications via the optional replay feature." 21. pg 11, 3.2.1-2, typos (Source Andy) a. s/via NETCONF protocol/via the NETCONF protocol/ b. missing period after last sentence c. s/i.e. the notification/i.e., the notification/ Proposed Resolution: In section 3.2.1 and section 3.2.2, perform the following edits a. s/via NETCONF protocol/via the NETCONF protocol/ b. Add missing period after last sentence c. s/i.e. the notification/i.e., the notification/ 22. pg 11, sec 3.2.3, Default Event Stream (Source Andy) a. Mentions the "NETCONF" notification event stream but this is not defined anywhere. b. Need to put this in the IANA considerations section that will be added. Proposed resolution: I don't understand why this is an IANA consideration. We agreed there would be a Netconf event stream which would contain Netconf content. What's the specific edit?=20 23. pg 12, typos (Source Andy) a. para 1, s/e.g. SNMP, syslog, etc./e.g., SNMP, syslog/ b. para 3, missing space after and before operation Proposed Resolution: make these changes in section 3.2.5.1 i. para 1, s/e.g. SNMP, syslog, etc./e.g., SNMP, syslog/ ii. para 3, add missing space after and before operation 24. pg 12, Name Retrieval comments (Source Andy) a. Need introduction and formal description of the data model for retrieving stream names.=20 b. Can we use just one namespace for all NETCONF data model objects, put the definition in IANA, and use it for notification data? c. agree with comment to change to for better consistency with rest of this doc, and RFC 4741. Proposed Resolution: Add the following text to the beginning of section 3.3: "This Schema is used to learn about the event streams supported on the system and the query and modify named profiles. It also contains the definition of the replayCompleteNotification, which is sent to indicate that an event replay has sent all applicable notifications." Merge the event replay complete notification into the other content Schema. As discussed in Prague, lower camel is consistently done for the data model versus the protocol. Propose no change. 25. pg 13, bad XML style (Source Andy) end tags on new line introduces significant whitespace into the element content Proposed Resolution: This isn't bad XML Style. It makes it more readable. Whitespace is free. Propose no changes. Sharon Chisholm Nortel Ottawa, Ontario Canada -- 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 satomi@yahoo.co.jp Wed Apr 11 19:33:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbmJn-0007Aq-SA for NETCONF-ARCHIVE@LISTS.IETF.ORG; Wed, 11 Apr 2007 19:33:39 -0400 Received: from [221.203.67.187] (helo=so-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbmJl-0005Qo-CA for NETCONF-ARCHIVE@LISTS.IETF.ORG; Wed, 11 Apr 2007 19:33:39 -0400 Received: from gdht6 (unknown [82.54.77.238]) by smtp43 (Coremail) with SMTP id UNRvpMAWKi6SSerV.1 for ; Sat, 12 Apr 2008 07:33:44 +0800 (CST) X-Originating-IP: [82.54.77.238] Subject: =?iso-2022-jp?B?GyRCJEgkSyQrJC83KyRqSlYkNxsoQg==?= From: =?shift-jis?B?eWF1a28=?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_039F_01C77B8C.0F6AE4D0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 This is a multi-part message in MIME format. ------=_NextPart_000_039F_01C77B8C.0F6AE4D0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit 1$B!!%a!<%k$9$k(B 2$B!!2q$&(B 3$B!!$d$k(B $B$3$l$@$1$G$9!#$-$l$$$4$H$O8@$$$^$;$s!#(B $B%;%U%l$H$$$&$b$N$O(B1$B!A(B3$B$N7+$jJV$7!#(B $B$O$8$a$OM}A[$NAj/6lO+$9$k$+$b$7$l$^$;$s$,!"(B 3$BF|0J>e$+$+$k$3$H$O$^$:L5$$$G$7$g$&!#(B $B8GDj$NAj!
1=1B$B!!%a!<%k$9$k=1B(B
2=1B$B!!2q$&=1B(B
3=1B$B!!$d$k=1B(= B

=1B$B$3$l$@$1$G$9!#$-$l$$$4$H$O8@$$$^$;$s!#=1B(B
=1B$B%;%U%l$= H$$$&$b$N$O=1B(B1=1B$B!A=1B(B3=1B$B$N7+$jJV$7!#=1B(B
=1B$B$O$8$a$OM}A[= $NAj/6lO+$9$k$+$b$7$l$^$;$s$,!"=1B(B
3=1B$BF|0J>e$+$+$k= $3$H$O$^$:L5$$$G$7$g$&!#=1B(B
=1B$B8GDj$NAj!=1B$B=3DP2q$$7O$G5a$a$F$k$N$O$=3D$&$$$&$3$H= $8$c$J$$$G$9$+!)=1B(B
=1B$B$`$7$m$=3D$&$G$J$1$l$P0UL#$,$J$$$s$G$9!#=1B= (B
=1B$B$=3D$s$J!VEv$?$jA0$N;v!W$r=1B(B
=1B$B;d$?$A$O!VEv$?$jA0$N;v= !W$@$H;W$o$;$^$9!#=1B(B
http://cb405.iptime.org/best/= ?fs28






 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 




=1B$Bhosono145yuko@yahoo.co.uk
 
------=_NextPart_000_039F_01C77B8C.0F6AE4D0-- From owner-netconf@ops.ietf.org Sat Apr 14 13:54:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcmSO-0005XC-NK for netconf-archive@lists.ietf.org; Sat, 14 Apr 2007 13:54:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcmSN-0000xS-0W for netconf-archive@lists.ietf.org; Sat, 14 Apr 2007 13:54:40 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HcmLu-000Lm0-QG for netconf-data@psg.com; Sat, 14 Apr 2007 17:47:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HcmLp-000LlF-T1 for netconf@ops.ietf.org; Sat, 14 Apr 2007 17:47:56 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l3EHlHm28475 for ; Sat, 14 Apr 2007 17:47:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Netconf Notifications WG LC: Issues & Proposed Resolutions - Part 2 Date: Sat, 14 Apr 2007 13:47:46 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40E7991EC@zcarhxm2.corp.nortel.com> In-Reply-To: <6E21698722408147BEA594E073E2B0AB039BA1E0@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notifications WG LC: Issues & Proposed Resolutions - Part 2 Thread-Index: Acd92yAlPoVzdXXSR/2TgU1R3SfS6wACLrwQAAgNHtAALjMOAA== References: <713043CE8B8E1348AF3C546DBE02C1B40E745D08@zcarhxm2.corp.nortel.com> <6E21698722408147BEA594E073E2B0AB039BA1E0@xmb-sjc-223.amer.cisco.com> From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Hi Here is the rest of the working group last call comments. I will also be posting resolution to the Phil's slightly late comments. Coming soon. 26. pg 13, sec 3.2.5.2, redundant section (Source Andy) =09 This section is confusing to read, and does not really add any value, since the previous section just defined event subscription. Proposed Resolution: It provides information about querying the subscription. Proposed no change. 27. pg 14-15, XSD comments (Source Andy) a. should define the new verbs to be in the NETCONF base namespace and use the capability to determine whether to use it (like all other No operations) b. do not need to import these 3 namespaces c. should define 1 namespace for data models related to the NETCONF protocol, not a separate namespace for every bit of monitoring data. d. do not need 'stream' parameter; it is already in the RPC e. do not need the read-only timestamp. This is just general metadata associated with the configuration database. We should have a general notification if this is so important. IMO, it is not important, and also a bad idea to copy this aspect of MIB design. f. can we use short prefixes, like 'nc' instead of 'netconf'? Proposed Resolution: One namespace for content and one for protocol operations. In section 3.3, delete "" since it is not being used. This stream here is not redundant with the one in the protocol. It is the list of streams available. It is the step before the create-subscription command. Propose no change. The lastModidifed field is useful and necessary to tell if there is a mismatch between the content of the named profile and what the subscription is using. Propose no change. Replacing the netconf prefix with nc would make things less readable with very little or no benefit. Propose no change. 28. pg 16, sec 3.4 (Source Andy) a. Not clear why this section is here. It is actually incorrect. b. If a proprietary configuration data model (or future standard) exists, then this section is wrong. Proposed Resolution: We agreed before the information is not persistent across reboot. So, this is correct, according to what the working group agreed to. Proposed no change (except for the section title change discussed in another issue). 29. pg 17, sec 3.5 (Source Andy) First sentence is wrong; multiple filters cannot be combined. Proposed resolution: In section 3.5, first paragraph replace "Note that when multiple filters are specified" with 'Note that when multiple filter elements are specified". Replace "If a filter is Specified" with "If a filter element is specified". In the second paragraph replace "Note that the order that filters are applied" with "Note that the order that filter elements are applied". 30. pg 17, 3.5.2 (Source Andy) Term 'just-in-time filtering' is used here without any explanation what it is, or why it matters in this document. Proposed resolution: In section 3.5.2, replace "just-in-time" with "inline". 31. pg 18, message flow diagram (Source Andy) Should mention (and show) that many rpc/rpc-reply sequences could occur before the create-subscription. In fact, text suggests use of get(event-streams) first. Proposed Resolution: add text in section 3.6 in the first paragraph before the picture: "It is possible that many rpc/rpc-reply sequences occur before the subscription is created or after a stopTime in a replay subscription, but this is not depicted in the figure." 32. pg 19, XSD comments (Source Andy) Apply same changes wrt/ namespaces, imports, and prefixes. Proposed Resolution: If we agreed there were no changes above, then there are not changes here. 33. pg 20, XSD typo (Source Andy) Indentation of is wrong Proposed Resolution: In section 4, indent the filter element in the choice tag to fix the indenting. 34. pg 22-26, sec. 6 (Source Andy) Move entire section to a non-normative appendix and state clearly that the data models shown are examples, not standards(bugs found by others in examples not confirmed) Proposed resolution: It is all clearly labeled as examples. Other RFCs have examples in the main body of the document. Don't see any reason to move it to an appendix. Propose no change.=20 The following changes need to be made to fix the bugs: In section 5.1, on page 24 replace " critical major minor " With " =20 fault critical fault major =20 fault minor " In section 5.2, replace " " With " " Also in section 5.2, replace " " With " " 35. 3pg 27, sec 6 Replay (Source Andy) Should move all details to sec 2.1.1 Proposed Resolution: This is a duplicate of issue 15. 37. pg 28, error-tags (Source Andy) a. We cannot update RFC 4741 to add redundant specialized error codes. b. We already have 'invalid-value'. IMO, these should not even be errors. c. If the supplied timestamps are well-formed, but produce no output, then this is an empty data set. Proposed Resolution: The changes introduced as a result of issue 2 should also cover this issue. 38. pg 28, error handling design (Source Andy) a. The manager and agent procedures can both be simplified here. b. If the parameters are well-formed, but produce no matches, then this is no different than if the filter removed everything and there was no output. In both cases, just sent the replay-complete notification right away, instead of any warnings or errors. c. If a stop-time is specified, then the normal termination procedure is followed after the replay-complete is sent.=20 Proposed resolution: Conditional on the introduction of a timestamp on the stream Schema to indicate earliest logged notification, I think the warn and continue behaviour can now be removed. For point c, this is what the draft currently says. Propose no change. 39. pg 29, XSD comments (Source Andy) a. do not need a special namespace for the replay-complete notification b. suggest simple name like 'replay-complete' instead of 'replayCompleteNotification'. This appears in instance documents c. eventClass element introduces data model details into this document that the WG has not agreed to d. eventClass is an empty element with no data type or content. Doubt that is what is intended. e. do not need statistics collection and reporting in this notification f. do not need a timeGenerated timestamp here. The manager's receive timestamp is good enough, considering that the content or time of this notification is irrelevant. The manager just needs a marker to signal the end of replay. (That was the functional requirement.) g. agree with Martin that a simple empty notification element called is sufficient: even if numberEventsReplayed was useful, it should be a bounded integer like 'unsignedInt' or 'unsignedLong', not integer. 2^^64 log entries is a large enough amount to cover most implementations ;-) Proposed Resolution: The namespace bit is a duplicate of (24). Generally in the document, rename replayCompleteNotification to replayComplete. Working group consensus in Prague was to not have any content. Will remove content from the replayComplete notification. 40. pg 30, Security Considerations (Source Andy) a. remove 'use of , only want to document the threats from this document, not RFC 4741. b. fully specify the exact security threat, exact parameter names, use cases, etc. c. fully specify which data model content is writable and identify any threats to services due to notification delivery on a NETCONF session. (Are there any? d. explain that the notification content is outside the scope of this document but care must be taken just as with SNMP Notifications e. explain how notifications are handled by the agent in the presence of access control. f. Is the entire notification dropped if only some of the included data is not allowed, or just the classified data removed from the notification? g. capitalize netconf to NETCONF in last sentence Proposed Resolution: In section 7, remove bullet " o use of " Add text to section 7 that says "If a user does not have permission to view content via other NETCONF operations it does not have permission to access that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. In section 7, capitalize netconf to NETCONF in last sentence. Request text from working group to cover other issues. 41. pg 30, missing IANA Considerations section (Source Andy) need to determine exact IANA requests and add them here Proposed Resolution: This is a addressed by resolutions to (9) and (22). 42. The example in section 2.1 have some redundant tags, such as , and . (Source Ma Yuzhi) Proposed Resolution: There are no examples in section 2.1, but we will check all examples before submitting. 43. Create more types within protocol XSD (Source Sharon) Proposed Resolution: In section 4, create types for stream and named-profile based on current definitions. 44. In 6.2, about the warning message, it says (Source Martin) Error-info: : Timestamp of earliest event available for replay This element (log-starttime) should be defined in the schema. Also, the short description could be clarified. What exactly does "available for replay" mean? Does it mean available using the filters and access rules currently in effect? I assume it does not, since if it did, the warning would be pretty useless - the same info will be included in the first event replayed. Proposed Resolution Add log start time as a field in the stream query Schema. We can then remove the warning. In section 3.3, within the definition of stream replace " " With " The start time of the log used to support the replay function. If replay is not supported, this will return the current time. "=20 Sharon Chisholm Nortel Ottawa, Ontario Canada -- 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 Apr 18 16:57:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHDP-00084T-WE for netconf-archive@lists.ietf.org; Wed, 18 Apr 2007 16:57:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHDO-0006zK-It for netconf-archive@lists.ietf.org; Wed, 18 Apr 2007 16:57:23 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeH77-000Cxt-Cv for netconf-data@psg.com; Wed, 18 Apr 2007 20:50:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [62.241.163.6] (helo=astro.systems.pipex.net) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeDfx-000MOi-Iu for netconf@ops.ietf.org; Wed, 18 Apr 2007 17:10:39 +0000 Received: from pc6 (1Cust100.tnt2.lnd4.gbr.da.uu.net [62.188.131.100]) by astro.systems.pipex.net (Postfix) with SMTP id 7A074E000322; Wed, 18 Apr 2007 18:10:28 +0100 (BST) Message-ID: <027e01c781d3$ac617860$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Sharon Chisholm" , "Netconf \(E-mail\)" References: <713043CE8B8E1348AF3C546DBE02C1B40E6AF21A@zcarhxm2.corp.nortel.com> Subject: Re: Netconf Notifications WC LC: Issues & Proposed Resolutions - Part 1 Date: Wed, 18 Apr 2007 18:05:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 By analogy with RFC4741, I think that the IANA consideration for capability:notification should specify index :notification capability identifier urn:ietf:params:netconf:capability:notification:1.0 Specification 3.1 of this document [not sure about this is; is the expectation that everyone will implement everything eg subtree and XPath filtering or is 'notification' too big to be just one capability or should it be subdivided (as you might guess, I am thinking of different conformance clauses in various other standards)?] Tom Petch ----- Original Message ----- From: "Sharon Chisholm" To: "Netconf (E-mail)" Sent: Wednesday, April 11, 2007 9:45 PM Subject: Netconf Notifications WC LC: Issues & Proposed Resolutions - Part 1 hi 9. ToC: No entry for IANA Considerations (no section either) (Source Andy) Proposed Resolution: Add an 'IANA Considerations' section to request allocation of namespaces for the Schemas. "This document registers two URIs for the NETCONF XML namespace in the IETF XML registry [7]. Following the format in RFC 3688, IANA has made the following registration. URI: urn:ietf:params:netconf:capability:notification:1.0 URI: urn:ietf:params:xml:ns:netmod:notification Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace." Update various references to content namespace to use this tag. -- 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 Apr 18 22:00:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeLwa-0000wF-0U for netconf-archive@lists.ietf.org; Wed, 18 Apr 2007 22:00:20 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HeLwY-0003E4-Gu for netconf-archive@lists.ietf.org; Wed, 18 Apr 2007 22:00:19 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeLrG-0006a3-Cs for netconf-data@psg.com; Thu, 19 Apr 2007 01:54:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.7 Received: from [68.142.198.202] (helo=smtp103.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeLrD-0006Ze-Gm for netconf@ops.ietf.org; Thu, 19 Apr 2007 01:54:49 +0000 Received: (qmail 30253 invoked from network); 19 Apr 2007 01:54:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.217 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 19 Apr 2007 01:54:46 -0000 X-YMail-OSG: b2oAEfwVM1lkX6W0AHDBmam4qv7ofATBTo0ddv09K3m5rniCmWvMGjz.X6etm87yN_xIu213oEx4re306LQ1lZK6gQ-- Message-ID: <4626CBC1.1000102@andybierman.com> Date: Wed, 18 Apr 2007 18:54:09 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: FYI: NETCONF minutes uploaded Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hi, The minutes from the IETF 68 NETCONF WG meeting can be found on the IETF WEB site: http://www3.ietf.org/proceedings/07mar/minutes/netconf.txt 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 Apr 19 11:58:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZ1V-0005ij-Tx for netconf-archive@lists.ietf.org; Thu, 19 Apr 2007 11:58:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeZ1U-00009P-K2 for netconf-archive@lists.ietf.org; Thu, 19 Apr 2007 11:58:17 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeYv0-000LzY-Qm for netconf-data@psg.com; Thu, 19 Apr 2007 15:51:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeYuw-000LzA-Rm for netconf@ops.ietf.org; Thu, 19 Apr 2007 15:51:32 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3JFpQN13557 for ; Thu, 19 Apr 2007 15:51:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NETCONF minutes uploaded Date: Thu, 19 Apr 2007 11:51:25 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40E8F309D@zcarhxm2.corp.nortel.com> In-Reply-To: <4626CBC1.1000102@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF minutes uploaded Thread-Index: AceCJqlJt623/QWNSRWYkS07Zp/DkwAc3dPA References: <4626CBC1.1000102@andybierman.com> From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hi I couple corrections/clarifications. 2.6 and 2.7 were separate agenda items and not directly part of the Notification draft discussion. For 2.6, there was consensus that this wasn't the right working group to work on a Netconf Monitoring Schema but the group did not discuss the document very long and I don't remember any specific objections to the content of the document being raised. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, April 18, 2007 9:54 PM To: Netconf (E-mail) Subject: FYI: NETCONF minutes uploaded Hi, The minutes from the IETF 68 NETCONF WG meeting can be found on the IETF WEB site: http://www3.ietf.org/proceedings/07mar/minutes/netconf.txt 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: -- 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 Apr 19 12:49:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZod-0003Rn-3r for netconf-archive@lists.ietf.org; Thu, 19 Apr 2007 12:49:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeZoZ-0007xg-Ng for netconf-archive@lists.ietf.org; Thu, 19 Apr 2007 12:49:03 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeZjq-00003R-3Q for netconf-data@psg.com; Thu, 19 Apr 2007 16:44:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.7 Received: from [68.142.198.212] (helo=smtp113.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeZjm-000038-TI for netconf@ops.ietf.org; Thu, 19 Apr 2007 16:44:04 +0000 Received: (qmail 63150 invoked from network); 19 Apr 2007 16:44:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.217 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 19 Apr 2007 16:44:01 -0000 X-YMail-OSG: h3rUBIkVM1m2xx3s561w6n2rqS4PEVPvyRojZA910VwQEKxw Message-ID: <46279C30.8060903@andybierman.com> Date: Thu, 19 Apr 2007 09:43:28 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: NETCONF minutes uploaded References: <4626CBC1.1000102@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40E8F309D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40E8F309D@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Sharon Chisholm wrote: > Hi > > I couple corrections/clarifications. > > 2.6 and 2.7 were separate agenda items and not directly part of the > Notification draft discussion. > > For 2.6, there was consensus that this wasn't the right working group to > work on a Netconf Monitoring Schema but the group did not discuss the > document very long and I don't remember any specific objections to the > content of the document being raised. > There were several mailing list comments that questioned why we needed particular monitoring data model objects defined at this time, by this WG. Here is the 2.6 text: ----- 2.6) Monitoring Data Model There are many objections to the session-specific state data that is included in the draft, for retrieval with the operation. The group was in general agreement that data models should only be included in the document if they are really needed for interoperability. ------ I think this is consistent with your statement that this wasn't the right WG. My text is focusing on the contents of the Notifications draft. That's what I meant by 'the document'. I did not mean or say 'any document'. There is still an open issue with the read-only 'last modified' timestamp in the profile configuration data model. A few people (besides me) think it doesn't need to be there for interoperability. > Sharon 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 Apr 19 13:25:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeaNd-0001Rq-LF for netconf-archive@lists.ietf.org; Thu, 19 Apr 2007 13:25:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeaNb-0003UV-9c for netconf-archive@lists.ietf.org; Thu, 19 Apr 2007 13:25:13 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeaJ4-00034c-Mz for netconf-data@psg.com; Thu, 19 Apr 2007 17:20:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeaJ1-000346-Lr for netconf@ops.ietf.org; Thu, 19 Apr 2007 17:20:29 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l3JHJll09027 for ; Thu, 19 Apr 2007 17:19:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NETCONF minutes uploaded Date: Thu, 19 Apr 2007 13:20:21 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40E8F32AF@zcarhxm2.corp.nortel.com> In-Reply-To: <46279C30.8060903@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF minutes uploaded Thread-Index: AceCofGhwvN1KVIeS6mWSnJL+GbsKQABHHJQ References: <4626CBC1.1000102@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40E8F309D@zcarhxm2.corp.nortel.com> <46279C30.8060903@andybierman.com> From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi Mailing list comments do not belong in meeting minutes unless someone referred to them at the time. For correct minutes, I feel 2.6 should be come 3.0 and 2.7 should become 4.0 and I think 2.6 (3.0) should be modified to reflect the actual meeting discussion. Sharon=20 -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com]=20 Sent: Thursday, April 19, 2007 12:43 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: Netconf (E-mail) Subject: Re: NETCONF minutes uploaded Sharon Chisholm wrote: > Hi >=20 > I couple corrections/clarifications. >=20 > 2.6 and 2.7 were separate agenda items and not directly part of the=20 > Notification draft discussion. >=20 > For 2.6, there was consensus that this wasn't the right working group=20 > to work on a Netconf Monitoring Schema but the group did not discuss=20 > the document very long and I don't remember any specific objections to > the content of the document being raised. >=20 There were several mailing list comments that questioned why we needed particular monitoring data model objects defined at this time, by this WG. Here is the 2.6 text: ----- 2.6) Monitoring Data Model There are many objections to the session-specific state data that is included in the draft, for retrieval with the operation. The group was in general agreement that data models should only be included in the document if they are really needed for interoperability. ------ I think this is consistent with your statement that this wasn't the right WG. My text is focusing on the contents of the Notifications draft. That's what I meant by 'the document'. I did not mean or say 'any document'. There is still an open issue with the read-only 'last modified' timestamp in the profile configuration data model. A few people (besides me) think it doesn't need to be there for interoperability. > Sharon 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 Apr 19 14:04:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeazH-00063I-Ox for netconf-archive@lists.ietf.org; Thu, 19 Apr 2007 14:04:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeazG-0003Sd-9B for netconf-archive@lists.ietf.org; Thu, 19 Apr 2007 14:04:07 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Heatw-0006PR-Nr for netconf-data@psg.com; Thu, 19 Apr 2007 17:58:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.7 Received: from [68.142.198.209] (helo=smtp110.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Heats-0006P2-Vp for netconf@ops.ietf.org; Thu, 19 Apr 2007 17:58:34 +0000 Received: (qmail 47023 invoked from network); 19 Apr 2007 17:58:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.217 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 19 Apr 2007 17:58:31 -0000 X-YMail-OSG: Fkq5ehQVM1nTw2qlzyHX_00fXEqdWz3TPXTIhY316vJGzsk..WNUlG.NAsUenWD8m_qIJYFIGOPgSRcl0wkVQtBX1Q-- Message-ID: <4627ADAA.9080405@andybierman.com> Date: Thu, 19 Apr 2007 10:58:02 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: NETCONF minutes uploaded References: <4626CBC1.1000102@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40E8F309D@zcarhxm2.corp.nortel.com> <46279C30.8060903@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B40E8F32AF@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40E8F32AF@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Sharon Chisholm wrote: > Hi > > Mailing list comments do not belong in meeting minutes unless someone > referred to them at the time. For correct minutes, I feel 2.6 should be > come 3.0 and 2.7 should become 4.0 and I think 2.6 (3.0) should be > modified to reflect the actual meeting discussion. > 2.6 refers to the open issue of the last modified timestamp that is still in the 'profile', in the Notifications draft. 2.7 refers to where the new text for SSH transport support resides, and putting it in this draft has not been ruled out. There hasn't been any decision made yet on that issue. There were comments in the meeting about this issue. I believe Martin mentioned that the last-modified timestamp was not needed, and Simon mentioned that the 'getStreams' data model was not useful at all. Btw, Section 2 is titled 'Notification Issues', not 'Notification Draft Issues', since were reviewing the section numbering now. > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, April 19, 2007 12:43 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: Netconf (E-mail) > Subject: Re: NETCONF minutes uploaded > > Sharon Chisholm wrote: >> Hi >> >> I couple corrections/clarifications. >> >> 2.6 and 2.7 were separate agenda items and not directly part of the >> Notification draft discussion. >> >> For 2.6, there was consensus that this wasn't the right working group >> to work on a Netconf Monitoring Schema but the group did not discuss >> the document very long and I don't remember any specific objections to > >> the content of the document being raised. >> > > There were several mailing list comments that questioned why we needed > particular monitoring data model objects defined at this time, by this > WG. > > Here is the 2.6 text: > > ----- > 2.6) Monitoring Data Model > > There are many objections to the session-specific state data that is > included in the draft, for retrieval with the operation. > The group was in general agreement that data models should only be > included in the document if they are really needed for interoperability. > ------ > > I think this is consistent with your statement that this wasn't the > right WG. My text is focusing on the contents of the Notifications > draft. > That's what I meant by 'the document'. I did not mean or say 'any > document'. > > There is still an open issue with the read-only 'last modified' > timestamp in the profile configuration data model. A few people > (besides me) think it doesn't need to be there for interoperability. > > >> Sharon > > 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: > > -- 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 Apr 20 08:18:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hes4h-0006Kr-Fd for netconf-archive@lists.ietf.org; Fri, 20 Apr 2007 08:18:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hes4e-0003IN-3K for netconf-archive@lists.ietf.org; Fri, 20 Apr 2007 08:18:51 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Herx6-000FeM-N3 for netconf-data@psg.com; Fri, 20 Apr 2007 12:11:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Herwy-000Fdj-Uy for netconf@ops.ietf.org; Fri, 20 Apr 2007 12:10:57 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3KCAnv18830 for ; Fri, 20 Apr 2007 12:10:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Netconf Notifications P-WG LC: Issues & Proposed Resolutions Date: Fri, 20 Apr 2007 08:10:48 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40E93C878@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notifications P-WG LC: Issues & Proposed Resolutions Thread-Index: AceBGKoHCIxXtWSCQTajPy2y2oQb8AAxadNgAC9j1BAABxuw0AAAITsgACKmomA= References: <6E21698722408147BEA594E073E2B0AB03A1F7ED@xmb-sjc-223.amer.cisco.com> From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 935fcc3d6c448ae30077dce3cfc94471 Hi Here are proposed resolutions for comments received just after the last call. (PLC1) The subscription metaphor is unnecessary and confusing. There's no win from introducing it, since the subscription isn't a visible protocol element, nor is it visible to the client application. Use something like instead. (source Phil) Proposed resolution: This issue has been discussed and the current draft reflects working group consensus. Propose no change. (PLC 2) The element shouldn't be a top-level tag. The first netconf add-on should not require modification to the simple RPC protocol we put in netconf. It's both a bad precedent and unnecessary. The content can live inside a normal . (source Phil) This draft introduces a modality into the netconf session which is both subtle and disturbing. When a request for notification is issued, the session moves from netconf-rpc mode into netconf-notification mode. When the notifications are complete, the session silently reverts back to rpc mode. The transition is not signalled by any top-level operation. Proposed solution: A lot of this was discussed in the Montreal meeting. This modality goes away if you define an optional capability that can process requests while sending notifications. We have also previously discussed the layering issues around not having an RPC-layer wrapper. What is in the document reflects working group consensus. Propose no change. (PLC 3) The draft as written does not provide a solution to the notification problem. It is a wrapper. The meat is in the notifications themselves, and the draft does nothing to define a standard way of carrying the common notification formats. In particular, a syslog and an SNMP trap mapping are needed. (source Phil) Proposed Resolution: While I agree it is unfortunate that we don't define notification content (not SNMP or syslog, but rather Netconf stuff), the lack of it reflects working group consensus. Propose no changes. (PLC 4) Other editorial issues with the draft. In general, the draft is poorly organized, with numerous forward references to content that has not been discussed, often in vague terms without a concrete reference. (source Phil) Proposed Resolution: Are there specific forward references that are causing issue? The document is currently organized to introduce concepts and then explain them. I find this much more readable then here are some Lego blocks and now let's build them into the thing we are talking about. But, if this is causing confusion, it would be good to identify those items which are confusing readers and resolve them either via a reference or via reorganizing the text. In resolving another issue, some definitions are being added to the terminology section, so I imagine this will help. Propose no further change. (PLC 5) I'd also like to re-address the .vs. inconsistency, hoping for a better interest than the handful of people that voted in the working group meeting. (source Phil) Proposed Resolution: We don't seem to have consensus to change things. Propose no change. (PLC 6) I was originally quite confused about why this picture was included in this draft, since I missed the addition. Looking at the new picture, the layer violation becomes more obvious. I find it particularly disturbing when I think that this draft modifies all four of these layers. My preference is for something that lives within the netconf framework, without requiring changes throughout it. (source Phil) Proposed Resolution: While the original proposal did not require a layer violation, the current picture reflects working group consensus. Propose no change. (PLC 7) > Managed Object: A collection of one of more Elements that define an > abstract thing of interest. This term is never referenced. (source Phil) Proposed Resolution: This is a duplicate of issue number 1 (PLC 8)=20 > Subscription: A concept related to the delivery of notifications (if > any to send) involving destination and selection of notifications. > It is bound to the lifetime of a session. This definition is very weak. See above comments re: subscriptions. (source Phil) Proposed Resolutions: Were these some specific edits or issues? (PLC 9) This definition is very weak. See above comments re: subscriptions. > Operation: This term is used to refer to NETCONF protocol > operations. Specifically within this document, operation refers > to NETCONF protocol operations defined in support of NETCONF > notifications. Can we include terms from the base spec implicitly? There are _many_ terms missing here, including replay, streams, profiles, and filters (maybe?). (source Phil) Proposed Resolution: Add definition of replay, stream and profile. Filter and filter elements can be defined implicitly from the Netconf base specification.=20 Replay: Ability to send/re-send previously logged notifications upon request. These notifications are sent asynchronously. This feature is implemented by the NETCONF server and invoked by the NETCONF client. =20 Stream: An event stream is a set of event notifications matching some forwarding criteria and it is available to NETCONF clients for subscription.=20 Named Profile: A pre-defined set of filtering criteria residing in the Network Element which may be applied to a notification session at subscription creation time. =20 (PLC 10) > An event is something that happens which may be of interest - a > configuration change, a fault, a change in status, crossing a > threshold, or an external input to the system, for example. Often > this results in an asynchronous message, sometimes referred to as a > notification or event notification, being sent out to interested > parties to notify them that this event has occurred. s/sent out/sent/ s/ to notify them that this event has occurred// (source Phil) Proposed Resolution: In section 1.1, where the definition of event is being moved as a result of another edit, s/sent out/sent/. Propose no change from second proposed edit as the current text seems fine.=20 (PLC 11)=20 > This memo defines a mechanism whereby the NETCONF client indicates > interest in receiving event notifications from a NETCONF server by > creating a subscription to receive event notifications. The NETCONF > server replies to indicate whether the subscription request was > successful and, if it was successful, begins sending the event > notifications to the NETCONF client as the events occur within the > system. These event notifications will continue to be sent until > either the NETCONF session is terminated or the subscription to > terminate for some other reason. The event notification subscription > allows a number of options to enable the NETCONF client to specify > which events are of interest. These are specified when the > subscription is created. s/subscription to/subscription/ (source Phil) Proposed Resolution: In section 1.2, second paragraph (first after definition of event is moved) s/subscription to terminate/subscription terminates/ (PLC 12) =20 > An NETCONF server is not required to process RPC requests on the > session associated with the subscription until the notification > subscription is done and may silently discard these requests. A > capability may be advertised to announce that a server is able to > process RPCs while a notification stream is active on a session. s/An NETCONF/A NETCONF/ (source Phil) Proposed Resolution: There are apparently two camps on this question of grammar. http://www.gpuss.co.uk/english_usage/a_or_an.htm For consistency with the base protocol ;-) propose changing to "A NETCONF" (PLC 13) >1.3. Motivation > > The motivation for this work is to enable the sending of asynchronous > messages that are consistent with the data model (content) and > security model used within a NETCONF implementation. This section seems odd, since the more detailed model given in 1.2. (source Phil) Proposed Resolution: Move section 1.3 above section 1.2 (PLC 14) > o solution should provide a subscription mechanism (A NETCONF server > does not send notifications before being asked to do so and the > NETCONF client initiates the flow of notifications) Use of subscriptions isn't the requirement; the parenthetical sentence is the real requirement. (source Phil) Proposed Resolution: And collectively they define the requirement. Propose no change. (PLC 15) >2. Notification-Related Operations The underlaying model from Section 3 (Supporting concepts) should appear before this section. Diving straight into operations without giving the reader a framework into which those operations fit puts syntax over semantics. (source Phil) Proposed Resolution: This is a duplication of 27. (PLC 16)=20 >2.1.1. > Description: > This operation initiates an event notification subscription which > will send asynchronous event notifications to the initiator of the > command until the subscription to terminates. s/to terminates/is terminated/ or /terminates/ Can this description be improved? The subscription doesn't send notifications, but instructs the server to initiate sending notifications for events that match the given criteria. (source Phil) Proposed Resolution: In section 2.1.1, s/to terminates/terminates/. The second point seems to be splitting hairs. The subscription is what makes the server send the notifications. (PLC 17) > Stream: > An optional parameter that indicates which stream of events is > of interest. If not present, then events in the default > NETCONF stream will be sent. Streams are not defined at the point in the draft. (source Phil) Proposed Resolution: As specified in (PLC 9), we shall add this definition to the terminology section. (PLC 18) > Filter: > An optional parameter that indicates which subset of all > possible events are of interest. The format of this parameter > is the same as that of the filter parameter in the NETCONF > protocol operations. If not present, all events not precluded > by other parameters will be sent. This is mutually exclusive > with the named profile parameter. Include a reference to the section on filters. (source Phil) Proposed Resolution: Add text "See section 3.5 for more information on filers.\ (PLC 19) > Named Profile: > An optional parameter that points to a separately defined > filter profile. If not present, no additional filtering will > be applied. Note that changes to the profile after the > subscription has been created will have no effect. This is > mutually exclusive with the filter parameter This needs a forward reference also. Changes "points to" to "refers to".=20 Missing period on last sentence. (source Phil) =20 Proposed Resolution: In section 2.1.1 in the section on Named profile, add a period to the last sentence. Change "points to" to "refers to". Add text at the end which says "For more information on named profiles, see section 3.5.1. (PLC 20) > Start Time: > A parameter used to trigger the replay feature and indicates > that the replay should start at the time specified. If start > time is not present, this is not a replay subscription. Why not refer to parameters by their real names, like start-time? Talk about the acceptable formats for this parameter. (source Phil) Proposed Resolution: In section 2.1.1, in the section on start time, replace "If start time" with "If startTime". Add text that says "This parameter is of type dateTime." (PLC 21)=20 >2.2. Sending Event Notifications > Once the subscription has been set up, the NETCONF server sends the > event notifications asynchronously along the connection. s/along/over/ (source Phil) Proposed resolution: In section 2.2, replace "the NETCONF server sends the event notifications asynchronously along the connection" with "the NETCONF server sends the event notifications asynchronously over the connection" (PLC 22) >2.2.1. > > Description: > > An event notification is sent to the initiator of a subscription> command asynchronously when an event of interest > (i.e. meeting the specified filtering criteria) to them has > occurred. An event notification is a complete and well-formed XML > document. Note that is not an RPC method but > rather the top level element identifying the one way message as a > notification. It should mention that the encoding of this element is transport specific, which I guess means we need to rev all the transport RFCs. Use ""client" instead of "initiator". It's confusing. It's not clear that "filtering criteria" refers to more than . The contents of the element are never discussed. It should at least say that the draft is not concerned with content. (source Phil) Proposed Resolution: I don't think we actually need to say anything about the encoding for transport beyond what was said in the base protocol. Propose no change.=20 In section 2.2.1, in the description, replace "sent to the initiator of a " with "sent to the client who initiated the " Filtering criteria just reads better in the sentence. I don't think it will cause confusion. Propose no change. In section 2.2.1, in the "Data" section, add the text that says "The content of the data tag is beyond the scope of this document." (PLC 23) =20 >2.3. Terminating the Subscription > Closing of the event notification subscription can be done by > terminating the NETCONF session ( ) or the underlying > transport session. If a stop time is provided when the subscription > is created, then the subscription will terminate after the stop time > is reached. In this case, the Netconf session will still be an > active session. This introduces a modality into netconf sessions that I dislike, especially since the triggers that switch the modes are buried inside the content. There's nothing at the layer to tell you that you've moved from mode to mode. The reference to is odd, since I can't see this being used in any real way. Are we expecting people to open a second session to kill their first session? This is the way the text reads but I can't imagine that's the intention. (source Phil) Proposed Resolution: Yes, this is one method that people could use to terminate the session. We also mention terminating the underlying transport session. Propose no change. (PLC 24)=20 >3. Supporting Concepts Supporting concepts (semantics) should appear before syntactic content. Otherwise the reader is lost. (source Phil) Proposed Resolution: This is a duplicate of issue (PLC 4). (PLC 25) >3.2. Event Streams > An event stream is defined herein as a set of event notifications > matching some forwarding criteria. s/herein// since all definitions are specific to this document. s/forwarding// since it doesn't make sense. (source Phil) Proposed Resolution: In section 3.2, replace "An event stream is defined herein" with "An event stream is defined". I believe though that the term forwarding is used to indicate that they are forwarded from the general event system within the box to the Netconf event system. The fact that the stream exists outside of the context of Netconf is important from my understanding.=20 (PLC 26) > +----+ > | c1 |---+ available streams > +----+ | +---------+ > +----+ | |central |-> stream 1 > | c2 | +--->|event |-> stream 2 filter +-------+ > +----+ | |processor|-> netconf stream --->|netconf| > ... | | |-> stream n |server | see > System | +---------+ +-------+ below > Components| | // > ... | | // > +----+ | | (------------) > | cn |---+ | (notification) > +----+ +-----> ( logging ) > ( service ) > (------------) What are the "//" marks for? The "see below" is confusing, since the "below" boxes look like orphans. (source Phil) Proposed Resolution: In section 3.2, in the figure, remove the "//" characters on line lines 9 and 10, replace with line-arrow from "notification logging service" to "netconf server". This shows that logged notifications are sent to the netconf server (replay feature). Also remove the text "see below". (PLC 27) >3.2.1. Event Stream Definition > > Event streams are predefined on the managed device. The > configuration of event streams is outside the scope of this document. > However, it is envisioned that event streams are either pre- > established by the vendor (pre-configured) or user configurable (e.g. > part of the device's configuration) or both. Device vendors may > allow event stream configuration via NETCONF protocol (i.e. edit- > config operation) 3.2 starts with the definition of event streams. This section doesn't read well. It would be better to start with the event model, add event streams, add netconf, and then draw a picture of the final world view. (source Phil) Proposed Resolution: I'm not sure what is specifically being requested. Propose no change. (PLC 28) >3.2.2. Event Stream Content Format > The contents of all event streams made available to a NETCONF client > (i.e. the notification sent by the NETCONF server) must be encoded in > XML. XML, but what sort? Can I just put a string under ? Do I need my own container tag? Can I put multiple elements in a ? Are there any rules? (source Phil) Proposed Resolution: I believe working group consensus was not to specify much here. I suppose is the wrapper. Propose no change. (PLC 29) >3.2.3. Default Event Stream > A NETCONF server implementation supporting the notification > capability must support the "NETCONF" notification event stream. > This stream contains all NETCONF XML event notifications supported by > the NETCONF server. The definition of the event notification and > their contents for this event stream is outside the scope of this > document. We define a stream without a notification data model? How does this work? What possible purpose could it serve? Clients spontaneously "know" how to interpret these events? s/event notification/event notifications/ ? (source Phil) Proposed Resolution: This reflects working group consensus. I will confess to not fully getting the appeal of streams, but, again, this is working group consensus. In section 3.2.3 replace "The definition of the event notification and their contents" with "The definition of the event notifications and their contents". (PLC 30) >3.2.4. Event Stream Sources > With the exception of the default event stream (NETCONF > notifications) specification of additional event stream sources (e.g. > SNMP, syslog, etc.) is outside the scope of this document. NETCONF > server implementations may leverage any desired event stream source > in the creation of supported event streams. I don't understand this section. Is it placing any sort of limitation on an NETCONF implementation? What should be NETCONF implementor read into it? Just that they can do what they want? Do we need to tell them that explicitly? (source Phil) Proposed Resolution: Working group consensus was that we were not going to talk about the content. As a technical contributor, I'm not pleased with that, but it is what it is. Give that, I don't know what sort of restrictions we can place on implementers. Propose no changes. (PLC 31) >3.2.5.1. Name Retrieval using operation > > The list of available event streams is retrieved by requesting the > subtree via a operation. Available event streams > for the requesting session are returned in the reply containing the > and elements, where element is mandatory > and its value is unique. The returned list must only include the > names of those event streams for which the NETCONF session has > sufficient privileges. The NETCONF session privileges are determined > via access control mechanisms which are beyond the scope of this > document. An empty reply is returned if there are no available event > streams. The information is retrieved by requesting the > subtree via a operation. s/operation/ operation/ (source Phil) Proposed Resolution: This is a duplicate of (23) (PLC 32) > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > What is "netmod"? Should this be under ":netconf:notification:1.0"? Are we intentionally making "netmod" .vs. "netconf" distinctions? Can you explain the distinction? (source Phil) Proposed Resolution: Netmod is the de facto name people have been using for Netconf content. (NETconf MODel). Based on other issues, we assume here a separate namespace for the content. The urn matches the pattern used by other things in http://www.iana.org/assignments/xmlregistry/ns.html. In general the naming of the content URN has been an issue in every update. Propose changing from netmod:base to netmod:notifications since this brings us closer to where we need to be. (PLC 33) >3.2.5.2. Event Stream Subscription > A NETCONF client may request from the NETCONF server the list of > available event streams to this session and then issue a subscription> request with the desired event stream name. Omitting > the event stream name from the request results > in subscription to the default NETCONF event stream. Why is this a feature, rather than a bug in the client code? Are we expecting an overwhelming use of the NETCONF stream that it makes sense to use it as the default? (source Phil) Proposed Resolution: Yes, I expect that sending Netconf content over the Netconf Notification interface will be common. It's also the simplest thing to talk about in a Netconf protocol specification. Implementations sending content from other streams just need to specify those other streams. Propose no change. (PLC 34) Section 3.3 I skipped the schema, but will note that there normative text in the schema that is not in the real text. I don't know if this is intentional or not, but it's a bit confusing, especially given that people don't tend to read the schemas. elements are a poor source of specification. Better to move these discussion into the text. In particular, the bits about profiledata imply that it's configuration data, but there's no data model to go with it. For example, how to I change the of a named-profile? Also there are some odd rules about timestamps, and the interaction between fielded requests and the profiles. IMHO, this is best left to the implementation because (a) it's a corner case and (b) it's expensive to treat corner cases in ways that your implementation considered unnatural. If you force rigid behavior, you're likely to be ignored anyway. Best to leave it undefined. (source Phil) Proposed Resolution: Actually, we found in SNMP that the descriptions were very important; more important then the text in the rest of the document. I agree for the protocol definitions the opposite might be true, but we are talking content definitions here. The name object in the named profile is modifiable so to change it, you would just change it. We have not discussed what happens if that named profile is currently in use. There are some options we could take here to fix this ambiguity. I would suggest adding additional text to lastModified to clarify things. "Note there is no guarantee that the profile named in the subscription will be found at all."=20 I assume for the last point you are talking about the lastModified field, except that this does not describe any behaviour on the server, rather tell the client how to interpret the information. Propose no change. (PLC 35) >3.4. Subscriptions not Configuration Data s/not/are not/ >While it may be possible to retrieve information about subscriptions=20 >via a get operation, subscriptions are not stored configuration. This makes it sound like you can get configuration via , which is not true. Better to just explain that subscriptions are not configuration data, and their lifetime is defined by their session. > Named profiles, if used, are considered configuration data. Profiles may also be built into the device, right? (source Phil) Proposed resolution: The first bit is a duplicate of (7) The description of the operation in RFC 4741 Is "Retrieve running configuration and device state information", but I do like the clarifying text you have suggested. In section 3.4, replace "They are non-persistent state information" with "They are non-persistent state information and their lifetime is defined by their session". By built into the device I assume you mean configured in the default configuration. If so, the answer is yes. (PLC 36) >3.5. Filter Dependencies s/Dependencies/Mechanics/? >3.5.1. Named Profiles > A named profile is a filter that is created ahead of time and applied > at the time an event notification subscription is created . Note > that changes to the profile after the subscription has been created > will have no effect on the subscription. Since named profiles exist > outside of the subscription, they persist after the subscription has > been torn down. s/created ./created./ Again, the "changes" part is better seen as implementation-specific behavior. (source Phil) Proposed Resolution: Rename the title of section 3.5 from "Filter Dependencies" to "Filter Mechanics". In section 3.5.1, delete the extra space after 'created' and before the period.=20 The behaviour around what happens when named profile is modified is necessary for predictability and is working group consensus. Propose no changes. (PLC 37) >4. XML Schema for Event Notifications Why are some imports documented and other not? (source Phil) Proposed Resolution: The documents required to pass validation have been imported while those not required or not. In another issue we determined that netconf:notification is not actually used in this schema so its important statement will therefore be deleted. (PLC 38) >6.1. Overview > > Replay is the ability to create an event subscription that will > resend recently sent notifications. These notifications are sent the > same way as normal notifications. s/recently sent/recently generated/ since they may not have been sent anywhere. > The actual number of stored notifications available for retrieval at > any given time is an NETCONF server implementation specific matter. > Control parameters for this aspect of the feature are outside the > scope of the current work. s/the current work/this document/ > This feature is dependent on a notification stream supporting some > form of notification logging, although it puts no restrictions on the > size or form of the log, nor where it resides within the device. s/This feature/Replay/ (source Phil) Proposed Resolution: In section 6.1, first paragraph, replace "resend recently sent notifications" with "resend recently generated notifications". In the fourth paragraph, replace "scope of the current work" with "scope of this document". In the fifth paragraph, replace "This feature is dependent" with "This feature is dependent". (PLC 39) >6.2. Creating a Subscription with Replay > This feature uses optional parameters to the > command called 'startTime' and 'stopTime'. 'startTime' identifies the > earliest date and time of interest for event notifications being > replayed and also indicates that a subscription will be providing > replay of notifications. Events generated before this time are not > matched. 'stopTime' specifies the latest date and time of interest > for event notifications being replayed. If it is not present, then > notifications will continue to be sent until the subscription is > terminated. Talk about the transition to live events.(source Phil) Proposed Resolution: In section 6.2, add text that says "A replay complete notification is sent to trigger that all of the replay notifications have been sent. If this subscription has a stop time, then this session becomes a normal NETCONF session again. In the case of a subscription without a stop time, after the replay complete notification has been sent, it can be expected that any notifications generated since the start of the subscription creation will be sent followed by notifications as they arise naturally within the system." (PLC 40) > Note that while a notification has three potential times associated > it - the time it was generated, the time it was logged and the time > it was sent out by the NETCONF server - the startTime and stopTime > parameters are related to generation time. This paragraph should just say event time should be relative to the time the event occurred and the notification was generated. Discussing the other times is confusing. Is there a way to say now to avoid waiting for live events? (source Phil) Proposed Resolution: In section 6.2, replace "Note that while a notification has three potential times associated it - the time it was generated, the time it was logged and the time it was sent out by the NETCONF server - the startTime and stopTime parameters are related to generation time." with startTime and stopTime are associated with the time an event was generated by the system."=20 Replay is optional, so not specifying it means you get the real-time notifications right away. I agree that having to wait for the replay to continue to get real-time notifications is unfortunate, but I'm not sure how it address it given previous working group consensus. Note that, as currently defined, stopTime is implicitly defined to be now.=20 (PLC 41) > Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing > their input into the early work on this document. In addition, the > editors would like to acknowledge input at the Vancouver editing > session from the following people: Orly Nicklass, James Balestriere, > Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, > Dave Partain, Ray Atarashi and Dave Perkins and the following > additional people from the Montreal editing session: Balazs Lengyel, > Phil Shafer, Rob Ennes, Andy Bierman, Dan Romascanu, Bert Wijnen, > Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, > Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William > Chow. s/Ennes/Enns/ (source Phil) Proposed Resolution: In section 8, s/Ennes/Enns/ Sharon Chisholm Nortel Ottawa, Ontario Canada -- 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 Apr 20 08:26:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HesBu-0003ld-A6 for netconf-archive@lists.ietf.org; Fri, 20 Apr 2007 08:26:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HesBt-0006SF-Vf for netconf-archive@lists.ietf.org; Fri, 20 Apr 2007 08:26:18 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Hes67-000GNe-8x for netconf-data@psg.com; Fri, 20 Apr 2007 12:20:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.7 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Hes64-000GNF-9H for netconf@ops.ietf.org; Fri, 20 Apr 2007 12:20:17 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3KCKDv21267 for ; Fri, 20 Apr 2007 12:20:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Netconf Notifications WC LC: Issues & Proposed Resolutions - Part 1 Date: Fri, 20 Apr 2007 08:20:12 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40E93C89C@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40E6AF21A@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notifications WC LC: Issues & Proposed Resolutions - Part 1 Thread-Index: Acd8PhwFkZVxZFKWREWj9itd5sP28wAC8njwAb7GASA= References: <713043CE8B8E1348AF3C546DBE02C1B40E6AF21A@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi I have a different proposed resolution to issue 17, which I think people will prefer. The requirement for a warn-and-continue construct goes away with the addition of the replayLogStartTime introduced in the resolution of issue 44. This provides an alternative way to tell the difference between no notifications within a timeframe and no notifications in the log for a timeframe. Updated Proposed Resolution for 17: I think we briefly discussed this in Prague, but I don't remember the consensus, if any. An edit is definitely required to make these consistent with each other. Conditional on the inclusion of replayLogStartTime discussed in issue 44, delete any reference to warn-and-continue like constructs from current section 6 before merging it into section 2.2.1 and section 3. Sharon -----Original Message----- From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Wednesday, April 11, 2007 3:46 PM To: Netconf (E-mail) Subject: Netconf Notifications WC LC: Issues & Proposed Resolutions - Part 1 17. pg 8, sec 2.1.1, Negative Response (Source Andy)=20 a. This section is correct, but inconsistent with the text in sec. 6.1, para 3. b. There is no mention of a 'warning-and-continue' mode of operation here. (More reason why sec 6. create-sub. details needs to be integrated into this section.) Proposed Resolution: I think we briefly discussed this in Prague, but I don't remember the consensus, if any. An edit is definitely required to make these consistent with each other. The reasons why warn and continue is required it to allow the client to create a replay request without actually needing to know the exact time of the earliest available log. Propose adding text to section 2.1.1 to reflect the warn and continue method discussed in section 6. Create a new section between "Positive Response" and "Negative Response" called "Warn and Continue" with the following text "If the NETCONF server can satisfy the request, but the start time specified is too early then the element will be included a warning message, but the client can expect to be along the Netconf session. " -- 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 Apr 20 12:20:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HevqJ-0006Xd-Ed for netconf-archive@lists.ietf.org; Fri, 20 Apr 2007 12:20:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HevqJ-0001By-2l for netconf-archive@lists.ietf.org; Fri, 20 Apr 2007 12:20:15 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Hevk9-00091G-Aw for netconf-data@psg.com; Fri, 20 Apr 2007 16:13:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [68.142.198.202] (helo=smtp103.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Hevk5-00090G-Pd for netconf@ops.ietf.org; Fri, 20 Apr 2007 16:13:51 +0000 Received: (qmail 69942 invoked from network); 20 Apr 2007 16:13:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.217 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 20 Apr 2007 16:13:48 -0000 X-YMail-OSG: 70b8rDIVM1mRJDllC3beckGP.vtfjMvD7AoP0VwZlKgdLZ9YaeBVDWyFauIaSB8naI96kZyLaMk29zApoLsyFwq6cA-- Message-ID: <4628E69F.3010401@andybierman.com> Date: Fri, 20 Apr 2007 09:13:19 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Netconf Notifications WC LC: Issues & Proposed Resolutions - Part 1 References: <713043CE8B8E1348AF3C546DBE02C1B40E6AF21A@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B40E93C89C@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40E93C89C@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Sharon Chisholm wrote: > Hi > > I have a different proposed resolution to issue 17, which I think people > will prefer. The requirement for a warn-and-continue construct goes away > with the addition of the replayLogStartTime introduced in the resolution > of issue 44. This provides an alternative way to tell the difference > between no notifications within a timeframe and no notifications in the > log for a timeframe. > > Updated Proposed Resolution for 17: I think we briefly discussed this in > Prague, but I don't remember the consensus, if any. An edit is > definitely required to make these consistent with each other. > Conditional on the inclusion of replayLogStartTime discussed in issue > 44, delete any reference to warn-and-continue like constructs from > current section 6 before merging it into section 2.2.1 and section 3. > I'm having a hard time following all the details in these long emails. I don't recall what Issue 17 by number. I've decided it would be easier (for me anyway) to just read the new draft when it comes out, rather than discussing the issue list. We are getting to the point when we start asking for strong objections to text, rather than just comments, especially issues which have been closed for some time. I have no strong objections to anything in the draft, so I'm not going to comment further on the remaining details. > Sharon Andy > > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Wednesday, April 11, 2007 3:46 PM > To: Netconf (E-mail) > Subject: Netconf Notifications WC LC: Issues & Proposed Resolutions - > Part 1 > > > > 17. pg 8, sec 2.1.1, Negative Response (Source Andy) > > a. This section is correct, but inconsistent with the text in sec. > 6.1, para 3. > b. There is no mention of a 'warning-and-continue' mode of > operation here. (More reason why sec 6. create-sub. details needs to be > integrated into this section.) > > Proposed Resolution: I think we briefly discussed this in Prague, but I > don't remember the consensus, if any. An edit is definitely required to > make these consistent with each other. The reasons why warn and continue > is required it to allow the client to create a replay request without > actually needing to know the exact time of the earliest available log. > Propose adding text to section 2.1.1 to reflect the warn and continue > method discussed in section 6. Create a new section between "Positive > Response" and "Negative Response" called "Warn and Continue" with the > following text "If the NETCONF server can satisfy the request, but the > start time specified is too early then the element will be > included a warning message, but the client can expect to > be along the Netconf session. " > > > > -- > 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 Apr 25 10:29:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiUq-0001HG-20 for netconf-archive@lists.ietf.org; Wed, 25 Apr 2007 10:29:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgiUo-0004xQ-Nd for netconf-archive@lists.ietf.org; Wed, 25 Apr 2007 10:29:28 -0400 Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HgiLz-0008gK-Vy for netconf-data@psg.com; Wed, 25 Apr 2007 14:20:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.7 Received: from [68.142.198.202] (helo=smtp103.sbc.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HgiLr-0008fa-Ry for netconf@ops.ietf.org; Wed, 25 Apr 2007 14:20:14 +0000 Received: (qmail 57878 invoked from network); 25 Apr 2007 14:20:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@75.50.191.217 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 25 Apr 2007 14:20:10 -0000 X-YMail-OSG: 4M94hsAVM1ksQKejt3NwbU30hXvvS3gM26AJO_3RLiHxcwe3 Message-ID: <462F637C.4060008@andybierman.com> Date: Wed, 25 Apr 2007 07:19:40 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Sharon Chisholm CC: "Netconf (E-mail)" Subject: Re: Netconf Notifications WC LC: Issues & Proposed Resolutions - Part 1 References: <713043CE8B8E1348AF3C546DBE02C1B40E6AF21A@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40E6AF21A@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Sharon Chisholm wrote: > hi > >... > 2. Section 2.1.1 (Source Ken) > > The "negative response" section should clearly indicate what happens > when either the start-time is set but the stream doesn't support replay > or when the stop-time is set without having the start-time set - both of > these conditions are marked as illegal by the spec without any clear > statement about what will happen (i.e. what rpc-error will be returned) > > Proposed Resolution: > > Add the following text to Section 2.1.1 under Negative Response > "If a stop-time is specified in a request without having specified a > start-time the following error is returned > > Tag: bad-element > Error-type: protocol > Severity: error > Error-info: > Description: An element value is not correct; e.g., wrong type, > out of range, pattern mismatch. > This is not correct. The bad-element error-tag defines a QName, which in this case, is set to 'startTime': bad-element ... err:startTime >... > Sharon Chisholm 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: