From owner-netconf@ops.ietf.org Tue Aug 3 10:49:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13402 for ; Tue, 3 Aug 2004 10:49:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bs0OW-000P4O-Lg for netconf-data@psg.com; Tue, 03 Aug 2004 14:36:00 +0000 Received: from [164.164.31.5] (helo=wiproecmx1.wipro.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bs0OI-000P2L-AK for netconf@ops.ietf.org; Tue, 03 Aug 2004 14:35:47 +0000 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx1.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i73EZgCd012758 for ; Tue, 3 Aug 2004 20:05:44 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Tue, 03 Aug 2004 20:05:42 +0530 Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Aug 2004 20:05:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C47967.267DCC01" Subject: comments on NETCONF RPC and Protocol Operations Schema Date: Tue, 3 Aug 2004 20:05:40 +0530 Message-ID: <184E80410B37F54F8FAFE5CF9AD757C4013F557E@blr-m2-msg.wipro.com> X-MS-Has-Attach: yes Thread-Topic: comments on NETCONF RPC and Protocol Operations Schema Thread-Index: AcR5Z+R7MSM49Gb/SjSNz27QWJob1Q== From: To: X-OriginalArrivalTime: 03 Aug 2004 14:35:41.0268 (UTC) FILETIME=[26CB8140:01C47967] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C47967.267DCC01 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C47967.267DCC01" ------_=_NextPart_002_01C47967.267DCC01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 some comments on NETCONF RPC and Protocol Operations Schema. (Appendix B) =20 1. edit-config: has a source parameter of rpcOperationSourceType.=20 Having source and target both in edit-config doesn't seem appropriate.=20 Shouldn't source parameter be removed? =20 2. edit-config: The config parameter is marked as optional in edit-configType, Shouldn't this be mandatory instead? 3. get-config: refers to rpcOperationSourceType, which has a config element.=20 config tag inside source parameter is not meaningful, instead we could define a=20 rpcOperationGetSourceType without a config element. =20 4. lock and unlock: these commands refer to rpcOperationTargetType, which can take url as a target. Enforcing lock on url configuration is not feasible. So url should be removed from target in case of lock and unlock. =20 Instead we can define a rpcOperationLockTargetType without url, which we can refer in lock and unlock. =20 5. kill-session: has session-id as optional, shouldn't this be mandatory too. =20 Here is the new protocol operations schema with the above changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_002_01C47967.267DCC01 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi All,
 
some comments on NETCONF RPC and = Protocol=20 Operations Schema. (Appendix B)
 
1. = edit-config: has=20 a source parameter of rpcOperationSourceType.
   =20 Having source and target both in edit-config doesn't seem appropriate.=20
   =20 Shouldn't source parameter be removed?
   =20
2. = edit-config: The=20 config parameter is marked as optional in edit-configType, Shouldn't = this be=20 mandatory instead?
     <xs:element ref=3D"config" = minOccurs=3D1=20 />
3. = get-config:=20 refers to rpcOperationSourceType, which has a config element.=20
   =20 config tag inside source parameter is not meaningful, instead we could = define a=20
   =20 rpcOperationGetSourceType without a config element.
 
4. = lock and unlock:=20 these commands refer to rpcOperationTargetType, which can take url as a=20 target.
   =20 Enforcing lock on url configuration is not feasible. So url should be = removed=20 from target in case of lock and unlock.
 
   =20 Instead we can define a rpcOperationLockTargetType without url, = which we=20 can refer in lock and unlock.
 
5.=20 kill-session: has session-id as optional, shouldn't this be = mandatory=20 too.
 
   =20 Here is the new protocol operations schema with the above=20 changes
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
<xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"> <xs:complexType name=3D"rpcType"> <xs:sequence> <xs:element ref=3D"rpcOperation"/> </xs:sequence> <xs:attribute name=3D"message-id" type=3D"xs:string" = use=3D"required"/> </xs:complexType> <xs:element name=3D"rpc" type=3D"rpcType"/> <xs:simpleType name=3D"SessionId"> <xs:restriction base=3D"xs:unsignedInt"/> </xs:simpleType> <xs:simpleType name=3D"ErrorType"> <xs:restriction base=3D"xs:string"> <xs:enumeration value=3D"transport"/> <xs:enumeration value=3D"rpc"/> <xs:enumeration value=3D"protocol"/> <xs:enumeration value=3D"application"/> </xs:restriction> </xs:simpleType> <xs:simpleType name=3D"ErrorTag"> <xs:restriction base=3D"xs:string"> <xs:enumeration value=3D"TOO_BIG"/> <xs:enumeration value=3D"MISSING_ATTRIBUTE"/> <xs:enumeration value=3D"BAD_ATTRIBUTE"/> <xs:enumeration value=3D"UNKNOWN_ATTRIBUTE"/> <xs:enumeration value=3D"MISSING_ELEMENT"/> <xs:enumeration value=3D"BAD_ELEMENT"/> <xs:enumeration value=3D"UNKNOWN_ELEMENT"/> <xs:enumeration value=3D"ACCESS_DENIED"/> <xs:enumeration value=3D"LOCK_DENIED"/> <xs:enumeration value=3D"RESOURCE_DENIED"/> <xs:enumeration value=3D"ROLLBACK_FAILED"/> <xs:enumeration value=3D"DATA_EXISTS"/> <xs:enumeration value=3D"DATA_MISSING"/> <xs:enumeration value=3D"OPERATION_NOT_SUPPORTED"/> <xs:enumeration value=3D"OPERATION_FAILED"/> <xs:enumeration value=3D"PARTIAL_OPERATION"/> </xs:restriction> </xs:simpleType> <xs:simpleType name=3D"ErrorSeverity"> <xs:restriction base=3D"xs:string"> <xs:enumeration value=3D"error"/> <xs:enumeration value=3D"warning"/> </xs:restriction> </xs:simpleType> <xs:complexType name=3D"rpc-errorType"> <xs:sequence> <xs:element name=3D"error-type" type=3D"ErrorType"/> <xs:element name=3D"error-tag" type=3D"ErrorTag"/> <xs:element name=3D"error-severity" type=3D"ErrorSeverity"/> <xs:element name=3D"error-app-tag" type=3D"xs:string" = minOccurs=3D"0"/> <xs:element name=3D"error-path" type=3D"xs:string" minOccurs=3D"0"/> <xs:element name=3D"error-message" type=3D"xs:string" = minOccurs=3D"0"/> <xs:element name=3D"error-info" type=3D"xs:anyType" minOccurs=3D"0"/> </xs:sequence> </xs:complexType> <!-- Standard elements used in the error-info container --> <xs:element name=3D"bad-attribute" type=3D"xs:QName"/> <xs:element name=3D"bad-element" type=3D"xs:QName"/> <xs:element name=3D"ok-element" type=3D"xs:QName"/> <xs:element name=3D"err-element" type=3D"xs:QName"/> <xs:element name=3D"noop-element" type=3D"xs:QName"/> <xs:element name=3D"session-id" type=3D"SessionId"/> <xs:complexType name=3D"rpc-replyType"> <xs:choice> <xs:element name=3D"ok" minOccurs=3D"0"/> <xs:element name=3D"rpc-error" type=3D"rpc-errorType" = minOccurs=3D"0"/> <xs:element ref=3D"config" minOccurs=3D"0"/> <xs:element ref=3D"data" minOccurs=3D"0"/> </xs:choice> <xs:attribute name=3D"message-id" type=3D"xs:string" = use=3D"required"/> </xs:complexType> <xs:element name=3D"rpc-reply" type=3D"rpc-replyType"/> <xs:simpleType name=3D"test-optionType"> <xs:restriction base=3D"xs:string"> <xs:enumeration value=3D"test"/> <xs:enumeration value=3D"test-then-set"/> <xs:enumeration value=3D"set"/> </xs:restriction> </xs:simpleType> <xs:element name=3D"test-option" type=3D"test-optionType"/> <xs:simpleType name=3D"error-optionType"> <xs:restriction base=3D"xs:string"> <xs:enumeration value=3D"stop-on-error"/> <xs:enumeration value=3D"ignore-error"/> <xs:enumeration value=3D"rollback-on-error"/> </xs:restriction> </xs:simpleType> <xs:element name=3D"error-option" type=3D"error-optionType"/> <xs:complexType name=3D"rpcOperationType"/> <xs:element name=3D"rpcOperation" type=3D"rpcOperationType" = abstract=3D"true"/> <xs:complexType name=3D"config-inlineType"> <xs:complexContent> <xs:extension base=3D"xs:anyType"/> </xs:complexContent> </xs:complexType> <xs:element name=3D"data" type=3D"xs:anyType"/> <xs:element name=3D"config" type=3D"config-inlineType"/> <xs:element name=3D"filter" type=3D"config-inlineType"/> <xs:complexType name=3D"config-nameType"/> <xs:element name=3D"config-name" type=3D"config-nameType" = abstract=3D"true"/> <xs:element name=3D"startup" type=3D"config-nameType" = substitutionGroup=3D"config-name"/> <xs:element name=3D"candidate" type=3D"config-nameType" = substitutionGroup=3D"config-name"/> <xs:element name=3D"running" type=3D"config-nameType" = substitutionGroup=3D"config-name"/> <xs:complexType name=3D"config-uriType"> <xs:simpleContent> <xs:extension base=3D"xs:anyURI"/> </xs:simpleContent> </xs:complexType> <xs:element name=3D"url" type=3D"config-uriType"/> <xs:complexType name=3D"rpcOperationSourceType"> <xs:choice> <xs:element ref=3D"config"/> <xs:element ref=3D"config-name"/> <xs:element ref=3D"url"/> </xs:choice> </xs:complexType> <xs:complexType name=3D"rpcOperationGetSourceType"> <xs:choice> <xs:element ref=3D"config-name"/> <xs:element ref=3D"url"/> </xs:choice> </xs:complexType> <xs:element name=3D"get-source" type=3D"rpcOperationGetSourceType"/> <xs:element name=3D"source" type=3D"rpcOperationSourceType"/> <xs:complexType name=3D"rpcOperationTargetType"> <xs:choice> <xs:element ref=3D"config-name"/> <xs:element ref=3D"url"/> </xs:choice> </xs:complexType> <xs:complexType name=3D"rpcOperationLockTargetType"> <xs:choice> <xs:element ref=3D"config-name"/> </xs:choice> </xs:complexType> <xs:element name=3D"lock-target" type=3D"rpcOperationLockTargetType"/> <xs:element name=3D"target" type=3D"rpcOperationTargetType"/> <xs:complexType name=3D"get-configType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"> <xs:sequence> <xs:element ref=3D"get-source"/> <xs:element ref=3D"filter" minOccurs=3D"0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=3D"get-config" type=3D"get-configType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"edit-configType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"> <xs:sequence> <xs:element ref=3D"target"/> <xs:element ref=3D"test-option" minOccurs=3D"0"/> <xs:element ref=3D"error-option" minOccurs=3D"0"/> <xs:element ref=3D"config"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=3D"edit-config" type=3D"edit-configType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"copy-configType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"> <xs:sequence> <xs:element ref=3D"source"/> <xs:element ref=3D"target"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=3D"copy-config" type=3D"copy-configType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"delete-configType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"> <xs:sequence> <xs:element ref=3D"target"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=3D"delete-config" type=3D"delete-configType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"getType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"> <xs:sequence> <xs:element ref=3D"filter" minOccurs=3D"0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=3D"get" type=3D"getType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"lockType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"> <xs:sequence> <xs:element ref=3D"lock-target"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=3D"lock" type=3D"lockType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"unlockType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"> <xs:sequence> <xs:element ref=3D"lock-target"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=3D"unlock" type=3D"unlockType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"validateType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"> <xs:sequence> <xs:element ref=3D"source"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=3D"validate" type=3D"validateType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"commitType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"> <xs:sequence> <xs:element name=3D"confirmed" minOccurs=3D"0"/> <xs:element name=3D"confirmed-timeout" minOccurs=3D"0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=3D"commit" type=3D"commitType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"discard-changesType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"/> </xs:complexContent> </xs:complexType> <xs:element name=3D"discard-changes" type=3D"discard-changesType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"close-sessionType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"/> </xs:complexContent> </xs:complexType> <xs:element name=3D"close-session" type=3D"close-sessionType" = substitutionGroup=3D"rpcOperation"/> <xs:complexType name=3D"kill-sessionType"> <xs:complexContent> <xs:extension base=3D"rpcOperationType"> <xs:sequence> <xs:element name=3D"session-id" type=3D"SessionId"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name=3D"kill-session" type=3D"kill-sessionType" = substitutionGroup=3D"rpcOperation"/> </xs:schema>
------_=_NextPart_002_01C47967.267DCC01-- ------_=_NextPart_001_01C47967.267DCC01 Content-Type: application/octet-stream; name="NewNetconfSchema.xsd" Content-Transfer-Encoding: base64 Content-Description: NewNetconfSchema.xsd Content-Disposition: attachment; filename="NewNetconfSchema.xsd" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+PC9IRUFEPg0KPEJPRFk+PFhNUD48 eHM6c2NoZW1hIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSI+DQoJ PHhzOmNvbXBsZXhUeXBlIG5hbWU9InJwY1R5cGUiPg0KCQk8eHM6c2VxdWVuY2U+DQoJCQk8eHM6 ZWxlbWVudCByZWY9InJwY09wZXJhdGlvbiIvPg0KCQk8L3hzOnNlcXVlbmNlPg0KCQk8eHM6YXR0 cmlidXRlIG5hbWU9Im1lc3NhZ2UtaWQiIHR5cGU9InhzOnN0cmluZyIgdXNlPSJyZXF1aXJlZCIv Pg0KCTwveHM6Y29tcGxleFR5cGU+DQoJPHhzOmVsZW1lbnQgbmFtZT0icnBjIiB0eXBlPSJycGNU eXBlIi8+DQoJPHhzOnNpbXBsZVR5cGUgbmFtZT0iU2Vzc2lvbklkIj4NCgkJPHhzOnJlc3RyaWN0 aW9uIGJhc2U9InhzOnVuc2lnbmVkSW50Ii8+DQoJPC94czpzaW1wbGVUeXBlPg0KCTx4czpzaW1w bGVUeXBlIG5hbWU9IkVycm9yVHlwZSI+DQoJCTx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzdHJp bmciPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJ0cmFuc3BvcnQiLz4NCgkJCTx4czplbnVt ZXJhdGlvbiB2YWx1ZT0icnBjIi8+DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9InByb3RvY29s Ii8+DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9ImFwcGxpY2F0aW9uIi8+DQoJCTwveHM6cmVz dHJpY3Rpb24+DQoJPC94czpzaW1wbGVUeXBlPg0KCTx4czpzaW1wbGVUeXBlIG5hbWU9IkVycm9y VGFnIj4NCgkJPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOnN0cmluZyI+DQoJCQk8eHM6ZW51bWVy YXRpb24gdmFsdWU9IlRPT19CSUciLz4NCgkJCTx4czplbnVtZXJhdGlvbiB2YWx1ZT0iTUlTU0lO R19BVFRSSUJVVEUiLz4NCgkJCTx4czplbnVtZXJhdGlvbiB2YWx1ZT0iQkFEX0FUVFJJQlVURSIv Pg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJVTktOT1dOX0FUVFJJQlVURSIvPg0KCQkJPHhz OmVudW1lcmF0aW9uIHZhbHVlPSJNSVNTSU5HX0VMRU1FTlQiLz4NCgkJCTx4czplbnVtZXJhdGlv biB2YWx1ZT0iQkFEX0VMRU1FTlQiLz4NCgkJCTx4czplbnVtZXJhdGlvbiB2YWx1ZT0iVU5LTk9X Tl9FTEVNRU5UIi8+DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkFDQ0VTU19ERU5JRUQiLz4N CgkJCTx4czplbnVtZXJhdGlvbiB2YWx1ZT0iTE9DS19ERU5JRUQiLz4NCgkJCTx4czplbnVtZXJh dGlvbiB2YWx1ZT0iUkVTT1VSQ0VfREVOSUVEIi8+DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9 IlJPTExCQUNLX0ZBSUxFRCIvPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJEQVRBX0VYSVNU UyIvPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJEQVRBX01JU1NJTkciLz4NCgkJCTx4czpl bnVtZXJhdGlvbiB2YWx1ZT0iT1BFUkFUSU9OX05PVF9TVVBQT1JURUQiLz4NCgkJCTx4czplbnVt ZXJhdGlvbiB2YWx1ZT0iT1BFUkFUSU9OX0ZBSUxFRCIvPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZh bHVlPSJQQVJUSUFMX09QRVJBVElPTiIvPg0KCQk8L3hzOnJlc3RyaWN0aW9uPg0KCTwveHM6c2lt cGxlVHlwZT4NCgk8eHM6c2ltcGxlVHlwZSBuYW1lPSJFcnJvclNldmVyaXR5Ij4NCgkJPHhzOnJl c3RyaWN0aW9uIGJhc2U9InhzOnN0cmluZyI+DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9ImVy cm9yIi8+DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9Indhcm5pbmciLz4NCgkJPC94czpyZXN0 cmljdGlvbj4NCgk8L3hzOnNpbXBsZVR5cGU+DQoJPHhzOmNvbXBsZXhUeXBlIG5hbWU9InJwYy1l cnJvclR5cGUiPg0KCQk8eHM6c2VxdWVuY2U+DQoJCQk8eHM6ZWxlbWVudCBuYW1lPSJlcnJvci10 eXBlIiB0eXBlPSJFcnJvclR5cGUiLz4NCgkJCTx4czplbGVtZW50IG5hbWU9ImVycm9yLXRhZyIg dHlwZT0iRXJyb3JUYWciLz4NCgkJCTx4czplbGVtZW50IG5hbWU9ImVycm9yLXNldmVyaXR5IiB0 eXBlPSJFcnJvclNldmVyaXR5Ii8+DQoJCQk8eHM6ZWxlbWVudCBuYW1lPSJlcnJvci1hcHAtdGFn IiB0eXBlPSJ4czpzdHJpbmciIG1pbk9jY3Vycz0iMCIvPg0KCQkJPHhzOmVsZW1lbnQgbmFtZT0i ZXJyb3ItcGF0aCIgdHlwZT0ieHM6c3RyaW5nIiBtaW5PY2N1cnM9IjAiLz4NCgkJCTx4czplbGVt ZW50IG5hbWU9ImVycm9yLW1lc3NhZ2UiIHR5cGU9InhzOnN0cmluZyIgbWluT2NjdXJzPSIwIi8+ DQoJCQk8eHM6ZWxlbWVudCBuYW1lPSJlcnJvci1pbmZvIiB0eXBlPSJ4czphbnlUeXBlIiBtaW5P Y2N1cnM9IjAiLz4NCgkJPC94czpzZXF1ZW5jZT4NCgk8L3hzOmNvbXBsZXhUeXBlPg0KCTwhLS0g U3RhbmRhcmQgZWxlbWVudHMgdXNlZCBpbiB0aGUgZXJyb3ItaW5mbyBjb250YWluZXIgIC0tPg0K CTx4czplbGVtZW50IG5hbWU9ImJhZC1hdHRyaWJ1dGUiIHR5cGU9InhzOlFOYW1lIi8+DQoJPHhz OmVsZW1lbnQgbmFtZT0iYmFkLWVsZW1lbnQiIHR5cGU9InhzOlFOYW1lIi8+DQoJPHhzOmVsZW1l bnQgbmFtZT0ib2stZWxlbWVudCIgdHlwZT0ieHM6UU5hbWUiLz4NCgk8eHM6ZWxlbWVudCBuYW1l PSJlcnItZWxlbWVudCIgdHlwZT0ieHM6UU5hbWUiLz4NCgk8eHM6ZWxlbWVudCBuYW1lPSJub29w LWVsZW1lbnQiIHR5cGU9InhzOlFOYW1lIi8+DQoJPHhzOmVsZW1lbnQgbmFtZT0ic2Vzc2lvbi1p ZCIgdHlwZT0iU2Vzc2lvbklkIi8+DQoJPHhzOmNvbXBsZXhUeXBlIG5hbWU9InJwYy1yZXBseVR5 cGUiPg0KCQk8eHM6Y2hvaWNlPg0KCQkJPHhzOmVsZW1lbnQgbmFtZT0ib2siIG1pbk9jY3Vycz0i MCIvPg0KCQkJPHhzOmVsZW1lbnQgbmFtZT0icnBjLWVycm9yIiB0eXBlPSJycGMtZXJyb3JUeXBl IiBtaW5PY2N1cnM9IjAiLz4NCgkJCTx4czplbGVtZW50IHJlZj0iY29uZmlnIiBtaW5PY2N1cnM9 IjAiLz4NCgkJCTx4czplbGVtZW50IHJlZj0iZGF0YSIgbWluT2NjdXJzPSIwIi8+DQoJCTwveHM6 Y2hvaWNlPg0KCQk8eHM6YXR0cmlidXRlIG5hbWU9Im1lc3NhZ2UtaWQiIHR5cGU9InhzOnN0cmlu ZyIgdXNlPSJyZXF1aXJlZCIvPg0KCTwveHM6Y29tcGxleFR5cGU+DQoJPHhzOmVsZW1lbnQgbmFt ZT0icnBjLXJlcGx5IiB0eXBlPSJycGMtcmVwbHlUeXBlIi8+DQoJPHhzOnNpbXBsZVR5cGUgbmFt ZT0idGVzdC1vcHRpb25UeXBlIj4NCgkJPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOnN0cmluZyI+ DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9InRlc3QiLz4NCgkJCTx4czplbnVtZXJhdGlvbiB2 YWx1ZT0idGVzdC10aGVuLXNldCIvPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJzZXQiLz4N CgkJPC94czpyZXN0cmljdGlvbj4NCgk8L3hzOnNpbXBsZVR5cGU+DQoJPHhzOmVsZW1lbnQgbmFt ZT0idGVzdC1vcHRpb24iIHR5cGU9InRlc3Qtb3B0aW9uVHlwZSIvPg0KCTx4czpzaW1wbGVUeXBl IG5hbWU9ImVycm9yLW9wdGlvblR5cGUiPg0KCQk8eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3Ry aW5nIj4NCgkJCTx4czplbnVtZXJhdGlvbiB2YWx1ZT0ic3RvcC1vbi1lcnJvciIvPg0KCQkJPHhz OmVudW1lcmF0aW9uIHZhbHVlPSJpZ25vcmUtZXJyb3IiLz4NCgkJCTx4czplbnVtZXJhdGlvbiB2 YWx1ZT0icm9sbGJhY2stb24tZXJyb3IiLz4NCgkJPC94czpyZXN0cmljdGlvbj4NCgk8L3hzOnNp bXBsZVR5cGU+DQoJPHhzOmVsZW1lbnQgbmFtZT0iZXJyb3Itb3B0aW9uIiB0eXBlPSJlcnJvci1v cHRpb25UeXBlIi8+DQoJPHhzOmNvbXBsZXhUeXBlIG5hbWU9InJwY09wZXJhdGlvblR5cGUiLz4N Cgk8eHM6ZWxlbWVudCBuYW1lPSJycGNPcGVyYXRpb24iIHR5cGU9InJwY09wZXJhdGlvblR5cGUi IGFic3RyYWN0PSJ0cnVlIi8+DQoJPHhzOmNvbXBsZXhUeXBlIG5hbWU9ImNvbmZpZy1pbmxpbmVU eXBlIj4NCgkJPHhzOmNvbXBsZXhDb250ZW50Pg0KCQkJPHhzOmV4dGVuc2lvbiBiYXNlPSJ4czph bnlUeXBlIi8+DQoJCTwveHM6Y29tcGxleENvbnRlbnQ+DQoJPC94czpjb21wbGV4VHlwZT4NCgk8 eHM6ZWxlbWVudCBuYW1lPSJkYXRhIiB0eXBlPSJ4czphbnlUeXBlIi8+DQoJPHhzOmVsZW1lbnQg bmFtZT0iY29uZmlnIiB0eXBlPSJjb25maWctaW5saW5lVHlwZSIvPg0KCTx4czplbGVtZW50IG5h bWU9ImZpbHRlciIgdHlwZT0iY29uZmlnLWlubGluZVR5cGUiLz4NCgk8eHM6Y29tcGxleFR5cGUg bmFtZT0iY29uZmlnLW5hbWVUeXBlIi8+DQoJPHhzOmVsZW1lbnQgbmFtZT0iY29uZmlnLW5hbWUi IHR5cGU9ImNvbmZpZy1uYW1lVHlwZSIgYWJzdHJhY3Q9InRydWUiLz4NCgk8eHM6ZWxlbWVudCBu YW1lPSJzdGFydHVwIiB0eXBlPSJjb25maWctbmFtZVR5cGUiIHN1YnN0aXR1dGlvbkdyb3VwPSJj b25maWctbmFtZSIvPg0KCTx4czplbGVtZW50IG5hbWU9ImNhbmRpZGF0ZSIgdHlwZT0iY29uZmln LW5hbWVUeXBlIiBzdWJzdGl0dXRpb25Hcm91cD0iY29uZmlnLW5hbWUiLz4NCgk8eHM6ZWxlbWVu dCBuYW1lPSJydW5uaW5nIiB0eXBlPSJjb25maWctbmFtZVR5cGUiIHN1YnN0aXR1dGlvbkdyb3Vw PSJjb25maWctbmFtZSIvPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJjb25maWctdXJpVHlwZSI+ DQoJCTx4czpzaW1wbGVDb250ZW50Pg0KCQkJPHhzOmV4dGVuc2lvbiBiYXNlPSJ4czphbnlVUkki Lz4NCgkJPC94czpzaW1wbGVDb250ZW50Pg0KCTwveHM6Y29tcGxleFR5cGU+DQoJPHhzOmVsZW1l bnQgbmFtZT0idXJsIiB0eXBlPSJjb25maWctdXJpVHlwZSIvPg0KCTx4czpjb21wbGV4VHlwZSBu YW1lPSJycGNPcGVyYXRpb25Tb3VyY2VUeXBlIj4NCgkJPHhzOmNob2ljZT4NCgkJCTx4czplbGVt ZW50IHJlZj0iY29uZmlnIi8+DQoJCQk8eHM6ZWxlbWVudCByZWY9ImNvbmZpZy1uYW1lIi8+DQoJ CQk8eHM6ZWxlbWVudCByZWY9InVybCIvPg0KCQk8L3hzOmNob2ljZT4NCgk8L3hzOmNvbXBsZXhU eXBlPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJycGNPcGVyYXRpb25HZXRTb3VyY2VUeXBlIj4N CgkJPHhzOmNob2ljZT4NCgkJCTx4czplbGVtZW50IHJlZj0iY29uZmlnLW5hbWUiLz4NCgkJCTx4 czplbGVtZW50IHJlZj0idXJsIi8+DQoJCTwveHM6Y2hvaWNlPg0KCTwveHM6Y29tcGxleFR5cGU+ DQoJPHhzOmVsZW1lbnQgbmFtZT0iZ2V0LXNvdXJjZSIgdHlwZT0icnBjT3BlcmF0aW9uR2V0U291 cmNlVHlwZSIvPg0KCTx4czplbGVtZW50IG5hbWU9InNvdXJjZSIgdHlwZT0icnBjT3BlcmF0aW9u U291cmNlVHlwZSIvPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJycGNPcGVyYXRpb25UYXJnZXRU eXBlIj4NCgkJPHhzOmNob2ljZT4NCgkJCTx4czplbGVtZW50IHJlZj0iY29uZmlnLW5hbWUiLz4N CgkJCTx4czplbGVtZW50IHJlZj0idXJsIi8+DQoJCTwveHM6Y2hvaWNlPg0KCTwveHM6Y29tcGxl eFR5cGU+DQoJPHhzOmNvbXBsZXhUeXBlIG5hbWU9InJwY09wZXJhdGlvbkxvY2tUYXJnZXRUeXBl Ij4NCgkJPHhzOmNob2ljZT4NCgkJCTx4czplbGVtZW50IHJlZj0iY29uZmlnLW5hbWUiLz4NCgkJ PC94czpjaG9pY2U+DQoJPC94czpjb21wbGV4VHlwZT4NCgk8eHM6ZWxlbWVudCBuYW1lPSJsb2Nr LXRhcmdldCIgdHlwZT0icnBjT3BlcmF0aW9uTG9ja1RhcmdldFR5cGUiLz4NCgk8eHM6ZWxlbWVu dCBuYW1lPSJ0YXJnZXQiIHR5cGU9InJwY09wZXJhdGlvblRhcmdldFR5cGUiLz4NCgk8eHM6Y29t cGxleFR5cGUgbmFtZT0iZ2V0LWNvbmZpZ1R5cGUiPg0KCQk8eHM6Y29tcGxleENvbnRlbnQ+DQoJ CQk8eHM6ZXh0ZW5zaW9uIGJhc2U9InJwY09wZXJhdGlvblR5cGUiPg0KCQkJCTx4czpzZXF1ZW5j ZT4NCgkJCQkJPHhzOmVsZW1lbnQgcmVmPSJnZXQtc291cmNlIi8+DQoJCQkJCTx4czplbGVtZW50 IHJlZj0iZmlsdGVyIiBtaW5PY2N1cnM9IjAiLz4NCgkJCQk8L3hzOnNlcXVlbmNlPg0KCQkJPC94 czpleHRlbnNpb24+DQoJCTwveHM6Y29tcGxleENvbnRlbnQ+DQoJPC94czpjb21wbGV4VHlwZT4N Cgk8eHM6ZWxlbWVudCBuYW1lPSJnZXQtY29uZmlnIiB0eXBlPSJnZXQtY29uZmlnVHlwZSIgc3Vi c3RpdHV0aW9uR3JvdXA9InJwY09wZXJhdGlvbiIvPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJl ZGl0LWNvbmZpZ1R5cGUiPg0KCQk8eHM6Y29tcGxleENvbnRlbnQ+DQoJCQk8eHM6ZXh0ZW5zaW9u IGJhc2U9InJwY09wZXJhdGlvblR5cGUiPg0KCQkJCTx4czpzZXF1ZW5jZT4NCgkJCQkJPHhzOmVs ZW1lbnQgcmVmPSJ0YXJnZXQiLz4NCgkJCQkJPHhzOmVsZW1lbnQgcmVmPSJ0ZXN0LW9wdGlvbiIg bWluT2NjdXJzPSIwIi8+DQoJCQkJCTx4czplbGVtZW50IHJlZj0iZXJyb3Itb3B0aW9uIiBtaW5P Y2N1cnM9IjAiLz4NCgkJCQkJPHhzOmVsZW1lbnQgcmVmPSJjb25maWciLz4NCgkJCQk8L3hzOnNl cXVlbmNlPg0KCQkJPC94czpleHRlbnNpb24+DQoJCTwveHM6Y29tcGxleENvbnRlbnQ+DQoJPC94 czpjb21wbGV4VHlwZT4NCgk8eHM6ZWxlbWVudCBuYW1lPSJlZGl0LWNvbmZpZyIgdHlwZT0iZWRp dC1jb25maWdUeXBlIiBzdWJzdGl0dXRpb25Hcm91cD0icnBjT3BlcmF0aW9uIi8+DQoJPHhzOmNv bXBsZXhUeXBlIG5hbWU9ImNvcHktY29uZmlnVHlwZSI+DQoJCTx4czpjb21wbGV4Q29udGVudD4N CgkJCTx4czpleHRlbnNpb24gYmFzZT0icnBjT3BlcmF0aW9uVHlwZSI+DQoJCQkJPHhzOnNlcXVl bmNlPg0KCQkJCQk8eHM6ZWxlbWVudCByZWY9InNvdXJjZSIvPg0KCQkJCQk8eHM6ZWxlbWVudCBy ZWY9InRhcmdldCIvPg0KCQkJCTwveHM6c2VxdWVuY2U+DQoJCQk8L3hzOmV4dGVuc2lvbj4NCgkJ PC94czpjb21wbGV4Q29udGVudD4NCgk8L3hzOmNvbXBsZXhUeXBlPg0KCTx4czplbGVtZW50IG5h bWU9ImNvcHktY29uZmlnIiB0eXBlPSJjb3B5LWNvbmZpZ1R5cGUiIHN1YnN0aXR1dGlvbkdyb3Vw PSJycGNPcGVyYXRpb24iLz4NCgk8eHM6Y29tcGxleFR5cGUgbmFtZT0iZGVsZXRlLWNvbmZpZ1R5 cGUiPg0KCQk8eHM6Y29tcGxleENvbnRlbnQ+DQoJCQk8eHM6ZXh0ZW5zaW9uIGJhc2U9InJwY09w ZXJhdGlvblR5cGUiPg0KCQkJCTx4czpzZXF1ZW5jZT4NCgkJCQkJPHhzOmVsZW1lbnQgcmVmPSJ0 YXJnZXQiLz4NCgkJCQk8L3hzOnNlcXVlbmNlPg0KCQkJPC94czpleHRlbnNpb24+DQoJCTwveHM6 Y29tcGxleENvbnRlbnQ+DQoJPC94czpjb21wbGV4VHlwZT4NCgk8eHM6ZWxlbWVudCBuYW1lPSJk ZWxldGUtY29uZmlnIiB0eXBlPSJkZWxldGUtY29uZmlnVHlwZSIgc3Vic3RpdHV0aW9uR3JvdXA9 InJwY09wZXJhdGlvbiIvPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJnZXRUeXBlIj4NCgkJPHhz OmNvbXBsZXhDb250ZW50Pg0KCQkJPHhzOmV4dGVuc2lvbiBiYXNlPSJycGNPcGVyYXRpb25UeXBl Ij4NCgkJCQk8eHM6c2VxdWVuY2U+DQoJCQkJCTx4czplbGVtZW50IHJlZj0iZmlsdGVyIiBtaW5P Y2N1cnM9IjAiLz4NCgkJCQk8L3hzOnNlcXVlbmNlPg0KCQkJPC94czpleHRlbnNpb24+DQoJCTwv eHM6Y29tcGxleENvbnRlbnQ+DQoJPC94czpjb21wbGV4VHlwZT4NCgk8eHM6ZWxlbWVudCBuYW1l PSJnZXQiIHR5cGU9ImdldFR5cGUiIHN1YnN0aXR1dGlvbkdyb3VwPSJycGNPcGVyYXRpb24iLz4N Cgk8eHM6Y29tcGxleFR5cGUgbmFtZT0ibG9ja1R5cGUiPg0KCQk8eHM6Y29tcGxleENvbnRlbnQ+ DQoJCQk8eHM6ZXh0ZW5zaW9uIGJhc2U9InJwY09wZXJhdGlvblR5cGUiPg0KCQkJCTx4czpzZXF1 ZW5jZT4NCgkJCQkJPHhzOmVsZW1lbnQgcmVmPSJsb2NrLXRhcmdldCIvPg0KCQkJCTwveHM6c2Vx dWVuY2U+DQoJCQk8L3hzOmV4dGVuc2lvbj4NCgkJPC94czpjb21wbGV4Q29udGVudD4NCgk8L3hz OmNvbXBsZXhUeXBlPg0KCTx4czplbGVtZW50IG5hbWU9ImxvY2siIHR5cGU9ImxvY2tUeXBlIiBz dWJzdGl0dXRpb25Hcm91cD0icnBjT3BlcmF0aW9uIi8+DQoJPHhzOmNvbXBsZXhUeXBlIG5hbWU9 InVubG9ja1R5cGUiPg0KCQk8eHM6Y29tcGxleENvbnRlbnQ+DQoJCQk8eHM6ZXh0ZW5zaW9uIGJh c2U9InJwY09wZXJhdGlvblR5cGUiPg0KCQkJCTx4czpzZXF1ZW5jZT4NCgkJCQkJPHhzOmVsZW1l bnQgcmVmPSJsb2NrLXRhcmdldCIvPg0KCQkJCTwveHM6c2VxdWVuY2U+DQoJCQk8L3hzOmV4dGVu c2lvbj4NCgkJPC94czpjb21wbGV4Q29udGVudD4NCgk8L3hzOmNvbXBsZXhUeXBlPg0KCTx4czpl bGVtZW50IG5hbWU9InVubG9jayIgdHlwZT0idW5sb2NrVHlwZSIgc3Vic3RpdHV0aW9uR3JvdXA9 InJwY09wZXJhdGlvbiIvPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJ2YWxpZGF0ZVR5cGUiPg0K CQk8eHM6Y29tcGxleENvbnRlbnQ+DQoJCQk8eHM6ZXh0ZW5zaW9uIGJhc2U9InJwY09wZXJhdGlv blR5cGUiPg0KCQkJCTx4czpzZXF1ZW5jZT4NCgkJCQkJPHhzOmVsZW1lbnQgcmVmPSJzb3VyY2Ui Lz4NCgkJCQk8L3hzOnNlcXVlbmNlPg0KCQkJPC94czpleHRlbnNpb24+DQoJCTwveHM6Y29tcGxl eENvbnRlbnQ+DQoJPC94czpjb21wbGV4VHlwZT4NCgk8eHM6ZWxlbWVudCBuYW1lPSJ2YWxpZGF0 ZSIgdHlwZT0idmFsaWRhdGVUeXBlIiBzdWJzdGl0dXRpb25Hcm91cD0icnBjT3BlcmF0aW9uIi8+ DQoJPHhzOmNvbXBsZXhUeXBlIG5hbWU9ImNvbW1pdFR5cGUiPg0KCQk8eHM6Y29tcGxleENvbnRl bnQ+DQoJCQk8eHM6ZXh0ZW5zaW9uIGJhc2U9InJwY09wZXJhdGlvblR5cGUiPg0KCQkJCTx4czpz ZXF1ZW5jZT4NCgkJCQkJPHhzOmVsZW1lbnQgbmFtZT0iY29uZmlybWVkIiBtaW5PY2N1cnM9IjAi Lz4NCgkJCQkJPHhzOmVsZW1lbnQgbmFtZT0iY29uZmlybWVkLXRpbWVvdXQiIG1pbk9jY3Vycz0i MCIvPg0KCQkJCTwveHM6c2VxdWVuY2U+DQoJCQk8L3hzOmV4dGVuc2lvbj4NCgkJPC94czpjb21w bGV4Q29udGVudD4NCgk8L3hzOmNvbXBsZXhUeXBlPg0KCTx4czplbGVtZW50IG5hbWU9ImNvbW1p dCIgdHlwZT0iY29tbWl0VHlwZSIgc3Vic3RpdHV0aW9uR3JvdXA9InJwY09wZXJhdGlvbiIvPg0K CTx4czpjb21wbGV4VHlwZSBuYW1lPSJkaXNjYXJkLWNoYW5nZXNUeXBlIj4NCgkJPHhzOmNvbXBs ZXhDb250ZW50Pg0KCQkJPHhzOmV4dGVuc2lvbiBiYXNlPSJycGNPcGVyYXRpb25UeXBlIi8+DQoJ CTwveHM6Y29tcGxleENvbnRlbnQ+DQoJPC94czpjb21wbGV4VHlwZT4NCgk8eHM6ZWxlbWVudCBu YW1lPSJkaXNjYXJkLWNoYW5nZXMiIHR5cGU9ImRpc2NhcmQtY2hhbmdlc1R5cGUiIHN1YnN0aXR1 dGlvbkdyb3VwPSJycGNPcGVyYXRpb24iLz4NCgk8eHM6Y29tcGxleFR5cGUgbmFtZT0iY2xvc2Ut c2Vzc2lvblR5cGUiPg0KCQk8eHM6Y29tcGxleENvbnRlbnQ+DQoJCQk8eHM6ZXh0ZW5zaW9uIGJh c2U9InJwY09wZXJhdGlvblR5cGUiLz4NCgkJPC94czpjb21wbGV4Q29udGVudD4NCgk8L3hzOmNv bXBsZXhUeXBlPg0KCTx4czplbGVtZW50IG5hbWU9ImNsb3NlLXNlc3Npb24iIHR5cGU9ImNsb3Nl LXNlc3Npb25UeXBlIiBzdWJzdGl0dXRpb25Hcm91cD0icnBjT3BlcmF0aW9uIi8+DQoJPHhzOmNv bXBsZXhUeXBlIG5hbWU9ImtpbGwtc2Vzc2lvblR5cGUiPg0KCQk8eHM6Y29tcGxleENvbnRlbnQ+ DQoJCQk8eHM6ZXh0ZW5zaW9uIGJhc2U9InJwY09wZXJhdGlvblR5cGUiPg0KCQkJCTx4czpzZXF1 ZW5jZT4NCgkJCQkJPHhzOmVsZW1lbnQgbmFtZT0ic2Vzc2lvbi1pZCIgdHlwZT0iU2Vzc2lvbklk Ii8+DQoJCQkJPC94czpzZXF1ZW5jZT4NCgkJCTwveHM6ZXh0ZW5zaW9uPg0KCQk8L3hzOmNvbXBs ZXhDb250ZW50Pg0KCTwveHM6Y29tcGxleFR5cGU+DQoJPHhzOmVsZW1lbnQgbmFtZT0ia2lsbC1z ZXNzaW9uIiB0eXBlPSJraWxsLXNlc3Npb25UeXBlIiBzdWJzdGl0dXRpb25Hcm91cD0icnBjT3Bl cmF0aW9uIi8+DQo8L3hzOnNjaGVtYT4NCjwvWE1QPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C47967.267DCC01-- -- 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 Aug 4 02:26:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09227 for ; Wed, 4 Aug 2004 02:26:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BsF3m-000I1Y-JR for netconf-data@psg.com; Wed, 04 Aug 2004 06:15:34 +0000 Received: from [164.164.31.6] (helo=wiproecmx2.wipro.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BsF3Y-000I0b-L9 for netconf@ops.ietf.org; Wed, 04 Aug 2004 06:15:23 +0000 Received: from ec-vwall-wd (ec-vwall-wd.wipro.com [10.200.52.125]) by wiproecmx2.wipro.com (8.12.9-20031013/8.12.9) with SMTP id i746FDO7009896 for ; Wed, 4 Aug 2004 11:45:16 +0530 (IST) Received: from blr-ec-bh2.wipro.com ([10.200.50.92]) by ec-vwall-wd with InterScan Messaging Security Suite; Wed, 04 Aug 2004 11:45:11 +0530 Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Aug 2004 11:44:46 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C479EA.2D2946C6" Subject: RE: comments on NETCONF RPC and Protocol Operations Schema Date: Wed, 4 Aug 2004 11:43:36 +0530 Message-ID: <184E80410B37F54F8FAFE5CF9AD757C4013F5660@blr-m2-msg.wipro.com> X-MS-Has-Attach: yes Thread-Topic: comments on NETCONF RPC and Protocol Operations Schema Thread-Index: AcR5Z+R7MSM49Gb/SjSNz27QWJob1QAgkxPQ From: To: X-OriginalArrivalTime: 04 Aug 2004 06:14:46.0654 (UTC) FILETIME=[574319E0:01C479EA] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_01, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C479EA.2D2946C6 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C479EA.2D2946C6" ------_=_NextPart_002_01C479EA.2D2946C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Resending the schema in text format. =20 =20 =20 =20 Thanks & Regards, V.Sarma =20 ------_=_NextPart_002_01C479EA.2D2946C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 All,
    =20 Resending the schema in text format.
 
 
<xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchem= a">
 <xs:complexType=20 name=3D"rpcType">
  <xs:sequence>
  &n= bsp;<xs:element=20 ref=3D"rpcOperation"/>
  </xs:sequence>
 &n= bsp;<xs:attribute=20 name=3D"message-id" type=3D"xs:string"=20 use=3D"required"/>
 </xs:complexType>
 <xs:el= ement=20 name=3D"rpc" type=3D"rpcType"/>
 <xs:simpleType=20 name=3D"SessionId">
  <xs:restriction=20 base=3D"xs:unsignedInt"/>
 </xs:simpleType>
 <= ;xs:simpleType=20 name=3D"ErrorType">
  <xs:restriction=20 base=3D"xs:string">
   <xs:enumeration=20 value=3D"transport"/>
   <xs:enumeration=20 value=3D"rpc"/>
   <xs:enumeration=20 value=3D"protocol"/>
   <xs:enumeration=20 value=3D"application"/>
  </xs:restriction>
&nbs= p;</xs:simpleType>
 <xs:simpleType=20 name=3D"ErrorTag">
  <xs:restriction=20 base=3D"xs:string">
   <xs:enumeration=20 value=3D"TOO_BIG"/>
   <xs:enumeration=20 value=3D"MISSING_ATTRIBUTE"/>
   <xs:enumeration = value=3D"BAD_ATTRIBUTE"/>
   <xs:enumeration=20 value=3D"UNKNOWN_ATTRIBUTE"/>
   <xs:enumeration = value=3D"MISSING_ELEMENT"/>
   <xs:enumeration=20 value=3D"BAD_ELEMENT"/>
   <xs:enumeration=20 value=3D"UNKNOWN_ELEMENT"/>
   <xs:enumeration=20 value=3D"ACCESS_DENIED"/>
   <xs:enumeration=20 value=3D"LOCK_DENIED"/>
   <xs:enumeration=20 value=3D"RESOURCE_DENIED"/>
   <xs:enumeration=20 value=3D"ROLLBACK_FAILED"/>
   <xs:enumeration=20 value=3D"DATA_EXISTS"/>
   <xs:enumeration=20 value=3D"DATA_MISSING"/>
   <xs:enumeration=20 value=3D"OPERATION_NOT_SUPPORTED"/>
   <xs:enumer= ation=20 value=3D"OPERATION_FAILED"/>
   <xs:enumeration=20 value=3D"PARTIAL_OPERATION"/>
  </xs:restriction> </xs:simpleType>
 <xs:simpleType=20 name=3D"ErrorSeverity">
  <xs:restriction=20 base=3D"xs:string">
   <xs:enumeration=20 value=3D"error"/>
   <xs:enumeration=20 value=3D"warning"/>
  </xs:restriction>
 &l= t;/xs:simpleType>
 <xs:complexType=20 name=3D"rpc-errorType">
  <xs:sequence>
 &n= bsp; <xs:element=20 name=3D"error-type" = type=3D"ErrorType"/>
   <xs:element=20 name=3D"error-tag" = type=3D"ErrorTag"/>
   <xs:element=20 name=3D"error-severity"=20 type=3D"ErrorSeverity"/>
   <xs:element=20 name=3D"error-app-tag" type=3D"xs:string"=20 minOccurs=3D"0"/>
   <xs:element = name=3D"error-path"=20 type=3D"xs:string" = minOccurs=3D"0"/>
   <xs:element=20 name=3D"error-message" type=3D"xs:string"=20 minOccurs=3D"0"/>
   <xs:element = name=3D"error-info"=20 type=3D"xs:anyType"=20 minOccurs=3D"0"/>
  </xs:sequence>
 </xs= :complexType>
 <!--=20 Standard elements used in the error-info container =20 -->
 <xs:element name=3D"bad-attribute"=20 type=3D"xs:QName"/>
 <xs:element name=3D"bad-element"=20 type=3D"xs:QName"/>
 <xs:element name=3D"ok-element"=20 type=3D"xs:QName"/>
 <xs:element name=3D"err-element"=20 type=3D"xs:QName"/>
 <xs:element name=3D"noop-element"=20 type=3D"xs:QName"/>
 <xs:element name=3D"session-id"=20 type=3D"SessionId"/>
 <xs:complexType=20 name=3D"rpc-replyType">
  <xs:choice>
 &nbs= p; <xs:element=20 name=3D"ok" minOccurs=3D"0"/>
   <xs:element=20 name=3D"rpc-error" type=3D"rpc-errorType"=20 minOccurs=3D"0"/>
   <xs:element ref=3D"config"=20 minOccurs=3D"0"/>
   <xs:element ref=3D"data"=20 minOccurs=3D"0"/>
  </xs:choice>
  <= ;xs:attribute=20 name=3D"message-id" type=3D"xs:string"=20 use=3D"required"/>
 </xs:complexType>
 <xs:el= ement=20 name=3D"rpc-reply" = type=3D"rpc-replyType"/>
 <xs:simpleType=20 name=3D"test-optionType">
  <xs:restriction=20 base=3D"xs:string">
   <xs:enumeration=20 value=3D"test"/>
   <xs:enumeration=20 value=3D"test-then-set"/>
   <xs:enumeration=20 value=3D"set"/>
  </xs:restriction>
 </x= s:simpleType>
 <xs:element=20 name=3D"test-option" = type=3D"test-optionType"/>
 <xs:simpleType=20 name=3D"error-optionType">
  <xs:restriction=20 base=3D"xs:string">
   <xs:enumeration=20 value=3D"stop-on-error"/>
   <xs:enumeration=20 value=3D"ignore-error"/>
   <xs:enumeration=20 value=3D"rollback-on-error"/>
  </xs:restriction> </xs:simpleType>
 <xs:element=20 name=3D"error-option" = type=3D"error-optionType"/>
 <xs:complexType=20 name=3D"rpcOperationType"/>
 <xs:element = name=3D"rpcOperation"=20 type=3D"rpcOperationType" = abstract=3D"true"/>
 <xs:complexType=20 name=3D"config-inlineType">
  <xs:complexContent>   <xs:extension=20 base=3D"xs:anyType"/>
  </xs:complexContent>
&nb= sp;</xs:complexType>
 <xs:element=20 name=3D"data" type=3D"xs:anyType"/>
 <xs:element = name=3D"config"=20 type=3D"config-inlineType"/>
 <xs:element name=3D"filter"=20 type=3D"config-inlineType"/>
 <xs:complexType=20 name=3D"config-nameType"/>
 <xs:element = name=3D"config-name"=20 type=3D"config-nameType" abstract=3D"true"/>
 <xs:element=20 name=3D"startup" type=3D"config-nameType"=20 substitutionGroup=3D"config-name"/>
 <xs:element = name=3D"candidate"=20 type=3D"config-nameType"=20 substitutionGroup=3D"config-name"/>
 <xs:element = name=3D"running"=20 type=3D"config-nameType"=20 substitutionGroup=3D"config-name"/>
 <xs:complexType=20 name=3D"config-uriType">
  <xs:simpleContent>
&n= bsp;  <xs:extension=20 base=3D"xs:anyURI"/>
  </xs:simpleContent>
 = ;</xs:complexType>
 <xs:element=20 name=3D"url" type=3D"config-uriType"/>
 <xs:complexType=20 name=3D"rpcOperationSourceType">
  <xs:choice>
&= nbsp;  <xs:element=20 ref=3D"config"/>
   <xs:element=20 ref=3D"config-name"/>
   <xs:element=20 ref=3D"url"/>
  </xs:choice>
 </xs:compl= exType>
 <xs:complexType=20 name=3D"rpcOperationGetSourceType">
  <xs:choice>   <xs:element=20 ref=3D"config-name"/>
   <xs:element=20 ref=3D"url"/>
  </xs:choice>
 </xs:compl= exType>
 <xs:element=20 name=3D"get-source" = type=3D"rpcOperationGetSourceType"/>
 <xs:element=20 name=3D"source" = type=3D"rpcOperationSourceType"/>
 <xs:complexType=20 name=3D"rpcOperationTargetType">
  <xs:choice>
&= nbsp;  <xs:element=20 ref=3D"config-name"/>
   <xs:element=20 ref=3D"url"/>
  </xs:choice>
 </xs:compl= exType>
 <xs:complexType=20 name=3D"rpcOperationLockTargetType">
  <xs:choice><= BR>   <xs:element=20 ref=3D"config-name"/>
  </xs:choice>
 </= xs:complexType>
 <xs:element=20 name=3D"lock-target"=20 type=3D"rpcOperationLockTargetType"/>
 <xs:element = name=3D"target"=20 type=3D"rpcOperationTargetType"/>
 <xs:complexType=20 name=3D"get-configType">
  <xs:complexContent>
&= nbsp;  <xs:extension=20 base=3D"rpcOperationType">
    <xs:sequence&= gt;
     <xs:element=20 ref=3D"get-source"/>
     <xs:element=20 ref=3D"filter"=20 minOccurs=3D"0"/>
    </xs:sequence>
&= nbsp;  </xs:extension>
  </xs:complexCont= ent>
 </xs:complexType>
 <xs:element=20 name=3D"get-config" type=3D"get-configType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"edit-configType">
  <xs:complexContent>
=    <xs:extension=20 base=3D"rpcOperationType">
    <xs:sequence&= gt;
     <xs:element=20 ref=3D"target"/>
     <xs:element=20 ref=3D"test-option"=20 minOccurs=3D"0"/>
     <xs:element=20 ref=3D"error-option"=20 minOccurs=3D"0"/>
     <xs:element=20 ref=3D"config"/>
    </xs:sequence>
&n= bsp;  </xs:extension>
  </xs:complexConte= nt>
 </xs:complexType>
 <xs:element=20 name=3D"edit-config" type=3D"edit-configType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"copy-configType">
  <xs:complexContent>
=    <xs:extension=20 base=3D"rpcOperationType">
    <xs:sequence&= gt;
     <xs:element=20 ref=3D"source"/>
     <xs:element=20 ref=3D"target"/>
    </xs:sequence>
&n= bsp;  </xs:extension>
  </xs:complexConte= nt>
 </xs:complexType>
 <xs:element=20 name=3D"copy-config" type=3D"copy-configType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"delete-configType">
  <xs:complexContent>   <xs:extension=20 base=3D"rpcOperationType">
    <xs:sequence&= gt;
     <xs:element=20 ref=3D"target"/>
    </xs:sequence>
&n= bsp;  </xs:extension>
  </xs:complexConte= nt>
 </xs:complexType>
 <xs:element=20 name=3D"delete-config" type=3D"delete-configType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"getType">
  <xs:complexContent>
 &n= bsp; <xs:extension=20 base=3D"rpcOperationType">
    <xs:sequence&= gt;
     <xs:element=20 ref=3D"filter"=20 minOccurs=3D"0"/>
    </xs:sequence>
&= nbsp;  </xs:extension>
  </xs:complexCont= ent>
 </xs:complexType>
 <xs:element=20 name=3D"get" type=3D"getType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"lockType">
  <xs:complexContent>
 &= nbsp; <xs:extension=20 base=3D"rpcOperationType">
    <xs:sequence&= gt;
     <xs:element=20 ref=3D"lock-target"/>
    </xs:sequence><= BR>   </xs:extension>
  </xs:complex= Content>
 </xs:complexType>
 <xs:element=20 name=3D"lock" type=3D"lockType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"unlockType">
  <xs:complexContent>
 = ;  <xs:extension=20 base=3D"rpcOperationType">
    <xs:sequence&= gt;
     <xs:element=20 ref=3D"lock-target"/>
    </xs:sequence><= BR>   </xs:extension>
  </xs:complex= Content>
 </xs:complexType>
 <xs:element=20 name=3D"unlock" type=3D"unlockType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"validateType">
  <xs:complexContent>
&nb= sp;  <xs:extension=20 base=3D"rpcOperationType">
    <xs:sequence&= gt;
     <xs:element=20 ref=3D"source"/>
    </xs:sequence>
&n= bsp;  </xs:extension>
  </xs:complexConte= nt>
 </xs:complexType>
 <xs:element=20 name=3D"validate" type=3D"validateType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"commitType">
  <xs:complexContent>
 = ;  <xs:extension=20 base=3D"rpcOperationType">
    <xs:sequence&= gt;
     <xs:element=20 name=3D"confirmed"=20 minOccurs=3D"0"/>
     <xs:element=20 name=3D"confirmed-timeout"=20 minOccurs=3D"0"/>
    </xs:sequence>
&= nbsp;  </xs:extension>
  </xs:complexCont= ent>
 </xs:complexType>
 <xs:element=20 name=3D"commit" type=3D"commitType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"discard-changesType">
  <xs:complexContent>=
   <xs:extension=20 base=3D"rpcOperationType"/>
  </xs:complexContent><= BR> </xs:complexType>
 <xs:element=20 name=3D"discard-changes" type=3D"discard-changesType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"close-sessionType">
  <xs:complexContent>   <xs:extension=20 base=3D"rpcOperationType"/>
  </xs:complexContent><= BR> </xs:complexType>
 <xs:element=20 name=3D"close-session" type=3D"close-sessionType"=20 substitutionGroup=3D"rpcOperation"/>
 <xs:complexType=20 name=3D"kill-sessionType">
  <xs:complexContent>   <xs:extension=20 base=3D"rpcOperationType">
    <xs:sequence&= gt;
     <xs:element=20 name=3D"session-id"=20 type=3D"SessionId"/>
    </xs:sequence>   </xs:extension>
  </xs:complexC= ontent>
 </xs:complexType>
 <xs:element=20 name=3D"kill-session" type=3D"kill-sessionType"=20 substitutionGroup=3D"rpcOperation"/>
</xs:schema>
 
 
Thanks=20 & Regards,
V.Sarma
 
------_=_NextPart_002_01C479EA.2D2946C6-- ------_=_NextPart_001_01C479EA.2D2946C6 Content-Type: text/plain; name="NewNetconfSchema.xsd.txt" Content-Transfer-Encoding: base64 Content-Description: NewNetconfSchema.xsd.txt Content-Disposition: attachment; filename="NewNetconfSchema.xsd.txt" Content-Transfer-Encoding: base64 PHhzOnNjaGVtYSB4bWxuczp4cz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEiPg0K CTx4czpjb21wbGV4VHlwZSBuYW1lPSJycGNUeXBlIj4NCgkJPHhzOnNlcXVlbmNlPg0KCQkJPHhz OmVsZW1lbnQgcmVmPSJycGNPcGVyYXRpb24iLz4NCgkJPC94czpzZXF1ZW5jZT4NCgkJPHhzOmF0 dHJpYnV0ZSBuYW1lPSJtZXNzYWdlLWlkIiB0eXBlPSJ4czpzdHJpbmciIHVzZT0icmVxdWlyZWQi Lz4NCgk8L3hzOmNvbXBsZXhUeXBlPg0KCTx4czplbGVtZW50IG5hbWU9InJwYyIgdHlwZT0icnBj VHlwZSIvPg0KCTx4czpzaW1wbGVUeXBlIG5hbWU9IlNlc3Npb25JZCI+DQoJCTx4czpyZXN0cmlj dGlvbiBiYXNlPSJ4czp1bnNpZ25lZEludCIvPg0KCTwveHM6c2ltcGxlVHlwZT4NCgk8eHM6c2lt cGxlVHlwZSBuYW1lPSJFcnJvclR5cGUiPg0KCQk8eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3Ry aW5nIj4NCgkJCTx4czplbnVtZXJhdGlvbiB2YWx1ZT0idHJhbnNwb3J0Ii8+DQoJCQk8eHM6ZW51 bWVyYXRpb24gdmFsdWU9InJwYyIvPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJwcm90b2Nv bCIvPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJhcHBsaWNhdGlvbiIvPg0KCQk8L3hzOnJl c3RyaWN0aW9uPg0KCTwveHM6c2ltcGxlVHlwZT4NCgk8eHM6c2ltcGxlVHlwZSBuYW1lPSJFcnJv clRhZyI+DQoJCTx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzdHJpbmciPg0KCQkJPHhzOmVudW1l cmF0aW9uIHZhbHVlPSJUT09fQklHIi8+DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9Ik1JU1NJ TkdfQVRUUklCVVRFIi8+DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkJBRF9BVFRSSUJVVEUi Lz4NCgkJCTx4czplbnVtZXJhdGlvbiB2YWx1ZT0iVU5LTk9XTl9BVFRSSUJVVEUiLz4NCgkJCTx4 czplbnVtZXJhdGlvbiB2YWx1ZT0iTUlTU0lOR19FTEVNRU5UIi8+DQoJCQk8eHM6ZW51bWVyYXRp b24gdmFsdWU9IkJBRF9FTEVNRU5UIi8+DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9IlVOS05P V05fRUxFTUVOVCIvPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJBQ0NFU1NfREVOSUVEIi8+ DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9IkxPQ0tfREVOSUVEIi8+DQoJCQk8eHM6ZW51bWVy YXRpb24gdmFsdWU9IlJFU09VUkNFX0RFTklFRCIvPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVl PSJST0xMQkFDS19GQUlMRUQiLz4NCgkJCTx4czplbnVtZXJhdGlvbiB2YWx1ZT0iREFUQV9FWElT VFMiLz4NCgkJCTx4czplbnVtZXJhdGlvbiB2YWx1ZT0iREFUQV9NSVNTSU5HIi8+DQoJCQk8eHM6 ZW51bWVyYXRpb24gdmFsdWU9Ik9QRVJBVElPTl9OT1RfU1VQUE9SVEVEIi8+DQoJCQk8eHM6ZW51 bWVyYXRpb24gdmFsdWU9Ik9QRVJBVElPTl9GQUlMRUQiLz4NCgkJCTx4czplbnVtZXJhdGlvbiB2 YWx1ZT0iUEFSVElBTF9PUEVSQVRJT04iLz4NCgkJPC94czpyZXN0cmljdGlvbj4NCgk8L3hzOnNp bXBsZVR5cGU+DQoJPHhzOnNpbXBsZVR5cGUgbmFtZT0iRXJyb3JTZXZlcml0eSI+DQoJCTx4czpy ZXN0cmljdGlvbiBiYXNlPSJ4czpzdHJpbmciPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJl cnJvciIvPg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJ3YXJuaW5nIi8+DQoJCTwveHM6cmVz dHJpY3Rpb24+DQoJPC94czpzaW1wbGVUeXBlPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJycGMt ZXJyb3JUeXBlIj4NCgkJPHhzOnNlcXVlbmNlPg0KCQkJPHhzOmVsZW1lbnQgbmFtZT0iZXJyb3It dHlwZSIgdHlwZT0iRXJyb3JUeXBlIi8+DQoJCQk8eHM6ZWxlbWVudCBuYW1lPSJlcnJvci10YWci IHR5cGU9IkVycm9yVGFnIi8+DQoJCQk8eHM6ZWxlbWVudCBuYW1lPSJlcnJvci1zZXZlcml0eSIg dHlwZT0iRXJyb3JTZXZlcml0eSIvPg0KCQkJPHhzOmVsZW1lbnQgbmFtZT0iZXJyb3ItYXBwLXRh ZyIgdHlwZT0ieHM6c3RyaW5nIiBtaW5PY2N1cnM9IjAiLz4NCgkJCTx4czplbGVtZW50IG5hbWU9 ImVycm9yLXBhdGgiIHR5cGU9InhzOnN0cmluZyIgbWluT2NjdXJzPSIwIi8+DQoJCQk8eHM6ZWxl bWVudCBuYW1lPSJlcnJvci1tZXNzYWdlIiB0eXBlPSJ4czpzdHJpbmciIG1pbk9jY3Vycz0iMCIv Pg0KCQkJPHhzOmVsZW1lbnQgbmFtZT0iZXJyb3ItaW5mbyIgdHlwZT0ieHM6YW55VHlwZSIgbWlu T2NjdXJzPSIwIi8+DQoJCTwveHM6c2VxdWVuY2U+DQoJPC94czpjb21wbGV4VHlwZT4NCgk8IS0t IFN0YW5kYXJkIGVsZW1lbnRzIHVzZWQgaW4gdGhlIGVycm9yLWluZm8gY29udGFpbmVyICAtLT4N Cgk8eHM6ZWxlbWVudCBuYW1lPSJiYWQtYXR0cmlidXRlIiB0eXBlPSJ4czpRTmFtZSIvPg0KCTx4 czplbGVtZW50IG5hbWU9ImJhZC1lbGVtZW50IiB0eXBlPSJ4czpRTmFtZSIvPg0KCTx4czplbGVt ZW50IG5hbWU9Im9rLWVsZW1lbnQiIHR5cGU9InhzOlFOYW1lIi8+DQoJPHhzOmVsZW1lbnQgbmFt ZT0iZXJyLWVsZW1lbnQiIHR5cGU9InhzOlFOYW1lIi8+DQoJPHhzOmVsZW1lbnQgbmFtZT0ibm9v cC1lbGVtZW50IiB0eXBlPSJ4czpRTmFtZSIvPg0KCTx4czplbGVtZW50IG5hbWU9InNlc3Npb24t aWQiIHR5cGU9IlNlc3Npb25JZCIvPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJycGMtcmVwbHlU eXBlIj4NCgkJPHhzOmNob2ljZT4NCgkJCTx4czplbGVtZW50IG5hbWU9Im9rIiBtaW5PY2N1cnM9 IjAiLz4NCgkJCTx4czplbGVtZW50IG5hbWU9InJwYy1lcnJvciIgdHlwZT0icnBjLWVycm9yVHlw ZSIgbWluT2NjdXJzPSIwIi8+DQoJCQk8eHM6ZWxlbWVudCByZWY9ImNvbmZpZyIgbWluT2NjdXJz PSIwIi8+DQoJCQk8eHM6ZWxlbWVudCByZWY9ImRhdGEiIG1pbk9jY3Vycz0iMCIvPg0KCQk8L3hz OmNob2ljZT4NCgkJPHhzOmF0dHJpYnV0ZSBuYW1lPSJtZXNzYWdlLWlkIiB0eXBlPSJ4czpzdHJp bmciIHVzZT0icmVxdWlyZWQiLz4NCgk8L3hzOmNvbXBsZXhUeXBlPg0KCTx4czplbGVtZW50IG5h bWU9InJwYy1yZXBseSIgdHlwZT0icnBjLXJlcGx5VHlwZSIvPg0KCTx4czpzaW1wbGVUeXBlIG5h bWU9InRlc3Qtb3B0aW9uVHlwZSI+DQoJCTx4czpyZXN0cmljdGlvbiBiYXNlPSJ4czpzdHJpbmci Pg0KCQkJPHhzOmVudW1lcmF0aW9uIHZhbHVlPSJ0ZXN0Ii8+DQoJCQk8eHM6ZW51bWVyYXRpb24g dmFsdWU9InRlc3QtdGhlbi1zZXQiLz4NCgkJCTx4czplbnVtZXJhdGlvbiB2YWx1ZT0ic2V0Ii8+ DQoJCTwveHM6cmVzdHJpY3Rpb24+DQoJPC94czpzaW1wbGVUeXBlPg0KCTx4czplbGVtZW50IG5h bWU9InRlc3Qtb3B0aW9uIiB0eXBlPSJ0ZXN0LW9wdGlvblR5cGUiLz4NCgk8eHM6c2ltcGxlVHlw ZSBuYW1lPSJlcnJvci1vcHRpb25UeXBlIj4NCgkJPHhzOnJlc3RyaWN0aW9uIGJhc2U9InhzOnN0 cmluZyI+DQoJCQk8eHM6ZW51bWVyYXRpb24gdmFsdWU9InN0b3Atb24tZXJyb3IiLz4NCgkJCTx4 czplbnVtZXJhdGlvbiB2YWx1ZT0iaWdub3JlLWVycm9yIi8+DQoJCQk8eHM6ZW51bWVyYXRpb24g dmFsdWU9InJvbGxiYWNrLW9uLWVycm9yIi8+DQoJCTwveHM6cmVzdHJpY3Rpb24+DQoJPC94czpz aW1wbGVUeXBlPg0KCTx4czplbGVtZW50IG5hbWU9ImVycm9yLW9wdGlvbiIgdHlwZT0iZXJyb3It b3B0aW9uVHlwZSIvPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJycGNPcGVyYXRpb25UeXBlIi8+ DQoJPHhzOmVsZW1lbnQgbmFtZT0icnBjT3BlcmF0aW9uIiB0eXBlPSJycGNPcGVyYXRpb25UeXBl IiBhYnN0cmFjdD0idHJ1ZSIvPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJjb25maWctaW5saW5l VHlwZSI+DQoJCTx4czpjb21wbGV4Q29udGVudD4NCgkJCTx4czpleHRlbnNpb24gYmFzZT0ieHM6 YW55VHlwZSIvPg0KCQk8L3hzOmNvbXBsZXhDb250ZW50Pg0KCTwveHM6Y29tcGxleFR5cGU+DQoJ PHhzOmVsZW1lbnQgbmFtZT0iZGF0YSIgdHlwZT0ieHM6YW55VHlwZSIvPg0KCTx4czplbGVtZW50 IG5hbWU9ImNvbmZpZyIgdHlwZT0iY29uZmlnLWlubGluZVR5cGUiLz4NCgk8eHM6ZWxlbWVudCBu YW1lPSJmaWx0ZXIiIHR5cGU9ImNvbmZpZy1pbmxpbmVUeXBlIi8+DQoJPHhzOmNvbXBsZXhUeXBl IG5hbWU9ImNvbmZpZy1uYW1lVHlwZSIvPg0KCTx4czplbGVtZW50IG5hbWU9ImNvbmZpZy1uYW1l IiB0eXBlPSJjb25maWctbmFtZVR5cGUiIGFic3RyYWN0PSJ0cnVlIi8+DQoJPHhzOmVsZW1lbnQg bmFtZT0ic3RhcnR1cCIgdHlwZT0iY29uZmlnLW5hbWVUeXBlIiBzdWJzdGl0dXRpb25Hcm91cD0i Y29uZmlnLW5hbWUiLz4NCgk8eHM6ZWxlbWVudCBuYW1lPSJjYW5kaWRhdGUiIHR5cGU9ImNvbmZp Zy1uYW1lVHlwZSIgc3Vic3RpdHV0aW9uR3JvdXA9ImNvbmZpZy1uYW1lIi8+DQoJPHhzOmVsZW1l bnQgbmFtZT0icnVubmluZyIgdHlwZT0iY29uZmlnLW5hbWVUeXBlIiBzdWJzdGl0dXRpb25Hcm91 cD0iY29uZmlnLW5hbWUiLz4NCgk8eHM6Y29tcGxleFR5cGUgbmFtZT0iY29uZmlnLXVyaVR5cGUi Pg0KCQk8eHM6c2ltcGxlQ29udGVudD4NCgkJCTx4czpleHRlbnNpb24gYmFzZT0ieHM6YW55VVJJ Ii8+DQoJCTwveHM6c2ltcGxlQ29udGVudD4NCgk8L3hzOmNvbXBsZXhUeXBlPg0KCTx4czplbGVt ZW50IG5hbWU9InVybCIgdHlwZT0iY29uZmlnLXVyaVR5cGUiLz4NCgk8eHM6Y29tcGxleFR5cGUg bmFtZT0icnBjT3BlcmF0aW9uU291cmNlVHlwZSI+DQoJCTx4czpjaG9pY2U+DQoJCQk8eHM6ZWxl bWVudCByZWY9ImNvbmZpZyIvPg0KCQkJPHhzOmVsZW1lbnQgcmVmPSJjb25maWctbmFtZSIvPg0K CQkJPHhzOmVsZW1lbnQgcmVmPSJ1cmwiLz4NCgkJPC94czpjaG9pY2U+DQoJPC94czpjb21wbGV4 VHlwZT4NCgk8eHM6Y29tcGxleFR5cGUgbmFtZT0icnBjT3BlcmF0aW9uR2V0U291cmNlVHlwZSI+ DQoJCTx4czpjaG9pY2U+DQoJCQk8eHM6ZWxlbWVudCByZWY9ImNvbmZpZy1uYW1lIi8+DQoJCQk8 eHM6ZWxlbWVudCByZWY9InVybCIvPg0KCQk8L3hzOmNob2ljZT4NCgk8L3hzOmNvbXBsZXhUeXBl Pg0KCTx4czplbGVtZW50IG5hbWU9ImdldC1zb3VyY2UiIHR5cGU9InJwY09wZXJhdGlvbkdldFNv dXJjZVR5cGUiLz4NCgk8eHM6ZWxlbWVudCBuYW1lPSJzb3VyY2UiIHR5cGU9InJwY09wZXJhdGlv blNvdXJjZVR5cGUiLz4NCgk8eHM6Y29tcGxleFR5cGUgbmFtZT0icnBjT3BlcmF0aW9uVGFyZ2V0 VHlwZSI+DQoJCTx4czpjaG9pY2U+DQoJCQk8eHM6ZWxlbWVudCByZWY9ImNvbmZpZy1uYW1lIi8+ DQoJCQk8eHM6ZWxlbWVudCByZWY9InVybCIvPg0KCQk8L3hzOmNob2ljZT4NCgk8L3hzOmNvbXBs ZXhUeXBlPg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJycGNPcGVyYXRpb25Mb2NrVGFyZ2V0VHlw ZSI+DQoJCTx4czpjaG9pY2U+DQoJCQk8eHM6ZWxlbWVudCByZWY9ImNvbmZpZy1uYW1lIi8+DQoJ CTwveHM6Y2hvaWNlPg0KCTwveHM6Y29tcGxleFR5cGU+DQoJPHhzOmVsZW1lbnQgbmFtZT0ibG9j ay10YXJnZXQiIHR5cGU9InJwY09wZXJhdGlvbkxvY2tUYXJnZXRUeXBlIi8+DQoJPHhzOmVsZW1l bnQgbmFtZT0idGFyZ2V0IiB0eXBlPSJycGNPcGVyYXRpb25UYXJnZXRUeXBlIi8+DQoJPHhzOmNv bXBsZXhUeXBlIG5hbWU9ImdldC1jb25maWdUeXBlIj4NCgkJPHhzOmNvbXBsZXhDb250ZW50Pg0K CQkJPHhzOmV4dGVuc2lvbiBiYXNlPSJycGNPcGVyYXRpb25UeXBlIj4NCgkJCQk8eHM6c2VxdWVu Y2U+DQoJCQkJCTx4czplbGVtZW50IHJlZj0iZ2V0LXNvdXJjZSIvPg0KCQkJCQk8eHM6ZWxlbWVu dCByZWY9ImZpbHRlciIgbWluT2NjdXJzPSIwIi8+DQoJCQkJPC94czpzZXF1ZW5jZT4NCgkJCTwv eHM6ZXh0ZW5zaW9uPg0KCQk8L3hzOmNvbXBsZXhDb250ZW50Pg0KCTwveHM6Y29tcGxleFR5cGU+ DQoJPHhzOmVsZW1lbnQgbmFtZT0iZ2V0LWNvbmZpZyIgdHlwZT0iZ2V0LWNvbmZpZ1R5cGUiIHN1 YnN0aXR1dGlvbkdyb3VwPSJycGNPcGVyYXRpb24iLz4NCgk8eHM6Y29tcGxleFR5cGUgbmFtZT0i ZWRpdC1jb25maWdUeXBlIj4NCgkJPHhzOmNvbXBsZXhDb250ZW50Pg0KCQkJPHhzOmV4dGVuc2lv biBiYXNlPSJycGNPcGVyYXRpb25UeXBlIj4NCgkJCQk8eHM6c2VxdWVuY2U+DQoJCQkJCTx4czpl bGVtZW50IHJlZj0idGFyZ2V0Ii8+DQoJCQkJCTx4czplbGVtZW50IHJlZj0idGVzdC1vcHRpb24i IG1pbk9jY3Vycz0iMCIvPg0KCQkJCQk8eHM6ZWxlbWVudCByZWY9ImVycm9yLW9wdGlvbiIgbWlu T2NjdXJzPSIwIi8+DQoJCQkJCTx4czplbGVtZW50IHJlZj0iY29uZmlnIi8+DQoJCQkJPC94czpz ZXF1ZW5jZT4NCgkJCTwveHM6ZXh0ZW5zaW9uPg0KCQk8L3hzOmNvbXBsZXhDb250ZW50Pg0KCTwv eHM6Y29tcGxleFR5cGU+DQoJPHhzOmVsZW1lbnQgbmFtZT0iZWRpdC1jb25maWciIHR5cGU9ImVk aXQtY29uZmlnVHlwZSIgc3Vic3RpdHV0aW9uR3JvdXA9InJwY09wZXJhdGlvbiIvPg0KCTx4czpj b21wbGV4VHlwZSBuYW1lPSJjb3B5LWNvbmZpZ1R5cGUiPg0KCQk8eHM6Y29tcGxleENvbnRlbnQ+ DQoJCQk8eHM6ZXh0ZW5zaW9uIGJhc2U9InJwY09wZXJhdGlvblR5cGUiPg0KCQkJCTx4czpzZXF1 ZW5jZT4NCgkJCQkJPHhzOmVsZW1lbnQgcmVmPSJzb3VyY2UiLz4NCgkJCQkJPHhzOmVsZW1lbnQg cmVmPSJ0YXJnZXQiLz4NCgkJCQk8L3hzOnNlcXVlbmNlPg0KCQkJPC94czpleHRlbnNpb24+DQoJ CTwveHM6Y29tcGxleENvbnRlbnQ+DQoJPC94czpjb21wbGV4VHlwZT4NCgk8eHM6ZWxlbWVudCBu YW1lPSJjb3B5LWNvbmZpZyIgdHlwZT0iY29weS1jb25maWdUeXBlIiBzdWJzdGl0dXRpb25Hcm91 cD0icnBjT3BlcmF0aW9uIi8+DQoJPHhzOmNvbXBsZXhUeXBlIG5hbWU9ImRlbGV0ZS1jb25maWdU eXBlIj4NCgkJPHhzOmNvbXBsZXhDb250ZW50Pg0KCQkJPHhzOmV4dGVuc2lvbiBiYXNlPSJycGNP cGVyYXRpb25UeXBlIj4NCgkJCQk8eHM6c2VxdWVuY2U+DQoJCQkJCTx4czplbGVtZW50IHJlZj0i dGFyZ2V0Ii8+DQoJCQkJPC94czpzZXF1ZW5jZT4NCgkJCTwveHM6ZXh0ZW5zaW9uPg0KCQk8L3hz OmNvbXBsZXhDb250ZW50Pg0KCTwveHM6Y29tcGxleFR5cGU+DQoJPHhzOmVsZW1lbnQgbmFtZT0i ZGVsZXRlLWNvbmZpZyIgdHlwZT0iZGVsZXRlLWNvbmZpZ1R5cGUiIHN1YnN0aXR1dGlvbkdyb3Vw PSJycGNPcGVyYXRpb24iLz4NCgk8eHM6Y29tcGxleFR5cGUgbmFtZT0iZ2V0VHlwZSI+DQoJCTx4 czpjb21wbGV4Q29udGVudD4NCgkJCTx4czpleHRlbnNpb24gYmFzZT0icnBjT3BlcmF0aW9uVHlw ZSI+DQoJCQkJPHhzOnNlcXVlbmNlPg0KCQkJCQk8eHM6ZWxlbWVudCByZWY9ImZpbHRlciIgbWlu T2NjdXJzPSIwIi8+DQoJCQkJPC94czpzZXF1ZW5jZT4NCgkJCTwveHM6ZXh0ZW5zaW9uPg0KCQk8 L3hzOmNvbXBsZXhDb250ZW50Pg0KCTwveHM6Y29tcGxleFR5cGU+DQoJPHhzOmVsZW1lbnQgbmFt ZT0iZ2V0IiB0eXBlPSJnZXRUeXBlIiBzdWJzdGl0dXRpb25Hcm91cD0icnBjT3BlcmF0aW9uIi8+ DQoJPHhzOmNvbXBsZXhUeXBlIG5hbWU9ImxvY2tUeXBlIj4NCgkJPHhzOmNvbXBsZXhDb250ZW50 Pg0KCQkJPHhzOmV4dGVuc2lvbiBiYXNlPSJycGNPcGVyYXRpb25UeXBlIj4NCgkJCQk8eHM6c2Vx dWVuY2U+DQoJCQkJCTx4czplbGVtZW50IHJlZj0ibG9jay10YXJnZXQiLz4NCgkJCQk8L3hzOnNl cXVlbmNlPg0KCQkJPC94czpleHRlbnNpb24+DQoJCTwveHM6Y29tcGxleENvbnRlbnQ+DQoJPC94 czpjb21wbGV4VHlwZT4NCgk8eHM6ZWxlbWVudCBuYW1lPSJsb2NrIiB0eXBlPSJsb2NrVHlwZSIg c3Vic3RpdHV0aW9uR3JvdXA9InJwY09wZXJhdGlvbiIvPg0KCTx4czpjb21wbGV4VHlwZSBuYW1l PSJ1bmxvY2tUeXBlIj4NCgkJPHhzOmNvbXBsZXhDb250ZW50Pg0KCQkJPHhzOmV4dGVuc2lvbiBi YXNlPSJycGNPcGVyYXRpb25UeXBlIj4NCgkJCQk8eHM6c2VxdWVuY2U+DQoJCQkJCTx4czplbGVt ZW50IHJlZj0ibG9jay10YXJnZXQiLz4NCgkJCQk8L3hzOnNlcXVlbmNlPg0KCQkJPC94czpleHRl bnNpb24+DQoJCTwveHM6Y29tcGxleENvbnRlbnQ+DQoJPC94czpjb21wbGV4VHlwZT4NCgk8eHM6 ZWxlbWVudCBuYW1lPSJ1bmxvY2siIHR5cGU9InVubG9ja1R5cGUiIHN1YnN0aXR1dGlvbkdyb3Vw PSJycGNPcGVyYXRpb24iLz4NCgk8eHM6Y29tcGxleFR5cGUgbmFtZT0idmFsaWRhdGVUeXBlIj4N CgkJPHhzOmNvbXBsZXhDb250ZW50Pg0KCQkJPHhzOmV4dGVuc2lvbiBiYXNlPSJycGNPcGVyYXRp b25UeXBlIj4NCgkJCQk8eHM6c2VxdWVuY2U+DQoJCQkJCTx4czplbGVtZW50IHJlZj0ic291cmNl Ii8+DQoJCQkJPC94czpzZXF1ZW5jZT4NCgkJCTwveHM6ZXh0ZW5zaW9uPg0KCQk8L3hzOmNvbXBs ZXhDb250ZW50Pg0KCTwveHM6Y29tcGxleFR5cGU+DQoJPHhzOmVsZW1lbnQgbmFtZT0idmFsaWRh dGUiIHR5cGU9InZhbGlkYXRlVHlwZSIgc3Vic3RpdHV0aW9uR3JvdXA9InJwY09wZXJhdGlvbiIv Pg0KCTx4czpjb21wbGV4VHlwZSBuYW1lPSJjb21taXRUeXBlIj4NCgkJPHhzOmNvbXBsZXhDb250 ZW50Pg0KCQkJPHhzOmV4dGVuc2lvbiBiYXNlPSJycGNPcGVyYXRpb25UeXBlIj4NCgkJCQk8eHM6 c2VxdWVuY2U+DQoJCQkJCTx4czplbGVtZW50IG5hbWU9ImNvbmZpcm1lZCIgbWluT2NjdXJzPSIw Ii8+DQoJCQkJCTx4czplbGVtZW50IG5hbWU9ImNvbmZpcm1lZC10aW1lb3V0IiBtaW5PY2N1cnM9 IjAiLz4NCgkJCQk8L3hzOnNlcXVlbmNlPg0KCQkJPC94czpleHRlbnNpb24+DQoJCTwveHM6Y29t cGxleENvbnRlbnQ+DQoJPC94czpjb21wbGV4VHlwZT4NCgk8eHM6ZWxlbWVudCBuYW1lPSJjb21t aXQiIHR5cGU9ImNvbW1pdFR5cGUiIHN1YnN0aXR1dGlvbkdyb3VwPSJycGNPcGVyYXRpb24iLz4N Cgk8eHM6Y29tcGxleFR5cGUgbmFtZT0iZGlzY2FyZC1jaGFuZ2VzVHlwZSI+DQoJCTx4czpjb21w bGV4Q29udGVudD4NCgkJCTx4czpleHRlbnNpb24gYmFzZT0icnBjT3BlcmF0aW9uVHlwZSIvPg0K CQk8L3hzOmNvbXBsZXhDb250ZW50Pg0KCTwveHM6Y29tcGxleFR5cGU+DQoJPHhzOmVsZW1lbnQg bmFtZT0iZGlzY2FyZC1jaGFuZ2VzIiB0eXBlPSJkaXNjYXJkLWNoYW5nZXNUeXBlIiBzdWJzdGl0 dXRpb25Hcm91cD0icnBjT3BlcmF0aW9uIi8+DQoJPHhzOmNvbXBsZXhUeXBlIG5hbWU9ImNsb3Nl LXNlc3Npb25UeXBlIj4NCgkJPHhzOmNvbXBsZXhDb250ZW50Pg0KCQkJPHhzOmV4dGVuc2lvbiBi YXNlPSJycGNPcGVyYXRpb25UeXBlIi8+DQoJCTwveHM6Y29tcGxleENvbnRlbnQ+DQoJPC94czpj b21wbGV4VHlwZT4NCgk8eHM6ZWxlbWVudCBuYW1lPSJjbG9zZS1zZXNzaW9uIiB0eXBlPSJjbG9z ZS1zZXNzaW9uVHlwZSIgc3Vic3RpdHV0aW9uR3JvdXA9InJwY09wZXJhdGlvbiIvPg0KCTx4czpj b21wbGV4VHlwZSBuYW1lPSJraWxsLXNlc3Npb25UeXBlIj4NCgkJPHhzOmNvbXBsZXhDb250ZW50 Pg0KCQkJPHhzOmV4dGVuc2lvbiBiYXNlPSJycGNPcGVyYXRpb25UeXBlIj4NCgkJCQk8eHM6c2Vx dWVuY2U+DQoJCQkJCTx4czplbGVtZW50IG5hbWU9InNlc3Npb24taWQiIHR5cGU9IlNlc3Npb25J ZCIvPg0KCQkJCTwveHM6c2VxdWVuY2U+DQoJCQk8L3hzOmV4dGVuc2lvbj4NCgkJPC94czpjb21w bGV4Q29udGVudD4NCgk8L3hzOmNvbXBsZXhUeXBlPg0KCTx4czplbGVtZW50IG5hbWU9ImtpbGwt c2Vzc2lvbiIgdHlwZT0ia2lsbC1zZXNzaW9uVHlwZSIgc3Vic3RpdHV0aW9uR3JvdXA9InJwY09w ZXJhdGlvbiIvPg0KPC94czpzY2hlbWE+DQoNCg== ------_=_NextPart_001_01C479EA.2D2946C6-- -- 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 Aug 8 15:33:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08864 for ; Sun, 8 Aug 2004 15:33:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BttFn-000445-KS for netconf-data@psg.com; Sun, 08 Aug 2004 19:22:47 +0000 Received: from [192.11.222.161] (helo=ihemail1.lucent.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BttFd-00041u-1Q for netconf@ops.ietf.org; Sun, 08 Aug 2004 19:22:37 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i78JMW5L027332 for ; Sun, 8 Aug 2004 14:22:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 8 Aug 2004 21:22:32 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504F29E6A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: draft-ietf-netconf-soap-02.txt Date: Sun, 8 Aug 2004 21:22:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk While reading this for prep of IETF, I found these nits: - title expand acronyms - s/IPSec/IPsec/ - are all normative refs indeed normative? I doubt it. For example Radius ?? - missing IANA considerations So hopefully they can be addressed when you do next rev Thanks, Bert -- 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 Aug 8 15:33:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08878 for ; Sun, 8 Aug 2004 15:33:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BttG4-00045n-B6 for netconf-data@psg.com; Sun, 08 Aug 2004 19:23:04 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BttFd-000426-Om for netconf@ops.ietf.org; Sun, 08 Aug 2004 19:22:37 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i78JMZCb019532 for ; Sun, 8 Aug 2004 14:22:36 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 8 Aug 2004 21:22:35 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504F29E6B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Netconf (E-mail)" Subject: FW: draft-ietf-netconf-prot-03.txt Date: Sun, 8 Aug 2004 21:22:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-netconf@ops.ietf.org Precedence: bulk While reading this do in preparation for IETF60, I found these nits: - expand Acronyms in title. - use rfc3330 IP addresses need to be used in examples - new boilerplate Pls address in next revision Thanks, Bert -- 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 Aug 16 17:03:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09728 for ; Mon, 16 Aug 2004 17:03:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwoRB-000A75-03 for netconf-data@psg.com; Mon, 16 Aug 2004 20:50:37 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwoR0-000A5H-51 for netconf@ops.ietf.org; Mon, 16 Aug 2004 20:50:26 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7GKoHMV000637; Mon, 16 Aug 2004 13:50:17 -0700 (PDT) Received: from [171.71.119.171] (dhcp-171-71-119-171.cisco.com [171.71.119.171]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA17613; Mon, 16 Aug 2004 13:50:16 -0700 (PDT) Message-ID: <41211E0A.6040104@cisco.com> Date: Mon, 16 Aug 2004 13:50:18 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Bierman CC: netconf@ops.ietf.org Subject: Re: Comments on Application Mapping I-Ds References: <4.3.2.7.2.20040730080346.0275a778@fedex.cisco.com> In-Reply-To: <4.3.2.7.2.20040730080346.0275a778@fedex.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andy: General comments below, I think we agreed at the meeting that since Margaret was not in the room (always a good method to decide things) and since it probably didn't matter too much, we'd go with her organization. And so this means the following for BEEP: > 1) General Comments > > - Titles should be consistent; every one is a different style. > We need to decide which style is best: > - BEEP Application Protocol Mapping for NETCONF > - NETCONF Over SOAP > - Using the NETCONF Configuration Protocol over Secure Shell (SSH) Title - Using the NETCONF Configuration Protocol over BEEP I don't personally like the "using" part, but I don't care all that much. > > - The following normative sections should exist in > all documents, and be consistent in content: > - NETCONF Session Establishment > - NETCONF Capabilities Exchange > - NETCONF Session Usage > - NETCONF Session Teardown This is fine. Expect a draft on short order. -- 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 Aug 16 22:47:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02135 for ; Mon, 16 Aug 2004 22:47:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwtoY-000OVw-Mg for netconf-data@psg.com; Tue, 17 Aug 2004 02:35:06 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwtoF-000OSP-GH for netconf@ops.ietf.org; Tue, 17 Aug 2004 02:34:47 +0000 Received: from [207.31.248.169] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 127862; Mon, 16 Aug 2004 22:31:13 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <41211E0A.6040104@cisco.com> References: <4.3.2.7.2.20040730080346.0275a778@fedex.cisco.com> <41211E0A.6040104@cisco.com> Date: Mon, 16 Aug 2004 22:34:32 -0400 To: Eliot Lear From: Margaret Wasserman Subject: Re: Comments on Application Mapping I-Ds Cc: netconf@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk >General comments below, I think we agreed at the meeting that since >Margaret was not in the room (always a good method to decide things) >and since it probably didn't matter too much, we'd go with her >organization. I guess I'll have to miss more meetings, as I am apparently more persuasive when I'm not present... :-) >And so this means the following for BEEP: > >> 1) General Comments >> - Titles should be consistent; every one is a different style. >> We need to decide which style is best: >> - BEEP Application Protocol Mapping for NETCONF >> - NETCONF Over SOAP >> - Using the NETCONF Configuration Protocol over Secure Shell (SSH) > > >Title - Using the NETCONF Configuration Protocol over BEEP Unfortunately, we have to expand the acronyms, so I think we end up with: Using NETCONF over the Blocks Extensible Exchange Protocol (BEEP) Do you think we have to expand NETCONF? Or that we can get away with claiming that NETCONF _is_ the fully-expanded name of the protocol? Margaret -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Aug 16 23:48:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04572 for ; Mon, 16 Aug 2004 23:48:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwusB-00072Q-Pc for netconf-data@psg.com; Tue, 17 Aug 2004 03:42:55 +0000 Received: from [207.217.120.22] (helo=hawk.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bwus1-00070q-8G for netconf@ops.ietf.org; Tue, 17 Aug 2004 03:42:45 +0000 Received: from h-69-3-26-3.snvacaid.dynamic.covad.net ([69.3.26.3] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bwus0-000243-00 for netconf@ops.ietf.org; Mon, 16 Aug 2004 20:42:44 -0700 Message-ID: <002901c4840c$ae05b4a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <4.3.2.7.2.20040730080346.0275a778@fedex.cisco.com> <41211E0A.6040104@cisco.com> Subject: Re: Comments on Application Mapping I-Ds Date: Mon, 16 Aug 2004 20:45:46 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Margaret Wasserman" > To: "Eliot Lear" > Cc: > Sent: Monday, August 16, 2004 7:34 PM > Subject: Re: Comments on Application Mapping I-Ds ... > Do you think we have to expand NETCONF? Or that we can get away with > claiming that NETCONF _is_ the fully-expanded name of the protocol? ... I think it would be better to expand it. 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 Tue Aug 17 00:13:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05860 for ; Tue, 17 Aug 2004 00:13:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BwvBz-000APD-U7 for netconf-data@psg.com; Tue, 17 Aug 2004 04:03:23 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BwvBp-000ANx-C7 for netconf@ops.ietf.org; Tue, 17 Aug 2004 04:03:13 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Aug 2004 21:08:11 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7H438CA008566; Mon, 16 Aug 2004 21:03:08 -0700 (PDT) Received: from abierman-w2k01.cisco.com (sjc-vpn3-263.cisco.com [10.21.65.7]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AYC20207; Mon, 16 Aug 2004 21:03:10 -0700 (PDT) Message-Id: <4.3.2.7.2.20040816210326.01d47f00@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 16 Aug 2004 21:04:46 -0700 To: "Randy Presuhn" From: Andy Bierman Subject: Re: Comments on Application Mapping I-Ds Cc: In-Reply-To: <002901c4840c$ae05b4a0$7f1afea9@oemcomputer> References: <4.3.2.7.2.20040730080346.0275a778@fedex.cisco.com> <41211E0A.6040104@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk At 08:45 PM 8/16/2004, Randy Presuhn wrote: >Hi - > >> From: "Margaret Wasserman" >> To: "Eliot Lear" >> Cc: >> Sent: Monday, August 16, 2004 7:34 PM >> Subject: Re: Comments on Application Mapping I-Ds >... >> Do you think we have to expand NETCONF? Or that we can get away with >> claiming that NETCONF _is_ the fully-expanded name of the protocol? >... > >I think it would be better to expand it. Agreed. The full title should be: Network Configuration Protocol (NETCONF) >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 Aug 17 11:27:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23190 for ; Tue, 17 Aug 2004 11:27:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bx5Zq-000IPZ-Ds for netconf-data@psg.com; Tue, 17 Aug 2004 15:08:42 +0000 Received: from [64.40.109.159] (helo=mail.icesoft.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bx5Zf-000IOR-Qg for netconf@ops.ietf.org; Tue, 17 Aug 2004 15:08:31 +0000 Received: from [10.18.39.60] ([142.179.182.176]) by mail.icesoft.com (Kerio MailServer 5.7.6) for netconf@ops.ietf.org; Tue, 17 Aug 2004 08:08:23 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <4.3.2.7.2.20040816210326.01d47f00@fedex.cisco.com> References: <4.3.2.7.2.20040730080346.0275a778@fedex.cisco.com> <41211E0A.6040104@cisco.com> <4.3.2.7.2.20040816210326.01d47f00@fedex.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4C0E550E-F05F-11D8-898B-003065C0229A@icesoft.com> Content-Transfer-Encoding: 7bit From: Ted Goddard Subject: Re: Comments on Application Mapping I-Ds Date: Tue, 17 Aug 2004 09:08:29 -0600 To: netconf@ops.ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Note that "SOAP" is no longer an acronym, it's now just "SOAP". However, as of SOAP 1.1, it was "Simple Object Access Protocol". Does that warrant expansion? Ted. On 16-Aug-04, at 10:04 PM, Andy Bierman wrote: > At 08:45 PM 8/16/2004, Randy Presuhn wrote: >> Hi - >> >>> From: "Margaret Wasserman" >>> To: "Eliot Lear" >>> Cc: >>> Sent: Monday, August 16, 2004 7:34 PM >>> Subject: Re: Comments on Application Mapping I-Ds >> ... >>> Do you think we have to expand NETCONF? Or that we can get away with >>> claiming that NETCONF _is_ the fully-expanded name of the protocol? >> ... >> >> I think it would be better to expand it. > > Agreed. The full title should be: > > Network Configuration Protocol (NETCONF) > > >> 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: -- 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 Aug 17 17:13:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14950 for ; Tue, 17 Aug 2004 17:13:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxB1f-000Bm8-Fp for netconf-data@psg.com; Tue, 17 Aug 2004 20:57:47 +0000 Received: from [207.217.120.48] (helo=mallard.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxB1V-000Bkm-0A for netconf@ops.ietf.org; Tue, 17 Aug 2004 20:57:37 +0000 Received: from h-66-167-206-164.snvacaid.dynamic.covad.net ([66.167.206.164] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BxB1U-00064S-00 for netconf@ops.ietf.org; Tue, 17 Aug 2004 13:57:36 -0700 Message-ID: <002601c4849d$40a05dc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <4.3.2.7.2.20040730080346.0275a778@fedex.cisco.com> <41211E0A.6040104@cisco.com> <4.3.2.7.2.20040816210326.01d47f00@fedex.cisco.com> <4C0E550E-F05F-11D8-898B-003065C0229A@icesoft.com> Subject: Re: Comments on Application Mapping I-Ds Date: Tue, 17 Aug 2004 14:00:39 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Ted Goddard" > To: > Sent: Tuesday, August 17, 2004 8:08 AM > Subject: Re: Comments on Application Mapping I-Ds > > > Note that "SOAP" is no longer an acronym, it's now just "SOAP". > However, as of SOAP 1.1, it was "Simple Object Access Protocol". > > Does that warrant expansion? ... I think expansion is warranted. An explanation of the politics of the name, along with any additional etymological details could go in a parenthetical comment in the document's introduction. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 18 14:12:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26628 for ; Wed, 18 Aug 2004 14:11:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxUfd-0007PP-6c for netconf-data@psg.com; Wed, 18 Aug 2004 17:56:21 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxUfS-0007OD-EC for netconf@ops.ietf.org; Wed, 18 Aug 2004 17:56:10 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2004 10:59:53 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7IHu5Tt018816 for ; Wed, 18 Aug 2004 10:56:05 -0700 (PDT) Received: from [171.71.95.36] (dhcp-171-71-95-36.cisco.com [171.71.95.36]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA26515 for ; Wed, 18 Aug 2004 10:56:08 -0700 (PDT) Message-ID: <41238823.4090904@cisco.com> Date: Wed, 18 Aug 2004 09:47:31 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netconf Subject: little problem with Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The manager is meant to issue a element to initiate a close. For BEEP this is a bad idea, and it's probably a bad idea for everyone else as well. The problem is that either side should be able to initiate a close. This is particularly necessary for orderly shutdown of the device running the agent. This argues *strongly* for the removal of and returning this function to the application mappings. If we need to add some meta-thing into SSH, so be it, but the agent needs to initiate the close - somehow. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Aug 18 19:03:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28786 for ; Wed, 18 Aug 2004 19:03:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxZDI-0003xC-L1 for netconf-data@psg.com; Wed, 18 Aug 2004 22:47:24 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxZD7-0003wR-KB for netconf@ops.ietf.org; Wed, 18 Aug 2004 22:47:13 +0000 Received: from [207.31.248.169] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 129021; Wed, 18 Aug 2004 18:43:40 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <41238823.4090904@cisco.com> References: <41238823.4090904@cisco.com> Date: Wed, 18 Aug 2004 18:42:21 -0400 To: Eliot Lear , netconf From: Margaret Wasserman Subject: Re: little problem with Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Eliot, Maybe you are right, but I have some thoughts... At 9:47 AM -0700 8/18/04, Eliot Lear wrote: >The manager is meant to issue a element to initiate >a close. For BEEP this is a bad idea, and it's probably a bad idea >for everyone else as well. The problem is that either side should >be able to initiate a close. This is particularly necessary for >orderly shutdown of the device running the agent. is really a way that the manager can ask the agent to close the session. Its existence does not, necessarily, stop the agent from closing the session at other times, I suppose. There are two reasons why I think that this is cleaner than having the manager simply shut down the connection when it is finished: (1) The command will be processed in-band, like any other command and the agent can close the session when it is finish processing all commands, freeing all locks, etc. This avoids any ambiguous cases where (for instance) the manager finishes and closes down before the agent has finished processing all of the commands. After receiving an error when trying to respond to one command, should the agent continue to read from the connection and process subsequent commands from the manager? (2) For TCP-based session-layer protocols, it is (IMO) highly desirable for the manager to be the one that initiates the TCP-level close, so that the TIME-WAIT state ends-up on the agent side. A manager may manage a very large number of devices and need to connect to all of those devices in rapid succession, while it seems less likely that an individual device will be reconfigured as often. >This argues *strongly* for the removal of and >returning this function to the application mappings. If we need to >add some meta-thing into SSH, so be it, but the agent needs to >initiate the close - somehow. If we put this in the application mapping, how would you suggest that would work? Margaret -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 19 14:47:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23200 for ; Thu, 19 Aug 2004 14:47:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bxrml-0000e5-Vf for netconf-data@psg.com; Thu, 19 Aug 2004 18:37:15 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bxrmb-0000ct-At for netconf@ops.ietf.org; Thu, 19 Aug 2004 18:37:05 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2004 11:41:00 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7JIb0IU015864; Thu, 19 Aug 2004 11:37:01 -0700 (PDT) Received: from [171.71.117.113] (dhcp-171-71-117-113.cisco.com [171.71.117.113]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA20479; Thu, 19 Aug 2004 11:37:02 -0700 (PDT) Message-ID: <4124F34E.50605@cisco.com> Date: Thu, 19 Aug 2004 11:37:02 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: netconf Subject: Re: little problem with References: <41238823.4090904@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Margaret, > is really a way that the manager can ask the agent to > close the session. Its existence does not, necessarily, stop the agent > from closing the session at other times, I suppose. But we haven't defined how to do that. I can easily define how to do that in the BEEP mapping, but since we don't have the agent sending commands, I don't really know how to do it at the NETCONF protocol level. > There are two > reasons why I think that this is cleaner than having the manager simply > shut down the connection > when it is finished: > > (1) The command will be processed in-band, like any > other command and the agent can close the session when it is finish > processing all commands, freeing all locks, etc. All I am saying is that how this happens needs to be specified in the application mapping document and NOT the base protocol. See my current draft. I provide guidance specifically on how locking is handled. For instance, you don't want the agent initiating a close while it is locked. > This avoids any > ambiguous cases where (for instance) the manager finishes and closes > down before the agent has finished processing all of the commands. After > receiving an error when trying to respond to one command, should the > agent continue to read from the connection and process subsequent > commands from the manager? Since commands are synchronous, I don't see the problem. > > (2) For TCP-based session-layer protocols, it is (IMO) highly desirable > for the manager to be the one that initiates the TCP-level close, so > that the TIME-WAIT state ends-up on the agent side. A manager may > manage a very large number of devices and need to connect to all of > those devices in rapid succession, while it seems less likely that an > individual device will be reconfigured as often. Think about a meta-command, then. I can already do this in the BEEP mapping, and can control which side disconnects first. But putting that aside, in the case of an attack (which is what I think you're concerned about), the device is going to close unauthenticated connections as a defensive mechanism, no matter what the protocol says. > >> This argues *strongly* for the removal of and >> returning this function to the application mappings. If we need to >> add some meta-thing into SSH, so be it, but the agent needs to >> initiate the close - somehow. > > > If we put this in the application mapping, how would you suggest that > would work? For BEEP it's easy, there are protocol semantics to close a connection. You tell me for SSH. What are the protocol semantics to close a connection? Same deal with HTTP. If you need to signal to the manager to close the connection, perhaps a meta-command within the mapping. Nothing prevents such a thing, and the code to do so would be small. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Aug 19 16:20:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04346 for ; Thu, 19 Aug 2004 16:20:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BxtIs-000Ef0-Mg for netconf-data@psg.com; Thu, 19 Aug 2004 20:14:30 +0000 Received: from [207.217.120.18] (helo=goose.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BxtIi-000EeL-0N for netconf@ops.ietf.org; Thu, 19 Aug 2004 20:14:20 +0000 Received: from h-66-167-205-163.snvacaid.dynamic.covad.net ([66.167.205.163] helo=oemcomputer) by goose.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BxtIg-0005Np-00 for netconf@ops.ietf.org; Thu, 19 Aug 2004 13:14:19 -0700 Message-ID: <000401c48629$8bf225a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "netconf" References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> Subject: Re: little problem with Date: Thu, 19 Aug 2004 13:17:26 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Eliot Lear" > To: "Margaret Wasserman" > Cc: "netconf" > Sent: Thursday, August 19, 2004 11:37 AM > Subject: Re: little problem with ... > All I am saying is that how this happens needs to be specified in the > application mapping document and NOT the base protocol. See my current > draft. I provide guidance specifically on how locking is handled. For > instance, you don't want the agent initiating a close while it is locked. You may not want it, but it may be unavoidable. Consider cases like power failure or removal of the card where the nonvolatile store lives. The question is whether there's any value to having the protocol reflect these nasty cases, when there's always going to be the possibility that the "last gasp" might not make it to the wire. > > This avoids any > > ambiguous cases where (for instance) the manager finishes and closes > > down before the agent has finished processing all of the commands. After > > receiving an error when trying to respond to one command, should the > > agent continue to read from the connection and process subsequent > > commands from the manager? > > Since commands are synchronous, I don't see the problem. The concern is independent of whether command processing is synchronous. The protocol (section 3.6) does not require the manager to wait for a response before sending the next command. The question is about what the agent should do with buffered commands if an attempt to send a response fails because the other side (in "fire and forget" mode) has closed the connection. Regardless of whether the protocol has a "close" PDU, the behaviour needs to be defined. (I.e., are commands processed after the manager initiates a transport layer close?) > > (2) For TCP-based session-layer protocols, it is (IMO) highly desirable > > for the manager to be the one that initiates the TCP-level close, so > > that the TIME-WAIT state ends-up on the agent side. A manager may > > manage a very large number of devices and need to connect to all of > > those devices in rapid succession, while it seems less likely that an > > individual device will be reconfigured as often. > > Think about a meta-command, then. I can already do this in the BEEP > mapping, and can control which side disconnects first. But putting that > aside, in the case of an attack (which is what I think you're concerned > about), the device is going to close unauthenticated connections as a > defensive mechanism, no matter what the protocol says. I think the concern is not about a possible attack, but rather about resource consumption on the manager when it needs to talk to a large number of devices consecutively. 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 Fri Aug 20 09:17:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11594 for ; Fri, 20 Aug 2004 09:17:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By97h-000Bae-LD for netconf-data@psg.com; Fri, 20 Aug 2004 13:08:01 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By97W-000BZ5-89 for netconf@ops.ietf.org; Fri, 20 Aug 2004 13:07:50 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2A6E27B4F for ; Fri, 20 Aug 2004 15:07:49 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 10358-01; Fri, 20 Aug 2004 15:07:48 +0200 (CEST) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.81]) by hermes.iu-bremen.de (Postfix) with ESMTP id D1BA47B30; Fri, 20 Aug 2004 15:07:47 +0200 (CEST) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id BBC9C82A8; Fri, 20 Aug 2004 15:07:47 +0200 (CEST) Date: Fri, 20 Aug 2004 15:07:47 +0200 From: Juergen Schoenwaelder To: netconf@ops.ietf.org Subject: what happend at the 60th ietf? Message-ID: <20040820130747.GB2951@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: netconf@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk I am wondering whether someone can summarize what happened at the last IETF meeting. Any progress on the open issues that we have? Is netconf still doing fine and coming closer to completion? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Aug 20 09:21:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11861 for ; Fri, 20 Aug 2004 09:21:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1By9DD-000CL8-Fu for netconf-data@psg.com; Fri, 20 Aug 2004 13:13:43 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1By9D2-000CKJ-MN for netconf@ops.ietf.org; Fri, 20 Aug 2004 13:13:32 +0000 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i7KDDU622419 for ; Fri, 20 Aug 2004 09:13:30 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Aug 2004 09:13:30 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4012D5CAB@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: netconf@ops.ietf.org Subject: RE: what happend at the 60th ietf? Date: Fri, 20 Aug 2004 09:13:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk hi Eliot and I did a Jabber log. Check it out at http://www.xmpp.org/ietf-logs/netconf@ietf.xmpp.org/2004-08-05.html For the most part we were closing off on issues, but we had a lot of discussion on rollback with no agreed to path forward from my recollection. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Sent: Friday, August 20, 2004 9:08 AM To: netconf@ops.ietf.org Subject: what happend at the 60th ietf? I am wondering whether someone can summarize what happened at the last IETF meeting. Any progress on the open issues that we have? Is netconf still doing fine and coming closer to completion? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Aug 20 20:58:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27150 for ; Fri, 20 Aug 2004 20:58:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByK2J-000F0Q-L0 for netconf-data@psg.com; Sat, 21 Aug 2004 00:47:11 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByK28-000Eyr-O3 for netconf@ops.ietf.org; Sat, 21 Aug 2004 00:47:00 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 Aug 2004 13:30:04 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7KKPtH6006868; Fri, 20 Aug 2004 13:25:55 -0700 (PDT) Received: from [10.242.20.74] (sjc-vpn5-692.cisco.com [10.21.90.180]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA05275; Fri, 20 Aug 2004 13:25:54 -0700 (PDT) Message-ID: <41265E52.1050802@cisco.com> Date: Fri, 20 Aug 2004 16:25:54 -0400 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: netconf Subject: Re: little problem with References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> In-Reply-To: <000401c48629$8bf225a0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Hi - > > >>From: "Eliot Lear" >>To: "Margaret Wasserman" >>Cc: "netconf" >>Sent: Thursday, August 19, 2004 11:37 AM >>Subject: Re: little problem with > > ... > >>All I am saying is that how this happens needs to be specified in the >>application mapping document and NOT the base protocol. See my current >>draft. I provide guidance specifically on how locking is handled. For >>instance, you don't want the agent initiating a close while it is locked. > > > You may not want it, but it may be unavoidable. I agree, it may be unavoidable. But in an orderly shutdown it is avoidable, and we should provide guidance on that (hopefully) general case. >>>This avoids any >>>ambiguous cases where (for instance) the manager finishes and closes >>>down before the agent has finished processing all of the commands. After >>>receiving an error when trying to respond to one command, should the >>>agent continue to read from the connection and process subsequent >>>commands from the manager? >> >>Since commands are synchronous, I don't see the problem. > > > The concern is independent of whether command processing > is synchronous. The protocol (section 3.6) does not require > the manager to wait for a response before sending the next command. > The question is about what the agent should do with buffered commands > if an attempt to send a response fails because the other side > (in "fire and forget" mode) has closed the connection. Regardless of > whether the protocol has a "close" PDU, the behaviour needs to be > defined. (I.e., are commands processed after the manager initiates > a transport layer close?) My answer is NO. If you send a close and then send an additional command, you've gone nuts. But this is only half the problem- the other half is that the agent cannot initiate the close, and it should be able to. Consider the very basic case of a reconfiguration requiring a re-authentication. The only way to do that is to close the connection. We need an orderly way to do that. > > >>>(2) For TCP-based session-layer protocols, it is (IMO) highly desirable >>>for the manager to be the one that initiates the TCP-level close, so >>>that the TIME-WAIT state ends-up on the agent side. A manager may >>>manage a very large number of devices and need to connect to all of >>>those devices in rapid succession, while it seems less likely that an >>>individual device will be reconfigured as often. >> >>Think about a meta-command, then. I can already do this in the BEEP >>mapping, and can control which side disconnects first. But putting that >>aside, in the case of an attack (which is what I think you're concerned >>about), the device is going to close unauthenticated connections as a >>defensive mechanism, no matter what the protocol says. > > > I think the concern is not about a possible attack, but rather about > resource consumption on the manager when it needs to talk to a large > number of devices consecutively. Fair 'nuff. It's possible in the BEEP application mapping. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sat Aug 21 04:08:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00365 for ; Sat, 21 Aug 2004 04:08:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByQkL-000F9q-CB for netconf-data@psg.com; Sat, 21 Aug 2004 07:57:05 +0000 Received: from [207.217.120.69] (helo=aftermath.mail.pas.earthlink.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByQkA-000F7x-Pq for netconf@ops.ietf.org; Sat, 21 Aug 2004 07:56:54 +0000 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by aftermath.mail.pas.earthlink.net with esmtp (Exim 3.36 #1) id 1ByGyj-0005o5-00 for netconf@ops.ietf.org; Fri, 20 Aug 2004 14:31:17 -0700 Received: from h-69-3-26-74.snvacaid.dynamic.covad.net ([69.3.26.74] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1ByGyi-0006TI-00 for netconf@ops.ietf.org; Fri, 20 Aug 2004 14:31:16 -0700 Message-ID: <002c01c486fd$77bc6620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "netconf" References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> <41265E52.1050802@cisco.com> Subject: Re: little problem with Date: Fri, 20 Aug 2004 14:34:26 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi - > From: "Eliot Lear" > To: "Randy Presuhn" > Cc: "netconf" > Sent: Friday, August 20, 2004 1:25 PM > Subject: Re: little problem with ... > > The concern is independent of whether command processing > > is synchronous. The protocol (section 3.6) does not require > > the manager to wait for a response before sending the next command. > > The question is about what the agent should do with buffered commands > > if an attempt to send a response fails because the other side > > (in "fire and forget" mode) has closed the connection. Regardless of > > whether the protocol has a "close" PDU, the behaviour needs to be > > defined. (I.e., are commands processed after the manager initiates > > a transport layer close?) > > My answer is NO. If you send a close and then send an additional > command, you've gone nuts. That's not the case we were worried about. The scenario is where a manager sends one or more commands, and then closes the connection without waiting for the response(s). The agent will be able to read the (buffered) commands, but will get an error when it tries to send the responses on the closed connection. Regardless of whether we think this is a smart thing to do, we need to define what happens. > But this is only half the problem- the other > half is that the agent cannot initiate the close, and it should be able > to. Consider the very basic case of a reconfiguration requiring a > re-authentication. The only way to do that is to close the connection. > We need an orderly way to do that. ... I think we're in violent agreement on this point. 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 Sat Aug 21 06:31:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06230 for ; Sat, 21 Aug 2004 06:31:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByT4p-0007zL-3z for netconf-data@psg.com; Sat, 21 Aug 2004 10:26:23 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByT4e-0007yH-3p for netconf@ops.ietf.org; Sat, 21 Aug 2004 10:26:12 +0000 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 130226; Sat, 21 Aug 2004 06:22:34 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <4124F34E.50605@cisco.com> References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> Date: Sat, 21 Aug 2004 06:21:25 -0400 To: Eliot Lear From: Margaret Wasserman Subject: Re: little problem with Cc: netconf Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Hi Eliot, >> (2) For TCP-based session-layer protocols, it is (IMO) highly desirable >> for the manager to be the one that initiates the TCP-level close, so that s/manager/agent >>the TIME-WAIT state ends-up on the agent side. A manager may manage >>a very large number of devices and need to connect to all of those devices >>in rapid succession, while it seems less likely that an individual device >>will be reconfigured as often. > >Think about a meta-command, then. What is a "meta command"? >I can already do this in the BEEP mapping, and can control which side >disconnects first. But putting that aside, in the case of an attack (which >is what I think you're concerned about), the device is going to close >unauthenticated connections as a defensive mechanism, no matter what >the protocol says. I am not talking about an attack, I am talking about normal operation. As you may recall, one of the serious problems with HTTP 1.0 was that it opened many TCP connections and left the connections in TIME-WAIT state on the server (because the server would close the connection to indicate end-of-file). Because there was one server and many, many clients, the server would eventually run out of resources. In our protocol, there is likely to be one manager and many, many agents. Therefore, we need to be careful that any state (such as TIME-WAT state) that is left behind after a session completes remains on the agent, not on the manager. So, it is important that all TCP connection closes are initiated by the agent, so that the agent will end-up with the TIME-WAIT state. And, I consider to be a good way for the manager to ask the agent to initiate a close. Can you explain what problem causes? I don't understand what the existence of has to do with the fact that we don't have the ability for the agent to send commands to the manager. I understand that the agent might close the session in mid-session if the agent is shut down, but that will typically result in a reset and wouldn't be considered normal operation. It is also possible that an agent or manager will crash (go away without closing or resetting the session) or that the agent will become unreachable from the manager (and/or vice versa) due to network problems that are unrelated to either the manager or agent... Implementations will need to handle those conditions. Do you think we need to add text to the base spec explaining what happens in such abnormal close conditions? I'm not sure this is needed to write interoperable implementations, but perhaps it would address your issue of what happens when the agent needs to close the session? Margaret -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Aug 22 15:02:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11743 for ; Sun, 22 Aug 2004 15:02:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByxPs-000CEc-0Q for netconf-data@psg.com; Sun, 22 Aug 2004 18:50:08 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByxPh-000CCF-Ca for netconf@ops.ietf.org; Sun, 22 Aug 2004 18:49:57 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 22 Aug 2004 11:54:51 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7MInpCK009266; Sun, 22 Aug 2004 11:49:52 -0700 (PDT) Received: from [10.61.124.32] (ams-clip-equant-dhcp-31.cisco.com [10.61.124.32]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA04909; Sun, 22 Aug 2004 11:49:52 -0700 (PDT) Message-ID: <4128EAD0.2090403@cisco.com> Date: Sun, 22 Aug 2004 20:49:52 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: netconf Subject: Re: little problem with References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret, What I meant by a "meta-command" is something that is sent in the mapping but not otherewise part of the netconf protocol. in the BEEP mapping could simply be a CLOSE 0. My motivation is simple- the agent should be able to initiate an orderly close, just as the manager would. Now, if we don't add this into the protocol, the BEEP mapping will simply do the normal BEEP thing to close a BEEP session. It certainly will NOT send an RST unless the close was not orderly ;-) BTW, in my mind the manager is likely to keep connections up for long periods of time. I realize this is only one model of operation, though. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Sun Aug 22 15:06:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12117 for ; Sun, 22 Aug 2004 15:06:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1ByxaM-000DeC-5l for netconf-data@psg.com; Sun, 22 Aug 2004 19:00:58 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1ByxaB-000Dch-Ky for netconf@ops.ietf.org; Sun, 22 Aug 2004 19:00:47 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 22 Aug 2004 12:06:52 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7MI0jWB029531; Sun, 22 Aug 2004 11:00:45 -0700 (PDT) Received: from [10.61.124.32] (ams-clip-equant-dhcp-31.cisco.com [10.61.124.32]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA08357; Sun, 22 Aug 2004 12:00:42 -0700 (PDT) Message-ID: <4128ED5A.8010409@cisco.com> Date: Sun, 22 Aug 2004 21:00:42 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: netconf Subject: Re: little problem with References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> <41265E52.1050802@cisco.com> <002c01c486fd$77bc6620$7f1afea9@oemcomputer> In-Reply-To: <002c01c486fd$77bc6620$7f1afea9@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > That's not the case we were worried about. > The scenario is where a manager sends one > or more commands, and then closes the connection > without waiting for the response(s). The agent will > be able to read the (buffered) commands, but will > get an error when it tries to send the responses on > the closed connection. Regardless of whether we think > this is a smart thing to do, we need to define what happens. ahh... okay, I think we have been miscommunicating. I don't propose that the BEEP application mapping close the transport connection until all responses are received. As it receives those responses it can ACK them at the TCP level. N.B. in BEEP the initiator always initiates the transport close. This may be a problem, given Margaret's concerns, but doesn't address that part at all. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Aug 23 06:10:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26238 for ; Mon, 23 Aug 2004 06:10:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzBZL-000JoG-40 for netconf-data@psg.com; Mon, 23 Aug 2004 09:56:51 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzBZA-000JmS-63 for netconf@ops.ietf.org; Mon, 23 Aug 2004 09:56:40 +0000 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 130607; Mon, 23 Aug 2004 05:52:59 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <4128ED5A.8010409@cisco.com> References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> <41265E52.1050802@cisco.com> <002c01c486fd$77bc6620$7f1afea9@oemcomputer> <4128ED5A.8010409@cisco.com> Date: Mon, 23 Aug 2004 05:52:54 -0400 To: Eliot Lear From: Margaret Wasserman Subject: Re: little problem with Cc: netconf Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk >N.B. in BEEP the initiator always initiates the transport close. This may be >a problem, given Margaret's concerns, but doesn't address >that part at all. When the initiator initiates a BEEP-level close, does that mean that it will also initiate the TCP-level close (by sending the first )? If so, I think that this may cause a potentially serious problem with the scalability of NETCONF over BEEP for managing very large numbers or nodes and/or handling large numbers of separately-initiated transactions, as the side of the TCP connection that sends the first will also be the side that ends-up with connections in TIME-WAIT state for a couple of minutes after each session is closed. Perhaps, given the capabilities of workstations and/or some enhancements to the TCP protocol this is no longer a serious problem? I know that it was a serious problem when HTTP 1.0 was introduced -- in that case the TIME-WAIT connections were left on the server and this required very high-end servers to handle large numbers of HTTP connections. I am surprised, based on that experience, that BEEP doesn't offer a way for the two ends of the session to negotiation/control who will initiate the TCP portion of the close. Is BEEP specifically tailored for use in cases where there will be many clients and few servers? In NETCONF we have the opposite situation -- one (or a few) client(s) and many servers. Anyway, maybe we should check with some transport-saavy folks to see if this is still an important consideration for protocol design? Margaret -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Aug 23 08:11:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02752 for ; Mon, 23 Aug 2004 08:11:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzDZ5-0009e7-CI for netconf-data@psg.com; Mon, 23 Aug 2004 12:04:43 +0000 Received: from [212.201.44.23] (helo=hermes.iu-bremen.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzDYu-0009Zy-AJ for netconf@ops.ietf.org; Mon, 23 Aug 2004 12:04:32 +0000 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 209489350; Mon, 23 Aug 2004 14:04:31 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19788-04; Mon, 23 Aug 2004 14:04:30 +0200 (CEST) Received: from james (G5b0c.g.pppool.de [80.185.91.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 11E2B62FE; Mon, 23 Aug 2004 14:04:30 +0200 (CEST) Received: from schoenw by james with local (Exim 4.34) id 1BzDYp-0000rn-UI; Mon, 23 Aug 2004 14:04:27 +0200 Date: Mon, 23 Aug 2004 14:04:27 +0200 From: Juergen Schoenwaelder To: Margaret Wasserman Cc: netconf Subject: Re: little problem with Message-ID: <20040823120427.GA3281@james> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Margaret Wasserman , netconf References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> <41265E52.1050802@cisco.com> <002c01c486fd$77bc6620$7f1afea9@oemcomputer> <4128ED5A.8010409@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk On Mon, Aug 23, 2004 at 05:52:54AM -0400, Margaret Wasserman wrote: > Perhaps, given the capabilities of workstations and/or some > enhancements to the TCP protocol this is no longer a serious problem? > I know that it was a serious problem when HTTP 1.0 was introduced -- > in that case the TIME-WAIT connections were left on the server and > this required very high-end servers to handle large numbers of HTTP > connections. To we envision short lived netconf connections? I mean, in HTTP 1.0, you had a separate connection for every little icon or other gimmick. Do we expect that same for netconf? I would hope not. On the other hand, lazy script writers might produce exactly this kind of thing (and most of them will not bother about nice cleanups and just call "exit" or whatever). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Aug 23 09:06:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06512 for ; Mon, 23 Aug 2004 09:06:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzEOg-000Fdo-8P for netconf-data@psg.com; Mon, 23 Aug 2004 12:58:02 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzEOV-000FcZ-JB for netconf@ops.ietf.org; Mon, 23 Aug 2004 12:57:51 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Aug 2004 06:02:30 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7NCvmDO028064; Mon, 23 Aug 2004 05:57:49 -0700 (PDT) Received: from [192.168.1.3] (sjc-vpn4-555.cisco.com [10.21.82.43]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA00553; Mon, 23 Aug 2004 05:57:48 -0700 (PDT) Message-ID: <4129E9CC.3020608@cisco.com> Date: Mon, 23 Aug 2004 14:57:48 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: netconf Subject: Re: little problem with References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> <41265E52.1050802@cisco.com> <002c01c486fd$77bc6620$7f1afea9@oemcomputer> <4128ED5A.8010409@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret, My goof. I misread the RFC. It is based on who requests the close (the other guy then closes). So if the agent wants to close, the manager would initiate the close. On the other hand, in the case you are concerned about, as currently written, when the manager wants to close, it would be the agent that initiates the close. RFCs in question are 3080 and 3081. 3081 has the TCP mapping. I'd like to understand how much the CLOSE_WAIT concern is real. The problem with HTTP 1.0 is that each site would create tens of connections to retrieve a page. In addition, sessions were VERY short lived. Will either of these cases be generally true? Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Aug 23 09:09:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06667 for ; Mon, 23 Aug 2004 09:09:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BzESf-000G8B-QW for netconf-data@psg.com; Mon, 23 Aug 2004 13:02:09 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzESV-000G6q-38 for netconf@ops.ietf.org; Mon, 23 Aug 2004 13:01:59 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Aug 2004 06:06:38 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i7ND1bJa017121; Mon, 23 Aug 2004 06:01:53 -0700 (PDT) Received: from [192.168.1.3] (sjc-vpn4-555.cisco.com [10.21.82.43]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA03561; Mon, 23 Aug 2004 06:01:39 -0700 (PDT) Message-ID: <4129EAB4.104@cisco.com> Date: Mon, 23 Aug 2004 15:01:40 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040814 X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: Margaret Wasserman , netconf Subject: Re: little problem with References: <41238823.4090904@cisco.com> <4124F34E.50605@cisco.com> <000401c48629$8bf225a0$7f1afea9@oemcomputer> <41265E52.1050802@cisco.com> <002c01c486fd$77bc6620$7f1afea9@oemcomputer> <4128ED5A.8010409@cisco.com> <20040823120427.GA3281@james> In-Reply-To: <20040823120427.GA3281@james> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-netconf@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > On the other hand, lazy script writers might produce exactly this > kind of thing (and most of them will not bother about nice cleanups > and just call "exit" or whatever). Yah, presumably that's okay as long as they don't repeatedly hit the same element in a rapid-fire sort of way. Eliot -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: