From andy@netconfcentral.com  Mon Jun  1 08:03:24 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F073A6B56 for <netconf@core3.amsl.com>; Mon,  1 Jun 2009 08:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.708
X-Spam-Level: 
X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.891,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z+AwaRidA9C for <netconf@core3.amsl.com>; Mon,  1 Jun 2009 08:03:22 -0700 (PDT)
Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id AED5F3A696A for <netconf@ietf.org>; Mon,  1 Jun 2009 08:03:22 -0700 (PDT)
Received: (qmail 41229 invoked from network); 1 Jun 2009 15:03:21 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 1 Jun 2009 15:03:20 -0000
X-YMail-OSG: bHv1swkVM1nUm6K5y.wHTYejChufwNXtvNPb76URzXBU2FKmjMkmF.IAGAcOQhzF8ioaOABexnwJzIgmBqu_d9FwW8H.fnhzFhQsaL5Nyk0IQH_zkjif_REZkV.4R6bWFUlxeTCvEJo1Wce_3Gb7n70SH89aG0_LEJwjcvXo987dx_5J3gL5RAKecIiWR2d9alT38Trc7yMHofHyPrI3gt0b5jSj15Ticrz6D7_ERj5pkVKv.S2PYQPXI00BRSz8pjXjRzVpFSCxwfV9sg9V9eijqa3ndUNQcNoS.R5vncGSh87v146q
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A23EDB6.2000303@netconfcentral.com>
Date: Mon, 01 Jun 2009 08:03:18 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Netconf] 4741bis-00: error-path
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2009 15:03:24 -0000

Hi,

pg 16:

    error-path:  Contains the absolute XPath [2] expression identifying
       the element path to the node that is associated with the error
       being reported in a particular rpc-error element.  This element
       will not be present if no appropriate payload element can be
       associated with a particular error condition, or if the
       'bad-element' QString returned in the 'error-info' container is
       sufficient to identify the node associated with the error.  When
       the XPath expression is interpreted, the set of namespace
       declarations are those in scope on the rpc-error element,
       including the default namespace.

[note sentence 2]

pg 85:

          <xs:element name="error-path" type="xs:string" minOccurs="0"/>

[note minOccurs]

When this text was written, there was significantly less understanding of the
content layer details.  Now that YANG is almost here, and the
instance-identifier is available, it seems clear that error-path field
should be used all the time, and the <bad-element>QName</bad-element>
approach should be deprecated.

The error-path should be mandatory-to-implement, not optional.


Andy







From andy@netconfcentral.com  Tue Jun  2 08:32:44 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352A03A6D58 for <netconf@core3.amsl.com>; Tue,  2 Jun 2009 08:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.931
X-Spam-Level: 
X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.669,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9LQQbo7g0SJ for <netconf@core3.amsl.com>; Tue,  2 Jun 2009 08:32:43 -0700 (PDT)
Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 34ADB3A6F4A for <netconf@ietf.org>; Tue,  2 Jun 2009 08:32:43 -0700 (PDT)
Received: (qmail 74347 invoked from network); 2 Jun 2009 15:32:42 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 2 Jun 2009 15:32:41 -0000
X-YMail-OSG: f569qWYVM1kqz6DUdec.4ZMdJ919.s6GWXJnbGcNXDPAWCsThYfM_k0xkF9i21hRANSEmFDly2Ck5ZtIFPvf6QhYCgpzie4lWKQRdwCaqNEf4Kh6O4kpn5W3vizLkCby81A44KgwN9_v5qQzXO0OEr0k4K4eP0FqdNuB.32OANrWGfJROty4QpLPyrFQm1tFK7uLz9uZwAPF6MyH_mJZkYT_GoDhn2R0JEZxC7ZMNh5YwCh8dGhjBG9N9m.hC49wKf78PZUEE3ZWmdvM
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A254617.6040109@netconfcentral.com>
Date: Tue, 02 Jun 2009 08:32:39 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Netconf] notification replay
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2009 15:32:44 -0000

Hi,

According to RFC 5277, stopTime values in the future are valid.
So, when is the <replayComplete> notification really sent?
Is it after the last one in the buffer at subscription-start-time,
or is it sent at 'stopTime', regardless of future notifications?
The text is scattered, contradictory in places, in not clear
on this point.

Also, what about garbage collection?
If a subscription already has been started from
startTime X to stopTime Y, then is it OK to garbage-collect
any replay buffer entries between time X and Y, before they
have been delivered to this subscription?
What if there is an explicit RPC operation like delete-replay-entries()?
Does that make a difference?


Andy




From balazs.lengyel@ericsson.com  Tue Jun  2 09:33:29 2009
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE12E3A6D58 for <netconf@core3.amsl.com>; Tue,  2 Jun 2009 09:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjfelC9zXDp5 for <netconf@core3.amsl.com>; Tue,  2 Jun 2009 09:33:29 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9FD373A6E59 for <netconf@ietf.org>; Tue,  2 Jun 2009 09:33:28 -0700 (PDT)
X-AuditID: c1b4fb3e-b7b4bae00000395e-af-4a2541441064
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id E2.D0.14686.441452A4; Tue,  2 Jun 2009 17:12:04 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 2 Jun 2009 11:31:34 +0200
Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 2 Jun 2009 11:31:33 +0200
Message-ID: <4A24F175.2070201@ericsson.com>
Date: Tue, 02 Jun 2009 11:31:33 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <20090430.160342.82409955.mbj@tail-f.com>	<fa80acf15710.49fec511@huaweisymantec.com> <20090504.093511.126952205.mbj@tail-f.com>
In-Reply-To: <20090504.093511.126952205.mbj@tail-f.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Jun 2009 09:31:33.0832 (UTC) FILETIME=[EB28BC80:01C9E364]
X-Brightmail-Tracker: AAAAAA==
Cc: netconf@ietf.org
Subject: Re: [Netconf] 4741bis - data stores
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2009 16:33:30 -0000

Hello Martin,
I would also add, that
If
- the startup capability is present,
- and if a confirm a commit arrives, for a commit which was sent before a reboot,
the confirm operation SHOULD/MUST be answered with an error, and result in no changes to the 
datastores.

You reverted to startup during reboot, so it is very hard to even understand, what would you 
confirm at this point.
Balazs

Martin Bjorklund wrote:
> Hi,
> 
> WashamFan <Washam.Fan@huaweisymantec.com> wrote:
>>> Hi,
>>>  
>>>  There has been some discussion whether different combinations of
>>>  capabilities are allowed or not.  A clarification could be that we
>>>  explicitly state that any combination is allowed unless otherwise
>>>  stated.
>>>  
>>>  One such combination is :confimed-commit and :startup.  The text on
>>>  :confimed-commit says:
>>>  
>>>     If the device reboots for any reason before the confirm timeout
>>>     expires, the server MUST restore the configuration to its state
>>>     before the confirmed commit was issued.
>>>  
>>>  But this seems to contradict the fact that the startup configuration
>>>  is used when the device boots.
>> I don't see the contradictory. If the device reboots unexpectedly in that
>> case, <startup>(even <running>) has not reflected the changes yet, and 
>> the server should be in the state before the confirmed commit was issued 
>> after <startup> has been loaded.
>>
>> But the point is which datastore the configuration here refers to? candidate?
> 
> It refers to 'running', which makes the contradiction.
> 
> If startup is not present, the confimred commit modifies running.  If
> the box reboots before the confirming commit is given, running is
> reverted to its state before the confirmed commit.
> 
> If startup is present, and the box reboots, running will be
> initialized from startup, and it will (may) not be equal to what it
> was before the confirmed commit.
> 
> 
> /martin
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel@ericsson.com

From mbj@tail-f.com  Tue Jun  2 13:19:02 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7523A7024 for <netconf@core3.amsl.com>; Tue,  2 Jun 2009 13:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mHf9AFsEgYt for <netconf@core3.amsl.com>; Tue,  2 Jun 2009 13:19:01 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4172C3A702F for <netconf@ietf.org>; Tue,  2 Jun 2009 13:18:43 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4163161600E; Tue,  2 Jun 2009 22:18:43 +0200 (CEST)
Date: Tue, 02 Jun 2009 22:18:49 +0200 (CEST)
Message-Id: <20090602.221849.65848130.mbj@tail-f.com>
To: andy@netconfcentral.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4A254617.6040109@netconfcentral.com>
References: <4A254617.6040109@netconfcentral.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] notification replay
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2009 20:19:02 -0000

Hi,

Andy Bierman <andy@netconfcentral.com> wrote:
> Hi,
> 
> According to RFC 5277, stopTime values in the future are valid.
> So, when is the <replayComplete> notification really sent?
> Is it after the last one in the buffer at subscription-start-time,
> or is it sent at 'stopTime', regardless of future notifications?

I think it is clearly not at 'stopTime'.  For this there is
<notificationComplete>.  The intention was that <replayComplete> is
sent as the server finishes the buffered notification and goes into
live mode.  There is one special case - what if a notification is
generated and stored in the log after subscription-start-time, but
before the server has sent all buffered notifications?  Will
<replayComplete> be sent before or after this one?  I am not sure it
matters, so maybe this can be up to the implementation.

> The text is scattered, contradictory in places, in not clear
> on this point.

Agreed.

> Also, what about garbage collection?
> If a subscription already has been started from
> startTime X to stopTime Y, then is it OK to garbage-collect
> any replay buffer entries between time X and Y, before they
> have been delivered to this subscription?

I think it must be ok.



/martin

From root@core3.amsl.com  Wed Jun  3 01:45:01 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 4A3EA3A6AD2; Wed,  3 Jun 2009 01:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090603084501.4A3EA3A6AD2@core3.amsl.com>
Date: Wed,  3 Jun 2009 01:45:01 -0700 (PDT)
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-08.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2009 08:45:01 -0000

--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-08.txt
	Pages           : 31
	Date            : 2009-06-03

The NETCONF protocol defines the lock and unlock RPCs, used to 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-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-netconf-partial-lock-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-06-03014032.I-D@ietf.org>


--NextPart--

From bertietf@bwijnen.net  Wed Jun  3 04:29:01 2009
Return-Path: <bertietf@bwijnen.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B373A6842 for <netconf@core3.amsl.com>; Wed,  3 Jun 2009 04:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.787
X-Spam-Level: 
X-Spam-Status: No, score=0.787 tagged_above=-999 required=5 tests=[AWL=-1.230,  BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlJefnl+N8XK for <netconf@core3.amsl.com>; Wed,  3 Jun 2009 04:28:54 -0700 (PDT)
Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 78D243A6A89 for <netconf@ietf.org>; Wed,  3 Jun 2009 04:28:54 -0700 (PDT)
Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from <bertietf@bwijnen.net>) id 1MBoeK-0005Kw-PQ; Wed, 03 Jun 2009 13:28:53 +0200
Message-ID: <133975A501BF420A85F69CF4B7614671@BertLaptop>
From: "Bert Wijnen \(IETF\)" <bertietf@bwijnen.net>
To: <netconf@ietf.org>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com>
In-Reply-To: <20090603084501.4A3EA3A6AD2@core3.amsl.com>
Date: Wed, 3 Jun 2009 13:28:34 +0200
Organization: Consultant
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_082A_01C9E44F.31C96000"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
Cc: Ron Bonica <rbonica@juniper.net>
Subject: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD and IETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2009 11:29:01 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_082A_01C9E44F.31C96000
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

WG particpants,

Unfortunately, not too many people have given a clear statement of their =

opinion on the question if they could accept Balazs' reasoning w.r.t. =
the
partial lock issues (see below).

But, based on the comments received, We (WG chairs) have asked
Balazs to do a new rev that explains as much as possible what can=20
and cannot be done and what impacts it has?

Balazs has now done so and revision =
draft-ietf-netconf-partial-lock-08.txt
is now available. Revision 7 was already handed to our AD for review
and IETF Last Call, and we believe that this new revision addresses
(or at least explains) the last issues that came up before our AD could=20
do an IETF LC for rev 07.

We have asked Dan (our AD) to pick up revision 08 for IETF Last Call.

I assume all WG members are now OK with this revision. We have
(in the WG chairs views) consensus (at least rough) consensus.
If anyone still has concerns, you can always post them to our NETCONF
mailing list and.or raise them during IETF Last Call.

Thanks you all.
Bert and Mehmet


----- Original Message -----=20
From: Bert Wijnen (IETF)=20
To: Balazs Lengyel ; netconf mailing list=20
Sent: Tuesday, May 19, 2009 8:51 PM
Subject: Re: [Netconf] Partial-lock issues


Thanks Balazs for summarizing.

I believe I (as a technical contributer) can accept your reasoning.

Speaking as document shepherd and WG co-chair I would like to
urge all WG members to state their opinion (or comments) as well.

Bert
  ----- Original Message -----=20
  From: Balazs Lengyel=20
  To: netconf mailing list=20
  Sent: Tuesday, May 19, 2009 12:01 PM
  Subject: [Netconf] Partial-lock issues


  Hello,
  Some people brought it up that partial-locking without partial commit =
is not a good solution as
  it can lead to dead-locks. For one last time I try to list the reasons =
why we included candidate.

  Please state if you can accept the reasoning below or whether you =
think we should allow
  partial-locking ONLY for the running configuration?

  1) As Washam pointed out just by having access control and without =
using any locks we face a
  dead-lock problems:
  - A only has access to /foo, and edits it in candidate
  - B only has access to /bar, and edits it in candidate
  - A terminates it's session
  - Now B can not issue <discard-changes> because it can not modify /foo =
in the candidate
  - B can not issue <commit> because it can not modify /foo in the =
running
  If A and/or B uses partial-locking that will NOT make this situation =
WORSE, as the lock is
  automatically released at the end of the session. The real problem is =
caused by access control.

  2) When partial-locking is used correctly, there is no danger of =
dead-lock, and locking does
  help to protect the individual operator's activities. (In the next =
sequence we presume access
  control will not block any of the actions.)

  - Operator A locks everything it needs both in candidate and running =
in one operation e.g. /foo
  - A edits the locked part in the candidate
  - A issues commit, if this fails due to lock conflicts, it simply =
releases the lock, and let's
  any concurrent operator (e.g. B) work on candidate; B will later =
commit changes done by A as
  well. Lock conflicts can include operator B locking /bar in the =
running configuration
  - Operator B works the same way on another area e.g. /bar
  - The operator that finishes editing last will successfully commit all =
changes to running (by
  this time there are no other locks)

  3) Later we might introduce partial commit, in which case =
partial-locking would be very much
  needed/useful

  4) Partial-locking does no evil

  5) It is nice to have the feature available on all three datastores

  So we propose to keep partial-locking on candidate, but as this is =
only secondary use-case if
  the workgroup decides it can be removed.

  This question has already been raised a number of times, so we would =
like to establish the
  workgroup
  consensus and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING ON =
CANDIDATE SHOULD STAY OR
  SHOULD BE REMOVED !!!!

  Balazs



------=_NextPart_000_082A_01C9E44F.31C96000
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6001.18226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>WG particpants,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>
<DIV><FONT size=3D2>Unfortunately, not too many people&nbsp;have given a =
clear=20
statement of their </FONT></DIV>
<DIV><FONT size=3D2>opinion </FONT><FONT size=3D2>on the question if =
they could=20
accept&nbsp;Balazs' reasoning w.r.t. the</FONT></DIV>
<DIV><FONT size=3D2>partial lock issues (see below).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>But, based on the comments received,&nbsp;We (WG =
chairs) have=20
asked</FONT></DIV>
<DIV><FONT size=3D2>Balazs to do a new rev&nbsp;that explains as =
</FONT><FONT=20
size=3D2>much as possible what can </FONT></DIV>
<DIV><FONT size=3D2>and cannot be done and what impacts it =
has?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Balazs has now done so and=20
revision&nbsp;draft-ietf-netconf-partial-lock-08.txt</FONT></DIV>
<DIV><FONT size=3D2>is now available. Revision 7 was already handed to =
our AD for=20
review</FONT></DIV>
<DIV><FONT size=3D2>and IETF Last Call, and we believe that this new =
revision=20
addresses</FONT></DIV>
<DIV><FONT size=3D2>(or at least explains) the last issues that came up =
before our=20
AD could </FONT></DIV>
<DIV><FONT size=3D2>do an IETF LC for rev 07.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>We have asked Dan (our AD) to pick up revision 08 =
for IETF=20
Last Call.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I assume all WG members are now OK with this =
revision. We=20
have</FONT></DIV>
<DIV><FONT size=3D2>(in the WG chairs views) consensus (at least rough)=20
consensus.</FONT></DIV>
<DIV><FONT size=3D2>If anyone still has concerns, you can always post =
them to our=20
NETCONF</FONT></DIV>
<DIV><FONT size=3D2>mailing list and.or raise them during IETF Last=20
Call.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Thanks you all.</FONT></DIV>
<DIV><FONT size=3D2>Bert and Mehmet</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV></DIV>
<DIV><FONT size=3D2>
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B> <A=20
title=3Dbertietf@bwijnen.net href=3D"">Bert Wijnen (IETF)</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dbalazs.lengyel@ericsson.com=20
href=3D"">Balazs Lengyel</A> ; <A title=3Dnetconf@ietf.org =
href=3D"">netconf mailing=20
list</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, May 19, 2009 8:51 =
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [Netconf] =
Partial-lock=20
issues</DIV>
<DIV><BR></DIV>
<DIV><FONT size=3D2>Thanks Balazs for summarizing.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I believe I (as a technical contributer) can accept =
your=20
reasoning.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Speaking as document shepherd and WG co-chair I =
would like=20
to</FONT></DIV>
<DIV><FONT size=3D2>urge all WG members to state their opinion (or =
comments) as=20
well.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Bert</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dbalazs.lengyel@ericsson.com href=3D"">Balazs Lengyel</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dnetconf@ietf.org =

  href=3D"">netconf mailing list</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, May 19, 2009 =
12:01=20
PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [Netconf] Partial-lock =

  issues</DIV>
  <DIV><BR></DIV>Hello,<BR>Some people brought it up that =
partial-locking=20
  without partial commit is not a good solution as<BR>it can lead to =
dead-locks.=20
  For one last time I try to list the reasons why we included=20
  candidate.<BR><BR>Please state if you can accept the reasoning below =
or=20
  whether you think we should allow<BR>partial-locking ONLY for the =
running=20
  configuration?<BR><BR>1) As Washam pointed out just by having access =
control=20
  and without using any locks we face a<BR>dead-lock problems:<BR>- A =
only has=20
  access to /foo, and edits it in candidate<BR>- B only has access to =
/bar, and=20
  edits it in candidate<BR>- A terminates it's session<BR>- Now B can =
not issue=20
  &lt;discard-changes&gt; because it can not modify /foo in the =
candidate<BR>- B=20
  can not issue &lt;commit&gt; because it can not modify /foo in the=20
  running<BR>If A and/or B uses partial-locking that will NOT make this=20
  situation WORSE, as the lock is<BR>automatically released at the end =
of the=20
  session. The real problem is caused by access control.<BR><BR>2) When=20
  partial-locking is used correctly, there is no danger of dead-lock, =
and=20
  locking does<BR>help to protect the individual operator's activities. =
(In the=20
  next sequence we presume access<BR>control will not block any of the=20
  actions.)<BR><BR>- Operator A locks everything it needs both in =
candidate and=20
  running in one operation e.g. /foo<BR>- A edits the locked part in the =

  candidate<BR>- A issues commit, if this fails due to lock conflicts, =
it simply=20
  releases the lock, and let's<BR>any concurrent operator (e.g. B) work =
on=20
  candidate; B will later commit changes done by A as<BR>well. Lock =
conflicts=20
  can include operator B locking /bar in the running configuration<BR>- =
Operator=20
  B works the same way on another area e.g. /bar<BR>- The operator that =
finishes=20
  editing last will successfully commit all changes to running =
(by<BR>this time=20
  there are no other locks)<BR><BR>3) Later we might introduce partial =
commit,=20
  in which case partial-locking would be very =
much<BR>needed/useful<BR><BR>4)=20
  Partial-locking does no evil<BR><BR>5) It is nice to have the feature=20
  available on all three datastores<BR><BR>So we propose to keep =
partial-locking=20
  on candidate, but as this is only secondary use-case if<BR>the =
workgroup=20
  decides it can be removed.<BR><BR>This question has already been =
raised a=20
  number of times, so we would like to establish =
the<BR>workgroup<BR>consensus=20
  and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING ON CANDIDATE =
SHOULD=20
  STAY OR<BR>SHOULD BE REMOVED=20
!!!!<BR><BR>Balazs<BR><BR><BR></FONT></BLOCKQUOTE></DIV></BODY></HTML>

------=_NextPart_000_082A_01C9E44F.31C96000--


From dbharrington@comcast.net  Wed Jun  3 09:54:17 2009
Return-Path: <dbharrington@comcast.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C9D3A6D8A for <netconf@core3.amsl.com>; Wed,  3 Jun 2009 09:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7WdCgHdLsTg for <netconf@core3.amsl.com>; Wed,  3 Jun 2009 09:54:16 -0700 (PDT)
Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id F25853A6945 for <netconf@ietf.org>; Wed,  3 Jun 2009 09:54:15 -0700 (PDT)
Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA03.westchester.pa.mail.comcast.net with comcast id zR311b00P0cZkys53UuJW2; Wed, 03 Jun 2009 16:54:18 +0000
Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id zUuH1b00j0UQ6dC3WUuHno; Wed, 03 Jun 2009 16:54:18 +0000
From: "David B Harrington" <dbharrington@comcast.net>
To: "'Bert Wijnen \(IETF\)'" <bertietf@bwijnen.net>, <netconf@ietf.org>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com> <133975A501BF420A85F69CF4B7614671@BertLaptop>
Date: Wed, 3 Jun 2009 12:54:14 -0400
Message-ID: <008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01C9E44A.667ADA90"
X-Mailer: Microsoft Office Outlook 11
In-reply-to: <133975A501BF420A85F69CF4B7614671@BertLaptop>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: AcnkPoIvBT0fev4yR82d/5FUa8K7kgAK6hfA
Cc: 'Ron Bonica' <rbonica@juniper.net>
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2009 16:54:17 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0084_01C9E44A.667ADA90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,
 
I think there is a real problem that exists, and Balaz's reasoning
effectively says "let's just ignore the conflict with access control;
then we can make believe the problem does not exist." This does not
make the problem go away.
 
The problem is that the scope of the lock and the scope of the commit
are different.
I believe that for partial lock on candidiate to work, you need a
corresponding partial commit.
This could be handled using an explicit command for partial commit.
It could be handled by allowing multiple candidiates, each containing
a partial config that is specified as a parameter to the partial lock
(or to a partial-copy-config), with what is effectively a global lock
of the partial config and a global commit of that partial config.
The lock and the commit need to match scope. If they do not match, you
will have problems.
 
If the WG chooses to not have a partial commit that corresponds to the
partial lock, or multiple candidiate sandboxes that can allow an
operator to independently lock, edit, and commit a partial config,
then I think the partial lock for candidate should be removed. 
 
That is not my preferred solution, because I believe operators will
need to lock and modify and commit partial configs, but removing the
partial lock from candidiate is probably the easiest for now.
 
dbh
 
 


  _____  

From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On
Behalf Of Bert Wijnen (IETF)
Sent: Wednesday, June 03, 2009 7:29 AM
To: netconf@ietf.org
Cc: Ron Bonica
Subject: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to
AD andIETF Last Call


WG particpants,
 
Unfortunately, not too many people have given a clear statement of
their 
opinion on the question if they could accept Balazs' reasoning w.r.t.
the
partial lock issues (see below).
 
But, based on the comments received, We (WG chairs) have asked
Balazs to do a new rev that explains as much as possible what can 
and cannot be done and what impacts it has?
 
Balazs has now done so and revision
draft-ietf-netconf-partial-lock-08.txt
is now available. Revision 7 was already handed to our AD for review
and IETF Last Call, and we believe that this new revision addresses
(or at least explains) the last issues that came up before our AD
could 
do an IETF LC for rev 07.
 
We have asked Dan (our AD) to pick up revision 08 for IETF Last Call.
 
I assume all WG members are now OK with this revision. We have
(in the WG chairs views) consensus (at least rough) consensus.
If anyone still has concerns, you can always post them to our NETCONF
mailing list and.or raise them during IETF Last Call.
 
Thanks you all.
Bert and Mehmet
 
 

----- Original Message ----- 
From: Bert Wijnen (IETF) 
To: Balazs Lengyel ; netconf mailing list 
Sent: Tuesday, May 19, 2009 8:51 PM
Subject: Re: [Netconf] Partial-lock issues

Thanks Balazs for summarizing.
 
I believe I (as a technical contributer) can accept your reasoning.
 
Speaking as document shepherd and WG co-chair I would like to
urge all WG members to state their opinion (or comments) as well.
 
Bert

----- Original Message ----- 
From: Balazs Lengyel 
To: netconf mailing list 
Sent: Tuesday, May 19, 2009 12:01 PM
Subject: [Netconf] Partial-lock issues

Hello,
Some people brought it up that partial-locking without partial commit
is not a good solution as
it can lead to dead-locks. For one last time I try to list the reasons
why we included candidate.

Please state if you can accept the reasoning below or whether you
think we should allow
partial-locking ONLY for the running configuration?

1) As Washam pointed out just by having access control and without
using any locks we face a
dead-lock problems:
- A only has access to /foo, and edits it in candidate
- B only has access to /bar, and edits it in candidate
- A terminates it's session
- Now B can not issue <discard-changes> because it can not modify /foo
in the candidate
- B can not issue <commit> because it can not modify /foo in the
running
If A and/or B uses partial-locking that will NOT make this situation
WORSE, as the lock is
automatically released at the end of the session. The real problem is
caused by access control.

2) When partial-locking is used correctly, there is no danger of
dead-lock, and locking does
help to protect the individual operator's activities. (In the next
sequence we presume access
control will not block any of the actions.)

- Operator A locks everything it needs both in candidate and running
in one operation e.g. /foo
- A edits the locked part in the candidate
- A issues commit, if this fails due to lock conflicts, it simply
releases the lock, and let's
any concurrent operator (e.g. B) work on candidate; B will later
commit changes done by A as
well. Lock conflicts can include operator B locking /bar in the
running configuration
- Operator B works the same way on another area e.g. /bar
- The operator that finishes editing last will successfully commit all
changes to running (by
this time there are no other locks)

3) Later we might introduce partial commit, in which case
partial-locking would be very much
needed/useful

4) Partial-locking does no evil

5) It is nice to have the feature available on all three datastores

So we propose to keep partial-locking on candidate, but as this is
only secondary use-case if
the workgroup decides it can be removed.

This question has already been raised a number of times, so we would
like to establish the
workgroup
consensus and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING ON
CANDIDATE SHOULD STAY OR
SHOULD BE REMOVED !!!!

Balazs





------=_NextPart_000_0084_01C9E44A.667ADA90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16481" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I think there is a real problem that exists, =
and Balaz's=20
reasoning effectively says "let's just ignore the conflict with access =
control;=20
then we can make believe the problem does not exist." This does not make =
the=20
problem go away.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>The problem is that the scope of the lock and =
the scope of=20
the commit are different.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I believe that for partial lock on candidiate =
to work, you=20
need a corresponding partial commit.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>This could be handled using an explicit command =
for partial=20
commit.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>It could be handled by allowing multiple =
candidiates, each=20
containing a partial config that is specified as a parameter to the =
partial lock=20
(or to a partial-copy-config), with what is effectively a global lock of =
the=20
partial config and a global commit of that partial =
config.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>The lock and the commit need to match scope. If =
they do not=20
match, you will have problems.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>If the WG chooses to not have a partial commit =
that=20
corresponds to the partial lock, or multiple candidiate sandboxes that =
can allow=20
an operator to independently lock, edit, and commit a partial config,=20
then&nbsp;I think the partial lock for candidate should be removed.=20
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>That is not my preferred solution, because I =
believe=20
operators will need to lock and modify and commit partial configs, but =
removing=20
the partial lock from candidiate is probably the easiest for=20
now.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>dbh</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> netconf-bounces@ietf.org=20
  [mailto:netconf-bounces@ietf.org] <B>On Behalf Of </B>Bert Wijnen=20
  (IETF)<BR><B>Sent:</B> Wednesday, June 03, 2009 7:29 AM<BR><B>To:</B>=20
  netconf@ietf.org<BR><B>Cc:</B> Ron Bonica<BR><B>Subject:</B> [Netconf] =
New=20
  draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last=20
  Call<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT size=3D2>WG particpants,</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV>
  <DIV><FONT size=3D2>Unfortunately, not too many people&nbsp;have given =
a clear=20
  statement of their </FONT></DIV>
  <DIV><FONT size=3D2>opinion </FONT><FONT size=3D2>on the question if =
they could=20
  accept&nbsp;Balazs' reasoning w.r.t. the</FONT></DIV>
  <DIV><FONT size=3D2>partial lock issues (see below).</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT size=3D2>But, based on the comments received,&nbsp;We (WG =
chairs)=20
  have asked</FONT></DIV>
  <DIV><FONT size=3D2>Balazs to do a new rev&nbsp;that explains as =
</FONT><FONT=20
  size=3D2>much as possible what can </FONT></DIV>
  <DIV><FONT size=3D2>and cannot be done and what impacts it =
has?</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>Balazs has now done so and=20
  revision&nbsp;draft-ietf-netconf-partial-lock-08.txt</FONT></DIV>
  <DIV><FONT size=3D2>is now available. Revision 7 was already handed to =
our AD=20
  for review</FONT></DIV>
  <DIV><FONT size=3D2>and IETF Last Call, and we believe that this new =
revision=20
  addresses</FONT></DIV>
  <DIV><FONT size=3D2>(or at least explains) the last issues that came =
up before=20
  our AD could </FONT></DIV>
  <DIV><FONT size=3D2>do an IETF LC for rev 07.</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>We have asked Dan (our AD) to pick up revision 08 =
for IETF=20
  Last Call.</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>I assume all WG members are now OK with this =
revision. We=20
  have</FONT></DIV>
  <DIV><FONT size=3D2>(in the WG chairs views) consensus (at least =
rough)=20
  consensus.</FONT></DIV>
  <DIV><FONT size=3D2>If anyone still has concerns, you can always post =
them to=20
  our NETCONF</FONT></DIV>
  <DIV><FONT size=3D2>mailing list and.or raise them during IETF Last=20
  Call.</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>Thanks you all.</FONT></DIV>
  <DIV><FONT size=3D2>Bert and Mehmet</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV></DIV>
  <DIV><FONT size=3D2>
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dbertietf@bwijnen.net href=3D"">Bert Wijnen (IETF)</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dbalazs.lengyel@ericsson.com=20
  href=3D"">Balazs Lengyel</A> ; <A title=3Dnetconf@ietf.org =
href=3D"">netconf mailing=20
  list</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, May 19, 2009 =
8:51 PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [Netconf] =
Partial-lock=20
  issues</DIV>
  <DIV><BR></DIV>
  <DIV><FONT size=3D2>Thanks Balazs for summarizing.</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>I believe I (as a technical contributer) can =
accept your=20
  reasoning.</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>Speaking as document shepherd and WG co-chair I =
would like=20
  to</FONT></DIV>
  <DIV><FONT size=3D2>urge all WG members to state their opinion (or =
comments) as=20
  well.</FONT></DIV>
  <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2>Bert</FONT></DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=3Dbalazs.lengyel@ericsson.com href=3D"">Balazs Lengyel</A> =
</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dnetconf@ietf.org=20
    href=3D"">netconf mailing list</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, May 19, 2009 =
12:01=20
    PM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [Netconf] =
Partial-lock=20
    issues</DIV>
    <DIV><BR></DIV>Hello,<BR>Some people brought it up that =
partial-locking=20
    without partial commit is not a good solution as<BR>it can lead to=20
    dead-locks. For one last time I try to list the reasons why we =
included=20
    candidate.<BR><BR>Please state if you can accept the reasoning below =
or=20
    whether you think we should allow<BR>partial-locking ONLY for the =
running=20
    configuration?<BR><BR>1) As Washam pointed out just by having access =
control=20
    and without using any locks we face a<BR>dead-lock problems:<BR>- A =
only has=20
    access to /foo, and edits it in candidate<BR>- B only has access to =
/bar,=20
    and edits it in candidate<BR>- A terminates it's session<BR>- Now B =
can not=20
    issue &lt;discard-changes&gt; because it can not modify /foo in the=20
    candidate<BR>- B can not issue &lt;commit&gt; because it can not =
modify /foo=20
    in the running<BR>If A and/or B uses partial-locking that will NOT =
make this=20
    situation WORSE, as the lock is<BR>automatically released at the end =
of the=20
    session. The real problem is caused by access control.<BR><BR>2) =
When=20
    partial-locking is used correctly, there is no danger of dead-lock, =
and=20
    locking does<BR>help to protect the individual operator's =
activities. (In=20
    the next sequence we presume access<BR>control will not block any of =
the=20
    actions.)<BR><BR>- Operator A locks everything it needs both in =
candidate=20
    and running in one operation e.g. /foo<BR>- A edits the locked part =
in the=20
    candidate<BR>- A issues commit, if this fails due to lock conflicts, =
it=20
    simply releases the lock, and let's<BR>any concurrent operator (e.g. =
B) work=20
    on candidate; B will later commit changes done by A as<BR>well. Lock =

    conflicts can include operator B locking /bar in the running=20
    configuration<BR>- Operator B works the same way on another area =
e.g.=20
    /bar<BR>- The operator that finishes editing last will successfully =
commit=20
    all changes to running (by<BR>this time there are no other =
locks)<BR><BR>3)=20
    Later we might introduce partial commit, in which case =
partial-locking would=20
    be very much<BR>needed/useful<BR><BR>4) Partial-locking does no=20
    evil<BR><BR>5) It is nice to have the feature available on all three =

    datastores<BR><BR>So we propose to keep partial-locking on =
candidate, but as=20
    this is only secondary use-case if<BR>the workgroup decides it can =
be=20
    removed.<BR><BR>This question has already been raised a number of =
times, so=20
    we would like to establish the<BR>workgroup<BR>consensus and follow =
it.=20
    PLEASE INDICATE WHETHER PARTIAL-LOCKING ON CANDIDATE SHOULD STAY=20
    OR<BR>SHOULD BE REMOVED=20
  =
!!!!<BR><BR>Balazs<BR><BR><BR></FONT></BLOCKQUOTE></DIV></BLOCKQUOTE></BO=
DY></HTML>

------=_NextPart_000_0084_01C9E44A.667ADA90--


From andy@netconfcentral.com  Wed Jun  3 10:10:17 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D079328C117 for <netconf@core3.amsl.com>; Wed,  3 Jun 2009 10:10:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.853
X-Spam-Level: 
X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.146,  BAYES_00=-2.599, J_CHICKENPOX_32=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUpqLtQyBm+N for <netconf@core3.amsl.com>; Wed,  3 Jun 2009 10:10:16 -0700 (PDT)
Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 9AA063A68BC for <netconf@ietf.org>; Wed,  3 Jun 2009 10:10:16 -0700 (PDT)
Received: (qmail 35739 invoked from network); 3 Jun 2009 17:10:15 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 3 Jun 2009 17:10:15 -0000
X-YMail-OSG: NI0tpB4VM1nMSMU7xC3vRiAkWDcKlGHEmLVWgb0BvqnFWVEUleX6zHQuI.4hig4CasxR7fa5uVD7_XEsShnqstEfamAPF2HJs7iSWMA9aqR1IMtd4bs3uPfVjs61svoHT7APVVbr_32u3UJdAwgpddhBIGF16u3Tg6DttA3whR9WdkhLyPf6LgSWPrVA_lMuIb_u18g6aAcPLjDZRsppeQMSyYolq3U3bVcV7bQrlaU2IiNXWHgjHNjcq.lQ6kTRqO.NSrpsPKQPHMoWbIDvd99_Zkl82NZH_2C2PN.qcOy6FbP9
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A26AE5F.80906@netconfcentral.com>
Date: Wed, 03 Jun 2009 10:09:51 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: David B Harrington <dbharrington@comcast.net>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com>	<133975A501BF420A85F69CF4B7614671@BertLaptop> <008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com>
In-Reply-To: <008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'Ron Bonica' <rbonica@juniper.net>, netconf@ietf.org
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD	andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2009 17:10:17 -0000

David B Harrington wrote:
> Hi,
>  
> I think there is a real problem that exists, and Balaz's reasoning 
> effectively says "let's just ignore the conflict with access control; 
> then we can make believe the problem does not exist." This does not make 
> the problem go away.
>  
> The problem is that the scope of the lock and the scope of the commit 
> are different.
> I believe that for partial lock on candidiate to work, you need a 
> corresponding partial commit.
> This could be handled using an explicit command for partial commit.
> It could be handled by allowing multiple candidiates, each containing a 
> partial config that is specified as a parameter to the partial lock (or 
> to a partial-copy-config), with what is effectively a global lock of the 
> partial config and a global commit of that partial config.
> The lock and the commit need to match scope. If they do not match, you 
> will have problems.
>  
> If the WG chooses to not have a partial commit that corresponds to the 
> partial lock, or multiple candidiate sandboxes that can allow an 
> operator to independently lock, edit, and commit a partial config, 
> then I think the partial lock for candidate should be removed.
>  

As I have stated before, I strongly object to changing
the NETCONF database architecture without a complete
re-charter and development of a NETCONF Architecture
document first -- one that does not ignore access control.

NETCONF databases and SQL databases do different things,
and are intended for different target environments.
For NETCONF servers, CM database manipulation is a 2nd or 3rd
order problem, as opposed to the *only* problem for
an SQL server.

Partial commit does not work for <candidate>.
It can have the same effect as not using any lock at all,
which IMO fails claim #4 below (do no evil).

I'm not so sure <partial-lock> works for <running> either.
What if :startup is supported and a <copy-config> is
needed to actually save the changes?  That is a global
operation, which means the independent writers use-case
is a myth.  They may have concurrent edit capability
for <running>, but the copy to <startup> still needs
to be coordinated.


> That is not my preferred solution, because I believe operators will need 
> to lock and modify and commit partial configs, but removing the partial 
> lock from candidiate is probably the easiest for now.
>  
> dbh
>  


Andy



>  
> 
>     ------------------------------------------------------------------------
>     *From:* netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]
>     *On Behalf Of *Bert Wijnen (IETF)
>     *Sent:* Wednesday, June 03, 2009 7:29 AM
>     *To:* netconf@ietf.org
>     *Cc:* Ron Bonica
>     *Subject:* [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes
>     to AD andIETF Last Call
> 
>     WG particpants,
>      
>     Unfortunately, not too many people have given a clear statement of
>     their
>     opinion on the question if they could accept Balazs' reasoning
>     w.r.t. the
>     partial lock issues (see below).
>      
>     But, based on the comments received, We (WG chairs) have asked
>     Balazs to do a new rev that explains as much as possible what can
>     and cannot be done and what impacts it has?
>      
>     Balazs has now done so and
>     revision draft-ietf-netconf-partial-lock-08.txt
>     is now available. Revision 7 was already handed to our AD for review
>     and IETF Last Call, and we believe that this new revision addresses
>     (or at least explains) the last issues that came up before our AD could
>     do an IETF LC for rev 07.
>      
>     We have asked Dan (our AD) to pick up revision 08 for IETF Last Call.
>      
>     I assume all WG members are now OK with this revision. We have
>     (in the WG chairs views) consensus (at least rough) consensus.
>     If anyone still has concerns, you can always post them to our NETCONF
>     mailing list and.or raise them during IETF Last Call.
>      
>     Thanks you all.
>     Bert and Mehmet
>      
>      
>     ----- Original Message -----
>     *From:* Bert Wijnen (IETF)
>     *To:* Balazs Lengyel ; netconf mailing list
>     *Sent:* Tuesday, May 19, 2009 8:51 PM
>     *Subject:* Re: [Netconf] Partial-lock issues
> 
>     Thanks Balazs for summarizing.
>      
>     I believe I (as a technical contributer) can accept your reasoning.
>      
>     Speaking as document shepherd and WG co-chair I would like to
>     urge all WG members to state their opinion (or comments) as well.
>      
>     Bert
> 
>         ----- Original Message -----
>         *From:* Balazs Lengyel
>         *To:* netconf mailing list
>         *Sent:* Tuesday, May 19, 2009 12:01 PM
>         *Subject:* [Netconf] Partial-lock issues
> 
>         Hello,
>         Some people brought it up that partial-locking without partial
>         commit is not a good solution as
>         it can lead to dead-locks. For one last time I try to list the
>         reasons why we included candidate.
> 
>         Please state if you can accept the reasoning below or whether
>         you think we should allow
>         partial-locking ONLY for the running configuration?
> 
>         1) As Washam pointed out just by having access control and
>         without using any locks we face a
>         dead-lock problems:
>         - A only has access to /foo, and edits it in candidate
>         - B only has access to /bar, and edits it in candidate
>         - A terminates it's session
>         - Now B can not issue <discard-changes> because it can not
>         modify /foo in the candidate
>         - B can not issue <commit> because it can not modify /foo in the
>         running
>         If A and/or B uses partial-locking that will NOT make this
>         situation WORSE, as the lock is
>         automatically released at the end of the session. The real
>         problem is caused by access control.
> 
>         2) When partial-locking is used correctly, there is no danger of
>         dead-lock, and locking does
>         help to protect the individual operator's activities. (In the
>         next sequence we presume access
>         control will not block any of the actions.)
> 
>         - Operator A locks everything it needs both in candidate and
>         running in one operation e.g. /foo
>         - A edits the locked part in the candidate
>         - A issues commit, if this fails due to lock conflicts, it
>         simply releases the lock, and let's
>         any concurrent operator (e.g. B) work on candidate; B will later
>         commit changes done by A as
>         well. Lock conflicts can include operator B locking /bar in the
>         running configuration
>         - Operator B works the same way on another area e.g. /bar
>         - The operator that finishes editing last will successfully
>         commit all changes to running (by
>         this time there are no other locks)
> 
>         3) Later we might introduce partial commit, in which case
>         partial-locking would be very much
>         needed/useful
> 
>         4) Partial-locking does no evil
> 
>         5) It is nice to have the feature available on all three datastores
> 
>         So we propose to keep partial-locking on candidate, but as this
>         is only secondary use-case if
>         the workgroup decides it can be removed.
> 
>         This question has already been raised a number of times, so we
>         would like to establish the
>         workgroup
>         consensus and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING
>         ON CANDIDATE SHOULD STAY OR
>         SHOULD BE REMOVED !!!!
> 
>         Balazs
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf



From bertietf@bwijnen.net  Wed Jun  3 10:14:31 2009
Return-Path: <bertietf@bwijnen.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8716428C18B for <netconf@core3.amsl.com>; Wed,  3 Jun 2009 10:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.268
X-Spam-Level: 
X-Spam-Status: No, score=0.268 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkE6cJ5OcNTp for <netconf@core3.amsl.com>; Wed,  3 Jun 2009 10:14:29 -0700 (PDT)
Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 096D428C164 for <netconf@ietf.org>; Wed,  3 Jun 2009 10:13:56 -0700 (PDT)
Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from <bertietf@bwijnen.net>) id 1MBu1w-0000Vn-08; Wed, 03 Jun 2009 19:13:36 +0200
Message-ID: <94619C6C853C465482441B6A4BE188FB@BertLaptop>
From: "Bert Wijnen \(IETF\)" <bertietf@bwijnen.net>
To: "David B Harrington" <dbharrington@comcast.net>, <netconf@ietf.org>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com> <133975A501BF420A85F69CF4B7614671@BertLaptop> <008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com>
In-Reply-To: <008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com>
Date: Wed, 3 Jun 2009 19:13:20 +0200
Organization: Consultant
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0AED_01C9E47F.5B9C4FC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
Cc: 'Ron Bonica' <rbonica@juniper.net>
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2009 17:14:31 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0AED_01C9E47F.5B9C4FC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I really believe that we have worked hard on this document and that it =
deserves publication.
With the Warning that Balazs added, people can understand what the =
issues are and
act accordingly.=20
If we want t o add partial-commit and/or multiple candidate-configs, =
then that is fine.
I am looking forward to Internet-Drafts that make a first pass at =
describing such functions
after which we can discuss if we need a charter update for that =
(assuming we have enough
WG members to work on such a document).

Bert
partial-lock document shepherd and WG co-chair
  ----- Original Message -----=20
  From: David B Harrington=20
  To: 'Bert Wijnen (IETF)' ; netconf@ietf.org=20
  Cc: 'Ron Bonica'=20
  Sent: Wednesday, June 03, 2009 6:54 PM
  Subject: RE: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes =
to AD andIETF Last Call


  Hi,

  I think there is a real problem that exists, and Balaz's reasoning =
effectively says "let's just ignore the conflict with access control; =
then we can make believe the problem does not exist." This does not make =
the problem go away.

  The problem is that the scope of the lock and the scope of the commit =
are different.
  I believe that for partial lock on candidiate to work, you need a =
corresponding partial commit.
  This could be handled using an explicit command for partial commit.
  It could be handled by allowing multiple candidiates, each containing =
a partial config that is specified as a parameter to the partial lock =
(or to a partial-copy-config), with what is effectively a global lock of =
the partial config and a global commit of that partial config.
  The lock and the commit need to match scope. If they do not match, you =
will have problems.

  If the WG chooses to not have a partial commit that corresponds to the =
partial lock, or multiple candidiate sandboxes that can allow an =
operator to independently lock, edit, and commit a partial config, then =
I think the partial lock for candidate should be removed.=20

  That is not my preferred solution, because I believe operators will =
need to lock and modify and commit partial configs, but removing the =
partial lock from candidiate is probably the easiest for now.

  dbh





-------------------------------------------------------------------------=
---
    From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On =
Behalf Of Bert Wijnen (IETF)
    Sent: Wednesday, June 03, 2009 7:29 AM
    To: netconf@ietf.org
    Cc: Ron Bonica
    Subject: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes =
to AD andIETF Last Call


    WG particpants,

    Unfortunately, not too many people have given a clear statement of =
their=20
    opinion on the question if they could accept Balazs' reasoning =
w.r.t. the
    partial lock issues (see below).

    But, based on the comments received, We (WG chairs) have asked
    Balazs to do a new rev that explains as much as possible what can=20
    and cannot be done and what impacts it has?

    Balazs has now done so and revision =
draft-ietf-netconf-partial-lock-08.txt
    is now available. Revision 7 was already handed to our AD for review
    and IETF Last Call, and we believe that this new revision addresses
    (or at least explains) the last issues that came up before our AD =
could=20
    do an IETF LC for rev 07.

    We have asked Dan (our AD) to pick up revision 08 for IETF Last =
Call.

    I assume all WG members are now OK with this revision. We have
    (in the WG chairs views) consensus (at least rough) consensus.
    If anyone still has concerns, you can always post them to our =
NETCONF
    mailing list and.or raise them during IETF Last Call.

    Thanks you all.
    Bert and Mehmet


    ----- Original Message -----=20
    From: Bert Wijnen (IETF)=20
    To: Balazs Lengyel ; netconf mailing list=20
    Sent: Tuesday, May 19, 2009 8:51 PM
    Subject: Re: [Netconf] Partial-lock issues


    Thanks Balazs for summarizing.

    I believe I (as a technical contributer) can accept your reasoning.

    Speaking as document shepherd and WG co-chair I would like to
    urge all WG members to state their opinion (or comments) as well.

    Bert
      ----- Original Message -----=20
      From: Balazs Lengyel=20
      To: netconf mailing list=20
      Sent: Tuesday, May 19, 2009 12:01 PM
      Subject: [Netconf] Partial-lock issues


      Hello,
      Some people brought it up that partial-locking without partial =
commit is not a good solution as
      it can lead to dead-locks. For one last time I try to list the =
reasons why we included candidate.

      Please state if you can accept the reasoning below or whether you =
think we should allow
      partial-locking ONLY for the running configuration?

      1) As Washam pointed out just by having access control and without =
using any locks we face a
      dead-lock problems:
      - A only has access to /foo, and edits it in candidate
      - B only has access to /bar, and edits it in candidate
      - A terminates it's session
      - Now B can not issue <discard-changes> because it can not modify =
/foo in the candidate
      - B can not issue <commit> because it can not modify /foo in the =
running
      If A and/or B uses partial-locking that will NOT make this =
situation WORSE, as the lock is
      automatically released at the end of the session. The real problem =
is caused by access control.

      2) When partial-locking is used correctly, there is no danger of =
dead-lock, and locking does
      help to protect the individual operator's activities. (In the next =
sequence we presume access
      control will not block any of the actions.)

      - Operator A locks everything it needs both in candidate and =
running in one operation e.g. /foo
      - A edits the locked part in the candidate
      - A issues commit, if this fails due to lock conflicts, it simply =
releases the lock, and let's
      any concurrent operator (e.g. B) work on candidate; B will later =
commit changes done by A as
      well. Lock conflicts can include operator B locking /bar in the =
running configuration
      - Operator B works the same way on another area e.g. /bar
      - The operator that finishes editing last will successfully commit =
all changes to running (by
      this time there are no other locks)

      3) Later we might introduce partial commit, in which case =
partial-locking would be very much
      needed/useful

      4) Partial-locking does no evil

      5) It is nice to have the feature available on all three =
datastores

      So we propose to keep partial-locking on candidate, but as this is =
only secondary use-case if
      the workgroup decides it can be removed.

      This question has already been raised a number of times, so we =
would like to establish the
      workgroup
      consensus and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING =
ON CANDIDATE SHOULD STAY OR
      SHOULD BE REMOVED !!!!

      Balazs





-------------------------------------------------------------------------=
-----



  No virus found in this incoming message.
  Checked by AVG - www.avg.com=20
  Version: 8.5.339 / Virus Database: 270.12.52/2152 - Release Date: =
06/03/09 05:53:00

------=_NextPart_000_0AED_01C9E47F.5B9C4FC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6001.18226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>I really believe that we have worked hard on this =
document and=20
that it deserves publication.</FONT></DIV>
<DIV><FONT size=3D2>With the Warning that Balazs added, people can =
understand what=20
the issues are and</FONT></DIV>
<DIV><FONT size=3D2>act accordingly. </FONT></DIV>
<DIV><FONT size=3D2>If we want t o add partial-commit and/or multiple=20
candidate-configs, then that is fine.</FONT></DIV>
<DIV><FONT size=3D2>I am looking forward to Internet-Drafts that make a =
first pass=20
at describing such functions</FONT></DIV>
<DIV><FONT size=3D2>after which we can discuss if we need a charter =
update for=20
that (assuming we have enough</FONT></DIV>
<DIV><FONT size=3D2>WG members to work on such a document).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Bert</FONT></DIV>
<DIV><FONT size=3D2>partial-lock document shepherd and WG =
co-chair</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Ddbharrington@comcast.net =
href=3D"mailto:dbharrington@comcast.net">David=20
  B Harrington</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dbertietf@bwijnen.net=20
  href=3D"mailto:bertietf@bwijnen.net">'Bert Wijnen (IETF)'</A> ; <A=20
  title=3Dnetconf@ietf.org =
href=3D"mailto:netconf@ietf.org">netconf@ietf.org</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Drbonica@juniper.net=20
  href=3D"mailto:rbonica@juniper.net">'Ron Bonica'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, June 03, 2009 =
6:54=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [Netconf] New=20
  draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last =
Call</DIV>
  <DIV><BR></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>I think there is a real problem that exists, =
and Balaz's=20
  reasoning effectively says "let's just ignore the conflict with access =

  control; then we can make believe the problem does not exist." This =
does not=20
  make the problem go away.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>The problem is that the scope of the lock and =
the scope=20
  of the commit are different.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>I believe that for partial lock on candidiate =
to work,=20
  you need a corresponding partial commit.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>This could be handled using an explicit =
command for=20
  partial commit.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>It could be handled by allowing multiple =
candidiates,=20
  each containing a partial config that is specified as a parameter to =
the=20
  partial lock (or to a partial-copy-config), with what is effectively a =
global=20
  lock of the partial config and a global commit of that partial=20
  config.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>The lock and the commit need to match scope. =
If they do=20
  not match, you will have problems.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>If the WG chooses to not have a partial =
commit that=20
  corresponds to the partial lock, or multiple candidiate sandboxes that =
can=20
  allow an operator to independently lock, edit, and commit a partial =
config,=20
  then&nbsp;I think the partial lock for candidate should be removed.=20
  </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>That is not my preferred solution, because I =
believe=20
  operators will need to lock and modify and commit partial configs, but =

  removing the partial lock from candidiate is probably the easiest for=20
  now.</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>dbh</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D125394116-03062009><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV><BR>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> netconf-bounces@ietf.org=20
    [mailto:netconf-bounces@ietf.org] <B>On Behalf Of </B>Bert Wijnen=20
    (IETF)<BR><B>Sent:</B> Wednesday, June 03, 2009 7:29 =
AM<BR><B>To:</B>=20
    netconf@ietf.org<BR><B>Cc:</B> Ron Bonica<BR><B>Subject:</B> =
[Netconf] New=20
    draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last=20
    Call<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT size=3D2>WG particpants,</FONT></DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
    <DIV>
    <DIV><FONT size=3D2>Unfortunately, not too many people&nbsp;have =
given a clear=20
    statement of their </FONT></DIV>
    <DIV><FONT size=3D2>opinion </FONT><FONT size=3D2>on the question if =
they could=20
    accept&nbsp;Balazs' reasoning w.r.t. the</FONT></DIV>
    <DIV><FONT size=3D2>partial lock issues (see below).</FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT size=3D2>But, based on the comments received,&nbsp;We (WG =
chairs)=20
    have asked</FONT></DIV>
    <DIV><FONT size=3D2>Balazs to do a new rev&nbsp;that explains as =
</FONT><FONT=20
    size=3D2>much as possible what can </FONT></DIV>
    <DIV><FONT size=3D2>and cannot be done and what impacts it =
has?</FONT></DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT size=3D2>Balazs has now done so and=20
    revision&nbsp;draft-ietf-netconf-partial-lock-08.txt</FONT></DIV>
    <DIV><FONT size=3D2>is now available. Revision 7 was already handed =
to our AD=20
    for review</FONT></DIV>
    <DIV><FONT size=3D2>and IETF Last Call, and we believe that this new =
revision=20
    addresses</FONT></DIV>
    <DIV><FONT size=3D2>(or at least explains) the last issues that came =
up before=20
    our AD could </FONT></DIV>
    <DIV><FONT size=3D2>do an IETF LC for rev 07.</FONT></DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT size=3D2>We have asked Dan (our AD) to pick up revision =
08 for IETF=20
    Last Call.</FONT></DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT size=3D2>I assume all WG members are now OK with this =
revision. We=20
    have</FONT></DIV>
    <DIV><FONT size=3D2>(in the WG chairs views) consensus (at least =
rough)=20
    consensus.</FONT></DIV>
    <DIV><FONT size=3D2>If anyone still has concerns, you can always =
post them to=20
    our NETCONF</FONT></DIV>
    <DIV><FONT size=3D2>mailing list and.or raise them during IETF Last=20
    Call.</FONT></DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT size=3D2>Thanks you all.</FONT></DIV>
    <DIV><FONT size=3D2>Bert and Mehmet</FONT></DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV></DIV>
    <DIV><FONT size=3D2>
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=3Dbertietf@bwijnen.net href=3D"">Bert Wijnen (IETF)</A> =
</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
    title=3Dbalazs.lengyel@ericsson.com href=3D"">Balazs Lengyel</A> ; =
<A=20
    title=3Dnetconf@ietf.org href=3D"">netconf mailing list</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, May 19, 2009 =
8:51=20
    PM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [Netconf] =
Partial-lock=20
    issues</DIV>
    <DIV><BR></DIV>
    <DIV><FONT size=3D2>Thanks Balazs for summarizing.</FONT></DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT size=3D2>I believe I (as a technical contributer) can =
accept your=20
    reasoning.</FONT></DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT size=3D2>Speaking as document shepherd and WG co-chair I =
would like=20
    to</FONT></DIV>
    <DIV><FONT size=3D2>urge all WG members to state their opinion (or =
comments)=20
    as well.</FONT></DIV>
    <DIV><FONT size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT size=3D2>Bert</FONT></DIV>
    <BLOCKQUOTE=20
    style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
      <DIV style=3D"FONT: 10pt arial">----- Original Message ----- =
</DIV>
      <DIV=20
      style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
      <A title=3Dbalazs.lengyel@ericsson.com href=3D"">Balazs =
Lengyel</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dnetconf@ietf.org=20
      href=3D"">netconf mailing list</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, May 19, 2009 =
12:01=20
      PM</DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [Netconf] =
Partial-lock=20
      issues</DIV>
      <DIV><BR></DIV>Hello,<BR>Some people brought it up that =
partial-locking=20
      without partial commit is not a good solution as<BR>it can lead to =

      dead-locks. For one last time I try to list the reasons why we =
included=20
      candidate.<BR><BR>Please state if you can accept the reasoning =
below or=20
      whether you think we should allow<BR>partial-locking ONLY for the =
running=20
      configuration?<BR><BR>1) As Washam pointed out just by having =
access=20
      control and without using any locks we face a<BR>dead-lock =
problems:<BR>-=20
      A only has access to /foo, and edits it in candidate<BR>- B only =
has=20
      access to /bar, and edits it in candidate<BR>- A terminates it's=20
      session<BR>- Now B can not issue &lt;discard-changes&gt; because =
it can=20
      not modify /foo in the candidate<BR>- B can not issue =
&lt;commit&gt;=20
      because it can not modify /foo in the running<BR>If A and/or B =
uses=20
      partial-locking that will NOT make this situation WORSE, as the =
lock=20
      is<BR>automatically released at the end of the session. The real =
problem=20
      is caused by access control.<BR><BR>2) When partial-locking is =
used=20
      correctly, there is no danger of dead-lock, and locking =
does<BR>help to=20
      protect the individual operator's activities. (In the next =
sequence we=20
      presume access<BR>control will not block any of the =
actions.)<BR><BR>-=20
      Operator A locks everything it needs both in candidate and running =
in one=20
      operation e.g. /foo<BR>- A edits the locked part in the =
candidate<BR>- A=20
      issues commit, if this fails due to lock conflicts, it simply =
releases the=20
      lock, and let's<BR>any concurrent operator (e.g. B) work on =
candidate; B=20
      will later commit changes done by A as<BR>well. Lock conflicts can =
include=20
      operator B locking /bar in the running configuration<BR>- Operator =
B works=20
      the same way on another area e.g. /bar<BR>- The operator that =
finishes=20
      editing last will successfully commit all changes to running =
(by<BR>this=20
      time there are no other locks)<BR><BR>3) Later we might introduce =
partial=20
      commit, in which case partial-locking would be very=20
      much<BR>needed/useful<BR><BR>4) Partial-locking does no =
evil<BR><BR>5) It=20
      is nice to have the feature available on all three =
datastores<BR><BR>So we=20
      propose to keep partial-locking on candidate, but as this is only=20
      secondary use-case if<BR>the workgroup decides it can be=20
      removed.<BR><BR>This question has already been raised a number of =
times,=20
      so we would like to establish the<BR>workgroup<BR>consensus and =
follow it.=20
      PLEASE INDICATE WHETHER PARTIAL-LOCKING ON CANDIDATE SHOULD STAY=20
      OR<BR>SHOULD BE REMOVED=20
    =
!!!!<BR><BR>Balazs<BR><BR><BR></FONT></BLOCKQUOTE></DIV></BLOCKQUOTE>
  <P>
  <HR>

  <P></P><BR>No virus found in this incoming message.<BR>Checked by AVG =
-=20
  www.avg.com <BR>Version: 8.5.339 / Virus Database: 270.12.52/2152 - =
Release=20
  Date: 06/03/09 05:53:00<BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0AED_01C9E47F.5B9C4FC0--


From andy@netconfcentral.com  Wed Jun  3 10:30:23 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A9028C154 for <netconf@core3.amsl.com>; Wed,  3 Jun 2009 10:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level: 
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_00=-2.599, J_CHICKENPOX_32=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJv1GlzVWPn7 for <netconf@core3.amsl.com>; Wed,  3 Jun 2009 10:30:22 -0700 (PDT)
Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id 0233F3A7050 for <netconf@ietf.org>; Wed,  3 Jun 2009 10:30:21 -0700 (PDT)
Received: (qmail 16444 invoked from network); 3 Jun 2009 17:29:43 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 3 Jun 2009 17:29:43 -0000
X-YMail-OSG: m82XodgVM1lAUx46AqKtMP50cGkdMqJlNaph0gN1_tUMLMlnIFbfMoKcoa2lqXGimjxBhIv56HUJOFDrMlQscW7zP.FQUGPHHyqEF7WMyD9E8YaR6JSA5OGLfaIrCFTD5ecuH22d0sB5vybyeoeFxJLqQn6jnUgGgvWT1CXuLjX4hqvNf9REGFL.R755cB0XHo7r2YjZE4e0G22rm9OuxUWWGi9wUptPosVX0IjsQ3HBlcLoY5MS_FzijNIejPJ08bPtlBfzTWweVGOo27qNOzigYpSd5qvFa_QcDMSbgJBqHRtpjE7h6zpu8vwH7iE42PVXaqJlQ9UzvabKXCk-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A26B305.2040302@netconfcentral.com>
Date: Wed, 03 Jun 2009 10:29:41 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com>	<133975A501BF420A85F69CF4B7614671@BertLaptop>	<008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com> <94619C6C853C465482441B6A4BE188FB@BertLaptop>
In-Reply-To: <94619C6C853C465482441B6A4BE188FB@BertLaptop>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org, 'Ron Bonica' <rbonica@juniper.net>
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD	andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2009 17:30:23 -0000

Bert Wijnen (IETF) wrote:
> I really believe that we have worked hard on this document and that it 
> deserves publication.

I agree.
If NV-memory is handled by the agent, then
partial locks on <running> work great.
Well-understood boundaries (e.g., per-ifEntry)
can easily be managed among N writers.


Andy


> With the Warning that Balazs added, people can understand what the 
> issues are and
> act accordingly.
> If we want t o add partial-commit and/or multiple candidate-configs, 
> then that is fine.
> I am looking forward to Internet-Drafts that make a first pass at 
> describing such functions
> after which we can discuss if we need a charter update for that 
> (assuming we have enough
> WG members to work on such a document).
>  
> Bert
> partial-lock document shepherd and WG co-chair
> 
>     ----- Original Message -----
>     *From:* David B Harrington <mailto:dbharrington@comcast.net>
>     *To:* 'Bert Wijnen (IETF)' <mailto:bertietf@bwijnen.net> ;
>     netconf@ietf.org <mailto:netconf@ietf.org>
>     *Cc:* 'Ron Bonica' <mailto:rbonica@juniper.net>
>     *Sent:* Wednesday, June 03, 2009 6:54 PM
>     *Subject:* RE: [Netconf] New draft-ietf-netconf-partial-lock-08.txt
>     goes to AD andIETF Last Call
> 
>     Hi,
>      
>     I think there is a real problem that exists, and Balaz's reasoning
>     effectively says "let's just ignore the conflict with access
>     control; then we can make believe the problem does not exist." This
>     does not make the problem go away.
>      
>     The problem is that the scope of the lock and the scope of the
>     commit are different.
>     I believe that for partial lock on candidiate to work, you need a
>     corresponding partial commit.
>     This could be handled using an explicit command for partial commit.
>     It could be handled by allowing multiple candidiates, each
>     containing a partial config that is specified as a parameter to the
>     partial lock (or to a partial-copy-config), with what is effectively
>     a global lock of the partial config and a global commit of that
>     partial config.
>     The lock and the commit need to match scope. If they do not match,
>     you will have problems.
>      
>     If the WG chooses to not have a partial commit that corresponds to
>     the partial lock, or multiple candidiate sandboxes that can allow an
>     operator to independently lock, edit, and commit a partial config,
>     then I think the partial lock for candidate should be removed.
>      
>     That is not my preferred solution, because I believe operators will
>     need to lock and modify and commit partial configs, but removing the
>     partial lock from candidiate is probably the easiest for now.
>      
>     dbh
>      
>      
> 
>         ------------------------------------------------------------------------
>         *From:* netconf-bounces@ietf.org
>         [mailto:netconf-bounces@ietf.org] *On Behalf Of *Bert Wijnen (IETF)
>         *Sent:* Wednesday, June 03, 2009 7:29 AM
>         *To:* netconf@ietf.org
>         *Cc:* Ron Bonica
>         *Subject:* [Netconf] New draft-ietf-netconf-partial-lock-08.txt
>         goes to AD andIETF Last Call
> 
>         WG particpants,
>          
>         Unfortunately, not too many people have given a clear statement
>         of their
>         opinion on the question if they could accept Balazs' reasoning
>         w.r.t. the
>         partial lock issues (see below).
>          
>         But, based on the comments received, We (WG chairs) have asked
>         Balazs to do a new rev that explains as much as possible what can
>         and cannot be done and what impacts it has?
>          
>         Balazs has now done so and
>         revision draft-ietf-netconf-partial-lock-08.txt
>         is now available. Revision 7 was already handed to our AD for review
>         and IETF Last Call, and we believe that this new revision addresses
>         (or at least explains) the last issues that came up before our
>         AD could
>         do an IETF LC for rev 07.
>          
>         We have asked Dan (our AD) to pick up revision 08 for IETF Last
>         Call.
>          
>         I assume all WG members are now OK with this revision. We have
>         (in the WG chairs views) consensus (at least rough) consensus.
>         If anyone still has concerns, you can always post them to our
>         NETCONF
>         mailing list and.or raise them during IETF Last Call.
>          
>         Thanks you all.
>         Bert and Mehmet
>          
>          
>         ----- Original Message -----
>         *From:* Bert Wijnen (IETF)
>         *To:* Balazs Lengyel ; netconf mailing list
>         *Sent:* Tuesday, May 19, 2009 8:51 PM
>         *Subject:* Re: [Netconf] Partial-lock issues
> 
>         Thanks Balazs for summarizing.
>          
>         I believe I (as a technical contributer) can accept your reasoning.
>          
>         Speaking as document shepherd and WG co-chair I would like to
>         urge all WG members to state their opinion (or comments) as well.
>          
>         Bert
> 
>             ----- Original Message -----
>             *From:* Balazs Lengyel
>             *To:* netconf mailing list
>             *Sent:* Tuesday, May 19, 2009 12:01 PM
>             *Subject:* [Netconf] Partial-lock issues
> 
>             Hello,
>             Some people brought it up that partial-locking without
>             partial commit is not a good solution as
>             it can lead to dead-locks. For one last time I try to list
>             the reasons why we included candidate.
> 
>             Please state if you can accept the reasoning below or
>             whether you think we should allow
>             partial-locking ONLY for the running configuration?
> 
>             1) As Washam pointed out just by having access control and
>             without using any locks we face a
>             dead-lock problems:
>             - A only has access to /foo, and edits it in candidate
>             - B only has access to /bar, and edits it in candidate
>             - A terminates it's session
>             - Now B can not issue <discard-changes> because it can not
>             modify /foo in the candidate
>             - B can not issue <commit> because it can not modify /foo in
>             the running
>             If A and/or B uses partial-locking that will NOT make this
>             situation WORSE, as the lock is
>             automatically released at the end of the session. The real
>             problem is caused by access control.
> 
>             2) When partial-locking is used correctly, there is no
>             danger of dead-lock, and locking does
>             help to protect the individual operator's activities. (In
>             the next sequence we presume access
>             control will not block any of the actions.)
> 
>             - Operator A locks everything it needs both in candidate and
>             running in one operation e.g. /foo
>             - A edits the locked part in the candidate
>             - A issues commit, if this fails due to lock conflicts, it
>             simply releases the lock, and let's
>             any concurrent operator (e.g. B) work on candidate; B will
>             later commit changes done by A as
>             well. Lock conflicts can include operator B locking /bar in
>             the running configuration
>             - Operator B works the same way on another area e.g. /bar
>             - The operator that finishes editing last will successfully
>             commit all changes to running (by
>             this time there are no other locks)
> 
>             3) Later we might introduce partial commit, in which case
>             partial-locking would be very much
>             needed/useful
> 
>             4) Partial-locking does no evil
> 
>             5) It is nice to have the feature available on all three
>             datastores
> 
>             So we propose to keep partial-locking on candidate, but as
>             this is only secondary use-case if
>             the workgroup decides it can be removed.
> 
>             This question has already been raised a number of times, so
>             we would like to establish the
>             workgroup
>             consensus and follow it. PLEASE INDICATE WHETHER
>             PARTIAL-LOCKING ON CANDIDATE SHOULD STAY OR
>             SHOULD BE REMOVED !!!!
> 
>             Balazs
> 
> 
>     ------------------------------------------------------------------------
> 
> 
>     No virus found in this incoming message.
>     Checked by AVG - www.avg.com
>     Version: 8.5.339 / Virus Database: 270.12.52/2152 - Release Date:
>     06/03/09 05:53:00
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf



From balazs.lengyel@ericsson.com  Thu Jun  4 00:39:37 2009
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B92E3A68D7 for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 00:39:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level: 
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB2fZRR5C8Mi for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 00:39:35 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D8B253A6832 for <netconf@ietf.org>; Thu,  4 Jun 2009 00:38:41 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b9cae00000140d-f9-4a2779e5c1e0
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 22.6F.05133.5E9772A4; Thu,  4 Jun 2009 09:38:13 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 4 Jun 2009 09:37:48 +0200
Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 4 Jun 2009 09:37:47 +0200
Message-ID: <4A2779CA.10703@ericsson.com>
Date: Thu, 04 Jun 2009 09:37:46 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: David B Harrington <dbharrington@comcast.net>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com>	<133975A501BF420A85F69CF4B7614671@BertLaptop> <008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com>
In-Reply-To: <008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Jun 2009 07:37:47.0453 (UTC) FILETIME=[5B2576D0:01C9E4E7]
X-Brightmail-Tracker: AAAAAA==
Cc: 'Ron Bonica' <rbonica@juniper.net>, netconf@ietf.org
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD	andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2009 07:39:37 -0000

Hello,
I have to repeat, that the conflict is NOT the result of partial-locking, it is between access 
control and commit. So why should partial-lock be responsible for solving access control issues?

Unless the chairs and the AD agree with my reasoning, I propose to immediately remove 
partial-lock for candidate and startup. While I stand by my earlier arguments, and disagree 
with David, I want to settle this issue fast, and rather remove startup and candidate, then 
keep on arguing.

However remember, that restricting partial-lock to running, will not make the access 
control/commit conflict go away.

Balazs

David B Harrington wrote:
> Hi,
>  
> I think there is a real problem that exists, and Balaz's reasoning 
> effectively says "let's just ignore the conflict with access control; 

BALAZS: No my reasoning says, that you should not solve access control issues in a locking 
draft. Or do you claim, that partial-locking makes the situation worse. If yes please tell me why!

As described in my earlier mail, you can have the same deadlock without partial-lock, so will 
we remove the commit operation, because it can lead to dead-locks :-)

> then we can make believe the problem does not exist." This does not make 
> the problem go away.
>  
> The problem is that the scope of the lock and the scope of the commit 
> are different.

BALAZS: No the problem is with access control. If the user has all needed access rights, there 
will be no dead-locks, or do you think thats not true?

> I believe that for partial lock on candidiate to work, you need a 
> corresponding partial commit.
> This could be handled using an explicit command for partial commit.
> It could be handled by allowing multiple candidiates, each containing a 
> partial config that is specified as a parameter to the partial lock (or 
> to a partial-copy-config), with what is effectively a global lock of the 
> partial config and a global commit of that partial config.
> The lock and the commit need to match scope. If they do not match, you 
> will have problems.
>  
> If the WG chooses to not have a partial commit that corresponds to the 
> partial lock, or multiple candidiate sandboxes that can allow an 
> operator to independently lock, edit, and commit a partial config, 
> then I think the partial lock for candidate should be removed.
>  
> That is not my preferred solution, because I believe operators will need 
> to lock and modify and commit partial configs, but removing the partial 
> lock from candidiate is probably the easiest for now.
>  
> dbh
>  
>  
> 
>     ------------------------------------------------------------------------
>     *From:* netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]
>     *On Behalf Of *Bert Wijnen (IETF)
>     *Sent:* Wednesday, June 03, 2009 7:29 AM
>     *To:* netconf@ietf.org
>     *Cc:* Ron Bonica
>     *Subject:* [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes
>     to AD andIETF Last Call
> 
>     WG particpants,
>      
>     Unfortunately, not too many people have given a clear statement of
>     their
>     opinion on the question if they could accept Balazs' reasoning
>     w.r.t. the
>     partial lock issues (see below).
>      
>     But, based on the comments received, We (WG chairs) have asked
>     Balazs to do a new rev that explains as much as possible what can
>     and cannot be done and what impacts it has?
>      
>     Balazs has now done so and
>     revision draft-ietf-netconf-partial-lock-08.txt
>     is now available. Revision 7 was already handed to our AD for review
>     and IETF Last Call, and we believe that this new revision addresses
>     (or at least explains) the last issues that came up before our AD could
>     do an IETF LC for rev 07.
>      
>     We have asked Dan (our AD) to pick up revision 08 for IETF Last Call.
>      
>     I assume all WG members are now OK with this revision. We have
>     (in the WG chairs views) consensus (at least rough) consensus.
>     If anyone still has concerns, you can always post them to our NETCONF
>     mailing list and.or raise them during IETF Last Call.
>      
>     Thanks you all.
>     Bert and Mehmet
>      
>      
>     ----- Original Message -----
>     *From:* Bert Wijnen (IETF)
>     *To:* Balazs Lengyel ; netconf mailing list
>     *Sent:* Tuesday, May 19, 2009 8:51 PM
>     *Subject:* Re: [Netconf] Partial-lock issues
> 
>     Thanks Balazs for summarizing.
>      
>     I believe I (as a technical contributer) can accept your reasoning.
>      
>     Speaking as document shepherd and WG co-chair I would like to
>     urge all WG members to state their opinion (or comments) as well.
>      
>     Bert
> 
>         ----- Original Message -----
>         *From:* Balazs Lengyel
>         *To:* netconf mailing list
>         *Sent:* Tuesday, May 19, 2009 12:01 PM
>         *Subject:* [Netconf] Partial-lock issues
> 
>         Hello,
>         Some people brought it up that partial-locking without partial
>         commit is not a good solution as
>         it can lead to dead-locks. For one last time I try to list the
>         reasons why we included candidate.
> 
>         Please state if you can accept the reasoning below or whether
>         you think we should allow
>         partial-locking ONLY for the running configuration?
> 
>         1) As Washam pointed out just by having access control and
>         without using any locks we face a
>         dead-lock problems:
>         - A only has access to /foo, and edits it in candidate
>         - B only has access to /bar, and edits it in candidate
>         - A terminates it's session
>         - Now B can not issue <discard-changes> because it can not
>         modify /foo in the candidate
>         - B can not issue <commit> because it can not modify /foo in the
>         running
>         If A and/or B uses partial-locking that will NOT make this
>         situation WORSE, as the lock is
>         automatically released at the end of the session. The real
>         problem is caused by access control.
> 
>         2) When partial-locking is used correctly, there is no danger of
>         dead-lock, and locking does
>         help to protect the individual operator's activities. (In the
>         next sequence we presume access
>         control will not block any of the actions.)
> 
>         - Operator A locks everything it needs both in candidate and
>         running in one operation e.g. /foo
>         - A edits the locked part in the candidate
>         - A issues commit, if this fails due to lock conflicts, it
>         simply releases the lock, and let's
>         any concurrent operator (e.g. B) work on candidate; B will later
>         commit changes done by A as
>         well. Lock conflicts can include operator B locking /bar in the
>         running configuration
>         - Operator B works the same way on another area e.g. /bar
>         - The operator that finishes editing last will successfully
>         commit all changes to running (by
>         this time there are no other locks)
> 
>         3) Later we might introduce partial commit, in which case
>         partial-locking would be very much
>         needed/useful
> 
>         4) Partial-locking does no evil
> 
>         5) It is nice to have the feature available on all three datastores
> 
>         So we propose to keep partial-locking on candidate, but as this
>         is only secondary use-case if
>         the workgroup decides it can be removed.
> 
>         This question has already been raised a number of times, so we
>         would like to establish the
>         workgroup
>         consensus and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING
>         ON CANDIDATE SHOULD STAY OR
>         SHOULD BE REMOVED !!!!
> 
>         Balazs
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel@ericsson.com

From balazs.lengyel@ericsson.com  Thu Jun  4 00:40:35 2009
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296123A68D9 for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 00:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level: 
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKiDPvvmK380 for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 00:40:34 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 368343A6832 for <netconf@ietf.org>; Thu,  4 Jun 2009 00:40:34 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b9cae00000140d-4e-4a277a71cb1a
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 2E.EF.05133.17A772A4; Thu,  4 Jun 2009 09:40:33 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 4 Jun 2009 09:40:33 +0200
Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 4 Jun 2009 09:40:33 +0200
Message-ID: <4A277A70.4080308@ericsson.com>
Date: Thu, 04 Jun 2009 09:40:32 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Andy Bierman <andy@netconfcentral.com>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com>	<133975A501BF420A85F69CF4B7614671@BertLaptop>	<008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com> <4A26AE5F.80906@netconfcentral.com>
In-Reply-To: <4A26AE5F.80906@netconfcentral.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Jun 2009 07:40:33.0366 (UTC) FILETIME=[BE09C760:01C9E4E7]
X-Brightmail-Tracker: AAAAAA==
Cc: netconf@ietf.org, 'Ron Bonica' <rbonica@juniper.net>
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD	andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2009 07:40:35 -0000

Andy Bierman wrote:
> As I have stated before, I strongly object to changing
> the NETCONF database architecture without a complete
> re-charter and development of a NETCONF Architecture
> document first -- one that does not ignore access control.
> 

I agree with Andy, that introducing multiple candidate configs or a partial-commit operation is 
out of scope for now, and requires careful consideration and a recharter.
Balazs

From dromasca@avaya.com  Thu Jun  4 01:01:14 2009
Return-Path: <dromasca@avaya.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A283A6B66 for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 01:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level: 
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5NyMl7N9VNo for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 01:01:13 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 25B843A6A57 for <netconf@ietf.org>; Thu,  4 Jun 2009 01:01:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.41,304,1241409600"; d="scan'208";a="172888129"
Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Jun 2009 04:01:15 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Jun 2009 04:01:14 -0400
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
Date: Thu, 4 Jun 2009 10:00:53 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401757672@307622ANEX5.global.avaya.com>
In-Reply-To: <4A277A70.4080308@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD	andIETF Last Call
Thread-Index: Acnk58JYkPOCnmgyQiuAMH6T7l/IiQAAfBiA
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com>	<133975A501BF420A85F69CF4B7614671@BertLaptop>	<008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com><4A26AE5F.80906@netconfcentral.com> <4A277A70.4080308@ericsson.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Balazs Lengyel" <balazs.lengyel@ericsson.com>, "Andy Bierman" <andy@netconfcentral.com>
Cc: Ron Bonica <rbonica@juniper.net>, netconf@ietf.org
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD	andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2009 08:01:14 -0000

I would like to make progress on this issue and forward the document to
IETF Last Call. My reading from the discussions on the list supports the
chairs opinion about consensus, but also shows that at least one strong
and articulated different opinion exists. This is not reflected in the
current PROTO write-up, so I would like to ask Bert to mention the
minority concerns in section (1e) of the write-up (How solid is the WG
consensus behind this document?).=20

DBH and other - please feel free to re-iterate your concerns as IETF LC
comments.=20

Dan


> -----Original Message-----
> From: netconf-bounces@ietf.org=20
> [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel
> Sent: Thursday, June 04, 2009 10:41 AM
> To: Andy Bierman
> Cc: netconf@ietf.org; 'Ron Bonica'
> Subject: Re: [Netconf] New=20
> draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last Call
>=20
> Andy Bierman wrote:
> > As I have stated before, I strongly object to changing the NETCONF=20
> > database architecture without a complete re-charter and=20
> development of=20
> > a NETCONF Architecture document first -- one that does not ignore=20
> > access control.
> >=20
>=20
> I agree with Andy, that introducing multiple candidate=20
> configs or a partial-commit operation is out of scope for=20
> now, and requires careful consideration and a recharter.
> Balazs
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>=20

From bertietf@bwijnen.net  Thu Jun  4 03:32:00 2009
Return-Path: <bertietf@bwijnen.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0B03A6ADA for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 03:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.06
X-Spam-Level: 
X-Spam-Status: No, score=-0.06 tagged_above=-999 required=5 tests=[AWL=0.382,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvODLNFRr2e6 for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 03:31:59 -0700 (PDT)
Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 287C63A69ED for <netconf@ietf.org>; Thu,  4 Jun 2009 03:31:57 -0700 (PDT)
Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from <bertietf@bwijnen.net>) id 1MCAEU-0002bP-2l; Thu, 04 Jun 2009 12:31:38 +0200
Message-ID: <96099AD4208D4933BC168203606DFE57@BertLaptop>
From: "Bert Wijnen \(IETF\)" <bertietf@bwijnen.net>
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>, "Balazs Lengyel" <balazs.lengyel@ericsson.com>, "Andy Bierman" <andy@netconfcentral.com>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com>	<133975A501BF420A85F69CF4B7614671@BertLaptop>	<008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com><4A26AE5F.80906@netconfcentral.com><4A277A70.4080308@ericsson.com> <EDC652A26FB23C4EB6384A4584434A0401757672@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0401757672@307622ANEX5.global.avaya.com>
Date: Thu, 4 Jun 2009 12:31:23 +0200
Organization: Consultant
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E8D_01C9E510.5EE938F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
Cc: Ron Bonica <rbonica@juniper.net>, netconf@ietf.org
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes toAD	andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2009 10:32:00 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0E8D_01C9E510.5EE938F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I will update the proto-writeup later today

Bert
  ----- Original Message -----=20
  From: Romascanu, Dan (Dan)=20
  To: Balazs Lengyel ; Andy Bierman=20
  Cc: Ron Bonica ; netconf@ietf.org=20
  Sent: Thursday, June 04, 2009 10:00 AM
  Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes =
toAD andIETF Last Call


  I would like to make progress on this issue and forward the document =
to
  IETF Last Call. My reading from the discussions on the list supports =
the
  chairs opinion about consensus, but also shows that at least one =
strong
  and articulated different opinion exists. This is not reflected in the
  current PROTO write-up, so I would like to ask Bert to mention the
  minority concerns in section (1e) of the write-up (How solid is the WG
  consensus behind this document?).=20

  DBH and other - please feel free to re-iterate your concerns as IETF =
LC
  comments.=20

  Dan


  > -----Original Message-----
  > From: netconf-bounces@ietf.org=20
  > [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel
  > Sent: Thursday, June 04, 2009 10:41 AM
  > To: Andy Bierman
  > Cc: netconf@ietf.org; 'Ron Bonica'
  > Subject: Re: [Netconf] New=20
  > draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last Call
  >=20
  > Andy Bierman wrote:
  > > As I have stated before, I strongly object to changing the NETCONF =

  > > database architecture without a complete re-charter and=20
  > development of=20
  > > a NETCONF Architecture document first -- one that does not ignore=20
  > > access control.
  > >=20
  >=20
  > I agree with Andy, that introducing multiple candidate=20
  > configs or a partial-commit operation is out of scope for=20
  > now, and requires careful consideration and a recharter.
  > Balazs
  > _______________________________________________
  > Netconf mailing list
  > Netconf@ietf.org
  > https://www.ietf.org/mailman/listinfo/netconf
  >=20
  _______________________________________________
  Netconf mailing list
  Netconf@ietf.org
  https://www.ietf.org/mailman/listinfo/netconf



-------------------------------------------------------------------------=
-----



  No virus found in this incoming message.
  Checked by AVG - www.avg.com=20
  Version: 8.5.339 / Virus Database: 270.12.52/2152 - Release Date: =
06/03/09 05:53:00

------=_NextPart_000_0E8D_01C9E510.5EE938F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6001.18226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>I will update the proto-writeup later =
today</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Bert</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Ddromasca@avaya.com =
href=3D"mailto:dromasca@avaya.com">Romascanu, Dan=20
  (Dan)</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dbalazs.lengyel@ericsson.com=20
  href=3D"mailto:balazs.lengyel@ericsson.com">Balazs Lengyel</A> ; <A=20
  title=3Dandy@netconfcentral.com =
href=3D"mailto:andy@netconfcentral.com">Andy=20
  Bierman</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Drbonica@juniper.net=20
  href=3D"mailto:rbonica@juniper.net">Ron Bonica</A> ; <A =
title=3Dnetconf@ietf.org=20
  href=3D"mailto:netconf@ietf.org">netconf@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, June 04, 2009 =
10:00=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [Netconf] New=20
  draft-ietf-netconf-partial-lock-08.txt goes toAD andIETF Last =
Call</DIV>
  <DIV><BR></DIV>I would like to make progress on this issue and forward =
the=20
  document to<BR>IETF Last Call. My reading from the discussions on the =
list=20
  supports the<BR>chairs opinion about consensus, but also shows that at =
least=20
  one strong<BR>and articulated different opinion exists. This is not =
reflected=20
  in the<BR>current PROTO write-up, so I would like to ask Bert to =
mention=20
  the<BR>minority concerns in section (1e) of the write-up (How solid is =
the=20
  WG<BR>consensus behind this document?). <BR><BR>DBH and other - please =
feel=20
  free to re-iterate your concerns as IETF LC<BR>comments.=20
  <BR><BR>Dan<BR><BR><BR>&gt; -----Original Message-----<BR>&gt; From: =
<A=20
  href=3D"mailto:netconf-bounces@ietf.org">netconf-bounces@ietf.org</A> =
<BR>&gt;=20
  [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel<BR>&gt; =
Sent:=20
  Thursday, June 04, 2009 10:41 AM<BR>&gt; To: Andy Bierman<BR>&gt; Cc: =
<A=20
  href=3D"mailto:netconf@ietf.org">netconf@ietf.org</A>; 'Ron =
Bonica'<BR>&gt;=20
  Subject: Re: [Netconf] New <BR>&gt; =
draft-ietf-netconf-partial-lock-08.txt=20
  goes to AD andIETF Last Call<BR>&gt; <BR>&gt; Andy Bierman =
wrote:<BR>&gt; &gt;=20
  As I have stated before, I strongly object to changing the NETCONF =
<BR>&gt;=20
  &gt; database architecture without a complete re-charter and <BR>&gt;=20
  development of <BR>&gt; &gt; a NETCONF Architecture document first -- =
one that=20
  does not ignore <BR>&gt; &gt; access control.<BR>&gt; &gt; <BR>&gt; =
<BR>&gt; I=20
  agree with Andy, that introducing multiple candidate <BR>&gt; configs =
or a=20
  partial-commit operation is out of scope for <BR>&gt; now, and =
requires=20
  careful consideration and a recharter.<BR>&gt; Balazs<BR>&gt;=20
  _______________________________________________<BR>&gt; Netconf =
mailing=20
  list<BR>&gt; <A =
href=3D"mailto:Netconf@ietf.org">Netconf@ietf.org</A><BR>&gt; <A=20
  =
href=3D"https://www.ietf.org/mailman/listinfo/netconf">https://www.ietf.o=
rg/mailman/listinfo/netconf</A><BR>&gt;=20
  <BR>_______________________________________________<BR>Netconf mailing =

  list<BR><A href=3D"mailto:Netconf@ietf.org">Netconf@ietf.org</A><BR><A =

  =
href=3D"https://www.ietf.org/mailman/listinfo/netconf">https://www.ietf.o=
rg/mailman/listinfo/netconf</A><BR>
  <P>
  <HR>

  <P></P><BR>No virus found in this incoming message.<BR>Checked by AVG =
- <A=20
  href=3D"http://www.avg.com">www.avg.com</A> <BR>Version: 8.5.339 / =
Virus=20
  Database: 270.12.52/2152 - Release Date: 06/03/09=20
05:53:00<BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0E8D_01C9E510.5EE938F0--


From randy_presuhn@mindspring.com  Thu Jun  4 12:22:19 2009
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7583A6CE0 for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 12:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcHpyBpayaKP for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 12:22:18 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 63C903A6B6F for <netconf@ietf.org>; Thu,  4 Jun 2009 12:22:18 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NECaBUmLwc6mvHu8w4zU6ec4lVhLfUNyyFhprYpOp/+yVy5Zw7VAv9XW+0+J3/ZW; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [68.164.80.196] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1MCIVv-0006M3-Cd for netconf@ietf.org; Thu, 04 Jun 2009 15:22:11 -0400
Message-ID: <007c01c9e549$c1c29d20$6801a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: <netconf@ietf.org>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com>	<133975A501BF420A85F69CF4B7614671@BertLaptop><008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com> <4A2779CA.10703@ericsson.com>
Date: Thu, 4 Jun 2009 12:22:09 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968513d773b89275dc980ef78879b03319a350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 68.164.80.196
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD	andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2009 19:22:19 -0000

Hi -

> From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
> To: "David B Harrington" <dbharrington@comcast.net>
> Cc: "'Ron Bonica'" <rbonica@juniper.net>; <netconf@ietf.org>
> Sent: Thursday, June 04, 2009 12:37 AM
> Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last Call
>
> Hello,
> I have to repeat, that the conflict is NOT the result of partial-locking, it is between access 
> control and commit. So why should partial-lock be responsible for solving access control issues?
> 
> Unless the chairs and the AD agree with my reasoning, I propose to immediately remove 
> partial-lock for candidate and startup. While I stand by my earlier arguments, and disagree 
> with David, I want to settle this issue fast, and rather remove startup and candidate, then 
> keep on arguing.
> 
> However remember, that restricting partial-lock to running, will not make the access 
> control/commit conflict go away.

If one believes that access decisions are made during "commit" then
all these horrible things *will* happen, and it's broken, just as Balazs argues.

If access decisions are *not* made during "commit"  then the problem goes away.

The problem, if I recall an off-line discussion correctly, is the language in an
example in the netconf spec that indicates that access decisions are made
during the commit.  Other than that, I see no reason for access decisions to
be made during commit time in a single-candidate view of how things should
work.

Randy


From Washam.Fan@huaweisymantec.com  Thu Jun  4 20:01:08 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72853A6A20 for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 20:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6JxXoW7i66c for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 20:01:08 -0700 (PDT)
Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id E18133A6867 for <netconf@ietf.org>; Thu,  4 Jun 2009 20:01:07 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KKQ00BC8WDNZ910@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 05 Jun 2009 11:00:59 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KKQ00GFBWDND600@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 05 Jun 2009 11:00:59 +0800 (CST)
Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 05 Jun 2009 11:00:59 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
Message-id: <fc9ea2672efa.4a28faeb@huaweisymantec.com>
Date: Fri, 05 Jun 2009 11:00:59 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <4A2779CA.10703@ericsson.com>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com> <133975A501BF420A85F69CF4B7614671@BertLaptop> <008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com> <4A2779CA.10703@ericsson.com>
Cc: netconf@ietf.org, 'Ron Bonica' <rbonica@juniper.net>
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2009 03:01:08 -0000

Hi,

>  I have to repeat, that the conflict is NOT the result of 
> partial-locking, it is between access 
>  control and commit. So why should partial-lock be responsible for 
> solving access control issues?

I admit partial-locking does not make the things worse, and without
partial-locking, the issues are still there. But on the other hand,
users might benefit little from partial-locking with these issues. And
partial-locking gives an impression it encourages simultaneous-edits
on candidate, which is the key reason of access control issues.

If we benefit little from partial-locking on candidate, then removing
the use case seems OK.

>  Unless the chairs and the AD agree with my reasoning, I propose to 
> immediately remove 
>  partial-lock for candidate and startup. While I stand by my earlier 
> arguments, and disagree 
>  with David, I want to settle this issue fast, and rather remove 
> startup and candidate, then 
>  keep on arguing.
>  
>  However remember, that restricting partial-lock to running, will not 
> make the access 
>  control/commit conflict go away.

I have no idea why the problem happens on running, since commit
does not apply to running.

>  Balazs

washam

From Washam.Fan@huaweisymantec.com  Thu Jun  4 20:06:15 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33713A6867 for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 20:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level: 
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WJSLpC9akhf for <netconf@core3.amsl.com>; Thu,  4 Jun 2009 20:06:15 -0700 (PDT)
Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id C7C093A6813 for <netconf@ietf.org>; Thu,  4 Jun 2009 20:06:14 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KKQ00H1NWMGNM80@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 05 Jun 2009 11:06:16 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KKQ00FEFWMGL700@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 05 Jun 2009 11:06:16 +0800 (CST)
Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 05 Jun 2009 11:06:16 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>
Message-id: <fc32bf665b27.4a28fc28@huaweisymantec.com>
Date: Fri, 05 Jun 2009 11:06:16 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <007c01c9e549$c1c29d20$6801a8c0@oemcomputer>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com> <133975A501BF420A85F69CF4B7614671@BertLaptop> <008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com> <4A2779CA.10703@ericsson.com> <007c01c9e549$c1c29d20$6801a8c0@oemcomputer>
Cc: netconf@ietf.org
Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to	AD andIETF Last Call
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2009 03:06:15 -0000

Hi,

>  If one believes that access decisions are made during "commit" then
>  all these horrible things *will* happen, and it's broken, just as 
> Balazs argues.
>  
>  If access decisions are *not* made during "commit"  then the problem 
> goes away.

I am afraid access decision during commit or not is not the key
reason to the problem. even access decision during config-edit
can cause the problem. The point is, we only edit a portion of
candidate, when we try to commit the whole candidate, we
have no idea if other parts have been modified by other people.

washam

>  The problem, if I recall an off-line discussion correctly, is the 
> language in an
>  example in the netconf spec that indicates that access decisions are 
> made
>  during the commit.  Other than that, I see no reason for access 
> decisions to
>  be made during commit time in a single-candidate view of how things should
>  work.
>  
>  Randy
>  
>  _______________________________________________
>  Netconf mailing list
>  Netconf@ietf.org
>  https://www.ietf.org/mailman/listinfo/netconf
>  

From balazs.lengyel@ericsson.com  Fri Jun  5 04:52:19 2009
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4104628B56A for <netconf@core3.amsl.com>; Fri,  5 Jun 2009 04:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.189
X-Spam-Level: 
X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUUEkIRfmujU for <netconf@core3.amsl.com>; Fri,  5 Jun 2009 04:52:18 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F0C843A6CF6 for <netconf@ietf.org>; Fri,  5 Jun 2009 04:52:17 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b9cae00000140d-c3-4a2906d612d8
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 02.2A.05133.6D6092A4; Fri,  5 Jun 2009 13:51:50 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 5 Jun 2009 13:51:49 +0200
Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 5 Jun 2009 13:51:49 +0200
Message-ID: <4A2906D5.1020305@ericsson.com>
Date: Fri, 05 Jun 2009 13:51:49 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com>	<133975A501BF420A85F69CF4B7614671@BertLaptop><008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com>	<4A2779CA.10703@ericsson.com> <007c01c9e549$c1c29d20$6801a8c0@oemcomputer>
In-Reply-To: <007c01c9e549$c1c29d20$6801a8c0@oemcomputer>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Jun 2009 11:51:49.0754 (UTC) FILETIME=[02ADC5A0:01C9E5D4]
X-Brightmail-Tracker: AAAAAA==
Cc: netconf@ietf.org
Subject: [Netconf] Access control [was: ew draft-ietf-netconf-partial-lock-08.txt goes to	AD
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2009 11:52:19 -0000

Hello Randy,
Some other assumptions that might impact this issue:
- Do we have separate/differing access rights for running and candidate? (I hope not.)
- Your question stated somewhat differently: Do we have access control at edit-config/commit or 
both?
- for commit is the access control allowing the commit operation or the modification of the 
relevant data

We will run into some other interesting issues with access control
- how do you use validate (even for your own little area), if you don't have access rights to 
the full config? If validation can take into account areas that are non-readable for the user, 
that may lead to information leaks.
- can you lock the datastore if you are not allowed to read/write parts of it?

But all these are access control issues NOT partial-locking related.

Balazs

Randy Presuhn wrote:
> Hi -
> 
>> From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
>> To: "David B Harrington" <dbharrington@comcast.net>
>> Cc: "'Ron Bonica'" <rbonica@juniper.net>; <netconf@ietf.org>
>> Sent: Thursday, June 04, 2009 12:37 AM
>> Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last Call
>>
>> Hello,
>> I have to repeat, that the conflict is NOT the result of partial-locking, it is between access 
>> control and commit. So why should partial-lock be responsible for solving access control issues?
>>
>> Unless the chairs and the AD agree with my reasoning, I propose to immediately remove 
>> partial-lock for candidate and startup. While I stand by my earlier arguments, and disagree 
>> with David, I want to settle this issue fast, and rather remove startup and candidate, then 
>> keep on arguing.
>>
>> However remember, that restricting partial-lock to running, will not make the access 
>> control/commit conflict go away.
> 
> If one believes that access decisions are made during "commit" then
> all these horrible things *will* happen, and it's broken, just as Balazs argues.
> 
> If access decisions are *not* made during "commit"  then the problem goes away.
> 
> The problem, if I recall an off-line discussion correctly, is the language in an
> example in the netconf spec that indicates that access decisions are made
> during the commit.  Other than that, I see no reason for access decisions to
> be made during commit time in a single-candidate view of how things should
> work.
> 
> Randy
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel@ericsson.com

From Washam.Fan@huaweisymantec.com  Fri Jun  5 19:58:57 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB683A69E6 for <netconf@core3.amsl.com>; Fri,  5 Jun 2009 19:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPBNIReXFCmC for <netconf@core3.amsl.com>; Fri,  5 Jun 2009 19:58:56 -0700 (PDT)
Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 43B383A6850 for <netconf@ietf.org>; Fri,  5 Jun 2009 19:58:56 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KKS00F64QY7FF90@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 06 Jun 2009 10:58:55 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KKS00A2LQY7F600@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 06 Jun 2009 10:58:55 +0800 (CST)
Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Sat, 06 Jun 2009 10:58:55 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
Message-id: <fbdfeb0d642e.4a2a4bef@huaweisymantec.com>
Date: Sat, 06 Jun 2009 10:58:55 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <4A2906D5.1020305@ericsson.com>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com> <133975A501BF420A85F69CF4B7614671@BertLaptop> <008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com> <4A2779CA.10703@ericsson.com> <007c01c9e549$c1c29d20$6801a8c0@oemcomputer> <4A2906D5.1020305@ericsson.com>
Cc: netconf@ietf.org
Subject: Re: [Netconf] Access control [was: ew draft-ietf-netconf-partial-lock-08.txt goes to	AD
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2009 02:58:57 -0000

Hi,

----- Original Message -----
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
Date: Friday, June 5, 2009 7:52 pm
Subject: [Netconf] Access control [was: ew draft-ietf-netconf-partial-lock-08.txt goes to	AD
To: Randy Presuhn <randy_presuhn@mindspring.com>
Cc: netconf@ietf.org


> Hello Randy,
> Some other assumptions that might impact this issue:
> - Do we have separate/differing access rights for running and 
> candidate? (I hope not.)
> - Your question stated somewhat differently: Do we have access control 
> at edit-config/commit or 
> both?
> - for commit is the access control allowing the commit operation or 
> the modification of the 
> relevant data
> 
> We will run into some other interesting issues with access control
> - how do you use validate (even for your own little area), if you 
> don't have access rights to 
> the full config? If validation can take into account areas that are 
> non-readable for the user, 
> that may lead to information leaks.

I review sec8.6.4.1, rfc4741, which tells me <source> parameter
of <validate> operation might indicate configuration subtree
rather than the full candidate. Although I am not sure if it is the
intent.

washam

> - can you lock the datastore if you are not allowed to read/write 
> parts of it?
> 
> But all these are access control issues NOT partial-locking related.
> 
> Balazs
> 
> Randy Presuhn wrote:
> > Hi -
> > 
> >> From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
> >> To: "David B Harrington" <dbharrington@comcast.net>
> >> Cc: "'Ron Bonica'" <rbonica@juniper.net>; <netconf@ietf.org>
> >> Sent: Thursday, June 04, 2009 12:37 AM
> >> Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt 
> goes to AD andIETF Last Call
> >>
> >> Hello,
> >> I have to repeat, that the conflict is NOT the result of 
> partial-locking, it is between access 
> >> control and commit. So why should partial-lock be responsible for 
> solving access control issues?
> >>
> >> Unless the chairs and the AD agree with my reasoning, I propose to 
> immediately remove 
> >> partial-lock for candidate and startup. While I stand by my earlier 
> arguments, and disagree 
> >> with David, I want to settle this issue fast, and rather remove 
> startup and candidate, then 
> >> keep on arguing.
> >>
> >> However remember, that restricting partial-lock to running, will 
> not make the access 
> >> control/commit conflict go away.
> > 
> > If one believes that access decisions are made during "commit" then
> > all these horrible things *will* happen, and it's broken, just as 
> Balazs argues.
> > 
> > If access decisions are *not* made during "commit"  then the problem 
> goes away.
> > 
> > The problem, if I recall an off-line discussion correctly, is the 
> language in an
> > example in the netconf spec that indicates that access decisions are 
> made
> > during the commit.  Other than that, I see no reason for access 
> decisions to
> > be made during commit time in a single-candidate view of how things 
> should
> > work.
> > 
> > Randy
> > 
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> > 
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> System Manager
> ECN: 831 7320                        Fax: +36 1 4377792
> Tel: +36-1-437-7320                  email: Balazs.Lengyel@ericsson.com
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

From andy@netconfcentral.com  Fri Jun  5 20:25:19 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732603A6D0C for <netconf@core3.amsl.com>; Fri,  5 Jun 2009 20:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.073
X-Spam-Level: 
X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.193,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32S7HjbCb+hf for <netconf@core3.amsl.com>; Fri,  5 Jun 2009 20:25:18 -0700 (PDT)
Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id BCC653A6CE9 for <netconf@ietf.org>; Fri,  5 Jun 2009 20:25:18 -0700 (PDT)
Received: (qmail 4666 invoked from network); 6 Jun 2009 03:25:21 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 6 Jun 2009 03:25:20 -0000
X-YMail-OSG: M9qbqgMVM1nDBug86XG985lDA2yLk7x69dFVoa8wP4vMY0lw.b4Iv92RT5QVSrkvmEu7k.wHTRjCY1X72FyNSxUXikGdwiYiMSliHpgo9vr7gyA7.Mtm8LYsZlM8C9qgbvf72LGXTeXVPrOrv9jvUIwJ_RsGJ.DVr2XS.l8ZFtURTncSHRDx5G7mQk7wjMKiMmu5fORGXHwz79.nzOu4b7..Y1qRORFLj6WqxGmnmRZtQHtchZojq4iMPLHbMBlC0CIDQdYSPW95hHGl1OjHVUMcFahzmlUNC54uyNHrMAYQHKoAnCkkfSbKBTti4jJCIXkkTjrG3VQISfwqUrO8Rnpm2UYJe34bWq1YG9T681LeqU8HQ0cisaH2dUjMy5iYBNLalb1C8cIhMK4RI97dE0r4X1BCKO7H7IltOccCm9uS693lZUsYnWpXI1C3Vi2cdZ4uSLJWmzskUd9hGRAjSqW5HNPRbRGPEPjwGyH0dqwhObsBpX-Yahoo-Newman-Property: ymail-3
Message-ID: <4A29E18B.1050205@netconfcentral.com>
Date: Fri, 05 Jun 2009 20:24:59 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: WashamFan <Washam.Fan@huaweisymantec.com>
References: <20090603084501.4A3EA3A6AD2@core3.amsl.com>	<133975A501BF420A85F69CF4B7614671@BertLaptop>	<008301c9e46b$ed8c7a90$0600a8c0@china.huawei.com>	<4A2779CA.10703@ericsson.com>	<007c01c9e549$c1c29d20$6801a8c0@oemcomputer>	<4A2906D5.1020305@ericsson.com> <fbdfeb0d642e.4a2a4bef@huaweisymantec.com>
In-Reply-To: <fbdfeb0d642e.4a2a4bef@huaweisymantec.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] Access control [was: ew draft-ietf-netconf-partial-lock-08.txt goes to	AD
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2009 03:25:19 -0000

WashamFan wrote:
> Hi,
....
> I review sec8.6.4.1, rfc4741, which tells me <source> parameter
> of <validate> operation might indicate configuration subtree
> rather than the full candidate. Although I am not sure if it is the
> intent.
> 

Actually, the text in this section clearly says
that an empty element for the name of a database is used,
such as <candidate/> or <running/>.  Except the
complexType 'rpcOperationSourceType' in the XSD
does not match this text, because it includes
the 'inline config' option in the choice.

The NETCONF WG needs to decide (for 4741-bis) whether the
the text or the XSD is correct.

The intent of the WG at the time was not really clear,
except that the entire config was being validated
by this operation, not a piece of a config.

If an inline config element was used, then it
would need to be validated as if it were a complete
config database, so must/mandatory top-level nodes not
included in the inline config would still cause
a validation failure.


> washam
> 

Andy


From mbj@tail-f.com  Sat Jun  6 14:28:53 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD493A6880 for <netconf@core3.amsl.com>; Sat,  6 Jun 2009 14:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.545
X-Spam-Level: 
X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=0.501,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zzMlJ7-sfoI for <netconf@core3.amsl.com>; Sat,  6 Jun 2009 14:28:52 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id AC1733A6782 for <netconf@ietf.org>; Sat,  6 Jun 2009 14:28:52 -0700 (PDT)
Received: from localhost (de-0316.d.ipeer.se [213.180.79.212]) by mail.tail-f.com (Postfix) with ESMTPA id 4F32D616001; Sat,  6 Jun 2009 23:28:55 +0200 (CEST)
Date: Sat, 06 Jun 2009 23:28:54 +0200 (CEST)
Message-Id: <20090606.232854.47734269.mbj@tail-f.com>
To: Washam.Fan@huaweisymantec.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <fbdfeb0d642e.4a2a4bef@huaweisymantec.com>
References: <007c01c9e549$c1c29d20$6801a8c0@oemcomputer> <4A2906D5.1020305@ericsson.com> <fbdfeb0d642e.4a2a4bef@huaweisymantec.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] Access control [was: ew draft-ietf-netconf-partial-lock-08.txt goes to AD
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2009 21:28:53 -0000

Hi,

WashamFan <Washam.Fan@huaweisymantec.com> wrote:

> I review sec8.6.4.1, rfc4741, which tells me <source> parameter
> of <validate> operation might indicate configuration subtree
> rather than the full candidate. Although I am not sure if it is the
> intent.

This issue has been up a couple of times, and I started a thread
"4741bis - validate" on this issue 04/30.  So far it has received very
few comments.


/martin

From balazs.lengyel@ericsson.com  Sun Jun  7 23:55:19 2009
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244DB3A6A0D for <netconf@core3.amsl.com>; Sun,  7 Jun 2009 23:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Level: 
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7+lVUS7FQ8I for <netconf@core3.amsl.com>; Sun,  7 Jun 2009 23:55:17 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 107E53A67A6 for <netconf@ietf.org>; Sun,  7 Jun 2009 23:55:16 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b9cae00000140d-62-4a2cb5d84405
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id CA.0C.05133.8D5BC2A4; Mon,  8 Jun 2009 08:55:20 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 8 Jun 2009 08:55:19 +0200
Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 8 Jun 2009 08:55:19 +0200
Message-ID: <4A2CB5D6.4040506@ericsson.com>
Date: Mon, 08 Jun 2009 08:55:18 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <007c01c9e549$c1c29d20$6801a8c0@oemcomputer>	<4A2906D5.1020305@ericsson.com>	<fbdfeb0d642e.4a2a4bef@huaweisymantec.com> <20090606.232854.47734269.mbj@tail-f.com>
In-Reply-To: <20090606.232854.47734269.mbj@tail-f.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Jun 2009 06:55:19.0440 (UTC) FILETIME=[16108900:01C9E806]
X-Brightmail-Tracker: AAAAAA==
Cc: netconf@ietf.org
Subject: Re: [Netconf] Access control [was: ew draft-ietf-netconf-partial-lock-08.txt goes to AD
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2009 06:55:19 -0000

Hello Martin,
My opinion and IMHO the consensus so far is:
- Validate only for a complete database
- test-only option for edit-config
Balazs

Martin Bjorklund wrote:
> Hi,
> 
> WashamFan <Washam.Fan@huaweisymantec.com> wrote:
> 
>> I review sec8.6.4.1, rfc4741, which tells me <source> parameter
>> of <validate> operation might indicate configuration subtree
>> rather than the full candidate. Although I am not sure if it is the
>> intent.
> 
> This issue has been up a couple of times, and I started a thread
> "4741bis - validate" on this issue 04/30.  So far it has received very
> few comments.
> 
> 
> /martin
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel@ericsson.com

From andy@netconfcentral.com  Mon Jun  8 22:51:25 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3C93A6C4E for <netconf@core3.amsl.com>; Mon,  8 Jun 2009 22:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.167,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9yzWqpvGqBg for <netconf@core3.amsl.com>; Mon,  8 Jun 2009 22:51:25 -0700 (PDT)
Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 27BB63A6C34 for <netconf@ietf.org>; Mon,  8 Jun 2009 22:51:25 -0700 (PDT)
Received: (qmail 68513 invoked from network); 9 Jun 2009 05:51:28 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 9 Jun 2009 05:51:27 -0000
X-YMail-OSG: pT0GtXwVM1mP24anIW816Ud10hp6ZpgkrJRB9iGFD_XCgirJyebJNAIT.2yBrrLnAARsSVFoCGnCEiAjef31BMsdSDs_R6XR4140cWHVzRT4Ov96VwqvNdLEVOb1d9W95ziw1nc.qoe7NU5ksEZR6FOHGcwaA4kARYA1.7cF9jb2jwjZgEt1ZDtZrtO0jV6NBxtszHfgOQnhTjT3x3wpQdR5J.rQ070UFR6cHYpxDS9HfdR.liVtuQJpxWdvulqh1_k9TAN4gJujxJgC
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A2DF85D.50308@netconfcentral.com>
Date: Mon, 08 Jun 2009 22:51:25 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Andy Bierman <andy@netconfcentral.com>,  NETMOD Working Group <netmod@ietf.org>
References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local>
In-Reply-To: <20090609054626.GC2691@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] [netmod] date-and-time vs. dateTime
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 05:51:25 -0000

Juergen Schoenwaelder wrote:
> On Tue, Jun 09, 2009 at 05:17:48AM +0200, Andy Bierman wrote:
> 
>> I propose that RFC 5277 be "clarified" to indicate
>> that YANG date-and-time encoding rules SHOULD be
>> used instead of XSD dateTime.  The only differences
>> are pathological corner-cases that have no utility
>> in the <create-subscription> operation.
> 
> I think RFC 5277 is a product of the NETCONF WG and thus your message
> should have gone to the NETCONF mailing list and not to the NETMOD
> mailing list.
> 

OK -- another possible solution is to remove (or change)
any YANG data type that is not exactly like its XSD counterpart.
That would affect YANG, not NETCONF.


> /js
> 

Andy


From j.schoenwaelder@jacobs-university.de  Mon Jun  8 23:38:41 2009
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF1E3A6CD9; Mon,  8 Jun 2009 23:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3Us6ua8Sm4H; Mon,  8 Jun 2009 23:38:40 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 116133A6CD5; Mon,  8 Jun 2009 23:38:40 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FD63C0076; Tue,  9 Jun 2009 08:38:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q-KiKLVlWmKo; Tue,  9 Jun 2009 08:38:44 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A917DC0071; Tue,  9 Jun 2009 08:38:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8B0AAB346F9; Tue,  9 Jun 2009 08:38:43 +0200 (CEST)
Date: Tue, 9 Jun 2009 08:38:43 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@netconfcentral.com>
Message-ID: <20090609063843.GA2798@elstar.local>
Mail-Followup-To: Andy Bierman <andy@netconfcentral.com>, NETMOD Working Group <netmod@ietf.org>, NETCONF <netconf@ietf.org>
References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A2DF85D.50308@netconfcentral.com>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: NETCONF <netconf@ietf.org>, NETMOD Working Group <netmod@ietf.org>
Subject: Re: [Netconf] [netmod] date-and-time vs. dateTime
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 06:38:41 -0000

On Tue, Jun 09, 2009 at 07:51:25AM +0200, Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
> > On Tue, Jun 09, 2009 at 05:17:48AM +0200, Andy Bierman wrote:
> > 
> >> I propose that RFC 5277 be "clarified" to indicate
> >> that YANG date-and-time encoding rules SHOULD be
> >> used instead of XSD dateTime.  The only differences
> >> are pathological corner-cases that have no utility
> >> in the <create-subscription> operation.
> > 
> > I think RFC 5277 is a product of the NETCONF WG and thus your message
> > should have gone to the NETCONF mailing list and not to the NETMOD
> > mailing list.
> > 
> 
> OK -- another possible solution is to remove (or change)
> any YANG data type that is not exactly like its XSD counterpart.
> That would affect YANG, not NETCONF.

Is that a serious proposal or just noise?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From andy@netconfcentral.com  Tue Jun  9 03:33:37 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B716F3A6B8E for <netconf@core3.amsl.com>; Tue,  9 Jun 2009 03:33:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level: 
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.156,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf47I0LE1SEc for <netconf@core3.amsl.com>; Tue,  9 Jun 2009 03:33:37 -0700 (PDT)
Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 96F6B3A6B1A for <netconf@ietf.org>; Tue,  9 Jun 2009 03:33:37 -0700 (PDT)
Received: (qmail 62179 invoked from network); 9 Jun 2009 10:27:02 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 9 Jun 2009 10:27:02 -0000
X-YMail-OSG: 8A16cV0VM1mjkMH_mo6ZRmNG.yp27bU0IJwb3Wr.b2uLO0xcmxGs_lj.NuuRk9RGRt86BMLMDKOPfHLOpcmHiqmb3WTceALUyPt3HSZfZjRzdBPpttWhqlWbEqVCv34fmnHeJIAqccSdc27KehQhWjVJnAyDa8eeyBD5pQx62cMg_cFD01O376FS5a7tb.r4QSWe9MGQmxfPzdHtglEdzqf.eYg84B_VPsIa.eQqEcu1kIRm2KZqH8bG3cbVlK0xFBo1El6SSDaCT8tRYa.2XF.EnZG0K3cA33Qkp8PuyrtfKQplnntt
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A2E38F4.6030600@netconfcentral.com>
Date: Tue, 09 Jun 2009 03:27:00 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Andy Bierman <andy@netconfcentral.com>,  NETMOD Working Group <netmod@ietf.org>, NETCONF <netconf@ietf.org>
References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> <20090609063843.GA2798@elstar.local>
In-Reply-To: <20090609063843.GA2798@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] [netmod] date-and-time vs. dateTime
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 10:33:37 -0000

Juergen Schoenwaelder wrote:
> On Tue, Jun 09, 2009 at 07:51:25AM +0200, Andy Bierman wrote:
>> Juergen Schoenwaelder wrote:
>>> On Tue, Jun 09, 2009 at 05:17:48AM +0200, Andy Bierman wrote:
>>>
>>>> I propose that RFC 5277 be "clarified" to indicate
>>>> that YANG date-and-time encoding rules SHOULD be
>>>> used instead of XSD dateTime.  The only differences
>>>> are pathological corner-cases that have no utility
>>>> in the <create-subscription> operation.
>>> I think RFC 5277 is a product of the NETCONF WG and thus your message
>>> should have gone to the NETCONF mailing list and not to the NETMOD
>>> mailing list.
>>>
>> OK -- another possible solution is to remove (or change)
>> any YANG data type that is not exactly like its XSD counterpart.
>> That would affect YANG, not NETCONF.
> 
> Is that a serious proposal or just noise?
> 

Quite serious.
The NETCONF WG is writing data models in XSD
and the NETMOD WG is writing YANG as if XSD did not
really exist.

Why do we need 2 sets of almost-compatible data types?

> /js
> 

Andy



From j.schoenwaelder@jacobs-university.de  Tue Jun  9 03:52:12 2009
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960373A6C07; Tue,  9 Jun 2009 03:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiMi+jOkVxwR; Tue,  9 Jun 2009 03:52:11 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3E64E3A685A; Tue,  9 Jun 2009 03:52:08 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAAA0C00A5; Tue,  9 Jun 2009 12:52:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CVUVE6vvbAXW; Tue,  9 Jun 2009 12:52:12 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62FD5C0093; Tue,  9 Jun 2009 12:52:12 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 35476B34C5A; Tue,  9 Jun 2009 12:52:11 +0200 (CEST)
Date: Tue, 9 Jun 2009 12:52:11 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@netconfcentral.com>
Message-ID: <20090609105211.GC3133@elstar.local>
Mail-Followup-To: Andy Bierman <andy@netconfcentral.com>, NETMOD Working Group <netmod@ietf.org>, NETCONF <netconf@ietf.org>
References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> <20090609063843.GA2798@elstar.local> <4A2E38F4.6030600@netconfcentral.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A2E38F4.6030600@netconfcentral.com>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: NETCONF <netconf@ietf.org>, NETMOD Working Group <netmod@ietf.org>
Subject: Re: [Netconf] [netmod]   date-and-time vs. dateTime
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 10:52:12 -0000

On Tue, Jun 09, 2009 at 12:27:00PM +0200, Andy Bierman wrote:
 
> Quite serious.
> The NETCONF WG is writing data models in XSD
> and the NETMOD WG is writing YANG as if XSD did not
> really exist.

The NETCONF WG is producing a protocol, the NETMOD WG is producing a
data modeling language used to model configuration and state data
manipulated by the NETCONF protocol, NETCONF remote procedure calls,
and NETCONF notifications. So there is a difference, even though the
use of XML for everything makes it hard to see the border.

> Why do we need 2 sets of almost-compatible data types?

This question can't answered in the abstract because you have to pay
attention to the reasons for any differences there are. What concerns
the ietf-yang-types module, I tried to document where the differences
are. Wrt data-and-time, the concensus so far was to follow RFC 3339
(Proposed Standard) in some corner cases instead of XSD. While I
personally do not care much about negative years and what they might
mean, I think the distinction between -00:00 and +00:00 and Z made in
RFC 3339 is actually a very useful one.

If you have further issues with any of the ietf-yang-types data types,
please start separate threads so we can work them out and see what the
concensus is.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From andy@netconfcentral.com  Tue Jun  9 08:28:21 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0DF3A67DA for <netconf@core3.amsl.com>; Tue,  9 Jun 2009 08:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b749wuFBuECB for <netconf@core3.amsl.com>; Tue,  9 Jun 2009 08:28:21 -0700 (PDT)
Received: from n23a.bullet.mail.mud.yahoo.com (n23a.bullet.mail.mud.yahoo.com [68.142.207.189]) by core3.amsl.com (Postfix) with SMTP id 0F5F73A6ABB for <netconf@ietf.org>; Tue,  9 Jun 2009 08:28:21 -0700 (PDT)
Received: from [209.191.108.97] by n23.bullet.mail.mud.yahoo.com with NNFMP; 09 Jun 2009 15:28:25 -0000
Received: from [68.142.201.71] by t4.bullet.mud.yahoo.com with NNFMP; 09 Jun 2009 15:28:25 -0000
Received: from [127.0.0.1] by omp423.mail.mud.yahoo.com with NNFMP; 09 Jun 2009 15:28:25 -0000
X-Yahoo-Newman-Id: 279631.9451.bm@omp423.mail.mud.yahoo.com
Received: (qmail 38681 invoked from network); 9 Jun 2009 15:28:24 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.226.211 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 9 Jun 2009 15:28:24 -0000
X-YMail-OSG: _T1_mwgVM1mZmCPYw8.WUMhSWBrrXM7oYIQyEGMel4XexAzrCpfVRl3NZc4h4N25gtCq08kuJU0KfUEzEC.DDPDHz..41kCUy8Z5.VEF0X5Uigofc2ZcvVCZpikcSNN.Vh0rpw1V.fX1.pNmgZoXZF.3Oo.EkmzwsxNoZU97q8D6A_6gKS1kkObGoI0k3QfBkhv3f_eaKnBuxFB.uWIWhAQRg2iIz4__CvPDac36sSHP5bMqHA6kE8_.Zl95fmof6K78.HeZGzCiG_Idj2QfELCr55AOd2XmsDaCJx8yC.IrXwtggfiT
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A2E7F96.3060903@netconfcentral.com>
Date: Tue, 09 Jun 2009 08:28:22 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Andy Bierman <andy@netconfcentral.com>,  NETMOD Working Group <netmod@ietf.org>, NETCONF <netconf@ietf.org>
References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> <20090609063843.GA2798@elstar.local> <4A2E38F4.6030600@netconfcentral.com> <20090609105211.GC3133@elstar.local>
In-Reply-To: <20090609105211.GC3133@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] [netmod]   date-and-time vs. dateTime
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 15:28:22 -0000

Juergen Schoenwaelder wrote:
> On Tue, Jun 09, 2009 at 12:27:00PM +0200, Andy Bierman wrote:
>  
>> Quite serious.
>> The NETCONF WG is writing data models in XSD
>> and the NETMOD WG is writing YANG as if XSD did not
>> really exist.
> 
> The NETCONF WG is producing a protocol, the NETMOD WG is producing a
> data modeling language used to model configuration and state data
> manipulated by the NETCONF protocol, NETCONF remote procedure calls,
> and NETCONF notifications. So there is a difference, even though the
> use of XML for everything makes it hard to see the border.
> 

The NETCONF WG is producing content.
In fact, the ONLY standard content for NETCONF
that exists has been done by the NETCONF WG.

    - notification monitoring and create-subscription operation
    - ietf-netconf-state anf get-schema operation
    - partial-lock and partial unlock operations
    - with-defaults parameter extension to some operations

All of these documents have content at the layers that
YANG is intended to cover.


>> Why do we need 2 sets of almost-compatible data types?
> 
> This question can't answered in the abstract because you have to pay
> attention to the reasons for any differences there are. What concerns
> the ietf-yang-types module, I tried to document where the differences
> are. Wrt data-and-time, the concensus so far was to follow RFC 3339
> (Proposed Standard) in some corner cases instead of XSD. While I
> personally do not care much about negative years and what they might
> mean, I think the distinction between -00:00 and +00:00 and Z made in
> RFC 3339 is actually a very useful one.
> 
> If you have further issues with any of the ietf-yang-types data types,
> please start separate threads so we can work them out and see what the
> concensus is.
> 

The subject line says date-and-time and that is the issue here.
Remove it, change it, or change ALL of the NETCONF content
that uses dateTime to perfectly align with the YANG language.

I was hoping we were going to avoid the same sort of compartmental
politics that plagued EOS/SMIng.  I guess not.


> /js
> 

Andy



From j.schoenwaelder@jacobs-university.de  Tue Jun  9 08:59:13 2009
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA61D3A68F9; Tue,  9 Jun 2009 08:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swfJ5y3NbsYP; Tue,  9 Jun 2009 08:59:12 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6F43A3A6784; Tue,  9 Jun 2009 08:59:12 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2D25C00B6; Tue,  9 Jun 2009 17:59:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hFvztgMHSNXO; Tue,  9 Jun 2009 17:59:17 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0279C0062; Tue,  9 Jun 2009 17:59:16 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 8F4A5B356FF; Tue,  9 Jun 2009 17:59:15 +0200 (CEST)
Date: Tue, 9 Jun 2009 17:59:15 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@netconfcentral.com>
Message-ID: <20090609155915.GG4194@elstar.local>
Mail-Followup-To: Andy Bierman <andy@netconfcentral.com>, NETMOD Working Group <netmod@ietf.org>, NETCONF <netconf@ietf.org>
References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> <20090609063843.GA2798@elstar.local> <4A2E38F4.6030600@netconfcentral.com> <20090609105211.GC3133@elstar.local> <4A2E7F96.3060903@netconfcentral.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A2E7F96.3060903@netconfcentral.com>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: NETCONF <netconf@ietf.org>, NETMOD Working Group <netmod@ietf.org>
Subject: Re: [Netconf] [netmod]   date-and-time vs. dateTime
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 15:59:13 -0000

On Tue, Jun 09, 2009 at 05:28:22PM +0200, Andy Bierman wrote:
 
> The subject line says date-and-time and that is the issue here.
> Remove it, change it, or change ALL of the NETCONF content
> that uses dateTime to perfectly align with the YANG language.
> 
> I was hoping we were going to avoid the same sort of compartmental
> politics that plagued EOS/SMIng.  I guess not.

YANG started late and some data models were started before and this
explains the situation (and this particularly applies to RFC 5277,
published in July 2008). I do not see compartmental politics - just
the IETF working as it is.

Concerning RFC 5277, I like to quote section 2.2.1:

   Parameters:

      eventTime

         The time the event was generated by the event source.  This
         parameter is of type dateTime and compliant to [RFC3339].
         Implementations must support time zones.

This says eventTime is compliant to RFC3339 and thus I believe it is
actually compliant with date-and-time (but perhaps the WG was not
aware of the corner case differences between XSD dateTime and RFC3339
ietf-yang-types is pointing out).

The more interesting question for me is whether eventTime is part of
the content or part of the protocol. For me, it seems to be more part
of the protocol as it is hardwired to the <notification> message but
I understand that this piece of the design can be debated.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From andy@netconfcentral.com  Tue Jun  9 09:13:29 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69BB3A6923 for <netconf@core3.amsl.com>; Tue,  9 Jun 2009 09:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level: 
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vvaklwDKxla for <netconf@core3.amsl.com>; Tue,  9 Jun 2009 09:13:28 -0700 (PDT)
Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id E1B223A687A for <netconf@ietf.org>; Tue,  9 Jun 2009 09:13:28 -0700 (PDT)
Received: (qmail 98370 invoked from network); 9 Jun 2009 16:13:32 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.226.211 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 9 Jun 2009 16:13:32 -0000
X-YMail-OSG: 4PXVdrMVM1nT9Fv9x8np03w05rn0emBpUMa9O3yBYb64MzOQNckOQDTo0MqX54rPnyGiK5mEVCzyDlIF4UMWL6IU6l.Ttz2KW7VRfAR7zG6Re1Hzjx0LGrMj.aJ8q8gLxyUvyPp3aXibshZWMhcebPwYgQpDbf1Xh_r8nl5WrB3d8xpI5uYHys15r6CaBz3DPrxbgfiGVg_t7VJQsOGKgtcSq_KxNTunrNpExjqSNnob4h2kw0Z_TPKtsLQII80CeDbWCshj9eir17g6Afjn4gZ9H3iz15ZPVhFv3UlT_qAI6Q_Awktf
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A2E8A14.4020308@netconfcentral.com>
Date: Tue, 09 Jun 2009 09:13:08 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Andy Bierman <andy@netconfcentral.com>,  NETMOD Working Group <netmod@ietf.org>, NETCONF <netconf@ietf.org>
References: <4A2DD45C.7050607@netconfcentral.com> <20090609054626.GC2691@elstar.local> <4A2DF85D.50308@netconfcentral.com> <20090609063843.GA2798@elstar.local> <4A2E38F4.6030600@netconfcentral.com> <20090609105211.GC3133@elstar.local> <4A2E7F96.3060903@netconfcentral.com> <20090609155915.GG4194@elstar.local>
In-Reply-To: <20090609155915.GG4194@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] [netmod]   date-and-time vs. dateTime
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 16:13:29 -0000

Juergen Schoenwaelder wrote:
> On Tue, Jun 09, 2009 at 05:28:22PM +0200, Andy Bierman wrote:
>  
>> The subject line says date-and-time and that is the issue here.
>> Remove it, change it, or change ALL of the NETCONF content
>> that uses dateTime to perfectly align with the YANG language.
>>
>> I was hoping we were going to avoid the same sort of compartmental
>> politics that plagued EOS/SMIng.  I guess not.
> 
> YANG started late and some data models were started before and this
> explains the situation (and this particularly applies to RFC 5277,
> published in July 2008). I do not see compartmental politics - just
> the IETF working as it is.
> 
> Concerning RFC 5277, I like to quote section 2.2.1:
> 
>    Parameters:
> 
>       eventTime
> 
>          The time the event was generated by the event source.  This
>          parameter is of type dateTime and compliant to [RFC3339].
>          Implementations must support time zones.
> 

This text is why I proposed an RFC Errata to fix the problem.
I do not think the NETCONF WG understood the differences
at the time.  However, the XSD clearly uses dateTime as
the data type, not string.

RFC 5277 does not say what to do with startTime and/or stopTime
with negative dateTime. Is -2010-06-09T12:00:00Z before 'now'?
(What were the XSD designers thinking!?!)

So problem solved.  The text you quoted above is correct
and the XSD is wrong, and an RFC Erratta note is needed
for RFC 5277 after all. From now on, all time values
in NETCONF/YANG MUST be date-and-time.



> This says eventTime is compliant to RFC3339 and thus I believe it is
> actually compliant with date-and-time (but perhaps the WG was not
> aware of the corner case differences between XSD dateTime and RFC3339
> ietf-yang-types is pointing out).
> 
> The more interesting question for me is whether eventTime is part of
> the content or part of the protocol. For me, it seems to be more part
> of the protocol as it is hardwired to the <notification> message but
> I understand that this piece of the design can be debated.
>

eventTime is another problem, but at least it is
read-only and the agent generates only canonical
format, so the differences never show up.


> /js
> 

Andy


From dromasca@avaya.com  Wed Jun 10 07:34:03 2009
Return-Path: <dromasca@avaya.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8885E28C1B8 for <netconf@core3.amsl.com>; Wed, 10 Jun 2009 07:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDx0dD2hnB72 for <netconf@core3.amsl.com>; Wed, 10 Jun 2009 07:33:58 -0700 (PDT)
Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id E6E2928C1B2 for <netconf@ietf.org>; Wed, 10 Jun 2009 07:33:57 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.41,341,1241409600"; d="scan'208";a="163892353"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 10 Jun 2009 10:34:03 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jun 2009 10:34:03 -0400
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
Date: Wed, 10 Jun 2009 16:33:51 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401790365@307622ANEX5.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AD review for draft-ietf-netconf-partial-lock-08.txt
Thread-Index: Acnp2HkQgHxioQTxQ6yBTnhAlX5K5A==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: <netconf@ietf.org>
Subject: [Netconf] AD review for draft-ietf-netconf-partial-lock-08.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2009 14:34:03 -0000

This document is ready to be sent to IETF Last Call, and I will send it
immediately after sending this message. Please consider the comments
below together with the other IETF Last Call comments.

1. IPR and Copyright issues

Running idnits results in the following warning:=20

=3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, but =
was
     first submitted before 10 November 2008.  Should you add the
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.).=20

     trust-12-feb-2009 Section 6.c.iii text:
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.

      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."

Also, the schema in Appendix A will need to include the full text of the
BSD license for code or a reference to it. This issue is still debated
with the Trust, so no action by now on this.=20

2. last paragraph in Section 1.1=20

s/This consist/These consist/

3. Section 2.1.1

s/However it can be used to lock a candidate datastore/However it can be
used to lock parts of a candidate datastore/

4. The title of Section 2.1.1.1 seems to me to be more appropriately
'Multiple managers handling the writable running datastore with
overlapping sections'

5. same section - I am a little nervous about saying 'The lock should be
held only a short time (seconds rather then minutes)'. What if the lock
can be help less than seconds or minutes at minimum because of the size
of the records to be operated? Maybe better is to say 'The lock should
be held the shortest possible time (e.g. seconds rather then minutes)'.

6. Section 2.1.1.2 - better (e.g. minutes, hours)

7. Section 2.1.1.3 - same comment as #5 for 2.1.1.1

8. page 6 - section 2.4.1 - 'these notes should be included in the
protected area of the lock' - it seems to me that a capitalized SHOULD
is appropriate here.=20

9. Capitalization seems necessary also in 2.4.1.2 and also a change as I
do not see in which situations if locking fails the client should not
back-off. I realize this is client behavior, but the normative language
still seems to apply

So:=20

OLD:=20

   To avoid this situation, clients should lock
   everything they need in one operation.  If locking fails, the client
   should back-off, release any previously acquired locks, and retry the
   procedure after waiting some randomized time interval.

NEW:

   To avoid this situation, clients SHOULD lock
   everything they need in one operation.  If locking fails, the client
   MUST back-off, release any previously acquired locks, and SHOULD
retry the
   procedure after waiting some randomized time interval.

10. Last paragraph in section 3 - why is NOT capitalized?=20

Dan



From wwwrun@core3.amsl.com  Wed Jun 10 07:45:21 2009
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 2FEF53A6BE0; Wed, 10 Jun 2009 07:45:20 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <ietf-announce@ietf.org> 
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <20090610144521.2FEF53A6BE0@core3.amsl.com>
Date: Wed, 10 Jun 2009 07:45:21 -0700 (PDT)
Cc: netconf@ietf.org
Subject: [Netconf] Last Call: draft-ietf-netconf-partial-lock (Partial Lock RPC for NETCONF) to Proposed Standard
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2009 14:45:21 -0000

The IESG has received a request from the Network Configuration WG 
(netconf) to consider the following document:

- 'Partial Lock RPC for NETCONF '
   <draft-ietf-netconf-partial-lock-08.txt> 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 2009-06-24. 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-partial-lock-08.txt




IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16844&rfc_flag=0


From Graham.Phillips@citrix.com  Tue Jun  9 16:05:50 2009
Return-Path: <Graham.Phillips@citrix.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94AB3A6AFC for <netconf@core3.amsl.com>; Tue,  9 Jun 2009 16:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCpkLGjZOfq8 for <netconf@core3.amsl.com>; Tue,  9 Jun 2009 16:05:50 -0700 (PDT)
Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by core3.amsl.com (Postfix) with ESMTP id 974913A67F1 for <netconf@ietf.org>; Tue,  9 Jun 2009 16:05:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.41,335,1241409600"; d="scan'208,217";a="54367255"
Received: from sjcpmailmx02.citrite.net ([10.216.4.75]) by FTLPIPO02.CITRIX.COM with ESMTP; 09 Jun 2009 19:05:53 -0400
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX02.citrite.net ([10.216.4.75]) with mapi; Tue, 9 Jun 2009 16:05:53 -0700
From: Graham Phillips <Graham.Phillips@citrix.com>
To: "'netconf@ietf.org'" <netconf@ietf.org>
Date: Tue, 9 Jun 2009 16:05:53 -0700
Thread-Topic: A question on NETCONF versus RESTful webservices 
Thread-Index: AcnpVuaDIxV91OdnRZCB1wxzTzmXgw==
Message-ID: <B1DF26ECC0458748AC97CECE2DA98D412F4482243F@SJCPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_B1DF26ECC0458748AC97CECE2DA98D412F4482243FSJCPMAILBOX01_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 10 Jun 2009 08:28:28 -0700
Subject: [Netconf] A question on NETCONF versus RESTful webservices
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 23:07:07 -0000

--_000_B1DF26ECC0458748AC97CECE2DA98D412F4482243FSJCPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,


I am a proponent of NETCONF and am trying to promote it within my organizat=
ion, Netscaler/Citrix.

I am running into some difficultly selling NETCONF to my colleges who have =
build a prototype using a RESTful web services approach.   In this approach=
 they are using JSON over HTTP.   The retrieval of individual configuration=
 entities is handled by mapping the request to an HTTP GET request on a par=
ticular URL (eg. GET device_ip_address/entity_X/name).  Setting of configur=
ation entities are mapped to HTTP POST requests.

Can anyone give me some ideas how I might sell the NETCONF idea to non-beli=
evers?
I think some advantages of NETCONF are:
            1) That it is a standard that has been adopted by large network=
 vendors (ie Juniper and Cisco)
                        Any others?
            2) I suspect that it has been adopted by network management ven=
dors.  Do we have any vendor names?

One question that I have been asked is how easier is it to wrap client-side=
 language-bindings around the NETCONF protocol.  For example, in the web se=
rvices world, one has a WSDL file, and client side language binding can be =
automatically generated.    How does one achieve this stub generation with =
NETCONF?  Can this be achieve with the NETCONF over SOAP scheme.

Thank you.
--Graham Phillips



--_000_B1DF26ECC0458748AC97CECE2DA98D412F4482243FSJCPMAILBOX01_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Hello,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>I am a proponent of NETCONF and am trying to promote it
within my organization, Netscaler/Citrix.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>I am running into some difficultly selling NETCONF to my
colleges who have build a prototype using a RESTful web services
approach.&nbsp;&nbsp; In this approach they are using JSON over
HTTP.&nbsp;&nbsp; The retrieval of individual configuration entities is han=
dled
by mapping the request to an HTTP GET request on a particular URL (eg. GET =
device_ip_address/entity_X/name).&nbsp;
Setting of configuration entities are mapped to HTTP POST requests.<o:p></o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Can anyone give me some ideas how I might sell the NETCO=
NF
idea to non-believers?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>I think some advantages of NETCONF are:<o:p></o:p></span=
></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 1)
That it is a standard that has been adopted by large network vendors (ie
Juniper and Cisco)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; Any
others?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 2)
I suspect that it has been adopted by network management vendors.&nbsp; Do =
we
have any vendor names? <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>One question that I have been asked is how easier is it =
to wrap
client-side language-bindings around the NETCONF protocol.&nbsp; For exampl=
e,
in the web services world, one has a WSDL file, and client side language
binding can be automatically generated. &nbsp;&nbsp;&nbsp;How does one achi=
eve
this stub generation with NETCONF?&nbsp; Can this be achieve with the NETCO=
NF
over SOAP scheme.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Thank you.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>--Graham Phillips<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--_000_B1DF26ECC0458748AC97CECE2DA98D412F4482243FSJCPMAILBOX01_--

From andy@netconfcentral.com  Wed Jun 10 09:19:32 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75C928C21E for <netconf@core3.amsl.com>; Wed, 10 Jun 2009 09:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.543
X-Spam-Level: 
X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55nENxY0MjwE for <netconf@core3.amsl.com>; Wed, 10 Jun 2009 09:19:31 -0700 (PDT)
Received: from n16.bullet.mail.mud.yahoo.com (n16.bullet.mail.mud.yahoo.com [68.142.206.43]) by core3.amsl.com (Postfix) with SMTP id BCEAE28C210 for <netconf@ietf.org>; Wed, 10 Jun 2009 09:19:31 -0700 (PDT)
Received: from [68.142.200.225] by n16.bullet.mail.mud.yahoo.com with NNFMP; 10 Jun 2009 16:19:36 -0000
Received: from [68.142.201.246] by t6.bullet.mud.yahoo.com with NNFMP; 10 Jun 2009 16:19:36 -0000
Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 10 Jun 2009 16:19:36 -0000
X-Yahoo-Newman-Id: 294801.57846.bm@omp407.mail.mud.yahoo.com
Received: (qmail 60870 invoked from network); 10 Jun 2009 16:19:35 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.226.211 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 10 Jun 2009 16:19:35 -0000
X-YMail-OSG: arjPuIgVM1m4aX61Y_Vzb4ZjoB_XQBZsVipdWRjKb9j4Xo10grBQaCrHr8YyKeQVNQ_Vu8LOATZtwZRWU2DPwD98tNPQG5WlH6sBeoizsOklwmkPOcgcRT5fsGRsi9EE8Oa4Po3Ry63H3KEPAKLG6w_TOxppL_FJMRVlPxmjpfqIDhI75Otelbt6TYiUtzVjuBy3gCNSqsSVhzQSksRqi4xWRZMRom11l04A4PC4TcDj4VhNaTswWI.U.9E9pJxIjezWXAC9XaGrGMD1a8qg66sbFT3zH7UHjsIimvkBbk0RL934Nxa9tfQWyoBTv99va0HlQGwYKjmrNtk.EkTU
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A2FDD14.1040507@netconfcentral.com>
Date: Wed, 10 Jun 2009 09:19:32 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Graham Phillips <Graham.Phillips@citrix.com>
References: <B1DF26ECC0458748AC97CECE2DA98D412F4482243F@SJCPMAILBOX01.citrite.net>
In-Reply-To: <B1DF26ECC0458748AC97CECE2DA98D412F4482243F@SJCPMAILBOX01.citrite.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "'netconf@ietf.org'" <netconf@ietf.org>
Subject: Re: [Netconf] A question on NETCONF versus RESTful webservices
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2009 16:19:32 -0000

Graham Phillips wrote:
> Hello,
> 
>  
> 
>  
> 
> I am a proponent of NETCONF and am trying to promote it within my 
> organization, Netscaler/Citrix.
> 
>  
> 
> I am running into some difficultly selling NETCONF to my colleges who 
> have build a prototype using a RESTful web services approach.   In this 
> approach they are using JSON over HTTP.   The retrieval of individual 
> configuration entities is handled by mapping the request to an HTTP GET 
> request on a particular URL (eg. GET device_ip_address/entity_X/name).  
> Setting of configuration entities are mapped to HTTP POST requests.
> 
>  
> 
> Can anyone give me some ideas how I might sell the NETCONF idea to 
> non-believers?
> 


There are many reasons that NETCONF/YANG are better suited
for embedded networking devices.  This is probably the
wrong list for a detailed discussion.

For many reasons, managing a router as if it
was just an XML instance document that can be
peeked and poked with data just doesn't work.
On the other end, asking a router to provide
complex transaction capability found in an SQL server
is too heavy-weight.  NETCONF is somewhere in between.

Try these links for more info:
http://trac.tools.ietf.org/wg/netconf/trac/wiki
http://www.netconfcentral.org/
http://www.yang-central.org/twiki/bin/view/Main/WebHome


> I think some advantages of NETCONF are:
> 
>             1) That it is a standard that has been adopted by large 
> network vendors (ie Juniper and Cisco)
> 
>                         Any others?
> 
>             2) I suspect that it has been adopted by network management 
> vendors.  Do we have any vendor names?
> 
>  
> 
> One question that I have been asked is how easier is it to wrap 
> client-side language-bindings around the NETCONF protocol.  For example, 
> in the web services world, one has a WSDL file, and client side language 
> binding can be automatically generated.    How does one achieve this 
> stub generation with NETCONF?  Can this be achieve with the NETCONF over 
> SOAP scheme.
> 

People may or may not be working on YANG translation
tools which would help here.  The best part about
NETCONF is YANG, and that's not quite here yet.
Complex networking services require complex APIs to manage.
NETCONF/YANG provides the building blocks for such APIs.


>  
> 
> Thank you.
> 
> --Graham Phillips
> 
>  

Andy



From t.iijima3@gmail.com  Wed Jun 10 15:46:05 2009
Return-Path: <t.iijima3@gmail.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C163A6A37 for <netconf@core3.amsl.com>; Wed, 10 Jun 2009 15:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6I5hl+bCufY for <netconf@core3.amsl.com>; Wed, 10 Jun 2009 15:46:04 -0700 (PDT)
Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 3529C3A68AD for <netconf@ietf.org>; Wed, 10 Jun 2009 15:46:04 -0700 (PDT)
Received: by pzk42 with SMTP id 42so55362pzk.29 for <netconf@ietf.org>; Wed, 10 Jun 2009 15:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=5PFFMImB9Tt1PQKEZ6TbWqlxeDboJOMxmrYcQfQZdzU=; b=fR1BxLGLpR0qEEYhvrtTIJ5hXxvuwQL/Y8amWV2zvfuS34Y9kkbvoXg/pAJnw4Df+h ocJ9c7J+O+Zzbq7a6MwyvIOaJXiJ+LiWuwfD8R/iNuZUeDwTLiNd7j2u8dxHRfKYZ0Ia /gOvRp6GgZoH9B80tXQZAHqlj0jhAN2NedXK4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wzxe1pet4Evjx3TBTkT5Ta6YChestqiT0opvvXFgfcOODXOZL6KxptDYizaffUSOTo rd+aOVi0rQ1ObxOcgxEMGZ6TzpNnrU/fbwUgSaAKsRvhN4Yc0wWGTWBgWCxlkHJi77YE yijuv71hHofBdGiPCX75p53upJwSXaoI8o2dM=
Received: by 10.114.169.12 with SMTP id r12mr2834595wae.68.1244673968608; Wed, 10 Jun 2009 15:46:08 -0700 (PDT)
Received: from ?192.168.1.2? (191.124.100.220.dy.bbexcite.jp [220.100.124.191]) by mx.google.com with ESMTPS id n6sm143550wag.39.2009.06.10.15.46.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 15:46:07 -0700 (PDT)
Message-ID: <4A3037B3.3070906@gmail.com>
Date: Thu, 11 Jun 2009 07:46:11 +0900
From: Tomoyuki Iijima <t.iijima3@gmail.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Graham Phillips <Graham.Phillips@citrix.com>
References: <B1DF26ECC0458748AC97CECE2DA98D412F4482243F@SJCPMAILBOX01.citrite.net>
In-Reply-To: <B1DF26ECC0458748AC97CECE2DA98D412F4482243F@SJCPMAILBOX01.citrite.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "'netconf@ietf.org'" <netconf@ietf.org>
Subject: Re: [Netconf] A question on NETCONF versus RESTful webservices
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2009 22:46:05 -0000

Hello Graham,

 >             1) That it is a standard that has been adopted by large
 > network vendors (ie Juniper and Cisco)
 >
 >                         Any others?
 >
 >             2) I suspect that it has been adopted by network managemen
 > vendors.  Do we have any vendor names?

 > binding can be automatically generated.    How does one achieve this
 > stub generation with NETCONF?  Can this be achieve with the NETCONF ov
 > SOAP scheme.

We (Alaxala Networks in Japan) have an experience of implementing 
NETCONF over SOAP. I used Apache Axis to generate stub class (Java API) 
from SOAP scheme (WSDL file). By utilizing the stub class (Java API) and 
other commonly available Java libraries, we could develop several 
network management systems. I wrote some parts of our experience in 
RFC5381. But as long as data model is not decided, full interoperability 
is not ensured...

p.s.
We are also taking into account using RESTful webservices.

Kind regards,

Graham Phillips wrote:
> Hello,
> 
>  
> 
>  
> 
> I am a proponent of NETCONF and am trying to promote it within my 
> organization, Netscaler/Citrix.
> 
>  
> 
> I am running into some difficultly selling NETCONF to my colleges who 
> have build a prototype using a RESTful web services approach.   In this 
> approach they are using JSON over HTTP.   The retrieval of individual 
> configuration entities is handled by mapping the request to an HTTP GET 
> request on a particular URL (eg. GET device_ip_address/entity_X/name).  
> Setting of configuration entities are mapped to HTTP POST requests.
> 
>  
> 
> Can anyone give me some ideas how I might sell the NETCONF idea to 
> non-believers?
> 
> I think some advantages of NETCONF are:
> 
>             1) That it is a standard that has been adopted by large 
> network vendors (ie Juniper and Cisco)
> 
>                         Any others?
> 
>             2) I suspect that it has been adopted by network management 
> vendors.  Do we have any vendor names?
> 
>  
> 
> One question that I have been asked is how easier is it to wrap 
> client-side language-bindings around the NETCONF protocol.  For example, 
> in the web services world, one has a WSDL file, and client side language 
> binding can be automatically generated.    How does one achieve this 
> stub generation with NETCONF?  Can this be achieve with the NETCONF over 
> SOAP scheme.
> 
>  
> 
> Thank you.
> 
> --Graham Phillips
> 

--
Tomoyuki Iijima

From balazs.lengyel@ericsson.com  Thu Jun 11 02:24:35 2009
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72883A6BFD for <netconf@core3.amsl.com>; Thu, 11 Jun 2009 02:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.206
X-Spam-Level: 
X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoOoA9Zaypj5 for <netconf@core3.amsl.com>; Thu, 11 Jun 2009 02:24:30 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A3E863A6D46 for <netconf@ietf.org>; Thu, 11 Jun 2009 02:24:28 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b9cae00000140d-64-4a30cd526691
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7B.35.05133.25DC03A4; Thu, 11 Jun 2009 11:24:34 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 11 Jun 2009 11:24:33 +0200
Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 11 Jun 2009 11:24:33 +0200
Message-ID: <4A30CD50.5020305@ericsson.com>
Date: Thu, 11 Jun 2009 11:24:32 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>,  Martin Bjorklund <mbj@tail-f.com>
References: <EDC652A26FB23C4EB6384A4584434A0401790365@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0401790365@307622ANEX5.global.avaya.com>
Content-Type: multipart/mixed; boundary="------------020406030902060608020203"
X-OriginalArrivalTime: 11 Jun 2009 09:24:33.0289 (UTC) FILETIME=[6E36B790:01C9EA76]
X-Brightmail-Tracker: AAAAAA==
Cc: netconf mailing list <netconf@ietf.org>
Subject: Re: [Netconf] AD review for draft-ietf-netconf-partial-lock-08.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2009 09:24:36 -0000

This is a multi-part message in MIME format.
--------------020406030902060608020203
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Dan, Martin,
Thanks for the comments.  See below.

I attached a diff between the current 08 version and the future 09 version as it stands at the 
moment.
Balazs

Romascanu, Dan (Dan) wrote:
> This document is ready to be sent to IETF Last Call, and I will send it
> immediately after sending this message. Please consider the comments
> below together with the other IETF Last Call comments.
> 
> 1. IPR and Copyright issues
> 
> Running idnits results in the following warning: 
> 
> == The document seems to lack a disclaimer for pre-RFC5378 work, but was
>      first submitted before 10 November 2008.  Should you add the
> disclaimer?
>      (See the Legal Provisions document at
>      http://trustee.ietf.org/license-info for more information.). 
> 
>      trust-12-feb-2009 Section 6.c.iii text:
>      "This document may contain material from IETF Documents or IETF
>       Contributions published or made publicly available before November
>       10, 2008.  The person(s) controlling the copyright in some of this
>       material may not have granted the IETF Trust the right to allow
>       modifications of such material outside the IETF Standards Process.
> 
>       Without obtaining an adequate license from the person(s)
>       controlling the copyright in such materials, this document may not
>       be modified outside the IETF Standards Process, and derivative
>       works of it may not be created outside the IETF Standards Process,
>       except to format it for publication as an RFC or to translate it
>       into languages other than English."

BALAZS: Changed IPR to pre5378Trust200902.

> 
> Also, the schema in Appendix A will need to include the full text of the
> BSD license for code or a reference to it. This issue is still debated
> with the Trust, so no action by now on this. 

BALAZS: So  I should wait for further information. When and where can I find this, or will the 
chairs or you supply it?

> 
> 2. last paragraph in Section 1.1 
> 
> s/This consist/These consist/

BALAZS: Is OK if I change the paragraph to:
Protected area: the set of nodes that are protected from
modification by the lock.  This set consists of nodes in the scope of
the lock and nodes in subtrees under them.

> 
> 3. Section 2.1.1
> 
> s/However it can be used to lock a candidate datastore/However it can be
> used to lock parts of a candidate datastore/

BALAZS: OK

> 
> 4. The title of Section 2.1.1.1 seems to me to be more appropriately
> 'Multiple managers handling the writable running datastore with
> overlapping sections'

BALAZS: OK

> 
> 5. same section - I am a little nervous about saying 'The lock should be
> held only a short time (seconds rather then minutes)'. What if the lock
> can be help less than seconds or minutes at minimum because of the size
> of the records to be operated? Maybe better is to say 'The lock should
> be held the shortest possible time (e.g. seconds rather then minutes)'.

BALAZS: OK

> 
> 6. Section 2.1.1.2 - better (e.g. minutes, hours)

BALAZS: OK

> 
> 7. Section 2.1.1.3 - same comment as #5 for 2.1.1.1

BALAZS: OK

> 
> 8. page 6 - section 2.4.1 - 'these notes should be included in the
> protected area of the lock' - it seems to me that a capitalized SHOULD
> is appropriate here. 

BALAZS: OK

> 
> 9. Capitalization seems necessary also in 2.4.1.2 and also a change as I
> do not see in which situations if locking fails the client should not
> back-off. I realize this is client behavior, but the normative language
> still seems to apply
> 
> So: 
> 
> OLD: 
> 
>    To avoid this situation, clients should lock
>    everything they need in one operation.  If locking fails, the client
>    should back-off, release any previously acquired locks, and retry the
>    procedure after waiting some randomized time interval.
> 
> NEW:
> 
>    To avoid this situation, clients SHOULD lock
>    everything they need in one operation.  If locking fails, the client
>    MUST back-off, release any previously acquired locks, and SHOULD
> retry the
>    procedure after waiting some randomized time interval.
> 

BALAZS: OK

> 10. Last paragraph in section 3 - why is NOT capitalized? 

BALAZS: Just to emphasize it. I removed the capitalization.

> 
> Dan
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel@ericsson.com

--------------020406030902060608020203
Content-Type: text/html; charset=ISO-8859-1;
 name="partial-lock-rfcdiff.html"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="partial-lock-rfcdiff.html"

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlv
bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5z
aXRpb25hbC5kdGQiPgo8aHRtbD48aGVhZD4KIAo8IS0tIEdlbmVyYXRlZCBieSByZmNkaWZm
IDEuMzU6IHJmY2RpZmYgIC0tPiAKPCEtLSA8IURPQ1RZUEUgaHRtbCBQVUJMSUMgIi0vL1cz
Qy8vRFREIEhUTUwgNC4wMSBUcmFuc2l0aW9uYWwiID4gLS0+CjwhLS0gU3lzdGVtOiBMaW51
eCBnYW1heS50b29scy5pZXRmLm9yZyAyLjYuMjQtMS02ODYgIzEgU01QIFRodSBNYXkgOCAw
MjoxNjozOSBVVEMgMjAwOCBpNjg2IEdOVS9MaW51eCAtLT4gCjwhLS0gVXNpbmcgYXdrOiAv
dXNyL2Jpbi9nYXdrOiBHTlUgQXdrIDMuMS41IC0tPiAKPCEtLSBVc2luZyBkaWZmOiAvdXNy
L2Jpbi9kaWZmOiBkaWZmIChHTlUgZGlmZnV0aWxzKSAyLjguMSAtLT4gCjwhLS0gVXNpbmcg
d2RpZmY6IC91c3IvYmluL3dkaWZmOiBHTlUgd2RpZmYgMC41IC0tPiAKIAogCiAgPG1ldGEg
aHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9
SVNPLTg4NTktMSI+IAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtU3R5bGUtVHlwZSIg
Y29udGVudD0idGV4dC9jc3MiPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1uZXRjb25m
LXBhcnRpYWwtbG9jay0wOC50eHQgLSBkcmFmdC1pZXRmLW5ldGNvbmYtcGFydGlhbC1sb2Nr
LTA5LnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+IAogICAgYm9keSAg
ICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAgIHRyICAgICAg
eyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5OiBtb25v
c3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAgICB0
aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXpl
OiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVs
dmV0aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6
ICNFRUU7IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAg
IC5kaWZmICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJh
Y2tncm91bmQtY29sb3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xv
cjogI0ZGODsgfSAKICAgIC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAog
ICAgLmRlbGV0ZSB7IGJhY2tncm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsg
YmFja2dyb3VuZC1jb2xvcjogI0ZGQjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNv
bG9yOiAjRUVFOyB9IAogICAgLmxpbmViciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0g
CiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9u
dC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmlnaHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAog
ICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGVmdCAuY29u
dCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAucmlnaHQgLmNvbnQgeyBiYWNr
Z3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29udCB7IGJhY2tncm91bmQt
Y29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjog
I0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjMEREOyB9
IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0gCiAgICAu
c3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsg
cGFkZGluZzogMnB4IDA7IH0gCiAgPC9zdHlsZT4gCjwvaGVhZD48Ym9keT4gCiAgPHRhYmxl
IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4gCiAgPHRib2R5
Pjx0ciBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD4mbmJzcDtkcmFmdC1pZXRmLW5l
dGNvbmYtcGFydGlhbC1sb2NrLTA4LnR4dCZuYnNwOzwvdGg+PHRoPiA8L3RoPjx0aD4mbmJz
cDtkcmFmdC1pZXRmLW5ldGNvbmYtcGFydGlhbC1sb2NrLTA5LnR4dCZuYnNwOzwvdGg+PHRo
PjwvdGg+PC90cj4gCiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+TkVUQ09ORiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBCLiBMZW5neWVsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+TkVUQ09ORiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBCLiBMZW5neWVsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFcmljc3NvbjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFcmljc3NvbjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlbmRlZCBz
dGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBC
am9ya2x1bmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbnRlbmRlZCBzdGF0
dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBCam9y
a2x1bmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAxIj48L2E+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs
b2NrIj5FeHBpcmVzOiBEZWNlbWJlciA8c3BhbiBjbGFzcz0iZGVsZXRlIj41LDwvc3Bhbj4g
MjAwOSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRhaWwtZiBTeXN0ZW1zPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPkV4cGlyZXM6IERlY2VtYmVyIDxzcGFu
IGNsYXNzPSJpbnNlcnQiPjEzLDwvc3Bhbj4gMjAwOSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgVGFpbC1mIFN5c3RlbXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249
InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgPHNwYW4gY2xhc3M9ImRl
bGV0ZSI+MDMsPC9zcGFuPiAyMDA5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si
PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgSnVuZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMSw8L3NwYW4+IDIwMDk8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAg
ICBQYXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgIFBhcnRpYWwgTG9jayBSUEMgZm9yIE5F
VENPTkY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAyIj48L2E+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJs
b2NrIj4gICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1uZXRjb25mLXBhcnRpYWwtbG9j
ay0wPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ODwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJibG9jayI+ICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtbmV0Y29uZi1wYXJ0
aWFsLWxvY2stMDxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5TdGF0dXMgb2YgdGhpcyBNZW1vPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+U3RhdHVzIG9mIHRoaXMgTWVtbzwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBp
cyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBz
dWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48
YSBuYW1lPSJkaWZmMDAwMyI+PC9hPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcHJvdmlz
aW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi
bG9jayI+ICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4gIDxzcGFuIGNsYXNz
PSJpbnNlcnQiPlRoaXMgZG9jdW1lbnQgbWF5IGNvbnRhaW4gbWF0ZXJpYWw8L3NwYW4+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j
ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl
cnQiPiAgIGZyb20gSUVURiBEb2N1bWVudHMgb3IgSUVURiBDb250cmlidXRpb25zIHB1Ymxp
c2hlZCBvciBtYWRlIHB1YmxpY2x5PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBhdmFpbGFibGUgYmVmb3Jl
IE5vdmVtYmVyIDEwLCAyMDA4LiAgVGhlIHBlcnNvbihzKSBjb250cm9sbGluZyB0aGU8L3Nw
YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9
ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz
PSJpbnNlcnQiPiAgIGNvcHlyaWdodCBpbiBzb21lIG9mIHRoaXMgbWF0ZXJpYWwgbWF5IG5v
dCBoYXZlIGdyYW50ZWQgdGhlIElFVEY8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFRydXN0IHRoZSByaWdo
dCB0byBhbGxvdyBtb2RpZmljYXRpb25zIG9mIHN1Y2ggbWF0ZXJpYWwgb3V0c2lkZSB0aGU8
L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh
c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNs
YXNzPSJpbnNlcnQiPiAgIElFVEYgU3RhbmRhcmRzIFByb2Nlc3MuICBXaXRob3V0IG9idGFp
bmluZyBhbiBhZGVxdWF0ZSBsaWNlbnNlIGZyb208L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHRoZSBwZXJz
b24ocykgY29udHJvbGxpbmcgdGhlIGNvcHlyaWdodCBpbiBzdWNoIG1hdGVyaWFscywgdGhp
czwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g
Y2xhc3M9Imluc2VydCI+ICAgZG9jdW1lbnQgbWF5IG5vdCBiZSBtb2RpZmllZCBvdXRzaWRl
IHRoZSBJRVRGIFN0YW5kYXJkcyBQcm9jZXNzLCBhbmQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGRlcml2
YXRpdmUgd29ya3Mgb2YgaXQgbWF5IG5vdCBiZSBjcmVhdGVkIG91dHNpZGUgdGhlIElFVEYg
U3RhbmRhcmRzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBQcm9jZXNzLCBleGNlcHQgdG8gZm9ybWF0IGl0
IGZvciBwdWJsaWNhdGlvbiBhcyBhbiBSRkMgb3IgdG88L3NwYW4+PC90ZD48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHRyYW5z
bGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuIEVuZ2xpc2guPC9zcGFuPjwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRz
IGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdv
cmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXNr
IEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90
ZSB0aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGFzayBGb3JjZSAo
SUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdDwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij4gICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50
cyBhcyBJbnRlcm5ldC08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvdGhl
ciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl
cm5ldC08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+ICAgRHJhZnRzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IERyYWZ0cy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElu
dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0g
b2Ygc2l4IG1vbnRoczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVy
bmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg
c2l4IG1vbnRoczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv
bGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRl
ZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJv
cHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8g
dXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWF0ZXJpYWwgb3IgdG8g
Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl
ciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRz
IGNhbiBiZSBhY2Nlc3NlZCBhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBh
dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p
ZXRmLzFpZC1hYnN0cmFjdHMudHh0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+ICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9y
aWVzIGNhbiBiZSBhY2Nlc3NlZCBhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4g
YmUgYWNjZXNzZWQgYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC48
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBodHRwOi8vd3d3LmlldGYub3Jn
L3NoYWRvdy5odG1sLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkPjxhIG5hbWU9ImRpZmYwMDA0Ij48L2E+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBU
aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIERlY2VtYmVyIDxzcGFuIGNsYXNz
PSJkZWxldGUiPjU8L3NwYW4+LCAyMDA5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs
b2NrIj4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIERlY2VtYmVyIDxz
cGFuIGNsYXNzPSJpbnNlcnQiPjEzPC9zcGFuPiwgMjAwOS48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb3B5cmlnaHQgKGMpIDIwMDkgSUVURiBUcnVzdCBh
bmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICBDb3B5cmlnaHQgKGMpIDIwMDkgSUVURiBUcnVzdCBhbmQgdGhlIHBl
cnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249
InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCBy
aWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9j
dW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g
QkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQg
dGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElF
VEYgRG9jdW1lbnRzIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVu
dHMgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMg
ZG9jdW1lbnQgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykuPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1
bWVudCAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKS48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUGxl
YXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJl
IHlvdXIgcmlnaHRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUGxlYXNl
IHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlv
dXIgcmlnaHRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRoPjxh
IG5hbWU9InBhcnQtbDIiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxl
bT4gcGFnZSAyLCBsaW5lIDEwPC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9
InBhcnQtcjIiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFn
ZSAzLCBsaW5lIDc8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0
cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgTkVUQ09ORiBwcm90b2Nv
bCBkZWZpbmVzIHRoZSBsb2NrIGFuZCB1bmxvY2sgUlBDcywgdXNlZCB0byBsb2NrPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIE5FVENPTkYgcHJvdG9jb2wgZGVm
aW5lcyB0aGUgbG9jayBhbmQgdW5sb2NrIFJQQ3MsIHVzZWQgdG8gbG9jazwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBlbnRp
cmUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzLiAgSW4gc29tZSBzaXR1YXRpb25zLCBhIHdh
eSB0byBsb2NrPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZW50aXJlIGNv
bmZpZ3VyYXRpb24gZGF0YXN0b3Jlcy4gIEluIHNvbWUgc2l0dWF0aW9ucywgYSB3YXkgdG8g
bG9jazwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICBvbmx5IHBhcnRzIG9mIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgaXMg
cmVxdWlyZWQuICBUaGlzIGRvY3VtZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+ICAgb25seSBwYXJ0cyBvZiBhIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIGlzIHJlcXVp
cmVkLiAgVGhpcyBkb2N1bWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZWZpbmVzIGEgY2FwYWJpbGl0eS1iYXNlZCBl
eHRlbnNpb24gdG8gdGhlIE5FVENPTkYgcHJvdG9jb2wgZm9yPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgZGVmaW5lcyBhIGNhcGFiaWxpdHktYmFzZWQgZXh0ZW5zaW9u
IHRvIHRoZSBORVRDT05GIHByb3RvY29sIGZvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBsb2NraW5nIHBvcnRpb25zIG9m
IGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+ICAgbG9ja2luZyBwb3J0aW9ucyBvZiBhIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jl
LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+VGFibGUgb2YgQ29u
dGVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5UYWJsZSBvZiBDb250ZW50
czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9
ImRpZmYwMDA1Ij48L2E+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAxLiAgSW50cm9kdWN0
aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
IDxzcGFuIGNsYXNzPSJkZWxldGUiPjM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyYmxvY2siPiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+NDwvc3Bh
bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i
bGJsb2NrIj4gICAgIDEuMS4gIERlZmluaXRpb24gb2YgVGVybXMgIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjM8L3NwYW4+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgMS4xLiAgRGVmaW5pdGlv
biBvZiBUZXJtcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNw
YW4gY2xhc3M9Imluc2VydCI+NDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAyLiAgUGFydGlhbCBMb2NraW5n
IENhcGFiaWxpdHkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFu
IGNsYXNzPSJkZWxldGUiPjM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPiAgIDIuICBQYXJ0aWFsIExvY2tpbmcgQ2FwYWJpbGl0eSAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+NDwvc3Bhbj48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr
Ij4gICAgIDIuMS4gIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjM8L3NwYW4+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgMi4xLiAgT3ZlcnZpZXcgLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xh
c3M9Imluc2VydCI+NDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgMi4xLjEuICBVc2FnZSBTY2VuYXJp
b3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNz
PSJkZWxldGUiPjQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg
ICAgICAyLjEuMS4gIFVzYWdlIFNjZW5hcmlvcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+NTwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg
IDIuMi4gIERlcGVuZGVuY2llcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjY8L3NwYW4+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgMi4yLiAgRGVwZW5kZW5jaWVzIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imlu
c2VydCI+Nzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDIuMy4gIENhcGFiaWxpdHkgSWRlbnRpZmllciAg
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxl
dGUiPjY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgMi4z
LiAgQ2FwYWJpbGl0eSBJZGVudGlmaWVyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+Nzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDIuNC4g
IE5ldyBPcGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyYmxvY2siPiAgICAgMi40LiAgTmV3IE9wZXJhdGlvbnMgLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+
Nzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj4gICAgICAgMi40LjEuICAmbHQ7cGFydGlhbC1sb2NrJmd0OyAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxl
dGUiPjY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAy
LjQuMS4gICZsdDtwYXJ0aWFsLWxvY2smZ3Q7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+Nzwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg
ICAgMi40LjIuICAmbHQ7cGFydGlhbC11bmxvY2smZ3Q7IC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTE8L3NwYW4+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAyLjQuMi4gICZsdDtwYXJ0aWFs
LXVubG9jayZndDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3Bh
biBjbGFzcz0iaW5zZXJ0Ij4xMjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDIuNS4gIE1vZGlmaWNhdGlv
bnMgdG8gRXhpc3RpbmcgT3BlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4g
Y2xhc3M9ImRlbGV0ZSI+MTE8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPiAgICAgMi41LiAgTW9kaWZpY2F0aW9ucyB0byBFeGlzdGluZyBPcGVyYXRpb25zIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xMzwvc3Bhbj48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr
Ij4gICAgIDIuNi4gIEludGVyYWN0aW9ucyB3aXRoIE90aGVyIENhcGFiaWxpdGllcyAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTI8L3NwYW4+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgMi42LiAgSW50ZXJhY3Rpb25zIHdp
dGggT3RoZXIgQ2FwYWJpbGl0aWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFz
cz0iaW5zZXJ0Ij4xNDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgMi42LjEuICBDYW5kaWRhdGUgQ29u
ZmlndXJhdGlvbiBDYXBhYmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9
ImRlbGV0ZSI+MTI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg
ICAgICAyLjYuMS4gIENhbmRpZGF0ZSBDb25maWd1cmF0aW9uIENhcGFiaWxpdHkgLiAuIC4g
LiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNDwvc3Bhbj48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg
ICAgMi42LjIuICBDb25maXJtZWQgQ29tbWl0IENhcGFiaWxpdHkgIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTI8L3NwYW4+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAyLjYuMi4gIENvbmZpcm1lZCBDb21taXQg
Q2FwYWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5z
ZXJ0Ij4xNDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgMi42LjMuICBEaXN0aW5jdCBTdGFydHVwIENh
cGFiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0
ZSI+MTI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAy
LjYuMy4gIERpc3RpbmN0IFN0YXJ0dXAgQ2FwYWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAzLiAgU2Vj
dXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyYmxvY2siPiAgIDMuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4x
NDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj4gICA0LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTM8
L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDQuICBJQU5BIENv
bnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA1LiAgQXBwZW5kaXgg
QSAgLSAgWE1MIFNjaGVtYSBmb3IgUGFydGlhbCBMb2NraW5nIChub3JtYXRpdmUpICAuIC4g
PHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyYmxvY2siPiAgIDUuICBBcHBlbmRpeCBBICAtICBYTUwgU2NoZW1hIGZvciBQYXJ0aWFs
IExvY2tpbmcgKG5vcm1hdGl2ZSkgIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4xNjwvc3Bh
bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+ICAgNi4gIEFwcGVuZGl4IEIgIC0gWUFORyBNb2R1bGUgZm9yIFBhcnRpYWwgTG9j
a2luZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDYuICBBcHBlbmRpeCBC
ICAtIFlBTkcgTW9kdWxlIGZvciBQYXJ0aWFsIExvY2tpbmc8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRp
ZmYwMDA2Ij48L2E+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgKG5vbi1ub3JtYXRp
dmUpICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNw
YW4gY2xhc3M9ImRlbGV0ZSI+MTk8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
YmxvY2siPiAgICAgICAobm9uLW5vcm1hdGl2ZSkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yMDwvc3Bhbj48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+ICAgNy4gIEFwcGVuZGl4IEMgLSBVc2FnZSBFeGFtcGxlIC0gUmVzZXJ2aW5nIG5vZGVz
IGZvciBmdXR1cmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA3LiAgQXBw
ZW5kaXggQyAtIFVzYWdlIEV4YW1wbGUgLSBSZXNlcnZpbmcgbm9kZXMgZm9yIGZ1dHVyZTwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDciPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg
ICAgICBlZGl0aW5nIChub24tbm9ybWF0aXZlKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4yMjwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIGVkaXRpbmcgKG5vbi1ub3JtYXRpdmUp
ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJp
bnNlcnQiPjIzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDguICBBcHBlbmRpeCBEICAtICBDaGFuZ2UgTG9n
ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVs
ZXRlIj4yNzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgOC4g
IEFwcGVuZGl4IEQgIC0gIENoYW5nZSBMb2cgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjI4PC9zcGFuPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgOC4x
LiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MDctMDg8L3NwYW4+ICAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0
ZSI+Mjc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgOC4x
LiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MDgtMDk8L3NwYW4+ICAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9Imluc2Vy
dCI+Mjg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxibG9jayI+ICAgICA4LjIuICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4wNi0w
Nzwvc3Bhbj4gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4yNzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJibG9jayI+ICAgICA4LjIuICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4wNy0w
ODwvc3Bhbj4gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDguMy4g
IDxzcGFuIGNsYXNzPSJkZWxldGUiPjA1LTA2PC9zcGFuPiAgLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJkZWxldGUi
PjI3PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDguMy4g
IDxzcGFuIGNsYXNzPSJpbnNlcnQiPjA2LTA3PC9zcGFuPiAgLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQi
PjI4PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk
IGNsYXNzPSJsYmxvY2siPiAgICAgOC40LiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MDQtMDU8
L3NwYW4+ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Mjc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyYmxvY2siPiAgICAgOC40LiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MDUtMDY8
L3NwYW4+ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gPHNwYW4gY2xhc3M9Imluc2VydCI+Mjg8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICA4LjUuICA8
c3BhbiBjbGFzcz0iZGVsZXRlIj4wMy0wNDwvc3Bhbj4gIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4y
Nzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICA4LjUuICA8
c3BhbiBjbGFzcz0iaW5zZXJ0Ij4wNC0wNTwvc3Bhbj4gIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4y
ODwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj4gICAgIDguNi4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjAyLTAzPC9z
cGFuPiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIDI4PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgOC42LiAgPHNw
YW4gY2xhc3M9Imluc2VydCI+MDMtMDQ8L3NwYW4+ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjg8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDguNy4gIDxzcGFu
IGNsYXNzPSJkZWxldGUiPjAxLTAyPC9zcGFuPiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJkZWxldGUiPjI4PC9z
cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIDguNy4gIDxzcGFu
IGNsYXNzPSJpbnNlcnQiPjAyLTAzPC9zcGFuPiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjI5PC9z
cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz
PSJsYmxvY2siPiAgICAgOC44LiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MDAtMDE8L3NwYW4+
ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
PHNwYW4gY2xhc3M9ImRlbGV0ZSI+Mjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyYmxvY2siPiAgICAgOC44LiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MDEtMDI8L3NwYW4+
ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
PHNwYW4gY2xhc3M9Imluc2VydCI+Mjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICA4LjkuICAtMDAgIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxz
cGFuIGNsYXNzPSJkZWxldGUiPjI4PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmJsb2NrIj4gICAgIDguOS4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjAwLTAxICAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjk8L3NwYW4+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi
bG9jayI+ICAgOS4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJkZWxldGUiPjI5PC9zcGFuPjwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g
ICAgIDguMTAuPC9zcGFuPiAtMDAgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjI5PC9zcGFuPjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv
Y2siPiAgIDEwLiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4zMDwvc3Bhbj48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgOS4gIEFja25vd2xlZGdlbWVudHMg
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNs
YXNzPSJpbnNlcnQiPjMwPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgMTAuMS4gTm9ybWF0aXZlIFJlZmVy
ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFz
cz0iZGVsZXRlIj4zMDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+
ICAgMTAuIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjMxPC9zcGFuPjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg
ICAgMTAuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4zMDwvc3Bhbj48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAxMC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNl
cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJp
bnNlcnQiPjMxPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3BhbiBjbGFzcz0iZGVs
ZXRlIj4zMTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAx
MC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjMxPC9zcGFuPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHNwYW4gY2xhc3M9
Imluc2VydCI+MzI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+ICAgVGhlIFtORVRDT05GXSBwcm90b2NvbCBkZXNjcmliZXMgdGhlIGxvY2sgYW5kIHVu
bG9jayBvcGVyYXRpb25zIHRoYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICBUaGUgW05FVENPTkZdIHByb3RvY29sIGRlc2NyaWJlcyB0aGUgbG9jayBhbmQgdW5sb2Nr
IG9wZXJhdGlvbnMgdGhhdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcGVyYXRlIG9uIGVudGlyZSBjb25maWd1cmF0aW9u
IGRhdGFzdG9yZXMuICBPZnRlbiwgbXVsdGlwbGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBvcGVyYXRlIG9uIGVudGlyZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZXMu
ICBPZnRlbiwgbXVsdGlwbGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWFuYWdlbWVudCBzZXNzaW9ucyBuZWVkIHRvIGJl
IGFibGUgdG8gbW9kaWZ5IHRoZSBjb25maWd1cmF0aW9uIG9mIGE8L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij4gICBtYW5hZ2VtZW50IHNlc3Npb25zIG5lZWQgdG8gYmUgYWJs
ZSB0byBtb2RpZnkgdGhlIGNvbmZpZ3VyYXRpb24gb2YgYTwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtYW5hZ2VkIGRldmlj
ZSBpbiBwYXJhbGxlbC4gIEluIHRoZXNlIGNhc2VzLCBsb2NraW5nIG9ubHkgcGFydHMgb2Yg
YTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1hbmFnZWQgZGV2aWNlIGlu
IHBhcmFsbGVsLiAgSW4gdGhlc2UgY2FzZXMsIGxvY2tpbmcgb25seSBwYXJ0cyBvZiBhPC90
ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIGlzIG5lZWRlZC4gIFRoaXMgZG9jdW1lbnQg
ZGVmaW5lcyBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29uZmlndXJh
dGlvbiBkYXRhc3RvcmUgaXMgbmVlZGVkLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGE8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
ICAgY2FwYWJpbGl0eSBiYXNlZCBleHRlbnNpb24gdG8gdGhlIE5FVENPTkYgcHJvdG9jb2wg
dG8gc3VwcG9ydCBwYXJ0aWFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
Y2FwYWJpbGl0eSBiYXNlZCBleHRlbnNpb24gdG8gdGhlIE5FVENPTkYgcHJvdG9jb2wgdG8g
c3VwcG9ydCBwYXJ0aWFsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGxvY2tpbmcgb2YgTkVUQ09ORiBkYXRhc3RvcmVzIHVz
aW5nIGEgbWVjaGFuaXNtIGJhc2VkIG9uIHRoZSBleGlzdGluZzwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIGxvY2tpbmcgb2YgTkVUQ09ORiBkYXRhc3RvcmVzIHVzaW5n
IGEgbWVjaGFuaXNtIGJhc2VkIG9uIHRoZSBleGlzdGluZzwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29s
b3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwzIj48c21hbGw+c2tpcHBp
bmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMywgbGluZSAzNjwvZW0+PC9hPjwv
dGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXIzIj48c21hbGw+c2tpcHBpbmcgdG8g
Y2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgNCwgbGluZSAzNjwvZW0+PC9hPjwvdGg+PHRk
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIG5vZGUgaW4gdGhlIGNvbmNlcHR1YWwgWE1M
IGRhdGFzdG9yZS4gIEl0IGNvbnRhaW5zIGFuIGFic29sdXRlPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgICAgbm9kZSBpbiB0aGUgY29uY2VwdHVhbCBYTUwgZGF0YXN0
b3JlLiAgSXQgY29udGFpbnMgYW4gYWJzb2x1dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgcGF0aCBleHByZXNzaW9u
IGluIGFiYnJldmlhdGVkIHN5bnRheCwgd2hlcmUgcHJlZGljYXRlcyBhcmUgdXNlZDwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHBhdGggZXhwcmVzc2lvbiBpbiBh
YmJyZXZpYXRlZCBzeW50YXgsIHdoZXJlIHByZWRpY2F0ZXMgYXJlIHVzZWQ8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg
b25seSB0byBzcGVjaWZ5IHZhbHVlcyBmb3Igbm9kZXMgZGVmaW5lZCBhcyBrZXlzIHRvIGRp
c3Rpbmd1aXNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgb25seSB0
byBzcGVjaWZ5IHZhbHVlcyBmb3Igbm9kZXMgZGVmaW5lZCBhcyBrZXlzIHRvIGRpc3Rpbmd1
aXNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPiAgICAgIG11bHRpcGxlIGluc3RhbmNlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICAgICBtdWx0aXBsZSBpbnN0YW5jZXMuPC90ZD48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBTY29wZSBvZiB0aGUgbG9jazogaW5pdGlh
bGx5IHRoZSBzZXQgb2Ygbm9kZXMgcmV0dXJuZWQgYnkgdGhlPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgbyAgU2NvcGUgb2YgdGhlIGxvY2s6IGluaXRpYWxseSB0aGUg
c2V0IG9mIG5vZGVzIHJldHVybmVkIGJ5IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBYUGF0aCBleHByZXNzaW9u
cyBpbiBhIHN1Y2Nlc3NmdWwgcGFydGlhbC1sb2NrIG9wZXJhdGlvbi4gIFRoZSBzZXQ8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBYUGF0aCBleHByZXNzaW9ucyBp
biBhIHN1Y2Nlc3NmdWwgcGFydGlhbC1sb2NrIG9wZXJhdGlvbi4gIFRoZSBzZXQ8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
ICAgbWlnaHQgYmUgbW9kaWZpZWQgaWYgc29tZSBvZiB0aGUgbm9kZXMgYXJlIGRlbGV0ZWQu
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgbWlnaHQgYmUgbW9kaWZp
ZWQgaWYgc29tZSBvZiB0aGUgbm9kZXMgYXJlIGRlbGV0ZWQuPC90ZD48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBQcm90ZWN0ZWQgYXJlYTogdGhlIHNldCBv
ZiBub2RlcyB0aGF0IGFyZSBwcm90ZWN0ZWQgZnJvbTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgIG8gIFByb3RlY3RlZCBhcmVhOiB0aGUgc2V0IG9mIG5vZGVzIHRoYXQg
YXJlIHByb3RlY3RlZCBmcm9tPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwOCI+PC9hPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxibG9jayI+ICAgICAgbW9kaWZpY2F0aW9uIGJ5IHRoZSBsb2NrLiAgVGhp
cyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5jb25zaXN0PC9zcGFuPiBvZiBub2RlcyBpbiB0aGUg
c2NvcGUgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgbW9kaWZp
Y2F0aW9uIGJ5IHRoZSBsb2NrLiAgVGhpcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zZXQgY29u
c2lzdHM8L3NwYW4+IG9mIG5vZGVzIGluIHRoZSBzY29wZTwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIHRoZSBsb2Nr
IGFuZCBub2RlcyBpbiBzdWJ0cmVlcyB1bmRlciB0aGVtLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmJsb2NrIj4gICAgICBvZiB0aGUgbG9jayBhbmQgbm9kZXMgaW4gc3VidHJlZXMg
dW5kZXIgdGhlbS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIu
ICBQYXJ0aWFsIExvY2tpbmcgQ2FwYWJpbGl0eTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPjIuICBQYXJ0aWFsIExvY2tpbmcgQ2FwYWJpbGl0eTwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi4xLiAgT3ZlcnZpZXc8L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij4yLjEuICBPdmVydmlldzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIDpwYXJ0aWFsLWxvY2sgY2FwYWJpbGl0eSBpbmRp
Y2F0ZXMgdGhhdCB0aGUgZGV2aWNlIHN1cHBvcnRzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj
bGFzcz0icmlnaHQiPiAgIFRoZSA6cGFydGlhbC1sb2NrIGNhcGFiaWxpdHkgaW5kaWNhdGVz
IHRoYXQgdGhlIGRldmljZSBzdXBwb3J0cyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbG9ja2luZyBvZiBpdHMgY29u
ZmlndXJhdGlvbiB3aXRoIGEgbW9yZSBsaW1pdGVkIHNjb3BlIHRoYW4gYTwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxvY2tpbmcgb2YgaXRzIGNvbmZpZ3VyYXRpb24g
d2l0aCBhIG1vcmUgbGltaXRlZCBzY29wZSB0aGFuIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29tcGxldGUgY29uZmln
dXJhdGlvbiBkYXRhc3RvcmUuICBUaGUgc2NvcGUgdG8gYmUgbG9ja2VkIGlzPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29tcGxldGUgY29uZmlndXJhdGlvbiBkYXRh
c3RvcmUuICBUaGUgc2NvcGUgdG8gYmUgbG9ja2VkIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNwZWNpZmllZCBieSB1
c2luZyByZXN0cmljdGVkIG9yIGZ1bGwgWFBhdGggZXhwcmVzc2lvbnMuICBQYXJ0aWFsPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3BlY2lmaWVkIGJ5IHVzaW5nIHJl
c3RyaWN0ZWQgb3IgZnVsbCBYUGF0aCBleHByZXNzaW9ucy4gIFBhcnRpYWw8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbG9j
a2luZyBvbmx5IGFmZmVjdHMgY29uZmlndXJhdGlvbiBkYXRhLjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIGxvY2tpbmcgb25seSBhZmZlY3RzIGNvbmZpZ3VyYXRpb24g
ZGF0YS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFt
ZT0icGFydC1sNCI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBw
YWdlIDQsIGxpbmUgMjc8L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFy
dC1yNCI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDUs
IGxpbmUgMjc8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4yLjEuMS4g
IFVzYWdlIFNjZW5hcmlvczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjIuMS4x
LiAgVXNhZ2UgU2NlbmFyaW9zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICBJbiB0aGUgZm9sbG93aW5nIHdlIGRlc2NyaWJlIGEgZmV3IHNjZW5hcmlvcyBm
b3IgcGFydGlhbCBsb2NraW5nLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
IEluIHRoZSBmb2xsb3dpbmcgd2UgZGVzY3JpYmUgYSBmZXcgc2NlbmFyaW9zIGZvciBwYXJ0
aWFsIGxvY2tpbmcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIFBhcnRpYWwgbG9ja2luZyBpcyBwcmltYXJpbHkgdXNlZnVs
IHRvd2FyZHMgdGhlIHJ1bm5pbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICBQYXJ0aWFsIGxvY2tpbmcgaXMgcHJpbWFyaWx5IHVzZWZ1bCB0b3dhcmRzIHRoZSBydW5u
aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPiAgIGNvbmZpZ3VyYXRpb24uICBIb3dldmVyIGl0IGNhbiBiZSB1c2VkIHRvIGxv
Y2sgYSBjYW5kaWRhdGUgZGF0YXN0b3JlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+ICAgY29uZmlndXJhdGlvbi4gIEhvd2V2ZXIgaXQgY2FuIGJlIHVzZWQgdG8gbG9jayBh
IGNhbmRpZGF0ZSBkYXRhc3RvcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXMgd2VsbC4gIFdoaWxlIHNjZW5hcmlvcyB1
c2luZyB0aGUgcnVubmluZyBkYXRhc3RvcmUgYXJlIHNlZW4gYXMgdGhlPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXMgd2VsbC4gIFdoaWxlIHNjZW5hcmlvcyB1c2lu
ZyB0aGUgcnVubmluZyBkYXRhc3RvcmUgYXJlIHNlZW4gYXMgdGhlPC90ZD48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1vc3QgaW1w
b3J0YW50LCBhcyBhbiBleGFtcGxlIGEgc2NlbmFyaW8gaW52b2x2aW5nIHRoZSBjYW5kaWRh
dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtb3N0IGltcG9ydGFudCwg
YXMgYW4gZXhhbXBsZSBhIHNjZW5hcmlvIGludm9sdmluZyB0aGUgY2FuZGlkYXRlPC90ZD48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
IGRhdGFzdG9yZSBpcyBhbHNvIHByZXNlbnRlZC4gIEJlc2lkZXMgdGhlIHRocmVlIGRlc2Ny
aWJlZCBoZXJlLCB0aGVyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRh
dGFzdG9yZSBpcyBhbHNvIHByZXNlbnRlZC4gIEJlc2lkZXMgdGhlIHRocmVlIGRlc2NyaWJl
ZCBoZXJlLCB0aGVyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICBhcmUgbWFueSBvdGhlciB1c2FnZSBzY2VuYXJpb3MgcG9z
c2libGUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXJlIG1hbnkgb3Ro
ZXIgdXNhZ2Ugc2NlbmFyaW9zIHBvc3NpYmxlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA5Ij48L2E+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGJsb2NrIj4yLjEuMS4xLiAgTXVsdGlwbGUgbWFuYWdlcnMgaGFuZGxpbmcgdGhlIHdy
aXRhYmxlIHJ1bm5pbmcgZGF0YXN0b3JlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv
Y2siPjIuMS4xLjEuICBNdWx0aXBsZSBtYW5hZ2VycyBoYW5kbGluZyB0aGUgd3JpdGFibGUg
cnVubmluZyBkYXRhc3RvcmUgPHNwYW4gY2xhc3M9Imluc2VydCI+d2l0aDwvc3Bhbj48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy
dCI+ICAgICAgICAgIG92ZXJsYXBwaW5nIHNlY3Rpb25zPC9zcGFuPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249
InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTXVsdGlwbGUgbWFuYWdlcnMgYXJlIGhh
bmRsaW5nIHRoZSBzYW1lIE5FVENPTkYgYWdlbnQgc2ltdWx0YW5lb3VzbHkuPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTXVsdGlwbGUgbWFuYWdlcnMgYXJlIGhhbmRs
aW5nIHRoZSBzYW1lIE5FVENPTkYgYWdlbnQgc2ltdWx0YW5lb3VzbHkuPC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBh
Z2VudCBpcyBoYW5kbGVkIHZpYSB0aGUgd3JpdGFibGUgcnVubmluZyBkYXRhc3RvcmUuICBF
YWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGFnZW50IGlzIGhh
bmRsZWQgdmlhIHRoZSB3cml0YWJsZSBydW5uaW5nIGRhdGFzdG9yZS4gIEVhY2g8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
bWFuYWdlciBoYXMgaGlzIG9yIGhlciBvd24gdGFzaywgd2hpY2ggbWlnaHQgaW52b2x2ZSB0
aGUgbW9kaWZpY2F0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWFu
YWdlciBoYXMgaGlzIG9yIGhlciBvd24gdGFzaywgd2hpY2ggbWlnaHQgaW52b2x2ZSB0aGUg
bW9kaWZpY2F0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIG9mIG92ZXJsYXBwaW5nIHNlY3Rpb25zIG9mIHRoZSBkYXRh
c3RvcmUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2Ygb3ZlcmxhcHBp
bmcgc2VjdGlvbnMgb2YgdGhlIGRhdGFzdG9yZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIEFmdGVyIGNvbGxlY3RpbmcgYW5kIGFuYWx5emluZyBpbnB1
dCBhbmQgcHJlcGFyaW5nIHRoZSBORVRDT05GPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+ICAgQWZ0ZXIgY29sbGVjdGluZyBhbmQgYW5hbHl6aW5nIGlucHV0IGFuZCBwcmVw
YXJpbmcgdGhlIE5FVENPTkY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3BlcmF0aW9ucyBvZmYtbGluZSwgdGhlIG1hbmFn
ZXIgbG9ja3MgdGhlIGFyZWFzIHRoYXQgYXJlIGltcG9ydGFudDwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIG9wZXJhdGlvbnMgb2ZmLWxpbmUsIHRoZSBtYW5hZ2VyIGxv
Y2tzIHRoZSBhcmVhcyB0aGF0IGFyZSBpbXBvcnRhbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZm9yIGhpcyB0YXNrIHVz
aW5nIG9uZSBzaW5nbGUgJmx0O3BhcnRpYWwtbG9jayZndDsgb3BlcmF0aW9uLiAgVGhlIG1h
bmFnZXI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmb3IgaGlzIHRhc2sg
dXNpbmcgb25lIHNpbmdsZSAmbHQ7cGFydGlhbC1sb2NrJmd0OyBvcGVyYXRpb24uICBUaGUg
bWFuYWdlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBleGVjdXRlcyBhIG51bWJlciBvZiAmbHQ7ZWRpdC1jb25maWcmZ3Q7
IG9wZXJhdGlvbnMgdG8gbW9kaWZ5IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIGV4ZWN1dGVzIGEgbnVtYmVyIG9mICZsdDtlZGl0LWNvbmZpZyZndDsgb3BlcmF0
aW9ucyB0byBtb2RpZnkgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbmZpZ3VyYXRpb24sIHRoZW4gcmVsZWFzZXMg
dGhlIHBhcnRpYWwtbG9jay4gIFRoZSBsb2NrIHNob3VsZCBiZTwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIGNvbmZpZ3VyYXRpb24sIHRoZW4gcmVsZWFzZXMgdGhlIHBh
cnRpYWwtbG9jay4gIFRoZSBsb2NrIHNob3VsZCBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw
MTAiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGhlbGQgZm9yIDxzcGFuIGNsYXNz
PSJkZWxldGUiPm9ubHkgYSBzaG9ydDwvc3Bhbj4gdGltZSA8c3BhbiBjbGFzcz0iZGVsZXRl
Ij4oc2Vjb25kczwvc3Bhbj4gcmF0aGVyIHRoZW4gbWludXRlcykuICBUaGU8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgaGVsZCBmb3IgPHNwYW4gY2xhc3M9Imluc2Vy
dCI+dGhlIHNob3J0ZXN0IHBvc3NpYmxlPC9zcGFuPiB0aW1lIDxzcGFuIGNsYXNzPSJpbnNl
cnQiPihlLmcuIHNlY29uZHM8L3NwYW4+IHJhdGhlciB0aGVuPC90ZD48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbWFuYWdlciBz
aG91bGQgY29sbGVjdCBhbGwgaHVtYW4gaW5wdXQgYmVmb3JlIGxvY2tpbmcgYW55dGhpbmcu
ICBBczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBtaW51dGVzKS4gIFRo
ZSBtYW5hZ2VyIHNob3VsZCBjb2xsZWN0IGFsbCBodW1hbiBpbnB1dCBiZWZvcmUgbG9ja2lu
ZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs
YmxvY2siPiAgIGVhY2ggbWFuYWdlciBsb2NrcyBvbmx5IGEgcGFydCBvZiB0aGUgZGF0YSBt
b2RlbCwgdXN1YWxseSBtdWx0aXBsZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij4gICBhbnl0aGluZy4gIEFzIGVhY2ggbWFuYWdlciBsb2NrcyBvbmx5IGEgcGFydCBvZiB0
aGUgZGF0YSBtb2RlbCw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBvcGVyYXRvcnMgY2FuIGV4ZWN1dGUgdGhlICZsdDtl
ZGl0LWNvbmZpZyZndDsgb3BlcmF0aW9ucyBzaW11bHRhbmVvdXNseS48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdXN1YWxseSBtdWx0aXBsZSBvcGVyYXRvcnMgY2Fu
IGV4ZWN1dGUgdGhlICZsdDtlZGl0LWNvbmZpZyZndDsgb3BlcmF0aW9uczwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBzaW11bHRhbmVvdXNseS48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuMS4xLjIuICBNdWx0aXBsZSBt
YW5hZ2VycyBoYW5kbGluZyB0aGUgd3JpdGFibGUgcnVubmluZyBkYXRhc3RvcmUsPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Mi4xLjEuMi4gIE11bHRpcGxlIG1hbmFnZXJz
IGhhbmRsaW5nIHRoZSB3cml0YWJsZSBydW5uaW5nIGRhdGFzdG9yZSw8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg
IGRpc3RpbmN0IG1hbmFnZW1lbnQgYXJlYXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICAgICAgICAgZGlzdGluY3QgbWFuYWdlbWVudCBhcmVhczwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249
InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTXVsdGlwbGUgbWFuYWdlcnMgYXJlIGhh
bmRsaW5nIHRoZSBzYW1lIE5FVENPTkYgYWdlbnQgc2ltdWx0YW5lb3VzbHkuPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTXVsdGlwbGUgbWFuYWdlcnMgYXJlIGhhbmRs
aW5nIHRoZSBzYW1lIE5FVENPTkYgYWdlbnQgc2ltdWx0YW5lb3VzbHkuPC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBh
Z2VudCBpcyBoYW5kbGVkIHZpYSB0aGUgd3JpdGFibGUgcnVubmluZyBkYXRhc3RvcmUuICBU
aGUgYWdlbnQnczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBhZ2Vu
dCBpcyBoYW5kbGVkIHZpYSB0aGUgd3JpdGFibGUgcnVubmluZyBkYXRhc3RvcmUuICBUaGUg
YWdlbnQnczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBkYXRhIG1vZGVsIGNvbnRhaW5zIGEgbnVtYmVyIG9mIHdlbGwgZGVm
aW5lZCBzZXBhcmF0ZSBhcmVhcyB0aGF0IGNhbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgIGRhdGEgbW9kZWwgY29udGFpbnMgYSBudW1iZXIgb2Ygd2VsbCBkZWZpbmVk
IHNlcGFyYXRlIGFyZWFzIHRoYXQgY2FuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249
InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJlIGNvbmZpZ3VyZWQgd2l0aG91dCBp
bXBhY3Rpbmcgb3RoZXIgYXJlYXMuICBBbiBleGFtcGxlIGNhbiBiZSBhPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmUgY29uZmlndXJlZCB3aXRob3V0IGltcGFjdGlu
ZyBvdGhlciBhcmVhcy4gIEFuIGV4YW1wbGUgY2FuIGJlIGE8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2VydmVyIHdpdGgg
bXVsdGlwbGUgYXBwbGljYXRpb25zIHJ1bm5pbmcgb24gaXQsIG9yIGEgbnVtYmVyIG9mIGE8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzZXJ2ZXIgd2l0aCBtdWx0aXBs
ZSBhcHBsaWNhdGlvbnMgcnVubmluZyBvbiBpdCwgb3IgYSBudW1iZXIgb2YgYTwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBu
ZXR3b3JrIGVsZW1lbnRzIHdpdGggYSBjb21tb24gTkVUQ09ORiBhZ2VudCBmb3IgbWFuYWdl
bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBuZXR3b3JrIGVsZW1l
bnRzIHdpdGggYSBjb21tb24gTkVUQ09ORiBhZ2VudCBmb3IgbWFuYWdlbWVudC48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEVhY2ggbWFuYWdlciBoYXMg
aGlzIG9yIGhlciBvd24gdGFzaywgd2hpY2ggZG9lcyBub3QgaW52b2x2ZSB0aGU8L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBFYWNoIG1hbmFnZXIgaGFzIGhpcyBvciBo
ZXIgb3duIHRhc2ssIHdoaWNoIGRvZXMgbm90IGludm9sdmUgdGhlPC90ZD48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1vZGlmaWNh
dGlvbiBvZiBvdmVybGFwcGluZyBzZWN0aW9ucyBvZiB0aGUgZGF0YXN0b3JlLjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1vZGlmaWNhdGlvbiBvZiBvdmVybGFwcGlu
ZyBzZWN0aW9ucyBvZiB0aGUgZGF0YXN0b3JlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIG1hbmFnZXIgbG9ja3MgaGlzIGFyZWEgd2l0aCBhICZs
dDtwYXJ0aWFsLWxvY2smZ3Q7IG9wZXJhdGlvbiwgdXNlcyBhPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgVGhlIG1hbmFnZXIgbG9ja3MgaGlzIGFyZWEgd2l0aCBhICZs
dDtwYXJ0aWFsLWxvY2smZ3Q7IG9wZXJhdGlvbiwgdXNlcyBhPC90ZD48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG51bWJlciBvZiAm
bHQ7ZWRpdC1jb25maWcmZ3Q7IGNvbW1hbmRzIHRvIG1vZGlmeSBpdCwgbGF0ZXIgcmVsZWFz
ZXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbnVtYmVyIG9mICZs
dDtlZGl0LWNvbmZpZyZndDsgY29tbWFuZHMgdG8gbW9kaWZ5IGl0LCBsYXRlciByZWxlYXNl
cyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+ICAgbG9jay4gIEFzIGVhY2ggbWFuYWdlciBoYXMgaGlzIGZ1bmN0aW9uYWwg
YXJlYSBhc3NpZ25lZCB0byBoaW0sIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIGxvY2suICBBcyBlYWNoIG1hbmFnZXIgaGFzIGhpcyBmdW5jdGlvbmFsIGFyZWEg
YXNzaWduZWQgdG8gaGltLCBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaGUgbG9ja3Mgb25seSB0aGF0IGFyZWEsIG11
bHRpcGxlIG1hbmFnZXJzIGNhbiBlZGl0IHRoZSBjb25maWd1cmF0aW9uPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaGUgbG9ja3Mgb25seSB0aGF0IGFyZWEsIG11bHRp
cGxlIG1hbmFnZXJzIGNhbiBlZGl0IHRoZSBjb25maWd1cmF0aW9uPC90ZD48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1l
PSJkaWZmMDAxMSI+PC9hPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgc2ltdWx0YW5lb3Vz
bHkuICBMb2NrcyBjYW4gYmUgaGVsZCBmb3IgZXh0ZW5kZWQgcGVyaW9kcyA8c3BhbiBjbGFz
cz0iZGVsZXRlIj4obWludXRlcyw8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
YmxvY2siPiAgIHNpbXVsdGFuZW91c2x5LiAgTG9ja3MgY2FuIGJlIGhlbGQgZm9yIGV4dGVu
ZGVkIHBlcmlvZHMgPHNwYW4gY2xhc3M9Imluc2VydCI+KGUuZy48L3NwYW4+PC90ZD48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg
aG91cnMpLCBhcyB0aGlzIHdpbGwgbm90IGhpbmRlciBvdGhlciBtYW5hZ2Vycy48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgbWlu
dXRlcyw8L3NwYW4+IGhvdXJzKSwgYXMgdGhpcyB3aWxsIG5vdCBoaW5kZXIgb3RoZXIgbWFu
YWdlcnMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlz
IHNjZW5hcmlvIGFzc3VtZXMsIHRoYXQgdGhlIGdsb2JhbCBsb2NrIG9wZXJhdGlvbiBmcm9t
IFtORVRDT05GXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgc2Nl
bmFyaW8gYXNzdW1lcywgdGhhdCB0aGUgZ2xvYmFsIGxvY2sgb3BlcmF0aW9uIGZyb20gW05F
VENPTkZdPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIGlzIG5vdCB1c2VkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIGlzIG5vdCB1c2VkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+Mi4xLjEuMy4gIE11bHRpcGxlIG1hbmFnZXJzIGhhbmRsaW5nIHRoZSBjYW5kaWRh
dGUgZGF0YXN0b3JlIGluIGEgc2VtaS08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij4yLjEuMS4zLiAgTXVsdGlwbGUgbWFuYWdlcnMgaGFuZGxpbmcgdGhlIGNhbmRpZGF0ZSBk
YXRhc3RvcmUgaW4gYSBzZW1pLTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgY29vcmRpbmF0ZWQgd29yayBtb2Rl
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgIGNvb3JkaW5hdGVk
IHdvcmsgbW9kZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
TXVsdGlwbGUgbWFuYWdlcnMgYXJlIGhhbmRsaW5nIHRoZSBzYW1lIE5FVENPTkYgYWdlbnQg
c2ltdWx0YW5lb3VzbHkuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTXVs
dGlwbGUgbWFuYWdlcnMgYXJlIGhhbmRsaW5nIHRoZSBzYW1lIE5FVENPTkYgYWdlbnQgc2lt
dWx0YW5lb3VzbHkuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBhZ2VudCBpcyBoYW5kbGVkIHZpYSB0aGUgY2FuZGlk
YXRlIGRhdGFzdG9yZS4gIEVhY2ggbWFuYWdlciBoYXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICBUaGUgYWdlbnQgaXMgaGFuZGxlZCB2aWEgdGhlIGNhbmRpZGF0ZSBk
YXRhc3RvcmUuICBFYWNoIG1hbmFnZXIgaGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGhpcyBvciBoZXIgb3duIHRhc2sg
d2hpY2ggbWlnaHQgaW52b2x2ZSB0aGUgbW9kaWZpY2F0aW9uIG9mPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgaGlzIG9yIGhlciBvd24gdGFzayB3aGljaCBtaWdodCBp
bnZvbHZlIHRoZSBtb2RpZmljYXRpb24gb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3ZlcmxhcHBpbmcgc2VjdGlvbnMg
b2YgdGhlIGRhdGFzdG9yZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBv
dmVybGFwcGluZyBzZWN0aW9ucyBvZiB0aGUgZGF0YXN0b3JlLjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQWZ0ZXIgY29sbGVjdGluZyBhbmQgYW5hbHl6
aW5nIGlucHV0IGFuZCBwcmVwYXJpbmcgdGhlIE5FVENPTkY8L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij4gICBBZnRlciBjb2xsZWN0aW5nIGFuZCBhbmFseXppbmcgaW5wdXQg
YW5kIHByZXBhcmluZyB0aGUgTkVUQ09ORjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcGVyYXRpb25zIG9mZi1saW5lLCB0
aGUgbWFuYWdlciBsb2NrcyB0aGUgYXJlYXMgdGhhdCBhcmUgaW1wb3J0YW50PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3BlcmF0aW9ucyBvZmYtbGluZSwgdGhlIG1h
bmFnZXIgbG9ja3MgdGhlIGFyZWFzIHRoYXQgYXJlIGltcG9ydGFudDwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmb3IgaGlz
IHRhc2sgdXNpbmcgb25lIHNpbmdsZSAmbHQ7cGFydGlhbC1sb2NrJmd0OyBvcGVyYXRpb24g
aW4gYm90aCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmb3IgaGlz
IHRhc2sgdXNpbmcgb25lIHNpbmdsZSAmbHQ7cGFydGlhbC1sb2NrJmd0OyBvcGVyYXRpb24g
aW4gYm90aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgY2FuZGlkYXRlIGFuZCB0aGUgcnVubmluZyBkYXRhc3RvcmUu
ICBIZSBleGVjdXRlcyBhIG51bWJlciBvZiAmbHQ7ZWRpdC08L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij4gICBjYW5kaWRhdGUgYW5kIHRoZSBydW5uaW5nIGRhdGFzdG9yZS4g
IEhlIGV4ZWN1dGVzIGEgbnVtYmVyIG9mICZsdDtlZGl0LTwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb25maWcmZ3Q7IG9w
ZXJhdGlvbnMgdG8gbW9kaWZ5IHRoZSBjb25maWd1cmF0aW9uLCB0aGVuIHJlbGVhc2VzIHRo
ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbmZpZyZndDsgb3BlcmF0
aW9ucyB0byBtb2RpZnkgdGhlIGNvbmZpZ3VyYXRpb24sIHRoZW4gcmVsZWFzZXMgdGhlPC90
ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZD48YSBuYW1lPSJkaWZmMDAxMiI+PC9hPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg
cGFydGlhbC1sb2NrLiAgVGhlIGxvY2sgc2hvdWxkIGJlIGhlbGQgZm9yIDxzcGFuIGNsYXNz
PSJkZWxldGUiPm9ubHkgYSBzaG9ydDwvc3Bhbj4gdGltZSA8c3BhbiBjbGFzcz0iZGVsZXRl
Ij4oc2Vjb25kczwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg
cGFydGlhbC1sb2NrLiAgVGhlIGxvY2sgc2hvdWxkIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm9u
bHk8L3NwYW4+IGJlIGhlbGQgZm9yIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoZSBzaG9ydGVz
dCBwb3NzaWJsZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICByYXRoZXIgdGhlbiBtaW51dGVzKS48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGltZSA8c3BhbiBjbGFzcz0iaW5zZXJ0
Ij4oZS5nLiBzZWNvbmRzPC9zcGFuPiByYXRoZXIgdGhlbiBtaW51dGVzKS48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE9wZXJhdG9ycyBjb29yZGluYXRl
IHdpdGggZWFjaCBvdGhlci4gIFdoZW4gYWxsIG9mIHRoZW0gZmluaXNoIHRoZWlyPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgT3BlcmF0b3JzIGNvb3JkaW5hdGUgd2l0
aCBlYWNoIG90aGVyLiAgV2hlbiBhbGwgb2YgdGhlbSBmaW5pc2ggdGhlaXI8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGFz
a3Mgb25lIG9mIHRoZW0gb3JkZXJzIGNvbW1pdC4gIElmIGFueSBvZiB0aGUgb3BlcmF0b3Jz
IGFyZSBzdGlsbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRhc2tzIG9u
ZSBvZiB0aGVtIG9yZGVycyBjb21taXQuICBJZiBhbnkgb2YgdGhlIG9wZXJhdG9ycyBhcmUg
c3RpbGw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+ICAgd29ya2luZywgYW5kIGhvbGRzIGEgbG9jaywgdGhlIGNvbW1pdCB3aWxs
IGZhaWwsIGFuZCB3aWxsIG5lZWQgdG8gYmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICB3b3JraW5nLCBhbmQgaG9sZHMgYSBsb2NrLCB0aGUgY29tbWl0IHdpbGwgZmFp
bCwgYW5kIHdpbGwgbmVlZCB0byBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZXBlYXRlZCBhZnRlciBhbGwgbWFuYWdl
cnMgZmluaXNoLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlcGVhdGVk
IGFmdGVyIGFsbCBtYW5hZ2VycyBmaW5pc2guPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICBXYXJuaW5nOiBXaGVuIG11bHRpcGxlIG1hbmFnZXJzIHVzZSB0
aGUgY2FuZGlkYXRlIGNvbmZpZ3VyYXRpb24gaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBXYXJuaW5nOiBXaGVuIG11bHRpcGxlIG1hbmFnZXJzIHVzZSB0aGUgY2Fu
ZGlkYXRlIGNvbmZpZ3VyYXRpb24gaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249
InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcGFyYWxsZWwsIHRoZXJlIGlzIGEgcmlz
ayB0aGF0IHRoZSBpbnRlcmFjdGlvbiBvZiBhY2Nlc3MgY29udHJvbDwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBhcmFsbGVsLCB0aGVyZSBpcyBhIHJpc2sgdGhhdCB0
aGUgaW50ZXJhY3Rpb24gb2YgYWNjZXNzIGNvbnRyb2w8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKHdoaWNoIGlzIHN0aWxs
IGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGF0IHRoZSB0aW1lIG9mIHRoaXMgd3JpdGluZyk8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAod2hpY2ggaXMgc3RpbGwgaW1w
bGVtZW50YXRpb24gc3BlY2lmaWMgYXQgdGhlIHRpbWUgb2YgdGhpcyB3cml0aW5nKTwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g
ICBhbmQgdGhlIGNvbW1pdCBvcGVyYXRpb24gbWlnaHQgcmVzdWx0IGluIGEgZGVhZC1sb2Nr
LCBhcyBpbGx1c3RyYXRlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFu
ZCB0aGUgY29tbWl0IG9wZXJhdGlvbiBtaWdodCByZXN1bHQgaW4gYSBkZWFkLWxvY2ssIGFz
IGlsbHVzdHJhdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp
bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRo
PjxhIG5hbWU9InBhcnQtbDUiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxs
PjxlbT4gcGFnZSA4LCBsaW5lIDE1PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5h
bWU9InBhcnQtcjUiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4g
cGFnZSA5LCBsaW5lIDE3PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
ICAgVGhlICZsdDtwYXJ0aWFsLWxvY2smZ3Q7IG9wZXJhdGlvbiBpcyBkZXNpZ25lZCBmb3Ig
c2ltcGxpY2l0eSwgc28gd2hlbiBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
ICAgVGhlICZsdDtwYXJ0aWFsLWxvY2smZ3Q7IG9wZXJhdGlvbiBpcyBkZXNpZ25lZCBmb3Ig
c2ltcGxpY2l0eSwgc28gd2hlbiBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBhcnRpYWwgbG9jayBpcyBleGVjdXRlZCB5
b3UgZ2V0IHdoYXQgeW91IGFza2VkIGZvcjogYSBzZXQgb2Ygbm9kZXM8L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwYXJ0aWFsIGxvY2sgaXMgZXhlY3V0ZWQgeW91IGdl
dCB3aGF0IHlvdSBhc2tlZCBmb3I6IGEgc2V0IG9mIG5vZGVzPC90ZD48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoYXQgYXJlIGxv
Y2tlZCBmb3Igd3JpdGluZy4gIEFzIGEgY29uc2VxdWVuY2UgdXNlcnMgbXVzdCBvYnNlcnZl
IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoYXQgYXJlIGxvY2tl
ZCBmb3Igd3JpdGluZy4gIEFzIGEgY29uc2VxdWVuY2UgdXNlcnMgbXVzdCBvYnNlcnZlIHRo
ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICBmb2xsb3dpbmc6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
Zm9sbG93aW5nOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
byAgTG9ja2luZyBkb2VzIG5vdCBhZmZlY3QgcmVhZCBvcGVyYXRpb25zLjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIExvY2tpbmcgZG9lcyBub3QgYWZmZWN0IHJl
YWQgb3BlcmF0aW9ucy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PiAgIG8gIElmIHBhcnQgb2YgYSBkYXRhc3RvcmUgaXMgbG9ja2VkLCB0aGlzIGhhcyBubyBl
ZmZlY3Qgb24gYW55PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgSWYg
cGFydCBvZiBhIGRhdGFzdG9yZSBpcyBsb2NrZWQsIHRoaXMgaGFzIG5vIGVmZmVjdCBvbiBh
bnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+ICAgICAgdW5sb2NrZWQgcGFydHMgb2YgdGhlIGRhdGFzdG9yZS4gIElmIHRoaXMg
aXMgYSBwcm9ibGVtIChlLmcuLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
ICAgIHVubG9ja2VkIHBhcnRzIG9mIHRoZSBkYXRhc3RvcmUuICBJZiB0aGlzIGlzIGEgcHJv
YmxlbSAoZS5nLiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgICAgY2hhbmdlcyBkZXBlbmQgb24gZGF0YSB2YWx1ZXMgb3Ig
bm9kZXMgb3V0c2lkZSB0aGUgcHJvdGVjdGVkIHBhcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICAgICBjaGFuZ2VzIGRlcGVuZCBvbiBkYXRhIHZhbHVlcyBvciBub2Rl
cyBvdXRzaWRlIHRoZSBwcm90ZWN0ZWQgcGFydDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTMi
PjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIG9mIHRoZSBkYXRhc3RvcmUpLCB0
aGVzZSBub2RlcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5zaG91bGQ8L3NwYW4+IGJlIGluY2x1
ZGVkIGluIHRoZSBwcm90ZWN0ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+
ICAgICAgb2YgdGhlIGRhdGFzdG9yZSksIHRoZXNlIG5vZGVzIDxzcGFuIGNsYXNzPSJpbnNl
cnQiPlNIT1VMRDwvc3Bhbj4gYmUgaW5jbHVkZWQgaW4gdGhlIHByb3RlY3RlZDwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg
ICBhcmVhIG9mIHRoZSBsb2NrLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg
ICAgIGFyZWEgb2YgdGhlIGxvY2suPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICBvICBDb25maWd1cmF0aW9uIGRhdGEgY2FuIGJlIGVkaXRlZCBib3RoIGlu
c2lkZSBhbmQgb3V0c2lkZSB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g
ICBvICBDb25maWd1cmF0aW9uIGRhdGEgY2FuIGJlIGVkaXRlZCBib3RoIGluc2lkZSBhbmQg
b3V0c2lkZSB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgICAgcHJvdGVjdGVkIGFyZWEgb2YgYSBsb2NrLiAgSXQgaXMg
dGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBORVRDT05GPC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+ICAgICAgcHJvdGVjdGVkIGFyZWEgb2YgYSBsb2NrLiAgSXQgaXMgdGhl
IHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBORVRDT05GPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGNsaWVudCBhcHBsaWNh
dGlvbiB0byBsb2NrIGFsbCByZWxldmFudCBwYXJ0cyBvZiBhIGRhdGFzdG9yZSB0aGF0PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgY2xpZW50IGFwcGxpY2F0aW9u
IHRvIGxvY2sgYWxsIHJlbGV2YW50IHBhcnRzIG9mIGEgZGF0YXN0b3JlIHRoYXQ8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
ICAgYXJlIGNydWNpYWwgZm9yIGEgc3BlY2lmaWMgbWFuYWdlbWVudCBhY3Rpb24uPC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgYXJlIGNydWNpYWwgZm9yIGEgc3Bl
Y2lmaWMgbWFuYWdlbWVudCBhY3Rpb24uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249
InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBOb3RlOiBUaGUgJmx0O3BhcnRpYWwtbG9jayZndDsgb3BlcmF0aW9u
IGRvZXMgbm90IG1vZGlmeSB0aGUgZ2xvYmFsICZsdDtsb2NrJmd0OzwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIE5vdGU6IFRoZSAmbHQ7cGFydGlhbC1sb2NrJmd0OyBv
cGVyYXRpb24gZG9lcyBub3QgbW9kaWZ5IHRoZSBnbG9iYWwgJmx0O2xvY2smZ3Q7PC90ZD48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
IG9wZXJhdGlvbiBkZWZpbmVkIGluIHRoZSBiYXNlIE5FVENPTkYgUHJvdG9jb2wgW05FVENP
TkZdLiAgSWYgcGFydCBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9w
ZXJhdGlvbiBkZWZpbmVkIGluIHRoZSBiYXNlIE5FVENPTkYgUHJvdG9jb2wgW05FVENPTkZd
LiAgSWYgcGFydCBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij4gICBhIGRhdGFzdG9yZSBpcyBhbHJlYWR5IGxvY2tlZCBieSAm
bHQ7cGFydGlhbC1sb2NrJmd0OywgdGhlbiBhIGdsb2JhbCBsb2NrPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgYSBkYXRhc3RvcmUgaXMgYWxyZWFkeSBsb2NrZWQgYnkg
Jmx0O3BhcnRpYWwtbG9jayZndDssIHRoZW4gYSBnbG9iYWwgbG9jazwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy
IGJnY29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWw2Ij48c21hbGw+
c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTAsIGxpbmUgNDY8L2Vt
PjwvYT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yNiI+PHNtYWxsPnNraXBw
aW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDEyLCBsaW5lIDM1PC9lbT48L2E+
PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbm90IGFuIEluc3RhbmNlIElkZW50
aWZpZXIsIHRoZSAmbHQ7ZXJyb3ItdGFnJmd0OyBpcyAnaW52YWxpZC12YWx1ZScsIHRoZTwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG5vdCBhbiBJbnN0YW5jZSBJZGVu
dGlmaWVyLCB0aGUgJmx0O2Vycm9yLXRhZyZndDsgaXMgJ2ludmFsaWQtdmFsdWUnLCB0aGU8
L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8
dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm
dCI+ICAgJmx0O2Vycm9yLWFwcC10YWcmZ3Q7IGlzICdpbnZhbGlkLWxvY2stc3BlY2lmaWNh
dGlvbicuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgJmx0O2Vycm9yLWFw
cC10YWcmZ3Q7IGlzICdpbnZhbGlkLWxvY2stc3BlY2lmaWNhdGlvbicuPC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJZiBhY2Nlc3MgY29udHJvbCBkZW5p
ZXMgdGhlIHBhcnRpYWwgbG9jaywgdGhlICZsdDtlcnJvci10YWcmZ3Q7IGlzPC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgYWNjZXNzIGNvbnRyb2wgZGVuaWVzIHRo
ZSBwYXJ0aWFsIGxvY2ssIHRoZSAmbHQ7ZXJyb3ItdGFnJmd0OyBpczwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAnYWNjZXNz
LWRlbmllZCcuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgJ2FjY2Vzcy1k
ZW5pZWQnLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi40LjEu
Mi4gIERlYWRsb2NrIEF2b2lkYW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PjIuNC4xLjIuICBEZWFkbG9jayBBdm9pZGFuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIEFzIHdpdGggbW9zdCBsb2NraW5nIHN5c3RlbXMsIGl0IGlz
IHBvc3NpYmxlIHRoYXQgdHdvIG1hbmFnZW1lbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij4gICBBcyB3aXRoIG1vc3QgbG9ja2luZyBzeXN0ZW1zLCBpdCBpcyBwb3NzaWJs
ZSB0aGF0IHR3byBtYW5hZ2VtZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHNlc3Npb25zIHRyeWluZyB0byBsb2NrIGRp
ZmZlcmVudCBwYXJ0cyBvZiB0aGUgY29uZmlndXJhdGlvbiBjb3VsZDwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlc3Npb25zIHRyeWluZyB0byBsb2NrIGRpZmZlcmVu
dCBwYXJ0cyBvZiB0aGUgY29uZmlndXJhdGlvbiBjb3VsZDwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlm
ZjAwMTQiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGJlY29tZSBkZWFkLWxvY2tl
ZC4gIFRvIGF2b2lkIHRoaXMgc2l0dWF0aW9uLCBjbGllbnRzIDxzcGFuIGNsYXNzPSJkZWxl
dGUiPnNob3VsZDwvc3Bhbj4gbG9jazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr
Ij4gICBiZWNvbWUgZGVhZC1sb2NrZWQuICBUbyBhdm9pZCB0aGlzIHNpdHVhdGlvbiwgY2xp
ZW50cyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TSE9VTEQ8L3NwYW4+IGxvY2s8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZXZl
cnl0aGluZyB0aGV5IG5lZWQgaW4gb25lIG9wZXJhdGlvbi4gIElmIGxvY2tpbmcgZmFpbHMs
IHRoZSBjbGllbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBldmVyeXRo
aW5nIHRoZXkgbmVlZCBpbiBvbmUgb3BlcmF0aW9uLiAgSWYgbG9ja2luZyBmYWlscywgdGhl
IGNsaWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTUiPjwvYT48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs
YmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPnNob3VsZDwvc3Bhbj4gYmFjay1vZmYs
IHJlbGVhc2UgYW55IHByZXZpb3VzbHkgYWNxdWlyZWQgbG9ja3MsIGFuZCByZXRyeSB0aGU8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2Vy
dCI+TVVTVDwvc3Bhbj4gYmFjay1vZmYsIHJlbGVhc2UgYW55IHByZXZpb3VzbHkgYWNxdWly
ZWQgbG9ja3MsIGFuZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TSE9VTEQ8L3NwYW4+PC90ZD48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+
ICAgcHJvY2VkdXJlIGFmdGVyIHdhaXRpbmcgc29tZSByYW5kb21pemVkIHRpbWUgaW50ZXJ2
YWwuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHJldHJ5IHRoZSBwcm9j
ZWR1cmUgYWZ0ZXIgd2FpdGluZyBzb21lIHJhbmRvbWl6ZWQgdGltZSBpbnRlcnZhbC48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuNC4yLiAgJmx0O3BhcnRp
YWwtdW5sb2NrJmd0OzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjIuNC4yLiAg
Jmx0O3BhcnRpYWwtdW5sb2NrJmd0OzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+ICAgVGhlIG9wZXJhdGlvbiB1bmxvY2tzIHRoZSBwYXJ0cyBvZiB0aGUgZGF0
YXN0b3JlcyB0aGF0IHdlcmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBU
aGUgb3BlcmF0aW9uIHVubG9ja3MgdGhlIHBhcnRzIG9mIHRoZSBkYXRhc3RvcmVzIHRoYXQg
d2VyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICBwcmV2aW91c2x5IGxvY2tlZCB1c2luZyAmbHQ7cGFydGlhbC1sb2NrJmd0
OyBkdXJpbmcgdGhlIHNhbWUgc2Vzc2lvbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICBwcmV2aW91c2x5IGxvY2tlZCB1c2luZyAmbHQ7cGFydGlhbC1sb2NrJmd0OyBk
dXJpbmcgdGhlIHNhbWUgc2Vzc2lvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249
InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIFBhcmFtZXRlcnM6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+ICAgUGFyYW1ldGVyczo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgIGxvY2staWQ6ICBJZGVudGl0eSBvZiB0aGUgbG9jayB0byBiZSB1bmxvY2tlZC4g
IFRoaXMgbG9jay1pZCBNVVNUPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
bG9jay1pZDogIElkZW50aXR5IG9mIHRoZSBsb2NrIHRvIGJlIHVubG9ja2VkLiAgVGhpcyBs
b2NrLWlkIE1VU1Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgICAgIGhhdmUgYmVlbiByZWNlaXZlZCBhcyBhIHJlc3BvbnNl
IHRvIGEgbG9jayByZXF1ZXN0IGJ5IHRoZSBtYW5hZ2VyPC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+ICAgICAgIGhhdmUgYmVlbiByZWNlaXZlZCBhcyBhIHJlc3BvbnNlIHRv
IGEgbG9jayByZXF1ZXN0IGJ5IHRoZSBtYW5hZ2VyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0i
Z3JheSI+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDciPjxzbWFsbD5za2lwcGluZyB0
byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxMywgbGluZSAyOTwvZW0+PC9hPjwvdGg+
PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI3Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hh
bmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTUsIGxpbmUgMTk8L2VtPjwvYT48L3RoPjx0ZD48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB1c2VycydzIHNlc3Npb25zLjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHVzZXJzJ3Mgc2Vzc2lvbnMuPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+
PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUaGUgTkVUQ09ORiBzZXJ2
ZXIgbWF5IGxvZyBwYXJ0aWFsIGxvY2sgcmVxdWVzdHMgaW4gYW4gYXVkaXQ8L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBUaGUgTkVUQ09ORiBzZXJ2ZXIgbWF5IGxv
ZyBwYXJ0aWFsIGxvY2sgcmVxdWVzdHMgaW4gYW4gYXVkaXQ8L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdHJhaWwuPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgdHJhaWwuPC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBIGxvY2sgdGhhdCBpcyBodW5nIGZv
ciBzb21lIHJlYXNvbiAoZS5nLiwgYSBicm9rZW4gVENQIGNvbm5lY3Rpb248L3RkPjx0ZD4g
PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBIGxvY2sgdGhhdCBpcyBodW5nIGZvciBzb21l
IHJlYXNvbiAoZS5nLiwgYSBicm9rZW4gVENQIGNvbm5lY3Rpb248L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhhdCB0aGUg
c2VydmVyIGhhcyBub3QgeWV0IHJlY29nbmlzZWQpIGNhbiBiZSByZWxlYXNlZCB1c2luZyBh
bm90aGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhhdCB0aGUgc2Vy
dmVyIGhhcyBub3QgeWV0IHJlY29nbmlzZWQpIGNhbiBiZSByZWxlYXNlZCB1c2luZyBhbm90
aGVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPiAgIE5FVENPTkYgc2Vzc2lvbiBieSBleHBsaWNpdGx5IGtpbGxpbmcgdGhlIHNl
c3Npb24gb3duaW5nIHRoYXQgbG9jazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PiAgIE5FVENPTkYgc2Vzc2lvbiBieSBleHBsaWNpdGx5IGtpbGxpbmcgdGhlIHNlc3Npb24g
b3duaW5nIHRoYXQgbG9jazwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1c2luZyB0aGUgJmx0O2tpbGwtc2Vzc2lvbiZndDsg
b3BlcmF0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVzaW5nIHRo
ZSAmbHQ7a2lsbC1zZXNzaW9uJmd0OyBvcGVyYXRpb24uPC90ZD48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTYiPjwvYT48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk
IGNsYXNzPSJsYmxvY2siPiAgIFBhcnRpYWwgbG9ja2luZyBpcyA8c3BhbiBjbGFzcz0iZGVs
ZXRlIj5OT1Q8L3NwYW4+IGFuIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtOyBpdCBTSE9VTEQg
Tk9UIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFBhcnRpYWwgbG9j
a2luZyBpcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5ub3Q8L3NwYW4+IGFuIGF1dGhvcml6YXRp
b24gbWVjaGFuaXNtOyBpdCBTSE9VTEQgTk9UIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVzZWQgdG8gcHJvdmlkZSBz
ZWN1cml0eSBvciBhY2Nlc3MgY29udHJvbC4gIFBhcnRpYWwgbG9ja2luZyBTSE9VTEQ8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB1c2VkIHRvIHByb3ZpZGUgc2VjdXJp
dHkgb3IgYWNjZXNzIGNvbnRyb2wuICBQYXJ0aWFsIGxvY2tpbmcgU0hPVUxEPC90ZD48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9u
bHkgYmUgdXNlZCBhcyBhIG1lY2hhbmlzbSBmb3IgcHJvdmlkaW5nIGNvbnNpc3RlbmN5IHdo
ZW4gbXVsdGlwbGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvbmx5IGJl
IHVzZWQgYXMgYSBtZWNoYW5pc20gZm9yIHByb3ZpZGluZyBjb25zaXN0ZW5jeSB3aGVuIG11
bHRpcGxlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K
ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh
c3M9ImxlZnQiPiAgIG1hbmFnZXJzIGFyZSB0cnlpbmcgdG8gY29uZmlndXJlIHRoZSBub2Rl
LiAgSXQgaXMgdml0YWwgdGhhdCB1c2VyczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPiAgIG1hbmFnZXJzIGFyZSB0cnlpbmcgdG8gY29uZmlndXJlIHRoZSBub2RlLiAgSXQg
aXMgdml0YWwgdGhhdCB1c2VyczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBlYXNpbHkgdW5kZXJzdGFuZCB0aGUgZXhhY3Qg
c2NvcGUgb2YgYSBsb2NrLiAgVGhpcyBpcyB3aHkgdGhlIHNjb3BlPC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+ICAgZWFzaWx5IHVuZGVyc3RhbmQgdGhlIGV4YWN0IHNjb3Bl
IG9mIGEgbG9jay4gIFRoaXMgaXMgd2h5IHRoZSBzY29wZTwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpcyBkZXRlcm1pbmVk
IHdoZW4gZ3JhbnRpbmcgYSBsb2NrIGFuZCBpcyBub3QgbW9kaWZpZWQgdGhlcmVhZnRlci48
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpcyBkZXRlcm1pbmVkIHdoZW4g
Z3JhbnRpbmcgYSBsb2NrIGFuZCBpcyBub3QgbW9kaWZpZWQgdGhlcmVhZnRlci48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuICBJQU5BIENvbnNpZGVyYXRp
b25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4gIElBTkEgQ29uc2lkZXJh
dGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMg
ZG9jdW1lbnQgcmVnaXN0ZXJzIHR3byBVUklzIGZvciB0aGUgTkVUQ09ORiBYTUwgbmFtZXNw
YWNlIGluIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9j
dW1lbnQgcmVnaXN0ZXJzIHR3byBVUklzIGZvciB0aGUgTkVUQ09ORiBYTUwgbmFtZXNwYWNl
IGluIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICBJRVRGIFhNTCByZWdpc3RyeSBbUkZDMzY4OF0uICBOb3RlIHRoYXQg
dGhlIGNhcGFiaWxpdHkgVVJOIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+
ICAgSUVURiBYTUwgcmVnaXN0cnkgW1JGQzM2ODhdLiAgTm90ZSB0aGF0IHRoZSBjYXBhYmls
aXR5IFVSTiBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiPjx0ZD48L3RkPjx0aD48
YSBuYW1lPSJwYXJ0LWw4Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48
ZW0+IHBhZ2UgMjcsIGxpbmUgNzwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1l
PSJwYXJ0LXI4Ij48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBh
Z2UgMjgsIGxpbmUgNzwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg
ICZsdDtuYzpycGMgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpwYXJ0
aWFsLWxvY2s6MS4wIjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICZsdDtu
YzpycGMgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpwYXJ0aWFsLWxv
Y2s6MS4wIjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij4gICAgICAgeG1sbnM6bmM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0
Y29uZjpiYXNlOjEuMCI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg
eG1sbnM6bmM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
ICAgICAgIG1lc3NhZ2UtaWQ9IjEwNSImZ3Q7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy
aWdodCI+ICAgICAgIG1lc3NhZ2UtaWQ9IjEwNSImZ3Q7PC90ZD48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgJmx0O3BhcnRpYWwt
dW5sb2NrJmd0OzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgJmx0O3Bh
cnRpYWwtdW5sb2NrJmd0OzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgJmx0O2xvY2staWQmZ3Q7MSZsdDsvbG9jay1p
ZCZndDs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgJmx0O2xvY2st
aWQmZ3Q7MSZsdDsvbG9jay1pZCZndDs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249
InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i
dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAmbHQ7L3BhcnRpYWwtdW5sb2NrJmd0
OzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgJmx0Oy9wYXJ0aWFsLXVu
bG9jayZndDs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+ICAgJmx0Oy9uYzpycGMmZ3Q7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgJmx0Oy9uYzpycGMmZ3Q7PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij44LiAgQXBwZW5kaXggRCAgLSAgQ2hhbmdlIExvZzwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjguICBBcHBlbmRpeCBEICAtICBDaGFuZ2UgTG9nPC90
ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi
PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlm
ZjAwMTciPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjguMS4gIDA8c3BhbiBjbGFzcz0i
ZGVsZXRlIj43LTA4PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj44
LjEuICAwPHNwYW4gY2xhc3M9Imluc2VydCI+OC0wOTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENsYXJpZmljYXRpb25zPC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ2xhcmlmaWNhdGlvbnM8L3RkPjx0ZCBjbGFzcz0i
bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv
dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxOCI+PC9hPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48dGQgY2xhc3M9ImxibG9jayI+OC4yLiAgMDYtMDc8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJibG9jayI+OC4yLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MDctMDg8L3NwYW4+PC90
ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j
ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl
cnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0
ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw
YW4gY2xhc3M9Imluc2VydCI+ICAgQ2xhcmlmaWNhdGlvbnM8L3NwYW4+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPjwvc3Bh
bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i
bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9
Imluc2VydCI+OC4zLjwvc3Bhbj4gIDA2LTA3PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij4gICBDaGFuZ2VkIFhTRCBhbmQgWUFORyB0byBhbGxvdyBhZGRpdGlv
bmFsIHByb3ByaWV0YXJ5IGRhdGFzdG9yZXMgdG8gYmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij4gICBDaGFuZ2VkIFhTRCBhbmQgWUFORyB0byBhbGxvdyBhZGRpdGlvbmFs
IHByb3ByaWV0YXJ5IGRhdGFzdG9yZXMgdG8gYmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbG9ja2VkLjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxvY2tlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAxOSI+PC9hPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg
Y2xhc3M9ImxibG9jayI+OC48c3BhbiBjbGFzcz0iZGVsZXRlIj4zPC9zcGFuPi4gIDA1LTA2
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjguPHNwYW4gY2xhc3M9Imluc2Vy
dCI+NDwvc3Bhbj4uICAwNS0wNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0
Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg
ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i
bGVmdCI+ICAgQWRkZWQgdXNhZ2UgZXhhbXBsZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i
cmlnaHQiPiAgIEFkZGVkIHVzYWdlIGV4YW1wbGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs
YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
dGQgY2xhc3M9ImxlZnQiPiAgIENsYXJpZmllZCBlcnJvciBtZXNzYWdlczwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENsYXJpZmllZCBlcnJvciBtZXNzYWdlczwvdGQ+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ2xhcmlmaWVkIGludGVy
YWN0aW9uIHdpdGggZWRpdC1jb25maWcgY29udGludWUtb24tZXJyb3I8L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDbGFyaWZpZWQgaW50ZXJhY3Rpb24gd2l0aCBlZGl0
LWNvbmZpZyBjb250aW51ZS1vbi1lcnJvcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9
InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGVmdCI+ICAgSW1wcm92ZWQgWUFORzogaW5kZW50YXRpb24sIGNhbm9uaWNhbCBv
cmRlciwgY29udGFjdCBpbmZvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg
SW1wcm92ZWQgWUFORzogaW5kZW50YXRpb24sIGNhbm9uaWNhbCBvcmRlciwgY29udGFjdCBp
bmZvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBZGRlZCB1
c2FnZSBleGFtcGxlIGluIGFwcGVuZGl4IEM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICBBZGRlZCB1c2FnZSBleGFtcGxlIGluIGFwcGVuZGl4IEM8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+
IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu
PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249
InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFN5bmNocm9uaXplZCBZQU5HIGFuZCBY
U0Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTeW5jaHJvbml6ZWQgWUFO
RyBhbmQgWFNEPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+
PGEgbmFtZT0iZGlmZjAwMjAiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9
ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjguPHNwYW4g
Y2xhc3M9ImRlbGV0ZSI+NDwvc3Bhbj4uICAwNC0wNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmJsb2NrIj44LjxzcGFuIGNsYXNzPSJpbnNlcnQiPjU8L3NwYW4+LiAgMDQtMDU8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIExhbmd1YWdlIGFuZCBl
ZGl0b3JpYWwgdXBkYXRlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIExh
bmd1YWdlIGFuZCBlZGl0b3JpYWwgdXBkYXRlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+ICAgYWxsIGFwcC10YWdzIGFyZSB3aXRoIGRhc2hlcyB3aXRob3V0
IHNwYWNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFsbCBhcHAtdGFn
cyBhcmUgd2l0aCBkYXNoZXMgd2l0aG91dCBzcGFjZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFkZGVkIHVzYWdlIHNjZW5hcmlvczwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFkZGVkIHVzYWdlIHNjZW5hcmlvczwvdGQ+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg
Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ2hhbmdlZCBlbmNvZGluZzwv
dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENoYW5nZWQgZW5jb2Rpbmc8L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENsYXJpZmllZCBkZWZp
bml0aW9ucywgc2VwYXJhdGVkIHNjb3BlIG9mIGxvY2sgYW5kIHByb3RlY3RlZCBhcmVhPC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ2xhcmlmaWVkIGRlZmluaXRpb25z
LCBzZXBhcmF0ZWQgc2NvcGUgb2YgbG9jayBhbmQgcHJvdGVjdGVkIGFyZWE8L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyMSI+
PC9hPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+OC48c3BhbiBjbGFzcz0iZGVsZXRlIj41PC9z
cGFuPi4gIDAzLTA0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjguPHNwYW4g
Y2xhc3M9Imluc2VydCI+Njwvc3Bhbj4uICAwMy0wNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgTWlub3IgY2xhcmlmaWNhdGlvbnM8L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBNaW5vciBjbGFyaWZpY2F0aW9uczwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQWRkZWQgbGlzdCBvZiBsb2NrZWQt
bm9kZXMgdG8gdGhlIG91dHB1dCBvZiBwYXJ0aWFsLWxvY2suPC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+ICAgQWRkZWQgbGlzdCBvZiBsb2NrZWQtbm9kZXMgdG8gdGhlIG91
dHB1dCBvZiBwYXJ0aWFsLWxvY2suPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0
b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln
aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg
ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz
PSJsZWZ0Ij4gICBBZGRlZCAmbHQ7dGFyZ2V0Jmd0OyB3cmFwcGVyIGFyb3VuZCBkYXRhc3Rv
cmUgbmFtZXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQWRkZWQgJmx0
O3RhcmdldCZndDsgd3JhcHBlciBhcm91bmQgZGF0YXN0b3JlIG5hbWVzLjwvdGQ+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0
ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQWxsb3dlZCBhdG9taWMvb25lIG9w
ZXJhdGlvbiBsb2NraW5nIG9mIGRhdGFzdG9yZSBwYXJ0cyBpbiBtdWx0aXBsZTwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFsbG93ZWQgYXRvbWljL29uZSBvcGVyYXRp
b24gbG9ja2luZyBvZiBkYXRhc3RvcmUgcGFydHMgaW4gbXVsdGlwbGU8L3RkPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz
PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGF0YXN0
b3Jlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkYXRhc3RvcmVzLjwv
dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0
cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0
Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW1wcm92ZWQgRW5n
bGlzaCAoaG9wZWZ1bGx5KTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElt
cHJvdmVkIEVuZ2xpc2ggKGhvcGVmdWxseSk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg
Y2xhc3M9ImxlZnQiPiAgIFJlbW92ZWQgdGhlICZsdDtkYXRhJmd0OyBlbGVtZW50IGZyb20g
cnBjLXJlcGx5IGZvbGxvd2luZyB0aGUgdGV4dCBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgIFJlbW92ZWQgdGhlICZsdDtkYXRhJmd0OyBlbGVtZW50IGZyb20gcnBj
LXJlcGx5IGZvbGxvd2luZyB0aGUgdGV4dCBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZmM0NzQxLjwvdGQ+PHRkPiA8
L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJmYzQ3NDEuPC90ZD48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjIiPjwvYT48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk
IGNsYXNzPSJsYmxvY2siPjguPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Njwvc3Bhbj4uICAwMi0w
MzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj44LjxzcGFuIGNsYXNzPSJpbnNl
cnQiPjc8L3NwYW4+LiAgMDItMDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo
dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9
ImxlZnQiPiAgIE1pbm9yIGNsYXJpZmljYXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgTWlub3IgY2xhcmlmaWNhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v
IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk
IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv
dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNhbWUgZGVzY3JpcHRpb25zIGluIFhTRCBhbmQgWUFO
Ry48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTYW1lIGRlc2NyaXB0aW9u
cyBpbiBYU0QgYW5kIFlBTkcuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMjMiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48
dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si
PjguPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Nzwvc3Bhbj4uICAwMS0wMjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmJsb2NrIj44LjxzcGFuIGNsYXNzPSJpbnNlcnQiPjg8L3NwYW4+LiAg
MDEtMDI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1hZGUg
WFNEIG5vcm1hdGl2ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE1hZGUg
WFNEIG5vcm1hdGl2ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk
PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+
PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk
Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+
PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+
ICAgQ2xhcmlmaWVkIHRoYXQgbm8gc3BlY2lmaWMgYWNjZXNzIGNvbnRyb2wgaXMgYXNzdW1l
ZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDbGFyaWZpZWQgdGhhdCBu
byBzcGVjaWZpYyBhY2Nlc3MgY29udHJvbCBpcyBhc3N1bWVkLjwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90
ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv
cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w
Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQ2xhcmlmaWVkIHRoYXQgbm9uLWV4aXN0aW5n
IG5vZGVzIGFyZSBOT1QgY292ZXJlZCBieSB0aGUgbG9jaywgZXZlbjwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIENsYXJpZmllZCB0aGF0IG5vbi1leGlzdGluZyBub2Rl
cyBhcmUgTk9UIGNvdmVyZWQgYnkgdGhlIGxvY2ssIGV2ZW48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaWYgdGhleSB3aGVy
ZSBleGlzdGluZyBhbmQgY292ZXJlZCBieSB0aGUgbG9jayB3aGVuIGl0IHdhcyBvcmlnaW5h
bGx5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaWYgdGhleSB3aGVyZSBl
eGlzdGluZyBhbmQgY292ZXJlZCBieSB0aGUgbG9jayB3aGVuIGl0IHdhcyBvcmlnaW5hbGx5
PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgIGdyYW50ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZ3Jh
bnRlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNvbWUg
cmV3b3JkaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU29tZSByZXdv
cmRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog
ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz
cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh
c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz
cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFkZGVk
IGFwcC10YWdzIGZvciB0d28gb2YgdGhlIGVycm9yIGNhc2VzLjwvdGQ+PHRkPiA8L3RkPjx0
ZCBjbGFzcz0icmlnaHQiPiAgIEFkZGVkIGFwcC10YWdzIGZvciB0d28gb2YgdGhlIGVycm9y
IGNhc2VzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+
CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs
YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj
bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs
YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTWFk
ZSBZQU5HIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz
cz0icmlnaHQiPiAgIE1hZGUgWUFORyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2U8L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90
ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2
YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEVuaGFuY2VkIHNlY3VyaXR5
IGNvbnNpZGVyYXRpb25zLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEVu
aGFuY2VkIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i
IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg
dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90
ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDI0Ij48L2E+PC90ZD48L3Ry
PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj
bGFzcz0ibGJsb2NrIj44LjxzcGFuIGNsYXNzPSJkZWxldGUiPjg8L3NwYW4+LiAgMDAtMDE8
L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+OC48c3BhbiBjbGFzcz0iaW5zZXJ0
Ij45PC9zcGFuPi4gIDAwLTAxPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi
PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg
IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs
ZWZ0Ij4gICBBZGRlZCBZQU5HIG1vZHVsZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp
Z2h0Ij4gICBBZGRlZCBZQU5HIG1vZHVsZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp
Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln
bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90
cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAyNSI+PC9hPjwvdGQ+PC90cj4KICAg
ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9
ImxibG9jayI+OC48c3BhbiBjbGFzcz0iZGVsZXRlIj45PC9zcGFuPi4gIC0wMDwvdGQ+PHRk
PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj44LjxzcGFuIGNsYXNzPSJpbnNlcnQiPjEwPC9z
cGFuPi4gIC0wMDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv
dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk
IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0
ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk
IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg
Q3JlYXRlZCBmcm9tIGRyYWZ0LWxlbmd5ZWwtbmdvLXBhcnRpYWwtbG9jay0wMS50eHQ8L3Rk
Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDcmVhdGVkIGZyb20gZHJhZnQtbGVu
Z3llbC1uZ28tcGFydGlhbC1sb2NrLTAxLnR4dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh
bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs
aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh
c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48
L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0
ZCBjbGFzcz0ibGVmdCI+OS4gIEFja25vd2xlZGdlbWVudHM8L3RkPjx0ZD4gPC90ZD48dGQg
Y2xhc3M9InJpZ2h0Ij45LiAgQWNrbm93bGVkZ2VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu
byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48
dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48
L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhhbmtzIHRvIEFuZHkgQmllcm1hbiwgU2hhcm9u
IENoaXNob2xtLCBQaGlsIFNoYWZlciAsIERhdmlkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgVGhhbmtzIHRvIEFuZHkgQmllcm1hbiwgU2hhcm9uIENoaXNob2xtLCBQ
aGlsIFNoYWZlciAsIERhdmlkPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+
PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEhhcnJpbmd0b24sIE1laG1ldCBFcnN1ZSwgV2Vz
IEhhcmRha2VyLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIsIFdhc2hhbTwvdGQ+PHRkPiA8L3Rk
Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIEhhcnJpbmd0b24sIE1laG1ldCBFcnN1ZSwgV2VzIEhh
cmRha2VyLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIsIFdhc2hhbTwvdGQ+PHRkIGNsYXNzPSJs
aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp
bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBGYW4gYW5kIG1h
bnkgb3RoZXIgbWVtYmVycyBvZiB0aGUgTkVUQ09ORiBXRyBmb3IgcHJvdmlkaW5nIGltcG9y
dGFudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEZhbiBhbmQgbWFueSBv
dGhlciBtZW1iZXJzIG9mIHRoZSBORVRDT05GIFdHIGZvciBwcm92aWRpbmcgaW1wb3J0YW50
PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg
PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl
ZnQiPiAgIGlucHV0IHRvIHRoaXMgZG9jdW1lbnQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz
PSJyaWdodCI+ICAgaW5wdXQgdG8gdGhpcyBkb2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGlu
ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l
bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+
PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai
PjwvdGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48
dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0
ciBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+PGEgbmFt
ZT0iZW5kIj4mbmJzcDtFbmQgb2YgY2hhbmdlcy4gMjUgY2hhbmdlIGJsb2Nrcy4mbmJzcDs8
L2E+PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT42
NSBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48dGg+PGk+IDwvaT48L3RoPjx0
aD48aT44MiBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+PC90cj4K
ICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGNsYXNzPSJzbWFsbCIgYWxpZ249ImNlbnRlciI+
PGJyPlRoaXMgaHRtbCBkaWZmIHdhcyBwcm9kdWNlZCBieSByZmNkaWZmIDEuMzUuIFRoZSBs
YXRlc3QgdmVyc2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8YSBocmVmPSJodHRwOi8vd3d3LnRv
b2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9v
bHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4KICAgPC90Ym9keT48L3RhYmxlPgogICA8L2Jv
ZHk+PC9odG1sPg==
--------------020406030902060608020203--

From dromasca@avaya.com  Thu Jun 11 02:40:59 2009
Return-Path: <dromasca@avaya.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCFF3A6B02 for <netconf@core3.amsl.com>; Thu, 11 Jun 2009 02:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level: 
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me0-puy3pPdZ for <netconf@core3.amsl.com>; Thu, 11 Jun 2009 02:40:59 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 25DB03A6B2A for <netconf@ietf.org>; Thu, 11 Jun 2009 02:40:58 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,201,1243828800"; d="scan'208";a="173614255"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Jun 2009 05:41:05 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Jun 2009 05:41:05 -0400
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
Date: Thu, 11 Jun 2009 11:40:47 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04017904F0@307622ANEX5.global.avaya.com>
In-Reply-To: <4A30CD50.5020305@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Netconf] AD review for draft-ietf-netconf-partial-lock-08.txt
Thread-Index: AcnqdnRmttLEniyLRAezvlDXecmx6wAAcKhg
References: <EDC652A26FB23C4EB6384A4584434A0401790365@307622ANEX5.global.avaya.com> <4A30CD50.5020305@ericsson.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Balazs Lengyel" <balazs.lengyel@ericsson.com>, "Martin Bjorklund" <mbj@tail-f.com>
Cc: netconf mailing list <netconf@ietf.org>
Subject: Re: [Netconf] AD review for draft-ietf-netconf-partial-lock-08.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2009 09:41:00 -0000

Hi Balazs,

Thanks for the quick answer. Please gather all edits but do not issue
any new version until the end of the Last Call

Concerning:=20

>=20
> >=20
> > Also, the schema in Appendix A will need to include the=20
> full text of=20
> > the BSD license for code or a reference to it. This issue is still=20
> > debated with the Trust, so no action by now on this.
>=20
> BALAZS: So  I should wait for further information. When and=20
> where can I find this, or will the chairs or you supply it?
>=20

As I said, it's still in discussions and reviews. If there will be a
finalized text by the time you will do the revision I will let you and
the WG chairs know. Otherwise you can ignore this comment by now.=20

Dan

From andy@netconfcentral.com  Tue Jun 16 11:29:08 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4E543A6969 for <netconf@core3.amsl.com>; Tue, 16 Jun 2009 11:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.956
X-Spam-Level: 
X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gq+kTQMXvZZ for <netconf@core3.amsl.com>; Tue, 16 Jun 2009 11:29:08 -0700 (PDT)
Received: from n16a.bullet.mail.mud.yahoo.com (n16a.bullet.mail.mud.yahoo.com [68.142.207.126]) by core3.amsl.com (Postfix) with SMTP id 73F103A6D88 for <netconf@ietf.org>; Tue, 16 Jun 2009 11:28:59 -0700 (PDT)
Received: from [68.142.200.221] by n16.bullet.mail.mud.yahoo.com with NNFMP; 16 Jun 2009 18:29:08 -0000
Received: from [68.142.201.73] by t9.bullet.mud.yahoo.com with NNFMP; 16 Jun 2009 18:29:08 -0000
Received: from [127.0.0.1] by omp425.mail.mud.yahoo.com with NNFMP; 16 Jun 2009 18:29:08 -0000
X-Yahoo-Newman-Id: 838912.26309.bm@omp425.mail.mud.yahoo.com
Received: (qmail 29163 invoked from network); 16 Jun 2009 18:29:08 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp109.sbc.mail.sp1.yahoo.com with SMTP; 16 Jun 2009 18:29:07 -0000
X-YMail-OSG: KA9TlUoVM1lZ60iT5vPudfdhnVplePzwHVzfhdA8nnyYVVvvgWjuDroNmjy0raF.LCJLj12viSnDP9_9gjze56x1hgY.6djQ.D3uWeY9wmynqB3csEPgpk3h3ez7aSfSS86JpgBO0WyYZGAgeqG6o_wdfEKkTvmKycw95ftAzg_AHdxrfeWZJFp_kXEEVOTK.PTtpjcuMHf78iVt3UbawmOaq9OAqkKjvI8K.foTG8gaBmTuIkqfXbr.5HN1bYjZ5RnXUypERdv20dhl
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A37E473.1090401@netconfcentral.com>
Date: Tue, 16 Jun 2009 11:29:07 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Netconf] notification replay question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2009 18:29:08 -0000

Hi,

It is not clear whether or not <replayComplete> and
<notificationComplete> eventTypes are saved in the
global replay buffer, and replayed to subsequent
replay subscriptions.  RFC 5277, sec.3 doesn't say
one way or the other, but it does imply that only
one is expected on the subscription ('the'
replayComplete text + flow diagram shows 1 also).

Obviously, if either of these notifications is
replayed, the manager may get confused and think
the notification was for its subscription,
not for another session.  The eventTime could
be checked, but this is too complicated.

So, are these notifications saved or not?
IMO, they are not the same as system events
like 'startup' or 'config change', and MUST NOT be saved.
Otherwise, the text should be updated, and a 'sessionId'
field added to the <replayComplate> and <notificationComplete>
eventTypes.



Andy






From mbj@tail-f.com  Tue Jun 16 13:30:27 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53C93A6B11 for <netconf@core3.amsl.com>; Tue, 16 Jun 2009 13:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.826
X-Spam-Level: 
X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.220,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIxtpi0OL4mY for <netconf@core3.amsl.com>; Tue, 16 Jun 2009 13:30:27 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id EAE8C3A6A49 for <netconf@ietf.org>; Tue, 16 Jun 2009 13:30:26 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 17A60616001; Tue, 16 Jun 2009 22:21:02 +0200 (CEST)
Date: Tue, 16 Jun 2009 22:21:01 +0200 (CEST)
Message-Id: <20090616.222101.158429510.mbj@tail-f.com>
To: andy@netconfcentral.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4A37E473.1090401@netconfcentral.com>
References: <4A37E473.1090401@netconfcentral.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] notification replay question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2009 20:30:27 -0000

Hi,

Andy Bierman <andy@netconfcentral.com> wrote:
> Hi,
> 
> It is not clear whether or not <replayComplete> and
> <notificationComplete> eventTypes are saved in the
> global replay buffer, and replayed to subsequent
> replay subscriptions.  RFC 5277, sec.3 doesn't say
> one way or the other, but it does imply that only
> one is expected on the subscription ('the'
> replayComplete text + flow diagram shows 1 also).
> 
> Obviously, if either of these notifications is
> replayed, the manager may get confused and think
> the notification was for its subscription,
> not for another session.  The eventTime could
> be checked, but this is too complicated.
> 
> So, are these notifications saved or not?

IMO they are not saved.  They represent meta information which happen
to be sent in-band.

> IMO, they are not the same as system events
> like 'startup' or 'config change', and MUST NOT be saved.

I agree.


/martin

From Washam.Fan@huaweisymantec.com  Tue Jun 16 20:10:48 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881483A6DA8 for <netconf@core3.amsl.com>; Tue, 16 Jun 2009 20:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.604
X-Spam-Level: 
X-Spam-Status: No, score=0.604 tagged_above=-999 required=5 tests=[AWL=-1.501,  BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHRV9EZGpLIJ for <netconf@core3.amsl.com>; Tue, 16 Jun 2009 20:10:47 -0700 (PDT)
Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 89ECA3A6B93 for <netconf@ietf.org>; Tue, 16 Jun 2009 20:10:47 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLD001PX4U0WO80@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Wed, 17 Jun 2009 11:10:48 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLD00EYQ4U0FL00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Wed, 17 Jun 2009 11:10:48 +0800 (CST)
Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 17 Jun 2009 11:10:48 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: Martin Bjorklund <mbj@tail-f.com>
Message-id: <fc4cf4fa3c36.4a38cf38@huaweisymantec.com>
Date: Wed, 17 Jun 2009 11:10:48 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <20090616.222101.158429510.mbj@tail-f.com>
References: <4A37E473.1090401@netconfcentral.com> <20090616.222101.158429510.mbj@tail-f.com>
Cc: netconf@ietf.org
Subject: Re: [Netconf] notification replay question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 03:10:48 -0000

Hi,

----- Original Message -----
From: Martin Bjorklund <mbj@tail-f.com>
Date: Wednesday, June 17, 2009 4:30 am
Subject: Re: [Netconf] notification replay question
To: andy@netconfcentral.com
Cc: netconf@ietf.org


> Hi,
>  
>  Andy Bierman <andy@netconfcentral.com> wrote:
>  > Hi,
>  > 
>  > It is not clear whether or not <replayComplete> and
>  > <notificationComplete> eventTypes are saved in the
>  > global replay buffer, and replayed to subsequent
>  > replay subscriptions.  RFC 5277, sec.3 doesn't say
>  > one way or the other, but it does imply that only
>  > one is expected on the subscription ('the'
>  > replayComplete text + flow diagram shows 1 also).
>  > 
>  > Obviously, if either of these notifications is
>  > replayed, the manager may get confused and think
>  > the notification was for its subscription,
>  > not for another session.  The eventTime could
>  > be checked, but this is too complicated.
>  > 
>  > So, are these notifications saved or not?
>  
>  IMO they are not saved.  They represent meta information which happen
>  to be sent in-band.

And this information is session-specific, IMO. It might make
little sense to another session.

washam

>  > IMO, they are not the same as system events
>  > like 'startup' or 'config change', and MUST NOT be saved.
>  
>  I agree.
>  
>  
>  /martin
>  _______________________________________________
>  Netconf mailing list
>  Netconf@ietf.org
>  https://www.ietf.org/mailman/listinfo/netconf
>  

From andy@netconfcentral.com  Wed Jun 17 12:25:39 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C467828C2D8 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 12:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.956
X-Spam-Level: 
X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQNCS04FUVes for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 12:25:38 -0700 (PDT)
Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id D7ED428C2C5 for <netconf@ietf.org>; Wed, 17 Jun 2009 12:25:37 -0700 (PDT)
Received: (qmail 5416 invoked from network); 17 Jun 2009 19:25:45 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 17 Jun 2009 19:25:45 -0000
X-YMail-OSG: RK1badQVM1n0X6rk_QbsJSp0hGyv7Q6LL_AZNXW0rMuTBJgudn8o_5Vr4Mb4unn1uonVA61Cn6tcBjYep2SEEOPTmVhPmzw3DO7GYRxLFcHGXhwbR5yZO1uDM0O.mTStIDzSsJHmfny3zZKSj3jgHpR6mGbFTa3prEUmu3bLOMlj5c.57Coy12F966bIrEfrAFjv5JCok4t2q00YnxuNi1Ub6WlwjVqI6beWYPPgJIiEZjdtLv76yt84ic9riv5hWMXcW5Jm.6nYavPcUXy._SWqt_WHqTj0.nXpg_a6BKswP.pZMk0_
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A394337.6020004@netconfcentral.com>
Date: Wed, 17 Jun 2009 12:25:43 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 19:25:39 -0000

Hi,

I know I keep complaining about the lack of a coherent
ACM in NETCONF, but the presumption of a completely
unspecified access control in this RFC is problematic.

3.2, para 4:

    After generation of the <notification> element, access control is
    applied by the server.  If a session does not have permission to
    receive the <notification>, then it is discarded for that session,
    and processing of the internal event is completed for that session.

Without any actual ACM, what does 'permission' really mean?

Why is there a presumption that data delivered to a session
via <get> should have a different ACM architecture than data
delivered to the exact same session via <notification>?

The RFC never says the agent MUST make an all-or-nothing
decision wrt/ granting permission to deliver the notification.
What if access control is enforced at a lower level,
in the XML generation, so no matter what RPC method is
trying to access /path/to/secret-password, they can't?

I will assume an implementation may silently prune
parts of the payload from the notification, due to access
control policy.  The notification MUST be dropped
if the <eventType> element would be filtered out,
in violation of the <notification> element schema.


Andy



From phil@juniper.net  Wed Jun 17 12:59:36 2009
Return-Path: <phil@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ACDC3A6407 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 12:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.442
X-Spam-Level: 
X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZfEjvvdaBZq for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 12:59:35 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 59CC13A69D2 for <netconf@ietf.org>; Wed, 17 Jun 2009 12:59:34 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSjlLMRRB+s6o93RP6vhUuo/1+FHsWm0f@postini.com; Wed, 17 Jun 2009 12:59:47 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Wed, 17 Jun 2009 12:54:59 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 12:54:58 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 12:54:58 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 12:54:57 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5HJsvL59682; Wed, 17 Jun 2009 12:54:57 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n5HJiBBo056500; Wed, 17 Jun 2009 19:44:11 GMT (envelope-from phil@idle.juniper.net)
Message-ID: <200906171944.n5HJiBBo056500@idle.juniper.net>
To: Andy Bierman <andy@netconfcentral.com>
In-Reply-To: <4A394337.6020004@netconfcentral.com> 
Date: Wed, 17 Jun 2009 15:44:11 -0400
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 17 Jun 2009 19:54:57.0871 (UTC) FILETIME=[7DE665F0:01C9EF85]
MIME-Version: 1.0
Content-Type: text/plain
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 19:59:36 -0000

Andy Bierman writes:
>3.2, para 4:
>    After generation of the <notification> element, access control is
>    applied by the server.  If a session does not have permission to
>    receive the <notification>, then it is discarded for that session,
>    and processing of the internal event is completed for that session.

>I will assume an implementation may silently prune
>parts of the payload from the notification, due to access
>control policy.  The notification MUST be dropped
>if the <eventType> element would be filtered out,
>in violation of the <notification> element schema.

Yes, let's add this as an issue list for a future -bis, since an
implementation should be able to prune inappropriate elements from
the notification.

Also we should repair the word "after" in the above text, since
there isn't any explicit to generate the <notification> element at
all if no one is permitted to receive the content.

Thanks,
 Phil

From andy@netconfcentral.com  Wed Jun 17 13:17:45 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C6B28C2F5 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 13:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.789
X-Spam-Level: 
X-Spam-Status: No, score=-0.789 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqIOkBqkX8gl for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 13:17:44 -0700 (PDT)
Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 74F0028C2E9 for <netconf@ietf.org>; Wed, 17 Jun 2009 13:17:44 -0700 (PDT)
Received: (qmail 99805 invoked from network); 17 Jun 2009 20:17:54 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 17 Jun 2009 20:17:53 -0000
X-YMail-OSG: 0IYbTwAVM1lbZLnJXqzv65ycb8EAigByShRW4D2YMQHyKt3xTw0J7zSN7EdyX1pF8o4O4seoo6N_GMV1GBGpyYQ4T_2GizdoS9Z1itdd04MirG2btw7PNs6fMBOWi.BUI7qkW8v4a14i7Dm_bRawzliGtxtwtXIaJlWA9IJjYQ7e39VyERCy_qghB.gY5EQSqivXLDm22Ubte90T6.B_Oe0vYcEEJv6RixeeYQa5_nHaIQW_kZYs3zDeKdJydYKMHr29FMQhIODd_vES
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A394F71.4090500@netconfcentral.com>
Date: Wed, 17 Jun 2009 13:17:53 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>
In-Reply-To: <200906171944.n5HJiBBo056500@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 20:17:45 -0000

Phil Shafer wrote:
> Andy Bierman writes:
>> 3.2, para 4:
>>    After generation of the <notification> element, access control is
>>    applied by the server.  If a session does not have permission to
>>    receive the <notification>, then it is discarded for that session,
>>    and processing of the internal event is completed for that session.
> 
>> I will assume an implementation may silently prune
>> parts of the payload from the notification, due to access
>> control policy.  The notification MUST be dropped
>> if the <eventType> element would be filtered out,
>> in violation of the <notification> element schema.
> 
> Yes, let's add this as an issue list for a future -bis, since an
> implementation should be able to prune inappropriate elements from
> the notification.
> 
> Also we should repair the word "after" in the above text, since
> there isn't any explicit to generate the <notification> element at
> all if no one is permitted to receive the content.
> 

yes -- I assume you mean the 'stream n' delivery in figure 2.
The replay (logging service) is given a copy of the event.
Delivery of replay notifications to a stream is no different
than live events.  (not shown in figure 2.)

Also, the 'filter' step in figure 2 is misleading.
ACM and filtering is not applied on the stream, but
independently, on each subscription (not shown).

The all-or-nothing approach actually helps hackers.
If there is no filter, then any dropped notification
would stick out like a red flag, since it must have
contained some sensitive data. (This works just
by watching the traffic with wireshark, without
actually being able to read any of the packets.)
We should want to make it as difficult as possible
to discover the access control policy in use on an agent.


> Thanks,
>  Phil
> 
> 

Andy


From mbj@tail-f.com  Wed Jun 17 13:39:06 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4FB3A6EA8 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 13:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51JFhY6j4Tws for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 13:39:05 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8BFEB28C306 for <netconf@ietf.org>; Wed, 17 Jun 2009 13:38:53 -0700 (PDT)
Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 62F7C616001; Wed, 17 Jun 2009 22:33:47 +0200 (CEST)
Date: Wed, 17 Jun 2009 22:33:46 +0200 (CEST)
Message-Id: <20090617.223346.105733797.mbj@tail-f.com>
To: andy@netconfcentral.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4A394F71.4090500@netconfcentral.com>
References: <200906171944.n5HJiBBo056500@idle.juniper.net> <4A394F71.4090500@netconfcentral.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 20:39:06 -0000

Andy Bierman <andy@netconfcentral.com> wrote:
> The all-or-nothing approach actually helps hackers.
> If there is no filter, then any dropped notification
> would stick out like a red flag, since it must have
> contained some sensitive data. (This works just
> by watching the traffic with wireshark, without
> actually being able to read any of the packets.)

How would a hacker know that a notification was *not* sent by watching
the traffic?

I don't care that much if the entire notif is dropped, or some element
is pruned, but the current spec is pretty clear - the notification
MUST be dropped.  So a 5277 compliant server cannot prune
elements from the notifications.


/martin

From andy@netconfcentral.com  Wed Jun 17 13:57:50 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC053A6EAE for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 13:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.733
X-Spam-Level: 
X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+TeOZaU0qD0 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 13:57:49 -0700 (PDT)
Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id E100B3A6936 for <netconf@ietf.org>; Wed, 17 Jun 2009 13:57:49 -0700 (PDT)
Received: (qmail 76783 invoked from network); 17 Jun 2009 20:57:58 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 17 Jun 2009 20:57:58 -0000
X-YMail-OSG: TLaCu.UVM1mQ8H4mQAmrofpDb68cTQB1wPeXOmecoc3SWEYskHWeRztGcC.ERtQGP65gXIusIWry6zxEhlvwZeFnE61htpUS3OFUJo4aF7vclnFnkqMZ6IIv6d9yQ8s.xnJ9EqfqZiEVKFm7VwLB3mssfmt089oMzcznGi6bCyphCoFeon79Mayh2BAz9jOwm6omob9KpGheegif4j0Y2j9WGEb2uWC5G5Hlr5o8iOFmhcHYmV5cnIUcjU_JDyB8XMXKA_0teDw9rcPT3txCpPj1t1NZxASEZzeMarOAia_P_cLEKDaca2hCCeUmWfB2oJQgIQdi4DcpAeHO19PiyxKAsJ96.cHDQ1RFvfgnKneA3X1zlQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A3958C0.70404@netconfcentral.com>
Date: Wed, 17 Jun 2009 13:57:36 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com> <20090617.223346.105733797.mbj@tail-f.com>
In-Reply-To: <20090617.223346.105733797.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 20:57:50 -0000

Martin Bjorklund wrote:
> Andy Bierman <andy@netconfcentral.com> wrote:
>> The all-or-nothing approach actually helps hackers.
>> If there is no filter, then any dropped notification
>> would stick out like a red flag, since it must have
>> contained some sensitive data. (This works just
>> by watching the traffic with wireshark, without
>> actually being able to read any of the packets.)
> 
> How would a hacker know that a notification was *not* sent by watching
> the traffic?
> 

by watching traffic patterns (when multiple subscriptions
are active).


> I don't care that much if the entire notif is dropped, or some element
> is pruned, but the current spec is pretty clear - the notification
> MUST be dropped.  So a 5277 compliant server cannot prune
> elements from the notifications.
> 

I don't think the RFC says that anywhere.
There is just the vague text about granting
permission.  IMO, that meant that the manager
has permission to see the <eventType> element,
but it does not mean the entire payload is going
to be delivered, if ACM policy decides otherwise.

What if the ACM rule is simply:  deny "//secret-stuff".
What if the ACM defines 'deny on read access' to mean prune?
(And what about applying access control to 'anyxml'
nodes, like a subtree <filter>?)

> 
> /martin
> 
> 

Andy


From mbj@tail-f.com  Wed Jun 17 14:09:54 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88C83A6801 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 14:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yijUMPYq4VA for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 14:09:54 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 020A83A6808 for <netconf@ietf.org>; Wed, 17 Jun 2009 14:09:53 -0700 (PDT)
Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 8BC73616028; Wed, 17 Jun 2009 23:10:05 +0200 (CEST)
Date: Wed, 17 Jun 2009 23:10:05 +0200 (CEST)
Message-Id: <20090617.231005.07000664.mbj@tail-f.com>
To: andy@netconfcentral.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4A3958C0.70404@netconfcentral.com>
References: <4A394F71.4090500@netconfcentral.com> <20090617.223346.105733797.mbj@tail-f.com> <4A3958C0.70404@netconfcentral.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 21:09:54 -0000

Andy Bierman <andy@netconfcentral.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <andy@netconfcentral.com> wrote:
> >> The all-or-nothing approach actually helps hackers.
> >> If there is no filter, then any dropped notification
> >> would stick out like a red flag, since it must have
> >> contained some sensitive data. (This works just
> >> by watching the traffic with wireshark, without
> >> actually being able to read any of the packets.)
> > How would a hacker know that a notification was *not* sent by watching
> > the traffic?
> > 
> 
> by watching traffic patterns (when multiple subscriptions
> are active).

But you wouldn't know that the different subscriptions use the same
filter.

> > I don't care that much if the entire notif is dropped, or some element
> > is pruned, but the current spec is pretty clear - the notification
> > MUST be dropped.  So a 5277 compliant server cannot prune
> > elements from the notifications.
> > 
> 
> I don't think the RFC says that anywhere.
> There is just the vague text about granting
> permission.  IMO, that meant that the manager
> has permission to see the <eventType> element,
> but it does not mean the entire payload is going
> to be delivered, if ACM policy decides otherwise.

Ok, I agree the text is vague.  But maybe this is good - it means that
the ACM can define the behavior without a 5277bis.

(Compare with 4741, it doesn't say what the result is if you do a
<get> w/o a filter when you don't have read access to everything - do
you get all data you're allowed to see (yes), or do you get an
access-denied error (no)?)



/martin

From andy@netconfcentral.com  Wed Jun 17 14:21:21 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC803A6808 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 14:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.873
X-Spam-Level: 
X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVbSkQgqqFCk for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 14:21:21 -0700 (PDT)
Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by core3.amsl.com (Postfix) with SMTP id E1FEF3A67B7 for <netconf@ietf.org>; Wed, 17 Jun 2009 14:21:20 -0700 (PDT)
Received: from [68.142.200.224] by n17.bullet.mail.mud.yahoo.com with NNFMP; 17 Jun 2009 21:21:31 -0000
Received: from [68.142.201.64] by t5.bullet.mud.yahoo.com with NNFMP; 17 Jun 2009 21:21:31 -0000
Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 17 Jun 2009 21:21:31 -0000
X-Yahoo-Newman-Id: 39009.41743.bm@omp416.mail.mud.yahoo.com
Received: (qmail 68175 invoked from network); 17 Jun 2009 21:21:30 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 17 Jun 2009 21:21:30 -0000
X-YMail-OSG: an0THRkVM1nanVwWZl0M7Hu6GZlIzhreo9HgX3sjKvPzdPAmYdJs32H_wYSH8JGxAx4qdWh_XKIGdAh1lympgCVXN1SaHfHl.JJe7xPnrVA8Snl_XHJH65OOqN7vs0WbVa9pMwuNas.DL5gf6jX6kRjImGcAehkw1yb9pUCbYLitj1SPfHqtERFRrUUpsT.rvviAxN8C_UsyA6aCcPHNUQicgoOb6hKTsPH4yb51Od19sq8h9XbC80weUUs1l3A9RxhDV0xAnBrhK.Q9Eb9b6G970UWvquwFzdg0YX1lbclNR8yDSF_abDg_7y_uajBsxOOdJAGShD.Tct24c.EEkHToxgDpdSvF6jOoO0jmcbBZr6frlA--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A395E45.4060900@netconfcentral.com>
Date: Wed, 17 Jun 2009 14:21:09 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <4A394F71.4090500@netconfcentral.com>	<20090617.223346.105733797.mbj@tail-f.com>	<4A3958C0.70404@netconfcentral.com> <20090617.231005.07000664.mbj@tail-f.com>
In-Reply-To: <20090617.231005.07000664.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 21:21:21 -0000

Martin Bjorklund wrote:
> Andy Bierman <andy@netconfcentral.com> wrote:
>> Martin Bjorklund wrote:
>>> Andy Bierman <andy@netconfcentral.com> wrote:
>>>> The all-or-nothing approach actually helps hackers.
>>>> If there is no filter, then any dropped notification
>>>> would stick out like a red flag, since it must have
>>>> contained some sensitive data. (This works just
>>>> by watching the traffic with wireshark, without
>>>> actually being able to read any of the packets.)
>>> How would a hacker know that a notification was *not* sent by watching
>>> the traffic?
>>>
>> by watching traffic patterns (when multiple subscriptions
>> are active).
> 
> But you wouldn't know that the different subscriptions use the same
> filter.
> 

true -- especially since the filter element is
getting removed from the ietf-netconf-state module.

>>> I don't care that much if the entire notif is dropped, or some element
>>> is pruned, but the current spec is pretty clear - the notification
>>> MUST be dropped.  So a 5277 compliant server cannot prune
>>> elements from the notifications.
>>>
>> I don't think the RFC says that anywhere.
>> There is just the vague text about granting
>> permission.  IMO, that meant that the manager
>> has permission to see the <eventType> element,
>> but it does not mean the entire payload is going
>> to be delivered, if ACM policy decides otherwise.
> 
> Ok, I agree the text is vague.  But maybe this is good - it means that
> the ACM can define the behavior without a 5277bis.
> 
> (Compare with 4741, it doesn't say what the result is if you do a
> <get> w/o a filter when you don't have read access to everything - do
> you get all data you're allowed to see (yes), or do you get an
> access-denied error (no)?)
> 

For write access and exec access (invoke RPC method),
an access-denied error is generated.  For all read operations,
the data is just silently dropped.

Since there is no standard ACM, and assumptions are valid,
including these.


> 
> 
> /martin
> 
> 

Andy



From randy_presuhn@mindspring.com  Wed Jun 17 15:39:07 2009
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12AFE3A6878 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 15:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H53rgdX9P+hW for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 15:39:06 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 543F83A6939 for <netconf@ietf.org>; Wed, 17 Jun 2009 15:39:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mdfr8bQUh5LSSvCHIlqAqD4XhjGvdhRIJKEHcbFuQPZhcbrxxIB+z/Rt9o/u6rwj; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.187.238.229] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1MH3mo-0008V7-2C for netconf@ietf.org; Wed, 17 Jun 2009 18:39:18 -0400
Message-ID: <001201c9ef9c$832a64a0$6801a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "NETCONF" <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net> <4A394F71.4090500@netconfcentral.com>
Date: Wed, 17 Jun 2009 15:39:43 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968020a94b73f72bc854d96d0e5cf0b15e0350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.187.238.229
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 22:39:07 -0000

Hi -

> From: "Andy Bierman" <andy@netconfcentral.com>
> To: "Phil Shafer" <phil@juniper.net>
> Cc: "NETCONF" <netconf@ietf.org>
> Sent: Wednesday, June 17, 2009 1:17 PM
> Subject: Re: [Netconf] notification access control
...
> The all-or-nothing approach actually helps hackers.
> If there is no filter, then any dropped notification
> would stick out like a red flag, since it must have
> contained some sensitive data. (This works just
> by watching the traffic with wireshark, without
> actually being able to read any of the packets.)
> We should want to make it as difficult as possible
> to discover the access control policy in use on an agent.

I have a couple of problems with this line of reasoning.

(1) hiding the policy is probably not as important as
protecting the information covered by that policy.

(2) selective removal of elements from the payload
can still permit semantic leaks.  Consider something
analogous to a "linkUp" notification.  For a particular
interface, the payload might be supressed by such a
policy, but the notification would still be delivered to
a party that wasn't supposed to know what was going
on with that interface.  If that was the only interface
which would meet the subscription's criteria, then
even surpressing the payload doesn't prevent the
information leak.

Randy


From andy@netconfcentral.com  Wed Jun 17 16:30:17 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECC73A6DF8 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 16:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeMZuut30izO for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 16:30:16 -0700 (PDT)
Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 2408C3A6DE5 for <netconf@ietf.org>; Wed, 17 Jun 2009 16:30:15 -0700 (PDT)
Received: (qmail 15366 invoked from network); 17 Jun 2009 23:30:26 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 17 Jun 2009 23:30:25 -0000
X-YMail-OSG: L_5RyyYVM1mdOqbylAqYdVC4aYuvatbi7r2RwhW4.j6aNZuiqj7CFi.iNFO6_DLLljrV0Q2kym2s4LYuX0CAqEe_1y4XdQUuqM_KrzznD5xcdeCkOPfKtkvQa_TqcZeQ.WLeTLGAk7dsCuNkkEUGv.fazxTf2lYMvpvXBrOHVsS4zgKgd8UgPaZljwxZZOUruKngWQeH314_V0E.9cge939NBDaK0.XFjdzHIcuW_pIYADkwt8JuPJ0COsmHpql3qIe72wbs9qNowugf.d34z.Ml.O6QQor466Ae.tDDsETdhFMZ
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A397C90.1050801@netconfcentral.com>
Date: Wed, 17 Jun 2009 16:30:24 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com> <001201c9ef9c$832a64a0$6801a8c0@oemcomputer>
In-Reply-To: <001201c9ef9c$832a64a0$6801a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 23:30:17 -0000

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <andy@netconfcentral.com>
>> To: "Phil Shafer" <phil@juniper.net>
>> Cc: "NETCONF" <netconf@ietf.org>
>> Sent: Wednesday, June 17, 2009 1:17 PM
>> Subject: Re: [Netconf] notification access control
> ...
>> The all-or-nothing approach actually helps hackers.
>> If there is no filter, then any dropped notification
>> would stick out like a red flag, since it must have
>> contained some sensitive data. (This works just
>> by watching the traffic with wireshark, without
>> actually being able to read any of the packets.)
>> We should want to make it as difficult as possible
>> to discover the access control policy in use on an agent.
> 
> I have a couple of problems with this line of reasoning.
> 
> (1) hiding the policy is probably not as important as
> protecting the information covered by that policy.
> 
> (2) selective removal of elements from the payload
> can still permit semantic leaks.  Consider something
> analogous to a "linkUp" notification.  For a particular
> interface, the payload might be supressed by such a
> policy, but the notification would still be delivered to
> a party that wasn't supposed to know what was going
> on with that interface.  If that was the only interface
> which would meet the subscription's criteria, then
> even surpressing the payload doesn't prevent the
> information leak.
> 

I think Martin is right.
Since the filters will be removed from monitoring data,
an attacker won't really have any way of knowing which
sessions are trying to filter which content.  Therefore,
presence or absence of a notification does not really
mean anything.

What's the problem if the agent leaves out some subtrees
in the payload on <get> or <notification>?  And why
would the ACM policy be different for <get> or <notification>
in NETCONF? (it's all just SSH2 channel data to me :-)

The argument that the manager may not understand the
notification payload is no different than if the
manager did a NETCONF <get/> on the same data, and
a subset was returned.

Obviously, any system that rejected all <get/> requests
with an access-denied error, would not be very usable.
Silently skipping over unauthorized data is needed
to provide a usable management system. What if an
SNMP MIB walk crashed with an access-control error the
first unauthorized node it hit?  Same problem in NETCONF, no?


> Randy


Andy


From j.schoenwaelder@jacobs-university.de  Wed Jun 17 16:39:08 2009
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1217E3A69CD for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 16:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.217
X-Spam-Level: 
X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599, HELO_EQ_DE=0.35, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdJuZRfspo1o for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 16:39:07 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9C5343A6E4B for <netconf@ietf.org>; Wed, 17 Jun 2009 16:38:46 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DFDEC0039; Thu, 18 Jun 2009 01:38:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BzvCDLf+GbBH; Thu, 18 Jun 2009 01:38:57 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55E29C0035; Thu, 18 Jun 2009 01:38:56 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 49CF8B468EA; Thu, 18 Jun 2009 01:38:55 +0200 (CEST)
Date: Thu, 18 Jun 2009 01:38:55 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@netconfcentral.com>
Message-ID: <20090617233855.GA11123@elstar.local>
Mail-Followup-To: Andy Bierman <andy@netconfcentral.com>, Phil Shafer <phil@juniper.net>, NETCONF <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net> <4A394F71.4090500@netconfcentral.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A394F71.4090500@netconfcentral.com>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 23:39:08 -0000

On Wed, Jun 17, 2009 at 10:17:53PM +0200, Andy Bierman wrote:
 
> The all-or-nothing approach actually helps hackers.
> If there is no filter, then any dropped notification
> would stick out like a red flag, since it must have
> contained some sensitive data. (This works just
> by watching the traffic with wireshark, without
> actually being able to read any of the packets.)
> We should want to make it as difficult as possible
> to discover the access control policy in use on an agent.

I hope SSH makes it difficult enough to do this kind of attack; an
attacker would need a valid session key to make any sense out of the
encrypted byte stream. And if the attacker is able to obtain a valid
session key, well then you likely have a bigger problem.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From andy@netconfcentral.com  Wed Jun 17 16:40:52 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71ED33A6A95 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 16:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km+TU4gKYNYQ for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 16:40:51 -0700 (PDT)
Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id B83463A69CD for <netconf@ietf.org>; Wed, 17 Jun 2009 16:40:51 -0700 (PDT)
Received: from [68.142.194.243] by n20.bullet.mail.mud.yahoo.com with NNFMP; 17 Jun 2009 23:41:01 -0000
Received: from [68.142.201.254] by t1.bullet.mud.yahoo.com with NNFMP; 17 Jun 2009 23:41:01 -0000
Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 17 Jun 2009 23:41:01 -0000
X-Yahoo-Newman-Id: 826424.14880.bm@omp415.mail.mud.yahoo.com
Received: (qmail 16087 invoked from network); 17 Jun 2009 23:41:01 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp104.sbc.mail.sp1.yahoo.com with SMTP; 17 Jun 2009 23:41:01 -0000
X-YMail-OSG: JRebbRcVM1mhIksE3kWnhZ8u.f_tvVuZ_gAAoLbOKPT_cXiJPQaL4uGKCYobZMRmgo.zEF99KQNriWXr6rQbxH4_8kp5FVknPPZFQ1h47wbr486h7Xojhw6xTCXCpBbVoRWgV4aoT1TrHvBVUjbUvDr2Xs3gMPU2W9rFDhb3XPDszA92GLhb2Fj_vEn5eXkDVMPr9lymtgaXq2bQnyb1GGMW8G82lwP3muqkXspRA2h3I.dCQF_ybQDkMi_Oy_P6Cs8EWvNIFXUjz9BG
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A397F0C.4000108@netconfcentral.com>
Date: Wed, 17 Jun 2009 16:41:00 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com> <001201c9ef9c$832a64a0$6801a8c0@oemcomputer>
In-Reply-To: <001201c9ef9c$832a64a0$6801a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 23:40:52 -0000

Randy Presuhn wrote:
> Hi -
>

Here is a use-case example of what I mean.

Let's say a WG or vendor defines a config-change
notification that includes a 'username' field
(i.e., who made the config change).

Let's say an operator using equipment purchased
from the vendor decides to implement a security policy
that usernames are restricted data (because they aid
brute-force login attacks which guess usernames).

Should NETCONF be flexible enough to allow the operator
to decide security policy, not the WG or equipment vendor?

IMO, yes.  IMO, SNMP made a big assumption by deciding
that any access-control filtering applied on the payload means
the payload will be unusable by the manager.  NETCONF should
not make the same mistake.


> Randy
>

Andy





From andy@netconfcentral.com  Wed Jun 17 16:50:28 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96523A689D for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 16:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.741
X-Spam-Level: 
X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PedTik0+3pyE for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 16:50:28 -0700 (PDT)
Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id B91903A6407 for <netconf@ietf.org>; Wed, 17 Jun 2009 16:50:27 -0700 (PDT)
Received: (qmail 65583 invoked from network); 17 Jun 2009 23:50:37 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 17 Jun 2009 23:50:37 -0000
X-YMail-OSG: gz60ACwVM1kCutB3Mnpdszo51jRKhvBTpo847n.9rO8_6qqXgiAo_3TNa3IdKIIPjqCYrZY0BV8j4o7JFa_8ZRQL4UvDV2uI3VZXaTCjJmGgRKmuChmTu1Ei6lXU1u.42Zvsd9znkshdtEX_fPyuS6DO.pGI19bNU2A7_VnaP9kRsBHFiFuIcs02zZ__dSJov5zkLL5dLKiRq9GJ92SzWwhdY6xfL4dougxPcbYTus.LvtcwlUwLmmRsj9KXf_oJ01qrB3.enJalfJVA
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A398137.8060403@netconfcentral.com>
Date: Wed, 17 Jun 2009 16:50:15 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Andy Bierman <andy@netconfcentral.com>, Phil Shafer <phil@juniper.net>, NETCONF <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net> <4A394F71.4090500@netconfcentral.com> <20090617233855.GA11123@elstar.local>
In-Reply-To: <20090617233855.GA11123@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 23:50:28 -0000

Juergen Schoenwaelder wrote:
> On Wed, Jun 17, 2009 at 10:17:53PM +0200, Andy Bierman wrote:
>  
>> The all-or-nothing approach actually helps hackers.
>> If there is no filter, then any dropped notification
>> would stick out like a red flag, since it must have
>> contained some sensitive data. (This works just
>> by watching the traffic with wireshark, without
>> actually being able to read any of the packets.)
>> We should want to make it as difficult as possible
>> to discover the access control policy in use on an agent.
> 
> I hope SSH makes it difficult enough to do this kind of attack; an
> attacker would need a valid session key to make any sense out of the
> encrypted byte stream. And if the attacker is able to obtain a valid
> session key, well then you likely have a bigger problem.
> 

Not entirely.
If ClientAliveInterval or ServerAliveInterval is enabled
in openssh, then there will be periodic data sent on
the channel to keep proxies from timing out, etc.
(Plain Keepalive messages are TCP, not SSH.)

These can be guessed (and removed from the data set)
just because they will be the same SSH message at
regular intervals.

Any <rpc-reply> will be immediately preceded by the <rpc>
PDU going the other way, so that is easy to remove
from the data-set.

So, you can easily tell that a session is getting
a notification (or not), but you cannot guess the content.


> /js
> 

Andy


From andy@netconfcentral.com  Wed Jun 17 17:02:02 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7723A6A15 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 17:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.893
X-Spam-Level: 
X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[AWL=0.063,  BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZjbcNZ34oLV for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 17:02:00 -0700 (PDT)
Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id 05FDD3A6A95 for <netconf@ietf.org>; Wed, 17 Jun 2009 17:01:59 -0700 (PDT)
Received: (qmail 70343 invoked from network); 18 Jun 2009 00:02:10 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 18 Jun 2009 00:02:10 -0000
X-YMail-OSG: 9JZPocUVM1k92hvs6AQcF998jILAjS_oHEs64AeGD63UsHqrKkVCrmbvjf526RH9JkZcO.0uR9sxAS9eVDZ_k_CzEFPXrZKz3IdUiLTen6tmYGBQPPkoKXp1223n80l_6owjDfcJj2ccOfjafonMJpKzh5YWplmSmDhZGs6al8Z9GGNGFOBN0tIuyOgfP.WuyWAFu9I3ZwJfVWm7SdEzksTFCmA5Wf6w2P2eScS7eJoFqrvGSw3vo4X5rZy6clCWimqafmQixumGJH1b
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A398401.7090400@netconfcentral.com>
Date: Wed, 17 Jun 2009 17:02:09 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net> <4A394F71.4090500@netconfcentral.com> <20090617233855.GA11123@elstar.local> <4A398137.8060403@netconfcentral.com>
In-Reply-To: <4A398137.8060403@netconfcentral.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 00:02:02 -0000

Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
...
> So, you can easily tell that a session is getting
> a notification (or not), but you cannot guess the content.
> 

I want to summarize that this is not any new security hole,
and pruning payload data or dropping the notification (on one session
but not another), offers an attacker the same opportunity
to identity 'packets of interest' within the capture log.
Without knowing all the filters as well, this is much
less likely to be a real vulnerability.


> 
>> /js
>>
> 
> Andy
> 
> 
> 

Andy


From j.schoenwaelder@jacobs-university.de  Wed Jun 17 17:10:48 2009
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5A93A6A95 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 17:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Level: 
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599, HELO_EQ_DE=0.35, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P92Dzm+bpvMM for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 17:10:47 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5A58F3A6407 for <netconf@ietf.org>; Wed, 17 Jun 2009 17:10:47 -0700 (PDT)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20BD8C0039; Thu, 18 Jun 2009 02:10:59 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VyFj79MER1mN; Thu, 18 Jun 2009 02:10:58 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3EB2C0035; Thu, 18 Jun 2009 02:10:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 160B8B4697E; Thu, 18 Jun 2009 02:10:57 +0200 (CEST)
Date: Thu, 18 Jun 2009 02:10:56 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@netconfcentral.com>
Message-ID: <20090618001056.GA11185@elstar.local>
Mail-Followup-To: Andy Bierman <andy@netconfcentral.com>, Phil Shafer <phil@juniper.net>, NETCONF <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net> <4A394F71.4090500@netconfcentral.com> <20090617233855.GA11123@elstar.local> <4A398137.8060403@netconfcentral.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A398137.8060403@netconfcentral.com>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 00:10:48 -0000

On Thu, Jun 18, 2009 at 01:50:15AM +0200, Andy Bierman wrote:

[...]
 
> So, you can easily tell that a session is getting a notification (or
> not), but you cannot guess the content.

So what? (And I would be curious to see a demonstration of this
technique at the next IETF. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From randy_presuhn@mindspring.com  Wed Jun 17 17:22:30 2009
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF5D3A6EBB for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 17:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIGChxzsvpsW for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 17:22:30 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id CF6263A6808 for <netconf@ietf.org>; Wed, 17 Jun 2009 17:22:29 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VEmvQ2SqfoiQRqbl87lt/+XMN65DcmPGVjl9y/HnEsENo7iK1DzTHHz1ROJ7xfKN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.187.238.229] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1MH5Or-0006HT-LX for netconf@ietf.org; Wed, 17 Jun 2009 20:22:41 -0400
Message-ID: <000c01c9efaa$f6489340$6801a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "NETCONF" <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com> <001201c9ef9c$832a64a0$6801a8c0@oemcomputer> <4A397C90.1050801@netconfcentral.com>
Date: Wed, 17 Jun 2009 17:23:09 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968a34834a087c62df5c8acce62db49b0af350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.187.238.229
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 00:22:30 -0000

Hi -

> From: "Andy Bierman" <andy@netconfcentral.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "NETCONF" <netconf@ietf.org>
> Sent: Wednesday, June 17, 2009 4:30 PM
> Subject: Re: [Netconf] notification access control
>
> Randy Presuhn wrote:
> > Hi -
> > 
> >> From: "Andy Bierman" <andy@netconfcentral.com>
> >> To: "Phil Shafer" <phil@juniper.net>
> >> Cc: "NETCONF" <netconf@ietf.org>
> >> Sent: Wednesday, June 17, 2009 1:17 PM
> >> Subject: Re: [Netconf] notification access control
...
> Since the filters will be removed from monitoring data,
> an attacker won't really have any way of knowing which
> sessions are trying to filter which content.  Therefore,
> presence or absence of a notification does not really
> mean anything.

You're only looking at the potential eavesdropper.
Consider where the atacker is the authorized user,
trying to ferrer out information s/he is not supposed
to be able to have access to.

> What's the problem if the agent leaves out some subtrees
> in the payload on <get> or <notification>?  And why
> would the ACM policy be different for <get> or <notification>
> in NETCONF? (it's all just SSH2 channel data to me :-)

It's not the omission per se that bothers me.  It's that the
very existence of the notification reveals information.
That's why SNMP doesn't just consider the varbinds
in deciding whether to forward a notification.  Now maybe
this is covered by Netconf's access control framework,
or maybe it isn't.

> The argument that the manager may not understand the
> notification payload is no different than if the
> manager did a NETCONF <get/> on the same data, and
> a subset was returned.

I don't think anyone is making that argument.

> Obviously, any system that rejected all <get/> requests
> with an access-denied error, would not be very usable.
> Silently skipping over unauthorized data is needed
> to provide a usable management system. What if an
> SNMP MIB walk crashed with an access-control error the
> first unauthorized node it hit?  Same problem in NETCONF, no?

How did we get from notifications into get requests?

Randy



From andy@netconfcentral.com  Wed Jun 17 17:30:30 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B2F3A6C93 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 17:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.733
X-Spam-Level: 
X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCyPP8GpRI8O for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 17:30:29 -0700 (PDT)
Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id B6DC23A6962 for <netconf@ietf.org>; Wed, 17 Jun 2009 17:30:29 -0700 (PDT)
Received: (qmail 38144 invoked from network); 18 Jun 2009 00:30:39 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2009 00:30:39 -0000
X-YMail-OSG: SVm7m3MVM1kLlPD.bd1J5fSEhTZbv3AGRHUP2e3LI1N4ZCgoJzVR7oqZbX091ERy_xVbFVy0lAWObzmntsz20X17HCImH8bWIfGxB2cUREwJomo2_KRFA2w9sAxw.KFLOsGdreGXEt6imqZgxuZlY4AZH00GDS5JCL3rrbjByAIf2noxe.SLmradk2XecxgkXbCt2fG0BXUhzvTo5Pm57niTARmBH3iY5_fQodmqPLh2CdFYN_CUi5l5G30To1EB1rlLWQwaSzkCxqPzjzJ70aNtqd8vmzQmTeXLhgRo81lD7s7I
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A398AAE.5000300@netconfcentral.com>
Date: Wed, 17 Jun 2009 17:30:38 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com> <000c01c9efaa$f6489340$6801a8c0@oemcomputer>
In-Reply-To: <000c01c9efaa$f6489340$6801a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 00:30:30 -0000

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <andy@netconfcentral.com>
>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
>> Cc: "NETCONF" <netconf@ietf.org>
>> Sent: Wednesday, June 17, 2009 4:30 PM
>> Subject: Re: [Netconf] notification access control
>>
>> Randy Presuhn wrote:
>>> Hi -
>>>
>>>> From: "Andy Bierman" <andy@netconfcentral.com>
>>>> To: "Phil Shafer" <phil@juniper.net>
>>>> Cc: "NETCONF" <netconf@ietf.org>
>>>> Sent: Wednesday, June 17, 2009 1:17 PM
>>>> Subject: Re: [Netconf] notification access control
> ...
>> Since the filters will be removed from monitoring data,
>> an attacker won't really have any way of knowing which
>> sessions are trying to filter which content.  Therefore,
>> presence or absence of a notification does not really
>> mean anything.
> 
> You're only looking at the potential eavesdropper.
> Consider where the atacker is the authorized user,
> trying to ferrer out information s/he is not supposed
> to be able to have access to.
> 

How does guessing that one session received a
notification but another one didn't help here?


>> What's the problem if the agent leaves out some subtrees
>> in the payload on <get> or <notification>?  And why
>> would the ACM policy be different for <get> or <notification>
>> in NETCONF? (it's all just SSH2 channel data to me :-)
> 
> It's not the omission per se that bothers me.  It's that the
> very existence of the notification reveals information.
> That's why SNMP doesn't just consider the varbinds
> in deciding whether to forward a notification.  Now maybe
> this is covered by Netconf's access control framework,
> or maybe it isn't.
> 
>> The argument that the manager may not understand the
>> notification payload is no different than if the
>> manager did a NETCONF <get/> on the same data, and
>> a subset was returned.
> 
> I don't think anyone is making that argument.
> 
>> Obviously, any system that rejected all <get/> requests
>> with an access-denied error, would not be very usable.
>> Silently skipping over unauthorized data is needed
>> to provide a usable management system. What if an
>> SNMP MIB walk crashed with an access-control error the
>> first unauthorized node it hit?  Same problem in NETCONF, no?
> 
> How did we get from notifications into get requests?
> 

To me, a <get> and a <notification> that reveal the
same information are just 'read' operations.
I do not understand why access control should work
differently for these 2 forms of a read operation.


> Randy
> 

Andy


From randy_presuhn@mindspring.com  Wed Jun 17 18:03:00 2009
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E66B3A69E3 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 18:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6AKIf45YqSm for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 18:02:59 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 795B53A67D4 for <netconf@ietf.org>; Wed, 17 Jun 2009 18:02:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PLsH1meSvnY3sn76hnI4pgqE3AWX5Kid9JFrqEzvocQhBwlp3wYrpPKx9saO47fR; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.187.238.229] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1MH623-0001Lc-9j for netconf@ietf.org; Wed, 17 Jun 2009 21:03:11 -0400
Message-ID: <000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "NETCONF" <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com> <000c01c9efaa$f6489340$6801a8c0@oemcomputer> <4A398AAE.5000300@netconfcentral.com>
Date: Wed, 17 Jun 2009 18:03:40 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69687b3d64e5c89586c00833ff7540938313350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.187.238.229
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 01:03:00 -0000

Hi -

> From: "Andy Bierman" <andy@netconfcentral.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "NETCONF" <netconf@ietf.org>
> Sent: Wednesday, June 17, 2009 5:30 PM
> Subject: Re: [Netconf] notification access control
>
> Randy Presuhn wrote:
> > Hi -
> > 
> >> From: "Andy Bierman" <andy@netconfcentral.com>
> >> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> >> Cc: "NETCONF" <netconf@ietf.org>
> >> Sent: Wednesday, June 17, 2009 4:30 PM
> >> Subject: Re: [Netconf] notification access control
> >>
> >> Randy Presuhn wrote:
> >>> Hi -
> >>>
> >>>> From: "Andy Bierman" <andy@netconfcentral.com>
> >>>> To: "Phil Shafer" <phil@juniper.net>
> >>>> Cc: "NETCONF" <netconf@ietf.org>
> >>>> Sent: Wednesday, June 17, 2009 1:17 PM
> >>>> Subject: Re: [Netconf] notification access control
> > ...
> >> Since the filters will be removed from monitoring data,
> >> an attacker won't really have any way of knowing which
> >> sessions are trying to filter which content.  Therefore,
> >> presence or absence of a notification does not really
> >> mean anything.
> > 
> > You're only looking at the potential eavesdropper.
> > Consider where the atacker is the authorized user,
> > trying to ferrer out information s/he is not supposed
> > to be able to have access to.
> > 
> 
> How does guessing that one session received a
> notification but another one didn't help here?

That's not the issue.  Don't think about eavesdroppers.
Think about an authorized user being able to figure
out things from the information stream legitimately
delivered with "redacted" payloads.  Trivial example:
system has two users who are not allowed to see each
others' data.  By subscribing to all events, the receipt
of ones with empty or partial payloads would let one
user know what was going on with the other.

...
> > How did we get from notifications into get requests?
> > 
> 
> To me, a <get> and a <notification> that reveal the
> same information are just 'read' operations.
> I do not understand why access control should work
> differently for these 2 forms of a read operation.

A notification conveys more information than just its
payload.

Randy


From andy@netconfcentral.com  Wed Jun 17 18:47:03 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C513A6EDF for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 18:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh-+IUJRhcYi for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 18:47:03 -0700 (PDT)
Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id E15093A6EDE for <netconf@ietf.org>; Wed, 17 Jun 2009 18:47:02 -0700 (PDT)
Received: (qmail 58613 invoked from network); 18 Jun 2009 01:47:06 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.172.240 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 18 Jun 2009 01:47:06 -0000
X-YMail-OSG: K1lUtwAVM1kelgBGoP3X2sK72EQWaXtJaut1hldw4CS5yxbdDqspByuq3C8RO1Rb6ShvfTh8bcLdMmF22yJVLS7cnNvt_Qj1Ia_tiQeYoEYAENrdSqlgeVnVwNvtXscHa2m.Kuafy0QkSaJhpFb69.07jb9ELXH324EU6S9LogU9KjwkHv57JCzYPctPkOS9BeT8o.zBSRH6vxnhINMngPIdftm_t114T3QXlqShnUOABWAycz4Ma7Ph4i9Uv4RBnSX_yckKrAxkGkT8ickXApu5mJRB.o0_tQt7Rs4bzbz4rOVF
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A399C99.8060709@netconfcentral.com>
Date: Wed, 17 Jun 2009 18:47:05 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com>	<000c01c9efaa$f6489340$6801a8c0@oemcomputer>	<4A398AAE.5000300@netconfcentral.com> <000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer>
In-Reply-To: <000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 01:47:03 -0000

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <andy@netconfcentral.com>
>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
>> Cc: "NETCONF" <netconf@ietf.org>
>> Sent: Wednesday, June 17, 2009 5:30 PM
>> Subject: Re: [Netconf] notification access control
>>
>> Randy Presuhn wrote:
>>> Hi -
>>>
>>>> From: "Andy Bierman" <andy@netconfcentral.com>
>>>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
>>>> Cc: "NETCONF" <netconf@ietf.org>
>>>> Sent: Wednesday, June 17, 2009 4:30 PM
>>>> Subject: Re: [Netconf] notification access control
>>>>
>>>> Randy Presuhn wrote:
>>>>> Hi -
>>>>>
>>>>>> From: "Andy Bierman" <andy@netconfcentral.com>
>>>>>> To: "Phil Shafer" <phil@juniper.net>
>>>>>> Cc: "NETCONF" <netconf@ietf.org>
>>>>>> Sent: Wednesday, June 17, 2009 1:17 PM
>>>>>> Subject: Re: [Netconf] notification access control
>>> ...
>>>> Since the filters will be removed from monitoring data,
>>>> an attacker won't really have any way of knowing which
>>>> sessions are trying to filter which content.  Therefore,
>>>> presence or absence of a notification does not really
>>>> mean anything.
>>> You're only looking at the potential eavesdropper.
>>> Consider where the atacker is the authorized user,
>>> trying to ferrer out information s/he is not supposed
>>> to be able to have access to.
>>>
>> How does guessing that one session received a
>> notification but another one didn't help here?
> 
> That's not the issue.  Don't think about eavesdroppers.
> Think about an authorized user being able to figure
> out things from the information stream legitimately
> delivered with "redacted" payloads.  Trivial example:
> system has two users who are not allowed to see each
> others' data.  By subscribing to all events, the receipt
> of ones with empty or partial payloads would let one
> user know what was going on with the other.
> 

I don't understand.
I can't see any data on another SSH session
without knowing the keys for that other session.
There isn't any "no-auth/no-priv" in NETCONF.
The other session could be subscribed to a different
stream as well.

You can tell from watching traffic that 2 sessions
are getting significantly different sized notifications
delivered at the same time.  You don't need to be logged
in to the agent to watch another session's traffic and
guess that.


> ...
>>> How did we get from notifications into get requests?
>>>
>> To me, a <get> and a <notification> that reveal the
>> same information are just 'read' operations.
>> I do not understand why access control should work
>> differently for these 2 forms of a read operation.
> 
> A notification conveys more information than just its
> payload.
> 

How important is this threat, since all data is probably
encrypted in NETCONF?

What about utility?

Back to my example, what if the application has
a cache of the <running> config database,
and depends on the 'config-change' event
to trigger a cache refresh?  It does not
care which user changed the config, but
missing the event completely (due to operator security policy)
will break the application.


> Randy

Andy


From randy_presuhn@mindspring.com  Wed Jun 17 19:48:16 2009
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280033A6EF1 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 19:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh-IwQJt49cP for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 19:48:15 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 385513A6EFD for <netconf@ietf.org>; Wed, 17 Jun 2009 19:48:15 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=BYR9yTAypLeoEax7GR5HP/kYnhTIAev2Hl8QFVjyZLbE+XqcXbr8rPuq2uNbgDKT; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.187.238.229] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1MH7fv-0006cx-1u for netconf@ietf.org; Wed, 17 Jun 2009 22:48:27 -0400
Message-ID: <000601c9efbf$53822580$6801a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "NETCONF" <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com>	<000c01c9efaa$f6489340$6801a8c0@oemcomputer>	<4A398AAE.5000300@netconfcentral.com> <000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer> <4A399C99.8060709@netconfcentral.com>
Date: Wed, 17 Jun 2009 19:48:56 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968ae13428ae3f5804bcd3ae826d36e36b8350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.187.238.229
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 02:48:16 -0000

Hi -

> From: "Andy Bierman" <andy@netconfcentral.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "NETCONF" <netconf@ietf.org>
> Sent: Wednesday, June 17, 2009 6:47 PM
> Subject: Re: [Netconf] notification access control
...
> I don't understand.
> I can't see any data on another SSH session
> without knowing the keys for that other session.

Again that's not the issue.  Don't think about evesdroppers.
Don't think about multiple session.  Thnk about what a single
user is permitted to see on his own, properly authorized session.

> There isn't any "no-auth/no-priv" in NETCONF.
> The other session could be subscribed to a different
> stream as well.

That's not the concern.  Think about what it is possible to
infer from what one sees one one's own even stream under
this sort of access control policy.
 
> You can tell from watching traffic that 2 sessions
> are getting significantly different sized notifications
> delivered at the same time.  You don't need to be logged
> in to the agent to watch another session's traffic and
> guess that.

Doesn't matter.  Management traffic always has been and
probably always will be subject to all sorts of flow analysis
attacks. That doesn't concern me at all.

My concern is how relying on redaction of notification payloads
could leak information to an *authorized* user.

> >>> How did we get from notifications into get requests?
> >>>
> >> To me, a <get> and a <notification> that reveal the
> >> same information are just 'read' operations.
> >> I do not understand why access control should work
> >> differently for these 2 forms of a read operation.
> > 
> > A notification conveys more information than just its
> > payload.
> > 
> 
> How important is this threat, since all data is probably
> encrypted in NETCONF?

I'm not concerned about evesdroppers here.  I'm concerned
about the information leaked to authenticated users.

Simple example:
ISP has equipment with dedicated interfaces for two
companies.  Let's call them AndyCorp and RandyCorp.
Each of these companies is provided (limited) access to
its dedicated interfaces, and should be kept in the dark
about what's happening with the competitor's interfaces.
By subscribing to all notifications, RandyCorp could get
a pretty good idea what's happening at AndyCorp, even if
all the AndyCorp content was stripped from the notifications.

> What about utility?
> 
> Back to my example, what if the application has
> a cache of the <running> config database,
> and depends on the 'config-change' event
> to trigger a cache refresh?  It does not
> care which user changed the config, but
> missing the event completely (due to operator security policy)
> will break the application.

No, a config-change for information which that application is not
permitted to access is pointless.

Randy


From andy@netconfcentral.com  Wed Jun 17 20:01:05 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22FC3A68D0 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 20:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.715,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyIPAstsUsFp for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 20:01:05 -0700 (PDT)
Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 0C5433A6820 for <netconf@ietf.org>; Wed, 17 Jun 2009 20:01:05 -0700 (PDT)
Received: (qmail 18419 invoked from network); 18 Jun 2009 03:01:14 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2009 03:01:14 -0000
X-YMail-OSG: Jji.yikVM1ka_.8aIMurfzrvUokd16BDNu3tf9GjtRU1PLWYez.vpDFLhcaBOGxDtScU6rXLvlIbCckOXFxpVTKgVdf6LIAABa3dyZFd_m2TwiLpwOgAiSOR7UHFnS_eAKFCYwv7CMT_uxHMhqxgCvVorvi_..RqJdBTh5JscEm10fUmZ5MPUww5s87SBBAMtA3ARlncWDmBpZUE8sKjRFdTnPXkN1a2TqGZphVktzhwZsVNd.ysY.ll_pM8gH2EqpDbpy0v1hTI5.SiSwxtEesCwOzRTg9JyVzYPhaNheSiD77b
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A39ADF9.4060006@netconfcentral.com>
Date: Wed, 17 Jun 2009 20:01:13 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com>	<000c01c9efaa$f6489340$6801a8c0@oemcomputer>	<4A398AAE.5000300@netconfcentral.com>	<000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer>	<4A399C99.8060709@netconfcentral.com> <000601c9efbf$53822580$6801a8c0@oemcomputer>
In-Reply-To: <000601c9efbf$53822580$6801a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 03:01:05 -0000

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <andy@netconfcentral.com>
>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
>> Cc: "NETCONF" <netconf@ietf.org>
>> Sent: Wednesday, June 17, 2009 6:47 PM
>> Subject: Re: [Netconf] notification access control
> ...
>> I don't understand.
>> I can't see any data on another SSH session
>> without knowing the keys for that other session.
> 
> Again that's not the issue.  Don't think about evesdroppers.
> Don't think about multiple session.  Thnk about what a single
> user is permitted to see on his own, properly authorized session.
> 
>> There isn't any "no-auth/no-priv" in NETCONF.
>> The other session could be subscribed to a different
>> stream as well.
> 
> That's not the concern.  Think about what it is possible to
> infer from what one sees one one's own even stream under
> this sort of access control policy.
>  
>> You can tell from watching traffic that 2 sessions
>> are getting significantly different sized notifications
>> delivered at the same time.  You don't need to be logged
>> in to the agent to watch another session's traffic and
>> guess that.
> 
> Doesn't matter.  Management traffic always has been and
> probably always will be subject to all sorts of flow analysis
> attacks. That doesn't concern me at all.
> 
> My concern is how relying on redaction of notification payloads
> could leak information to an *authorized* user.
> 
>>>>> How did we get from notifications into get requests?
>>>>>
>>>> To me, a <get> and a <notification> that reveal the
>>>> same information are just 'read' operations.
>>>> I do not understand why access control should work
>>>> differently for these 2 forms of a read operation.
>>> A notification conveys more information than just its
>>> payload.
>>>
>> How important is this threat, since all data is probably
>> encrypted in NETCONF?
> 
> I'm not concerned about evesdroppers here.  I'm concerned
> about the information leaked to authenticated users.
> 
> Simple example:
> ISP has equipment with dedicated interfaces for two
> companies.  Let's call them AndyCorp and RandyCorp.
> Each of these companies is provided (limited) access to
> its dedicated interfaces, and should be kept in the dark
> about what's happening with the competitor's interfaces.
> By subscribing to all notifications, RandyCorp could get
> a pretty good idea what's happening at AndyCorp, even if
> all the AndyCorp content was stripped from the notifications.
> 

I'm not seeing the security hole here.
Why assume that the ACM cannot simply
put a filter on the eventType, which is the
most common usage of a filter?  That way
the entire notification will be dropped.

But that is up to the operator to decide by
configuring the ACM one way or another.
The vendor should use virtual routers or some
solution like that if ACM alone cannot be trusted
to prevent one org from spying on another.


>> What about utility?
>>
>> Back to my example, what if the application has
>> a cache of the <running> config database,
>> and depends on the 'config-change' event
>> to trigger a cache refresh?  It does not
>> care which user changed the config, but
>> missing the event completely (due to operator security policy)
>> will break the application.
> 
> No, a config-change for information which that application is not
> permitted to access is pointless.
> 
> Randy
> 


Andy


From randy_presuhn@mindspring.com  Wed Jun 17 20:54:51 2009
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE9D3A6A81 for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 20:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDmBk18zHRPL for <netconf@core3.amsl.com>; Wed, 17 Jun 2009 20:54:50 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 670B23A6A5A for <netconf@ietf.org>; Wed, 17 Jun 2009 20:54:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=j+Blfqle+wAOX5AMy+vG0lSD1zhKJSCbos+3rRTuJA24oGPqzt3pkUEM00KREhXN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.187.238.229] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1MH8iM-0007Yc-Cs for netconf@ietf.org; Wed, 17 Jun 2009 23:55:02 -0400
Message-ID: <000401c9efc8$9dbbd480$6801a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "NETCONF" <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com>	<000c01c9efaa$f6489340$6801a8c0@oemcomputer>	<4A398AAE.5000300@netconfcentral.com>	<000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer>	<4A399C99.8060709@netconfcentral.com> <000601c9efbf$53822580$6801a8c0@oemcomputer> <4A39ADF9.4060006@netconfcentral.com>
Date: Wed, 17 Jun 2009 20:55:25 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968755c9c7754e212ddb4cf36a36ad9a2e8350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.187.238.229
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 03:54:51 -0000

Hi -

> From: "Andy Bierman" <andy@netconfcentral.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "NETCONF" <netconf@ietf.org>
> Sent: Wednesday, June 17, 2009 8:01 PM
> Subject: Re: [Netconf] notification access control
...
> > Simple example:
> > ISP has equipment with dedicated interfaces for two
> > companies.  Let's call them AndyCorp and RandyCorp.
> > Each of these companies is provided (limited) access to
> > its dedicated interfaces, and should be kept in the dark
> > about what's happening with the competitor's interfaces.
> > By subscribing to all notifications, RandyCorp could get
> > a pretty good idea what's happening at AndyCorp, even if
> > all the AndyCorp content was stripped from the notifications.
> > 
> 
> I'm not seeing the security hole here.
> Why assume that the ACM cannot simply
> put a filter on the eventType, which is the
> most common usage of a filter?  That way
> the entire notification will be dropped.

Because both AndyCorp and RandyCorp will need to get
the same event types.  Consider a linkDown as an example.

> But that is up to the operator to decide by
> configuring the ACM one way or another.
> The vendor should use virtual routers or some
> solution like that if ACM alone cannot be trusted
> to prevent one org from spying on another.

What I'm saying is that attempts to redact notification payloads
will still leak information since you can't reasonably expect
to limit who should get a notification based on notification type alone.

Randy


From Washam.Fan@huaweisymantec.com  Thu Jun 18 00:36:12 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498313A688F for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 00:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.262
X-Spam-Level: 
X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[AWL=0.233,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-tY8lXc3aL6 for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 00:36:11 -0700 (PDT)
Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 6B35D3A67EB for <netconf@ietf.org>; Thu, 18 Jun 2009 00:36:11 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLF000ILBSBCQ40@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 18 Jun 2009 15:36:11 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLF003HMBSAJO10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 18 Jun 2009 15:36:10 +0800 (CST)
Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 18 Jun 2009 15:36:10 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: Andy Bierman <andy@netconfcentral.com>
Message-id: <fc9ddfeb1c73.4a3a5eea@huaweisymantec.com>
Date: Thu, 18 Jun 2009 15:36:10 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <4A394337.6020004@netconfcentral.com>
References: <4A394337.6020004@netconfcentral.com>
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 07:36:12 -0000

Hi,

----- Original Message -----
From: Andy Bierman <andy@netconfcentral.com>
Date: Thursday, June 18, 2009 3:25 am
Subject: [Netconf] notification access control
To: NETCONF <netconf@ietf.org>


> Hi,
>  
>  I know I keep complaining about the lack of a coherent
>  ACM in NETCONF, but the presumption of a completely
>  unspecified access control in this RFC is problematic.
>  
>  3.2, para 4:
>  
>      After generation of the <notification> element, access control is
>      applied by the server.  If a session does not have permission to
>      receive the <notification>, then it is discarded for that session,
>      and processing of the internal event is completed for that session.
>  
>  Without any actual ACM, what does 'permission' really mean?

I assume read-access.
 
>  Why is there a presumption that data delivered to a session
>  via <get> should have a different ACM architecture than data
>  delivered to the exact same session via <notification>?

I am not quite sure how data to get differentiate from notif data.
(Since Randy argue that notif data means more than the info
it contains). If yes, notif data should be dropped completely
just as current text says.
  
>  The RFC never says the agent MUST make an all-or-nothing
>  decision wrt/ granting permission to deliver the notification.
>  What if access control is enforced at a lower level,
>  in the XML generation, so no matter what RPC method is
>  trying to access /path/to/secret-password, they can't?

Although NETCONF ACM is lack, but IMO, the ACM should be
applied on XML data. (I.e., after XML generation). Sorry,
maybe I am misunderstood.

>  I will assume an implementation may silently prune
>  parts of the payload from the notification, due to access
>  control policy.  The notification MUST be dropped
>  if the <eventType> element would be filtered out,
>  in violation of the <notification> element schema.

So, if we treat the notif data as the same way as data to get,
then 3 filters might exist: vendor-defined filter for stream definition,
access control filter and user-defined filter when subscription
is created. the latter two filters should be applied to the XML
data (i.e., after <notification> element generation).

[By the way, I am not sure what <eventType> is refering to?
event stream?]

washam


From andy@netconfcentral.com  Thu Jun 18 05:00:25 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAED43A6EFB for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 05:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.609
X-Spam-Level: 
X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=0.656,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmsQYwkm7i4L for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 05:00:25 -0700 (PDT)
Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 42F0F3A6E47 for <netconf@ietf.org>; Thu, 18 Jun 2009 05:00:25 -0700 (PDT)
Received: (qmail 98314 invoked from network); 18 Jun 2009 12:00:33 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2009 12:00:33 -0000
X-YMail-OSG: vdMk_VUVM1k_AKTd3R9.73g_Ov1hVGtLxdgtc5171Z3CFyoQLWEx8O7IytriQCb.36U.S3E7LwpUz.UBTFoRMcOvw0dhw0AzfYvj9Nhpl510BntYVGoCJkt1o3O2WRTAemQCgz_i.EfXWNhLjk09MJCrfWgXTqxjskcEO4MjU2d5AhM.PkmDlH4hNS4r1AwSF3he9P1Q2.eHDKtXKVINzyGd4XvFyqc6fsI6cd9CDdQCOLYtVlkOZb.TU3D2BjI1eweoLocMWsOsSp7lBHW79tcaw_WPQzyPi0DEwUXQ7VqaSMsS1ZcHpDuEpejZzHPSkn9pQmx9nqTO7Qu01ol3
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A3A2C5F.9030003@netconfcentral.com>
Date: Thu, 18 Jun 2009 05:00:31 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com>	<000c01c9efaa$f6489340$6801a8c0@oemcomputer>	<4A398AAE.5000300@netconfcentral.com>	<000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer>	<4A399C99.8060709@netconfcentral.com>	<000601c9efbf$53822580$6801a8c0@oemcomputer>	<4A39ADF9.4060006@netconfcentral.com> <000401c9efc8$9dbbd480$6801a8c0@oemcomputer>
In-Reply-To: <000401c9efc8$9dbbd480$6801a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 12:00:26 -0000

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <andy@netconfcentral.com>
>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
>> Cc: "NETCONF" <netconf@ietf.org>
>> Sent: Wednesday, June 17, 2009 8:01 PM
>> Subject: Re: [Netconf] notification access control
> ...
>>> Simple example:
>>> ISP has equipment with dedicated interfaces for two
>>> companies.  Let's call them AndyCorp and RandyCorp.
>>> Each of these companies is provided (limited) access to
>>> its dedicated interfaces, and should be kept in the dark
>>> about what's happening with the competitor's interfaces.
>>> By subscribing to all notifications, RandyCorp could get
>>> a pretty good idea what's happening at AndyCorp, even if
>>> all the AndyCorp content was stripped from the notifications.
>>>
>> I'm not seeing the security hole here.
>> Why assume that the ACM cannot simply
>> put a filter on the eventType, which is the
>> most common usage of a filter?  That way
>> the entire notification will be dropped.
> 
> Because both AndyCorp and RandyCorp will need to get
> the same event types.  Consider a linkDown as an example.
> 

Why assume the ACM is incapable of providing this
data isolation, if that is what the operator wants?
Why assume a <get> operation on the other companies <interface>
entry can be properly protected by the ACM, but not a
<link-down> notification?

>> But that is up to the operator to decide by
>> configuring the ACM one way or another.
>> The vendor should use virtual routers or some
>> solution like that if ACM alone cannot be trusted
>> to prevent one org from spying on another.
> 
> What I'm saying is that attempts to redact notification payloads
> will still leak information since you can't reasonably expect
> to limit who should get a notification based on notification type alone.
> 

Depending on the environment, the operator can configure
the ACM to do the right thing.


> Randy

Andy




From randy_presuhn@mindspring.com  Thu Jun 18 09:59:33 2009
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB2F3A69D9 for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 09:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level: 
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PSdWb72+DQZ for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 09:59:32 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 914A33A67DA for <netconf@ietf.org>; Thu, 18 Jun 2009 09:59:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tcSZFeqjcD30QL6NXaUsolyhEdENx8oA4ZvsiiITi7AAdLLPRYLPMAsSWPnJnQmZ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [76.254.50.192] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1MHKxk-0002n8-SO for netconf@ietf.org; Thu, 18 Jun 2009 12:59:45 -0400
Message-ID: <004001c9f036$40d57140$6801a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "NETCONF" <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com>	<000c01c9efaa$f6489340$6801a8c0@oemcomputer>	<4A398AAE.5000300@netconfcentral.com>	<000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer>	<4A399C99.8060709@netconfcentral.com>	<000601c9efbf$53822580$6801a8c0@oemcomputer>	<4A39ADF9.4060006@netconfcentral.com> <000401c9efc8$9dbbd480$6801a8c0@oemcomputer> <4A3A2C5F.9030003@netconfcentral.com>
Date: Thu, 18 Jun 2009 10:00:15 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968813d7d3867828aa3f663f5d8f7248547350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.254.50.192
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 16:59:33 -0000

Hi -

> From: "Andy Bierman" <andy@netconfcentral.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "NETCONF" <netconf@ietf.org>
> Sent: Thursday, June 18, 2009 5:00 AM
> Subject: Re: [Netconf] notification access control
...
> Depending on the environment, the operator can configure
> the ACM to do the right thing.

The point is this: configuring the ACM to "do the right thing"
would mean that notification payload redaction would not
happen, because the cases where redaction would occur
should have been precluded by access control to begin with.
Or is the idea that payload redaction would function
as a kind of "harm reduction" in cases where the security
administrator didn't set up notification access control correctly?

Randy


From andy@netconfcentral.com  Thu Jun 18 10:11:58 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30DD3A69D9 for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 10:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.829
X-Spam-Level: 
X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.436,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXVGjmvpcxBU for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 10:11:58 -0700 (PDT)
Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 138063A68F3 for <netconf@ietf.org>; Thu, 18 Jun 2009 10:11:58 -0700 (PDT)
Received: (qmail 6537 invoked from network); 18 Jun 2009 17:11:51 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 18 Jun 2009 17:11:51 -0000
X-YMail-OSG: VfI7CicVM1kFYCKzWwhoxUzkk7_EIlMSHpkl5boHzEBBiVN4pf6N1SpsYxPA8yd4X9OPpHIzC9MkwTDgv8Ynk215QLjrlElclqESYm0uwPWJW6kUBM7ayDdrsqRJE2Czng6Ls4U1ghqjKkCborQdgq0COEt5Ve3_._KopX3.7YSbR0FFFTIOMNX7_F7mIfc.aWKrz84P.fsQrnOULA3amsJ9w5qZq6Q744xobUJBbIyFKJics1efnY0GBl4Ijou8Y_XyiVmRxxLRcske5bTJifwIZWBx3A9ssHDXFF60o5vR_mX0
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A3A7542.3060302@netconfcentral.com>
Date: Thu, 18 Jun 2009 10:11:30 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com>	<000c01c9efaa$f6489340$6801a8c0@oemcomputer>	<4A398AAE.5000300@netconfcentral.com>	<000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer>	<4A399C99.8060709@netconfcentral.com>	<000601c9efbf$53822580$6801a8c0@oemcomputer>	<4A39ADF9.4060006@netconfcentral.com>	<000401c9efc8$9dbbd480$6801a8c0@oemcomputer>	<4A3A2C5F.9030003@netconfcentral.com> <004001c9f036$40d57140$6801a8c0@oemcomputer>
In-Reply-To: <004001c9f036$40d57140$6801a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 17:11:58 -0000

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <andy@netconfcentral.com>
>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
>> Cc: "NETCONF" <netconf@ietf.org>
>> Sent: Thursday, June 18, 2009 5:00 AM
>> Subject: Re: [Netconf] notification access control
> ...
>> Depending on the environment, the operator can configure
>> the ACM to do the right thing.
> 
> The point is this: configuring the ACM to "do the right thing"
> would mean that notification payload redaction would not
> happen, because the cases where redaction would occur
> should have been precluded by access control to begin with.
> Or is the idea that payload redaction would function
> as a kind of "harm reduction" in cases where the security
> administrator didn't set up notification access control correctly?
> 

I don't agree with you that all-or-nothing is always the
best choice for delivering notifications.  It is up to the
operator to decide which data is sensitive.

The scenario you are describing is not well-suited to a
single monolithic agent at all.  Instead, each customer
should get their own virtual agent, and use some
sort of proprietary 'glue code' to let each virtual agent have
access to a subset of the real agent.


> Randy

Andy



From andy@netconfcentral.com  Thu Jun 18 10:36:35 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FF628C3D6 for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 10:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.024
X-Spam-Level: 
X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDgT0uG6ilbb for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 10:36:34 -0700 (PDT)
Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id 63F7128C3CD for <netconf@ietf.org>; Thu, 18 Jun 2009 10:36:34 -0700 (PDT)
Received: (qmail 55773 invoked from network); 18 Jun 2009 17:36:36 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 18 Jun 2009 17:36:36 -0000
X-YMail-OSG: 0HrHDlsVM1lj3AUBIQDvEmx7guVdoLhF7NKat3a_BIj0Y2tP9DYROwZ_MmpLSqiO_VzraHgkoT4espbz3KZoGXwcVJxiU2izWfjK4Ybr_jTeeElJgaeb4BShYRrtRKNbn8U0053A68VK7BVnPLRiVUpaGsvh13SnveNepz2rgkBJUsirl83HR1g8YvoXpxupv6aFbQb1J3LgLill3j53yGvZlI9cBMt5dG4uCaE0vqJ6yjhyo7uLn43dEyjLNjOHy8heWghmIOxDhtdkxOcI3CeoxZ37dzxjBWRApbdcVIm3Uo1cyVdyFWmBvpre7aQGsPcUdFepD4KjMXRD2ozJsec4
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A3A7B22.2050401@netconfcentral.com>
Date: Thu, 18 Jun 2009 10:36:34 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Netconf] SSH question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 17:36:35 -0000

Hi,


You know about openssh, and the ClientAliveInterval messages
that it sends (keepalive@openssh.com)?  The client is
supposed to send data on the channel before N of these
arrive.

It seems that libssh2 drops these messages.
But if the NETCONF manager wanted to answer,
what can it send to the agent?  whitespace?
an XML comment?

Is the agent supposed to handle (discard) non-PDU messages
received on its channel? What is the most interoperable
way to send data to the agent without actually issuing
an <rpc> and wasting resources?


thanks,
Andy


From randy_presuhn@mindspring.com  Thu Jun 18 10:41:07 2009
Return-Path: <randy_presuhn@mindspring.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36EC53A6AAF for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 10:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level: 
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021,  BAYES_00=-2.599, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYuCyF8A0o-i for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 10:41:06 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 5D0C33A6891 for <netconf@ietf.org>; Thu, 18 Jun 2009 10:41:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sQ4+l8sxl9sajw/wnsrqXV/mmyr9im/Rtto3lCnr8vAJz/emcij6ZJMTO605P8RB; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [76.254.50.192] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1MHLby-0005kC-Lk for netconf@ietf.org; Thu, 18 Jun 2009 13:41:18 -0400
Message-ID: <007101c9f03c$0f506200$6801a8c0@oemcomputer>
From: "Randy Presuhn" <randy_presuhn@mindspring.com>
To: "NETCONF" <netconf@ietf.org>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com>	<000c01c9efaa$f6489340$6801a8c0@oemcomputer>	<4A398AAE.5000300@netconfcentral.com>	<000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer>	<4A399C99.8060709@netconfcentral.com>	<000601c9efbf$53822580$6801a8c0@oemcomputer>	<4A39ADF9.4060006@netconfcentral.com>	<000401c9efc8$9dbbd480$6801a8c0@oemcomputer>	<4A3A2C5F.9030003@netconfcentral.com> <004001c9f036$40d57140$6801a8c0@oemcomputer> <4A3A7542.3060302@netconfcentral.com>
Date: Thu, 18 Jun 2009 10:41:49 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968a5a093b61fc1cd968cdaa14ba96332a0350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.254.50.192
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 17:41:07 -0000

Hi -

> From: "Andy Bierman" <andy@netconfcentral.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "NETCONF" <netconf@ietf.org>
> Sent: Thursday, June 18, 2009 10:11 AM
> Subject: Re: [Netconf] notification access control
...
> The scenario you are describing is not well-suited to a
> single monolithic agent at all.

I do have a strong bias against monolithic agents.

I think they spell software configuration management
disaster for complex or multi-vendor systems.  But
the current IETF direction seems to be to not worry about
those cases, and let them define their own solutions
as the need arises.  I don't think that was a good choice,
but this is not the place to re-hash old debates.

>  Instead, each customer
> should get their own virtual agent, and use some
> sort of proprietary 'glue code' to let each virtual agent have
> access to a subset of the real agent.

"And then a miracle occurs."  :-)

We have clearly different visions of how to make this stuff
work, so I guess I'll just have to wait until we see how that
glue code actually works.  But I am concerned that these
decisions will inexorably paint the developers of the netconf
ACM (or, more likely, ACMs) into a corner.

Randy


From andy@netconfcentral.com  Thu Jun 18 10:54:06 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6834328C3F6 for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 10:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.058
X-Spam-Level: 
X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.542,  BAYES_00=-2.599, TVD_PH_SUBJ_META=0]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6-CKtk8WlOB for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 10:54:05 -0700 (PDT)
Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 44CB43A6B1E for <netconf@ietf.org>; Thu, 18 Jun 2009 10:53:38 -0700 (PDT)
Received: (qmail 11018 invoked from network); 18 Jun 2009 17:53:46 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 18 Jun 2009 17:53:46 -0000
X-YMail-OSG: VkNsnWYVM1kwcpu0uWq8grnDrqlXNXgFVRbyXMnKb6hC_BbG2k3xtxFp6FR8A98MZZc3MJk2lQJc0pEILAwnO4nbUZAaLtg2mrwqDrBfMApBcPLVYiNloEUCNcECAMhDSG3VD7iGKKBsDLeGH8TA1bdGxKFjxgcyA07AVfAKYbyUjfwHii7.ojdLeTP2RJfmnXSAX.OP2SCPuTOWDGwHrCfVuo6tGAAW0gWUKSOzPnOGsqlxGLe0RKMPszPyFHSrC127J0MFSRZ1i5_fVOSk6Pr8zn_vZm44cfP1XPJA63Xrf_23emiuRIFhDaDhJzSzW_UUwSysKlq.sY.Binjn
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A3A7F28.9010603@netconfcentral.com>
Date: Thu, 18 Jun 2009 10:53:44 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Randy Presuhn <randy_presuhn@mindspring.com>
References: <200906171944.n5HJiBBo056500@idle.juniper.net>	<4A394F71.4090500@netconfcentral.com>	<001201c9ef9c$832a64a0$6801a8c0@oemcomputer>	<4A397C90.1050801@netconfcentral.com>	<000c01c9efaa$f6489340$6801a8c0@oemcomputer>	<4A398AAE.5000300@netconfcentral.com>	<000401c9efb0$9eb7d4a0$6801a8c0@oemcomputer>	<4A399C99.8060709@netconfcentral.com>	<000601c9efbf$53822580$6801a8c0@oemcomputer>	<4A39ADF9.4060006@netconfcentral.com>	<000401c9efc8$9dbbd480$6801a8c0@oemcomputer>	<4A3A2C5F.9030003@netconfcentral.com>	<004001c9f036$40d57140$6801a8c0@oemcomputer>	<4A3A7542.3060302@netconfcentral.com> <007101c9f03c$0f506200$6801a8c0@oemcomputer>
In-Reply-To: <007101c9f03c$0f506200$6801a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] notification access control
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 17:54:06 -0000

Randy Presuhn wrote:
> Hi -
> 
>> From: "Andy Bierman" <andy@netconfcentral.com>
>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
>> Cc: "NETCONF" <netconf@ietf.org>
>> Sent: Thursday, June 18, 2009 10:11 AM
>> Subject: Re: [Netconf] notification access control
> ...
>> The scenario you are describing is not well-suited to a
>> single monolithic agent at all.
> 
> I do have a strong bias against monolithic agents.
> 
> I think they spell software configuration management
> disaster for complex or multi-vendor systems.  But
> the current IETF direction seems to be to not worry about
> those cases, and let them define their own solutions
> as the need arises.  I don't think that was a good choice,
> but this is not the place to re-hash old debates.
> 
>>  Instead, each customer
>> should get their own virtual agent, and use some
>> sort of proprietary 'glue code' to let each virtual agent have
>> access to a subset of the real agent.
> 
> "And then a miracle occurs."  :-)
> 
> We have clearly different visions of how to make this stuff
> work, so I guess I'll just have to wait until we see how that
> glue code actually works.  But I am concerned that these
> decisions will inexorably paint the developers of the netconf
> ACM (or, more likely, ACMs) into a corner.
> 

This is already being done with CLI, so I imagine
someday a NETCONF version might show up.

The problem with ACMs is that they are always too hard
to configure, so they don't get used. That's why I am
experimenting with 'schema content tagging'.
That way, with zero-config, the defaults do the right thing.
(e.g., tag the password leaf as 'very-secure' in the YANG file
with an extension, and the agent knows not to let it be
accessed at all by default (no ACL found)).

> Randy
> 

Andy


From mbj@tail-f.com  Thu Jun 18 11:09:47 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24AC28C118 for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 11:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iWLV440DWps for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 11:09:47 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 00BCB3A6860 for <netconf@ietf.org>; Thu, 18 Jun 2009 11:09:46 -0700 (PDT)
Received: from localhost (213-65-181-236-no181.tbcn.telia.com [213.65.181.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 00A1C616001; Thu, 18 Jun 2009 20:09:58 +0200 (CEST)
Date: Thu, 18 Jun 2009 20:09:58 +0200 (CEST)
Message-Id: <20090618.200958.246661251.mbj@tail-f.com>
To: andy@netconfcentral.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4A3A7B22.2050401@netconfcentral.com>
References: <4A3A7B22.2050401@netconfcentral.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] SSH question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 18:09:48 -0000

Andy Bierman <andy@netconfcentral.com> wrote:
> Hi,
> 
> 
> You know about openssh, and the ClientAliveInterval messages
> that it sends (keepalive@openssh.com)?  The client is
> supposed to send data on the channel before N of these
> arrive.
> 
> It seems that libssh2 drops these messages.

Are you sure?  It's supposed to reply with an error if it doesn't
understand the request, since WantReply is set.

> But if the NETCONF manager wanted to answer,
> what can it send to the agent?  whitespace?
> an XML comment?
> 
> Is the agent supposed to handle (discard) non-PDU messages
> received on its channel? 

This is unclear.  At least the counter inBadRpcs will be incremented.
One school of thought says that if garbage is received, the session
should be dropped.

> What is the most interoperable
> way to send data to the agent without actually issuing
> an <rpc> and wasting resources?

I think you have to send an rpc.  kill-session on your own session id
should be cheap (just hope the server is 4741 compliant :)


/martin

From andy@netconfcentral.com  Thu Jun 18 11:52:22 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299F43A68DE for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 11:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.115
X-Spam-Level: 
X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.485,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlThWYX9O55Z for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 11:52:21 -0700 (PDT)
Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by core3.amsl.com (Postfix) with SMTP id 441AA3A69ED for <netconf@ietf.org>; Thu, 18 Jun 2009 11:52:21 -0700 (PDT)
Received: (qmail 26324 invoked from network); 18 Jun 2009 18:52:22 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 18 Jun 2009 18:52:21 -0000
X-YMail-OSG: xFy3iTYVM1kAGjcCU6oJuTadLpsqQp1TN5DjwO7SniSt56NuEdi17GwdnTfAWwekxDFI0WrnjabN1ynoMthCMea92S.Kqt7vgTcFxloxZMHHCdgdsaX8Cqa6v0Ufs8R3ZCyBPdS3lAvXTeR8ttD4Ap_DCtbqEa8r5BLN1upxEW.lJJv4pB._caf4A3Tr2EMfEIfxN9.yCic2xjkugE6tXjRlYp.9x5GRwA56yAm3g_ZKKlKvQPvl4DkEiD7GF7yHgYql5TyUilWynTR6MS5E5D3sJz6ZTMhgN9CSlOJ7zsAdBzxMtIBl
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A3A8CCE.3050202@netconfcentral.com>
Date: Thu, 18 Jun 2009 11:51:58 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <4A3A7B22.2050401@netconfcentral.com> <20090618.200958.246661251.mbj@tail-f.com>
In-Reply-To: <20090618.200958.246661251.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] SSH question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 18:52:22 -0000

Martin Bjorklund wrote:
> Andy Bierman <andy@netconfcentral.com> wrote:
>> Hi,
>>
>>
>> You know about openssh, and the ClientAliveInterval messages
>> that it sends (keepalive@openssh.com)?  The client is
>> supposed to send data on the channel before N of these
>> arrive.
>>
>> It seems that libssh2 drops these messages.
> 
> Are you sure?  It's supposed to reply with an error if it doesn't
> understand the request, since WantReply is set.
> 

well, there's nothing for the channel to read (EAGAIN),
even though the select() says there is.  Not sure if
it is pilot error on my part or not.


>> But if the NETCONF manager wanted to answer,
>> what can it send to the agent?  whitespace?
>> an XML comment?
>>
>> Is the agent supposed to handle (discard) non-PDU messages
>> received on its channel? 
> 
> This is unclear.  At least the counter inBadRpcs will be incremented.
> One school of thought says that if garbage is received, the session
> should be dropped.
> 
>> What is the most interoperable
>> way to send data to the agent without actually issuing
>> an <rpc> and wasting resources?
> 
> I think you have to send an rpc.  kill-session on your own session id
> should be cheap (just hope the server is 4741 compliant :)
> 

I agree that the RFC text does not offer much wiggle room here.

I don't want to increment counters, especially error counters.
I wish there was a no-op() command in NETCONF.

A <get> may not be that cheap:

      <get>
        <filter>bogus</filter>
      </get>

   returns

      <data></data>

   right away.


> 
> /martin
> 
> 

Andy


From j.schoenwaelder@jacobs-university.de  Thu Jun 18 13:27:34 2009
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436333A69AE for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 13:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.219
X-Spam-Level: 
X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09mJ-3O6Jz5G for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 13:27:33 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 03FCF3A67A1 for <netconf@ietf.org>; Thu, 18 Jun 2009 13:27:33 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E6F2C004E; Thu, 18 Jun 2009 22:27:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1CFtHXFgtzTs; Thu, 18 Jun 2009 22:27:44 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0B31C004B; Thu, 18 Jun 2009 22:27:43 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B0138B47999; Thu, 18 Jun 2009 22:27:42 +0200 (CEST)
Date: Thu, 18 Jun 2009 22:27:42 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@netconfcentral.com>
Message-ID: <20090618202742.GA12298@elstar.local>
Mail-Followup-To: Andy Bierman <andy@netconfcentral.com>, NETCONF <netconf@ietf.org>
References: <4A3A7B22.2050401@netconfcentral.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A3A7B22.2050401@netconfcentral.com>
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: NETCONF <netconf@ietf.org>
Subject: Re: [Netconf] SSH question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 20:27:34 -0000

On Thu, Jun 18, 2009 at 07:36:34PM +0200, Andy Bierman wrote:
 
> You know about openssh, and the ClientAliveInterval messages
> that it sends (keepalive@openssh.com)?  The client is
> supposed to send data on the channel before N of these
> arrive.
> 
> It seems that libssh2 drops these messages.
> But if the NETCONF manager wanted to answer,
> what can it send to the agent?  whitespace?
> an XML comment?
> 
> Is the agent supposed to handle (discard) non-PDU messages
> received on its channel? What is the most interoperable
> way to send data to the agent without actually issuing
> an <rpc> and wasting resources?

I think you are confusing protocol layers. The keepalive@openssh.com
messages are sent as part of the SSH Connection Protocol (see RFC
4254) and they should trigger an SSH Connection Protocol reply. They
should never show up in the data stream carried over an SSH channel.
If they do, then the SSH implementation needs to be fixed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From andy@netconfcentral.com  Thu Jun 18 18:43:11 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9E43A67E6 for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 18:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.024
X-Spam-Level: 
X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.241,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnjYHVu3Fvo0 for <netconf@core3.amsl.com>; Thu, 18 Jun 2009 18:43:10 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 6DD2A3A67A1 for <netconf@ietf.org>; Thu, 18 Jun 2009 18:43:10 -0700 (PDT)
Received: (qmail 53856 invoked from network); 19 Jun 2009 01:43:20 -0000
Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.173.161 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 19 Jun 2009 01:43:20 -0000
X-YMail-OSG: nzvdfukVM1kstmTmaFudN8kG6A2mMmF1Y78ImEEf2Mn69jPV_8ZN5N__bynwi9hOzfG9O5x6xpDCF0Yoo.lnMM58F.4UfmDfj0uRpmiOmh.eVUZ0DL4WlHcOKO32rRE3MXztfeIMl6dHU.i0vUtkgx0ZHn5EUxdPcSLRQIk.Rxp6Ed1cA4AC7nmErsRtueaYJg1bJQIqwBpPZwynLliOuJhgwbX25h7rSYXiJNiae5Ho7ZxDJU.6opnuaTm8Cj49cN0eaKNhctruWj5946Fs0Dhrsp8Kz4FeGInAzZdMgsoktOA7ZrS2
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A3AED21.1020903@netconfcentral.com>
Date: Thu, 18 Jun 2009 18:42:57 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Andy Bierman <andy@netconfcentral.com>, NETCONF <netconf@ietf.org>
References: <4A3A7B22.2050401@netconfcentral.com> <20090618202742.GA12298@elstar.local>
In-Reply-To: <20090618202742.GA12298@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Netconf] SSH question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2009 01:43:11 -0000

Juergen Schoenwaelder wrote:
> On Thu, Jun 18, 2009 at 07:36:34PM +0200, Andy Bierman wrote:
>  
>> You know about openssh, and the ClientAliveInterval messages
>> that it sends (keepalive@openssh.com)?  The client is
>> supposed to send data on the channel before N of these
>> arrive.
>>
>> It seems that libssh2 drops these messages.
>> But if the NETCONF manager wanted to answer,
>> what can it send to the agent?  whitespace?
>> an XML comment?
>>
>> Is the agent supposed to handle (discard) non-PDU messages
>> received on its channel? What is the most interoperable
>> way to send data to the agent without actually issuing
>> an <rpc> and wasting resources?
> 
> I think you are confusing protocol layers. The keepalive@openssh.com
> messages are sent as part of the SSH Connection Protocol (see RFC
> 4254) and they should trigger an SSH Connection Protocol reply. They
> should never show up in the data stream carried over an SSH channel.
> If they do, then the SSH implementation needs to be fixed.
> 

thanks.
you are right -- these are CHANNEL_REQUEST messages,
not CHANNEL_DATA messages. Not sure what libssh2 is
answering with, but it isn't working (yet).


> /js
> 

Andy


From dromasca@avaya.com  Wed Jun 24 00:58:21 2009
Return-Path: <dromasca@avaya.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73843A6F2F for <netconf@core3.amsl.com>; Wed, 24 Jun 2009 00:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.456
X-Spam-Level: 
X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOJMW2NbF1XJ for <netconf@core3.amsl.com>; Wed, 24 Jun 2009 00:58:21 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 73CAC3A6F16 for <netconf@ietf.org>; Wed, 24 Jun 2009 00:58:20 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,281,1243828800"; d="scan'208";a="149415778"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Jun 2009 03:57:04 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jun 2009 03:57:03 -0400
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
Date: Wed, 24 Jun 2009 09:56:43 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040180821B@307622ANEX5.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Gen-ART review of draft-ietf-netconf-partial-lock-08.txt
thread-index: Acn0TqQVaxe7SBEQQkqCV9aMlUJkmQAUqkVA
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "netconf mailing list" <netconf@ietf.org>
Subject: [Netconf] FW: Gen-ART review of draft-ietf-netconf-partial-lock-08.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2009 07:58:21 -0000

=20

-----Original Message-----
From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=20
Sent: Wednesday, June 24, 2009 1:03 AM
To: General Area Review Team;
draft-ietf-netconf-partial-lock.all@tools.ietf.org
Subject: Gen-ART review of draft-ietf-netconf-partial-lock-08.txt

I am the assigned Gen-ART reviewer for
draft-ietf-netconf-partial-lock-08.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

Summary: This draft is almost ready for publication as Proposed Standard
but I have a couple of comments.

Major
=3D=3D=3D=3D=3D

* Section 2.4.1 page 7 paragraph 3 "Let's say ..."

The following text is confusing

"If someone later creates a new user, this new user will not be included
in the locked-nodes list created previously, the new user will not be
locked."

It is unclear how this is even possible given there is a partial lock on
all the users that was obtained using the following select parameter

        <select xmlns:usr=3D"http://example.com/users">
          /usr:top/usr:users
        </select>

Can you please clarify what you mean here?

Minor
=3D=3D=3D=3D=3D

* Section 2.1.1.3

The scenario described here does not really describe a deadlock as
deadlock requires two competing actions waiting for each other to
finish. I do not know what to call it but this is certainly not a
deadlock :-) and the deadlock avoidance measures described in section
2.4.1.2 will not fix this problem.

* IANA considerations

- The section states that "This document registers two URIs..." but it
only registers one. Either another URI is missing or this text needs to
be changed.

- It is also not clear where the :partial-lock capability is being
allocated from. I guess it is coming from the NETCONF Capability URNs
registry.

Thanks
Suresh






From balazs.lengyel@ericsson.com  Thu Jun 25 06:47:00 2009
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031133A6AC3 for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 06:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.216
X-Spam-Level: 
X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vakf1HZ9dJ95 for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 06:46:58 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 34B073A6A05 for <netconf@ietf.org>; Thu, 25 Jun 2009 06:46:57 -0700 (PDT)
X-AuditID: c1b4fb3e-b7be1ae000004757-7d-4a436593f2a2
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 2B.96.18263.395634A4; Thu, 25 Jun 2009 13:54:59 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 25 Jun 2009 13:54:59 +0200
Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 25 Jun 2009 13:54:58 +0200
Message-ID: <4A436592.6060306@ericsson.com>
Date: Thu, 25 Jun 2009 13:54:58 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: netconf mailing list <netconf@ietf.org>
References: <4A41511A.1050006@ericsson.com>
In-Reply-To: <4A41511A.1050006@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jun 2009 11:54:58.0617 (UTC) FILETIME=[C382FA90:01C9F58B]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [Netconf] Gen-ART review of draft-ietf-netconf-partial-lock-08.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 13:47:00 -0000

fyi

Suresh Krishnan wrote:
> I am the assigned Gen-ART reviewer for
> draft-ietf-netconf-partial-lock-08.txt
> 
> For background on Gen-ART, please see the FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Summary: This draft is almost ready for publication as Proposed Standard 
> but I have a couple of comments.
> 
> Major
> =====
> 
> * Section 2.4.1 page 7 paragraph 3 "Let's say ..."
> 
> The following text is confusing
> 
> "If someone later creates a new user, this new user will not be included 
> in the locked-nodes list created previously, the new user will not be 
> locked."
> 
> It is unclear how this is even possible given there is a partial lock on 
> all the users that was obtained using the following select parameter
> 
>        <select xmlns:usr="http://example.com/users">
>          /usr:top/usr:users
>        </select>
> 
> Can you please clarify what you mean here?

BALAZS:
(Examples without namespaces and with some simplifications)
Lets assume we have the following model

container top {
   list user {
     key name;
     // data about individual user
   }
}

with  management data like

<top>
   <user>
     <name>Paul</name>
   </user>
   <user>
     <name>Suresh</name>
   </user>
</top>

The case mentioned in the paragraph is if the XPath is
<select>
    /usr:top/usr:user
</select>

The above expression will select every individual user at the time of locking (Paul, Suresh).
However if we use

<edit-config>
   <config>
     <top>
       <user>
         <name>Joe</name>
       </user>
     </top>
   </config>
</edit-config>

A new user Joe is added. Joe is not locked in this case.

The text mentions the "list of 'user' nodes". A node called "userS" is not mentioned.

> 
> Minor
> =====
> 
> * Section 2.1.1.3
> 
> The scenario described here does not really describe a deadlock as 
> deadlock requires two competing actions waiting for each other to 
> finish. I do not know what to call it but this is certainly not a 
> deadlock :-) and the deadlock avoidance measures described in section 
> 2.4.1.2 will not fix this problem.

BALAZS: Is the following wording better/OK?

When multiple managers use the candidate configuration in parallel,
there is a risk that the interaction of access control (which is still
implementation specific at the time of this writing) and the commit
operation ___ might result in a manager becoming unable both to commit
or discard changes___, as illustrated by the following sequence.

> 
> * IANA considerations
> 
> - The section states that "This document registers two URIs..." but it 
> only registers one. Either another URI is missing or this text needs to 
> be changed.
(AFAIK an URN is an URI as well.)
> 
> - It is also not clear where the :partial-lock capability is being 
> allocated from. I guess it is coming from the NETCONF Capability URNs 
> registry.
So is the following modification OK?

This document registers one capability identifier URN from the NETCONF Capability URNs
registry, and one URI for the NETCONF XML namespace in the
IETF XML registry [RFC3688].  Note that the capability URN is
compliant to [NETCONF] section 10.3.

> Thanks
> Suresh
> 
> 
> 
> 
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel@ericsson.com


From root@core3.amsl.com  Thu Jun 25 08:00:01 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id A7D143A6B74; Thu, 25 Jun 2009 08:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090625150001.A7D143A6B74@core3.amsl.com>
Date: Thu, 25 Jun 2009 08:00:01 -0700 (PDT)
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action:draft-ietf-netconf-monitoring-05.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 15:00:01 -0000

--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, et al.
	Filename        : draft-ietf-netconf-monitoring-05.txt
	Pages           : 43
	Date            : 2009-06-25

This document defines a NETCONF data model (in XML Schema) to be used
to monitor the NETCONF protocol.  The monitoring data model includes
information about NETCONF datastores, sessions, locks and statistics.
This data facilitates the management of a NETCONF server.  This
document also defines methods for NETCONF clients to discover data
models supported by a NETCONF server and defines a new NETCONF <get-
schema> operation to retrieve them.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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: Message/External-body;
	name="draft-ietf-netconf-monitoring-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-06-25075221.I-D@ietf.org>


--NextPart--

From MARKSCOT@nortel.com  Thu Jun 25 08:07:34 2009
Return-Path: <MARKSCOT@nortel.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374F428C1AE for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 08:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qudLJZgJSBVE for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 08:07:33 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2514C28C1A3 for <netconf@ietf.org>; Thu, 25 Jun 2009 08:07:33 -0700 (PDT)
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5PF3p526810 for <netconf@ietf.org>; Thu, 25 Jun 2009 15:03:51 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Thu, 25 Jun 2009 11:05:13 -0400
Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D198F35EB@zcarhxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New Version Notification for draft-ietf-netconf-monitoring-05 
Thread-Index: Acn1pJdEGDWYqkz7SrCXNa1w0LXxRAAABaVQ
From: "Mark Scott" <markscot@nortel.com>
To: "netconf mailing list" <netconf@ietf.org>
Subject: [Netconf] FW: New Version Notification for draft-ietf-netconf-monitoring-05
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 15:07:34 -0000

SGVsbG8sDQoNCkEgbmV3IHZlcnNpb24gKHY1KSBvZiB0aGUgTkVUQ09ORiBNb25pdG9yaW5nIFNj
aGVtYSBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQuDQoNClRoaXMgdmVyc2lvbiBhZGRyZXNzZXMgYWN0
aW9uIGl0ZW1zIGZyb20gSUVURjc0IGFuZCBjb21tZW50cyByZWNlaXZlZCBvbiB2NC4gIENoYW5n
ZXMgaW5jbHVkZToNCi0gdXBkYXRlZCBzdGF0aXN0aWNzIChhbmQgY291bnRlciBkZWZpbml0aW9u
cykgcGVyIG9mZmxpbmUgZGlzY3Vzc2lvbjoNCgktIHVwZGF0ZWQgY291bnRlciBkZWZpbml0aW9u
cw0KCS0gdXBkYXRlZCBkYXRhIHR5cGVzICAoYWRkaXRpb24gb2YgWmVyb0Jhc2VkQ291bnRlcjMy
KQ0KCS0gcGVyIHNlc3Npb24gY291bnRlcnM7ICBzZWUgc2VjdGlvbiAyLjEuNA0KCS0gZ2xvYmFs
IGNvdW50ZXJzOyAgc2VlIHNlY3Rpb24gMi4xLjUNCi0gdW5pcXVlIHNlc3Npb25JZCBoYW5kbGlu
ZyBhbmQgV0cgY29uc2Vuc3VzOg0KCS0gZXhwZWN0ZWQgaGFuZGxpbmcgb2YgTkVUQ09ORiBhbmQg
bm9uLU5FVENPTkYgc2Vzc2lvbnMgZGVmaW5lZA0KCS0gZXhwbGljaXQgZXhjbHVzaW9uIG9mIHNl
c3Npb25JZD0wIGFkZGVkDQoJLSBzZWUgc2VjdGlvbiAyLjEuNA0KLSByZW1vdmFsIG9mIHN1YnNj
cmlwdGlvbnMgc3VidHJlZTsgIHdhcyBzZWMgMi4xLjUgaW4gdjQNCi0gcmV2aXNlZCBYU0QgYW5k
IFlBTkcgbW9kZWxzDQoNClRoYW5rIHlvdSB0byBhbGwgd2hvIHByb3ZpZGVkIGNvbW1lbnRzIGFu
ZCBwYXJ0aWNpcGF0ZWQgaW4gdGhlIG9mZmxpbmUgZGlzY3Vzc2lvbnMuDQoNClBsZWFzZSBkaXJl
Y3QgYWxsIGNvbW1lbnRzIG9uIHRoaXMgbmV3IHZlcnNpb24gdG8gdGhlIE1MIGZvciBmdXJ0aGVy
IGNvbnNpZGVyYXRpb24uDQoNCmNoZWVycywNCk1hcmsNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNz
aW9uQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI1LCAyMDA5IDEwOjUyIEFNDQpU
bzogU2NvdHQsIE1hcmsgKENBUjoyTjAwKQ0KQ2M6IENoaXNob2xtLCBTaGFyb24gKENBUjpaWjAw
KTsgbWJqQHRhaWwtZi5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig
ZHJhZnQtaWV0Zi1uZXRjb25mLW1vbml0b3JpbmctMDUgDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ
LUQsIGRyYWZ0LWlldGYtbmV0Y29uZi1tb25pdG9yaW5nLTA1LnR4dCBoYXMgYmVlbiBzdWNjZXNz
ZnVseSBzdWJtaXR0ZWQgYnkgTWFyayBTY290dCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z
aXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1uZXRjb25mLW1vbml0b3JpbmcNClJldmlz
aW9uOgkgMDUNClRpdGxlOgkJIE5FVENPTkYgTW9uaXRvcmluZyBTY2hlbWENCkNyZWF0aW9uX2Rh
dGU6CSAyMDA5LTA2LTI0DQpXRyBJRDoJCSBuZXRjb25mDQpOdW1iZXJfb2ZfcGFnZXM6IDQzDQoN
CkFic3RyYWN0Og0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgTkVUQ09ORiBkYXRhIG1vZGVsIChp
biBYTUwgU2NoZW1hKSB0byBiZSB1c2VkDQp0byBtb25pdG9yIHRoZSBORVRDT05GIHByb3RvY29s
LiAgVGhlIG1vbml0b3JpbmcgZGF0YSBtb2RlbCBpbmNsdWRlcw0KaW5mb3JtYXRpb24gYWJvdXQg
TkVUQ09ORiBkYXRhc3RvcmVzLCBzZXNzaW9ucywgbG9ja3MgYW5kIHN0YXRpc3RpY3MuDQpUaGlz
IGRhdGEgZmFjaWxpdGF0ZXMgdGhlIG1hbmFnZW1lbnQgb2YgYSBORVRDT05GIHNlcnZlci4gIFRo
aXMNCmRvY3VtZW50IGFsc28gZGVmaW5lcyBtZXRob2RzIGZvciBORVRDT05GIGNsaWVudHMgdG8g
ZGlzY292ZXIgZGF0YQ0KbW9kZWxzIHN1cHBvcnRlZCBieSBhIE5FVENPTkYgc2VydmVyIGFuZCBk
ZWZpbmVzIGEgbmV3IE5FVENPTkYgPGdldC0NCnNjaGVtYT4gb3BlcmF0aW9uIHRvIHJldHJpZXZl
IHRoZW0uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJp
YXQuDQoNCg0K

From reid@snmp.com  Thu Jun 25 11:12:29 2009
Return-Path: <reid@snmp.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BBF3A6E03 for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 11:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEFY07wflGC0 for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 11:12:29 -0700 (PDT)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id B4C703A686A for <netconf@ietf.org>; Thu, 25 Jun 2009 11:12:28 -0700 (PDT)
Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA26013 for <netconf@ietf.org>; Thu, 25 Jun 2009 14:12:02 -0400 (EDT)
Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA17955 for <netconf@ietf.org>; Thu, 25 Jun 2009 14:12:02 -0400 (EDT)
Message-Id: <200906251812.OAA17955@adminfs.snmp.com>
To: netconf@ietf.org
Date: Thu, 25 Jun 2009 14:12:01 -0400
From: David Reid <reid@snmp.com>
Subject: [Netconf] xml start directive with ssh
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 18:12:29 -0000

>From rfc4742 page 3:

   Once the SSH session has been established, the user (or application)
   will invoke NETCONF as an SSH subsystem called "netconf".  Subsystem
   support is a feature of SSH version 2 (SSHv2) and is not included in
   SSHv1.  Running NETCONF as an SSH subsystem avoids the need for the
   script to recognize shell prompts or skip over extraneous
   information, such as a system message that is sent at shell start-up.
   However, even when a subsystem is used, some extraneous messages may
   be printed by the user's start-up scripts.  Implementations MUST skip
   over these messages by searching for an 'xml' start directive, which
   MUST be followed by a <hello> element in the 'NETCONF' namespace.


I want to make sure I understand this correctly. Does this mean:

Both the netconf client and server MUST send an xml start directive before
the <hello> message and MAY send an xml start directive before any other
message when running over SSH.

When not running over SSH, the xml start directive is always optional.

Anything sent by either the client or server before the xml start directive
MUST be ignored when running over SSH.

When not running over SSH, any extraneous data results in a parse error.

-David Reid 

From phil@juniper.net  Thu Jun 25 11:59:57 2009
Return-Path: <phil@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E5A28C17C for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 11:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.462
X-Spam-Level: 
X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9an+9vBmhPA for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 11:59:56 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 6DDCB3A67E2 for <netconf@ietf.org>; Thu, 25 Jun 2009 11:59:49 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSkPI89UplCwiHaxZanoVsMfnhwzh9CfF@postini.com; Thu, 25 Jun 2009 12:00:14 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 25 Jun 2009 11:28:13 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 11:28:13 -0700
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 11:28:13 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 11:28:12 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5PISCL63131; Thu, 25 Jun 2009 11:28:12 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n5PIHHlI018841; Thu, 25 Jun 2009 18:17:17 GMT (envelope-from phil@idle.juniper.net)
Message-ID: <200906251817.n5PIHHlI018841@idle.juniper.net>
To: David Reid <reid@snmp.com>
In-Reply-To: <200906251812.OAA17955@adminfs.snmp.com> 
Date: Thu, 25 Jun 2009 14:17:17 -0400
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 25 Jun 2009 18:28:12.0616 (UTC) FILETIME=[B2A18480:01C9F5C2]
MIME-Version: 1.0
Content-Type: text/plain
Cc: netconf@ietf.org
Subject: Re: [Netconf] xml start directive with ssh
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 18:59:57 -0000

David Reid writes:
>>From rfc4742 page 3:
>
>   Once the SSH session has been established, the user (or application)
>   will invoke NETCONF as an SSH subsystem called "netconf".  Subsystem
>   support is a feature of SSH version 2 (SSHv2) and is not included in
>   SSHv1.  Running NETCONF as an SSH subsystem avoids the need for the
>   script to recognize shell prompts or skip over extraneous
>   information, such as a system message that is sent at shell start-up.
>   However, even when a subsystem is used, some extraneous messages may
>   be printed by the user's start-up scripts.  Implementations MUST skip
>   over these messages by searching for an 'xml' start directive, which
>   MUST be followed by a <hello> element in the 'NETCONF' namespace.

IMHO this is not right.  An SSH subsystem won't run "user's start-up
scripts", so the skipping issue is moot.  Also "'xml' start directive"
should be "XML Declaration", but that's minor.

>Both the netconf client and server MUST send an xml start directive before
>the <hello> message and MAY send an xml start directive before any other
>message when running over SSH.

Since hello and other messages are individual XML documents, they
MAY being with an XML declaration.

>Anything sent by either the client or server before the xml start directive
>MUST be ignored when running over SSH.

This is what it says, but I don't see this as real world.

>When not running over SSH, any extraneous data results in a parse error.

This RFC can't say anything about other transports.

Thanks,
 Phil

From Washam.Fan@huaweisymantec.com  Thu Jun 25 18:52:35 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B9B3A693B for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 18:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.368
X-Spam-Level: 
X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=1.231,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fITIbLchq93 for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 18:52:35 -0700 (PDT)
Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id C98593A687C for <netconf@ietf.org>; Thu, 25 Jun 2009 18:52:34 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLT00DP4P7ZX660@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 26 Jun 2009 09:52:48 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLT00KTXP7Z6K00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 26 Jun 2009 09:52:47 +0800 (CST)
Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 26 Jun 2009 09:52:47 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: Phil Shafer <phil@juniper.net>
Message-id: <fc9ee3fe57e4.4a449a6f@huaweisymantec.com>
Date: Fri, 26 Jun 2009 09:52:47 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <200906251817.n5PIHHlI018841@idle.juniper.net>
References: <200906251812.OAA17955@adminfs.snmp.com> <200906251817.n5PIHHlI018841@idle.juniper.net>
Cc: netconf@ietf.org
Subject: Re: [Netconf] xml start directive with ssh
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 01:52:35 -0000

Hi,

>  >Both the netconf client and server MUST send an xml start directive 
> before
>  >the <hello> message and MAY send an xml start directive before any other
>  >message when running over SSH.
>  
>  Since hello and other messages are individual XML documents, they
>  MAY being with an XML declaration.

>From this sentence:

   Implementations MUST skip
   over these messages by searching for an 'xml' start directive, which
   MUST be followed by a <hello> element in the 'NETCONF' namespace.

<hello> message with an XML declaration is a MUST.

washam


From andy@netconfcentral.com  Thu Jun 25 19:50:31 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03813A6849 for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 19:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.209
X-Spam-Level: 
X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzkkBA09aeZB for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 19:50:30 -0700 (PDT)
Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 9FCCA3A67E3 for <netconf@ietf.org>; Thu, 25 Jun 2009 19:50:30 -0700 (PDT)
Received: (qmail 84567 invoked from network); 26 Jun 2009 02:50:46 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 26 Jun 2009 02:50:46 -0000
X-YMail-OSG: 22horNMVM1mp4X36i9srKESI2oiEuQEFAQtqfT.vvOR0lVNmUXgbNeA_b6hySEvZME1jqubEKJmVC8Zd1mZx2c1MyOx02wEBHvJ2Aqx5QYmd0D1aduXOAJSr66fVbWKruew8Z9B02iRHAP4jkVbeQNtPUq.FvswSAbbdERZk_iRxbyTZnn1f6on5qvbTvMa2PTBDmYcjlshKWw5BF4JBs4RICT3vC.2.momseafNBn368RjcQzcoVa5Oc2bb6gE.cxfmWWqUpP4IuJSFrsrxj0y3os43asY9gg9ZhQtcN8cjjJoO7r8d
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A443788.2080904@netconfcentral.com>
Date: Thu, 25 Jun 2009 19:50:48 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
MIME-Version: 1.0
To: WashamFan <Washam.Fan@huaweisymantec.com>
References: <200906251812.OAA17955@adminfs.snmp.com>	<200906251817.n5PIHHlI018841@idle.juniper.net> <fc9ee3fe57e4.4a449a6f@huaweisymantec.com>
In-Reply-To: <fc9ee3fe57e4.4a449a6f@huaweisymantec.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] xml start directive with ssh
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 02:50:31 -0000

WashamFan wrote:
> Hi,
> 
>>  >Both the netconf client and server MUST send an xml start directive 
>> before
>>  >the <hello> message and MAY send an xml start directive before any other
>>  >message when running over SSH.
>>  
>>  Since hello and other messages are individual XML documents, they
>>  MAY being with an XML declaration.
> 
>>From this sentence:
> 
>    Implementations MUST skip
>    over these messages by searching for an 'xml' start directive, which
>    MUST be followed by a <hello> element in the 'NETCONF' namespace.
> 
> <hello> message with an XML declaration is a MUST.
>

This text is a perfect example of the "CLI mentality" in place
when NETCONF was written.  It was assumed that implementations
would do a normal CLI login, and then magically (or manually)
switch to "NETCONF mode", after a bunch of screen-scraping.
(Wrong!)

IMO, this text should be removed somehow.  NETCONF agents should
expect only a stream of XML instance documents, not garbage text
sometimes.  The replacement text should say the manager MUST send
only complete XML instance documents (PDUs) and nothing else.

I doubt any agents actually support this requirement.
Since a manager has to explicitly start up the 'netconf' subsystem
in its implementation, there is no reason whatsoever for
the manager to send garbage text after that.
The manager knows (regardless of port number) whether it
is connecting to a plain CLI or to a NETCONF session.
At the time 4742 was written, nobody in the WG was aware of how
SSH subsystems actually worked.




> washam

Andy

From phil@juniper.net  Thu Jun 25 20:35:53 2009
Return-Path: <phil@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA023A6A8C for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 20:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.477
X-Spam-Level: 
X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91vU9c-xn3cI for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 20:35:53 -0700 (PDT)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id E08CD3A6835 for <netconf@ietf.org>; Thu, 25 Jun 2009 20:35:46 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSkRCHphOYYoxF4m/jRl8o4oewDJsM8Wt@postini.com; Thu, 25 Jun 2009 20:36:08 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Thu, 25 Jun 2009 20:31:16 -0700
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 20:31:16 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 20:31:16 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 20:31:15 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5Q3VFL43753; Thu, 25 Jun 2009 20:31:15 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n5Q3KKs6023872; Fri, 26 Jun 2009 03:20:20 GMT (envelope-from phil@idle.juniper.net)
Message-ID: <200906260320.n5Q3KKs6023872@idle.juniper.net>
To: Andy Bierman <andy@netconfcentral.com>
In-Reply-To: <4A443788.2080904@netconfcentral.com> 
Date: Thu, 25 Jun 2009 23:20:19 -0400
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 26 Jun 2009 03:31:15.0503 (UTC) FILETIME=[8F8B83F0:01C9F60E]
MIME-Version: 1.0
Content-Type: text/plain
Cc: netconf@ietf.org
Subject: Re: [Netconf] xml start directive with ssh
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 03:35:53 -0000

Andy Bierman writes:
>This text is a perfect example of the "CLI mentality" in place
>when NETCONF was written.  It was assumed that implementations
>would do a normal CLI login, and then magically (or manually)
>switch to "NETCONF mode", after a bunch of screen-scraping.

This is the part that makes no sense, since NETCONF uses SSH's
subsystem mechanism.  There's no CLI login stuff going on.  The
sshd runs the netconf subsystem directly with no login shell, making
it perfectly suitable for use as a protocol transfer (just like
sftp).  I agree these words need removed.

Thanks,
 Phil

From Washam.Fan@huaweisymantec.com  Thu Jun 25 20:45:02 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE2B3A6A8C for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 20:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.418
X-Spam-Level: 
X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=0.077,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuUdrpEKFdf8 for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 20:45:02 -0700 (PDT)
Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id D0A5D3A6A57 for <netconf@ietf.org>; Thu, 25 Jun 2009 20:45:01 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLT002KXUDRDZ60@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 26 Jun 2009 11:44:15 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLT00L4EUDR8G10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 26 Jun 2009 11:44:15 +0800 (CST)
Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 26 Jun 2009 11:44:15 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: netconf@ietf.org
Message-id: <fbe3cb002a34.4a44b48f@huaweisymantec.com>
Date: Fri, 26 Jun 2009 11:44:15 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
Subject: [Netconf] about subtree filtering
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 03:45:02 -0000

Hi,

>From sec6.4.6, rfc4741, there is a request using subtree:

   <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user>
                 <name>fred</name>
                 <type/>
                 <full-name/>
               </user>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

But what if users contains another element, let's say <role>
and I also want it returned, so is it legal, and is it returned as
the intent?

   <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user>
                 <name>fred</name>
                 <type/>
                 <full-name/>
               </user>
               <role/>                            <!-- user's sibling-->
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

Thanks,
washam

From andy@netconfcentral.com  Thu Jun 25 21:47:11 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B42B3A67F8 for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 21:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.222
X-Spam-Level: 
X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmTDTShaSMjU for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 21:47:10 -0700 (PDT)
Received: from n63.bullet.mail.sp1.yahoo.com (n63.bullet.mail.sp1.yahoo.com [98.136.44.33]) by core3.amsl.com (Postfix) with SMTP id 96EDE3A685C for <netconf@ietf.org>; Thu, 25 Jun 2009 21:47:10 -0700 (PDT)
Received: from [216.252.122.219] by n63.bullet.mail.sp1.yahoo.com with NNFMP; 26 Jun 2009 04:45:18 -0000
Received: from [68.142.200.224] by t4.bullet.sp1.yahoo.com with NNFMP; 26 Jun 2009 04:45:18 -0000
Received: from [68.142.201.243] by t5.bullet.mud.yahoo.com with NNFMP; 26 Jun 2009 04:45:18 -0000
Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 26 Jun 2009 04:45:17 -0000
X-Yahoo-Newman-Id: 979566.13193.bm@omp404.mail.mud.yahoo.com
Received: (qmail 93694 invoked from network); 26 Jun 2009 04:45:17 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 26 Jun 2009 04:45:17 -0000
X-YMail-OSG: AlzMxhMVM1lI55V.RzDT4DcCmHhXNwuyTfVw3NidqWGd7QkJ5Dw3YKrFTBBKi_atFbUJr8_gstQ5EMkM_rPcW05HsrVdkL3YPUx2F.LSH_jlCregIvSvtRIXijmqqm3Vw.Gp3kczgDp3iEnSEXw5oEqPrGhKX52sNKQifCS5Gz_FSuzMl13TBc0pJtlAzNaJwduZlLLnuMg1L.ENAZZPBHH265j8wENYgF1u8GqsVc3VLRRQcC7tzqOssw_XBj8cXiABGNDWWVR0HiqFmbNIukS1pZIVxyk5J5BIqWB7TMb.Vkir6nvs
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A4451E5.1050404@netconfcentral.com>
Date: Thu, 25 Jun 2009 21:43:17 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
MIME-Version: 1.0
To: WashamFan <Washam.Fan@huaweisymantec.com>
References: <fbe3cb002a34.4a44b48f@huaweisymantec.com>
In-Reply-To: <fbe3cb002a34.4a44b48f@huaweisymantec.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] about subtree filtering
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 04:47:11 -0000

WashamFan wrote:
> Hi,
> 
>>From sec6.4.6, rfc4741, there is a request using subtree:
> 
>    <rpc message-id="101"
>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>        <get-config>
>          <source>
>            <running/>
>          </source>
>          <filter type="subtree">
>            <top xmlns="http://example.com/schema/1.2/config">
>              <users>
>                <user>
>                  <name>fred</name>
>                  <type/>
>                  <full-name/>
>                </user>
>              </users>
>            </top>
>          </filter>
>        </get-config>
>      </rpc>
> 
> But what if users contains another element, let's say <role>
> and I also want it returned, so is it legal, and is it returned as
> the intent?
> 
>    <rpc message-id="101"
>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>        <get-config>
>          <source>
>            <running/>
>          </source>
>          <filter type="subtree">
>            <top xmlns="http://example.com/schema/1.2/config">
>              <users>
>                <user>
>                  <name>fred</name>
>                  <type/>
>                  <full-name/>
>                </user>
>                <role/>                            <!-- user's sibling-->
>              </users>
>            </top>
>          </filter>
>        </get-config>
>      </rpc>
> 

This is fine.
This is just another selection node, like if <user/> was empty.
If there is no <role> in the entry, the whole thing will be
left out, because the select nodes form an AND expression.

> Thanks,
> washam

Andy


From mbj@tail-f.com  Thu Jun 25 23:54:11 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900BF3A67FA for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 23:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.157,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pAZ7o6HuzxR for <netconf@core3.amsl.com>; Thu, 25 Jun 2009 23:54:11 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 581873A6969 for <netconf@ietf.org>; Thu, 25 Jun 2009 23:53:55 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 36A8B616004; Fri, 26 Jun 2009 08:53:17 +0200 (CEST)
Date: Fri, 26 Jun 2009 08:53:16 +0200 (CEST)
Message-Id: <20090626.085316.22629704.mbj@tail-f.com>
To: andy@netconfcentral.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4A4451E5.1050404@netconfcentral.com>
References: <fbe3cb002a34.4a44b48f@huaweisymantec.com> <4A4451E5.1050404@netconfcentral.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] about subtree filtering
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 06:54:11 -0000

Andy Bierman <andy@netconfcentral.com> wrote:
> This is fine.

Yes.

> This is just another selection node, like if <user/> was empty.
> If there is no <role> in the entry, the whole thing will be
> left out, because the select nodes form an AND expression.

No, selection nodes do not form AND expressions - content match nodes
do.  So even if no users/role exists, the fred user will be returned
(if it exists).


/martin

From Washam.Fan@huaweisymantec.com  Fri Jun 26 00:59:38 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50F63A68C4 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 00:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.424
X-Spam-Level: 
X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rzzkk65DuEFg for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 00:59:38 -0700 (PDT)
Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id EC0823A684C for <netconf@ietf.org>; Fri, 26 Jun 2009 00:59:37 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLU002CJ66FDZ90@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 26 Jun 2009 15:59:03 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLU00KFR66FQ010@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 26 Jun 2009 15:59:03 +0800 (CST)
Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 26 Jun 2009 15:59:03 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: Martin Bjorklund <mbj@tail-f.com>
Message-id: <fc9e84d263e3.4a44f047@huaweisymantec.com>
Date: Fri, 26 Jun 2009 15:59:03 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <20090626.085316.22629704.mbj@tail-f.com>
References: <fbe3cb002a34.4a44b48f@huaweisymantec.com> <4A4451E5.1050404@netconfcentral.com> <20090626.085316.22629704.mbj@tail-f.com>
Cc: netconf@ietf.org
Subject: Re: [Netconf] about subtree filtering
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 07:59:38 -0000

> Andy Bierman <andy@netconfcentral.com> wrote:
>  > This is fine.
>  
>  Yes.
>  
>  > This is just another selection node, like if <user/> was empty.
>  > If there is no <role> in the entry, the whole thing will be
>  > left out, because the select nodes form an AND expression.
>  
>  No, selection nodes do not form AND expressions - content match nodes
>  do.  So even if no users/role exists, the fred user will be returned
>  (if it exists).

Actually, that is what I want. I want all possible info about fred.
If fred has the role, please return the role info, elsewise, just return me
the basic info.

Thanks,
washam

>  /martin
>  

From mbj@tail-f.com  Fri Jun 26 02:23:24 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442923A67A4 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 02:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.137,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VGYXVL7wOCe for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 02:23:23 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 492F63A6784 for <netconf@ietf.org>; Fri, 26 Jun 2009 02:23:23 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 57EBF616004; Fri, 26 Jun 2009 10:34:27 +0200 (CEST)
Date: Fri, 26 Jun 2009 10:34:26 +0200 (CEST)
Message-Id: <20090626.103426.178042103.mbj@tail-f.com>
To: Washam.Fan@huaweisymantec.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <fc9e84d263e3.4a44f047@huaweisymantec.com>
References: <4A4451E5.1050404@netconfcentral.com> <20090626.085316.22629704.mbj@tail-f.com> <fc9e84d263e3.4a44f047@huaweisymantec.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] about subtree filtering
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 09:23:24 -0000

WashamFan <Washam.Fan@huaweisymantec.com> wrote:
> > Andy Bierman <andy@netconfcentral.com> wrote:
> >  > This is fine.
> >  
> >  Yes.
> >  
> >  > This is just another selection node, like if <user/> was empty.
> >  > If there is no <role> in the entry, the whole thing will be
> >  > left out, because the select nodes form an AND expression.
> >  
> >  No, selection nodes do not form AND expressions - content match nodes
> >  do.  So even if no users/role exists, the fred user will be returned
> >  (if it exists).
> 
> Actually, that is what I want. I want all possible info about fred.

Ok.

> If fred has the role, please return the role info, elsewise, just return me
> the basic info.

This is probably just fine, but note that in your example you did:

             <users>
               <user>
                 <name>fred</name>
                 <type/>
                 <full-name/>
               </user>
               <role/>                            <!-- user's sibling-->
             </users>

Which would correspond to this:

  container users {
      list user { ... }
      leaf role { ... }
  }

so the role - in your example - isn't a property of the user, but a
global property for all users.


The reasoning applies even if we do:

  container users {
      list user {
          ...
          leaf role { ... }
      }
  }




/martin

From Washam.Fan@huaweisymantec.com  Fri Jun 26 02:26:10 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20BE3A6855 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 02:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.481
X-Spam-Level: 
X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=1.118,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+R-9toRUY71 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 02:26:08 -0700 (PDT)
Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 808443A6784 for <netconf@ietf.org>; Fri, 26 Jun 2009 02:26:08 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLU00HAXA6VWN20@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 26 Jun 2009 17:25:44 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLU00KMGA6VSV10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 26 Jun 2009 17:25:43 +0800 (CST)
Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 26 Jun 2009 17:25:43 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: Martin Bjorklund <mbj@tail-f.com>
Message-id: <fc53b76f3ea1.4a450497@huaweisymantec.com>
Date: Fri, 26 Jun 2009 17:25:43 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <20090626.103426.178042103.mbj@tail-f.com>
References: <4A4451E5.1050404@netconfcentral.com> <20090626.085316.22629704.mbj@tail-f.com> <fc9e84d263e3.4a44f047@huaweisymantec.com> <20090626.103426.178042103.mbj@tail-f.com>
Cc: netconf@ietf.org
Subject: Re: [Netconf] about subtree filtering
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 09:26:10 -0000

Hi,

----- Original Message -----
From: Martin Bjorklund <mbj@tail-f.com>
Date: Friday, June 26, 2009 4:35 pm
Subject: Re: [Netconf] about subtree filtering
To: Washam.Fan@huaweisymantec.com
Cc: andy@netconfcentral.com, netconf@ietf.org


> WashamFan <Washam.Fan@huaweisymantec.com> wrote:
>  > > Andy Bierman <andy@netconfcentral.com> wrote:
>  > >  > This is fine.
>  > >  
>  > >  Yes.
>  > >  
>  > >  > This is just another selection node, like if <user/> was empty.
>  > >  > If there is no <role> in the entry, the whole thing will be
>  > >  > left out, because the select nodes form an AND expression.
>  > >  
>  > >  No, selection nodes do not form AND expressions - content match 
> nodes
>  > >  do.  So even if no users/role exists, the fred user will be returned
>  > >  (if it exists).
>  > 
>  > Actually, that is what I want. I want all possible info about fred.
>  
>  Ok.
>  
>  > If fred has the role, please return the role info, elsewise, just 
> return me
>  > the basic info.
>  
>  This is probably just fine, but note that in your example you did:
>  
>               <users>
>                 <user>
>                   <name>fred</name>
>                   <type/>
>                   <full-name/>
>                 </user>
>                 <role/>                            <!-- user's sibling-->
>               </users>
>  
>  Which would correspond to this:
>  
>    container users {
>        list user { ... }
>        leaf role { ... }
>    }
>  
>  so the role - in your example - isn't a property of the user, but a
>  global property for all users.
>  
>  
>  The reasoning applies even if we do:
>  
>    container users {
>        list user {
>            ...
>            leaf role { ... }
>        }
>    }
>  
Well, the data model might like this:

   container users {
     list user {
       container basic {
          leaf name { ...}
          leaf type {...}
          leaf full-name { ... }
       }
       leaf role { ... }
     }
   }

So, the filter

   <users>
      <user>
        <basic>
           <name>fred</name>
           <type/>
           <full-name/>
        </basic>
        <role/>
      </user>
    </users>

will help return what I want?

Thanks,
washam

   

From mbj@tail-f.com  Fri Jun 26 04:58:01 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB813A6AB2 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 04:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level: 
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.122,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U3Fy1A8O194 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 04:58:01 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D69CD3A68ED for <netconf@ietf.org>; Fri, 26 Jun 2009 04:58:00 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C683616004; Fri, 26 Jun 2009 13:18:58 +0200 (CEST)
Date: Fri, 26 Jun 2009 13:18:58 +0200 (CEST)
Message-Id: <20090626.131858.25987560.mbj@tail-f.com>
To: Washam.Fan@huaweisymantec.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <fc53b76f3ea1.4a450497@huaweisymantec.com>
References: <fc9e84d263e3.4a44f047@huaweisymantec.com> <20090626.103426.178042103.mbj@tail-f.com> <fc53b76f3ea1.4a450497@huaweisymantec.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] about subtree filtering
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 11:58:01 -0000

WashamFan <Washam.Fan@huaweisymantec.com> wrote:
> Well, the data model might like this:
> 
>    container users {
>      list user {
>        container basic {
>           leaf name { ...}
>           leaf type {...}
>           leaf full-name { ... }
>        }
>        leaf role { ... }
>      }
>    }
> 
> So, the filter
> 
>    <users>
>       <user>
>         <basic>
>            <name>fred</name>
>            <type/>
>            <full-name/>
>         </basic>
>         <role/>
>       </user>
>     </users>
> 
> will help return what I want?

Assuming this is config, the data model is not quite correct - the
list lacks a key.  So if we do:

    container users {
      list user {
        key name;
        leaf name { ...}
        container basic {
           leaf type {...}
           leaf full-name { ... }
        }
        leaf role { ... }
      }
    }

Then the filter:

    <users>
       <user>
         <name>fred</name>
         <basic>
            <type/>
            <full-name/>
         </basic>
         <role/>
       </user>
     </users>

will return the type, full-name, and role of "fred", if they exist,
which is what you want.

However, the filter:

    <users>
       <user>
         <basic>
            <type/>
            <full-name>Fred Flintstone</full-name>
         </basic>
         <role/>
       </user>
     </users>

will return the role of *all* users, and the type of Fred.


/martin

From mbj@tail-f.com  Fri Jun 26 05:31:20 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538BD3A684F for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 05:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.936
X-Spam-Level: 
X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L3OFYEw1moY for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 05:31:19 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7D2D93A67DB for <netconf@ietf.org>; Fri, 26 Jun 2009 05:31:18 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 4BB0B616015; Fri, 26 Jun 2009 14:29:18 +0200 (CEST)
Date: Fri, 26 Jun 2009 14:29:18 +0200 (CEST)
Message-Id: <20090626.142918.117864005.mbj@tail-f.com>
To: rgcole01@comcast.net, andy@netconfcentral.com, dromasca@avaya.com
From: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: [Netconf] draft-cole-netconf-robust-config-01
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 12:31:20 -0000

Hi,

I have read this document, and I think the ideas presented are very
interesting.

But I have a comment on the solution you have chosen to trigger the
tests.  It seems you have re-invented confirmed commit, with some
additional parameters.  IMO, the existing confirmed commit operation
is well suited for the things you want to do (maybe it was even
designed to be able to handle this kind of use case).  Why don't you
simply add a new operation <start-test> that can be used to trigger
the tests at the server when the conrimed commit is active?  This
would look like:

            +------------------------------>
             Sets up <candidate> config

            +------------------------------>
             Sets up test control

   ---      +------------------------------>
    |        Sends <commit> <confirmed>
   (set             - timeout
    timeout)
    |        <-----------------------------+
    |                              reply(OK)
    |      +------------------------------>
    |        Sends <start-test>
    |         - test-template:instanceID
    |        <-----------------------------+
    |                              reply(OK)
   (running                                  (run server-side tests)
    client-side
    tests)
    |                                        (server-side test success)
    |        <-----------------------------+
    |         <verifiedCommitStatus = good> notification
    |
    |
    |        +----------------------------->
    |         Sends <commit> (confirming)
    |
    |        <-----------------------------+
    |                              reply(OK)
    |
   ---


One advantage of this is that is can also be used on servers that have
startup instead of candidate, (with the normal disadvantages of this
design):

   make changes to running
   set up test control
   <start-test>
   if test-ok: copy running to startup
   if test-fail: revert running



/martin

From Washam.Fan@huaweisymantec.com  Fri Jun 26 06:45:58 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913F53A6AF5 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 06:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level: 
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-fWH2YWC+rs for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 06:45:57 -0700 (PDT)
Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id A1AD13A6AD3 for <netconf@ietf.org>; Fri, 26 Jun 2009 06:45:57 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLU001ZAM8THX20@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 26 Jun 2009 21:46:05 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLU00B42M8TA220@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 26 Jun 2009 21:46:05 +0800 (CST)
Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Fri, 26 Jun 2009 21:46:05 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: Martin Bjorklund <mbj@tail-f.com>
Message-id: <fc00fde85218.4a45419d@huaweisymantec.com>
Date: Fri, 26 Jun 2009 21:46:05 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <20090626.131858.25987560.mbj@tail-f.com>
References: <fc9e84d263e3.4a44f047@huaweisymantec.com> <20090626.103426.178042103.mbj@tail-f.com> <fc53b76f3ea1.4a450497@huaweisymantec.com> <20090626.131858.25987560.mbj@tail-f.com>
Cc: netconf@ietf.org
Subject: Re: [Netconf] about subtree filtering
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 13:45:58 -0000

Hi,

----- Original Message -----
From: Martin Bjorklund <mbj@tail-f.com>
Date: Friday, June 26, 2009 7:19 pm
Subject: Re: [Netconf] about subtree filtering
To: Washam.Fan@huaweisymantec.com
Cc: andy@netconfcentral.com, netconf@ietf.org


> WashamFan <Washam.Fan@huaweisymantec.com> wrote:
> > Well, the data model might like this:
> > 
> >    container users {
> >      list user {
> >        container basic {
> >           leaf name { ...}
> >           leaf type {...}
> >           leaf full-name { ... }
> >        }
> >        leaf role { ... }
> >      }
> >    }
> > 
> > So, the filter
> > 
> >    <users>
> >       <user>
> >         <basic>
> >            <name>fred</name>
> >            <type/>
> >            <full-name/>
> >         </basic>
> >         <role/>
> >       </user>
> >     </users>
> > 
> > will help return what I want?
> 
> Assuming this is config, the data model is not quite correct - the
> list lacks a key.  So if we do:
> 
>     container users {
>       list user {
>         key name;
>         leaf name { ...}
>         container basic {
>            leaf type {...}
>            leaf full-name { ... }
>         }
>         leaf role { ... }
>       }
>     }
> 
> Then the filter:
> 
>     <users>
>        <user>
>          <name>fred</name>
>          <basic>
>             <type/>
>             <full-name/>
>          </basic>
>          <role/>
>        </user>
>      </users>
> 
> will return the type, full-name, and role of "fred", if they exist,
> which is what you want.
> 
> However, the filter:
> 
>     <users>
>        <user>
>          <basic>
>             <type/>
>             <full-name>Fred Flintstone</full-name>
>          </basic>
>          <role/>
>        </user>
>      </users>
> 
> will return the role of *all* users, and the type of Fred.

So, <role> is only constrained by the key, but not the 
siblings. What if <role> is under a container:

   container owner {
     container basic {
       leaf name { ... }
       leaf type { ... }
       leaf full-name { ... }
     }
     leaf role { ... }
   }

When the belowing filter is applied:

   <owner>
     <basic>
       <name>fred</name>
       <type/>
       <full-name/>
     </basic>
     <role/>
   </owner>

If the current owner is fred, the name, type, full-name as well as
role (if exists) of fred would be returned, right?
If the current owner is fan, the name, type, full-name of
fan would not be returned, but would the role of fan be returned?

washam

From phil@juniper.net  Fri Jun 26 07:38:34 2009
Return-Path: <phil@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF973A6B84 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 07:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.489
X-Spam-Level: 
X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhyLzUv4-9v7 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 07:38:33 -0700 (PDT)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 806A43A6AEA for <netconf@ietf.org>; Fri, 26 Jun 2009 07:38:33 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSkTddKlzCRehjLMwokUefiposm9Lvt2t@postini.com; Fri, 26 Jun 2009 07:38:52 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 26 Jun 2009 07:03:31 -0700
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Jun 2009 07:03:30 -0700
Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Jun 2009 07:03:30 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jun 2009 07:03:29 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5QE3ML19610; Fri, 26 Jun 2009 07:03:22 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n5QDqQJ9026637; Fri, 26 Jun 2009 13:52:26 GMT (envelope-from phil@idle.juniper.net)
Message-ID: <200906261352.n5QDqQJ9026637@idle.juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20090626.142918.117864005.mbj@tail-f.com> 
Date: Fri, 26 Jun 2009 09:52:26 -0400
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 26 Jun 2009 14:03:29.0659 (UTC) FILETIME=[E2105CB0:01C9F666]
MIME-Version: 1.0
Content-Type: text/plain
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] draft-cole-netconf-robust-config-01
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 14:38:34 -0000

Martin Bjorklund writes:
>Why don't you
>simply add a new operation <start-test> that can be used to trigger
>the tests at the server when the conrimed commit is active?

Another thing to consider that the nature of the test are typically
interwoven with the architecture of the network and the characteristics
of the change.  What test do you perform when you:

(a) change a BGP export filter
(b) change an AS number
(c) add a BGPVPN site

(a) would only affect your peer(s), (b) could have serious impact (but
that's what you wanted), and (c) should have no impact on existing
peers/sites/etc.

So given that the application is making the change, and that testing
the change is integrated with both the change and the customer
network architecture, why not use the existing "commit confirmed"
mechanism and have the application drive the testing of changes
using remote RPCs to get information off the box re: the impact
of the change?  This seems much more straight forward and was
what we had in mind from the start.

Thanks,
 Phil

From andy@netconfcentral.com  Fri Jun 26 08:04:28 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049733A6B45 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 08:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level: 
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VTuvGZR7bC5 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 08:04:27 -0700 (PDT)
Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by core3.amsl.com (Postfix) with SMTP id 22A8F3A6B86 for <netconf@ietf.org>; Fri, 26 Jun 2009 08:03:49 -0700 (PDT)
Received: (qmail 35339 invoked from network); 26 Jun 2009 15:01:48 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 26 Jun 2009 15:01:47 -0000
X-YMail-OSG: PIkS7HcVM1lh1W3vkl0r1eYbvvgzSvKQySxWki0zNYpcle15MPCI.pKp5nrPD2C8omcaJEvwyAFbAQrpyehywueWnyeEPcSQEsgNMM18zPrvsiyYqhb0PjzYm_Vsay0S6jFeJF_ZhOjSZIYNm4wTr9S810NSCTaAhqjF4omfZksYUZN7elZfx6IziMBr3aKTod9PpBdUCGvRbKaNKDqzFBHby3EI3Ly83Fv7GUoBPyYJVdaG8qyH0mvJMUmiG2ImjvSPlap6UaZjVaWVDzV2j3SqcPblHm77O_t4uat6GwMe4XavZDCe
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A44E2DE.2060509@netconfcentral.com>
Date: Fri, 26 Jun 2009 08:01:50 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <20090626.142918.117864005.mbj@tail-f.com>
In-Reply-To: <20090626.142918.117864005.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] draft-cole-netconf-robust-config-01
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 15:04:28 -0000

Martin Bjorklund wrote:
> Hi,
> 
> I have read this document, and I think the ideas presented are very
> interesting.
> 
> But I have a comment on the solution you have chosen to trigger the
> tests.  It seems you have re-invented confirmed commit, with some
> additional parameters.  IMO, the existing confirmed commit operation
> is well suited for the things you want to do (maybe it was even
> designed to be able to handle this kind of use case).  Why don't you
> simply add a new operation <start-test> that can be used to trigger
> the tests at the server when the conrimed commit is active?  This
> would look like:


I prefer the design of the verified commit over the confirmed commit.

  1) using the same command multiple times to do different things
     is confusing and prone to errors (user B's first <commit>
     can actually be used as user A's 2nd commit.  That's broken.)

  2) there is no way to cancel a confirmed-commit, other than
     by dropping the session.  This is not very clean.

  3) the lack of notifications makes confirmed commit harder to
     use in a network-wide config change.

  4) overloading the <commit> operation with more modes is more
     confusing than using a new operation.


Andy

> 
>             +------------------------------>
>              Sets up <candidate> config
> 
>             +------------------------------>
>              Sets up test control
> 
>    ---      +------------------------------>
>     |        Sends <commit> <confirmed>
>    (set             - timeout
>     timeout)
>     |        <-----------------------------+
>     |                              reply(OK)
>     |      +------------------------------>
>     |        Sends <start-test>
>     |         - test-template:instanceID
>     |        <-----------------------------+
>     |                              reply(OK)
>    (running                                  (run server-side tests)
>     client-side
>     tests)
>     |                                        (server-side test success)
>     |        <-----------------------------+
>     |         <verifiedCommitStatus = good> notification
>     |
>     |
>     |        +----------------------------->
>     |         Sends <commit> (confirming)
>     |
>     |        <-----------------------------+
>     |                              reply(OK)
>     |
>    ---
> 
> 
> One advantage of this is that is can also be used on servers that have
> startup instead of candidate, (with the normal disadvantages of this
> design):
> 
>    make changes to running
>    set up test control
>    <start-test>
>    if test-ok: copy running to startup
>    if test-fail: revert running
> 
> 
> 
> /martin
> 


From balazs.lengyel@ericsson.com  Fri Jun 26 09:22:42 2009
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82D83A6B6C for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 09:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.222
X-Spam-Level: 
X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2Jym9dAOpWv for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 09:22:41 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 39C1F3A6A67 for <netconf@ietf.org>; Fri, 26 Jun 2009 09:22:41 -0700 (PDT)
X-AuditID: c1b4fb3c-b7bdcae0000052f9-82-4a44f5e222c9
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C3.A9.21241.2E5F44A4; Fri, 26 Jun 2009 18:22:58 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 26 Jun 2009 18:22:56 +0200
Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 26 Jun 2009 18:22:55 +0200
Message-ID: <4A44F70A.2050006@ericsson.com>
Date: Fri, 26 Jun 2009 18:27:54 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: Mark Scott <markscot@nortel.com>
References: <085091CB2CA14E4B8B163FFC37C84E9D198F35EB@zcarhxm0.corp.nortel.com>
In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D198F35EB@zcarhxm0.corp.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Jun 2009 16:22:55.0357 (UTC) FILETIME=[5C6892D0:01C9F67A]
X-Brightmail-Tracker: AAAAAA==
Cc: netconf mailing list <netconf@ietf.org>
Subject: Re: [Netconf] FW: New Version Notification for	draft-ietf-netconf-monitoring-05
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 16:22:42 -0000

Hello Mark,
Some comments:
General)
I think we should not exclude the possibility of monitoring non-netconf sessions in this schema.

2.1.2) "The /netconf-state/datastores subtree contains configuration data"
This seems to indicate it contains writable data. I know that was not your intention, so please 
reword.

Some changes to the paragraph starting with "For partial locks the list":
For partial locks the list of locked nodes and the select expressions originally used to 
request the lock are returned. The scope of the partial lock is defined by the list of locked 
nodes. This list might change during the lifetime of the lock.
The select expressions indicate the original intended scope of the lock.

Ch 2.1.3)
YIN should be added as a format.
s/One of more locations/Zero one of more locations/

2.1.4) in several places you use "a <rpc> message was expected"
Who expects it? Does the device know that an <edit-config> should be arriving at 7:00 PM? :-) 
Rather remove the expected part.

2.1.5) Please indicate if droppedSessions includes session closed due to parseErrors.

3.1)
- One XML error, search for ><
- negative response missing

3.2)
- s/schema may be supported in multiple locations/schema may be available in multiple locations/
- first paragraph last sentence is trivial, remove it.
- Why do you have a negative response section here? Does this belong to 3.1?

5) didn't check XSD. How about generating it automatically from YANG? That would more or less 
remove the need to review it.

9) Include non-normative references for yang and yang-types

Appendix)
- location should be a leaf-list not a leaf
- get-schema output: if we have a YANG schema will it will be a string not any XML
- the level of descriptions is uneven in this YAM

Balazs


Mark Scott wrote:
> Hello,
> 
> A new version (v5) of the NETCONF Monitoring Schema draft has been posted.
> 
> This version addresses action items from IETF74 and comments received on v4.  Changes include:
> - updated statistics (and counter definitions) per offline discussion:
> 	- updated counter definitions
> 	- updated data types  (addition of ZeroBasedCounter32)
> 	- per session counters;  see section 2.1.4
> 	- global counters;  see section 2.1.5
> - unique sessionId handling and WG consensus:
> 	- expected handling of NETCONF and non-NETCONF sessions defined
> 	- explicit exclusion of sessionId=0 added
> 	- see section 2.1.4
> - removal of subscriptions subtree;  was sec 2.1.5 in v4
> - revised XSD and YANG models
> 
> Thank you to all who provided comments and participated in the offline discussions.
> 
> Please direct all comments on this new version to the ML for further consideration.
> 
> cheers,
> Mark
> 
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] 
> Sent: Thursday, June 25, 2009 10:52 AM
> To: Scott, Mark (CAR:2N00)
> Cc: Chisholm, Sharon (CAR:ZZ00); mbj@tail-f.com
> Subject: New Version Notification for draft-ietf-netconf-monitoring-05 
> 
> 
> A new version of I-D, draft-ietf-netconf-monitoring-05.txt has been successfuly submitted by Mark Scott and posted to the IETF repository.
> 
> Filename:	 draft-ietf-netconf-monitoring
> Revision:	 05
> Title:		 NETCONF Monitoring Schema
> Creation_date:	 2009-06-24
> WG ID:		 netconf
> Number_of_pages: 43
> 
> Abstract:
> This document defines a NETCONF data model (in XML Schema) to be used
> to monitor the NETCONF protocol.  The monitoring data model includes
> information about NETCONF datastores, sessions, locks and statistics.
> This data facilitates the management of a NETCONF server.  This
> document also defines methods for NETCONF clients to discover data
> models supported by a NETCONF server and defines a new NETCONF <get-
> schema> operation to retrieve them.
>                                                                                   
> 
> 
> The IETF Secretariat.
> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel@ericsson.com

From andy@netconfcentral.com  Fri Jun 26 10:12:10 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911B83A6BB6 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 10:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Level: 
X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.187,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thLJzkMBzQqi for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 10:12:09 -0700 (PDT)
Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id C04D13A6A91 for <netconf@ietf.org>; Fri, 26 Jun 2009 10:12:09 -0700 (PDT)
Received: (qmail 14294 invoked from network); 26 Jun 2009 17:12:25 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 26 Jun 2009 17:12:25 -0000
X-YMail-OSG: h1piD_UVM1licwDauiqBL.5DU1wCtLN_MKmEhRYR1a2esbSaIggnk1LKuNf6m42ijt6OAhn9VxVOmaKww7ZPCcP1gD2ZiNFl46a4wm2p1qquxI_aRP1KhfTzQuwY.QF2Pw.8WvBi.AHkf2c4aEqGKlK_falDH5o5undUSUQvcwdblpPtNGnEhTpm6TfGqImLbfBYcOzPs68UrFaLjsQrli38hcbdi91Rc1wPelGQT1MK40DNk9DDjSG06rce7TsrRX.v8SvCF82gIIaTNPd7xXTEVVspe6mxD4.l4J0cJIjKNqCL
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A450178.6070607@netconfcentral.com>
Date: Fri, 26 Jun 2009 10:12:24 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: rgcole01@comcast.net
References: <575086273.111721246035490273.JavaMail.root@sz0139a.westchester.pa.mail.comcast.net>
In-Reply-To: <575086273.111721246035490273.JavaMail.root@sz0139a.westchester.pa.mail.comcast.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] draft-cole-netconf-robust-config-01
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 17:12:10 -0000

rgcole01@comcast.net wrote:
> Phil,
> 
>  
> 
> I agree that the nature of the test are tied to the change and the role
> of the device in the network.  We discuss this to some extent in the
> draft.  I think one of the challenges if to determine if it is possible
> to strongly associate tests to config objects.  I would like to think
> this is generally possible but think this is an outstanding question.
> 
>  

I think there are 4 classes of managed devices when considering
the Verified Commit Procedure:


    need to run commit     need to run test
  +--------------------+--------------------+
  |      no            |        no          |   1) not involved in verified commit
  +--------------------+--------------------+
  |      no            |        yes         |   2) just run verify test(s)
  +--------------------+--------------------+
  |      yes           |        no          |   3) just run double-commit procedure
  +--------------------+--------------------+
  |      yes           |       yes          |   4) run verify test(s) and double-commit
  +--------------------+--------------------+


I think the YANG module needs to address (2).  It currently does not.



> 
> However,  another reason for the start-verifed-commit  approach is to
> push the tests to the server.  I believe this level of testing is
> necessary and goes beyond running tests from the client application or
> inferring behavior on the server through means outside of NETCONF.  We
> list some example use cases in the appendix where active tests run from
> the server would be useful.
> 
>  
> 
> Thanks,
> 
> Bob

Andy



> ----- Original Message -----
> From: "Phil Shafer" <phil@juniper.net>
> To: "Martin Bjorklund" <mbj@tail-f.com>
> Cc: rgcole01@comcast.net, andy@netconfcentral.com, dromasca@avaya.com,
> netconf@ietf.org
> Sent: Friday, June 26, 2009 9:52:26 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [Netconf] draft-cole-netconf-robust-config-01
> 
> Martin Bjorklund writes:
>>Why don't you
>>simply add a new operation <start-test> that can be used to trigger
>>the tests at the server when the conrimed commit is active?
> 
> Another thing to consider that the nature of the test are typically
> interwoven with the architecture of the network and the characteristics
> of the change.  What test do you perform when you:
> 
> (a) change a BGP export filter
> (b) change an AS number
> (c) add a BGPVPN site
> 
> (a) would only affect your peer(s), (b) could have serious impact (but
> that's what you wanted), and (c) should have no impact on existing
> peers/sites/etc.
> 
> So given that the application is making the change, and that testing
> the change is integrated with both the change and the customer
> network architecture, why not use the existing "commit confirmed"
> mechanism and have the application drive the testing of changes
> using remote RPCs to get information off the box re: the impact
> of the change?  This seems much more straight forward and was
> what we had in mind from the start.
> 
> Thanks,
>  Phil
> 


From mbj@tail-f.com  Fri Jun 26 12:24:58 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9573A68CD for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 12:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.946
X-Spam-Level: 
X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zHJ1tIrLgv2 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 12:24:58 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BAFB33A67AA for <netconf@ietf.org>; Fri, 26 Jun 2009 12:24:57 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C594616004; Fri, 26 Jun 2009 21:25:07 +0200 (CEST)
Date: Fri, 26 Jun 2009 21:25:07 +0200 (CEST)
Message-Id: <20090626.212507.126802307.mbj@tail-f.com>
To: andy@netconfcentral.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4A44E2DE.2060509@netconfcentral.com>
References: <20090626.142918.117864005.mbj@tail-f.com> <4A44E2DE.2060509@netconfcentral.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] draft-cole-netconf-robust-config-01
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 19:24:58 -0000

Andy Bierman <andy@netconfcentral.com> wrote:
> Martin Bjorklund wrote:
> > Hi,
> > 
> > I have read this document, and I think the ideas presented are very
> > interesting.
> > 
> > But I have a comment on the solution you have chosen to trigger the
> > tests.  It seems you have re-invented confirmed commit, with some
> > additional parameters.  IMO, the existing confirmed commit operation
> > is well suited for the things you want to do (maybe it was even
> > designed to be able to handle this kind of use case).  Why don't you
> > simply add a new operation <start-test> that can be used to trigger
> > the tests at the server when the conrimed commit is active?  This
> > would look like:
> 
> 
> I prefer the design of the verified commit over the confirmed commit.
> 
>   1) using the same command multiple times to do different things
>      is confusing and prone to errors (user B's first <commit>
>      can actually be used as user A's 2nd commit.  That's broken.)
> 
>   2) there is no way to cancel a confirmed-commit, other than
>      by dropping the session.  This is not very clean.

If you think the current confirmed commit is broken, it should be
fixed.  I don't like the idea of introducing new partly overlapping,
partly different operations in an ad-hoc manner.  I think it would be
better to fix confirmed commit (if necessary), and use it for this
function as well.  [this should be discussed in a separate thread]

>   3) the lack of notifications makes confirmed commit harder to
>      use in a network-wide config change.

But you have solved that with your new operation.  The <start-test>
operation would still generate notifications as in your proposal.  I
think this is a good idea.

>   4) overloading the <commit> operation with more modes is more
>      confusing than using a new operation.

The idea is that <commit> is not modified at all.  The new
<start-test> operation is orthogonal to <commit>.  The idea is that
the client uses <start-test> in the confirm time window, just like it
can do other tests before issuing the confirming commit.


/martin

From andy@netconfcentral.com  Fri Jun 26 13:04:12 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E473A6B07 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 13:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.25
X-Spam-Level: 
X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCEJ0QJMhaEA for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 13:04:12 -0700 (PDT)
Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by core3.amsl.com (Postfix) with SMTP id 46D8D28C14C for <netconf@ietf.org>; Fri, 26 Jun 2009 13:04:03 -0700 (PDT)
Received: from [68.142.200.227] by n15.bullet.mail.mud.yahoo.com with NNFMP; 26 Jun 2009 20:04:19 -0000
Received: from [68.142.201.64] by t8.bullet.mud.yahoo.com with NNFMP; 26 Jun 2009 20:04:19 -0000
Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 26 Jun 2009 20:04:19 -0000
X-Yahoo-Newman-Id: 681778.81498.bm@omp416.mail.mud.yahoo.com
Received: (qmail 48378 invoked from network); 26 Jun 2009 20:04:19 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp107.sbc.mail.sp1.yahoo.com with SMTP; 26 Jun 2009 20:04:18 -0000
X-YMail-OSG: .NU0gBgVM1kKJqmorwT3YimM7xd7XxVKNNaVNWjgvgdidiFcXaUpZvPGM3Ntza19JALC_z1ZPDJiUDFSXUtd0k_pvcgGX333kTjX_a3BDwlEYoiAqtUD2eUEk_LxUAlwsaVudtEiqGkWI_Vn1IHp9XoFS7UBMTIbdvu3SZ7MenFtzJrECdx69x4uk6eJnha8PZnp1gyjdfUF9qMkv_z_wm38aeQtqo7c58P1yNrU4qLJ.Odbu35ttNp_LznnqGJqz1qTgXPUQLE9aqaMhSjErDRiZPeuxAmofOqwDMk.hprghjbGS1RW5ZqA9D_et_0LrRfcvZuJddBZe1kNHyXXDjDXeGGJaagQEmLaKZrchb4nrgVanA--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A4529C1.6020407@netconfcentral.com>
Date: Fri, 26 Jun 2009 13:04:17 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <20090626.142918.117864005.mbj@tail-f.com>	<4A44E2DE.2060509@netconfcentral.com> <20090626.212507.126802307.mbj@tail-f.com>
In-Reply-To: <20090626.212507.126802307.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] draft-cole-netconf-robust-config-01
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 20:04:13 -0000

Martin Bjorklund wrote:
> Andy Bierman <andy@netconfcentral.com> wrote:
>> Martin Bjorklund wrote:
>>> Hi,
>>>
>>> I have read this document, and I think the ideas presented are very
>>> interesting.
>>>
>>> But I have a comment on the solution you have chosen to trigger the
>>> tests.  It seems you have re-invented confirmed commit, with some
>>> additional parameters.  IMO, the existing confirmed commit operation
>>> is well suited for the things you want to do (maybe it was even
>>> designed to be able to handle this kind of use case).  Why don't you
>>> simply add a new operation <start-test> that can be used to trigger
>>> the tests at the server when the conrimed commit is active?  This
>>> would look like:
>>
>> I prefer the design of the verified commit over the confirmed commit.
>>
>>   1) using the same command multiple times to do different things
>>      is confusing and prone to errors (user B's first <commit>
>>      can actually be used as user A's 2nd commit.  That's broken.)
>>
>>   2) there is no way to cancel a confirmed-commit, other than
>>      by dropping the session.  This is not very clean.
> 
> If you think the current confirmed commit is broken, it should be
> fixed.  I don't like the idea of introducing new partly overlapping,
> partly different operations in an ad-hoc manner.  I think it would be
> better to fix confirmed commit (if necessary), and use it for this
> function as well.  [this should be discussed in a separate thread]
> 

I don't want to introduce an incompatible version of
the protocol.  The charter already assumes in advance
that there are no problems worthy of a new protocol version.

But you will tell me that we could just introduce :confirmed-commit.1.1,
so I guess it doesn't matter.  But I am not so sure the complexity on
the NMS is less in the long run if we do this.  A lot of capabilities
interact.  So now we have to document how every version of every
capability interacts with every other, for all time.  Sounds hard.
This is probably why most protocol WGs just version the entire protocol,
and not arbitrarily small subsets of it. (hint)



>>   3) the lack of notifications makes confirmed commit harder to
>>      use in a network-wide config change.
> 
> But you have solved that with your new operation.  The <start-test>
> operation would still generate notifications as in your proposal.  I
> think this is a good idea.


I kept saying I wanted some notification content. :-)
The details of the partial status updates and how
a real template gets used instead of the 'anyxml'
for <extendedStatus>, depending on the test type.

The idea is that a test could return whatever it wants,
even the direct output of unix ping or traceroute commands,
if that was all that was available.

There should probably be distinct <commitStarted> and <commitComplete>
notifications.  There is no 'start' now, and the current complete is
for the tests (but if it worked, it can be assumed the 2nd commit
worked too.  But maybe not, so that's why a <commitComplete>
notification will tell the operator for sure.

The notification replay log could be searched for

  <commitStarted>
    ... bunch of verification tests reporting status and completion ...
  <commitComplete>

That way, different commits in the log could be determined easily.


> 
>>   4) overloading the <commit> operation with more modes is more
>>      confusing than using a new operation.
> 
> The idea is that <commit> is not modified at all.  The new
> <start-test> operation is orthogonal to <commit>.  The idea is that
> the client uses <start-test> in the confirm time window, just like it
> can do other tests before issuing the confirming commit.
> 


Well, using a <complete-verified-commit> operation instead of <commit> again,
and adding a <cancel-verified-commit> operation are certainly different.
Except for that part, it is the same as confirmed-commit,
with some tests on the side to help the operator decide
whether to save or rollback the changes.

The tests need to be independent to support case (2)
I mentioned before.  The operator needs to get baseline
numbers (for example), so running the verification tests
outside the context of a commit is important.


> 
> /martin
> 

Andy


From andy@netconfcentral.com  Fri Jun 26 13:36:20 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22463A6977 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 13:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level: 
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WtWebtCmq37 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 13:36:19 -0700 (PDT)
Received: from n16.bullet.mail.mud.yahoo.com (n16.bullet.mail.mud.yahoo.com [68.142.206.43]) by core3.amsl.com (Postfix) with SMTP id 03CB13A6861 for <netconf@ietf.org>; Fri, 26 Jun 2009 13:36:18 -0700 (PDT)
Received: from [68.142.200.226] by n16.bullet.mail.mud.yahoo.com with NNFMP; 26 Jun 2009 20:34:39 -0000
Received: from [68.142.201.67] by t7.bullet.mud.yahoo.com with NNFMP; 26 Jun 2009 20:34:39 -0000
Received: from [127.0.0.1] by omp419.mail.mud.yahoo.com with NNFMP; 26 Jun 2009 20:34:39 -0000
X-Yahoo-Newman-Id: 693799.68760.bm@omp419.mail.mud.yahoo.com
Received: (qmail 3558 invoked from network); 26 Jun 2009 20:34:39 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 26 Jun 2009 20:34:39 -0000
X-YMail-OSG: bzgj2L4VM1k89ExtKHzrdtTvTbRo0Woa9fCqXW3c62uq5Fh4qCgAPwVVmmxo2Qfnsf5AsjmW5Cr7EtNVhns1Kovu0sfAcJ5iivg6y9T_z7NzSgoGTnmjJSEDjeiYZLHmsnU83Y7vChUnrOi1y9EU2LrelwEXo2TdXxuj9eTaA_xeip1TFxr5BWEj2AIBbVqiMh_97C8cFaQm7DoaJJgkFOD3RjMgFQ6PY2BCjZyoF.tQ5XpuYkuPv7Girzg9BISV3L0k0efM6LmHK5Qe
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A4530DD.5060208@netconfcentral.com>
Date: Fri, 26 Jun 2009 13:34:37 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <20090626.142918.117864005.mbj@tail-f.com>	<4A44E2DE.2060509@netconfcentral.com>	<20090626.212507.126802307.mbj@tail-f.com> <4A4529C1.6020407@netconfcentral.com>
In-Reply-To: <4A4529C1.6020407@netconfcentral.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: [Netconf] capability exchange (was Re: draft-cole-netconf-robust-config-01)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jun 2009 20:36:20 -0000

Andy Bierman wrote:
> Martin Bjorklund wrote:
....
> 
> I don't want to introduce an incompatible version of
> the protocol.  The charter already assumes in advance
> that there are no problems worthy of a new protocol version.
> 
> But you will tell me that we could just introduce :confirmed-commit.1.1,
> so I guess it doesn't matter.  But I am not so sure the complexity on
> the NMS is less in the long run if we do this.  A lot of capabilities
> interact.  So now we have to document how every version of every
> capability interacts with every other, for all time.  Sounds hard.
> This is probably why most protocol WGs just version the entire protocol,
> and not arbitrarily small subsets of it. (hint)
> 

At this point, the NETCONF WG cannot introduce any new version
of a single capability, because the current capability exchange
is not documented to support it.

RFC 4741 says very clearly what capabilities the manager
MUST sent (netconf-base) and what an agent MUST send
(everything it has).  So manager implementations do
not send all the capabilities (like confirmed-commit)
that they support.  They know a 4741 agent will just
ignore them, so why bother.


Except:
   1) if the agent advertises just :foo.1.1, then
      old managers break, since they only know about :foo.1.0

   2) if the agent advertises :foo.1.0 and :foo.1.1,
      and they are not backward-compatible, then
      the agent may not know which one the manager expects

If I were thinking about a solution to the problem
that is optimal, instead of worrying about the charter,
I would suggest that capability exchange needs to
be rewritten in 4741-bis so both side always send
everything they know, and they automatically pick
the highest capability version in common.

But a charter-compatible solution would be to put
CLRs in place that a new capability version MUST follow
all the same revision rules as YANG modules.

For example, adding 'test-only' follows the rules.
An agent could advertise both :validate1.0 and :validate.1.1,
and both old and new managers will work.

I don't think the same is true (so far) wrt/ :confirmed-commit.1.1.



> .....
>> /martin
>>
> 
> Andy
>

Andy


From Washam.Fan@huaweisymantec.com  Fri Jun 26 19:02:01 2009
Return-Path: <Washam.Fan@huaweisymantec.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6A53A69B2 for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 19:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.852
X-Spam-Level: 
X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.747,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JHph-L2y3hF for <netconf@core3.amsl.com>; Fri, 26 Jun 2009 19:02:00 -0700 (PDT)
Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 891C73A676A for <netconf@ietf.org>; Fri, 26 Jun 2009 19:02:00 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLV00HZVKBTWN90@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 27 Jun 2009 10:02:17 +0800 (CST)
Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KLV00ARGKBT5P00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 27 Jun 2009 10:02:17 +0800 (CST)
Received: from [10.27.154.65] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 27 Jun 2009 10:02:17 +0800
From: WashamFan <Washam.Fan@huaweisymantec.com>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
Message-id: <fc9addc34fdf.4a45ee29@huaweisymantec.com>
Date: Sat, 27 Jun 2009 10:02:17 +0800
X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit)
Content-language: en
X-Accept-Language: en
Priority: normal
In-reply-to: <4A44F70A.2050006@ericsson.com>
References: <085091CB2CA14E4B8B163FFC37C84E9D198F35EB@zcarhxm0.corp.nortel.com> <4A44F70A.2050006@ericsson.com>
Cc: netconf mailing list <netconf@ietf.org>
Subject: Re: [Netconf] FW: New Version Notification	for draft-ietf-netconf-monitoring-05
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 02:02:01 -0000

Hi,

>  Some changes to the paragraph starting with "For partial locks the list":
>  For partial locks the list of locked nodes and the select expressions 
> originally used to 
>  request the lock are returned. The scope of the partial lock is 
> defined by the list of locked 
>  nodes. This list might change during the lifetime of the lock.
>  The select expressions indicate the original intended scope of the lock.

How to understand "This list might change during the lifetime of the lock."?
What the list herein refer to? IMO, the list of locked nodes to which 
the original XPath expressions evaluate at the first time WONT change.
But the list of nodes to which the original XPath expressions evaluate
during the lifetime of the lock MIGHT change. I think we should spell
out it.

washam

From mbj@tail-f.com  Sat Jun 27 14:11:20 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3AFB3A6C93 for <netconf@core3.amsl.com>; Sat, 27 Jun 2009 14:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level: 
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdwmYWE9fQeO for <netconf@core3.amsl.com>; Sat, 27 Jun 2009 14:11:20 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D63AC3A6C1A for <netconf@ietf.org>; Sat, 27 Jun 2009 14:11:19 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 61E15616004; Sat, 27 Jun 2009 23:11:37 +0200 (CEST)
Date: Sat, 27 Jun 2009 23:11:37 +0200 (CEST)
Message-Id: <20090627.231137.218850786.mbj@tail-f.com>
To: andy@netconfcentral.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <4A4530DD.5060208@netconfcentral.com>
References: <20090626.212507.126802307.mbj@tail-f.com> <4A4529C1.6020407@netconfcentral.com> <4A4530DD.5060208@netconfcentral.com>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] capability exchange
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 21:11:21 -0000

Andy Bierman <andy@netconfcentral.com> wrote:
> Andy Bierman wrote:
> > Martin Bjorklund wrote:
> ....
> > 
> > I don't want to introduce an incompatible version of
> > the protocol.  The charter already assumes in advance
> > that there are no problems worthy of a new protocol version.
> > 
> > But you will tell me that we could just introduce :confirmed-commit.1.1,
> > so I guess it doesn't matter.

Yes!  See below.

> >  But I am not so sure the complexity on
> > the NMS is less in the long run if we do this.  A lot of capabilities
> > interact.  So now we have to document how every version of every
> > capability interacts with every other, for all time.  Sounds hard.
> > This is probably why most protocol WGs just version the entire protocol,
> > and not arbitrarily small subsets of it. (hint)
> > 
> 
> At this point, the NETCONF WG cannot introduce any new version
> of a single capability, because the current capability exchange
> is not documented to support it.
> 
> RFC 4741 says very clearly what capabilities the manager
> MUST sent (netconf-base) and what an agent MUST send
> (everything it has).  So manager implementations do
> not send all the capabilities (like confirmed-commit)
> that they support.  They know a 4741 agent will just
> ignore them, so why bother.
> 
> 
> Except:
>    1) if the agent advertises just :foo.1.1, then
>       old managers break, since they only know about :foo.1.0

Right.

>    2) if the agent advertises :foo.1.0 and :foo.1.1,
>       and they are not backward-compatible, then
>       the agent may not know which one the manager expects

There is nothing that prevents us from requiring the client to
advertise foo:1.1, if it is necessary.  So if foo:1.1 changes some
semantics of foo:1.0, then we can say that the client MUST advertise
foo:1.1, otherwise the agent will use the semantics of foo:1.0.

> For example, adding 'test-only' follows the rules.
> An agent could advertise both :validate1.0 and :validate.1.1,
> and both old and new managers will work.
> 
> I don't think the same is true (so far) wrt/ :confirmed-commit.1.1.

I think it can be made to work this way, without requiring the client
to advertise :confirmed-commit:1.1.

For example, :confirmed-commit:1.1 could add one rpc method
<cancel-confirmed-commit/>.


/martin

From andy@netconfcentral.com  Sat Jun 27 15:31:18 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8933A68CB for <netconf@core3.amsl.com>; Sat, 27 Jun 2009 15:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.27
X-Spam-Level: 
X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3suQ4qH9Azut for <netconf@core3.amsl.com>; Sat, 27 Jun 2009 15:31:17 -0700 (PDT)
Received: from n55.bullet.mail.sp1.yahoo.com (n55.bullet.mail.sp1.yahoo.com [98.136.44.188]) by core3.amsl.com (Postfix) with SMTP id 412203A687B for <netconf@ietf.org>; Sat, 27 Jun 2009 15:31:17 -0700 (PDT)
Received: from [69.147.84.145] by n55.bullet.mail.sp1.yahoo.com with NNFMP; 27 Jun 2009 22:31:34 -0000
Received: from [68.142.194.243] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 27 Jun 2009 22:31:34 -0000
Received: from [68.142.201.66] by t1.bullet.mud.yahoo.com with NNFMP; 27 Jun 2009 22:31:34 -0000
Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 27 Jun 2009 22:31:34 -0000
X-Yahoo-Newman-Id: 640906.18415.bm@omp418.mail.mud.yahoo.com
Received: (qmail 82774 invoked from network); 27 Jun 2009 22:31:34 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp110.sbc.mail.sp1.yahoo.com with SMTP; 27 Jun 2009 22:31:33 -0000
X-YMail-OSG: X81k5ikVM1lt7Lw6vgdWET9d9hKIIkyrT9FdyOnmGrxcT3Pn0lW4FTjhu9vTO4oDAPg2lxDo8l.4bEGjItvEKlTIXnJ499MAAc__rFthv7_p8pz5kFl2ZW40YHtY5pV3.Oqi6YRtICJky0QW7DzzZibFo7FUbqSY77GzVpKC4DqILTA9d7QHyz0hSHTsoqTnSFj.sQwV.Odt7.0hnjmlacrcVDOa.wP1UYmS8hJTsoAWafkZoSorQIOIWvL0Q1b0uPHjycYxcMv55jTRWGhrLYozaNxiC.pXlBpk9uqNwp0JgZ5bqx_hp7fxJLRGdV0OaHX7bTAzzGhhx9BiLLLqKgyk2RpaiYvKi_uCl4.ey_cHvq2SWQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A469DC0.6070502@netconfcentral.com>
Date: Sat, 27 Jun 2009 15:31:28 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Martin Bjorklund <mbj@tail-f.com>
References: <20090626.212507.126802307.mbj@tail-f.com>	<4A4529C1.6020407@netconfcentral.com>	<4A4530DD.5060208@netconfcentral.com> <20090627.231137.218850786.mbj@tail-f.com>
In-Reply-To: <20090627.231137.218850786.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] capability exchange
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2009 22:31:18 -0000

Martin Bjorklund wrote:
> Andy Bierman <andy@netconfcentral.com> wrote:
>> Andy Bierman wrote:
>>> Martin Bjorklund wrote:
>> ....
>>> I don't want to introduce an incompatible version of
>>> the protocol.  The charter already assumes in advance
>>> that there are no problems worthy of a new protocol version.
>>>
>>> But you will tell me that we could just introduce :confirmed-commit.1.1,
>>> so I guess it doesn't matter.
> 
> Yes!  See below.
> 
>>>  But I am not so sure the complexity on
>>> the NMS is less in the long run if we do this.  A lot of capabilities
>>> interact.  So now we have to document how every version of every
>>> capability interacts with every other, for all time.  Sounds hard.
>>> This is probably why most protocol WGs just version the entire protocol,
>>> and not arbitrarily small subsets of it. (hint)
>>>
>> At this point, the NETCONF WG cannot introduce any new version
>> of a single capability, because the current capability exchange
>> is not documented to support it.
>>
>> RFC 4741 says very clearly what capabilities the manager
>> MUST sent (netconf-base) and what an agent MUST send
>> (everything it has).  So manager implementations do
>> not send all the capabilities (like confirmed-commit)
>> that they support.  They know a 4741 agent will just
>> ignore them, so why bother.
>>
>>
>> Except:
>>    1) if the agent advertises just :foo.1.1, then
>>       old managers break, since they only know about :foo.1.0
> 
> Right.
> 
>>    2) if the agent advertises :foo.1.0 and :foo.1.1,
>>       and they are not backward-compatible, then
>>       the agent may not know which one the manager expects
> 
> There is nothing that prevents us from requiring the client to
> advertise foo:1.1, if it is necessary.  So if foo:1.1 changes some
> semantics of foo:1.0, then we can say that the client MUST advertise
> foo:1.1, otherwise the agent will use the semantics of foo:1.0.
> 
>> For example, adding 'test-only' follows the rules.
>> An agent could advertise both :validate1.0 and :validate.1.1,
>> and both old and new managers will work.
>>
>> I don't think the same is true (so far) wrt/ :confirmed-commit.1.1.
> 
> I think it can be made to work this way, without requiring the client
> to advertise :confirmed-commit:1.1.
> 
> For example, :confirmed-commit:1.1 could add one rpc method
> <cancel-confirmed-commit/>.
> 

Yes -- but a verify-commit.1.0 would also require all the
behind-the-scenes integration with the verification tests,
in order to send the mandatory notifications.  I don't see
the log-term benefits of creating lots of tiny little
protocol capabilities, even down to adding enums to
parameters.  It seems expedient now, when they are
still on the order of O(10).  Add one zero
to that and you end up with spaghetti YANG.

There is nothing in RFC 4741 that says the same session has
to issue the 2 <commit> operations.  I really don't like this
at all.  It clearly indicates the <commit> is overloaded,
since (even with all its CLRs) it still requires global locks
to work correctly.

I know we don't really have a proper database transaction model in
NETCONF, but the pseudo-transaction model can be
much cleaner that whatever it is we have now.  Just bolting
more parameters and modes onto this supposedly documented transaction
model is just asking for trouble later.  IMO, the NETCONF database
transaction model (including partial locking) is somewhat amateurish.
It's got more holes in it than Swiss cheese.

I don't really care what the capability is called,
as long as there are no restrictions to the design.
Whatever works best -- not whatever band-aid fits the quickest.


> 
> /martin
> 

Andy


From phil@juniper.net  Sat Jun 27 21:17:24 2009
Return-Path: <phil@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4AE3A6C8F for <netconf@core3.amsl.com>; Sat, 27 Jun 2009 21:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfoKBzoVNUpK for <netconf@core3.amsl.com>; Sat, 27 Jun 2009 21:17:23 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 9BE843A6BBD for <netconf@ietf.org>; Sat, 27 Jun 2009 21:17:22 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSkbu47GH1saPK1Cd0p7kKPubBy6XUcgA@postini.com; Sat, 27 Jun 2009 21:17:43 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 27 Jun 2009 21:16:05 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 21:16:05 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 21:16:05 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 21:16:04 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5S4G3L96513; Sat, 27 Jun 2009 21:16:03 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n5S456tE035847; Sun, 28 Jun 2009 04:05:06 GMT (envelope-from phil@idle.juniper.net)
Message-ID: <200906280405.n5S456tE035847@idle.juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20090627.231137.218850786.mbj@tail-f.com> 
Date: Sun, 28 Jun 2009 00:05:06 -0400
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 28 Jun 2009 04:16:04.0240 (UTC) FILETIME=[26FBB900:01C9F7A7]
MIME-Version: 1.0
Content-Type: text/plain
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] capability exchange
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2009 04:17:24 -0000

Martin Bjorklund writes:
>There is nothing that prevents us from requiring the client to
>advertise foo:1.1, if it is necessary.  So if foo:1.1 changes some
>semantics of foo:1.0, then we can say that the client MUST advertise
>foo:1.1, otherwise the agent will use the semantics of foo:1.0.

Brief history:  when capabilities were introduced, the idea was
that both sides would always advertise all there capabilities and
the overlapping set of capabilities would be what defines the
capabilities of the session.  So if both sides support the a new
revision of a capability, both sides can operate with an understanding
that the other side will do The Right Thing WRT this capability.

Useful, simple, elegant.

But someone objected and this idea turned into a rat's nest, so
during the Great Netconf Purge, this idea was discarded.

The post-Purge idea was that if you want the server to behave
differently, then the new capability should introduce a new RPC or
parameter to explicitly request this new behavior.

Personally, I'd be happy if 4741 reverts this to an "advertise all
your capabilities" strategy, so capabilities can more easily evolve
over time.

Thanks,
 Phil

From phil@juniper.net  Sat Jun 27 21:22:17 2009
Return-Path: <phil@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339F83A6C8F for <netconf@core3.amsl.com>; Sat, 27 Jun 2009 21:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.507
X-Spam-Level: 
X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWg4CAKZbcGs for <netconf@core3.amsl.com>; Sat, 27 Jun 2009 21:22:16 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id B54D73A685A for <netconf@ietf.org>; Sat, 27 Jun 2009 21:22:15 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSkbwCb9lwLiwdBivZQMSTFt7Kl1VE1p+@postini.com; Sat, 27 Jun 2009 21:22:36 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sat, 27 Jun 2009 21:20:49 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 21:20:49 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 21:20:49 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 21:20:48 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5S4KlL98325; Sat, 27 Jun 2009 21:20:47 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n5S49oVs035873; Sun, 28 Jun 2009 04:09:50 GMT (envelope-from phil@idle.juniper.net)
Message-ID: <200906280409.n5S49oVs035873@idle.juniper.net>
To: Andy Bierman <andy@netconfcentral.com>
In-Reply-To: <4A469DC0.6070502@netconfcentral.com> 
Date: Sun, 28 Jun 2009 00:09:50 -0400
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 28 Jun 2009 04:20:48.0029 (UTC) FILETIME=[D0227CD0:01C9F7A7]
MIME-Version: 1.0
Content-Type: text/plain
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] capability exchange
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2009 04:22:17 -0000

Andy Bierman writes:
>IMO, the NETCONF database
>transaction model (including partial locking) is somewhat amateurish.
>It's got more holes in it than Swiss cheese.

Not sure how to parse this, since IMHO the NETCONF database transaction
model does not include partial locking.  If you do partial locking,
then you can't use the 4741 transaction model.  There's no overlap.

Thanks,
 Phil

From andy@netconfcentral.com  Sat Jun 27 22:07:45 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBDC3A6C8F for <netconf@core3.amsl.com>; Sat, 27 Jun 2009 22:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.279
X-Spam-Level: 
X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHiEudp-ezjV for <netconf@core3.amsl.com>; Sat, 27 Jun 2009 22:07:44 -0700 (PDT)
Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id F0AD03A6906 for <netconf@ietf.org>; Sat, 27 Jun 2009 22:07:43 -0700 (PDT)
Received: (qmail 66531 invoked from network); 28 Jun 2009 05:08:00 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@67.127.173.161 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 28 Jun 2009 05:08:00 -0000
X-YMail-OSG: udYt6BwVM1nSt76DJ.QSw7t3v7JwmVBJ_Ue0fTEwIN55ihBVDvpxFMU.9_BwRmOHhJo5DavYIusNhqCuf01S.BylQ5q7Gt2I72ujGS19cENiXFHM9MSXGzLGWLnw5e88AXQ6ki_nWKR0rdE4m2_n1n.mcDEeD.dmlsjxbXfQ36arRK.nJ_KpKE0RKsUUwpENeE6CFzkVcExGnOHINCjpcwAXzYjmRXd.o05_rn56BsPV.eK0UHcOWCNLOnXngVjky9bFg9W3dmbnEMz6
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A46FA2B.2060809@netconfcentral.com>
Date: Sat, 27 Jun 2009 22:05:47 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
References: <200906280409.n5S49oVs035873@idle.juniper.net>
In-Reply-To: <200906280409.n5S49oVs035873@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] capability exchange
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2009 05:07:45 -0000

Phil Shafer wrote:
> Andy Bierman writes:
>> IMO, the NETCONF database
>> transaction model (including partial locking) is somewhat amateurish.
>> It's got more holes in it than Swiss cheese.
> 
> Not sure how to parse this, since IMHO the NETCONF database transaction
> model does not include partial locking.  If you do partial locking,
> then you can't use the 4741 transaction model.  There's no overlap.
> 

Well, partial-lock works fine for editing <running>,
but if <candidate> or <startup> is supported
on the agent, then you cannot use it.  Batting .333
is good in baseball, but maybe not here :-)


> Thanks,
>  Phil
> 

Andy

From mbj@tail-f.com  Sun Jun 28 12:44:31 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E56F3A684D for <netconf@core3.amsl.com>; Sun, 28 Jun 2009 12:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Level: 
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.085,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3P3KZxyo9dO3 for <netconf@core3.amsl.com>; Sun, 28 Jun 2009 12:44:30 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 870753A6782 for <netconf@ietf.org>; Sun, 28 Jun 2009 12:44:30 -0700 (PDT)
Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 25FD376C52D; Sun, 28 Jun 2009 21:44:49 +0200 (CEST)
Date: Sun, 28 Jun 2009 21:44:48 +0200 (CEST)
Message-Id: <20090628.214448.198683690.mbj@tail-f.com>
To: phil@juniper.net
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <200906280405.n5S456tE035847@idle.juniper.net>
References: <20090627.231137.218850786.mbj@tail-f.com> <200906280405.n5S456tE035847@idle.juniper.net>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] capability exchange
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2009 19:44:31 -0000

Phil Shafer <phil@juniper.net> wrote:
> Martin Bjorklund writes:
> >There is nothing that prevents us from requiring the client to
> >advertise foo:1.1, if it is necessary.  So if foo:1.1 changes some
> >semantics of foo:1.0, then we can say that the client MUST advertise
> >foo:1.1, otherwise the agent will use the semantics of foo:1.0.
> 
> Brief history:  when capabilities were introduced, the idea was
> that both sides would always advertise all there capabilities and
> the overlapping set of capabilities would be what defines the
> capabilities of the session.  So if both sides support the a new
> revision of a capability, both sides can operate with an understanding
> that the other side will do The Right Thing WRT this capability.
> 
> Useful, simple, elegant.
> 
> But someone objected and this idea turned into a rat's nest, so
> during the Great Netconf Purge, this idea was discarded.
> 
> The post-Purge idea was that if you want the server to behave
> differently, then the new capability should introduce a new RPC or
> parameter to explicitly request this new behavior.
> 
> Personally, I'd be happy if 4741 reverts this to an "advertise all
> your capabilities" strategy, so capabilities can more easily evolve
> over time.

But I don't think 4741 needs to be changed in order to handle this.
As I wrote above, I think this can be handled on a capability basis -
i.e. if a particular capability's semantics is dependent on e.g. which
version of the capability the client implements, then that capability
can be defined to require that the client advertises it.  There is one
such capability already - the base capability.


/martin




From andy@netconfcentral.com  Sun Jun 28 13:01:57 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847AF3A6ACA for <netconf@core3.amsl.com>; Sun, 28 Jun 2009 13:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level: 
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSUsh6PNxc-q for <netconf@core3.amsl.com>; Sun, 28 Jun 2009 13:01:56 -0700 (PDT)
Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id CA6AD3A69C4 for <netconf@ietf.org>; Sun, 28 Jun 2009 13:01:56 -0700 (PDT)
Received: (qmail 65852 invoked from network); 28 Jun 2009 20:02:13 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 28 Jun 2009 20:02:13 -0000
X-YMail-OSG: wIMKACoVM1k9rSsQ5VSqYsPqZN5n_zCymGj9ZmOepdCHraK0POlKuh24587iScavavoVnssgq4k9S0qL6ZEtePoJJn8NMXQhwed_g9dluSvCyFLwRpbpLGyL1oXIiMDcAUwqll9QuYapzmfAi56UjfLhyLgrjSOVBUZcMnz26L8YyYCRkkWwvROQmkV7ils5.gt6L1Zy58rY962mQmJFsOaLUNzZ.vmLdAAEKe.7AJY3JGwSsSUR8UeRZJNBWPMuMxF7uUO4dr2MHakz
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A47CC3C.3030307@netconfcentral.com>
Date: Sun, 28 Jun 2009 13:02:04 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: NETCONF <netconf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Netconf] idea for new commit operation
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2009 20:01:57 -0000

Hi,

A :new-commit capability can add output parameters, not just
input parameters.  It can persist across sessions, and
fix the broken parts of confirmed-commit.1.0.  It can support
the verified commit procedure defined in a separate document.

E.g.:

  feature new-commit {
    if-feature confirmed-commit;
    description
      "Supports the new confirmed commit procedure and the
       verified commit procedure.";
  }

  typedef commit-id-type {
     description
       "Contains the agent-assigned identifier for this commit request.
        This value is returned by a new <commit> operation, and
	must be used with the subsequent <complete-commit> or <cancel-commit>
        operations, or the agent will not accept the request.
        This commit identifier is only valid while a confirmed or verified
        commit operation is in effect.  The agent should use a string value
	which is not predictable, and cannot be easily guessed.";
     type string {
        length { "8 .. 1024"; }
     }
  }

  rpc commit {
    if-feature candidate;
    description
      "If the :new-commit capability is supported, and the
       'verified' or 'persist' parameter is entered, then the new
       commit procedure is in effect.  The <complete-commit> or <cancel-commit>
       operations will be used, not the <commit> operation again.

       If the :new-commit capability is not supported, or these
       parameters are not present, then the old commit procedure
       is in effect, and a 2nd <commit> operation is expected
       by any session, before the current session terminates or
       the timeout expires.";
    input {
       leaf timeout {
          if-feature confirmed-commit;
	  description "unchanged";
          type timeout-type;
       }
       leaf confirmed {
          if-feature confirmed-commit;
	  description "unchanged";
          type empty;
       }
       leaf-list test-template {
          if-feature new-commit;
          description
	     "Optional list of verification control entries to
	      use during the verified commit procedure.";
          type instance-identifier;
       }
       leaf persist {
	  if-feature new-commit;
          description
            "If present, then this commit procedure is allowed
	     to persist across a single session.  If the current session
	     is terminated, the running database will not be automatically
             reverted.  Only a timeout or the <cancel-commit> operation
	     will cause the commit procedure to be terminated, if this
	     parameter is present.";
	  type empty;
       }
    }
    output {
       leaf commit-id {
	 if-feature new-commit;
         type commit-id-type;
       }
    }
  }

  rpc complete-commit {
     if-feature new-commit;
     description
       "The 2nd commit to finalize a confirmed or verified commit operation.";
     input {
        leaf commit-id {
           type commit-id-type;
        }
     }
  }

  rpc cancel-commit {
     if-feature new-commit;
     description
       "Cancel a confirmed or verified commit operation in progress.";
     input {
        leaf commit-id {
           type commit-id-type;
        }
     }
  }



Andy


From phil@juniper.net  Sun Jun 28 18:55:32 2009
Return-Path: <phil@juniper.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F463A67E2 for <netconf@core3.amsl.com>; Sun, 28 Jun 2009 18:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.514
X-Spam-Level: 
X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbxTGws5A8nj for <netconf@core3.amsl.com>; Sun, 28 Jun 2009 18:55:32 -0700 (PDT)
Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id D42403A69C3 for <netconf@ietf.org>; Sun, 28 Jun 2009 18:55:30 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSkgfI1WMBd2A9fiBk9G4bEWqjq6Sb9W2@postini.com; Sun, 28 Jun 2009 18:55:52 PDT
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Sun, 28 Jun 2009 18:50:59 -0700
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Jun 2009 18:50:59 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Jun 2009 18:50:59 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Jun 2009 18:50:58 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n5T1ovL61390; Sun, 28 Jun 2009 18:50:57 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.13.8/8.13.8) with ESMTP id n5T1dxfw040530; Mon, 29 Jun 2009 01:39:59 GMT (envelope-from phil@idle.juniper.net)
Message-ID: <200906290139.n5T1dxfw040530@idle.juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20090628.214448.198683690.mbj@tail-f.com> 
Date: Sun, 28 Jun 2009 21:39:59 -0400
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 29 Jun 2009 01:50:58.0101 (UTC) FILETIME=[0C221650:01C9F85C]
MIME-Version: 1.0
Content-Type: text/plain
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] capability exchange
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 01:55:32 -0000

Martin Bjorklund writes:
>But I don't think 4741 needs to be changed in order to handle this.
>As I wrote above, I think this can be handled on a capability basis -
>i.e. if a particular capability's semantics is dependent on e.g. which
>version of the capability the client implements, then that capability
>can be defined to require that the client advertises it.  There is one
>such capability already - the base capability.

Would it be possible to make this example more explicit somehow
so that it becomes a conscious model which capabilities are
allowed (encouraged?) to follow?

Thanks,
 Phil

From mbj@tail-f.com  Mon Jun 29 00:33:14 2009
Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB5828C176 for <netconf@core3.amsl.com>; Mon, 29 Jun 2009 00:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.971
X-Spam-Level: 
X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5TumQ1NiUze for <netconf@core3.amsl.com>; Mon, 29 Jun 2009 00:33:13 -0700 (PDT)
Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B4D3428C16F for <netconf@ietf.org>; Mon, 29 Jun 2009 00:33:13 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1ED23616011; Mon, 29 Jun 2009 09:33:33 +0200 (CEST)
Date: Mon, 29 Jun 2009 09:33:32 +0200 (CEST)
Message-Id: <20090629.093332.110401508.mbj@tail-f.com>
To: phil@juniper.net
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <200906290139.n5T1dxfw040530@idle.juniper.net>
References: <20090628.214448.198683690.mbj@tail-f.com> <200906290139.n5T1dxfw040530@idle.juniper.net>
X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: rgcole01@comcast.net, netconf@ietf.org
Subject: Re: [Netconf] capability exchange
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 07:33:14 -0000

Phil Shafer <phil@juniper.net> wrote:
> Martin Bjorklund writes:
> >But I don't think 4741 needs to be changed in order to handle this.
> >As I wrote above, I think this can be handled on a capability basis -
> >i.e. if a particular capability's semantics is dependent on e.g. which
> >version of the capability the client implements, then that capability
> >can be defined to require that the client advertises it.  There is one
> >such capability already - the base capability.
> 
> Would it be possible to make this example more explicit somehow
> so that it becomes a conscious model which capabilities are
> allowed (encouraged?) to follow?

I am not convinced that it should be encouraged.  Or rather, I believe
that for most capabilities it will not be necessary.  For example, why
should a client advertise any of the capabilities in 4741?  They just
add rpcs that a client can send.  If the client doesn't understand
:url, it will never send an rpc with a url.


/martin


From balazs.lengyel@ericsson.com  Mon Jun 29 02:51:19 2009
Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7D228C20D for <netconf@core3.amsl.com>; Mon, 29 Jun 2009 02:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.224
X-Spam-Level: 
X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW3YeMU4z32F for <netconf@core3.amsl.com>; Mon, 29 Jun 2009 02:51:18 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0407828C1E5 for <netconf@ietf.org>; Mon, 29 Jun 2009 02:51:17 -0700 (PDT)
X-AuditID: c1b4fb3c-b7bdcae0000052f9-a2-4a488ea851d0
Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 81.9A.21241.8AE884A4; Mon, 29 Jun 2009 11:51:36 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 29 Jun 2009 11:51:36 +0200
Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 29 Jun 2009 11:51:36 +0200
Message-ID: <4A488EA7.4000503@ericsson.com>
Date: Mon, 29 Jun 2009 11:51:35 +0200
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
User-Agent: Thunderbird 2.0.0.4 (X11/20070604)
MIME-Version: 1.0
To: WashamFan <Washam.Fan@huaweisymantec.com>
References: <085091CB2CA14E4B8B163FFC37C84E9D198F35EB@zcarhxm0.corp.nortel.com> <4A44F70A.2050006@ericsson.com> <fc9addc34fdf.4a45ee29@huaweisymantec.com>
In-Reply-To: <fc9addc34fdf.4a45ee29@huaweisymantec.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Jun 2009 09:51:36.0382 (UTC) FILETIME=[31168DE0:01C9F89F]
X-Brightmail-Tracker: AAAAAA==
Cc: netconf mailing list <netconf@ietf.org>
Subject: Re: [Netconf] FW: New Version Notification	for draft-ietf-netconf-monitoring-05
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 09:51:19 -0000

Ok, lets make it even more explicit.
The __list of locked nodes__ might change as indicated in partial-lock chapter 1.1 and also 2.4.1.
Balazs

WashamFan wrote:
> Hi,
> 
>>  Some changes to the paragraph starting with "For partial locks the list":
>>  For partial locks the list of locked nodes and the select expressions 
>> originally used to 
>>  request the lock are returned. The scope of the partial lock is 
>> defined by the list of locked 
>>  nodes. This list might change during the lifetime of the lock.
>>  The select expressions indicate the original intended scope of the lock.
> 
> How to understand "This list might change during the lifetime of the lock."?
> What the list herein refer to? IMO, the list of locked nodes to which 
> the original XPath expressions evaluate at the first time WONT change.
> But the list of nodes to which the original XPath expressions evaluate
> during the lifetime of the lock MIGHT change. I think we should spell
> out it.
> 
> washam
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel@ericsson.com

From wjhns1@hardakers.net  Mon Jun 29 10:14:45 2009
Return-Path: <wjhns1@hardakers.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD2B3A6A6D for <netconf@core3.amsl.com>; Mon, 29 Jun 2009 10:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level: 
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN8ORvK34p-p for <netconf@core3.amsl.com>; Mon, 29 Jun 2009 10:14:45 -0700 (PDT)
Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 0E93C3A67A6 for <netconf@ietf.org>; Mon, 29 Jun 2009 10:14:44 -0700 (PDT)
Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 522129812E; Mon, 29 Jun 2009 10:15:01 -0700 (PDT)
Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 3310E399B49; Mon, 29 Jun 2009 10:15:01 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Andy Bierman <andy@netconfcentral.com>
Organization: Sparta
References: <200906251812.OAA17955@adminfs.snmp.com> <200906251817.n5PIHHlI018841@idle.juniper.net> <fc9ee3fe57e4.4a449a6f@huaweisymantec.com> <4A443788.2080904@netconfcentral.com>
Date: Mon, 29 Jun 2009 10:15:01 -0700
In-Reply-To: <4A443788.2080904@netconfcentral.com> (Andy Bierman's message of "Thu, 25 Jun 2009 19:50:48 -0700")
Message-ID: <sdeit3rmga.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: netconf@ietf.org
Subject: Re: [Netconf] xml start directive with ssh
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 17:14:46 -0000

>>>>> On Thu, 25 Jun 2009 19:50:48 -0700, Andy Bierman <andy@netconfcentral.com> said:

AB> At the time 4742 was written, nobody in the WG was aware of how
AB> SSH subsystems actually worked.

No, it was a deliberate decision that some systems might want to only
start a netconf agent based on a command line flag.  Subsystems were
understood at the time, people just wanted to be able to exercise both
potential "start" mechanisms.


From andy@netconfcentral.com  Mon Jun 29 10:53:16 2009
Return-Path: <andy@netconfcentral.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B033A6D35 for <netconf@core3.amsl.com>; Mon, 29 Jun 2009 10:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level: 
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+UQaxMrhs3E for <netconf@core3.amsl.com>; Mon, 29 Jun 2009 10:53:15 -0700 (PDT)
Received: from n26.bullet.mail.mud.yahoo.com (n26.bullet.mail.mud.yahoo.com [68.142.206.221]) by core3.amsl.com (Postfix) with SMTP id 5E1233A6D2A for <netconf@ietf.org>; Mon, 29 Jun 2009 10:53:15 -0700 (PDT)
Received: from [68.142.194.244] by n26.bullet.mail.mud.yahoo.com with NNFMP; 29 Jun 2009 17:53:15 -0000
Received: from [68.142.201.243] by t2.bullet.mud.yahoo.com with NNFMP; 29 Jun 2009 17:53:15 -0000
Received: from [127.0.0.1] by omp404.mail.mud.yahoo.com with NNFMP; 29 Jun 2009 17:53:15 -0000
X-Yahoo-Newman-Id: 756172.28649.bm@omp404.mail.mud.yahoo.com
Received: (qmail 90535 invoked from network); 29 Jun 2009 17:53:15 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@68.120.228.134 with plain) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 29 Jun 2009 17:53:14 -0000
X-YMail-OSG: _BPC1dYVM1kNoRLH3L4TsNDTBLcYMbMIh6OU9VyQoBwx31XWMUZZH.6Q_lK28XiP4vKTZfX9rxWMhkgobsy4NnoWhdQhKJe0s0oMGG9YeDmWTunZVieHG8eEkeLbVmHMHg.8qKAz1QRHfzCDaKmrU5BqLtkhx3HjOt2P59IQekeNQINEDg7qF8A9dS1qnZuZZuUBwnbdg47KFmK.6CIHttsVt2SuRng_x7IJXaHsMNJMxb7h9QapdtsSWm__w9nK8GkolCxa6Jmm4ah3XXRhVMLKPyN.csRWz85vWdeBQXGnHqwZYf5mYyb46mdJ6oa8CwI2j1E.T62oTesojhDWqLISrK0MNHF_gJGJRdeThGyhFEcLEQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A48FF7E.1070301@netconfcentral.com>
Date: Mon, 29 Jun 2009 10:53:02 -0700
From: Andy Bierman <andy@netconfcentral.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Wes Hardaker <wjhns1@hardakers.net>
References: <200906251812.OAA17955@adminfs.snmp.com>	<200906251817.n5PIHHlI018841@idle.juniper.net>	<fc9ee3fe57e4.4a449a6f@huaweisymantec.com>	<4A443788.2080904@netconfcentral.com> <sdeit3rmga.fsf@wes.hardakers.net>
In-Reply-To: <sdeit3rmga.fsf@wes.hardakers.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] xml start directive with ssh
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 17:53:16 -0000

Wes Hardaker wrote:
>>>>>> On Thu, 25 Jun 2009 19:50:48 -0700, Andy Bierman <andy@netconfcentral.com> said:
> 
> AB> At the time 4742 was written, nobody in the WG was aware of how
> AB> SSH subsystems actually worked.
> 
> No, it was a deliberate decision that some systems might want to only
> start a netconf agent based on a command line flag.  Subsystems were
> understood at the time, people just wanted to be able to exercise both
> potential "start" mechanisms.
> 
> 

Well, this other 'start mechanism' was never documented,
if it was discussed in any detail.  It was understood
at the time that the 'netconf' subsystem must be specified,
when starting up ssh from the command line.

There was discussion at the time about logging into the CLI,
however that is done, and then some sort of 'switch to NETCONF'
command would be issued, and the NETCONF subsystem would
then be started somehow.

I really don't remember any rules about garbage text passed to the
NETCONF subsystem before the <hello>.  What if the <hello>
is in a string or XML comment, and not 'real'?  Is the
garbage supposed to be parsed in case there is any XML or
quoted strings in there?

I think the NETCONF subsystem should only send and receive
XML instance documents.  I would be surprised if any implementations
accepted arbitrary garbage text at any time.



Andy


From wes@hardakers.net  Mon Jun 29 12:41:47 2009
Return-Path: <wes@hardakers.net>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46FD28C2BA for <netconf@core3.amsl.com>; Mon, 29 Jun 2009 12:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeAJlrIKjNsK for <netconf@core3.amsl.com>; Mon, 29 Jun 2009 12:41:47 -0700 (PDT)
Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id EFAD228C0DF for <netconf@ietf.org>; Mon, 29 Jun 2009 12:41:46 -0700 (PDT)
Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id C0E2098182; Mon, 29 Jun 2009 12:42:06 -0700 (PDT)
Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 8D51C399B49; Mon, 29 Jun 2009 12:42:06 -0700 (PDT)
From: Wes Hardaker <wes@hardakers.net>
To: Andy Bierman <andy@netconfcentral.com>
Organization: Sparta
References: <200906251812.OAA17955@adminfs.snmp.com> <200906251817.n5PIHHlI018841@idle.juniper.net> <fc9ee3fe57e4.4a449a6f@huaweisymantec.com> <4A443788.2080904@netconfcentral.com> <sdeit3rmga.fsf@wes.hardakers.net> <4A48FF7E.1070301@netconfcentral.com>
Date: Mon, 29 Jun 2009 12:42:06 -0700
In-Reply-To: <4A48FF7E.1070301@netconfcentral.com> (Andy Bierman's message of "Mon, 29 Jun 2009 10:53:02 -0700")
Message-ID: <sd63eeg73l.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailman-Approved-At: Mon, 29 Jun 2009 12:44:31 -0700
Cc: netconf@ietf.org
Subject: Re: [Netconf] xml start directive with ssh
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 19:41:47 -0000

>>>>> On Mon, 29 Jun 2009 10:53:02 -0700, Andy Bierman <andy@netconfcentral.com> said:

AB> I think the NETCONF subsystem should only send and receive
AB> XML instance documents.  I would be surprised if any implementations
AB> accepted arbitrary garbage text at any time.

I do agree that it would be a much cleaner service if we stop trying to
do the odd protocol mashing.  If a bis is ever done I agree it should be
dropped.