From owner-netconf@ops.ietf.org Wed Sep 06 10:34:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKyTc-0005aY-9K for netconf-archive@lists.ietf.org; Wed, 06 Sep 2006 10:34:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKyTa-0005Ix-Ng for netconf-archive@lists.ietf.org; Wed, 06 Sep 2006 10:34:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKyID-000Dy0-Bd for netconf-data@psg.com; Wed, 06 Sep 2006 14:22:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKyIB-000DxS-1e for netconf@ops.ietf.org; Wed, 06 Sep 2006 14:22:16 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 06 Sep 2006 07:22:14 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k86EMEix005059 for ; Wed, 6 Sep 2006 07:22:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k86EMEYr018413 for ; Wed, 6 Sep 2006 07:22:14 -0700 (PDT) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Sep 2006 07:22:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D1BF.D95CE0D2" Subject: interim meeting - clarifications Date: Wed, 6 Sep 2006 07:22:13 -0700 Message-ID: <6E21698722408147BEA594E073E2B0AB02633FFF@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: interim meeting - clarifications Thread-Index: AcbRv9jxcatXRHpESiWKMEj00cMIAQ== From: "Hector Trevino \(htrevino\)" To: X-OriginalArrivalTime: 06 Sep 2006 14:22:14.0375 (UTC) FILETIME=[D9726770:01C6D1BF] DKIM-Signature: a=rsa-sha1; q=dns; l=5409; t=1157552534; x=1158416534; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=htrevino@cisco.com; z=From:=22Hector=20Trevino=20\(htrevino\)=22=20 |Subject:interim=20meeting=20-=20clarifications; X=v=3Dcisco.com=3B=20h=3DMy2qkGUfJu+txIugZ4r5f3frj9w=3D; b=RQn1l3gHwvCn1HpX486HbcD8IZBdBKIZcD0fsQaBn7mvl7OKpGMyzT7ybZj/tteaQzMEMWwE +1lSwIi1Wvns3QJfVAE6lioVBbBL+t4ev8mS9qPscTzCTa7zOWlUwO0J; Authentication-Results: sj-dkim-4.cisco.com; header.From=htrevino@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D1BF.D95CE0D2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Andy, =20 =20 =20 From meeting minutes 5.4) Filtering =20 The use of POSIX regular expressions is planned for this feature. There are still a lot of details that need to be written down before an interoperable filtering mechanism (i.e., same NETCONF behavior across agents) is fully defined. =20 It was noted that the function library of XPATH 2.0 supports=20 regular expressions in the function library. XPATH 1.0 does=20 not have something like that. =20 The authors will propose some text in the next revision of=20 the Notifications I-D. =20 Question: The current notifications draft uses the same filtering mechanism as those identified in the netconf protocol doc. Wouldn't it be more appropriate to add this information (i.e. filtering using XPATH 2.0 reg exp) to the main protocol document after it becomes an RFC? By doing this we maintain the two docs in sync wrt filtering features. =20 thanks=20 Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 Mobile: 303-619-3172 =20 9155 E. Nichols Ave Fax: 720-875-1414 Englewood, CO E-mail: htrevino@cisco.com 80112 =20 ------_=_NextPart_001_01C6D1BF.D95CE0D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Andy,
 
 
 
From = meeting=20 minutes

5.4)=20 Filtering

 

The use of=20 POSIX regular expressions is planned for this

feature.  There are still a lot of = details that=20 need to

be written down=20 before an interoperable filtering

mechanism=20 (i.e., same NETCONF behavior across agents)

is fully=20 defined.

 

It was noted=20 that the function library of XPATH 2.0 supports

regular=20 expressions in the function library. XPATH 1.0 does

not have=20 something like that.

 

The authors=20 will propose some text in the next revision of

the=20 Notifications I-D.

 
Question: The=20 current notifications draft uses the same filtering mechanism as those=20 identified in the netconf protocol doc. Wouldn't it be more = appropriate=20 to add this information (i.e. filtering using XPATH 2.0 reg exp) to = the=20 main protocol document after it becomes an RFC? By doing this=20 we maintain the two docs in sync wrt filtering features.=20  
thanks 
Hector Trevino
Network Management Technology =
Group (NMTG)
Cisco Systems Inc.        Voice:  720-875-1369
Suite =
400                 Mobile: 303-619-3172     
9155 E. Nichols Ave     =
  Fax:    720-875-1414
Englewood, CO             E-mail: =
htrevino@cisco.com
80112
 
------_=_NextPart_001_01C6D1BF.D95CE0D2-- -- 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 Sep 06 10:50:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKyjn-0002GN-VZ for netconf-archive@lists.ietf.org; Wed, 06 Sep 2006 10:50:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKyjk-0007wl-LI for netconf-archive@lists.ietf.org; Wed, 06 Sep 2006 10:50:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKydj-000Fqp-8Y for netconf-data@psg.com; Wed, 06 Sep 2006 14:44:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKydi-000Fqa-A8 for netconf@ops.ietf.org; Wed, 06 Sep 2006 14:44:30 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k86EiNaL006401 for ; Wed, 6 Sep 2006 10:44:24 -0400 Received: (qmail 21132 invoked by uid 78); 6 Sep 2006 14:44:15 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 6 Sep 2006 14:44:15 -0000 Message-ID: <44FEDF2E.5040005@andybierman.com> Date: Wed, 06 Sep 2006 07:46:06 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Hector Trevino (htrevino)" CC: netconf@ops.ietf.org Subject: Re: interim meeting - clarifications References: <6E21698722408147BEA594E073E2B0AB02633FFF@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6E21698722408147BEA594E073E2B0AB02633FFF@xmb-sjc-223.amer.cisco.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: f4c2cf0bccc868e4cc88dace71fb3f44 Hector Trevino (htrevino) wrote: > > Andy, > > > > From meeting minutes > > 5.4) Filtering > > > > The use of POSIX regular expressions is planned for this > > feature. There are still a lot of details that need to > > be written down before an interoperable filtering > > mechanism (i.e., same NETCONF behavior across agents) > > is fully defined. > > > > It was noted that the function library of XPATH 2.0 supports > > regular expressions in the function library. XPATH 1.0 does > > not have something like that. > > > > The authors will propose some text in the next revision of > > the Notifications I-D. > > > Question: The current notifications draft uses the same filtering > mechanism as those identified in the netconf protocol doc. Wouldn't it > be more appropriate to add this information (i.e. filtering using XPATH > 2.0 reg exp) to the main protocol document after it becomes an RFC? By > doing this we maintain the two docs in sync wrt filtering features. > thanks > IMO, it would be more appropriate to put this new filtering in a separate document, with its own capability. The base protocol doesn't need to change to add a new capability. > Hector Trevino 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 Sep 06 11:31:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKzN6-0005OT-Fw for netconf-archive@lists.ietf.org; Wed, 06 Sep 2006 11:31:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKzN5-0006DJ-2N for netconf-archive@lists.ietf.org; Wed, 06 Sep 2006 11:31:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzJW-000KUo-3f for netconf-data@psg.com; Wed, 06 Sep 2006 15:27:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzJV-000KUS-8A for netconf@ops.ietf.org; Wed, 06 Sep 2006 15:27:41 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 06 Sep 2006 08:27:41 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k86FRelp026632; Wed, 6 Sep 2006 08:27:40 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k86FRe1E007888; Wed, 6 Sep 2006 08:27:40 -0700 (PDT) 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); Wed, 6 Sep 2006 08:27:40 -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: interim meeting - clarifications Date: Wed, 6 Sep 2006 08:27:39 -0700 Message-ID: <6E21698722408147BEA594E073E2B0AB02634040@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: interim meeting - clarifications Thread-Index: AcbRwvXMsqpIY/7mRj6J8zeyR+3PIwABdAiQ From: "Hector Trevino \(htrevino\)" To: "Andy Bierman" Cc: X-OriginalArrivalTime: 06 Sep 2006 15:27:40.0624 (UTC) FILETIME=[FDAC7500:01C6D1C8] DKIM-Signature: a=rsa-sha1; q=dns; l=1871; t=1157556460; x=1158420460; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=htrevino@cisco.com; z=From:=22Hector=20Trevino=20\(htrevino\)=22=20 |Subject:RE=3A=20interim=20meeting=20-=20clarifications; X=v=3Dcisco.com=3B=20h=3DeMaM0lxmKDLaRqL0Tq8BqpOoz2o=3D; b=d80Pd4FJcQRxChPDiEpQq5f46vohrL/fK020uVq7QqO2MksYV1WQ3dHT9VP31eFQNe73r4Uo 0dp7R3izrOXIDUauebvB4163SIAmnigtKKDQNDkn2QC7PbuuC25EVWZQ; Authentication-Results: sj-dkim-3.cisco.com; header.From=htrevino@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Just to make sure... are you suggesting this to be included in the notifications draft or some new document to be done at a later time. =20 > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com]=20 > Sent: Wednesday, September 06, 2006 8:46 AM > To: Hector Trevino (htrevino) > Cc: netconf@ops.ietf.org > Subject: Re: interim meeting - clarifications >=20 > Hector Trevino (htrevino) wrote: > > =20 > > Andy, > > =20 > > =20 > > =20 > > From meeting minutes > >=20 > > 5.4) Filtering > >=20 > > =20 > >=20 > > The use of POSIX regular expressions is planned for this > >=20 > > feature. There are still a lot of details that need to > >=20 > > be written down before an interoperable filtering > >=20 > > mechanism (i.e., same NETCONF behavior across agents) > >=20 > > is fully defined. > >=20 > > =20 > >=20 > > It was noted that the function library of XPATH 2.0 supports > >=20 > > regular expressions in the function library. XPATH 1.0 does > >=20 > > not have something like that. > >=20 > > =20 > >=20 > > The authors will propose some text in the next revision of > >=20 > > the Notifications I-D. > >=20 > > =20 > > Question: The current notifications draft uses the same filtering=20 > > mechanism as those identified in the netconf protocol doc.=20 > Wouldn't it=20 > > be more appropriate to add this information (i.e. filtering using=20 > > XPATH 2.0 reg exp) to the main protocol document after it=20 > becomes an=20 > > RFC? By doing this we maintain the two docs in sync wrt=20 > filtering features. > > thanks > >=20 >=20 > IMO, it would be more appropriate to put this new filtering=20 > in a separate document, with its own capability. The base=20 > protocol doesn't need to change to add a new capability. >=20 >=20 > > Hector Trevino >=20 > Andy >=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 Wed Sep 06 11:32:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKzOP-0005yB-0N for netconf-archive@lists.ietf.org; Wed, 06 Sep 2006 11:32:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKzOM-0006Md-Ld for netconf-archive@lists.ietf.org; Wed, 06 Sep 2006 11:32:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzHw-000KJo-ST for netconf-data@psg.com; Wed, 06 Sep 2006 15:26:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GKzHw-000KJV-1j for netconf@ops.ietf.org; Wed, 06 Sep 2006 15:26:04 +0000 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 06 Sep 2006 08:26:04 -0700 X-IronPort-AV: i="4.08,221,1154934000"; d="scan'208,217"; a="318133669:sNHT52087156" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k86FQ3BZ006195 for ; Wed, 6 Sep 2006 08:26:03 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k86FQ3w7005250 for ; Wed, 6 Sep 2006 08:26:03 -0700 (PDT) Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Sep 2006 08:26:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D1C8.C3B8B7B4" Subject: interim notes - clarification #2 Date: Wed, 6 Sep 2006 08:26:02 -0700 Message-ID: <6E21698722408147BEA594E073E2B0AB0263403E@xmb-sjc-223.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: interim notes - clarification #2 Thread-Index: AcbRyMMn56LyTmgEQDG5tH0fewXd4Q== From: "Hector Trevino \(htrevino\)" To: X-OriginalArrivalTime: 06 Sep 2006 15:26:03.0491 (UTC) FILETIME=[C3C72330:01C6D1C8] DKIM-Signature: a=rsa-sha1; q=dns; l=4210; t=1157556363; x=1158420363; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=htrevino@cisco.com; z=From:=22Hector=20Trevino=20\(htrevino\)=22=20 |Subject:interim=20notes=20-=20clarification=20#2; X=v=3Dcisco.com=3B=20h=3DZ40O0nkB1Iz8cU2sTQ79I8Q9cCM=3D; b=D2yuBCutPPcbbM98WfxFwMHm9tY+0PWNQpqwdTsu1fOfhMQqNPhPSGh3lguvU40NaSOKUnHt Wr9OEgzhdvwxoS0Ue1Z4bpnQHe2Y+CdinHUsfNiv2qSCalsctMLfg0Zj; Authentication-Results: sj-dkim-6.cisco.com; header.From=htrevino@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D1C8.C3B8B7B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Andy, =20 =20 I'd like to get confirmation on the point below. While we discussed the ability to replay notifications and also buffering of newly generated notifications during replay, I don't recall getting concensus on this point (i.e. maintain temporal order of notifications in notification stream). Was this the group concensus? thanks=20 =20 =20 4.3) Live Notification Buffering =20 If an agent supports notification replay, then it must (should?)=20 also support the ability to defer delivery of new notifications while replayed notifications are currently being delivered on a particular session, thereby maintaining temporal order of the notification stream. =20 Hector Trevino Network Management Technology Group (NMTG) Cisco Systems Inc. Voice: 720-875-1369 Suite 400 Mobile: 303-619-3172 =20 9155 E. Nichols Ave Fax: 720-875-1414 Englewood, CO E-mail: htrevino@cisco.com 80112 =20 ------_=_NextPart_001_01C6D1C8.C3B8B7B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Andy,
 
 
I'd = like to get=20 confirmation on the point below. While we discussed the ability to = replay=20 notifications and also buffering of newly generated = notifications during=20 replay, I don't recall getting concensus on this point (i.e. maintain = temporal=20 order of notifications in notification stream). Was this the = group=20 concensus?
thanks 
 
 

4.3) Live=20 Notification Buffering

 

If an agent=20 supports notification replay, then it must (should?)

also support=20 the ability to defer delivery of new notifications

while replayed=20 notifications are currently being delivered

on a particular=20 session, thereby maintaining temporal order

of=20 the notification stream.
 
Hector Trevino
Network Management Technology =
Group (NMTG)
Cisco Systems Inc.        Voice:  720-875-1369
Suite =
400                 Mobile: 303-619-3172     
9155 E. Nichols Ave     =
  Fax:    720-875-1414
Englewood, CO             E-mail: =
htrevino@cisco.com
80112
 
