From owner-netconf@ops.ietf.org Tue Jan 01 04:48:57 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9dk1-0000Zs-Ib for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 04:48:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9djy-00082Y-UW for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 04:48:57 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9dXN-000L0D-9e for netconf-data@psg.com; Tue, 01 Jan 2008 09:35:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [198.152.13.100] (helo=co300216-co-outbound.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9dWp-000KxS-Sh for netconf@ops.ietf.org; Tue, 01 Jan 2008 09:35:38 +0000 X-IronPort-AV: E=Sophos;i="4.24,230,1196658000"; d="scan'208";a="95445003" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 01 Jan 2008 04:35:18 -0500 X-IronPort-AV: E=Sophos;i="4.24,230,1196658000"; d="scan'208";a="138482778" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Jan 2008 04:34:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DRAFT minutes from NETCONF meeting at IETF 70 Date: Tue, 1 Jan 2008 10:34:35 +0100 Message-ID: In-Reply-To: <18297.28117.324037.143910@switch.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DRAFT minutes from NETCONF meeting at IETF 70 Thread-Index: AchL/WZ9E1WsioBDTfqfe53j1SjGjwAW0hBQ References: <18297.28117.324037.143910@switch.ch> From: "Romascanu, Dan (Dan)" To: "Simon Leinen" , Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -2.8 (--) X-Scan-Signature: 2f46977da373544777a750d5247d6ccc The minutes look good, thanks, Simon.=20 I have just one comment:=20 > Dan Romascanu: This is the document that drew the most attention from the IESG when the charter came up. There was an early review in the IESG to make sure that there weren't any red flags. I was referring to the early security review for NETCONF over TLS which was not yet performed as it could be understood in the text above, but was introduced as an explicit milestone in the charter to be performed by the Security Area experts.=20 Dan =20 =20 > -----Original Message----- > From: owner-netconf@ops.ietf.org=20 > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Simon Leinen > Sent: Tuesday, January 01, 2008 12:32 AM > To: netconf@ops.ietf.org > Subject: DRAFT minutes from NETCONF meeting at IETF 70 >=20 > Draft minutes have been posted to the IETF proceedings site on >=20 > http://www3.ietf.org/proceedings/07dec/minutes/netconf.html >=20 > Please check them and send me your corrections. I'll try to=20 > make sure that those are applied quickly. Thanks in advance! > Plain-text version of the draft minutes follows. > -- > Simon. >=20 > NETCONF Working Group meeting >=20 > IETF 70, Vancouver, B.C., Canada > Wednesday, 5 December 2007 > Minutes by Simon Leinen based on notes from David Partain. >=20 > Administrativia ([1]slides) >=20 > NETCONF is 4.5 years old! >=20 > Dan Romascanu: Applause for outgoing chairs! The process=20 > is ongoing for > selecting new chairs. >=20 > Notifications Document (draft-ietf-netconf-notifications) >=20 > The notification document passed WG last call, and is pending proto > writeup, to then be handed to the IESG. Dan Romascanu=20 > mentions that the > writeup can be done by one of the new chairs or someone else. >=20 > Bert Wijnen: Shouldn't the proto write-up be written by one of the > outgoing chairs? > Simon: That might be an option. >=20 > Use of Mailing Lists >=20 > Mailing lists: Many mailing lists are used for NETCONF-related > discussions right now, including the APPS area mailing list. One > proposal: move all netconf-related discussions into the=20 > main netconf > list. > Sharon Chisholm: keep netconf for chartered items, and keep NGO for > non-chartered discussion. Axe all the others. After=20 > discussion, the new > proposal is to keep all lists except for the netmod list at Nortel > (netconfmodel@lists.nortel.com). Proposed usage guidelines: >=20 > netconf@ops.ietf.org > For discussions related to work on whatever is the current > NETCONF charter. >=20 > ngo@ietf.org > For discussions about unchartered NETCONF-related work, > including data-model proposals in general. >=20 > yang@ietf.org > For discussion about the YANG data-modeling=20 > language proposal. >=20 > netconfmodel@lists.nortel.com > Can be abandoned. >=20 > New Security Advisor >=20 > Charlie Kaufman agreed to serve as the new security advisor for the > working group. >=20 > New charter items >=20 > The new charter was accepted by the IESG in November. One=20 > goal of this > meeting is to determine whether input documents are in a=20 > good enough > state for their change control to be moved to the working group. > =20 > __________________________________________________________________ >=20 > Mohamad Badra on NETCONF over TLS ([2]slides) >=20 > Balazs Lengyel: The authentication part is welcome, but=20 > access control > is outside our current charter. >=20 > Dan Romascanu: This is the document that drew the most=20 > attention from > the IESG when the charter came up. There was an early review in the > IESG to make sure that there weren't any red flags. >=20 > Show of hands >=20 > 8-10 people present have read this document, almost the same number > thinks this should be adopted as a WG item, with no-one=20 > objecting. Will > confirm this decision on the mailing list. Not terribly=20 > wide review. > =20 > __________________________________________________________________ >=20 > Balazs Lengyel on partial locking ([3]slides) >=20 > Balazs Lengyel spent more time explaining the YANG module=20 > that he has > written for maintaining configuration of the locks on a system. >=20 > Full XPath support vs. (Instance Identifier) XPath subset >=20 > Sharon Chisholm: have sent a bunch of comments to the=20 > list. One of them > is around XPath: "if you don't support XPath, then you can=20 > support this > smaller subset". Should we just mandate XPath if you support this > capability (fine-grained locking)? >=20 > Andy Bierman: absolutely doesn't want to use full XPath. The XPath > expression can be dynamic. > Balazs: the XPath is only evaluated once. > Andy: that's a security hole -- if you don't apply it when it's > evaluated. Andy wants the >=20 > Use of YANG to describe locking data model >=20 > Dan Romascanu: about the use of YANG: Not sure whether it=20 > will be in > the final draft, but as long as it's not a standard, we=20 > cannot use it > normatively - although perhaps in an annex. For=20 > normatively describing > the data model, we'd need to use something else. > Balazs agrees that we'll have to deal with this problem. >=20 > Lock semantics, interactions, and security >=20 > Phil Shafer: Please talk about the interactions between=20 > partial locks, > get-config, and commit. Phil thinks there are interactions=20 > that Balazs > doesn't. If two users have locked two different parts of=20 > the database > with dependencies between the two, and I change mine based on your > values which then are not committed, what happens? > Balazs: there are issues; we need to describe this carefully. >=20 > Wes Hardaker: if you do a partial lock on part of the=20 > config but then > try to edit outside that part that you've locked, do you=20 > get feedback > on that? > Balazs: no, not at this point. > Wes: only an interesting management error to consider. >=20 > Wes Hardaker reiterates that he's worried about evaluation of XPath > expressions taking place at a time other than when it's=20 > being applied. > Andy: what if one of the things you are changing is in the lock > expression? > Balazs: having a very dynamic lock has its own set of problems. >=20 > Phil Shafer: Lifespan of the lock, in terms of how long they're > supposed to last. The global lock was intended to cover=20 > the duration of > your edit, whereas you are talking about longer times. > Balazs: it would be possible to add a timeout to the partial lock. > Phil: are you intending these to be short-term or long-term locks? > Balazs: I can't control it, but my intention is that they be > short-term. Balazs will add a comment to the draft. >=20 > Wes Hardaker: one question about the partial lock of a=20 > tree. If I lock > the user table, can someone else add a user? > Balazs: no. >=20 > Mark Scott: why can a lock only be unlocked in the same session? > Balazs: even today, if you have locked (the global lock) in one > session, you can't unlock it in a different user session and we're > continuing that. >=20 > David Harrington: What session does SNMP lock? > Balazs: one idea is that all non-NETCONF protocols might have a > reserved session id range. > Sharon: the monitoring draft is a good place to report=20 > these sessions. >=20 > Phil Shafer: you mentioned being able to do locks on startup > configuration, but that config is not writable. > Balazs: you're probably right. >=20 > Show of hands >=20 > 11-12 people present have read this document. Nearly all=20 > of those favor > WG adoption, with one person against it. > =20 > __________________________________________________________________ >=20 > Mark Scott on monitoring NETCONF ([4]slides) >=20 > Balazs Lengyel: the GUI / CLI / locks inside are very much needed. > Consider locks that are "internal" like a backup process.=20 > Why aren't > any counters included? >=20 > Mark: simply because it's a different area, and it would=20 > be hard to get > it standardized in the short term. We don't think that the=20 > operational > data is not relevant to making the configuration process=20 > more bug-free. > There is a minimal set still included. >=20 > Show of hands >=20 > About 8 people present have read this, about 6 in favor of=20 > adoption, no > objections. > =20 > __________________________________________________________________ >=20 > Hideki Okita: schema advertisement with WSDL and XSD ([5]slides) >=20 > Rohan Mahy: Are you assuming that schemas be transient? > Hideki Okita: mostly interested in knowing where the=20 > information is and > how to get to it. > Rohan: if I go to my device and ask it about its schemas,=20 > and there are > YANG modules, XSD, and there's a RelaxNG schema. Will the=20 > query tell me > about all three or only one of them? > Simon: are you saying it would be useful to be able to get=20 > the schemas > in different forms? > Rohan: yes, it'd be useful. >=20 > David Perkins: the user wants to know what the device=20 > does, not what > the standards document says it's supposed to do. If the=20 > device doesn't > fully comply, you want to know that. >=20 > Dan Romascanu reminds presenters to avoid putting company names on > slides. >=20 > Show of hands >=20 > About 11 people present have read this document. Polling=20 > on WG adoption > is deferred to after the next draft's discussion. > =20 > __________________________________________________________________ >=20 > Mark Scott on schema query ([6]slides) >=20 > Scope perhaps a bit narrower than the previous proposal. >=20 > Balazs: are you opposed to merging the two drafts? > Mark: not opposed. >=20 > Hideki Okita: what is the use case for the work? >=20 > Specific operations () vs. >=20 > Phil Shafer: have we abandoned dedicated RPCs and gone to the > all-powerful get? >=20 > Balazs: I have some rules in my mind when to use them. Can=20 > the normal > RPCs accomplish them, then why not use it? >=20 > Mark: I had the same question. Maybe we should write down when it > should be new ones and when not. >=20 > David Harrington: I thought NETCONF was going to be=20 > "task-based" and I > think it would make it unfortunate if this became >=20 > Andy: when you are actually adding a new verb, then do so.=20 > If you're > just changing what you're getting, then don't add a new verb. >=20 > Sharon: CLIs have a single verb for a show but not for=20 > changes. I agree > that there are cases where we should create new verbs.=20 > Don't see that > this is a case where a new verb is needed. >=20 > Finer-grained semantics >=20 > David Perkins: How do you specify that a device has implemented a > subset of a schema? > Mark: you'd have to put your own sub-set schema somewhere=20 > and publish > that subset somewhere. > Sharon: not sure that we need this for our requirements=20 > unless they're > non-conformant. The manager should be able to handle that=20 > non-mandatory > objects aren't there. For the most part, the high-level information > (name, version number) is sufficient. We're getting 90% of=20 > the value > without getting into the specifics. >=20 > Wes: David Perkins is absolutely right. NM applications=20 > can't figure > out how things are broken. >=20 > David Harrington: concerned that this sounds like=20 > AGENT-CAPABILITIES, > which failed. >=20 > Dan Romascanu: This looks more like the RMON capabilities stuff. >=20 > Show of hands >=20 > 10-11 people present have read Mark's document. In order=20 > to gauge the > relative preference, Simon asked for a show of hands in favor of WG > adoption for each of the drafts. Because the sample size=20 > is small, the > results cannot be used to make a decision. Five people=20 > think Hideki's > draft should be adopted, 6-7 people think Mark's draft should be > adopted. >=20 > Dan Romascanu: A suggestion as a contributor: Since there=20 > doesn't seem > to be a clear-cut answer, maybe the two groups should try to work > together. >=20 > Andy Bierman: concerned that a NETCONF agent would have to=20 > use HTTP. A > lot of overhead for not much information instead of using=20 > NETCONF to > get it. >=20 > David Harrington: concerned about introducing dependencies on other > protocols. >=20 > Hideki Okita: we have HTTP already, so it's not a concern=20 > to us, but I > understand your concern. >=20 > Simon: it's clear why your approach is attractive given that you've > used SOAP. >=20 > Phil Shafer: operators often do not enable HTTP on their devices. > =20 > __________________________________________________________________ >=20 > Other business >=20 > Sharon: there's some work that's not in the charter=20 > because we didn't > know if this would be a new WG or if it'd be in a > 1. Clarifications of implementation issues in a bis of=20 > the NETCONF RFC > 2. Update on transport documents > =20 > __________________________________________________________________ >=20 > Tomoyuki Iijima on experience of implementing a SOAP-based NETCONF > client-server ([7]slides) >=20 > Please contact him if you'd like to see a demonstration. >=20 > References >=20 > 1. http://www3.ietf.org/proceedings/07dec/slides/netconf-0/sld1.htm > 2. http://www3.ietf.org/proceedings/07dec/slides/netconf-3/sld1.htm > 3. http://www3.ietf.org/proceedings/07dec/slides/netconf-1/sld1.htm > 4. http://www3.ietf.org/proceedings/07dec/slides/netconf-6/sld1.htm > 5. http://www3.ietf.org/proceedings/07dec/slides/netconf-4/sld1.htm > 6. http://www3.ietf.org/proceedings/07dec/slides/netconf-5/sld1.htm > 7. http://www3.ietf.org/proceedings/07dec/slides/netconf-2/sld1.htm >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org=20 > with the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jan 01 07:18:31 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9g4l-0003rm-8Y for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 07:18:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9g4k-0001Ys-MZ for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 07:18:31 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9fzQ-0004UK-Ix for netconf-data@psg.com; Tue, 01 Jan 2008 12:13:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9fzN-0004Tt-A1 for netconf@ops.ietf.org; Tue, 01 Jan 2008 12:12:58 +0000 Received: (from leinen@localhost) by diotima.switch.ch (8.14.1+Sun/8.14.1) id m01CCpO4012688; Tue, 1 Jan 2008 13:12:51 +0100 (CET) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: "Romascanu, Dan (Dan)" Cc: Subject: Re: DRAFT minutes from NETCONF meeting at IETF 70 In-Reply-To: (Dan Romascanu's message of "Tue, 1 Jan 2008 10:34:35 +0100") References: <18297.28117.324037.143910@switch.ch> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Date: Tue, 01 Jan 2008 13:12:51 +0100 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Dan Romascanu writes: > The minutes look good, thanks, Simon. > I have just one comment: >> Dan Romascanu: This is the document that drew the most attention > from the IESG when the charter came up. There was an early review > in the IESG to make sure that there weren't any red flags. > I was referring to the early security review for NETCONF over TLS > which was not yet performed as it could be understood in the text > above, but was introduced as an explicit milestone in the charter to > be performed by the Security Area experts. Thanks for reviewing, and for the clarification. I have updated the minutes accordingly. -- Simon. -- 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 Jan 01 09:12:06 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9hqg-0006AR-KN for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 09:12:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9hqf-0002zz-5A for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 09:12:06 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9hkz-000BHk-7o for netconf-data@psg.com; Tue, 01 Jan 2008 14:06:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9hjO-000B6V-Jh for netconf@ops.ietf.org; Tue, 01 Jan 2008 14:04:36 +0000 Received: from localhost (localhost [IPv6:::1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id m01E4SLx018840; Tue, 1 Jan 2008 15:04:29 +0100 (CET) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18298.18540.204228.774810@switch.ch> Date: Tue, 1 Jan 2008 15:04:28 +0100 To: netconf@ops.ietf.org CC: ngo@ietf.org Subject: WG adoption of draft-lengyel-ngo-partial-lock-01.txt X-Mailer: VM 8.0.0-453 under Emacs 22.1.1 (i486-pc-linux-gnu) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Judging from feedback given at last month's IETF meeting, the NETCONF WG has adopted this draft as a basis for its work under the charter item: 1. Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore. Discussion of this document should continue on the mailing list. Balasz, feel free to submit the next version of the document as draft-ietf-netconf-partial-lock-00.txt. -- Simon. -- 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 Jan 01 09:12:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9hqp-0006JA-JC for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 09:12:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9hqp-000304-9n for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 09:12:15 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9hju-000BAx-3U for netconf-data@psg.com; Tue, 01 Jan 2008 14:05:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9hjb-000B8x-GB for netconf@ops.ietf.org; Tue, 01 Jan 2008 14:04:48 +0000 Received: from localhost (localhost [IPv6:::1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id m01E4ipf018850; Tue, 1 Jan 2008 15:04:44 +0100 (CET) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18298.18556.419742.867514@switch.ch> Date: Tue, 1 Jan 2008 15:04:44 +0100 To: netconf@ops.ietf.org CC: ngo@ietf.org Subject: WG adoption of draft-badra-tls-netconf-04.txt X-Mailer: VM 8.0.0-453 under Emacs 22.1.1 (i486-pc-linux-gnu) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Judging from feedback given at last month's IETF meeting, the NETCONF WG has adopted this draft as a basis for its work under the charter item: 4. NETCONF over TLS - based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for NETCONF Discussion of this document should continue on the mailing list. Mohamad, feel free to submit the next version of the document as draft-ietf-netconf-tls-00.txt. -- Simon. -- 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 Jan 01 09:12:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9hr1-0006zk-3u for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 09:12:27 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9hr0-00030J-QJ for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 09:12:27 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9hkx-000BHZ-Po for netconf-data@psg.com; Tue, 01 Jan 2008 14:06:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9hjU-000B8S-4s for netconf@ops.ietf.org; Tue, 01 Jan 2008 14:04:42 +0000 Received: from localhost (localhost [IPv6:::1]) by diotima.switch.ch (8.14.1+Sun/8.14.1) with ESMTP id m01E4XLm018843; Tue, 1 Jan 2008 15:04:33 +0100 (CET) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18298.18545.367377.451056@switch.ch> Date: Tue, 1 Jan 2008 15:04:33 +0100 To: netconf@ops.ietf.org CC: ngo@ietf.org Subject: WG adoption of draft-scott-netconf-monitoring-00.txt X-Mailer: VM 8.0.0-453 under Emacs 22.1.1 (i486-pc-linux-gnu) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Judging from feedback given at last month's IETF meeting, the NETCONF WG has adopted this draft as a basis for its work under the charter item: 2. NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. NETCONF does not provide this capability. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation. Discussion of this document should continue on the mailing list. Mark, feel free to submit the next version of the document as draft-ietf-netconf-monitoring-00.txt. -- Simon. -- 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 Jan 01 15:32:37 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9nmv-0000yy-Bh for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 15:32:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9nmt-0006J0-51 for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 15:32:37 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9nex-000D4N-CS for netconf-data@psg.com; Tue, 01 Jan 2008 20:24:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9neu-000D3x-MX for netconf@ops.ietf.org; Tue, 01 Jan 2008 20:24:22 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 84B6320450; Tue, 1 Jan 2008 21:24:18 +0100 (CET) X-AuditID: c1b4fb3e-afea1bb00000459d-e0-477aa172eab6 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 600D420197; Tue, 1 Jan 2008 21:24:18 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jan 2008 21:24:18 +0100 Received: from [127.0.0.1] ([159.107.148.22]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Jan 2008 21:24:17 +0100 Message-ID: <477AA182.6040002@ericsson.com> Date: Tue, 01 Jan 2008 21:24:34 +0100 From: Balazs Lengyel Reply-To: balazs.lengyel@ericsson.com User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Simon Leinen CC: netconf@ops.ietf.org, ngo@ietf.org Subject: Re: [NGO] WG adoption of draft-lengyel-ngo-partial-lock-01.txt References: <18298.18540.204228.774810@switch.ch> In-Reply-To: <18298.18540.204228.774810@switch.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jan 2008 20:24:17.0866 (UTC) FILETIME=[48C392A0:01C84CB4] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 I will do it. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com Simon Leinen wrote: > Judging from feedback given at last month's IETF meeting, the NETCONF > WG has adopted this draft as a basis for its work under the charter > item: > > 1. Fine-grain locking: The base NETCONF protocol only provides a > lock for the entire configuration datastore, which is not > deemed to meet important operational and security > requirements. The NETCONF working group will produce a > standards-track RFC specifying a mechanism for fine-grain > locking of the NETCONF configuration datastore. > > Discussion of this document should continue on the > mailing list. > > Balasz, feel free to submit the next version of the document as > draft-ietf-netconf-partial-lock-00.txt. -- 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 Jan 01 18:16:00 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9qL2-0002ge-Mm for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 18:16:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9qL1-0008Es-9C for netconf-archive@lists.ietf.org; Tue, 01 Jan 2008 18:16:00 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9qFm-0000YY-AZ for netconf-data@psg.com; Tue, 01 Jan 2008 23:10:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J9qFG-0000Vf-UT for netconf@ops.ietf.org; Tue, 01 Jan 2008 23:10:19 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 204D7328B6; Tue, 1 Jan 2008 23:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J9qFG-0001sW-0A; Tue, 01 Jan 2008 18:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-netconf-tls-00.txt Message-Id: Date: Tue, 01 Jan 2008 18:10:02 -0500 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF over TLS Author(s) : M. Badra Filename : draft-ietf-netconf-tls-00.txt Pages : 9 Date : 2008-01-01 The NETCONF configuration protocol provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use TLS to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-tls-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-tls-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-01180118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-tls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-tls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-01180118.I-D\@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jan 07 07:30:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBr7B-0000MG-I2 for netconf-archive@lists.ietf.org; Mon, 07 Jan 2008 07:30:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBr7A-0005AZ-01 for netconf-archive@lists.ietf.org; Mon, 07 Jan 2008 07:30:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JBqy2-0000dE-Kn for netconf-data@psg.com; Mon, 07 Jan 2008 12:20:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JBqxX-0000am-72 for netconf@ops.ietf.org; Mon, 07 Jan 2008 12:20:19 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 56F7932934; Mon, 7 Jan 2008 12:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JBqxW-0008L9-7W; Mon, 07 Jan 2008 07:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-netconf-partial-lock-00.txt Message-Id: Date: Mon, 07 Jan 2008 07:20:02 -0500 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Partial Lock RPC for NETCONF Author(s) : B. Lengyel, M. Bjorklund Filename : draft-ietf-netconf-partial-lock-00.txt Pages : 11 Date : 2008-01-07 The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-partial-lock-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-partial-lock-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-07071443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-partial-lock-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-partial-lock-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-07071443.I-D\@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jan 09 13:32:57 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCfjV-00050Y-Ow for netconf-archive@lists.ietf.org; Wed, 09 Jan 2008 13:32:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCfjU-0007p8-Cx for netconf-archive@lists.ietf.org; Wed, 09 Jan 2008 13:32:57 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCfaF-000B8f-31 for netconf-data@psg.com; Wed, 09 Jan 2008 18:23:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCfZw-000B73-2j for netconf@ops.ietf.org; Wed, 09 Jan 2008 18:23:21 +0000 X-IronPort-AV: E=Sophos;i="4.24,263,1196658000"; d="scan'208";a="91210126" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 09 Jan 2008 13:23:00 -0500 X-IronPort-AV: E=Sophos;i="4.24,263,1196658000"; d="scan'208";a="141047242" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 09 Jan 2008 13:23:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: test Date: Wed, 9 Jan 2008 19:22:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: test Thread-Index: AchS7KhRezuroD29T3O5q0n5Y+tXBQ== From: "Romascanu, Dan (Dan)" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Test, please skip =20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jan 09 13:36:00 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCfmR-0005d9-NR for netconf-archive@lists.ietf.org; Wed, 09 Jan 2008 13:36:00 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCfmR-0007sP-DF for netconf-archive@lists.ietf.org; Wed, 09 Jan 2008 13:35:59 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCfgf-000Bhl-LL for netconf-data@psg.com; Wed, 09 Jan 2008 18:30:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCffR-000BZr-9X for netconf@ops.ietf.org; Wed, 09 Jan 2008 18:29:20 +0000 X-IronPort-AV: E=Sophos;i="4.24,263,1196658000"; d="scan'208";a="91211402" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 09 Jan 2008 13:28:42 -0500 X-IronPort-AV: E=Sophos;i="4.24,263,1196658000"; d="scan'208";a="141051834" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 09 Jan 2008 13:28:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: New NETCONF WG co-chairs Date: Wed, 9 Jan 2008 19:28:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New NETCONF WG co-chairs Thread-Index: AchS7XPxp6LZQ6F2SC6Ro9WAk/n/ow== From: "Romascanu, Dan (Dan)" To: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 We would like to inform you that we completed the process of choosing the new co-chairs for NETCONF and decided to nominate Bert Wijnen and Mehmet Ersue as co-chairs. It was not an easy choice as Ron and me had the privilege to make a selection from a pool of excellent candidates. We are sure that Bert and Mehmet bring the competence, experience and enthusiasm to continue the fine job that has been started by Andy and Simon. This working group has an ambitious but focused chartered to fulfill, while many of its participants are also involved in challenging discussions and work related to data modeling and other NETCONF-related features. We wish success to the new chairs and to the whole working group.=20 Regards, Ron and Dan =20 =20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 10 05:56:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCv4r-0002XB-Sz for netconf-archive@lists.ietf.org; Thu, 10 Jan 2008 05:56:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCv4p-0004Et-KI for netconf-archive@lists.ietf.org; Thu, 10 Jan 2008 05:56:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCuys-0000fz-48 for netconf-data@psg.com; Thu, 10 Jan 2008 10:49:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCuyR-0000eZ-4e for netconf@ops.ietf.org; Thu, 10 Jan 2008 10:49:36 +0000 Received: (qmail 19278 invoked from network); 10 Jan 2008 10:49:20 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 10 Jan 2008 10:49:20 -0000 From: "Bert Wijnen - IETF" To: Subject: Hello from your new NetConf WG chairs Date: Thu, 10 Jan 2008 11:49:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Hello NETCONF WG members, First, we would like to thank Simon and Andy for their good work in the past and getting NETCONF to the point of a Proposed Standard. We understand they now want to hand over the baton to a new team. So here we are. We are honored to be appointed as your new WG chairs. And we are eager to try and get us moving forward on the new work items we have on our charter. We are already working with Dan to get the notifications draft into IETF Last Call. Andy had done an initial document-shepherd writeup, and we are evaluating that with our AD Dan and will try to get it into IETF Last Call asap. Further, we see that 2 of our 3 working group documents (as decided at the last IETF meeting in Vancouver now have a WG revision posted in the I-D repository. These are (as posted by Simon recently): draft-ietf-netconf-tls-00 replaces draft-badra-tls-netconf-04 draft-ietf-netconf-partial-lock-00 replaces draft-lengyel-ngo-partial-lock-01 We as WG chairs will start reviewing these documents and then try to start discussions on the list. WG members, please read these documents too and post your comments (a comment like "I read it and like it" is also welcome, because it shows that people have indeed read it). A discussion on extensions or issues will get the documents more stable. We are eagerly looking forward for the 3rd one: draft-ietf-netconf-monitoring-00 replaces draft-scott-netconf-monitoring-00 We are also planning to move our mailing list and WG web page from the netconf.ops.ietf.org (this is basically hosted on psg.com system) to the ietf.org systems, where most mailing lists are hosted and archived. Your subscription should move automagically with it. We'll keep you informed. We are planning to ask for a 2 hour meeting slot at the upcoming IETF in Philadelphia. The main goal will be to make progress in completing our current work items (so that is the above 3 documents). If anyone has any constraints or requests with regard to a session at the upcoming IETF, please let us know asap. More later, Mehmet Ersue and Bert Wijnen > -----Oorspronkelijk bericht----- > Van: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org]Namens Romascanu, Dan (Dan) > Verzonden: woensdag 9 januari 2008 19:29 > Aan: netconf@ops.ietf.org > Onderwerp: New NETCONF WG co-chairs > > > We would like to inform you that we completed the process of choosing > the new co-chairs for NETCONF and decided to nominate Bert Wijnen and > Mehmet Ersue as co-chairs. It was not an easy choice as Ron and me had > the privilege to make a selection from a pool of excellent candidates. > We are sure that Bert and Mehmet bring the competence, experience and > enthusiasm to continue the fine job that has been started by Andy and > Simon. > > This working group has an ambitious but focused chartered to fulfill, > while many of its participants are also involved in challenging > discussions and work related to data modeling and other > NETCONF-related > features. We wish success to the new chairs and to the whole working > group. > > Regards, > > Ron and Dan > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- 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 Jan 10 15:36:43 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD48p-0001iA-Ev for netconf-archive@lists.ietf.org; Thu, 10 Jan 2008 15:36:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD48n-0007Ay-WC for netconf-archive@lists.ietf.org; Thu, 10 Jan 2008 15:36:43 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JD41g-000GRI-74 for netconf-data@psg.com; Thu, 10 Jan 2008 20:29:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JD41d-000GQy-HX for netconf@ops.ietf.org; Thu, 10 Jan 2008 20:29:18 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XKVGmPi/PCxIO0uZMNAGEh2SClw3WU/AncYJYZO0CmCOLfkXsOogicOdOoBBpsDq; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [69.3.144.163] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JD41a-0005TR-Mh for netconf@ops.ietf.org; Thu, 10 Jan 2008 15:29:14 -0500 Message-ID: <004d01c853c7$a5d42440$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "netconf" Subject: design team update Date: Thu, 10 Jan 2008 12:30:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a4beb055f130b31a5852d688f4dad2231da73ef8231f0139350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.3.144.163 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi - I've been asked to provide a quick update on the design team's progress. In addition to our work by email, we've had three teleconferences so far (about two hours each time), and plan to continue with bi-weekly meetings in addition to our email discussion. We've been plowing through the requirements from past meetings, making sure that we understood what was meant by each one. In several cases we've had to split them as it became apparent that there were either multiple requirements in one statement or a statement had multiple distinct interpretations. Don't be surprised if you get a call or email from a design team member asking for clarification of your pet requirement! Occasionally new ones emerge from the discussion. We've also been identifying the ones on which we could get agreement, one way or another. Our goal is to have a -00- at the end of January, so that those with proposals will have some opportunity to assess where they stand with respect to the proposed requirements before the i-d cutoff. Randy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 10 18:01:33 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD6Oy-0001Ym-Sx for netconf-archive@lists.ietf.org; Thu, 10 Jan 2008 18:01:33 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD6Oy-0000tH-Gh for netconf-archive@lists.ietf.org; Thu, 10 Jan 2008 18:01:32 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JD6Jt-0000hC-OO for netconf-data@psg.com; Thu, 10 Jan 2008 22:56:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JD6JN-0000eR-Sb for netconf@ops.ietf.org; Thu, 10 Jan 2008 22:56:02 +0000 Received: (qmail 73190 invoked from network); 10 Jan 2008 22:55:42 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 10 Jan 2008 22:55:42 -0000 From: "Bert Wijnen - IETF" To: "Randy Presuhn" , "netconf" Subject: RE: design team update Date: Thu, 10 Jan 2008 23:55:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <004d01c853c7$a5d42440$6801a8c0@oemcomputer> Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Thanks for the update Randy. Bert Wijnen=20 > -----Oorspronkelijk bericht----- > Van: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org]Namens Randy Presuhn > Verzonden: donderdag 10 januari 2008 21:31 > Aan: netconf > Onderwerp: design team update >=20 >=20 > Hi - >=20 > I've been asked to provide a quick update on the design team's > progress. In addition to our work by email, we've had three > teleconferences so far (about two hours each time), and plan to > continue with bi-weekly meetings in addition to our email discussion. >=20 > We've been plowing through the requirements from past meetings, > making sure that we understood what was meant by each one. > In several cases we've had to split them as it became > apparent that there were either multiple requirements in > one statement or a statement had multiple distinct interpretations. > Don't be surprised if you get a call or email from a design > team member asking for clarification of your pet requirement! > Occasionally new ones emerge from the discussion. We've also > been identifying the ones on which we could get agreement, > one way or another. >=20 > Our goal is to have a -00- at the end of January, so that > those with proposals will have some opportunity to assess > where they stand with respect to the proposed requirements > before the i-d cutoff. >=20 > Randy >=20 >=20 > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jan 11 03:30:48 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDFHs-0003GO-7y for netconf-archive@lists.ietf.org; Fri, 11 Jan 2008 03:30:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDFHr-0000CM-O1 for netconf-archive@lists.ietf.org; Fri, 11 Jan 2008 03:30:48 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JDFAT-0005ui-94 for netconf-data@psg.com; Fri, 11 Jan 2008 08:23:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JDF9l-0005sD-99 for netconf@ops.ietf.org; Fri, 11 Jan 2008 08:22:54 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 412C621145; Fri, 11 Jan 2008 09:22:20 +0100 (CET) X-AuditID: c1b4fb3e-af6a0bb00000459d-de-4787273c16b4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 22902213C9; Fri, 11 Jan 2008 09:22:20 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 09:22:19 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 09:22:19 +0100 Message-ID: <4787273B.9080402@ericsson.com> Date: Fri, 11 Jan 2008 09:22:19 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Bert Wijnen - IETF CC: Randy Presuhn , netconf Subject: Re: design team update References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2008 08:22:19.0846 (UTC) FILETIME=[1557C660:01C8542B] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hello Randy, Thanks for the update. I assume you will prioritize requirements as well not just list them. regards Balazs Bert Wijnen - IETF wrote: > Thanks for the update Randy. > > Bert Wijnen > >> -----Oorspronkelijk bericht----- >> Van: owner-netconf@ops.ietf.org >> [mailto:owner-netconf@ops.ietf.org]Namens Randy Presuhn >> Verzonden: donderdag 10 januari 2008 21:31 >> Aan: netconf >> Onderwerp: design team update >> >> >> Hi - >> >> I've been asked to provide a quick update on the design team's >> progress. In addition to our work by email, we've had three >> teleconferences so far (about two hours each time), and plan to >> continue with bi-weekly meetings in addition to our email discussion. >> >> We've been plowing through the requirements from past meetings, >> making sure that we understood what was meant by each one. >> In several cases we've had to split them as it became >> apparent that there were either multiple requirements in >> one statement or a statement had multiple distinct interpretations. >> Don't be surprised if you get a call or email from a design >> team member asking for clarification of your pet requirement! >> Occasionally new ones emerge from the discussion. We've also >> been identifying the ones on which we could get agreement, >> one way or another. >> >> Our goal is to have a -00- at the end of January, so that >> those with proposals will have some opportunity to assess >> where they stand with respect to the proposed requirements >> before the i-d cutoff. >> >> 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: >> > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jan 11 03:43:34 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDFUE-0006gN-Hl for netconf-archive@lists.ietf.org; Fri, 11 Jan 2008 03:43:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDFUE-0000Z7-7x for netconf-archive@lists.ietf.org; Fri, 11 Jan 2008 03:43:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JDFIO-0006VD-98 for netconf-data@psg.com; Fri, 11 Jan 2008 08:31:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JDFIL-0006Uu-OZ for netconf@ops.ietf.org; Fri, 11 Jan 2008 08:31:19 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E5E8321181 for ; Fri, 11 Jan 2008 09:31:15 +0100 (CET) X-AuditID: c1b4fb3e-b0ea3bb00000459d-01-478729533bb1 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BBF2C20412 for ; Fri, 11 Jan 2008 09:31:15 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 09:31:14 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 09:31:14 +0100 Message-ID: <47872952.803@ericsson.com> Date: Fri, 11 Jan 2008 09:31:14 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Update to partial lock draft Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2008 08:31:14.0640 (UTC) FILETIME=[541ADD00:01C8542C] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hello All, As today we do not have a standardized modeling language, and for completeness, following Dan's opinion. I plan to add a YANG definition of the new operations to the partial-lock draft. Naturally this will be informative only as YANG is not an accepted RFC. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jan 15 11:08:18 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEoKo-0004UW-Mz for netconf-archive@lists.ietf.org; Tue, 15 Jan 2008 11:08:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEoKo-0006tv-9v for netconf-archive@lists.ietf.org; Tue, 15 Jan 2008 11:08:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEo9b-000Fxj-B3 for netconf-data@psg.com; Tue, 15 Jan 2008 15:56:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEo9M-000Fua-0M for netconf@ops.ietf.org; Tue, 15 Jan 2008 15:56:40 +0000 Received: (qmail 93573 invoked from network); 15 Jan 2008 15:56:24 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 15 Jan 2008 15:56:24 -0000 From: "Bert Wijnen - IETF" To: , Cc: "Sharon Chisholm" , Subject: FW: Status of netconf-schema-query Date: Tue, 15 Jan 2008 16:56:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Mark, Hideki, Sharon, From the last IETF71 Netconf Minutes, we see that our AD (Dan) has recommended that the authors of draft-okita-netconf-advertisement-00.txt and draft-scott-netconf-schema-query-00.txt would get together and try to come up with a common proposal. Both documents were read by about the same amount of people (10-11) and when asked who would like adopt each of the documents, they both got some 5-7 or so supporters. So it is best to see if we can merge the best from the two. So, can the two of you (with your co-authors/co-editors) work together to create a new (or merge your existing) document(s) that we can put on the WG agenda for the upcoming IETF. The goal should be to try and address the WG charter item that says: 3. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible. Note that the charter also says: This item may be merged with "NETCONF monitoring" into a single document. That is why we also copied Sharon. We as WG chairs would like to know what the 3 of you want to do: a) submit one WG netconf-monitoring draft that incorporates the best ideas from the 3 of your drafts including the schema advertisement, or b) submit monitoring document based on existing monitoring document and do a separate schema-advertisment related document. In any case, we would like the documents to be submitted asap/timely, so that they meet the -00 cutof date of 11 feb 2008. This so that we have ample time to study and review and so that we can have a fruitful discussion at IETF71. Bert and Mehmet -- 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 Jan 15 16:25:21 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtHd-0005ki-2R for netconf-archive@lists.ietf.org; Tue, 15 Jan 2008 16:25:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEtHc-0006Wd-Js for netconf-archive@lists.ietf.org; Tue, 15 Jan 2008 16:25:21 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEt8C-0003Xc-1X for netconf-data@psg.com; Tue, 15 Jan 2008 21:15:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEt7g-0003Sq-Hg for netconf@ops.ietf.org; Tue, 15 Jan 2008 21:15:20 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2A49A3289D; Tue, 15 Jan 2008 21:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JEt7e-0005iS-QO; Tue, 15 Jan 2008 16:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: netconf@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-netconf-monitoring-00.txt Message-Id: Date: Tue, 15 Jan 2008 16:15:02 -0500 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Monitoring Schema Author(s) : M. Scott, S. Chisholm Filename : draft-ietf-netconf-monitoring-00.txt Pages : 14 Date : 2008-1-15 This document defines Netconf content via XML Schema to be used to monitor the Netconf protocol. It provides information about Netconf sessions and subscriptions. The proposed schema is intended to provide sufficient information to facilitate Netconf session and subscription management. It does not intend to provide detailed statistical session information. Though primarily intended to monitor Netconf protocol the schema also provides information for non-Netconf sessions. In particular for session management purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-netconf-monitoring-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-netconf-monitoring-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-1-15152223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netconf-monitoring-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netconf-monitoring-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-1-15152223.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Tue Jan 15 17:05:05 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtu5-0001Ni-Hg for netconf-archive@lists.ietf.org; Tue, 15 Jan 2008 17:05:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEtu4-0007pv-1m for netconf-archive@lists.ietf.org; Tue, 15 Jan 2008 17:05:05 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEtoz-0007ux-QV for netconf-data@psg.com; Tue, 15 Jan 2008 21:59:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.24.138] (helo=ns3.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEtoP-0007pD-81 for netconf@ops.ietf.org; Tue, 15 Jan 2008 21:59:33 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 443FC175AB; Tue, 15 Jan 2008 21:59:12 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JEtoN-0008Ck-QK; Tue, 15 Jan 2008 16:59:11 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-netconf-notification (NETCONF Event Notifications) to Proposed Standard Reply-To: ietf@ietf.org Cc: Message-Id: Date: Tue, 15 Jan 2008 16:59:11 -0500 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'NETCONF Event Notifications ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-01-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14141&rfc_flag=0 -- 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 Jan 15 17:10:11 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEtz1-0004y3-7p for netconf-archive@lists.ietf.org; Tue, 15 Jan 2008 17:10:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEtz0-0007xp-Jb for netconf-archive@lists.ietf.org; Tue, 15 Jan 2008 17:10:11 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEtuL-0008TK-Vx for netconf-data@psg.com; Tue, 15 Jan 2008 22:05:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEtu0-0008R0-PY for netconf@ops.ietf.org; Tue, 15 Jan 2008 22:05:04 +0000 Received: (qmail 70955 invoked from network); 15 Jan 2008 22:04:59 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 15 Jan 2008 22:04:59 -0000 From: "Bert Wijnen - IETF" To: Cc: Subject: RE: Last Call: draft-ietf-netconf-notification (NETCONF Event Notifications) to Proposed Standard Date: Tue, 15 Jan 2008 23:05:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Since Mehmet and I recently took over as WG chairs I am now the document shepherd. But the document writeup was already done/prepared by one of the earlier WG chairs. So I am submitting my review comments as IETF Last Call Comments. - sect 2.2.1 I asume that is of type dateTime!!?? Would be good to state so. - on page 14 I see: Should "netmod" be changed into "netconf" !!?? Actaully, I wonder if the line should be instead? Same question on page 15. Mmm... I see it in the Schema on page 17/18 as well. So maybe it is OK. Or is this an accidental inheritance from NETMOD efforts? Is there a good reason to make it netmod and not netconf? - Page 29/30 The above fictional notification definition could result in the following is a sample notification list, which is used in the examples in this section. On 2nd line s/is a// >> - IN IANA COnsiderations, I guess that instead of Following the format in RFC 3688, IANA has made the following registration. We should have stated: Following the format in RFC 3688, IANA is requested to make the following registration. Oh well... that is what we intended to write ;-) - I wonder how/why [XML Schema] Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer Second Edition", W3C XML Schema, October 2004. would/could be a normative reference. It is a "primer", so some sort of education/tutorial on XML Schema, no? I doubt that that should be normative. But I think the issue is that the reference is not so well described. I think they mean to point to: http://www.w3.org/TR/xmlschema-0/ Which states: XML Schema Part 0: Primer Second Edition W3C Recommendation 28 October 2004 So then it is a W3C recomendation, and then it may make sense as normative ref. I think I would make the reference as follows: [XML Schema] Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer Second Edition", W3C Recommendation, 28 October 2004 - I guess we should instruct the RFC-Editor to remove Appendix A (Change log) right before publication as RFC. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: The IESG [mailto:iesg-secretary@ietf.org] > Verzonden: dinsdag 15 januari 2008 22:59 > Aan: IETF-Announce > CC: netconf@ops.ietf.org > Onderwerp: Last Call: draft-ietf-netconf-notification (NETCONF Event > Notifications) to Proposed Standard > > > The IESG has received a request from the Network Configuration WG > (netconf) to consider the following document: > > - 'NETCONF Event Notifications ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2008-01-29. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-11.txt > > > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id > &dTag=14141&rfc_flag=0 > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > -- 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 Jan 15 17:16:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEu4t-00020M-DV for netconf-archive@lists.ietf.org; Tue, 15 Jan 2008 17:16:15 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEu4s-00084P-Rq for netconf-archive@lists.ietf.org; Tue, 15 Jan 2008 17:16:15 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEu04-0009EP-AM for netconf-data@psg.com; Tue, 15 Jan 2008 22:11:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEtzY-00099m-Lw for netconf@ops.ietf.org; Tue, 15 Jan 2008 22:11:01 +0000 Received: (qmail 73158 invoked from network); 15 Jan 2008 22:10:43 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 15 Jan 2008 22:10:43 -0000 From: "Bert Wijnen - IETF" To: Subject: Some strange text in our charter - do we have consensus? Date: Tue, 15 Jan 2008 23:10:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da [explicitly bcc:-ed Bill Fenner. I am not sure if he is still on the mailing list, Bill can you let me know?] The current WG charter has this text: - The Bill Fenner problem: Address real or perceived issue that "giving SSH for NETCONF gives full SSH access to the box" It is listed as a non-goal/non-work-item of the current charter. So we can just leave it as is. At the other hand, at the IETF69 meeting we did not have a lot of "operator" feedback on this. Discussing it with the one of the previous WG chairs (Simon), we got this explanation from Simon: > > This seems to come from a discussion at the NEE bof at IETF 69 > (http://www3.ietf.org/proceedings/07jul/minutes/nee.txt): > > [...] > Bill Fenner: possible gap, about authentication and authorization. > Operators are fine with SNMP read access, but ssh access for > NETCONF? Not sure. Perception is that NETCONF ssh access gives > full access to the box. > > Sharon Chisholm: Exactly what is this perception? > > Bert Wijnen: Completely in conflict with NETCONF requirements! > > Bill Fenner: Different operators have different concerns... > > David Partain: what should the WG do? > > Bill Fenner: TLS would help. Thinks we may need an authentication > mechanism just for NETCONF. SSH sounds like you can login to the > device which is scary. > [...] > > Maybe Bill thought (or "thought that operators would think", since > this is about perception) that NETCONF-over-SSH was linked with a > normal SSH server providing access to the full CLI. That is not the > intent: NETCONF over SSH is specified to be served on a separate TCP > port by default, and as a special SSH subsystem called "netconf". > > Well, the operators I know all permit SSH (or even TELNET) access to > their boxes for configuration, so why wouldn't they permit > NETCONF-over-SSH? Anyway. So that's why we're doing TLS! > > Best regards, > -- > Simon. > It would be good if NetConf participants (specifically operators) could chime in what they think about this "perceived problem". 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 Wed Jan 16 04:44:48 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF4pE-0003nY-U5 for netconf-archive@lists.ietf.org; Wed, 16 Jan 2008 04:44:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF4pC-0000zQ-Lq for netconf-archive@lists.ietf.org; Wed, 16 Jan 2008 04:44:48 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JF4TV-0003zb-4O for netconf-data@psg.com; Wed, 16 Jan 2008 09:22:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JF4TS-0003x5-Dm for netconf@ops.ietf.org; Wed, 16 Jan 2008 09:22:19 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2A35220F8F; Wed, 16 Jan 2008 10:21:32 +0100 (CET) X-AuditID: c1b4fb3c-b179abb0000030cf-ef-478dcc9bbb0f Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EA04120F70; Wed, 16 Jan 2008 10:21:31 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 10:21:27 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jan 2008 10:21:27 +0100 Message-ID: <478DCC96.1010708@ericsson.com> Date: Wed, 16 Jan 2008 10:21:26 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Bert Wijnen - IETF CC: netconf@ops.ietf.org Subject: Re: Some strange text in our charter - do we have consensus? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2008 09:21:27.0335 (UTC) FILETIME=[2BE06370:01C85821] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hello Bert, I think there should be a statement in the NETCONF over SSH RFC, Security considerations chapter dealing with the Bill Fenner problem. "Users should take care that allowing NETCONF over SSH should not open up other unwanted access possibilities e.g. console access to the node or access to other subsystems. This can be realized by using a dedicated SSH server for NETCONF, or using user accounts with CLI access disabled; however the exact method is up to the NETCONF server implementation." It is another question whether we want to open the RFC in order to add this? If we anyway open it to update it for Notifications, maybe this should go in as well. Balazs Bert Wijnen - IETF wrote: > [explicitly bcc:-ed Bill Fenner. I am not sure if he is still on the > mailing list, Bill can you let me know?] > > The current WG charter has this text: > > - The Bill Fenner problem: Address real or perceived issue that "giving > SSH for NETCONF gives full SSH access to the box" > > It is listed as a non-goal/non-work-item of the current charter. > So we can just leave it as is. > > At the other hand, at the IETF69 meeting we did not have a lot of > "operator" feedback on this. > > Discussing it with the one of the previous WG chairs (Simon), > we got this explanation from Simon: > >> This seems to come from a discussion at the NEE bof at IETF 69 >> (http://www3.ietf.org/proceedings/07jul/minutes/nee.txt): >> >> [...] >> Bill Fenner: possible gap, about authentication and authorization. >> Operators are fine with SNMP read access, but ssh access for >> NETCONF? Not sure. Perception is that NETCONF ssh access gives >> full access to the box. >> >> Sharon Chisholm: Exactly what is this perception? >> >> Bert Wijnen: Completely in conflict with NETCONF requirements! >> >> Bill Fenner: Different operators have different concerns... >> >> David Partain: what should the WG do? >> >> Bill Fenner: TLS would help. Thinks we may need an authentication >> mechanism just for NETCONF. SSH sounds like you can login to the >> device which is scary. >> [...] >> >> Maybe Bill thought (or "thought that operators would think", since >> this is about perception) that NETCONF-over-SSH was linked with a >> normal SSH server providing access to the full CLI. That is not the >> intent: NETCONF over SSH is specified to be served on a separate TCP >> port by default, and as a special SSH subsystem called "netconf". >> >> Well, the operators I know all permit SSH (or even TELNET) access to >> their boxes for configuration, so why wouldn't they permit >> NETCONF-over-SSH? Anyway. So that's why we're doing TLS! >> >> Best regards, >> -- >> Simon. >> > > It would be good if NetConf participants (specifically operators) could > chime in what they think about this "perceived problem". > > 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: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Wed Jan 16 06:10:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF69v-0002uO-Qu for netconf-archive@lists.ietf.org; Wed, 16 Jan 2008 06:10:15 -0500 Received: from [2001:418:1::62] (helo=psg.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JF69t-0002hP-AX for netconf-archive@lists.ietf.org; Wed, 16 Jan 2008 06:10:15 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JF5yn-0009yh-4o for netconf-data@psg.com; Wed, 16 Jan 2008 10:58:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [194.9.94.113] (helo=s87.loopia.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JF5yj-0009yG-S7 for netconf@ops.ietf.org; Wed, 16 Jan 2008 10:58:43 +0000 Received: (qmail 65043 invoked from network); 16 Jan 2008 10:58:36 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Jan 2008 10:58:36 -0000 Received: (qmail 39825 invoked from network); 16 Jan 2008 10:58:36 -0000 Received: from unknown (HELO [192.168.99.223]) (johan.rydberg@edgeware.tv@[212.112.160.94]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Jan 2008 10:58:36 -0000 Message-ID: <478DE32F.6040400@edgeware.tv> Date: Wed, 16 Jan 2008 11:57:51 +0100 From: Johan Rydberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund CC: netconf@ops.ietf.org Subject: Re: schema discovery References: <20071211.135156.74918411.mbj@tail-f.com> In-Reply-To: <20071211.135156.74918411.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Martin Bjorklund skrev: > I prefer the based approach for schema discovery. But I would > also like to see a mechanism to retrieve the actual schema over > NETCONF. The data model below supports those two concepts. It is > also extensible so that new schema formats can be added without > modifying this module. I agree, there need to be a way to fetch the schema. But as James pointed out, do there really need to be an identifier? The schema could be identified by the target namespace. I also think that the schema type should be metainformation of the value returned by (an attribute for example). ~jr -- 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 vipc12@pcconnection.com Thu Jan 17 16:12:02 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFc1q-0005B1-82 for netconf-archive@lists.ietf.org; Thu, 17 Jan 2008 16:12:02 -0500 Received: from [88.254.88.150] (helo=plee) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JFc1o-0006RJ-Um for netconf-archive@lists.ietf.org; Thu, 17 Jan 2008 16:12:02 -0500 Received: from nzl ([106.57.208.117]) by plee (8.13.1/8.13.1) with SMTP id m0HLE22r013128; Thu, 17 Jan 2008 23:14:02 +0200 Message-ID: <478FC48E.7030508@pcconnection.com> Date: Thu, 17 Jan 2008 23:11:42 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: netconf-archive@lists.ietf.org Subject: I Would Dream Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.4 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Kisses Through E-mail http://84.0.83.215/ From cockleshell@clogstore.com Sun Jan 20 10:57:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGcXv-0003K9-5M for netconf-archive@lists.ietf.org; Sun, 20 Jan 2008 10:57:19 -0500 Received: from [88.232.216.46] (helo=dgjhloe) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JGcXu-0007VD-Er for netconf-archive@lists.ietf.org; Sun, 20 Jan 2008 10:57:19 -0500 Message-ID: <000801c85b7c$49a9db80$0100007f@pexeoen> From: "Eddie Elliott" To: Subject: Jan 20 18:50:00 MSK 2008 save 1442 on a11 Ado6e/Mlcrosoft Date: Paz, 20 Oca 2008 17:57:17 +0200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 12.0.4210 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 3.5 (+++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 goto "2008softsale. com" in lnternet Explorer parallels desktop 3.0 for mac - 29 autodesk autocad electrical 2006 - 99 intuit quicken home and business 2008 - 39 cakewalk project 5 - 59 final draft 7 - 39 adobe audition 2.0 - 49 steinberg nuendo 3.1 - 99 coreldraw graphics suite x3 - 59 stuffit deluxe 11 for mac - 29 grand theft auto: san andreas - 29 adobe premiere pro cs3 - 79 alias motionbuilder 6.0 - 49 autodesk architectural desktop 2006 - 119 sonic scenarist 3.0 - 49 cakewalk project 5 - 59 From owner-netconf@ops.ietf.org Mon Jan 21 10:00:58 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGy8w-0001v4-4v for netconf-archive@lists.ietf.org; Mon, 21 Jan 2008 10:00:58 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JGy8u-0008Lz-3H for netconf-archive@lists.ietf.org; Mon, 21 Jan 2008 10:00:58 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JGxwh-000Dnw-Am for netconf-data@psg.com; Mon, 21 Jan 2008 14:48:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JGxwd-000DnG-LM for netconf@ops.ietf.org; Mon, 21 Jan 2008 14:48:17 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3A0CB207E5 for ; Mon, 21 Jan 2008 15:48:11 +0100 (CET) X-AuditID: c1b4fb3c-a8ae9bb0000007e0-94-4794b0ab0979 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1CAC2203FE for ; Mon, 21 Jan 2008 15:48:11 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 15:48:10 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jan 2008 15:48:10 +0100 Message-ID: <4794B0A9.8070909@ericsson.com> Date: Mon, 21 Jan 2008 15:48:09 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Netconf (E-mail)" Subject: Comments on Netconf Monitoring Content-Type: multipart/mixed; boundary="------------040506040105070904020606" X-OriginalArrivalTime: 21 Jan 2008 14:48:10.0538 (UTC) FILETIME=[A45C88A0:01C85C3C] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 This is a multi-part message in MIME format. --------------040506040105070904020606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Mark, Sharon, General) Netconf related performance counters are needed. Eg.g. - number of sessions - number of current sessions - number of messages, per operation type - number of faults (authentication, XML, etc.) The data model is described in XML schema which is just one possibility. At the moment it is missing real references for session and stream. I think a Yang model shall be added at least as a non-normative appendix (see attachment). Anyway we should clarify the content of the data model now, and hopefully by the next IETF we will know more about the modeling methodology. Chapter 1) Do we need this? I propose to remove it. Ch 1.1) Remove the last sentence for operation. Ch.1.2) Netconf state should not be the root level element, rather we should have something like netconf/netconfState. In types LockStatus, NetconfSubscriptionInfo real references to the sessionId would be good. This should be described at least in the documentation clause. It is possible to have zero sessions in the datastore. However when we read it out we will always have the reading session. Still I would rather see minOccurs=0 How do we represent CLI/GUI/etc. sessions? If we are speaking about locking the session can be an internal process like backup or restart. What is a sourceIdentifier? Some description is needed. Or should we just call it sessionSourceAddress which does not need an explanation? Partial locking shall be included in the schema. The sessionId must be always present for the lock. A real reference (keyRef) to the session object would be even better. stream should have a type of ncEvent:streamNameType. A real reference to the stream in the Notification Management Schema would be even better. (keyRef) Remove namedProfile The transportType enumeration is not complete, and not prepared for future new transports. It should be extensible. Beep and SOAP missing. Console should be CLI via telnet or SSH. Add none for internal processes. SessionType: Change webui to GUI, add internal srcIdentifier: rename to srcAddress. IPv6 and none for internal sessions should be included. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com --------------040506040105070904020606 Content-Type: text/plain; name="netconf-state.yang" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netconf-state.yang" module netconf-state { namespace "urn:ietf:params:xml:ns:netconf:state:1.0"; prefix "ns"; import yang-types { prefix yang; } import inet-types { prefix inet; } organization "IETF"; description "NetConf Monitoring Schema. All elements in this Schema are read-only."; revision "2007-11-12" { description "Updated to match draft-scott-netconf-monitoring-00.txt"; } revision "2007-07-22" { description "Initial revision."; } typedef SessionId { type uint32 { range "1..4294967295"; } reference "rfc4741"; } typedef ConfigName { type enumeration { enum "running"; enum "candidate"; enum "startup"; } reference "rfc4741"; } typedef transportType { type enumeration { enum "console"; enum "tcp"; enum "ssh"; enum "ssl"; } } typedef sessionType { type enumeration { enum "cli"; enum "netconf"; enum "webui"; } } grouping srcIdentifier { description "Information about source of the session."; leaf ipAddressTypev4 { type inet:ipv4-address; } leaf nodeName { type string; description "Name of the node."; } } container netconfState { config false; container capabilities { description "List of NETCONF capabilities supported by this device."; leaf-list capability { type yang:uri; min-elements 1; } } container sessions { description "List of NETCONF sessions currently active on this device."; list session { key sessionId; leaf sessionId { type SessionId; } leaf transport { type transportType; } leaf username { type string; } container sourceIdentifier { uses srcIdentifier; } leaf loginTime { type yang:date-and-time; } } } container configurations { description "List of NETCONF configuration datastores (e.g. running, startup, candidate) supported on this device and related information."; list config { key name; leaf name { type ConfigName; } container lockStatus { description "An indication of whether a resource is locked or unlocked. If locked, additional information about the locking such as user an time stamp is provided."; leaf lock-state { type enumeration { enum "locked"; enum "unlocked"; } } leaf lockedBySession { type SessionId; description "The session ID of the session that has locked this resource."; } leaf lockedTime { type yang:date-and-time; description "The date and time of when the resource was locked. If the resource is currently unlocked, this element will not be present."; } } } container subscriptions { description "List of NETCONF notification subscriptions active on this device and related information."; list subscription { key session-id; description "Information about Netconf Notification Subscriptions."; leaf session-id { type SessionId; description "The session id associated with this subscription."; } leaf stream { type string; description "The stream associated with this subscription."; } leaf filter { type anyxml; description "The filters associated with this subscription."; } leaf messagesSent { type yang:zero-based-counter32; description "A count of event notifications sent along this connection since the subscription was created."; } } } } } } --------------040506040105070904020606-- -- 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 Jan 22 07:42:35 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHISZ-0004XD-Bi for netconf-archive@lists.ietf.org; Tue, 22 Jan 2008 07:42:35 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHISW-0008A6-Ob for netconf-archive@lists.ietf.org; Tue, 22 Jan 2008 07:42:35 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHIJi-000LWX-Pn for netconf-data@psg.com; Tue, 22 Jan 2008 12:33:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHIJf-000LW0-Q1 for netconf@ops.ietf.org; Tue, 22 Jan 2008 12:33:25 +0000 Received: (qmail 43920 invoked from network); 22 Jan 2008 12:33:20 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Jan 2008 12:33:20 -0000 From: "Bert Wijnen" To: , Cc: Subject: RE: Last Call: draft-iijima-netconf-soap-implementation (Experience of implementing NETCONF over SOAP) to Informational RFC Date: Tue, 22 Jan 2008 13:33:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 [ copy to NetConf mailing list is FYI. This document is not a NETCONF WG document, but it is of course related] I reviewed this document and wonder about the following. Specifically I reviewed the document on possible conflicts or contradictions with work that has been done (or is planned to be done) in the NETCONF WG. 0.I think it would be good to add some text to the document (either front page or as the first subsection in section 1) that makes it very clear that this document is not a product from the NETCONF WG but a report on experience by some individual developers/implementers. 1.Section 1.2 I really wonder if RFC2119 language is appririate in a document like this. This is a dopcument that reports on/documents the implementation experience of the authors. I do not see that RFC2119 language makes sense (or was intended) for such a document. As far as I can tell, the document is better if the normal lower case words are used instead of the capitilized words. 2.Sect 1.3. Motivation, states: This document describes why SOAP is practical as a transport protocol of NETCONF in developing a network management system. This document also describes the experience of implementing NETCONF over SOAP. I would prefer that statements like above are written as an opinion or a belief of the authors rather than as if it is a fact on which people in general have consensus. So instead of "why SOAP is practical" I prefer to see "why the authors believe SOAP is practical" or "why the authors find Soap to be practical" 3.Sect 3.1.2 speaks about using the Cookie field in an HTTP header to exchange/store/maintain (?) a session identifier. I worry that this conflicts with (or wonder how it relates to) the fact that RFC4743 (sect 3.3. page 9/10) shows that the session-id is returned inside the hello response from the netconf-managed device. Similar concerns w.r.t. sect 3.2.2 4.Section 3.2.1 refers to "http://schema.xmlsoap.org/soap/encoding" but that page seems to not exist. Even schema.xmlsaop.org does not exist. Neither does xmlsoap.org. SO I have no idea what to check. 5.Maybe a nit, but anyway. In sect 4.1.1 (maybe in others too) yopu speak about "DOS prompt". I thought it is not really DOS anymore. It is just a "command prompt" is it not? 6.I think it would be good to add to sect 5 (Security COnsiderations) that the security considerations of RFC4741 and RFC4743 also are applicable and should be considered by any implementer or user. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: The IESG [mailto:iesg-secretary@ietf.org] > Verzonden: dinsdag 15 januari 2008 23:01 > Aan: IETF-Announce > Onderwerp: Last Call: draft-iijima-netconf-soap-implementation > (Experience of implementing NETCONF over SOAP) to Informational RFC > > > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Experience of implementing NETCONF over SOAP ' > as an Informational > RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2008-02-12. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-impl ementation-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1541 5&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- 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 Jan 22 11:19:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLq0-0001Zi-WC for netconf-archive@lists.ietf.org; Tue, 22 Jan 2008 11:19:01 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHLpx-00080F-TU for netconf-archive@lists.ietf.org; Tue, 22 Jan 2008 11:19:00 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHLiC-000KfU-Oj for netconf-data@psg.com; Tue, 22 Jan 2008 16:10:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHLi7-000Kek-4U for netconf@ops.ietf.org; Tue, 22 Jan 2008 16:10:55 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 26D8920F95; Tue, 22 Jan 2008 17:10:47 +0100 (CET) X-AuditID: c1b4fb3c-ab2eebb0000007e0-95-47961586883c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F158720F8D; Tue, 22 Jan 2008 17:10:46 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 17:10:46 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 17:10:46 +0100 Message-ID: <47961585.8070601@ericsson.com> Date: Tue, 22 Jan 2008 17:10:45 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Bert Wijnen - IETF CC: netconf@ops.ietf.org Subject: Re: Last Call: draft-ietf-netconf-notification (NETCONF Event Notifications) to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2008 16:10:46.0282 (UTC) FILETIME=[58A0CEA0:01C85D11] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hello Bert, I have read it and I am OK with the draft. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Thu Jan 24 08:30:40 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI2AC-0005HF-E0 for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 08:30:40 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI2A8-0004So-55 for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 08:30:40 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI1yp-000JOE-Ow for netconf-data@psg.com; Thu, 24 Jan 2008 13:18:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [217.146.182.13] (helo=web27808.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI1yj-000JNR-Fe for netconf@ops.ietf.org; Thu, 24 Jan 2008 13:18:53 +0000 Received: (qmail 22109 invoked by uid 60001); 24 Jan 2008 13:18:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=rzoTYoYMIh6nq/5VR593ArQRn6fRguEaz/7Qc1ot21M3Xt909yCRo0VtFtRRgaN4UV7atX5sdU7PwraiE//ygpydVsnmmYwn+sMTARYKw7ENX9DDvTF2LeFD8op9QJdZqGvDAaZBdPh0EYisu5BPvdQC/Y0Vk+7COI7vTsVL+Hg=; X-YMail-OSG: VHjzLSoVM1l7dW65SifB4Bc96iJcTgK0j648W3l6zDHBvQ5L8j89K7fLHl2DYL7XoLaAq72UaY5Fkvd_vrrH1L.16HGFb3QM95g8ZEtewep_BPUm1pGqEzn69fA- Received: from [217.115.75.229] by web27808.mail.ukl.yahoo.com via HTTP; Thu, 24 Jan 2008 13:18:47 GMT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.160 Date: Thu, 24 Jan 2008 13:18:47 +0000 (GMT) From: Mehmet Ersue Subject: Request for charter change To: dromasca@avaya.com, rbonica@juniper.net Cc: netconf@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-859375073-1201180727=:20935" Message-ID: <981942.20935.qm@web27808.mail.ukl.yahoo.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9d62a9227719824a4e99fed679d6685e --0-859375073-1201180727=:20935 Content-Type: multipart/alternative; boundary="0-1916029676-1201180727=:20935" --0-1916029676-1201180727=:20935 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0ADear ADs (and WG),=0A=0AAs new WG chairs, we have carefully studied the = current WG charter=0A http://www.ietf.org/html.charters/netconf-charter.h= tml=0A=0AAlthough the date on the charter page states that it was last upda= ted=0Aon 2008-01-09, that update was only to list us as new WG chairs and = =0Aour new Security Advisor. The base text is from a while ago, and=0Ain th= e meanwhile, some documents have completed, and some of the=0Atext that has= past tense or (future tense) is now better read as=0Abeing the present. We= also adopted a set of WG documents which=0Awere based on earlier individua= l I-Ds, and so we have completed=0Aposting of revision 00 documents for our= chartered WG work items.=0A=0AWe have clarified the text, cleaned it up a = bit and we have marked =0Aa few items as DONE. We made no substantial chang= e (of course, =0Abecause that would require WG consensus forming first).=0A= =0AADs, can you please approve that this cleanup charter text be posted =0A= as our current WG charter page. Will you forward it to iesg-secretary, =0Ao= r do we need to do so seperately (assuming you will approve)?=0A=0ABert and= Mehmet=0A=0A=0AAttached is the new charter and a rfcdiff of old and new ch= arter.=0AAnd here is the main body of the cleaned-up charter text:=0A=0ACon= figuration of networks of devices has become a critical requirement =0Afor = operators in today's highly interoperable networks. Operators from =0Alarge= to small have developed their own mechanisms or used vendor =0Aspecific me= chanisms to transfer configuration data to and from a =0Adevice, and for ex= amining device state information which may impact =0Athe configuration. Eac= h of these mechanisms may be different in =0Avarious aspects, such as sessi= on establishment, user authentication, =0Aconfiguration data exchange, and = error responses. =0A=0AThe NETCONF Working Group is chartered to produce a = protocol suitable =0Afor network configuration, with the following characte= ristics: =0A=0A- Provides retrieval mechanisms which can differentiate betw= een=0A configuration data and non-configuration data =0A- Is extensible en= ough so that vendors will provide access to all=0A configuration data on t= he device using a single protocol =0A- Has a programmatic interface (avoids= screen scraping and=0A formatting-related changes between releases) =0A- = Uses a textual data representation, that can be easily manipulated=0A usin= g non-specialized text manipulation tools. =0A- Supports integration with e= xisting user authentication methods =0A- Supports integration with existing= configuration database systems =0A- Supports network wide configuration tr= ansactions (with features such=0A as locking and rollback capability) =0A-= Is as transport-independent as possible =0A- Provides support for asynchro= nous notifications. =0A=0AThe NETCONF protocol is using XML for data encodi= ng purposes, because =0AXML is a widely deployed standard which is supporte= d by a large number =0Aof applications. =0A=0AThe NETCONF protocol should b= e independent of the data definition =0Alanguage and data models used to de= scribe configuration and state =0Adata. =0A=0AHowever, the authorization mo= del used in the protocol is dependent on =0Athe data model. Although these = issues must be fully addressed to =0Adevelop standard data models, only a s= mall part of this work will be =0Ainitially addressed. This group will spec= ify requirements for standard =0Adata models in order to fully support the = NETCONF protocol, such as: =0A=0A- identification of principals, such as us= er names or distinguished names =0A- mechanism to distinguish configuration= from non-configuration data =0A- XML namespace conventions =0A- XML usage = guidelines =0A=0AThe initial work started in 2003 and has already been comp= leted and was =0Arestricted to following items: =0A=0A a) NETCONF Protocol= Specification, which defines the operational model,=0A protocol operat= ions, transaction model, data model requirements,=0A security requireme= nts, and transport layer requirements. =0A b) NETCONF over SSH Specificati= on: Implementation Mandatory, =0A c) NETCONF over BEEP Specification: Impl= ementation Optional,=0A d) NETCONF over SOAP Specification: Implementation= Optional.=0A=0A These documents define how the NETCONF protocol is used w= ith each =0A transport protocol selected by the working group, and how it = meets =0A the security and transport layer requirements of the NETCONF Pro= tocol =0A Specification. =0A=0A e) NETCONF Notification Specification, wh= ich defines mechanisms that=0A provide an asynchronous message notifica= tion delivery service for=0A the NETCONF protocol. NETCONF Notificatio= n is an optional=0A capability built on top of the base NETCONF definit= ion and=0A provides the capabilities and operations necessary to suppor= t=0A this service.=0A=0AIn the current phase of the incremental develop= ment of NETCONF the =0Aworkgroup will focus on following items: =0A=0A1. Fi= ne-grain locking: The base NETCONF protocol only provides a lock=0A for t= he entire configuration datastore, which is not deemed to meet=0A importa= nt operational and security requirements. The NETCONF working=0A group wi= ll produce a standards-track RFC specifying a mechanism for=0A fine-grain= locking of the NETCONF configuration datastore. =0A=0A2. NETCONF monitorin= g: It is considered best practice for IETF working=0A groups to include m= anagement of their protocols within the scope of=0A the solution they are= providing. The NETCONF working group will=0A produce a standards-track R= FC with mechanisms allowing NETCONF=0A itself to be used to monitor some = aspects of NETCONF operation. =0A=0A3. Schema advertisement: Currently the = NETCONF protocol is able to=0A advertise which protocol features are supp= orted on a particular=0A netconf-capable device. However, there is curren= tly no way to discover=0A which XML Schema are supported on the device. T= he NETCONF working=0A group will produce a standards-track RFC with mecha= nisms making this=0A discovery possible (this item may be merged with "NE= TCONF monitoring"=0A into a single document). =0A=0A4. NETCONF over TLS: = Based on implementation experience there is a=0A need for a standards tra= ck document to define NETCONF over TLS as an=0A optional transport for th= e NETCONF protocol.=0A=0AThe following items have been identified as import= ant but are currently=0Anot considered in scope for re-chartering and may b= e candidates for work=0Awhen there is community consensus to take them on: = =0A=0A- General improvements to the base protocol =0A- Access Control requi= rements =0A- NETCONF access to SMI-based MIB data=0A=0A=0AGoals and Milesto= nes:=0ADone Working Group formed =0ADone Submit initial Netconf P= rotocol draft =0ADone Submit initial Netconf over (transport-TBD) draf= t =0ADone Begin Working Group Last Call for the Netconf Protocol draft= =0ADone Begin Working Group Last Call for the Netconf over (transport= -TBD)=0A draft =0ADone Submit final version of the Netconf Pr= otocol draft to the IESG =0ADone Submit final version of the Netconf o= ver SOAP draft to the IESG =0ADone Submit final version of the Netconf= over BEEP draft to the IESG =0ADone Submit final version of the Netco= nf over SSH draft to the IESG =0ADone Update charter =0ADone Subm= it first version of NETCONF Notifications document =0ADone Begin WGLC = of NETCONF Notifications document =0ADone Submit final version of NETC= ONF Notifications document to IESG=0A for consideration as Propose= d Standard =0ADone -00 draft for fine Grain Locking =0ADone -00 d= raft for NETCONF over TLS =0ADone -00 draft for NETCONF Monitoring =0A= Feb 2008 -00 draft for Schema Advertisement =0AMar 2008 Early Review of c= lient authentication approach (for NETCONF over=0A TLS) with the s= ecurity community at IETF 71 =0AAug 2008 WG Last Call on NETCONF Monitorin= g after IETF72 =0AAug 2008 WG Last Call on Schema Advertisement after IETF= 72 =0AAug 2008 WG Last Call on Fine Grain Locking after IETF72 =0AAug 2008= WG Last Call on NETCONF over TLS after IETF72 =0AAug 2008 Send four docu= ments to the IESG for consideration as proposed=0A standards=0A=0A= =0A=0A=0A=0A=0A __________________________________ Ihr erstes Fernweh= ? Wo gibt es den sch=C3=B6nsten Strand? www.yahoo.de/clever --0-1916029676-1201180727=:20935 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Dear ADs (and WG),

As new WG chairs, we have carefully s= tudied the current WG charter
   http://www.ie= tf.org/html.charters/netconf-charter.html

Although the da= te on the charter page states that it was last updated
on 2008-01-09, th= at update was only to list us as new WG chairs and
our new Security Adv= isor. The base text is from a while ago, and
in the meanwhile, some docu= ments have completed, and some of the
text that has past tense or (futur= e tense) is now better read as
being the present. We also adopted a set = of WG documents which
were based on earlier individual I-Ds, and so we h= ave completed
posting of revision 00 documents for our chartered WG work items.

We have clarified the text, cleaned it up a bit and we have = marked
a few items as DONE. We made no substantial change (of course, <= br>because that would require WG consensus forming first).

ADs, can = you please approve that this cleanup charter text be posted
as our curr= ent WG charter page. Will you forward it to iesg-secretary,
or do we ne= ed to do so seperately (assuming you will approve)?

Bert and Mehmet<= br>

Attached is the new charter and a rfcdiff of old and new charter= .
And here is the main body of the cleaned-up charter text:

Confi= guration of networks of devices has become a critical requirement
for o= perators in today's highly interoperable networks. Operators from
large= to small have developed their own mechanisms or used vendor
specific m= echanisms to transfer configuration data to and from a
device, and for = examining device state information which may impact
the configuration. Each of these mechanisms may be different in
various as= pects, such as session establishment, user authentication,
configuratio= n data exchange, and error responses.

The NETCONF Working Group is = chartered to produce a protocol suitable
for network configuration, wit= h the following characteristics:

- Provides retrieval mechanisms wh= ich can differentiate between
  configuration data and non-configur= ation data
- Is extensible enough so that vendors will provide access t= o all
  configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and
  form= atting-related changes between releases)
- Uses a textual data represen= tation, that can be easily manipulated
  using non-specialized text= manipulation tools.
- Supports integration with existing user authenti= cation methods
- Supports integration with existing configuration database systems
- Supports network wide configuration t= ransactions (with features such
  as locking and rollback capabilit= y)
- Is as transport-independent as possible
- Provides support for= asynchronous notifications.

The NETCONF protocol is using XML for = data encoding purposes, because
XML is a widely deployed standard which= is supported by a large number
of applications.

The NETCONF pr= otocol should be independent of the data definition
language and data m= odels used to describe configuration and state
data.

However, t= he authorization model used in the protocol is dependent on
the data mo= del. Although these issues must be fully addressed to
develop standard = data models, only a small part of this work will be
initially addressed= . This group will specify requirements for standard
data models in orde= r to fully support the NETCONF protocol, such as:

- identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data
= - XML namespace conventions
- XML usage guidelines

The initial = work started in 2003 and has already been completed and was
restricted = to following items:

  a) NETCONF Protocol Specification, which= defines the operational model,
     protocol operat= ions, transaction model, data model requirements,
   &nbs= p; security requirements, and transport layer requirements.
  b) N= ETCONF over SSH Specification: Implementation Mandatory,
  c) NETC= ONF over BEEP Specification: Implementation Optional,
  d) NETCONF = over SOAP Specification: Implementation Optional.

  These docum= ents define how the NETCONF protocol is used with each
  transport= protocol selected by the working group, and how it meets
  the security and transport layer requirements of the NETCONF Protocol
=   Specification.

  e) NETCONF Notification Specification,= which defines mechanisms that
     provide an async= hronous message notification delivery service for
   &nbs= p; the NETCONF protocol.  NETCONF Notification is an optional
 = ;    capability built on top of the base NETCONF definition = and
     provides the capabilities and operations ne= cessary to support
     this service.

In the = current phase of the incremental development of NETCONF the
workgroup w= ill focus on following items:

1. Fine-grain locking: The base NETCO= NF protocol only provides a lock
   for the entire configurati= on datastore, which is not deemed to meet
   important operati= onal and security requirements. The NETCONF working
   group will produce a standards-track RFC specifying a mechanism for
&nb= sp;  fine-grain locking of the NETCONF configuration datastore.
2. NETCONF monitoring: It is considered best practice for IETF working   groups to include management of their protocols within the sc= ope of
   the solution they are providing. The NETCONF working= group will
   produce a standards-track RFC with mechanisms a= llowing NETCONF
   itself to be used to monitor some aspects o= f NETCONF operation.

3. Schema advertisement: Currently the NETCONF= protocol is able to
   advertise which protocol features are = supported on a particular
   netconf-capable device. However, = there is currently no way to discover
   which XML Schema are = supported on the device. The NETCONF working
   group will pro= duce a standards-track RFC with mechanisms making this
   discovery possible (this item may be merged with "NET= CONF monitoring"
   into a single document).

4. NETCON= F over TLS: Based on implementation experience there is a
   n= eed for a standards track document to define NETCONF over TLS as an
&nbs= p;  optional transport for the NETCONF protocol.

The following = items have been identified as important but are currently
not considered= in scope for re-chartering and may be candidates for work
when there is= community consensus to take them on:

- General improvements to the= base protocol
- Access Control requirements
- NETCONF access to SM= I-based MIB data


Goals and Milestones:
Done   =   Working Group formed
Done      Submit initi= al Netconf Protocol draft
Done      Submit initial = Netconf over (transport-TBD) draft
Done      Begin Working Group Last Call for the Netconf Protocol draft
Done = ;     Begin Working Group Last Call for the Netconf over (tr= ansport-TBD)
          draf= t
Done      Submit final version of the Netconf Pro= tocol draft to the IESG
Done      Submit final vers= ion of the Netconf over SOAP draft to the IESG
Done    &= nbsp; Submit final version of the Netconf over BEEP draft to the IESG
D= one      Submit final version of the Netconf over SSH d= raft to the IESG
Done      Update charter
Done&= nbsp;     Submit first version of NETCONF Notifications docu= ment
Done      Begin WGLC of NETCONF Notifications = document
Done      Submit final version of NETCONF = Notifications document to IESG
          for conside= ration as Proposed Standard
Done      -00 draft for= fine Grain Locking
Done      -00 draft for NETCONF= over TLS
Done      -00 draft for NETCONF Monitorin= g
Feb 2008  -00 draft for Schema Advertisement
Mar 2008  = Early Review of client authentication approach (for NETCONF over
 &= nbsp;        TLS) with the security comm= unity at IETF 71
Aug 2008  WG Last Call on NETCONF Monitoring afte= r IETF72
Aug 2008  WG Last Call on Schema Advertisement after IETF= 72
Aug 2008  WG Last Call on Fine Grain Locking after IETF72
A= ug 2008  WG Last Call on NETCONF over TLS after IETF72
Aug 2008&nb= sp; Send four documents to the IESG for consideration as proposed
 =          standards



=0A=0A=0A
Jetzt Mai= ls schnell in einem Vorschaufenster =C3=BCberfliegen. Dies und viel mehr bi= etet das =0Aneue Yahoo! Mail. =0A --0-1916029676-1201180727=:20935-- --0-859375073-1201180727=:20935 Content-Type: X-unknown/exe; name="=?utf-8?q?WGCharter-20080124.txt?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?q?WGCharter-20080124.txt?=" 77u/TmV0d29yayBDb25maWd1cmF0aW9uIChuZXRjb25mKSBDaGFydGVyDQoN Cg0KDQoNCk5ldHdvcmsgQ29uZmlndXJhdGlvbiAobmV0Y29uZikNCg0KDQpJ biBhZGRpdGlvbiB0byB0aGlzIG9mZmljaWFsIGNoYXJ0ZXIgbWFpbnRhaW5l ZCBieSB0aGUgSUVURiBTZWNyZXRhcmlhdCwgdGhlcmUgDQppcyBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIGFib3V0IHRoaXMgd29ya2luZyBncm91cCBvbiB0 aGUgV2ViIGF0Og0KDQogICAgICAgQWRkaXRpb25hbCBORVRDT05GIFdlYiBQ YWdlDQoNCiANCkxhc3QgTW9kaWZpZWQ6IDIwMDgtMDEtMjQgDQpBZGRpdGlv bmFsIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy93Zy9uZXRjb25mIA0KDQpDaGFpcihzKToNCkJlcnQgV2lqbmVuIDxiZXJ0 aWV0ZkBid2lqbmVuLm5ldD4gDQoNCg0KTWVobWV0IEVyc3VlIDxtZWhtZXQu ZXJzdWVAbnNuLmNvbT4gDQoNCg0KT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVu dCBBcmVhIERpcmVjdG9yKHMpOg0KRGFuIFJvbWFzY2FudSA8ZHJvbWFzY2FA YXZheWEuY29tPiANCg0KUm9uYWxkIEJvbmljYSA8cmJvbmljYUBqdW5pcGVy Lm5ldD4gDQoNCk9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgQXJlYSBBZHZp c29yOg0KRGFuIFJvbWFzY2FudSA8ZHJvbWFzY2FAYXZheWEuY29tPiANCg0K VGVjaG5pY2FsIEFkdmlzb3Iocyk6DQpDaGFybGllIEthdWZtYW4gPGNoYXJs aWVrQG1pY3Jvc29mdC5jb20+IA0KDQpNYWlsaW5nIExpc3RzOg0KR2VuZXJh bCBEaXNjdXNzaW9uOiBuZXRjb25mQG9wcy5pZXRmLm9yZw0KVG8gU3Vic2Ny aWJlOiBuZXRjb25mLXJlcXVlc3RAb3BzLmlldGYub3JnDQpJbiBCb2R5OiBp biBtc2cgYm9keTogc3Vic2NyaWJlDQpBcmNoaXZlOiBodHRwczovL29wcy5p ZXRmLm9yZy9saXN0cy9uZXRjb25mDQoNCkRlc2NyaXB0aW9uIG9mIFdvcmtp bmcgR3JvdXA6DQpDaGFybGllIEthdWZtYW4gaXMgVGVjaG5pY2FsIEFkdmlz b3IgZm9yIFNlY3VyaXR5IE1hdHRlcnMgDQoNCkNvbmZpZ3VyYXRpb24gb2Yg bmV0d29ya3Mgb2YgZGV2aWNlcyBoYXMgYmVjb21lIGEgY3JpdGljYWwgcmVx dWlyZW1lbnQgDQpmb3Igb3BlcmF0b3JzIGluIHRvZGF5J3MgaGlnaGx5IGlu dGVyb3BlcmFibGUgbmV0d29ya3MuIE9wZXJhdG9ycyBmcm9tIA0KbGFyZ2Ug dG8gc21hbGwgaGF2ZSBkZXZlbG9wZWQgdGhlaXIgb3duIG1lY2hhbmlzbXMg b3IgdXNlZCB2ZW5kb3IgDQpzcGVjaWZpYyBtZWNoYW5pc21zIHRvIHRyYW5z ZmVyIGNvbmZpZ3VyYXRpb24gZGF0YSB0byBhbmQgZnJvbSBhIA0KZGV2aWNl LCBhbmQgZm9yIGV4YW1pbmluZyBkZXZpY2Ugc3RhdGUgaW5mb3JtYXRpb24g d2hpY2ggbWF5IGltcGFjdCANCnRoZSBjb25maWd1cmF0aW9uLiBFYWNoIG9m IHRoZXNlIG1lY2hhbmlzbXMgbWF5IGJlIGRpZmZlcmVudCBpbiANCnZhcmlv dXMgYXNwZWN0cywgc3VjaCBhcyBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIHVz ZXIgYXV0aGVudGljYXRpb24sIA0KY29uZmlndXJhdGlvbiBkYXRhIGV4Y2hh bmdlLCBhbmQgZXJyb3IgcmVzcG9uc2VzLiANCg0KVGhlIE5FVENPTkYgV29y a2luZyBHcm91cCBpcyBjaGFydGVyZWQgdG8gcHJvZHVjZSBhIHByb3RvY29s IHN1aXRhYmxlIA0KZm9yIG5ldHdvcmsgY29uZmlndXJhdGlvbiwgd2l0aCB0 aGUgZm9sbG93aW5nIGNoYXJhY3RlcmlzdGljczogDQoNCi0gUHJvdmlkZXMg cmV0cmlldmFsIG1lY2hhbmlzbXMgd2hpY2ggY2FuIGRpZmZlcmVudGlhdGUg YmV0d2Vlbg0KICBjb25maWd1cmF0aW9uIGRhdGEgYW5kIG5vbi1jb25maWd1 cmF0aW9uIGRhdGEgDQotIElzIGV4dGVuc2libGUgZW5vdWdoIHNvIHRoYXQg dmVuZG9ycyB3aWxsIHByb3ZpZGUgYWNjZXNzIHRvIGFsbA0KICBjb25maWd1 cmF0aW9uIGRhdGEgb24gdGhlIGRldmljZSB1c2luZyBhIHNpbmdsZSBwcm90 b2NvbCANCi0gSGFzIGEgcHJvZ3JhbW1hdGljIGludGVyZmFjZSAoYXZvaWRz IHNjcmVlbiBzY3JhcGluZyBhbmQNCiAgZm9ybWF0dGluZy1yZWxhdGVkIGNo YW5nZXMgYmV0d2VlbiByZWxlYXNlcykgDQotIFVzZXMgYSB0ZXh0dWFsIGRh dGEgcmVwcmVzZW50YXRpb24sIHRoYXQgY2FuIGJlIGVhc2lseSBtYW5pcHVs YXRlZA0KICB1c2luZyBub24tc3BlY2lhbGl6ZWQgdGV4dCBtYW5pcHVsYXRp b24gdG9vbHMuIA0KLSBTdXBwb3J0cyBpbnRlZ3JhdGlvbiB3aXRoIGV4aXN0 aW5nIHVzZXIgYXV0aGVudGljYXRpb24gbWV0aG9kcyANCi0gU3VwcG9ydHMg aW50ZWdyYXRpb24gd2l0aCBleGlzdGluZyBjb25maWd1cmF0aW9uIGRhdGFi YXNlIHN5c3RlbXMgDQotIFN1cHBvcnRzIG5ldHdvcmsgd2lkZSBjb25maWd1 cmF0aW9uIHRyYW5zYWN0aW9ucyAod2l0aCBmZWF0dXJlcyBzdWNoDQogIGFz IGxvY2tpbmcgYW5kIHJvbGxiYWNrIGNhcGFiaWxpdHkpIA0KLSBJcyBhcyB0 cmFuc3BvcnQtaW5kZXBlbmRlbnQgYXMgcG9zc2libGUgDQotIFByb3ZpZGVz IHN1cHBvcnQgZm9yIGFzeW5jaHJvbm91cyBub3RpZmljYXRpb25zLiANCg0K VGhlIE5FVENPTkYgcHJvdG9jb2wgaXMgdXNpbmcgWE1MIGZvciBkYXRhIGVu Y29kaW5nIHB1cnBvc2VzLCBiZWNhdXNlIA0KWE1MIGlzIGEgd2lkZWx5IGRl cGxveWVkIHN0YW5kYXJkIHdoaWNoIGlzIHN1cHBvcnRlZCBieSBhIGxhcmdl IG51bWJlciANCm9mIGFwcGxpY2F0aW9ucy4gDQoNClRoZSBORVRDT05GIHBy b3RvY29sIHNob3VsZCBiZSBpbmRlcGVuZGVudCBvZiB0aGUgZGF0YSBkZWZp bml0aW9uIA0KbGFuZ3VhZ2UgYW5kIGRhdGEgbW9kZWxzIHVzZWQgdG8gZGVz Y3JpYmUgY29uZmlndXJhdGlvbiBhbmQgc3RhdGUgDQpkYXRhLiANCg0KSG93 ZXZlciwgdGhlIGF1dGhvcml6YXRpb24gbW9kZWwgdXNlZCBpbiB0aGUgcHJv dG9jb2wgaXMgZGVwZW5kZW50IG9uIA0KdGhlIGRhdGEgbW9kZWwuIEFsdGhv dWdoIHRoZXNlIGlzc3VlcyBtdXN0IGJlIGZ1bGx5IGFkZHJlc3NlZCB0byAN CmRldmVsb3Agc3RhbmRhcmQgZGF0YSBtb2RlbHMsIG9ubHkgYSBzbWFsbCBw YXJ0IG9mIHRoaXMgd29yayB3aWxsIGJlIA0KaW5pdGlhbGx5IGFkZHJlc3Nl ZC4gVGhpcyBncm91cCB3aWxsIHNwZWNpZnkgcmVxdWlyZW1lbnRzIGZvciBz dGFuZGFyZCANCmRhdGEgbW9kZWxzIGluIG9yZGVyIHRvIGZ1bGx5IHN1cHBv cnQgdGhlIE5FVENPTkYgcHJvdG9jb2wsIHN1Y2ggYXM6IA0KDQotIGlkZW50 aWZpY2F0aW9uIG9mIHByaW5jaXBhbHMsIHN1Y2ggYXMgdXNlciBuYW1lcyBv ciBkaXN0aW5ndWlzaGVkIG5hbWVzIA0KLSBtZWNoYW5pc20gdG8gZGlzdGlu Z3Vpc2ggY29uZmlndXJhdGlvbiBmcm9tIG5vbi1jb25maWd1cmF0aW9uIGRh dGEgDQotIFhNTCBuYW1lc3BhY2UgY29udmVudGlvbnMgDQotIFhNTCB1c2Fn ZSBndWlkZWxpbmVzIA0KDQpUaGUgaW5pdGlhbCB3b3JrIHN0YXJ0ZWQgaW4g MjAwMyBhbmQgaGFzIGFscmVhZHkgYmVlbiBjb21wbGV0ZWQgYW5kIHdhcyAN CnJlc3RyaWN0ZWQgdG8gZm9sbG93aW5nIGl0ZW1zOiANCg0KICBhKSBORVRD T05GIFByb3RvY29sIFNwZWNpZmljYXRpb24sIHdoaWNoIGRlZmluZXMgdGhl IG9wZXJhdGlvbmFsIG1vZGVsLA0KICAgICBwcm90b2NvbCBvcGVyYXRpb25z LCB0cmFuc2FjdGlvbiBtb2RlbCwgZGF0YSBtb2RlbCByZXF1aXJlbWVudHMs DQogICAgIHNlY3VyaXR5IHJlcXVpcmVtZW50cywgYW5kIHRyYW5zcG9ydCBs YXllciByZXF1aXJlbWVudHMuIA0KICBiKSBORVRDT05GIG92ZXIgU1NIIFNw ZWNpZmljYXRpb246IEltcGxlbWVudGF0aW9uIE1hbmRhdG9yeSwgDQogIGMp IE5FVENPTkYgb3ZlciBCRUVQIFNwZWNpZmljYXRpb246IEltcGxlbWVudGF0 aW9uIE9wdGlvbmFsLA0KICBkKSBORVRDT05GIG92ZXIgU09BUCBTcGVjaWZp Y2F0aW9uOiBJbXBsZW1lbnRhdGlvbiBPcHRpb25hbC4NCg0KICBUaGVzZSBk b2N1bWVudHMgZGVmaW5lIGhvdyB0aGUgTkVUQ09ORiBwcm90b2NvbCBpcyB1 c2VkIHdpdGggZWFjaCANCiAgdHJhbnNwb3J0IHByb3RvY29sIHNlbGVjdGVk IGJ5IHRoZSB3b3JraW5nIGdyb3VwLCBhbmQgaG93IGl0IG1lZXRzIA0KICB0 aGUgc2VjdXJpdHkgYW5kIHRyYW5zcG9ydCBsYXllciByZXF1aXJlbWVudHMg b2YgdGhlIE5FVENPTkYgUHJvdG9jb2wgDQogIFNwZWNpZmljYXRpb24uIA0K DQogIGUpIE5FVENPTkYgTm90aWZpY2F0aW9uIFNwZWNpZmljYXRpb24sIHdo aWNoIGRlZmluZXMgbWVjaGFuaXNtcyB0aGF0DQogICAgIHByb3ZpZGUgYW4g YXN5bmNocm9ub3VzIG1lc3NhZ2Ugbm90aWZpY2F0aW9uIGRlbGl2ZXJ5IHNl cnZpY2UgZm9yDQogICAgIHRoZSBORVRDT05GIHByb3RvY29sLiAgTkVUQ09O RiBOb3RpZmljYXRpb24gaXMgYW4gb3B0aW9uYWwNCiAgICAgY2FwYWJpbGl0 eSBidWlsdCBvbiB0b3Agb2YgdGhlIGJhc2UgTkVUQ09ORiBkZWZpbml0aW9u IGFuZA0KICAgICBwcm92aWRlcyB0aGUgY2FwYWJpbGl0aWVzIGFuZCBvcGVy YXRpb25zIG5lY2Vzc2FyeSB0byBzdXBwb3J0DQogICAgIHRoaXMgc2Vydmlj ZS4NCg0KSW4gdGhlIGN1cnJlbnQgcGhhc2Ugb2YgdGhlIGluY3JlbWVudGFs IGRldmVsb3BtZW50IG9mIE5FVENPTkYgdGhlIA0Kd29ya2dyb3VwIHdpbGwg Zm9jdXMgb24gZm9sbG93aW5nIGl0ZW1zOiANCg0KMS4gRmluZS1ncmFpbiBs b2NraW5nOiBUaGUgYmFzZSBORVRDT05GIHByb3RvY29sIG9ubHkgcHJvdmlk ZXMgYSBsb2NrDQogICBmb3IgdGhlIGVudGlyZSBjb25maWd1cmF0aW9uIGRh dGFzdG9yZSwgd2hpY2ggaXMgbm90IGRlZW1lZCB0byBtZWV0DQogICBpbXBv cnRhbnQgb3BlcmF0aW9uYWwgYW5kIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4g VGhlIE5FVENPTkYgd29ya2luZw0KICAgZ3JvdXAgd2lsbCBwcm9kdWNlIGEg c3RhbmRhcmRzLXRyYWNrIFJGQyBzcGVjaWZ5aW5nIGEgbWVjaGFuaXNtIGZv cg0KICAgZmluZS1ncmFpbiBsb2NraW5nIG9mIHRoZSBORVRDT05GIGNvbmZp Z3VyYXRpb24gZGF0YXN0b3JlLiANCg0KMi4gTkVUQ09ORiBtb25pdG9yaW5n OiBJdCBpcyBjb25zaWRlcmVkIGJlc3QgcHJhY3RpY2UgZm9yIElFVEYgd29y a2luZw0KICAgZ3JvdXBzIHRvIGluY2x1ZGUgbWFuYWdlbWVudCBvZiB0aGVp ciBwcm90b2NvbHMgd2l0aGluIHRoZSBzY29wZSBvZg0KICAgdGhlIHNvbHV0 aW9uIHRoZXkgYXJlIHByb3ZpZGluZy4gVGhlIE5FVENPTkYgd29ya2luZyBn cm91cCB3aWxsDQogICBwcm9kdWNlIGEgc3RhbmRhcmRzLXRyYWNrIFJGQyB3 aXRoIG1lY2hhbmlzbXMgYWxsb3dpbmcgTkVUQ09ORg0KICAgaXRzZWxmIHRv IGJlIHVzZWQgdG8gbW9uaXRvciBzb21lIGFzcGVjdHMgb2YgTkVUQ09ORiBv cGVyYXRpb24uIA0KDQozLiBTY2hlbWEgYWR2ZXJ0aXNlbWVudDogQ3VycmVu dGx5IHRoZSBORVRDT05GIHByb3RvY29sIGlzIGFibGUgdG8NCiAgIGFkdmVy dGlzZSB3aGljaCBwcm90b2NvbCBmZWF0dXJlcyBhcmUgc3VwcG9ydGVkIG9u IGEgcGFydGljdWxhcg0KICAgbmV0Y29uZi1jYXBhYmxlIGRldmljZS4gSG93 ZXZlciwgdGhlcmUgaXMgY3VycmVudGx5IG5vIHdheSB0byBkaXNjb3Zlcg0K ICAgd2hpY2ggWE1MIFNjaGVtYSBhcmUgc3VwcG9ydGVkIG9uIHRoZSBkZXZp Y2UuIFRoZSBORVRDT05GIHdvcmtpbmcNCiAgIGdyb3VwIHdpbGwgcHJvZHVj ZSBhIHN0YW5kYXJkcy10cmFjayBSRkMgd2l0aCBtZWNoYW5pc21zIG1ha2lu ZyB0aGlzDQogICBkaXNjb3ZlcnkgcG9zc2libGUgKHRoaXMgaXRlbSBtYXkg YmUgbWVyZ2VkIHdpdGggIk5FVENPTkYgbW9uaXRvcmluZyINCiAgIGludG8g YSBzaW5nbGUgZG9jdW1lbnQpLiANCg0KNC4gTkVUQ09ORiBvdmVyIFRMUzog QmFzZWQgb24gaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSB0aGVyZSBpcyBh DQogICBuZWVkIGZvciBhIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudCB0byBk ZWZpbmUgTkVUQ09ORiBvdmVyIFRMUyBhcyBhbg0KICAgb3B0aW9uYWwgdHJh bnNwb3J0IGZvciB0aGUgTkVUQ09ORiBwcm90b2NvbC4NCg0KVGhlIGZvbGxv d2luZyBpdGVtcyBoYXZlIGJlZW4gaWRlbnRpZmllZCBhcyBpbXBvcnRhbnQg YnV0IGFyZSBjdXJyZW50bHkNCm5vdCBjb25zaWRlcmVkIGluIHNjb3BlIGZv ciByZS1jaGFydGVyaW5nIGFuZCBtYXkgYmUgY2FuZGlkYXRlcyBmb3Igd29y aw0Kd2hlbiB0aGVyZSBpcyBjb21tdW5pdHkgY29uc2Vuc3VzIHRvIHRha2Ug dGhlbSBvbjogDQoNCi0gR2VuZXJhbCBpbXByb3ZlbWVudHMgdG8gdGhlIGJh c2UgcHJvdG9jb2wgDQotIEFjY2VzcyBDb250cm9sIHJlcXVpcmVtZW50cyAN Ci0gTkVUQ09ORiBhY2Nlc3MgdG8gU01JLWJhc2VkIE1JQiBkYXRhDQoNCg0K R29hbHMgYW5kIE1pbGVzdG9uZXM6DQpEb25lCSAgV29ya2luZyBHcm91cCBm b3JtZWQgDQpEb25lCSAgU3VibWl0IGluaXRpYWwgTmV0Y29uZiBQcm90b2Nv bCBkcmFmdCANCkRvbmUJICBTdWJtaXQgaW5pdGlhbCBOZXRjb25mIG92ZXIg KHRyYW5zcG9ydC1UQkQpIGRyYWZ0IA0KRG9uZQkgIEJlZ2luIFdvcmtpbmcg R3JvdXAgTGFzdCBDYWxsIGZvciB0aGUgTmV0Y29uZiBQcm90b2NvbCBkcmFm dCANCkRvbmUJICBCZWdpbiBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3Ig dGhlIE5ldGNvbmYgb3ZlciAodHJhbnNwb3J0LVRCRCkNCiAgICAgICAgICBk cmFmdCANCkRvbmUJICBTdWJtaXQgZmluYWwgdmVyc2lvbiBvZiB0aGUgTmV0 Y29uZiBQcm90b2NvbCBkcmFmdCB0byB0aGUgSUVTRyANCkRvbmUJICBTdWJt aXQgZmluYWwgdmVyc2lvbiBvZiB0aGUgTmV0Y29uZiBvdmVyIFNPQVAgZHJh ZnQgdG8gdGhlIElFU0cgDQpEb25lCSAgU3VibWl0IGZpbmFsIHZlcnNpb24g b2YgdGhlIE5ldGNvbmYgb3ZlciBCRUVQIGRyYWZ0IHRvIHRoZSBJRVNHIA0K RG9uZQkgIFN1Ym1pdCBmaW5hbCB2ZXJzaW9uIG9mIHRoZSBOZXRjb25mIG92 ZXIgU1NIIGRyYWZ0IHRvIHRoZSBJRVNHIA0KRG9uZQkgIFVwZGF0ZSBjaGFy dGVyIA0KRG9uZQkgIFN1Ym1pdCBmaXJzdCB2ZXJzaW9uIG9mIE5FVENPTkYg Tm90aWZpY2F0aW9ucyBkb2N1bWVudCANCkRvbmUJICBCZWdpbiBXR0xDIG9m IE5FVENPTkYgTm90aWZpY2F0aW9ucyBkb2N1bWVudCANCkRvbmUJICBTdWJt aXQgZmluYWwgdmVyc2lvbiBvZiBORVRDT05GIE5vdGlmaWNhdGlvbnMgZG9j dW1lbnQgdG8gSUVTRw0KICAgICAgICAgIGZvciBjb25zaWRlcmF0aW9uIGFz IFByb3Bvc2VkIFN0YW5kYXJkIA0KRG9uZQkgIC0wMCBkcmFmdCBmb3IgZmlu ZSBHcmFpbiBMb2NraW5nIA0KRG9uZQkgIC0wMCBkcmFmdCBmb3IgTkVUQ09O RiBvdmVyIFRMUyANCkRvbmUJICAtMDAgZHJhZnQgZm9yIE5FVENPTkYgTW9u aXRvcmluZyANCkZlYiAyMDA4ICAtMDAgZHJhZnQgZm9yIFNjaGVtYSBBZHZl cnRpc2VtZW50IA0KTWFyIDIwMDggIEVhcmx5IFJldmlldyBvZiBjbGllbnQg YXV0aGVudGljYXRpb24gYXBwcm9hY2ggKGZvciBORVRDT05GIG92ZXINCiAg ICAgICAgICBUTFMpIHdpdGggdGhlIHNlY3VyaXR5IGNvbW11bml0eSBhdCBJ RVRGIDcxIA0KQXVnIDIwMDggIFdHIExhc3QgQ2FsbCBvbiBORVRDT05GIE1v bml0b3JpbmcgYWZ0ZXIgSUVURjcyIA0KQXVnIDIwMDggIFdHIExhc3QgQ2Fs bCBvbiBTY2hlbWEgQWR2ZXJ0aXNlbWVudCBhZnRlciBJRVRGNzIgDQpBdWcg MjAwOCAgV0cgTGFzdCBDYWxsIG9uIEZpbmUgR3JhaW4gTG9ja2luZyBhZnRl ciBJRVRGNzIgDQpBdWcgMjAwOCAgV0cgTGFzdCBDYWxsIG9uIE5FVENPTkYg b3ZlciBUTFMgYWZ0ZXIgSUVURjcyIA0KQXVnIDIwMDggIFNlbmQgZm91ciBk b2N1bWVudHMgdG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgcHJv cG9zZWQNCiAgICAgICAgICBzdGFuZGFyZHMNCg0KSW50ZXJuZXQtRHJhZnRz Og0KTkVUQ09ORiBFdmVudCBOb3RpZmljYXRpb25zICg4MDc1OSBieXRlcykN Ck5FVENPTkYgb3ZlciBUTFMgKDE4Mjg3IGJ5dGVzKQ0KUGFydGlhbCBMb2Nr IFJQQyBmb3IgTkVUQ09ORiAoMjA4NzYgYnl0ZXMpDQpORVRDT05GIE1vbml0 b3JpbmcgU2NoZW1hICgyMDc4NSBieXRlcykNCg0KUmVxdWVzdCBGb3IgQ29t bWVudHM6DQpORVRDT05GIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKFJGQyA0 NzQxKSAoMTczOTE0IGJ5dGVzKSANClVzaW5nIHRoZSBORVRDT05GIENvbmZp Z3VyYXRpb24gUHJvdG9jb2wgb3ZlciBTZWN1cmUgU2hlbGwgKFNTSCkgKFJG QyA0NzQyKSANCigxNzgwNyBieXRlcykgDQpVc2luZyB0aGUgTkVUQ09ORiBQ cm90b2NvbCBvdmVyIEJsb2NrcyBFeHRlbnNpYmxlIEV4Y2hhbmdlIFByb3Rv Y29sIChCRUVQKSAoUkZDIA0KNDc0NCkgKDE5Mjg3IGJ5dGVzKSANClVzaW5n IHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYp IE92ZXIgdGhlIFNpbXBsZSBPYmplY3QgQWNjZXNzIA0KUHJvdG9jb2wgKFNP QVApIChSRkMgNDc0MykgKDM5NzM0IGJ5dGVzKSANCg0KDQpJRVRGIFNlY3Jl dGFyaWF0IC0gUGxlYXNlIHNlbmQgcXVlc3Rpb25zLCBjb21tZW50cywgYW5k L29yIHN1Z2dlc3Rpb25zIHRvIA0KaWV0Zi13ZWJAaWV0Zi5vcmcuIA0KIFJl dHVybiB0byB3b3JraW5nIGdyb3VwIGRpcmVjdG9yeS4gDQogIFJldHVybiB0 byBJRVRGIGhvbWUgcGFnZS4g --0-859375073-1201180727=:20935 Content-Type: text/html; name="=?utf-8?q?Diff=20WGCharter-20080109-WGCharter-20080124.htm?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?q?Diff=20WGCharter-20080109-WGCharter-20080124.htm?=" CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4w IFRyYW5zaXRpb25hbC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRt bDEvRFREL3hodG1sMS10cmFuc2l0aW9uYWwuZHRkIj4gCjwhLS0gR2VuZXJh dGVkIGJ5IHJmY2RpZmYgMS4zNDogcmZjZGlmZiAgLS0+IAo8IS0tIDwhRE9D VFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0LjAxIFRyYW5z aXRpb25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IGNhYmVybmV0LnZl cmtzdGFkLm5ldCAyLjYuOC0yLTY4NiAjMSBUdWUgQXVnIDE2IDEzOjIyOjQ4 IFVUQyAyMDA1IGk2ODYgR05VL0xpbnV4IC0tPiAKPCEtLSBVc2luZyBhd2s6 IC91c3IvYmluL2dhd2s6IEdOVSBBd2sgMy4xLjUgLS0+IAo8IS0tIFVzaW5n IGRpZmY6IC91c3IvYmluL2RpZmY6IGRpZmYgKEdOVSBkaWZmdXRpbHMpIDIu OC4xIC0tPiAKPCEtLSBVc2luZyB3ZGlmZjogL3Vzci9iaW4vd2RpZmY6IEdO VSB3ZGlmZiAwLjUgLS0+IAo8aHRtbD4gCjxoZWFkPiAKICA8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD1pc28tODg1OS0xIiAvPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250 ZW50LVN0eWxlLVR5cGUiIGNvbnRlbnQ9InRleHQvY3NzIiAvPiAKICA8dGl0 bGU+RGlmZjogV0dDaGFydGVyLTIwMDgwMTA5LnR4dCAtIFdHQ2hhcnRlci0y MDA4MDEyNC50eHQ8L3RpdGxlPiAKICA8c3R5bGUgdHlwZT0idGV4dC9jc3Mi PiAKICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4tcmlnaHQ6 IGF1dG87IH0gCiAgICB0ciAgICAgIHsgfSAKICAgIHRkICAgICAgeyB3aGl0 ZS1zcGFjZTogcHJlOyBmb250LWZhbWlseTogbW9ub3NwYWNlOyB2ZXJ0aWNh bC1hbGlnbjogdG9wOyBmb250LXNpemU6IDAuODZlbTt9IAogICAgdGggICAg ICB7IGZvbnQtc2l6ZTogMC44NmVtOyB9IAogICAgLnNtYWxsICB7IGZvbnQt c2l6ZTogMC42ZW07IGZvbnQtc3R5bGU6IGl0YWxpYzsgZm9udC1mYW1pbHk6 IFZlcmRhbmEsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgfSAKICAgIC5sZWZ0 ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLnJpZ2h0ICB7 IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IH0gCiAgICAuZGlmZiAgIHsgYmFj a2dyb3VuZC1jb2xvcjogI0NDRjsgfSAKICAgIC5sYmxvY2sgeyBiYWNrZ3Jv dW5kLWNvbG9yOiAjQkZCOyB9IAogICAgLnJibG9jayB7IGJhY2tncm91bmQt Y29sb3I6ICNGRjg7IH0gCiAgICAuaW5zZXJ0IHsgYmFja2dyb3VuZC1jb2xv cjogIzhGRjsgfSAKICAgIC5kZWxldGUgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj QUNGOyB9IAogICAgLnZvaWQgICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkI7 IH0gCiAgICAuY29udCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAK ICAgIC5saW5lYnIgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9IAogICAg LmxpbmVubyB7IGNvbG9yOiByZWQ7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7 IGZvbnQtc2l6ZTogMC43ZW07IHRleHQtYWxpZ246IHJpZ2h0OyBwYWRkaW5n OiAwIDJweDsgfSAKICAgIC5lbGlwc2lzeyBiYWNrZ3JvdW5kLWNvbG9yOiAj QUFBOyB9IAogICAgLmxlZnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj REREOyB9IAogICAgLnJpZ2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjog I0VFRTsgfSAKICAgIC5sYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjOUQ5OyB9IAogICAgLnJibG9jayAuY29udCB7IGJhY2tncm91bmQtY29s b3I6ICNERDY7IH0gCiAgICAuaW5zZXJ0IC5jb250IHsgYmFja2dyb3VuZC1j b2xvcjogIzBERDsgfSAKICAgIC5kZWxldGUgLmNvbnQgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjOEFEOyB9IAogICAgLnN0YXRzLCAuc3RhdHMgdGQsIC5zdGF0 cyB0aCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IHBhZGRpbmc6IDJweCAw OyB9IAogIDwvc3R5bGU+IAo8L2hlYWQ+IAo8Ym9keSA+IAogIDx0YWJsZSBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+IAog IDx0ciBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD4mbmJzcDtXR0No YXJ0ZXItMjAwODAxMDkudHh0Jm5ic3A7PC90aD48dGg+IDwvdGg+PHRoPiZu YnNwO1dHQ2hhcnRlci0yMDA4MDEyNC50eHQmbmJzcDs8L3RoPjx0aD48L3Ro PjwvdHI+IAogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAxIiAvPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+TmV0d29yayBDb25maWd1 cmF0aW9uIChuZXRjb25mKSBDaGFydGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bhbj5OZXR3 b3JrIENvbmZpZ3VyYXRpb24gKG5ldGNvbmYpIENoYXJ0ZXI8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPk5ldHdvcmsgQ29uZmlndXJhdGlvbiAo bmV0Y29uZik8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5OZXR3 b3JrIENvbmZpZ3VyYXRpb24gKG5ldGNvbmYpPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij5JbiBhZGRpdGlvbiB0byB0aGlzIG9mZmljaWFsIGNo YXJ0ZXIgbWFpbnRhaW5lZCBieSB0aGUgSUVURiBTZWNyZXRhcmlhdCwgdGhl cmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbiBhZGRpdGlv biB0byB0aGlzIG9mZmljaWFsIGNoYXJ0ZXIgbWFpbnRhaW5lZCBieSB0aGUg SUVURiBTZWNyZXRhcmlhdCwgdGhlcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ aXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhYm91dCB0aGlzIHdvcmtpbmcg Z3JvdXAgb24gdGhlIFdlYiBhdDo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij5pcyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRoaXMg d29ya2luZyBncm91cCBvbiB0aGUgV2ViIGF0OjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgIEFkZGl0aW9uYWwgTkVUQ09ORiBXZWIg UGFnZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBB ZGRpdGlvbmFsIE5FVENPTkYgV2ViIFBhZ2U8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMiIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPkxhc3QgTW9kaWZpZWQ6IDIwMDgtMDEtPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+MDk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPkxhc3QgTW9kaWZpZWQ6IDIwMDgtMDEtPHNwYW4gY2xh c3M9Imluc2VydCI+MjQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFk ZGl0aW9uYWwgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnL3dnL25ldGNvbmY8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij5BZGRpdGlvbmFsIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy93Zy9uZXRjb25mPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij5DaGFpcihzKTo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij5DaGFpcihzKTo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QmVydCBX aWpuZW4gJmx0O2JlcnRpZXRmQGJ3aWpuZW4ubmV0Jmd0OzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkJlcnQgV2lqbmVuICZsdDtiZXJ0aWV0 ZkBid2lqbmVuLm5ldCZndDs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPk1laG1ldCBFcnN1ZSAmbHQ7bWVobWV0LmVyc3VlQG5zbi5jb20mZ3Q7 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+TWVobWV0IEVyc3Vl ICZsdDttZWhtZXQuZXJzdWVAbnNuLmNvbSZndDs8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPk9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgQXJl YSBEaXJlY3RvcihzKTo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij5PcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50IEFyZWEgRGlyZWN0b3Iocyk6 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPkRhbiBSb21hc2NhbnUgJmx0O2Ryb21h c2NhQGF2YXlhLmNvbSZndDs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij5EYW4gUm9tYXNjYW51ICZsdDtkcm9tYXNjYUBhdmF5YS5jb20mZ3Q7 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0i cGFydC1sMiIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFs bD48ZW0+IGxpbmUgNTI8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1l PSJwYXJ0LXIyIiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3Nt YWxsPjxlbT4gbGluZSA1MjwvZW0+PC90aD48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ZGV2aWNlLCBhbmQgZm9yIGV4YW1pbmluZyBkZXZp Y2Ugc3RhdGUgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGltcGFjdDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPmRldmljZSwgYW5kIGZvciBleGFt aW5pbmcgZGV2aWNlIHN0YXRlIGluZm9ybWF0aW9uIHdoaWNoIG1heSBpbXBh Y3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+dGhlIGNvbmZpZ3VyYXRpb24uIEVh Y2ggb2YgdGhlc2UgbWVjaGFuaXNtcyBtYXkgYmUgZGlmZmVyZW50IGluPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+dGhlIGNvbmZpZ3VyYXRp b24uIEVhY2ggb2YgdGhlc2UgbWVjaGFuaXNtcyBtYXkgYmUgZGlmZmVyZW50 IGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPnZhcmlvdXMgYXNwZWN0cywgc3Vj aCBhcyBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIHVzZXIgYXV0aGVudGljYXRp b24sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+dmFyaW91cyBh c3BlY3RzLCBzdWNoIGFzIHNlc3Npb24gZXN0YWJsaXNobWVudCwgdXNlciBh dXRoZW50aWNhdGlvbiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Y29uZmlndXJh dGlvbiBkYXRhIGV4Y2hhbmdlLCBhbmQgZXJyb3IgcmVzcG9uc2VzLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPmNvbmZpZ3VyYXRpb24gZGF0 YSBleGNoYW5nZSwgYW5kIGVycm9yIHJlc3BvbnNlcy48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPlRoZSBORVRDT05GIFdvcmtpbmcgR3JvdXAg aXMgY2hhcnRlcmVkIHRvIHByb2R1Y2UgYSBwcm90b2NvbCBzdWl0YWJsZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlRoZSBORVRDT05GIFdv cmtpbmcgR3JvdXAgaXMgY2hhcnRlcmVkIHRvIHByb2R1Y2UgYSBwcm90b2Nv bCBzdWl0YWJsZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5mb3IgbmV0d29yayBj b25maWd1cmF0aW9uLCB3aXRoIHRoZSBmb2xsb3dpbmcgY2hhcmFjdGVyaXN0 aWNzOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPmZvciBuZXR3 b3JrIGNvbmZpZ3VyYXRpb24sIHdpdGggdGhlIGZvbGxvd2luZyBjaGFyYWN0 ZXJpc3RpY3M6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4tIFBy b3ZpZGVzIHJldHJpZXZhbCBtZWNoYW5pc21zIHdoaWNoIGNhbiBkaWZmZXJl bnRpYXRlIGJldHdlZW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4tIFByb3ZpZGVzIHJldHJpZXZhbCBtZWNoYW5pc21zIHdoaWNoIGNhbiBk aWZmZXJlbnRpYXRlIGJldHdlZW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Y29u ZmlndXJhdGlvbiBkYXRhIGFuZCBub24tY29uZmlndXJhdGlvbiBkYXRhPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Y29uZmlndXJhdGlvbiBk YXRhIGFuZCBub24tY29uZmlndXJhdGlvbiBkYXRhPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDAwMyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPi0gSXMgZXh0ZW5zaWJsZSBlbm91Z2ggdGhhdCB2ZW5kb3Jz IHdpbGwgcHJvdmlkZSBhY2Nlc3MgdG8gYWxsPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPi0gSXMgZXh0ZW5zaWJsZSBlbm91Z2ggPHNwYW4g Y2xhc3M9Imluc2VydCI+c28gPC9zcGFuPnRoYXQgdmVuZG9ycyB3aWxsIHBy b3ZpZGUgYWNjZXNzIHRvIGFsbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5jb25m aWd1cmF0aW9uIGRhdGEgb24gdGhlIGRldmljZSB1c2luZyBhIHNpbmdsZSBw cm90b2NvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPmNvbmZp Z3VyYXRpb24gZGF0YSBvbiB0aGUgZGV2aWNlIHVzaW5nIGEgc2luZ2xlIHBy b3RvY29sPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPi0gSGFzIGEgcHJvZ3JhbW1h dGljIGludGVyZmFjZSAoYXZvaWRzIHNjcmVlbiBzY3JhcGluZyBhbmQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4tIEhhcyBhIHByb2dyYW1t YXRpYyBpbnRlcmZhY2UgKGF2b2lkcyBzY3JlZW4gc2NyYXBpbmcgYW5kPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPmZvcm1hdHRpbmctcmVsYXRlZCBjaGFuZ2Vz IGJldHdlZW4gcmVsZWFzZXMpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+Zm9ybWF0dGluZy1yZWxhdGVkIGNoYW5nZXMgYmV0d2VlbiByZWxl YXNlcyk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+LSBVc2VzIGEgdGV4dHVhbCBk YXRhIHJlcHJlc2VudGF0aW9uLCB0aGF0IGNhbiBiZSBlYXNpbHkgbWFuaXB1 bGF0ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4tIFVzZXMg YSB0ZXh0dWFsIGRhdGEgcmVwcmVzZW50YXRpb24sIHRoYXQgY2FuIGJlIGVh c2lseSBtYW5pcHVsYXRlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij51c2luZyBu b24tc3BlY2lhbGl6ZWQgdGV4dCBtYW5pcHVsYXRpb24gdG9vbHMuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+dXNpbmcgbm9uLXNwZWNpYWxp emVkIHRleHQgbWFuaXB1bGF0aW9uIHRvb2xzLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4tIFN1cHBvcnRzIGludGVncmF0aW9uIHdpdGggZXhpc3RpbmcgdXNl ciBhdXRoZW50aWNhdGlvbiBtZXRob2RzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+LSBTdXBwb3J0cyBpbnRlZ3JhdGlvbiB3aXRoIGV4aXN0 aW5nIHVzZXIgYXV0aGVudGljYXRpb24gbWV0aG9kczwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4tIFN1cHBvcnRzIGludGVncmF0aW9uIHdpdGggZXhpc3Rpbmcg Y29uZmlndXJhdGlvbiBkYXRhYmFzZSBzeXN0ZW1zPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+LSBTdXBwb3J0cyBpbnRlZ3JhdGlvbiB3aXRo IGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24gZGF0YWJhc2Ugc3lzdGVtczwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4tIFN1cHBvcnRzIG5ldHdvcmsgd2lkZSBjb25m aWd1cmF0aW9uIHRyYW5zYWN0aW9ucyAod2l0aCBmZWF0dXJlcyBzdWNoPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+LSBTdXBwb3J0cyBuZXR3 b3JrIHdpZGUgY29uZmlndXJhdGlvbiB0cmFuc2FjdGlvbnMgKHdpdGggZmVh dHVyZXMgc3VjaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5hcyBsb2NraW5nIGFu ZCByb2xsYmFjayBjYXBhYmlsaXR5KTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPmFzIGxvY2tpbmcgYW5kIHJvbGxiYWNrIGNhcGFiaWxpdHkp PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPi0gSXMgYXMgdHJhbnNwb3J0LWluZGVw ZW5kZW50IGFzIHBvc3NpYmxlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+LSBJcyBhcyB0cmFuc3BvcnQtaW5kZXBlbmRlbnQgYXMgcG9zc2li bGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+LSBQcm92aWRlcyB0aGUgZm9sbG93 aW5nIHN1cHBvcnQgZm9yIGFzeW5jaHJvbm91cyBub3RpZmljYXRpb25zOjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPi0gUHJvdmlkZXMgc3Vw cG9ydCBmb3IgYXN5bmNocm9ub3VzIG5vdGlmaWNhdGlvbnM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA0IiAvPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+LSBTcGVjaWZ5 IHRoZSAmbHQ7aGVsbG8mZ3Q7IG1lc3NhZ2UgKGNhcGFiaWxpdHkgZXhjaGFu Z2UpIGRldGFpbHMgdG8gc3VwcG9ydDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+bm90aWZpY2F0aW9ucy48L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPi0gU3BlY2lmeSB0aGUgYXBw bGljYXRpb24gbWFwcGluZyBkZXRhaWxzIHRvIHN1cHBvcnQgbm90aWZpY2F0 aW9ucy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUi Pi0gU3BlY2lmeSB0aGUgcHJvdG9jb2wgc3ludGF4IGFuZCBzZW1hbnRpY3Mg b2YgYSBub3RpZmljYXRpb24gbWVzc2FnZS48L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjxzcGFuIGNsYXNzPSJkZWxldGUiPi0gU3BlY2lmeSBvciBzZWxlY3QgYSBu b3RpZmljYXRpb24gY29udGVudCBpbmZvcm1hdGlvbiBtb2RlbC48L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPi0gU3BlY2lmeSBh IG1lY2hhbmlzbSBmb3IgY29udHJvbGxpbmcgdGhlIGRlbGl2ZXJ5ICh0dXJu IG9uL29mZikgb2Y8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPm5vdGlmaWNhdGlvbnMgZHVyaW5nIGEgc2Vzc2lvbi48L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPi0gU3BlY2lmeSBh IG1lY2hhbmlzbSBmb3Igc2VsZWN0aXZlbHkgcmVjZWl2aW5nIGEgY29uZmln dXJhYmxlIHN1YnNldDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+b2YgYWxsIHBvc3NpYmxlIG5vdGlmaWNhdGlvbiB0eXBlcy48 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA1IiAvPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+VGhlIE5FVENPTkYgcHJv dG9jb2wgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+d2lsbCB1c2U8L3NwYW4+IFhN TCBmb3IgZGF0YSBlbmNvZGluZyBwdXJwb3NlcywgYmVjYXVzZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5UaGUgTkVUQ09ORiBwcm90b2Nv bCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5pcyB1c2luZzwvc3Bhbj4gWE1MIGZv ciBkYXRhIGVuY29kaW5nIHB1cnBvc2VzLCBiZWNhdXNlPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPlhNTCBpcyBhIHdpZGVseSBkZXBsb3llZCBzdGFuZGFyZCB3 aGljaCBpcyBzdXBwb3J0ZWQgYnkgYSBsYXJnZSBudW1iZXI8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5YTUwgaXMgYSB3aWRlbHkgZGVwbG95 ZWQgc3RhbmRhcmQgd2hpY2ggaXMgc3VwcG9ydGVkIGJ5IGEgbGFyZ2UgbnVt YmVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNiIgLz48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPm9mIGFwcGxpY2F0aW9ucy48 c3BhbiBjbGFzcz0iZGVsZXRlIj4gWE1MIGFsc28gc3VwcG9ydHMgaGllcmFy Y2hpY2FsIGRhdGEgc3RydWN0dXJlcy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPm9mIGFwcGxpY2F0aW9ucy48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPlRoZSBORVRDT05GIHByb3RvY29sIHNo b3VsZCBiZSBpbmRlcGVuZGVudCBvZiB0aGUgZGF0YSBkZWZpbml0aW9uPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+VGhlIE5FVENPTkYgcHJv dG9jb2wgc2hvdWxkIGJlIGluZGVwZW5kZW50IG9mIHRoZSBkYXRhIGRlZmlu aXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+bGFuZ3VhZ2UgYW5kIGRhdGEg bW9kZWxzIHVzZWQgdG8gZGVzY3JpYmUgY29uZmlndXJhdGlvbiBhbmQgc3Rh dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5sYW5ndWFnZSBh bmQgZGF0YSBtb2RlbHMgdXNlZCB0byBkZXNjcmliZSBjb25maWd1cmF0aW9u IGFuZCBzdGF0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5kYXRhLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPmRhdGEuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij5Ib3dldmVyLCB0aGUgYXV0aG9yaXphdGlvbiBt b2RlbCB1c2VkIGluIHRoZSBwcm90b2NvbCBpcyBkZXBlbmRlbnQgb248L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Ib3dldmVyLCB0aGUgYXV0 aG9yaXphdGlvbiBtb2RlbCB1c2VkIGluIHRoZSBwcm90b2NvbCBpcyBkZXBl bmRlbnQgb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+dGhlIGRhdGEgbW9kZWwu IEFsdGhvdWdoIHRoZXNlIGlzc3VlcyBtdXN0IGJlIGZ1bGx5IGFkZHJlc3Nl ZCB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPnRoZSBkYXRh IG1vZGVsLiBBbHRob3VnaCB0aGVzZSBpc3N1ZXMgbXVzdCBiZSBmdWxseSBh ZGRyZXNzZWQgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ZGV2ZWxvcCBzdGFu ZGFyZCBkYXRhIG1vZGVscywgb25seSBhIHNtYWxsIHBhcnQgb2YgdGhpcyB3 b3JrIHdpbGwgYmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5k ZXZlbG9wIHN0YW5kYXJkIGRhdGEgbW9kZWxzLCBvbmx5IGEgc21hbGwgcGFy dCBvZiB0aGlzIHdvcmsgd2lsbCBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5p bml0aWFsbHkgYWRkcmVzc2VkLiBUaGlzIGdyb3VwIHdpbGwgc3BlY2lmeSBy ZXF1aXJlbWVudHMgZm9yIHN0YW5kYXJkPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+aW5pdGlhbGx5IGFkZHJlc3NlZC4gVGhpcyBncm91cCB3 aWxsIHNwZWNpZnkgcmVxdWlyZW1lbnRzIGZvciBzdGFuZGFyZDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij5kYXRhIG1vZGVscyBpbiBvcmRlciB0byBmdWxseSBz dXBwb3J0IHRoZSBORVRDT05GIHByb3RvY29sLCBzdWNoIGFzOjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPmRhdGEgbW9kZWxzIGluIG9yZGVy IHRvIGZ1bGx5IHN1cHBvcnQgdGhlIE5FVENPTkYgcHJvdG9jb2wsIHN1Y2gg YXM6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw MDciIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4tIGlkZW50 aWZpY2F0aW9uIG9mIHByaW5jaXBhbHMsIHN1Y2ggYXMgdXNlciBuYW1lcyBv ciBkaXN0aW5ndWlzaGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPi0gaWRlbnRpZmljYXRpb24gb2YgcHJpbmNpcGFscywgc3VjaCBhcyB1 c2VyIG5hbWVzIG9yIGRpc3Rpbmd1aXNoZWQgbmFtZXM8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj5uYW1lczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+LSBtZWNoYW5pc20gdG8gZGlz dGluZ3Vpc2ggY29uZmlndXJhdGlvbiBmcm9tIG5vbi1jb25maWd1cmF0aW9u IGRhdGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4tIG1lY2hh bmlzbSB0byBkaXN0aW5ndWlzaCBjb25maWd1cmF0aW9uIGZyb20gbm9uLWNv bmZpZ3VyYXRpb24gZGF0YTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlm ZjAwMDgiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gaWRlbnRpZmljYXRpb24gb2YgcHJpbmNpcGFs cywgc3VjaCBhcyB1c2VyIG5hbWVzIG9yIGRpc3Rpbmd1aXNoZWQgbmFtZXM8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4tIFhNTCBuYW1lc3BhY2UgY29udmVudGlvbnM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4tIFhNTCBuYW1lc3Bh Y2UgY29udmVudGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+LSBYTUwgdXNh Z2UgZ3VpZGVsaW5lczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi Pi0gWE1MIHVzYWdlIGd1aWRlbGluZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZD48YSBuYW1lPSJkaWZmMDAwOSIgLz48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPkl0IHNob3VsZCBi ZSBwb3NzaWJsZSB0byB0cmFuc3BvcnQgdGhlIE5FVENPTkYgcHJvdG9jb2wg dXNpbmcgc2V2ZXJhbDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+VGhlIGluaXRpYWwgd29yayA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij5zdGFydGVkIGluIDIwMDMgYW5kIGhhcyBhbHJlYWR5IGJlZW4gY29tcGxl dGVkPC9zcGFuPiBhbmQgd2FzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+ZGlmZmVyZW50IHByb3RvY29scy4gVGhlIGdy b3VwIHdpbGwgc2VsZWN0IGF0IGxlYXN0IG9uZSBzdWl0YWJsZTwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+cmVzdHJpY3RlZCB0 byBmb2xsb3dpbmcgaXRlbXM6PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+dHJhbnNwb3J0IG1lY2hhbmlzbSwgYW5kIGRl ZmluZSBhIG1hcHBpbmcgZm9yIHRoZSBzZWxlY3RlZCBwcm90b2NvbDwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+KHMpLjwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj5UaGUgaW5pdGlhbCB3b3JrIDxzcGFuIGNsYXNzPSJkZWxl dGUiPihoYXMgY29tcGxldGVkKTwvc3Bhbj4gYW5kIHdhcyByZXN0cmljdGVk IHRvIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRoZTwvc3Bhbj4gZm9sbG93aW5n PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPml0ZW1zOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJk aWZmMDAxMCIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxz cGFuIGNsYXNzPSJkZWxldGUiPi08L3NwYW4+IE5FVENPTkYgUHJvdG9jb2wg U3BlY2lmaWNhdGlvbiwgd2hpY2ggZGVmaW5lcyB0aGUgb3BlcmF0aW9uYWwg bW9kZWwsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgYSk8L3NwYW4+IE5FVENPTkYgUHJvdG9jb2wg U3BlY2lmaWNhdGlvbiwgd2hpY2ggZGVmaW5lcyB0aGUgb3BlcmF0aW9uYWwg bW9kZWwsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPnByb3RvY29sIG9wZXJhdGlv bnMsIHRyYW5zYWN0aW9uIG1vZGVsLCBkYXRhIG1vZGVsIHJlcXVpcmVtZW50 cyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5wcm90b2NvbCBv cGVyYXRpb25zLCB0cmFuc2FjdGlvbiBtb2RlbCwgZGF0YSBtb2RlbCByZXF1 aXJlbWVudHMsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPnNlY3VyaXR5IHJlcXVp cmVtZW50cywgYW5kIHRyYW5zcG9ydCBsYXllciByZXF1aXJlbWVudHMuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+c2VjdXJpdHkgcmVxdWly ZW1lbnRzLCBhbmQgdHJhbnNwb3J0IGxheWVyIHJlcXVpcmVtZW50cy48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDExIiAvPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgPHNwYW4gY2xhc3M9Imluc2VydCI+YikgTkVUQ09ORiBv dmVyIFNTSCBTcGVjaWZpY2F0aW9uOiBJbXBsZW1lbnRhdGlvbiBNYW5kYXRv cnksPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g IGMpIE5FVENPTkYgb3ZlciBCRUVQIFNwZWNpZmljYXRpb246IEltcGxlbWVu dGF0aW9uIE9wdGlvbmFsLDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICBkKSBORVRDT05GIG92ZXIgU09BUCBTcGVjaWZpY2F0 aW9uOiBJbXBsZW1lbnRhdGlvbiBPcHRpb25hbC48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTIiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij4tIE5FVENPTkYgb3ZlciBTU0ggU3BlY2lmaWNhdGlvbjogSW1wbGVtZW50 YXRpb24gTWFuZGF0b3J5OyBORVRDT05GPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gIFRoZXNlIGRvY3VtZW50cyBkZWZpbmUg aG93IHRoZSBORVRDT05GIHByb3RvY29sIGlzIHVzZWQgd2l0aCBlYWNoPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+b3Zl ciBCRUVQIFNwZWNpZmljYXRpb246IEltcGxlbWVudGF0aW9uIE9wdGlvbmFs OyBORVRDT05GIG92ZXIgU09BUDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICB0cmFuc3BvcnQgcHJvdG9jb2wgc2VsZWN0ZWQg YnkgdGhlIHdvcmtpbmcgZ3JvdXAsIGFuZCBob3cgaXQgbWVldHM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj5TcGVjaWZp Y2F0aW9uOiBJbXBsZW1lbnRhdGlvbiBPcHRpb25hbDs8L3NwYW4+IFRoZXNl IGRvY3VtZW50cyBkZWZpbmUgaG93IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gIHRoZSBzZWN1cml0eSBhbmQgdHJhbnNwb3J0IGxh eWVyIHJlcXVpcmVtZW50cyBvZiB0aGUgTkVUQ09ORiBQcm90b2NvbDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPk5FVENPTkYgcHJvdG9jb2wgaXMgdXNlZCB3 aXRoIGVhY2ggdHJhbnNwb3J0IHByb3RvY29sIHNlbGVjdGVkIGJ5IHRoZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gIFNwZWNpZmljYXRp b24uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+d29ya2luZyBncm91cCwgYW5k IGhvdyBpdCBtZWV0cyB0aGUgc2VjdXJpdHkgYW5kIHRyYW5zcG9ydCBsYXll cjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj5yZXF1aXJlbWVudHMgb2YgdGhlIE5FVENPTkYgUHJv dG9jb2wgU3BlY2lmaWNhdGlvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj5BZGRpdGlvbmFsIE5vdGlmaWNhdGlvbiB3b3JrIChhcyBkZXNjcmli ZWQgYWJvdmUpIHdpbGwgbm93IGJlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj5hZGRyZXNzZWQgc2luY2UgdGhlIGluaXRpYWwg d29yayBoYXMgYmVlbiBjb21wbGV0ZWQuPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDAxMyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPkFuIGluZGl2aWR1YWwg c3VibWlzc2lvbiBJbnRlcm5ldCBEcmFmdCBoYXMgYmVlbiBwcm9wb3NlZCB0 byB0aGUgV0cgYXM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgPHNwYW4gY2xhc3M9Imluc2VydCI+ZSkgTkVUQ09ORiBOb3Rp ZmljYXRpb24gU3BlY2lmaWNhdGlvbiwgd2hpY2ggZGVmaW5lcyBtZWNoYW5p c21zIHRoYXQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4g Y2xhc3M9ImRlbGV0ZSI+dGhlIHN0YXJ0aW5nIHBvaW50PC9zcGFuPiBmb3Ig dGhlIE5vdGlmaWNhdGlvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj53b3JrLiBU aGUgV0cgc2hhbGwgYWRvcHQ8L3NwYW4+IHRoZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgIHBy b3ZpZGUgYW4gYXN5bmNocm9ub3VzIG1lc3NhZ2Ugbm90aWZpY2F0aW9uIGRl bGl2ZXJ5IHNlcnZpY2U8L3NwYW4+IGZvcjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPmRvY3VtZW50IGlkZW50aWZpZWQg YXMgJ2RyYWZ0LWNoaXNob2xtLU5FVENPTkYtZXZlbnQtMDEudHh0JyBhczwv c3Bhbj4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgdGhlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk5FVENPTkYgcHJvdG9jb2wu ICBORVRDT05GPC9zcGFuPiBOb3RpZmljYXRpb24gPHNwYW4gY2xhc3M9Imlu c2VydCI+aXMgYW4gb3B0aW9uYWw8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+c3RhcnRpbmcgcG9pbnQgZm9y PC9zcGFuPiB0aGlzIDxzcGFuIGNsYXNzPSJkZWxldGUiPndvcmsuPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICAgIGNhcGFiaWxpdHkgYnVpbHQgb24gdG9wIG9mPC9z cGFuPiB0aGUgPHNwYW4gY2xhc3M9Imluc2VydCI+YmFzZSBORVRDT05GIGRl ZmluaXRpb24gYW5kPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICAgIHByb3ZpZGVzPC9zcGFuPiB0aGUgPHNwYW4gY2xhc3M9 Imluc2VydCI+Y2FwYWJpbGl0aWVzIGFuZCBvcGVyYXRpb25zIG5lY2Vzc2Fy eSB0byBzdXBwb3J0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIHRoaXMgPHNw YW4gY2xhc3M9Imluc2VydCI+c2VydmljZS48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTQiIC8+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj5B IHNlY29uZDwvc3Bhbj4gcGhhc2Ugb2YgaW5jcmVtZW50YWwgZGV2ZWxvcG1l bnQgb2YgTkVUQ09ORiA8c3BhbiBjbGFzcz0iZGVsZXRlIj53aWxsIGluY2x1 ZGU8L3NwYW4+IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij5JbiB0aGUgY3VycmVudDwvc3Bhbj4g cGhhc2Ugb2YgPHNwYW4gY2xhc3M9Imluc2VydCI+dGhlPC9zcGFuPiBpbmNy ZW1lbnRhbCBkZXZlbG9wbWVudCBvZiBORVRDT05GIHRoZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPmZvbGxvd2luZyBpdGVtczo8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+d29ya2dy b3VwIHdpbGwgZm9jdXMgb248L3NwYW4+IGZvbGxvd2luZyBpdGVtczo8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjEuIEZpbmUtZ3JhaW4gbG9j a2luZzogVGhlIGJhc2UgTkVUQ09ORiBwcm90b2NvbCBvbmx5IHByb3ZpZGVz IGEgbG9jazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjEuIEZp bmUtZ3JhaW4gbG9ja2luZzogVGhlIGJhc2UgTkVUQ09ORiBwcm90b2NvbCBv bmx5IHByb3ZpZGVzIGEgbG9jazwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5mb3Ig dGhlIGVudGlyZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSwgd2hpY2ggaXMg bm90IGRlZW1lZCB0byBtZWV0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+Zm9yIHRoZSBlbnRpcmUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUs IHdoaWNoIGlzIG5vdCBkZWVtZWQgdG8gbWVldDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij5pbXBvcnRhbnQgb3BlcmF0aW9uYWwgYW5kIHNlY3VyaXR5IHJlcXVp cmVtZW50cy4gVGhlIE5FVENPTkYgd29ya2luZzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPmltcG9ydGFudCBvcGVyYXRpb25hbCBhbmQgc2Vj dXJpdHkgcmVxdWlyZW1lbnRzLiBUaGUgTkVUQ09ORiB3b3JraW5nPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPmdyb3VwIHdpbGwgcHJvZHVjZSBhIHN0YW5kYXJk cy10cmFjayBSRkMgc3BlY2lmeWluZyBhIG1lY2hhbmlzbSBmb3I8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5ncm91cCB3aWxsIHByb2R1Y2Ug YSBzdGFuZGFyZHMtdHJhY2sgUkZDIHNwZWNpZnlpbmcgYSBtZWNoYW5pc20g Zm9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPmZpbmUtZ3JhaW4gbG9ja2luZyBv ZiB0aGUgTkVUQ09ORiBjb25maWd1cmF0aW9uIGRhdGFzdG9yZS48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5maW5lLWdyYWluIGxvY2tpbmcg b2YgdGhlIE5FVENPTkYgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTUiIC8+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj4oVGhlIGluaXRpYWwgZHJhZnQgd2lsbCBiZSBiYXNlZCBvbjwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZHJhZnQtbGVu Z3llbC1uZ28tcGFydGlhbC1sb2NrLTAwLnR4dCBiYXJyaW5nIGFkZGl0aW9u YWwgY29udHJpYnV0aW9uczwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xh c3M9ImRlbGV0ZSI+ZnJvbSB0aGUgY29tbXVuaXR5Lik8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjIuIE5FVENPTkYgbW9uaXRvcmluZzogSXQgaXMgY29uc2lkZXJlZCBiZXN0 IHByYWN0aWNlIGZvciBJRVRGIHdvcmtpbmc8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4yLiBORVRDT05GIG1vbml0b3Jpbmc6IEl0IGlzIGNv bnNpZGVyZWQgYmVzdCBwcmFjdGljZSBmb3IgSUVURiB3b3JraW5nPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPmdyb3VwcyB0byBpbmNsdWRlIG1hbmFnZW1lbnQg b2YgdGhlaXIgcHJvdG9jb2xzIHdpdGhpbiB0aGUgc2NvcGUgb2Y8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5ncm91cHMgdG8gaW5jbHVkZSBt YW5hZ2VtZW50IG9mIHRoZWlyIHByb3RvY29scyB3aXRoaW4gdGhlIHNjb3Bl IG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxNiIgLz48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPnRoZSBzb2x1dGlvbiB0aGV5 IGFyZSBwcm92aWRpbmcuIDxzcGFuIGNsYXNzPSJkZWxldGUiPk5FVENPTkYg ZG9lcyBub3QgcHJvdmlkZSB0aGlzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICB0aGUgc29sdXRpb24gdGhleSBhcmUgcHJv dmlkaW5nLiBUaGUgTkVUQ09ORiB3b3JraW5nIGdyb3VwIHdpbGw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj5jYXBhYmls aXR5Ljwvc3Bhbj4gVGhlIE5FVENPTkYgd29ya2luZyBncm91cCB3aWxsIHBy b2R1Y2UgYSBzdGFuZGFyZHMtdHJhY2s8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgcHJvZHVjZSBhIHN0YW5kYXJkcy10cmFjayBSRkMg d2l0aCBtZWNoYW5pc21zIGFsbG93aW5nIE5FVENPTkY8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj5SRkMgd2l0aCBtZWNoYW5pc21zIGFsbG93aW5nIE5FVENP TkYgaXRzZWxmIHRvIGJlIHVzZWQgdG8gbW9uaXRvciBzb21lPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGl0c2VsZiB0byBiZSB1c2Vk IHRvIG1vbml0b3Igc29tZSBhc3BlY3RzIG9mIE5FVENPTkYgb3BlcmF0aW9u LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPmFzcGVjdHMgb2YgTkVUQ09ORiBv cGVyYXRpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+KFRoZSBp bml0aWFsIGRyYWZ0IHdpbGwgYmUgYmFzZWQgb248L3NwYW4+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPmRyYWZ0LWNoaXNob2xtLW5ldGNv bmYtbW9uaXRvcmluZy0wMC50eHQgYmFycmluZyBhZGRpdGlvbmFsPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj5jb250cmlidXRp b25zIGZyb20gdGhlIGNvbW11bml0eS4pPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjMuIFNjaGVtYSBhZHZlcnRpc2VtZW50OiBDdXJyZW50bHkgdGhl IE5FVENPTkYgcHJvdG9jb2wgaXMgYWJsZSB0bzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjMuIFNjaGVtYSBhZHZlcnRpc2VtZW50OiBDdXJy ZW50bHkgdGhlIE5FVENPTkYgcHJvdG9jb2wgaXMgYWJsZSB0bzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij5hZHZlcnRpc2Ugd2hpY2ggcHJvdG9jb2wgZmVhdHVy ZXMgYXJlIHN1cHBvcnRlZCBvbiBhIHBhcnRpY3VsYXI8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij5hZHZlcnRpc2Ugd2hpY2ggcHJvdG9jb2wg ZmVhdHVyZXMgYXJlIHN1cHBvcnRlZCBvbiBhIHBhcnRpY3VsYXI8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+bmV0Y29uZi1jYXBhYmxlIGRldmljZS4gSG93ZXZl ciwgdGhlcmUgaXMgY3VycmVudGx5IG5vIHdheSB0byBkaXNjb3ZlcjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPm5ldGNvbmYtY2FwYWJsZSBk ZXZpY2UuIEhvd2V2ZXIsIHRoZXJlIGlzIGN1cnJlbnRseSBubyB3YXkgdG8g ZGlzY292ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+d2hpY2ggWE1MIFNjaGVt YSBhcmUgc3VwcG9ydGVkIG9uIHRoZSBkZXZpY2UuIFRoZSBORVRDT05GIHdv cmtpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij53aGljaCBY TUwgU2NoZW1hIGFyZSBzdXBwb3J0ZWQgb24gdGhlIGRldmljZS4gVGhlIE5F VENPTkYgd29ya2luZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5ncm91cCB3aWxs IHByb2R1Y2UgYSBzdGFuZGFyZHMtdHJhY2sgUkZDIHdpdGggbWVjaGFuaXNt cyBtYWtpbmcgdGhpczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi Pmdyb3VwIHdpbGwgcHJvZHVjZSBhIHN0YW5kYXJkcy10cmFjayBSRkMgd2l0 aCBtZWNoYW5pc21zIG1ha2luZyB0aGlzPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBu YW1lPSJkaWZmMDAxNyIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPmRpc2NvdmVyeSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5wb3NzaWJsZS48 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGRp c2NvdmVyeSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5wb3NzaWJsZSAodGhpczwv c3Bhbj4gaXRlbSBtYXkgYmUgbWVyZ2VkIHdpdGggIk5FVENPTkYgbW9uaXRv cmluZyI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVs ZXRlIj48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIGludG8gYSBzaW5nbGUgPHNwYW4gY2xhc3M9Imluc2VydCI+ZG9jdW1l bnQpLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFz cz0iZGVsZXRlIj5UaGlzPC9zcGFuPiBpdGVtIG1heSBiZSBtZXJnZWQgd2l0 aCAiTkVUQ09ORiBtb25pdG9yaW5nIiBpbnRvIGEgc2luZ2xlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPmRvY3VtZW50Ljwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+PC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4oVGhlIGluaXRpYWwgZHJhZnQg d2lsbCBiZSBiYXNlZCBvbjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xh c3M9ImRlbGV0ZSI+ZHJhZnQtc2NvdHQtbmV0Y29uZi1zY2hlbWEtcXVlcnkt MDAudHh0IGJhcnJpbmcgYWRkaXRpb25hbDwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+Y29udHJpYnV0aW9ucyBmcm9tIHRoZSBj b21tdW5pdHkuKTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlm ZjAwMTgiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj40LiBO RVRDT05GIG92ZXIgVExTPHNwYW4gY2xhc3M9ImRlbGV0ZSI+IC0gYjwvc3Bh bj5hc2VkIG9uIGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2UgdGhlcmUgaXMg YTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj40LiBORVRDT05G IG92ZXIgVExTPHNwYW4gY2xhc3M9Imluc2VydCI+OiBCPC9zcGFuPmFzZWQg b24gaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSB0aGVyZSBpcyBhPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPm5lZWQgZm9yIGEgc3RhbmRhcmRzIHRyYWNrIGRv Y3VtZW50IHRvIGRlZmluZSBORVRDT05GIG92ZXIgVExTIGFzIGFuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+bmVlZCBmb3IgYSBzdGFuZGFy ZHMgdHJhY2sgZG9jdW1lbnQgdG8gZGVmaW5lIE5FVENPTkYgb3ZlciBUTFMg YXMgYW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDE5IiAvPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+b3B0aW9uYWwgdHJhbnNw b3J0IGZvciA8c3BhbiBjbGFzcz0iZGVsZXRlIj5ORVRDT05GPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBvcHRpb25hbCB0 cmFuc3BvcnQgZm9yIHRoZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5ORVRDT05G IHByb3RvY29sLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNs YXNzPSJkZWxldGUiPihUaGUgaW5pdGlhbCBkcmFmdCB3aWxsIGJlIGJhc2Vk IG9uPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj5k cmFmdC1iYWRyYS10bHMtbmV0Y29uZi0wNC50eHQgYmFycmluZyBhZGRpdGlv bmFsIGNvbnRyaWJ1dGlvbnMgZnJvbTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+dGhl IDxzcGFuIGNsYXNzPSJkZWxldGUiPmNvbW11bml0eS4pPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyMCIgLz48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPlRoZSBmb2xsb3dpbmcgYXJlIGN1cnJlbnRs eSBub3QgY29uc2lkZXJlZCBpbiBzY29wZSBmb3IgcmUtY2hhcnRlcmluZzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj5UaGUgZm9sbG93aW5n IDxzcGFuIGNsYXNzPSJpbnNlcnQiPml0ZW1zIGhhdmUgYmVlbiBpZGVudGlm aWVkIGFzIGltcG9ydGFudCBidXQ8L3NwYW4+IGFyZSBjdXJyZW50bHk8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj5hdCB0 aGlzIHRpbWUsIGJ1dDwvc3Bhbj4gbWF5IGJlIGNhbmRpZGF0ZXMgZm9yIHdv cmsgd2hlbiB0aGVyZSBpcyBjb21tdW5pdHk8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+bm90IGNvbnNpZGVyZWQgaW4gc2NvcGUgZm9yIHJl LWNoYXJ0ZXJpbmcgPHNwYW4gY2xhc3M9Imluc2VydCI+YW5kPC9zcGFuPiBt YXkgYmUgY2FuZGlkYXRlcyBmb3Igd29yazwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPmNvbnNlbnN1cyB0byB0YWtlIHRoZW0gPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+b24uIEluZGl2aWR1YWwgc3VibWlzc2lvbnMgYXJlIGJlaW5nPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj53aGVuIHRoZXJl IGlzIGNvbW11bml0eSBjb25zZW5zdXMgdG8gdGFrZSB0aGVtIDxzcGFuIGNs YXNzPSJpbnNlcnQiPm9uOjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48c3BhbiBjbGFzcz0iZGVsZXRlIj5lbmNvdXJhZ2VkLjwvc3Bhbj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjEiIC8+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj5vIEFj Y2VzcyBDb250cm9sIHJlcXVpcmVtZW50czwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+LTwv c3Bhbj4gR2VuZXJhbCBpbXByb3ZlbWVudHMgdG8gdGhlIGJhc2UgcHJvdG9j b2w8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij5vPC9zcGFuPiBHZW5lcmFsIGltcHJvdmVtZW50cyB0byB0aGUgYmFzZSBw cm90b2NvbCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5vPC9zcGFuPiBORVRDT05G IGFjY2VzcyB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4tIEFjY2VzcyBDb250cm9sIHJlcXVpcmVt ZW50czwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5TTUktYmFzZWQg TUlCIGRhdGEgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+byBUaGUgQmlsbCBGZW5u ZXIgcHJvYmxlbTogQWRkcmVzcyByZWFsIG9yPC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4t PC9zcGFuPiBORVRDT05GIGFjY2VzcyB0byBTTUktYmFzZWQgTUlCIGRhdGE8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj5w ZXJjZWl2ZWQgaXNzdWUgdGhhdCAiZ2l2aW5nIFNTSCBmb3IgTkVUQ09ORiBn aXZlcyBmdWxsIFNTSCBhY2Nlc3MgdG88L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxz cGFuIGNsYXNzPSJkZWxldGUiPnRoZSBib3giPC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPkdvYWxzIGFuZCBNaWxlc3RvbmVzOjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPkdvYWxzIGFuZCBNaWxlc3RvbmVzOjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBEb25lICBXb3JraW5nIEdyb3VwIGZv cm1lZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIERv bmUgIFdvcmtpbmcgR3JvdXAgZm9ybWVkPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgIERvbmUgIFN1Ym1pdCBpbml0aWFsIE5ldGNvbmYgUHJvdG9jb2wg ZHJhZnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBE b25lICBTdWJtaXQgaW5pdGlhbCBOZXRjb25mIFByb3RvY29sIGRyYWZ0PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIERvbmUgIFN1Ym1pdCBpbml0aWFs IE5ldGNvbmYgb3ZlciAodHJhbnNwb3J0LVRCRCkgZHJhZnQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBEb25lICBTdWJtaXQgaW5p dGlhbCBOZXRjb25mIG92ZXIgKHRyYW5zcG9ydC1UQkQpIGRyYWZ0PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgIERvbmUgIEJlZ2luIFdvcmtpbmcgR3Jv dXAgTGFzdCBDYWxsIGZvciB0aGUgTmV0Y29uZiBQcm90b2NvbCBkcmFmdDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIERvbmUgIEJl Z2luIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciB0aGUgTmV0Y29uZiBQ cm90b2NvbCBkcmFmdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBEb25l ICBCZWdpbiBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgdGhlIE5ldGNv bmYgb3ZlciAodHJhbnNwb3J0LVRCRCk8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICBEb25lICBCZWdpbiBXb3JraW5nIEdyb3VwIExh c3QgQ2FsbCBmb3IgdGhlIE5ldGNvbmYgb3ZlciAodHJhbnNwb3J0LVRCRCk8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgZHJhZnQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBkcmFmdDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICBEb25lICBTdWJtaXQgZmluYWwgdmVyc2lvbiBvZiB0 aGUgTmV0Y29uZiBQcm90b2NvbCBkcmFmdCB0byB0aGUgSUVTRzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIERvbmUgIFN1Ym1pdCBm aW5hbCB2ZXJzaW9uIG9mIHRoZSBOZXRjb25mIFByb3RvY29sIGRyYWZ0IHRv IHRoZSBJRVNHPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIERvbmUgIFN1 Ym1pdCBmaW5hbCB2ZXJzaW9uIG9mIHRoZSBOZXRjb25mIG92ZXIgU09BUCBk cmFmdCB0byB0aGUgSUVTRzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgIERvbmUgIFN1Ym1pdCBmaW5hbCB2ZXJzaW9uIG9mIHRoZSBO ZXRjb25mIG92ZXIgU09BUCBkcmFmdCB0byB0aGUgSUVTRzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICBEb25lICBTdWJtaXQgZmluYWwgdmVyc2lvbiBv ZiB0aGUgTmV0Y29uZiBvdmVyIEJFRVAgZHJhZnQgdG8gdGhlIElFU0c8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBEb25lICBTdWJt aXQgZmluYWwgdmVyc2lvbiBvZiB0aGUgTmV0Y29uZiBvdmVyIEJFRVAgZHJh ZnQgdG8gdGhlIElFU0c8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgRG9u ZSAgU3VibWl0IGZpbmFsIHZlcnNpb24gb2YgdGhlIE5ldGNvbmYgb3ZlciBT U0ggZHJhZnQgdG8gdGhlIElFU0c8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICBEb25lICBTdWJtaXQgZmluYWwgdmVyc2lvbiBvZiB0 aGUgTmV0Y29uZiBvdmVyIFNTSCBkcmFmdCB0byB0aGUgSUVTRzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICBEb25lICBVcGRhdGUgY2hhcnRlcjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIERvbmUgIFVwZGF0 ZSBjaGFydGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIERvbmUgIFN1 Ym1pdCBmaXJzdCB2ZXJzaW9uIG9mIE5FVENPTkYgTm90aWZpY2F0aW9ucyBk b2N1bWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg IERvbmUgIFN1Ym1pdCBmaXJzdCB2ZXJzaW9uIG9mIE5FVENPTkYgTm90aWZp Y2F0aW9ucyBkb2N1bWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBE b25lICBCZWdpbiBXR0xDIG9mIE5FVENPTkYgTm90aWZpY2F0aW9ucyBkb2N1 bWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIERv bmUgIEJlZ2luIFdHTEMgb2YgTkVUQ09ORiBOb3RpZmljYXRpb25zIGRvY3Vt ZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyMiIgLz48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgICAgIERlYyAyMDA2PC9zcGFuPiAgU3VibWl0IGZpbmFsIHZlcnNp b24gb2YgTkVUQ09ORiBOb3RpZmljYXRpb25zIGRvY3VtZW50IHRvIElFU0c8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+RG9uZQk8L3NwYW4+ICBTdWJtaXQgZmluYWwgdmVyc2lvbiBv ZiBORVRDT05GIE5vdGlmaWNhdGlvbnMgZG9jdW1lbnQgdG8gSUVTRzwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBmb3IgY29uc2lkZXJhdGlvbiBhcyBQ cm9wb3NlZCBTdGFuZGFyZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgIGZvciBjb25zaWRlcmF0aW9uIGFzIFByb3Bvc2VkIFN0YW5k YXJkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyMyIgLz48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDxzcGFuIGNsYXNz PSJkZWxldGUiPkRlYyAyMDA3PC9zcGFuPiAgLTAwIGRyYWZ0IGZvciA8c3Bh biBjbGFzcz0iZGVsZXRlIj5ORVRDT05GIE1vbml0b3Jpbmc8L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPkRvbmU8L3NwYW4+CSAgLTAwIGRyYWZ0IGZvciA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5maW5lIEdyYWluIExvY2tpbmc8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgRGVj IDIwMDc8L3NwYW4+ICAtMDAgZHJhZnQgZm9yIDxzcGFuIGNsYXNzPSJkZWxl dGUiPlNjaGVtYSBBZHZlcnRpc2VtZW50PC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Eb25l PC9zcGFuPgkgIC0wMCBkcmFmdCBmb3IgPHNwYW4gY2xhc3M9Imluc2VydCI+ TkVUQ09ORiBvdmVyIFRMUzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICBEZWMgMjAwNzwvc3Bhbj4g IC0wMCBkcmFmdCBmb3IgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+RmluZSBHcmFp biBMb2NraW5nPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij5Eb25lPC9zcGFuPgkgIC0wMCBk cmFmdCBmb3IgPHNwYW4gY2xhc3M9Imluc2VydCI+TkVUQ09ORiBNb25pdG9y aW5nPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPiAgICAgIERlYyAyMDA3PC9zcGFuPiAgLTAwIGRyYWZ0IGZv ciA8c3BhbiBjbGFzcz0iZGVsZXRlIj5ORVRDT05GIG92ZXIgVExTPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij5GZWIgMjAwODwvc3Bhbj4gIC0wMCBkcmFmdCBmb3IgPHNw YW4gY2xhc3M9Imluc2VydCI+U2NoZW1hIEFkdmVydGlzZW1lbnQ8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE1hciAyMDA4ICBFYXJseSBS ZXZpZXcgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFwcHJvYWNoIChmb3Ig TkVUQ09ORiBvdmVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgTWFyIDIwMDggIEVhcmx5IFJldmlldyBvZiBjbGllbnQgYXV0aGVu dGljYXRpb24gYXBwcm9hY2ggKGZvciBORVRDT05GIG92ZXI8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgVExTKSB3aXRoIHRoZSBzZWN1cml0eSBjb21t dW5pdHkgYXQgSUVURiA3MTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgIFRMUykgd2l0aCB0aGUgc2VjdXJpdHkgY29tbXVuaXR5IGF0 IElFVEYgNzE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgQXVnIDIwMDgg IFdHIExhc3QgQ2FsbCBvbiBORVRDT05GIE1vbml0b3JpbmcgYWZ0ZXIgSUVU RjcyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgQXVn IDIwMDggIFdHIExhc3QgQ2FsbCBvbiBORVRDT05GIE1vbml0b3JpbmcgYWZ0 ZXIgSUVURjcyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIEF1ZyAyMDA4 ICBXRyBMYXN0IENhbGwgb24gU2NoZW1hIEFkdmVydGlzZW1lbnQgYWZ0ZXIg SUVURjcyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg QXVnIDIwMDggIFdHIExhc3QgQ2FsbCBvbiBTY2hlbWEgQWR2ZXJ0aXNlbWVu dCBhZnRlciBJRVRGNzI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgQXVn IDIwMDggIFdHIExhc3QgQ2FsbCBvbiBGaW5lIEdyYWluIExvY2tpbmcgYWZ0 ZXIgSUVURjcyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgQXVnIDIwMDggIFdHIExhc3QgQ2FsbCBvbiBGaW5lIEdyYWluIExvY2tp bmcgYWZ0ZXIgSUVURjcyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIEF1 ZyAyMDA4ICBXRyBMYXN0IENhbGwgb24gTkVUQ09ORiBvdmVyIFRMUyBhZnRl ciBJRVRGNzI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBBdWcgMjAwOCAgV0cgTGFzdCBDYWxsIG9uIE5FVENPTkYgb3ZlciBUTFMg YWZ0ZXIgSUVURjcyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIEF1ZyAy MDA4ICBTZW5kIGZvdXIgZG9jdW1lbnRzIHRvIHRoZSBJRVNHIGZvciBjb25z aWRlcmF0aW9uIGFzIHByb3Bvc2VkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgQXVnIDIwMDggIFNlbmQgZm91ciBkb2N1bWVudHMg dG8gdGhlIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgcHJvcG9zZWQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgc3RhbmRhcmRzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgc3RhbmRhcmRzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlcm5ldC1EcmFmdHM6PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZXJuZXQtRHJhZnRzOjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4K ICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWdu PSJjZW50ZXIiPjxhIG5hbWU9ImVuZCI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMu IDIzIGNoYW5nZSBibG9ja3MuJm5ic3A7PC9hPjwvdGg+PC90cj4KICAgICA8 dHIgY2xhc3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+ODAgbGluZXMgY2hh bmdlZCBvciBkZWxldGVkPC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+ PGk+NDIgbGluZXMgY2hhbmdlZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48L3Rk PjwvdHI+CiAgICAgPHRyPjx0ZCBjb2xzcGFuPSI1IiBhbGlnbj0iY2VudGVy IiBjbGFzcz0ic21hbGwiPjxici8+VGhpcyBodG1sIGRpZmYgd2FzIHByb2R1 Y2VkIGJ5IHJmY2RpZmYgMS4zNC4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5v cmcvdG9vbHMvcmZjZGlmZi8iID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9v bHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4KICAgPC90YWJsZT4KICAgPC9i b2R5PgogICA8L2h0bWw+Cg== --0-859375073-1201180727=:20935-- -- 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 Jan 24 08:35:52 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI2FE-0000PK-Gt for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 08:35:52 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI2F9-0004kw-Ep for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 08:35:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI23V-000JoG-Su for netconf-data@psg.com; Thu, 24 Jan 2008 13:23:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI23N-000Jnc-Qv for netconf@ops.ietf.org; Thu, 24 Jan 2008 13:23:43 +0000 X-IronPort-AV: E=Sophos;i="4.25,244,1199682000"; d="scan'208,217";a="94707885" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Jan 2008 08:23:36 -0500 X-IronPort-AV: E=Sophos;i="4.25,244,1199682000"; d="scan'208,217";a="146310861" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 Jan 2008 08:23:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85E8C.49E41CAD" Subject: RE: Request for charter change Date: Thu, 24 Jan 2008 14:23:24 +0100 Message-ID: In-Reply-To: <981942.20935.qm@web27808.mail.ukl.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for charter change Thread-Index: Achei60sB/nOasN1Qru/odZSUGJIxwAAGdtA References: <981942.20935.qm@web27808.mail.ukl.yahoo.com> From: "Romascanu, Dan (Dan)" To: "Mehmet Ersue" , Cc: Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: dc7bd83d90806aed39f33478866e2683 This is a multi-part message in MIME format. ------_=_NextPart_001_01C85E8C.49E41CAD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This looks fine to me. Unless I hear any comments and requests to change = from the list I will forward to the secretariat by Monday. Please send = me a reminder if you do not see such a message until then.=20 =20 Dan =20 =20 =20 =20 ________________________________ From: Mehmet Ersue [mailto:m_ersue@yahoo.de]=20 Sent: Thursday, January 24, 2008 3:19 PM To: Romascanu, Dan (Dan); rbonica@juniper.net Cc: netconf@ops.ietf.org Subject: Request for charter change =09 =09 Dear ADs (and WG), =09 As new WG chairs, we have carefully studied the current WG charter http://www.ietf.org/html.charters/netconf-charter.html =09 Although the date on the charter page states that it was last updated on 2008-01-09, that update was only to list us as new WG chairs and=20 our new Security Advisor. The base text is from a while ago, and in the meanwhile, some documents have completed, and some of the text that has past tense or (future tense) is now better read as being the present. We also adopted a set of WG documents which were based on earlier individual I-Ds, and so we have completed posting of revision 00 documents for our chartered WG work items. =09 We have clarified the text, cleaned it up a bit and we have marked=20 a few items as DONE. We made no substantial change (of course,=20 because that would require WG consensus forming first). =09 ADs, can you please approve that this cleanup charter text be posted=20 as our current WG charter page. Will you forward it to iesg-secretary,=20 or do we need to do so seperately (assuming you will approve)? =09 Bert and Mehmet =09 =09 Attached is the new charter and a rfcdiff of old and new charter. And here is the main body of the cleaned-up charter text: =09 Configuration of networks of devices has become a critical requirement=20 for operators in today's highly interoperable networks. Operators from=20 large to small have developed their own mechanisms or used vendor=20 specific mechanisms to transfer configuration data to and from a=20 device, and for examining device state information which may impact=20 the configuration. Each of these mechanisms may be different in=20 various aspects, such as session establishment, user authentication,=20 configuration data exchange, and error responses.=20 =09 The NETCONF Working Group is chartered to produce a protocol suitable=20 for network configuration, with the following characteristics:=20 =09 - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data=20 - Is extensible enough so that vendors will provide access to all configuration data on the device using a single protocol=20 - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases)=20 - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools.=20 - Supports integration with existing user authentication methods=20 - Supports integration with existing configuration database systems=20 - Supports network wide configuration transactions (with features such as locking and rollback capability)=20 - Is as transport-independent as possible=20 - Provides support for asynchronous notifications.=20 =09 The NETCONF protocol is using XML for data encoding purposes, because=20 XML is a widely deployed standard which is supported by a large number=20 of applications.=20 =09 The NETCONF protocol should be independent of the data definition=20 language and data models used to describe configuration and state=20 data.=20 =09 However, the authorization model used in the protocol is dependent on=20 the data model. Although these issues must be fully addressed to=20 develop standard data models, only a small part of this work will be=20 initially addressed. This group will specify requirements for standard=20 data models in order to fully support the NETCONF protocol, such as:=20 =09 - identification of principals, such as user names or distinguished = names=20 - mechanism to distinguish configuration from non-configuration data=20 - XML namespace conventions=20 - XML usage guidelines=20 =09 The initial work started in 2003 and has already been completed and was = restricted to following items:=20 =09 a) NETCONF Protocol Specification, which defines the operational = model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements.=20 b) NETCONF over SSH Specification: Implementation Mandatory,=20 c) NETCONF over BEEP Specification: Implementation Optional, d) NETCONF over SOAP Specification: Implementation Optional. =09 These documents define how the NETCONF protocol is used with each=20 transport protocol selected by the working group, and how it meets=20 the security and transport layer requirements of the NETCONF Protocol = Specification.=20 =09 e) NETCONF Notification Specification, which defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. NETCONF Notification is an optional capability built on top of the base NETCONF definition and provides the capabilities and operations necessary to support this service. =09 In the current phase of the incremental development of NETCONF the=20 workgroup will focus on following items:=20 =09 1. Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore.=20 =09 2. NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation.=20 =09 3. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to = discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible (this item may be merged with "NETCONF = monitoring" into a single document).=20 =09 4. NETCONF over TLS: Based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for the NETCONF protocol. =09 The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for = work when there is community consensus to take them on:=20 =09 - General improvements to the base protocol=20 - Access Control requirements=20 - NETCONF access to SMI-based MIB data =09 =09 Goals and Milestones: Done Working Group formed=20 Done Submit initial Netconf Protocol draft=20 Done Submit initial Netconf over (transport-TBD) draft=20 Done Begin Working Group Last Call for the Netconf Protocol draft=20 Done Begin Working Group Last Call for the Netconf over = (transport-TBD) draft=20 Done Submit final version of the Netconf Protocol draft to the = IESG=20 Done Submit final version of the Netconf over SOAP draft to the = IESG=20 Done Submit final version of the Netconf over BEEP draft to the = IESG=20 Done Submit final version of the Netconf over SSH draft to the = IESG=20 Done Update charter=20 Done Submit first version of NETCONF Notifications document=20 Done Begin WGLC of NETCONF Notifications document=20 Done Submit final version of NETCONF Notifications document to = IESG for consideration as Proposed Standard=20 Done -00 draft for fine Grain Locking=20 Done -00 draft for NETCONF over TLS=20 Done -00 draft for NETCONF Monitoring=20 Feb 2008 -00 draft for Schema Advertisement=20 Mar 2008 Early Review of client authentication approach (for NETCONF = over TLS) with the security community at IETF 71=20 Aug 2008 WG Last Call on NETCONF Monitoring after IETF72=20 Aug 2008 WG Last Call on Schema Advertisement after IETF72=20 Aug 2008 WG Last Call on Fine Grain Locking after IETF72=20 Aug 2008 WG Last Call on NETCONF over TLS after IETF72=20 Aug 2008 Send four documents to the IESG for consideration as proposed standards =09 =09 =09 ________________________________ Jetzt Mails schnell in einem Vorschaufenster =FCberfliegen. Dies und = viel mehr bietet das neue Yahoo! Mail = .=20 ------_=_NextPart_001_01C85E8C.49E41CAD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This looks fine to me. Unless I hear any comments = and=20 requests to change from the list I will forward to the secretariat by = Monday.=20 Please send me a reminder if you do not see such a message until then.=20
 
Dan
 
 
 
 

From: Mehmet Ersue = [mailto:m_ersue@yahoo.de]=20
Sent: Thursday, January 24, 2008 3:19 PM
To: = Romascanu,=20 Dan (Dan); rbonica@juniper.net
Cc:=20 netconf@ops.ietf.org
Subject: Request for charter=20 change


Dear ADs (and WG),

As new WG chairs, we have carefully = studied=20 the current WG charter
   http://www.ietf.org/html.charters/netconf-charter.html

Although=20 the date on the charter page states that it was last updated
on = 2008-01-09,=20 that update was only to list us as new WG chairs and
our new = Security=20 Advisor. The base text is from a while ago, and
in the meanwhile, = some=20 documents have completed, and some of the
text that has past tense = or=20 (future tense) is now better read as
being the present. We also = adopted a=20 set of WG documents which
were based on earlier individual I-Ds, = and so we=20 have completed
posting of revision 00 documents for our chartered = WG work=20 items.

We have clarified the text, cleaned it up a bit and we = have=20 marked
a few items as DONE. We made no substantial change (of = course,=20
because that would require WG consensus forming = first).

ADs, can=20 you please approve that this cleanup charter text be posted
as our = current=20 WG charter page. Will you forward it to iesg-secretary,
or do we = need to=20 do so seperately (assuming you will approve)?

Bert and=20 Mehmet


Attached is the new charter and a rfcdiff of old and = new=20 charter.
And here is the main body of the cleaned-up charter=20 text:

Configuration of networks of devices has become a = critical=20 requirement
for operators in today's highly interoperable = networks.=20 Operators from
large to small have developed their own mechanisms = or used=20 vendor
specific mechanisms to transfer configuration data to and = from a=20
device, and for examining device state information which may = impact=20
the configuration. Each of these mechanisms may be different in=20
various aspects, such as session establishment, user = authentication,=20
configuration data exchange, and error responses.

The = NETCONF=20 Working Group is chartered to produce a protocol suitable
for = network=20 configuration, with the following characteristics:

- Provides=20 retrieval mechanisms which can differentiate between
  = configuration=20 data and non-configuration data
- Is extensible enough so that = vendors=20 will provide access to all
  configuration data on the device = using a=20 single protocol
- Has a programmatic interface (avoids screen = scraping=20 and
  formatting-related changes between releases)
- Uses = a=20 textual data representation, that can be easily manipulated
  = using=20 non-specialized text manipulation tools.
- Supports integration = with=20 existing user authentication methods
- Supports integration with = existing=20 configuration database systems
- Supports network wide = configuration=20 transactions (with features such
  as locking and rollback = capability)=20
- Is as transport-independent as possible
- Provides support = for=20 asynchronous notifications.

The NETCONF protocol is using XML = for data=20 encoding purposes, because
XML is a widely deployed standard which = is=20 supported by a large number
of applications.

The NETCONF = protocol=20 should be independent of the data definition
language and data = models used=20 to describe configuration and state
data.

However, the=20 authorization model used in the protocol is dependent on
the data = model.=20 Although these issues must be fully addressed to
develop standard = data=20 models, only a small part of this work will be
initially = addressed. This=20 group will specify requirements for standard
data models in order = to fully=20 support the NETCONF protocol, such as:

- identification of = principals,=20 such as user names or distinguished names
- mechanism to = distinguish=20 configuration from non-configuration data
- XML namespace = conventions=20
- XML usage guidelines

The initial work started in 2003 = and has=20 already been completed and was
restricted to following items:=20

  a) NETCONF Protocol Specification, which defines the=20 operational model,
     protocol operations,=20 transaction model, data model = requirements,
    =20 security requirements, and transport layer requirements.
  b) = NETCONF=20 over SSH Specification: Implementation Mandatory,
  c) = NETCONF over=20 BEEP Specification: Implementation Optional,
  d) NETCONF over = SOAP=20 Specification: Implementation Optional.

  These documents = define=20 how the NETCONF protocol is used with each
  transport = protocol=20 selected by the working group, and how it meets
  the = security and=20 transport layer requirements of the NETCONF Protocol
  = Specification.=20

  e) NETCONF Notification Specification, which defines = mechanisms=20 that
     provide an asynchronous message = notification=20 delivery service for
     the NETCONF = protocol. =20 NETCONF Notification is an optional
     = capability=20 built on top of the base NETCONF definition = and
    =20 provides the capabilities and operations necessary to=20 support
     this service.

In the = current phase=20 of the incremental development of NETCONF the
workgroup will focus = on=20 following items:

1. Fine-grain locking: The base NETCONF = protocol only=20 provides a lock
   for the entire configuration = datastore, which=20 is not deemed to meet
   important operational and = security=20 requirements. The NETCONF working
   group will produce a = standards-track RFC specifying a mechanism for
   = fine-grain=20 locking of the NETCONF configuration datastore.

2. NETCONF = monitoring:=20 It is considered best practice for IETF working
   groups = to=20 include management of their protocols within the scope = of
   the=20 solution they are providing. The NETCONF working group = will
  =20 produce a standards-track RFC with mechanisms allowing = NETCONF
  =20 itself to be used to monitor some aspects of NETCONF operation. =

3.=20 Schema advertisement: Currently the NETCONF protocol is able=20 to
   advertise which protocol features are supported on = a=20 particular
   netconf-capable device. However, there is = currently=20 no way to discover
   which XML Schema are supported on = the=20 device. The NETCONF working
   group will produce a=20 standards-track RFC with mechanisms making this
   = discovery=20 possible (this item may be merged with "NETCONF = monitoring"
  =20 into a single document).

4. NETCONF over TLS: Based on = implementation=20 experience there is a
   need for a standards track = document to=20 define NETCONF over TLS as an
   optional transport for = the=20 NETCONF protocol.

The following items have been identified as = important=20 but are currently
not considered in scope for re-chartering and may = be=20 candidates for work
when there is community consensus to take them = on:=20

- General improvements to the base protocol
- Access = Control=20 requirements
- NETCONF access to SMI-based MIB = data


Goals and=20 Milestones:
Done      Working Group formed=20
Done      Submit initial Netconf Protocol = draft=20
Done      Submit initial Netconf over = (transport-TBD)=20 draft
Done      Begin Working Group Last Call = for the=20 Netconf Protocol draft
Done      Begin Working = Group=20 Last Call for the Netconf over=20 = (transport-TBD)
         = =20 draft
Done      Submit final version of the = Netconf=20 Protocol draft to the IESG
Done      Submit = final=20 version of the Netconf over SOAP draft to the IESG =
Done   =20   Submit final version of the Netconf over BEEP draft to the IESG =
Done      Submit final version of the Netconf = over SSH=20 draft to the IESG
Done      Update charter=20
Done      Submit first version of NETCONF=20 Notifications document
Done      Begin WGLC of = NETCONF=20 Notifications document
Done      Submit final = version=20 of NETCONF Notifications document to=20 IESG
          for=20 consideration as Proposed Standard
Done      = -00 draft=20 for fine Grain Locking
Done      -00 draft for = NETCONF=20 over TLS
Done      -00 draft for NETCONF = Monitoring=20
Feb 2008  -00 draft for Schema Advertisement
Mar = 2008  Early=20 Review of client authentication approach (for NETCONF=20 over
          TLS) = with the=20 security community at IETF 71
Aug 2008  WG Last Call on = NETCONF=20 Monitoring after IETF72
Aug 2008  WG Last Call on Schema=20 Advertisement after IETF72
Aug 2008  WG Last Call on Fine = Grain=20 Locking after IETF72
Aug 2008  WG Last Call on NETCONF over = TLS after=20 IETF72
Aug 2008  Send four documents to the IESG for = consideration as=20 proposed
         =20 standards



Jetzt Mails schnell in einem Vorschaufenster =FCberfliegen. Dies und = viel mehr=20 bietet das neue Yahoo! Mail. ------_=_NextPart_001_01C85E8C.49E41CAD-- -- 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 Jan 24 09:41:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI3GU-000551-Is for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 09:41:14 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI3GR-00063T-TC for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 09:41:14 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI35a-0001Tu-PG for netconf-data@psg.com; Thu, 24 Jan 2008 14:29:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.96] (helo=QMTA09.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI35W-0001T9-GO for netconf@ops.ietf.org; Thu, 24 Jan 2008 14:29:56 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA09.westchester.pa.mail.comcast.net with comcast id gzGl1Y0061GhbT8590E100; Thu, 24 Jan 2008 14:29:38 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id h2Vo1Y00X4HwxpC3T00000; Thu, 24 Jan 2008 14:29:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=CjxXgO3LAAAA:8 a=0ofL3cLZzXS3slbSmHwA:9 a=05ZB6yKEcsJH8Ws5lpcA:7 a=ssXPPplgBig3js28PNolixrp0ecA:4 a=4dyfk4FV-b8A:10 a=peF9eE_zjQwA:10 a=50e4U0PicR4A:10 a=wnkUB5U5BCEuFGhzy1kA:9 a=fuklZzVcPBYAM-HyI8kA:7 a=ue46u17d3niwHHzF14Evi5a_JB4A:4 a=AfD3MYMu9mQA:10 From: "David B Harrington" To: "'Mehmet Ersue'" , , Cc: References: <981942.20935.qm@web27808.mail.ukl.yahoo.com> Subject: RE: Request for charter change Date: Thu, 24 Jan 2008 09:29:48 -0500 Message-ID: <01e601c85e95$93c66550$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E7_01C85E6B.AAF05D50" X-Mailer: Microsoft Office Outlook 11 In-reply-to: <981942.20935.qm@web27808.mail.ukl.yahoo.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AchejVdpL3G1tHgXRYSwFs0XE80QTgACAuUw Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596 This is a multi-part message in MIME format. ------=_NextPart_000_01E7_01C85E6B.AAF05D50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I have reviewed the charter changes and they look good to me. Thank you. =20 dbh _____ =20 From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Mehmet Ersue Sent: Thursday, January 24, 2008 8:19 AM To: dromasca@avaya.com; rbonica@juniper.net Cc: netconf@ops.ietf.org Subject: Request for charter change Dear ADs (and WG), As new WG chairs, we have carefully studied the current WG charter http://www.ietf.org/html.charters/netconf-charter.html Although the date on the charter page states that it was last updated on 2008-01-09, that update was only to list us as new WG chairs and=20 our new Security Advisor. The base text is from a while ago, and in the meanwhile, some documents have completed, and some of the text that has past tense or (future tense) is now better read as being the present. We also adopted a set of WG documents which were based on earlier individual I-Ds, and so we have completed posting of revision 00 documents for our chartered WG work items. We have clarified the text, cleaned it up a bit and we have marked=20 a few items as DONE. We made no substantial change (of course,=20 because that would require WG consensus forming first). ADs, can you please approve that this cleanup charter text be posted=20 as our current WG charter page. Will you forward it to iesg-secretary, or do we need to do so seperately (assuming you will approve)? Bert and Mehmet Attached is the new charter and a rfcdiff of old and new charter. And here is the main body of the cleaned-up charter text: Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor=20 specific mechanisms to transfer configuration data to and from a=20 device, and for examining device state information which may impact=20 the configuration. Each of these mechanisms may be different in=20 various aspects, such as session establishment, user authentication,=20 configuration data exchange, and error responses.=20 The NETCONF Working Group is chartered to produce a protocol suitable=20 for network configuration, with the following characteristics:=20 - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data=20 - Is extensible enough so that vendors will provide access to all configuration data on the device using a single protocol=20 - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases)=20 - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools.=20 - Supports integration with existing user authentication methods=20 - Supports integration with existing configuration database systems=20 - Supports network wide configuration transactions (with features such as locking and rollback capability)=20 - Is as transport-independent as possible=20 - Provides support for asynchronous notifications.=20 The NETCONF protocol is using XML for data encoding purposes, because=20 XML is a widely deployed standard which is supported by a large number of applications.=20 The NETCONF protocol should be independent of the data definition=20 language and data models used to describe configuration and state=20 data.=20 However, the authorization model used in the protocol is dependent on=20 the data model. Although these issues must be fully addressed to=20 develop standard data models, only a small part of this work will be=20 initially addressed. This group will specify requirements for standard data models in order to fully support the NETCONF protocol, such as:=20 - identification of principals, such as user names or distinguished names=20 - mechanism to distinguish configuration from non-configuration data=20 - XML namespace conventions=20 - XML usage guidelines=20 The initial work started in 2003 and has already been completed and was=20 restricted to following items:=20 a) NETCONF Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements.=20 b) NETCONF over SSH Specification: Implementation Mandatory,=20 c) NETCONF over BEEP Specification: Implementation Optional, d) NETCONF over SOAP Specification: Implementation Optional. These documents define how the NETCONF protocol is used with each=20 transport protocol selected by the working group, and how it meets=20 the security and transport layer requirements of the NETCONF Protocol=20 Specification.=20 e) NETCONF Notification Specification, which defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. NETCONF Notification is an optional capability built on top of the base NETCONF definition and provides the capabilities and operations necessary to support this service. In the current phase of the incremental development of NETCONF the=20 workgroup will focus on following items:=20 1. Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore.=20 2. NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation.=20 3. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible (this item may be merged with "NETCONF monitoring" into a single document).=20 4. NETCONF over TLS: Based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for the NETCONF protocol. The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for work when there is community consensus to take them on:=20 - General improvements to the base protocol=20 - Access Control requirements=20 - NETCONF access to SMI-based MIB data Goals and Milestones: Done Working Group formed=20 Done Submit initial Netconf Protocol draft=20 Done Submit initial Netconf over (transport-TBD) draft=20 Done Begin Working Group Last Call for the Netconf Protocol draft Done Begin Working Group Last Call for the Netconf over (transport-TBD) draft=20 Done Submit final version of the Netconf Protocol draft to the IESG=20 Done Submit final version of the Netconf over SOAP draft to the IESG=20 Done Submit final version of the Netconf over BEEP draft to the IESG=20 Done Submit final version of the Netconf over SSH draft to the IESG=20 Done Update charter=20 Done Submit first version of NETCONF Notifications document=20 Done Begin WGLC of NETCONF Notifications document=20 Done Submit final version of NETCONF Notifications document to IESG for consideration as Proposed Standard=20 Done -00 draft for fine Grain Locking=20 Done -00 draft for NETCONF over TLS=20 Done -00 draft for NETCONF Monitoring=20 Feb 2008 -00 draft for Schema Advertisement=20 Mar 2008 Early Review of client authentication approach (for NETCONF over TLS) with the security community at IETF 71=20 Aug 2008 WG Last Call on NETCONF Monitoring after IETF72=20 Aug 2008 WG Last Call on Schema Advertisement after IETF72=20 Aug 2008 WG Last Call on Fine Grain Locking after IETF72=20 Aug 2008 WG Last Call on NETCONF over TLS after IETF72=20 Aug 2008 Send four documents to the IESG for consideration as proposed standards _____ =20 Jetzt Mails schnell in einem Vorschaufenster =FCberfliegen. Dies und viel mehr bietet das neue Yahoo! Mail .=20 ------=_NextPart_000_01E7_01C85E6B.AAF05D50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have reviewed the charter changes and they = look good to=20 me.
Thank you.
 
dbh

From: owner-netconf@ops.ietf.org=20 [mailto:owner-netconf@ops.ietf.org] On Behalf Of Mehmet=20 Ersue
Sent: Thursday, January 24, 2008 8:19 AM
To: = dromasca@avaya.com; rbonica@juniper.net
Cc:=20 netconf@ops.ietf.org
Subject: Request for charter=20 change


Dear ADs (and WG),

As new WG chairs, we have carefully = studied=20 the current WG charter
   http://www.ietf.org/html.charters/netconf-charter.html

Although=20 the date on the charter page states that it was last updated
on = 2008-01-09,=20 that update was only to list us as new WG chairs and
our new = Security=20 Advisor. The base text is from a while ago, and
in the meanwhile, = some=20 documents have completed, and some of the
text that has past tense = or=20 (future tense) is now better read as
being the present. We also = adopted a=20 set of WG documents which
were based on earlier individual I-Ds, = and so we=20 have completed
posting of revision 00 documents for our chartered = WG work=20 items.

We have clarified the text, cleaned it up a bit and we = have=20 marked
a few items as DONE. We made no substantial change (of = course,=20
because that would require WG consensus forming = first).

ADs, can=20 you please approve that this cleanup charter text be posted
as our = current=20 WG charter page. Will you forward it to iesg-secretary,
or do we = need to=20 do so seperately (assuming you will approve)?

Bert and=20 Mehmet


Attached is the new charter and a rfcdiff of old and = new=20 charter.
And here is the main body of the cleaned-up charter=20 text:

Configuration of networks of devices has become a = critical=20 requirement
for operators in today's highly interoperable = networks.=20 Operators from
large to small have developed their own mechanisms = or used=20 vendor
specific mechanisms to transfer configuration data to and = from a=20
device, and for examining device state information which may = impact=20
the configuration. Each of these mechanisms may be different in=20
various aspects, such as session establishment, user = authentication,=20
configuration data exchange, and error responses.

The = NETCONF=20 Working Group is chartered to produce a protocol suitable
for = network=20 configuration, with the following characteristics:

- Provides=20 retrieval mechanisms which can differentiate between
  = configuration=20 data and non-configuration data
- Is extensible enough so that = vendors=20 will provide access to all
  configuration data on the device = using a=20 single protocol
- Has a programmatic interface (avoids screen = scraping=20 and
  formatting-related changes between releases)
- Uses = a=20 textual data representation, that can be easily manipulated
  = using=20 non-specialized text manipulation tools.
- Supports integration = with=20 existing user authentication methods
- Supports integration with = existing=20 configuration database systems
- Supports network wide = configuration=20 transactions (with features such
  as locking and rollback = capability)=20
- Is as transport-independent as possible
- Provides support = for=20 asynchronous notifications.

The NETCONF protocol is using XML = for data=20 encoding purposes, because
XML is a widely deployed standard which = is=20 supported by a large number
of applications.

The NETCONF = protocol=20 should be independent of the data definition
language and data = models used=20 to describe configuration and state
data.

However, the=20 authorization model used in the protocol is dependent on
the data = model.=20 Although these issues must be fully addressed to
develop standard = data=20 models, only a small part of this work will be
initially = addressed. This=20 group will specify requirements for standard
data models in order = to fully=20 support the NETCONF protocol, such as:

- identification of = principals,=20 such as user names or distinguished names
- mechanism to = distinguish=20 configuration from non-configuration data
- XML namespace = conventions=20
- XML usage guidelines

The initial work started in 2003 = and has=20 already been completed and was
restricted to following items:=20

  a) NETCONF Protocol Specification, which defines the=20 operational model,
     protocol operations,=20 transaction model, data model = requirements,
    =20 security requirements, and transport layer requirements.
  b) = NETCONF=20 over SSH Specification: Implementation Mandatory,
  c) = NETCONF over=20 BEEP Specification: Implementation Optional,
  d) NETCONF over = SOAP=20 Specification: Implementation Optional.

  These documents = define=20 how the NETCONF protocol is used with each
  transport = protocol=20 selected by the working group, and how it meets
  the = security and=20 transport layer requirements of the NETCONF Protocol
  = Specification.=20

  e) NETCONF Notification Specification, which defines = mechanisms=20 that
     provide an asynchronous message = notification=20 delivery service for
     the NETCONF = protocol. =20 NETCONF Notification is an optional
     = capability=20 built on top of the base NETCONF definition = and
    =20 provides the capabilities and operations necessary to=20 support
     this service.

In the = current phase=20 of the incremental development of NETCONF the
workgroup will focus = on=20 following items:

1. Fine-grain locking: The base NETCONF = protocol only=20 provides a lock
   for the entire configuration = datastore, which=20 is not deemed to meet
   important operational and = security=20 requirements. The NETCONF working
   group will produce a = standards-track RFC specifying a mechanism for
   = fine-grain=20 locking of the NETCONF configuration datastore.

2. NETCONF = monitoring:=20 It is considered best practice for IETF working
   groups = to=20 include management of their protocols within the scope = of
   the=20 solution they are providing. The NETCONF working group = will
  =20 produce a standards-track RFC with mechanisms allowing = NETCONF
  =20 itself to be used to monitor some aspects of NETCONF operation. =

3.=20 Schema advertisement: Currently the NETCONF protocol is able=20 to
   advertise which protocol features are supported on = a=20 particular
   netconf-capable device. However, there is = currently=20 no way to discover
   which XML Schema are supported on = the=20 device. The NETCONF working
   group will produce a=20 standards-track RFC with mechanisms making this
   = discovery=20 possible (this item may be merged with "NETCONF = monitoring"
  =20 into a single document).

4. NETCONF over TLS: Based on = implementation=20 experience there is a
   need for a standards track = document to=20 define NETCONF over TLS as an
   optional transport for = the=20 NETCONF protocol.

The following items have been identified as = important=20 but are currently
not considered in scope for re-chartering and may = be=20 candidates for work
when there is community consensus to take them = on:=20

- General improvements to the base protocol
- Access = Control=20 requirements
- NETCONF access to SMI-based MIB = data


Goals and=20 Milestones:
Done      Working Group formed=20
Done      Submit initial Netconf Protocol = draft=20
Done      Submit initial Netconf over = (transport-TBD)=20 draft
Done      Begin Working Group Last Call = for the=20 Netconf Protocol draft
Done      Begin Working = Group=20 Last Call for the Netconf over=20 = (transport-TBD)
         = =20 draft
Done      Submit final version of the = Netconf=20 Protocol draft to the IESG
Done      Submit = final=20 version of the Netconf over SOAP draft to the IESG =
Done   =20   Submit final version of the Netconf over BEEP draft to the IESG =
Done      Submit final version of the Netconf = over SSH=20 draft to the IESG
Done      Update charter=20
Done      Submit first version of NETCONF=20 Notifications document
Done      Begin WGLC of = NETCONF=20 Notifications document
Done      Submit final = version=20 of NETCONF Notifications document to=20 IESG
          for=20 consideration as Proposed Standard
Done      = -00 draft=20 for fine Grain Locking
Done      -00 draft for = NETCONF=20 over TLS
Done      -00 draft for NETCONF = Monitoring=20
Feb 2008  -00 draft for Schema Advertisement
Mar = 2008  Early=20 Review of client authentication approach (for NETCONF=20 over
          TLS) = with the=20 security community at IETF 71
Aug 2008  WG Last Call on = NETCONF=20 Monitoring after IETF72
Aug 2008  WG Last Call on Schema=20 Advertisement after IETF72
Aug 2008  WG Last Call on Fine = Grain=20 Locking after IETF72
Aug 2008  WG Last Call on NETCONF over = TLS after=20 IETF72
Aug 2008  Send four documents to the IESG for = consideration as=20 proposed
         =20 standards



Jetzt Mails schnell in einem Vorschaufenster =FCberfliegen. Dies und = viel mehr=20 bietet das neue Yahoo! Mail. ------=_NextPart_000_01E7_01C85E6B.AAF05D50-- -- 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 Jan 24 12:24:22 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI5oM-0005Gm-Kf for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 12:24:22 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI5oK-0003mG-GM for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 12:24:22 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI5du-000Msb-Je for netconf-data@psg.com; Thu, 24 Jan 2008 17:13:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI5dr-000Mrj-Dl for netconf@ops.ietf.org; Thu, 24 Jan 2008 17:13:33 +0000 Received: (qmail 38659 invoked from network); 24 Jan 2008 17:13:28 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 24 Jan 2008 17:13:28 -0000 From: "Bert Wijnen" To: "tom.petch" , "Netconf \(E-mail\)" Subject: RE: quick check of notification-11 Date: Thu, 24 Jan 2008 18:13:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <02e701c840d1$5d512280$0601a8c0@pc6> Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Tom, as netconf-noticiation document shepherd, I am checking all (possibly still) outsanding comments. I think that the one from you (below) is still unanswered. My comments questions inline Bert Wijnen > -----Oorspronkelijk bericht----- > Van: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org]Namens tom.petch > Verzonden: maandag 17 december 2007 16:18 > Aan: Andy Bierman; Netconf (E-mail) > Onderwerp: Re: quick check of notification-11 > > > A minor quirk - I see a missing solidus in 3.2.5.1 > " > > > " > I think you mean that the last tag should be a closing tag: ? So the above 3 lines should read: " right? > and an uncertainty - the I-D does not register the XML Schema defined in > sections 4 and 3.4, just their targetNamespace; is this intentional? > Not sure yet. I need to check. Andy (or netconf-monitoring authors, can you pls comment? > Also in IANA considerations, it might be clearer if the > registration of the capability urn refers to the named registry > created by RFC4741 s.10.3; obvious to those up to their ears in > netconf, perhaps less so to those with an IANA-wide remit. > I think you are ricght. Re-reading the IANA considerations in this draft and also in RFC4741, maybe that section should be rewritten as: 8. IANA Considerations 8.1 NETCONF XML Namespace This document registers a URI for the NETCONF XML namespace [RFC4741, section 10.1) in the IETF XML registry [RFC3688]. Following the format in RFC 3688, IANA has made the following registration: URI: urn:ietf:params:xml:ns:netconf:notification:1.0 Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. 8.2 ?? 8.3 NETCONF Capability URNs This document registers URNs for the the following NETCONF capabilities in the netconf registry (RFC4741], sect 10.3): +--------------------+----------------------------------------------+ | Index | Capability Identifier | +--------------------+----------------------------------------------+ | :notification | urn:ietf:params:netconf:capability: | | | notification:1.0 | | | running:1.0 | | | | | :interleave | urn:ietf:params:netconf:capability: | | | interleave:1.0 | +--------------------+----------------------------------------------+ I am not sure (yet) where to put the following. Is that part of the NETCONF XML namespace (i.e. should it go in sect 8.1 above?): URI: urn:ietf:params:xml:ns:netmod:notification Anyway, Tom, is this the direction you were looking for? Any comments from authors or WG participants? Bert > Tom Petch > > -- 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 netcondb@netcond.com.br Thu Jan 24 15:29:44 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8hk-0000fy-4O for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 15:29:44 -0500 Received: from bb116-14-157-11.singnet.com.sg ([116.14.157.11] helo=hppav) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JI8hj-0002WC-5h for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 15:29:44 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 24419 by uid 186); Fri, 25 Jan 2008 04:29:48 +0800 Message-Id: <20080125122948.24421.qmail@hppav> To: Subject: January 77% OFF From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
From owner-netconf@ops.ietf.org Thu Jan 24 18:49:22 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIBow-0006zd-OO for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 18:49:22 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIBou-0003s9-V8 for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 18:49:22 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIBhf-000D17-6z for netconf-data@psg.com; Thu, 24 Jan 2008 23:41:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIBhU-000Cyy-DD for netconf@ops.ietf.org; Thu, 24 Jan 2008 23:41:41 +0000 Received: (qmail 16717 invoked from network); 24 Jan 2008 23:41:35 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 24 Jan 2008 23:41:35 -0000 From: "Bert Wijnen" To: Subject: comments on draft-ietf-netconf-partial-lock-00 Date: Fri, 25 Jan 2008 00:41:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Commenting as a technical contributor. These are however mainly/initial editorial comments that you can consider for the next revision. - sect 1 Partial locking will be introduced as a capability to NETCONF. I think I would prefer Partial locking is defined as a capability to NETCONF. or some such. So do not speak in the future - Sect 1.1 Need to add a citation to RFC2119, and then add RFC2119 to the normative references. - sect 2.1 The system will ensure that configuration resources covered by the lock will not be modified by other NETCONF or non-NETCONF management operations such as SNMP and the CLI. I think it would be better to not speak in the future. So I would do The system ensures... lock can not be modified ,,, Or some such - Sect 2.2 If the :xpath capability is supported, the filter expressions can be full XPath 1.0 expressions. This may be a good place to also add some text on how the filter experssions are limited if :xpath capability is not supported. - page 12 target: Name of the configuration datastore of which a part will be locked. URIs are not accepted. Did you mean "url" instead of URI? In rfc4741 in sect 8.8 we speak of "URL capability" that allows urls to be used for target. We should try to be consistent in our usage of terms. - section 4, IANA considerations. The capability's URI should be registered by IANA. I would make this somewhat more explicit. Something aka This document registers a URN for the the following NETCONF capability in the netconf registry (RFC4741], sect 10.3): +--------------------+----------------------------------------------+ | Index | Capability Identifier | +--------------------+----------------------------------------------+ | :partial-lock | urn:ietf:params:netconf:capability:partial- | | | lock:1.0 | +--------------------+----------------------------------------------+ - Overall Bert Wijnen -- 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 net@confhotel.hu Thu Jan 24 20:10:48 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JID5k-0000g4-7t for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 20:10:48 -0500 Received: from [201.170.208.10] (helo=NALIN) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JID5i-00023x-W7 for netconf-archive@lists.ietf.org; Thu, 24 Jan 2008 20:10:48 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 6590 by uid 186); Thu, 24 Jan 2008 05:10:58 -0800 Message-Id: <20080124-31058.6592.qmail@NALIN> To: Subject: January 70% OFF From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
From owner-netconf@ops.ietf.org Fri Jan 25 04:28:35 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIKrT-0000n8-PH for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 04:28:35 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIKrR-0000We-Ch for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 04:28:35 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIKjB-000FqC-Qj for netconf-data@psg.com; Fri, 25 Jan 2008 09:20:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIKj9-000FpU-6W for netconf@ops.ietf.org; Fri, 25 Jan 2008 09:20:00 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 117EC8A2DF; Fri, 25 Jan 2008 10:19:57 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22728-04-5; Fri, 25 Jan 2008 10:19:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F34A5AD24; Fri, 25 Jan 2008 10:19:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1484348AAB9; Fri, 25 Jan 2008 10:19:47 +0100 (CET) Date: Fri, 25 Jan 2008 10:19:46 +0100 From: Juergen Schoenwaelder To: yang@ietf.org, netconf@ops.ietf.org Subject: Re: [YANG] errors Message-ID: <20080125091946.GA17440@elstar.local> Reply-To: netconf@ops.ietf.org Mail-Followup-To: yang@ietf.org, netconf@ops.ietf.org References: <20080124.153853.210376606.mbj@tail-f.com> <4798BFCD.3000706@andybierman.com> <20080124.185012.212081588.mbj@tail-f.com> <20080124193906.GB16515@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080124193906.GB16515@elstar.local> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Thu, Jan 24, 2008 at 08:39:06PM +0100, Juergen Schoenwaelder wrote: > Did I mention that it would be nice to have a NETCONF maintenance > activity? Even if it is just a web page to keep track of the issues > until the IETF gets to it? I started a wiki page to track NETCONF RFC 4741 issues. http://cnds.eecs.jacobs-university.de/wiki/NETCONF It is currently in its infancy so please send me your favourite bugs and I will happily add them to the wiki page. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- 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 Jan 25 05:06:18 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILRy-00080h-5P for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 05:06:18 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JILRx-0001n3-J7 for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 05:06:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JILLt-000K6j-17 for netconf-data@psg.com; Fri, 25 Jan 2008 10:00:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JILLm-000K65-5F for netconf@ops.ietf.org; Fri, 25 Jan 2008 09:59:55 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id BD3D71B80D7; Fri, 25 Jan 2008 10:59:52 +0100 (CET) Date: Fri, 25 Jan 2008 11:01:19 +0100 (CET) Message-Id: <20080125.110119.211713651.mbj@tail-f.com> To: netconf@ops.ietf.org, j.schoenwaelder@jacobs-university.de Cc: yang@ietf.org Subject: Re: [YANG] errors From: Martin Bjorklund In-Reply-To: <20080125091946.GA17440@elstar.local> References: <20080124.185012.212081588.mbj@tail-f.com> <20080124193906.GB16515@elstar.local> <20080125091946.GA17440@elstar.local> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi Juergen, Juergen Schoenwaelder wrote: > I started a wiki page to track NETCONF RFC 4741 issues. > > http://cnds.eecs.jacobs-university.de/wiki/NETCONF There's also: http://www3.tools.ietf.org/wg/netconf/trac/report/1 Do we need both? /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jan 25 05:09:47 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILVL-00017M-Tk for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 05:09:47 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JILVL-0001sU-HR for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 05:09:47 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JILRB-000Kjv-H2 for netconf-data@psg.com; Fri, 25 Jan 2008 10:05:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JILR8-000KjZ-Sq for netconf@ops.ietf.org; Fri, 25 Jan 2008 10:05:28 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B9788A1A3; Fri, 25 Jan 2008 11:05:26 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 26953-02-8; Fri, 25 Jan 2008 11:05:21 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 601B08A2DF; Fri, 25 Jan 2008 11:04:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 475CB48AB90; Fri, 25 Jan 2008 11:04:35 +0100 (CET) Date: Fri, 25 Jan 2008 11:04:35 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: netconf@ops.ietf.org, yang@ietf.org Subject: Re: [YANG] errors Message-ID: <20080125100435.GA17475@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: Martin Bjorklund , netconf@ops.ietf.org, yang@ietf.org References: <20080124.185012.212081588.mbj@tail-f.com> <20080124193906.GB16515@elstar.local> <20080125091946.GA17440@elstar.local> <20080125.110119.211713651.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080125.110119.211713651.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Fri, Jan 25, 2008 at 11:01:19AM +0100, Martin Bjorklund wrote: > Hi Juergen, > > Juergen Schoenwaelder wrote: > > I started a wiki page to track NETCONF RFC 4741 issues. > > > > http://cnds.eecs.jacobs-university.de/wiki/NETCONF > > There's also: > > http://www3.tools.ietf.org/wg/netconf/trac/report/1 > > Do we need both? No, I did not know that this exists. Who is putting stuff on there? I am happy to kill my page on favour of this one... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- 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 Jan 25 05:12:23 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILXr-000451-4N for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 05:12:23 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JILXq-0001v9-QU for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 05:12:23 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JILTq-000L7M-KO for netconf-data@psg.com; Fri, 25 Jan 2008 10:08:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00, MISSING_HEADERS autolearn=no version=3.2.3 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JILTn-000L6P-W3 for netconf@ops.ietf.org; Fri, 25 Jan 2008 10:08:13 +0000 Received: from localhost ([127.0.0.1]:35227 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1JILTk-0001Xz-ON; Fri, 25 Jan 2008 11:08:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Fri, 25 Jan 2008 10:08:08 -0000 Reply-To: netconf@ops.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #18: error-severity warning problem X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/netconf/trac/ticket/18 Message-ID: <064.600378f0f3d116d357402c631bd20ea4@tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mbj@tail-f.com, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 IzE4OiBlcnJvci1zZXZlcml0eSB3YXJuaW5nIHByb2JsZW0NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiBSZXBvcnRlcjogIG1iakB0YWlsLWYuY29tICB8ICAgICAgIE93bmVyOiAgICAgDQogICAgIFR5 cGU6ICBkZWZlY3QgICAgICAgICAgfCAgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFq b3IgICAgICAgICAgIHwgICBNaWxlc3RvbmU6ICAgICANCkNvbXBvbmVudDogIFJGQzQ3NDEgICAg ICAgICB8ICAgICBWZXJzaW9uOiAgICAgDQogS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgfCAg DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogQW4gcnBjLWVycm9yIE1VU1QgaW5jbHVkZSBlcnJvci10 YWcuIFRoZSBsaXN0IG9mIGVycm9yLXRhZ3MgaXMgZGVmaW5lZCBpbg0KIFJGQyA0NzQxLiBGb3Ig ZWFjaCBzdWNoIHRhZywgdGhlIGNvcnJlc3BvbmRpbmcgZXJyb3Itc2V2ZXJpdHkgaXMgZGVmaW5l ZC4NCiBBbGwgdGFncyBoYXZlIGVycm9yLXNldmVyaXR5ICdlcnJvcicuIENvbmNsdXNpb246IGVy cm9yLXNldmVyaXR5ICd3YXJuaW5nJw0KIGNhbiBuZXZlciBiZSBnZW5lcmF0ZWQuICEhPyE/IQ0K DQotLSANClRpY2tldCBVUkw6IDxodHRwOi8vd3d3My50b29scy5pZXRmLm9yZy93Zy9uZXRjb25m L3RyYWMvdGlja2V0LzE4Pg0KTmV0Y29uZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNv bmYvdHJhYy8+DQpJc3N1ZSB0cmFja2VyIGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- 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 Jan 25 05:15:29 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILar-0001C0-Ap for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 05:15:29 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JILaq-0001yK-SV for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 05:15:29 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JILWC-000LMJ-TH for netconf-data@psg.com; Fri, 25 Jan 2008 10:10:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [213.180.94.162] (helo=mail.tail-f.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JILWA-000LLe-85 for netconf@ops.ietf.org; Fri, 25 Jan 2008 10:10:39 +0000 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 57BD81B80D7; Fri, 25 Jan 2008 11:10:37 +0100 (CET) Date: Fri, 25 Jan 2008 11:12:03 +0100 (CET) Message-Id: <20080125.111203.133760488.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: netconf@ops.ietf.org, yang@ietf.org Subject: Re: [YANG] errors From: Martin Bjorklund In-Reply-To: <20080125100435.GA17475@elstar.local> References: <20080125091946.GA17440@elstar.local> <20080125.110119.211713651.mbj@tail-f.com> <20080125100435.GA17475@elstar.local> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Juergen Schoenwaelder wrote: > On Fri, Jan 25, 2008 at 11:01:19AM +0100, Martin Bjorklund wrote: > > Hi Juergen, > > > > Juergen Schoenwaelder wrote: > > > I started a wiki page to track NETCONF RFC 4741 issues. > > > > > > http://cnds.eecs.jacobs-university.de/wiki/NETCONF > > > > There's also: > > > > http://www3.tools.ietf.org/wg/netconf/trac/report/1 > > > > Do we need both? > > No, I did not know that this exists. Who is putting stuff on there? You! Me! You just have to register. But as you can see, all tickets were created last summer, and since then not much has happend. I just added a ticket for the error-severity problem. /martin -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jan 25 06:26:59 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIMi3-0003do-1V for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 06:26:59 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIMi2-0003HR-49 for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 06:26:59 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIMZL-0002Qr-Vp for netconf-data@psg.com; Fri, 25 Jan 2008 11:18:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE,USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [217.146.182.8] (helo=web27803.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIMZJ-0002QP-14 for netconf@ops.ietf.org; Fri, 25 Jan 2008 11:17:58 +0000 Received: (qmail 8044 invoked by uid 60001); 25 Jan 2008 11:17:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=a5OohzT3+1+NgR+/Oj4dxp0OEga7i23o7mU9G1yJ+IY+cae9oOCpXGD283ofGgZQ1SaX9YUWLOtuxUYnkX2ugm2kr21fslaR14MFEUi/k7HIp23mAtZWhLlqTowyGXtoF//kmkmBBQi+YVXralIVzLlK9wssXKlHR/eTCyqjmCc=; X-YMail-OSG: CsVQz98VM1kMIv1LMqmQmHTLCV0YZk94ijeq6wpyi.bpNR90NPlXKMNWFpFjDr5pHtdDMIIjEFvMsRfWG5H2RTrNrShfFuOjw7RibBAaNiVjpuuH2dBSngeHB7A- Received: from [217.115.75.231] by web27803.mail.ukl.yahoo.com via HTTP; Fri, 25 Jan 2008 11:17:55 GMT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.160 Date: Fri, 25 Jan 2008 11:17:55 +0000 (GMT) From: Mehmet Ersue Reply-To: Mehmet Ersue Subject: Netconf issue tracker WAS: Re: [YANG] errors To: j.schoenwaelder@jacobs-university.de, Martin Cc: NETCONF , yang@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1683349822-1201259875=:5155" Message-ID: <851758.5155.qm@web27803.mail.ukl.yahoo.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 --0-1683349822-1201259875=:5155 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0AHi Juergen, All,=0A=0AI think it's a good idea to have the issues on a c= entral place and=0Ato use the existing page on Netconf Wiki. We are going t= o clean =0Ait up soon.=0A=0AIn parallel the additional Netconf page will be= moved from =0Ahttp://www.ops.ietf.org/netconf/ to http://www3.tools.ietf.o= rg/wg/netconf/trac/wiki.=0A=0ACheers, =0AMehmet =0A =0A=0A> -----Original M= essage-----=0A> From: ext Juergen Schoenwaelder =0A> [mailto:j.schoenwaelde= r@jacobs-university.de] =0A> Sent: Friday, January 25, 2008 11:05 AM=0A> To= : Martin Bjorklund=0A> Cc: yang@ietf.org; netconf@ops.ietf.org=0A> Subject:= Re: [YANG]=0A errors=0A> =0A> On Fri, Jan 25, 2008 at 11:01:19AM +0100, Ma= rtin Bjorklund wrote:=0A> > Hi Juergen,=0A> > =0A> > Juergen Schoenwaelder = wrote:=0A> > > I started a wiki page= to track NETCONF RFC 4741 issues. =0A> > > =0A> > > http://cnds.eecs.jacob= s-university.de/wiki/NETCONF=0A> > =0A> > There's also:=0A> > =0A> > http:/= /www3.tools.ietf.org/wg/netconf/trac/report/1=0A> > =0A> > Do we need both?= =0A> =0A> No, I did not know that this exists. Who is putting stuff on ther= e? I=0A> am happy to kill my page on favour of this one...=0A> =0A> /js=0A>= =0A> -- =0A> Juergen=0A Schoenwaelder Jacobs University Bremen g= GmbH=0A> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germa= ny=0A> Fax: +49 421 200 3103 = =0A> =0A> =0A> _______________________________________________=0A> YANG mai= ling list=0A> YANG@ietf.org=0A> https://www1.ietf.org/mailman/listinfo/yang= =0A> =0A=0A=0A=0A=0A=0A __________________________________ Ihr erstes= Fernweh? Wo gibt es den sch=C3=B6nsten Strand? www.yahoo.de/clever --0-1683349822-1201259875=:5155 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Juergen, All,

I think it's a good idea to have the issu= es on a central place and
to use the existing page on Netconf Wiki. We a= re going to clean
it up soon.

In parallel the additional Netconf= page will be moved from
http://www.ops.ietf.org/netconf/ to http://www3.tools.ietf.org/wg/netconf/trac/wiki.

Cheers,
Mehmet


> -----Original Message= -----
> From: ext Juergen Schoenwaelder
> [mailto:j.schoenwael= der@jacobs-university.de]
> Sent: Friday, January 25, 2008 11:05 AM<= br>> To: Martin Bjorklund
> Cc: yang@ietf.org; netconf@ops.ietf.org
> S= ubject: Re: [YANG]=0A errors
>
> On Fri, Jan 25, 2008 at 11:01= :19AM +0100, Martin Bjorklund wrote:
> > Hi Juergen,
> > =
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.d= e> wrote:
> > > I started a wiki page to track NETCONF RFC 4= 741 issues.
> > >
> > > http://cnds.eecs.jacobs-university.de/wiki/NETCONF
> &= gt;
> > There's also:
> >
> > http://www3.tools.ietf.org/wg/netconf/trac/report/1
> >
> > Do we need both?
>
> No, I did no= t know that this exists. Who is putting stuff on there? I
> am happy = to kill my page on favour of this one...
>
> /js
>
&= gt; --
> Juergen=0A Schoenwaelder      = ;     Jacobs University Bremen gGmbH
> Phone: +49= 421 200 3587         Campus Ring 1= , 28759 Bremen, Germany
> Fax:   +49 421 200 3103&nbs= p;        <http://www.jacobs-uni= versity.de/>
>
>
> ______________________= _________________________
> YANG mailing list
> YANG@ietf.org> https://www1.ietf.org/mailman/listinfo/yang
>

=0A=0A=0A=0A
H= eute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie=C2= =B4s mit dem =0Aneuen Yahoo! Mail. =0A<= /body> --0-1683349822-1201259875=:5155-- -- 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 Jan 25 06:53:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIN7X-0001Mg-Fd for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 06:53:19 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIN7V-0003n7-2t for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 06:53:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIN1a-0005jN-Tn for netconf-data@psg.com; Fri, 25 Jan 2008 11:47:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.74.114.38] (helo=mk-outboundfilter-2.mail.uk.tiscali.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIN1Y-0005j0-0b for netconf@ops.ietf.org; Fri, 25 Jan 2008 11:47:09 +0000 X-Trace: 17590664/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIpamUc+8aMG/2dsb2JhbACKTaQP X-IP-Direction: IN Received: from astro.systems.pipex.net ([62.241.163.6]) by smtp.pipex.tiscali.co.uk with ESMTP; 25 Jan 2008 11:47:06 +0000 Received: from pc6 (1Cust181.tnt13.lnd4.gbr.da.uu.net [62.188.142.181]) by astro.systems.pipex.net (Postfix) with SMTP id 67390E000085; Fri, 25 Jan 2008 11:47:03 +0000 (GMT) Message-ID: <01bb01c85f3f$60ebbea0$0601a8c0@pc6> Reply-To: "tom.petch" From: "tom.petch" To: "Bert Wijnen" , "Netconf \(E-mail\)" References: Subject: Re: quick check of notification-11 Date: Fri, 25 Jan 2008 10:26:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Bert Yes, I agree, I think these are unresolved and that your suggestions are good. I would be inclined to say "Following the format in RFC 3688, IANA is requested to make the following registration " rather than "Following the format in RFC 3688, IANA has made the following registration" thinking that the former is politer - but then IANA my prefer to have the words put in their mouth:-) (I will ask them one day). netmod is the to-be-created Netconf data model, much discussed in 2004/5; you will find that the URI for it was issue 7 in the tracker in July 2007. I think it should be kept quite distinct from the other netconf URI until and when it takes a more concrete form. Tom Petch ----- Original Message ----- From: "Bert Wijnen" To: "tom.petch" ; "Netconf (E-mail)" Sent: Thursday, January 24, 2008 6:13 PM Subject: RE: quick check of notification-11 > Tom, as netconf-noticiation document shepherd, I am checking > all (possibly still) outsanding comments. I think that the > one from you (below) is still unanswered. > > My comments questions inline > > Bert Wijnen > > > -----Oorspronkelijk bericht----- > > Van: owner-netconf@ops.ietf.org > > [mailto:owner-netconf@ops.ietf.org]Namens tom.petch > > Verzonden: maandag 17 december 2007 16:18 > > Aan: Andy Bierman; Netconf (E-mail) > > Onderwerp: Re: quick check of notification-11 > > > > > > A minor quirk - I see a missing solidus in 3.2.5.1 > > " > > > > > > " > > > > I think you mean that the last tag should be a > closing tag: ? > So the above 3 lines should read: > > " > > > > right? > > > and an uncertainty - the I-D does not register the XML Schema defined in > > sections 4 and 3.4, just their targetNamespace; is this intentional? > > > > Not sure yet. I need to check. > Andy (or netconf-monitoring authors, can you pls comment? > > > > Also in IANA considerations, it might be clearer if the > > registration of the capability urn refers to the named registry > > created by RFC4741 s.10.3; obvious to those up to their ears in > > netconf, perhaps less so to those with an IANA-wide remit. > > > > I think you are ricght. Re-reading the IANA considerations in this > draft and also in RFC4741, maybe that section should be rewritten as: > > 8. IANA Considerations > > 8.1 NETCONF XML Namespace > > This document registers a URI for the NETCONF XML namespace > [RFC4741, section 10.1) in the IETF XML registry [RFC3688]. > > Following the format in RFC 3688, IANA has made the following > registration: > > URI: urn:ietf:params:xml:ns:netconf:notification:1.0 > > Registrant Contact: The IESG. > > XML: N/A, the requested URI is an XML namespace. > > 8.2 ?? > > 8.3 NETCONF Capability URNs > > This document registers URNs for the the following NETCONF > capabilities in the netconf registry (RFC4741], sect 10.3): > > +--------------------+----------------------------------------------+ > | Index | Capability Identifier | > +--------------------+----------------------------------------------+ > | :notification | urn:ietf:params:netconf:capability: | > | | notification:1.0 | > | | running:1.0 | > | | | > | :interleave | urn:ietf:params:netconf:capability: | > | | interleave:1.0 | > +--------------------+----------------------------------------------+ > > I am not sure (yet) where to put the following. > Is that part of the NETCONF XML namespace (i.e. should it > go in sect 8.1 above?): > > URI: urn:ietf:params:xml:ns:netmod:notification > > Anyway, Tom, is this the direction you were looking for? > > Any comments from authors or WG participants? > > Bert > > Tom Petch > > > > > -- 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 Jan 25 07:09:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JINMj-0007tf-8k for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 07:09:01 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JINMg-0004rp-VV for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 07:09:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JINGb-0007i0-TQ for netconf-data@psg.com; Fri, 25 Jan 2008 12:02:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JINGY-0007hM-47 for netconf@ops.ietf.org; Fri, 25 Jan 2008 12:02:39 +0000 Received: (qmail 2336 invoked from network); 25 Jan 2008 11:55:57 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Jan 2008 11:55:57 -0000 From: "Bert Wijnen" To: "tom.petch" , "Netconf \(E-mail\)" Subject: RE: quick check of notification-11 Date: Fri, 25 Jan 2008 12:56:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <01bb01c85f3f$60ebbea0$0601a8c0@pc6> Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Ok, thanks Tom. W.r.t. > "Following the format in RFC 3688, IANA is requested to make the following > registration " > > rather than > > "Following the format in RFC 3688, IANA has made the following > registration" > > thinking that the former is politer - but then IANA my prefer to Yep, that is my feeling too. But since the text has gone out in IETF LC in that (unpolite) style, I did not want to change that. In the end, this is the text that should end up in the RFC. Maybe a good compromise would be -- Editor note to IANA/RFC-Editor: we request that you make these -- assignments, in shich case it is top be documented as below "Following the format in RFC 3688, IANA has made the following registration" Oh well. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: tom.petch [mailto:cfinss@dial.pipex.com] > Verzonden: vrijdag 25 januari 2008 10:26 > Aan: Bert Wijnen; Netconf (E-mail) > Onderwerp: Re: quick check of notification-11 > > > Bert > > Yes, I agree, I think these are unresolved and that your > suggestions are good. > I would be inclined to say > > "Following the format in RFC 3688, IANA is requested to make the following > registration " > > rather than > > "Following the format in RFC 3688, IANA has made the following > registration" > > thinking that the former is politer - but then IANA my prefer to > have the words > put in their mouth:-) (I will ask them one day). > > netmod is the to-be-created Netconf data model, much discussed in > 2004/5; you > will find that the URI for it was issue 7 in the tracker in July > 2007. I think > it should be kept quite distinct from the other netconf URI until > and when it > takes a more concrete form. > > Tom Petch > > ----- Original Message ----- > From: "Bert Wijnen" > To: "tom.petch" ; "Netconf (E-mail)" > > Sent: Thursday, January 24, 2008 6:13 PM > Subject: RE: quick check of notification-11 > > > > Tom, as netconf-noticiation document shepherd, I am checking > > all (possibly still) outsanding comments. I think that the > > one from you (below) is still unanswered. > > > > My comments questions inline > > > > Bert Wijnen > > > > > -----Oorspronkelijk bericht----- > > > Van: owner-netconf@ops.ietf.org > > > [mailto:owner-netconf@ops.ietf.org]Namens tom.petch > > > Verzonden: maandag 17 december 2007 16:18 > > > Aan: Andy Bierman; Netconf (E-mail) > > > Onderwerp: Re: quick check of notification-11 > > > > > > > > > A minor quirk - I see a missing solidus in 3.2.5.1 > > > " > > > > > > > > > " > > > > > > > I think you mean that the last tag should be a > > closing tag: ? > > So the above 3 lines should read: > > > > " > > > > > > > > right? > > > > > and an uncertainty - the I-D does not register the XML Schema > defined in > > > sections 4 and 3.4, just their targetNamespace; is this intentional? > > > > > > > Not sure yet. I need to check. > > Andy (or netconf-monitoring authors, can you pls comment? > > > > > > > Also in IANA considerations, it might be clearer if the > > > registration of the capability urn refers to the named registry > > > created by RFC4741 s.10.3; obvious to those up to their ears in > > > netconf, perhaps less so to those with an IANA-wide remit. > > > > > > > I think you are ricght. Re-reading the IANA considerations in this > > draft and also in RFC4741, maybe that section should be rewritten as: > > > > 8. IANA Considerations > > > > 8.1 NETCONF XML Namespace > > > > This document registers a URI for the NETCONF XML namespace > > [RFC4741, section 10.1) in the IETF XML registry [RFC3688]. > > > > Following the format in RFC 3688, IANA has made the following > > registration: > > > > URI: urn:ietf:params:xml:ns:netconf:notification:1.0 > > > > Registrant Contact: The IESG. > > > > XML: N/A, the requested URI is an XML namespace. > > > > 8.2 ?? > > > > 8.3 NETCONF Capability URNs > > > > This document registers URNs for the the following NETCONF > > capabilities in the netconf registry (RFC4741], sect 10.3): > > > > +--------------------+----------------------------------------------+ > > | Index | Capability Identifier | > > +--------------------+----------------------------------------------+ > > | :notification | urn:ietf:params:netconf:capability: | > > | | notification:1.0 | > > | | running:1.0 | > > | | | > > | :interleave | urn:ietf:params:netconf:capability: | > > | | interleave:1.0 | > > +--------------------+----------------------------------------------+ > > > > I am not sure (yet) where to put the following. > > Is that part of the NETCONF XML namespace (i.e. should it > > go in sect 8.1 above?): > > > > URI: urn:ietf:params:xml:ns:netmod:notification > > > > Anyway, Tom, is this the direction you were looking for? > > > > Any comments from authors or WG participants? > > > > Bert > > > Tom Petch > > > > > > > > > > -- 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 Jan 25 09:23:54 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIPTG-0003bA-9M for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 09:23:54 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIPTD-0007iC-W8 for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 09:23:54 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIPK1-000OWt-EK for netconf-data@psg.com; Fri, 25 Jan 2008 14:14:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIPJy-000OVv-I2 for netconf@ops.ietf.org; Fri, 25 Jan 2008 14:14:20 +0000 Received: (qmail 30379 invoked from network); 25 Jan 2008 14:14:13 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Jan 2008 14:14:13 -0000 From: "Bert Wijnen" To: "IANA" , "Dan Romascanu" Cc: Subject: Pls update IANA registry for NETCONF Date: Fri, 25 Jan 2008 15:14:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Dear IANA, While reviewing new NETCIONF registration requets for a document that is now in IETF Last Call, I found some incomplete entries (I think). At this page: http://www.iana.org/assignments/xml-registry/ns/netconf.txt you have registered the NETCONF xml namspace. So far so good. But, It states: Registration request for the netconf: URI: urn:ietf:params:xml:ns:netconf Specification: [RFC-ietf-netconf-prot-12.txt] Registrant Contact: IETF NETCONF Working Group I suggest that you replace Specification: [RFC-ietf-netconf-prot-12.txt] with Specification: RFC4741 For this page: http://www.iana.org/assignments/xml-registry/ns/netconf/soap.txt I similarly suggest that you replace Specification: [RFC-ietf-netconf-soap-08.txt] with Specification: RFC4743 Further, both these pages state (1st line): Registration request.... Butr I think that they are no longer requests, but actual registrations, are they not? Bert Wijnen co-chair for the NETCONF WG -- 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 Jan 25 10:16:52 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQIW-00009e-V8 for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 10:16:52 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIQIW-0000Gu-GG for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 10:16:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIQD9-0006hs-OD for netconf-data@psg.com; Fri, 25 Jan 2008 15:11:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIQD6-0006gI-LJ for netconf@ops.ietf.org; Fri, 25 Jan 2008 15:11:18 +0000 Received: (qmail 83774 invoked from network); 25 Jan 2008 15:11:15 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Jan 2008 15:11:15 -0000 From: "Bert Wijnen" To: "Andy Bierman" Cc: Subject: NETCONF ticket 7 - URI assignments for IANA (netconf-notifications) Date: Fri, 25 Jan 2008 16:11:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Andy, this ticket http://www3.tools.ietf.org/wg/netconf/trac/ticket/7 is created by you. It states: From Andy Bierman: http://psg.com/lists/netconf/netconf.2007/msg00336.html 1) Capability for notification support, used in URI: urn:ietf:params:netconf:capability:notification:1.0 2) Namespace URI for the XSD in 3.4: "urn:ietf:params:xml:ns:netmod:notification" 3) Namespace URI for the XSD in 4.: "urn:ietf:params:xml:ns:netconf:notification" The 'targetNamespace' value currently in use in 4. is wrong: "urn:ietf:params:netconf:capability:notification:1.0" The comments were raised against revision 8 of the notifications draft. So I suspect they no longer hold. In any event, there are now 4 registrations. But they are also registrations in different namespaces. We also had comments from Tom Pech in this space. And while reviewing current xml registrations and such I have more open questions. See also my own review of the netconf notifications draft and my response to Tom Pech. More to follow. Bert (speaking as document shepherd) -- 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 Jan 25 10:26:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQRf-0000Tm-0P for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 10:26:19 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIQRc-0000RI-AC for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 10:26:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIQLU-0007oA-Mn for netconf-data@psg.com; Fri, 25 Jan 2008 15:19:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIQLO-0007nI-Tz for netconf@ops.ietf.org; Fri, 25 Jan 2008 15:19:54 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 20D35214B3; Fri, 25 Jan 2008 16:19:47 +0100 (CET) X-AuditID: c1b4fb3e-ab5e9bb0000007e1-bd-4799fe13e7c2 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0496B213CB; Fri, 25 Jan 2008 16:19:47 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 16:19:46 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 16:19:46 +0100 Message-ID: <4799FE11.7080303@ericsson.com> Date: Fri, 25 Jan 2008 16:19:45 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Mehmet Ersue CC: dromasca@avaya.com, rbonica@juniper.net, netconf@ops.ietf.org Subject: Re: Request for charter change References: <981942.20935.qm@web27808.mail.ukl.yahoo.com> In-Reply-To: <981942.20935.qm@web27808.mail.ukl.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Jan 2008 15:19:46.0253 (UTC) FILETIME=[B7F2AFD0:01C85F65] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 56904003e9d74831849863e83b1962ec I agree with all changes, they are good. However I think the charter is too long. I don't know if some of the introductory staff is still needed? I would try to shorten the charter in a second go. IMHO sooner or later updates to the base Netconf draft will also be needed. Balazs Mehmet Ersue wrote: > > Dear ADs (and WG), > > As new WG chairs, we have carefully studied the current WG charter > http://www.ietf.org/html.charters/netconf-charter.html > > Although the date on the charter page states that it was last updated > on 2008-01-09, that update was only to list us as new WG chairs and > our new Security Advisor. The base text is from a while ago, and > in the meanwhile, some documents have completed, and some of the > text that has past tense or (future tense) is now better read as > being the present. We also adopted a set of WG documents which > were based on earlier individual I-Ds, and so we have completed > posting of revision 00 documents for our chartered WG work items. > > We have clarified the text, cleaned it up a bit and we have marked > a few items as DONE. We made no substantial change (of course, > because that would require WG consensus forming first). > > ADs, can you please approve that this cleanup charter text be posted > as our current WG charter page. Will you forward it to iesg-secretary, > or do we need to do so seperately (assuming you will approve)? > > Bert and Mehmet > > > Attached is the new charter and a rfcdiff of old and new charter. > And here is the main body of the cleaned-up charter text: > > Configuration of networks of devices has become a critical requirement > for operators in today's highly interoperable networks. Operators from > large to small have developed their own mechanisms or used vendor > specific mechanisms to transfer configuration data to and from a > device, and for examining device state information which may impact > the configuration. Each of these mechanisms may be different in > various aspects, such as session establishment, user authentication, > configuration data exchange, and error responses. > > The NETCONF Working Group is chartered to produce a protocol suitable > for network configuration, with the following characteristics: > > - Provides retrieval mechanisms which can differentiate between > configuration data and non-configuration data > - Is extensible enough so that vendors will provide access to all > configuration data on the device using a single protocol > - Has a programmatic interface (avoids screen scraping and > formatting-related changes between releases) > - Uses a textual data representation, that can be easily manipulated > using non-specialized text manipulation tools. > - Supports integration with existing user authentication methods > - Supports integration with existing configuration database systems > - Supports network wide configuration transactions (with features such > as locking and rollback capability) > - Is as transport-independent as possible > - Provides support for asynchronous notifications. > > The NETCONF protocol is using XML for data encoding purposes, because > XML is a widely deployed standard which is supported by a large number > of applications. > > The NETCONF protocol should be independent of the data definition > language and data models used to describe configuration and state > data. > > However, the authorization model used in the protocol is dependent on > the data model. Although these issues must be fully addressed to > develop standard data models, only a small part of this work will be > initially addressed. This group will specify requirements for standard > data models in order to fully support the NETCONF protocol, such as: > > - identification of principals, such as user names or distinguished names > - mechanism to distinguish configuration from non-configuration data > - XML namespace conventions > - XML usage guidelines > > The initial work started in 2003 and has already been completed and was > restricted to following items: > > a) NETCONF Protocol Specification, which defines the operational model, > protocol operations, transaction model, data model requirements, > security requirements, and transport layer requirements. > b) NETCONF over SSH Specification: Implementation Mandatory, > c) NETCONF over BEEP Specification: Implementation Optional, > d) NETCONF over SOAP Specification: Implementation Optional. > > These documents define how the NETCONF protocol is used with each > transport protocol selected by the working group, and how it meets > the security and transport layer requirements of the NETCONF Protocol > Specification. > > e) NETCONF Notification Specification, which defines mechanisms that > provide an asynchronous message notification delivery service for > the NETCONF protocol. NETCONF Notification is an optional > capability built on top of the base NETCONF definition and > provides the capabilities and operations necessary to support > this service. > > In the current phase of the incremental development of NETCONF the > workgroup will focus on following items: > > 1. Fine-grain locking: The base NETCONF protocol only provides a lock > for the entire configuration datastore, which is not deemed to meet > important operational and security requirements. The NETCONF working > group will produce a standards-track RFC specifying a mechanism for > fine-grain locking of the NETCONF configuration datastore. > > 2. NETCONF monitoring: It is considered best practice for IETF working > groups to include management of their protocols within the scope of > the solution they are providing. The NETCONF working group will > produce a standards-track RFC with mechanisms allowing NETCONF > itself to be used to monitor some aspects of NETCONF operation. > > 3. Schema advertisement: Currently the NETCONF protocol is able to > advertise which protocol features are supported on a particular > netconf-capable device. However, there is currently no way to discover > which XML Schema are supported on the device. The NETCONF working > group will produce a standards-track RFC with mechanisms making this > discovery possible (this item may be merged with "NETCONF monitoring" > into a single document). > > 4. NETCONF over TLS: Based on implementation experience there is a > need for a standards track document to define NETCONF over TLS as an > optional transport for the NETCONF protocol. > > The following items have been identified as important but are currently > not considered in scope for re-chartering and may be candidates for work > when there is community consensus to take them on: > > - General improvements to the base protocol > - Access Control requirements > - NETCONF access to SMI-based MIB data > > > Goals and Milestones: > Done Working Group formed > Done Submit initial Netconf Protocol draft > Done Submit initial Netconf over (transport-TBD) draft > Done Begin Working Group Last Call for the Netconf Protocol draft > Done Begin Working Group Last Call for the Netconf over (transport-TBD) > draft > Done Submit final version of the Netconf Protocol draft to the IESG > Done Submit final version of the Netconf over SOAP draft to the IESG > Done Submit final version of the Netconf over BEEP draft to the IESG > Done Submit final version of the Netconf over SSH draft to the IESG > Done Update charter > Done Submit first version of NETCONF Notifications document > Done Begin WGLC of NETCONF Notifications document > Done Submit final version of NETCONF Notifications document to IESG > for consideration as Proposed Standard > Done -00 draft for fine Grain Locking > Done -00 draft for NETCONF over TLS > Done -00 draft for NETCONF Monitoring > Feb 2008 -00 draft for Schema Advertisement > Mar 2008 Early Review of client authentication approach (for NETCONF over > TLS) with the security community at IETF 71 > Aug 2008 WG Last Call on NETCONF Monitoring after IETF72 > Aug 2008 WG Last Call on Schema Advertisement after IETF72 > Aug 2008 WG Last Call on Fine Grain Locking after IETF72 > Aug 2008 WG Last Call on NETCONF over TLS after IETF72 > Aug 2008 Send four documents to the IESG for consideration as proposed > standards > > > > ------------------------------------------------------------------------ > Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel > mehr bietet das neue Yahoo! Mail > . > > ------------------------------------------------------------------------ > > WGCharter-20080109.txt WGCharter-20080124.txt > Network Configuration (netconf) Charter Network Configuration > (netconf) Charter > > Network Configuration (netconf) Network Configuration (netconf) > > In addition to this official charter maintained by the IETF > Secretariat, there In addition to this official charter maintained by > the IETF Secretariat, there > is additional information about this working group on the Web at: is > additional information about this working group on the Web at: > > Additional NETCONF Web Page Additional NETCONF Web Page > > Last Modified: 2008-01-09 Last Modified: 2008-01-24 > Additional information is available at tools.ietf.org/wg/netconf > Additional information is available at tools.ietf.org/wg/netconf > > Chair(s): Chair(s): > Bert Wijnen Bert Wijnen > > Mehmet Ersue Mehmet Ersue > > Operations and Management Area Director(s): Operations and Management > Area Director(s): > Dan Romascanu Dan Romascanu > > > skipping to change at/ line 52/ skipping to change at/ line 52/ > device, and for examining device state information which may impact > device, and for examining device state information which may impact > the configuration. Each of these mechanisms may be different in the > configuration. Each of these mechanisms may be different in > various aspects, such as session establishment, user authentication, > various aspects, such as session establishment, user authentication, > configuration data exchange, and error responses. configuration data > exchange, and error responses. > > The NETCONF Working Group is chartered to produce a protocol suitable > The NETCONF Working Group is chartered to produce a protocol suitable > for network configuration, with the following characteristics: for > network configuration, with the following characteristics: > > - Provides retrieval mechanisms which can differentiate between - > Provides retrieval mechanisms which can differentiate between > configuration data and non-configuration data configuration data and > non-configuration data > - Is extensible enough that vendors will provide access to all - Is > extensible enough so that vendors will provide access to all > configuration data on the device using a single protocol configuration > data on the device using a single protocol > - Has a programmatic interface (avoids screen scraping and - Has a > programmatic interface (avoids screen scraping and > formatting-related changes between releases) formatting-related > changes between releases) > - Uses a textual data representation, that can be easily manipulated - > Uses a textual data representation, that can be easily manipulated > using non-specialized text manipulation tools. using non-specialized > text manipulation tools. > - Supports integration with existing user authentication methods - > Supports integration with existing user authentication methods > - Supports integration with existing configuration database systems - > Supports integration with existing configuration database systems > - Supports network wide configuration transactions (with features > such - Supports network wide configuration transactions (with > features such > as locking and rollback capability) as locking and rollback capability) > - Is as transport-independent as possible - Is as > transport-independent as possible > - Provides the following support for asynchronous notifications: - > Provides support for asynchronous notifications > - Specify the message (capability exchange) details to support > notifications. > - Specify the application mapping details to support notifications. > - Specify the protocol syntax and semantics of a notification message. > - Specify or select a notification content information model. > - Specify a mechanism for controlling the delivery (turn on/off) of > notifications during a session. > - Specify a mechanism for selectively receiving a configurable subset > of all possible notification types. > > The NETCONF protocol will use XML for data encoding purposes, because > The NETCONF protocol is using XML for data encoding purposes, because > XML is a widely deployed standard which is supported by a large > number XML is a widely deployed standard which is supported by a large > number > of applications. XML also supports hierarchical data structures. of > applications. > > The NETCONF protocol should be independent of the data definition The > NETCONF protocol should be independent of the data definition > language and data models used to describe configuration and state > language and data models used to describe configuration and state > data. data. > > However, the authorization model used in the protocol is dependent on > However, the authorization model used in the protocol is dependent on > the data model. Although these issues must be fully addressed to the > data model. Although these issues must be fully addressed to > develop standard data models, only a small part of this work will be > develop standard data models, only a small part of this work will be > initially addressed. This group will specify requirements for > standard initially addressed. This group will specify requirements for > standard > data models in order to fully support the NETCONF protocol, such as: > data models in order to fully support the NETCONF protocol, such as: > > - identification of principals, such as user names or distinguished - > identification of principals, such as user names or distinguished names > names > - mechanism to distinguish configuration from non-configuration data - > mechanism to distinguish configuration from non-configuration data > identification of principals, such as user names or distinguished names > - XML namespace conventions - XML namespace conventions > - XML usage guidelines - XML usage guidelines > > It should be possible to transport the NETCONF protocol using several > The initial work started in 2003 and has already been completed and was > different protocols. The group will select at least one suitable > restricted to following items: > transport mechanism, and define a mapping for the selected protocol > (s). > > The initial work (has completed) and was restricted to the following > items: > > - NETCONF Protocol Specification, which defines the operational > model, a) NETCONF Protocol Specification, which defines the operational > model, > protocol operations, transaction model, data model requirements, > protocol operations, transaction model, data model requirements, > security requirements, and transport layer requirements. security > requirements, and transport layer requirements. > b) NETCONF over SSH Specification: Implementation Mandatory, > c) NETCONF over BEEP Specification: Implementation Optional, > d) NETCONF over SOAP Specification: Implementation Optional. > > - NETCONF over SSH Specification: Implementation Mandatory; NETCONF > These documents define how the NETCONF protocol is used with each > over BEEP Specification: Implementation Optional; NETCONF over SOAP > transport protocol selected by the working group, and how it meets > Specification: Implementation Optional; These documents define how > the the security and transport layer requirements of the NETCONF Protocol > NETCONF protocol is used with each transport protocol selected by the > Specification. > working group, and how it meets the security and transport layer > requirements of the NETCONF Protocol Specification. > > Additional Notification work (as described above) will now be > addressed since the initial work has been completed. > > An individual submission Internet Draft has been proposed to the WG > as e) NETCONF Notification Specification, which defines mechanisms that > the starting point for the Notification work. The WG shall adopt the > provide an asynchronous message notification delivery service for > document identified as 'draft-chisholm-NETCONF-event-01.txt' as the > the NETCONF protocol. NETCONF Notification is an optional > starting point for this work. capability built on top of the base > NETCONF definition and > provides the capabilities and operations necessary to support > this service. > > A second phase of incremental development of NETCONF will include the > In the current phase of the incremental development of NETCONF the > following items: workgroup will focus on following items: > > 1. Fine-grain locking: The base NETCONF protocol only provides a lock > 1. Fine-grain locking: The base NETCONF protocol only provides a lock > for the entire configuration datastore, which is not deemed to meet > for the entire configuration datastore, which is not deemed to meet > important operational and security requirements. The NETCONF working > important operational and security requirements. The NETCONF working > group will produce a standards-track RFC specifying a mechanism for > group will produce a standards-track RFC specifying a mechanism for > fine-grain locking of the NETCONF configuration datastore. fine-grain > locking of the NETCONF configuration datastore. > > (The initial draft will be based on > draft-lengyel-ngo-partial-lock-00.txt barring additional contributions > from the community.) > > 2. NETCONF monitoring: It is considered best practice for IETF > working 2. NETCONF monitoring: It is considered best practice for IETF > working > groups to include management of their protocols within the scope of > groups to include management of their protocols within the scope of > the solution they are providing. NETCONF does not provide this the > solution they are providing. The NETCONF working group will > capability. The NETCONF working group will produce a standards-track > produce a standards-track RFC with mechanisms allowing NETCONF > RFC with mechanisms allowing NETCONF itself to be used to monitor > some itself to be used to monitor some aspects of NETCONF operation. > aspects of NETCONF operation. > > (The initial draft will be based on > draft-chisholm-netconf-monitoring-00.txt barring additional > contributions from the community.) > > 3. Schema advertisement: Currently the NETCONF protocol is able to 3. > Schema advertisement: Currently the NETCONF protocol is able to > advertise which protocol features are supported on a particular > advertise which protocol features are supported on a particular > netconf-capable device. However, there is currently no way to > discover netconf-capable device. However, there is currently no way to > discover > which XML Schema are supported on the device. The NETCONF working > which XML Schema are supported on the device. The NETCONF working > group will produce a standards-track RFC with mechanisms making this > group will produce a standards-track RFC with mechanisms making this > discovery possible. discovery possible (this item may be merged with > "NETCONF monitoring" > into a single document). > This item may be merged with "NETCONF monitoring" into a single > document. > > (The initial draft will be based on > draft-scott-netconf-schema-query-00.txt barring additional > contributions from the community.) > > 4. NETCONF over TLS - based on implementation experience there is a 4. > NETCONF over TLS: Based on implementation experience there is a > need for a standards track document to define NETCONF over TLS as an > need for a standards track document to define NETCONF over TLS as an > optional transport for NETCONF optional transport for the NETCONF > protocol. > > (The initial draft will be based on > draft-badra-tls-netconf-04.txt barring additional contributions from > the community.) > > The following are currently not considered in scope for re-chartering > The following items have been identified as important but are currently > at this time, but may be candidates for work when there is community > not considered in scope for re-chartering and may be candidates for work > consensus to take them on. Individual submissions are being when there > is community consensus to take them on: > encouraged. > > o Access Control requirements - General improvements to the base protocol > o General improvements to the base protocol o NETCONF access to - > Access Control requirements > SMI-based MIB data o The Bill Fenner problem: Address real or - > NETCONF access to SMI-based MIB data > perceived issue that "giving SSH for NETCONF gives full SSH access to > the box" > > Goals and Milestones: Goals and Milestones: > Done Working Group formed Done Working Group formed > Done Submit initial Netconf Protocol draft Done Submit initial Netconf > Protocol draft > Done Submit initial Netconf over (transport-TBD) draft Done Submit > initial Netconf over (transport-TBD) draft > Done Begin Working Group Last Call for the Netconf Protocol draft Done > Begin Working Group Last Call for the Netconf Protocol draft > Done Begin Working Group Last Call for the Netconf over > (transport-TBD) Done Begin Working Group Last Call for the Netconf over > (transport-TBD) > draft draft > Done Submit final version of the Netconf Protocol draft to the IESG > Done Submit final version of the Netconf Protocol draft to the IESG > Done Submit final version of the Netconf over SOAP draft to the IESG > Done Submit final version of the Netconf over SOAP draft to the IESG > Done Submit final version of the Netconf over BEEP draft to the IESG > Done Submit final version of the Netconf over BEEP draft to the IESG > Done Submit final version of the Netconf over SSH draft to the IESG > Done Submit final version of the Netconf over SSH draft to the IESG > Done Update charter Done Update charter > Done Submit first version of NETCONF Notifications document Done > Submit first version of NETCONF Notifications document > Done Begin WGLC of NETCONF Notifications document Done Begin WGLC of > NETCONF Notifications document > Dec 2006 Submit final version of NETCONF Notifications document to > IESG Done Submit final version of NETCONF Notifications document to IESG > for consideration as Proposed Standard for consideration as Proposed > Standard > Dec 2007 -00 draft for NETCONF Monitoring Done -00 draft for fine > Grain Locking > Dec 2007 -00 draft for Schema Advertisement Done -00 draft for NETCONF > over TLS > Dec 2007 -00 draft for Fine Grain Locking Done -00 draft for NETCONF > Monitoring > Dec 2007 -00 draft for NETCONF over TLS Feb 2008 -00 draft for Schema > Advertisement > Mar 2008 Early Review of client authentication approach (for > NETCONF over Mar 2008 Early Review of client authentication approach > (for NETCONF over > TLS) with the security community at IETF 71 TLS) with the security > community at IETF 71 > Aug 2008 WG Last Call on NETCONF Monitoring after IETF72 Aug 2008 WG > Last Call on NETCONF Monitoring after IETF72 > Aug 2008 WG Last Call on Schema Advertisement after IETF72 Aug 2008 WG > Last Call on Schema Advertisement after IETF72 > Aug 2008 WG Last Call on Fine Grain Locking after IETF72 Aug 2008 WG > Last Call on Fine Grain Locking after IETF72 > Aug 2008 WG Last Call on NETCONF over TLS after IETF72 Aug 2008 WG > Last Call on NETCONF over TLS after IETF72 > Aug 2008 Send four documents to the IESG for consideration as > proposed Aug 2008 Send four documents to the IESG for consideration as > proposed > standards standards > > Internet-Drafts: Internet-Drafts: > > End of changes. 23 change blocks. > /80 lines changed or deleted/ / / /42 lines changed or added/ > > This html diff was produced by rfcdiff 1.34. The latest version is > available from http://tools.ietf.org/tools/rfcdiff/ > > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jan 25 11:31:37 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIRSr-00069W-D1 for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 11:31:37 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIRSq-0002TR-Rp for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 11:31:37 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIRGy-000Etg-KW for netconf-data@psg.com; Fri, 25 Jan 2008 16:19:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [217.146.182.15] (helo=web27810.mail.ukl.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIRGs-000Et2-Fx for netconf@ops.ietf.org; Fri, 25 Jan 2008 16:19:16 +0000 Received: (qmail 17622 invoked by uid 60001); 25 Jan 2008 16:19:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=fSsqw9DNuK/XS8VN0KYqVPG5HvU6KSOFyBXCZtA1kkwbPJ9e/ovbSCcF+VKCmqqOqM+J0iJ8SNicdsOCOxGPF+/M7r/fYjHUPppMBFO4K+Z3Xujh5WCg/Hqj4M4hZqfAcarzn2qveGymm6id81SVFBb8FWEp9xLjqbN1L9qW2CA=; X-YMail-OSG: icHTxnEVM1kXwz.6H9VBmK6g4g_gzqhzCeydcGoK49aduSI3jaJLOBDTIJsCdrHzIQ-- Received: from [217.115.75.231] by web27810.mail.ukl.yahoo.com via HTTP; Fri, 25 Jan 2008 16:19:12 GMT X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.160 Date: Fri, 25 Jan 2008 16:19:12 +0000 (GMT) From: Mehmet Ersue Subject: Re: Request for charter change To: Balazs Cc: Dan Romascanu , NETCONF , Ron Bonica MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1544769766-1201277952=:15696" Message-ID: <964138.15696.qm@web27810.mail.ukl.yahoo.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 --0-1544769766-1201277952=:15696 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Balazs,=0A=0Athank you for your comments. We can do another reduction in= the second =0Ago after having some progress with ongoing documents.=0A=0AB= TW: Netconf Charter page and the 'Additional NETCONF Web Page' are =0Awell-= known in the Web. I guess detailed info on what we are doing can be =0Ahelp= ful.=0A=0ACheers,=0AMehmet=0A=0A> -----Original Message-----=0A> From: ext = Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] =0A> Sent: Friday, Janu= ary 25, 2008 4:20 PM=0A> To: Mehmet Ersue=0A> Cc: dromasca@avaya.com; rboni= ca@juniper.net; netconf@ops.ietf.org=0A> Subject: Re: Request for charter c= hange=0A> =0A> I agree with all changes, they are good.=0A> However I think= the charter is too long. I don't know if some =0A> of the introductory sta= ff is =0A> still needed? I would try to shorten the charter in a second go.= =0A> =0A> IMHO sooner or later updates to the base Netconf draft will =0A> = also be needed.=0A> =0A> Balazs=0A=0A=0A=0A=0A=0A Jetzt Mails schnell = in einem Vorschaufenster =C3=BCberfliegen. Dies und viel mehr bietet das ne= ue Yahoo! Mail - www.yahoo.de/mail --0-1544769766-1201277952=:15696 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Balazs,

thank you for your comments. We can do another re= duction in the second
go after having some progress with ongoing docume= nts.

BTW: Netconf Charter page and the 'Additional NETCONF Web Page'= are
well-known in the Web. I guess detailed info on what we are doing = can be
helpful.

Cheers,
Mehmet

> -----Original Mess= age-----
> From: ext Balazs Lengyel [mailto:balazs.lengyel@ericsson.c= om]
> Sent: Friday, January 25, 2008 4:20 PM
> To: Mehmet Ersu= e
> Cc: dromasca@avaya.com; rbonica@juniper.net; netconf@ops.ietf.org=
> Subject: Re: Request for charter change
>
> I agree w= ith all changes, they are good.
> However I think the charter is too = long. I don't know if some
> of the introductory staff is
> still needed? I would try to shorten the charter in a second go.<= br>>
> IMHO sooner or later updates to the base Netconf draft wil= l
> also be needed.
>
> Balazs


= =0A=0A=0A
Heute schon einen Blick in die Zukunft von E-Ma= ils wagen? Versuchen Sie=C2=B4s mit dem =0A= neuen Yahoo! Mail. =0A --0-1544769766-1201277952=:15696-- -- 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 Jan 25 11:55:27 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIRpv-0006LT-UX for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 11:55:27 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIRpu-0002x0-5g for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 11:55:27 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIRhi-000ImW-Ig for netconf-data@psg.com; Fri, 25 Jan 2008 16:46:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIRhf-000IlQ-TF for netconf@ops.ietf.org; Fri, 25 Jan 2008 16:46:57 +0000 Received: (qmail 52839 invoked from network); 25 Jan 2008 16:46:50 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Jan 2008 16:46:50 -0000 From: "Bert Wijnen" To: "Andy Bierman" Cc: "Netconf" Subject: NETCONF ticket 8 - URL assignments for IANA 2 (netconf-notifications) Date: Fri, 25 Jan 2008 17:46:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Ticket 8 at http://tools.ietf.org/wg/netconf/trac/ticket/8 is also about URL assignments. In fact it is about registering the XML schema files. Looks like there are 2 Schemas to be registered, namely the one in section 3.4 and the one in section 4. I suspect we need to give better instructions for that in the IANA considerations section. Bert Wijnen -------- ticket 8: From Andy Bierman: http://psg.com/lists/netconf/netconf.2007/msg00336.html Need IANA to assign URLs for each of the 2 XSDs in the draft, and each XSD extracted and made available online. For example, "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"; -- 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 Jan 25 12:05:08 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIRzI-0006zA-Ow for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 12:05:08 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIRzG-0003Am-F9 for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 12:05:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIRtu-000Kzb-MT for netconf-data@psg.com; Fri, 25 Jan 2008 16:59:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIRtr-000KyQ-El for netconf@ops.ietf.org; Fri, 25 Jan 2008 16:59:33 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7A22B2116D; Fri, 25 Jan 2008 17:58:34 +0100 (CET) X-AuditID: c1b4fb3c-aaaedbb0000007e0-2b-479a153a7c8f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 57014205F8; Fri, 25 Jan 2008 17:58:34 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 17:58:33 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 17:58:33 +0100 Message-ID: <479A1539.3070105@ericsson.com> Date: Fri, 25 Jan 2008 17:58:33 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Bert Wijnen CC: netconf@ops.ietf.org Subject: Re: comments on draft-ietf-netconf-partial-lock-00 References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2008 16:58:33.0626 (UTC) FILETIME=[84F007A0:01C85F73] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 386e0819b1192672467565a524848168 Hello Bert, Thanks for the comments. I mostly agree (see below). Balazs Bert Wijnen wrote: > Commenting as a technical contributor. > These are however mainly/initial editorial comments > that you can consider for the next revision. > > - sect 1 > Partial locking will be introduced as a capability to NETCONF. > I think I would prefer > Partial locking is defined as a capability to NETCONF. > or some such. So do not speak in the future OK > > - Sect 1.1 > Need to add a citation to RFC2119, and then add RFC2119 to the > normative references. OK > > - sect 2.1 > The system will ensure that configuration resources covered by the > lock will not be modified by other NETCONF or non-NETCONF management > operations such as SNMP and the CLI. > > I think it would be better to not speak in the future. > So I would do > The system ensures... > lock can not be modified ,,, > Or some such OK > > - Sect 2.2 > > If the :xpath capability is supported, the filter expressions can be > full XPath 1.0 expressions. > > This may be a good place to also add some text on how the filter > experssions are limited if :xpath capability is not supported. It is described in chapter 2.4.1. . Do you find that description insufficient or do you think we should bring it forward here? > > - page 12 > > target: Name of the configuration datastore of which a part will be > locked. URIs are not accepted. > > Did you mean "url" instead of URI? > In rfc4741 in sect 8.8 we speak of "URL capability" that allows urls > to be used for target. We should try to be consistent in our usage of > terms. OK > > - section 4, IANA considerations. > > The capability's URI should be registered by IANA. > > I would make this somewhat more explicit. Something aka > > This document registers a URN for the the following NETCONF > capability in the netconf registry (RFC4741], sect 10.3): > > +--------------------+----------------------------------------------+ > | Index | Capability Identifier | > +--------------------+----------------------------------------------+ > | :partial-lock | urn:ietf:params:netconf:capability:partial- | > | | lock:1.0 | > +--------------------+----------------------------------------------+ OK > > - Overall > > > > Bert Wijnen > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Fri Jan 25 12:12:45 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIS6f-0008NO-JU for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 12:12:45 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIS6f-0003wK-73 for netconf-archive@lists.ietf.org; Fri, 25 Jan 2008 12:12:45 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIS2d-000MaO-HE for netconf-data@psg.com; Fri, 25 Jan 2008 17:08:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIS2a-000MZb-FJ for netconf@ops.ietf.org; Fri, 25 Jan 2008 17:08:34 +0000 Received: (qmail 63392 invoked from network); 25 Jan 2008 17:08:31 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Jan 2008 17:08:31 -0000 From: "Bert Wijnen" To: "Balazs Lengyel" Cc: Subject: RE: comments on draft-ietf-netconf-partial-lock-00 Date: Fri, 25 Jan 2008 18:08:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <479A1539.3070105@ericsson.com> Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 W.r.t. > > > > - Sect 2.2 > > > > If the :xpath capability is supported, the filter expressions can be > > full XPath 1.0 expressions. > > > > This may be a good place to also add some text on how the filter > > experssions are limited if :xpath capability is not supported. > It is described in chapter 2.4.1. . Do you find > that description insufficient or do you think we should bring it forward here? > > Yes I had seen that. At least you might want to add a forward reference. But 2.4.1 has a lot more than just the filter expression and the limitations if one does not support :xpath. So you may want to add some specific text here in Sect 2.2 that explains the limitations. My comment of course is not a show stopper. But when I was reading the draft I sort of wondered and had to a read lot more before it started to make any sense. 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 Sat Jan 26 11:06:46 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JInYM-0004eB-MJ for netconf-archive@lists.ietf.org; Sat, 26 Jan 2008 11:06:46 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JInYK-0008JJ-LC for netconf-archive@lists.ietf.org; Sat, 26 Jan 2008 11:06:46 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JInP2-000GBF-UM for netconf-data@psg.com; Sat, 26 Jan 2008 15:57:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JInP0-000GAW-85 for netconf@ops.ietf.org; Sat, 26 Jan 2008 15:57:07 +0000 Received: (qmail 23424 invoked from network); 26 Jan 2008 15:57:03 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 26 Jan 2008 15:57:03 -0000 From: "Bert Wijnen" To: "Netconf" Subject: FW: [IANA #138331] Pls update IANA registry for NETCONF Date: Sat, 26 Jan 2008 16:57:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac FYI Bert Wijnen=20 -----Oorspronkelijk bericht----- Van: Amanda Baber via RT [mailto:iana-matrix@icann.org] Verzonden: zaterdag 26 januari 2008 1:03 Aan: bertietf@bwijnen.net Onderwerp: [IANA #138331] Pls update IANA registry for NETCONF=20 Hi Bert, We've removed the "Registration request" lines and updated the RFC=20 numbers for these entries, along with a couple of other registrations=20 linked from http://www.iana.org/assignments/xml-registry/ns.html.=20 Thanks for pointing them out. Amanda IANA On Fri Jan 25 06:17:14 2008, bertietf@bwijnen.net wrote: > Dear IANA, >=20 > While reviewing new NETCIONF registration requets for a > document that is now in IETF Last Call, I found some incomplete > entries (I think). >=20 > At this page: > http://www.iana.org/assignments/xml-registry/ns/netconf.txt > you have registered the NETCONF xml namspace. So far so good.=20 > But, It states: >=20 > Registration request for the netconf: >=20 > URI: urn:ietf:params:xml:ns:netconf >=20 > Specification: [RFC-ietf-netconf-prot-12.txt] >=20 > Registrant Contact:=20 > =20 > IETF > NETCONF Working Group >=20 >=20 > I suggest that you replace=20 > Specification: [RFC-ietf-netconf-prot-12.txt] > with=20 > Specification: RFC4741 >=20 >=20 > For this page: > http://www.iana.org/assignments/xml-registry/ns/netconf/soap.txt >=20 > I similarly suggest that you replace > Specification: [RFC-ietf-netconf-soap-08.txt] > with > Specification: RFC4743 >=20 >=20 > Further, both these pages state (1st line): Registration request.... > Butr I think that they are no longer requests, but actual = registrations, > are they not?=20 >=20 > Bert Wijnen=20 > co-chair for the NETCONF WG >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jan 28 03:12:31 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJP6U-0001Qf-HF for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 03:12:31 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJP6S-00012p-5b for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 03:12:30 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJOwF-0003v6-Qz for netconf-data@psg.com; Mon, 28 Jan 2008 08:01:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [198.152.13.100] (helo=co300216-co-outbound.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJOwD-0003uk-6P for netconf@ops.ietf.org; Mon, 28 Jan 2008 08:01:54 +0000 X-IronPort-AV: E=Sophos;i="4.25,258,1199682000"; d="url'?txt'208?scan'208,208";a="101862812" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 28 Jan 2008 03:01:51 -0500 X-IronPort-AV: E=Sophos;i="4.25,258,1199682000"; d="url'?txt'208?scan'208,208";a="154817338" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jan 2008 02:52:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C86182.C341B565" Subject: FW: I-D Action:draft-presuhn-rcdml-00.txt Date: Mon, 28 Jan 2008 08:52:41 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-presuhn-rcdml-00.txt Thread-Index: AchheP5QjeH2JlF8T+OAGKHG4CnAIQACVruw From: "Romascanu, Dan (Dan)" To: , , , Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 This is a multi-part message in MIME format. ------_=_NextPart_001_01C86182.C341B565 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I apologize for cross-posting, but I think it is justified in this case. I suggest yang@ietf.org as prefered space for comments.=20 Dan =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Monday, January 28, 2008 8:40 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-presuhn-rcdml-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for a Configuration Data Modeling Language Author(s) : R. Presuhn Filename : draft-presuhn-rcdml-00.txt Pages : 22 Date : 2008-01-28 This memo contains a compilation of requirements for a Configuration Data Modeling Language. Although focusing on the needs of the NETCONF Protocol, these requirements potentially have broader applicability. Comments should be sent to ngo@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-presuhn-rcdml-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-presuhn-rcdml-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-presuhn-rcdml-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. This email was protected during delivery to Avaya with TLS encryption ------_=_NextPart_001_01C86182.C341B565 Content-Type: application/octet-stream; name="ATT856200.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT856200.TXT Content-Disposition: attachment; filename="ATT856200.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwOC0wMS0yODAxMzA1OC5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wcmVzdWhuLXJjZG1sLTAw LnR4dA0K ------_=_NextPart_001_01C86182.C341B565 Content-Type: application/octet-stream; name="draft-presuhn-rcdml-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-presuhn-rcdml-00.URL Content-Disposition: attachment; filename="draft-presuhn-rcdml-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1wcmVzdWhuLXJjZG1sLTAwLnR4dA0K ------_=_NextPart_001_01C86182.C341B565 Content-Type: text/plain; name="ATT856201.txt" Content-Transfer-Encoding: base64 Content-Description: ATT856201.txt Content-Disposition: attachment; filename="ATT856201.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQoNClRoaXMgZW1haWwgd2FzIHBy b3RlY3RlZCBkdXJpbmcgZGVsaXZlcnkgdG8gQXZheWEgd2l0aCBUTFMgZW5jcnlwdGlvbg0K ------_=_NextPart_001_01C86182.C341B565-- -- 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 Jan 28 07:13:52 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJSs4-0006Ub-4N for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 07:13:52 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJSs2-0006Dm-Dm for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 07:13:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJShK-0008HB-Pk for netconf-data@psg.com; Mon, 28 Jan 2008 12:02:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [198.152.12.100] (helo=nj300815-nj-outbound.avaya.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJShH-0008GV-9k for netconf@ops.ietf.org; Mon, 28 Jan 2008 12:02:45 +0000 X-IronPort-AV: E=Sophos;i="4.25,259,1199682000"; d="scan'208";a="95678637" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 28 Jan 2008 07:02:36 -0500 X-IronPort-AV: E=Sophos;i="4.25,259,1199682000"; d="scan'208";a="147642913" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Jan 2008 07:02:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D Action:draft-presuhn-rcdml-00.txt Date: Mon, 28 Jan 2008 13:02:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-presuhn-rcdml-00.txt Thread-Index: AchheP5QjeH2JlF8T+OAGKHG4CnAIQACVruwAAjMMeA= From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , , , , Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Sorry, comments better be addressed to ngo@ietf.org. This is what the I-D says and it's better to let the yang folks focus on yang work.=20 Dan =20 =20 > -----Original Message----- > From: Romascanu, Dan (Dan)=20 > Sent: Monday, January 28, 2008 9:53 AM > To: netconf@ops.ietf.org; 'yang@ietf.org';=20 > 'ops-area@ietf.org'; ngo@ietf.org > Subject: FW: I-D Action:draft-presuhn-rcdml-00.txt=20 >=20 > I apologize for cross-posting, but I think it is justified in=20 > this case. I suggest yang@ietf.org as prefered space for comments.=20 >=20 > Dan >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, January 28, 2008 8:40 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-presuhn-rcdml-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Requirements for a Configuration Data=20 > Modeling Language > Author(s) : R. Presuhn > Filename : draft-presuhn-rcdml-00.txt > Pages : 22 > Date : 2008-01-28 >=20 > This memo contains a compilation of requirements for a=20 > Configuration Data Modeling Language. Although focusing on=20 > the needs of the NETCONF Protocol, these requirements=20 > potentially have broader applicability. Comments should be=20 > sent to ngo@ietf.org. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-presuhn-rcdml-00.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-presuhn-rcdml-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-presuhn-rcdml-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 > This email was protected during delivery to Avaya with TLS encryption >=20 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jan 28 08:04:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJTeo-00028I-8L for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 08:04:14 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJTem-0007RO-DC for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 08:04:14 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJTYy-000JDF-A3 for netconf-data@psg.com; Mon, 28 Jan 2008 12:58:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJTYu-000JC7-KF for netconf@ops.ietf.org; Mon, 28 Jan 2008 12:58:10 +0000 Received: (qmail 28507 invoked from network); 28 Jan 2008 12:58:07 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Jan 2008 12:58:07 -0000 From: "Bert Wijnen" To: "Netconf" Subject: DO we really need a session at IETF71? Date: Mon, 28 Jan 2008 13:58:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Dear WG members, As you know, we have requested a session slot for IETF71. But in order for such a session to be usefull, we MUST prepare. We now have (for more than 10 days already) revision 00 documents for all of our currently 3 charterd WG work items. Namely: Title : NETCONF Monitoring Schema Author(s) : M. Scott, S. Chisholm Filename : draft-ietf-netconf-monitoring-00.txt Pages : 14 Date : 2008-1-15 Title : Partial Lock RPC for NETCONF Author(s) : B. Lengyel, M. Bjorklund Filename : draft-ietf-netconf-partial-lock-00.txt Pages : 11 Date : 2008-01-07 Title : NETCONF over TLS Author(s) : M. Badra Filename : draft-ietf-netconf-tls-00.txt Pages : 9 Date : 2008-01-01 Not much commenting and/or discussion has taken place on our mailing list yet. And that is NOT GOOD. We MUST review and then comment/discuss these documents on our WG mailing list. We need to know: - are enough people reading/reviewing the documents in other words, does the WG really care? - what do people think about the documents. don't assume that we as WG chairs will assume that silence means consent or agreement. If you like it, pls state so with an email to the mailing list that says something aka: - I reviewed the document and it is in GOOD SHAPE. Please publish asap. - I reviewed (or read) the document and I like it - I reviewed (or read) the document and I did not see any fatal problems or things that I cannot agree with - Of course, if you see any open gaps, any problems, or things that you think could be done better, then PLEASE POST those rather sooner than later. It will help some discussion on the mailing list. Hopefully we can solve the issues and address the concerns on the list and come to convergence. - Those issues that we seem to not be able to find a solution for, or for which we do not come to convergence, ONLY THOSE deserve serious face to face time at the upcoming IETF meeting. - We do NOT WANT just presentations or tutorials. We want serious discussion of open and/or controversial issues. But we all need to prepare for that. It may sound harsh, but if we do not see any serious discussion or signs of review on the WG mailing list, then it seems better to cancel our session at the upconing IETF. Bert and Mehmet -- 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 Jan 28 08:56:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJUSv-000772-Fu for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 08:56:01 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJUSv-0008LC-0q for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 08:56:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJUNF-0001XX-SD for netconf-data@psg.com; Mon, 28 Jan 2008 13:50:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJUN9-0001Vz-1U for netconf@ops.ietf.org; Mon, 28 Jan 2008 13:50:08 +0000 Received: (qmail 80908 invoked from network); 28 Jan 2008 13:50:00 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Jan 2008 13:50:00 -0000 From: "Bert Wijnen" To: "Netconf" Subject: review/comments of/on draft-ietf-netconf-tls-00.txt Date: Mon, 28 Jan 2008 14:50:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Here are my initial comments. Mainly editorial/administrative for now, except for the last comment/question. - ID-NITS tells us: == Missing Reference: 'RFC4279' is mentioned on line 246, but not defined -- Duplicate reference: RFC4346, mentioned in 'TLSEXT', was also mentioned in 'TLS'. Summary: 0 errors (**), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. see: http://tools.ietf.org/wg/netconf/draft-ietf-netconf-tls/draft-ietf-netconf-t ls-00.nits.txt - expand acronyms. You have as title: NETCONF over TLS I suggest to change it to NETCONF over Transport Layer Security (TLS) that would also bee more conistent with the titles of RFC4742, 4743 and 4744 I would also expand the TLS acronym in the abstract and in section 1.1 - general Personally I like ciatations of the form [RFC4346] better than [TLS}. The reason is that I can immediately see which RFC to check. I know it is subjective. So if you feel strong about your form of citation, then I will respect that. - Section 1.1 I wonder if it would not be better to be more consistent with the other NETCONF documents and use the terms "client"and "server" instead of "manager" and "agent" In fact throughout the document, you sometimes do use the terms client and server and other times manager and agent. - section 3.2 of the password is stored is used to generate the PSK. It is ----------------^^--------^^ for the seconf "is" maybe change it to "and is" ?? - In section 3.2 I read: The psk_identity_hint is initially defined in section 5.1 of RFC4279 The psk_identity_hint can do double duty and also provide a form of server authentication in the case where the user has the same password on a number of NETCONF agents. and wonder: would that not be risky in that if an intruder discovers the password of one agent, that he then has access to all/several other agents as well? Bert Wijnen -- 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 Jan 28 09:20:58 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJUr4-0004pY-DT for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 09:20:58 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJUr2-0000Rm-6m for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 09:20:58 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJUkf-0005A8-7q for netconf-data@psg.com; Mon, 28 Jan 2008 14:14:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=ALL_TRUSTED,BAYES_00, MISSING_HEADERS autolearn=no version=3.2.3 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJUkc-00059V-7w for netconf@ops.ietf.org; Mon, 28 Jan 2008 14:14:19 +0000 Received: from localhost ([127.0.0.1]:38164 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.68) (envelope-from ) id 1JJUkZ-0005Wv-JW; Mon, 28 Jan 2008 15:14:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: "Netconf" X-Trac-Version: 0.10.4 Cc: netconf@ops.ietf.org X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: Netconf Date: Mon, 28 Jan 2008 14:14:15 -0000 Reply-To: netconf@ops.ietf.org X-URL: http://tools.ietf.org/wg/netconf/trac/ Subject: [Netconf] #19: error-type terminology confusion X-Trac-Ticket-URL: http://tools.ietf.org/wg/netconf/trac/ticket/19 Message-ID: <086.9d5fedb96f679afea723cc5ba2fba6ae@tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: j.schoenwaelder@jacobs-university.de, netconf@ops.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 IzE5OiBlcnJvci10eXBlIHRlcm1pbm9sb2d5IGNvbmZ1c2lvbg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KIFJlcG9ydGVyOiAgai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlICB8ICAg ICAgIE93bmVyOiAgICAgDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTogIG1pbm9yICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9uZTogICAgIA0KQ29tcG9uZW50OiAg UkZDNDc0MSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBWZXJzaW9uOiAgICAg DQogS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIA0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KIEFwcGVuZGl4IEEgb2YgUkZDIDQ3NDEgY2xhc3NpZmllcyBl cnJvcnMgcmVsYXRlZCB0byB0aGUgZXJyb3ItdHlwZXMNCiAndHJhbnNwb3J0JywgJ3JwYycsICdw cm90b2NvbCcsIGFuZCAnYXBwbGljYXRpb24nLiBUaGlzIGlzIGluY29uc2lzdGVudA0KIHdpdGgg dGhlIGxheWVyaW5nIG1vZGVsIGludHJvZHVjZWQgaW4gc2VjdGlvbiAxIHdoaWNoIGRpc3Rpbmd1 aXNoZXMNCiAndHJhbnNwb3J0JywgJ3JwYycsICdvcGVyYXRpb25zJywgYW5kICdjb250ZW50JyBs YXllcnMuIE5vdGUgdGhhdCB0aGUNCiBkZWZpbml0aW9uIG9mIGVycm9yLXR5cGVzIGluIHNlY3Rp b24gNC4zIGlzIHRoZSBwbGFjZSB3aGVyZSB0aGUgY29uZnVzaW9uDQogd2FzIGludHJvZHVjZWQu DQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9uZXRjb25mL3Ry YWMvdGlja2V0LzE5Pg0KTmV0Y29uZiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25ldGNvbmYv dHJhYy8+DQpJc3N1ZSB0cmFja2VyIGZvciB0aGUgTkVUQ09ORiBXb3JraW5nIEdyb3Vw -- 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 Jan 28 09:30:46 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJV0Y-0007vN-Ob for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 09:30:46 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJV0W-0000ci-F2 for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 09:30:46 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJUuL-0006bd-05 for netconf-data@psg.com; Mon, 28 Jan 2008 14:24:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJUuB-0006aD-RN for netconf@ops.ietf.org; Mon, 28 Jan 2008 14:24:16 +0000 Received: (qmail 16890 invoked from network); 28 Jan 2008 14:24:06 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Jan 2008 14:24:06 -0000 From: "Bert Wijnen" To: "Netconf" Subject: review of draft-ietf-netconf-monitoring-00.txt Date: Mon, 28 Jan 2008 15:24:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Here is my initial review. Mainly editorial/administrative for now. - general. There are quite a few ID-NITS as per: http://tools.ietf.org/wg/netconf/draft-ietf-netconf-monitoring/draft-ietf -netconf-monitoring-00.nits.txt - general. I wonder.... is this all we want to write for these type of content models? I.e. just the schema and no explanatory text in english as to what the schema represents? - It seems that wherever you have citations, you have omitted white psace. For example [NETCONF]can be ... described in[RFC2119]. Element: An[XML]Element. - By the way, I personally like citations of the form [RFC4741] better than of the form [NETCONF], because that way I can quicker pick up the referenced RFC. Best I think would be to change [NETCONF] can be ... into NETCONF [RFC4741] can be.... Anyway, I know this is subjective so will respect your choice. - I think that in the Security COnsiderations you should be more specific as to what kind of data/information we speak about and explain how/why that data is a possibly security risk when in the wrong hands. - For [NETCONF-EVENT] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", ID draft-ietf-netconf-notifications-06, February 2007. I have already posted that the "s" is not part of the name of the WG draft (i.e. currently it is draft-ietf-netconf-notifications-11, NOV 2007) - For [XML Schema] Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer Second Edition", W3C XML Schema, October 2004. would you not want to add a ptr to the website? I think it is: http://www.w3.org/TR/xmlschema-0/ - Good news. The schema seems valid: Schema validating with XSV 3.1-1 of 2007/12/11 16:20:05 Target: file:/usr/local/XSV/xsvlog/tmprFp4kbuploaded (Real name: C:\bwietf\netconf-wg\monitoring-schema.xml) docElt: {http://www.w3.org/2001/XMLSchema}schema Validation was strict, starting with type [Anonymous] The schema(s) used for schema-validation had no errors No schema-validity problems were found in the target Not that that means I can read/understand it. That will be a next step, after which I may have more comments/questions. Bert Wijnen -- 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 Jan 28 10:16:50 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJVj8-00072D-Tu for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 10:16:50 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJVj7-0001aB-3R for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 10:16:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJVba-000Dby-Tq for netconf-data@psg.com; Mon, 28 Jan 2008 15:09:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJVbT-000Db8-IS for netconf@ops.ietf.org; Mon, 28 Jan 2008 15:08:57 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m0SG5Kjs733326; Mon, 28 Jan 2008 16:05:20 GMT Message-ID: <479DEFC7.4080600@isima.fr> Date: Mon, 28 Jan 2008 16:07:51 +0100 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Bert Wijnen CC: Netconf Subject: Re: review/comments of/on draft-ietf-netconf-tls-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 28 Jan 2008 16:05:21 +0000 (WET) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Dear Bert, Thank you for your comments, I will integrate all of them in the future version. > - In section 3.2 I read: > > The psk_identity_hint is initially defined in section 5.1 of RFC4279 > The psk_identity_hint can do double duty and also provide a form of > server authentication in the case where the user has the same > password on a number of NETCONF agents. > > and wonder: would that not be risky in that if an intruder discovers > the password of one agent, that he then has access to > all/several other agents as well? Of course it is risky in having the same password shared with several agents, not only from intruder (external entity) point of view but also from any legitimate agent (internal entity) that has the password. The easier way to minimize this risk is by recommending the use of a different password for each agent. However, it is possible to minimize the risk of discovering the password of one user as follows: 1) the user has to store its password in a secure way (e.g. on a temper-resistant), and 2) on each agent, the user stores the hashed value of the concatenation of the password and the agent_id (the agent_id is the agent identifier, e.g. IP address). The user computes the hash version of the concatenation of the password and the agent_id before connecting to the agent. In this way, the intruder that discovers the password of one agent will not be able to have access to all other agents, unless he is able to perform a brute-force or dictionary attack to recover the password in clear text. Best regards, Badra -- 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 Jan 28 10:37:46 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJW3O-0002YV-L4 for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 10:37:46 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJW3M-0002YH-PQ for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 10:37:46 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJVwA-000HTX-C0 for netconf-data@psg.com; Mon, 28 Jan 2008 15:30:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJVvz-000HS8-Rp for netconf@ops.ietf.org; Mon, 28 Jan 2008 15:30:09 +0000 Received: (qmail 83967 invoked from network); 28 Jan 2008 15:30:06 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Jan 2008 15:30:06 -0000 From: "Bert Wijnen" To: "Mohamad Badra" Cc: "Netconf" Subject: RE: review/comments of/on draft-ietf-netconf-tls-00.txt Date: Mon, 28 Jan 2008 16:30:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <479DEFC7.4080600@isima.fr> Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a OK, so that explanation/detail/advice that you give below may be something worthwhile to add to the text, or maybe state such a thing in security considerations section? Or is that already covered in the standard TLS documents? Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Mohamad Badra [mailto:badra@isima.fr] > Verzonden: maandag 28 januari 2008 16:08 > Aan: Bert Wijnen > CC: Netconf > Onderwerp: Re: review/comments of/on draft-ietf-netconf-tls-00.txt > > > Dear Bert, > > Thank you for your comments, I will integrate all of them in the future > version. > > > - In section 3.2 I read: > > > > The psk_identity_hint is initially defined in section 5.1 of RFC4279 > > The psk_identity_hint can do double duty and also provide a form of > > server authentication in the case where the user has the same > > password on a number of NETCONF agents. > > > > and wonder: would that not be risky in that if an intruder discovers > > the password of one agent, that he then has access to > > all/several other agents as well? > > > Of course it is risky in having the same password shared with several > agents, not only from intruder (external entity) point of view but also > from any legitimate agent (internal entity) that has the password. > > The easier way to minimize this risk is by recommending the use of a > different password for each agent. > > However, it is possible to minimize the risk of discovering the password > of one user as follows: 1) the user has to store its password in a > secure way (e.g. on a temper-resistant), and 2) on each agent, the user > stores the hashed value of the concatenation of the password and the > agent_id (the agent_id is the agent identifier, e.g. IP address). The > user computes the hash version of the concatenation of the password and > the agent_id before connecting to the agent. In this way, the intruder > that discovers the password of one agent will not be able to have access > to all other agents, unless he is able to perform a brute-force or > dictionary attack to recover the password in clear text. > > Best regards, > Badra > > -- 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 Jan 28 11:03:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWS7-0006x4-7x for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:03:19 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJWS6-0003FM-E7 for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:03:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJWNv-000M0S-6k for netconf-data@psg.com; Mon, 28 Jan 2008 15:58:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJWNr-000Lzy-Vm for netconf@ops.ietf.org; Mon, 28 Jan 2008 15:58:57 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m0SGtuQm733410; Mon, 28 Jan 2008 16:55:56 GMT Message-ID: <479DFBA2.2090006@isima.fr> Date: Mon, 28 Jan 2008 16:58:26 +0100 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Bert Wijnen CC: Netconf Subject: Re: review/comments of/on draft-ietf-netconf-tls-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 28 Jan 2008 16:55:56 +0000 (WET) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Dear Bert, The TLS documents don't discuss the storage of the credentials (certificates, PSK, etc.). However, they recommend some documents to particularly generate the PSK as described in section 7.2 of RFC4279. I can insert a sub-section on that but I think it will create some interoperability issues if we replace the hashed value of the password with the hashed value of the concatenation of the password and the agent identifier. Personally, I prefer to recommend the use of a different password on each agent. The issues related to the password storage are not related to the TLS itself, and then better to don't discuss them in the document. But adding some hints in the security considerations section may be useful. Best regards, Badra Bert Wijnen a écrit : > OK, so that explanation/detail/advice that you give below may > be something worthwhile to add to the text, or maybe state such > a thing in security considerations section? > > Or is that already covered in the standard TLS documents? > > Bert Wijnen > >> -----Oorspronkelijk bericht----- >> Van: Mohamad Badra [mailto:badra@isima.fr] >> Verzonden: maandag 28 januari 2008 16:08 >> Aan: Bert Wijnen >> CC: Netconf >> Onderwerp: Re: review/comments of/on draft-ietf-netconf-tls-00.txt >> >> >> Dear Bert, >> >> Thank you for your comments, I will integrate all of them in the future >> version. >> >>> - In section 3.2 I read: >>> >>> The psk_identity_hint is initially defined in section 5.1 of RFC4279 >>> The psk_identity_hint can do double duty and also provide a form of >>> server authentication in the case where the user has the same >>> password on a number of NETCONF agents. >>> >>> and wonder: would that not be risky in that if an intruder discovers >>> the password of one agent, that he then has access to >>> all/several other agents as well? >> >> Of course it is risky in having the same password shared with several >> agents, not only from intruder (external entity) point of view but also >> from any legitimate agent (internal entity) that has the password. >> >> The easier way to minimize this risk is by recommending the use of a >> different password for each agent. >> >> However, it is possible to minimize the risk of discovering the password >> of one user as follows: 1) the user has to store its password in a >> secure way (e.g. on a temper-resistant), and 2) on each agent, the user >> stores the hashed value of the concatenation of the password and the >> agent_id (the agent_id is the agent identifier, e.g. IP address). The >> user computes the hash version of the concatenation of the password and >> the agent_id before connecting to the agent. In this way, the intruder >> that discovers the password of one agent will not be able to have access >> to all other agents, unless he is able to perform a brute-force or >> dictionary attack to recover the password in clear text. >> >> Best regards, >> Badra >> >> -- 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 Jan 28 11:09:57 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWYX-0003YQ-FS for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:09:57 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJWYU-0003Om-H8 for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:09:57 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJWLV-000Lc5-Gl for netconf-data@psg.com; Mon, 28 Jan 2008 15:56:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJWLS-000Lax-AC for netconf@ops.ietf.org; Mon, 28 Jan 2008 15:56:28 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 92B2920E2F; Mon, 28 Jan 2008 16:56:24 +0100 (CET) X-AuditID: c1b4fb3c-aaaedbb0000007e0-a1-479dfb282bb9 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 740E2203DF; Mon, 28 Jan 2008 16:56:24 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 16:56:24 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jan 2008 16:56:24 +0100 Message-ID: <479DFB27.9050205@ericsson.com> Date: Mon, 28 Jan 2008 16:56:23 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Bert Wijnen CC: Netconf Subject: Re: DO we really need a session at IETF71? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2008 15:56:24.0159 (UTC) FILETIME=[553DC6F0:01C861C6] X-Brightmail-Tracker: AAAAAA== Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Hello Bert, We are missing the schema discovery draft. It is not merged into the monitoring draft as I see it. I have put in comments for the monitoring draft, and have read the TLS one which is OK. I will shortly publish a 01 version of the partial-locking draft - I think most/many of the netconf people are putting their energies into the modeling work. So please PUSH!!!! for a decision there. Balazs Bert Wijnen wrote: > Dear WG members, > > As you know, we have requested a session slot for IETF71. But > in order for such a session to be usefull, we MUST prepare. > > We now have (for more than 10 days already) revision 00 > documents for all of our currently 3 charterd WG work items. > Namely: > > Title : NETCONF Monitoring Schema > Author(s) : M. Scott, S. Chisholm > Filename : draft-ietf-netconf-monitoring-00.txt > Pages : 14 > Date : 2008-1-15 > > Title : Partial Lock RPC for NETCONF > Author(s) : B. Lengyel, M. Bjorklund > Filename : draft-ietf-netconf-partial-lock-00.txt > Pages : 11 > Date : 2008-01-07 > > Title : NETCONF over TLS > Author(s) : M. Badra > Filename : draft-ietf-netconf-tls-00.txt > Pages : 9 > Date : 2008-01-01 > > Not much commenting and/or discussion has taken place on our > mailing list yet. And that is NOT GOOD. We MUST review and > then comment/discuss these documents on our WG mailing list. > > We need to know: > > - are enough people reading/reviewing the documents > in other words, does the WG really care? > - what do people think about the documents. > don't assume that we as WG chairs will assume that silence > means consent or agreement. If you like it, pls state so > with an email to the mailing list that says something aka: > - I reviewed the document and it is in GOOD SHAPE. > Please publish asap. > - I reviewed (or read) the document and I like it > - I reviewed (or read) the document and I did not see any > fatal problems or things that I cannot agree with > - Of course, if you see any open gaps, any problems, or things > that you think could be done better, then PLEASE POST those > rather sooner than later. It will help some discussion on > the mailing list. Hopefully we can solve the issues and > address the concerns on the list and come to convergence. > - Those issues that we seem to not be able to find a solution > for, or for which we do not come to convergence, ONLY THOSE > deserve serious face to face time at the upcoming IETF meeting. > - We do NOT WANT just presentations or tutorials. We want serious > discussion of open and/or controversial issues. But we all need > to prepare for that. > > It may sound harsh, but if we do not see any serious discussion > or signs of review on the WG mailing list, then it seems better > to cancel our session at the upconing IETF. > > Bert and Mehmet > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jan 28 11:17:10 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWfW-0004ms-0p for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:17:10 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJWfV-0003X4-Kp for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:17:10 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJWZa-000Nvh-4j for netconf-data@psg.com; Mon, 28 Jan 2008 16:11:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJWZS-000Nud-CF for netconf@ops.ietf.org; Mon, 28 Jan 2008 16:11:00 +0000 X-IronPort-AV: E=Sophos;i="4.25,260,1199660400"; d="scan'208";a="4179050" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Jan 2008 17:10:53 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0SGAqe8019976; Mon, 28 Jan 2008 17:10:52 +0100 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp814.cisco.com [10.61.67.46]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0SGAmlJ020483; Mon, 28 Jan 2008 16:10:52 GMT Message-ID: <479DFE88.6030505@cisco.com> Date: Mon, 28 Jan 2008 17:10:48 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Bert Wijnen CC: Netconf Subject: Re: review/comments of/on draft-ietf-netconf-tls-00.txt References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=508; t=1201536652; x=1202400652; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20review/comments=20of/on=20draft-ietf-ne tconf-tls-00.txt |Sender:=20; bh=QKs189oxWO3/8IOxLU/yVOk0Gp2jWy/hN5ZJ4mv6P84=; b=oE5ISO58mOWk0i/qa3wgKXME8cG5TWZbAFqCEXI95UJOBVy1ijdKmDPeoE IYVHIeM+LTX+mNO2Rz7Aib9oZwoGW1yJ/vwBeYyEs39elgrqBeYz2D3tAGVT o28yOK/7+3; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Bert Wijnen wrote: > - Section 1.1 > I wonder if it would not be better to be more consistent with the > other NETCONF documents and use the terms "client"and "server" > instead of "manager" and "agent" > In fact throughout the document, you sometimes do use the > terms client and server and other times manager and agent. > The only reason I used manager and agent in RFC 4744 was that to not do so would have caused more confusion. This ought not apply to NETCONF/TLS. 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 Jan 28 11:19:51 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWi7-0008LW-VT for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:19:51 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJWi7-0003Yr-Gb for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:19:51 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJWd5-000OUz-Aj for netconf-data@psg.com; Mon, 28 Jan 2008 16:14:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJWd2-000OUV-LM for netconf@ops.ietf.org; Mon, 28 Jan 2008 16:14:37 +0000 X-IronPort-AV: E=Sophos;i="4.25,260,1199660400"; d="scan'208";a="4179506" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Jan 2008 17:14:35 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0SGEZdn011844 for ; Mon, 28 Jan 2008 17:14:35 +0100 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp814.cisco.com [10.61.67.46]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0SGEZlJ021813 for ; Mon, 28 Jan 2008 16:14:35 GMT Message-ID: <479DFF6B.5090906@cisco.com> Date: Mon, 28 Jan 2008 17:14:35 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: netconf Subject: additional comments about draft-ietf-netconf-tls-00.txt X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=199; t=1201536875; x=1202400875; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20additional=20comments=20about=20draft-ietf-netc onf-tls-00.txt |Sender:=20; bh=3MTVv7MpMiDmvUfdKw9mBz52vhM9jkHZaE+ZFziLvsY=; b=HjToJmL9QQAp57S2F4Cmuel48lewQlmwAaltq7Z9GGiU1gN3iy4yIkHvK2 NjXG2BHSuneKYUG6mO/DnyB2KGc6YAlQVAx8boTVii8KfV6WEx2Xc3+qPtTZ safZBzVhWX; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Dear all, Can someone please explain to me how NETCONF/TLS could be used in combination with existing user authentication databases on NETCONF servers (e.g., the agents)? Thanks, 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 Jan 28 11:21:54 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWk6-0000h8-Ai for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:21:54 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJWk5-0003ax-H6 for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:21:54 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJWdK-000OWa-KS for netconf-data@psg.com; Mon, 28 Jan 2008 16:14:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJWdG-000OW0-Ry for netconf@ops.ietf.org; Mon, 28 Jan 2008 16:14:52 +0000 Received: (qmail 27170 invoked from network); 28 Jan 2008 16:14:49 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Jan 2008 16:14:49 -0000 From: "Bert Wijnen" To: "Balazs Lengyel" , "Bert Wijnen" Cc: "Netconf" Subject: RE: DO we really need a session at IETF71? Date: Mon, 28 Jan 2008 17:14:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <479DFB27.9050205@ericsson.com> Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Hi Balazs inline Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Verzonden: maandag 28 januari 2008 16:56 > Aan: Bert Wijnen > CC: Netconf > Onderwerp: Re: DO we really need a session at IETF71? > > > Hello Bert, > We are missing the schema discovery draft. It is not merged into > the monitoring draft as I see it. Yep I just reviewed quickly and am also not sure if/how it got merged. So hopefully mark and Sharon can explain what is going on. We (the WG chairs) had asked for the merged document. > I have put in comments for the monitoring draft, and have read > the TLS one which is OK. Thanks. > I will shortly publish a 01 version of the partial-locking draft > Great. At the other hand, just publishing it to address my admin/editorial comments is not needed. What we need is to try and get the WHOLE WG involved and get theire review. We MUST find out (well before IETF71) if there are any serious/controverisal issues that we need to discuss f2f. Once we have more comment, then it is timely enough (in my view) to do a new revision. But I won;t stop you if you have to cycles to do one sooner. > - I think most/many of the netconf people are putting their > energies into the modeling work. > So please PUSH!!!! for a decision there. > That work is also very important, and indeed we need a decision at the updoming IETF on a direction and a base to work from. Nevertheless, here in the NETCONF WG, we MUST also try to make progress and try to meet our milestones that we more or less committed to. As WG chairs Mehmet and I are responsible to focus (here) on the NETCONF chartered tasks and to make sure we have a fruitfull session at IETF71 on the NETCONF chartered WG work items. That is what we are trying to push for with our somewhat hars message. Hope you understand. Bert > Balazs > > > > Bert Wijnen wrote: > > Dear WG members, > > > > As you know, we have requested a session slot for IETF71. But > > in order for such a session to be usefull, we MUST prepare. > > > > We now have (for more than 10 days already) revision 00 > > documents for all of our currently 3 charterd WG work items. > > Namely: > > > > Title : NETCONF Monitoring Schema > > Author(s) : M. Scott, S. Chisholm > > Filename : draft-ietf-netconf-monitoring-00.txt > > Pages : 14 > > Date : 2008-1-15 > > > > Title : Partial Lock RPC for NETCONF > > Author(s) : B. Lengyel, M. Bjorklund > > Filename : draft-ietf-netconf-partial-lock-00.txt > > Pages : 11 > > Date : 2008-01-07 > > > > Title : NETCONF over TLS > > Author(s) : M. Badra > > Filename : draft-ietf-netconf-tls-00.txt > > Pages : 9 > > Date : 2008-01-01 > > > > Not much commenting and/or discussion has taken place on our > > mailing list yet. And that is NOT GOOD. We MUST review and > > then comment/discuss these documents on our WG mailing list. > > > > We need to know: > > > > - are enough people reading/reviewing the documents > > in other words, does the WG really care? > > - what do people think about the documents. > > don't assume that we as WG chairs will assume that silence > > means consent or agreement. If you like it, pls state so > > with an email to the mailing list that says something aka: > > - I reviewed the document and it is in GOOD SHAPE. > > Please publish asap. > > - I reviewed (or read) the document and I like it > > - I reviewed (or read) the document and I did not see any > > fatal problems or things that I cannot agree with > > - Of course, if you see any open gaps, any problems, or things > > that you think could be done better, then PLEASE POST those > > rather sooner than later. It will help some discussion on > > the mailing list. Hopefully we can solve the issues and > > address the concerns on the list and come to convergence. > > - Those issues that we seem to not be able to find a solution > > for, or for which we do not come to convergence, ONLY THOSE > > deserve serious face to face time at the upcoming IETF meeting. > > - We do NOT WANT just presentations or tutorials. We want serious > > discussion of open and/or controversial issues. But we all need > > to prepare for that. > > > > It may sound harsh, but if we do not see any serious discussion > > or signs of review on the WG mailing list, then it seems better > > to cancel our session at the upconing IETF. > > > > Bert and Mehmet > > > > > > -- > > to unsubscribe send a message to netconf-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-netconf@ops.ietf.org Mon Jan 28 11:59:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJXKE-0001m1-6M for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:59:14 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJXKD-0005Bw-PI for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 11:59:14 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJXFZ-0004lh-6Q for netconf-data@psg.com; Mon, 28 Jan 2008 16:54:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJXFV-0004ka-RV for netconf@ops.ietf.org; Mon, 28 Jan 2008 16:54:23 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m0SHoLc3794716; Mon, 28 Jan 2008 17:50:21 GMT Message-ID: <479E0863.4080708@isima.fr> Date: Mon, 28 Jan 2008 17:52:51 +0100 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Eliot Lear CC: netconf Subject: Re: additional comments about draft-ietf-netconf-tls-00.txt References: <479DFF6B.5090906@cisco.com> In-Reply-To: <479DFF6B.5090906@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 28 Jan 2008 17:50:21 +0000 (WET) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f > Can someone please explain to me how NETCONF/TLS could be used in > combination with existing user authentication databases on NETCONF > servers (e.g., the agents)? Before answer your question, I will appreciate if you could kindly tell me how HTTP/TLS, "LDAP protocol over TLS/SSL", FTP/TLS and other protocols do that? Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory -- 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 Jan 28 12:10:40 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJXVI-0002jE-3W for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 12:10:40 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJXVG-0005Sy-I9 for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 12:10:40 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJXQD-0006a9-EI for netconf-data@psg.com; Mon, 28 Jan 2008 17:05:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJXQA-0006YD-HQ for netconf@ops.ietf.org; Mon, 28 Jan 2008 17:05:24 +0000 Received: (qmail 61030 invoked from network); 28 Jan 2008 17:04:23 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Jan 2008 17:04:23 -0000 From: "Bert Wijnen" To: "Netconf" Subject: can I post this Date: Mon, 28 Jan 2008 18:04:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 pls ignore, testing Bert Wijnen -- 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 Jan 28 13:44:16 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJYxs-0003Bu-Np for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 13:44:16 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJYxr-0007iT-5q for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 13:44:16 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJYos-000Ltx-TO for netconf-data@psg.com; Mon, 28 Jan 2008 18:34:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJYop-000Lsv-JM for netconf@ops.ietf.org; Mon, 28 Jan 2008 18:34:57 +0000 X-IronPort-AV: E=Sophos;i="4.25,260,1199660400"; d="scan'208";a="4192135" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Jan 2008 19:34:54 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m0SIYsNV015219; Mon, 28 Jan 2008 19:34:54 +0100 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp814.cisco.com [10.61.67.46]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0SIYslJ008573; Mon, 28 Jan 2008 18:34:54 GMT Message-ID: <479E204D.4020505@cisco.com> Date: Mon, 28 Jan 2008 19:34:53 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mohamad Badra CC: netconf Subject: Re: additional comments about draft-ietf-netconf-tls-00.txt References: <479DFF6B.5090906@cisco.com> <479E0863.4080708@isima.fr> In-Reply-To: <479E0863.4080708@isima.fr> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=695; t=1201545294; x=1202409294; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20additional=20comments=20about=20draft-i etf-netconf-tls-00.txt |Sender:=20; bh=ugHMZFYLa16+tUHebtJjGNf+5q7LsifNyM2Ce0VQJUg=; b=GEYXyToWPpGYM+MQo/A1dcQdITnR+oieck6yqVC9AUo0DScteIMSLiMNCY PTK3jlns4Uwbq92rLtFZ/vups4jJVIjAw4TVgGnAwQj9dJyOHTfyDtkFBxwI LIgmHyazK+; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Mohamad Badra wrote: >> Can someone please explain to me how NETCONF/TLS could be used in >> combination with existing user authentication databases on NETCONF >> servers (e.g., the agents)? > > Before answer your question, I will appreciate if you could kindly > tell me how HTTP/TLS, "LDAP protocol over TLS/SSL", FTP/TLS and other > protocols do that? > > Best regards, HTTP/TLS uses HTTP AUTH to accomplish this task. I don't know much about LDAP, but I suspect there's a SASL or SASL-like transaction somewhere in there. FTP uses the same username/password approaches that existed before TLS. My point: there is no such underlying mechanism in NETCONF. 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 Jan 28 16:28:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbWY-00041E-7Y for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 16:28:14 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJbWW-0006GG-Nc for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 16:28:14 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJbQq-000OHK-PY for netconf-data@psg.com; Mon, 28 Jan 2008 21:22:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [66.249.92.171] (helo=ug-out-1314.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJZ8I-000PZD-Vp for netconf@ops.ietf.org; Mon, 28 Jan 2008 18:55:04 +0000 Received: by ug-out-1314.google.com with SMTP id k3so65511ugf.5 for ; Mon, 28 Jan 2008 10:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=kAlHhPUV6bIjWQ8L8+/qJpmB9fUlKlyEYoBUbkDP92Q=; b=Ti0WsJ6TcxXQc/lY+xpD4wPZCOhDmRhpApk+QShjlxGy9NRCo+jjxaT7ckGpSQ+sklL4f16IOwgfgUD1Kj3M4tJMx0PMqt8wlRtCDaGOVnMGhkmqFlE10ypTwf5jIKB4SxKfsL+mqXeuCMEsdTYP2/UXlkLxrd3TpdKwcqiy9ao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=BpYFefIHdx5y0NGlg7asLV2UaF/dZY2N9le1hEB2I2Pe5o+jPj7qM+QI5UGgaNiyr5BR4XPuwpDTG8t2wvDad3tZwhkSA9xMGuoGfVjsTzgXK0MrZULZxccqMGD/tJs2ifOF5XCCPepbtPqY2HkSFg1YmQFJ1dQn7iIV0p0iGzA= Received: by 10.67.100.12 with SMTP id c12mr450696ugm.28.1201546500833; Mon, 28 Jan 2008 10:55:00 -0800 (PST) Received: by 10.67.28.17 with HTTP; Mon, 28 Jan 2008 10:55:00 -0800 (PST) Message-ID: Date: Mon, 28 Jan 2008 19:55:00 +0100 From: Badra To: "Eliot Lear" Subject: Re: additional comments about draft-ietf-netconf-tls-00.txt Cc: "Mohamad Badra" , netconf In-Reply-To: <479E204D.4020505@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7854_7599044.1201546500833" References: <479DFF6B.5090906@cisco.com> <479E0863.4080708@isima.fr> <479E204D.4020505@cisco.com> Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 ------=_Part_7854_7599044.1201546500833 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Jan 28, 2008 7:34 PM, Eliot Lear wrote: > Mohamad Badra wrote: > >> Can someone please explain to me how NETCONF/TLS could be used in > >> combination with existing user authentication databases on NETCONF > >> servers (e.g., the agents)? > > > > Before answer your question, I will appreciate if you could kindly > > tell me how HTTP/TLS, "LDAP protocol over TLS/SSL", FTP/TLS and other > > protocols do that? > > > > Best regards, > > HTTP/TLS uses HTTP AUTH to accomplish this task. I don't know much > about LDAP, but I suspect there's a SASL or SASL-like transaction > somewhere in there. FTP uses the same username/password approaches that > existed before TLS. My point: there is no such underlying mechanism in > NETCONF. This is not directly specified in the document since it relies on Requirements for Management Interfaces specified in rfc4279. However, if you think it should be clarified, please suggest some text! Best regards, -- Badra ------=_Part_7854_7599044.1201546500833 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On Jan 28, 2008 7:34 PM, Eliot Lear <lear@cisco.com> wrote:
Mohamad Badra wrote:
>> Can someone please explain to me how NETCONF/TLS could be used in
>> combination with existing user authentication databases on NETCONF
>> servers (e.g., the agents)?
>
> Before answer your question, I will appreciate if you could kindly
> tell me how HTTP/TLS, "LDAP protocol over TLS/SSL", FTP/TLS and other
> protocols do that?
>
> Best regards,

HTTP/TLS uses HTTP AUTH to accomplish this task.  I don't know much
about LDAP, but I suspect there's a SASL or SASL-like transaction
somewhere in there.  FTP uses the same username/password approaches that
existed before TLS.  My point: there is no such underlying mechanism in
NETCONF.
 
This is not directly specified in the document since it relies on Requirements for Management Interfaces specified in rfc4279. However, if you think it should be clarified, please suggest some text!
 
Best regards,
--
Badra
------=_Part_7854_7599044.1201546500833-- -- 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 Jan 28 16:40:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbiB-0002fL-KX for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 16:40:15 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJbi9-0006cT-N1 for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 16:40:15 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJbaG-000PqA-QB for netconf-data@psg.com; Mon, 28 Jan 2008 21:32:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.250.3.110] (helo=relay.versatel.net) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJbaD-000Ppa-TI for netconf@ops.ietf.org; Mon, 28 Jan 2008 21:32:03 +0000 Received: (qmail 95368 invoked from network); 28 Jan 2008 21:32:00 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Jan 2008 21:32:00 -0000 From: "Bert Wijnen" To: "Netconf" Subject: Re: review/comments of/on draft-ietf-netconf-tls-00.txt Date: Mon, 28 Jan 2008 22:32:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 I hope Charlie (our Security Advisor) can chime in on this. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Mohamad Badra [mailto:badra@isima.fr] > Verzonden: maandag 28 januari 2008 16:58 > Aan: Bert Wijnen > CC: Netconf > Onderwerp: Re: review/comments of/on draft-ietf-netconf-tls-00.txt > > > Dear Bert, > > The TLS documents don't discuss the storage of the credentials > (certificates, PSK, etc.). However, they recommend some documents to > particularly generate the PSK as described in section 7.2 of RFC4279. > > I can insert a sub-section on that but I think it will create some > interoperability issues if we replace the hashed value of the password > with the hashed value of the concatenation of the password and the agent > identifier. > > Personally, I prefer to recommend the use of a different password on > each agent. The issues related to the password storage are not related > to the TLS itself, and then better to don't discuss them in the > document. But adding some hints in the security considerations section > may be useful. > > Best regards, > Badra > > > Bert Wijnen a écrit : > > OK, so that explanation/detail/advice that you give below may > > be something worthwhile to add to the text, or maybe state such > > a thing in security considerations section? > > > > Or is that already covered in the standard TLS documents? > > > > Bert Wijnen > > > >> -----Oorspronkelijk bericht----- > >> Van: Mohamad Badra [mailto:badra@isima.fr] > >> Verzonden: maandag 28 januari 2008 16:08 > >> Aan: Bert Wijnen > >> CC: Netconf > >> Onderwerp: Re: review/comments of/on draft-ietf-netconf-tls-00.txt > >> > >> > >> Dear Bert, > >> > >> Thank you for your comments, I will integrate all of them in the future > >> version. > >> > >>> - In section 3.2 I read: > >>> > >>> The psk_identity_hint is initially defined in section 5.1 > of RFC4279 > >>> The psk_identity_hint can do double duty and also provide > a form of > >>> server authentication in the case where the user has the same > >>> password on a number of NETCONF agents. > >>> > >>> and wonder: would that not be risky in that if an intruder discovers > >>> the password of one agent, that he then has access to > >>> all/several other agents as well? > >> > >> Of course it is risky in having the same password shared with several > >> agents, not only from intruder (external entity) point of view but also > >> from any legitimate agent (internal entity) that has the password. > >> > >> The easier way to minimize this risk is by recommending the use of a > >> different password for each agent. > >> > >> However, it is possible to minimize the risk of discovering > the password > >> of one user as follows: 1) the user has to store its password in a > >> secure way (e.g. on a temper-resistant), and 2) on each agent, the user > >> stores the hashed value of the concatenation of the password and the > >> agent_id (the agent_id is the agent identifier, e.g. IP address). The > >> user computes the hash version of the concatenation of the password and > >> the agent_id before connecting to the agent. In this way, the intruder > >> that discovers the password of one agent will not be able to > have access > >> to all other agents, unless he is able to perform a brute-force or > >> dictionary attack to recover the password in clear text. > >> > >> Best regards, > >> Badra > >> > >> > > > Bert Wijnen -- 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 Jan 28 18:30:08 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJdQW-0000yT-Pq for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 18:30:08 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJdQW-0000xT-4e for netconf-archive@lists.ietf.org; Mon, 28 Jan 2008 18:30:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJdKB-000Gwi-Bs for netconf-data@psg.com; Mon, 28 Jan 2008 23:23:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [69.147.64.95] (helo=smtp122.sbc.mail.sp1.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJdK7-000GwF-LH for netconf@ops.ietf.org; Mon, 28 Jan 2008 23:23:34 +0000 Received: (qmail 18639 invoked from network); 28 Jan 2008 23:23:27 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.121.104.118 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 28 Jan 2008 23:23:27 -0000 X-YMail-OSG: _n.B9twVM1mgvqf7Vc3ivxcX.KqQvC0gKytQaqmpg9_XAzub4DEk8NL6TNVjKPegIR3I90fyt7phJ3nlcnWZU1p_ X-Yahoo-Newman-Property: ymail-3 Message-ID: <479E6404.3030505@andybierman.com> Date: Mon, 28 Jan 2008 15:23:48 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bert Wijnen CC: Netconf Subject: Re: DO we really need a session at IETF71? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Bert Wijnen wrote: > Dear WG members, > I have commented on all the pre-WG versions of these drafts. I may make further comments on the mailing list (if I find any issues that have not been raised already), but I plan to read all 3 drafts before the WG meeting. I think many people will show up prepared to discuss the drafts, even if they read them the night before the meeting ;-) Andy > As you know, we have requested a session slot for IETF71. But > in order for such a session to be usefull, we MUST prepare. > > We now have (for more than 10 days already) revision 00 > documents for all of our currently 3 charterd WG work items. > Namely: > > Title : NETCONF Monitoring Schema > Author(s) : M. Scott, S. Chisholm > Filename : draft-ietf-netconf-monitoring-00.txt > Pages : 14 > Date : 2008-1-15 > > Title : Partial Lock RPC for NETCONF > Author(s) : B. Lengyel, M. Bjorklund > Filename : draft-ietf-netconf-partial-lock-00.txt > Pages : 11 > Date : 2008-01-07 > > Title : NETCONF over TLS > Author(s) : M. Badra > Filename : draft-ietf-netconf-tls-00.txt > Pages : 9 > Date : 2008-01-01 > > Not much commenting and/or discussion has taken place on our > mailing list yet. And that is NOT GOOD. We MUST review and > then comment/discuss these documents on our WG mailing list. > > We need to know: > > - are enough people reading/reviewing the documents > in other words, does the WG really care? > - what do people think about the documents. > don't assume that we as WG chairs will assume that silence > means consent or agreement. If you like it, pls state so > with an email to the mailing list that says something aka: > - I reviewed the document and it is in GOOD SHAPE. > Please publish asap. > - I reviewed (or read) the document and I like it > - I reviewed (or read) the document and I did not see any > fatal problems or things that I cannot agree with > - Of course, if you see any open gaps, any problems, or things > that you think could be done better, then PLEASE POST those > rather sooner than later. It will help some discussion on > the mailing list. Hopefully we can solve the issues and > address the concerns on the list and come to convergence. > - Those issues that we seem to not be able to find a solution > for, or for which we do not come to convergence, ONLY THOSE > deserve serious face to face time at the upcoming IETF meeting. > - We do NOT WANT just presentations or tutorials. We want serious > discussion of open and/or controversial issues. But we all need > to prepare for that. > > It may sound harsh, but if we do not see any serious discussion > or signs of review on the WG mailing list, then it seems better > to cancel our session at the upconing IETF. > > Bert and Mehmet > > > -- > 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 Jan 29 00:56:06 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJjS2-0005UZ-VQ for netconf-archive@lists.ietf.org; Tue, 29 Jan 2008 00:56:06 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJjS0-00088q-Q2 for netconf-archive@lists.ietf.org; Tue, 29 Jan 2008 00:56:06 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJjHh-0003UK-NH for netconf-data@psg.com; Tue, 29 Jan 2008 05:45:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [131.107.1.27] (helo=mail.exchange.microsoft.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJjHe-0003Tq-JE for netconf@ops.ietf.org; Tue, 29 Jan 2008 05:45:24 +0000 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 28 Jan 2008 21:45:31 -0800 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.10]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.155]) with mapi; Mon, 28 Jan 2008 21:45:31 -0800 From: Charlie Kaufman To: Bert Wijnen , Netconf , "badra@isima.fr" Date: Mon, 28 Jan 2008 21:45:19 -0800 Subject: RE: review/comments of/on draft-ietf-netconf-tls-00.txt Thread-Topic: review/comments of/on draft-ietf-netconf-tls-00.txt Thread-Index: Achh9P6/QmeJdHmHSby+dvS2jud90QAN9ZNA Message-ID: <30C65F3A3407B943826897E025135BE6010D865E0DCD@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <479DFBA2.2090006@isima.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: -0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 The Security Considerations section should at least strongly recommend and possibly even require that users choose different passwords for the different servers they manage. As designers, we should anticipate that real users will ignore that advice (unless we can figure out a way to enforce it, which seems unlikely). We could recommend that they use some secure password storage mechanism to allow passwords to be long and randomly generated, but it's unrealistic to expect such options will always be available. In most scenarios where that is possible, use of client TLS certificates would also be feasible and they offer better security. There probably should be an RFC with recommendations for deriving PSKs from passwords generally so that documents like this one would have something to reference, but I expect the subject would be so controversial that it would never be approved. There are people who believe that IETF should never standardize any protocols based on passwords; we can only hope that this one has a sufficiently low profile to escape their notice. The series of hashes in the current proposal already captures the advantages proposed earlier in this thread. In particular, > >> 2) on each agent, the user > >> stores the hashed value of the concatenation of the password and the > >> agent_id (the agent_id is the agent identifier, e.g. IP address). the current proposal includes in the computation of the PSK the value of psk_identity_hint, which is the DNS name of the agent. This allows agents to store a PSK that even if disclosed is not helpful in authenticating to any other agent. Other comments on this spec: 1) This spec calls for running NETCONF over TLS on a dedicated TCP port. If there is also a TCP port allocated to running NETCONF not over TLS (is there?), this goes against what has been recent IETF policy. While this was done in the early days of SSL (in particular, for HTTP), it uses up twice as many ports and more recently the practice has become some negotiation on the unprotected port in which use of TLS for the rest of the TCP session is negotiated. 2) The last sentence of section 3.1 says that server-only authentication or anonymous mechanism can have password-based client authentication added on as specified in section 3.2. I don't believe that's technically correct. There are mechanisms that do mutual authentication based on public keys (which are described in section 3.1.*), mechanisms that do mutual authentication based on a pre-shared key (which are described in section 3.2.*), mechanisms which use Kerberos (which are not described in this document, but logically could be), mechanisms which are anonymous (which can't be used with NETCONF), and mechanisms which do both public key based authentication of the server and mutual authentication based on a pre-shared key. These last use the techniques of both sections 3.1.* and 3.2.*. For some of the mechanisms, client authentication is optional; those variants also cannot be used with NETCONF. THIS IS ONLY AN ISSUE WITH YOUR TERMINOLOGY; THE IDEAS ARE RIGHT. I could help with text if it's not obvious how to fix it. 3) Particularly in section 2.1, but also elsewhere, I was confused by the relationship between the terms NETCONF manager, NETCONF client, NETCONF agent, and NETCONF server. I believe that for purposes of this document, the first two terms are synonyms and the second two terms are synonyms. If that's true (and more so if it is not), that should be stated somewhere. 4) Section 3.2 does not specify how "stored-hash" is derived from "password". If it is by hashing it, you need to specify what hash function (probably SHA-1). I believe it would be better to dispense with the term "stored-hash" entirely and use "password" in its place. The value to be stored on the server for the purpose of running this protocol should be the PSK rather than the password or any earlier intermediate hash. 5) You should specify canonicalization of the password as entered by the user to the byte string input to the first hash function. RFC 4013 is probably the best reference to cite unless you want something more restrictive. 6) There should probably be a statement of required cipher suites to support interoperability (unless there is some RFC somewhere that can be referenced for this purpose). I would expect that the most commonly used would be: TLS_DHE_PSK_WITH_AES_128_CBC_SHA (authentication using a password), TLS_RSA_WITH_AES_128_CBC_SHA (authentication using X.509 certs), and TLS_RSA_PSK_WITH_AES_128_CBC_SHA (authentication using both). --Charlie -----Original Message----- From: Bert Wijnen [mailto:bertietf@bwijnen.net] Sent: Monday, January 28, 2008 1:30 PM To: Netconf Cc: Charlie Kaufman Subject: RE: review/comments of/on draft-ietf-netconf-tls-00.txt I hope Charlie (our Security Advisor) can chime in on this. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Mohamad Badra [mailto:badra@isima.fr] > Verzonden: maandag 28 januari 2008 16:58 > Aan: Bert Wijnen > CC: Netconf > Onderwerp: Re: review/comments of/on draft-ietf-netconf-tls-00.txt > > > Dear Bert, > > The TLS documents don't discuss the storage of the credentials > (certificates, PSK, etc.). However, they recommend some documents to > particularly generate the PSK as described in section 7.2 of RFC4279. > > I can insert a sub-section on that but I think it will create some > interoperability issues if we replace the hashed value of the password > with the hashed value of the concatenation of the password and the agent > identifier. > > Personally, I prefer to recommend the use of a different password on > each agent. The issues related to the password storage are not related > to the TLS itself, and then better to don't discuss them in the > document. But adding some hints in the security considerations section > may be useful. > > Best regards, > Badra > > > Bert Wijnen a =E9crit : > > OK, so that explanation/detail/advice that you give below may > > be something worthwhile to add to the text, or maybe state such > > a thing in security considerations section? > > > > Or is that already covered in the standard TLS documents? > > > > Bert Wijnen > > > >> -----Oorspronkelijk bericht----- > >> Van: Mohamad Badra [mailto:badra@isima.fr] > >> Verzonden: maandag 28 januari 2008 16:08 > >> Aan: Bert Wijnen > >> CC: Netconf > >> Onderwerp: Re: review/comments of/on draft-ietf-netconf-tls-00.txt > >> > >> > >> Dear Bert, > >> > >> Thank you for your comments, I will integrate all of them in the futur= e > >> version. > >> > >>> - In section 3.2 I read: > >>> > >>> The psk_identity_hint is initially defined in section 5.1 > of RFC4279 > >>> The psk_identity_hint can do double duty and also provide > a form of > >>> server authentication in the case where the user has the same > >>> password on a number of NETCONF agents. > >>> > >>> and wonder: would that not be risky in that if an intruder discover= s > >>> the password of one agent, that he then has access to > >>> all/several other agents as well? > >> > >> Of course it is risky in having the same password shared with several > >> agents, not only from intruder (external entity) point of view but als= o > >> from any legitimate agent (internal entity) that has the password. > >> > >> The easier way to minimize this risk is by recommending the use of a > >> different password for each agent. > >> > >> However, it is possible to minimize the risk of discovering > the password > >> of one user as follows: 1) the user has to store its password in a > >> secure way (e.g. on a temper-resistant), and 2) on each agent, the use= r > >> stores the hashed value of the concatenation of the password and the > >> agent_id (the agent_id is the agent identifier, e.g. IP address). The > >> user computes the hash version of the concatenation of the password an= d > >> the agent_id before connecting to the agent. In this way, the intruder > >> that discovers the password of one agent will not be able to > have access > >> to all other agents, unless he is able to perform a brute-force or > >> dictionary attack to recover the password in clear text. > >> > >> Best regards, > >> Badra > >> > >> > > > -- 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 Jan 29 12:27:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJuEs-0005bT-7J for netconf-archive@lists.ietf.org; Tue, 29 Jan 2008 12:27:14 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJuEp-0005dF-UZ for netconf-archive@lists.ietf.org; Tue, 29 Jan 2008 12:27:14 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJu6Q-0000kD-3g for netconf-data@psg.com; Tue, 29 Jan 2008 17:18:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.55.95.1] (helo=sp.isima.fr) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJu6M-0000ji-F7 for netconf@ops.ietf.org; Tue, 29 Jan 2008 17:18:28 +0000 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m0TIFNZe671906; Tue, 29 Jan 2008 18:15:24 GMT Message-ID: <479F5FC3.9010605@isima.fr> Date: Tue, 29 Jan 2008 18:17:55 +0100 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Charlie Kaufman CC: Bert Wijnen , Netconf Subject: Re: review/comments of/on draft-ietf-netconf-tls-00.txt References: <479DFBA2.2090006@isima.fr> <30C65F3A3407B943826897E025135BE6010D865E0DCD@DF-GRTDANE-MSG.exchange.corp.microsoft.com> In-Reply-To: <30C65F3A3407B943826897E025135BE6010D865E0DCD@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 29 Jan 2008 18:15:24 +0000 (WET) Sender: owner-netconf@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Dear Charlie, Charlie Kaufman a écrit : > The Security Considerations section should at least strongly recommend > and possibly even require that users choose different passwords > for the different servers they manage. As designers, we should > anticipate that real users will ignore that advice (unless we can > figure out a way to enforce it, which seems unlikely). I will insert the following text somewhere in section 3.2 and in the security considerations: "It is RECOMMENDED that users choose different passwords for the different servers they manage." > We could recommend that they use some secure password storage > mechanism to allow passwords to be long and randomly generated, but > it's unrealistic to expect such options will always be available. > In most scenarios where that is possible, use of client TLS certificates > would also be feasible and they offer better security. AFAIK, IETF documents don't specify any recommendation for secure and safe storage, do they? Moreover, RFC4279 said "This document does not specify how the server stores the keys and identities, or how exactly it finds the key corresponding to the identity it receives." In the same way, I think the document should not specify any recommendation for the storage. The security considerations of RFC4279 said: "As with all schemes involving shared keys, special care should be taken to protect the shared values and to limit their exposure over time." We can extend this as follow: "As with all schemes involving shared keys and passwords, special care should be taken to protect the shared values and passwords as well as to limit their exposure over time. Alternatively, using certificates would provide better protection". > There probably should be an RFC with recommendations for deriving > PSKs from passwords generally so that documents like this one would > have something to reference, but I expect the subject would be so > controversial that it would never be approved. There are people who > believe that IETF should never standardize any protocols based on > passwords; we can only hope that this one has a sufficiently low > profile to escape their notice. I will ask the TLS WG about that. > The series of hashes in the current proposal already captures the > advantages proposed earlier in this thread. In particular, > >>>> 2) on each agent, the user >>>> stores the hashed value of the concatenation of the password and the >>>> agent_id (the agent_id is the agent identifier, e.g. IP address). > > the current proposal includes in the computation of the PSK the value > of psk_identity_hint, which is the DNS name of the agent. This allows > agents to store a PSK that even if disclosed is not helpful in > authenticating to any other agent. > OK. > Other comments on this spec: > > 1) This spec calls for running NETCONF over TLS on a dedicated TCP port. > If there is also a TCP port allocated to running NETCONF not over TLS > (is there?), this goes against what has been recent IETF policy. While > this was done in the early days of SSL (in particular, for HTTP), it > uses up twice as many ports and more recently the practice has become > some negotiation on the unprotected port in which use of TLS for the > rest of the TCP session is negotiated. AFAIK, no TCP port for NETCONF. Note that netconfsoaphttp, netconf-beep, and netconf-ssh run NETCONF over the security protocol on a dedicated TCP (or UDP) port. > 2) The last sentence of section 3.1 says that server-only authentication > or anonymous mechanism can have password-based client authentication > added on as specified in section 3.2. I don't believe that's > technically correct. There are mechanisms that do mutual authentication > based on public keys (which are described in section 3.1.*), mechanisms > that do mutual authentication based on a pre-shared key (which are > described in section 3.2.*), mechanisms which use Kerberos (which are > not described in this document, but logically could be), mechanisms > which are anonymous (which can't be used with NETCONF), and mechanisms > which do both public key based authentication of the server and mutual > authentication based on a pre-shared key. These last use the techniques > of both sections 3.1.* and 3.2.*. For some of the mechanisms, client > authentication is optional; those variants also cannot be used with > NETCONF. THIS IS ONLY AN ISSUE WITH YOUR TERMINOLOGY; THE IDEAS ARE > RIGHT. I could help with text if it's not obvious how to fix it. I agree, all of the above mechanisms, excepting the anonymous one, are supported by the document. What about replacing: When public key is used for authentication, TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. For the last two modes, a profile to enable the password-based client (manager) authentication is defined in section 3.2. with: When public key based-certificate authentication is used, TLS supports two authentication modes: mutual and server-side authentication. For the second mode, the client authentication may be done at the application layer or by negotiating one of the ciphersuites defined in RFC4279. This document defines a profile to authenticate the client using PSKs derived from passwords (see section 3.2). Please don't hesitate to submit your text if you think it is always not clear or not fixed. > 3) Particularly in section 2.1, but also elsewhere, I was confused by > the relationship between the terms NETCONF manager, NETCONF client, > NETCONF agent, and NETCONF server. I believe that for purposes of this > document, the first two terms are synonyms and the second two terms > are synonyms. Yes >If that's true (and more so if it is not), that should > be stated somewhere. Fixed. > > 4) Section 3.2 does not specify how "stored-hash" is derived from > "password". If it is by hashing it, you need to specify what hash > function (probably SHA-1). I believe it would be better to > dispense with the term "stored-hash" entirely and use "password" in > its place. The value to be stored on the server for the purpose of > running this protocol should be the PSK rather than the password > or any earlier intermediate hash. Phil Shafer writes : "I'm not a security dude, but just wanted to confirm that this is a new pre-shared key per user, and the normal CLI passwords will not be usable in this scheme, given that the passwords are not stored on the router (or anywhere else), rather the salted or hashed version of the password is stored, ala unix. Deploying new PSKs will be an impediment to deployment." In this way, I replaced the password with its hash value. (In JUNOS, the plain text and the hash value (MD5) are supported!! I will fellow your point of view and use the password instead of the hash value and then store the PSK instead of any other hash value. > 5) You should specify canonicalization of the password as entered > by the user to the byte string input to the first hash function. > RFC 4013 is probably the best reference to cite unless you want > something more restrictive. RFC4279 specifies that in section 5 and recommendes RFC4013. What about saying: "RFC4279 defines some conformance requirements for the PSK, for the PSK identity encoding and for the identity hint. The same requirements apply here as well; in particular on the password." > 6) There should probably be a statement of required cipher suites > to support interoperability (unless there is some RFC somewhere > that can be referenced for this purpose). I would expect that the > most commonly used would be: > TLS_DHE_PSK_WITH_AES_128_CBC_SHA (authentication using a password), > TLS_RSA_WITH_AES_128_CBC_SHA (authentication using X.509 certs), and > TLS_RSA_PSK_WITH_AES_128_CBC_SHA (authentication using both). OK. > > --Charlie > Thanks! Badra -- Mohamad Badra CNRS - LIMOS Laboratory -- 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 netconf-data@psg.com Thu Jan 31 06:24:37 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKXX3-0000r8-Cy for netconf-archive@lists.ietf.org; Thu, 31 Jan 2008 06:24:37 -0500 Received: from kollegium.jtkf.hu ([193.224.97.129]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKXX2-0004wF-Pe for netconf-archive@lists.ietf.org; Thu, 31 Jan 2008 06:24:37 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 4211 by uid 224); Thu, 31 Jan 2008 12:24:36 +0100 Message-Id: <20080131132436.4213.qmail@kollegium.jtkf.hu> To: Subject: January 76% OFF From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b