------_=_NextPart_001_01C6D1C8.C3B8B7B4-- -- 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 Sep 06 12:30:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GL0IA-00007k-4F for netconf-archive@lists.ietf.org; Wed, 06 Sep 2006 12:30:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GL05h-0004La-LP for netconf-archive@lists.ietf.org; Wed, 06 Sep 2006 12:17:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL00Z-000PwD-4h for netconf-data@psg.com; Wed, 06 Sep 2006 16:12:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [205.178.146.54] (helo=omr4.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GL00Y-000Pvy-7L for netconf@ops.ietf.org; Wed, 06 Sep 2006 16:12:10 +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 k86GC7oj022600 for ; Wed, 6 Sep 2006 12:12:08 -0400 Received: (qmail 15591 invoked by uid 78); 6 Sep 2006 16:12:07 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 6 Sep 2006 16:12:07 -0000 Message-ID: <44FEF3C8.5050705@andybierman.com> Date: Wed, 06 Sep 2006 09:14:00 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Hector Trevino (htrevino)" CC: netconf@ops.ietf.org Subject: Re: interim meeting - clarifications References: <6E21698722408147BEA594E073E2B0AB02634040@xmb-sjc-223.amer.cisco.com> In-Reply-To: <6E21698722408147BEA594E073E2B0AB02634040@xmb-sjc-223.amer.cisco.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: b5d20af10c334b36874c0264b10f59f1 Hector Trevino (htrevino) wrote: > Just to make sure... are you suggesting this to be included in the > notifications draft or some new document to be done at a later time. > > I don't know: - how much text this capability needs - what the WG wants I think it would be fine to put it in the next Notifications draft, and after the WG reads it, this decision can be made by the WG. Andy >> -----Original Message----- >> From: Andy Bierman [mailto:ietf@andybierman.com] >> Sent: Wednesday, September 06, 2006 8:46 AM >> To: Hector Trevino (htrevino) >> Cc: netconf@ops.ietf.org >> Subject: Re: interim meeting - clarifications >> >> Hector Trevino (htrevino) wrote: >>> >>> Andy, >>> >>> >>> >>> From meeting minutes >>> >>> 5.4) Filtering >>> >>> >>> >>> The use of POSIX regular expressions is planned for this >>> >>> feature. There are still a lot of details that need to >>> >>> be written down before an interoperable filtering >>> >>> mechanism (i.e., same NETCONF behavior across agents) >>> >>> is fully defined. >>> >>> >>> >>> It was noted that the function library of XPATH 2.0 supports >>> >>> regular expressions in the function library. XPATH 1.0 does >>> >>> not have something like that. >>> >>> >>> >>> The authors will propose some text in the next revision of >>> >>> the Notifications I-D. >>> >>> >>> Question: The current notifications draft uses the same filtering >>> mechanism as those identified in the netconf protocol doc. >> Wouldn't it >>> be more appropriate to add this information (i.e. filtering using >>> XPATH 2.0 reg exp) to the main protocol document after it >> becomes an >>> RFC? By doing this we maintain the two docs in sync wrt >> filtering features. >>> thanks >>> >> IMO, it would be more appropriate to put this new filtering >> in a separate document, with its own capability. The base >> protocol doesn't need to change to add a new capability. >> >> >>> Hector Trevino >> 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 momomokoko@ocn.ne.jp Sat Sep 09 09:18:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GM2j1-00029J-Bd for NETCONF-ARCHIVE@LISTS.IETF.ORG; Sat, 09 Sep 2006 09:18:23 -0400 Received: from [222.173.203.77] (helo=so-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GM2is-000493-Li for NETCONF-ARCHIVE@LISTS.IETF.ORG; Sat, 09 Sep 2006 09:18:23 -0400 Received: from norlpp5 (unknown [199.197.97.77]) by smtp73 (Coremail) with SMTP id ViG3VQeI1JmLZIeT.1 for ; Sat, 09 Sep 2006 21:18:13 +0800 (CST) X-Originating-IP: [199.197.97.77] Subject: =?iso-2022-jp?B?GyRCMGxMaSEhGyhCMzYbJEI6UBsoQg==?= From: =?shift-jis?B?luyShoFAkF6U/A==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0128_01C6CF8D.EC1EAED0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db This is a multi-part message in MIME format. ------=_NextPart_000_0128_01C6CF8D.EC1EAED0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B>/$7%a!<%k8r$o$7$?46$8$G$O?5=E$G>/$7G:$_B?$$=w@-$@$J$C$F;W$C$F$?!#$*Cc$@$1$H8@$&LsB+$G2q$C$F8+$F!"!"!"OCJ9$$$F$"$2$k$H!VFH?H$KLa$j$?$$!W$C$F8@$o$l$F!":#$8$c%;%U%l$N4X78$G$9!#!#!V%3%D$O%^%a$K$9$k$3$H!*!*!W$G$9$M!*!*!!
=1B$B>/$7%a!<%k8r$o$7$?46$8$G$O?5=3DE$G>/$7G:$_B?$$=3Dw@-$@$J$C$F;W$= C$F$?!#$*Cc$@$1$H8@$&LsB+$G2q$C$F8+$F!"!"!"OCJ9$$$F$"$2$k$H!VFH?H$KLa$j$?= $$!W$C$F8@$o$l$F!":#$8$c%;%U%l$N4X78$G$9!#!#=1B(B=1B$B!V%3%D$O%^%a$K$9$k$3$H!*!*!W$G$9$M!*!*!!=1B(= B=1B$Bhttp://sruq.com/?nb03
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
=1B$B5qH]=1B(B
star_dast1000@yahoo.fr<= /DIV>

 
------=_NextPart_000_0128_01C6CF8D.EC1EAED0-- From yuiyuiyuichan@ocn.ne.jp Mon Sep 11 04:08:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMgqI-0003cT-5I for NETCONF-ARCHIVE@LISTS.IETF.ORG; Mon, 11 Sep 2006 04:08:34 -0400 Received: from [222.172.19.137] (helo=so-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMgqG-0003TD-2b for NETCONF-ARCHIVE@LISTS.IETF.ORG; Mon, 11 Sep 2006 04:08:34 -0400 Received: from ibn3 (unknown [112.192.55.26]) by smtp73 (Coremail) with SMTP id wZbTRrtr3M5JBz7W.1 for ; Mon, 11 Sep 2006 16:08:40 +0800 (CST) X-Originating-IP: [112.192.55.26] Subject: =?iso-2022-jp?B?GyRCJDMkbCRHJEkkJiRHJDckZyQmGyhC?= From: =?shift-jis?B?l0SI3w==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 $B5.J}$O$*6b$b=w$b(BSEX$B$bBg9%$-$G$O$"$j$^$;$s$+!)$=$l$,0l5$$K$OB(0)$$!"5U1o$r4uK>$7$F$k;v$,%"%s%1!<%HD4::$GJ,$+$j$^$7$?!#(B $B6C$/Dx!"4JC1$K%"%]$,) id 1GMkyp-0009QA-Br for netconf-data@psg.com; Mon, 11 Sep 2006 12:33:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GMkyo-0009P4-3D for netconf@ops.ietf.org; Mon, 11 Sep 2006 12:33:38 +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 k8BCXXl16064 for ; Mon, 11 Sep 2006 08:33:33 -0400 (EDT) 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: Proposed Changes to Notification Draft in -03 Date: Mon, 11 Sep 2006 08:33:31 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40AB6D17B@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Changes to Notification Draft in -03 thread-index: AcbVnn2COLHzXDVRRRarQUOt4A07Ew== From: "Sharon Chisholm" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi The following changes, based on the Montreal meeting, have been made to Netconf Event Notification draft that will be posted shortly. Note that as there have been some rather large changes to the document, we have not noted previous section numbers or exact text being deleted, modified or added, but rather summarize the changes. Please let us know now if there are any comments on this. Document changes 1. Removed all appendices (agent initiated sessions, syslog transport, configuration change notifications) 2. Removed all content related information from the header (eventClasses, sequenceNumber, timestamp, etc.) and related discussions. These concepts are now only used in examples within the tag. 3. Made corrections to subtree filtering examples (only OR operations supported) 4. Removed notion of mixed mode (i.e. ability to issue commands and receive event notifications on a single session/channel). Related operations (e.g. , removed) 5. Modified read-only (monitoring) data model for agent notification (subscription) activity to reflect protocol changes.=20 6. Introduced the concept of event streams 7. Introduced a default NETCONF notifications stream=20 8. Added schemas to support retrieval of event streams information to aid subscription process 9. Modified to accept name of event stream 10. Added capability to support event notification replay 11. Clarified the subscription lifecycle (transient, only valid for the life of the session) 12. No specialized "get-*" operations. Using standard NETCONF operations for retrieval of notification related information 13. Note that replay requires dedicated subscription. This was done to avoid having to deal with in-order delivery of notification (i.e. temporal delivery) which puts a delay on the delivery of new notifications.=20 14. Fixed some Schema bugs 15. Updated Requirements Section reflecting Montreal meeting 16. Added definition of subscription to section 1.1 17. Deleted old discussion on architecture in favour of some figured based on Phil's draft shown later in the document. 18. Deleted discussion on how to declare something is a notification within the XML Schema. 19. Removed detailed discussion of syslog. Sharon Chisholm Nortel=20 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 Tue Sep 12 11:26:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNA9R-0007vX-Gx for netconf-archive@lists.ietf.org; Tue, 12 Sep 2006 11:26:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNA9Q-0000sQ-6N for netconf-archive@lists.ietf.org; Tue, 12 Sep 2006 11:26:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNA2Y-000O3K-3X for netconf-data@psg.com; Tue, 12 Sep 2006 15:19:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [205.178.146.59] (helo=omr9.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNA2T-000O2y-SB for netconf@ops.ietf.org; Tue, 12 Sep 2006 15:19:06 +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 k8CFItIu004011 for ; Tue, 12 Sep 2006 11:19:01 -0400 Received: (qmail 31806 invoked by uid 78); 12 Sep 2006 15:18:55 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 12 Sep 2006 15:18:55 -0000 Message-ID: <4506CFD7.1040805@andybierman.com> Date: Tue, 12 Sep 2006 08:18:47 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Netconf (E-mail)" , Netconf Data Model Discussion Subject: Why Phil is right about vs. 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: 50a516d93fd399dc60588708fd9a3002 Hi, First, I am not going to say we need to stop using . I just going to point out a critical SNMP problem the XMLCONF design team really wanted to fix -- but didn't. The root problem in NE management today is the relative expense and difficulty in adding new agent functionality into NE devices. SNMP Set failed for 3 reasons: 1) Casting high-level procedures as a "100 bits of peek/poke data" is an Unnatural Act that never had a chance of succeeding. 2) One generic "edit" PDU that can contain an arbitrary mix of arbitrarily incomplete high-level operations (i.e. varbinds), dispensed like gumballs, across an arbitrary number of Set PDUs. 3) In accordance with the Postel Principle, the agent needs to code for complex (legal) Set PDUs the manager should never ever use. NETCONF has better error reporting then SNMP, but the complexity of implementing in an optimal manner is non-trivial. In contrast, none of the arbitrary mix-and-match "Gumball API" problems exist with RPCs. The agent automation complexity is dramatically lower than for . Agent callback chains can handle hard problems like resource reservation and rollback much easier as well. The approach is much better for managers, because an "object-oriented API" can easily be mapped to services or classes, and the set of methods defined for them. The "fly in the ointment" is the startup config file (e.g., show running config). This data-centric view of the configuration state is heavily used, and not going away any time soon. The trick is finding the right mix of heuristics, mappings, and special RPCs, so both views of the NE device can be easily supported. 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 Tue Sep 12 11:57:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNAe5-0001oY-Lx for netconf-archive@lists.ietf.org; Tue, 12 Sep 2006 11:57:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNAe4-0005hv-8s for netconf-archive@lists.ietf.org; Tue, 12 Sep 2006 11:57:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNAXO-0001MA-Rb for netconf-data@psg.com; Tue, 12 Sep 2006 15:51:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [135.245.0.37] (helo=ihemail3.lucent.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNAXL-0001LT-H3 for netconf@ops.ietf.org; Tue, 12 Sep 2006 15:50:59 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k8CFoOHs015540; Tue, 12 Sep 2006 10:50:29 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 12 Sep 2006 17:50:23 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550AA9741E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Andy Bierman , "Netconf (E-mail)" , Netconf Data Model Discussion Subject: RE: Why Phil is right about vs. Date: Tue, 12 Sep 2006 17:50:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Having implemented the SNMP engine for both agent and manager side I can wholeheartedly support Andy's points 2 and 3 below as to why the SNMP SET command has been much much more complex than it needs to be. It is one of the reasons why I am advocating these days that in a MIB MODULE, oine adds a MODULE-COMPLIANCE that allows to "not support" the createAndWait mechanism. But that is only a small piece of the problem. Bert > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Andy Bierman > Sent: Tuesday, September 12, 2006 17:19 > To: Netconf (E-mail); Netconf Data Model Discussion > Subject: Why Phil is right about vs. > > > Hi, > > First, I am not going to say we need to stop using . > I just going to point out a critical SNMP problem the XMLCONF design > team really wanted to fix -- but didn't. > > The root problem in NE management today is the relative expense > and difficulty in adding new agent functionality into NE devices. > > SNMP Set failed for 3 reasons: > 1) Casting high-level procedures as a "100 bits of peek/poke data" > is an Unnatural Act that never had a chance of succeeding. > 2) One generic "edit" PDU that can contain an arbitrary mix > of arbitrarily incomplete high-level operations (i.e. varbinds), > dispensed like gumballs, across an arbitrary number of Set PDUs. > 3) In accordance with the Postel Principle, the agent needs to code > for complex (legal) Set PDUs the manager should never ever use. > > NETCONF has better error reporting then SNMP, but the complexity > of implementing in an optimal manner is non-trivial. > > In contrast, none of the arbitrary mix-and-match "Gumball > API" problems > exist with RPCs. The agent automation complexity is > dramatically lower than for . Agent callback chains > can handle hard problems like resource reservation and rollback > much easier as well. > > The approach is much better for managers, > because an "object-oriented API" can easily be mapped to > services or classes, and the set of methods defined for them. > > The "fly in the ointment" is the startup config file > (e.g., show running config). This data-centric view > of the configuration state is heavily used, and not going > away any time soon. The trick is finding the right mix > of heuristics, mappings, and special RPCs, so both views > of the NE device can be easily supported. > > > > 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 Wed Sep 13 22:47:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNhFm-0001fk-9P for netconf-archive@lists.ietf.org; Wed, 13 Sep 2006 22:47:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNhFi-0002IR-U5 for netconf-archive@lists.ietf.org; Wed, 13 Sep 2006 22:47:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNh9X-000Kpg-EX for netconf-data@psg.com; Thu, 14 Sep 2006 02:40:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [205.178.146.59] (helo=omr9.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNh9W-000KpH-3w for netconf@ops.ietf.org; Thu, 14 Sep 2006 02:40:34 +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 k8E2eWlx023110 for ; Wed, 13 Sep 2006 22:40:33 -0400 Received: (qmail 13967 invoked by uid 78); 14 Sep 2006 02:40:32 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 14 Sep 2006 02:40:32 -0000 Message-ID: <4508C111.6000309@andybierman.com> Date: Wed, 13 Sep 2006 19:40:17 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Sharon Chisholm CC: netconf@ops.ietf.org Subject: Re: Proposed Changes to Notification Draft in -03 References: <713043CE8B8E1348AF3C546DBE02C1B40AB6D17B@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B40AB6D17B@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: d0bdc596f8dd1c226c458f0b4df27a88 Sharon Chisholm wrote: > Hi > > The following changes, based on the Montreal meeting, have been made to > Netconf Event Notification draft that will be posted shortly. Note that > as there have been some rather large changes to the document, we have > not noted previous section numbers or exact text being deleted, modified > or added, but rather summarize the changes. Please let us know now if > there are any comments on this. > Looks great! Looks like a lot of work too. thanks, Andy > Document changes > > 1. Removed all appendices (agent initiated sessions, syslog > transport, configuration change notifications) > 2. Removed all content related information from the header > (eventClasses, sequenceNumber, timestamp, etc.) and related discussions. > These concepts are now only used in examples within the tag. > 3. Made corrections to subtree filtering examples (only OR > operations supported) > 4. Removed notion of mixed mode (i.e. ability to issue commands and > receive event notifications on a single session/channel). Related > operations (e.g. , removed) > 5. Modified read-only (monitoring) data model for agent > notification (subscription) activity to reflect protocol changes. > 6. Introduced the concept of event streams > 7. Introduced a default NETCONF notifications stream > 8. Added schemas to support retrieval of event streams information > to aid subscription process > 9. Modified to accept name of event stream > 10. Added capability to support event notification replay > 11. Clarified the subscription lifecycle (transient, only valid for > the life of the session) > 12. No specialized "get-*" operations. Using standard NETCONF > operations for retrieval of notification related information > 13. Note that replay requires dedicated subscription. This was done > to avoid having to deal with in-order delivery of notification (i.e. > temporal delivery) which puts a delay on the delivery of new > notifications. > 14. Fixed some Schema bugs > 15. Updated Requirements Section reflecting Montreal meeting > 16. Added definition of subscription to section 1.1 > 17. Deleted old discussion on architecture in favour of some figured > based on Phil's draft shown later in the document. > 18. Deleted discussion on how to declare something is a notification > within the XML Schema. > 19. Removed detailed discussion of syslog. > > 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: > > -- 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 Sep 14 11:32:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtCf-0001Q0-IT for netconf-archive@lists.ietf.org; Thu, 14 Sep 2006 11:32:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNtCe-0003yO-Uj for netconf-archive@lists.ietf.org; Thu, 14 Sep 2006 11:32:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNt2Z-000NT6-UQ for netconf-data@psg.com; Thu, 14 Sep 2006 15:22:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [204.127.200.81] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GNt2W-000NSF-Os for netconf@ops.ietf.org; Thu, 14 Sep 2006 15:22:08 +0000 Received: from harrington73653 (c-24-61-222-235.hsd1.nh.comcast.net[24.61.222.235]) by comcast.net (sccrmhc11) with SMTP id <2006091415215601100s0vhde>; Thu, 14 Sep 2006 15:22:07 +0000 From: "David B Harrington" To: "'Andy Bierman'" , "'Netconf \(E-mail\)'" , "'Netconf Data Model Discussion'" Subject: RE: Why Phil is right about vs. Date: Thu, 14 Sep 2006 11:20:01 -0400 Message-ID: <048201c6d811$45700250$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbWf9pmBGd0T5RUR46D0bvr8BT6xQBghTHQ In-reply-to: <4506CFD7.1040805@andybierman.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Hi, I agree that RPCs are needed to help reduce complexity of SET functionality. I also think we need to understand how to standardize and functionality for interoperability across vendors. -- data versus functions -- I have commented in the past about the comparison of NM approaches to programming languages. SNMP uses the peek/poke approach of an assembly language, a 2nd generation programming language. The CLI is the equivalent of a 3rd generation language, such as Fortran, Cobol, C, or Pascal. It is function-oriented. This is much more "natural" for a human being to use, as it is task oriented. An important feature of later functional languages is the concept of variable scope. Functions may touch any data anywhere in the application space, and this can cause bugs when one function's code modifies a variable that another function expects to remain constant (or at least not to change in a "volatile" manner). To constrain the side-effects of modifying variables, langauges like C introduced the concepts of function-scope (local variables) and file scope (structures only modifiable by functions in the same file that defines the structures). Object-oriented, the fourth generation of langauges, takes it a step further by having data that is specific to an object that is only modifiable by the fucntions (methods) of the object. In this way, the data definition is unknown except internally. Objects in an O-O environment also are derivable from base classes, promoting hierarchical reuse. I stopped following the evolution of programming languages at fourth generation, but I think the fifth generation is the use of remote procedure calls and the existence of "objects" callable across the network. This requires the ability to build components that are largely self-sufficient and have a "public" interface to manipulate its private data (an extension of the data hiding from 3rdgen scope and 4thgen "data hiding"). Why am I suddenly giving lessons in programming langauges? Because we need to decide where on the continuum netconf should fit, and much of that decision will have to do with the incompatibility of standard data models and global functions such as the RPC, and the concepts of data hiding. -- iteration and an object-oriented hierarchy -- I have programmed in C++ for years, working on a NMS application that used object-oriented design for modeling the network. Each device model had public methods and hidden data. One of the toughest problems we ran into was "searching the network" for specific data, because it required having a search routine for every object, and a search routine that iterated through every object in the hierarchy. Of course, we could derive objects from a base class that has a search method that could iterately call the search method for all derived classes. Derivation is hard to work with, and an object hierarchy is hard to get right in a manner that works for multiple "world-views"; how one models the hierarchy depends a lot on what you are trying to achieve. To do , we will probably need to define a RPC for every object you plan to use to modularize the hierarchy (I assume a capability might represent the definition of an object), and we will a consistent varbind format to report the object's data, and roll the data up into a complete picture of the configuration. And ideally, the "varbind" format will not place any restrictions on implementation-specific decisions of data modeling within the "object". Assuming the "objects" will exist in some type of hierarchy, it will probably be necessary to define a mechanism for "rolling up" the data through the hierarchy. For instance, calling the for a chassis might cause the chassis code to iterate through for each blade in the chassis, and combine these subordinate configs with the chassis's own config information. And because you don't want each blade's trgggered by the chassis AND by a direct iterative , we will need to make some provision for recognizing when a complete subtree has been queried by the command. Mayeb Xpath already solves this iteration problem. -- sets versus gets -- RPCs are needed to help reduce complexity of SET functionality. But what about RPCs? I suggest we consider a system that uses only functions for SET functionality, and uses both global and RPCs. can make the functionality addressable in a standardized manner, make modification of data "gumballs" predictable, and make the details implementation-specific to a large degree (support data hiding and proprietary schema pieces). I expect we will want to standardize portions of a data model into a standard schema, and allow this to be supplemented with vendor-specific parameters in one or more supplemental schemas. The and operations should have a standard reporting format to improve interoperability, and to promote the development of standard data models for monitoring and cross-vendor comparison capabiltities. Failure to impose some standards on the format of the returned values leads to the problem faced today by operators trying to use expect scripts to parse through inconsistent and constantly changing proprietary CLI data models. XML will help, but will fall short if each vendor uses different schemas for the same functionality. One area this WG has not discussed is how to do access control. This has been pushed off as data-model-dependent. But if the interface to functinoality will be functions rather than peek/poke, then access control should probably be applied to each function, not to the underlying gumballs of data that might get modified. It is possible that two types of access control will be required - read access might be best modeled as data-hierarchy-centric, while write access might be best modeled as function-centric. Of course, if we bundle data and functions into objects, and the hierarchy is at the object level, then access control could be object-centric, and we would avoid the overkill of per-variable access control. P.s. it might be worthwhile looking at the <*-config> commands as being an object as well, and the and commands are methods specific to managing the functionality of a "running config" object. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, September 12, 2006 11:19 AM > To: Netconf (E-mail); Netconf Data Model Discussion > Subject: Why Phil is right about vs. > > Hi, > > First, I am not going to say we need to stop using . > I just going to point out a critical SNMP problem the XMLCONF design > team really wanted to fix -- but didn't. > > The root problem in NE management today is the relative expense > and difficulty in adding new agent functionality into NE devices. > > SNMP Set failed for 3 reasons: > 1) Casting high-level procedures as a "100 bits of peek/poke data" > is an Unnatural Act that never had a chance of succeeding. > 2) One generic "edit" PDU that can contain an arbitrary mix > of arbitrarily incomplete high-level operations (i.e. varbinds), > dispensed like gumballs, across an arbitrary number of Set PDUs. > 3) In accordance with the Postel Principle, the agent needs to code > for complex (legal) Set PDUs the manager should never ever use. > > NETCONF has better error reporting then SNMP, but the complexity > of implementing in an optimal manner is non-trivial. > > In contrast, none of the arbitrary mix-and-match "Gumball > API" problems > exist with RPCs. The agent automation complexity is > dramatically lower than for . Agent callback chains > can handle hard problems like resource reservation and rollback > much easier as well. > > The approach is much better for managers, > because an "object-oriented API" can easily be mapped to > services or classes, and the set of methods defined for them. > > The "fly in the ointment" is the startup config file > (e.g., show running config). This data-centric view > of the configuration state is heavily used, and not going > away any time soon. The trick is finding the right mix > of heuristics, mappings, and special RPCs, so both views > of the NE device can be easily supported. > > > > 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 Sep 14 21:37:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GO2e4-0005g6-8p for netconf-archive@lists.ietf.org; Thu, 14 Sep 2006 21:37:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GO2e1-0002aU-Iw for netconf-archive@lists.ietf.org; Thu, 14 Sep 2006 21:37:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GO2WP-0001GN-Gz for netconf-data@psg.com; Fri, 15 Sep 2006 01:29:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [205.178.146.58] (helo=omr8.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GO2WN-0001G9-Ee for netconf@ops.ietf.org; Fri, 15 Sep 2006 01:29:36 +0000 Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k8F1TYBg026786 for ; Thu, 14 Sep 2006 21:29:34 -0400 Received: (qmail 823 invoked by uid 78); 15 Sep 2006 01:29:33 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 15 Sep 2006 01:29:33 -0000 Message-ID: <450A01F6.7070609@andybierman.com> Date: Thu, 14 Sep 2006 18:29:26 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: David B Harrington CC: "'Netconf (E-mail)'" , "'Netconf Data Model Discussion'" Subject: Re: Why Phil is right about vs. References: <048201c6d811$45700250$0400a8c0@china.huawei.com> In-Reply-To: <048201c6d811$45700250$0400a8c0@china.huawei.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: b84f8c8fba0e1389e5eb998b64078964 David B Harrington wrote: > Hi, Interesting comments. One quick reply on access control: I think we need a comprehensive tiered access control model that works for any RPC on any data. RPC invocation has to be the basis of the model, or a device can't be properly secured when vendor RPCs are used. At a minimum, we need to: 1) check that the user is allowed to invoke the specific RPC method 2) if relevant, check that the data under (or other data root elements) can be accessed by this user as requested (granularity TBD) - minimum granularity is at (read, write) - maximum NETCONF granularity is (create, delete, merge, replace) Andy > > I agree that RPCs are needed to help reduce complexity > of SET functionality. > > I also think we need to understand how to standardize and > functionality for interoperability across vendors. > > -- data versus functions -- > > I have commented in the past about the comparison of NM approaches to > programming languages. > SNMP uses the peek/poke approach of an assembly language, a 2nd > generation programming language. > > The CLI is the equivalent of a 3rd generation language, such as > Fortran, Cobol, C, or Pascal. It is function-oriented. This is much > more "natural" for a human being to use, as it is task oriented. An > important feature of later functional languages is the concept of > variable scope. Functions may touch any data anywhere in the > application space, and this can cause bugs when one function's code > modifies a variable that another function expects to remain constant > (or at least not to change in a "volatile" manner). To constrain the > side-effects of modifying variables, langauges like C introduced the > concepts of function-scope (local variables) and file scope > (structures only modifiable by functions in the same file that defines > the structures). > > Object-oriented, the fourth generation of langauges, takes it a step > further by having data that is specific to an object that is only > modifiable by the fucntions (methods) of the object. In this way, the > data definition is unknown except internally. Objects in an O-O > environment also are derivable from base classes, promoting > hierarchical reuse. > > I stopped following the evolution of programming languages at fourth > generation, but I think the fifth generation is the use of remote > procedure calls and the existence of "objects" callable across the > network. This requires the ability to build components that are > largely self-sufficient and have a "public" interface to manipulate > its private data (an extension of the data hiding from 3rdgen scope > and 4thgen "data hiding"). > > Why am I suddenly giving lessons in programming langauges? Because we > need to decide where on the continuum netconf should fit, and much of > that decision will have to do with the incompatibility of standard > data models and global functions such as the RPC, and the > concepts of data hiding. > > -- iteration and an object-oriented hierarchy -- > > I have programmed in C++ for years, working on a NMS application that > used object-oriented design for modeling the network. Each device > model had public methods and hidden data. One of the toughest problems > we ran into was "searching the network" for specific data, because it > required having a search routine for every object, and a search > routine that iterated through every object in the hierarchy. > > Of course, we could derive objects from a base class that has a search > method that could iterately call the search method for all derived > classes. Derivation is hard to work with, and an object hierarchy is > hard to get right in a manner that works for multiple "world-views"; > how one models the hierarchy depends a lot on what you are trying to > achieve. > > To do , we will probably need to define a RPC > for every object you plan to use to modularize the hierarchy (I assume > a capability might represent the definition of an object), and we will > a consistent varbind format to report the object's data, and roll the > data up into a complete picture of the configuration. And ideally, the > "varbind" format will not place any restrictions on > implementation-specific decisions of data modeling within the > "object". > > Assuming the "objects" will exist in some type of hierarchy, it will > probably be necessary to define a mechanism for "rolling up" the data > through the hierarchy. For instance, calling the for a > chassis might cause the chassis code to iterate through > for each blade in the chassis, and combine these subordinate configs > with the chassis's own config information. And because you don't want > each blade's trgggered by the chassis AND by a direct > iterative , we will need to make some provision for > recognizing when a complete subtree has been queried by the > command. Mayeb Xpath already solves this iteration > problem. > > -- sets versus gets -- > > RPCs are needed to help reduce complexity of SET > functionality. But what about RPCs? > > I suggest we consider a system that uses only functions > for SET functionality, and uses both global and > RPCs. > > can make the functionality addressable in a > standardized manner, make modification of data "gumballs" predictable, > and make the details implementation-specific to a large degree > (support data hiding and proprietary schema pieces). I expect we will > want to standardize portions of a data model into a standard > schema, and allow this to be supplemented with vendor-specific > parameters in one or more supplemental schemas. > > The and operations should have a standard > reporting format to improve interoperability, and to promote the > development of standard data models for monitoring and cross-vendor > comparison capabiltities. Failure to impose some standards on the > format of the returned values leads to the problem faced today by > operators trying to use expect scripts to parse through inconsistent > and constantly changing proprietary CLI data models. XML will help, > but will fall short if each vendor uses different schemas for the same > functionality. > > One area this WG has not discussed is how to do access control. This > has been pushed off as data-model-dependent. But if the interface to > functinoality will be functions rather than peek/poke, then access > control should probably be applied to each function, not to the > underlying gumballs of data that might get modified. > > It is possible that two types of access control will be required - > read access might be best modeled as data-hierarchy-centric, while > write access might be best modeled as function-centric. Of course, if > we bundle data and functions into objects, and the hierarchy is at the > object level, then access control could be object-centric, and we > would avoid the overkill of per-variable access control. > > P.s. it might be worthwhile looking at the <*-config> commands as > being an object as well, and the and > commands are methods specific to managing the functionality of a > "running config" object. > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > > > >> -----Original Message----- >> From: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >> Sent: Tuesday, September 12, 2006 11:19 AM >> To: Netconf (E-mail); Netconf Data Model Discussion >> Subject: Why Phil is right about vs. >> >> Hi, >> >> First, I am not going to say we need to stop using . >> I just going to point out a critical SNMP problem the XMLCONF design >> team really wanted to fix -- but didn't. >> >> The root problem in NE management today is the relative expense >> and difficulty in adding new agent functionality into NE devices. >> >> SNMP Set failed for 3 reasons: >> 1) Casting high-level procedures as a "100 bits of peek/poke data" >> is an Unnatural Act that never had a chance of succeeding. >> 2) One generic "edit" PDU that can contain an arbitrary mix >> of arbitrarily incomplete high-level operations (i.e. varbinds), >> dispensed like gumballs, across an arbitrary number of Set PDUs. >> 3) In accordance with the Postel Principle, the agent needs to code >> for complex (legal) Set PDUs the manager should never ever use. >> >> NETCONF has better error reporting then SNMP, but the complexity >> of implementing in an optimal manner is non-trivial. >> >> In contrast, none of the arbitrary mix-and-match "Gumball >> API" problems >> exist with RPCs. The agent automation complexity is >> dramatically lower than for . Agent callback chains >> can handle hard problems like resource reservation and rollback >> much easier as well. >> >> The approach is much better for managers, >> because an "object-oriented API" can easily be mapped to >> services or classes, and the set of methods defined for them. >> >> The "fly in the ointment" is the startup config file >> (e.g., show running config). This data-centric view >> of the configuration state is heavily used, and not going >> away any time soon. The trick is finding the right mix >> of heuristics, mappings, and special RPCs, so both views >> of the NE device can be easily supported. >> >> >> >> 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 Mon Sep 18 05:56:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPFr8-0000T4-L0 for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 05:56:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPFca-0004ek-6u for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 05:41:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPFVd-000NZ5-Rj for netconf-data@psg.com; Mon, 18 Sep 2006 09:33:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPFVX-000NYH-FA for netconf@ops.ietf.org; Mon, 18 Sep 2006 09:33:44 +0000 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 57F4A8E0001 for ; Mon, 18 Sep 2006 11:33:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 11:33:41 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 11:33:40 +0200 Message-ID: <450E67F4.3030206@ericsson.com> Date: Mon, 18 Sep 2006 11:33:40 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: "'Netconf (E-mail)'" Subject: Access control References: <048201c6d811$45700250$0400a8c0@china.huawei.com> <450A01F6.7070609@andybierman.com> In-Reply-To: <450A01F6.7070609@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Sep 2006 09:33:40.0633 (UTC) FILETIME=[869C0890:01C6DB05] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Hello, One specific problem we have with access control: It would be nice if we could check access control just based on the incoming RPC, the userID/group and his access control rights; without a need to know what is already in the datastore. However if I get a request like (in approximate netconf): Up and the user has read rights on all parts of the data model but write rights only on the adminstate but not on the interface level I have a problem. Depending on the current content of the datastore might be - a request to create the interface which must be denied - a reference to an existing eth0 interface, so the request should be allowed. Is there any easy solution for this? Balazs PS. Generally I believe with it's four operation possibilities is a complex thing to implement. In some cases it would be enough to allow only "null" as a default operation and only create/delete (and maybe replace) as subsequent operations. This would make life much easier for some nodes. Sadly merge is mandatory in the draft. Andy Bierman wrote: > David B Harrington wrote: >> Hi, > > Interesting comments. > One quick reply on access control: > > I think we need a comprehensive tiered access control > model that works for any RPC on any data. RPC invocation > has to be the basis of the model, or a device can't be properly > secured when vendor RPCs are used. > > At a minimum, we need to: > > 1) check that the user is allowed to invoke the specific RPC method > 2) if relevant, check that the data under (or other data root > elements) > can be accessed by this user as requested (granularity TBD) > - minimum granularity is at (read, write) > - maximum NETCONF granularity is (create, delete, merge, replace) > > > Andy > >> >> I agree that RPCs are needed to help reduce complexity >> of SET functionality. >> I also think we need to understand how to standardize and >> functionality for interoperability across vendors. >> >> -- data versus functions -- >> >> I have commented in the past about the comparison of NM approaches to >> programming languages. >> SNMP uses the peek/poke approach of an assembly language, a 2nd >> generation programming language. >> >> The CLI is the equivalent of a 3rd generation language, such as >> Fortran, Cobol, C, or Pascal. It is function-oriented. This is much >> more "natural" for a human being to use, as it is task oriented. An >> important feature of later functional languages is the concept of >> variable scope. Functions may touch any data anywhere in the >> application space, and this can cause bugs when one function's code >> modifies a variable that another function expects to remain constant >> (or at least not to change in a "volatile" manner). To constrain the >> side-effects of modifying variables, langauges like C introduced the >> concepts of function-scope (local variables) and file scope >> (structures only modifiable by functions in the same file that defines >> the structures). >> >> Object-oriented, the fourth generation of langauges, takes it a step >> further by having data that is specific to an object that is only >> modifiable by the fucntions (methods) of the object. In this way, the >> data definition is unknown except internally. Objects in an O-O >> environment also are derivable from base classes, promoting >> hierarchical reuse. >> I stopped following the evolution of programming languages at fourth >> generation, but I think the fifth generation is the use of remote >> procedure calls and the existence of "objects" callable across the >> network. This requires the ability to build components that are >> largely self-sufficient and have a "public" interface to manipulate >> its private data (an extension of the data hiding from 3rdgen scope >> and 4thgen "data hiding"). >> >> Why am I suddenly giving lessons in programming langauges? Because we >> need to decide where on the continuum netconf should fit, and much of >> that decision will have to do with the incompatibility of standard >> data models and global functions such as the RPC, and the >> concepts of data hiding. >> >> -- iteration and an object-oriented hierarchy -- >> >> I have programmed in C++ for years, working on a NMS application that >> used object-oriented design for modeling the network. Each device >> model had public methods and hidden data. One of the toughest problems >> we ran into was "searching the network" for specific data, because it >> required having a search routine for every object, and a search >> routine that iterated through every object in the hierarchy. >> Of course, we could derive objects from a base class that has a search >> method that could iterately call the search method for all derived >> classes. Derivation is hard to work with, and an object hierarchy is >> hard to get right in a manner that works for multiple "world-views"; >> how one models the hierarchy depends a lot on what you are trying to >> achieve. >> >> To do , we will probably need to define a RPC >> for every object you plan to use to modularize the hierarchy (I assume >> a capability might represent the definition of an object), and we will >> a consistent varbind format to report the object's data, and roll the >> data up into a complete picture of the configuration. And ideally, the >> "varbind" format will not place any restrictions on >> implementation-specific decisions of data modeling within the >> "object". >> >> Assuming the "objects" will exist in some type of hierarchy, it will >> probably be necessary to define a mechanism for "rolling up" the data >> through the hierarchy. For instance, calling the for a >> chassis might cause the chassis code to iterate through >> for each blade in the chassis, and combine these subordinate configs >> with the chassis's own config information. And because you don't want >> each blade's trgggered by the chassis AND by a direct >> iterative , we will need to make some provision for >> recognizing when a complete subtree has been queried by the >> command. Mayeb Xpath already solves this iteration >> problem. >> >> -- sets versus gets -- >> >> RPCs are needed to help reduce complexity of SET >> functionality. But what about RPCs? >> >> I suggest we consider a system that uses only functions >> for SET functionality, and uses both global and >> RPCs. >> can make the functionality addressable in a >> standardized manner, make modification of data "gumballs" predictable, >> and make the details implementation-specific to a large degree >> (support data hiding and proprietary schema pieces). I expect we will >> want to standardize portions of a data model into a standard >> schema, and allow this to be supplemented with vendor-specific >> parameters in one or more supplemental schemas. >> >> The and operations should have a standard >> reporting format to improve interoperability, and to promote the >> development of standard data models for monitoring and cross-vendor >> comparison capabiltities. Failure to impose some standards on the >> format of the returned values leads to the problem faced today by >> operators trying to use expect scripts to parse through inconsistent >> and constantly changing proprietary CLI data models. XML will help, >> but will fall short if each vendor uses different schemas for the same >> functionality. >> >> One area this WG has not discussed is how to do access control. This >> has been pushed off as data-model-dependent. But if the interface to >> functinoality will be functions rather than peek/poke, then access >> control should probably be applied to each function, not to the >> underlying gumballs of data that might get modified. >> >> It is possible that two types of access control will be required - >> read access might be best modeled as data-hierarchy-centric, while >> write access might be best modeled as function-centric. Of course, if >> we bundle data and functions into objects, and the hierarchy is at the >> object level, then access control could be object-centric, and we >> would avoid the overkill of per-variable access control. >> >> P.s. it might be worthwhile looking at the <*-config> commands as >> being an object as well, and the and >> commands are methods specific to managing the functionality of a >> "running config" object. >> David Harrington >> dharrington@huawei.com dbharrington@comcast.net >> ietfdbh@comcast.net >> >> >> >> >>> -----Original Message----- >>> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] >>> On Behalf Of Andy Bierman >>> Sent: Tuesday, September 12, 2006 11:19 AM >>> To: Netconf (E-mail); Netconf Data Model Discussion >>> Subject: Why Phil is right about vs. >>> >>> Hi, >>> >>> First, I am not going to say we need to stop using . >>> I just going to point out a critical SNMP problem the XMLCONF design >>> team really wanted to fix -- but didn't. >>> >>> The root problem in NE management today is the relative expense >>> and difficulty in adding new agent functionality into NE devices. >>> >>> SNMP Set failed for 3 reasons: >>> 1) Casting high-level procedures as a "100 bits of peek/poke data" >>> is an Unnatural Act that never had a chance of succeeding. >>> 2) One generic "edit" PDU that can contain an arbitrary mix >>> of arbitrarily incomplete high-level operations (i.e. varbinds), >>> dispensed like gumballs, across an arbitrary number of Set PDUs. >>> 3) In accordance with the Postel Principle, the agent needs to code >>> for complex (legal) Set PDUs the manager should never ever use. >>> >>> NETCONF has better error reporting then SNMP, but the complexity >>> of implementing in an optimal manner is non-trivial. >>> >>> In contrast, none of the arbitrary mix-and-match "Gumball API" problems >>> exist with RPCs. The agent automation complexity is >>> dramatically lower than for . Agent callback chains >>> can handle hard problems like resource reservation and rollback >>> much easier as well. >>> >>> The approach is much better for managers, >>> because an "object-oriented API" can easily be mapped to >>> services or classes, and the set of methods defined for them. >>> >>> The "fly in the ointment" is the startup config file >>> (e.g., show running config). This data-centric view >>> of the configuration state is heavily used, and not going >>> away any time soon. The trick is finding the right mix >>> of heuristics, mappings, and special RPCs, so both views >>> of the NE device can be easily supported. >>> >>> >>> >>> 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: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- 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 Sep 18 06:15:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPGAA-00081e-3s for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 06:15:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPGA1-0002IN-Bh for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 06:15:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPG57-0000w9-B5 for netconf-data@psg.com; Mon, 18 Sep 2006 10:10:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [152.81.144.101] (helo=mailironport2.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPG52-0000vM-LK for netconf@ops.ietf.org; Mon, 18 Sep 2006 10:10:25 +0000 Received: from sydney.loria.fr (HELO [152.81.8.136]) ([152.81.8.136]) by mailironport2.loria.fr with ESMTP; 18 Sep 2006 12:10:22 +0200 X-IronPort-AV: i="4.09,180,1157320800"; d="vcf'?scan'208"; a="4088:sNHT25426296" Message-ID: <450E7072.7090605@loria.fr> Date: Mon, 18 Sep 2006 12:09:54 +0200 From: Vincent Cridlig User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: Balazs Lengyel CC: "'Netconf (E-mail)'" Subject: Re: Access control References: <048201c6d811$45700250$0400a8c0@china.huawei.com> <450A01F6.7070609@andybierman.com> <450E67F4.3030206@ericsson.com> In-Reply-To: <450E67F4.3030206@ericsson.com> Content-Type: multipart/mixed; boundary="------------030507010303050701050508" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 This is a multi-part message in MIME format. --------------030507010303050701050508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hello, I have the same problem. We control access before calling MIB modules for executing the request. The reason is that we don't want each module to implement access control. This is too costly. The second reason is that if several modules have to be called for the same request and one module decides that access should be denied, we have to rollback the other modules. However, because of the merge operation and the default operation concept, sometimes only the MIB modules know what concretely must be done on the config. What we did until know is to deny the operation when the context does not allow the access control process to decide. And we specify as precisely as possible the requests on the manager side (using the operation attribute). Regards, Vincent Balazs Lengyel a écrit : > Hello, > One specific problem we have with access control: > > It would be nice if we could check access control just based on the > incoming RPC, the userID/group and his access control rights; without > a need to know what is already in the datastore. However if I get a > request like (in approximate netconf): > > > > > Up > > > > > and the user has read rights on all parts of the data model but write > rights only on the adminstate but not on the interface level I have a > problem. > Depending on the current content of the datastore > might be > - a request to create the interface which must be denied > - a reference to an existing eth0 interface, so the request should be > allowed. > > Is there any easy solution for this? > > Balazs > > PS. Generally I believe with it's four operation > possibilities is a complex thing to implement. In some cases it would > be enough to allow only "null" as a default operation and only > create/delete (and maybe replace) as subsequent operations. This would > make life much easier for some nodes. Sadly merge is mandatory in the > draft. > > > Andy Bierman wrote: >> David B Harrington wrote: >>> Hi, >> >> Interesting comments. >> One quick reply on access control: >> >> I think we need a comprehensive tiered access control >> model that works for any RPC on any data. RPC invocation >> has to be the basis of the model, or a device can't be properly >> secured when vendor RPCs are used. >> >> At a minimum, we need to: >> >> 1) check that the user is allowed to invoke the specific RPC method >> 2) if relevant, check that the data under (or other data >> root elements) >> can be accessed by this user as requested (granularity TBD) >> - minimum granularity is at (read, write) >> - maximum NETCONF granularity is (create, delete, merge, replace) >> >> >> Andy >> >>> >>> I agree that RPCs are needed to help reduce complexity >>> of SET functionality. >>> I also think we need to understand how to standardize and >>> functionality for interoperability across vendors. >>> >>> -- data versus functions -- >>> >>> I have commented in the past about the comparison of NM approaches to >>> programming languages. >>> SNMP uses the peek/poke approach of an assembly language, a 2nd >>> generation programming language. >>> >>> The CLI is the equivalent of a 3rd generation language, such as >>> Fortran, Cobol, C, or Pascal. It is function-oriented. This is much >>> more "natural" for a human being to use, as it is task oriented. An >>> important feature of later functional languages is the concept of >>> variable scope. Functions may touch any data anywhere in the >>> application space, and this can cause bugs when one function's code >>> modifies a variable that another function expects to remain constant >>> (or at least not to change in a "volatile" manner). To constrain the >>> side-effects of modifying variables, langauges like C introduced the >>> concepts of function-scope (local variables) and file scope >>> (structures only modifiable by functions in the same file that defines >>> the structures). >>> >>> Object-oriented, the fourth generation of langauges, takes it a step >>> further by having data that is specific to an object that is only >>> modifiable by the fucntions (methods) of the object. In this way, the >>> data definition is unknown except internally. Objects in an O-O >>> environment also are derivable from base classes, promoting >>> hierarchical reuse. >>> I stopped following the evolution of programming languages at fourth >>> generation, but I think the fifth generation is the use of remote >>> procedure calls and the existence of "objects" callable across the >>> network. This requires the ability to build components that are >>> largely self-sufficient and have a "public" interface to manipulate >>> its private data (an extension of the data hiding from 3rdgen scope >>> and 4thgen "data hiding"). >>> >>> Why am I suddenly giving lessons in programming langauges? Because we >>> need to decide where on the continuum netconf should fit, and much of >>> that decision will have to do with the incompatibility of standard >>> data models and global functions such as the RPC, and the >>> concepts of data hiding. >>> >>> -- iteration and an object-oriented hierarchy -- >>> >>> I have programmed in C++ for years, working on a NMS application that >>> used object-oriented design for modeling the network. Each device >>> model had public methods and hidden data. One of the toughest problems >>> we ran into was "searching the network" for specific data, because it >>> required having a search routine for every object, and a search >>> routine that iterated through every object in the hierarchy. >>> Of course, we could derive objects from a base class that has a search >>> method that could iterately call the search method for all derived >>> classes. Derivation is hard to work with, and an object hierarchy is >>> hard to get right in a manner that works for multiple "world-views"; >>> how one models the hierarchy depends a lot on what you are trying to >>> achieve. >>> >>> To do , we will probably need to define a RPC >>> for every object you plan to use to modularize the hierarchy (I assume >>> a capability might represent the definition of an object), and we will >>> a consistent varbind format to report the object's data, and roll the >>> data up into a complete picture of the configuration. And ideally, the >>> "varbind" format will not place any restrictions on >>> implementation-specific decisions of data modeling within the >>> "object". >>> >>> Assuming the "objects" will exist in some type of hierarchy, it will >>> probably be necessary to define a mechanism for "rolling up" the data >>> through the hierarchy. For instance, calling the for a >>> chassis might cause the chassis code to iterate through >>> for each blade in the chassis, and combine these subordinate configs >>> with the chassis's own config information. And because you don't want >>> each blade's trgggered by the chassis AND by a direct >>> iterative , we will need to make some provision for >>> recognizing when a complete subtree has been queried by the >>> command. Mayeb Xpath already solves this iteration >>> problem. >>> >>> -- sets versus gets -- >>> >>> RPCs are needed to help reduce complexity of SET >>> functionality. But what about RPCs? >>> >>> I suggest we consider a system that uses only functions >>> for SET functionality, and uses both global and >>> RPCs. >>> can make the functionality addressable in a >>> standardized manner, make modification of data "gumballs" predictable, >>> and make the details implementation-specific to a large degree >>> (support data hiding and proprietary schema pieces). I expect we will >>> want to standardize portions of a data model into a standard >>> schema, and allow this to be supplemented with vendor-specific >>> parameters in one or more supplemental schemas. >>> >>> The and operations should have a standard >>> reporting format to improve interoperability, and to promote the >>> development of standard data models for monitoring and cross-vendor >>> comparison capabiltities. Failure to impose some standards on the >>> format of the returned values leads to the problem faced today by >>> operators trying to use expect scripts to parse through inconsistent >>> and constantly changing proprietary CLI data models. XML will help, >>> but will fall short if each vendor uses different schemas for the same >>> functionality. >>> >>> One area this WG has not discussed is how to do access control. This >>> has been pushed off as data-model-dependent. But if the interface to >>> functinoality will be functions rather than peek/poke, then access >>> control should probably be applied to each function, not to the >>> underlying gumballs of data that might get modified. >>> >>> It is possible that two types of access control will be required - >>> read access might be best modeled as data-hierarchy-centric, while >>> write access might be best modeled as function-centric. Of course, if >>> we bundle data and functions into objects, and the hierarchy is at the >>> object level, then access control could be object-centric, and we >>> would avoid the overkill of per-variable access control. >>> >>> P.s. it might be worthwhile looking at the <*-config> commands as >>> being an object as well, and the and >>> commands are methods specific to managing the functionality of a >>> "running config" object. >>> David Harrington >>> dharrington@huawei.com dbharrington@comcast.net >>> ietfdbh@comcast.net >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: owner-netconf@ops.ietf.org >>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>>> Sent: Tuesday, September 12, 2006 11:19 AM >>>> To: Netconf (E-mail); Netconf Data Model Discussion >>>> Subject: Why Phil is right about vs. >>>> >>>> Hi, >>>> >>>> First, I am not going to say we need to stop using . >>>> I just going to point out a critical SNMP problem the XMLCONF design >>>> team really wanted to fix -- but didn't. >>>> >>>> The root problem in NE management today is the relative expense >>>> and difficulty in adding new agent functionality into NE devices. >>>> >>>> SNMP Set failed for 3 reasons: >>>> 1) Casting high-level procedures as a "100 bits of peek/poke data" >>>> is an Unnatural Act that never had a chance of succeeding. >>>> 2) One generic "edit" PDU that can contain an arbitrary mix >>>> of arbitrarily incomplete high-level operations (i.e. varbinds), >>>> dispensed like gumballs, across an arbitrary number of Set PDUs. >>>> 3) In accordance with the Postel Principle, the agent needs to code >>>> for complex (legal) Set PDUs the manager should never ever use. >>>> >>>> NETCONF has better error reporting then SNMP, but the complexity >>>> of implementing in an optimal manner is non-trivial. >>>> >>>> In contrast, none of the arbitrary mix-and-match "Gumball API" >>>> problems >>>> exist with RPCs. The agent automation complexity is >>>> dramatically lower than for . Agent callback chains >>>> can handle hard problems like resource reservation and rollback >>>> much easier as well. >>>> >>>> The approach is much better for managers, >>>> because an "object-oriented API" can easily be mapped to >>>> services or classes, and the set of methods defined for them. >>>> >>>> The "fly in the ointment" is the startup config file >>>> (e.g., show running config). This data-centric view >>>> of the configuration state is heavily used, and not going >>>> away any time soon. The trick is finding the right mix >>>> of heuristics, mappings, and special RPCs, so both views >>>> of the NE device can be easily supported. >>>> >>>> >>>> >>>> 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: > --------------030507010303050701050508 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vincent.cridlig.vcf" begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine, France;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------030507010303050701050508-- -- 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 Sep 18 10:51:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKTP-0003Lx-7e for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 10:51:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPKTA-0007on-On for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 10:51:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPKL3-000225-E1 for netconf-data@psg.com; Mon, 18 Sep 2006 14:43:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPKKy-0001zZ-VU for netconf@ops.ietf.org; Mon, 18 Sep 2006 14:43:09 +0000 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k8IEh7rb013648 for ; Mon, 18 Sep 2006 10:43:07 -0400 Received: (qmail 24689 invoked by uid 78); 18 Sep 2006 14:43:06 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 18 Sep 2006 14:43:06 -0000 Message-ID: <450EB000.3010906@andybierman.com> Date: Mon, 18 Sep 2006 07:41:04 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Vincent Cridlig CC: Balazs Lengyel , "'Netconf (E-mail)'" Subject: Re: Access control References: <048201c6d811$45700250$0400a8c0@china.huawei.com> <450A01F6.7070609@andybierman.com> <450E67F4.3030206@ericsson.com> <450E7072.7090605@loria.fr> In-Reply-To: <450E7072.7090605@loria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Vincent Cridlig wrote: > Hello, > > I have the same problem. > We control access before calling MIB modules for executing the request. > The reason is that we don't want each module to implement access > control. This is too costly. > The second reason is that if several modules have to be called for the > same request and one module decides that access should be denied, we > have to rollback the other modules. > IMO, both of your approaches are flawed. You have to check each child node against the target, from the root to every leaf node. This is no different than checking every parameter in a CLI command. You might want to check access control in the validation phase, before anything in the target config is actually touched. If you don't have a non-destructive validation phase, then you have to do a rollback-on-error (if supported and requested). Andy > However, because of the merge operation and the default operation > concept, sometimes only the MIB modules know what concretely must be > done on the config. > > What we did until know is to deny the operation when the context does > not allow the access control process to decide. > And we specify as precisely as possible the requests on the manager side > (using the operation attribute). > > Regards, > Vincent > > Balazs Lengyel a écrit : >> Hello, >> One specific problem we have with access control: >> >> It would be nice if we could check access control just based on the >> incoming RPC, the userID/group and his access control rights; without >> a need to know what is already in the datastore. However if I get a >> request like (in approximate netconf): >> >> >> >> >> Up >> >> >> >> >> and the user has read rights on all parts of the data model but write >> rights only on the adminstate but not on the interface level I have a >> problem. >> Depending on the current content of the datastore >> might be >> - a request to create the interface which must be denied >> - a reference to an existing eth0 interface, so the request should be >> allowed. >> >> Is there any easy solution for this? >> >> Balazs >> >> PS. Generally I believe with it's four operation >> possibilities is a complex thing to implement. In some cases it would >> be enough to allow only "null" as a default operation and only >> create/delete (and maybe replace) as subsequent operations. This would >> make life much easier for some nodes. Sadly merge is mandatory in the >> draft. >> >> >> Andy Bierman wrote: >>> David B Harrington wrote: >>>> Hi, >>> >>> Interesting comments. >>> One quick reply on access control: >>> >>> I think we need a comprehensive tiered access control >>> model that works for any RPC on any data. RPC invocation >>> has to be the basis of the model, or a device can't be properly >>> secured when vendor RPCs are used. >>> >>> At a minimum, we need to: >>> >>> 1) check that the user is allowed to invoke the specific RPC method >>> 2) if relevant, check that the data under (or other data >>> root elements) >>> can be accessed by this user as requested (granularity TBD) >>> - minimum granularity is at (read, write) >>> - maximum NETCONF granularity is (create, delete, merge, replace) >>> >>> >>> Andy >>> >>>> >>>> I agree that RPCs are needed to help reduce complexity >>>> of SET functionality. >>>> I also think we need to understand how to standardize and >>>> functionality for interoperability across vendors. >>>> >>>> -- data versus functions -- >>>> >>>> I have commented in the past about the comparison of NM approaches to >>>> programming languages. >>>> SNMP uses the peek/poke approach of an assembly language, a 2nd >>>> generation programming language. >>>> >>>> The CLI is the equivalent of a 3rd generation language, such as >>>> Fortran, Cobol, C, or Pascal. It is function-oriented. This is much >>>> more "natural" for a human being to use, as it is task oriented. An >>>> important feature of later functional languages is the concept of >>>> variable scope. Functions may touch any data anywhere in the >>>> application space, and this can cause bugs when one function's code >>>> modifies a variable that another function expects to remain constant >>>> (or at least not to change in a "volatile" manner). To constrain the >>>> side-effects of modifying variables, langauges like C introduced the >>>> concepts of function-scope (local variables) and file scope >>>> (structures only modifiable by functions in the same file that defines >>>> the structures). >>>> >>>> Object-oriented, the fourth generation of langauges, takes it a step >>>> further by having data that is specific to an object that is only >>>> modifiable by the fucntions (methods) of the object. In this way, the >>>> data definition is unknown except internally. Objects in an O-O >>>> environment also are derivable from base classes, promoting >>>> hierarchical reuse. >>>> I stopped following the evolution of programming languages at fourth >>>> generation, but I think the fifth generation is the use of remote >>>> procedure calls and the existence of "objects" callable across the >>>> network. This requires the ability to build components that are >>>> largely self-sufficient and have a "public" interface to manipulate >>>> its private data (an extension of the data hiding from 3rdgen scope >>>> and 4thgen "data hiding"). >>>> >>>> Why am I suddenly giving lessons in programming langauges? Because we >>>> need to decide where on the continuum netconf should fit, and much of >>>> that decision will have to do with the incompatibility of standard >>>> data models and global functions such as the RPC, and the >>>> concepts of data hiding. >>>> >>>> -- iteration and an object-oriented hierarchy -- >>>> >>>> I have programmed in C++ for years, working on a NMS application that >>>> used object-oriented design for modeling the network. Each device >>>> model had public methods and hidden data. One of the toughest problems >>>> we ran into was "searching the network" for specific data, because it >>>> required having a search routine for every object, and a search >>>> routine that iterated through every object in the hierarchy. >>>> Of course, we could derive objects from a base class that has a search >>>> method that could iterately call the search method for all derived >>>> classes. Derivation is hard to work with, and an object hierarchy is >>>> hard to get right in a manner that works for multiple "world-views"; >>>> how one models the hierarchy depends a lot on what you are trying to >>>> achieve. >>>> >>>> To do , we will probably need to define a RPC >>>> for every object you plan to use to modularize the hierarchy (I assume >>>> a capability might represent the definition of an object), and we will >>>> a consistent varbind format to report the object's data, and roll the >>>> data up into a complete picture of the configuration. And ideally, the >>>> "varbind" format will not place any restrictions on >>>> implementation-specific decisions of data modeling within the >>>> "object". >>>> >>>> Assuming the "objects" will exist in some type of hierarchy, it will >>>> probably be necessary to define a mechanism for "rolling up" the data >>>> through the hierarchy. For instance, calling the for a >>>> chassis might cause the chassis code to iterate through >>>> for each blade in the chassis, and combine these subordinate configs >>>> with the chassis's own config information. And because you don't want >>>> each blade's trgggered by the chassis AND by a direct >>>> iterative , we will need to make some provision for >>>> recognizing when a complete subtree has been queried by the >>>> command. Mayeb Xpath already solves this iteration >>>> problem. >>>> >>>> -- sets versus gets -- >>>> >>>> RPCs are needed to help reduce complexity of SET >>>> functionality. But what about RPCs? >>>> >>>> I suggest we consider a system that uses only functions >>>> for SET functionality, and uses both global and >>>> RPCs. >>>> can make the functionality addressable in a >>>> standardized manner, make modification of data "gumballs" predictable, >>>> and make the details implementation-specific to a large degree >>>> (support data hiding and proprietary schema pieces). I expect we will >>>> want to standardize portions of a data model into a standard >>>> schema, and allow this to be supplemented with vendor-specific >>>> parameters in one or more supplemental schemas. >>>> >>>> The and operations should have a standard >>>> reporting format to improve interoperability, and to promote the >>>> development of standard data models for monitoring and cross-vendor >>>> comparison capabiltities. Failure to impose some standards on the >>>> format of the returned values leads to the problem faced today by >>>> operators trying to use expect scripts to parse through inconsistent >>>> and constantly changing proprietary CLI data models. XML will help, >>>> but will fall short if each vendor uses different schemas for the same >>>> functionality. >>>> >>>> One area this WG has not discussed is how to do access control. This >>>> has been pushed off as data-model-dependent. But if the interface to >>>> functinoality will be functions rather than peek/poke, then access >>>> control should probably be applied to each function, not to the >>>> underlying gumballs of data that might get modified. >>>> >>>> It is possible that two types of access control will be required - >>>> read access might be best modeled as data-hierarchy-centric, while >>>> write access might be best modeled as function-centric. Of course, if >>>> we bundle data and functions into objects, and the hierarchy is at the >>>> object level, then access control could be object-centric, and we >>>> would avoid the overkill of per-variable access control. >>>> >>>> P.s. it might be worthwhile looking at the <*-config> commands as >>>> being an object as well, and the and >>>> commands are methods specific to managing the functionality of a >>>> "running config" object. >>>> David Harrington >>>> dharrington@huawei.com dbharrington@comcast.net >>>> ietfdbh@comcast.net >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: owner-netconf@ops.ietf.org >>>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>>>> Sent: Tuesday, September 12, 2006 11:19 AM >>>>> To: Netconf (E-mail); Netconf Data Model Discussion >>>>> Subject: Why Phil is right about vs. >>>>> >>>>> Hi, >>>>> >>>>> First, I am not going to say we need to stop using . >>>>> I just going to point out a critical SNMP problem the XMLCONF design >>>>> team really wanted to fix -- but didn't. >>>>> >>>>> The root problem in NE management today is the relative expense >>>>> and difficulty in adding new agent functionality into NE devices. >>>>> >>>>> SNMP Set failed for 3 reasons: >>>>> 1) Casting high-level procedures as a "100 bits of peek/poke data" >>>>> is an Unnatural Act that never had a chance of succeeding. >>>>> 2) One generic "edit" PDU that can contain an arbitrary mix >>>>> of arbitrarily incomplete high-level operations (i.e. varbinds), >>>>> dispensed like gumballs, across an arbitrary number of Set PDUs. >>>>> 3) In accordance with the Postel Principle, the agent needs to code >>>>> for complex (legal) Set PDUs the manager should never ever use. >>>>> >>>>> NETCONF has better error reporting then SNMP, but the complexity >>>>> of implementing in an optimal manner is non-trivial. >>>>> >>>>> In contrast, none of the arbitrary mix-and-match "Gumball API" >>>>> problems >>>>> exist with RPCs. The agent automation complexity is >>>>> dramatically lower than for . Agent callback chains >>>>> can handle hard problems like resource reservation and rollback >>>>> much easier as well. >>>>> >>>>> The approach is much better for managers, >>>>> because an "object-oriented API" can easily be mapped to >>>>> services or classes, and the set of methods defined for them. >>>>> >>>>> The "fly in the ointment" is the startup config file >>>>> (e.g., show running config). This data-centric view >>>>> of the configuration state is heavily used, and not going >>>>> away any time soon. The trick is finding the right mix >>>>> of heuristics, mappings, and special RPCs, so both views >>>>> of the NE device can be easily supported. >>>>> >>>>> >>>>> >>>>> 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: >> > -- 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 Sep 18 11:42:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPLFw-0002pe-IQ for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 11:42:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPLFo-0007Vh-Oz for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 11:42:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPL8Q-0007Po-Db for netconf-data@psg.com; Mon, 18 Sep 2006 15:34:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [152.81.144.101] (helo=mailironport2.loria.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPL8L-0007Nv-Cu for netconf@ops.ietf.org; Mon, 18 Sep 2006 15:34:09 +0000 Received: from sydney.loria.fr (HELO [152.81.8.136]) ([152.81.8.136]) by mailironport2.loria.fr with ESMTP; 18 Sep 2006 17:34:06 +0200 X-IronPort-AV: i="4.09,181,1157320800"; d="vcf'?scan'208"; a="4365:sNHT25573653" Message-ID: <450EBC52.6020700@loria.fr> Date: Mon, 18 Sep 2006 17:33:38 +0200 From: Vincent Cridlig User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: Andy Bierman , "'Netconf (E-mail)'" Subject: Re: Access control References: <048201c6d811$45700250$0400a8c0@china.huawei.com> <450A01F6.7070609@andybierman.com> <450E67F4.3030206@ericsson.com> <450E7072.7090605@loria.fr> <450EB000.3010906@andybierman.com> In-Reply-To: <450EB000.3010906@andybierman.com> Content-Type: multipart/mixed; boundary="------------080806020004020908090204" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 This is a multi-part message in MIME format. --------------080806020004020908090204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Andy Bierman a écrit : > Vincent Cridlig wrote: >> Hello, >> >> I have the same problem. >> We control access before calling MIB modules for executing the >> request. The reason is that we don't want each module to implement >> access control. This is too costly. >> The second reason is that if several modules have to be called for >> the same request and one module decides that access should be denied, >> we have to rollback the other modules. >> > > IMO, both of your approaches are flawed. > You have to check each child node against the target, > from the root to every leaf node. I would argue that it depends a lot on how you specified your access control model, for example, if you specify permissions by subtrees, by MIB modules, ... rather than by nodes. > This is no different > than checking every parameter in a CLI command. > > You might want to check access control in the validation phase, > before anything in the target config is actually touched. > If you don't have a non-destructive validation phase, then > you have to do a rollback-on-error (if supported and requested). I fully agree with you on that. My only wish is to make the MIB module developement as easy as possible, meaning no access control knowledge within modules. Of course, my position may be very specific to our implementation ;-) Regards, Vincent > > > Andy > >> However, because of the merge operation and the default operation >> concept, sometimes only the MIB modules know what concretely must be >> done on the config. >> >> What we did until know is to deny the operation when the context does >> not allow the access control process to decide. >> And we specify as precisely as possible the requests on the manager >> side (using the operation attribute). >> >> Regards, >> Vincent >> >> Balazs Lengyel a écrit : >>> Hello, >>> One specific problem we have with access control: >>> >>> It would be nice if we could check access control just based on the >>> incoming RPC, the userID/group and his access control rights; >>> without a need to know what is already in the datastore. However if >>> I get a request like (in approximate netconf): >>> >>> >>> >>> >>> Up >>> >>> >>> >>> >>> and the user has read rights on all parts of the data model but >>> write rights only on the adminstate but not on the interface level I >>> have a problem. >>> Depending on the current content of the datastore >>> might be >>> - a request to create the interface which must be denied >>> - a reference to an existing eth0 interface, so the request should >>> be allowed. >>> >>> Is there any easy solution for this? >>> >>> Balazs >>> >>> PS. Generally I believe with it's four operation >>> possibilities is a complex thing to implement. In some cases it >>> would be enough to allow only "null" as a default operation and only >>> create/delete (and maybe replace) as subsequent operations. This >>> would make life much easier for some nodes. Sadly merge is mandatory >>> in the draft. >>> >>> >>> Andy Bierman wrote: >>>> David B Harrington wrote: >>>>> Hi, >>>> >>>> Interesting comments. >>>> One quick reply on access control: >>>> >>>> I think we need a comprehensive tiered access control >>>> model that works for any RPC on any data. RPC invocation >>>> has to be the basis of the model, or a device can't be properly >>>> secured when vendor RPCs are used. >>>> >>>> At a minimum, we need to: >>>> >>>> 1) check that the user is allowed to invoke the specific RPC method >>>> 2) if relevant, check that the data under (or other data >>>> root elements) >>>> can be accessed by this user as requested (granularity TBD) >>>> - minimum granularity is at (read, write) >>>> - maximum NETCONF granularity is (create, delete, merge, replace) >>>> >>>> >>>> Andy >>>> >>>>> >>>>> I agree that RPCs are needed to help reduce complexity >>>>> of SET functionality. >>>>> I also think we need to understand how to standardize and >>>>> functionality for interoperability across vendors. >>>>> >>>>> -- data versus functions -- >>>>> >>>>> I have commented in the past about the comparison of NM approaches to >>>>> programming languages. >>>>> SNMP uses the peek/poke approach of an assembly language, a 2nd >>>>> generation programming language. >>>>> >>>>> The CLI is the equivalent of a 3rd generation language, such as >>>>> Fortran, Cobol, C, or Pascal. It is function-oriented. This is much >>>>> more "natural" for a human being to use, as it is task oriented. An >>>>> important feature of later functional languages is the concept of >>>>> variable scope. Functions may touch any data anywhere in the >>>>> application space, and this can cause bugs when one function's code >>>>> modifies a variable that another function expects to remain constant >>>>> (or at least not to change in a "volatile" manner). To constrain the >>>>> side-effects of modifying variables, langauges like C introduced the >>>>> concepts of function-scope (local variables) and file scope >>>>> (structures only modifiable by functions in the same file that >>>>> defines >>>>> the structures). >>>>> >>>>> Object-oriented, the fourth generation of langauges, takes it a step >>>>> further by having data that is specific to an object that is only >>>>> modifiable by the fucntions (methods) of the object. In this way, the >>>>> data definition is unknown except internally. Objects in an O-O >>>>> environment also are derivable from base classes, promoting >>>>> hierarchical reuse. >>>>> I stopped following the evolution of programming languages at fourth >>>>> generation, but I think the fifth generation is the use of remote >>>>> procedure calls and the existence of "objects" callable across the >>>>> network. This requires the ability to build components that are >>>>> largely self-sufficient and have a "public" interface to manipulate >>>>> its private data (an extension of the data hiding from 3rdgen scope >>>>> and 4thgen "data hiding"). >>>>> >>>>> Why am I suddenly giving lessons in programming langauges? Because we >>>>> need to decide where on the continuum netconf should fit, and much of >>>>> that decision will have to do with the incompatibility of standard >>>>> data models and global functions such as the RPC, and >>>>> the >>>>> concepts of data hiding. >>>>> >>>>> -- iteration and an object-oriented hierarchy -- >>>>> >>>>> I have programmed in C++ for years, working on a NMS application that >>>>> used object-oriented design for modeling the network. Each device >>>>> model had public methods and hidden data. One of the toughest >>>>> problems >>>>> we ran into was "searching the network" for specific data, because it >>>>> required having a search routine for every object, and a search >>>>> routine that iterated through every object in the hierarchy. >>>>> Of course, we could derive objects from a base class that has a >>>>> search >>>>> method that could iterately call the search method for all derived >>>>> classes. Derivation is hard to work with, and an object hierarchy is >>>>> hard to get right in a manner that works for multiple "world-views"; >>>>> how one models the hierarchy depends a lot on what you are trying to >>>>> achieve. >>>>> >>>>> To do , we will probably need to define a >>>>> RPC >>>>> for every object you plan to use to modularize the hierarchy (I >>>>> assume >>>>> a capability might represent the definition of an object), and we >>>>> will >>>>> a consistent varbind format to report the object's data, and roll the >>>>> data up into a complete picture of the configuration. And ideally, >>>>> the >>>>> "varbind" format will not place any restrictions on >>>>> implementation-specific decisions of data modeling within the >>>>> "object". >>>>> >>>>> Assuming the "objects" will exist in some type of hierarchy, it will >>>>> probably be necessary to define a mechanism for "rolling up" the data >>>>> through the hierarchy. For instance, calling the for a >>>>> chassis might cause the chassis code to iterate through >>>>> for each blade in the chassis, and combine these subordinate configs >>>>> with the chassis's own config information. And because you don't want >>>>> each blade's trgggered by the chassis AND by a direct >>>>> iterative , we will need to make some provision for >>>>> recognizing when a complete subtree has been queried by the >>>>> command. Mayeb Xpath already solves this iteration >>>>> problem. >>>>> >>>>> -- sets versus gets -- >>>>> >>>>> RPCs are needed to help reduce complexity of SET >>>>> functionality. But what about RPCs? >>>>> >>>>> I suggest we consider a system that uses only functions >>>>> for SET functionality, and uses both global and >>>>> RPCs. >>>>> can make the functionality addressable in a >>>>> standardized manner, make modification of data "gumballs" >>>>> predictable, >>>>> and make the details implementation-specific to a large degree >>>>> (support data hiding and proprietary schema pieces). I expect we will >>>>> want to standardize portions of a data model into a standard >>>>> schema, and allow this to be supplemented with vendor-specific >>>>> parameters in one or more supplemental schemas. >>>>> >>>>> The and operations should have a standard >>>>> reporting format to improve interoperability, and to promote the >>>>> development of standard data models for monitoring and cross-vendor >>>>> comparison capabiltities. Failure to impose some standards on the >>>>> format of the returned values leads to the problem faced today by >>>>> operators trying to use expect scripts to parse through inconsistent >>>>> and constantly changing proprietary CLI data models. XML will help, >>>>> but will fall short if each vendor uses different schemas for the >>>>> same >>>>> functionality. >>>>> >>>>> One area this WG has not discussed is how to do access control. This >>>>> has been pushed off as data-model-dependent. But if the interface to >>>>> functinoality will be functions rather than peek/poke, then access >>>>> control should probably be applied to each function, not to the >>>>> underlying gumballs of data that might get modified. >>>>> >>>>> It is possible that two types of access control will be required - >>>>> read access might be best modeled as data-hierarchy-centric, while >>>>> write access might be best modeled as function-centric. Of course, if >>>>> we bundle data and functions into objects, and the hierarchy is at >>>>> the >>>>> object level, then access control could be object-centric, and we >>>>> would avoid the overkill of per-variable access control. >>>>> >>>>> P.s. it might be worthwhile looking at the <*-config> commands as >>>>> being an object as well, and the and >>>>> commands are methods specific to managing the functionality of a >>>>> "running config" object. >>>>> David Harrington >>>>> dharrington@huawei.com dbharrington@comcast.net >>>>> ietfdbh@comcast.net >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: owner-netconf@ops.ietf.org >>>>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>>>>> Sent: Tuesday, September 12, 2006 11:19 AM >>>>>> To: Netconf (E-mail); Netconf Data Model Discussion >>>>>> Subject: Why Phil is right about vs. >>>>>> >>>>>> Hi, >>>>>> >>>>>> First, I am not going to say we need to stop using . >>>>>> I just going to point out a critical SNMP problem the XMLCONF design >>>>>> team really wanted to fix -- but didn't. >>>>>> >>>>>> The root problem in NE management today is the relative expense >>>>>> and difficulty in adding new agent functionality into NE devices. >>>>>> >>>>>> SNMP Set failed for 3 reasons: >>>>>> 1) Casting high-level procedures as a "100 bits of peek/poke data" >>>>>> is an Unnatural Act that never had a chance of succeeding. >>>>>> 2) One generic "edit" PDU that can contain an arbitrary mix >>>>>> of arbitrarily incomplete high-level operations (i.e. varbinds), >>>>>> dispensed like gumballs, across an arbitrary number of Set PDUs. >>>>>> 3) In accordance with the Postel Principle, the agent needs to code >>>>>> for complex (legal) Set PDUs the manager should never ever use. >>>>>> >>>>>> NETCONF has better error reporting then SNMP, but the complexity >>>>>> of implementing in an optimal manner is non-trivial. >>>>>> >>>>>> In contrast, none of the arbitrary mix-and-match "Gumball API" >>>>>> problems >>>>>> exist with RPCs. The agent automation complexity is >>>>>> dramatically lower than for . Agent callback chains >>>>>> can handle hard problems like resource reservation and rollback >>>>>> much easier as well. >>>>>> >>>>>> The approach is much better for managers, >>>>>> because an "object-oriented API" can easily be mapped to >>>>>> services or classes, and the set of methods defined for them. >>>>>> >>>>>> The "fly in the ointment" is the startup config file >>>>>> (e.g., show running config). This data-centric view >>>>>> of the configuration state is heavily used, and not going >>>>>> away any time soon. The trick is finding the right mix >>>>>> of heuristics, mappings, and special RPCs, so both views >>>>>> of the NE device can be easily supported. >>>>>> >>>>>> >>>>>> >>>>>> 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: >>> >> > > > -- > 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: --------------080806020004020908090204 Content-Type: text/x-vcard; charset=utf-8; name="vincent.cridlig.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vincent.cridlig.vcf" begin:vcard fn:Vincent Cridlig n:Cridlig;Vincent org:LORIA - INRIA Lorraine, France;Madynes adr:;;;Nancy;;;France email;internet:cridligv@loria.fr title:PhD Student tel;work:+33 (0)3 83 59 20 48 url:http://www.loria.fr/~cridligv version:2.1 end:vcard --------------080806020004020908090204-- -- 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 Sep 18 11:49:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPLN2-0005g1-5K for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 11:49:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPLMt-00018A-9K for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 11:49:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPLHW-0008NX-OH for netconf-data@psg.com; Mon, 18 Sep 2006 15:43:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPLHQ-0008N2-BY for netconf@ops.ietf.org; Mon, 18 Sep 2006 15:43:33 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F26EC8E0001; Mon, 18 Sep 2006 17:43:30 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 17:43:30 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 17:43:29 +0200 Message-ID: <450EBEA1.20403@ericsson.com> Date: Mon, 18 Sep 2006 17:43:29 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Andy Bierman CC: Vincent Cridlig , "'Netconf (E-mail)'" Subject: Re: Access control References: <048201c6d811$45700250$0400a8c0@china.huawei.com> <450A01F6.7070609@andybierman.com> <450E67F4.3030206@ericsson.com> <450E7072.7090605@loria.fr> <450EB000.3010906@andybierman.com> In-Reply-To: <450EB000.3010906@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Sep 2006 15:43:29.0667 (UTC) FILETIME=[304DED30:01C6DB39] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Hello, Does this mean, that in your opinion it is NOT Possible to do access control without the information: what is stored already in the datastore? Balazs Andy Bierman wrote: > IMO, both of your approaches are flawed. > You have to check each child node against the target, > from the root to every leaf node. This is no different > than checking every parameter in a CLI command. > > You might want to check access control in the validation phase, > before anything in the target config is actually touched. > If you don't have a non-destructive validation phase, then > you have to do a rollback-on-error (if supported and requested). > > > Andy >> >> Balazs Lengyel a écrit : >>> Hello, >>> One specific problem we have with access control: >>> >>> It would be nice if we could check access control just based on the >>> incoming RPC, the userID/group and his access control rights; without >>> a need to know what is already in the datastore. However if I get a >>> request like (in approximate netconf): >>> >>> >>> >>> >>> Up >>> >>> >>> >>> >>> and the user has read rights on all parts of the data model but write >>> rights only on the adminstate but not on the interface level I have a >>> problem. >>> Depending on the current content of the datastore >>> might be >>> - a request to create the interface which must be denied >>> - a reference to an existing eth0 interface, so the request should be >>> allowed. >>> >>> Is there any easy solution for this? >>> >>> Balazs >>> >>> PS. Generally I believe with it's four operation >>> possibilities is a complex thing to implement. In some cases it would >>> be enough to allow only "null" as a default operation and only >>> create/delete (and maybe replace) as subsequent operations. This >>> would make life much easier for some nodes. Sadly merge is mandatory >>> in the draft. >>> >>> >>> Andy Bierman wrote: >>>> David B Harrington wrote: >>>>> Hi, >>>> >>>> Interesting comments. >>>> One quick reply on access control: >>>> >>>> I think we need a comprehensive tiered access control >>>> model that works for any RPC on any data. RPC invocation >>>> has to be the basis of the model, or a device can't be properly >>>> secured when vendor RPCs are used. >>>> >>>> At a minimum, we need to: >>>> >>>> 1) check that the user is allowed to invoke the specific RPC method >>>> 2) if relevant, check that the data under (or other data >>>> root elements) >>>> can be accessed by this user as requested (granularity TBD) >>>> - minimum granularity is at (read, write) >>>> - maximum NETCONF granularity is (create, delete, merge, replace) >>>> >>>> >>>> Andy >>>> >>>>> >>>>> I agree that RPCs are needed to help reduce complexity >>>>> of SET functionality. >>>>> I also think we need to understand how to standardize and >>>>> functionality for interoperability across vendors. >>>>> >>>>> -- data versus functions -- >>>>> >>>>> I have commented in the past about the comparison of NM approaches to >>>>> programming languages. >>>>> SNMP uses the peek/poke approach of an assembly language, a 2nd >>>>> generation programming language. >>>>> >>>>> The CLI is the equivalent of a 3rd generation language, such as >>>>> Fortran, Cobol, C, or Pascal. It is function-oriented. This is much >>>>> more "natural" for a human being to use, as it is task oriented. An >>>>> important feature of later functional languages is the concept of >>>>> variable scope. Functions may touch any data anywhere in the >>>>> application space, and this can cause bugs when one function's code >>>>> modifies a variable that another function expects to remain constant >>>>> (or at least not to change in a "volatile" manner). To constrain the >>>>> side-effects of modifying variables, langauges like C introduced the >>>>> concepts of function-scope (local variables) and file scope >>>>> (structures only modifiable by functions in the same file that defines >>>>> the structures). >>>>> >>>>> Object-oriented, the fourth generation of langauges, takes it a step >>>>> further by having data that is specific to an object that is only >>>>> modifiable by the fucntions (methods) of the object. In this way, the >>>>> data definition is unknown except internally. Objects in an O-O >>>>> environment also are derivable from base classes, promoting >>>>> hierarchical reuse. >>>>> I stopped following the evolution of programming languages at fourth >>>>> generation, but I think the fifth generation is the use of remote >>>>> procedure calls and the existence of "objects" callable across the >>>>> network. This requires the ability to build components that are >>>>> largely self-sufficient and have a "public" interface to manipulate >>>>> its private data (an extension of the data hiding from 3rdgen scope >>>>> and 4thgen "data hiding"). >>>>> >>>>> Why am I suddenly giving lessons in programming langauges? Because we >>>>> need to decide where on the continuum netconf should fit, and much of >>>>> that decision will have to do with the incompatibility of standard >>>>> data models and global functions such as the RPC, and the >>>>> concepts of data hiding. >>>>> >>>>> -- iteration and an object-oriented hierarchy -- >>>>> >>>>> I have programmed in C++ for years, working on a NMS application that >>>>> used object-oriented design for modeling the network. Each device >>>>> model had public methods and hidden data. One of the toughest problems >>>>> we ran into was "searching the network" for specific data, because it >>>>> required having a search routine for every object, and a search >>>>> routine that iterated through every object in the hierarchy. >>>>> Of course, we could derive objects from a base class that has a search >>>>> method that could iterately call the search method for all derived >>>>> classes. Derivation is hard to work with, and an object hierarchy is >>>>> hard to get right in a manner that works for multiple "world-views"; >>>>> how one models the hierarchy depends a lot on what you are trying to >>>>> achieve. >>>>> >>>>> To do , we will probably need to define a RPC >>>>> for every object you plan to use to modularize the hierarchy (I assume >>>>> a capability might represent the definition of an object), and we will >>>>> a consistent varbind format to report the object's data, and roll the >>>>> data up into a complete picture of the configuration. And ideally, the >>>>> "varbind" format will not place any restrictions on >>>>> implementation-specific decisions of data modeling within the >>>>> "object". >>>>> >>>>> Assuming the "objects" will exist in some type of hierarchy, it will >>>>> probably be necessary to define a mechanism for "rolling up" the data >>>>> through the hierarchy. For instance, calling the for a >>>>> chassis might cause the chassis code to iterate through >>>>> for each blade in the chassis, and combine these subordinate configs >>>>> with the chassis's own config information. And because you don't want >>>>> each blade's trgggered by the chassis AND by a direct >>>>> iterative , we will need to make some provision for >>>>> recognizing when a complete subtree has been queried by the >>>>> command. Mayeb Xpath already solves this iteration >>>>> problem. >>>>> >>>>> -- sets versus gets -- >>>>> >>>>> RPCs are needed to help reduce complexity of SET >>>>> functionality. But what about RPCs? >>>>> >>>>> I suggest we consider a system that uses only functions >>>>> for SET functionality, and uses both global and >>>>> RPCs. >>>>> can make the functionality addressable in a >>>>> standardized manner, make modification of data "gumballs" predictable, >>>>> and make the details implementation-specific to a large degree >>>>> (support data hiding and proprietary schema pieces). I expect we will >>>>> want to standardize portions of a data model into a standard >>>>> schema, and allow this to be supplemented with vendor-specific >>>>> parameters in one or more supplemental schemas. >>>>> >>>>> The and operations should have a standard >>>>> reporting format to improve interoperability, and to promote the >>>>> development of standard data models for monitoring and cross-vendor >>>>> comparison capabiltities. Failure to impose some standards on the >>>>> format of the returned values leads to the problem faced today by >>>>> operators trying to use expect scripts to parse through inconsistent >>>>> and constantly changing proprietary CLI data models. XML will help, >>>>> but will fall short if each vendor uses different schemas for the same >>>>> functionality. >>>>> >>>>> One area this WG has not discussed is how to do access control. This >>>>> has been pushed off as data-model-dependent. But if the interface to >>>>> functinoality will be functions rather than peek/poke, then access >>>>> control should probably be applied to each function, not to the >>>>> underlying gumballs of data that might get modified. >>>>> >>>>> It is possible that two types of access control will be required - >>>>> read access might be best modeled as data-hierarchy-centric, while >>>>> write access might be best modeled as function-centric. Of course, if >>>>> we bundle data and functions into objects, and the hierarchy is at the >>>>> object level, then access control could be object-centric, and we >>>>> would avoid the overkill of per-variable access control. >>>>> >>>>> P.s. it might be worthwhile looking at the <*-config> commands as >>>>> being an object as well, and the and >>>>> commands are methods specific to managing the functionality of a >>>>> "running config" object. >>>>> David Harrington >>>>> dharrington@huawei.com dbharrington@comcast.net >>>>> ietfdbh@comcast.net >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: owner-netconf@ops.ietf.org >>>>>> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman >>>>>> Sent: Tuesday, September 12, 2006 11:19 AM >>>>>> To: Netconf (E-mail); Netconf Data Model Discussion >>>>>> Subject: Why Phil is right about vs. >>>>>> >>>>>> Hi, >>>>>> >>>>>> First, I am not going to say we need to stop using . >>>>>> I just going to point out a critical SNMP problem the XMLCONF design >>>>>> team really wanted to fix -- but didn't. >>>>>> >>>>>> The root problem in NE management today is the relative expense >>>>>> and difficulty in adding new agent functionality into NE devices. >>>>>> >>>>>> SNMP Set failed for 3 reasons: >>>>>> 1) Casting high-level procedures as a "100 bits of peek/poke data" >>>>>> is an Unnatural Act that never had a chance of succeeding. >>>>>> 2) One generic "edit" PDU that can contain an arbitrary mix >>>>>> of arbitrarily incomplete high-level operations (i.e. varbinds), >>>>>> dispensed like gumballs, across an arbitrary number of Set PDUs. >>>>>> 3) In accordance with the Postel Principle, the agent needs to code >>>>>> for complex (legal) Set PDUs the manager should never ever use. >>>>>> >>>>>> NETCONF has better error reporting then SNMP, but the complexity >>>>>> of implementing in an optimal manner is non-trivial. >>>>>> >>>>>> In contrast, none of the arbitrary mix-and-match "Gumball API" >>>>>> problems >>>>>> exist with RPCs. The agent automation complexity is >>>>>> dramatically lower than for . Agent callback chains >>>>>> can handle hard problems like resource reservation and rollback >>>>>> much easier as well. >>>>>> >>>>>> The approach is much better for managers, >>>>>> because an "object-oriented API" can easily be mapped to >>>>>> services or classes, and the set of methods defined for them. >>>>>> >>>>>> The "fly in the ointment" is the startup config file >>>>>> (e.g., show running config). This data-centric view >>>>>> of the configuration state is heavily used, and not going >>>>>> away any time soon. The trick is finding the right mix >>>>>> of heuristics, mappings, and special RPCs, so both views >>>>>> of the NE device can be easily supported. >>>>>> >>>>>> >>>>>> >>>>>> 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: >>> >> > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- 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 Sep 18 12:11:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPLi3-0007nJ-6B for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 12:11:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPLi1-0004RO-T9 for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 12:11:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPLXL-000AL4-2x for netconf-data@psg.com; Mon, 18 Sep 2006 15:59:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPLXI-000AKc-HK for netconf@ops.ietf.org; Mon, 18 Sep 2006 15:59:56 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k8IFxf1Z006371; Mon, 18 Sep 2006 08:59:41 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (leida.juniper.net [172.18.16.26]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k8IFxbg64730; Mon, 18 Sep 2006 08:59:37 -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 k8IFxawn086251; Mon, 18 Sep 2006 11:59:36 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-Id: <200609181559.k8IFxawn086251@idle.juniper.net> To: Balazs Lengyel cc: Andy Bierman , Vincent Cridlig , "'Netconf (E-mail)'" Subject: Re: Access control In-Reply-To: Your message of "Mon, 18 Sep 2006 17:43:29 +0200." <450EBEA1.20403@ericsson.com> Date: Mon, 18 Sep 2006 11:59:36 -0400 From: Phil Shafer Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Balazs Lengyel writes: >Does this mean, that in your opinion it is NOT Possible to do access control without the >information: what is stored already in the datastore? You shouldn't need the datastore to do access control, but you might need the schema and the user's permissions. In JUNOS, we try to leverage the normal CLI permissions, so if you can't touch it (or view it) via the CLI, you can't touch/view it in the API. The schema that defines the data store contains this access information, so both the CLI, the API, the web goo, and whatever else can eat your schema will be able to understand and enforce your permission scheme. 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 Sep 18 13:04:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPMXx-0007U8-9i for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 13:04:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPMOo-0002zx-1h for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 12:55:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPMHs-000F0L-Pu for netconf-data@psg.com; Mon, 18 Sep 2006 16:48:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPMHr-000EzP-Gs for netconf@ops.ietf.org; Mon, 18 Sep 2006 16:48:04 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pC6ixQ2AWxNNpTiNHiM8r28jbykBfiRd5xyoqAQVmw0veOV7V5zGU5vlI0VUUHPr; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.7.241] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GPMHl-0005K4-LV for netconf@ops.ietf.org; Mon, 18 Sep 2006 12:47:58 -0400 Message-ID: <002101c6db42$976c00c0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "'Netconf \(E-mail\)'" References: <048201c6d811$45700250$0400a8c0@china.huawei.com> <450A01F6.7070609@andybierman.com> <450E67F4.3030206@ericsson.com> <450E7072.7090605@loria.fr> <450EB000.3010906@andybierman.com> <450EBEA1.20403@ericsson.com> Subject: Re: Access control Date: Mon, 18 Sep 2006 09:50:06 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7afa6ee62a50436c7d2310c0e6748eb51f4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.7.241 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi - > From: "Balazs Lengyel" > To: "Andy Bierman" > Cc: "Vincent Cridlig" ; "'Netconf (E-mail)'" > Sent: Monday, September 18, 2006 8:43 AM > Subject: Re: Access control ... > Does this mean, that in your opinion it is NOT Possible to do access control without the > information: what is stored already in the datastore? ... Yes, for the example you gave. This is a direct consequence of the way edit-config merge is defined, and of the of access control requirement to distinguish creation of an object instance from the modification of an objects' attributes. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Sep 18 13:29:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPMwH-0000ZT-O5 for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 13:29:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPMtF-0006q1-N3 for netconf-archive@lists.ietf.org; Mon, 18 Sep 2006 13:26:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPMjk-000HtM-VY for netconf-data@psg.com; Mon, 18 Sep 2006 17:16:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [205.178.146.52] (helo=omr2.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPMjY-000Hrg-NS for netconf@ops.ietf.org; Mon, 18 Sep 2006 17:16:41 +0000 Received: from mail.networksolutionsemail.com (ns-omr2.mgt.netsol.com [10.49.6.65]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k8IHGRPU025429 for ; Mon, 18 Sep 2006 13:16:34 -0400 Received: (qmail 10803 invoked by uid 78); 18 Sep 2006 17:15:40 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by ns-omr2.lb.hosting.dc2.netsol.com with SMTP; 18 Sep 2006 17:15:40 -0000 Message-ID: <450ED3BA.9060403@andybierman.com> Date: Mon, 18 Sep 2006 10:13:30 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Randy Presuhn CC: "'Netconf (E-mail)'" Subject: Re: Access control References: <048201c6d811$45700250$0400a8c0@china.huawei.com> <450A01F6.7070609@andybierman.com> <450E67F4.3030206@ericsson.com> <450E7072.7090605@loria.fr> <450EB000.3010906@andybierman.com> <450EBEA1.20403@ericsson.com> <002101c6db42$976c00c0$6501a8c0@oemcomputer> In-Reply-To: <002101c6db42$976c00c0$6501a8c0@oemcomputer> 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: 4d87d2aa806f79fed918a62e834505ca Randy Presuhn wrote: > Hi - > >> From: "Balazs Lengyel" >> To: "Andy Bierman" >> Cc: "Vincent Cridlig" ; "'Netconf (E-mail)'" >> Sent: Monday, September 18, 2006 8:43 AM >> Subject: Re: Access control > ... >> Does this mean, that in your opinion it is NOT Possible to do access control without the >> information: what is stored already in the datastore? > ... > > Yes, for the example you gave. > This is a direct consequence of the way edit-config merge > is defined, and of the of access control requirement to distinguish > creation of an object instance from the modification of an objects' > attributes. This depends on the "operation" and how that is represented in the access control model. If you wanted a model that uses the NETCONF operation set (merge, replace, edit, delete) then you have to look at the datastore during validation at some point anyway to process an PDU already. If your access control operation set is simply (read, write) then you do not need to look at the datastore to enfore access control. > > Randy 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 Sep 19 02:22:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZ0V-00068W-VT for netconf-archive@lists.ietf.org; Tue, 19 Sep 2006 02:22:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPZ0J-0006Ok-AW for netconf-archive@lists.ietf.org; Tue, 19 Sep 2006 02:22:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPYtZ-000I5u-AN for netconf-data@psg.com; Tue, 19 Sep 2006 06:15:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPYtW-000I5P-Rl for netconf@ops.ietf.org; Tue, 19 Sep 2006 06:15:47 +0000 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 276448E0001; Tue, 19 Sep 2006 08:15:45 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 08:15:44 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Sep 2006 08:15:44 +0200 Message-ID: <450F8B0D.80600@ericsson.com> Date: Tue, 19 Sep 2006 08:15:41 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Andy Bierman CC: Randy Presuhn , "'Netconf (E-mail)'" Subject: Re: Access control References: <048201c6d811$45700250$0400a8c0@china.huawei.com> <450A01F6.7070609@andybierman.com> <450E67F4.3030206@ericsson.com> <450E7072.7090605@loria.fr> <450EB000.3010906@andybierman.com> <450EBEA1.20403@ericsson.com> <002101c6db42$976c00c0$6501a8c0@oemcomputer> <450ED3BA.9060403@andybierman.com> In-Reply-To: <450ED3BA.9060403@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2006 06:15:44.0286 (UTC) FILETIME=[0A2B0BE0:01C6DBB3] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 I want just read, write controls still I don't know how to handle the merge example. Balazs Andy Bierman wrote: > Randy Presuhn wrote: >> Hi - >> >>> From: "Balazs Lengyel" >>> To: "Andy Bierman" >>> Cc: "Vincent Cridlig" ; "'Netconf >>> (E-mail)'" >>> Sent: Monday, September 18, 2006 8:43 AM >>> Subject: Re: Access control >> ... >>> Does this mean, that in your opinion it is NOT Possible to do access >>> control without the information: what is stored already in the >>> datastore? >> ... >> >> Yes, for the example you gave. >> This is a direct consequence of the way edit-config merge >> is defined, and of the of access control requirement to distinguish >> creation of an object instance from the modification of an objects' >> attributes. > > > This depends on the "operation" and how that is represented > in the access control model. > > If you wanted a model that uses the NETCONF operation set > (merge, replace, edit, delete) then you have to look at the > datastore during validation at some point anyway to process > an PDU already. > > If your access control operation set is simply (read, write) > then you do not need to look at the datastore to enfore access > control. > > >> >> Randy > > 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: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- 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 Sep 19 03:37:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPaAX-0002pL-Vv for netconf-archive@lists.ietf.org; Tue, 19 Sep 2006 03:37:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPaAS-0001F8-Ma for netconf-archive@lists.ietf.org; Tue, 19 Sep 2006 03:37:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPa4G-0000aI-BJ for netconf-data@psg.com; Tue, 19 Sep 2006 07:30:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPa4F-0000Zq-Ap for netconf@ops.ietf.org; Tue, 19 Sep 2006 07:30:55 +0000 Received: from localhost (c213-100-166-163.swipnet.se [213.100.166.163]) by mail.tail-f.com (Postfix) with ESMTP id A6C141B8011; Tue, 19 Sep 2006 09:30:51 +0200 (CEST) Date: Tue, 19 Sep 2006 09:30:41 +0200 (CEST) Message-Id: <20060919.093041.94165842.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: ietf@andybierman.com, randy_presuhn@mindspring.com, netconf@ops.ietf.org Subject: Re: Access control From: Martin Bjorklund In-Reply-To: <450F8B0D.80600@ericsson.com> References: <002101c6db42$976c00c0$6501a8c0@oemcomputer> <450ED3BA.9060403@andybierman.com> <450F8B0D.80600@ericsson.com> X-Mailer: Mew version 2.2rc2-mbj2 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: ea4ac80f790299f943f0a53be7e1a21a Balazs Lengyel wrote: > I want just read, write controls still I don't know how to handle > the merge example. I agree that you need info from the datastore in your example: > > > > Up > > > since the merge on will create it if it doesn't exist. I don't see the big problem though. As an alternative, you could deny the merge request if the user doesn't have write access, and force her to use explicit operations. /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 Tue Sep 19 15:57:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPlir-0001fV-EW for netconf-archive@lists.ietf.org; Tue, 19 Sep 2006 15:57:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPlif-0007MN-RC for netconf-archive@lists.ietf.org; Tue, 19 Sep 2006 15:57:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPlbZ-000K1z-MK for netconf-data@psg.com; Tue, 19 Sep 2006 19:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GPlbW-000K0i-UW for netconf@ops.ietf.org; Tue, 19 Sep 2006 19:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 3AED23287F; Tue, 19 Sep 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GPlbW-0006uA-45; Tue, 19 Sep 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-notification-03.txt Message-Id: Date: Tue, 19 Sep 2006 15:50:02 -0400 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Event Notifications Author(s) : H. Trevino, S. Chisholm Filename : draft-ietf-netconf-notification-03.txt Pages : 41 Date : 2006-9-19 This memo defines a framework for sending asynchronous messages, or event notifications in NETCONF. It defines both the operations necessary to support this concept, and also discusses implications for the mapping to transport protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-notification-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-notification-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-9-19115446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-notification-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-notification-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-19115446.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Sep 20 11:57:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ4SO-0004jg-Ni for netconf-archive@lists.ietf.org; Wed, 20 Sep 2006 11:57:52 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ4SF-0004kU-7m for netconf-archive@lists.ietf.org; Wed, 20 Sep 2006 11:57:52 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ4Ka-0005lw-En for netconf-data@psg.com; Wed, 20 Sep 2006 15:49:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQ4KV-0005l3-E0 for netconf@ops.ietf.org; Wed, 20 Sep 2006 15:49:43 +0000 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1998D8E0001 for ; Wed, 20 Sep 2006 17:49:36 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 17:49:35 +0200 Received: from [159.107.196.23] ([159.107.196.23]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 17:49:35 +0200 Message-ID: <4511630F.10308@ericsson.com> Date: Wed, 20 Sep 2006 17:49:35 +0200 From: Balazs Lengyel User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Comments on notifications-03 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Sep 2006 15:49:35.0376 (UTC) FILETIME=[5F1C3100:01C6DCCC] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hello, General: I think the draft is going in the good direction, nice work but still needs clarifications. The document should state very clearly whether this is new capability (or two) or a mandatory addition to netconf. I believe the draft defines 2 new capabilities, however for the base-notification this is not clearly stated. Even the capability identifier is defined only in the example in chapter 3.1 Chapter 1.1) The definition of subscription contradicts the 9th requirement in chapter 1.4 Chapter 1.2 last paragraph) The agent is not required to process RPC requests ON THE SAME NETCONF SESSION. I believe it is required for the agent to be able to open another Netconf session and handle RPCs there. Chapter 1.4) - requirement5: We will not provide agent initiated connections just now so this should only be a future goal not a requirement. - requirement10: I don't see this implemented in the draft, propose to be removed. Chapter 2.1.1 Description) What kind of event are you thinking about ? Chapter 2.3) I would mention closing the transport session. What other actions are you thinking about? Chapter 3.2.5.1) I believe we should consider defining the exact namespace and path of the stream information instead of providing a namespace called example.com I wonder if the distinction between sessionEventStreams and systemEventStreams is really needed. Why don't we just say: There is a set of eventStreams and every one will see the set of streams according to his/her access rights. I also believe it would be enough to use get-config in the examples and omit the ones using get. Chapter 3.2.5.3) Inside xs:annotation/xs:documentation it says: "Schema for event streams". Is this correct? Chapter 3.2.6.2) Is it allowed to subscribe to multiple eventStreams in one subscription/session ? I would like to believe so. If I am right further channels are not needed to receive multiple streams. Until now we avoided using multiple channels on one Netconf session. Why do we introduce it here? Chapter 5.2.1.2) Is there a strong need for the new construct? If not remove it. Chapter 7.1 paragraph 3) The warning message should be defined somehow. E.g. an extra element in the first notification indicating the real start time. Balazs -- 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 Sep 22 09:37:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQlDp-0005J8-7e for netconf-archive@lists.ietf.org; Fri, 22 Sep 2006 09:37:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQl4Q-0003IF-26 for netconf-archive@lists.ietf.org; Fri, 22 Sep 2006 09:28:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQktJ-0002sC-3O for netconf-data@psg.com; Fri, 22 Sep 2006 13:16:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [131.115.18.152] (helo=sehan001bb.han.telia.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQktG-0002qu-G2 for netconf@ops.ietf.org; Fri, 22 Sep 2006 13:16:26 +0000 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 15:16:24 +0200 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 roadmap? Date: Fri, 22 Sep 2006 15:16:23 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3AA49C7@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: netconf roadmap? Thread-Index: AcbDo4AwRGSVADECShGQycr8Gg7b7AAAAAFiBqlP9nA= From: To: X-OriginalArrivalTime: 22 Sep 2006 13:16:24.0311 (UTC) FILETIME=[4DA27870:01C6DE49] Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hello Has there been any discussion about the steps after current tasks have been finished? Or is this to be defined and is defined all the time? Regards, Antti-Jussi Korjonen -- 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 Sep 22 17:32:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQsdG-0000FE-CK for netconf-archive@lists.ietf.org; Fri, 22 Sep 2006 17:32:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQsdF-00022r-0v for netconf-archive@lists.ietf.org; Fri, 22 Sep 2006 17:32:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQsWV-000DEm-3h for netconf-data@psg.com; Fri, 22 Sep 2006 21:25:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [205.178.146.58] (helo=omr8.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GQsWT-000DEH-S1 for netconf@ops.ietf.org; Fri, 22 Sep 2006 21:25:26 +0000 Received: from mail.networksolutionsemail.com (ns-omr8.mgt.netsol.com [10.49.6.71]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k8MLPO0J030747 for ; Fri, 22 Sep 2006 17:25:25 -0400 Received: (qmail 1557 invoked by uid 78); 22 Sep 2006 21:25:24 -0000 Received: from unknown (HELO ?24.52.157.75?) (andy@andybierman.com@24.52.157.75) by ns-omr8.lb.hosting.dc2.netsol.com with SMTP; 22 Sep 2006 21:25:24 -0000 Message-ID: <451454BE.8000200@andybierman.com> Date: Fri, 22 Sep 2006 14:25:18 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: antti-jussi.korjonen@teliasonera.com CC: netconf@ops.ietf.org Subject: Re: netconf roadmap? References: <59D7431DE2527D4CB0F1EFEDA5683ED3AA49C7@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3AA49C7@SEHAN021MB.tcad.telia.se> 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: 3e15cc4fdc61d7bce84032741d11c8e5 antti-jussi.korjonen@teliasonera.com wrote: > Hello > > Has there been any discussion about the steps after current > tasks have been finished? Or is this to be defined and is > defined all the time? > Short answer: After notifications, then NETCONF data modeling. Long answer: There has been a lot of discussion on this topic, although no formal roadmap exists. The ADs and co-Chairs want to see some deployment of the base protocol, and use that experience to address NETCONF data modeling (also called NETMOD). There are no milestones for data modeling, and therefore no road map. IMO, the community has not shown enough deployment or base-level interoperability to plan very far into the future. For example, experience is suggesting that specialized methods need to be part of the data modeling work, using a procedural framework instead of the "static + dynamic data" framework from SMI/SNMP. There are probably several problem areas currently unexposed in the base protocol, that will likely surface in the next year. > Regards, > Antti-Jussi Korjonen > 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 Sun Sep 24 05:07:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRPxd-00075p-3C for netconf-archive@lists.ietf.org; Sun, 24 Sep 2006 05:07:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRPxa-0002Ou-Nw for netconf-archive@lists.ietf.org; Sun, 24 Sep 2006 05:07:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GRPrg-0001Ab-3p for netconf-data@psg.com; Sun, 24 Sep 2006 09:01:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [198.152.13.103] (helo=co300216-ier2.net.avaya.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GRPre-0001A5-W7 for netconf@ops.ietf.org; Sun, 24 Sep 2006 09:01:31 +0000 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k8O8rcfe016389 for ; Sun, 24 Sep 2006 04:53:39 -0400 content-class: urn:content-classes:message Subject: RE: netconf roadmap? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Sep 2006 12:01:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: netconf roadmap? Thread-Index: Acbejfc6+IbWBl/FRmyVxBK59Bw3MABKVuSg From: "Romascanu, Dan \(Dan\)" To: "Andy Bierman" , Cc: X-Scanner: InterScan AntiVirus for Sendmail Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman > Sent: Saturday, September 23, 2006 12:25 AM > To: antti-jussi.korjonen@teliasonera.com > Cc: netconf@ops.ietf.org > Subject: Re: netconf roadmap? >=20 > antti-jussi.korjonen@teliasonera.com wrote: > > Hello > > > > Has there been any discussion about the steps after current=20 > tasks have=20 > > been finished? Or is this to be defined and is defined all the time? > > =20 >=20 > Short answer: >=20 > After notifications, then NETCONF data modeling. >=20 > Long answer: >=20 > There has been a lot of discussion on this topic, although no formal > roadmap exists. The ADs and co-Chairs want to see some deployment > of the base protocol, and use that experience to address NETCONF data=20 > modeling > (also called NETMOD). >=20 > There are no milestones for data modeling, and therefore no road map. >=20 > IMO, the community has not shown enough deployment or base-level=20 > interoperability > to plan very far into the future. For example, experience is=20 > suggesting=20 > that specialized > methods need to be part of the data modeling work, using a procedural=20 > framework instead > of the "static + dynamic data" framework from SMI/SNMP. =20 > There are probably > several problem areas currently unexposed in the base protocol, that=20 > will likely > surface in the next year. >=20 >=20 > > Regards, > > Antti-Jussi Korjonen > > =20 >=20 >=20 > Andy >=20 Just to add to what Andy wrote - in the meantime discussions, experimentation, and sharing results and experience on items of future work including but necessarily restricted to data modeling are supported and encouraged. The more we have a shared experience of what is achievable and needed, the easier will be the task to define precise next steps if and when time arrives.=20 Dan -- 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 Sep 26 07:35:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSBDj-0003qY-4O for netconf-archive@lists.ietf.org; Tue, 26 Sep 2006 07:35:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSBDf-0003oQ-Hg for netconf-archive@lists.ietf.org; Tue, 26 Sep 2006 07:35:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GSB5c-00011x-MK for netconf-data@psg.com; Tue, 26 Sep 2006 11:27:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) 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.1 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GSB5Z-00010q-Fl for netconf@ops.ietf.org; Tue, 26 Sep 2006 11:27:01 +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 k8QBQuS23487 for ; Tue, 26 Sep 2006 07:26:56 -0400 (EDT) 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: Comments on notifications-03 Date: Tue, 26 Sep 2006 07:26:54 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40AFF83C3@zcarhxm2.corp.nortel.com> In-Reply-To: <4511630F.10308@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on notifications-03 thread-index: AcbczxttdvN/s2HiTMu8PnZV3jHKxwEjGelQ From: "Sharon Chisholm" To: "Netconf \(E-mail\)" Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Hi Thanks a lot for the review: =20 The document should state very clearly whether this is new capability (or two) or a mandatory addition to netconf. I believe the draft defines 2 new capabilities, however for the base-notification this is not clearly stated. Even the capability identifier is defined only in the example in chapter 3.1 We can make this clearer. State that is a new capability building on what was defined in the base protocol specification. Chapter 1.1) The definition of subscription contradicts the 9th requirement in chapter 1.4 That bullet says:=20 "solution should not bind subscriptions to a connection" Which does seem to contradict both the definition of a subscription and what the working group agreed to. I believe that requirement means something else, but I can't quite remember at the moment. Chapter 1.2 last paragraph) The agent is not required to process RPC requests ON THE SAME NETCONF SESSION. I believe it is required for the agent to be able to open another Netconf session and handle RPCs there. Ok. Good bit of clarification. Chapter 1.4) - requirement5: We will not provide agent initiated connections just now so this should only be a future goal not a requirement. I'm not sure why this is still in the requirements list. I think we agreed to remove it. - requirement10: I don't see this implemented in the draft, propose to be removed. "channels for configuration change notifications should share fate with a session that includes a configuration channel" Um. I think I left it in based on the notes from the Montreal meeting, but I believe we indicated that they were independent. Chapter 2.1.1 Description) What kind of event are you thinking about ? Chapter 2.3) I would mention closing the transport session. What other actions are you thinking about? We had talked in Montreal about the fact that the current capability didn't support 'mix-mode', but that we could define an optional capability at some future date that did. This text is intending to not preclude that definition, which may well include a definition of a command such as cancel-subscription. Another event could be someone supporting a CLI command to do this as well I suppose. Chapter 3.2.5.1) I believe we should consider defining the exact namespace and path of the stream information instead of providing a namespace called example.com Agreed. I wonder if the distinction between sessionEventStreams and systemEventStreams is really needed. Why don't we just say: There is a set of eventStreams and every one will see the set of streams according to his/her access rights. No. That could be my mistake. Hector and I had talked about this and decided having both was over-engineered so Hector provided a single one to handle both. It seems we left some residue of the interim solution in the draft. We'll fix that. I also believe it would be enough to use get-config in the examples and omit the ones using get. Or the other way around I suppose ... Chapter 3.2.5.3) Inside xs:annotation/xs:documentation it says: "Schema for event streams". Is this correct? I believe so, but perhaps it could use a bit more description. This is the schema that people are suppose to query to find out what streams are supported by the system. As noted above, it does not match up with the examples anymore. Chapter 3.2.6.2) Is it allowed to subscribe to multiple eventStreams in one subscription/session ? I would like to believe so. If I am right further channels are not needed to receive multiple streams. Until now we avoided using multiple channels on one Netconf session. Why do we introduce it here? I notice we forgot to put the definition of stream in the XSD for the create-subscription command. This of course would have definitively shown the cardinality of streams per subscription. We do say in section 2.1.1 that you associate 'stream(s)' which is meant to indicate you can associate more then one per subscription. We will fix up the schema to properly handle streams. Chapter 5.2.1.2) Is there a strong need for the new construct? If not remove it. This is related to the Beep transport mapping, which is something WE NEED INPUT ON. Chapter 7.1 paragraph 3) The warning message should be defined somehow. E.g. an extra element in the first notification indicating the real start time. Agreed. We need to better specify this in the next release. Thanks again, Sharon -- 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 Sep 27 13:14:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSczV-0006Cd-Py for netconf-archive@lists.ietf.org; Wed, 27 Sep 2006 13:14:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSczQ-0007En-Ac for netconf-archive@lists.ietf.org; Wed, 27 Sep 2006 13:14:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GScr4-000864-DO for netconf-data@psg.com; Wed, 27 Sep 2006 17:05:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.180.94.158] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GScr3-00085j-0r for netconf@ops.ietf.org; Wed, 27 Sep 2006 17:05:53 +0000 Received: from localhost (vbn.0050420.lodgenet.net [209.19.49.10]) by mail.tail-f.com (Postfix) with ESMTP id 0558F1B8011; Wed, 27 Sep 2006 19:05:36 +0200 (CEST) Date: Wed, 27 Sep 2006 19:05:33 +0200 (CEST) Message-Id: <20060927.190533.133433864.mbj@tail-f.com> To: schishol@nortel.com Cc: netconf@ops.ietf.org Subject: more comments on notifications-03 From: Martin Bjorklund X-Mailer: Mew version 2.2rc2-mbj2 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: d890c9ddd0b0a61e8c597ad30c1c2176 Hi, Here are a couple of comments on the latest notifications draft. o 3.2.5 Says that or can be used to retreive the list of supported event streams. But using implies that this list is config data (which e.g. can be written). The s should be removed. o 3.2.6.2 A NETCONF client subscribing to multiple event streams must do so by either establishing a new NETCONF session or opening a new channel on an existing NETCONF session. From your reply to Balazs it seems that this sentence will be removed. If not, it should just say A NETCONF client subscribing to multiple event streams must do so by establishing a new NETCONF session. For SSH, this can be done by either opening a new SSH connection, or opening a new SSH channel on the existsing connection. o 3.4 The schema in this section defines a "lastModified" element. Maybe this should be renamed to "creationTime", since modifications is not supported. o 3.4 The element "messagesSent" should probably be of type xs:unsingedInt, which is 32 bits. xs:integer is a bignum. o 3.6 This text should describe that the filter is applied to the XML in the element (which the examples seems to indicate is the case). o 4. The description for element "SequenceNumber" says: A monotonically increasing integer. Starts at 0. Always increases by just one. Roll back to 0 after maximum value is reached. But the type is xs:integer, which doesn't have a maximum value. The type should probably be xs:unsingedInt. (or even better smiv2:Counter32 ...). o 4. The complextType "NotificationType" is missing the "data" element. o 5.1 The example in this section has some namespace errors. It should probably look like this (slightly modified to be consistent with other examples). 123456 notice 2 2000-01-12T12:13:14Z Fred Flinstone Ethernet0/0 1500 ]]>]]> Note that the separator was split into two lines in the document. o 6.1 This example also has some namespace errors. The infamous 'neb' element is still there also... I suggest something like this: critical major minor NOTE: there are a few other examples throughout the document which have the same namespace errors on the 'rpc' and 'create-subscription' elements. o 7. The replay capability adds a startTime parameter. We had some discussion about this time in Montreal. So - what time does this parameter refer to? The time the event was generated? The time it was logged by the agent? If it is the former, this seems to imply that the replay mechanism can only be used when there is a timestamp in the event itself. If it is the latter, this time should be included in each event - if not, how would a manager know which time to use? I would prefer the latter. o 7. Why isn't there a symmetrical stopTime parameter? o 7.1 The text says: If a client requests a replay of notifications that predate the oldest notification available, then the NETCONF server must return an warning message in the RPC reply and start replaying the notifications it does have available, Why is this warning message necessary? (I suspect the answer might be that if no timestamp is included in the event, then the client won't know...) o 7.1 The text says: A replay subscription terminates once the it has completed replaying past events. How will a client know that the last event has been sent? Is the session open for new rpcs once the last event has been sent? /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 Sat Sep 30 05:57:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTbaq-0005eZ-Le for netconf-archive@lists.ietf.org; Sat, 30 Sep 2006 05:57:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTbao-0005mb-SQ for netconf-archive@lists.ietf.org; Sat, 30 Sep 2006 05:57:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GTbSh-00066i-GV for netconf-data@psg.com; Sat, 30 Sep 2006 09:48:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_MESSAGE,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.54] (helo=szxga02-in.huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GTbSe-00065e-5x for netconf@ops.ietf.org; Sat, 30 Sep 2006 09:48:45 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6E0081FHGNTD@szxga02-in.huawei.com> for netconf@ops.ietf.org; Sat, 30 Sep 2006 18:07:36 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6E00JOCHGML9@szxga02-in.huawei.com> for netconf@ops.ietf.org; Sat, 30 Sep 2006 18:07:35 +0800 (CST) Received: from l48181 ([10.111.12.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J6E0085OH6PZI@szxml04-in.huawei.com> for netconf@ops.ietf.org; Sat, 30 Sep 2006 18:01:41 +0800 (CST) Date: Sat, 30 Sep 2006 17:48:34 +0800 From: Li Yan Subject: A question on notifications-03 To: 'Sharon Chisholm' Cc: netconf@ops.ietf.org Message-id: <002101c6e475$98a58a10$3a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_dyZlfAOXuCRTkO8/GiTx8Q)" Thread-index: AcbkdZhGSrpdC2tVTGiYCwxKghZbcg== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: aafbb359257cdee39d68c7ac7bccd638 This is a multi-part message in MIME format. --Boundary_(ID_dyZlfAOXuCRTkO8/GiTx8Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I have a question on notifications-03. 2.3 Terminating the Subscription Closing of the event notification subscription is done by terminating the Netconf session ( )or via some action outside the scope of this specification. Does it imply that configuration and notification MUST run in two different sessions? Otherwise, configuration operations could be broke by . In addition, I believe the Subscription Id doesn't make sense any more, because and operations have been eliminated. A notification subscription should associate with a session-id, thus we can use to close a notification subscription. Yan --Boundary_(ID_dyZlfAOXuCRTkO8/GiTx8Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I have a question on notifications-03.

2.3  Terminating the Subscription

   Closing of the event notification subscription is done by terminating

   the Netconf session ( <kill-session> )or via some action outside the

   scope of this specification.

Does it imply that configuration and notification MUST run in two different sessions? Otherwise, configuration operations could be broke by <kill-session>.

In addition, I believe the Subscription Id doesn't make sense any more, because <cancel-subscription> and <modify-subscription> operations have been eliminated. A notification subscription should associate with a session-id, thus we can use <kill-session> to close a notification subscription.

 

Yan

--Boundary_(ID_dyZlfAOXuCRTkO8/GiTx8Q)-- -- 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: