From netconf-bounces@ietf.org Fri May 2 08:22:38 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933B228C3D2; Fri, 2 May 2008 08:22:38 -0700 (PDT) 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 CEB2328C410 for ; Fri, 2 May 2008 08:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 Ed1p4WjwQmqe for ; Fri, 2 May 2008 08:22:35 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 80A2528C3DF for ; Fri, 2 May 2008 08:22:35 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m42FMQk21617; Fri, 2 May 2008 15:22:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 May 2008 11:22:01 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4145DFBB5@zcarhxm2.corp.nortel.com> In-Reply-To: <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue X: access to notification content Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvAABsEUIABWhJqg References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , "Bert Wijnen - IETF" , Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi The originator of the discuss was satisfied that his concerns were addressed, I think you are raising different issues. The problem is that the access control model is not yet defined and we need to be careful about the assumptions we make about it. We also need to be careful to not confuse authorization with how the information is actually available (synchronous/asynchronous, NETCONF/Syslog/SNMP). We do have the open question about the access control model on those implementations that are tunnelling syslog or SNMP traffic in NETCONF. Another reason I'm not a fan of this feature. In a lot of implementations I expect these to map to a single underlying authorization model, but since nothing has been standardized in the IETF, we can't make that assumption here. Is this something we should solve now or as part of the access control discussion? Presumably it applies to notification and traffic equally. I think it should be solved more generally. By proposed text, did you mean: "she probably should not ... depending on the access control model and administrative policy." Which From netconf-bounces@ietf.org Fri May 2 08:22:38 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933B228C3D2; Fri, 2 May 2008 08:22:38 -0700 (PDT) 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 CEB2328C410 for ; Fri, 2 May 2008 08:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 Ed1p4WjwQmqe for ; Fri, 2 May 2008 08:22:35 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 80A2528C3DF for ; Fri, 2 May 2008 08:22:35 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m42FMQk21617; Fri, 2 May 2008 15:22:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 May 2008 11:22:01 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4145DFBB5@zcarhxm2.corp.nortel.com> In-Reply-To: <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue X: access to notification content Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvAABsEUIABWhJqg References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , "Bert Wijnen - IETF" , Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi The originator of the discuss was satisfied that his concerns were addressed, I think you are raising different issues. The problem is that the access control model is not yet defined and we need to be careful about the assumptions we make about it. We also need to be careful to not confuse authorization with how the information is actually available (synchronous/asynchronous, NETCONF/Syslog/SNMP). We do have the open question about the access control model on those implementations that are tunnelling syslog or SNMP traffic in NETCONF. Another reason I'm not a fan of this feature. In a lot of implementations I expect these to map to a single underlying authorization model, but since nothing has been standardized in the IETF, we can't make that assumption here. Is this something we should solve now or as part of the access control discussion? Presumably it applies to notification and traffic equally. I think it should be solved more generally. By proposed text, did you mean: "she probably should not ... depending on the access control model and administrative policy." Which I proposed to change to "she likely will not ... depending on the access control model and administrative policy." Sharon -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Wednesday, April 30, 2008 5:53 PM To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; netconf@ietf.org Subject: RE: Issue X: access to notification content Hi, I don't think your proposed change addresses the security review concern. It doesn't say how access will be controlled. I think my proposed text does, by saying it will be handled by the access control model and adminstrative policy. Is there a reason you don't find my proposed text acceptable? dbh > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Wednesday, April 30, 2008 2:39 PM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > Hi > > I can change from "she must not" to "she likely will not". I think the > probably softens things too much. The intent is that you only get to > view content you have permission to view, regardless of the access > mechanisms. > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Tuesday, April 29, 2008 10:25 AM > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > netconf@ietf.org > Subject: RE: Issue X: access to notification content > > Hi, > > If it is only a discussion, then I suggest rewording "she must not > ..." > to "she probably should not ... depending on the access control model > and administrative policy." > > This does not create a CLR. > > dbh > > > -----Original Message----- > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > Sent: Tuesday, April 29, 2008 2:41 AM > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Dave, this is a clarification to an concern from an IESG member. > > It is in the "Security Considerations" section, so it is > not a "hard > > choice of protocol standard". We are explaining in the security > > considerations section what kind of access concerns there might be. > > Does that clarify? > > > > Sharon, do you have other comments on Dave's concern? > > > > Bert Wijnen > > > > > -----Oorspronkelijk bericht----- > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > Verzonden: maandag 28 april 2008 19:28 > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > Onderwerp: Issue X: access to notification content > > > > > > > > > Hi bert, > > > > > > There were a bunch of issues I raised on 4/23 that I think > > Sharon just > > > didn't understand and didn't fix. here's one: > > > > > > -- > > > In section 7, the text says "If a user does not have > > > permission to view content via other NETCONF operations, she > must > > > not > > > have access to that content via Notifications." > > > > > > This creates a big CLR. > > > > > > Can content from a syslog or SNMP notification stream be > sent to a > > > user that does not have permission to access the syslog or SNMP > > > content using some other Netconf operation? What other Netconf > > > operation works with the syslog stream? Didn't we > > explicitly decide it > > > was not necessary to support access to notication streams > > > (including syslog and SNMP streams)? > > > > > > I am also concerned that this access control "policy" > should be an > > > administrative one, not a hard choice of the protocol > standard. In > > > most cases it is the right choice. But a NOC manager > might want to > > > allow, say, the helpdesk to be alerted whenever a Netconf config > is > > > being changed, or an intrusion detection application to > be alerted > > > when there is an authentication failure. And yet, they may > > not want to > > > give the helpdesk or the IDS permissions. With this CLR, a > NOC > > > manager is simply not allowed to make such a decision. > > > > > > I understand the intent; I think the wording is poorly chosen, > > > especially because it uses a "must", which has special > > RFC2119 meaning > > > and creates a huge CLR. And since access control will be > > done later, I > > > don't think the WG wants this CLR constraining all future > > AC designs. > > > > > > But I could be wrong; maybe the WG will decide this is exactly > what > > > they want to say. If that is the case, then I think we need > > to review > > > this document to make sure everything else (like syslog streams) > can > > > work with this CLR. > > > > > > dbh > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf I proposed to change to "she likely will not ... depending on the access control model and administrative policy." Sharon -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Wednesday, April 30, 2008 5:53 PM To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; netconf@ietf.org Subject: RE: Issue X: access to notification content Hi, I don't think your proposed change addresses the security review concern. It doesn't say how access will be controlled. I think my proposed text does, by saying it will be handled by the access control model and adminstrative policy. Is there a reason you don't find my proposed text acceptable? dbh > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Wednesday, April 30, 2008 2:39 PM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > Hi > > I can change from "she must not" to "she likely will not". I think the > probably softens things too much. The intent is that you only get to > view content you have permission to view, regardless of the access > mechanisms. > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Tuesday, April 29, 2008 10:25 AM > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > netconf@ietf.org > Subject: RE: Issue X: access to notification content > > Hi, > > If it is only a discussion, then I suggest rewording "she must not > ..." > to "she probably should not ... depending on the access control model > and administrative policy." > > This does not create a CLR. > > dbh > > > -----Original Message----- > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > Sent: Tuesday, April 29, 2008 2:41 AM > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Dave, this is a clarification to an concern from an IESG member. > > It is in the "Security Considerations" section, so it is > not a "hard > > choice of protocol standard". We are explaining in the security > > considerations section what kind of access concerns there might be. > > Does that clarify? > > > > Sharon, do you have other comments on Dave's concern? > > > > Bert Wijnen > > > > > -----Oorspronkelijk bericht----- > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > Verzonden: maandag 28 april 2008 19:28 > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > Onderwerp: Issue X: access to notification content > > > > > > > > > Hi bert, > > > > > > There were a bunch of issues I raised on 4/23 that I think > > Sharon just > > > didn't understand and didn't fix. here's one: > > > > > > -- > > > In section 7, the text says "If a user does not have > > > permission to view content via other NETCONF operations, she > must > > > not > > > have access to that content via Notifications." > > > > > > This creates a big CLR. > > > > > > Can content from a syslog or SNMP notification stream be > sent to a > > > user that does not have permission to access the syslog or SNMP > > > content using some other Netconf operation? What other Netconf > > > operation works with the syslog stream? Didn't we > > explicitly decide it > > > was not necessary to support access to notication streams > > > (including syslog and SNMP streams)? > > > > > > I am also concerned that this access control "policy" > should be an > > > administrative one, not a hard choice of the protocol > standard. In > > > most cases it is the right choice. But a NOC manager > might want to > > > allow, say, the helpdesk to be alerted whenever a Netconf config > is > > > being changed, or an intrusion detection application to > be alerted > > > when there is an authentication failure. And yet, they may > > not want to > > > give the helpdesk or the IDS permissions. With this CLR, a > NOC > > > manager is simply not allowed to make such a decision. > > > > > > I understand the intent; I think the wording is poorly chosen, > > > especially because it uses a "must", which has special > > RFC2119 meaning > > > and creates a huge CLR. And since access control will be > > done later, I > > > don't think the WG wants this CLR constraining all future > > AC designs. > > > > > > But I could be wrong; maybe the WG will decide this is exactly > what > > > they want to say. If that is the case, then I think we need > > to review > > > this document to make sure everything else (like syslog streams) > can > > > work with this CLR. > > > > > > dbh > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 2 10:40:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8482D3A6ACD; Fri, 2 May 2008 10:40:55 -0700 (PDT) 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 D7EFC3A6ACD for ; Fri, 2 May 2008 10:40:54 -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] 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 es49fOphiNhq for ; Fri, 2 May 2008 10:40:53 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id D33193A6A56 for ; Fri, 2 May 2008 10:40:53 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id Lc3P1Z0030EPchoA70RR00; Fri, 02 May 2008 17:40:44 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id Lhgt1Z00E4HwxpC8M00000; Fri, 02 May 2008 17:40:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=HHmwR-jtwyEA:10 a=Vu4nIF-vJQAA:10 a=RmSreRG0cfL-IdSgBqgA:9 a=TToazjnJSt0opKw95n0A:7 a=73XoNRzw1JGv8fCJgGATiI37XYcA:4 a=ZPn7O4N2MpQA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=jFPUFpGHtmAA:10 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'Sharon Chisholm'" , "'Bert Wijnen - IETF'" , References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145DFBB5@zcarhxm2.corp.nortel.com> Date: Fri, 2 May 2008 13:40:53 -0400 Message-ID: <00a901c8ac7b$ac789e40$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4145DFBB5@zcarhxm2.corp.nortel.com> Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvAABsEUIABWhJqgAAUdWGA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Friday, May 02, 2008 11:22 AM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > By proposed text, did you mean: > > "she probably should not ... depending on the access control model and > administrative policy." > > Which I proposed to change to > > "she likely will not ... depending on the access control model and > administrative policy." That is not what your earlier response said. The proposal in your response did not include the text after the ellipsis. I prefer "she probably should not" because "should not" is RFC2119 language. You might want to stiffen that slightly by making it "she probably SHOULD NOT ... depending on the access control model and administrative policy." > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Wednesday, April 30, 2008 5:53 PM > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > netconf@ietf.org > Subject: RE: Issue X: access to notification content > > Hi, > > I don't think your proposed change addresses the security review > concern. It doesn't say how access will be controlled. > > I think my proposed text does, by saying it will be handled by the > access control model and adminstrative policy. > > Is there a reason you don't find my proposed text acceptable? > > dbh > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > Sent: Wednesday, April 30, 2008 2:39 PM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi > > > > I can change from "she must not" to "she likely will not". I think > the > > probably softens things too much. The intent is that you > only get to > > view content you have permission to view, regardless of the access > > mechanisms. > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Tuesday, April 29, 2008 10:25 AM > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi, > > > > If it is only a discussion, then I suggest rewording "she must not > > ..." > > to "she probably should not ... depending on the access control > model > > and administrative policy." > > > > This does not create a CLR. > > > > dbh > > > > > -----Original Message----- > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Dave, this is a clarification to an concern from an IESG member. > > > It is in the "Security Considerations" section, so it is > > not a "hard > > > choice of protocol standard". We are explaining in the security > > > considerations section what kind of access concerns there might > be. > > > Does that clarify? > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > Bert Wijnen > > > > > > > -----Oorspronkelijk bericht----- > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > Verzonden: maandag 28 april 2008 19:28 > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > Hi bert, > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > Sharon just > > > > didn't understand and didn't fix. here's one: > > > > > > > > -- > > > > In section 7, the text says "If a user does not have > > > > permission to view content via other NETCONF operations, she > > must > > > > not > > > > have access to that content via Notifications." > > > > > > > > This creates a big CLR. > > > > > > > > Can content from a syslog or SNMP notification stream be > > sent to a > > > > user that does not have permission to access the syslog or SNMP > > > > content using some other Netconf operation? What other Netconf > > > > operation works with the syslog stream? Didn't we > > > explicitly decide it > > > > was not necessary to support access to notication streams > > > > (including syslog and SNMP streams)? > > > > > > > > I am also concerned that this access control "policy" > > should be an > > > > administrative one, not a hard choice of the protocol > > standard. In > > > > most cases it is the right choice. But a NOC manager > > might want to > > > > allow, say, the helpdesk to be alerted whenever a Netconf config > > is > > > > being changed, or an intrusion detection application to > > be alerted > > > > when there is an authentication failure. And yet, they may > > > not want to > > > > give the helpdesk or the IDS permissions. With this CLR, a > > NOC > > > > manager is simply not allowed to make such a decision. > > > > > > > > I understand the intent; I think the wording is poorly chosen, > > > > especially because it uses a "must", which has special > > > RFC2119 meaning > > > > and creates a huge CLR. And since access control will be > > > done later, I > > > > don't think the WG wants this CLR constraining all future > > > AC designs. > > > > > > > > But I could be wrong; maybe the WG will decide this is exactly > > what > > > > they want to say. If that is the case, then I think we need > > > to review > > > > this document to make sure everything else (like syslog streams) > > can > > > > work with this CLR. > > > > > > > > dbh > > > > > > > > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 2 10:40:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8482D3A6ACD; Fri, 2 May 2008 10:40:55 -0700 (PDT) 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 D7EFC3A6ACD for ; Fri, 2 May 2008 10:40:54 -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] 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 es49fOphiNhq for ; Fri, 2 May 2008 10:40:53 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id D33193A6A56 for ; Fri, 2 May 2008 10:40:53 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id Lc3P1Z0030EPchoA70RR00; Fri, 02 May 2008 17:40:44 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id Lhgt1Z00E4HwxpC8M00000; Fri, 02 May 2008 17:40:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=HHmwR-jtwyEA:10 a=Vu4nIF-vJQAA:10 a=RmSreRG0cfL-IdSgBqgA:9 a=TToazjnJSt0opKw95n0A:7 a=73XoNRzw1JGv8fCJgGATiI37XYcA:4 a=ZPn7O4N2MpQA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=jFPUFpGHtmAA:10 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'Sharon Chisholm'" , "'Bert Wijnen - IETF'" , References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145DFBB5@zcarhxm2.corp.nortel.com> Date: Fri, 2 May 2008 13:40:53 -0400 Message-ID: <00a901c8ac7b$ac789e40$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4145DFBB5@zcarhxm2.corp.nortel.com> Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvAABsEUIABWhJqgAAUdWGA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Friday, May 02, 2008 11:22 AM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > By proposed text, did you mean: > > "she probably should not ... depending on the access control model and > administrative policy." > > Which I proposed to change to > > "she likely will not ... depending on the access control model and > administrative policy." That is not what your earlier response said. The proposal in your response did not include the text after the ellipsis. I prefer "she probably should not" because "should not" is RFC2119 language. You might want to stiffen that slightly by making it "she probably SHOULD NOT ... depending on the access control model and administrative policy." > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Wednesday, April 30, 2008 5:53 PM > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > netconf@ietf.org > Subject: RE: Issue X: access to notification content > > Hi, > > I don't think your proposed change addresses the security review > concern. It doesn't say how access will be controlled. > > I think my proposed text does, by saying it will be handled by the > access control model and adminstrative policy. > > Is there a reason you don't find my proposed text acceptable? > > dbh > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > Sent: Wednesday, April 30, 2008 2:39 PM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi > > > > I can change from "she must not" to "she likely will not". I think > the > > probably softens things too much. The intent is that you > only get to > > view content you have permission to view, regardless of the access > > mechanisms. > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Tuesday, April 29, 2008 10:25 AM > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi, > > > > If it is only a discussion, then I suggest rewording "she must not > > ..." > > to "she probably should not ... depending on the access control > model > > and administrative policy." > > > > This does not create a CLR. > > > > dbh > > > > > -----Original Message----- > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Dave, this is a clarification to an concern from an IESG member. > > > It is in the "Security Considerations" section, so it is > > not a "hard > > > choice of protocol standard". We are explaining in the security > > > considerations section what kind of access concerns there might > be. > > > Does that clarify? > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > Bert Wijnen > > > > > > > -----Oorspronkelijk bericht----- > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > Verzonden: maandag 28 april 2008 19:28 > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > Hi bert, > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > Sharon just > > > > didn't understand and didn't fix. here's one: > > > > > > > > -- > > > > In section 7, the text says "If a user does not have > > > > permission to view content via other NETCONF operations, she > > must > > > > not > > > > have access to that content via Notifications." > > > > > > > > This creates a big CLR. > > > > > > > > Can content from a syslog or SNMP notification stream be > > sent to a > > > > user that does not have permission to access the syslog or SNMP > > > > content using some other Netconf operation? What other Netconf > > > > operation works with the syslog stream? Didn't we > > > explicitly decide it > > > > was not necessary to support access to notication streams > > > > (including syslog and SNMP streams)? > > > > > > > > I am also concerned that this access control "policy" > > should be an > > > > administrative one, not a hard choice of the protocol > > standard. In > > > > most cases it is the right choice. But a NOC manager > > might want to > > > > allow, say, the helpdesk to be alerted whenever a Netconf config > > is > > > > being changed, or an intrusion detection application to > > be alerted > > > > when there is an authentication failure. And yet, they may > > > not want to > > > > give the helpdesk or the IDS permissions. With this CLR, a > > NOC > > > > manager is simply not allowed to make such a decision. > > > > > > > > I understand the intent; I think the wording is poorly chosen, > > > > especially because it uses a "must", which has special > > > RFC2119 meaning > > > > and creates a huge CLR. And since access control will be > > > done later, I > > > > don't think the WG wants this CLR constraining all future > > > AC designs. > > > > > > > > But I could be wrong; maybe the WG will decide this is exactly > > what > > > > they want to say. If that is the case, then I think we need > > > to review > > > > this document to make sure everything else (like syslog streams) > > can > > > > work with this CLR. > > > > > > > > dbh > > > > > > > > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon May 5 05:09:40 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05923A6B65; Mon, 5 May 2008 05:09:40 -0700 (PDT) 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 3D49F3A6C69 for ; Mon, 5 May 2008 05:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 SJ1s5gjonPur for ; Mon, 5 May 2008 05:09:36 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2D35D3A6BEE for ; Mon, 5 May 2008 05:07:05 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m45C6UO23393; Mon, 5 May 2008 12:06:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 May 2008 08:06:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4145E07E1@zcarhxm2.corp.nortel.com> In-Reply-To: <002101c8a955$4e0565b0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues Thread-Index: AcimybQVJEZ5iqdXTweyEournL26jgABBQJgAfaRXuA= References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com><4811C0B5.7010907@cisco.com> <20080425114407.GC19025@elstar.local> <002101c8a955$4e0565b0$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , , "Eliot Lear" Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Just to close this off. It seems we are converging on not adding the ISO reference but just the RFC. (Note the RFC references the ISO specification and attempts to remove some ambiguities). Just to clarify what people want to do 1) Keep both references 2) Just have a reference to RFC3339 3) Just have a reference to RFC3339 section 4.4 and appendix A 4) Just have a reference to RFC3339 section 4.4 5) Just have a reference to RFC339 appendix A Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David B Harrington Sent: Monday, April 28, 2008 1:28 PM To: j.schoenwaelder@jacobs-university.de; 'Eliot Lear' Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues I believe we should follow RFC3339 section 4.4 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Friday, April 25, 2008 7:44 AM > TFrom netconf-bounces@ietf.org Mon May 5 05:09:40 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05923A6B65; Mon, 5 May 2008 05:09:40 -0700 (PDT) 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 3D49F3A6C69 for ; Mon, 5 May 2008 05:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 SJ1s5gjonPur for ; Mon, 5 May 2008 05:09:36 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2D35D3A6BEE for ; Mon, 5 May 2008 05:07:05 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m45C6UO23393; Mon, 5 May 2008 12:06:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 May 2008 08:06:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4145E07E1@zcarhxm2.corp.nortel.com> In-Reply-To: <002101c8a955$4e0565b0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues Thread-Index: AcimybQVJEZ5iqdXTweyEournL26jgABBQJgAfaRXuA= References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com><4811C0B5.7010907@cisco.com> <20080425114407.GC19025@elstar.local> <002101c8a955$4e0565b0$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , , "Eliot Lear" Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Just to close this off. It seems we are converging on not adding the ISO reference but just the RFC. (Note the RFC references the ISO specification and attempts to remove some ambiguities). Just to clarify what people want to do 1) Keep both references 2) Just have a reference to RFC3339 3) Just have a reference to RFC3339 section 4.4 and appendix A 4) Just have a reference to RFC3339 section 4.4 5) Just have a reference to RFC339 appendix A Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David B Harrington Sent: Monday, April 28, 2008 1:28 PM To: j.schoenwaelder@jacobs-university.de; 'Eliot Lear' Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues I believe we should follow RFC3339 section 4.4 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Friday, April 25, 2008 7:44 o: Eliot Lear > Cc: netconf@ietf.org > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > Issues > > On Fri, Apr 25, 2008 at 01:29:57PM +0200, Eliot Lear wrote: > > Hi Sharon, > > > > This comment is largely bureaucratic: > > > > > Proposed Edits > > > -------------- > > > > > > A. In section 2.1.1, for both instances and in section > 2.2.1 Replace > > > This parameter is of type dateTime. > > > With > > > This parameter is of type dateTime and compliant to > [RFC3339] and > > > [ISO.8601.1988]. > > > > > > > RFC 3339 specifically uses a subset of ISO.8601.1988. As this > > discussion illustrates it is possible to construct times that are > > compliant with the latter and non-compliant with the > former. I believe > > that ISO.8601.1988 is a superset of RFC 3339. If you wish > compliance > > with "both", my recommendation would be to specify only > ISO.8601.1988. > > This would meet Juergen's requirement of being able to specify an > > unqualified timezone. > > > > ALTERNATIVELY, you could require times to be in > ISO.8601.1988 format, as > > specified in Appendix A of RFC 3339. > > > > Pointing at two standards covering the precise same > specification is > > just asking for a poke in the eye. > > Good bureaucratic comment. Reading section 4.4 or RFC 3339, I should > probably shut up and be fine with requiring a timezone to be known by > a conforming device and then we can perhaps go with the RFC 3339 > subset. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf AM > To: Eliot Lear > Cc: netconf@ietf.org > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > Issues > > On Fri, Apr 25, 2008 at 01:29:57PM +0200, Eliot Lear wrote: > > Hi Sharon, > > > > This comment is largely bureaucratic: > > > > > Proposed Edits > > > -------------- > > > > > > A. In section 2.1.1, for both instances and in section > 2.2.1 Replace > > > This parameter is of type dateTime. > > > With > > > This parameter is of type dateTime and compliant to > [RFC3339] and > > > [ISO.8601.1988]. > > > > > > > RFC 3339 specifically uses a subset of ISO.8601.1988. As this > > discussion illustrates it is possible to construct times that are > > compliant with the latter and non-compliant with the > former. I believe > > that ISO.8601.1988 is a superset of RFC 3339. If you wish > compliance > > with "both", my recommendation would be to specify only > ISO.8601.1988. > > This would meet Juergen's requirement of being able to specify an > > unqualified timezone. > > > > ALTERNATIVELY, you could require times to be in > ISO.8601.1988 format, as > > specified in Appendix A of RFC 3339. > > > > Pointing at two standards covering the precise same > specification is > > just asking for a poke in the eye. > > Good bureaucratic comment. Reading section 4.4 or RFC 3339, I should > probably shut up and be fine with requiring a timezone to be known by > a conforming device and then we can perhaps go with the RFC 3339 > subset. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon May 5 05:33:31 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74983A6B6C; Mon, 5 May 2008 05:33:31 -0700 (PDT) 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 C19203A682C for ; Mon, 5 May 2008 05:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_50=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 wKdPdXXiV5l6 for ; Mon, 5 May 2008 05:33:26 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5753A3A6B6C for ; Mon, 5 May 2008 05:33:26 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m45CXJO27588; Mon, 5 May 2008 12:33:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 May 2008 08:33:12 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4145E0839@zcarhxm2.corp.nortel.com> In-Reply-To: <00a901c8ac7b$ac789e40$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue X: access to notification content Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvAABsEUIABWhJqgAAUdWGAAi9ih4A== References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145DFBB5@zcarhxm2.corp.nortel.com> <00a901c8ac7b$ac789e40$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , "Bert Wijnen - IETF" , Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I think it would be helpful to go back to original text we are editing rather then the snippets. I've modified the second sentence in ways that I think address the access versus authorization confusion and I think makes it so we can keep the 'must not'. I think now we don't need to 'depending on access control..." part because we are make a recommendation about the access control in order to maintain minimal security. I've added a third option which tries to include those for comparison. I prefer A. Current text The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view content via other NETCONF operations, she must not have access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. Proposed text (A) The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view the information in the notification, they must not have access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. Proposed text (B) The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view the information in the notification, the access control model and administrative policy probably should not allow them access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. I also got rid of the 'she' thing since I think the singular use of 'they' is now grammatically acceptable in these cases. Sharon -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Friday, May 02, 2008 1:41 PM To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; netconf@ietf.org Subject: RE: Issue X: access to notification content > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Friday, May 02, 2008 11:22 AM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > By proposed text, did you mean: > > "she probably should not ... depending on the access control model and > administrative policy." > > Which I proposed to change to > > "she likely will not ... depending on the access control model and > administrative policy." That is not what your earlier response said. The proposal in your response did not include the text after the ellipsis. I prefer "she probably should not" because "should not" is RFC2119 language. You might want to stiffen that slightly by making it "she probably SHOULD NOT ... depending on the access control model and administrative policy." > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Wednesday, April 30, 2008 5:53 PM > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > netconf@ietf.org > Subject: RE: Issue X: access to notification content > > Hi, > > I don't think your proposed change addresses the security review > concern. It doesn't say how access will be controlled. > > I think my proposed text does, by saying it will be handled by the > access control model and adminstrative policy. > > Is there a reason you don't find my proposed text acceptable? > > dbh > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > Sent: Wednesday, April 30, 2008 2:39 PM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi > > > > I can change from "she must not" to "she likely will not". I think > the > > probably softens things too much. The intent is that you > only get to > > view content you have permission to view, regardless of the access > > mechanisms. > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Tuesday, April 29, 2008 10:25 AM > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi, > > > > If it is only a discussion, then I suggest rewording "she must not > > ..." > > to "she probably should not ... depending on the access control > model > > and administrative policy." > > > > This does not create a CLR. > > > > dbh > > > > > -----Original Message----- > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Dave, this is a clarification to an concern from an IESG member. > > > It is in the "Security Considerations" section, so it is > > not a "hard > > > choice of protocol standard". We are explaining in the security > > > considerations section what kind of access concerns there might > be. > > > Does that clarify? > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > Bert Wijnen > > > > > > > -----Oorspronkelijk bericht----- > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > Verzonden: maandag 28 april 2008 19:28 > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > Hi bert, > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > Sharon just > > > > didn't understand and didn't fix. here's one: > > > > > > > > -- > > > > In section 7, the text says "If a user does not have > > > > permission to view content via other NETCONF operations, she > > must > > > > not > > > > have access to that content via Notifications." > > > > > > > > This creates a big CLR. > > > > > > > > Can content from a syslog or SNMP notification stream be > > sent to a > > > > user that does not have permission to access the syslog or SNMP > > > > content using some other Netconf operation? What other Netconf > > > > operation works with the syslog stream? Didn't we > > > explicitly decide it > > > > was not necessary to support access to notication streams > > > > (including syslog and SNMP streams)? > > > > > > > > I am also concerned that this access control "policy" > > should be an > > > > administrative one, not a hard choice of the protocol > > standard. In > > > > most cases it is the right choice. But a NOC manager > > might want to > > > > allow, say, the helpdesk to be alerted whenever a Netconf config > > is > > > > being changed, or an intrusion detection application to > > be alerted > > > > when there is an authentication failure. And yet, they may > > > not want to > > > > give the helpdesk or the IDS permissions. With this CLR, a > > NOC > > > > manager is simply not allowed to make such a decision. > > > > > > > > I understand the intent; I think the wording is poorly chosen, > > > > especially because it uses a "must", which has special > > > RFC2119 meaning > > > > and creates a huge CLR. And since access control will be > > > done later, I > > > > don't think the WG wants this CLR constraining all future > > > AC designs. > > > > > > > > But I could be wrong; maybe the WG will decide this is exactly > > what > > > > they want to say. If that is the case, then I think we need > > > to review > > > > this document to make sure everything else (like syslog streams) > > can > > > > work with this CLR. > > > > > > > > dbh > > > > > > > > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon May 5 05:33:31 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74983A6B6C; Mon, 5 May 2008 05:33:31 -0700 (PDT) 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 C19203A682C for ; Mon, 5 May 2008 05:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_50=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 wKdPdXXiV5l6 for ; Mon, 5 May 2008 05:33:26 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5753A3A6B6C for ; Mon, 5 May 2008 05:33:26 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m45CXJO27588; Mon, 5 May 2008 12:33:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 May 2008 08:33:12 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4145E0839@zcarhxm2.corp.nortel.com> In-Reply-To: <00a901c8ac7b$ac789e40$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue X: access to notification content Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvAABsEUIABWhJqgAAUdWGAAi9ih4A== References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145DFBB5@zcarhxm2.corp.nortel.com> <00a901c8ac7b$ac789e40$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , "Bert Wijnen - IETF" , Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I think it would be helpful to go back to original text we are editing rather then the snippets. I've modified the second sentence in ways that I think address the access versus authorization confusion and I think makes it so we can keep the 'must not'. I think now we don't need to 'depending on access control..." part because we are make a recommendation about the access control in order to maintain minimal security. I've added a third option which tries to include those for comparison. I prefer A. Current text The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view content via other NETCONF operations, she must not have access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. Proposed text (A) The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view the information in the notification, they must not have access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. Proposed text (B) The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view the information in the notification, the access control model and administrative policy probably should not allow them access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. I also got rid of the 'she' thing since I think the singular use of 'they' is now grammatically acceptable in these cases. Sharon -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Friday, May 02, 2008 1:41 PM To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; netconf@ietf.org Subject: RE: Issue X: access to notification content > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Friday, May 02, 2008 11:22 AM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > By proposed text, did you mean: > > "she probably should not ... depending on the access control model and > administrative policy." > > Which I proposed to change to > > "she likely will not ... depending on the access control model and > administrative policy." That is not what your earlier response said. The proposal in your response did not include the text after the ellipsis. I prefer "she probably should not" because "should not" is RFC2119 language. You might want to stiffen that slightly by making it "she probably SHOULD NOT ... depending on the access control model and administrative policy." > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Wednesday, April 30, 2008 5:53 PM > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > netconf@ietf.org > Subject: RE: Issue X: access to notification content > > Hi, > > I don't think your proposed change addresses the security review > concern. It doesn't say how access will be controlled. > > I think my proposed text does, by saying it will be handled by the > access control model and adminstrative policy. > > Is there a reason you don't find my proposed text acceptable? > > dbh > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > Sent: Wednesday, April 30, 2008 2:39 PM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi > > > > I can change from "she must not" to "she likely will not". I think > the > > probably softens things too much. The intent is that you > only get to > > view content you have permission to view, regardless of the access > > mechanisms. > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Tuesday, April 29, 2008 10:25 AM > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi, > > > > If it is only a discussion, then I suggest rewording "she must not > > ..." > > to "she probably should not ... depending on the access control > model > > and administrative policy." > > > > This does not create a CLR. > > > > dbh > > > > > -----Original Message----- > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Dave, this is a clarification to an concern from an IESG member. > > > It is in the "Security Considerations" section, so it is > > not a "hard > > > choice of protocol standard". We are explaining in the security > > > considerations section what kind of access concerns there might > be. > > > Does that clarify? > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > Bert Wijnen > > > > > > > -----Oorspronkelijk bericht----- > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > Verzonden: maandag 28 april 2008 19:28 > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > Hi bert, > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > Sharon just > > > > didn't understand and didn't fix. here's one: > > > > > > > > -- > > > > In section 7, the text says "If a user does not have > > > > permission to view content via other NETCONF operations, she > > must > > > > not > > > > have access to that content via Notifications." > > > > > > > > This creates a big CLR. > > > > > > > > Can content from a syslog or SNMP notification stream be > > sent to a > > > > user that does not have permission to access the syslog or SNMP > > > > content using some other Netconf operation? What other Netconf > > > > operation works with the syslog stream? Didn't we > > > explicitly decide it > > > > was not necessary to support access to notication streams > > > > (including syslog and SNMP streams)? > > > > > > > > I am also concerned that this access control "policy" > > should be an > > > > administrative one, not a hard choice of the protocol > > standard. In > > > > most cases it is the right choice. But a NOC manager > > might want to > > > > allow, say, the helpdesk to be alerted whenever a Netconf config > > is > > > > being changed, or an intrusion detection application to > > be alerted > > > > when there is an authentication failure. And yet, they may > > > not want to > > > > give the helpdesk or the IDS permissions. With this CLR, a > > NOC > > > > manager is simply not allowed to make such a decision. > > > > > > > > I understand the intent; I think the wording is poorly chosen, > > > > especially because it uses a "must", which has special > > > RFC2119 meaning > > > > and creates a huge CLR. And since access control will be > > > done later, I > > > > don't think the WG wants this CLR constraining all future > > > AC designs. > > > > > > > > But I could be wrong; maybe the WG will decide this is exactly > > what > > > > they want to say. If that is the case, then I think we need > > > to review > > > > this document to make sure everything else (like syslog streams) > > can > > > > work with this CLR. > > > > > > > > dbh > > > > > > > > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 01:48:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5FA3A6A27; Tue, 6 May 2008 01:48:39 -0700 (PDT) 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 623313A6A27 for ; Tue, 6 May 2008 01:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.132, 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 0ex+fLC27+6U for ; Tue, 6 May 2008 01:48:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 64CD23A6827 for ; Tue, 6 May 2008 01:48:38 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26428C0017 for ; Tue, 6 May 2008 10:48:49 +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 hA41tMTLEvX5; Tue, 6 May 2008 10:48:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CAAFC0014; Tue, 6 May 2008 10:48:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 66EE0571D11; Tue, 6 May 2008 10:48:30 +0200 (CEST) Date: Tue, 6 May 2008 10:48:30 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20080506084830.GE29870@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, are XML declarations required for NETCONF messages or optional? I could not find an answer in the RFCs and it seems that some implementations require XML declarations in NETCONF messages while others don't. XML 1.0 seems to require XML declarations for valid XML documents but then RFC 4741 or RFC 4742 are silent about the question whether NETCONF messages must be valid XML or just well-formed. If XML declarations are required, what is the error code to return? /js PS The last question touches a general issue; the RFC does not provide much detail which error codes apply where and so implementations seem to return pretty different results when you feed them with carefully crafted input. There are several other places where RFC 4741 is inconsistent; shall we start an effort to work on a -bis version so that we can fix the specs as we test implementations? -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 ___From netconf-bounces@ietf.org Tue May 6 01:48:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5FA3A6A27; Tue, 6 May 2008 01:48:39 -0700 (PDT) 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 623313A6A27 for ; Tue, 6 May 2008 01:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.132, 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 0ex+fLC27+6U for ; Tue, 6 May 2008 01:48:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 64CD23A6827 for ; Tue, 6 May 2008 01:48:38 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26428C0017 for ; Tue, 6 May 2008 10:48:49 +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 hA41tMTLEvX5; Tue, 6 May 2008 10:48:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CAAFC0014; Tue, 6 May 2008 10:48:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 66EE0571D11; Tue, 6 May 2008 10:48:30 +0200 (CEST) Date: Tue, 6 May 2008 10:48:30 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20080506084830.GE29870@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, are XML declarations required for NETCONF messages or optional? I could not find an answer in the RFCs and it seems that some implementations require XML declarations in NETCONF messages while others don't. XML 1.0 seems to require XML declarations for valid XML documents but then RFC 4741 or RFC 4742 are silent about the question whether NETCONF messages must be valid XML or just well-formed. If XML declarations are required, what is the error code to return? /js PS The last question touches a general issue; the RFC does not provide much detail which error codes apply where and so implementations seem to return pretty different results when you feed them with carefully crafted input. There are several other places where RFC 4741 is inconsistent; shall we start an effort to work on a -bis version so that we can fix the specs as we test implementations? -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 07:27:36 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FC93A6C59; Tue, 6 May 2008 07:27:36 -0700 (PDT) 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 1D6533A688E for ; Tue, 6 May 2008 07:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.577 X-Spam-Level: X-Spam-Status: No, score=-5.577 tagged_above=-999 required=5 tests=[AWL=1.022, 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 I4GVX+vUBMkz for ; Tue, 6 May 2008 07:27:32 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D33093A6BD7 for ; Tue, 6 May 2008 07:26:14 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m46EQ7027928; Tue, 6 May 2008 14:26:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 10:25:56 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41469B251@zcarhxm2.corp.nortel.com> In-Reply-To: <20080506084830.GE29870@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] xml declaration required or optional Thread-Index: AcivVf8kChT53vL4QG2G+Dj0uMchlQALqUGQ References: <20080506084830.GE29870@elstar.local> From: "Sharon Chisholm" To: , Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi It's not a bad idea. Another ambiguity seems to be whether the reply to and contains the element or not. We are also suppose to be doing -bis to the transport mappings to add text around although if we touch it we might want to see if we need to make the text more general if we think we might ever add something else that doesn't use the layer. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, May 06, 2008 4:48 AM To: netconf@ietf.org Subject: [Netconf] xml declaration required or optional Hi, are XML declarations required for NETCONF messages or optional? I could not find an answer in the RFCs and it seems that some implementations require XML declarations in NETCONF messages while others don't. XML 1.0 seems to require XML declarations for valid XML documents but then RFC 4741 or RFC 4742 are silent about the question whether NETCONF messages must be valid XML or just well-formed. If XML declarations are required, what is the error code to return? /js PS The last question touches a general issue; the RFC does not provide much detail which error codes apply where and so implementations seem to return pretty different results when you feed them with carefully crafted input. There are several other places where RFC 4741 is inconsistent; shall we start an effort to work on a -bis version so that we can fix the specs as we test implementations? -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 07:27:36 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FC93A6C59; Tue, 6 May 2008 07:27:36 -0700 (PDT) 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 1D6533A688E for ; Tue, 6 May 2008 07:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.577 X-Spam-Level: X-Spam-Status: No, score=-5.577 tagged_above=-999 required=5 tests=[AWL=1.022, 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 I4GVX+vUBMkz for ; Tue, 6 May 2008 07:27:32 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D33093A6BD7 for ; Tue, 6 May 2008 07:26:14 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m46EQ7027928; Tue, 6 May 2008 14:26:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 10:25:56 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41469B251@zcarhxm2.corp.nortel.com> In-Reply-To: <20080506084830.GE29870@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] xml declaration required or optional Thread-Index: AcivVf8kChT53vL4QG2G+Dj0uMchlQALqUGQ References: <20080506084830.GE29870@elstar.local> From: "Sharon Chisholm" To: , Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi It's not a bad idea. Another ambiguity seems to be whether the reply to and contains the element or not. We are also suppose to be doing -bis to the transport mappings to add text around although if we touch it we might want to see if we need to make the text more general if we think we might ever add something else that doesn't use the layer. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, May 06, 2008 4:48 AM To: netconf@ietf.org Subject: [Netconf] xml declaration required or optional Hi, are XML declarations required for NETCONF messages or optional? I could not find an answer in the RFCs and it seems that some implementations require XML declarations in NETCONF messages while others don't. XML 1.0 seems to require XML declarations for valid XML documents but then RFC 4741 or RFC 4742 are silent about the question whether NETCONF messages must be valid XML or just well-formed. If XML declarations are required, what is the error code to return? /js PS The last question touches a general issue; the RFC does not provide much detail which error codes apply where and so implementations seem to return pretty different results when you feed them with carefully crafted input. There are several other places where RFC 4741 is inconsistent; shall we start an effort to work on a -bis version so that we can fix the specs as we test implementations? -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 07:48:19 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C43C3A704A; Tue, 6 May 2008 07:48:19 -0700 (PDT) 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 5A9D23A704D for ; Tue, 6 May 2008 07:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=0.465, 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 RueKjqR6hiCR for ; Tue, 6 May 2008 07:48:13 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 0CACC3A7059 for ; Tue, 6 May 2008 07:46:36 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 3A4BF1B80D5; Tue, 6 May 2008 16:46:33 +0200 (CEST) Date: Tue, 06 May 2008 16:46:45 +0200 (CEST) Message-Id: <20080506.164645.97463010.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41469B251@zcarhxm2.corp.nortel.com> References: <20080506084830.GE29870@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B41469B251@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Sharon Chisholm" wrote: > Hi > > It's not a bad idea. Another ambiguity seems to be whether the reply to > and contains the element or not. Do you mean for the case where no data is returned, e.g. if a filter is used which selects nothing? For the case where data _is_ returned I think the text + XSD is clear. I think we should use the ticket tracker (http://www3.tools.ietf.org/wg/netconf/trac/) for these issues. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 07:48:19 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C43C3A704A; Tue, 6 May 2008 07:48:19 -0700 (PDT) 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 5A9D23A704D for ; Tue, 6 May 2008 07:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=0.465, 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 RueKjqR6hiCR for ; Tue, 6 May 2008 07:48:13 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 0CACC3A7059 for ; Tue, 6 May 2008 07:46:36 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 3A4BF1B80D5; Tue, 6 May 2008 16:46:33 +0200 (CEST) Date: Tue, 06 May 2008 16:46:45 +0200 (CEST) Message-Id: <20080506.164645.97463010.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41469B251@zcarhxm2.corp.nortel.com> References: <20080506084830.GE29870@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B41469B251@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.1.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Sharon Chisholm" wrote: > Hi > > It's not a bad idea. Another ambiguity seems to be whether the reply to > and contains the element or not. Do you mean for the case where no data is returned, e.g. if a filter is used which selects nothing? For the case where data _is_ returned I think the text + XSD is clear. I think we should use the ticket tracker (http://www3.tools.ietf.org/wg/netconf/trac/) for these issues. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 07:50:54 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800903A7005; Tue, 6 May 2008 07:50:54 -0700 (PDT) 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 617CF3A7031 for ; Tue, 6 May 2008 07:50:53 -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 9B7LpUzinLBK for ; Tue, 6 May 2008 07:50:46 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C84833A7005 for ; Tue, 6 May 2008 07:50:46 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1202220686 for ; Tue, 6 May 2008 16:50:44 +0200 (CEST) X-AuditID: c1b4fb3c-b009fbb00000193b-f0-48207044e165 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 03F54205ED for ; Tue, 6 May 2008 16:50:44 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 16:50:43 +0200 Received: from [147.214.238.36] ([147.214.238.36]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 16:50:43 +0200 Message-ID: <48206F8F.2060901@ericsson.com> Date: Tue, 06 May 2008 16:47:43 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ietf.org References: <20080506084830.GE29870@elstar.local> In-Reply-To: <20080506084830.GE29870@elstar.local> X-OriginalArrivalTime: 06 May 2008 14:50:43.0749 (UTC) FILETIME=[8F782D50:01C8AF88] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, I would like a bis. Would a bis only cover corrections or can it include new stuff like: - with-defaults - test-only option for edit-config Balazs Juergen Schoenwaelder wrote: > Hi, > > are XML declarations required for NETCONF messages or optional? I > could not find an answer in the RFCs and it seems that some > implementations require XML declarations in NETCONF messages while > others don't. > > XML 1.0 seems to require XML declarations for valid XML documents > but then RFC 4741 or RFC 4742 are silent about the question whether > NETCONF messages must be valid XML or just well-formed. > > If XML declarations are required, what is the error code to return? > > /js > > PS The last question touches a general issue; the RFC does not provide > much detail which error codes apply where and so implementations > seem to return pretty different results when you feed them with > carefully crafted input. There are several other places where RFC > 4741 is inconsistent; shall we start an effort to work on a -bis > version so that we can fix the specs as we test implementations? > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 07:50:54 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800903A7005; Tue, 6 May 2008 07:50:54 -0700 (PDT) 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 617CF3A7031 for ; Tue, 6 May 2008 07:50:53 -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 9B7LpUzinLBK for ; Tue, 6 May 2008 07:50:46 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C84833A7005 for ; Tue, 6 May 2008 07:50:46 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1202220686 for ; Tue, 6 May 2008 16:50:44 +0200 (CEST) X-AuditID: c1b4fb3c-b009fbb00000193b-f0-48207044e165 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 03F54205ED for ; Tue, 6 May 2008 16:50:44 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 16:50:43 +0200 Received: from [147.214.238.36] ([147.214.238.36]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 16:50:43 +0200 Message-ID: <48206F8F.2060901@ericsson.com> Date: Tue, 06 May 2008 16:47:43 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: netconf@ietf.org References: <20080506084830.GE29870@elstar.local> In-Reply-To: <20080506084830.GE29870@elstar.local> X-OriginalArrivalTime: 06 May 2008 14:50:43.0749 (UTC) FILETIME=[8F782D50:01C8AF88] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, I would like a bis. Would a bis only cover corrections or can it include new stuff like: - with-defaults - test-only option for edit-config Balazs Juergen Schoenwaelder wrote: > Hi, > > are XML declarations required for NETCONF messages or optional? I > could not find an answer in the RFCs and it seems that some > implementations require XML declarations in NETCONF messages while > others don't. > > XML 1.0 seems to require XML declarations for valid XML documents > but then RFC 4741 or RFC 4742 are silent about the question whether > NETCONF messages must be valid XML or just well-formed. > > If XML declarations are required, what is the error code to return? > > /js > > PS The last question touches a general issue; the RFC does not provide > much detail which error codes apply where and so implementations > seem to return pretty different results when you feed them with > carefully crafted input. There are several other places where RFC > 4741 is inconsistent; shall we start an effort to work on a -bis > version so that we can fix the specs as we test implementations? > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 07:55:53 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0363A7005; Tue, 6 May 2008 07:55:53 -0700 (PDT) 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 9448A3A7005 for ; Tue, 6 May 2008 07:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.918 X-Spam-Level: X-Spam-Status: No, score=-5.918 tagged_above=-999 required=5 tests=[AWL=0.682, 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 tc1iXjJVNybc for ; Tue, 6 May 2008 07:55:50 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 96A4B3A69D8 for ; Tue, 6 May 2008 07:55:50 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m46EtiH14433; Tue, 6 May 2008 14:55:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 10:55:14 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> In-Reply-To: <20080506.164645.97463010.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] xml declaration required or optional Thread-Index: Acivh/41+bgyE08FT3qI4K23Y6qNoQAACSWw References: <20080506084830.GE29870@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B41469B251@zcarhxm2.corp.nortel.com> <20080506.164645.97463010.mbj@tail-f.com> From: "Sharon Chisholm" To: "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Section 4.4 says: The element is sent in messages if no errors or warnings occurred during the processing of an request. This has caused some confusion. Sharon -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Tuesday, May 06, 2008 10:47 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: j.schoenwaelder@jacobs-university.de; netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional "Sharon Chisholm" wrote: > Hi > > It's not a bad idea. Another ambiguity seems to be whether the reply > to and contains the element or not. Do you mean for the case where no data is returned, e.g. if a filter is used which selects nothing? For the case where data _is_ returned I think the text + XSD is clear. I think we should use the ticket tracker (http://www3.tools.ietf.org/wg/netconf/trac/) for these issues. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 07:55:53 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0363A7005; Tue, 6 May 2008 07:55:53 -0700 (PDT) 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 9448A3A7005 for ; Tue, 6 May 2008 07:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.918 X-Spam-Level: X-Spam-Status: No, score=-5.918 tagged_above=-999 required=5 tests=[AWL=0.682, 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 tc1iXjJVNybc for ; Tue, 6 May 2008 07:55:50 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 96A4B3A69D8 for ; Tue, 6 May 2008 07:55:50 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m46EtiH14433; Tue, 6 May 2008 14:55:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 10:55:14 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> In-Reply-To: <20080506.164645.97463010.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] xml declaration required or optional Thread-Index: Acivh/41+bgyE08FT3qI4K23Y6qNoQAACSWw References: <20080506084830.GE29870@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B41469B251@zcarhxm2.corp.nortel.com> <20080506.164645.97463010.mbj@tail-f.com> From: "Sharon Chisholm" To: "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Section 4.4 says: The element is sent in messages if no errors or warnings occurred during the processing of an request. This has caused some confusion. Sharon -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Tuesday, May 06, 2008 10:47 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: j.schoenwaelder@jacobs-university.de; netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional "Sharon Chisholm" wrote: > Hi > > It's not a bad idea. Another ambiguity seems to be whether the reply > to and contains the element or not. Do you mean for the case where no data is returned, e.g. if a filter is used which selects nothing? For the case where data _is_ returned I think the text + XSD is clear. I think we should use the ticket tracker (http://www3.tools.ietf.org/wg/netconf/trac/) for these issues. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 08:27:23 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF443A68DA; Tue, 6 May 2008 08:27:23 -0700 (PDT) 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 CD3A83A6954 for ; Tue, 6 May 2008 08:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 fuXJDHEaffXF for ; Tue, 6 May 2008 08:27:18 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id 582403A6897 for ; Tue, 6 May 2008 08:27:16 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob59.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 08:23:34 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 08:18:25 -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 m46FIOx52418; Tue, 6 May 2008 08:18:24 -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 m46FGeVB049807; Tue, 6 May 2008 15:16:40 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061516.m46FGeVB049807@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> Date: Tue, 06 May 2008 11:16:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 15:18:25.0050 (UTC) FILETIME=[6DAE97A0:01C8AF8C] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Sharon Chisholm" writes: >The element is sent in messages if no errors or > warnings occurred during the processing of an request. >This has caused some confusion. Well, that's completely clear, but not what we implemented in JUNOS. I'm happy to fix our implementation though. Being able to do simple tests like: if ($results/ok) { ... } is a win. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 08:27:23 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF443A68DA; Tue, 6 May 2008 08:27:23 -0700 (PDT) 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 CD3A83A6954 for ; Tue, 6 May 2008 08:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 fuXJDHEaffXF for ; Tue, 6 May 2008 08:27:18 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id 582403A6897 for ; Tue, 6 May 2008 08:27:16 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob59.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 08:23:34 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 08:18:25 -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 m46FIOx52418; Tue, 6 May 2008 08:18:24 -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 m46FGeVB049807; Tue, 6 May 2008 15:16:40 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061516.m46FGeVB049807@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> Date: Tue, 06 May 2008 11:16:40 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 15:18:25.0050 (UTC) FILETIME=[6DAE97A0:01C8AF8C] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Sharon Chisholm" writes: >The element is sent in messages if no errors or > warnings occurred during the processing of an request. >This has caused some confusion. Well, that's completely clear, but not what we implemented in JUNOS. I'm happy to fix our implementation though. Being able to do simple tests like: if ($results/ok) { ... } is a win. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 08:34:45 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30E13A6B8F; Tue, 6 May 2008 08:34:45 -0700 (PDT) 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 962BC3A6830 for ; Tue, 6 May 2008 08:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.228, 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 NnjwtrGJvLlH for ; Tue, 6 May 2008 08:34:43 -0700 (PDT) Received: from chip3og58.obsmtp.com (chip3og58.obsmtp.com [64.18.14.181]) by core3.amsl.com (Postfix) with ESMTP id 3DB5E3A6C59 for ; Tue, 6 May 2008 08:34:36 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob58.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 08:34:32 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 08:34:28 -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 m46FYSx59320; Tue, 6 May 2008 08:34:28 -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 m46FWh8I049905; Tue, 6 May 2008 15:32:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061532.m46FWh8I049905@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080506084830.GE29870@elstar.local> Date: Tue, 06 May 2008 11:32:43 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 15:34:28.0610 (UTC) FILETIME=[AC022E20:01C8AF8E] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder writes: >If XML declarations are required, what is the error code to return? XMLDecls are always optional, per REC-xml: [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? So it definitely shouldn't be an error if they are missing. We talked early on about avoiding the entire prolog, during the XMLCONF design team's effort: 7.1 Canonical XML XMLCONF's use of XML follows the rules specified by Canonical XML (RFC 3076 [6]). These rules were meant to make XML appear in a consistent form, suitable for string comparison. Many of XML's more marginal constructs are excluded, allowing simple parsers to avoid implementation issues for rarely-used features. ... RFC 3076 summarizes the changes required by Canonical XML as follows: ... * The XML declaration and document type declaration (DTD) are removed But this didn't make it into the final rfc; IIRC we were concerned about defining our own XML variant. In the end we just dropped the DTD. I'd be happy to return to Canonical XML, but I don't see that as likely. Lacking specific words in rfc4741, the xml declaration should be optional on both sides. We should add some words saying that it MUST NOT change over the lifetime of NETCONF session, since popping from version="1.0" to version="2.0" isn't fun for anyone. Thanks, Phil P.S.: I did find this ancient text in the prot-00 draft: 2.4 Channels NETCONF requires two distinct communication channels and an optional third channel. One channel, called the "management channel", carries information for managing the NETCONF session. A second channel, called the "operation channel", carries a series of RPCs that constitute the real content of the NETCONF session. A third optional channel, called the "notification channel", carries asynchronous notifications. This channel is established only if both parties request it during the initial capabilities exchange. (See Section 6 for more information.) _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 08:34:45 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30E13A6B8F; Tue, 6 May 2008 08:34:45 -0700 (PDT) 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 962BC3A6830 for ; Tue, 6 May 2008 08:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.228, 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 NnjwtrGJvLlH for ; Tue, 6 May 2008 08:34:43 -0700 (PDT) Received: from chip3og58.obsmtp.com (chip3og58.obsmtp.com [64.18.14.181]) by core3.amsl.com (Postfix) with ESMTP id 3DB5E3A6C59 for ; Tue, 6 May 2008 08:34:36 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob58.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 08:34:32 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 08:34:28 -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 m46FYSx59320; Tue, 6 May 2008 08:34:28 -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 m46FWh8I049905; Tue, 6 May 2008 15:32:44 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061532.m46FWh8I049905@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080506084830.GE29870@elstar.local> Date: Tue, 06 May 2008 11:32:43 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 15:34:28.0610 (UTC) FILETIME=[AC022E20:01C8AF8E] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder writes: >If XML declarations are required, what is the error code to return? XMLDecls are always optional, per REC-xml: [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? So it definitely shouldn't be an error if they are missing. We talked early on about avoiding the entire prolog, during the XMLCONF design team's effort: 7.1 Canonical XML XMLCONF's use of XML follows the rules specified by Canonical XML (RFC 3076 [6]). These rules were meant to make XML appear in a consistent form, suitable for string comparison. Many of XML's more marginal constructs are excluded, allowing simple parsers to avoid implementation issues for rarely-used features. ... RFC 3076 summarizes the changes required by Canonical XML as follows: ... * The XML declaration and document type declaration (DTD) are removed But this didn't make it into the final rfc; IIRC we were concerned about defining our own XML variant. In the end we just dropped the DTD. I'd be happy to return to Canonical XML, but I don't see that as likely. Lacking specific words in rfc4741, the xml declaration should be optional on both sides. We should add some words saying that it MUST NOT change over the lifetime of NETCONF session, since popping from version="1.0" to version="2.0" isn't fun for anyone. Thanks, Phil P.S.: I did find this ancient text in the prot-00 draft: 2.4 Channels NETCONF requires two distinct communication channels and an optional third channel. One channel, called the "management channel", carries information for managing the NETCONF session. A second channel, called the "operation channel", carries a series of RPCs that constitute the real content of the NETCONF session. A third optional channel, called the "notification channel", carries asynchronous notifications. This channel is established only if both parties request it during the initial capabilities exchange. (See Section 6 for more information.) _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 09:05:21 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337CB28C3F6; Tue, 6 May 2008 09:05:21 -0700 (PDT) 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 8A01128C412 for ; Tue, 6 May 2008 09:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=0.511, 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 Cqw--Pf2aOps for ; Tue, 6 May 2008 09:04:50 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 86B5728C429 for ; Tue, 6 May 2008 09:03:48 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m46G3hY21114; Tue, 6 May 2008 16:03:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 12:03:33 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41469B557@zcarhxm2.corp.nortel.com> In-Reply-To: <200805061516.m46FGeVB049807@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] xml declaration required or optional Thread-Index: AcivjcbkfzzJe/TgQAmOpG7wnQPNtQABHIWQ References: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> <200805061516.m46FGeVB049807@idle.juniper.net> From: "Sharon Chisholm" To: "Phil Shafer" Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Except that it is contradicted in other parts of the document, like the XSD and the examples. What people do seems to depend on which parts of the document they pay the most attention to. I sort of like the easier test too. We just need to be clear which is intended and ensure that all the text is consistent. Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Tuesday, May 06, 2008 11:17 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: Martin Bjorklund; netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional "Sharon Chisholm" writes: >The element is sent in messages if no errors or > warnings occurred during the processing of an request. >This has caused some confusion. Well, that's completely clear, but not what we implemented in JUNOS. I'm happy to fix our implementation though. Being able to do simple tests like: if ($results/ok) { ... } is a win. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 09:05:21 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337CB28C3F6; Tue, 6 May 2008 09:05:21 -0700 (PDT) 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 8A01128C412 for ; Tue, 6 May 2008 09:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=0.511, 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 Cqw--Pf2aOps for ; Tue, 6 May 2008 09:04:50 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 86B5728C429 for ; Tue, 6 May 2008 09:03:48 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m46G3hY21114; Tue, 6 May 2008 16:03:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 12:03:33 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41469B557@zcarhxm2.corp.nortel.com> In-Reply-To: <200805061516.m46FGeVB049807@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] xml declaration required or optional Thread-Index: AcivjcbkfzzJe/TgQAmOpG7wnQPNtQABHIWQ References: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> <200805061516.m46FGeVB049807@idle.juniper.net> From: "Sharon Chisholm" To: "Phil Shafer" Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Except that it is contradicted in other parts of the document, like the XSD and the examples. What people do seems to depend on which parts of the document they pay the most attention to. I sort of like the easier test too. We just need to be clear which is intended and ensure that all the text is consistent. Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Tuesday, May 06, 2008 11:17 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: Martin Bjorklund; netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional "Sharon Chisholm" writes: >The element is sent in messages if no errors or > warnings occurred during the processing of an request. >This has caused some confusion. Well, that's completely clear, but not what we implemented in JUNOS. I'm happy to fix our implementation though. Being able to do simple tests like: if ($results/ok) { ... } is a win. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 09:18:16 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69533A69AF; Tue, 6 May 2008 09:18:16 -0700 (PDT) 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 ADFB43A6A28 for ; Tue, 6 May 2008 09:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.300, 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 MGT8Yu3xTDPb for ; Tue, 6 May 2008 09:18:15 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 8A9143A69AF for ; Tue, 6 May 2008 09:18:14 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 5F3D21B80D3; Tue, 6 May 2008 18:18:12 +0200 (CEST) Date: Tue, 06 May 2008 18:18:01 +0200 (CEST) Message-Id: <20080506.181801.149900165.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200805061516.m46FGeVB049807@idle.juniper.net> References: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> <200805061516.m46FGeVB049807@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > "Sharon Chisholm" writes: > >The element is sent in messages if no errors or > > warnings occurred during the processing of an request. > >This has caused some confusion. > > Well, that's completely clear, but not what we implemented in > JUNOS. I'm happy to fix our implementation though. Being able > to do simple tests like: > > if ($results/ok) { ... } > > is a win. I probably don't understand what you mean. In a reply to , you'll get: What changes are you suggesting? or or what? /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 09:18:16 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69533A69AF; Tue, 6 May 2008 09:18:16 -0700 (PDT) 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 ADFB43A6A28 for ; Tue, 6 May 2008 09:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.300, 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 MGT8Yu3xTDPb for ; Tue, 6 May 2008 09:18:15 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 8A9143A69AF for ; Tue, 6 May 2008 09:18:14 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 5F3D21B80D3; Tue, 6 May 2008 18:18:12 +0200 (CEST) Date: Tue, 06 May 2008 18:18:01 +0200 (CEST) Message-Id: <20080506.181801.149900165.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200805061516.m46FGeVB049807@idle.juniper.net> References: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> <200805061516.m46FGeVB049807@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > "Sharon Chisholm" writes: > >The element is sent in messages if no errors or > > warnings occurred during the processing of an request. > >This has caused some confusion. > > Well, that's completely clear, but not what we implemented in > JUNOS. I'm happy to fix our implementation though. Being able > to do simple tests like: > > if ($results/ok) { ... } > > is a win. I probably don't understand what you mean. In a reply to , you'll get: What changes are you suggesting? or or what? /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 09:20:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78713A6A40; Tue, 6 May 2008 09:20:39 -0700 (PDT) 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 324153A69D8 for ; Tue, 6 May 2008 09:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=0.117, 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 Cjf0RevQ9yhn for ; Tue, 6 May 2008 09:20:34 -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 4625E3A6A28 for ; Tue, 6 May 2008 09:20:34 -0700 (PDT) Received: (qmail 43657 invoked from network); 6 May 2008 16:20:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 6 May 2008 16:20:30 -0000 X-YMail-OSG: fdduNdYVM1n2lC5z5W0ybxQbz0.EsDOVk6JQPHSxLQm6uAobD6zG2EsEFnJ5ySf8eowhKIg1F4aA939NXBgPAeg1KWGWoyfNzHQRun1OaBTRNSo._6rmzpQhWFD5mZtS_E4jKKKYPZtHrCbyph5DPFFV X-Yahoo-Newman-Property: ymail-3 Message-ID: <48208513.5000408@andybierman.com> Date: Tue, 06 May 2008 09:19:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> <200805061516.m46FGeVB049807@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B41469B557@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41469B557@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > Except that it is contradicted in other parts of the document, like the > XSD and the examples. What people do seems to depend on which parts of > the document they pay the most attention to. I sort of like the easier > test too. We just need to be clear which is intended and ensure that all > the text is consistent. > The XSD reflects the intent of the WG, when RFC 4741 was developed. RPC methods that returned data used the node in the . Instead of sending an empty upon success (for RPC methods that do not return any data), it was thought that an explicit would be better. IMO, section 4.4 is incomplete. It should say that that only applies if no element is sent (and the other conditions are met). All the examples, and the normative XSD say otherwise. > Sharon Andy > > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Tuesday, May 06, 2008 11:17 AM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: Martin Bjorklund; netconf@ietf.org > Subject: Re: [Netconf] xml declaration required or optional > > "Sharon Chisholm" writes: >> The element is sent in messages if no errors or >> warnings occurred during the processing of an request. >> This has caused some confusion. > > Well, that's completely clear, but not what we implemented in JUNOS. > I'm happy to fix our implementation though. Being able to do simple > tests like: > > if ($results/ok) { ... } > > is a win. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 09:20:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78713A6A40; Tue, 6 May 2008 09:20:39 -0700 (PDT) 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 324153A69D8 for ; Tue, 6 May 2008 09:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.839 X-Spam-Level: X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[AWL=0.117, 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 Cjf0RevQ9yhn for ; Tue, 6 May 2008 09:20:34 -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 4625E3A6A28 for ; Tue, 6 May 2008 09:20:34 -0700 (PDT) Received: (qmail 43657 invoked from network); 6 May 2008 16:20:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 6 May 2008 16:20:30 -0000 X-YMail-OSG: fdduNdYVM1n2lC5z5W0ybxQbz0.EsDOVk6JQPHSxLQm6uAobD6zG2EsEFnJ5ySf8eowhKIg1F4aA939NXBgPAeg1KWGWoyfNzHQRun1OaBTRNSo._6rmzpQhWFD5mZtS_E4jKKKYPZtHrCbyph5DPFFV X-Yahoo-Newman-Property: ymail-3 Message-ID: <48208513.5000408@andybierman.com> Date: Tue, 06 May 2008 09:19:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> <200805061516.m46FGeVB049807@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B41469B557@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41469B557@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > Except that it is contradicted in other parts of the document, like the > XSD and the examples. What people do seems to depend on which parts of > the document they pay the most attention to. I sort of like the easier > test too. We just need to be clear which is intended and ensure that all > the text is consistent. > The XSD reflects the intent of the WG, when RFC 4741 was developed. RPC methods that returned data used the node in the . Instead of sending an empty upon success (for RPC methods that do not return any data), it was thought that an explicit would be better. IMO, section 4.4 is incomplete. It should say that that only applies if no element is sent (and the other conditions are met). All the examples, and the normative XSD say otherwise. > Sharon Andy > > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Tuesday, May 06, 2008 11:17 AM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: Martin Bjorklund; netconf@ietf.org > Subject: Re: [Netconf] xml declaration required or optional > > "Sharon Chisholm" writes: >> The element is sent in messages if no errors or >> warnings occurred during the processing of an request. >> This has caused some confusion. > > Well, that's completely clear, but not what we implemented in JUNOS. > I'm happy to fix our implementation though. Being able to do simple > tests like: > > if ($results/ok) { ... } > > is a win. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 09:36:36 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4149328C1B6; Tue, 6 May 2008 09:36:36 -0700 (PDT) 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 363773A6A28 for ; Tue, 6 May 2008 09:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 KBJNudDi7mZR for ; Tue, 6 May 2008 09:36:33 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id C4E1B3A6B60 for ; Tue, 6 May 2008 09:36:31 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob59.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 09:33:29 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 09:33:53 -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 m46GXrx81326; Tue, 6 May 2008 09:33:53 -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 m46GW8uC050508; Tue, 6 May 2008 16:32:08 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061632.m46GW8uC050508@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080506.181801.149900165.mbj@tail-f.com> Date: Tue, 06 May 2008 12:32:08 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 16:33:53.0838 (UTC) FILETIME=[F90CCCE0:01C8AF96] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund writes: > > > > > > This one. If the RPC completes and the server hasn't emitted any errors or warnings, it emits and element. This allows, say, a config archiver to know if there were any errors reading the config from flash without having to traverse the entire hierarchy looking for elements. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 09:36:36 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4149328C1B6; Tue, 6 May 2008 09:36:36 -0700 (PDT) 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 363773A6A28 for ; Tue, 6 May 2008 09:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 KBJNudDi7mZR for ; Tue, 6 May 2008 09:36:33 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id C4E1B3A6B60 for ; Tue, 6 May 2008 09:36:31 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob59.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 09:33:29 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 09:33:53 -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 m46GXrx81326; Tue, 6 May 2008 09:33:53 -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 m46GW8uC050508; Tue, 6 May 2008 16:32:08 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061632.m46GW8uC050508@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080506.181801.149900165.mbj@tail-f.com> Date: Tue, 06 May 2008 12:32:08 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 16:33:53.0838 (UTC) FILETIME=[F90CCCE0:01C8AF96] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund writes: > > > > > > This one. If the RPC completes and the server hasn't emitted any errors or warnings, it emits and element. This allows, say, a config archiver to know if there were any errors reading the config from flash without having to traverse the entire hierarchy looking for elements. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 09:37:48 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C174F28C22D; Tue, 6 May 2008 09:37:48 -0700 (PDT) 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 BC87F28C298 for ; Tue, 6 May 2008 09:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 bfRLSPnnahju for ; Tue, 6 May 2008 09:37:46 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id 562453A6A28 for ; Tue, 6 May 2008 09:37:43 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob59.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 09:37:40 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 09:37: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 m46GbFx82257; Tue, 6 May 2008 09:37: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 m46GZVcB050562; Tue, 6 May 2008 16:35:31 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061635.m46GZVcB050562@idle.juniper.net> To: Andy Bierman In-reply-to: <48208513.5000408@andybierman.com> Date: Tue, 06 May 2008 12:35:30 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 16:37:15.0980 (UTC) FILETIME=[718938C0:01C8AF97] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >The XSD reflects the intent of the WG, when RFC 4741 was developed. ROFL!! No one read the XSD. This has become obvious. After seven years, very few WGers read the final draft. We'd read it so many times, we just sang the chorus and mumble the verses. I've been shocked several times at the words in the text, let alone the XSD. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 09:37:48 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C174F28C22D; Tue, 6 May 2008 09:37:48 -0700 (PDT) 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 BC87F28C298 for ; Tue, 6 May 2008 09:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 bfRLSPnnahju for ; Tue, 6 May 2008 09:37:46 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id 562453A6A28 for ; Tue, 6 May 2008 09:37:43 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob59.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 09:37:40 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 09:37: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 m46GbFx82257; Tue, 6 May 2008 09:37: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 m46GZVcB050562; Tue, 6 May 2008 16:35:31 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061635.m46GZVcB050562@idle.juniper.net> To: Andy Bierman In-reply-to: <48208513.5000408@andybierman.com> Date: Tue, 06 May 2008 12:35:30 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 16:37:15.0980 (UTC) FILETIME=[718938C0:01C8AF97] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >The XSD reflects the intent of the WG, when RFC 4741 was developed. ROFL!! No one read the XSD. This has become obvious. After seven years, very few WGers read the final draft. We'd read it so many times, we just sang the chorus and mumble the verses. I've been shocked several times at the words in the text, let alone the XSD. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 10:07:31 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01BE428C2B2; Tue, 6 May 2008 10:07:31 -0700 (PDT) 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 A504128C21B for ; Tue, 6 May 2008 10:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 2gp8m8pjEZWe for ; Tue, 6 May 2008 10:07:22 -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 E238E28C454 for ; Tue, 6 May 2008 10:06:23 -0700 (PDT) Received: (qmail 72521 invoked from network); 6 May 2008 17:06:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 6 May 2008 17:06:20 -0000 X-YMail-OSG: ha.tg_sVM1nMLgykyTMT0WH6oAi9kTDqY5LasDB0FDcJvs8KXn4cILS9vaTuh7IUEvyXZIAyU8Pa7s_.wSjEt2vYAWSoq02ijUwr9mvi4FPSaD2kb4CvPRkgeblc0KertQw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48208FCB.5000409@andybierman.com> Date: Tue, 06 May 2008 10:05:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805061635.m46GZVcB050562@idle.juniper.net> In-Reply-To: <200805061635.m46GZVcB050562@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> The XSD reflects the intent of the WG, when RFC 4741 was developed. > > ROFL!! No one read the XSD. This has become obvious. After seven > years, very few WGers read the final draft. We'd read it so many > times, we just sang the chorus and mumble the verses. I've been > shocked several times at the words in the text, let alone the XSD. > Nobody reads the YANG ABNF either. Proves nothing. What about the RFC 4741 examples? Are you saying nobody understood the examples either, and most of them are wrong? > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 10:07:31 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01BE428C2B2; Tue, 6 May 2008 10:07:31 -0700 (PDT) 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 A504128C21B for ; Tue, 6 May 2008 10:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 2gp8m8pjEZWe for ; Tue, 6 May 2008 10:07:22 -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 E238E28C454 for ; Tue, 6 May 2008 10:06:23 -0700 (PDT) Received: (qmail 72521 invoked from network); 6 May 2008 17:06:22 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 6 May 2008 17:06:20 -0000 X-YMail-OSG: ha.tg_sVM1nMLgykyTMT0WH6oAi9kTDqY5LasDB0FDcJvs8KXn4cILS9vaTuh7IUEvyXZIAyU8Pa7s_.wSjEt2vYAWSoq02ijUwr9mvi4FPSaD2kb4CvPRkgeblc0KertQw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48208FCB.5000409@andybierman.com> Date: Tue, 06 May 2008 10:05:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805061635.m46GZVcB050562@idle.juniper.net> In-Reply-To: <200805061635.m46GZVcB050562@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> The XSD reflects the intent of the WG, when RFC 4741 was developed. > > ROFL!! No one read the XSD. This has become obvious. After seven > years, very few WGers read the final draft. We'd read it so many > times, we just sang the chorus and mumble the verses. I've been > shocked several times at the words in the text, let alone the XSD. > Nobody reads the YANG ABNF either. Proves nothing. What about the RFC 4741 examples? Are you saying nobody understood the examples either, and most of them are wrong? > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 11:01:19 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9619C3A6B89; Tue, 6 May 2008 11:01:19 -0700 (PDT) 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 7060B3A6B8C for ; Tue, 6 May 2008 11:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.122, 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 gmItTZX+8b02 for ; Tue, 6 May 2008 11:01: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 2CF503A6B89 for ; Tue, 6 May 2008 11:01:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D372C0017; Tue, 6 May 2008 20:01:23 +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 370BUejjANg0; Tue, 6 May 2008 20:01:04 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FC12C000C; Tue, 6 May 2008 20:01:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AF08C572D80; Tue, 6 May 2008 20:01:03 +0200 (CEST) Date: Tue, 6 May 2008 20:01:03 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080506180103.GD1654@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf@ietf.org References: <20080506084830.GE29870@elstar.local> <48206F8F.2060901@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48206F8F.2060901@ericsson.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, May 06, 2008 at 04:47:43PM +0200, Balazs Lengyel wrote: > I would like a bis. > > Would a bis only cover corrections or can it include new stuff like: > - with-defaults > - test-only option for edit-config I think at this point, what we really need is an update which just does corrections. There many things that are simply inconsistent in RFC 4741; some are relatively clear and easy to fix. For others, it is not clear what the intent really was. /js PS: I am talking about the text and the examples, not the XSD which I tend to ignore. I would love the text and the examples to say everything that needs to be said. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________From netconf-bounces@ietf.org Tue May 6 11:01:19 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9619C3A6B89; Tue, 6 May 2008 11:01:19 -0700 (PDT) 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 7060B3A6B8C for ; Tue, 6 May 2008 11:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.122, 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 gmItTZX+8b02 for ; Tue, 6 May 2008 11:01: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 2CF503A6B89 for ; Tue, 6 May 2008 11:01:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D372C0017; Tue, 6 May 2008 20:01:23 +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 370BUejjANg0; Tue, 6 May 2008 20:01:04 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FC12C000C; Tue, 6 May 2008 20:01:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AF08C572D80; Tue, 6 May 2008 20:01:03 +0200 (CEST) Date: Tue, 6 May 2008 20:01:03 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20080506180103.GD1654@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf@ietf.org References: <20080506084830.GE29870@elstar.local> <48206F8F.2060901@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48206F8F.2060901@ericsson.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, May 06, 2008 at 04:47:43PM +0200, Balazs Lengyel wrote: > I would like a bis. > > Would a bis only cover corrections or can it include new stuff like: > - with-defaults > - test-only option for edit-config I think at this point, what we really need is an update which just does corrections. There many things that are simply inconsistent in RFC 4741; some are relatively clear and easy to fix. For others, it is not clear what the intent really was. /js PS: I am talking about the text and the examples, not the XSD which I tend to ignore. I would love the text and the examples to say everything that needs to be said. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ______ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 11:05:02 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCDB28C455; Tue, 6 May 2008 11:05:01 -0700 (PDT) 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 8335A28C453 for ; Tue, 6 May 2008 11:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 8m+aWkKXu5ns for ; Tue, 6 May 2008 11:04:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7B1B828C451 for ; Tue, 6 May 2008 11:04:54 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BD52C0002; Tue, 6 May 2008 20:05:02 +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 BTCrDdllNuk0; Tue, 6 May 2008 20:04:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F298AC0017; Tue, 6 May 2008 20:04:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A25DE572DB7; Tue, 6 May 2008 20:04:40 +0200 (CEST) Date: Tue, 6 May 2008 20:04:40 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080506180440.GE1654@elstar.local> Mail-Followup-To: Phil Shafer , netconf@ietf.org References: <20080506084830.GE29870@elstar.local> <200805061532.m46FWh8I049905@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200805061532.m46FWh8I049905@idle.juniper.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, May 06, 2008 at 11:32:43AM -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >If XML declarations are required, what is the error code to return? > > XMLDecls are always optional, per REC-xml: > > [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? > > So it definitely shouldn't be an error if they are missing. But declarations are required for valid XML documents as far as I can tell... Anyway, I have no personal opinion in favour or against XML declarations; I just want to know what I have to send to NETCONF server. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 11:05:02 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FCDB28C455; Tue, 6 May 2008 11:05:01 -0700 (PDT) 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 8335A28C453 for ; Tue, 6 May 2008 11:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 8m+aWkKXu5ns for ; Tue, 6 May 2008 11:04:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7B1B828C451 for ; Tue, 6 May 2008 11:04:54 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BD52C0002; Tue, 6 May 2008 20:05:02 +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 BTCrDdllNuk0; Tue, 6 May 2008 20:04:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F298AC0017; Tue, 6 May 2008 20:04:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A25DE572DB7; Tue, 6 May 2008 20:04:40 +0200 (CEST) Date: Tue, 6 May 2008 20:04:40 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20080506180440.GE1654@elstar.local> Mail-Followup-To: Phil Shafer , netconf@ietf.org References: <20080506084830.GE29870@elstar.local> <200805061532.m46FWh8I049905@idle.juniper.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200805061532.m46FWh8I049905@idle.juniper.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, May 06, 2008 at 11:32:43AM -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >If XML declarations are required, what is the error code to return? > > XMLDecls are always optional, per REC-xml: > > [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? > > So it definitely shouldn't be an error if they are missing. But declarations are required for valid XML documents as far as I can tell... Anyway, I have no personal opinion in favour or against XML declarations; I just want to know what I have to send to NETCONF server. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 12:10:46 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6986C3A6FFD; Tue, 6 May 2008 12:10:31 -0700 (PDT) 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 AD00828C517 for ; Tue, 6 May 2008 12:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 c2j0rGZyJ1b3 for ; Tue, 6 May 2008 12:07:06 -0700 (PDT) Received: from chip3og53.obsmtp.com (chip3og53.obsmtp.com [64.18.14.171]) by core3.amsl.com (Postfix) with ESMTP id 1739C28C497 for ; Tue, 6 May 2008 12:03:55 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob53.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 12:03:31 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 11:57: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 m46Ivvx32762; Tue, 6 May 2008 11:57: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 m46IuD46051592; Tue, 6 May 2008 18:56:13 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061856.m46IuD46051592@idle.juniper.net> To: Andy Bierman In-reply-to: <48208FCB.5000409@andybierman.com> Date: Tue, 06 May 2008 14:56:12 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 18:57:58.0166 (UTC) FILETIME=[19789360:01C8AFAB] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >Are you saying nobody understood the examples either, >and most of them are wrong? I'm just saying that the document has some parts that show that we did a fairly poor job of polishing it. Claiming that the XSD is the will of the WG conflicts with saying that we need YANG because no one reads XSD. We used the "surprises" in the NETCONF XSD as an example that no one read it. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 12:10:47 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6986C3A6FFD; Tue, 6 May 2008 12:10:31 -0700 (PDT) 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 AD00828C517 for ; Tue, 6 May 2008 12:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 c2j0rGZyJ1b3 for ; Tue, 6 May 2008 12:07:06 -0700 (PDT) Received: from chip3og53.obsmtp.com (chip3og53.obsmtp.com [64.18.14.171]) by core3.amsl.com (Postfix) with ESMTP id 1739C28C497 for ; Tue, 6 May 2008 12:03:55 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob53.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 12:03:31 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 11:57: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 m46Ivvx32762; Tue, 6 May 2008 11:57: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 m46IuD46051592; Tue, 6 May 2008 18:56:13 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061856.m46IuD46051592@idle.juniper.net> To: Andy Bierman In-reply-to: <48208FCB.5000409@andybierman.com> Date: Tue, 06 May 2008 14:56:12 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 18:57:58.0166 (UTC) FILETIME=[19789360:01C8AFAB] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >Are you saying nobody understood the examples either, >and most of them are wrong? I'm just saying that the document has some parts that show that we did a fairly poor job of polishing it. Claiming that the XSD is the will of the WG conflicts with saying that we need YANG because no one reads XSD. We used the "surprises" in the NETCONF XSD as an example that no one read it. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 12:10:47 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9CA3A7033; Tue, 6 May 2008 12:10:41 -0700 (PDT) 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 CA4E428C510 for ; Tue, 6 May 2008 12:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 JsZIiL0AQu0N for ; Tue, 6 May 2008 12:07:06 -0700 (PDT) Received: from chip3og51.obsmtp.com (chip3og51.obsmtp.com [64.18.14.167]) by core3.amsl.com (Postfix) with ESMTP id 2909228C4DD for ; Tue, 6 May 2008 12:03:58 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob51.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 12:03:31 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 12:02:21 -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 m46J2Lx35203; Tue, 6 May 2008 12:02:21 -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 m46J0bkh051648; Tue, 6 May 2008 19:00:37 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061900.m46J0bkh051648@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080506180440.GE1654@elstar.local> Date: Tue, 06 May 2008 15:00:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 19:02:21.0845 (UTC) FILETIME=[B6A2CC50:01C8AFAB] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder writes: >> [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? >But declarations are required for valid XML documents as far as I can >tell... Anyway, I have no personal opinion in favour or against XML >declarations; I just want to know what I have to send to NETCONF >server. The "?" in production [22] means "zero or one times", so they are optional. For example, XHTML web pages normally start directly with the DTD: Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 12:10:47 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9CA3A7033; Tue, 6 May 2008 12:10:41 -0700 (PDT) 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 CA4E428C510 for ; Tue, 6 May 2008 12:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 JsZIiL0AQu0N for ; Tue, 6 May 2008 12:07:06 -0700 (PDT) Received: from chip3og51.obsmtp.com (chip3og51.obsmtp.com [64.18.14.167]) by core3.amsl.com (Postfix) with ESMTP id 2909228C4DD for ; Tue, 6 May 2008 12:03:58 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob51.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 12:03:31 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 12:02:21 -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 m46J2Lx35203; Tue, 6 May 2008 12:02:21 -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 m46J0bkh051648; Tue, 6 May 2008 19:00:37 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805061900.m46J0bkh051648@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080506180440.GE1654@elstar.local> Date: Tue, 06 May 2008 15:00:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 19:02:21.0845 (UTC) FILETIME=[B6A2CC50:01C8AFAB] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder writes: >> [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? >But declarations are required for valid XML documents as far as I can >tell... Anyway, I have no personal opinion in favour or against XML >declarations; I just want to know what I have to send to NETCONF >server. The "?" in production [22] means "zero or one times", so they are optional. For example, XHTML web pages normally start directly with the DTD: Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 12:10:47 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178DB28C511; Tue, 6 May 2008 12:10:45 -0700 (PDT) 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 76D2528C515 for ; Tue, 6 May 2008 12:08:29 -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 4OUZABqbLZ2W for ; Tue, 6 May 2008 12:07:11 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 298F33A6830 for ; Tue, 6 May 2008 12:04:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m46J43UM010199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 21:04:03 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m46J43Yc013456; Tue, 6 May 2008 21:04:03 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 21:04:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 21:04:02 +0200 Message-ID: In-Reply-To: <20080506180103.GD1654@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] xml declaration required or optional Thread-Index: AcivozdKTyc1lSTKSEayAGGCNUfGjwABqABw References: <20080506084830.GE29870@elstar.local><48206F8F.2060901@ericsson.com> <20080506180103.GD1654@elstar.local> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 06 May 2008 19:04:03.0196 (UTC) FILETIME=[F30BBBC0:01C8AFAB] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Juergen, All, a -bis document in general may have also extensions but you are right, corrections should be done first. There are some other 4741 issues in the issue tracker already. Which issues do you guys think should be covered in the -bis document? It would be helpful to have a discussion on the list of corrections and kind of agreement before we chat with Dan to enable the work on -bis. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Juergen > Schoenwaelder > Sent: Tuesday, May 06, 2008 8:01 PM > To: Balazs Lengyel > Cc: netconf@ietf.org > Subject: Re: [Netconf] xml declaration required or optional > > On Tue, May 06, 2008 at 04:47:43PM +0200, Balazs Lengyel wrote: > > > I would like a bis. > > > > Would a bis only cover corrections or can it include new stuff like: > > - with-defaults > > - test-only option for edit-config > > I think at this point, what we really need is an update which just > does corrections. There many things that are simply inconsistent in > RFC 4741; some are relatively clear and easy to fix. For others, it is > not clear what the intent really was. > > /js > > PS: I am talking about the text and the examples, not the XSD which I > tend to ignore. I would love the text and the examples to say > everything that needs to be said. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 12:10:47 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178DB28C511; Tue, 6 May 2008 12:10:45 -0700 (PDT) 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 76D2528C515 for ; Tue, 6 May 2008 12:08:29 -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 4OUZABqbLZ2W for ; Tue, 6 May 2008 12:07:11 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 298F33A6830 for ; Tue, 6 May 2008 12:04:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m46J43UM010199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 21:04:03 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m46J43Yc013456; Tue, 6 May 2008 21:04:03 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 21:04:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 21:04:02 +0200 Message-ID: In-Reply-To: <20080506180103.GD1654@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] xml declaration required or optional Thread-Index: AcivozdKTyc1lSTKSEayAGGCNUfGjwABqABw References: <20080506084830.GE29870@elstar.local><48206F8F.2060901@ericsson.com> <20080506180103.GD1654@elstar.local> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 06 May 2008 19:04:03.0196 (UTC) FILETIME=[F30BBBC0:01C8AFAB] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Juergen, All, a -bis document in general may have also extensions but you are right, corrections should be done first. There are some other 4741 issues in the issue tracker already. Which issues do you guys think should be covered in the -bis document? It would be helpful to have a discussion on the list of corrections and kind of agreement before we chat with Dan to enable the work on -bis. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Juergen > Schoenwaelder > Sent: Tuesday, May 06, 2008 8:01 PM > To: Balazs Lengyel > Cc: netconf@ietf.org > Subject: Re: [Netconf] xml declaration required or optional > > On Tue, May 06, 2008 at 04:47:43PM +0200, Balazs Lengyel wrote: > > > I would like a bis. > > > > Would a bis only cover corrections or can it include new stuff like: > > - with-defaults > > - test-only option for edit-config > > I think at this point, what we really need is an update which just > does corrections. There many things that are simply inconsistent in > RFC 4741; some are relatively clear and easy to fix. For others, it is > not clear what the intent really was. > > /js > > PS: I am talking about the text and the examples, not the XSD which I > tend to ignore. I would love the text and the examples to say > everything that needs to be said. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 13:26:13 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041453A6906; Tue, 6 May 2008 13:26:13 -0700 (PDT) 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 9611928C356 for ; Tue, 6 May 2008 13:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.150, 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 W9L79Gb6xy6I for ; Tue, 6 May 2008 13:26:11 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id CC7173A6897 for ; Tue, 6 May 2008 13:26:10 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 2A78D1B80D3; Tue, 6 May 2008 22:26:08 +0200 (CEST) Date: Tue, 06 May 2008 22:25:57 +0200 (CEST) Message-Id: <20080506.222557.68758341.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200805061632.m46GW8uC050508@idle.juniper.net> References: <20080506.181801.149900165.mbj@tail-f.com> <200805061632.m46GW8uC050508@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Phil Shafer wrote: > Martin Bjorklund writes: > > > > > > > > > > > > > > This one. If the RPC completes and the server hasn't emitted > any errors or warnings, it emits and element. This > allows, say, a config archiver to know if there were any > errors reading the config from flash without having to > traverse the entire hierarchy looking for elements. if ($results/ok) { ... } vs. if (not($results/rpc-error)) { ... } I agree with Andy. All the examples, the text about get-config and get, and the XSD, indicate that there is no element in the reply for get and get-config. I would not consider changing this "a clarification" or bugfix. And I don't see the value in making this change at all. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 13:26:13 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041453A6906; Tue, 6 May 2008 13:26:13 -0700 (PDT) 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 9611928C356 for ; Tue, 6 May 2008 13:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.150, 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 W9L79Gb6xy6I for ; Tue, 6 May 2008 13:26:11 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id CC7173A6897 for ; Tue, 6 May 2008 13:26:10 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 2A78D1B80D3; Tue, 6 May 2008 22:26:08 +0200 (CEST) Date: Tue, 06 May 2008 22:25:57 +0200 (CEST) Message-Id: <20080506.222557.68758341.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200805061632.m46GW8uC050508@idle.juniper.net> References: <20080506.181801.149900165.mbj@tail-f.com> <200805061632.m46GW8uC050508@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Phil Shafer wrote: > Martin Bjorklund writes: > > > > > > > > > > > > > > This one. If the RPC completes and the server hasn't emitted > any errors or warnings, it emits and element. This > allows, say, a config archiver to know if there were any > errors reading the config from flash without having to > traverse the entire hierarchy looking for elements. if ($results/ok) { ... } vs. if (not($results/rpc-error)) { ... } I agree with Andy. All the examples, the text about get-config and get, and the XSD, indicate that there is no element in the reply for get and get-config. I would not consider changing this "a clarification" or bugfix. And I don't see the value in making this change at all. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 13:36:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0D93A6A9F; Tue, 6 May 2008 13:36:39 -0700 (PDT) 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 42F723A6C62 for ; Tue, 6 May 2008 13:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, MANGLED_LOOK=2.3, 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 DfoVmTWT0Y5E for ; Tue, 6 May 2008 13:36:37 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id AB4433A69EC for ; Tue, 6 May 2008 13:36:24 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob59.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 13:33:29 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 13:35:41 -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 m46KZfx66523; Tue, 6 May 2008 13:35:41 -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 m46KXv8X052844; Tue, 6 May 2008 20:33:57 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805062033.m46KXv8X052844@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080506.222557.68758341.mbj@tail-f.com> Date: Tue, 06 May 2008 16:33:56 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 20:35:41.0759 (UTC) FILETIME=[C071DCF0:01C8AFB8] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund writes: > if (not($results/rpc-error)) { ... } What about error or warning elements that appear deep inside the xml hierarchy? You'd need: if (not($results//rpc-error)) { ... } so your XPath searches the entire hierarchy. >And I don't see the value in making this change at all. The current text says: 4.4. Element The element is sent in messages if no errors or warnings occurred during the processing of an request. For example: So if you like the examples, this needs fixed to say "if no other elements are emitted" or something like that. Either way, it's a bugfix. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 13:36:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0D93A6A9F; Tue, 6 May 2008 13:36:39 -0700 (PDT) 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 42F723A6C62 for ; Tue, 6 May 2008 13:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, MANGLED_LOOK=2.3, 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 DfoVmTWT0Y5E for ; Tue, 6 May 2008 13:36:37 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id AB4433A69EC for ; Tue, 6 May 2008 13:36:24 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob59.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 13:33:29 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 13:35:41 -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 m46KZfx66523; Tue, 6 May 2008 13:35:41 -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 m46KXv8X052844; Tue, 6 May 2008 20:33:57 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805062033.m46KXv8X052844@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080506.222557.68758341.mbj@tail-f.com> Date: Tue, 06 May 2008 16:33:56 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 20:35:41.0759 (UTC) FILETIME=[C071DCF0:01C8AFB8] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund writes: > if (not($results/rpc-error)) { ... } What about error or warning elements that appear deep inside the xml hierarchy? You'd need: if (not($results//rpc-error)) { ... } so your XPath searches the entire hierarchy. >And I don't see the value in making this change at all. The current text says: 4.4. Element The element is sent in messages if no errors or warnings occurred during the processing of an request. For example: So if you like the examples, this needs fixed to say "if no other elements are emitted" or something like that. Either way, it's a bugfix. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 13:41:01 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE723A69EC; Tue, 6 May 2008 13:41:01 -0700 (PDT) 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 4F06D28C390 for ; Tue, 6 May 2008 13:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=0.114, 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 zdUhc8vzEK0x for ; Tue, 6 May 2008 13:40:59 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 7922128C49B for ; Tue, 6 May 2008 13:40:57 -0700 (PDT) Received: (qmail 6468 invoked from network); 6 May 2008 20:40:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 6 May 2008 20:40:53 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820C1F3.6070904@andybierman.com> Date: Tue, 06 May 2008 13:39:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805061856.m46IuD46051592@idle.juniper.net> In-Reply-To: <200805061856.m46IuD46051592@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Are you saying nobody understood the examples either, >> and most of them are wrong? > > I'm just saying that the document has some parts that show that we > did a fairly poor job of polishing it. Claiming that the XSD is > the will of the WG conflicts with saying that we need YANG because > no one reads XSD. We used the "surprises" in the NETCONF XSD as > an example that no one read it. > The XSD was reviewed by several people, over several years. It does reflect the consensus of the WG. BTW, for future development of protocol features (by NETCONF or any other WG): 1) Why does the IETF continue to use XSD if there is such great evidence that nobody understands it enough to review it? 2) There are less people qualified to review DSDL+Schematron than XSD (probably by an order of magnitude). Is the intent to include these in RFCs, but nobody will ever review them? 3) What are protocol WGs supposed to use to document XML-based protocols, if not XSD? When is this 'policy' going to show up in RFCs? > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 13:41:01 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE723A69EC; Tue, 6 May 2008 13:41:01 -0700 (PDT) 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 4F06D28C390 for ; Tue, 6 May 2008 13:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=0.114, 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 zdUhc8vzEK0x for ; Tue, 6 May 2008 13:40:59 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 7922128C49B for ; Tue, 6 May 2008 13:40:57 -0700 (PDT) Received: (qmail 6468 invoked from network); 6 May 2008 20:40:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 6 May 2008 20:40:53 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820C1F3.6070904@andybierman.com> Date: Tue, 06 May 2008 13:39:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805061856.m46IuD46051592@idle.juniper.net> In-Reply-To: <200805061856.m46IuD46051592@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Are you saying nobody understood the examples either, >> and most of them are wrong? > > I'm just saying that the document has some parts that show that we > did a fairly poor job of polishing it. Claiming that the XSD is > the will of the WG conflicts with saying that we need YANG because > no one reads XSD. We used the "surprises" in the NETCONF XSD as > an example that no one read it. > The XSD was reviewed by several people, over several years. It does reflect the consensus of the WG. BTW, for future development of protocol features (by NETCONF or any other WG): 1) Why does the IETF continue to use XSD if there is such great evidence that nobody understands it enough to review it? 2) There are less people qualified to review DSDL+Schematron than XSD (probably by an order of magnitude). Is the intent to include these in RFCs, but nobody will ever review them? 3) What are protocol WGs supposed to use to document XML-based protocols, if not XSD? When is this 'policy' going to show up in RFCs? > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 13:42:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED96C28C47B; Tue, 6 May 2008 13:42:54 -0700 (PDT) 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 CD1EC28C492 for ; Tue, 6 May 2008 13:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.689 X-Spam-Level: X-Spam-Status: No, score=-0.689 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 XPMMPH+FiPEm for ; Tue, 6 May 2008 13:42:52 -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 202F528C47B for ; Tue, 6 May 2008 13:42:52 -0700 (PDT) Received: (qmail 14952 invoked from network); 6 May 2008 20:42:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 6 May 2008 20:42:48 -0000 X-YMail-OSG: ItBYq6YVM1nY7r4l6POnizv.9g._nYpRou7Uoupl0proVkWyHAxuyjoiWAwgJsJEHC5suCVOU9.76gwlH_89VpA4NrIjSSZwx0tSyLGkvYNBv9IeBeOxnqddY7tGfT4kmAhBrxc2xIBWsUcqx_agc7TE X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820C266.4050201@andybierman.com> Date: Tue, 06 May 2008 13:41:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805062033.m46KXv8X052844@idle.juniper.net> In-Reply-To: <200805062033.m46KXv8X052844@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: >> if (not($results/rpc-error)) { ... } > > What about error or warning elements that appear deep inside the > xml hierarchy? You'd need: > > if (not($results//rpc-error)) { ... } > > so your XPath searches the entire hierarchy. > This is not allowed (by the XSD you never read). There are zero-or-more elements, as direct siblings of . There are no 'deep errors' to hunt down in a compliant implementation. Andy >> And I don't see the value in making this change at all. > > The current text says: > > 4.4. Element > > The element is sent in messages if no errors or > warnings occurred during the processing of an request. For > example: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > So if you like the examples, this needs fixed to say "if no other > elements are emitted" or something like that. Either way, it's a > bugfix. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 13:42:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED96C28C47B; Tue, 6 May 2008 13:42:54 -0700 (PDT) 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 CD1EC28C492 for ; Tue, 6 May 2008 13:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.689 X-Spam-Level: X-Spam-Status: No, score=-0.689 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 XPMMPH+FiPEm for ; Tue, 6 May 2008 13:42:52 -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 202F528C47B for ; Tue, 6 May 2008 13:42:52 -0700 (PDT) Received: (qmail 14952 invoked from network); 6 May 2008 20:42:50 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 6 May 2008 20:42:48 -0000 X-YMail-OSG: ItBYq6YVM1nY7r4l6POnizv.9g._nYpRou7Uoupl0proVkWyHAxuyjoiWAwgJsJEHC5suCVOU9.76gwlH_89VpA4NrIjSSZwx0tSyLGkvYNBv9IeBeOxnqddY7tGfT4kmAhBrxc2xIBWsUcqx_agc7TE X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820C266.4050201@andybierman.com> Date: Tue, 06 May 2008 13:41:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805062033.m46KXv8X052844@idle.juniper.net> In-Reply-To: <200805062033.m46KXv8X052844@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Martin Bjorklund writes: >> if (not($results/rpc-error)) { ... } > > What about error or warning elements that appear deep inside the > xml hierarchy? You'd need: > > if (not($results//rpc-error)) { ... } > > so your XPath searches the entire hierarchy. > This is not allowed (by the XSD you never read). There are zero-or-more elements, as direct siblings of . There are no 'deep errors' to hunt down in a compliant implementation. Andy >> And I don't see the value in making this change at all. > > The current text says: > > 4.4. Element > > The element is sent in messages if no errors or > warnings occurred during the processing of an request. For > example: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > So if you like the examples, this needs fixed to say "if no other > elements are emitted" or something like that. Either way, it's a > bugfix. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 14:11:50 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222DF3A6844; Tue, 6 May 2008 14:11:50 -0700 (PDT) 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 AD6643A6830 for ; Tue, 6 May 2008 14:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.212, 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 WicrWsIiyfmA for ; Tue, 6 May 2008 14:11:45 -0700 (PDT) Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id 2ADE83A6FD4 for ; Tue, 6 May 2008 14:10:58 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob60.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 14:10:38 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 14:10:05 -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 m46LA4x79045; Tue, 6 May 2008 14:10:04 -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 m46L8K5t053188; Tue, 6 May 2008 21:08:20 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805062108.m46L8K5t053188@idle.juniper.net> To: Andy Bierman In-reply-to: <4820C266.4050201@andybierman.com> Date: Tue, 06 May 2008 17:08:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 21:10:05.0006 (UTC) FILETIME=[8E3C5EE0:01C8AFBD] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >There are zero-or-more elements, as direct >siblings of . There are no 'deep errors' >to hunt down in a compliant implementation. If you read the text part, it says messages are emitted during the processing of the operation, which implies they appear inside the returned content. If I'm reading statistics from an embedded hardware component and I get an ENOMEM error, am I not able to emit that error immediately? Is it your position that I need to buffer all errors and emit them at the end of the rpc? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 14:11:50 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222DF3A6844; Tue, 6 May 2008 14:11:50 -0700 (PDT) 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 AD6643A6830 for ; Tue, 6 May 2008 14:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.212, 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 WicrWsIiyfmA for ; Tue, 6 May 2008 14:11:45 -0700 (PDT) Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id 2ADE83A6FD4 for ; Tue, 6 May 2008 14:10:58 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob60.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 14:10:38 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 May 2008 14:10:05 -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 m46LA4x79045; Tue, 6 May 2008 14:10:04 -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 m46L8K5t053188; Tue, 6 May 2008 21:08:20 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805062108.m46L8K5t053188@idle.juniper.net> To: Andy Bierman In-reply-to: <4820C266.4050201@andybierman.com> Date: Tue, 06 May 2008 17:08:19 -0400 From: Phil Shafer X-OriginalArrivalTime: 06 May 2008 21:10:05.0006 (UTC) FILETIME=[8E3C5EE0:01C8AFBD] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >There are zero-or-more elements, as direct >siblings of . There are no 'deep errors' >to hunt down in a compliant implementation. If you read the text part, it says messages are emitted during the processing of the operation, which implies they appear inside the returned content. If I'm reading statistics from an embedded hardware component and I get an ENOMEM error, am I not able to emit that error immediately? Is it your position that I need to buffer all errors and emit them at the end of the rpc? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 14:31:06 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7230128C480; Tue, 6 May 2008 14:31:06 -0700 (PDT) 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 1514E28C47B for ; Tue, 6 May 2008 14:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=0.108, 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 0ejjTOn39G+c for ; Tue, 6 May 2008 14:31:04 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 146953A6844 for ; Tue, 6 May 2008 14:30:30 -0700 (PDT) Received: (qmail 36135 invoked from network); 6 May 2008 21:30:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 6 May 2008 21:30:26 -0000 X-YMail-OSG: aFvSuYkVM1nz5oxcH9lswJOzuRkFW7FsY3TB1S3VvYNX713LHuySYqJ076aOAd6YLEcaevSgZnr8tbYoIKMlNDbPjHGGn91ieQoYg1JrSw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820CD89.5080903@andybierman.com> Date: Tue, 06 May 2008 14:28:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805062108.m46L8K5t053188@idle.juniper.net> In-Reply-To: <200805062108.m46L8K5t053188@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> There are zero-or-more elements, as direct >> siblings of . There are no 'deep errors' >> to hunt down in a compliant implementation. > > If you read the text part, it says messages are emitted > during the processing of the operation, which implies they appear > inside the returned content. If I'm reading statistics from an > embedded hardware component and I get an ENOMEM error, am I not > able to emit that error immediately? Is it your position that I > need to buffer all errors and emit them at the end of the rpc? > I don't see that text. Even if it did say "emitted" during processing, that does not mean they are embedded in the element. That is not how the protocol is defined. The XSD is normative for XML syntax, and it is very clear: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7230128C480; Tue, 6 May 2008 14:31:06 -0700 (PDT) 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 1514E28C47B for ; Tue, 6 May 2008 14:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[AWL=0.108, 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 0ejjTOn39G+c for ; Tue, 6 May 2008 14:31:04 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 146953A6844 for ; Tue, 6 May 2008 14:30:30 -0700 (PDT) Received: (qmail 36135 invoked from network); 6 May 2008 21:30:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 6 May 2008 21:30:26 -0000 X-YMail-OSG: aFvSuYkVM1nz5oxcH9lswJOzuRkFW7FsY3TB1S3VvYNX713LHuySYqJ076aOAd6YLEcaevSgZnr8tbYoIKMlNDbPjHGGn91ieQoYg1JrSw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820CD89.5080903@andybierman.com> Date: Tue, 06 May 2008 14:28:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805062108.m46L8K5t053188@idle.juniper.net> In-Reply-To: <200805062108.m46L8K5t053188@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> There are zero-or-more elements, as direct >> siblings of . There are no 'deep errors' >> to hunt down in a compliant implementation. > > If you read the text part, it says messages are emitted > during the processing of the operation, which implies they appear > inside the returned content. If I'm reading statistics from an > embedded hardware component and I get an ENOMEM error, am I not > able to emit that error immediately? Is it your position that I > need to buffer all errors and emit them at the end of the rpc? > I don't see that text. Even if it did say "emitted" during processing, that does not mean they are embedded in the element. That is not how the protocol is defined. The XSD is normative for XML syntax, and it is very clear: I cannot find any text that says elements are ever embedded within the element. IMO, this is not compliant. The XSD exactly reflects the intent of the WG, as I remember it. The contains a single element, or it contains zero-or-more and zero-or-one elements. > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf inOccurs="0" maxOccurs="unbounded"/> I cannot find any text that says elements are ever embedded within the element. IMO, this is not compliant. The XSD exactly reflects the intent of the WG, as I remember it. The contains a single element, or it contains zero-or-more and zero-or-one elements. > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 14:57:57 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A663A7095; Tue, 6 May 2008 14:57:57 -0700 (PDT) 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 0C27C3A7087 for ; Tue, 6 May 2008 14:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=0.088, 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 SsbafUGZsurS for ; Tue, 6 May 2008 14:57:54 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id C1EBC28C4C4 for ; Tue, 6 May 2008 14:55:34 -0700 (PDT) Received: (qmail 10501 invoked from network); 6 May 2008 21:55:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 6 May 2008 21:55:31 -0000 X-YMail-OSG: msTDWLMVM1nn3PsxPiw5iHbG62d8kzsGlyD_KUhvVcpEaRpMVm4pNTVREaI0lD6V9GJ9F3tEAnSSMRH4KQ.MA45fcMHKdposrRPzIie5Pw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820D365.4030609@andybierman.com> Date: Tue, 06 May 2008 14:53:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805062108.m46L8K5t053188@idle.juniper.net> In-Reply-To: <200805062108.m46L8K5t053188@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >... Is it your position that I > need to buffer all errors and emit them at the end of the rpc? > No -- it's even worse than that. The XSD says all the elements are first in the reply, optionally followed by the element. I don't agree that any RFC text indicates the messages should be generated in any other way. I have heard of performance-based arguments for protocols that are in the forwarding path, but never for NM, especially a relatively low frequency task like editing the configuration. It seems clear to me what XML is valid according to the XSD. I don't think that the internal buffering required for NETCONF is an implementation burden. Changing the XSD now will break existing implementations, so the protocol version will need to be incremented. > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 14:57:57 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A663A7095; Tue, 6 May 2008 14:57:57 -0700 (PDT) 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 0C27C3A7087 for ; Tue, 6 May 2008 14:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=0.088, 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 SsbafUGZsurS for ; Tue, 6 May 2008 14:57:54 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id C1EBC28C4C4 for ; Tue, 6 May 2008 14:55:34 -0700 (PDT) Received: (qmail 10501 invoked from network); 6 May 2008 21:55:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 6 May 2008 21:55:31 -0000 X-YMail-OSG: msTDWLMVM1nn3PsxPiw5iHbG62d8kzsGlyD_KUhvVcpEaRpMVm4pNTVREaI0lD6V9GJ9F3tEAnSSMRH4KQ.MA45fcMHKdposrRPzIie5Pw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820D365.4030609@andybierman.com> Date: Tue, 06 May 2008 14:53:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805062108.m46L8K5t053188@idle.juniper.net> In-Reply-To: <200805062108.m46L8K5t053188@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >... Is it your position that I > need to buffer all errors and emit them at the end of the rpc? > No -- it's even worse than that. The XSD says all the elements are first in the reply, optionally followed by the element. I don't agree that any RFC text indicates the messages should be generated in any other way. I have heard of performance-based arguments for protocols that are in the forwarding path, but never for NM, especially a relatively low frequency task like editing the configuration. It seems clear to me what XML is valid according to the XSD. I don't think that the internal buffering required for NETCONF is an implementation burden. Changing the XSD now will break existing implementations, so the protocol version will need to be incremented. > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 6 15:11:40 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15933A6931; Tue, 6 May 2008 15:11:40 -0700 (PDT) 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 D61B628C488 for ; Tue, 6 May 2008 15:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 DtBYNX+k-NyP for ; Tue, 6 May 2008 15:11:34 -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 5DAB93A6B21 for ; Tue, 6 May 2008 15:11:34 -0700 (PDT) Received: (qmail 48248 invoked from network); 6 May 2008 22:11:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 6 May 2008 22:11:31 -0000 X-YMail-OSG: GoBBd5EVM1kxOU75JxSOO9s4w7Ul_UGjaXhEQrrX7CSqJP54Cwo1UIQ1ds_m9sU9Cio2J699DTZOkJAUbZtOWGBD6v4klOkQGLA6FdIzyktg2xl1Lp89ZiZiWMwz66coYiN8jPW4HZGznnzXRi.VEsCQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820D723.70906@andybierman.com> Date: Tue, 06 May 2008 15:09:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805062108.m46L8K5t053188@idle.juniper.net> <4820D365.4030609@andybierman.com> In-Reply-To: <4820D365.4030609@andybierman.com> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > >... Is it your position that I >> need to buffer all errors and emit them at the end of the rpc? >> Wait -- there are no inline errors to generate for or , and there is no returned in , , or , which are the only RPCs that can generate inline errors. So why is this even a problem? Andy > > No -- it's even worse than that. > The XSD says all the elements are first in the reply, > optionally followed by the element. > > I don't agree that any RFC text indicates the > messages should be generated in any other way. > > I have heard of performance-based arguments for protocols that > are in the forwarding path, but never for NM, especially a > relatively low frequency task like editing the configuration. > It seems clear to me what XML is valid according to the XSD. > I don't think that the internal buffering required for NETCONF > is an implementation burden. Changing the XSD now will > break existing implementations, so the protocol version will > need to be incremented. > > >> Thanks, >> Phil >> >> >> > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________From netconf-bounces@ietf.org Tue May 6 15:11:40 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15933A6931; Tue, 6 May 2008 15:11:40 -0700 (PDT) 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 D61B628C488 for ; Tue, 6 May 2008 15:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 DtBYNX+k-NyP for ; Tue, 6 May 2008 15:11:34 -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 5DAB93A6B21 for ; Tue, 6 May 2008 15:11:34 -0700 (PDT) Received: (qmail 48248 invoked from network); 6 May 2008 22:11:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 6 May 2008 22:11:31 -0000 X-YMail-OSG: GoBBd5EVM1kxOU75JxSOO9s4w7Ul_UGjaXhEQrrX7CSqJP54Cwo1UIQ1ds_m9sU9Cio2J699DTZOkJAUbZtOWGBD6v4klOkQGLA6FdIzyktg2xl1Lp89ZiZiWMwz66coYiN8jPW4HZGznnzXRi.VEsCQ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4820D723.70906@andybierman.com> Date: Tue, 06 May 2008 15:09:39 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805062108.m46L8K5t053188@idle.juniper.net> <4820D365.4030609@andybierman.com> In-Reply-To: <4820D365.4030609@andybierman.com> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > >... Is it your position that I >> need to buffer all errors and emit them at the end of the rpc? >> Wait -- there are no inline errors to generate for or , and there is no returned in , , or , which are the only RPCs that can generate inline errors. So why is this even a problem? Andy > > No -- it's even worse than that. > The XSD says all the elements are first in the reply, > optionally followed by the element. > > I don't agree that any RFC text indicates the > messages should be generated in any other way. > > I have heard of performance-based arguments for protocols that > are in the forwarding path, but never for NM, especially a > relatively low frequency task like editing the configuration. > It seems clear to me what XML is valid according to the XSD. > I don't think that the internal buffering required for NETCONF > is an implementation burden. Changing the XSD now will > break existing implementations, so the protocol version will > need to be incremented. > > >> Thanks, >> Phil >> >> >> > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 02:44:20 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0047328C5FF; Wed, 7 May 2008 02:44:20 -0700 (PDT) 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 C4E6B3A6A99 for ; Wed, 7 May 2008 02:44:14 -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 DH9e2Bn3p9dY for ; Wed, 7 May 2008 02:44:13 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id B60603A70E5 for ; Wed, 7 May 2008 02:42:16 -0700 (PDT) X-Trace: 22721973/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.144.185 X-SBRS: None X-RemoteIP: 62.188.144.185 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAEcWIUg+vJC5/2dsb2JhbACLS6EpBA X-IP-Direction: IN Received: from 1cust185.tnt15.lnd4.gbr.da.uu.net (HELO allison) ([62.188.144.185]) by smtp.pipex.tiscali.co.uk with SMTP; 07 May 2008 10:42:11 +0100 Message-ID: <017801c8b01d$a7188000$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> <200805061516.m46FGeVB049807@idle.juniper.net><713043CE8B8E1348AF3C546DBE02C1B41469B557@zcarhxm2.corp.nortel.com> <48208513.5000408@andybierman.com> Date: Wed, 7 May 2008 10:35:18 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I agree that the intent was for to be an alternative to . Iff we get consensus on this, then we could file an erratum pending the production of the -bis. And I do read the Appendices (which is where the XSD is); but IMO there is a general principle in RFC that Appendices are not normative unless they say that they are and so where there is a conflict between Appendix and the body of the document, then the body wins. Which is something else a -bis could clarify. Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Sharon Chisholm" Cc: Sent: Tuesday, May 06, 2008 6:19 PM Subject: Re: [Netconf] xml declaration required or optional > Sharon Chisholm wrote: > > Hi > > > > Except that it is contradicted in other parts of the document, like the > > XSD and the examples. What people do seems to depend on which parts of > > the document they pay the most attention to. I sort of like the easier > > test too. We just need to be clear which is intended and ensure that all > > the text is consistent.From netconf-bounces@ietf.org Wed May 7 02:44:20 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0047328C5FF; Wed, 7 May 2008 02:44:20 -0700 (PDT) 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 C4E6B3A6A99 for ; Wed, 7 May 2008 02:44:14 -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 DH9e2Bn3p9dY for ; Wed, 7 May 2008 02:44:13 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id B60603A70E5 for ; Wed, 7 May 2008 02:42:16 -0700 (PDT) X-Trace: 22721973/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.144.185 X-SBRS: None X-RemoteIP: 62.188.144.185 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAEcWIUg+vJC5/2dsb2JhbACLS6EpBA X-IP-Direction: IN Received: from 1cust185.tnt15.lnd4.gbr.da.uu.net (HELO allison) ([62.188.144.185]) by smtp.pipex.tiscali.co.uk with SMTP; 07 May 2008 10:42:11 +0100 Message-ID: <017801c8b01d$a7188000$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <713043CE8B8E1348AF3C546DBE02C1B41469B32C@zcarhxm2.corp.nortel.com> <200805061516.m46FGeVB049807@idle.juniper.net><713043CE8B8E1348AF3C546DBE02C1B41469B557@zcarhxm2.corp.nortel.com> <48208513.5000408@andybierman.com> Date: Wed, 7 May 2008 10:35:18 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I agree that the intent was for to be an alternative to . Iff we get consensus on this, then we could file an erratum pending the production of the -bis. And I do read the Appendices (which is where the XSD is); but IMO there is a general principle in RFC that Appendices are not normative unless they say that they are and so where there is a conflict between Appendix and the body of the document, then the body wins. Which is something else a -bis could clarify. Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Sharon Chisholm" Cc: Sent: Tuesday, May 06, 2008 6:19 PM Subject: Re: [Netconf] xml declaration required or optional > Sharon Chisholm wrote: > > Hi > > > > Except that it is contradicted in other parts of the document, like the > > XSD and the examples. What people do seems to depend on which parts of > > the document they pay the most attention to. I sort of like the easier > > test too. We just need to be clear which is intended and ensure that all > > the text is consistent. > > > > The XSD reflects the intent of the WG, when RFC 4741 was developed. > RPC methods that returned data used the node in the . > Instead of sending an empty upon success (for RPC methods > that do not return any data), it was thought that an explicit > would be better. > > IMO, section 4.4 is incomplete. > It should say that that only applies if no > element is sent (and the other conditions are met). > > All the examples, and the normative XSD say otherwise. > > > Sharon > > Andy > > > > > > -----Original Message----- > > From: Phil Shafer [mailto:phil@juniper.net] > > Sent: Tuesday, May 06, 2008 11:17 AM > > To: Chisholm, Sharon (CAR:ZZ00) > > Cc: Martin Bjorklund; netconf@ietf.org > > Subject: Re: [Netconf] xml declaration required or optional > > > > "Sharon Chisholm" writes: > >> The element is sent in messages if no errors or > >> warnings occurred during the processing of an request. > >> This has caused some confusion. > > > > Well, that's completely clear, but not what we implemented in JUNOS. > > I'm happy to fix our implementation though. Being able to do simple > > tests like: > > > > if ($results/ok) { ... } > > > > is a win. > > > > Thanks, > > Phil > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf > > > > The XSD reflects the intent of the WG, when RFC 4741 was developed. > RPC methods that returned data used the node in the . > Instead of sending an empty upon success (for RPC methods > that do not return any data), it was thought that an explicit > would be better. > > IMO, section 4.4 is incomplete. > It should say that that only applies if no > element is sent (and the other conditions are met). > > All the examples, and the normative XSD say otherwise. > > > Sharon > > Andy > > > > > > -----Original Message----- > > From: Phil Shafer [mailto:phil@juniper.net] > > Sent: Tuesday, May 06, 2008 11:17 AM > > To: Chisholm, Sharon (CAR:ZZ00) > > Cc: Martin Bjorklund; netconf@ietf.org > > Subject: Re: [Netconf] xml declaration required or optional > > > > "Sharon Chisholm" writes: > >> The element is sent in messages if no errors or > >> warnings occurred during the processing of an request. > >> This has caused some confusion. > > > > Well, that's completely clear, but not what we implemented in JUNOS. > > I'm happy to fix our implementation though. Being able to do simple > > tests like: > > > > if ($results/ok) { ... } > > > > is a win. > > > > Thanks, > > Phil > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 06:06:11 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A7E28C6A0; Wed, 7 May 2008 06:06:08 -0700 (PDT) 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 B194828C66B for ; Wed, 7 May 2008 06:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 RoSIdN9ifJJB for ; Wed, 7 May 2008 06:05:13 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id CD63828C639 for ; Wed, 7 May 2008 06:04:01 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 07 May 2008 06:03:34 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 05:58:38 -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 m47Cwbx07166; Wed, 7 May 2008 05:58:37 -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 m47CuqLQ058310; Wed, 7 May 2008 12:56:52 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805071256.m47CuqLQ058310@idle.juniper.net> To: Andy Bierman In-reply-to: <4820D723.70906@andybierman.com> Date: Wed, 07 May 2008 08:56:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 May 2008 12:58:38.0100 (UTC) FILETIME=[11155540:01C8B042] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >Wait -- there are no inline errors to generate for > or , and there is no returned >in , , or , which are the >only RPCs that can generate inline errors. I gave a real-world example (ENOMEM while fetching statistics). I'm no XSD dude, but doesn't the :any inside mean it can contain anything, including ? Ah, nevermind. The RFC says: Negative Response: An element is included in the if the request cannot be completed for any reason. So if I complete the RPC, I can't send an error. And since warnings are encoded in elements, I can't do that either. So I need to discard errors and warnings during the the processing of the operation, if the operation succeeds, right? This means that warnings and (or ) can't live together, which significantly reduces the value of warnings. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 06:06:10 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A7E28C6A0; Wed, 7 May 2008 06:06:08 -0700 (PDT) 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 B194828C66B for ; Wed, 7 May 2008 06:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 RoSIdN9ifJJB for ; Wed, 7 May 2008 06:05:13 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id CD63828C639 for ; Wed, 7 May 2008 06:04:01 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 07 May 2008 06:03:34 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 05:58:38 -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 m47Cwbx07166; Wed, 7 May 2008 05:58:37 -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 m47CuqLQ058310; Wed, 7 May 2008 12:56:52 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805071256.m47CuqLQ058310@idle.juniper.net> To: Andy Bierman In-reply-to: <4820D723.70906@andybierman.com> Date: Wed, 07 May 2008 08:56:52 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 May 2008 12:58:38.0100 (UTC) FILETIME=[11155540:01C8B042] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >Wait -- there are no inline errors to generate for > or , and there is no returned >in , , or , which are the >only RPCs that can generate inline errors. I gave a real-world example (ENOMEM while fetching statistics). I'm no XSD dude, but doesn't the :any inside mean it can contain anything, including ? Ah, nevermind. The RFC says: Negative Response: An element is included in the if the request cannot be completed for any reason. So if I complete the RPC, I can't send an error. And since warnings are encoded in elements, I can't do that either. So I need to discard errors and warnings during the the processing of the operation, if the operation succeeds, right? This means that warnings and (or ) can't live together, which significantly reduces the value of warnings. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 06:30:45 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088133A6974; Wed, 7 May 2008 06:30:45 -0700 (PDT) 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 3CA833A6974 for ; Wed, 7 May 2008 06:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.409, 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 ILpJ6lppipmf for ; Wed, 7 May 2008 06:30:42 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id C0AD33A6883 for ; Wed, 7 May 2008 06:30:41 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m47DUXs28405; Wed, 7 May 2008 13:30:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 May 2008 09:30:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4145E0839@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Issue X: access to notification content Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvAABsEUIABWhJqgAAUdWGAAi9ih4ABnGPDg References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145DFBB5@zcarhxm2.corp.nortel.com> <00a901c8ac7b$ac789e40$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145E0839@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: "David B Harrington" , "Bert Wijnen - IETF" , Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi If there is no objection to proposal A then I will proceed to make this change and publish the updated draft. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Monday, May 05, 2008 8:33 AM To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content Hi I think it would be helpful to go back to original text we are editing rather then the snippets. I've modified the second sentence in ways that I think address the access versus authorization confusion and I think makes it so we can keep the 'must not'. I think now we don't need to 'depending on access control..." part because we are make a recommendation about the access control in order to maintain minimal security. I've added a third option which trFrom netconf-bounces@ietf.org Wed May 7 06:30:45 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088133A6974; Wed, 7 May 2008 06:30:45 -0700 (PDT) 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 3CA833A6974 for ; Wed, 7 May 2008 06:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.409, 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 ILpJ6lppipmf for ; Wed, 7 May 2008 06:30:42 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id C0AD33A6883 for ; Wed, 7 May 2008 06:30:41 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m47DUXs28405; Wed, 7 May 2008 13:30:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 May 2008 09:30:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4145E0839@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Issue X: access to notification content Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvAABsEUIABWhJqgAAUdWGAAi9ih4ABnGPDg References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145DFBB5@zcarhxm2.corp.nortel.com> <00a901c8ac7b$ac789e40$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145E0839@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: "David B Harrington" , "Bert Wijnen - IETF" , Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi If there is no objection to proposal A then I will proceed to make this change and publish the updated draft. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Monday, May 05, 2008 8:33 AM To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content Hi I think it would be helpful to go back to original text we are editing rather then the snippets. I've modified the second sentence in ways that I think address the access versus authorization confusion and I think makes it so we can keep the 'must not'. I think now we don't need to 'depending on access control..." part because we are make a recommendation about the access control in order to maintain minimal security. I've added a third option which tries to include those for comparison. I prefer A. Current text The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view content via other NETCONF operations, she must not have access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. Proposed text (A) The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view the information in the notification, they must not have access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. Proposed text (B) The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view the information in the notification, the access control model and administrative policy probably should not allow them access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. I also got rid of the 'she' thing since I think the singular use of 'they' is now grammatically acceptable in these cases. Sharon -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Friday, May 02, 2008 1:41 PM To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; netconf@ietf.org Subject: RE: Issue X: access to notification content > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Friday, May 02, 2008 11:22 AM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > By proposed text, did you mean: > > "she probably should not ... depending on the access control model and > administrative policy." > > Which I proposed to change to > > "she likely will not ... depending on the access control model and > administrative policy." That is not what your earlier response said. The proposal in your response did not include the text after the ellipsis. I prefer "she probably should not" because "should not" is RFC2119 language. You might want to stiffen that slightly by making it "she probably SHOULD NOT ... depending on the access control model and administrative policy." > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Wednesday, April 30, 2008 5:53 PM > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > netconf@ietf.org > Subject: RE: Issue X: access to notification content > > Hi, > > I don't think your proposed change addresses the security review > concern. It doesn't say how access will be controlled. > > I think my proposed text does, by saying it will be handled by the > access control model and adminstrative policy. > > Is there a reason you don't find my proposed text acceptable? > > dbh > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > Sent: Wednesday, April 30, 2008 2:39 PM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi > > > > I can change from "she must not" to "she likely will not". I think > the > > probably softens things too much. The intent is that you > only get to > > view content you have permission to view, regardless of the access > > mechanisms. > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Tuesday, April 29, 2008 10:25 AM > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi, > > > > If it is only a discussion, then I suggest rewording "she must not > > ..." > > to "she probably should not ... depending on the access control > model > > and administrative policy." > > > > This does not create a CLR. > > > > dbh > > > > > -----Original Message----- > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Dave, this is a clarification to an concern from an IESG member. > > > It is in the "Security Considerations" section, so it is > > not a "hard > > > choice of protocol standard". We are explaining in the security > > > considerations section what kind of access concerns there might > be. > > > Does that clarify? > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > Bert Wijnen > > > > > > > -----Oorspronkelijk bericht----- > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > Verzonden: maandag 28 april 2008 19:28 > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > Hi bert, > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > Sharon just > > > > didn't understand and didn't fix. here's one: > > > > > > > > -- > > > > In section 7, the text says "If a user does not have > > > > permission to view content via other NETCONF operations, she > > must > > > > not > > > > have access to that content via Notifications." > > > > > > > > This creates a big CLR. > > > > > > > > Can content from a syslog or SNMP notification stream be > > sent to a > > > > user that does not have permission to access the syslog or SNMP > > > > content using some other Netconf operation? What other Netconf > > > > operation works with the syslog stream? Didn't we > > > explicitly decide it > > > > was not necessary to support access to notication streams > > > > (including syslog and SNMP streams)? > > > > > > > > I am also concerned that this access control "policy" > > should be an > > > > administrative one, not a hard choice of the protocol > > standard. In > > > > most cases it is the right choice. But a NOC manager > > might want to > > > > allow, say, the helpdesk to be alerted whenever a Netconf config > > is > > > > being changed, or an intrusion detection application to > > be alerted > > > > when there is an authentication failure. And yet, they may > > > not want to > > > > give the helpdesk or the IDS permissions. With this CLR, a > > NOC > > > > manager is simply not allowed to make such a decision. > > > > > > > > I understand the intent; I think the wording is poorly chosen, > > > > especially because it uses a "must", which has special > > > RFC2119 meaning > > > > and creates a huge CLR. And since access control will be > > > done later, I > > > > don't think the WG wants this CLR constraining all future > > > AC designs. > > > > > > > > But I could be wrong; maybe the WG will decide this is exactly > > what > > > > they want to say. If that is the case, then I think we need > > > to review > > > > this document to make sure everything else (like syslog streams) > > can > > > > work with this CLR. > > > > > > > > dbh > > > > > > > > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ies to include those for comparison. I prefer A. Current text The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view content via other NETCONF operations, she must not have access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. Proposed text (A) The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view the information in the notification, they must not have access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. Proposed text (B) The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view the information in the notification, the access control model and administrative policy probably should not allow them access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. I also got rid of the 'she' thing since I think the singular use of 'they' is now grammatically acceptable in these cases. Sharon -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Friday, May 02, 2008 1:41 PM To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; netconf@ietf.org Subject: RE: Issue X: access to notification content > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Friday, May 02, 2008 11:22 AM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > By proposed text, did you mean: > > "she probably should not ... depending on the access control model and > administrative policy." > > Which I proposed to change to > > "she likely will not ... depending on the access control model and > administrative policy." That is not what your earlier response said. The proposal in your response did not include the text after the ellipsis. I prefer "she probably should not" because "should not" is RFC2119 language. You might want to stiffen that slightly by making it "she probably SHOULD NOT ... depending on the access control model and administrative policy." > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Wednesday, April 30, 2008 5:53 PM > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > netconf@ietf.org > Subject: RE: Issue X: access to notification content > > Hi, > > I don't think your proposed change addresses the security review > concern. It doesn't say how access will be controlled. > > I think my proposed text does, by saying it will be handled by the > access control model and adminstrative policy. > > Is there a reason you don't find my proposed text acceptable? > > dbh > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > Sent: Wednesday, April 30, 2008 2:39 PM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi > > > > I can change from "she must not" to "she likely will not". I think > the > > probably softens things too much. The intent is that you > only get to > > view content you have permission to view, regardless of the access > > mechanisms. > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Tuesday, April 29, 2008 10:25 AM > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi, > > > > If it is only a discussion, then I suggest rewording "she must not > > ..." > > to "she probably should not ... depending on the access control > model > > and administrative policy." > > > > This does not create a CLR. > > > > dbh > > > > > -----Original Message----- > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Dave, this is a clarification to an concern from an IESG member. > > > It is in the "Security Considerations" section, so it is > > not a "hard > > > choice of protocol standard". We are explaining in the security > > > considerations section what kind of access concerns there might > be. > > > Does that clarify? > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > Bert Wijnen > > > > > > > -----Oorspronkelijk bericht----- > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > Verzonden: maandag 28 april 2008 19:28 > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > Hi bert, > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > Sharon just > > > > didn't understand and didn't fix. here's one: > > > > > > > > -- > > > > In section 7, the text says "If a user does not have > > > > permission to view content via other NETCONF operations, she > > must > > > > not > > > > have access to that content via Notifications." > > > > > > > > This creates a big CLR. > > > > > > > > Can content from a syslog or SNMP notification stream be > > sent to a > > > > user that does not have permission to access the syslog or SNMP > > > > content using some other Netconf operation? What other Netconf > > > > operation works with the syslog stream? Didn't we > > > explicitly decide it > > > > was not necessary to support access to notication streams > > > > (including syslog and SNMP streams)? > > > > > > > > I am also concerned that this access control "policy" > > should be an > > > > administrative one, not a hard choice of the protocol > > standard. In > > > > most cases it is the right choice. But a NOC manager > > might want to > > > > allow, say, the helpdesk to be alerted whenever a Netconf config > > is > > > > being changed, or an intrusion detection application to > > be alerted > > > > when there is an authentication failure. And yet, they may > > > not want to > > > > give the helpdesk or the IDS permissions. With this CLR, a > > NOC > > > > manager is simply not allowed to make such a decision. > > > > > > > > I understand the intent; I think the wording is poorly chosen, > > > > especially because it uses a "must", which has special > > > RFC2119 meaning > > > > and creates a huge CLR. And since access control will be > > > done later, I > > > > don't think the WG wants this CLR constraining all future > > > AC designs. > > > > > > > > But I could be wrong; maybe the WG will decide this is exactly > > what > > > > they want to say. If that is the case, then I think we need > > > to review > > > > this document to make sure everything else (like syslog streams) > > can > > > > work with this CLR. > > > > > > > > dbh > > > > > > > > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 06:33:19 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB72628C1F7; Wed, 7 May 2008 06:33:19 -0700 (PDT) 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 69D323A70AE for ; Wed, 7 May 2008 06:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 iDa3sd-n+lpV for ; Wed, 7 May 2008 06:33:09 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 43DAB28C635 for ; Wed, 7 May 2008 06:31:31 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m47DUCN21597; Wed, 7 May 2008 13:30:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 May 2008 09:31:10 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4146E002D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4145E07E1@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues Thread-Index: AcimybQVJEZ5iqdXTweyEournL26jgABBQJgAfaRXuAAZ56j8A== References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com><4811C0B5.7010907@cisco.com> <20080425114407.GC19025@elstar.local> <002101c8a955$4e0565b0$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145E07E1@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: "David B Harrington" , , "Eliot Lear" Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi If there is no objection to option 2 then I will make the change and publish the updated draft. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Monday, May 05, 2008 8:06 AM To: David B Harrington; j.schoenwaelder@jacobs-university.de; Eliot Lear Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues Hi Just to close this off. It seems we are converging on not adding the ISO reference but just the RFC. (Note the RFC references the ISO specification and attempts to remove some ambiguities). Just to clarify what people want to do 1) Keep both references 2) Just have a reference to RFC3339 3) Just have a reference to RFC3339 section 4.4 and appendix A 4) Just have a reference to RFC3339 section 4.4 5) Just have a reference to RFC339 appendix A Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David B Harrington Sent: Monday, April 28, 2008 1:28 PM To: j.schoenwaelder@jacobs-university.de; 'Eliot Lear' Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues I believe we should follow RFC3339 section 4.4 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Friday, April 25, 2008 7:44 AM > To: Eliot Lear > Cc: netconf@ietf.org > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > Issues > > On Fri, Apr 25, 2008 at 01:29:57PM +0200, Eliot Lear wrote: > > Hi Sharon, > > > > This comment is largely bureaucratic: > > > > > Proposed Edits > > > -------------- > > > > > > A. In section 2.1.1, for both instances and in section > 2.2.1 Replace > > > This parameter is of type dateTime. > > > With > > > This parameter is of type dateTime and compliant to > [RFC3339] and > > > [ISO.8601.1988]. > > > > > > > RFC 3339 specifically uses a subset of ISO.8601.1988. As this > > discussion illustrates it is possible to construct times that are > > compliant with the latter and non-compliant with the > former. I believe > > that ISO.8601.1988 is a superset of RFC 3339. If you wish > compliance > > with "both", my recommendation would be to specify only > ISO.8601.1988. > > This would meet Juergen's requirement of being able to specify an > > unqualified timezone. > > > > ALTERNATIVELY, you could require times to be in > ISO.8601.1988 format, as > > specified in Appendix A of RFC 3339. > > > > Pointing at two standards covering the precise same > specification is > > just asking for a poke in the eye. > > Good bureaucratic comment. Reading section 4.4 or RFC 3339, I should > probably shut up and be fine with requiring a timezone to be known by > a conforming device and then we can perhaps go with the RFC 3339 > subset. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 06:33:19 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB72628C1F7; Wed, 7 May 2008 06:33:19 -0700 (PDT) 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 69D323A70AE for ; Wed, 7 May 2008 06:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 iDa3sd-n+lpV for ; Wed, 7 May 2008 06:33:09 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 43DAB28C635 for ; Wed, 7 May 2008 06:31:31 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m47DUCN21597; Wed, 7 May 2008 13:30:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 May 2008 09:31:10 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4146E002D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4145E07E1@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues Thread-Index: AcimybQVJEZ5iqdXTweyEournL26jgABBQJgAfaRXuAAZ56j8A== References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com><4811C0B5.7010907@cisco.com> <20080425114407.GC19025@elstar.local> <002101c8a955$4e0565b0$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145E07E1@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: "David B Harrington" , , "Eliot Lear" Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi If there is no objection to option 2 then I will make the change and publish the updated draft. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Monday, May 05, 2008 8:06 AM To: David B Harrington; j.schoenwaelder@jacobs-university.de; Eliot Lear Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues Hi Just to close this off. It seems we are converging on not adding the ISO reference but just the RFC. (Note the RFC references the ISO specification and attempts to remove some ambiguities). Just to clarify what people want to do 1) Keep both references 2) Just have a reference to RFC3339 3) Just have a reference to RFC3339 section 4.4 and appendix A 4) Just have a reference to RFC3339 section 4.4 5) Just have a reference to RFC339 appendix A Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of David B Harrington Sent: Monday, April 28, 2008 1:28 PM To: j.schoenwaelder@jacobs-university.de; 'Eliot Lear' Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues I believe we should follow RFC3339 section 4.4 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Friday, April 25, 2008 7:44 AM > To: Eliot Lear > Cc: netconf@ietf.org > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > Issues > > On Fri, Apr 25, 2008 at 01:29:57PM +0200, Eliot Lear wrote: > > Hi Sharon, > > > > This comment is largely bureaucratic: > > > > > Proposed Edits > > > -------------- > > > > > > A. In section 2.1.1, for both instances and in section > 2.2.1 Replace > > > This parameter is of type dateTime. > > > With > > > This parameter is of type dateTime and compliant to > [RFC3339] and > > > [ISO.8601.1988]. > > > > > > > RFC 3339 specifically uses a subset of ISO.8601.1988. As this > > discussion illustrates it is possible to construct times that are > > compliant with the latter and non-compliant with the > former. I believe > > that ISO.8601.1988 is a superset of RFC 3339. If you wish > compliance > > with "both", my recommendation would be to specify only > ISO.8601.1988. > > This would meet Juergen's requirement of being able to specify an > > unqualified timezone. > > > > ALTERNATIVELY, you could require times to be in > ISO.8601.1988 format, as > > specified in Appendix A of RFC 3339. > > > > Pointing at two standards covering the precise same > specification is > > just asking for a poke in the eye. > > Good bureaucratic comment. Reading section 4.4 or RFC 3339, I should > probably shut up and be fine with requiring a timezone to be known by > a conforming device and then we can perhaps go with the RFC 3339 > subset. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 08:04:34 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D97728C699; Wed, 7 May 2008 08:04:34 -0700 (PDT) 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 3E1E828C68D for ; Wed, 7 May 2008 08:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.087, 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 PCxrQnlSvxvv for ; Wed, 7 May 2008 08:04:22 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 71E5F28C705 for ; Wed, 7 May 2008 08:02:10 -0700 (PDT) Received: (qmail 44802 invoked from network); 7 May 2008 15:02:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 7 May 2008 15:02:02 -0000 X-YMail-OSG: txgp320VM1nDV8r4zrq3AZiZhtd_DKEaU0MBzEk1XkeQerBeZPtluRchh0it9pW2ouo5nSyfkxfHUOqcjTLLH_LMF1_zXfkJBdVEp8ZejPA9vecBxkLbYgFZzO2zkndVy88- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4821C47E.7090207@andybierman.com> Date: Wed, 07 May 2008 08:02:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805071256.m47CuqLQ058310@idle.juniper.net> In-Reply-To: <200805071256.m47CuqLQ058310@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Wait -- there are no inline errors to generate for >> or , and there is no returned >> in , , or , which are the >> only RPCs that can generate inline errors. > > I gave a real-world example (ENOMEM while fetching statistics). > I'm no XSD dude, but doesn't the :any inside mean it can > contain anything, including ? > > Ah, nevermind. The RFC says: > > Negative Response: > > An element is included in the if the > request cannot be completed for any reason. > > So if I complete the RPC, I can't send an error. And since warnings > are encoded in elements, I can't do that either. So I > need to discard errors and warnings during the the processing of > the operation, if the operation succeeds, right? > > This means that warnings and (or ) can't live together, > which significantly reduces the value of warnings. > It was the WG's intent that NETCONF work this way. If is present, then there are no warnings to report. Warnings and data can be in the same reply, but the implementation may need to buffer the results. (I can't find any text that even suggests the WG was concerned about implementations that want to save some memory and never buffer results.) The PDUs have been in the From netconf-bounces@ietf.org Wed May 7 08:04:34 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D97728C699; Wed, 7 May 2008 08:04:34 -0700 (PDT) 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 3E1E828C68D for ; Wed, 7 May 2008 08:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.087, 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 PCxrQnlSvxvv for ; Wed, 7 May 2008 08:04:22 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 71E5F28C705 for ; Wed, 7 May 2008 08:02:10 -0700 (PDT) Received: (qmail 44802 invoked from network); 7 May 2008 15:02:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 7 May 2008 15:02:02 -0000 X-YMail-OSG: txgp320VM1nDV8r4zrq3AZiZhtd_DKEaU0MBzEk1XkeQerBeZPtluRchh0it9pW2ouo5nSyfkxfHUOqcjTLLH_LMF1_zXfkJBdVEp8ZejPA9vecBxkLbYgFZzO2zkndVy88- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4821C47E.7090207@andybierman.com> Date: Wed, 07 May 2008 08:02:22 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805071256.m47CuqLQ058310@idle.juniper.net> In-Reply-To: <200805071256.m47CuqLQ058310@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Wait -- there are no inline errors to generate for >> or , and there is no returned >> in , , or , which are the >> only RPCs that can generate inline errors. > > I gave a real-world example (ENOMEM while fetching statistics). > I'm no XSD dude, but doesn't the :any inside mean it can > contain anything, including ? > > Ah, nevermind. The RFC says: > > Negative Response: > > An element is included in the if the > request cannot be completed for any reason. > > So if I complete the RPC, I can't send an error. And since warnings > are encoded in elements, I can't do that either. So I > need to discard errors and warnings during the the processing of > the operation, if the operation succeeds, right? > > This means that warnings and (or ) can't live together, > which significantly reduces the value of warnings. > It was the WG's intent that NETCONF work this way. If is present, then there are no warnings to report. Warnings and data can be in the same reply, but the implementation may need to buffer the results. (I can't find any text that even suggests the WG was concerned about implementations that want to save some memory and never buffer results.) The PDUs have been in the same XSD sequence order since the start. The element was placed first so the manager would not have to receive the entire element before knowing it there were any errors or warnings. > Thanks, > Phil > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf same XSD sequence order since the start. The element was placed first so the manager would not have to receive the entire element before knowing it there were any errors or warnings. > Thanks, > Phil > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 09:15:52 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAFBC3A6D1A; Wed, 7 May 2008 09:15:50 -0700 (PDT) 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 EB1B928C211 for ; Wed, 7 May 2008 09:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 NYZKXQgpHBB2 for ; Wed, 7 May 2008 09:15:28 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 776A93A7146 for ; Wed, 7 May 2008 09:14:35 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m47GEQ715737; Wed, 7 May 2008 16:14:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 May 2008 12:14:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4146E05A3@zcarhxm2.corp.nortel.com> In-Reply-To: <200805061856.m46IuD46051592@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] xml declaration required or optional Thread-Index: Acivq/HdNQDxlyfYRsWkSqEmXRervQAsTlRw References: <48208FCB.5000409@andybierman.com> <200805061856.m46IuD46051592@idle.juniper.net> From: "Sharon Chisholm" To: "Phil Shafer" , "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi What is the conclusion here (other then we don't need yang after all ;-))? The element does not get sent when the elements is sent and we clarify the text in section 4.4 to say this? Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Tuesday, May 06, 2008 2:56 PM To: Andy Bierman Cc: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional Andy Bierman writes: >Are you saying nobody understood the examples either, and most of them >are wrong? I'm just saying that the document has some parts that show that we did a fairly poor job of polishing it. Claiming that the XSD is the will of the WG conflicts with saying that we need YANG because no one reads XSD. We used the "surprises" in the NETCONF XSD as an example that no one read it. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 09:15:52 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAFBC3A6D1A; Wed, 7 May 2008 09:15:50 -0700 (PDT) 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 EB1B928C211 for ; Wed, 7 May 2008 09:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 NYZKXQgpHBB2 for ; Wed, 7 May 2008 09:15:28 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 776A93A7146 for ; Wed, 7 May 2008 09:14:35 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m47GEQ715737; Wed, 7 May 2008 16:14:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 May 2008 12:14:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4146E05A3@zcarhxm2.corp.nortel.com> In-Reply-To: <200805061856.m46IuD46051592@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] xml declaration required or optional Thread-Index: Acivq/HdNQDxlyfYRsWkSqEmXRervQAsTlRw References: <48208FCB.5000409@andybierman.com> <200805061856.m46IuD46051592@idle.juniper.net> From: "Sharon Chisholm" To: "Phil Shafer" , "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi What is the conclusion here (other then we don't need yang after all ;-))? The element does not get sent when the elements is sent and we clarify the text in section 4.4 to say this? Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Tuesday, May 06, 2008 2:56 PM To: Andy Bierman Cc: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional Andy Bierman writes: >Are you saying nobody understood the examples either, and most of them >are wrong? I'm just saying that the document has some parts that show that we did a fairly poor job of polishing it. Claiming that the XSD is the will of the WG conflicts with saying that we need YANG because no one reads XSD. We used the "surprises" in the NETCONF XSD as an example that no one read it. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 09:40:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B823E28C670; Wed, 7 May 2008 09:40:54 -0700 (PDT) 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 1150128C23F for ; Wed, 7 May 2008 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 U+9rtk-+TsGN for ; Wed, 7 May 2008 09:40:42 -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 5460128C700 for ; Wed, 7 May 2008 09:35:45 -0700 (PDT) Received: (qmail 72424 invoked from network); 7 May 2008 16:35:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 7 May 2008 16:35:41 -0000 X-YMail-OSG: E6Krl.UVM1mkn060qpP4iShqF2KkuGbIhEX4s6upSkdxGKiH4P6mzi5mOz3YZZER4tSFSxzkS7xMVvFVbLZRiTveXUi6TnqLbBJBTo4xHK17nGIFoU3Zt6L48mu7wSgIMXg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4821DA7A.3080400@andybierman.com> Date: Wed, 07 May 2008 09:36:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <48208FCB.5000409@andybierman.com> <200805061856.m46IuD46051592@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B4146E05A3@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4146E05A3@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > What is the conclusion here (other then we don't need yang after all > ;-))? The element does not get sent when the elements is > sent and we clarify the text in section 4.4 to say this? > yes -- the 4.4 text needs to align with the XSD and examples. > Sharon Andy > > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Tuesday, May 06, 2008 2:56 PM > To: Andy Bierman > Cc: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org > Subject: Re: [Netconf] xml declaration required or optional > > Andy Bierman writes: >> Are you saying nobody understood the examples either, and most of them >> are wrong? > > I'm just saying that the document has some parts that show that we did a > fairly poor job of polishing it. Claiming that the XSD is the will of > the WG conflicts with saying that we need YANG because no one reads XSD. > We used the "surprises" in the NETCONF XSD as an example that no one > read it. > > Thanks, > Phil > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 09:40:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B823E28C670; Wed, 7 May 2008 09:40:54 -0700 (PDT) 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 1150128C23F for ; Wed, 7 May 2008 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 U+9rtk-+TsGN for ; Wed, 7 May 2008 09:40:42 -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 5460128C700 for ; Wed, 7 May 2008 09:35:45 -0700 (PDT) Received: (qmail 72424 invoked from network); 7 May 2008 16:35:43 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 7 May 2008 16:35:41 -0000 X-YMail-OSG: E6Krl.UVM1mkn060qpP4iShqF2KkuGbIhEX4s6upSkdxGKiH4P6mzi5mOz3YZZER4tSFSxzkS7xMVvFVbLZRiTveXUi6TnqLbBJBTo4xHK17nGIFoU3Zt6L48mu7wSgIMXg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4821DA7A.3080400@andybierman.com> Date: Wed, 07 May 2008 09:36:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <48208FCB.5000409@andybierman.com> <200805061856.m46IuD46051592@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B4146E05A3@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4146E05A3@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > What is the conclusion here (other then we don't need yang after all > ;-))? The element does not get sent when the elements is > sent and we clarify the text in section 4.4 to say this? > yes -- the 4.4 text needs to align with the XSD and examples. > Sharon Andy > > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Tuesday, May 06, 2008 2:56 PM > To: Andy Bierman > Cc: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org > Subject: Re: [Netconf] xml declaration required or optional > > Andy Bierman writes: >> Are you saying nobody understood the examples either, and most of them >> are wrong? > > I'm just saying that the document has some parts that show that we did a > fairly poor job of polishing it. Claiming that the XSD is the will of > the WG conflicts with saying that we need YANG because no one reads XSD. > We used the "surprises" in the NETCONF XSD as an example that no one > read it. > > Thanks, > Phil > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 12:12:27 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE0E3A6C02; Wed, 7 May 2008 12:12:27 -0700 (PDT) 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 9A4AB3A6D82 for ; Wed, 7 May 2008 12:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 j9RmAOcvVH8Y for ; Wed, 7 May 2008 12:12:24 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id E66123A6B43 for ; Wed, 7 May 2008 12:12:22 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Wed, 07 May 2008 12:12:03 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 12:12: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 m47JCFx81507; Wed, 7 May 2008 12:12: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 m47JAU5w061218; Wed, 7 May 2008 19:10:30 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805071910.m47JAU5w061218@idle.juniper.net> To: Andy Bierman In-reply-to: <4821C47E.7090207@andybierman.com> Date: Wed, 07 May 2008 15:10:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 May 2008 19:12:15.0709 (UTC) FILETIME=[430500D0:01C8B076] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >Warnings and data can be in the same reply, but the implementation >may need to buffer the results. No, since an means the operation did not complete. Warnings are in s, so this applies to them as well. >(I can't find any text that even >suggests the WG was concerned about implementations that >want to save some memory and never buffer results.) We discussed it on the mailing list enough times. I see configs in the >50MB range. Bufferings not a reasonably solution. >The element was placed first so the manager would not >have to receive the entire element before knowing >it there were any errors or warnings. Are you saying that buffering's an issue for the manager, but not for the agent? That seems exactly backwards. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 12:12:27 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE0E3A6C02; Wed, 7 May 2008 12:12:27 -0700 (PDT) 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 9A4AB3A6D82 for ; Wed, 7 May 2008 12:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 j9RmAOcvVH8Y for ; Wed, 7 May 2008 12:12:24 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id E66123A6B43 for ; Wed, 7 May 2008 12:12:22 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Wed, 07 May 2008 12:12:03 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 12:12: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 m47JCFx81507; Wed, 7 May 2008 12:12: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 m47JAU5w061218; Wed, 7 May 2008 19:10:30 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200805071910.m47JAU5w061218@idle.juniper.net> To: Andy Bierman In-reply-to: <4821C47E.7090207@andybierman.com> Date: Wed, 07 May 2008 15:10:29 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 May 2008 19:12:15.0709 (UTC) FILETIME=[430500D0:01C8B076] Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman writes: >Warnings and data can be in the same reply, but the implementation >may need to buffer the results. No, since an means the operation did not complete. Warnings are in s, so this applies to them as well. >(I can't find any text that even >suggests the WG was concerned about implementations that >want to save some memory and never buffer results.) We discussed it on the mailing list enough times. I see configs in the >50MB range. Bufferings not a reasonably solution. >The element was placed first so the manager would not >have to receive the entire element before knowing >it there were any errors or warnings. Are you saying that buffering's an issue for the manager, but not for the agent? That seems exactly backwards. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 13:51:18 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6923A6B27; Wed, 7 May 2008 13:51:18 -0700 (PDT) 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 C34343A6AA3 for ; Wed, 7 May 2008 13:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.087, 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 mlViMAdZnVb8 for ; Wed, 7 May 2008 13:51:16 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 363A73A67F5 for ; Wed, 7 May 2008 13:51:12 -0700 (PDT) Received: (qmail 54643 invoked from network); 7 May 2008 20:51:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 7 May 2008 20:51:07 -0000 X-YMail-OSG: 7fjMlWYVM1my1VG2qYaGaK6OSrxPEh6LMjNT3vI6JppOPm5kk_.d5FjvMbqRJubbslAjHKMnkwVjV0SQM8QigzI7VriU8hquxIwdoGLwIhY6M2k4teukzWCwHV7TfmLcGEg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4822166A.5090902@andybierman.com> Date: Wed, 07 May 2008 13:51:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805071910.m47JAU5w061218@idle.juniper.net> In-Reply-To: <200805071910.m47JAU5w061218@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Warnings and data can be in the same reply, but the implementation >> may need to buffer the results. > > No, since an means the operation did not complete. > Warnings are in s, so this applies to them as well. > Any warnings would be proprietary, since there are only standard errors defined so far. What if the operation did complete, but some strings were truncated, etc.? This is a gray area where it is not clear what it means for the operation to complete. >> (I can't find any text that even >> suggests the WG was concerned about implementations that >> want to save some memory and never buffer results.) > > We discussed it on the mailing list enough times. I see > configs in the >50MB range. Bufferings not a reasonably > solution. > >> The element was placed first so the manager would not >> have to receive the entire element before knowing >> it there were any errors or warnings. > > Are you saying that buffering's an issue for the manager, but > not for the agent? That seems exactly backwards. > I'm saying, the XSD has this order (AFAIK) because it was perceived as better for the manager to know up-front if the element was 'tainted' in any way. The XSD is clear on the structure on the . You could embed or or whatever you want in your element, but a compliant implementation needs to follow the XSD structure for standard errors and standard operations. > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 7 13:51:18 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6923A6B27; Wed, 7 May 2008 13:51:18 -0700 (PDT) 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 C34343A6AA3 for ; Wed, 7 May 2008 13:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.087, 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 mlViMAdZnVb8 for ; Wed, 7 May 2008 13:51:16 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 363A73A67F5 for ; Wed, 7 May 2008 13:51:12 -0700 (PDT) Received: (qmail 54643 invoked from network); 7 May 2008 20:51:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 7 May 2008 20:51:07 -0000 X-YMail-OSG: 7fjMlWYVM1my1VG2qYaGaK6OSrxPEh6LMjNT3vI6JppOPm5kk_.d5FjvMbqRJubbslAjHKMnkwVjV0SQM8QigzI7VriU8hquxIwdoGLwIhY6M2k4teukzWCwHV7TfmLcGEg- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4822166A.5090902@andybierman.com> Date: Wed, 07 May 2008 13:51:54 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Phil Shafer References: <200805071910.m47JAU5w061218@idle.juniper.net> In-Reply-To: <200805071910.m47JAU5w061218@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> Warnings and data can be in the same reply, but the implementation >> may need to buffer the results. > > No, since an means the operation did not complete. > Warnings are in s, so this applies to them as well. > Any warnings would be proprietary, since there are only standard errors defined so far. What if the operation did complete, but some strings were truncated, etc.? This is a gray area where it is not clear what it means for the operation to complete. >> (I can't find any text that even >> suggests the WG was concerned about implementations that >> want to save some memory and never buffer results.) > > We discussed it on the mailing list enough times. I see > configs in the >50MB range. Bufferings not a reasonably > solution. > >> The element was placed first so the manager would not >> have to receive the entire element before knowing >> it there were any errors or warnings. > > Are you saying that buffering's an issue for the manager, but > not for the agent? That seems exactly backwards. > I'm saying, the XSD has this order (AFAIK) because it was perceived as better for the manager to know up-front if the element was 'tainted' in any way. The XSD is clear on the structure on the . You could embed or or whatever you want in your element, but a compliant implementation needs to follow the XSD structure for standard errors and standard operations. > Thanks, > Phil > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 08:34:10 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348B028D0BE; Thu, 8 May 2008 08:33:42 -0700 (PDT) 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 4CBDB3A72AC for ; Thu, 8 May 2008 08:33:04 -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 5Nyh7WVDCSrM for ; Thu, 8 May 2008 08:33:01 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id BE23E28C957 for ; Thu, 8 May 2008 06:28:21 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id NzyK1Z0050lTkoCA101R00; Thu, 08 May 2008 12:12:50 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id P0Co1Z0024HwxpC8Q00000; Thu, 08 May 2008 12:12:50 +0000 X-Authority-Analysis: v=1.0 c=1 a=EF4BHCKjP-MA:10 a=tIpjoOZtNw8A:10 a=1Xbv47itDCCaGSmE18MA:9 a=b28R0inagYt9FcgoVkT7NQ3TMbgA:4 a=gJcimI5xSWUA:10 From: "David Harrington" To: , "'Phil Shafer'" References: <20080506084830.GE29870@elstar.local><200805061532.m46FWh8I049905@idle.juniper.net> <20080506180440.GE1654@elstar.local> Date: Thu, 8 May 2008 08:12:47 -0400 Message-ID: <03b001c8b104$d5ae3ad0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080506180440.GE1654@elstar.local> Thread-Index: Acivo8Fx5kHSuHjzTqegec0X4TW/EQBYLFxw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > > XMLDecls are always optional, per REC-xml: > > > > [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? Oh, of course! It is right there in plain text; how could we have missed that? ;-) (just ignore me) I think it would be helpful to make it clear whether it is REQUIRED or RECOMMENDED or MAY be present in Netconf, for purposes of interoperability. dbh _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 08:34:11 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348B028D0BE; Thu, 8 May 2008 08:33:42 -0700 (PDT) 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 4CBDB3A72AC for ; Thu, 8 May 2008 08:33:04 -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 5Nyh7WVDCSrM for ; Thu, 8 May 2008 08:33:01 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id BE23E28C957 for ; Thu, 8 May 2008 06:28:21 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id NzyK1Z0050lTkoCA101R00; Thu, 08 May 2008 12:12:50 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id P0Co1Z0024HwxpC8Q00000; Thu, 08 May 2008 12:12:50 +0000 X-Authority-Analysis: v=1.0 c=1 a=EF4BHCKjP-MA:10 a=tIpjoOZtNw8A:10 a=1Xbv47itDCCaGSmE18MA:9 a=b28R0inagYt9FcgoVkT7NQ3TMbgA:4 a=gJcimI5xSWUA:10 From: "David Harrington" To: , "'Phil Shafer'" References: <20080506084830.GE29870@elstar.local><200805061532.m46FWh8I049905@idle.juniper.net> <20080506180440.GE1654@elstar.local> Date: Thu, 8 May 2008 08:12:47 -0400 Message-ID: <03b001c8b104$d5ae3ad0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080506180440.GE1654@elstar.local> Thread-Index: Acivo8Fx5kHSuHjzTqegec0X4TW/EQBYLFxw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > > XMLDecls are always optional, per REC-xml: > > > > [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? Oh, of course! It is right there in plain text; how could we have missed that? ;-) (just ignore me) I think it would be helpful to make it clear whether it is REQUIRED or RECOMMENDED or MAY be present in Netconf, for purposes of interoperability. dbh _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 08:34:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C57228D1B4; Thu, 8 May 2008 08:34:24 -0700 (PDT) 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 8BFF828C818 for ; Thu, 8 May 2008 08:33:44 -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 Q903sfYLVwWK for ; Thu, 8 May 2008 08:33:43 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id E2EE628C57C for ; Thu, 8 May 2008 06:22:31 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id NymW1Z0030mlR8UA905J00; Thu, 08 May 2008 12:06:49 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id P06w1Z0034HwxpC8X00000; Thu, 08 May 2008 12:06:58 +0000 X-Authority-Analysis: v=1.0 c=1 a=gUh9XYFHhvcA:10 a=lAxoPsH8wAIA:10 a=48vgC7mUAAAA:8 a=mfR3L9wEfcTzCE6CzPIA:9 a=FjFy1qd3BcZoUzOVkt4A:7 a=-t_JpUxUJrjCJi5gieKMee5n-fMA:4 a=jFPUFpGHtmAA:10 a=lZB815dzVvQA:10 a=ZPn7O4N2MpQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Sharon Chisholm'" , References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> Date: Thu, 8 May 2008 08:06:55 -0400 Message-ID: <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aciw4IFjOyntNgDYSTSln6u1gc8eAQAHolYQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I am NOT OK with option A. Notifications in syslog and in SNMP are normally sent to an application, which filters and aggregates the notifications. Such an application might alert an operator to important notifications, but many just get logged for later analysis. With the MUST formulation in option A, it becomes a protocol REQUIREMENT that such application/users CANNOT receive notifications UNLESS that application is also allowed to perform other Netconf operations. Syslog and SNMP do not contain such a crappy little rule; Administrators can decide that syslog notifications and/or SNMP notifications can be sent to a principal that has no other permissions within syslog or SNMP. But if the operator decides to have syslog or SNMP information carried over Nertconf, then they MUST give the receiving principal permission to use some other Netconf operation. WHY do we need to allow such an application to perform other Netconf operations? It should be an administrative policy decision to allow notifications to be sent to a principal that has no other operational permission in Netconf. I don't like option B simply because I don't like the way it has been worded. I suggest: Proposed Text (C) "The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. It is an administrative policy decision to determine who (or what) is authorized to have access to the information contained in notifications. It is RECOMMENDED that if a user is not authorized to view the content in the notification via other Newtconf operations, then they SHOULD NOT be authorized to have access to that content via Netconf notifications. If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." dbh > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > Sent: Thursday, May 08, 2008 3:53 AM > To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; > netconf@ietf.org > Subject: RE: [Netconf] Issue X: access to notification content > > I am OK with option/proposal A > > Bert Wijnen > > > -----Oorspronkelijk bericht----- > > Van: Sharon Chisholm [mailto:schishol@nortel.com] > > Verzonden: woensdag 7 mei 2008 15:30 > > Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Onderwerp: RE: [Netconf] Issue X: access to notification content > > > > > > Hi > > > > If there is no objection to proposal A then I will proceed > to make this > > change and publish the updated draft. > > > > Sharon > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of Chisholm, Sharon (CAR:ZZ00) > > Sent: Monday, May 05, 2008 8:33 AM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: Re: [Netconf] Issue X: access to notification content > > > > Hi > > > > I think it would be helpful to go back to original text we > are editing > > rather then the snippets. I've modified the second sentence > in ways that > > I think address the access versus authorization confusion > and I think > > makes it so we can keep the 'must not'. I think now we don't need to > > 'depending on access control..." part because we are make a > > recommendation about the access control in order to maintain minimal > > security. I've added a third option which tries to include those for > > comparison. I prefer A. > > > > Current text > > > > The contents of notifications as well as the name of event streams > > may contain sensitive information and care should be > taken to ensure > > that it is viewed only by authorized users. If a user > does not have > > permission to view content via other NETCONF operations, > she must not > > have access to that content via Notifications. If a user is not > > permitted to view one element in the content of the > notification, the > > notification is not sent to that user. > > > > Proposed text (A) > > > > The contents of notifications as well as the name of event streams > > may contain sensitive information and care should be > taken to ensure > > that it is viewed only by authorized users. If a user > does not have > > permission to view the information in the notification, > they must not > > have access to that content via Notifications. If a user is not > > permitted to view one element in the content of the > notification, the > > notification is not sent to that user. > > > > Proposed text (B) > > > > The contents of notifications as well as the name of event streams > > may contain sensitive information and care should be > taken to ensure > > that it is viewed only by authorized users. If a user > does not have > > permission to view the information in the notification, > the access > > control model and administrative policy probably should not > > allow them access to that content via Notifications. If > a user is > > not > > permitted to view one element in the content of the > notification, the > > notification is not sent to that user. > > > > I also got rid of the 'she' thing since I think the singular use of > > 'they' is now grammatically acceptable in these cases. > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Friday, May 02, 2008 1:41 PM > > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > > > > > > -----Original Message----- > > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > > Sent: Friday, May 02, 2008 11:22 AM > > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > By proposed text, did you mean: > > > > > > "she probably should not ... depending on the access control model > > and > > > administrative policy." > > > > > > Which I proposed to change to > > > > > > "she likely will not ... depending on the access control > model and > > > administrative policy." > > > > That is not what your earlier response said. The proposal in your > > response did not include the text after the ellipsis. > > > > I prefer "she probably should not" because "should not" is RFC2119 > > language. > > You might want to stiffen that slightly by making it "she probably > > SHOULD NOT ... depending on the access control model and > administrative > > policy." > > > > > > > > Sharon > > > > > > -----Original Message----- > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > Sent: Wednesday, April 30, 2008 5:53 PM > > > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > > > netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Hi, > > > > > > I don't think your proposed change addresses the security review > > > concern. It doesn't say how access will be controlled. > > > > > > I think my proposed text does, by saying it will be > handled by the > > > access control model and adminstrative policy. > > > > > > Is there a reason you don't find my proposed text acceptable? > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > > > Sent: Wednesday, April 30, 2008 2:39 PM > > > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > > > Subject: RE: Issue X: access to notification content > > > > > > > > Hi > > > > > > > > I can change from "she must not" to "she likely will > not". I think > > > the > > > > probably softens things too much. The intent is that you > > > only get to > > > > view content you have permission to view, regardless of > the access > > > > > > mechanisms. > > > > > > > > Sharon > > > > > > > > -----Original Message----- > > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > > Sent: Tuesday, April 29, 2008 10:25 AM > > > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > > > netconf@ietf.org > > > > Subject: RE: Issue X: access to notification content > > > > > > > > Hi, > > > > > > > > If it is only a discussion, then I suggest rewording > "she must not > > > > > > ..." > > > > to "she probably should not ... depending on the access control > > > model > > > > and administrative policy." > > > > > > > > This does not create a CLR. > > > > > > > > dbh > > > > > > > > > -----Original Message----- > > > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > > > Subject: RE: Issue X: access to notification content > > > > > > > > > > Dave, this is a clarification to an concern from an > IESG member. > > > > > It is in the "Security Considerations" section, so it is > > > > not a "hard > > > > > choice of protocol standard". We are explaining in > the security > > > > > considerations section what kind of access concerns > there might > > > be. > > > > > Does that clarify? > > > > > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > > > > > Bert Wijnen > > > > > > > > > > > -----Oorspronkelijk bericht----- > > > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > > > Verzonden: maandag 28 april 2008 19:28 > > > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; > netconf@ietf.org > > > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > > > > > > > Hi bert, > > > > > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > > > Sharon just > > > > > > didn't understand and didn't fix. here's one: > > > > > > > > > > > > -- > > > > > > In section 7, the text says "If a user does not have > > > > > > permission to view content via other NETCONF operations, > > she > > > > must > > > > > > not > > > > > > have access to that content via Notifications." > > > > > > > > > > > > This creates a big CLR. > > > > > > > > > > > > Can content from a syslog or SNMP notification stream be > > > > sent to a > > > > > > user that does not have permission to access the syslog or > > SNMP > > > > > > content using some other Netconf operation? What > other Netconf > > > > > > > > operation works with the syslog stream? Didn't we > > > > > explicitly decide it > > > > > > was not necessary to support access to notication > > streams > > > > > > (including syslog and SNMP streams)? > > > > > > > > > > > > I am also concerned that this access control "policy" > > > > should be an > > > > > > administrative one, not a hard choice of the protocol > > > > standard. In > > > > > > most cases it is the right choice. But a NOC manager > > > > might want to > > > > > > allow, say, the helpdesk to be alerted whenever a Netconf > > config > > > > is > > > > > > being changed, or an intrusion detection application to > > > > be alerted > > > > > > when there is an authentication failure. And yet, they may > > > > > not want to > > > > > > give the helpdesk or the IDS permissions. > With this CLR, > > a > > > > NOC > > > > > > manager is simply not allowed to make such a decision. > > > > > > > > > > > > I understand the intent; I think the wording is > poorly chosen, > > > > > > > > especially because it uses a "must", which has special > > > > > RFC2119 meaning > > > > > > and creates a huge CLR. And since access control will be > > > > > done later, I > > > > > > don't think the WG wants this CLR constraining all future > > > > > AC designs. > > > > > > > > > > > > But I could be wrong; maybe the WG will decide this > is exactly > > > > what > > > > > > they want to say. If that is the case, then I think we need > > > > > to review > > > > > > this document to make sure everything else (like syslog > > streams) > > > > can > > > > > > work with this CLR. > > > > > > > > > > > > dbh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 08:34:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C57228D1B4; Thu, 8 May 2008 08:34:24 -0700 (PDT) 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 8BFF828C818 for ; Thu, 8 May 2008 08:33:44 -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 Q903sfYLVwWK for ; Thu, 8 May 2008 08:33:43 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id E2EE628C57C for ; Thu, 8 May 2008 06:22:31 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id NymW1Z0030mlR8UA905J00; Thu, 08 May 2008 12:06:49 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id P06w1Z0034HwxpC8X00000; Thu, 08 May 2008 12:06:58 +0000 X-Authority-Analysis: v=1.0 c=1 a=gUh9XYFHhvcA:10 a=lAxoPsH8wAIA:10 a=48vgC7mUAAAA:8 a=mfR3L9wEfcTzCE6CzPIA:9 a=FjFy1qd3BcZoUzOVkt4A:7 a=-t_JpUxUJrjCJi5gieKMee5n-fMA:4 a=jFPUFpGHtmAA:10 a=lZB815dzVvQA:10 a=ZPn7O4N2MpQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Sharon Chisholm'" , References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> Date: Thu, 8 May 2008 08:06:55 -0400 Message-ID: <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aciw4IFjOyntNgDYSTSln6u1gc8eAQAHolYQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I am NOT OK with option A. Notifications in syslog and in SNMP are normally sent to an application, which filters and aggregates the notifications. Such an application might alert an operator to important notifications, but many just get logged for later analysis. With the MUST formulation in option A, it becomes a protocol REQUIREMENT that such application/users CANNOT receive notifications UNLESS that application is also allowed to perform other Netconf operations. Syslog and SNMP do not contain such a crappy little rule; Administrators can decide that syslog notifications and/or SNMP notifications can be sent to a principal that has no other permissions within syslog or SNMP. But if the operator decides to have syslog or SNMP information carried over Nertconf, then they MUST give the receiving principal permission to use some other Netconf operation. WHY do we need to allow such an application to perform other Netconf operations? It should be an administrative policy decision to allow notifications to be sent to a principal that has no other operational permission in Netconf. I don't like option B simply because I don't like the way it has been worded. I suggest: Proposed Text (C) "The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. It is an administrative policy decision to determine who (or what) is authorized to have access to the information contained in notifications. It is RECOMMENDED that if a user is not authorized to view the content in the notification via other Newtconf operations, then they SHOULD NOT be authorized to have access to that content via Netconf notifications. If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." dbh > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > Sent: Thursday, May 08, 2008 3:53 AM > To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; > netconf@ietf.org > Subject: RE: [Netconf] Issue X: access to notification content > > I am OK with option/proposal A > > Bert Wijnen > > > -----Oorspronkelijk bericht----- > > Van: Sharon Chisholm [mailto:schishol@nortel.com] > > Verzonden: woensdag 7 mei 2008 15:30 > > Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Onderwerp: RE: [Netconf] Issue X: access to notification content > > > > > > Hi > > > > If there is no objection to proposal A then I will proceed > to make this > > change and publish the updated draft. > > > > Sharon > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of Chisholm, Sharon (CAR:ZZ00) > > Sent: Monday, May 05, 2008 8:33 AM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: Re: [Netconf] Issue X: access to notification content > > > > Hi > > > > I think it would be helpful to go back to original text we > are editing > > rather then the snippets. I've modified the second sentence > in ways that > > I think address the access versus authorization confusion > and I think > > makes it so we can keep the 'must not'. I think now we don't need to > > 'depending on access control..." part because we are make a > > recommendation about the access control in order to maintain minimal > > security. I've added a third option which tries to include those for > > comparison. I prefer A. > > > > Current text > > > > The contents of notifications as well as the name of event streams > > may contain sensitive information and care should be > taken to ensure > > that it is viewed only by authorized users. If a user > does not have > > permission to view content via other NETCONF operations, > she must not > > have access to that content via Notifications. If a user is not > > permitted to view one element in the content of the > notification, the > > notification is not sent to that user. > > > > Proposed text (A) > > > > The contents of notifications as well as the name of event streams > > may contain sensitive information and care should be > taken to ensure > > that it is viewed only by authorized users. If a user > does not have > > permission to view the information in the notification, > they must not > > have access to that content via Notifications. If a user is not > > permitted to view one element in the content of the > notification, the > > notification is not sent to that user. > > > > Proposed text (B) > > > > The contents of notifications as well as the name of event streams > > may contain sensitive information and care should be > taken to ensure > > that it is viewed only by authorized users. If a user > does not have > > permission to view the information in the notification, > the access > > control model and administrative policy probably should not > > allow them access to that content via Notifications. If > a user is > > not > > permitted to view one element in the content of the > notification, the > > notification is not sent to that user. > > > > I also got rid of the 'she' thing since I think the singular use of > > 'they' is now grammatically acceptable in these cases. > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Friday, May 02, 2008 1:41 PM > > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > > > > > > -----Original Message----- > > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > > Sent: Friday, May 02, 2008 11:22 AM > > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > By proposed text, did you mean: > > > > > > "she probably should not ... depending on the access control model > > and > > > administrative policy." > > > > > > Which I proposed to change to > > > > > > "she likely will not ... depending on the access control > model and > > > administrative policy." > > > > That is not what your earlier response said. The proposal in your > > response did not include the text after the ellipsis. > > > > I prefer "she probably should not" because "should not" is RFC2119 > > language. > > You might want to stiffen that slightly by making it "she probably > > SHOULD NOT ... depending on the access control model and > administrative > > policy." > > > > > > > > Sharon > > > > > > -----Original Message----- > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > Sent: Wednesday, April 30, 2008 5:53 PM > > > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > > > netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Hi, > > > > > > I don't think your proposed change addresses the security review > > > concern. It doesn't say how access will be controlled. > > > > > > I think my proposed text does, by saying it will be > handled by the > > > access control model and adminstrative policy. > > > > > > Is there a reason you don't find my proposed text acceptable? > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > > > Sent: Wednesday, April 30, 2008 2:39 PM > > > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > > > Subject: RE: Issue X: access to notification content > > > > > > > > Hi > > > > > > > > I can change from "she must not" to "she likely will > not". I think > > > the > > > > probably softens things too much. The intent is that you > > > only get to > > > > view content you have permission to view, regardless of > the access > > > > > > mechanisms. > > > > > > > > Sharon > > > > > > > > -----Original Message----- > > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > > Sent: Tuesday, April 29, 2008 10:25 AM > > > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > > > netconf@ietf.org > > > > Subject: RE: Issue X: access to notification content > > > > > > > > Hi, > > > > > > > > If it is only a discussion, then I suggest rewording > "she must not > > > > > > ..." > > > > to "she probably should not ... depending on the access control > > > model > > > > and administrative policy." > > > > > > > > This does not create a CLR. > > > > > > > > dbh > > > > > > > > > -----Original Message----- > > > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > > > Subject: RE: Issue X: access to notification content > > > > > > > > > > Dave, this is a clarification to an concern from an > IESG member. > > > > > It is in the "Security Considerations" section, so it is > > > > not a "hard > > > > > choice of protocol standard". We are explaining in > the security > > > > > considerations section what kind of access concerns > there might > > > be. > > > > > Does that clarify? > > > > > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > > > > > Bert Wijnen > > > > > > > > > > > -----Oorspronkelijk bericht----- > > > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > > > Verzonden: maandag 28 april 2008 19:28 > > > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; > netconf@ietf.org > > > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > > > > > > > Hi bert, > > > > > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > > > Sharon just > > > > > > didn't understand and didn't fix. here's one: > > > > > > > > > > > > -- > > > > > > In section 7, the text says "If a user does not have > > > > > > permission to view content via other NETCONF operations, > > she > > > > must > > > > > > not > > > > > > have access to that content via Notifications." > > > > > > > > > > > > This creates a big CLR. > > > > > > > > > > > > Can content from a syslog or SNMP notification stream be > > > > sent to a > > > > > > user that does not have permission to access the syslog or > > SNMP > > > > > > content using some other Netconf operation? What > other Netconf > > > > > > > > operation works with the syslog stream? Didn't we > > > > > explicitly decide it > > > > > > was not necessary to support access to notication > > streams > > > > > > (including syslog and SNMP streams)? > > > > > > > > > > > > I am also concerned that this access control "policy" > > > > should be an > > > > > > administrative one, not a hard choice of the protocol > > > > standard. In > > > > > > most cases it is the right choice. But a NOC manager > > > > might want to > > > > > > allow, say, the helpdesk to be alerted whenever a Netconf > > config > > > > is > > > > > > being changed, or an intrusion detection application to > > > > be alerted > > > > > > when there is an authentication failure. And yet, they may > > > > > not want to > > > > > > give the helpdesk or the IDS permissions. > With this CLR, > > a > > > > NOC > > > > > > manager is simply not allowed to make such a decision. > > > > > > > > > > > > I understand the intent; I think the wording is > poorly chosen, > > > > > > > > especially because it uses a "must", which has special > > > > > RFC2119 meaning > > > > > > and creates a huge CLR. And since access control will be > > > > > done later, I > > > > > > don't think the WG wants this CLR constraining all future > > > > > AC designs. > > > > > > > > > > > > But I could be wrong; maybe the WG will decide this > is exactly > > > > what > > > > > > they want to say. If that is the case, then I think we need > > > > > to review > > > > > > this document to make sure everything else (like syslog > > streams) > > > > can > > > > > > work with this CLR. > > > > > > > > > > > > dbh > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 09:11:18 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EC0628CB82; Thu, 8 May 2008 09:11:18 -0700 (PDT) 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 E3BE328CB8E for ; Thu, 8 May 2008 09:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 lSGAL3NeXhAn for ; Thu, 8 May 2008 09:11:02 -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 34E593A72C6 for ; Thu, 8 May 2008 08:51:49 -0700 (PDT) Received: (qmail 26227 invoked from network); 8 May 2008 15:51:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2008 15:51:45 -0000 X-YMail-OSG: CBcVkUEVM1n8.RSEoJphRm7TOgZ_NxlTITkIHVdBxflyzt_S0SvmOETeWxUotUoSVYGXE2OKO04L7mS.h.32CxuVVmLTUYOmxCKl2Dird1VPd1WQkdWOtObhhcAfnJT7lHs33y5Z.7Z_7BylVDsEYX76 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48232185.9020109@andybierman.com> Date: Thu, 08 May 2008 08:51:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David B Harrington References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> In-Reply-To: <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > Hi, > I agree with Dave's concerns, and support his option (C) text. I don't even see what other NETCONF operations have to do with a notification receiver application. I don't agree that any additional security is provided by this MUST requirement. When user A attempts NETCONF operation , the agent will authorize the RPC operation at that time. Why would the agent even check if would be authorized in the future, when the user requests operation ? I don't know much about security, but it seems to be a total waste of time to do this. Andy > I am NOT OK with option A. Notifications in syslog and in SNMP are > normally sent to an application, which filters and aggregates the > notifications. Such an application might alert an operator to > important notifications, but many just get logged for later analysis. > > With the MUST formulation in option A, it becomes a protocol > REQUIREMENT that such application/users CANNOT receive notifications > UNLESS that application is also allowed to perform other Netconf > operations. > > Syslog and SNMP do not contain such a crappy little rule; > Administrators can decide that syslog notifications andFrom netconf-bounces@ietf.org Thu May 8 09:11:18 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EC0628CB82; Thu, 8 May 2008 09:11:18 -0700 (PDT) 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 E3BE328CB8E for ; Thu, 8 May 2008 09:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 lSGAL3NeXhAn for ; Thu, 8 May 2008 09:11:02 -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 34E593A72C6 for ; Thu, 8 May 2008 08:51:49 -0700 (PDT) Received: (qmail 26227 invoked from network); 8 May 2008 15:51:47 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2008 15:51:45 -0000 X-YMail-OSG: CBcVkUEVM1n8.RSEoJphRm7TOgZ_NxlTITkIHVdBxflyzt_S0SvmOETeWxUotUoSVYGXE2OKO04L7mS.h.32CxuVVmLTUYOmxCKl2Dird1VPd1WQkdWOtObhhcAfnJT7lHs33y5Z.7Z_7BylVDsEYX76 X-Yahoo-Newman-Property: ymail-3 Message-ID: <48232185.9020109@andybierman.com> Date: Thu, 08 May 2008 08:51:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David B Harrington References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> In-Reply-To: <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > Hi, > I agree with Dave's concerns, and support his option (C) text. I don't even see what other NETCONF operations have to do with a notification receiver application. I don't agree that any additional security is provided by this MUST requirement. When user A attempts NETCONF operation , the agent will authorize the RPC operation at that time. Why would the agent even check if would be authorized in the future, when the user requests operation ? I don't know much about security, but it seems to be a total waste of time to do this. Andy > I am NOT OK with option A. Notifications in syslog and in SNMP are > normally sent to an application, which filters and aggregates the > notifications. Such an application might alert an operator to > important notifications, but many just get logged for later analysis. > > With the MUST formulation in option A, it becomes a protocol > REQUIREMENT that such application/users CANNOT receive notifications > UNLESS that application is also allowed to perform other Netconf > operations. > > Syslog and SNMP do not contain such a crappy little rule; > Administrators can decide that syslog notifications and/or SN/or SNMP > notifications can be sent to a principal that has no other permissions > within syslog or SNMP. But if the operator decides to have syslog or > SNMP information carried over Nertconf, then they MUST give the > receiving principal permission to use some other Netconf operation. > > WHY do we need to allow such an application to perform other Netconf > operations? It should be an administrative policy decision to allow > notifications to be sent to a principal that has no other operational > permission in Netconf. > > I don't like option B simply because I don't like the way it has been > worded. I suggest: > > Proposed Text (C) > > "The contents of notifications as well as the names of event streams > may contain sensitive information and care should be taken to ensure > that they are viewed only by authorized users. It is an administrative > policy decision to determine who (or what) is authorized to have > access to the information contained in notifications. It is > RECOMMENDED that if a user is not authorized to view the content in > the notification via other Newtconf operations, then they SHOULD NOT > be authorized to have access to that content via Netconf > notifications. If a user is not authorized to view all elements in the > content of the notification, the notification is not sent to that > user." > > dbh > >> -----Original Message----- >> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >> Sent: Thursday, May 08, 2008 3:53 AM >> To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; >> netconf@ietf.org >> Subject: RE: [Netconf] Issue X: access to notification content >> >> I am OK with option/proposal A >> >> Bert Wijnen >> >>> -----Oorspronkelijk bericht----- >>> Van: Sharon Chisholm [mailto:schishol@nortel.com] >>> Verzonden: woensdag 7 mei 2008 15:30 >>> Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>> Onderwerp: RE: [Netconf] Issue X: access to notification content >>> >>> >>> Hi >>> >>> If there is no objection to proposal A then I will proceed >> to make this >>> change and publish the updated draft. >>> >>> Sharon >>> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > On >>> Behalf Of Chisholm, Sharon (CAR:ZZ00) >>> Sent: Monday, May 05, 2008 8:33 AM >>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>> Subject: Re: [Netconf] Issue X: access to notification content >>> >>> Hi >>> >>> I think it would be helpful to go back to original text we >> are editing >>> rather then the snippets. I've modified the second sentence >> in ways that >>> I think address the access versus authorization confusion >> and I think >>> makes it so we can keep the 'must not'. I think now we don't need > to >>> 'depending on access control..." part because we are make a >>> recommendation about the access control in order to maintain > minimal >>> security. I've added a third option which tries to include those > for >>> comparison. I prefer A. >>> >>> Current text >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view content via other NETCONF operations, >> she must not >>> have access to that content via Notifications. If a user is > not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> Proposed text (A) >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view the information in the notification, >> they must not >>> have access to that content via Notifications. If a user is > not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>MP > notifications can be sent to a principal that has no other permissions > within syslog or SNMP. But if the operator decides to have syslog or > SNMP information carried over Nertconf, then they MUST give the > receiving principal permission to use some other Netconf operation. > > WHY do we need to allow such an application to perform other Netconf > operations? It should be an administrative policy decision to allow > notifications to be sent to a principal that has no other operational > permission in Netconf. > > I don't like option B simply because I don't like the way it has been > worded. I suggest: > > Proposed Text (C) > > "The contents of notifications as well as the names of event streams > may contain sensitive information and care should be taken to ensure > that they are viewed only by authorized users. It is an administrative > policy decision to determine who (or what) is authorized to have > access to the information contained in notifications. It is > RECOMMENDED that if a user is not authorized to view the content in > the notification via other Newtconf operations, then they SHOULD NOT > be authorized to have access to that content via Netconf > notifications. If a user is not authorized to view all elements in the > content of the notification, the notification is not sent to that > user." > > dbh > >> -----Original Message----- >> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >> Sent: Thursday, May 08, 2008 3:53 AM >> To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; >> netconf@ietf.org >> Subject: RE: [Netconf] Issue X: access to notification content >> >> I am OK with option/proposal A >> >> Bert Wijnen >> >>> -----Oorspronkelijk bericht----- >>> Van: Sharon Chisholm [mailto:schishol@nortel.com] >>> Verzonden: woensdag 7 mei 2008 15:30 >>> Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>> Onderwerp: RE: [Netconf] Issue X: access to notification content >>> >>> >>> Hi >>> >>> If there is no objection to proposal A then I will proceed >> to make this >>> change and publish the updated draft. >>> >>> Sharon >>> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > On >>> Behalf Of Chisholm, Sharon (CAR:ZZ00) >>> Sent: Monday, May 05, 2008 8:33 AM >>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>> Subject: Re: [Netconf] Issue X: access to notification content >>> >>> Hi >>> >>> I think it would be helpful to go back to original text we >> are editing >>> rather then the snippets. I've modified the second sentence >> in ways that >>> I think address the access versus authorization confusion >> and I think >>> makes it so we can keep the 'must not'. I think now we don't need > to >>> 'depending on access control..." part because we are make a >>> recommendation about the access control in order to maintain > minimal >>> security. I've added a third option which tries to include those > for >>> comparison. I prefer A. >>> >>> Current text >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view content via other NETCONF operations, >> she must not >>> have access to that content via Notifications. If a user is > not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> Proposed text (A) >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view the information in the notification, >> they must not >>> have access to that content via Notifications. If a user is > not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> > >>> Proposed text (B) >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view the information in the notification, >> the access >>> control model and administrative policy probably should not >>> allow them access to that content via Notifications. If >> a user is >>> not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> I also got rid of the 'she' thing since I think the singular use > of >>> 'they' is now grammatically acceptable in these cases. >>> >>> Sharon >>> >>> -----Original Message----- >>> From: David B Harrington [mailto:dbharrington@comcast.net] >>> Sent: Friday, May 02, 2008 1:41 PM >>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >> netconf@ietf.org >>> Subject: RE: Issue X: access to notification content >>> >>> >>> >>>> -----Original Message----- >>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>> Sent: Friday, May 02, 2008 11:22 AM >>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>> Subject: RE: Issue X: access to notification content >>>> >>>> By proposed text, did you mean: >>>> >>>> "she probably should not ... depending on the access control > model >>> and >>>> administrative policy." >>>> >>>> Which I proposed to change to >>>> >>>> "she likely will not ... depending on the access control >> model and >>>> administrative policy." >>> That is not what your earlier response said. The proposal in your >>> response did not include the text after the ellipsis. >>> >>> I prefer "she probably should not" because "should not" is RFC2119 >>> language. >>> You might want to stiffen that slightly by making it "she probably >>> SHOULD NOT ... depending on the access control model and >> administrative >>> policy." >>> >>>> Sharon >>>> >>>> -----Original Message----- >>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>> Sent: Wednesday, April 30, 2008 5:53 PM >>>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >>>> netconf@ietf.org >>>> Subject: RE: Issue X: access to notification content >>>> >>>> Hi, >>>> >>>> I don't think your proposed change addresses the security review > >>>> concern. It doesn't say how access will be controlled. >>>> >>>> I think my proposed text does, by saying it will be >> handled by the >>>> access control model and adminstrative policy. >>>> >>>> Is there a reason you don't find my proposed text acceptable? >>>> >>>> dbh >>>> >>>>> -----Original Message----- >>>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>>> Sent: Wednesday, April 30, 2008 2:39 PM >>>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> Hi >>>>> >>>>> I can change from "she must not" to "she likely will >> not". I think >>>> the >>>>> probably softens things too much. The intent is that you >>>> only get to >>>>> view content you have permission to view, regardless of >> the access >>>>> mechanisms. >>>>> >>>>> Sharon >>>>> >>>>> -----Original Message----- >>>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>>> Sent: Tuesday, April 29, 2008 10:25 AM >>>>> To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); >>>>> netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> Hi, >>>>> >>>>> If it is only a discussion, then I suggest rewording >> "she must not >>>>> ..." >>>>> to "she probably should not ... depending on the access > control >>>> model >>>>> and administrative policy." >>>>> >>>>> This does not create a CLR. >>>>> >>>>> dbh >>>>> >>>>>> -----Original Message----- >>>>>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >>>>>> Sent: Tuesday, April 29, 2008 2:41 AM >>>>>> To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org >>>>>> Subject: RE: Issue X: access to notification contenProposed text (B) >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view the information in the notification, >> the access >>> control model and administrative policy probably should not >>> allow them access to that content via Notifications. If >> a user is >>> not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> I also got rid of the 'she' thing since I think the singular use > of >>> 'they' is now grammatically acceptable in these cases. >>> >>> Sharon >>> >>> -----Original Message----- >>> From: David B Harrington [mailto:dbharrington@comcast.net] >>> Sent: Friday, May 02, 2008 1:41 PM >>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >> netconf@ietf.org >>> Subject: RE: Issue X: access to notification content >>> >>> >>> >>>> -----Original Message----- >>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>> Sent: Friday, May 02, 2008 11:22 AM >>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>> Subject: RE: Issue X: access to notification content >>>> >>>> By proposed text, did you mean: >>>> >>>> "she probably should not ... depending on the access control > model >>> and >>>> administrative policy." >>>> >>>> Which I proposed to change to >>>> >>>> "she likely will not ... depending on the access control >> model and >>>> administrative policy." >>> That is not what your earlier response said. The proposal in your >>> response did not include the text after the ellipsis. >>> >>> I prefer "she probably should not" because "should not" is RFC2119 >>> language. >>> You might want to stiffen that slightly by making it "she probably >>> SHOULD NOT ... depending on the access control model and >> administrative >>> policy." >>> >>>> Sharon >>>> >>>> -----Original Message----- >>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>> Sent: Wednesday, April 30, 2008 5:53 PM >>>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >>>> netconf@ietf.org >>>> Subject: RE: Issue X: access to notification content >>>> >>>> Hi, >>>> >>>> I don't think your proposed change addresses the security review > >>>> concern. It doesn't say how access will be controlled. >>>> >>>> I think my proposed text does, by saying it will be >> handled by the >>>> access control model and adminstrative policy. >>>> >>>> Is there a reason you don't find my proposed text acceptable? >>>> >>>> dbh >>>> >>>>> -----Original Message----- >>>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>>> Sent: Wednesday, April 30, 2008 2:39 PM >>>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> Hi >>>>> >>>>> I can change from "she must not" to "she likely will >> not". I think >>>> the >>>>> probably softens things too much. The intent is that you >>>> only get to >>>>> view content you have permission to view, regardless of >> the access >>>>> mechanisms. >>>>> >>>>> Sharon >>>>> >>>>> -----Original Message----- >>>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>>> Sent: Tuesday, April 29, 2008 10:25 AM >>>>> To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); >>>>> netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> Hi, >>>>> >>>>> If it is only a discussion, then I suggest rewording >> "she must not >>>>> ..." >>>>> to "she probably should not ... depending on the access > control >>>> model >>>>> and administrative policy." >>>>> >>>>> This does not create a CLR. >>>>> >>>>> dbh >>>>> >>>>>> -----Original Message----- >>>>>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >>>>>> Sent: Tuesday, April 29, 2008 2:41 AM >>>>>> To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org >>>>>> Subject: RE: Issue X: access to notification content >>>>t >>>>>> >>>>>> Dave, this is a clarification to an concern from an >> IESG member. >>>>>> It is in the "Security Considerations" section, so it is >>>>> not a "hard >>>>>> choice of protocol standard". We are explaining in >> the security >>>>>> considerations section what kind of access concerns >> there might >>>> be. >>>>>> Does that clarify? >>>>>> >>>>>> Sharon, do you have other comments on Dave's concern? >>>>>> >>>>>> Bert Wijnen >>>>>> >>>>>>> -----Oorspronkelijk bericht----- >>>>>>> Van: David B Harrington [mailto:dbharrington@comcast.net] >>>>>>> Verzonden: maandag 28 april 2008 19:28 >>>>>>> Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; >> netconf@ietf.org >>>>>>> Onderwerp: Issue X: access to notification content >>>>>>> >>>>>>> >>>>>>> Hi bert, >>>>>>> >>>>>>> There were a bunch of issues I raised on 4/23 that I think >>>>>> Sharon just >>>>>>> didn't understand and didn't fix. here's one: >>>>>>> >>>>>>> -- >>>>>>> In section 7, the text says "If a user does not have >>>>>>> permission to view content via other NETCONF > operations, >>> she >>>>> must >>>>>>> not >>>>>>> have access to that content via Notifications." >>>>>>> >>>>>>> This creates a big CLR. >>>>>>> >>>>>>> Can content from a syslog or SNMP notification stream be >>>>> sent to a >>>>>>> user that does not have permission to access the syslog or >>> SNMP >>>>>>> content using some other Netconf operation? What >> other Netconf >>>>>>> operation works with the syslog stream? Didn't we >>>>>> explicitly decide it >>>>>>> was not necessary to support access to notication >>> streams >>>>>>> (including syslog and SNMP streams)? >>>>>>> >>>>>>> I am also concerned that this access control "policy" >>>>> should be an >>>>>>> administrative one, not a hard choice of the protocol >>>>> standard. In >>>>>>> most cases it is the right choice. But a NOC manager >>>>> might want to >>>>>>> allow, say, the helpdesk to be alerted whenever a Netconf >>> config >>>>> is >>>>>>> being changed, or an intrusion detection application to >>>>> be alerted >>>>>>> when there is an authentication failure. And yet, they may >>>>>> not want to >>>>>>> give the helpdesk or the IDS permissions. >> With this CLR, >>> a >>>>> NOC >>>>>>> manager is simply not allowed to make such a decision. >>>>>>> >>>>>>> I understand the intent; I think the wording is >> poorly chosen, >>>>>>> especially because it uses a "must", which has special >>>>>> RFC2119 meaning >>>>>>> and creates a huge CLR. And since access control will be >>>>>> done later, I >>>>>>> don't think the WG wants this CLR constraining all future >>>>>> AC designs. >>>>>>> But I could be wrong; maybe the WG will decide this >> is exactly >>>>> what >>>>>>> they want to say. If that is the case, then I think we > need >>>>>> to review >>>>>>> this document to make sure everything else (like syslog >>> streams) >>>>> can >>>>>>> work with this CLR. >>>>>>> >>>>>>> dbh >>>>>>> >>>>>>> >>>>> >>>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf >> >>>>>> Dave, this is a clarification to an concern from an >> IESG member. >>>>>> It is in the "Security Considerations" section, so it is >>>>> not a "hard >>>>>> choice of protocol standard". We are explaining in >> the security >>>>>> considerations section what kind of access concerns >> there might >>>> be. >>>>>> Does that clarify? >>>>>> >>>>>> Sharon, do you have other comments on Dave's concern? >>>>>> >>>>>> Bert Wijnen >>>>>> >>>>>>> -----Oorspronkelijk bericht----- >>>>>>> Van: David B Harrington [mailto:dbharrington@comcast.net] >>>>>>> Verzonden: maandag 28 april 2008 19:28 >>>>>>> Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; >> netconf@ietf.org >>>>>>> Onderwerp: Issue X: access to notification content >>>>>>> >>>>>>> >>>>>>> Hi bert, >>>>>>> >>>>>>> There were a bunch of issues I raised on 4/23 that I think >>>>>> Sharon just >>>>>>> didn't understand and didn't fix. here's one: >>>>>>> >>>>>>> -- >>>>>>> In section 7, the text says "If a user does not have >>>>>>> permission to view content via other NETCONF > operations, >>> she >>>>> must >>>>>>> not >>>>>>> have access to that content via Notifications." >>>>>>> >>>>>>> This creates a big CLR. >>>>>>> >>>>>>> Can content from a syslog or SNMP notification stream be >>>>> sent to a >>>>>>> user that does not have permission to access the syslog or >>> SNMP >>>>>>> content using some other Netconf operation? What >> other Netconf >>>>>>> operation works with the syslog stream? Didn't we >>>>>> explicitly decide it >>>>>>> was not necessary to support access to notication >>> streams >>>>>>> (including syslog and SNMP streams)? >>>>>>> >>>>>>> I am also concerned that this access control "policy" >>>>> should be an >>>>>>> administrative one, not a hard choice of the protocol >>>>> standard. In >>>>>>> most cases it is the right choice. But a NOC manager >>>>> might want to >>>>>>> allow, say, the helpdesk to be alerted whenever a Netconf >>> config >>>>> is >>>>>>> being changed, or an intrusion detection application to >>>>> be alerted >>>>>>> when there is an authentication failure. And yet, they may >>>>>> not want to >>>>>>> give the helpdesk or the IDS permissions. >> With this CLR, >>> a >>>>> NOC >>>>>>> manager is simply not allowed to make such a decision. >>>>>>> >>>>>>> I understand the intent; I think the wording is >> poorly chosen, >>>>>>> especially because it uses a "must", which has special >>>>>> RFC2119 meaning >>>>>>> and creates a huge CLR. And since access control will be >>>>>> done later, I >>>>>>> don't think the WG wants this CLR constraining all future >>>>>> AC designs. >>>>>>> But I could be wrong; maybe the WG will decide this >> is exactly >>>>> what >>>>>>> they want to say. If that is the case, then I think we > need >>>>>> to review >>>>>>> this document to make sure everything else (like syslog >>> streams) >>>>> can >>>>>>> work with this CLR. >>>>>>> >>>>>>> dbh >>>>>>> >>>>>>> >>>>> >>>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 09:20:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B953A7225; Thu, 8 May 2008 09:20:00 -0700 (PDT) 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 D676628C913 for ; Thu, 8 May 2008 09:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.343 X-Spam-Level: X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 x4q9sDPVXwqN for ; Thu, 8 May 2008 09:19:46 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id C072F28CB5F for ; Thu, 8 May 2008 09:09:52 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m48G9iv03910; Thu, 8 May 2008 16:09:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 May 2008 12:08:46 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> In-Reply-To: <48232185.9020109@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Issue X: access to notification content Thread-Index: AcixI3FqzFIz3N/AT+G5KE56Q4xRhgAAeh/Q References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> <48232185.9020109@andybierman.com> From: "Sharon Chisholm" To: "Andy Bierman" , "David B Harrington" Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Neither proposal A or B talk about other NETCONF operations. That text is only in the before text. The difference between proposal A and proposal B is that proposal A is making recommendations to prevent a security issue (don't give people information they are not allowed to see) and proposal B leaves open the option to have this security issue (you may allow people to see information they are not allowed to see). Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Thursday, May 08, 2008 11:52 AM To: David B Harrington Cc: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content David B Harrington wrote: > Hi, > I agree with Dave's concerns, and support his option (C) text. I don't even see what other NETCONF operations have to do with a notification receiver application. I don't agree that any additional security is provided by this MUST requirement. When user A attempts NETCONF operation , the agent will authorize the RPC operation at that time. Why would the agent even check if would be authorized in the future, when the user requests operation ? I don't know much about security, but it seems to be a total waste of time to do this. Andy > I am NOT OK with option A. Notifications in syslog and in SNMP are > normally sent to an application, which filters and aggregates the > notifications. Such an application might alert an operator to > important notifications, but many just get logged for later analysis. > > With the MUST formulation in option A, it becomes a protocol > REQUIREMENT that such application/users CANNOT receive notifications > UNLESS that application is also allowed to perform other Netconf > operations. > > Syslog and SNMP do not contain such a crappy little rule; > Administrators can decide that syslog notifications and/or SNMP > notifications can be sent to a principal that has no other permissions > within syslog or SNMP. But if the operator decides to have syslog or > SNMP information carried over Nertconf, then they MUST give the > receiving principal permission to use some other Netconf operation. > > WHY do we need to allow such an application to perform other Netconf > operations? It should be an administrative policy decision to allow > notifications to be sent to a principal that has no other operational > permission in Netconf. > > I don't like option B simply because I don't like the way it has been > worded. I suggest: > > Proposed Text (C) > > "The contents of notifications as well as the names of event streams > may contain sensitive information and care should be taken to ensure > that they are viewed only by authorized users. It is an administrative > policy decision to determine who (or what) is authorized to have > access to the information contained in notifications. It is > RECOMMENDED that if a user is not authorized to view the content in > the notification via other Newtconf operations, then they SHOULD NOT > be authorized to have access to that content via Netconf > notifications. If a user is not authorized to view all elements in the > content of the notification, the notification is not sent to that > user." > > dbh > >> -----Original Message----- >> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >> Sent: Thursday, May 08, 2008 3:53 AM >> To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; >> netconf@ietf.org >> Subject: RE: [Netconf] Issue X: access to notification content >> >> I am OK with option/proposal A >> >> Bert Wijnen >> >>> -----Oorspronkelijk bericht----- >>> Van: Sharon Chisholm [mailto:schishol@nortel.com] >>> Verzonden: woensdag 7 mei 2008 15:30 >>> Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>> Onderwerp: RE: [Netconf] Issue X: access to notification content >>> >>> >>> Hi >>> >>> If there is no objection to proposal A then I will proceed >> to make this >>> change and publish the updated draft. >>> >>> Sharon >>> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > On >>> Behalf Of Chisholm, Sharon (CAR:ZZ00) >>> Sent: Monday, May 05, 2008 8:33 AM >>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>> Subject: Re: [Netconf] Issue X: access to notification content >>> >>> Hi >>> >>> I think it would be helpful to go back to original text we >> are editing >>> rather then the snippets. I've modified the second sentence >> in ways that >>> I think address the access versus authorization confusion >> and I think >>> makes it so we can keep the 'must not'. I think now we don't need > to >>> 'depending on access control..." part because we are make a >>> recommendation about the access control in order to maintain > minimal >>> security. I've added a third option which tries to include those > for >>> comparison. I prefer A. >>> >>> Current text >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view content via other NETCONF operations, >> she must not >>> have access to that content via Notifications. If a user is > not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> Proposed text (A) >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view the information in the notification, >> they must not >>> have access to that content via Notifications. If a user is > not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> Proposed text (B) >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view the information in the notification, >> the access >>> control model and administrative policy probably should not >>> allow them access to that content via Notifications. If >> a user is >>> not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> I also got rid of the 'she' thing since I think the singular use > of >>> 'they' is now grammatically acceptable in these cases. >>> >>> Sharon >>> >>> -----Original Message----- >>> From: David B Harrington [mailto:dbharrington@comcast.net] >>> Sent: Friday, May 02, 2008 1:41 PM >>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >> netconf@ietf.org >>> Subject: RE: Issue X: access to notification content >>> >>> >>> >>>> -----Original Message----- >>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>> Sent: Friday, May 02, 2008 11:22 AM >>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>> Subject: RE: Issue X: access to notification content >>>> >>>> By proposed text, did you mean: >>>> >>>> "she probably should not ... depending on the access control > model >>> and >>>> administrative policy." >>>> >>>> Which I proposed to change to >>>> >>>> "she likely will not ... depending on the access control >> model and >>>> administrative policy." >>> That is not what your earlier response said. The proposal in your >>> response did not include the text after the ellipsis. >>> >>> I prefer "she probably should not" because "should not" is RFC2119 >>> language. >>> You might want to stiffen that slightly by making it "she probably >>> SHOULD NOT ... depending on the access control model and >> administrative >>> policy." >>> >>>> Sharon >>>> >>>> -----Original Message----- >>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>> Sent: Wednesday, April 30, 2008 5:53 PM >>>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >>>> netconf@ietf.org >>>> Subject: RE: Issue X: access to notification content >>>> >>>> Hi, >>>> >>>> I don't think your proposed change addresses the security review > >>>> concern. It doesn't say how access will be controlled. >>>> >>>> I think my proposed text does, by saying it will be >> handled by the >>>> access control model and adminstrative policy. >>>> >>>> Is there a reason you don't find my proposed text acceptable? >>>> >>>> dbh >>>> >>>>> -----Original Message----- >>>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>>> Sent: Wednesday, April 30, 2008 2:39 PM >>>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> Hi >>>>> >>>>> I can change from "she must not" to "she likely will >> not". I think >>>> the >>>>> probably softens things too much. The intent is that you >>>> only get to >>>>> view content you have permission to view, regardless of >> the access >>>>> mechanisms. >>>>> >>>>> Sharon >>>>> >>>>> -----Original Message----- >>>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>>> Sent: Tuesday, April 29, 2008 10:25 AM >>>>> To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); >>>>> netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> Hi, >>>>> >>>>> If it is only a discussion, then I suggest rewording >> "she must not >>>>> ..." >>>>> to "she probably should not ... depending on the access > control >>>> model >>>>> and administrative policy." >>>>> >>>>> This does not create a CLR. >>>>> >>>>> dbh >>>>> >>>>>> -----Original Message----- >>>>>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >>>>>> Sent: Tuesday, April 29, 2008 2:41 AM >>>>>> To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org >>>>>> Subject: RE: Issue X: access to notification content >>>>>> >>>>>> Dave, this is a clarification to an concern from an >> IESG member. >>>>>> It is in the "Security Considerations" section, so it is >>>>> not a "hard >>>>>> choice of protocol standard". We are explaining in >> the security >>>>>> considerations section what kind of access concerns >> there might >>>> be. >>>>>> Does that clarify? >>>>>> >>>>>> Sharon, do you have other comments on Dave's concern? >>>>>> >>>>>> Bert Wijnen >>>>>> >>>>>>> -----Oorspronkelijk bericht----- >>>>>>> Van: David B Harrington [mailto:dbharrington@comcast.net] >>>>>>> Verzonden: maandag 28 april 2008 19:28 >>>>>>> Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; >> netconf@ietf.org >>>>>>> Onderwerp: Issue X: access to notification content >>>>>>> >>>>>>> >>>>>>> Hi bert, >>>>>>> >>>>>>> There were a bunch of issues I raised on 4/23 that I think >>>>>> Sharon just >>>>>>> didn't understand and didn't fix. here's one: >>>>>>> >>>>>>> -- >>>>>>> In section 7, the text says "If a user does not have >>>>>>> permission to view content via other NETCONF > operations, >>> she >>>>> must >>>>>>> not >>>>>>> have access to that content via Notifications." >>>>>>> >>>>>>> This creates a big CLR. >>>>>>> >>>>>>> Can content from a syslog or SNMP notification stream be >>>>> sent to a >>>>>>> user that does not have permission to access the syslog or >>> SNMP >>>>>>> content using some other Netconf operation? What >> other Netconf >>>>>>> operation works with the syslog stream? Didn't we >>>>>> explicitly decide it >>>>>>> was not necessary to support access to notication >>> streams >>>>>>> (including syslog and SNMP streams)? >>>>>>> >>>>>>> I am also concerned that this access control "policy" >>>>> should be an >>>>>>> administrative one, not a hard choice of the protocol >>>>> standard. In >>>>>>> most cases it is the right choice. But a NOC manager >>>>> might want to >>>>>>> allow, say, the helpdesk to be alerted whenever a Netconf >>> config >>>>> is >>>>>>> being changed, or an intrusion detection application to >>>>> be alerted >>>>>>> when there is an authentication failure. And yet, they may >>>>>> not want to >>>>>>> give the helpdesk or the IDS permissions. >> With this CLR, >>> a >>>>> NOC >>>>>>> manager is simply not allowed to make such a decision. >>>>>>> >>>>>>> I understand the intent; I think the wording is >> poorly chosen, >>>>>>> especially because it uses a "must", which has special >>>>>> RFC2119 meaning >>>>>>> and creates a huge CLR. And since access control will be >>>>>> done later, I >>>>>>> don't think the WG wants this CLR constraining all future >>>>>> AC designs. >>>>>>> But I could be wrong; maybe the WG will decide this >> is exactly >>>>> what >>>>>>> they want to say. If that is the case, then I think we > need >>>>>> to review >>>>>>> this document to make sure everything else (like syslog >>> streams) >>>>> can >>>>>>> work with this CLR. >>>>>>> >>>>>>> dbh >>>>>>> >>>>>>> >>>>> >>>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 09:20:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B953A7225; Thu, 8 May 2008 09:20:00 -0700 (PDT) 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 D676628C913 for ; Thu, 8 May 2008 09:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.343 X-Spam-Level: X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 x4q9sDPVXwqN for ; Thu, 8 May 2008 09:19:46 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id C072F28CB5F for ; Thu, 8 May 2008 09:09:52 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m48G9iv03910; Thu, 8 May 2008 16:09:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 May 2008 12:08:46 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> In-Reply-To: <48232185.9020109@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Issue X: access to notification content Thread-Index: AcixI3FqzFIz3N/AT+G5KE56Q4xRhgAAeh/Q References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> <48232185.9020109@andybierman.com> From: "Sharon Chisholm" To: "Andy Bierman" , "David B Harrington" Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Neither proposal A or B talk about other NETCONF operations. That text is only in the before text. The difference between proposal A and proposal B is that proposal A is making recommendations to prevent a security issue (don't give people information they are not allowed to see) and proposal B leaves open the option to have this security issue (you may allow people to see information they are not allowed to see). Sharon -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Thursday, May 08, 2008 11:52 AM To: David B Harrington Cc: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content David B Harrington wrote: > Hi, > I agree with Dave's concerns, and support his option (C) text. I don't even see what other NETCONF operations have to do with a notification receiver application. I don't agree that any additional security is provided by this MUST requirement. When user A attempts NETCONF operation , the agent will authorize the RPC operation at that time. Why would the agent even check if would be authorized in the future, when the user requests operation ? I don't know much about security, but it seems to be a total waste of time to do this. Andy > I am NOT OK with option A. Notifications in syslog and in SNMP are > normally sent to an application, which filters and aggregates the > notifications. Such an application might alert an operator to > important notifications, but many just get logged for later analysis. > > With the MUST formulation in option A, it becomes a protocol > REQUIREMENT that such application/users CANNOT receive notifications > UNLESS that application is also allowed to perform other Netconf > operations. > > Syslog and SNMP do not contain such a crappy little rule; > Administrators can decide that syslog notifications and/or SNMP > notifications can be sent to a principal that has no other permissions > within syslog or SNMP. But if the operator decides to have syslog or > SNMP information carried over Nertconf, then they MUST give the > receiving principal permission to use some other Netconf operation. > > WHY do we need to allow such an application to perform other Netconf > operations? It should be an administrative policy decision to allow > notifications to be sent to a principal that has no other operational > permission in Netconf. > > I don't like option B simply because I don't like the way it has been > worded. I suggest: > > Proposed Text (C) > > "The contents of notifications as well as the names of event streams > may contain sensitive information and care should be taken to ensure > that they are viewed only by authorized users. It is an administrative > policy decision to determine who (or what) is authorized to have > access to the information contained in notifications. It is > RECOMMENDED that if a user is not authorized to view the content in > the notification via other Newtconf operations, then they SHOULD NOT > be authorized to have access to that content via Netconf > notifications. If a user is not authorized to view all elements in the > content of the notification, the notification is not sent to that > user." > > dbh > >> -----Original Message----- >> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >> Sent: Thursday, May 08, 2008 3:53 AM >> To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; >> netconf@ietf.org >> Subject: RE: [Netconf] Issue X: access to notification content >> >> I am OK with option/proposal A >> >> Bert Wijnen >> >>> -----Oorspronkelijk bericht----- >>> Van: Sharon Chisholm [mailto:schishol@nortel.com] >>> Verzonden: woensdag 7 mei 2008 15:30 >>> Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>> Onderwerp: RE: [Netconf] Issue X: access to notification content >>> >>> >>> Hi >>> >>> If there is no objection to proposal A then I will proceed >> to make this >>> change and publish the updated draft. >>> >>> Sharon >>> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > On >>> Behalf Of Chisholm, Sharon (CAR:ZZ00) >>> Sent: Monday, May 05, 2008 8:33 AM >>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>> Subject: Re: [Netconf] Issue X: access to notification content >>> >>> Hi >>> >>> I think it would be helpful to go back to original text we >> are editing >>> rather then the snippets. I've modified the second sentence >> in ways that >>> I think address the access versus authorization confusion >> and I think >>> makes it so we can keep the 'must not'. I think now we don't need > to >>> 'depending on access control..." part because we are make a >>> recommendation about the access control in order to maintain > minimal >>> security. I've added a third option which tries to include those > for >>> comparison. I prefer A. >>> >>> Current text >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view content via other NETCONF operations, >> she must not >>> have access to that content via Notifications. If a user is > not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> Proposed text (A) >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view the information in the notification, >> they must not >>> have access to that content via Notifications. If a user is > not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> Proposed text (B) >>> >>> The contents of notifications as well as the name of event streams >>> may contain sensitive information and care should be >> taken to ensure >>> that it is viewed only by authorized users. If a user >> does not have >>> permission to view the information in the notification, >> the access >>> control model and administrative policy probably should not >>> allow them access to that content via Notifications. If >> a user is >>> not >>> permitted to view one element in the content of the >> notification, the >>> notification is not sent to that user. >>> >>> I also got rid of the 'she' thing since I think the singular use > of >>> 'they' is now grammatically acceptable in these cases. >>> >>> Sharon >>> >>> -----Original Message----- >>> From: David B Harrington [mailto:dbharrington@comcast.net] >>> Sent: Friday, May 02, 2008 1:41 PM >>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >> netconf@ietf.org >>> Subject: RE: Issue X: access to notification content >>> >>> >>> >>>> -----Original Message----- >>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>> Sent: Friday, May 02, 2008 11:22 AM >>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>> Subject: RE: Issue X: access to notification content >>>> >>>> By proposed text, did you mean: >>>> >>>> "she probably should not ... depending on the access control > model >>> and >>>> administrative policy." >>>> >>>> Which I proposed to change to >>>> >>>> "she likely will not ... depending on the access control >> model and >>>> administrative policy." >>> That is not what your earlier response said. The proposal in your >>> response did not include the text after the ellipsis. >>> >>> I prefer "she probably should not" because "should not" is RFC2119 >>> language. >>> You might want to stiffen that slightly by making it "she probably >>> SHOULD NOT ... depending on the access control model and >> administrative >>> policy." >>> >>>> Sharon >>>> >>>> -----Original Message----- >>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>> Sent: Wednesday, April 30, 2008 5:53 PM >>>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >>>> netconf@ietf.org >>>> Subject: RE: Issue X: access to notification content >>>> >>>> Hi, >>>> >>>> I don't think your proposed change addresses the security review > >>>> concern. It doesn't say how access will be controlled. >>>> >>>> I think my proposed text does, by saying it will be >> handled by the >>>> access control model and adminstrative policy. >>>> >>>> Is there a reason you don't find my proposed text acceptable? >>>> >>>> dbh >>>> >>>>> -----Original Message----- >>>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>>> Sent: Wednesday, April 30, 2008 2:39 PM >>>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> Hi >>>>> >>>>> I can change from "she must not" to "she likely will >> not". I think >>>> the >>>>> probably softens things too much. The intent is that you >>>> only get to >>>>> view content you have permission to view, regardless of >> the access >>>>> mechanisms. >>>>> >>>>> Sharon >>>>> >>>>> -----Original Message----- >>>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>>> Sent: Tuesday, April 29, 2008 10:25 AM >>>>> To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); >>>>> netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> Hi, >>>>> >>>>> If it is only a discussion, then I suggest rewording >> "she must not >>>>> ..." >>>>> to "she probably should not ... depending on the access > control >>>> model >>>>> and administrative policy." >>>>> >>>>> This does not create a CLR. >>>>> >>>>> dbh >>>>> >>>>>> -----Original Message----- >>>>>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >>>>>> Sent: Tuesday, April 29, 2008 2:41 AM >>>>>> To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org >>>>>> Subject: RE: Issue X: access to notification content >>>>>> >>>>>> Dave, this is a clarification to an concern from an >> IESG member. >>>>>> It is in the "Security Considerations" section, so it is >>>>> not a "hard >>>>>> choice of protocol standard". We are explaining in >> the security >>>>>> considerations section what kind of access concerns >> there might >>>> be. >>>>>> Does that clarify? >>>>>> >>>>>> Sharon, do you have other comments on Dave's concern? >>>>>> >>>>>> Bert Wijnen >>>>>> >>>>>>> -----Oorspronkelijk bericht----- >>>>>>> Van: David B Harrington [mailto:dbharrington@comcast.net] >>>>>>> Verzonden: maandag 28 april 2008 19:28 >>>>>>> Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; >> netconf@ietf.org >>>>>>> Onderwerp: Issue X: access to notification content >>>>>>> >>>>>>> >>>>>>> Hi bert, >>>>>>> >>>>>>> There were a bunch of issues I raised on 4/23 that I think >>>>>> Sharon just >>>>>>> didn't understand and didn't fix. here's one: >>>>>>> >>>>>>> -- >>>>>>> In section 7, the text says "If a user does not have >>>>>>> permission to view content via other NETCONF > operations, >>> she >>>>> must >>>>>>> not >>>>>>> have access to that content via Notifications." >>>>>>> >>>>>>> This creates a big CLR. >>>>>>> >>>>>>> Can content from a syslog or SNMP notification stream be >>>>> sent to a >>>>>>> user that does not have permission to access the syslog or >>> SNMP >>>>>>> content using some other Netconf operation? What >> other Netconf >>>>>>> operation works with the syslog stream? Didn't we >>>>>> explicitly decide it >>>>>>> was not necessary to support access to notication >>> streams >>>>>>> (including syslog and SNMP streams)? >>>>>>> >>>>>>> I am also concerned that this access control "policy" >>>>> should be an >>>>>>> administrative one, not a hard choice of the protocol >>>>> standard. In >>>>>>> most cases it is the right choice. But a NOC manager >>>>> might want to >>>>>>> allow, say, the helpdesk to be alerted whenever a Netconf >>> config >>>>> is >>>>>>> being changed, or an intrusion detection application to >>>>> be alerted >>>>>>> when there is an authentication failure. And yet, they may >>>>>> not want to >>>>>>> give the helpdesk or the IDS permissions. >> With this CLR, >>> a >>>>> NOC >>>>>>> manager is simply not allowed to make such a decision. >>>>>>> >>>>>>> I understand the intent; I think the wording is >> poorly chosen, >>>>>>> especially because it uses a "must", which has special >>>>>> RFC2119 meaning >>>>>>> and creates a huge CLR. And since access control will be >>>>>> done later, I >>>>>>> don't think the WG wants this CLR constraining all future >>>>>> AC designs. >>>>>>> But I could be wrong; maybe the WG will decide this >> is exactly >>>>> what >>>>>>> they want to say. If that is the case, then I think we > need >>>>>> to review >>>>>>> this document to make sure everything else (like syslog >>> streams) >>>>> can >>>>>>> work with this CLR. >>>>>>> >>>>>>> dbh >>>>>>> >>>>>>> >>>>> >>>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 10:13:50 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346053A6992; Thu, 8 May 2008 10:13:50 -0700 (PDT) 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 A71DA3A6920 for ; Thu, 8 May 2008 10:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 7vV2sNKqx8IS for ; Thu, 8 May 2008 10:13:47 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 1A9503A6783 for ; Thu, 8 May 2008 10:13:47 -0700 (PDT) Received: (qmail 69467 invoked from network); 8 May 2008 17:13:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2008 17:13:43 -0000 X-YMail-OSG: FKZwQTUVM1n_NQ9FOzRRUAljx_Ec2QEwAH6xYXSlkg2y3Ljn_KfASGLFbaa7XqAXSHsNZxYkaZgMImHL1rGiyxxZtiKEAh8mpa30GjRKB9adAle6mSGs9JnGJhC5o_NmXre5sFMChvTVdStZLO3wvqbK X-Yahoo-Newman-Property: ymail-3 Message-ID: <482334BA.2060303@andybierman.com> Date: Thu, 08 May 2008 10:13:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> <48232185.9020109@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > Neither proposal A or B talk about other NETCONF operations. That text > is only in the before text. The difference between proposal A and > proposal B is that proposal A is making recommendations to prevent a > security issue (don't give people information they are not allowed to > see) and proposal B leaves open the option to have this security issue > (you may allow people to see information they are not allowed to see). > oops -- I was confused. I thought the paragraph dealt with other NETCONF operations, but I see that is Dave's text, not (A) or (B). I actually don't like any of the choices. The authorization policies, mechanisms, and data models are way out of scope at this time. At best, a generic sentence about the advantages of preventing sensitive information from being disclosed without proper authorization is needed. We already have an standard authorization architecture in NETCONF. It you can login, you can do anything and everything the agent supports. Root access or nothing. It really stinks, but it is what the protocol supports From netconf-bounces@ietf.org Thu May 8 10:13:50 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346053A6992; Thu, 8 May 2008 10:13:50 -0700 (PDT) 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 A71DA3A6920 for ; Thu, 8 May 2008 10:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 7vV2sNKqx8IS for ; Thu, 8 May 2008 10:13:47 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 1A9503A6783 for ; Thu, 8 May 2008 10:13:47 -0700 (PDT) Received: (qmail 69467 invoked from network); 8 May 2008 17:13:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2008 17:13:43 -0000 X-YMail-OSG: FKZwQTUVM1n_NQ9FOzRRUAljx_Ec2QEwAH6xYXSlkg2y3Ljn_KfASGLFbaa7XqAXSHsNZxYkaZgMImHL1rGiyxxZtiKEAh8mpa30GjRKB9adAle6mSGs9JnGJhC5o_NmXre5sFMChvTVdStZLO3wvqbK X-Yahoo-Newman-Property: ymail-3 Message-ID: <482334BA.2060303@andybierman.com> Date: Thu, 08 May 2008 10:13:30 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> <48232185.9020109@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > Neither proposal A or B talk about other NETCONF operations. That text > is only in the before text. The difference between proposal A and > proposal B is that proposal A is making recommendations to prevent a > security issue (don't give people information they are not allowed to > see) and proposal B leaves open the option to have this security issue > (you may allow people to see information they are not allowed to see). > oops -- I was confused. I thought the paragraph dealt with other NETCONF operations, but I see that is Dave's text, not (A) or (B). I actually don't like any of the choices. The authorization policies, mechanisms, and data models are way out of scope at this time. At best, a generic sentence about the advantages of preventing sensitive information from being disclosed without proper authorization is needed. We already have an standard authorization architecture in NETCONF. It you can login, you can do anything and everything the agent supports. Root access or nothing. It really stinks, but it is what the protocol supright now. Until something real is done about access control, I suggest the protocol not make any assumptions about how authorization to a specified subset of the 'entire agent' is done. IMO, an authorization model that does not account for the entire NETCONF stack is broken. Focusing on the data, ignoring the RPC methods, and ignoring the transport layer issues as well, will not lead to a good enough solution. > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, May 08, 2008 11:52 AM > To: David B Harrington > Cc: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org > Subject: Re: [Netconf] Issue X: access to notification content > > David B Harrington wrote: >> Hi, >> > > I agree with Dave's concerns, and support his option (C) text. > > I don't even see what other NETCONF operations have to do with a > notification receiver application. I don't agree that any additional > security is provided by this MUST requirement. > > When user A attempts NETCONF operation , the agent will authorize > the RPC operation at that time. Why would the agent even check if > would be authorized in the future, when the user requests operation > ? I don't know much about security, but it seems to be a total > waste of time to do this. > > > Andy > > >> I am NOT OK with option A. Notifications in syslog and in SNMP are >> normally sent to an application, which filters and aggregates the >> notifications. Such an application might alert an operator to >> important notifications, but many just get logged for later analysis. >> >> With the MUST formulation in option A, it becomes a protocol >> REQUIREMENT that such application/users CANNOT receive notifications >> UNLESS that application is also allowed to perform other Netconf >> operations. >> >> Syslog and SNMP do not contain such a crappy little rule; >> Administrators can decide that syslog notifications and/or SNMP >> notifications can be sent to a principal that has no other permissions > >> within syslog or SNMP. But if the operator decides to have syslog or >> SNMP information carried over Nertconf, then they MUST give the >> receiving principal permission to use some other Netconf operation. >> >> WHY do we need to allow such an application to perform other Netconf >> operations? It should be an administrative policy decision to allow >> notifications to be sent to a principal that has no other operational >> permission in Netconf. >> >> I don't like option B simply because I don't like the way it has been >> worded. I suggest: >> >> Proposed Text (C) >> >> "The contents of notifications as well as the names of event streams >> may contain sensitive information and care should be taken to ensure >> that they are viewed only by authorized users. It is an administrative > >> policy decision to determine who (or what) is authorized to have >> access to the information contained in notifications. It is >> RECOMMENDED that if a user is not authorized to view the content in >> the notification via other Newtconf operations, then they SHOULD NOT >> be authorized to have access to that content via Netconf >> notifications. If a user is not authorized to view all elements in the > >> content of the notification, the notification is not sent to that >> user." >> >> dbh >> >>> -----Original Message----- >>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >>> Sent: Thursday, May 08, 2008 3:53 AM >>> To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; >>> netconf@ietf.org >>> Subject: RE: [Netconf] Issue X: access to notification content >>> >>> I am OK with option/proposal A >>> >>> Bert Wijnen >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: Sharon Chisholm [mailto:schishol@nortel.com] >>>> Verzonden: woensdag 7 mei 2008 15:30 >>>> Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>> Onderwerp: RE: [Netconf] Issue X: access to notification content >>>> >>>> >>>> Hi >>>> >>>> If there is no objection to proposal A then I wilports right now. Until something real is done about access control, I suggest the protocol not make any assumptions about how authorization to a specified subset of the 'entire agent' is done. IMO, an authorization model that does not account for the entire NETCONF stack is broken. Focusing on the data, ignoring the RPC methods, and ignoring the transport layer issues as well, will not lead to a good enough solution. > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, May 08, 2008 11:52 AM > To: David B Harrington > Cc: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org > Subject: Re: [Netconf] Issue X: access to notification content > > David B Harrington wrote: >> Hi, >> > > I agree with Dave's concerns, and support his option (C) text. > > I don't even see what other NETCONF operations have to do with a > notification receiver application. I don't agree that any additional > security is provided by this MUST requirement. > > When user A attempts NETCONF operation , the agent will authorize > the RPC operation at that time. Why would the agent even check if > would be authorized in the future, when the user requests operation > ? I don't know much about security, but it seems to be a total > waste of time to do this. > > > Andy > > >> I am NOT OK with option A. Notifications in syslog and in SNMP are >> normally sent to an application, which filters and aggregates the >> notifications. Such an application might alert an operator to >> important notifications, but many just get logged for later analysis. >> >> With the MUST formulation in option A, it becomes a protocol >> REQUIREMENT that such application/users CANNOT receive notifications >> UNLESS that application is also allowed to perform other Netconf >> operations. >> >> Syslog and SNMP do not contain such a crappy little rule; >> Administrators can decide that syslog notifications and/or SNMP >> notifications can be sent to a principal that has no other permissions > >> within syslog or SNMP. But if the operator decides to have syslog or >> SNMP information carried over Nertconf, then they MUST give the >> receiving principal permission to use some other Netconf operation. >> >> WHY do we need to allow such an application to perform other Netconf >> operations? It should be an administrative policy decision to allow >> notifications to be sent to a principal that has no other operational >> permission in Netconf. >> >> I don't like option B simply because I don't like the way it has been >> worded. I suggest: >> >> Proposed Text (C) >> >> "The contents of notifications as well as the names of event streams >> may contain sensitive information and care should be taken to ensure >> that they are viewed only by authorized users. It is an administrative > >> policy decision to determine who (or what) is authorized to have >> access to the information contained in notifications. It is >> RECOMMENDED that if a user is not authorized to view the content in >> the notification via other Newtconf operations, then they SHOULD NOT >> be authorized to have access to that content via Netconf >> notifications. If a user is not authorized to view all elements in the > >> content of the notification, the notification is not sent to that >> user." >> >> dbh >> >>> -----Original Message----- >>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >>> Sent: Thursday, May 08, 2008 3:53 AM >>> To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; >>> netconf@ietf.org >>> Subject: RE: [Netconf] Issue X: access to notification content >>> >>> I am OK with option/proposal A >>> >>> Bert Wijnen >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: Sharon Chisholm [mailto:schishol@nortel.com] >>>> Verzonden: woensdag 7 mei 2008 15:30 >>>> Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>> Onderwerp: RE: [Netconf] Issue X: access to notification content >>>> >>>> >>>> Hi >>>> >>>> If there is no objection to proposal A thenl proceed >>> to make this >>>> change and publish the updated draft. >>>> >>>> Sharon >>>> >>>> -----Original Message----- >>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] >> On >>>> Behalf Of Chisholm, Sharon (CAR:ZZ00) >>>> Sent: Monday, May 05, 2008 8:33 AM >>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>> Subject: Re: [Netconf] Issue X: access to notification content >>>> >>>> Hi >>>> >>>> I think it would be helpful to go back to original text we >>> are editing >>>> rather then the snippets. I've modified the second sentence >>> in ways that >>>> I think address the access versus authorization confusion >>> and I think >>>> makes it so we can keep the 'must not'. I think now we don't need >> to >>>> 'depending on access control..." part because we are make a >>>> recommendation about the access control in order to maintain >> minimal >>>> security. I've added a third option which tries to include those >> for >>>> comparison. I prefer A. >>>> >>>> Current text >>>> >>>> The contents of notifications as well as the name of event streams >>>> may contain sensitive information and care should be >>> taken to ensure >>>> that it is viewed only by authorized users. If a user >>> does not have >>>> permission to view content via other NETCONF operations, >>> she must not >>>> have access to that content via Notifications. If a user is >> not >>>> permitted to view one element in the content of the >>> notification, the >>>> notification is not sent to that user. >>>> >>>> Proposed text (A) >>>> >>>> The contents of notifications as well as the name of event streams >>>> may contain sensitive information and care should be >>> taken to ensure >>>> that it is viewed only by authorized users. If a user >>> does not have >>>> permission to view the information in the notification, >>> they must not >>>> have access to that content via Notifications. If a user is >> not >>>> permitted to view one element in the content of the >>> notification, the >>>> notification is not sent to that user. >>>> >>>> Proposed text (B) >>>> >>>> The contents of notifications as well as the name of event streams >>>> may contain sensitive information and care should be >>> taken to ensure >>>> that it is viewed only by authorized users. If a user >>> does not have >>>> permission to view the information in the notification, >>> the access >>>> control model and administrative policy probably should not >>>> allow them access to that content via Notifications. If >>> a user is >>>> not >>>> permitted to view one element in the content of the >>> notification, the >>>> notification is not sent to that user. >>>> >>>> I also got rid of the 'she' thing since I think the singular use >> of >>>> 'they' is now grammatically acceptable in these cases. >>>> >>>> Sharon >>>> >>>> -----Original Message----- >>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>> Sent: Friday, May 02, 2008 1:41 PM >>>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >>> netconf@ietf.org >>>> Subject: RE: Issue X: access to notification content >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>>> Sent: Friday, May 02, 2008 11:22 AM >>>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> By proposed text, did you mean: >>>>> >>>>> "she probably should not ... depending on the access control >> model >>>> and >>>>> administrative policy." >>>>> >>>>> Which I proposed to change to >>>>> >>>>> "she likely will not ... depending on the access control >>> model and >>>>> administrative policy." >>>> That is not what your earlier response said. The proposal in your >>>> response did not include the text after the ellipsis. >>>> >>>> I prefer "she probably should not" because "should not" is RFC2119 >>>> language. >>>> You might want to stiffen that slightly by making it "she probably >>>> SHOULD NOT ... dependin I will proceed >>> to make this >>>> change and publish the updated draft. >>>> >>>> Sharon >>>> >>>> -----Original Message----- >>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] >> On >>>> Behalf Of Chisholm, Sharon (CAR:ZZ00) >>>> Sent: Monday, May 05, 2008 8:33 AM >>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>> Subject: Re: [Netconf] Issue X: access to notification content >>>> >>>> Hi >>>> >>>> I think it would be helpful to go back to original text we >>> are editing >>>> rather then the snippets. I've modified the second sentence >>> in ways that >>>> I think address the access versus authorization confusion >>> and I think >>>> makes it so we can keep the 'must not'. I think now we don't need >> to >>>> 'depending on access control..." part because we are make a >>>> recommendation about the access control in order to maintain >> minimal >>>> security. I've added a third option which tries to include those >> for >>>> comparison. I prefer A. >>>> >>>> Current text >>>> >>>> The contents of notifications as well as the name of event streams >>>> may contain sensitive information and care should be >>> taken to ensure >>>> that it is viewed only by authorized users. If a user >>> does not have >>>> permission to view content via other NETCONF operations, >>> she must not >>>> have access to that content via Notifications. If a user is >> not >>>> permitted to view one element in the content of the >>> notification, the >>>> notification is not sent to that user. >>>> >>>> Proposed text (A) >>>> >>>> The contents of notifications as well as the name of event streams >>>> may contain sensitive information and care should be >>> taken to ensure >>>> that it is viewed only by authorized users. If a user >>> does not have >>>> permission to view the information in the notification, >>> they must not >>>> have access to that content via Notifications. If a user is >> not >>>> permitted to view one element in the content of the >>> notification, the >>>> notification is not sent to that user. >>>> >>>> Proposed text (B) >>>> >>>> The contents of notifications as well as the name of event streams >>>> may contain sensitive information and care should be >>> taken to ensure >>>> that it is viewed only by authorized users. If a user >>> does not have >>>> permission to view the information in the notification, >>> the access >>>> control model and administrative policy probably should not >>>> allow them access to that content via Notifications. If >>> a user is >>>> not >>>> permitted to view one element in the content of the >>> notification, the >>>> notification is not sent to that user. >>>> >>>> I also got rid of the 'she' thing since I think the singular use >> of >>>> 'they' is now grammatically acceptable in these cases. >>>> >>>> Sharon >>>> >>>> -----Original Message----- >>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>> Sent: Friday, May 02, 2008 1:41 PM >>>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >>> netconf@ietf.org >>>> Subject: RE: Issue X: access to notification content >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>>> Sent: Friday, May 02, 2008 11:22 AM >>>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> By proposed text, did you mean: >>>>> >>>>> "she probably should not ... depending on the access control >> model >>>> and >>>>> administrative policy." >>>>> >>>>> Which I proposed to change to >>>>> >>>>> "she likely will not ... depending on the access control >>> model and >>>>> administrative policy." >>>> That is not what your earlier response said. The proposal in your >>>> response did not include the text after the ellipsis. >>>> >>>> I prefer "she probably should not" because "should not" is RFC2119 >>>> language. >>>> You might want to stiffen that slightly by making it "she probably >>>> SHOULD NOT ... deg on the access control model and >>> administrative >>>> policy." >>>> >>>>> Sharon >>>>> >>>>> -----Original Message----- >>>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>>> Sent: Wednesday, April 30, 2008 5:53 PM >>>>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >>>>> netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> Hi, >>>>> >>>>> I don't think your proposed change addresses the security review >>>>> concern. It doesn't say how access will be controlled. >>>>> >>>>> I think my proposed text does, by saying it will be >>> handled by the >>>>> access control model and adminstrative policy. >>>>> >>>>> Is there a reason you don't find my proposed text acceptable? >>>>> >>>>> dbh >>>>> >>>>>> -----Original Message----- >>>>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>>>> Sent: Wednesday, April 30, 2008 2:39 PM >>>>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>>>> Subject: RE: Issue X: access to notification content >>>>>> >>>>>> Hi >>>>>> >>>>>> I can change from "she must not" to "she likely will >>> not". I think >>>>> the >>>>>> probably softens things too much. The intent is that you >>>>> only get to >>>>>> view content you have permission to view, regardless of >>> the access >>>>>> mechanisms. >>>>>> >>>>>> Sharon >>>>>> >>>>>> -----Original Message----- >>>>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>>>> Sent: Tuesday, April 29, 2008 10:25 AM >>>>>> To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); >>>>>> netconf@ietf.org >>>>>> Subject: RE: Issue X: access to notification content >>>>>> >>>>>> Hi, >>>>>> >>>>>> If it is only a discussion, then I suggest rewording >>> "she must not >>>>>> ..." >>>>>> to "she probably should not ... depending on the access >> control >>>>> model >>>>>> and administrative policy." >>>>>> >>>>>> This does not create a CLR. >>>>>> >>>>>> dbh >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >>>>>>> Sent: Tuesday, April 29, 2008 2:41 AM >>>>>>> To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org >>>>>>> Subject: RE: Issue X: access to notification content >>>>>>> >>>>>>> Dave, this is a clarification to an concern from an >>> IESG member. >>>>>>> It is in the "Security Considerations" section, so it is >>>>>> not a "hard >>>>>>> choice of protocol standard". We are explaining in >>> the security >>>>>>> considerations section what kind of access concerns >>> there might >>>>> be. >>>>>>> Does that clarify? >>>>>>> >>>>>>> Sharon, do you have other comments on Dave's concern? >>>>>>> >>>>>>> Bert Wijnen >>>>>>> >>>>>>>> -----Oorspronkelijk bericht----- >>>>>>>> Van: David B Harrington [mailto:dbharrington@comcast.net] >>>>>>>> Verzonden: maandag 28 april 2008 19:28 >>>>>>>> Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; >>> netconf@ietf.org >>>>>>>> Onderwerp: Issue X: access to notification content >>>>>>>> >>>>>>>> >>>>>>>> Hi bert, >>>>>>>> >>>>>>>> There were a bunch of issues I raised on 4/23 that I think >>>>>>> Sharon just >>>>>>>> didn't understand and didn't fix. here's one: >>>>>>>> >>>>>>>> -- >>>>>>>> In section 7, the text says "If a user does not have >>>>>>>> permission to view content via other NETCONF >> operations, >>>> she >>>>>> must >>>>>>>> not >>>>>>>> have access to that content via Notifications." >>>>>>>> >>>>>>>> This creates a big CLR. >>>>>>>> >>>>>>>> Can content from a syslog or SNMP notification stream be >>>>>> sent to a >>>>>>>> user that does not have permission to access the syslog or >>>> SNMP >>>>>>>> content using some other Netconf operation? What >>> other Netconf >>>>>>>> operation works with the syslog stream? Didn't we >>>>>>> explicitly decide it >>>>>>>> was not necessary to support access to notication >>>> streams >>>>>>>> (including syslog and SNMP streams)? >>>>>>>> >>>>>>>> I am also concerned that this access control "policy" >>>>>> should be an >>>>>>>> administrative one, not a hard choice of the protocol >>>>>> standard. In >>>pending on the access control model and >>> administrative >>>> policy." >>>> >>>>> Sharon >>>>> >>>>> -----Original Message----- >>>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>>> Sent: Wednesday, April 30, 2008 5:53 PM >>>>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; >>>>> netconf@ietf.org >>>>> Subject: RE: Issue X: access to notification content >>>>> >>>>> Hi, >>>>> >>>>> I don't think your proposed change addresses the security review >>>>> concern. It doesn't say how access will be controlled. >>>>> >>>>> I think my proposed text does, by saying it will be >>> handled by the >>>>> access control model and adminstrative policy. >>>>> >>>>> Is there a reason you don't find my proposed text acceptable? >>>>> >>>>> dbh >>>>> >>>>>> -----Original Message----- >>>>>> From: Sharon Chisholm [mailto:schishol@nortel.com] >>>>>> Sent: Wednesday, April 30, 2008 2:39 PM >>>>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org >>>>>> Subject: RE: Issue X: access to notification content >>>>>> >>>>>> Hi >>>>>> >>>>>> I can change from "she must not" to "she likely will >>> not". I think >>>>> the >>>>>> probably softens things too much. The intent is that you >>>>> only get to >>>>>> view content you have permission to view, regardless of >>> the access >>>>>> mechanisms. >>>>>> >>>>>> Sharon >>>>>> >>>>>> -----Original Message----- >>>>>> From: David B Harrington [mailto:dbharrington@comcast.net] >>>>>> Sent: Tuesday, April 29, 2008 10:25 AM >>>>>> To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); >>>>>> netconf@ietf.org >>>>>> Subject: RE: Issue X: access to notification content >>>>>> >>>>>> Hi, >>>>>> >>>>>> If it is only a discussion, then I suggest rewording >>> "she must not >>>>>> ..." >>>>>> to "she probably should not ... depending on the access >> control >>>>> model >>>>>> and administrative policy." >>>>>> >>>>>> This does not create a CLR. >>>>>> >>>>>> dbh >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >>>>>>> Sent: Tuesday, April 29, 2008 2:41 AM >>>>>>> To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org >>>>>>> Subject: RE: Issue X: access to notification content >>>>>>> >>>>>>> Dave, this is a clarification to an concern from an >>> IESG member. >>>>>>> It is in the "Security Considerations" section, so it is >>>>>> not a "hard >>>>>>> choice of protocol standard". We are explaining in >>> the security >>>>>>> considerations section what kind of access concerns >>> there might >>>>> be. >>>>>>> Does that clarify? >>>>>>> >>>>>>> Sharon, do you have other comments on Dave's concern? >>>>>>> >>>>>>> Bert Wijnen >>>>>>> >>>>>>>> -----Oorspronkelijk bericht----- >>>>>>>> Van: David B Harrington [mailto:dbharrington@comcast.net] >>>>>>>> Verzonden: maandag 28 april 2008 19:28 >>>>>>>> Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; >>> netconf@ietf.org >>>>>>>> Onderwerp: Issue X: access to notification content >>>>>>>> >>>>>>>> >>>>>>>> Hi bert, >>>>>>>> >>>>>>>> There were a bunch of issues I raised on 4/23 that I think >>>>>>> Sharon just >>>>>>>> didn't understand and didn't fix. here's one: >>>>>>>> >>>>>>>> -- >>>>>>>> In section 7, the text says "If a user does not have >>>>>>>> permission to view content via other NETCONF >> operations, >>>> she >>>>>> must >>>>>>>> not >>>>>>>> have access to that content via Notifications." >>>>>>>> >>>>>>>> This creates a big CLR. >>>>>>>> >>>>>>>> Can content from a syslog or SNMP notification stream be >>>>>> sent to a >>>>>>>> user that does not have permission to access the syslog or >>>> SNMP >>>>>>>> content using some other Netconf operation? What >>> other Netconf >>>>>>>> operation works with the syslog stream? Didn't we >>>>>>> explicitly decide it >>>>>>>> was not necessary to support access to notication >>>> streams >>>>>>>> (including syslog and SNMP streams)? >>>>>>>> >>>>>>>> I am also concerned that this access control "policy" >>>>>> should be an >>>>>>>> administrative one, not a hard choice of the protocol >>>>>> standard. >>>>> most cases it is the right choice. But a NOC manager >>>>>> might want to >>>>>>>> allow, say, the helpdesk to be alerted whenever a Netconf >>>> config >>>>>> is >>>>>>>> being changed, or an intrusion detection application to >>>>>> be alerted >>>>>>>> when there is an authentication failure. And yet, they may >>>>>>> not want to >>>>>>>> give the helpdesk or the IDS permissions. >>> With this CLR, >>>> a >>>>>> NOC >>>>>>>> manager is simply not allowed to make such a decision. >>>>>>>> >>>>>>>> I understand the intent; I think the wording is >>> poorly chosen, >>>>>>>> especially because it uses a "must", which has special >>>>>>> RFC2119 meaning >>>>>>>> and creates a huge CLR. And since access control will be >>>>>>> done later, I >>>>>>>> don't think the WG wants this CLR constraining all future >>>>>>> AC designs. >>>>>>>> But I could be wrong; maybe the WG will decide this >>> is exactly >>>>>> what >>>>>>>> they want to say. If that is the case, then I think we >> need >>>>>>> to review >>>>>>>> this document to make sure everything else (like syslog >>>> streams) >>>>>> can >>>>>>>> work with this CLR. >>>>>>>> >>>>>>>> dbh >>>>>>>> >>>>>>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> >> > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf In >>>>>>>> most cases it is the right choice. But a NOC manager >>>>>> might want to >>>>>>>> allow, say, the helpdesk to be alerted whenever a Netconf >>>> config >>>>>> is >>>>>>>> being changed, or an intrusion detection application to >>>>>> be alerted >>>>>>>> when there is an authentication failure. And yet, they may >>>>>>> not want to >>>>>>>> give the helpdesk or the IDS permissions. >>> With this CLR, >>>> a >>>>>> NOC >>>>>>>> manager is simply not allowed to make such a decision. >>>>>>>> >>>>>>>> I understand the intent; I think the wording is >>> poorly chosen, >>>>>>>> especially because it uses a "must", which has special >>>>>>> RFC2119 meaning >>>>>>>> and creates a huge CLR. And since access control will be >>>>>>> done later, I >>>>>>>> don't think the WG wants this CLR constraining all future >>>>>>> AC designs. >>>>>>>> But I could be wrong; maybe the WG will decide this >>> is exactly >>>>>> what >>>>>>>> they want to say. If that is the case, then I think we >> need >>>>>>> to review >>>>>>>> this document to make sure everything else (like syslog >>>> streams) >>>>>> can >>>>>>>> work with this CLR. >>>>>>>> >>>>>>>> dbh >>>>>>>> >>>>>>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> >> > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 10:51:03 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7803A684F; Thu, 8 May 2008 10:51:03 -0700 (PDT) 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 C4B503A684F for ; Thu, 8 May 2008 10:51:01 -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 NmHznSJU4tXR for ; Thu, 8 May 2008 10:51:00 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 352B73A67F5 for ; Thu, 8 May 2008 10:51:00 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id P4no1Z0020QkzPwA509U00; Thu, 08 May 2008 17:50:52 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id P5qt1Z00F4HwxpC8N00000; Thu, 08 May 2008 17:50:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=gUh9XYFHhvcA:10 a=lAxoPsH8wAIA:10 a=48vgC7mUAAAA:8 a=F1DCGv9N3iwSnLcj4u0A:9 a=LZn3Sofqs7CGTDR07egA:7 a=T9t217oBE4aPJ-afQlJlfHqBYm4A:4 a=ZPn7O4N2MpQA:10 a=lZB815dzVvQA:10 a=ucw2XimmUOMA:10 a=jFPUFpGHtmAA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Sharon Chisholm'" , "'Andy Bierman'" References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> <48232185.9020109@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> Date: Thu, 8 May 2008 13:50:53 -0400 Message-ID: <03fe01c8b134$10d2b800$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> Thread-Index: AcixI3FqzFIz3N/AT+G5KE56Q4xRhgAAeh/QAAN7DvA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, You need to read RFC2119 to understand the difference between stating a REQUIREMENT and making a RECOMMENDATION. I mentioned uisng RFC2119 langauge in one of my earleir messages, to make it unambiguous. "must" = REQUIREMENT "should" = RECOMMENDATION You keep wanting to use "must" and that makes it a REQUIREMENT of the protocol. It should NOT be a REQUIREMENT. If we want to say anything about matching to other operations, then we want to make a RECOMMENDATION, and use "should", not "must". dbh > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Thursday, May 08, 2008 12:09 PM > To: Andy Bierman; David B Harrington > Cc: Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: [Netconf] Issue X: access to notification content > > Hi > > Neither proposal A or B talk about other NETCONF operations. That text > is only in the before text. The difference between proposal A and > proposal B is that proposal A is making recommendations to prevent a > security issue (don't give people information they are not allowed to > see) and proposal B leaves open the option to have this security issue > (you may allow people to see information they are not allowed to see). > > Sharon > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, May 08, 2008 11:52 AM > To: David B Harrington > Cc: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > netconf@ietf.org > Subject: Re: [Netconf] Issue X: access to notification content > > David B Harrington wrote: > > Hi, > > > > I agree with Dave's concerns, and support his option (C) text. > > I don't even see what other NETCONF operations have to do with a > notification receiver application. I don't agree that any additional > security is provided by this MUST requirement. > > When user A attempts NETCONF operation , the agent will authorize > the RPC operation at that time. Why would the agent even > check if > would be authorized in the future, when the user requests operation > ? I don't know much about security, but it seems to be a total > waste of time to do this. > > > Andy > > > > I am NOT OK with option A. Notifications in syslog and in SNMP are > > normally sent to an application, which filters and aggregates the > > notifications. Such an application might alert an operator to > > important notifications, but many just get logged for later > analysis. > > > > With the MUST formulation in option A, it becomes a protocol > > REQUIREMENT that such application/users CANNOT receive > notifications > > UNLESS that application is also allowed to perform other Netconf > > operations. > > > > Syslog and SNMP do not contain such a crappy little rule; > > Administrators can decide that syslog notifications and/or SNMP > > notifications can be sent to a principal that has no other > permissions > > > within syslog or SNMP. But if the operator decides to have > syslog or > > SNMP information carried over Nertconf, then they MUST give the > > receiving principal permission to use some other Netconf operation. > > > > WHY do we need to allow such an application to perform > other Netconf > > operations? It should be an administrative policy decision to allow > > notifications to be sent to a principal that has no other > operational > > permission in Netconf. > > > > I don't like option B simply because I don't like the way > it has been > > worded. I suggest: > > > > Proposed Text (C) > > > > "The contents of notifications as well as the names of > event streams > > may contain sensitive information and care should be taken > to ensure > > that they are viewed only by authorized users. It is an > administrative > > > policy decision to determine who (or what) is authorized to have > > access to the information contained in notifications. It is > > RECOMMENDED that if a user is not authorized to view the content in > > the notification via other Newtconf operations, then they > SHOULD NOT > > be authorized to have access to that content via Netconf > > notifications. If a user is not authorized to view all > elements in the > > > content of the notification, the notification is not sent to that > > user." > > > > dbh > > > >> -----Original Message----- > >> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > >> Sent: Thursday, May 08, 2008 3:53 AM > >> To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; > >> netconf@ietf.org > >> Subject: RE: [Netconf] Issue X: access to notification content > >> > >> I am OK with option/proposal A > >> > >> Bert Wijnen > >> > >>> -----Oorspronkelijk bericht----- > >>> Van: Sharon Chisholm [mailto:schishol@nortel.com] > >>> Verzonden: woensdag 7 mei 2008 15:30 > >>> Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > >>> Onderwerp: RE: [Netconf] Issue X: access to notification content > >>> > >>> > >>> Hi > >>> > >>> If there is no objection to proposal A then I will proceed > >> to make this > >>> change and publish the updated draft. > >>> > >>> Sharon > >>> > >>> -----Original Message----- > >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > > On > >>> Behalf Of Chisholm, Sharon (CAR:ZZ00) > >>> Sent: Monday, May 05, 2008 8:33 AM > >>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > >>> Subject: Re: [Netconf] Issue X: access to notification content > >>> > >>> Hi > >>> > >>> I think it would be helpful to go back to original text we > >> are editing > >>> rather then the snippets. I've modified the second sentence > >> in ways that > >>> I think address the access versus authorization confusion > >> and I think > >>> makes it so we can keep the 'must not'. I think now we don't need > > to > >>> 'depending on access control..." part because we are make a > >>> recommendation about the access control in order to maintain > > minimal > >>> security. I've added a third option which tries to include those > > for > >>> comparison. I prefer A. > >>> > >>> Current text > >>> > >>> The contents of notifications as well as the name of event streams > >>> may contain sensitive information and care should be > >> taken to ensure > >>> that it is viewed only by authorized users. If a user > >> does not have > >>> permission to view content via other NETCONF operations, > >> she must not > >>> have access to that content via Notifications. If a user is > > not > >>> permitted to view one element in the content of the > >> notification, the > >>> notification is not sent to that user. > >>> > >>> Proposed text (A) > >>> > >>> The contents of notifications as well as the name of event streams > >>> may contain sensitive information and care should be > >> taken to ensure > >>> that it is viewed only by authorized users. If a user > >> does not have > >>> permission to view the information in the notification, > >> they must not > >>> have access to that content via Notifications. If a user is > > not > >>> permitted to view one element in the content of the > >> notification, the > >>> notification is not sent to that user. > >>> > >>> Proposed text (B) > >>> > >>> The contents of notifications as well as the name of event streams > >>> may contain sensitive information and care should be > >> taken to ensure > >>> that it is viewed only by authorized users. If a user > >> does not have > >>> permission to view the information in the notification, > >> the access > >>> control model and administrative policy probably should not > >>> allow them access to that content via Notifications. If > >> a user is > >>> not > >>> permitted to view one element in the content of the > >> notification, the > >>> notification is not sent to that user. > >>> > >>> I also got rid of the 'she' thing since I think the singular use > > of > >>> 'they' is now grammatically acceptable in these cases. > >>> > >>> Sharon > >>> > >>> -----Original Message----- > >>> From: David B Harrington [mailto:dbharrington@comcast.net] > >>> Sent: Friday, May 02, 2008 1:41 PM > >>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > >> netconf@ietf.org > >>> Subject: RE: Issue X: access to notification content > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Sharon Chisholm [mailto:schishol@nortel.com] > >>>> Sent: Friday, May 02, 2008 11:22 AM > >>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > >>>> Subject: RE: Issue X: access to notification content > >>>> > >>>> By proposed text, did you mean: > >>>> > >>>> "she probably should not ... depending on the access control > > model > >>> and > >>>> administrative policy." > >>>> > >>>> Which I proposed to change to > >>>> > >>>> "she likely will not ... depending on the access control > >> model and > >>>> administrative policy." > >>> That is not what your earlier response said. The proposal in your > >>> response did not include the text after the ellipsis. > >>> > >>> I prefer "she probably should not" because "should not" > is RFC2119 > >>> language. > >>> You might want to stiffen that slightly by making it "she > probably > >>> SHOULD NOT ... depending on the access control model and > >> administrative > >>> policy." > >>> > >>>> Sharon > >>>> > >>>> -----Original Message----- > >>>> From: David B Harrington [mailto:dbharrington@comcast.net] > >>>> Sent: Wednesday, April 30, 2008 5:53 PM > >>>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > >>>> netconf@ietf.org > >>>> Subject: RE: Issue X: access to notification content > >>>> > >>>> Hi, > >>>> > >>>> I don't think your proposed change addresses the security review > > > >>>> concern. It doesn't say how access will be controlled. > >>>> > >>>> I think my proposed text does, by saying it will be > >> handled by the > >>>> access control model and adminstrative policy. > >>>> > >>>> Is there a reason you don't find my proposed text acceptable? > >>>> > >>>> dbh > >>>> > >>>>> -----Original Message----- > >>>>> From: Sharon Chisholm [mailto:schishol@nortel.com] > >>>>> Sent: Wednesday, April 30, 2008 2:39 PM > >>>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > >>>>> Subject: RE: Issue X: access to notification content > >>>>> > >>>>> Hi > >>>>> > >>>>> I can change from "she must not" to "she likely will > >> not". I think > >>>> the > >>>>> probably softens things too much. The intent is that you > >>>> only get to > >>>>> view content you have permission to view, regardless of > >> the access > >>>>> mechanisms. > >>>>> > >>>>> Sharon > >>>>> > >>>>> -----Original Message----- > >>>>> From: David B Harrington [mailto:dbharrington@comcast.net] > >>>>> Sent: Tuesday, April 29, 2008 10:25 AM > >>>>> To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > >>>>> netconf@ietf.org > >>>>> Subject: RE: Issue X: access to notification content > >>>>> > >>>>> Hi, > >>>>> > >>>>> If it is only a discussion, then I suggest rewording > >> "she must not > >>>>> ..." > >>>>> to "she probably should not ... depending on the access > > control > >>>> model > >>>>> and administrative policy." > >>>>> > >>>>> This does not create a CLR. > >>>>> > >>>>> dbh > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > >>>>>> Sent: Tuesday, April 29, 2008 2:41 AM > >>>>>> To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > >>>>>> Subject: RE: Issue X: access to notification content > >>>>>> > >>>>>> Dave, this is a clarification to an concern from an > >> IESG member. > >>>>>> It is in the "Security Considerations" section, so it is > >>>>> not a "hard > >>>>>> choice of protocol standard". We are explaining in > >> the security > >>>>>> considerations section what kind of access concerns > >> there might > >>>> be. > >>>>>> Does that clarify? > >>>>>> > >>>>>> Sharon, do you have other comments on Dave's concern? > >>>>>> > >>>>>> Bert Wijnen > >>>>>> > >>>>>>> -----Oorspronkelijk bericht----- > >>>>>>> Van: David B Harrington [mailto:dbharrington@comcast.net] > >>>>>>> Verzonden: maandag 28 april 2008 19:28 > >>>>>>> Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; > >> netconf@ietf.org > >>>>>>> Onderwerp: Issue X: access to notification content > >>>>>>> > >>>>>>> > >>>>>>> Hi bert, > >>>>>>> > >>>>>>> There were a bunch of issues I raised on 4/23 that I think > >>>>>> Sharon just > >>>>>>> didn't understand and didn't fix. here's one: > >>>>>>> > >>>>>>> -- > >>>>>>> In section 7, the text says "If a user does not have > >>>>>>> permission to view content via other NETCONF > > operations, > >>> she > >>>>> must > >>>>>>> not > >>>>>>> have access to that content via Notifications." > >>>>>>> > >>>>>>> This creates a big CLR. > >>>>>>> > >>>>>>> Can content from a syslog or SNMP notification stream be > >>>>> sent to a > >>>>>>> user that does not have permission to access the syslog or > >>> SNMP > >>>>>>> content using some other Netconf operation? What > >> other Netconf > >>>>>>> operation works with the syslog stream? Didn't we > >>>>>> explicitly decide it > >>>>>>> was not necessary to support access to notication > >>> streams > >>>>>>> (including syslog and SNMP streams)? > >>>>>>> > >>>>>>> I am also concerned that this access control "policy" > >>>>> should be an > >>>>>>> administrative one, not a hard choice of the protocol > >>>>> standard. In > >>>>>>> most cases it is the right choice. But a NOC manager > >>>>> might want to > >>>>>>> allow, say, the helpdesk to be alerted whenever a Netconf > >>> config > >>>>> is > >>>>>>> being changed, or an intrusion detection application to > >>>>> be alerted > >>>>>>> when there is an authentication failure. And yet, they may > >>>>>> not want to > >>>>>>> give the helpdesk or the IDS permissions. > >> With this CLR, > >>> a > >>>>> NOC > >>>>>>> manager is simply not allowed to make such a decision. > >>>>>>> > >>>>>>> I understand the intent; I think the wording is > >> poorly chosen, > >>>>>>> especially because it uses a "must", which has special > >>>>>> RFC2119 meaning > >>>>>>> and creates a huge CLR. And since access control will be > >>>>>> done later, I > >>>>>>> don't think the WG wants this CLR constraining all future > >>>>>> AC designs. > >>>>>>> But I could be wrong; maybe the WG will decide this > >> is exactly > >>>>> what > >>>>>>> they want to say. If that is the case, then I think we > > need > >>>>>> to review > >>>>>>> this document to make sure everything else (like syslog > >>> streams) > >>>>> can > >>>>>>> work with this CLR. > >>>>>>> > >>>>>>> dbh > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >>> > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 10:51:03 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7803A684F; Thu, 8 May 2008 10:51:03 -0700 (PDT) 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 C4B503A684F for ; Thu, 8 May 2008 10:51:01 -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 NmHznSJU4tXR for ; Thu, 8 May 2008 10:51:00 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 352B73A67F5 for ; Thu, 8 May 2008 10:51:00 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id P4no1Z0020QkzPwA509U00; Thu, 08 May 2008 17:50:52 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id P5qt1Z00F4HwxpC8N00000; Thu, 08 May 2008 17:50:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=gUh9XYFHhvcA:10 a=lAxoPsH8wAIA:10 a=48vgC7mUAAAA:8 a=F1DCGv9N3iwSnLcj4u0A:9 a=LZn3Sofqs7CGTDR07egA:7 a=T9t217oBE4aPJ-afQlJlfHqBYm4A:4 a=ZPn7O4N2MpQA:10 a=lZB815dzVvQA:10 a=ucw2XimmUOMA:10 a=jFPUFpGHtmAA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Sharon Chisholm'" , "'Andy Bierman'" References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> <48232185.9020109@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> Date: Thu, 8 May 2008 13:50:53 -0400 Message-ID: <03fe01c8b134$10d2b800$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> Thread-Index: AcixI3FqzFIz3N/AT+G5KE56Q4xRhgAAeh/QAAN7DvA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, You need to read RFC2119 to understand the difference between stating a REQUIREMENT and making a RECOMMENDATION. I mentioned uisng RFC2119 langauge in one of my earleir messages, to make it unambiguous. "must" = REQUIREMENT "should" = RECOMMENDATION You keep wanting to use "must" and that makes it a REQUIREMENT of the protocol. It should NOT be a REQUIREMENT. If we want to say anything about matching to other operations, then we want to make a RECOMMENDATION, and use "should", not "must". dbh > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Thursday, May 08, 2008 12:09 PM > To: Andy Bierman; David B Harrington > Cc: Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: [Netconf] Issue X: access to notification content > > Hi > > Neither proposal A or B talk about other NETCONF operations. That text > is only in the before text. The difference between proposal A and > proposal B is that proposal A is making recommendations to prevent a > security issue (don't give people information they are not allowed to > see) and proposal B leaves open the option to have this security issue > (you may allow people to see information they are not allowed to see). > > Sharon > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Thursday, May 08, 2008 11:52 AM > To: David B Harrington > Cc: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > netconf@ietf.org > Subject: Re: [Netconf] Issue X: access to notification content > > David B Harrington wrote: > > Hi, > > > > I agree with Dave's concerns, and support his option (C) text. > > I don't even see what other NETCONF operations have to do with a > notification receiver application. I don't agree that any additional > security is provided by this MUST requirement. > > When user A attempts NETCONF operation , the agent will authorize > the RPC operation at that time. Why would the agent even > check if > would be authorized in the future, when the user requests operation > ? I don't know much about security, but it seems to be a total > waste of time to do this. > > > Andy > > > > I am NOT OK with option A. Notifications in syslog and in SNMP are > > normally sent to an application, which filters and aggregates the > > notifications. Such an application might alert an operator to > > important notifications, but many just get logged for later > analysis. > > > > With the MUST formulation in option A, it becomes a protocol > > REQUIREMENT that such application/users CANNOT receive > notifications > > UNLESS that application is also allowed to perform other Netconf > > operations. > > > > Syslog and SNMP do not contain such a crappy little rule; > > Administrators can decide that syslog notifications and/or SNMP > > notifications can be sent to a principal that has no other > permissions > > > within syslog or SNMP. But if the operator decides to have > syslog or > > SNMP information carried over Nertconf, then they MUST give the > > receiving principal permission to use some other Netconf operation. > > > > WHY do we need to allow such an application to perform > other Netconf > > operations? It should be an administrative policy decision to allow > > notifications to be sent to a principal that has no other > operational > > permission in Netconf. > > > > I don't like option B simply because I don't like the way > it has been > > worded. I suggest: > > > > Proposed Text (C) > > > > "The contents of notifications as well as the names of > event streams > > may contain sensitive information and care should be taken > to ensure > > that they are viewed only by authorized users. It is an > administrative > > > policy decision to determine who (or what) is authorized to have > > access to the information contained in notifications. It is > > RECOMMENDED that if a user is not authorized to view the content in > > the notification via other Newtconf operations, then they > SHOULD NOT > > be authorized to have access to that content via Netconf > > notifications. If a user is not authorized to view all > elements in the > > > content of the notification, the notification is not sent to that > > user." > > > > dbh > > > >> -----Original Message----- > >> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > >> Sent: Thursday, May 08, 2008 3:53 AM > >> To: Sharon Chisholm; David B Harrington; Bert Wijnen - IETF; > >> netconf@ietf.org > >> Subject: RE: [Netconf] Issue X: access to notification content > >> > >> I am OK with option/proposal A > >> > >> Bert Wijnen > >> > >>> -----Oorspronkelijk bericht----- > >>> Van: Sharon Chisholm [mailto:schishol@nortel.com] > >>> Verzonden: woensdag 7 mei 2008 15:30 > >>> Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > >>> Onderwerp: RE: [Netconf] Issue X: access to notification content > >>> > >>> > >>> Hi > >>> > >>> If there is no objection to proposal A then I will proceed > >> to make this > >>> change and publish the updated draft. > >>> > >>> Sharon > >>> > >>> -----Original Message----- > >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] > > On > >>> Behalf Of Chisholm, Sharon (CAR:ZZ00) > >>> Sent: Monday, May 05, 2008 8:33 AM > >>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > >>> Subject: Re: [Netconf] Issue X: access to notification content > >>> > >>> Hi > >>> > >>> I think it would be helpful to go back to original text we > >> are editing > >>> rather then the snippets. I've modified the second sentence > >> in ways that > >>> I think address the access versus authorization confusion > >> and I think > >>> makes it so we can keep the 'must not'. I think now we don't need > > to > >>> 'depending on access control..." part because we are make a > >>> recommendation about the access control in order to maintain > > minimal > >>> security. I've added a third option which tries to include those > > for > >>> comparison. I prefer A. > >>> > >>> Current text > >>> > >>> The contents of notifications as well as the name of event streams > >>> may contain sensitive information and care should be > >> taken to ensure > >>> that it is viewed only by authorized users. If a user > >> does not have > >>> permission to view content via other NETCONF operations, > >> she must not > >>> have access to that content via Notifications. If a user is > > not > >>> permitted to view one element in the content of the > >> notification, the > >>> notification is not sent to that user. > >>> > >>> Proposed text (A) > >>> > >>> The contents of notifications as well as the name of event streams > >>> may contain sensitive information and care should be > >> taken to ensure > >>> that it is viewed only by authorized users. If a user > >> does not have > >>> permission to view the information in the notification, > >> they must not > >>> have access to that content via Notifications. If a user is > > not > >>> permitted to view one element in the content of the > >> notification, the > >>> notification is not sent to that user. > >>> > >>> Proposed text (B) > >>> > >>> The contents of notifications as well as the name of event streams > >>> may contain sensitive information and care should be > >> taken to ensure > >>> that it is viewed only by authorized users. If a user > >> does not have > >>> permission to view the information in the notification, > >> the access > >>> control model and administrative policy probably should not > >>> allow them access to that content via Notifications. If > >> a user is > >>> not > >>> permitted to view one element in the content of the > >> notification, the > >>> notification is not sent to that user. > >>> > >>> I also got rid of the 'she' thing since I think the singular use > > of > >>> 'they' is now grammatically acceptable in these cases. > >>> > >>> Sharon > >>> > >>> -----Original Message----- > >>> From: David B Harrington [mailto:dbharrington@comcast.net] > >>> Sent: Friday, May 02, 2008 1:41 PM > >>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > >> netconf@ietf.org > >>> Subject: RE: Issue X: access to notification content > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Sharon Chisholm [mailto:schishol@nortel.com] > >>>> Sent: Friday, May 02, 2008 11:22 AM > >>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > >>>> Subject: RE: Issue X: access to notification content > >>>> > >>>> By proposed text, did you mean: > >>>> > >>>> "she probably should not ... depending on the access control > > model > >>> and > >>>> administrative policy." > >>>> > >>>> Which I proposed to change to > >>>> > >>>> "she likely will not ... depending on the access control > >> model and > >>>> administrative policy." > >>> That is not what your earlier response said. The proposal in your > >>> response did not include the text after the ellipsis. > >>> > >>> I prefer "she probably should not" because "should not" > is RFC2119 > >>> language. > >>> You might want to stiffen that slightly by making it "she > probably > >>> SHOULD NOT ... depending on the access control model and > >> administrative > >>> policy." > >>> > >>>> Sharon > >>>> > >>>> -----Original Message----- > >>>> From: David B Harrington [mailto:dbharrington@comcast.net] > >>>> Sent: Wednesday, April 30, 2008 5:53 PM > >>>> To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > >>>> netconf@ietf.org > >>>> Subject: RE: Issue X: access to notification content > >>>> > >>>> Hi, > >>>> > >>>> I don't think your proposed change addresses the security review > > > >>>> concern. It doesn't say how access will be controlled. > >>>> > >>>> I think my proposed text does, by saying it will be > >> handled by the > >>>> access control model and adminstrative policy. > >>>> > >>>> Is there a reason you don't find my proposed text acceptable? > >>>> > >>>> dbh > >>>> > >>>>> -----Original Message----- > >>>>> From: Sharon Chisholm [mailto:schishol@nortel.com] > >>>>> Sent: Wednesday, April 30, 2008 2:39 PM > >>>>> To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > >>>>> Subject: RE: Issue X: access to notification content > >>>>> > >>>>> Hi > >>>>> > >>>>> I can change from "she must not" to "she likely will > >> not". I think > >>>> the > >>>>> probably softens things too much. The intent is that you > >>>> only get to > >>>>> view content you have permission to view, regardless of > >> the access > >>>>> mechanisms. > >>>>> > >>>>> Sharon > >>>>> > >>>>> -----Original Message----- > >>>>> From: David B Harrington [mailto:dbharrington@comcast.net] > >>>>> Sent: Tuesday, April 29, 2008 10:25 AM > >>>>> To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > >>>>> netconf@ietf.org > >>>>> Subject: RE: Issue X: access to notification content > >>>>> > >>>>> Hi, > >>>>> > >>>>> If it is only a discussion, then I suggest rewording > >> "she must not > >>>>> ..." > >>>>> to "she probably should not ... depending on the access > > control > >>>> model > >>>>> and administrative policy." > >>>>> > >>>>> This does not create a CLR. > >>>>> > >>>>> dbh > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > >>>>>> Sent: Tuesday, April 29, 2008 2:41 AM > >>>>>> To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > >>>>>> Subject: RE: Issue X: access to notification content > >>>>>> > >>>>>> Dave, this is a clarification to an concern from an > >> IESG member. > >>>>>> It is in the "Security Considerations" section, so it is > >>>>> not a "hard > >>>>>> choice of protocol standard". We are explaining in > >> the security > >>>>>> considerations section what kind of access concerns > >> there might > >>>> be. > >>>>>> Does that clarify? > >>>>>> > >>>>>> Sharon, do you have other comments on Dave's concern? > >>>>>> > >>>>>> Bert Wijnen > >>>>>> > >>>>>>> -----Oorspronkelijk bericht----- > >>>>>>> Van: David B Harrington [mailto:dbharrington@comcast.net] > >>>>>>> Verzonden: maandag 28 april 2008 19:28 > >>>>>>> Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; > >> netconf@ietf.org > >>>>>>> Onderwerp: Issue X: access to notification content > >>>>>>> > >>>>>>> > >>>>>>> Hi bert, > >>>>>>> > >>>>>>> There were a bunch of issues I raised on 4/23 that I think > >>>>>> Sharon just > >>>>>>> didn't understand and didn't fix. here's one: > >>>>>>> > >>>>>>> -- > >>>>>>> In section 7, the text says "If a user does not have > >>>>>>> permission to view content via other NETCONF > > operations, > >>> she > >>>>> must > >>>>>>> not > >>>>>>> have access to that content via Notifications." > >>>>>>> > >>>>>>> This creates a big CLR. > >>>>>>> > >>>>>>> Can content from a syslog or SNMP notification stream be > >>>>> sent to a > >>>>>>> user that does not have permission to access the syslog or > >>> SNMP > >>>>>>> content using some other Netconf operation? What > >> other Netconf > >>>>>>> operation works with the syslog stream? Didn't we > >>>>>> explicitly decide it > >>>>>>> was not necessary to support access to notication > >>> streams > >>>>>>> (including syslog and SNMP streams)? > >>>>>>> > >>>>>>> I am also concerned that this access control "policy" > >>>>> should be an > >>>>>>> administrative one, not a hard choice of the protocol > >>>>> standard. In > >>>>>>> most cases it is the right choice. But a NOC manager > >>>>> might want to > >>>>>>> allow, say, the helpdesk to be alerted whenever a Netconf > >>> config > >>>>> is > >>>>>>> being changed, or an intrusion detection application to > >>>>> be alerted > >>>>>>> when there is an authentication failure. And yet, they may > >>>>>> not want to > >>>>>>> give the helpdesk or the IDS permissions. > >> With this CLR, > >>> a > >>>>> NOC > >>>>>>> manager is simply not allowed to make such a decision. > >>>>>>> > >>>>>>> I understand the intent; I think the wording is > >> poorly chosen, > >>>>>>> especially because it uses a "must", which has special > >>>>>> RFC2119 meaning > >>>>>>> and creates a huge CLR. And since access control will be > >>>>>> done later, I > >>>>>>> don't think the WG wants this CLR constraining all future > >>>>>> AC designs. > >>>>>>> But I could be wrong; maybe the WG will decide this > >> is exactly > >>>>> what > >>>>>>> they want to say. If that is the case, then I think we > > need > >>>>>> to review > >>>>>>> this document to make sure everything else (like syslog > >>> streams) > >>>>> can > >>>>>>> work with this CLR. > >>>>>>> > >>>>>>> dbh > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >>> > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 11:26:40 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8643A6AFA; Thu, 8 May 2008 11:26:40 -0700 (PDT) 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 8A7B93A69AB for ; Thu, 8 May 2008 11:26:39 -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 SSuO9gUwKTa0 for ; Thu, 8 May 2008 11:26:38 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id B54833A66B4 for ; Thu, 8 May 2008 11:26:38 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id P50B1Z04g16AWCUA202Y00; Thu, 08 May 2008 18:24:34 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id P6Sa1Z00L4HwxpC8S00000; Thu, 08 May 2008 18:26:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=gUh9XYFHhvcA:10 a=lAxoPsH8wAIA:10 a=-lRRmDRuUDBm9SQvrf0A:9 a=6kFFjKUiDQY37k8V0BwA:7 a=lB7oOGUTNuYJhqPYOosyDNFVUNcA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'Andy Bierman'" , "'Sharon Chisholm'" References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> <48232185.9020109@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> <482334BA.2060303@andybierman.com> Date: Thu, 8 May 2008 14:26:34 -0400 Message-ID: <03ff01c8b139$0ce6be80$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <482334BA.2060303@andybierman.com> Thread-Index: AcixLt+3BZGvNiGuRdiu6OENoT2zLwABb5CA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > oops -- I was confused. I thought the paragraph dealt with > other NETCONF operations, but I see that is Dave's text, not > (A) or (B). Read the "current text" again, Andy. The current text specifies: "If a user does not have permission to view content via other NETCONF operations, she must not have access to that content via Notifications." I object to this for multiple independent reasons: 1) "must" is an RFC2119 reserved word. Using it here makes this a REQUIREMENT. 2) Access control mechanisms are out of scope at this time. So we should not state any REQUIREMENTS about how access control "must" work. 3) the current text makes notification access control dependent on the access controls used for other operations. Andy, I think this is a bad idea, for reasons similar to those you mention. 4) authorization to view information should be an adminstrative decision, not a protocol decision. 5) Netcofn notifications were designed to carry syslog and SNMP notifications streams. We should not impose the access control requirement that is specified in the "current text" for syslog and/or SNMP content. > > I actually don't like any of the choices. I don't like any of the choices either. The Proposed text (C) was a concession to Sharon's unwillingness to remove the dependence on other operations. In the REQUIREMENT in Sharon's (A), is access via SNMP-GET or syslog logging acceptable as the "permission to view the information" - I think that a dependency on access control mechanisms in other protocols would be even worse than "permission to view content via other NETCONF operations". here is another proposed text to replace the original text: Proposed Text (D) "The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. It is an administrative policy decision to determine who (or what) is authorized to have access to the information contained in notifications. If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." I could also live with the nice simple Proposed Text (E) "The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." I could also live with the even simpler: "The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users." And then leave it up future access control mechanisms to determine authorization. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 11:26:40 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8643A6AFA; Thu, 8 May 2008 11:26:40 -0700 (PDT) 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 8A7B93A69AB for ; Thu, 8 May 2008 11:26:39 -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 SSuO9gUwKTa0 for ; Thu, 8 May 2008 11:26:38 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id B54833A66B4 for ; Thu, 8 May 2008 11:26:38 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id P50B1Z04g16AWCUA202Y00; Thu, 08 May 2008 18:24:34 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id P6Sa1Z00L4HwxpC8S00000; Thu, 08 May 2008 18:26:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=gUh9XYFHhvcA:10 a=lAxoPsH8wAIA:10 a=-lRRmDRuUDBm9SQvrf0A:9 a=6kFFjKUiDQY37k8V0BwA:7 a=lB7oOGUTNuYJhqPYOosyDNFVUNcA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'Andy Bierman'" , "'Sharon Chisholm'" References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> <48232185.9020109@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> <482334BA.2060303@andybierman.com> Date: Thu, 8 May 2008 14:26:34 -0400 Message-ID: <03ff01c8b139$0ce6be80$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <482334BA.2060303@andybierman.com> Thread-Index: AcixLt+3BZGvNiGuRdiu6OENoT2zLwABb5CA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > oops -- I was confused. I thought the paragraph dealt with > other NETCONF operations, but I see that is Dave's text, not > (A) or (B). Read the "current text" again, Andy. The current text specifies: "If a user does not have permission to view content via other NETCONF operations, she must not have access to that content via Notifications." I object to this for multiple independent reasons: 1) "must" is an RFC2119 reserved word. Using it here makes this a REQUIREMENT. 2) Access control mechanisms are out of scope at this time. So we should not state any REQUIREMENTS about how access control "must" work. 3) the current text makes notification access control dependent on the access controls used for other operations. Andy, I think this is a bad idea, for reasons similar to those you mention. 4) authorization to view information should be an adminstrative decision, not a protocol decision. 5) Netcofn notifications were designed to carry syslog and SNMP notifications streams. We should not impose the access control requirement that is specified in the "current text" for syslog and/or SNMP content. > > I actually don't like any of the choices. I don't like any of the choices either. The Proposed text (C) was a concession to Sharon's unwillingness to remove the dependence on other operations. In the REQUIREMENT in Sharon's (A), is access via SNMP-GET or syslog logging acceptable as the "permission to view the information" - I think that a dependency on access control mechanisms in other protocols would be even worse than "permission to view content via other NETCONF operations". here is another proposed text to replace the original text: Proposed Text (D) "The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. It is an administrative policy decision to determine who (or what) is authorized to have access to the information contained in notifications. If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." I could also live with the nice simple Proposed Text (E) "The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user." I could also live with the even simpler: "The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users." And then leave it up future access control mechanisms to determine authorization. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 13:05:02 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE743A6858; Thu, 8 May 2008 13:05:02 -0700 (PDT) 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 34CA33A6A54 for ; Thu, 8 May 2008 13:05:00 -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.675, 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 2ToIM6xP-Gsy for ; Thu, 8 May 2008 13:04:58 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 510B53A6858 for ; Thu, 8 May 2008 13:04:58 -0700 (PDT) Received: (qmail 33861 invoked from network); 8 May 2008 20:04:56 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 8 May 2008 20:04:56 -0000 From: "Bert Wijnen - IETF" To: "Sharon Chisholm" , "David B Harrington" , , "Eliot Lear" Date: Thu, 8 May 2008 22:05:00 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4146E002D@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I am OK with option 2 Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Sharon Chisholm > Verzonden: woensdag 7 mei 2008 15:31 > Aan: David B Harrington; j.schoenwaelder@jacobs-university.de; Eliot > Lear > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > Issues > > > Hi > > If there is no objection to option 2 then I will make the change and > publish the updated draft. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Monday, May 05, 2008 8:06 AM > To: David B Harrington; j.schoenwaelder@jacobs-university.de; Eliot Lear > Cc: netconf@ietf.org > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > Issues > > Hi > > Just to close this off. It seems we are converging on not adding the ISO > reference but just the RFC. (Note the RFC references the ISO > specification and attempts to remove some ambiguities). Just to clarify > what people want to do > > 1) Keep both references > 2) Just have a reference to RFC3339 > 3) Just have a reference to RFC3339 section 4.4 and appendix A > 4) Just have a reference to RFC3339 section 4.4 > 5) Just have a reference to RFC339 appendix A > > Sharon > > -----Original Message----- > From: netconFrom netconf-bounces@ietf.org Thu May 8 13:05:02 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE743A6858; Thu, 8 May 2008 13:05:02 -0700 (PDT) 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 34CA33A6A54 for ; Thu, 8 May 2008 13:05:00 -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.675, 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 2ToIM6xP-Gsy for ; Thu, 8 May 2008 13:04:58 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 510B53A6858 for ; Thu, 8 May 2008 13:04:58 -0700 (PDT) Received: (qmail 33861 invoked from network); 8 May 2008 20:04:56 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 8 May 2008 20:04:56 -0000 From: "Bert Wijnen - IETF" To: "Sharon Chisholm" , "David B Harrington" , , "Eliot Lear" Date: Thu, 8 May 2008 22:05:00 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4146E002D@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I am OK with option 2 Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Sharon Chisholm > Verzonden: woensdag 7 mei 2008 15:31 > Aan: David B Harrington; j.schoenwaelder@jacobs-university.de; Eliot > Lear > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > Issues > > > Hi > > If there is no objection to option 2 then I will make the change and > publish the updated draft. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Monday, May 05, 2008 8:06 AM > To: David B Harrington; j.schoenwaelder@jacobs-university.de; Eliot Lear > Cc: netconf@ietf.org > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > Issues > > Hi > > Just to close this off. It seems we are converging on not adding the ISO > reference but just the RFC. (Note the RFC references the ISO > specification and attempts to remove some ambiguities). Just to clarify > what people want to do > > 1) Keep both references > 2) Just have a reference to RFC3339 > 3) Just have a reference to RFC3339 section 4.4 and appendix A > 4) Just have a reference to RFC3339 section 4.4 > 5) Just have a reference to RFC339 appendix A > > Sharon > > -----Original Message----- > From: netconf-bounf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of David B Harrington > Sent: Monday, April 28, 2008 1:28 PM > To: j.schoenwaelder@jacobs-university.de; 'Eliot Lear' > Cc: netconf@ietf.org > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > Issues > > I believe we should follow RFC3339 section 4.4 > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > > Sent: Friday, April 25, 2008 7:44 AM > > To: Eliot Lear > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > > > Issues > > > > On Fri, Apr 25, 2008 at 01:29:57PM +0200, Eliot Lear wrote: > > > Hi Sharon, > > > > > > This comment is largely bureaucratic: > > > > > > > Proposed Edits > > > > -------------- > > > > > > > > A. In section 2.1.1, for both instances and in section > > 2.2.1 Replace > > > > This parameter is of type dateTime. > > > > With > > > > This parameter is of type dateTime and compliant to > > [RFC3339] and > > > > [ISO.8601.1988]. > > > > > > > > > > RFC 3339 specifically uses a subset of ISO.8601.1988. As this > > > discussion illustrates it is possible to construct times that are > > > compliant with the latter and non-compliant with the > > former. I believe > > > that ISO.8601.1988 is a superset of RFC 3339. If you wish > > compliance > > > with "both", my recommendation would be to specify only > > ISO.8601.1988. > > > This would meet Juergen's requirement of being able to specify an > > > unqualified timezone. > > > > > > ALTERNATIVELY, you could require times to be in > > ISO.8601.1988 format, as > > > specified in Appendix A of RFC 3339. > > > > > > Pointing at two standards covering the precise same > > specification is > > > just asking for a poke in the eye. > > > > Good bureaucratic comment. Reading section 4.4 or RFC 3339, I should > > probably shut up and be fine with requiring a timezone to be known > by > > a conforming device and then we can perhaps go with the RFC 3339 > > subset. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of David B Harrington > Sent: Monday, April 28, 2008 1:28 PM > To: j.schoenwaelder@jacobs-university.de; 'Eliot Lear' > Cc: netconf@ietf.org > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > Issues > > I believe we should follow RFC3339 section 4.4 > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > > Sent: Friday, April 25, 2008 7:44 AM > > To: Eliot Lear > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss > > > Issues > > > > On Fri, Apr 25, 2008 at 01:29:57PM +0200, Eliot Lear wrote: > > > Hi Sharon, > > > > > > This comment is largely bureaucratic: > > > > > > > Proposed Edits > > > > -------------- > > > > > > > > A. In section 2.1.1, for both instances and in section > > 2.2.1 Replace > > > > This parameter is of type dateTime. > > > > With > > > > This parameter is of type dateTime and compliant to > > [RFC3339] and > > > > [ISO.8601.1988]. > > > > > > > > > > RFC 3339 specifically uses a subset of ISO.8601.1988. As this > > > discussion illustrates it is possible to construct times that are > > > compliant with the latter and non-compliant with the > > former. I believe > > > that ISO.8601.1988 is a superset of RFC 3339. If you wish > > compliance > > > with "both", my recommendation would be to specify only > > ISO.8601.1988. > > > This would meet Juergen's requirement of being able to specify an > > > unqualified timezone. > > > > > > ALTERNATIVELY, you could require times to be in > > ISO.8601.1988 format, as > > > specified in Appendix A of RFC 3339. > > > > > > Pointing at two standards covering the precise same > > specification is > > > just asking for a poke in the eye. > > > > Good bureaucratic comment. Reading section 4.4 or RFC 3339, I should > > probably shut up and be fine with requiring a timezone to be known > by > > a conforming device and then we can perhaps go with the RFC 3339 > > subset. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 13:05:02 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C87228C135; Thu, 8 May 2008 13:05:02 -0700 (PDT) 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 54C893A6858 for ; Thu, 8 May 2008 13:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.563, 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 GPRynmsYshpQ for ; Thu, 8 May 2008 13:04:59 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 50ED93A6780 for ; Thu, 8 May 2008 13:04:58 -0700 (PDT) Received: (qmail 33857 invoked from network); 8 May 2008 20:04:55 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 8 May 2008 20:04:55 -0000 From: "Bert Wijnen - IETF" To: "Sharon Chisholm" , "David B Harrington" , Date: Thu, 8 May 2008 22:05:00 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I am OK with option/proposal A Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Sharon Chisholm [mailto:schishol@nortel.com] > Verzonden: woensdag 7 mei 2008 15:30 > Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Onderwerp: RE: [Netconf] Issue X: access to notification content > > > Hi > > If there is no objection to proposal A then I will proceed to make this > change and publish the updated draft. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Monday, May 05, 2008 8:33 AM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: Re: [Netconf] Issue X: access to notification content > > Hi > > I think it would be helpful to go back to original text we are editing > rather then the snippets. I've modified the second sentence in ways that > I think address the access versus authorization confusion and I think > makes it so we can keep the 'must not'. I think now we don't need to > 'depending on access control..." part because we are make a > recommendation about the access control in order to maintain minimal > security. I've added a third option which tries to include those for > comparison. I prefer A. > > Current text > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view content via other NETCONF operations, she must not > have access to that content via Notifications. If a user is not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > Proposed text (A) > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view the information in the notification, they must not > have access to that content via Notifications. If a user is not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > Proposed text (B) > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view the information in the notification, the access > control model and administrative policy probably should not > allow them access to that content via Notifications. If a user is > not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > I also got rid of the 'she' thing since I think the singular use of > 'they' is now grammatically acceptable in these cases. > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Friday, May 02, 2008 1:41 PM > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > Sent: Friday, May 02, 2008 11:22 AM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > By proposed text, did you mean: > > > > "she probably should not ... depending on the access control model > and > > administrative policy." > > > > Which I proposed to change to > > > > "she likely will not ... depending on the access control model and > > administrative policy." > > That is not what your earlier response said. The proposal in your > response did not include the text after the ellipsis. > > I prefer "she probably should not" because "should not" is RFC2119 > language. > You might want to stiffen that slightly by making it "she probably > SHOULD NOT ... depending on the access control model and administrative > policy." > > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Wednesday, April 30, 2008 5:53 PM > > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi, > > > > I don't think your proposed change addresses the security review > > concern. It doesn't say how access will be controlled. > > > > I think my proposed text does, by saying it will be handled by the > > access control model and adminstrative policy. > > > > Is there a reason you don't find my proposed text acceptable? > > > > dbh > > > > > -----Original Message----- > > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > > Sent: Wednesday, April 30, 2008 2:39 PM > > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Hi > > > > > > I can change from "she must not" to "she likely will not". I think > > the > > > probably softens things too much. The intent is that you > > only get to > > > view content you have permission to view, regardless of the access > > > > mechanisms. > > > > > > Sharon > > > > > > -----Original Message----- > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > Sent: Tuesday, April 29, 2008 10:25 AM > > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > > netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Hi, > > > > > > If it is only a discussion, then I suggest rewording "she must not > > > > ..." > > > to "she probably should not ... depending on the access control > > model > > > and administrative policy." > > > > > > This does not create a CLR. > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > > Subject: RE: Issue X: access to notification content > > > > > > > > Dave, this is a clarification to an concern from an IESG member. > > > > It is in the "Security Considerations" section, so it is > > > not a "hard > > > > choice of protocol standard". We are explaining in the security > > > > considerations section what kind of access concerns there might > > be. > > > > Does that clarify? > > > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > > > Bert Wijnen > > > > > > > > > -----Oorspronkelijk bericht----- > > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > > Verzonden: maandag 28 april 2008 19:28 > > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > > > > Hi bert, > > > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > > Sharon just > > > > > didn't understand and didn't fix. here's one: > > > > > > > > > > -- > > > > > In section 7, the text says "If a user does not have > > > > > permission to view content via other NETCONF operations, > she > > > must > > > > > not > > > > > have access to that content via Notifications." > > > > > > > > > > This creates a big CLR. > > > > > > > > > > Can content from a syslog or SNMP notification stream be > > > sent to a > > > > > user that does not have permission to access the syslog or > SNMP > > > > > content using some other Netconf operation? What other Netconf > > > > > > operation works with the syslog stream? Didn't we > > > > explicitly decide it > > > > > was not necessary to support access to notication > streams > > > > > (including syslog and SNMP streams)? > > > > > > > > > > I am also concerned that this access control "policy" > > > should be an > > > > > administrative one, not a hard choice of the protocol > > > standard. In > > > > > most cases it is the right choice. But a NOC manager > > > might want to > > > > > allow, say, the helpdesk to be alerted whenever a Netconf > config > > > is > > > > > being changed, or an intrusion detection application to > > > be alerted > > > > > when there is an authentication failure. And yet, they may > > > > not want to > > > > > give the helpdesk or the IDS permissions. With this CLR, > a > > > NOC > > > > > manager is simply not allowed to make such a decision. > > > > > > > > > > I understand the intent; I think the wording is poorly chosen, > > > > > > especially because it uses a "must", which has special > > > > RFC2119 meaning > > > > > and creates a huge CLR. And since access control will be > > > > done later, I > > > > > don't think the WG wants this CLR constraining all future > > > > AC designs. > > > > > > > > > > But I could be wrong; maybe the WG will decide this is exactly > > > what > > > > > they want to say. If that is the case, then I think we need > > > > to review > > > > > this document to make sure everything else (like syslog > streams) > > > can > > > > > work with this CLR. > > > > > > > > > > dbh > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 13:05:02 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C87228C135; Thu, 8 May 2008 13:05:02 -0700 (PDT) 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 54C893A6858 for ; Thu, 8 May 2008 13:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.563, 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 GPRynmsYshpQ for ; Thu, 8 May 2008 13:04:59 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 50ED93A6780 for ; Thu, 8 May 2008 13:04:58 -0700 (PDT) Received: (qmail 33857 invoked from network); 8 May 2008 20:04:55 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 8 May 2008 20:04:55 -0000 From: "Bert Wijnen - IETF" To: "Sharon Chisholm" , "David B Harrington" , Date: Thu, 8 May 2008 22:05:00 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I am OK with option/proposal A Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Sharon Chisholm [mailto:schishol@nortel.com] > Verzonden: woensdag 7 mei 2008 15:30 > Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Onderwerp: RE: [Netconf] Issue X: access to notification content > > > Hi > > If there is no objection to proposal A then I will proceed to make this > change and publish the updated draft. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Monday, May 05, 2008 8:33 AM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: Re: [Netconf] Issue X: access to notification content > > Hi > > I think it would be helpful to go back to original text we are editing > rather then the snippets. I've modified the second sentence in ways that > I think address the access versus authorization confusion and I think > makes it so we can keep the 'must not'. I think now we don't need to > 'depending on access control..." part because we are make a > recommendation about the access control in order to maintain minimal > security. I've added a third option which tries to include those for > comparison. I prefer A. > > Current text > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view content via other NETCONF operations, she must not > have access to that content via Notifications. If a user is not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > Proposed text (A) > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view the information in the notification, they must not > have access to that content via Notifications. If a user is not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > Proposed text (B) > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view the information in the notification, the access > control model and administrative policy probably should not > allow them access to that content via Notifications. If a user is > not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > I also got rid of the 'she' thing since I think the singular use of > 'they' is now grammatically acceptable in these cases. > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Friday, May 02, 2008 1:41 PM > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > Sent: Friday, May 02, 2008 11:22 AM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > By proposed text, did you mean: > > > > "she probably should not ... depending on the access control model > and > > administrative policy." > > > > Which I proposed to change to > > > > "she likely will not ... depending on the access control model and > > administrative policy." > > That is not what your earlier response said. The proposal in your > response did not include the text after the ellipsis. > > I prefer "she probably should not" because "should not" is RFC2119 > language. > You might want to stiffen that slightly by making it "she probably > SHOULD NOT ... depending on the access control model and administrative > policy." > > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Wednesday, April 30, 2008 5:53 PM > > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi, > > > > I don't think your proposed change addresses the security review > > concern. It doesn't say how access will be controlled. > > > > I think my proposed text does, by saying it will be handled by the > > access control model and adminstrative policy. > > > > Is there a reason you don't find my proposed text acceptable? > > > > dbh > > > > > -----Original Message----- > > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > > Sent: Wednesday, April 30, 2008 2:39 PM > > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Hi > > > > > > I can change from "she must not" to "she likely will not". I think > > the > > > probably softens things too much. The intent is that you > > only get to > > > view content you have permission to view, regardless of the access > > > > mechanisms. > > > > > > Sharon > > > > > > -----Original Message----- > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > Sent: Tuesday, April 29, 2008 10:25 AM > > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > > netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Hi, > > > > > > If it is only a discussion, then I suggest rewording "she must not > > > > ..." > > > to "she probably should not ... depending on the access control > > model > > > and administrative policy." > > > > > > This does not create a CLR. > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > > Subject: RE: Issue X: access to notification content > > > > > > > > Dave, this is a clarification to an concern from an IESG member. > > > > It is in the "Security Considerations" section, so it is > > > not a "hard > > > > choice of protocol standard". We are explaining in the security > > > > considerations section what kind of access concerns there might > > be. > > > > Does that clarify? > > > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > > > Bert Wijnen > > > > > > > > > -----Oorspronkelijk bericht----- > > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > > Verzonden: maandag 28 april 2008 19:28 > > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > > > > Hi bert, > > > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > > Sharon just > > > > > didn't understand and didn't fix. here's one: > > > > > > > > > > -- > > > > > In section 7, the text says "If a user does not have > > > > > permission to view content via other NETCONF operations, > she > > > must > > > > > not > > > > > have access to that content via Notifications." > > > > > > > > > > This creates a big CLR. > > > > > > > > > > Can content from a syslog or SNMP notification stream be > > > sent to a > > > > > user that does not have permission to access the syslog or > SNMP > > > > > content using some other Netconf operation? What other Netconf > > > > > > operation works with the syslog stream? Didn't we > > > > explicitly decide it > > > > > was not necessary to support access to notication > streams > > > > > (including syslog and SNMP streams)? > > > > > > > > > > I am also concerned that this access control "policy" > > > should be an > > > > > administrative one, not a hard choice of the protocol > > > standard. In > > > > > most cases it is the right choice. But a NOC manager > > > might want to > > > > > allow, say, the helpdesk to be alerted whenever a Netconf > config > > > is > > > > > being changed, or an intrusion detection application to > > > be alerted > > > > > when there is an authentication failure. And yet, they may > > > > not want to > > > > > give the helpdesk or the IDS permissions. With this CLR, > a > > > NOC > > > > > manager is simply not allowed to make such a decision. > > > > > > > > > > I understand the intent; I think the wording is poorly chosen, > > > > > > especially because it uses a "must", which has special > > > > RFC2119 meaning > > > > > and creates a huge CLR. And since access control will be > > > > done later, I > > > > > don't think the WG wants this CLR constraining all future > > > > AC designs. > > > > > > > > > > But I could be wrong; maybe the WG will decide this is exactly > > > what > > > > > they want to say. If that is the case, then I think we need > > > > to review > > > > > this document to make sure everything else (like syslog > streams) > > > can > > > > > work with this CLR. > > > > > > > > > > dbh > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 13:27:19 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFBB53A6E14; Thu, 8 May 2008 13:27:19 -0700 (PDT) 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 D2AFE28C2D2 for ; Thu, 8 May 2008 13:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.092 X-Spam-Level: X-Spam-Status: No, score=-5.092 tagged_above=-999 required=5 tests=[AWL=1.507, 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 pPyN7t20M1f4 for ; Thu, 8 May 2008 13:27:14 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id AA60C3A6E32 for ; Thu, 8 May 2008 13:25:42 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m48KPdLf006396 for ; Thu, 8 May 2008 16:25:40 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m48KPdeI006384; Thu, 8 May 2008 16:25:39 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 16:25:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 May 2008 16:25:27 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02AE9FF3@IMCSRV2.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Issue X: access to notification content Thread-Index: AcixRvDhO8KpQ5JvQ3iRXripHR2iHQAAXgHA References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> From: "Natale, Bob" To: "Bert Wijnen - IETF" , "Sharon Chisholm" , "David B Harrington" X-OriginalArrivalTime: 08 May 2008 20:25:39.0518 (UTC) FILETIME=[AE4EADE0:01C8B149] Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I don't have a position in this matter...I'm just looking at the wording for implementation implications: All three of the option/proposal texts below conclude with this statement: "If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user." That can (sensibly) be read as meaning: "If a user is permitted to view [at least] one element in the content of the notification, the notification is sent to that user." If that is not what is intended, then perhaps something *like* this would be more effective: "If and only if a user is permitted to view all elements in the content of the notification, then the notification is sent to that user." Cheers, BobN -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf OfFrom netconf-bounces@ietf.org Thu May 8 13:27:19 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFBB53A6E14; Thu, 8 May 2008 13:27:19 -0700 (PDT) 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 D2AFE28C2D2 for ; Thu, 8 May 2008 13:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.092 X-Spam-Level: X-Spam-Status: No, score=-5.092 tagged_above=-999 required=5 tests=[AWL=1.507, 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 pPyN7t20M1f4 for ; Thu, 8 May 2008 13:27:14 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id AA60C3A6E32 for ; Thu, 8 May 2008 13:25:42 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m48KPdLf006396 for ; Thu, 8 May 2008 16:25:40 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m48KPdeI006384; Thu, 8 May 2008 16:25:39 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 16:25:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 May 2008 16:25:27 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02AE9FF3@IMCSRV2.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Issue X: access to notification content Thread-Index: AcixRvDhO8KpQ5JvQ3iRXripHR2iHQAAXgHA References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> From: "Natale, Bob" To: "Bert Wijnen - IETF" , "Sharon Chisholm" , "David B Harrington" X-OriginalArrivalTime: 08 May 2008 20:25:39.0518 (UTC) FILETIME=[AE4EADE0:01C8B149] Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I don't have a position in this matter...I'm just looking at the wording for implementation implications: All three of the option/proposal texts below conclude with this statement: "If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user." That can (sensibly) be read as meaning: "If a user is permitted to view [at least] one element in the content of the notification, the notification is sent to that user." If that is not what is intended, then perhaps something *like* this would be more effective: "If and only if a user is permitted to view all elements in the content of the notification, then the notification is sent to that user." Cheers, BobN -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Beh Bert Wijnen - IETF Sent: Thursday, May 08, 2008 4:05 PM To: Sharon Chisholm; David B Harrington; netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content I am OK with option/proposal A Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Sharon Chisholm [mailto:schishol@nortel.com] > Verzonden: woensdag 7 mei 2008 15:30 > Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Onderwerp: RE: [Netconf] Issue X: access to notification content > > > Hi > > If there is no objection to proposal A then I will proceed to make this > change and publish the updated draft. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Monday, May 05, 2008 8:33 AM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: Re: [Netconf] Issue X: access to notification content > > Hi > > I think it would be helpful to go back to original text we are editing > rather then the snippets. I've modified the second sentence in ways that > I think address the access versus authorization confusion and I think > makes it so we can keep the 'must not'. I think now we don't need to > 'depending on access control..." part because we are make a > recommendation about the access control in order to maintain minimal > security. I've added a third option which tries to include those for > comparison. I prefer A. > > Current text > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view content via other NETCONF operations, she must not > have access to that content via Notifications. If a user is not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > Proposed text (A) > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view the information in the notification, they must not > have access to that content via Notifications. If a user is not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > Proposed text (B) > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view the information in the notification, the access > control model and administrative policy probably should not > allow them access to that content via Notifications. If a user is > not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > I also got rid of the 'she' thing since I think the singular use of > 'they' is now grammatically acceptable in these cases. > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Friday, May 02, 2008 1:41 PM > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > Sent: Friday, May 02, 2008 11:22 AM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > By proposed text, did you mean: > > > > "she probably should not ... depending on the access control model > and > > administrative policy." > > > > Which I proposed to change to > > > > "she likely will not ... depending on the access control model and > > administrative policy." > > That is not what your earlier response said. The proposal in your > response did not alf Of Bert Wijnen - IETF Sent: Thursday, May 08, 2008 4:05 PM To: Sharon Chisholm; David B Harrington; netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content I am OK with option/proposal A Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Sharon Chisholm [mailto:schishol@nortel.com] > Verzonden: woensdag 7 mei 2008 15:30 > Aan: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Onderwerp: RE: [Netconf] Issue X: access to notification content > > > Hi > > If there is no objection to proposal A then I will proceed to make this > change and publish the updated draft. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Monday, May 05, 2008 8:33 AM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: Re: [Netconf] Issue X: access to notification content > > Hi > > I think it would be helpful to go back to original text we are editing > rather then the snippets. I've modified the second sentence in ways that > I think address the access versus authorization confusion and I think > makes it so we can keep the 'must not'. I think now we don't need to > 'depending on access control..." part because we are make a > recommendation about the access control in order to maintain minimal > security. I've added a third option which tries to include those for > comparison. I prefer A. > > Current text > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view content via other NETCONF operations, she must not > have access to that content via Notifications. If a user is not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > Proposed text (A) > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view the information in the notification, they must not > have access to that content via Notifications. If a user is not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > Proposed text (B) > > The contents of notifications as well as the name of event streams > may contain sensitive information and care should be taken to ensure > that it is viewed only by authorized users. If a user does not have > permission to view the information in the notification, the access > control model and administrative policy probably should not > allow them access to that content via Notifications. If a user is > not > permitted to view one element in the content of the notification, the > notification is not sent to that user. > > I also got rid of the 'she' thing since I think the singular use of > 'they' is now grammatically acceptable in these cases. > > Sharon > > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Friday, May 02, 2008 1:41 PM > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > > > > -----Original Message----- > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > Sent: Friday, May 02, 2008 11:22 AM > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > By proposed text, did you mean: > > > > "she probably should not ... depending on the access control model > and > > administrative policy." > > > > Which I proposed to change to > > > > "she likely will not ... depending on the access control model and > > administrative policy." > > That is not what your earlier response said. The proposal in your > response diinclude the text after the ellipsis. > > I prefer "she probably should not" because "should not" is RFC2119 > language. > You might want to stiffen that slightly by making it "she probably > SHOULD NOT ... depending on the access control model and administrative > policy." > > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Wednesday, April 30, 2008 5:53 PM > > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi, > > > > I don't think your proposed change addresses the security review > > concern. It doesn't say how access will be controlled. > > > > I think my proposed text does, by saying it will be handled by the > > access control model and adminstrative policy. > > > > Is there a reason you don't find my proposed text acceptable? > > > > dbh > > > > > -----Original Message----- > > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > > Sent: Wednesday, April 30, 2008 2:39 PM > > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Hi > > > > > > I can change from "she must not" to "she likely will not". I think > > the > > > probably softens things too much. The intent is that you > > only get to > > > view content you have permission to view, regardless of the access > > > > mechanisms. > > > > > > Sharon > > > > > > -----Original Message----- > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > Sent: Tuesday, April 29, 2008 10:25 AM > > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > > netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Hi, > > > > > > If it is only a discussion, then I suggest rewording "she must not > > > > ..." > > > to "she probably should not ... depending on the access control > > model > > > and administrative policy." > > > > > > This does not create a CLR. > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > > Subject: RE: Issue X: access to notification content > > > > > > > > Dave, this is a clarification to an concern from an IESG member. > > > > It is in the "Security Considerations" section, so it is > > > not a "hard > > > > choice of protocol standard". We are explaining in the security > > > > considerations section what kind of access concerns there might > > be. > > > > Does that clarify? > > > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > > > Bert Wijnen > > > > > > > > > -----Oorspronkelijk bericht----- > > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > > Verzonden: maandag 28 april 2008 19:28 > > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > > > > Hi bert, > > > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > > Sharon just > > > > > didn't understand and didn't fix. here's one: > > > > > > > > > > -- > > > > > In section 7, the text says "If a user does not have > > > > > permission to view content via other NETCONF operations, > she > > > must > > > > > not > > > > > have access to that content via Notifications." > > > > > > > > > > This creates a big CLR. > > > > > > > > > > Can content from a syslog or SNMP notification stream be > > > sent to a > > > > > user that does not have permission to access the syslog or > SNMP > > > > > content using some other Netconf operation? What other Netconf > > > > > > operation works with the syslog stream? Didn't we > > > > explicitly decide it > > > > > was not necessary to support access to notication > streams > > > > > (including syslog and SNMP streams)? > > > > > > > > > > I am also concerned not include the text after the ellipsis. > > I prefer "she probably should not" because "should not" is RFC2119 > language. > You might want to stiffen that slightly by making it "she probably > SHOULD NOT ... depending on the access control model and administrative > policy." > > > > > Sharon > > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Wednesday, April 30, 2008 5:53 PM > > To: Chisholm, Sharon (CAR:ZZ00); 'Bert Wijnen - IETF'; > > netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > Hi, > > > > I don't think your proposed change addresses the security review > > concern. It doesn't say how access will be controlled. > > > > I think my proposed text does, by saying it will be handled by the > > access control model and adminstrative policy. > > > > Is there a reason you don't find my proposed text acceptable? > > > > dbh > > > > > -----Original Message----- > > > From: Sharon Chisholm [mailto:schishol@nortel.com] > > > Sent: Wednesday, April 30, 2008 2:39 PM > > > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Hi > > > > > > I can change from "she must not" to "she likely will not". I think > > the > > > probably softens things too much. The intent is that you > > only get to > > > view content you have permission to view, regardless of the access > > > > mechanisms. > > > > > > Sharon > > > > > > -----Original Message----- > > > From: David B Harrington [mailto:dbharrington@comcast.net] > > > Sent: Tuesday, April 29, 2008 10:25 AM > > > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > > > netconf@ietf.org > > > Subject: RE: Issue X: access to notification content > > > > > > Hi, > > > > > > If it is only a discussion, then I suggest rewording "she must not > > > > ..." > > > to "she probably should not ... depending on the access control > > model > > > and administrative policy." > > > > > > This does not create a CLR. > > > > > > dbh > > > > > > > -----Original Message----- > > > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > > > Sent: Tuesday, April 29, 2008 2:41 AM > > > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > > > Subject: RE: Issue X: access to notification content > > > > > > > > Dave, this is a clarification to an concern from an IESG member. > > > > It is in the "Security Considerations" section, so it is > > > not a "hard > > > > choice of protocol standard". We are explaining in the security > > > > considerations section what kind of access concerns there might > > be. > > > > Does that clarify? > > > > > > > > Sharon, do you have other comments on Dave's concern? > > > > > > > > Bert Wijnen > > > > > > > > > -----Oorspronkelijk bericht----- > > > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > > > Verzonden: maandag 28 april 2008 19:28 > > > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > > > Onderwerp: Issue X: access to notification content > > > > > > > > > > > > > > > Hi bert, > > > > > > > > > > There were a bunch of issues I raised on 4/23 that I think > > > > Sharon just > > > > > didn't understand and didn't fix. here's one: > > > > > > > > > > -- > > > > > In section 7, the text says "If a user does not have > > > > > permission to view content via other NETCONF operations, > she > > > must > > > > > not > > > > > have access to that content via Notifications." > > > > > > > > > > This creates a big CLR. > > > > > > > > > > Can content from a syslog or SNMP notification stream be > > > sent to a > > > > > user that does not have permission to access the syslog or > SNMP > > > > > content using some other Netconf operation? What other Netconf > > > > > > operation works with the syslog stream? Didn't we > > > > explicitly decide it > > > > > was not necessary to support access to notication > streams > > > > > (including syslog and SNMP streams)? > > > > > > > > > > I am also cod that this access control "policy" > > > should be an > > > > > administrative one, not a hard choice of the protocol > > > standard. In > > > > > most cases it is the right choice. But a NOC manager > > > might want to > > > > > allow, say, the helpdesk to be alerted whenever a Netconf > config > > > is > > > > > being changed, or an intrusion detection application to > > > be alerted > > > > > when there is an authentication failure. And yet, they may > > > > not want to > > > > > give the helpdesk or the IDS permissions. With this CLR, > a > > > NOC > > > > > manager is simply not allowed to make such a decision. > > > > > > > > > > I understand the intent; I think the wording is poorly chosen, > > > > > > especially because it uses a "must", which has special > > > > RFC2119 meaning > > > > > and creates a huge CLR. And since access control will be > > > > done later, I > > > > > don't think the WG wants this CLR constraining all future > > > > AC designs. > > > > > > > > > > But I could be wrong; maybe the WG will decide this is exactly > > > what > > > > > they want to say. If that is the case, then I think we need > > > > to review > > > > > this document to make sure everything else (like syslog > streams) > > > can > > > > > work with this CLR. > > > > > > > > > > dbh > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ncerned that this access control "policy" > > > should be an > > > > > administrative one, not a hard choice of the protocol > > > standard. In > > > > > most cases it is the right choice. But a NOC manager > > > might want to > > > > > allow, say, the helpdesk to be alerted whenever a Netconf > config > > > is > > > > > being changed, or an intrusion detection application to > > > be alerted > > > > > when there is an authentication failure. And yet, they may > > > > not want to > > > > > give the helpdesk or the IDS permissions. With this CLR, > a > > > NOC > > > > > manager is simply not allowed to make such a decision. > > > > > > > > > > I understand the intent; I think the wording is poorly chosen, > > > > > > especially because it uses a "must", which has special > > > > RFC2119 meaning > > > > > and creates a huge CLR. And since access control will be > > > > done later, I > > > > > don't think the WG wants this CLR constraining all future > > > > AC designs. > > > > > > > > > > But I could be wrong; maybe the WG will decide this is exactly > > > what > > > > > they want to say. If that is the case, then I think we need > > > > to review > > > > > this document to make sure everything else (like syslog > streams) > > > can > > > > > work with this CLR. > > > > > > > > > > dbh > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 8 16:57:45 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530F03A684D; Thu, 8 May 2008 16:57:45 -0700 (PDT) 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 E822A3A684D for ; Thu, 8 May 2008 16:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 I7G45IFpCYp4 for ; Thu, 8 May 2008 16:57:43 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 1A6263A66B4 for ; Thu, 8 May 2008 16:57:42 -0700 (PDT) Received: (qmail 21442 invoked from network); 8 May 2008 23:57:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2008 23:57:39 -0000 X-YMail-OSG: qoMyuFsVM1kaaSWsTs.67bv9rYswUHmh0lSYcnLlX8l6LQ7y7wOjfRZoX83oibLK5JoRj41.kVbxhW0KAWQobSNrv9AseR0ZXIJwehB__sfM0to2IgDZR3b_dopKzcOu3I0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4823935B.3050802@andybierman.com> Date: Thu, 08 May 2008 16:57:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David B Harrington References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> <48232185.9020109@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> <482334BA.2060303@andybierman.com> <03ff01c8b139$0ce6be80$0600a8c0@china.huawei.com> In-Reply-To: <03ff01c8b139$0ce6be80$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > >> oops -- I was confused. I thought the paragraph dealt with >> other NETCONF operations, but I see that is Dave's text, not >> (A) or (B). > > Read the "current text" again, Andy. The current text specifies: > "If a user does not have permission to view content via other NETCONF > operations, she must not have access to that content via > Notifications." This text is not acceptable. What content? What operations? What if the data the user is allowed to see via notifications is not available via other operations? Does this sentence mean that scenario is forbidden in NETCONF? (E) is good. We have seen recently that people will parse a normative sentence to make it say what they want it to say. We should not add any problematic sentences to the Notifications RFC that will be impede any future access control work. (I bet dollars to donuts that the terms used carelessly in this paragraph in question will be parsed against the terminology in future access control documents, and cause problemsFrom netconf-bounces@ietf.org Thu May 8 16:57:45 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530F03A684D; Thu, 8 May 2008 16:57:45 -0700 (PDT) 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 E822A3A684D for ; Thu, 8 May 2008 16:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 I7G45IFpCYp4 for ; Thu, 8 May 2008 16:57:43 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id 1A6263A66B4 for ; Thu, 8 May 2008 16:57:42 -0700 (PDT) Received: (qmail 21442 invoked from network); 8 May 2008 23:57:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 8 May 2008 23:57:39 -0000 X-YMail-OSG: qoMyuFsVM1kaaSWsTs.67bv9rYswUHmh0lSYcnLlX8l6LQ7y7wOjfRZoX83oibLK5JoRj41.kVbxhW0KAWQobSNrv9AseR0ZXIJwehB__sfM0to2IgDZR3b_dopKzcOu3I0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4823935B.3050802@andybierman.com> Date: Thu, 08 May 2008 16:57:15 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David B Harrington References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com> <03af01c8b104$03fc48b0$0600a8c0@china.huawei.com> <48232185.9020109@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com> <482334BA.2060303@andybierman.com> <03ff01c8b139$0ce6be80$0600a8c0@china.huawei.com> In-Reply-To: <03ff01c8b139$0ce6be80$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > >> oops -- I was confused. I thought the paragraph dealt with >> other NETCONF operations, but I see that is Dave's text, not >> (A) or (B). > > Read the "current text" again, Andy. The current text specifies: > "If a user does not have permission to view content via other NETCONF > operations, she must not have access to that content via > Notifications." This text is not acceptable. What content? What operations? What if the data the user is allowed to see via notifications is not available via other operations? Does this sentence mean that scenario is forbidden in NETCONF? (E) is good. We have seen recently that people will parse a normative sentence to make it say what they want it to say. We should not add any problematic sentences to the Notifications RFC that will be impede any future access control work. (I bet dollars to donuts that the terms used carelessly in this paragraph in question will be parsed against the terminology in future access control documents, and cause pr. ;-) Andy > > I object to this for multiple independent reasons: > 1) "must" is an RFC2119 reserved word. Using it here makes this a > REQUIREMENT. > 2) Access control mechanisms are out of scope at this time. So we > should not state any REQUIREMENTS about how access control "must" > work. > 3) the current text makes notification access control dependent on the > access controls used for other operations. Andy, I think this is a bad > idea, for reasons similar to those you mention. > 4) authorization to view information should be an adminstrative > decision, not a protocol decision. > 5) Netcofn notifications were designed to carry syslog and SNMP > notifications streams. We should not impose the access control > requirement that is specified in the "current text" for syslog and/or > SNMP content. > >> I actually don't like any of the choices. > > I don't like any of the choices either. The Proposed text (C) was a > concession to Sharon's unwillingness to remove the dependence on other > operations. In the REQUIREMENT in Sharon's (A), is access via SNMP-GET > or syslog logging acceptable as the "permission to view the > information" - I think that a dependency on access control mechanisms > in other protocols would be even worse than "permission to view > content via other NETCONF operations". > > here is another proposed text to replace the original text: > > Proposed Text (D) > > "The contents of notifications as well as the names of event streams > may contain sensitive information and care should be taken to ensure > that they are viewed only by authorized users. It is an administrative > policy decision to determine who (or what) is authorized to have > access to the information contained in notifications. If a user is not > authorized to view all elements in the content of the notification, > the notification is not sent to that user." > > I could also live with the nice simple > > Proposed Text (E) > > "The contents of notifications as well as the names of event streams > may contain sensitive information and care should be taken to ensure > that they are viewed only by authorized users. If a user is not > authorized to view all elements in the content of the notification, > the notification is not sent to that user." > > I could also live with the even simpler: > > "The contents of notifications as well as the names of event streams > may contain sensitive information and care should be taken to ensure > that they are viewed only by authorized users." > > And then leave it up future access control mechanisms to determine > authorization. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf oblems. ;-) Andy > > I object to this for multiple independent reasons: > 1) "must" is an RFC2119 reserved word. Using it here makes this a > REQUIREMENT. > 2) Access control mechanisms are out of scope at this time. So we > should not state any REQUIREMENTS about how access control "must" > work. > 3) the current text makes notification access control dependent on the > access controls used for other operations. Andy, I think this is a bad > idea, for reasons similar to those you mention. > 4) authorization to view information should be an adminstrative > decision, not a protocol decision. > 5) Netcofn notifications were designed to carry syslog and SNMP > notifications streams. We should not impose the access control > requirement that is specified in the "current text" for syslog and/or > SNMP content. > >> I actually don't like any of the choices. > > I don't like any of the choices either. The Proposed text (C) was a > concession to Sharon's unwillingness to remove the dependence on other > operations. In the REQUIREMENT in Sharon's (A), is access via SNMP-GET > or syslog logging acceptable as the "permission to view the > information" - I think that a dependency on access control mechanisms > in other protocols would be even worse than "permission to view > content via other NETCONF operations". > > here is another proposed text to replace the original text: > > Proposed Text (D) > > "The contents of notifications as well as the names of event streams > may contain sensitive information and care should be taken to ensure > that they are viewed only by authorized users. It is an administrative > policy decision to determine who (or what) is authorized to have > access to the information contained in notifications. If a user is not > authorized to view all elements in the content of the notification, > the notification is not sent to that user." > > I could also live with the nice simple > > Proposed Text (E) > > "The contents of notifications as well as the names of event streams > may contain sensitive information and care should be taken to ensure > that they are viewed only by authorized users. If a user is not > authorized to view all elements in the content of the notification, > the notification is not sent to that user." > > I could also live with the even simpler: > > "The contents of notifications as well as the names of event streams > may contain sensitive information and care should be taken to ensure > that they are viewed only by authorized users." > > And then leave it up future access control mechanisms to determine > authorization. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 9 06:22:37 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4022A3A6872; Fri, 9 May 2008 06:22:37 -0700 (PDT) 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 95BCD3A6822 for ; Fri, 9 May 2008 06:22:35 -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 dqpyMZwG1K62 for ; Fri, 9 May 2008 06:22:31 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id DCD583A67FA for ; Fri, 9 May 2008 06:22:27 -0700 (PDT) X-Trace: 24305196/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.117 X-SBRS: None X-RemoteIP: 62.188.135.117 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEACvoI0g+vId1/2dsb2JhbACLUZ9WBA X-IP-Direction: IN Received: from 1cust117.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.117]) by smtp.pipex.tiscali.co.uk with SMTP; 09 May 2008 14:01:50 +0100 Message-ID: <020401c8b1cb$dff1c3a0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "David B Harrington" References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com><03af01c8b104$03fc48b0$0600a8c0@china.huawei.com><48232185.9020109@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com><482334BA.2060303@andybierman.com><03ff01c8b139$0ce6be80$0600a8c0@china.huawei.com> <4823935B.3050802@andybierman.com> Date: Fri, 9 May 2008 12:20:27 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I think that F) is the best so far, namely > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users." > > > > And then leave it up future access control mechanisms to determine > > authorization. > > > > David Harrington" I would suggest /they are viewed only by/they are made available only to/ to cover more forms of communication (like print). Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "David B Harrington" Cc: Sent: Friday, May 09, 2008 1:57 AM Subject: Re: [Netconf] Issue X: access to notification content > David B Harrington wrote: > > > >> oops -- I was confused. I thought the paragraph dealt with > >> other NETCONF operations, but I see that is Dave's text, not > >> (A) or (B). > > > > Read the "current text" again, Andy. The current text specifies: > > "If a user does not have permission to view content via other NETCONF > > operations, she must not have access to that content via > > Notifications." > > This text is not acceptable. > What content? What operations? > What if the data the user is allowed to see via notifications > is not available via other operations? Does this sentence mean that > scenario is forbidden in NETCONF? > > > (E) is good. > > We have seen recently that people will parse a normative sentence > to make it say what they want it to say. We should not add any > problematic sentences to the Notifications RFC that will be impede > any future access control work. > > (I bet dollars to donuts that the terms used carelessly in > this paragraph in question will be parsed against the terminology > in future access control documents, and cause problems. ;-) > > > Andy > > > > > > > I object to this for multiple independent reasons: > > 1) "must" is an RFC2119 reserved word. Using it here makes this a > > REQUIREMENT. > > 2) Access control mechanisms are out of scope at this time. So we > > should not state any REQUIREMENTS about how access control "must" > > work. > > 3) the current text makes notification access control dependent on the > > access controls used for other operations. Andy, I think this is a bad > > idea, for reasons similar to those you mention. > > 4) authorization to view information should be an adminstrative > > decision, not a protocol decision. > > 5) Netcofn notifications were designed to carry syslog and SNMP > > notifications streams. We should not impose the access control > > requirement that is specified in the "current text" for syslog and/or > > SNMP content. > > > >> I actually don't like any of the choices. > > > > I don't like any of the choices either. The Proposed text (C) was a > > concession to Sharon's unwillingness to remove the dependence on other > > operations. In the REQUIREMENT in Sharon's (A), is access via SNMP-GET > > or syslog logging acceptable as the "permission to view the > > information" - I think that a dependency on access control mechanisms > > in other protocols would be even worse than "permission to view > > content via other NETCONF operations". > > > > here is another proposed text to replace the original text: > > > > Proposed Text (D) > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users. It is an administrative > > policy decision to determine who (or what) is authorized to have > > access to the information contained in notifications. If a user is not > > authorized to view all elements in the content of the notification, > > the notification is not sent to that user." > > > > I could also live with the nice simple > > > > Proposed Text (E) > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users. If a user is not > > authorized to view all elements in the content of the notification, > > the notification is not sent to that user." > > > > I could also live with the even simpler: > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users." > > > > And then leave it up future access control mechanisms to determine > > authorization. > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 9 07:32:49 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A99C3A69DC; Fri, 9 May 2008 07:32:49 -0700 (PDT) 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 95BCD3A6822 for ; Fri, 9 May 2008 06:22:35 -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 dqpyMZwG1K62 for ; Fri, 9 May 2008 06:22:31 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id DCD583A67FA for ; Fri, 9 May 2008 06:22:27 -0700 (PDT) X-Trace: 24305196/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.117 X-SBRS: None X-RemoteIP: 62.188.135.117 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEACvoI0g+vId1/2dsb2JhbACLUZ9WBA X-IP-Direction: IN Received: from 1cust117.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.117]) by smtp.pipex.tiscali.co.uk with SMTP; 09 May 2008 14:01:50 +0100 Message-ID: <020401c8b1cb$dff1c3a0$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" , "David B Harrington" References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com><03af01c8b104$03fc48b0$0600a8c0@china.huawei.com><48232185.9020109@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com><482334BA.2060303@andybierman.com><03ff01c8b139$0ce6be80$0600a8c0@china.huawei.com> <4823935B.3050802@andybierman.com> Date: Fri, 9 May 2008 12:20:27 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I think that F) is the best so far, namely > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users." > > > > And then leave it up future access control mechanisms to determine > > authorization. > > > > David Harrington" I would suggest /they are viewed only by/they are made available only to/ to cover more forms of communication (like print). Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "David B Harrington" Cc: Sent: Friday, May 09, 2008 1:57 AM Subject: Re: [Netconf] Issue X: access to notification content > David B Harrington wrote: > > > >> oops -- I was confused. I thought the paragraph dealt with > >> other NETCONF operations, but I see that is Dave's text, not > >> (A) or (B). > > > > Read the "current text" again, Andy. The current text specifies: > > "If a user does not have permission to view content via other NETCONF > > operations, she must not have access to that content via > > Notifications." > > This text is not acceptable. > What content? What operations? > What if the data the user is allowed to see via notifications > is not available via other operations? Does this sentence mean that > scenario is forbidden in NETCONF? > > > (E) is good. > > We have seen recently that people will parse a normative sentence > to make it say what they want it to say. We should not add any > problematic sentences to the Notifications RFC that will be impede > any future access control work. > > (I bet dollars to donuts that the terms used carelessly in > this paragraph in question will be parsed against the terminology > in future access control documents, and cause problems. ;-) > > > Andy > > > > > > > I object to this for multiple independent reasons: > > 1) "must" is an RFC2119 reserved word. Using it here makes this a > > REQUIREMENT. > > 2) Access control mechanisms are out of scope at this time. So we > > should not state any REQUIREMENTS about how access control "must" > > work. > > 3) the current text makes notification access control dependent on the > > access controls used for other operations. Andy, I think this is a bad > > idea, for reasons similar to those you mention. > > 4) authorization to view information should be an adminstrative > > decision, not a protocol decision. > > 5) Netcofn notifications were designed to carry syslog and SNMP > > notifications streams. We should not impose the access control > > requirement that is specified in the "current text" for syslog and/or > > SNMP content. > > > >> I actually don't like any of the choices. > > > > I don't like any of the choices either. The Proposed text (C) was a > > concession to Sharon's unwillingness to remove the dependence on other > > operations. In the REQUIREMENT in Sharon's (A), is access via SNMP-GET > > or syslog logging acceptable as the "permission to view the > > information" - I think that a dependency on access control mechanisms > > in other protocols would be even worse than "permission to view > > content via other NETCONF operations". > > > > here is another proposed text to replace the original text: > > > > Proposed Text (D) > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users. It is an administrative > > policy decision to determine who (or what) is authorized to have > > access to the information contained in notifications. If a user is not > > authorized to view all elements in the content of the notification, > > the notification is not sent to that user." > > > > I could also live with the nice simple > > > > Proposed Text (E) > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users. If a user is not > > authorized to view all elements in the content of the notification, > > the notification is not sent to that user." > > > > I could also live with the even simpler: > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users." > > > > And then leave it up future access control mechanisms to determine > > authorization. > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 9 08:25:18 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACADB3A67FA; Fri, 9 May 2008 08:25:18 -0700 (PDT) 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 33E0D3A67FA for ; Fri, 9 May 2008 08:25:16 -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 NjKQOyoi9ejP for ; Fri, 9 May 2008 08:25:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1FB5C3A67CE for ; Fri, 9 May 2008 08:25:15 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9B50120114; Fri, 9 May 2008 17:23:16 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-92-48246c64d551 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 79FA8200C6; Fri, 9 May 2008 17:23:16 +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, 9 May 2008 17:23:16 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 17:23:16 +0200 Message-ID: <48246C63.9010308@ericsson.com> Date: Fri, 09 May 2008 17:23:15 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200805071910.m47JAU5w061218@idle.juniper.net> In-Reply-To: <200805071910.m47JAU5w061218@idle.juniper.net> X-OriginalArrivalTime: 09 May 2008 15:23:16.0203 (UTC) FILETIME=[9A7643B0:01C8B1E8] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, Actually we also have problems with buffering big configs. But you already get buffering problems if you have a big request and you find at the very end, that you can't complete your reply. I see the following possibilities: - you buffer the 50MBs (or more) see if it OK or if you have to start by sending an - you start to stream out the big result message and if you run into an error, you abort the rpc-reply or maybe even the complete session. Balazs Phil Shafer wrote: > We discussed it on the mailing list enough times. I see > configs in the >50MB range. Bufferings not a reasonably > solution. > >> The element was placed first so the manager would not >> have to receive the entire element before knowing >> it there were any errors or warnings. > > Are you saying that buffering's an issue for the manager, but > not for the agent? That seems exactly backwards. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 9 08:52:32 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518AE3A67FA; Fri, 9 May 2008 08:52:32 -0700 (PDT) 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 5E6403A67FA for ; Fri, 9 May 2008 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.862 X-Spam-Level: X-Spam-Status: No, score=-0.862 tagged_above=-999 required=5 tests=[AWL=0.094, 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 0pqwtuwm1xAn for ; Fri, 9 May 2008 08:52:30 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 78F4D3A67CE for ; Fri, 9 May 2008 08:52:30 -0700 (PDT) Received: (qmail 90982 invoked from network); 9 May 2008 15:51:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 9 May 2008 15:51:31 -0000 X-YMail-OSG: SGtzkZgVM1kQNkJJDgNs9JhS59mfqyjyVmxe6k.ucgjPURwShGsu5dTaAEgPw_VV81HyIHy0BJ1dcFT6u_icDHh3ZXe7y4JMnaAPmno7IB0uOWr0.aDIbCxXPijX3Kc4DR_WtP1_1JjTaZF56y_f8cGd X-Yahoo-Newman-Property: ymail-3 Message-ID: <48247304.9020505@andybierman.com> Date: Fri, 09 May 2008 08:51:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Balazs Lengyel References: <200805071910.m47JAU5w061218@idle.juniper.net> <48246C63.9010308@ericsson.com> In-Reply-To: <48246C63.9010308@ericsson.com> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > Hello, > Actually we also have problems with buffering big configs. > > But you already get buffering problems if you have a big request > and you find at the very end, that you can't complete your reply. I see > the following possibilities: > - you buffer the 50MBs (or more) see if it OK or if you have to start by > sending an > - you start to stream out the big result message and if you run into an > error, you abort the rpc-reply or maybe even the complete session. IMO, this is a totally different problem than is intended to solve. 1) If your implementation cannot determine if the RPC method parameters are valid, before returning the appropriate reply, it is broken. 2) It is not relevant to the standard what an implementation does after it receives an request and before it sends an . This is way out of scope. If you stream out a reply before validating the parameters, then your implementation is broken. However, if the parameters are valid: SNMPv3 has an exception mechanism within the varbind list (e.g. noSuchInstance). NETCONF could have a similar 'runtime exception' mechanism, that allows elements to be embedded in and replies, instead of the actual data. Applications can use these exception markers to find out why some data that should be present could not be included in the reply. > Balazs > Andy > Phil Shafer wrote: >> We discussed it on the mailing list enough times. I see >> configs in the >50MB range. Bufferings not a reasonably >> solution. >> >>> The element was placed first so the manager would not >>> have to receive the entire element before knowing >>> it there were any errors or warnings. >> >> Are you saying that buffering's an issue for the manager, but >> not for the agent? That seems exactly backwards. >> >> Thanks, >> Phil >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 9 09:33:36 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E9E93A6996; Fri, 9 May 2008 09:33:36 -0700 (PDT) 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 33E0D3A67FA for ; Fri, 9 May 2008 08:25:16 -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 NjKQOyoi9ejP for ; Fri, 9 May 2008 08:25:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1FB5C3A67CE for ; Fri, 9 May 2008 08:25:15 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9B50120114; Fri, 9 May 2008 17:23:16 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-92-48246c64d551 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 79FA8200C6; Fri, 9 May 2008 17:23:16 +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, 9 May 2008 17:23:16 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 17:23:16 +0200 Message-ID: <48246C63.9010308@ericsson.com> Date: Fri, 09 May 2008 17:23:15 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Phil Shafer References: <200805071910.m47JAU5w061218@idle.juniper.net> In-Reply-To: <200805071910.m47JAU5w061218@idle.juniper.net> X-OriginalArrivalTime: 09 May 2008 15:23:16.0203 (UTC) FILETIME=[9A7643B0:01C8B1E8] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, Actually we also have problems with buffering big configs. But you already get buffering problems if you have a big request and you find at the very end, that you can't complete your reply. I see the following possibilities: - you buffer the 50MBs (or more) see if it OK or if you have to start by sending an - you start to stream out the big result message and if you run into an error, you abort the rpc-reply or maybe even the complete session. Balazs Phil Shafer wrote: > We discussed it on the mailing list enough times. I see > configs in the >50MB range. Bufferings not a reasonably > solution. > >> The element was placed first so the manager would not >> have to receive the entire element before knowing >> it there were any errors or warnings. > > Are you saying that buffering's an issue for the manager, but > not for the agent? That seems exactly backwards. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 9 10:03:44 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2D33A6949; Fri, 9 May 2008 10:03:43 -0700 (PDT) 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 5E6403A67FA for ; Fri, 9 May 2008 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.862 X-Spam-Level: X-Spam-Status: No, score=-0.862 tagged_above=-999 required=5 tests=[AWL=0.094, 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 0pqwtuwm1xAn for ; Fri, 9 May 2008 08:52:30 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 78F4D3A67CE for ; Fri, 9 May 2008 08:52:30 -0700 (PDT) Received: (qmail 90982 invoked from network); 9 May 2008 15:51:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 9 May 2008 15:51:31 -0000 X-YMail-OSG: SGtzkZgVM1kQNkJJDgNs9JhS59mfqyjyVmxe6k.ucgjPURwShGsu5dTaAEgPw_VV81HyIHy0BJ1dcFT6u_icDHh3ZXe7y4JMnaAPmno7IB0uOWr0.aDIbCxXPijX3Kc4DR_WtP1_1JjTaZF56y_f8cGd X-Yahoo-Newman-Property: ymail-3 Message-ID: <48247304.9020505@andybierman.com> Date: Fri, 09 May 2008 08:51:32 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Balazs Lengyel References: <200805071910.m47JAU5w061218@idle.juniper.net> <48246C63.9010308@ericsson.com> In-Reply-To: <48246C63.9010308@ericsson.com> Cc: netconf@ietf.org Subject: Re: [Netconf] xml declaration required or optional X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > Hello, > Actually we also have problems with buffering big configs. > > But you already get buffering problems if you have a big request > and you find at the very end, that you can't complete your reply. I see > the following possibilities: > - you buffer the 50MBs (or more) see if it OK or if you have to start by > sending an > - you start to stream out the big result message and if you run into an > error, you abort the rpc-reply or maybe even the complete session. IMO, this is a totally different problem than is intended to solve. 1) If your implementation cannot determine if the RPC method parameters are valid, before returning the appropriate reply, it is broken. 2) It is not relevant to the standard what an implementation does after it receives an request and before it sends an . This is way out of scope. If you stream out a reply before validating the parameters, then your implementation is broken. However, if the parameters are valid: SNMPv3 has an exception mechanism within the varbind list (e.g. noSuchInstance). NETCONF could have a similar 'runtime exception' mechanism, that allows elements to be embedded in and replies, instead of the actual data. Applications can use these exception markers to find out why some data that should be present could not be included in the reply. > Balazs > Andy > Phil Shafer wrote: >> We discussed it on the mailing list enough times. I see >> configs in the >50MB range. Bufferings not a reasonably >> solution. >> >>> The element was placed first so the manager would not >>> have to receive the entire element before knowing >>> it there were any errors or warnings. >> >> Are you saying that buffering's an issue for the manager, but >> not for the agent? That seems exactly backwards. >> >> Thanks, >> Phil >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun May 11 04:43:38 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E69428C15A; Sun, 11 May 2008 04:43:38 -0700 (PDT) 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 165D828C119 for ; Sun, 11 May 2008 04:43:36 -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 VX+5T4Wn3xR5 for ; Sun, 11 May 2008 04:43:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2517228C15E for ; Sun, 11 May 2008 04:43:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,468,1204520400"; d="scan'208";a="7895502" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 May 2008 07:43:31 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4BBhVfi032267; Sun, 11 May 2008 07:43:31 -0400 Received: from adsl-247-6-fixip.tiscali.ch (rtp-vpn2-24.cisco.com [10.82.240.24]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4BBhUav011612; Sun, 11 May 2008 11:43:31 GMT Message-ID: <4826DBE2.6000109@cisco.com> Date: Sun, 11 May 2008 13:43:30 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com><4811C0B5.7010907@cisco.com> <20080425114407.GC19025@elstar.local> <002101c8a955$4e0565b0$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145E07E1@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4146E002D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4146E002D@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.95.6 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=545; t=1210506211; x=1211370211; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Netconf]=20Notifications=3A=20Proposed =20Edits=20to=20ResolveDiscuss=09Issues |Sender:=20 |To:=20Sharon=20Chisholm=20; bh=BLTfFTg8hvkKzg8fjHmItLyVDEVWBlMRN6y4o5xK34E=; b=mqBNiZxu2FDG49Joo6kpphUNsJ4bfDhKkEIdPhdaBu/uVoO8h3VRlxgEb9 A0YUQe6kzDC9kpoJ7iOxJZowElRytqvydHw7Yw2uv6enfessOK4xQs7cCqqv eCDGVoT+qP; Authentication-Results: rtp-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Greetings Sharon, and sorry for the delay (was on holiday), As to the below, my rule would be simple: have one reference. I understand Juergen's point, but I don't feel strongly as to which approach to take so long as it's one approach. > 1) Keep both references > 2) Just have a reference to RFC3339 > 3) Just have a reference to RFC3339 section 4.4 and appendix A > 4) Just have a reference to RFC3339 section 4.4 > 5) Just have a reference to RFC339 appendix A > And so I would be happy with [2], [4], or [5]. Eliot _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun May 11 04:43:38 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E69428C15A; Sun, 11 May 2008 04:43:38 -0700 (PDT) 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 165D828C119 for ; Sun, 11 May 2008 04:43:36 -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 VX+5T4Wn3xR5 for ; Sun, 11 May 2008 04:43:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2517228C15E for ; Sun, 11 May 2008 04:43:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,468,1204520400"; d="scan'208";a="7895502" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 May 2008 07:43:31 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4BBhVfi032267; Sun, 11 May 2008 07:43:31 -0400 Received: from adsl-247-6-fixip.tiscali.ch (rtp-vpn2-24.cisco.com [10.82.240.24]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4BBhUav011612; Sun, 11 May 2008 11:43:31 GMT Message-ID: <4826DBE2.6000109@cisco.com> Date: Sun, 11 May 2008 13:43:30 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com><4811C0B5.7010907@cisco.com> <20080425114407.GC19025@elstar.local> <002101c8a955$4e0565b0$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B4145E07E1@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4146E002D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4146E002D@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.95.6 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=545; t=1210506211; x=1211370211; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Netconf]=20Notifications=3A=20Proposed =20Edits=20to=20ResolveDiscuss=09Issues |Sender:=20 |To:=20Sharon=20Chisholm=20; bh=BLTfFTg8hvkKzg8fjHmItLyVDEVWBlMRN6y4o5xK34E=; b=mqBNiZxu2FDG49Joo6kpphUNsJ4bfDhKkEIdPhdaBu/uVoO8h3VRlxgEb9 A0YUQe6kzDC9kpoJ7iOxJZowElRytqvydHw7Yw2uv6enfessOK4xQs7cCqqv eCDGVoT+qP; Authentication-Results: rtp-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Greetings Sharon, and sorry for the delay (was on holiday), As to the below, my rule would be simple: have one reference. I understand Juergen's point, but I don't feel strongly as to which approach to take so long as it's one approach. > 1) Keep both references > 2) Just have a reference to RFC3339 > 3) Just have a reference to RFC3339 section 4.4 and appendix A > 4) Just have a reference to RFC3339 section 4.4 > 5) Just have a reference to RFC339 appendix A > And so I would be happy with [2], [4], or [5]. Eliot _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 13 02:14:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978AA3A6BE5; Tue, 13 May 2008 02:14:55 -0700 (PDT) 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 955173A6BEF for ; Tue, 13 May 2008 02:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 nSx+Tc-Tu86T for ; Tue, 13 May 2008 02:14:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 782233A6BE3 for ; Tue, 13 May 2008 02:14:52 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4D9ERSf017154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 11:14:27 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4D9EHlO012310; Tue, 13 May 2008 11:14:27 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 11:14:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 11:14:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF WG Session at IETF 72 thread-index: Aci02bpxc9vXAJldRMKlX3dyxF7AJQ== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 13 May 2008 09:14:23.0232 (UTC) FILETIME=[BBD5E800:01C8B4D9] Subject: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1204032379==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1204032379== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B4D9.BB5AAC6A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B4D9.BB5AAC6A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, we requested a 1-hour session at the IETF #72 in Dublin. Our main focus in the session will be on open issue discussion. We entered following WGs to avoid conflicts with relevant=20 sessions: Prio 1: opsarea opsawg netmod ipfix syslog opsec radext=20 Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg Prio 3: dime dnsop dnsext dhc bmwg=20 Please let us know if you have any comments or want to=20 add any other session to the list. Cheers,=20 Mehmet & Bert ------_=_NextPart_001_01C8B4D9.BB5AAC6A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72

Hi = All,

we requested a = 1-hour session at the IETF #72 in Dublin.
Our main focus = in the session will be on open issue discussion.

We entered = following WGs to avoid conflicts with relevant
sessions:

Prio 1: opsarea = opsawg netmod ipfix syslog opsec radext
Prio 2: ippm = pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg
Prio 3: dime = dnsop dnsext dhc bmwg

Please let us = know if you have any comments or want to
add any other = session to the list.

Cheers,
Mehmet & Bert

------_=_NextPart_001_01C8B4D9.BB5AAC6A-- --===============1204032379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1204032379==-- From netconf-bounces@ietf.org Tue May 13 02:14:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978AA3A6BE5; Tue, 13 May 2008 02:14:55 -0700 (PDT) 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 955173A6BEF for ; Tue, 13 May 2008 02:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 nSx+Tc-Tu86T for ; Tue, 13 May 2008 02:14:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 782233A6BE3 for ; Tue, 13 May 2008 02:14:52 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4D9ERSf017154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 11:14:27 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4D9EHlO012310; Tue, 13 May 2008 11:14:27 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 11:14:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 11:14:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF WG Session at IETF 72 thread-index: Aci02bpxc9vXAJldRMKlX3dyxF7AJQ== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 13 May 2008 09:14:23.0232 (UTC) FILETIME=[BBD5E800:01C8B4D9] Subject: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1204032379==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1204032379== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B4D9.BB5AAC6A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B4D9.BB5AAC6A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, we requested a 1-hour session at the IETF #72 in Dublin. Our main focus in the session will be on open issue discussion. We entered following WGs to avoid conflicts with relevant=20 sessions: Prio 1: opsarea opsawg netmod ipfix syslog opsec radext=20 Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg Prio 3: dime dnsop dnsext dhc bmwg=20 Please let us know if you have any comments or want to=20 add any other session to the list. Cheers,=20 Mehmet & Bert ------_=_NextPart_001_01C8B4D9.BB5AAC6A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72

Hi = All,

we requested a = 1-hour session at the IETF #72 in Dublin.
Our main focus = in the session will be on open issue discussion.

We entered = following WGs to avoid conflicts with relevant
sessions:

Prio 1: opsarea = opsawg netmod ipfix syslog opsec radext
Prio 2: ippm = pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg
Prio 3: dime = dnsop dnsext dhc bmwg

Please let us = know if you have any comments or want to
add any other = session to the list.

Cheers,
Mehmet & Bert

------_=_NextPart_001_01C8B4D9.BB5AAC6A-- --===============1204032379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1204032379==-- From netconf-bounces@ietf.org Tue May 13 07:30:38 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA413A67F7; Tue, 13 May 2008 07:30:37 -0700 (PDT) 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 438313A67F7 for ; Tue, 13 May 2008 07:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 dd4iG1m0xoBr for ; Tue, 13 May 2008 07:30:35 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 826F83A65A6 for ; Tue, 13 May 2008 07:30:35 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id R07i1Z0010vp7WLA70Ek00; Tue, 13 May 2008 14:28:10 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id R2UY1Z0094HwxpC8R00000; Tue, 13 May 2008 14:28:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=TGu6PMPeRocA:10 a=U62aKmVDKR8A:10 a=h4uoAmOJE9UXmHAtt_oA:9 a=ZYPONH42NGm1xfTkykJedFvhsfUA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=JA1z9Mnnm689uGPQvn4A:9 a=k-13GytePIdSrihfcFwA:7 a=tVSjmwgpsV-vMsGSWd1BjRocXuYA:4 a=AfD3MYMu9mQA:10 From: "David Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: Date: Tue, 13 May 2008 10:28:32 -0400 Message-ID: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aci02bpxc9vXAJldRMKlX3dyxF7AJQAKunWA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0577358202==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0577358202== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0616_01C8B4E4.18B9C4B0" This is a multi-part message in MIME format. ------=_NextPart_000_0616_01C8B4E4.18B9C4B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mehmet (and bert), dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session From netconf-bounces@ietf.org Tue May 13 07:30:38 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA413A67F7; Tue, 13 May 2008 07:30:37 -0700 (PDT) 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 438313A67F7 for ; Tue, 13 May 2008 07:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 dd4iG1m0xoBr for ; Tue, 13 May 2008 07:30:35 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 826F83A65A6 for ; Tue, 13 May 2008 07:30:35 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id R07i1Z0010vp7WLA70Ek00; Tue, 13 May 2008 14:28:10 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id R2UY1Z0094HwxpC8R00000; Tue, 13 May 2008 14:28:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=TGu6PMPeRocA:10 a=U62aKmVDKR8A:10 a=h4uoAmOJE9UXmHAtt_oA:9 a=ZYPONH42NGm1xfTkykJedFvhsfUA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 a=JA1z9Mnnm689uGPQvn4A:9 a=k-13GytePIdSrihfcFwA:7 a=tVSjmwgpsV-vMsGSWd1BjRocXuYA:4 a=AfD3MYMu9mQA:10 From: "David Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: Date: Tue, 13 May 2008 10:28:32 -0400 Message-ID: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aci02bpxc9vXAJldRMKlX3dyxF7AJQAKunWA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0577358202==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0577358202== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0616_01C8B4E4.18B9C4B0" This is a multi-part message in MIME format. ------=_NextPart_000_0616_01C8B4E4.18B9C4B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mehmet (and bert), dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session at IETat IETF 72 Hi All, we requested a 1-hour session at the IETF #72 in Dublin. Our main focus in the session will be on open issue discussion. We entered following WGs to avoid conflicts with relevant sessions: Prio 1: opsarea opsawg netmod ipfix syslog opsec radext Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg Prio 3: dime dnsop dnsext dhc bmwg Please let us know if you have any comments or want to add any other session to the list. Cheers, Mehmet & Bert ------=_NextPart_000_0616_01C8B4E4.18B9C4B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72
Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, and = should draw=20 at least me, bert, juergen, daveN, wes, and randy, so that should = probably be a=20 prio 1.
 
David=20 Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] NETCONF WG Session at = IETF=20 72


Hi All, =

we requested a 1-hour = session at=20 the IETF #72 in Dublin.
Our main focus in the session will be on open issue=20 discussion.

We entered = following WGs to=20 avoid conflicts with relevant
sessions:

Prio 1: opsarea = opsawg netmod=20 ipfix syslog opsec radext
Prio 2: ippm pmol psamp tsvarea apparea dime = dnsop isms=20 v6ops tsvwg
Prio=20 3: dime dnsop dnsext dhc bmwg

Please let us know = if you have=20 any comments or want to
add any other session to the list.

NETCONF WG Session at IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, and = should draw=20 at least me, bert, juergen, daveN, wes, and randy, so that should = probably be a=20 prio 1.
 
David=20 Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] NETCONF WG Session at = IETF=20 72


Hi All, =

we requested a 1-hour = session at=20 the IETF #72 in Dublin.
Our main focus in the session will be on open issue=20 discussion.

We entered = following WGs to=20 avoid conflicts with relevant
sessions:

Prio 1: opsarea = opsawg netmod=20 ipfix syslog opsec radext
Prio 2: ippm pmol psamp tsvarea apparea dime = dnsop isms=20 v6ops tsvwg
Prio=20 3: dime dnsop dnsext dhc bmwg

Please let us know = if you have=20 any comments or want to
add any other session to the list.

Cheers,
Mehmet = &=20 Bert =

------=_NextPart_000_0616_01C8B4E4.18B9C4B0-- --===============0577358202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0577358202==-- g=3Dde>Cheers,
Mehmet = &=20 Bert =

------=_NextPart_000_0616_01C8B4E4.18B9C4B0-- --===============0577358202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0577358202==-- From netconf-bounces@ietf.org Tue May 13 07:55:32 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66963A682D; Tue, 13 May 2008 07:55:32 -0700 (PDT) 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 8EA173A682D for ; Tue, 13 May 2008 07:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 0OJfqmYMKRaF for ; Tue, 13 May 2008 07:55:30 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 0AF7E3A67F7 for ; Tue, 13 May 2008 07:55:29 -0700 (PDT) Received: (qmail 36973 invoked from network); 13 May 2008 14:54:34 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 13 May 2008 14:54:34 -0000 From: "Bert Wijnen - IETF" To: "David Harrington" , "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , Date: Tue, 13 May 2008 16:54:42 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0645526215==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0645526215== Content-Type: multipart/alternative; boundary="----=_NextPart_000_044B_01C8B51A.0A5EA0D0" This is a multi-part message in MIME format. ------=_NextPart_000_044B_01C8B51A.0A5EA0D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit NETCONF WG Session at IETF 72I agree (and though Mehmet also agreed when we discussed this) that ISMS should be priority 1 to avoid. You may be right about psamp and ifpifx. dime is prio 2. Are you suggesting it should be 1? dnsop at prio 3 seems fine to me. In any event, I don';t think we can list all groups as an absolute CANNOT conflict, otherwise scheduling may become impossible for the secretariat Bert Wijnen -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David Harrington Verzonden: dinsdag 13 mei 2008 16:29 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] NETCONF WG Session at IETF 72 Hi Mehmet (and bert), dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ---------------------------------------------------------------------------- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session at IETF 72 Hi All, we requested a 1-hour session at the IETF #72 in Dublin. Our main focus in the session will be on open issue discussion. We entered following WGs to avoid conflicts with relevant sessions: Prio 1: opsarea opsawg netmod ipfix syslog opsec radext Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg Prio 3: dime dnsop dnsext dhc bmwg Please let us know if you have any comments or want to add any other session to the list. Cheers, Mehmet & Bert ------=_NextPart_000_044B_01C8B51A.0A5EA0D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72
I=20 agree (and though Mehmet also agreed when we discussed this) that ISMS=20 should
be=20 priority 1 to avoid.
 
You=20 may be right about psamp and ifpifx.
 
dime=20 is prio 2. Are you suggesting it should be 1?
dnsop=20 at prio 3 seems fine to me.
 
In any=20 event, I don';t think we can list all groups as an absolute CANNOT=20 conflict,
otherwise scheduling may become impossible for the=20 secretariat
 

Bert Wijnen

-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens = David=20 Harrington
Verzonden: dinsdag 13 mei 2008 = 16:29
Aan:=20 'Ersue, Mehmet (NSN - DE/Muenich)'; = netconf@ietf.org
Onderwerp: Re:=20 [Netconf] NETCONF WG Session at IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, and = should draw=20 at least me, bert, juergen, daveN, wes, and randy, so that should = probably be=20 a prio 1.
 
David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] NETCONF WG Session at = IETF=20 72


Hi = All,

we requested a = 1-hour session at=20 the IETF #72 in Dublin.
Our main focus in the session will be on = open issue=20 discussion.

We entered = following WGs to=20 avoid conflicts with relevant
sessions:

Prio 1: opsarea = opsawg netmod=20 ipfix syslog opsec radext
Prio 2: ippm pmol psamp tsvarea apparea dime = dnsop isms=20 v6ops tsvwg
Prio 3: dime dnsop dnsext dhc bmwg

Please let us = know if you have=20 any comments or want to
add any other session to the = list.

Cheers,
Mehmet = &=20 Bert=20

------=_NextPart_000_044B_01C8B51A.0A5EA0D0-- --===============0645526215== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0645526215==-- From netconf-bounces@ietf.org Tue May 13 07:55:32 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66963A682D; Tue, 13 May 2008 07:55:32 -0700 (PDT) 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 8EA173A682D for ; Tue, 13 May 2008 07:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 0OJfqmYMKRaF for ; Tue, 13 May 2008 07:55:30 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 0AF7E3A67F7 for ; Tue, 13 May 2008 07:55:29 -0700 (PDT) Received: (qmail 36973 invoked from network); 13 May 2008 14:54:34 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 13 May 2008 14:54:34 -0000 From: "Bert Wijnen - IETF" To: "David Harrington" , "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , Date: Tue, 13 May 2008 16:54:42 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0645526215==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0645526215== Content-Type: multipart/alternative; boundary="----=_NextPart_000_044B_01C8B51A.0A5EA0D0" This is a multi-part message in MIME format. ------=_NextPart_000_044B_01C8B51A.0A5EA0D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit NETCONF WG Session at IETF 72I agree (and though Mehmet also agreed when we discussed this) that ISMS should be priority 1 to avoid. You may be right about psamp and ifpifx. dime is prio 2. Are you suggesting it should be 1? dnsop at prio 3 seems fine to me. In any event, I don';t think we can list all groups as an absolute CANNOT conflict, otherwise scheduling may become impossible for the secretariat Bert Wijnen -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David Harrington Verzonden: dinsdag 13 mei 2008 16:29 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] NETCONF WG Session at IETF 72 Hi Mehmet (and bert), dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ---------------------------------------------------------------------------- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session at IETF 72 Hi All, we requested a 1-hour session at the IETF #72 in Dublin. Our main focus in the session will be on open issue discussion. We entered following WGs to avoid conflicts with relevant sessions: Prio 1: opsarea opsawg netmod ipfix syslog opsec radext Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg Prio 3: dime dnsop dnsext dhc bmwg Please let us know if you have any comments or want to add any other session to the list. Cheers, Mehmet & Bert ------=_NextPart_000_044B_01C8B51A.0A5EA0D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72
I=20 agree (and though Mehmet also agreed when we discussed this) that ISMS=20 should
be=20 priority 1 to avoid.
 
You=20 may be right about psamp and ifpifx.
 
dime=20 is prio 2. Are you suggesting it should be 1?
dnsop=20 at prio 3 seems fine to me.
 
In any=20 event, I don';t think we can list all groups as an absolute CANNOT=20 conflict,
otherwise scheduling may become impossible for the=20 secretariat
 

Bert Wijnen

-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens = David=20 Harrington
Verzonden: dinsdag 13 mei 2008 = 16:29
Aan:=20 'Ersue, Mehmet (NSN - DE/Muenich)'; = netconf@ietf.org
Onderwerp: Re:=20 [Netconf] NETCONF WG Session at IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, and = should draw=20 at least me, bert, juergen, daveN, wes, and randy, so that should = probably be=20 a prio 1.
 
David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] NETCONF WG Session at = IETF=20 72


Hi = All,

we requested a = 1-hour session at=20 the IETF #72 in Dublin.
Our main focus in the session will be on = open issue=20 discussion.

We entered = following WGs to=20 avoid conflicts with relevant
sessions:

Prio 1: opsarea = opsawg netmod=20 ipfix syslog opsec radext
Prio 2: ippm pmol psamp tsvarea apparea dime = dnsop isms=20 v6ops tsvwg
Prio 3: dime dnsop dnsext dhc bmwg

Please let us = know if you have=20 any comments or want to
add any other session to the = list.

Cheers,
Mehmet = &=20 Bert=20

------=_NextPart_000_044B_01C8B51A.0A5EA0D0-- --===============0645526215== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0645526215==-- From netconf-bounces@ietf.org Tue May 13 08:00:09 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E06728C30A; Tue, 13 May 2008 08:00:09 -0700 (PDT) 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 53A2C28C2FF for ; Tue, 13 May 2008 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 v7nxJgFRI55K for ; Tue, 13 May 2008 08:00:00 -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 4588E28C2EB for ; Tue, 13 May 2008 07:59:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,480,1204520400"; d="scan'208,217";a="107056275" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 May 2008 10:58:58 -0400 X-IronPort-AV: E=Sophos;i="4.27,480,1204520400"; d="scan'208,217";a="194470546" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 13 May 2008 10:58:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 16:58:55 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] NETCONF WG Session at IETF 72 Thread-Index: Aci1CWZkqfynZQz9SqeRUKNFRQGQigAAGInw References: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen - IETF" , "David Harrington" , "Ersue, Mehmet (NSN - DE/Muenich)" , Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0129688167==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0129688167== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B509.DE84635B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B509.DE84635B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable dime should be prio 1 because it's a wg I am sponsoring, same as netconf =20 Dan =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen - IETF Sent: Tuesday, May 13, 2008 5:55 PM To: David Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Subject: Re: [Netconf] NETCONF WG Session at IETF 72 =09 =09 I agree (and though Mehmet also agreed when we discussed this) that ISMS should be priority 1 to avoid. =20 You may be right about psamp and ifpifx. =20 dime is prio 2. Are you suggesting it should be 1? dnsop at prio 3 seems fine to me.=20 =20 In any event, I don';t think we can list all groups as an absolute CANNOT conflict, otherwise scheduling may become impossible for the secretariat =20 Bert Wijnen=20 -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David Harrington Verzonden: dinsdag 13 mei 2008 16:29 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi Mehmet (and bert), =20 dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. =20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com =09 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi All,=20 we requested a 1-hour session at the IETF #72 in Dublin.=20 Our main focus in the session will be on open issue discussion.=20 We entered following WGs to avoid conflicts with relevant=20 sessions:=20 Prio 1: opsarea opsawg netmod ipfix syslog opsec radext=20 Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg=20 Prio 3: dime dnsop dnsext dhc bmwg=20 Please let us know if you have any comments or want to=20 add any other session to the list.=20 Cheers, Mehmet & Bert=20 ------_=_NextPart_001_01C8B509.DE84635B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72
dime should be prio 1 because it's a wg I am = sponsoring, same=20 as netconf
 
Dan
 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen -=20 IETF
Sent: Tuesday, May 13, 2008 5:55 PM
To: David = Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Subject: Re: [Netconf] NETCONF WG Session = at IETF=20 72

I=20 agree (and though Mehmet also agreed when we discussed this) that ISMS = should
be=20 priority 1 to avoid.
 
You=20 may be right about psamp and ifpifx.
 
dime=20 is prio 2. Are you suggesting it should be 1?
dnsop at prio 3 seems fine to me.
 
In=20 any event, I don';t think we can list all groups as an absolute CANNOT = conflict,
otherwise scheduling may become impossible for the=20 secretariat
 

Bert Wijnen

-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens=20 David Harrington
Verzonden: dinsdag 13 mei 2008=20 16:29
Aan: 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Onderwerp: Re: [Netconf] NETCONF WG = Session at=20 IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 = and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, = and should=20 draw at least me, bert, juergen, daveN, wes, and randy, so that = should=20 probably be a prio 1.
 
David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: netconf-bounces@ietf.org = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = Mehmet (NSN -=20 DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] NETCONF WG Session = at IETF=20 72


Hi = All,

we requested a = 1-hour session=20 at the IETF #72 in Dublin.
Our main focus in the session will be on = open issue=20 discussion.

We entered = following WGs to=20 avoid conflicts with relevant
sessions:

Prio 1: = opsarea opsawg=20 netmod ipfix syslog opsec radext
Prio 2: ippm pmol psamp tsvarea apparea = dime dnsop=20 isms v6ops tsvwg
Prio 3: dime dnsop dnsext dhc bmwg

Please let us = know if you=20 have any comments or want to
add any other session to the = list.

Cheers,
Mehmet = &=20 Bert=20

------_=_NextPart_001_01C8B509.DE84635B-- --===============0129688167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0129688167==-- From netconf-bounces@ietf.org Tue May 13 08:00:09 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E06728C30A; Tue, 13 May 2008 08:00:09 -0700 (PDT) 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 53A2C28C2FF for ; Tue, 13 May 2008 08:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 v7nxJgFRI55K for ; Tue, 13 May 2008 08:00:00 -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 4588E28C2EB for ; Tue, 13 May 2008 07:59:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,480,1204520400"; d="scan'208,217";a="107056275" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 May 2008 10:58:58 -0400 X-IronPort-AV: E=Sophos;i="4.27,480,1204520400"; d="scan'208,217";a="194470546" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 13 May 2008 10:58:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 16:58:55 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] NETCONF WG Session at IETF 72 Thread-Index: Aci1CWZkqfynZQz9SqeRUKNFRQGQigAAGInw References: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen - IETF" , "David Harrington" , "Ersue, Mehmet (NSN - DE/Muenich)" , Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0129688167==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0129688167== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B509.DE84635B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B509.DE84635B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable dime should be prio 1 because it's a wg I am sponsoring, same as netconf =20 Dan =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen - IETF Sent: Tuesday, May 13, 2008 5:55 PM To: David Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Subject: Re: [Netconf] NETCONF WG Session at IETF 72 =09 =09 I agree (and though Mehmet also agreed when we discussed this) that ISMS should be priority 1 to avoid. =20 You may be right about psamp and ifpifx. =20 dime is prio 2. Are you suggesting it should be 1? dnsop at prio 3 seems fine to me.=20 =20 In any event, I don';t think we can list all groups as an absolute CANNOT conflict, otherwise scheduling may become impossible for the secretariat =20 Bert Wijnen=20 -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David Harrington Verzonden: dinsdag 13 mei 2008 16:29 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi Mehmet (and bert), =20 dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. =20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com =09 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi All,=20 we requested a 1-hour session at the IETF #72 in Dublin.=20 Our main focus in the session will be on open issue discussion.=20 We entered following WGs to avoid conflicts with relevant=20 sessions:=20 Prio 1: opsarea opsawg netmod ipfix syslog opsec radext=20 Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg=20 Prio 3: dime dnsop dnsext dhc bmwg=20 Please let us know if you have any comments or want to=20 add any other session to the list.=20 Cheers, Mehmet & Bert=20 ------_=_NextPart_001_01C8B509.DE84635B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72
dime should be prio 1 because it's a wg I am = sponsoring, same=20 as netconf
 
Dan
 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen -=20 IETF
Sent: Tuesday, May 13, 2008 5:55 PM
To: David = Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Subject: Re: [Netconf] NETCONF WG Session = at IETF=20 72

I=20 agree (and though Mehmet also agreed when we discussed this) that ISMS = should
be=20 priority 1 to avoid.
 
You=20 may be right about psamp and ifpifx.
 
dime=20 is prio 2. Are you suggesting it should be 1?
dnsop at prio 3 seems fine to me.
 
In=20 any event, I don';t think we can list all groups as an absolute CANNOT = conflict,
otherwise scheduling may become impossible for the=20 secretariat
 

Bert Wijnen

-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens=20 David Harrington
Verzonden: dinsdag 13 mei 2008=20 16:29
Aan: 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Onderwerp: Re: [Netconf] NETCONF WG = Session at=20 IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 = and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, = and should=20 draw at least me, bert, juergen, daveN, wes, and randy, so that = should=20 probably be a prio 1.
 
David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: netconf-bounces@ietf.org = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = Mehmet (NSN -=20 DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] NETCONF WG Session = at IETF=20 72


Hi = All,

we requested a = 1-hour session=20 at the IETF #72 in Dublin.
Our main focus in the session will be on = open issue=20 discussion.

We entered = following WGs to=20 avoid conflicts with relevant
sessions:

Prio 1: = opsarea opsawg=20 netmod ipfix syslog opsec radext
Prio 2: ippm pmol psamp tsvarea apparea = dime dnsop=20 isms v6ops tsvwg
Prio 3: dime dnsop dnsext dhc bmwg

Please let us = know if you=20 have any comments or want to
add any other session to the = list.

Cheers,
Mehmet = &=20 Bert=20

------_=_NextPart_001_01C8B509.DE84635B-- --===============0129688167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0129688167==-- From netconf-bounces@ietf.org Tue May 13 09:17:58 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9553A67F7; Tue, 13 May 2008 09:17:58 -0700 (PDT) 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 351493A6C27 for ; Tue, 13 May 2008 09:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 MaWRjU1JxQHt for ; Tue, 13 May 2008 09:17:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 6276E3A68B6 for ; Tue, 13 May 2008 09:17:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4DF1GcQ031971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 17:01:16 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4DF0qr4024186; Tue, 13 May 2008 17:01:16 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 17:00:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 17:00:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] NETCONF WG Session at IETF 72 thread-index: Aci1CUUydzrw5PWHQ9yPv5KDU0ysBAAADmCw References: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Bert Wijnen - IETF" , "David Harrington" , X-OriginalArrivalTime: 13 May 2008 15:00:55.0880 (UTC) FILETIME=[25383480:01C8B50A] Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0455311182==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0455311182== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B50A.24B11C2E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B50A.24B11C2E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, Bert, =20 pmol, psamp, dime are prio 1 for Dan. I set isms prio 1 too. Anyways the session request tool accepts 3 prio levels which we use all. Cheers, Mehmet=20 =20 ________________________________ From: ext Bert Wijnen - IETF [mailto:bertietf@bwijnen.net]=20 Sent: Tuesday, May 13, 20From netconf-bounces@ietf.org Tue May 13 09:17:58 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9553A67F7; Tue, 13 May 2008 09:17:58 -0700 (PDT) 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 351493A6C27 for ; Tue, 13 May 2008 09:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 MaWRjU1JxQHt for ; Tue, 13 May 2008 09:17:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 6276E3A68B6 for ; Tue, 13 May 2008 09:17:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4DF1GcQ031971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 17:01:16 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4DF0qr4024186; Tue, 13 May 2008 17:01:16 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 17:00:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 17:00:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] NETCONF WG Session at IETF 72 thread-index: Aci1CUUydzrw5PWHQ9yPv5KDU0ysBAAADmCw References: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Bert Wijnen - IETF" , "David Harrington" , X-OriginalArrivalTime: 13 May 2008 15:00:55.0880 (UTC) FILETIME=[25383480:01C8B50A] Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0455311182==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0455311182== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B50A.24B11C2E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B50A.24B11C2E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, Bert, =20 pmol, psamp, dime are prio 1 for Dan. I set isms prio 1 too. Anyways the session request tool accepts 3 prio levels which we use all. Cheers, Mehmet=20 =20 ________________________________ From: ext Bert Wijnen - IETF [mailto:bertietf@bwijnen.net]=20 Sent: Tuesday, May 08 4:55 PM To: David Harrington; Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] NETCONF WG Session at IETF 72 =09 =09 I agree (and though Mehmet also agreed when we discussed this) that ISMS should be priority 1 to avoid. =20 You may be right about psamp and ifpifx. =20 dime is prio 2. Are you suggesting it should be 1? dnsop at prio 3 seems fine to me.=20 =20 In any event, I don';t think we can list all groups as an absolute CANNOT conflict, otherwise scheduling may become impossible for the secretariat =20 Bert Wijnen=20 -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David Harrington Verzonden: dinsdag 13 mei 2008 16:29 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi Mehmet (and bert), =20 dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. =20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com =09 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi All,=20 we requested a 1-hour session at the IETF #72 in Dublin.=20 Our main focus in the session will be on open issue discussion.=20 We entered following WGs to avoid conflicts with relevant=20 sessions:=20 Prio 1: opsarea opsawg netmod ipfix syslog opsec radext=20 Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg=20 Prio 3: dime dnsop dnsext dhc bmwg=20 Please let us know if you have any comments or want to=20 add any other session to the list.=20 Cheers, Mehmet & Bert=20 ------_=_NextPart_001_01C8B50A.24B11C2E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72
Hi Dave,=20 Bert,
 
pmol, psamp,=20 dime are prio 1=20 for Dan. I set isms prio 1=20 too.
Anyways the session request tool accepts 3 = prio levels=20 which
we use = all.

Cheers,
Mehmet

 

<13, 2008 4:55 PM To: David Harrington; Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] NETCONF WG Session at IETF 72 =09 =09 I agree (and though Mehmet also agreed when we discussed this) that ISMS should be priority 1 to avoid. =20 You may be right about psamp and ifpifx. =20 dime is prio 2. Are you suggesting it should be 1? dnsop at prio 3 seems fine to me.=20 =20 In any event, I don';t think we can list all groups as an absolute CANNOT conflict, otherwise scheduling may become impossible for the secretariat =20 Bert Wijnen=20 -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David Harrington Verzonden: dinsdag 13 mei 2008 16:29 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi Mehmet (and bert), =20 dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. =20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com =09 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi All,=20 we requested a 1-hour session at the IETF #72 in Dublin.=20 Our main focus in the session will be on open issue discussion.=20 We entered following WGs to avoid conflicts with relevant=20 sessions:=20 Prio 1: opsarea opsawg netmod ipfix syslog opsec radext=20 Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg=20 Prio 3: dime dnsop dnsext dhc bmwg=20 Please let us know if you have any comments or want to=20 add any other session to the list.=20 Cheers, Mehmet & Bert=20 ------_=_NextPart_001_01C8B50A.24B11C2E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72
Hi Dave,=20 Bert,
 
pmol, psamp,=20 dime are prio 1=20 for Dan. I set isms prio 1=20 too.
Anyways the session request tool accepts 3 = prio levels=20 which
we use = all.

Cheers,
Mehmet

 

From: ext Bert Wijnen - IETF=20 [mailto:bertietf@bwijnen.net]
Sent: Tuesday, May 13, 2008 = 4:55=20 PM
To: David Harrington; Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Subject: RE: [Netconf] NETCONF WG Session = at IETF=20 72

I=20 agree (and though Mehmet also agreed when we discussed this) that ISMS = should
be=20 priority 1 to avoid.
 
You=20 may be right about psamp and ifpifx.
 
dime=20 is prio 2. Are you suggesting it should be 1?
dnsop at prio 3 seems fine to me.
 
In=20 any event, I don';t think we can list all groups as an absolute CANNOT = conflict,
otherwise scheduling may become impossible for the=20 secretariat
 

Bert Wijnen

-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens=20 David Harrington
Verzonden: dinsdag 13 mei 2008=20 16:29
Aan: 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Onderwerp: Re: [Netconf] NETCONF WG = Session at=20 IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 = and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, = and should=20 draw at least me, bert, juergen, daveN, wes, and randy, so that = should=20 probably be a prio 1.
 
David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: ext Bert Wijnen - IETF=20 [mailto:bertietf@bwijnen.net]
Sent: Tuesday, May 13, 2008 = 4:55=20 PM
To: David Harrington; Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Subject: RE: [Netconf] NETCONF WG Session = at IETF=20 72

I=20 agree (and though Mehmet also agreed when we discussed this) that ISMS = should
be=20 priority 1 to avoid.
 
You=20 may be right about psamp and ifpifx.
 
dime=20 is prio 2. Are you suggesting it should be 1?
dnsop at prio 3 seems fine to me.
 
In=20 any event, I don';t think we can list all groups as an absolute CANNOT = conflict,
otherwise scheduling may become impossible for the=20 secretariat
 

Bert Wijnen

-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens=20 David Harrington
Verzonden: dinsdag 13 mei 2008=20 16:29
Aan: 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Onderwerp: Re: [Netconf] NETCONF WG = Session at=20 IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 = and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, = and should=20 draw at least me, bert, juergen, daveN, wes, and randy, so that = should=20 probably be a prio 1.
 
David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: netconf-bounces@ietf.org = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = Mehmet (NSN -=20 DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] NETCONF WG Session = at IETF=20 72


Hi = All,

we requested a = 1-hour session=20 at the IETF #72 in Dublin.
Our main focus in the session will be on = open issue=20 discussion.

We entered = following WGs to=20 avoid conflicts with relevant
sessions:

Prio 1: = opsarea opsawg=20 netmod ipfix syslog opsec radext
Prio 2: ippm pmol psamp tsvarea apparea = dime dnsop=20 isms v6ops tsvwg
Prio 3: dime dnsop dnsext dhc bmwg

Please let us = know if you=20 have any comments or want to
add any other session to the = list.

Cheers,
Mehmet = &=20 Bert=20

------_=_NextPart_001_01C8B50A.24B11C2E-- --===============0455311182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0455311182==-- 0ff = 2px solid; MARGIN-RIGHT: 0px">
From: netconf-bounces@ietf.org = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = Mehmet (NSN -=20 DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] NETCONF WG Session = at IETF=20 72


Hi = All,

we requested a = 1-hour session=20 at the IETF #72 in Dublin.
Our main focus in the session will be on = open issue=20 discussion.

We entered = following WGs to=20 avoid conflicts with relevant
sessions:

Prio 1: = opsarea opsawg=20 netmod ipfix syslog opsec radext
Prio 2: ippm pmol psamp tsvarea apparea = dime dnsop=20 isms v6ops tsvwg
Prio 3: dime dnsop dnsext dhc bmwg

Please let us = know if you=20 have any comments or want to
add any other session to the = list.

Cheers,
Mehmet = &=20 Bert=20

------_=_NextPart_001_01C8B50A.24B11C2E-- --===============0455311182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0455311182==-- From netconf-bounces@ietf.org Tue May 13 20:25:51 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6CF13A69DC; Tue, 13 May 2008 20:25:51 -0700 (PDT) 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 55BA13A69DC for ; Tue, 13 May 2008 20:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 xquys0EyQm-y for ; Tue, 13 May 2008 20:25:45 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 23BC43A69AF for ; Tue, 13 May 2008 20:25:45 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id RFLb1Z0061HpZEsAA01E00; Wed, 14 May 2008 03:24:35 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id RFRj1Z00C4HwxpC8a00000; Wed, 14 May 2008 03:25:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=TGu6PMPeRocA:10 a=U62aKmVDKR8A:10 a=AYJSm_3cLQ6QT-fs7poA:9 a=AtkCimHjP-j1K81ypusA:7 a=SLiYChvf8pj-eSdTMHGrmywXDa8A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=oH_WKSxD8ioA:10 a=2uMJ1qzfawyPdw0fcUcA:9 a=5ps7b0glbXRjLLxyPhsA:7 a=G2L3waOuoopy1086nRQJh2OtMDkA:4 a=AfD3MYMu9mQA:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'David Harrington'" , "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> Date: Tue, 13 May 2008 23:25:43 -0400 Message-ID: <06b201c8b572$3241ee60$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aci1CWTEeEezfiBySe2GEk1/A4gdZAAaHHvQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1632195629==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1632195629== Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B3_01C8B550.AB304E60" This is a multi-part message in MIME format. ------=_NextPart_000_06B3_01C8B550.AB304E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My point about dime and dnsop is that they are both listed twice, under different priorities: Prio 2: ippm pmol psamp tsvarea apparea **dime dnsop** isms v6ops tsvwg Prio 3: **dime dnsop** dnsext dhc bmwg David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen - IETF Sent: From netconf-bounces@ietf.org Tue May 13 20:25:51 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6CF13A69DC; Tue, 13 May 2008 20:25:51 -0700 (PDT) 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 55BA13A69DC for ; Tue, 13 May 2008 20:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 xquys0EyQm-y for ; Tue, 13 May 2008 20:25:45 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 23BC43A69AF for ; Tue, 13 May 2008 20:25:45 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id RFLb1Z0061HpZEsAA01E00; Wed, 14 May 2008 03:24:35 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id RFRj1Z00C4HwxpC8a00000; Wed, 14 May 2008 03:25:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=TGu6PMPeRocA:10 a=U62aKmVDKR8A:10 a=AYJSm_3cLQ6QT-fs7poA:9 a=AtkCimHjP-j1K81ypusA:7 a=SLiYChvf8pj-eSdTMHGrmywXDa8A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=oH_WKSxD8ioA:10 a=2uMJ1qzfawyPdw0fcUcA:9 a=5ps7b0glbXRjLLxyPhsA:7 a=G2L3waOuoopy1086nRQJh2OtMDkA:4 a=AfD3MYMu9mQA:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'David Harrington'" , "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> Date: Tue, 13 May 2008 23:25:43 -0400 Message-ID: <06b201c8b572$3241ee60$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aci1CWTEeEezfiBySe2GEk1/A4gdZAAaHHvQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1632195629==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1632195629== Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B3_01C8B550.AB304E60" This is a multi-part message in MIME format. ------=_NextPart_000_06B3_01C8B550.AB304E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My point about dime and dnsop is that they are both listed twice, under different priorities: Prio 2: ippm pmol psamp tsvarea apparea **dime dnsop** isms v6ops tsvwg Prio 3: **dime dnsop** dnsext dhc bmwg David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen - IETF Sent: TuesdaTuesday, May 13, 2008 10:55 AM To: David Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Subject: Re: [Netconf] NETCONF WG Session at IETF 72 I agree (and though Mehmet also agreed when we discussed this) that ISMS should be priority 1 to avoid. You may be right about psamp and ifpifx. dime is prio 2. Are you suggesting it should be 1? dnsop at prio 3 seems fine to me. In any event, I don';t think we can list all groups as an absolute CANNOT conflict, otherwise scheduling may become impossible for the secretariat Bert Wijnen -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David Harrington Verzonden: dinsdag 13 mei 2008 16:29 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] NETCONF WG Session at IETF 72 Hi Mehmet (and bert), dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _____ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session at IETF 72 Hi All, we requested a 1-hour session at the IETF #72 in Dublin. Our main focus in the session will be on open issue discussion. We entered following WGs to avoid conflicts with relevant sessions: Prio 1: opsarea opsawg netmod ipfix syslog opsec radext Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg Prio 3: dime dnsop dnsext dhc bmwg Please let us know if you have any comments or want to add any other session to the list. Cheers, Mehmet & Bert ------=_NextPart_000_06B3_01C8B550.AB304E60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72
My point about dime and dnsop is that they are = both listed=20 twice, under different priorities:
 
Prio 2: ippm pmol psamp tsvarea apparea **dime = dnsop** isms=20 v6ops tsvwg
Prio 3:=20 **dime dnsop** dnsext dhc bmwg
 

David=20 Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen -=20 IETF
Sent: Tuesday, May 13, 2008 10:55 AM
To: = David=20 Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Subject: NETCONF WG Session at IETF 72
My point about dime and dnsop is that they are = both listed=20 twice, under different priorities:
 
Prio 2: ippm pmol psamp tsvarea apparea **dime = dnsop** isms=20 v6ops tsvwg
Prio 3:=20 **dime dnsop** dnsext dhc bmwg
 

David=20 Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen -=20 IETF
Sent: Tuesday, May 13, 2008 10:55 AM
To: = David=20 Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Subject: Re/B> Re: [Netconf] NETCONF WG Session = at IETF=20 72

I=20 agree (and though Mehmet also agreed when we discussed this) that ISMS = should
be=20 priority 1 to avoid.
 
You=20 may be right about psamp and ifpifx.
 
dime=20 is prio 2. Are you suggesting it should be 1?
dnsop at prio 3 seems fine to me.
 
In=20 any event, I don';t think we can list all groups as an absolute CANNOT = conflict,
otherwise scheduling may become impossible for the=20 secretariat
 

Bert Wijnen

-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens=20 David Harrington
Verzonden: dinsdag 13 mei 2008=20 16:29
Aan: 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Onderwerp: Re: [Netconf] NETCONF WG = Session at=20 IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 = and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, = and should=20 draw at least me, bert, juergen, daveN, wes, and randy, so that = should=20 probably be a prio 1.
 
David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: netconf-bounces@ietf.org = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = : [Netconf] NETCONF WG Session = at IETF=20 72

I=20 agree (and though Mehmet also agreed when we discussed this) that ISMS = should
be=20 priority 1 to avoid.
 
You=20 may be right about psamp and ifpifx.
 
dime=20 is prio 2. Are you suggesting it should be 1?
dnsop at prio 3 seems fine to me.
 
In=20 any event, I don';t think we can list all groups as an absolute CANNOT = conflict,
otherwise scheduling may become impossible for the=20 secretariat
 

Bert Wijnen

-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens=20 David Harrington
Verzonden: dinsdag 13 mei 2008=20 16:29
Aan: 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Onderwerp: Re: [Netconf] NETCONF WG = Session at=20 IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 = and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, = and should=20 draw at least me, bert, juergen, daveN, wes, and randy, so that = should=20 probably be a prio 1.
 
David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: netconf-bounces@ietf.org = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = MehmetMehmet (NSN -=20 DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] NETCONF WG Session = at IETF=20 72


Hi = All,

we requested a = 1-hour session=20 at the IETF #72 in Dublin.
Our main focus in the session will be on = open issue=20 discussion.

We entered = following WGs to=20 avoid conflicts with relevant
sessions:

Prio 1: = opsarea opsawg=20 netmod ipfix syslog opsec radext
Prio 2: ippm pmol psamp tsvarea apparea = dime dnsop=20 isms v6ops tsvwg
Prio 3: dime dnsop dnsext dhc bmwg

Please let us = know if you=20 have any comments or want to
add any other session to the = list.

Cheers,
Mehmet = &=20 Bert=20

------=_NextPart_000_06B3_01C8B550.AB304E60-- --===============1632195629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1632195629==-- (NSN -=20 DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] NETCONF WG Session = at IETF=20 72


Hi = All,

we requested a = 1-hour session=20 at the IETF #72 in Dublin.
Our main focus in the session will be on = open issue=20 discussion.

We entered = following WGs to=20 avoid conflicts with relevant
sessions:

Prio 1: = opsarea opsawg=20 netmod ipfix syslog opsec radext
Prio 2: ippm pmol psamp tsvarea apparea = dime dnsop=20 isms v6ops tsvwg
Prio 3: dime dnsop dnsext dhc bmwg

Please let us = know if you=20 have any comments or want to
add any other session to the = list.

Cheers,
Mehmet = &=20 Bert=20

------=_NextPart_000_06B3_01C8B550.AB304E60-- --===============1632195629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1632195629==-- From netconf-bounces@ietf.org Wed May 14 00:13:42 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8841C3A691D; Wed, 14 May 2008 00:13:42 -0700 (PDT) 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 F38963A691D for ; Wed, 14 May 2008 00:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 zSWNPRsdWQzm for ; Wed, 14 May 2008 00:13:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4A6253A6830 for ; Wed, 14 May 2008 00:13:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4E6nKfv009017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2008 08:49:20 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4E6nKdS008832; Wed, 14 May 2008 08:49:20 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 08:49:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 08:49:17 +0200 Message-ID: In-Reply-To: <06b201c8b572$3241ee60$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] NETCONF WG Session at IETF 72 thread-index: Aci1CWTEeEezfiBySe2GEk1/A4gdZAAaHHvQAAcQnxA= References: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> <06b201c8b572$3241ee60$0600a8c0@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext David B Harrington" X-OriginalArrivalTime: 14 May 2008 06:49:18.0177 (UTC) FILETIME=[A1A1AD10:01C8B58E] Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1255108093==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1255108093== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B58E.A12E8552" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B58E.A12E8552 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What can I say, you are right.=20 As Dan wanted dime is now p1, dnsop is p3. Cheers, Mehmet=20 ________________________________ From: ext David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Wednesday, May 14, 2008 5:26 AM To: 'Bert Wijnen - IETF'; 'David Harrington'; Ersue, MehmeFrom netconf-bounces@ietf.org Wed May 14 00:13:42 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8841C3A691D; Wed, 14 May 2008 00:13:42 -0700 (PDT) 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 F38963A691D for ; Wed, 14 May 2008 00:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 zSWNPRsdWQzm for ; Wed, 14 May 2008 00:13:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4A6253A6830 for ; Wed, 14 May 2008 00:13:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4E6nKfv009017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2008 08:49:20 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4E6nKdS008832; Wed, 14 May 2008 08:49:20 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 08:49:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 08:49:17 +0200 Message-ID: In-Reply-To: <06b201c8b572$3241ee60$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] NETCONF WG Session at IETF 72 thread-index: Aci1CWTEeEezfiBySe2GEk1/A4gdZAAaHHvQAAcQnxA= References: <061501c8b505$9fcb64b0$0600a8c0@china.huawei.com> <06b201c8b572$3241ee60$0600a8c0@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext David B Harrington" X-OriginalArrivalTime: 14 May 2008 06:49:18.0177 (UTC) FILETIME=[A1A1AD10:01C8B58E] Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF WG Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1255108093==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1255108093== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B58E.A12E8552" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B58E.A12E8552 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What can I say, you are right.=20 As Dan wanted dime is now p1, dnsop is p3. Cheers, Mehmet=20 ________________________________ From: ext David B Harrington [mailto:dbharrington@comcast.net]=20 Sent: Wednesday, May 14, 2008 5:26 AM To: 'Bert Wijnen - IETF'; 'David Harrington'; Ersue, Mehmet (NSNt (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] NETCONF WG Session at IETF 72 =09 =09 My point about dime and dnsop is that they are both listed twice, under different priorities: =20 Prio 2: ippm pmol psamp tsvarea apparea **dime dnsop** isms v6ops tsvwg=20 Prio 3: **dime dnsop** dnsext dhc bmwg=20 =20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com =09 =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen - IETF Sent: Tuesday, May 13, 2008 10:55 AM To: David Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Subject: Re: [Netconf] NETCONF WG Session at IETF 72 =09 =09 I agree (and though Mehmet also agreed when we discussed this) that ISMS should be priority 1 to avoid. =20 You may be right about psamp and ifpifx. =20 dime is prio 2. Are you suggesting it should be 1? dnsop at prio 3 seems fine to me.=20 =20 In any event, I don';t think we can list all groups as an absolute CANNOT conflict, otherwise scheduling may become impossible for the secretariat =20 Bert Wijnen=20 -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David Harrington Verzonden: dinsdag 13 mei 2008 16:29 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi Mehmet (and bert), =20 dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. =20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com =09 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi All,=20 we requested a 1-hour session at the IETF #72 in Dublin.=20 Our main focus in the session will be on open issue discussion.=20 We entered following WGs to avoid conflicts with relevant=20 sessions:=20 Prio 1: opsarea opsawg netmod ipfix syslog opsec radext=20 Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg=20 Prio 3: dime dnsop dnsext dhc bmwg=20 Please let us know if you have any comments or want to=20 add any other session to the list.=20 Cheers, Mehmet & Bert=20 ------_=_NextPart_001_01C8B58E.A12E8552 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72
What can I say, you are right. =
As Dan wanted dime is now p1, = dnsop is=20 p3.

Cheers,
Mehmet =


From: ext David B Harrington=20 [mailto:dbharrington@comcast.net] - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] NETCONF WG Session at IETF 72 =09 =09 My point about dime and dnsop is that they are both listed twice, under different priorities: =20 Prio 2: ippm pmol psamp tsvarea apparea **dime dnsop** isms v6ops tsvwg=20 Prio 3: **dime dnsop** dnsext dhc bmwg=20 =20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com =09 =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen - IETF Sent: Tuesday, May 13, 2008 10:55 AM To: David Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Subject: Re: [Netconf] NETCONF WG Session at IETF 72 =09 =09 I agree (and though Mehmet also agreed when we discussed this) that ISMS should be priority 1 to avoid. =20 You may be right about psamp and ifpifx. =20 dime is prio 2. Are you suggesting it should be 1? dnsop at prio 3 seems fine to me.=20 =20 In any event, I don';t think we can list all groups as an absolute CANNOT conflict, otherwise scheduling may become impossible for the secretariat =20 Bert Wijnen=20 -----Oorspronkelijk bericht----- Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens David Harrington Verzonden: dinsdag 13 mei 2008 16:29 Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org Onderwerp: Re: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi Mehmet (and bert), =20 dime and dnsop are listed as both prio 2 and 3. don't ipfix and psamp draw the same people? isms is resolving some final issues, and should draw at least me, bert, juergen, daveN, wes, and randy, so that should probably be a prio 1. =20 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com =09 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Tuesday, May 13, 2008 5:14 AM To: netconf@ietf.org Subject: [Netconf] NETCONF WG Session at IETF 72 =09 =09 Hi All,=20 we requested a 1-hour session at the IETF #72 in Dublin.=20 Our main focus in the session will be on open issue discussion.=20 We entered following WGs to avoid conflicts with relevant=20 sessions:=20 Prio 1: opsarea opsawg netmod ipfix syslog opsec radext=20 Prio 2: ippm pmol psamp tsvarea apparea dime dnsop isms v6ops tsvwg=20 Prio 3: dime dnsop dnsext dhc bmwg=20 Please let us know if you have any comments or want to=20 add any other session to the list.=20 Cheers, Mehmet & Bert=20 ------_=_NextPart_001_01C8B58E.A12E8552 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG Session at IETF 72
What can I say, you are right. =
As Dan wanted dime is now p1, = dnsop is=20 p3.

Cheers,
Mehmet =


From: ext David B Harrington=20 [mailto:dbharrington@comcast.net]
Sent: Wednesday, May 14, = 2008=20 5:26 AM
To: 'Bert Wijnen - IETF'; 'David Harrington'; Ersue, = Mehmet=20 (NSN - DE/Muenich); netconf@ietf.org
Subject: RE: [Netconf] = NETCONF=20 WG Session at IETF 72

My point about dime and dnsop is that they = are both=20 listed twice, under different priorities:
 
Prio 2: ippm pmol psamp tsvarea apparea **dime = dnsop**=20 isms v6ops tsvwg
Prio 3: **dime dnsop** dnsext dhc bmwg =
 

David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen -=20 IETF
Sent: Tuesday, May 13, 2008 10:55 AM
To: = David=20 Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Subject: Re: [Netconf] NETCONF WG Session = at IETF=20 72

I=20 agree (and though Mehmet also agreed when we discussed this) that = ISMS=20 should
be=20 priority 1 to avoid.
 
You may be right about psamp and = ifpifx.
 
dime is prio 2. Are you suggesting it should be=20 1?
dnsop at prio 3 seems fine to me.
 
In=20 any event, I don';t think we can list all groups as an absolute = CANNOT=20 conflict,
otherwise scheduling may become impossible for the=20 secretariat
 

Bert Wijnen

Sent: Wednesday, May 14, = 2008=20 5:26 AM
To: 'Bert Wijnen - IETF'; 'David Harrington'; Ersue, = Mehmet=20 (NSN - DE/Muenich); netconf@ietf.org
Subject: RE: [Netconf] = NETCONF=20 WG Session at IETF 72

My point about dime and dnsop is that they = are both=20 listed twice, under different priorities:
 
Prio 2: ippm pmol psamp tsvarea apparea **dime = dnsop**=20 isms v6ops tsvwg
Prio 3: **dime dnsop** dnsext dhc bmwg =
 

David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen -=20 IETF
Sent: Tuesday, May 13, 2008 10:55 AM
To: = David=20 Harrington; 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Subject: Re: [Netconf] NETCONF WG Session = at IETF=20 72

I=20 agree (and though Mehmet also agreed when we discussed this) that = ISMS=20 should
be=20 priority 1 to avoid.
 
You may be right about psamp and = ifpifx.
 
dime is prio 2. Are you suggesting it should be=20 1?
dnsop at prio 3 seems fine to me.
 
In=20 any event, I don';t think we can list all groups as an absolute = CANNOT=20 conflict,
otherwise scheduling may become impossible for the=20 secretariat
 

Bert Wijnen

-=3D2>-----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org = [mailto:netconf-bounces@ietf.org]Namens=20 David Harrington
Verzonden: dinsdag 13 mei 2008=20 16:29
Aan: 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Onderwerp: Re: [Netconf] NETCONF WG = Session at=20 IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 = and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, = and should=20 draw at least me, bert, juergen, daveN, wes, and randy, so that = should=20 probably be a prio 1.
 
David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: = netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = Mehmet (NSN=20 - DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14=20 AM
To: netconf@ietf.org
Subject: [Netconf] = NETCONF=20 WG Session at IETF 72


Hi = All,

we requested a = 1-hour session=20 at the IETF #72 in Dublin.
Our main focus in the session will be on = open issue=20 discussion.

We entered = following WGs=20 to avoid conflicts with relevant
sessions:

Prio 1: = opsarea opsawg=20 netmod ipfix syslog opsec radext
Prio 2: ippm pmol = psamp tsvarea=20 apparea dime dnsop isms v6ops tsvwg
Prio 3: dime dnsop = dnsext dhc bmwg=20

Please let = us know if you=20 have any comments or want to
add any other session to the = list.=20

Cheers,
Mehmet &=20 Bert=20

------_=_Ne----Oorspronkelijk bericht-----
Van:=20 netconf-bounces@ietf.org = [mailto:netconf-bounces@ietf.org]Namens=20 David Harrington
Verzonden: dinsdag 13 mei 2008=20 16:29
Aan: 'Ersue, Mehmet (NSN - DE/Muenich)';=20 netconf@ietf.org
Onderwerp: Re: [Netconf] NETCONF WG = Session at=20 IETF 72

Hi Mehmet (and bert),
 
dime and dnsop are listed as both prio 2 = and=20 3.
don't ipfix and psamp draw the same=20 people?
isms is resolving some final issues, = and should=20 draw at least me, bert, juergen, daveN, wes, and randy, so that = should=20 probably be a prio 1.
 
David=20 = Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: = netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, = Mehmet (NSN=20 - DE/Muenich)
Sent: Tuesday, May 13, 2008 5:14=20 AM
To: netconf@ietf.org
Subject: [Netconf] = NETCONF=20 WG Session at IETF 72


Hi = All,

we requested a = 1-hour session=20 at the IETF #72 in Dublin.
Our main focus in the session will be on = open issue=20 discussion.

We entered = following WGs=20 to avoid conflicts with relevant
sessions:

Prio 1: = opsarea opsawg=20 netmod ipfix syslog opsec radext
Prio 2: ippm pmol = psamp tsvarea=20 apparea dime dnsop isms v6ops tsvwg
Prio 3: dime dnsop = dnsext dhc bmwg=20

Please let = us know if you=20 have any comments or want to
add any other session to the = list.=20

Cheers,
Mehmet &=20 Bert=20

------_=_NextPartxtPart_001_01C8B58E.A12E8552-- --===============1255108093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1255108093==-- _001_01C8B58E.A12E8552-- --===============1255108093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1255108093==-- From netconf-bounces@ietf.org Wed May 14 08:29:05 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B0B3A695B; Wed, 14 May 2008 08:29:05 -0700 (PDT) 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 CF4A13A6949 for ; Wed, 14 May 2008 08:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 gh8anSfLdE-t for ; Wed, 14 May 2008 08:28:50 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4B1F33A692A for ; Wed, 14 May 2008 08:28:50 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4EFR3gF016371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2008 17:27:03 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4EFR1cm006989; Wed, 14 May 2008 17:27:01 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 17:27:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 17:27:00 +0200 Message-ID: In-Reply-To: <4823935B.3050802@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Issue X: access to notification content thread-index: AcixZ1G/YsE74OiCSxq9WS69Wnut5QEbw/zg References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com><03af01c8b104$03fc48b0$0600a8c0@china.huawei.com><48232185.9020109@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com><482334BA.2060303@andybierman.com><03ff01c8b139$0ce6be80$0600a8c0@china.huawei.com> <4823935B.3050802@andybierman.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Andy Bierman" , "David B Harrington" X-OriginalArrivalTime: 14 May 2008 15:27:01.0380 (UTC) FILETIME=[F4BE4C40:01C8B5D6] Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I think (D) is better than (E). IMO it is better to have the additional sentence to avoid another discuss asking "who is not authorized?". Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Friday, May 09, 2008 1:57 AM > To: David B Harrington > Cc: netconf@ietf.org > Subject: Re: [Netconf] Issue X: access to notification content > > David B Harrington wrote: > > > >> oops -- I was confused. I thought the paragraph dealt with > >> other NETCONF operations, but I see that is Dave's text, not > >> (A) or (B). > > > > Read the "current text" again, Andy. The current text specifies: > > "If a user does not have permission to view content via > other NETCONF > > operations, she must not have access to that content via > > Notifications." > > This text is not acceptable. > What content? What operations? > What if the data the user is allowed to see via notifications > is not available via other operations? Does this sentence mean that > scenario is forbidden in NETCONF? > > > (E) is good. > > We have seen recently that people will parse a normative sentence > to make it say what they want it to say. We should not add any > problematic sentences to the Notifications RFC that will be impede > any future access control work. > > (I bet dollars to donuts that the terms used carelessly in > this paragraph in question will be parsed against the terminology > in future access control documents, and cause problems. ;-) > > > Andy > > > > > > > I object to this for multiple independent reasons: > > 1) "must" is an RFC2119 reserved word. Using it here makes this a > > REQUIREMENT. > > 2) Access control mechanisms are out of scope at this time. So we > > should not state any REQUIREMENTS about how access control "must" > > work. > > 3) the current text makes notification access control > dependent on the > > access controls used for other operations. Andy, I think > this is a bad > > idea, for reasons similar to those you mention. > > 4) authorization to view information should be an adminstrative > > decision, not a protocol decision. > > 5) Netcofn notifications were designed to carry syslog and SNMP > > notifications streams. We should not impose the access control > > requirement that is specified in the "current text" for > syslog and/or > > SNMP content. > > > >> I actually don't like any of the choices. > > > > I don't like any of the choices either. The Proposed text (C) was a > > concession to Sharon's unwillingness to remove the > dependence on other > > operations. In the REQUIREMENT in Sharon's (A), is access > via SNMP-GET > > or syslog logging acceptable as the "permission to view the > > information" - I think that a dependency on access control > mechanisms > > in other protocols would be even worse than "permission to view > > content via other NETCONF operations". > > > > here is another proposed text to replace the original text: > > > > Proposed Text (D) > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users. It is an > administrative > > policy decision to determine who (or what) is authorized to have > > access to the information contained in notifications. If a > user is not > > authorized to view all elements in the content of the notification, > > the notification is not sent to that user." > > > > I could also live with the nice simple > > > > Proposed Text (E) > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users. If a user is not > > authorized to view all elements in the content of the notification, > > the notification is not sent to that user." > > > > I could also live with the even simpler: > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users." > > > > And then leave it up future access control mechanisms to determine > > authorization. > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed May 14 08:29:05 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B0B3A695B; Wed, 14 May 2008 08:29:05 -0700 (PDT) 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 CF4A13A6949 for ; Wed, 14 May 2008 08:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 gh8anSfLdE-t for ; Wed, 14 May 2008 08:28:50 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4B1F33A692A for ; Wed, 14 May 2008 08:28:50 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4EFR3gF016371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2008 17:27:03 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4EFR1cm006989; Wed, 14 May 2008 17:27:01 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 17:27:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 17:27:00 +0200 Message-ID: In-Reply-To: <4823935B.3050802@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Issue X: access to notification content thread-index: AcixZ1G/YsE74OiCSxq9WS69Wnut5QEbw/zg References: <713043CE8B8E1348AF3C546DBE02C1B4146E0025@zcarhxm2.corp.nortel.com><03af01c8b104$03fc48b0$0600a8c0@china.huawei.com><48232185.9020109@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41472D5CC@zcarhxm2.corp.nortel.com><482334BA.2060303@andybierman.com><03ff01c8b139$0ce6be80$0600a8c0@china.huawei.com> <4823935B.3050802@andybierman.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Andy Bierman" , "David B Harrington" X-OriginalArrivalTime: 14 May 2008 15:27:01.0380 (UTC) FILETIME=[F4BE4C40:01C8B5D6] Cc: netconf@ietf.org Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I think (D) is better than (E). IMO it is better to have the additional sentence to avoid another discuss asking "who is not authorized?". Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Friday, May 09, 2008 1:57 AM > To: David B Harrington > Cc: netconf@ietf.org > Subject: Re: [Netconf] Issue X: access to notification content > > David B Harrington wrote: > > > >> oops -- I was confused. I thought the paragraph dealt with > >> other NETCONF operations, but I see that is Dave's text, not > >> (A) or (B). > > > > Read the "current text" again, Andy. The current text specifies: > > "If a user does not have permission to view content via > other NETCONF > > operations, she must not have access to that content via > > Notifications." > > This text is not acceptable. > What content? What operations? > What if the data the user is allowed to see via notifications > is not available via other operations? Does this sentence mean that > scenario is forbidden in NETCONF? > > > (E) is good. > > We have seen recently that people will parse a normative sentence > to make it say what they want it to say. We should not add any > problematic sentences to the Notifications RFC that will be impede > any future access control work. > > (I bet dollars to donuts that the terms used carelessly in > this paragraph in question will be parsed against the terminology > in future access control documents, and cause problems. ;-) > > > Andy > > > > > > > I object to this for multiple independent reasons: > > 1) "must" is an RFC2119 reserved word. Using it here makes this a > > REQUIREMENT. > > 2) Access control mechanisms are out of scope at this time. So we > > should not state any REQUIREMENTS about how access control "must" > > work. > > 3) the current text makes notification access control > dependent on the > > access controls used for other operations. Andy, I think > this is a bad > > idea, for reasons similar to those you mention. > > 4) authorization to view information should be an adminstrative > > decision, not a protocol decision. > > 5) Netcofn notifications were designed to carry syslog and SNMP > > notifications streams. We should not impose the access control > > requirement that is specified in the "current text" for > syslog and/or > > SNMP content. > > > >> I actually don't like any of the choices. > > > > I don't like any of the choices either. The Proposed text (C) was a > > concession to Sharon's unwillingness to remove the > dependence on other > > operations. In the REQUIREMENT in Sharon's (A), is access > via SNMP-GET > > or syslog logging acceptable as the "permission to view the > > information" - I think that a dependency on access control > mechanisms > > in other protocols would be even worse than "permission to view > > content via other NETCONF operations". > > > > here is another proposed text to replace the original text: > > > > Proposed Text (D) > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users. It is an > administrative > > policy decision to determine who (or what) is authorized to have > > access to the information contained in notifications. If a > user is not > > authorized to view all elements in the content of the notification, > > the notification is not sent to that user." > > > > I could also live with the nice simple > > > > Proposed Text (E) > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users. If a user is not > > authorized to view all elements in the content of the notification, > > the notification is not sent to that user." > > > > I could also live with the even simpler: > > > > "The contents of notifications as well as the names of event streams > > may contain sensitive information and care should be taken to ensure > > that they are viewed only by authorized users." > > > > And then leave it up future access control mechanisms to determine > > authorization. > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From asseuvel1979@aB.apple.com Thu May 15 00:32:37 2008 Return-Path: X-Original-To: ietfarch-netconf-archive@core3.amsl.com Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DA2A3A6A44 for ; Thu, 15 May 2008 00:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.896 X-Spam-Level: X-Spam-Status: No, score=-21.896 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] 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 nj6iw9zulYQU for ; Thu, 15 May 2008 00:32:36 -0700 (PDT) Received: from [213.42.23.71] (ner-b11404.alshamil.net.ae [83.110.105.134]) by core3.amsl.com (Postfix) with ESMTP id 3B1EB3A6A3C for ; Thu, 15 May 2008 00:32:31 -0700 (PDT) User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 15 May 2008 11:31:51 +0400 Subject: Waste no further time From: Kimmel To: "netconf-archive@lists.ietf.org" Message-ID: Thread-Topic: Waste no further time Thread-Index: Aci2f0VIBQFQsiQjQ9mBVQrJf6W0jA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_1322549478_96642" --B_1322549478_96642 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The length of your manhood determines how much confidence you carry yourself http://www.buryaueg.com/ --B_1322549478_96642 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Waste no further time The length of your manhood determines how much = confidence you carry yourself http://www.buryaueg.com/
 --B_1322549478_96642-- From netconf-bounces@ietf.org Thu May 22 16:38:30 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3314C3A6B4E; Thu, 22 May 2008 16:38:30 -0700 (PDT) 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 64F453A6B6E for ; Thu, 22 May 2008 16:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, 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 uXT8nE0IyLaa for ; Thu, 22 May 2008 16:38:27 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id A69CD3A6B48 for ; Thu, 22 May 2008 16:38:27 -0700 (PDT) Received: (qmail 46354 invoked from network); 22 May 2008 23:38:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 22 May 2008 23:38:25 -0000 X-YMail-OSG: QZ5hdbwVM1kCpxwqLGyA_htA4.MFlSF.Cb7ew_N4ATRBTh.oHfYtdplVldnfSrAbR4nTXyYYrSjA3tDmJ0lFQXrsUS.cPIcJW5vzqbIQ_qDRot5GVhKY9fvhP5hrx3Xeapj_pOnDBp0EaoPM7c65FY0C X-Yahoo-Newman-Property: ymail-3 Message-ID: <483603F0.5090201@andybierman.com> Date: Thu, 22 May 2008 16:38:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group , NETCONF Subject: [Netconf] Online YANG module checker X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I am starting a new WEB site called Netconf Central, which has some free YANG tools. The 'yangto' program has been renamed 'yangdump' and is freely available in binary form: http://www.netconfcentral.com/download YANG modules can also be validated online: http://www.netconfcentral.com/run_yangdump (The WEB pages are still kind of rough, and most of the tools are not done yet, but maybe 'yangdump' can help people learn/use YANG a little better.) Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 22 16:38:30 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3314C3A6B4E; Thu, 22 May 2008 16:38:30 -0700 (PDT) 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 64F453A6B6E for ; Thu, 22 May 2008 16:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[AWL=-1.290, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, 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 uXT8nE0IyLaa for ; Thu, 22 May 2008 16:38:27 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id A69CD3A6B48 for ; Thu, 22 May 2008 16:38:27 -0700 (PDT) Received: (qmail 46354 invoked from network); 22 May 2008 23:38:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.166.23 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 22 May 2008 23:38:25 -0000 X-YMail-OSG: QZ5hdbwVM1kCpxwqLGyA_htA4.MFlSF.Cb7ew_N4ATRBTh.oHfYtdplVldnfSrAbR4nTXyYYrSjA3tDmJ0lFQXrsUS.cPIcJW5vzqbIQ_qDRot5GVhKY9fvhP5hrx3Xeapj_pOnDBp0EaoPM7c65FY0C X-Yahoo-Newman-Property: ymail-3 Message-ID: <483603F0.5090201@andybierman.com> Date: Thu, 22 May 2008 16:38:24 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: NETMOD Working Group , NETCONF Subject: [Netconf] Online YANG module checker X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I am starting a new WEB site called Netconf Central, which has some free YANG tools. The 'yangto' program has been renamed 'yangdump' and is freely available in binary form: http://www.netconfcentral.com/download YANG modules can also be validated online: http://www.netconfcentral.com/run_yangdump (The WEB pages are still kind of rough, and most of the tools are not done yet, but maybe 'yangdump' can help people learn/use YANG a little better.) Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun May 25 11:58:33 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6953A67A2; Sun, 25 May 2008 11:58:33 -0700 (PDT) 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 B0AFC3A69EE for ; Sun, 25 May 2008 11:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gUBs0NlAT0GW for ; Sun, 25 May 2008 11:54:43 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 3ED6B3A6BCD for ; Sun, 25 May 2008 11:54:20 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4PIsAGj009890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 May 2008 20:54:10 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4PIs9KR023991; Sun, 25 May 2008 20:54:09 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 May 2008 20:54:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 25 May 2008 20:54:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of the WG Items and Issue Discussion thread-index: Aci+mLaMwHWy9eEIRRyJ6qE5bwAjUw== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 25 May 2008 18:54:09.0862 (UTC) FILETIME=[B73D6660:01C8BE98] Subject: [Netconf] Update of the WG Items and Issue Discussion X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0347483499==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0347483499== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8BE98.B6FA814C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BE98.B6FA814C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG members,=20 as you know, we have requested a session slot for IETF 72.=20 But in order for such a session to be usefull, we MUST prepare.=20 Currently we have 4 chartered WG items. The notification=20 draft will be updated soon based on the changes for the=20 IESG discusses. The other 3 WG documents need a regular=20 update and issue discussion on the WG list.=20 We would like to encourage the I-D authors NOT TO WAIT=20 until the final I-D submission deadline on July 24. Please=20 submit your draft update in the next 1-2 weeks so that=20 we have sufficient time for review and issFrom netconf-bounces@ietf.org Sun May 25 11:58:33 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6953A67A2; Sun, 25 May 2008 11:58:33 -0700 (PDT) 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 B0AFC3A69EE for ; Sun, 25 May 2008 11:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gUBs0NlAT0GW for ; Sun, 25 May 2008 11:54:43 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 3ED6B3A6BCD for ; Sun, 25 May 2008 11:54:20 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4PIsAGj009890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 May 2008 20:54:10 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4PIs9KR023991; Sun, 25 May 2008 20:54:09 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 May 2008 20:54:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 25 May 2008 20:54:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of the WG Items and Issue Discussion thread-index: Aci+mLaMwHWy9eEIRRyJ6qE5bwAjUw== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 25 May 2008 18:54:09.0862 (UTC) FILETIME=[B73D6660:01C8BE98] Subject: [Netconf] Update of the WG Items and Issue Discussion X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0347483499==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0347483499== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8BE98.B6FA814C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BE98.B6FA814C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG members,=20 as you know, we have requested a session slot for IETF 72.=20 But in order for such a session to be usefull, we MUST prepare.=20 Currently we have 4 chartered WG items. The notification=20 draft will be updated soon based on the changes for the=20 IESG discusses. The other 3 WG documents need a regular=20 update and issue discussion on the WG list.=20 We would like to encourage the I-D authors NOT TO WAIT=20 until the final I-D submission deadline on July 24. Please=20 submit your draft update in the next 1-2 weeks so that=20 we have sufficient time for review aue discussion=20 on the maillist.=20 We would also like to urge everybody on the NETCONF=20 maillist to READ AND REVIEW the document updates and=20 send their review comments and requests to the maillist.=20 The issue discussion is definitely needed before the WG=20 session and is the only way to get the issues solved and=20 the documents stable.=20 If you see any open gaps, any problems, or things that=20 you think could be done better, then PLEASE POST those=20 to the maillist rather sooner than later. It will help some=20 discussion on the mailing list. Hopefully we can solve the=20 issues and address the concerns on the list and come to=20 convergence.=20 Those issues that we seem to not be able to find a=20 solution for, or for which we do not come to convergence,=20 ONLY THOSE deserve serious face to face time at the=20 upcoming IETF meeting.=20 We want to have only serious discussion of open and/or=20 controversial issues in the NETCONF session in Dublin.=20 But we all need to prepare for that. Let us prepare for=20 the NETCONF session at the IETF #72 in time and have=20 a successful session with solid results.=20 Thank you all for your support and enthusiasm.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C8BE98.B6FA814C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Update of the WG Items and Issue Discussion

Dear WG members,

as you know, we have requested a = session slot for IETF 72.
But in order for such a session to = be usefull, we MUST prepare.

Currently we have 4 chartered WG = items. The notification
draft will be updated soon based on = the changes for the
IESG discusses. The other 3 WG = documents need a regular
update and issue discussion on the = WG list.

We would like to encourage the I-D = authors NOT TO WAIT
until the final I-D submission = deadline on July 24. Please
submit your draft update in the next = 1-2 weeks so that
we have sufficient time for review = and issue discussion
on the maillist.

We would also like to urge everybody = on the NETCONF
maillist to READ AND REVIEW the = document updates and
send their review comments and = requests to the maillist.
The issue discussion is definitely = needed before the WG
session and is the only way to get = the issues solved and
the documents stable.
If you see any open gaps, any = problems, or things that
you think could be done better, then = PLEASE POST those
to the maillist rather sooner than = later. It will help some
discussion on the mailing list. = Hopefully we can solve the
issues and address the concerns on = the list and come to
convergence.

Those issues that we seem to not be = able to fnd issue discussion=20 on the maillist.=20 We would also like to urge everybody on the NETCONF=20 maillist to READ AND REVIEW the document updates and=20 send their review comments and requests to the maillist.=20 The issue discussion is definitely needed before the WG=20 session and is the only way to get the issues solved and=20 the documents stable.=20 If you see any open gaps, any problems, or things that=20 you think could be done better, then PLEASE POST those=20 to the maillist rather sooner than later. It will help some=20 discussion on the mailing list. Hopefully we can solve the=20 issues and address the concerns on the list and come to=20 convergence.=20 Those issues that we seem to not be able to find a=20 solution for, or for which we do not come to convergence,=20 ONLY THOSE deserve serious face to face time at the=20 upcoming IETF meeting.=20 We want to have only serious discussion of open and/or=20 controversial issues in the NETCONF session in Dublin.=20 But we all need to prepare for that. Let us prepare for=20 the NETCONF session at the IETF #72 in time and have=20 a successful session with solid results.=20 Thank you all for your support and enthusiasm.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C8BE98.B6FA814C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Update of the WG Items and Issue Discussion

Dear WG members,

as you know, we have requested a = session slot for IETF 72.
But in order for such a session to = be usefull, we MUST prepare.

Currently we have 4 chartered WG = items. The notification
draft will be updated soon based on = the changes for the
IESG discusses. The other 3 WG = documents need a regular
update and issue discussion on the = WG list.

We would like to encourage the I-D = authors NOT TO WAIT
until the final I-D submission = deadline on July 24. Please
submit your draft update in the next = 1-2 weeks so that
we have sufficient time for review = and issue discussion
on the maillist.

We would also like to urge everybody = on the NETCONF
maillist to READ AND REVIEW the = document updates and
send their review comments and = requests to the maillist.
The issue discussion is definitely = needed before the WG
session and is the only way to get = the issues solved and
the documents stable.
If you see any open gaps, any = problems, or things that
you think could be done better, then = PLEASE POST those
to the maillist rather sooner than = later. It will help some
discussion on the mailing list. = Hopefully we can solve the
issues and address the concerns on = the list and come to
convergence.

Those issues that we seem to not be = able to find a
solution for, or for which we do not = come to convergence,
ONLY THOSE deserve serious face to = face time at the
upcoming IETF meeting.
We want to have only serious = discussion of open and/or
controversial issues in the NETCONF = session in Dublin.

But we all need to prepare for that. = Let us prepare for
the NETCONF session at the IETF #72 = in time and have
a successful session with solid = results.

Thank you all for your support and = enthusiasm.

Bert & Mehmet

------_=_NextPart_001_01C8BE98.B6FA814C-- --===============0347483499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0347483499==-- ind a
solution for, or for which we do not = come to convergence,
ONLY THOSE deserve serious face to = face time at the
upcoming IETF meeting.
We want to have only serious = discussion of open and/or
controversial issues in the NETCONF = session in Dublin.

But we all need to prepare for that. = Let us prepare for
the NETCONF session at the IETF #72 = in time and have
a successful session with solid = results.

Thank you all for your support and = enthusiasm.

Bert & Mehmet

------_=_NextPart_001_01C8BE98.B6FA814C-- --===============0347483499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0347483499==-- From netconf-bounces@ietf.org Sun May 25 20:47:43 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7D23A68BD; Sun, 25 May 2008 20:47:43 -0700 (PDT) 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 602583A68BD for ; Sun, 25 May 2008 20:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, 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 nU8Qk7mztCVb for ; Sun, 25 May 2008 20:47:41 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 263C13A685A for ; Sun, 25 May 2008 20:47:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,540,1204520400"; d="scan'208,217";a="120569894" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 25 May 2008 23:47:41 -0400 X-IronPort-AV: E=Sophos;i="4.27,540,1204520400"; d="scan'208,217";a="200756438" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 25 May 2008 23:47:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 05:47:39 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of the WG Items and Issue Discussion Thread-Index: Aci+mLaMwHWy9eEIRRyJ6qE5bwAjUwASh7lw References: From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Muenich)" , Subject: Re: [Netconf] Update of the WG Items and Issue Discussion X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0667433657==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0667433657== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8BEE3.3F0BE9F6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BEE3.3F0BE9F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please pay attention, the final submission date for Dublin is JULY 14 and not July 24! =20 Of course, as Mehmet indicates, in order to prepare well the WG session in Dublin submitting early is very much recommended in order to ensure that the session is successful.=20 =20 Dan =20 ________________________________ From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com]=20 Sent: Sunday, May 25, 2008 9:54 PM To: netconf@ietf.org Cc: ext Bert Wijnen - IETF; Romascanu, Dan (Dan) Subject: Update of the WG Items and Issue Discussion =09 =09 Dear WG members,=20 as you know, we hFrom netconf-bounces@ietf.org Sun May 25 20:47:43 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7D23A68BD; Sun, 25 May 2008 20:47:43 -0700 (PDT) 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 602583A68BD for ; Sun, 25 May 2008 20:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, 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 nU8Qk7mztCVb for ; Sun, 25 May 2008 20:47:41 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 263C13A685A for ; Sun, 25 May 2008 20:47:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,540,1204520400"; d="scan'208,217";a="120569894" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 25 May 2008 23:47:41 -0400 X-IronPort-AV: E=Sophos;i="4.27,540,1204520400"; d="scan'208,217";a="200756438" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 25 May 2008 23:47:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 05:47:39 +0200 Message-ID: In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of the WG Items and Issue Discussion Thread-Index: Aci+mLaMwHWy9eEIRRyJ6qE5bwAjUwASh7lw References: From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Muenich)" , Subject: Re: [Netconf] Update of the WG Items and Issue Discussion X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0667433657==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0667433657== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8BEE3.3F0BE9F6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BEE3.3F0BE9F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please pay attention, the final submission date for Dublin is JULY 14 and not July 24! =20 Of course, as Mehmet indicates, in order to prepare well the WG session in Dublin submitting early is very much recommended in order to ensure that the session is successful.=20 =20 Dan =20 ________________________________ From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com]=20 Sent: Sunday, May 25, 2008 9:54 PM To: netconf@ietf.org Cc: ext Bert Wijnen - IETF; Romascanu, Dan (Dan) Subject: Update of the WG Items and Issue Discussion =09 =09 Dear WG members,=20 as you know, we have reave requested a session slot for IETF 72.=20 But in order for such a session to be usefull, we MUST prepare.=20 Currently we have 4 chartered WG items. The notification=20 draft will be updated soon based on the changes for the=20 IESG discusses. The other 3 WG documents need a regular=20 update and issue discussion on the WG list.=20 We would like to encourage the I-D authors NOT TO WAIT=20 until the final I-D submission deadline on July 24. Please=20 submit your draft update in the next 1-2 weeks so that=20 we have sufficient time for review and issue discussion=20 on the maillist.=20 We would also like to urge everybody on the NETCONF=20 maillist to READ AND REVIEW the document updates and=20 send their review comments and requests to the maillist.=20 The issue discussion is definitely needed before the WG=20 session and is the only way to get the issues solved and=20 the documents stable.=20 If you see any open gaps, any problems, or things that=20 you think could be done better, then PLEASE POST those=20 to the maillist rather sooner than later. It will help some=20 discussion on the mailing list. Hopefully we can solve the=20 issues and address the concerns on the list and come to=20 convergence.=20 Those issues that we seem to not be able to find a=20 solution for, or for which we do not come to convergence,=20 ONLY THOSE deserve serious face to face time at the=20 upcoming IETF meeting.=20 We want to have only serious discussion of open and/or=20 controversial issues in the NETCONF session in Dublin.=20 But we all need to prepare for that. Let us prepare for=20 the NETCONF session at the IETF #72 in time and have=20 a successful session with solid results.=20 Thank you all for your support and enthusiasm.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C8BEE3.3F0BE9F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Update of the WG Items and Issue Discussion
Please pay attention, the final submission date for = Dublin is=20 JULY 14 and not July 24!
 
Of course, as Mehmet indicates, in order to prepare well the WG = session=20 in Dublin submitting early is very much recommended in order to ensure = that the=20 session is successful.
 
Dan
 

From: Ersue, Mehmet (NSN - = DE/Muenich)=20 [mailto:mehmet.ersue@nsn.com]
Sent: Sunday, May 25, 2008 = 9:54=20 PM
To: netconf@ietf.org
Cc: ext Bert Wijnen - = IETF;=20 Romascanu, Dan (Dan)
Subject: Update of the WG Items and = Issue=20 Discussion


Dear WG members,

as you know, we have requested a = session slquested a session slot for IETF 72.=20 But in order for such a session to be usefull, we MUST prepare.=20 Currently we have 4 chartered WG items. The notification=20 draft will be updated soon based on the changes for the=20 IESG discusses. The other 3 WG documents need a regular=20 update and issue discussion on the WG list.=20 We would like to encourage the I-D authors NOT TO WAIT=20 until the final I-D submission deadline on July 24. Please=20 submit your draft update in the next 1-2 weeks so that=20 we have sufficient time for review and issue discussion=20 on the maillist.=20 We would also like to urge everybody on the NETCONF=20 maillist to READ AND REVIEW the document updates and=20 send their review comments and requests to the maillist.=20 The issue discussion is definitely needed before the WG=20 session and is the only way to get the issues solved and=20 the documents stable.=20 If you see any open gaps, any problems, or things that=20 you think could be done better, then PLEASE POST those=20 to the maillist rather sooner than later. It will help some=20 discussion on the mailing list. Hopefully we can solve the=20 issues and address the concerns on the list and come to=20 convergence.=20 Those issues that we seem to not be able to find a=20 solution for, or for which we do not come to convergence,=20 ONLY THOSE deserve serious face to face time at the=20 upcoming IETF meeting.=20 We want to have only serious discussion of open and/or=20 controversial issues in the NETCONF session in Dublin.=20 But we all need to prepare for that. Let us prepare for=20 the NETCONF session at the IETF #72 in time and have=20 a successful session with solid results.=20 Thank you all for your support and enthusiasm.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C8BEE3.3F0BE9F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Update of the WG Items and Issue Discussion

Please pay attention, the final submission date for = Dublin is=20 JULY 14 and not July 24!
 
Of course, as Mehmet indicates, in order to prepare well the WG = session=20 in Dublin submitting early is very much recommended in order to ensure = that the=20 session is successful.
 
Dan
 

From: Ersue, Mehmet (NSN - = DE/Muenich)=20 [mailto:mehmet.ersue@nsn.com]
Sent: Sunday, May 25, 2008 = 9:54=20 PM
To: netconf@ietf.org
Cc: ext Bert Wijnen - = IETF;=20 Romascanu, Dan (Dan)
Subject: Update of the WG Items and = Issue=20 Discussion


Dear WG members,

as you know, we have requested a = session slot forot for=20 IETF 72.
But in order for = such a session=20 to be usefull, we MUST prepare.

Currently we have 4 chartered WG = items. The=20 notification
draft will be = updated soon=20 based on the changes for the
IESG=20 discusses. The other 3 WG documents need a regular
update and issue discussion on the WG list. =

We would like to encourage the I-D = authors NOT TO=20 WAIT
until the final I-D = submission=20 deadline on July 24. Please
submit your=20 draft update in the next 1-2 weeks so that
we have sufficient time for review and issue discussion=20
on the maillist.

We would also like to urge everybody = on the=20 NETCONF
maillist to READ AND = REVIEW the=20 document updates and
send = their review=20 comments and requests to the maillist.
The issue discussion is definitely needed before the WG=20
session and is the only way = to get the=20 issues solved and
the = documents stable.=20
If you see any open gaps, any = problems,=20 or things that
you think = could be done=20 better, then PLEASE POST those
to the=20 maillist rather sooner than later. It will help some
discussion on the mailing list. Hopefully we = can solve the=20
issues and address the = concerns on the=20 list and come to
convergence. =

Those issues that we seem to not be = able to find=20 a
solution for, or for which = we do not=20 come to convergence,
ONLY = THOSE deserve=20 serious face to face time at the
upcoming=20 IETF meeting.
We want to have = only=20 serious discussion of open and/or
controversial issues in the NETCONF session in Dublin. =

But we all need to prepare for that. = Let us=20 prepare for
the NETCONF = session at the=20 IETF #72 in time and have
a = successful=20 session with solid results.

Thank you all for your support and = enthusiasm.=20

Bert & Mehmet=20

------_=_NextPart_001_01C8BEE3.3F0BE9F6-- --===============0667433657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0667433657==-- =20 IETF 72.
But in order for = such a session=20 to be usefull, we MUST prepare.

Currently we have 4 chartered WG = items. The=20 notification
draft will be = updated soon=20 based on the changes for the
IESG=20 discusses. The other 3 WG documents need a regular
update and issue discussion on the WG list. =

We would like to encourage the I-D = authors NOT TO=20 WAIT
until the final I-D = submission=20 deadline on July 24. Please
submit your=20 draft update in the next 1-2 weeks so that
we have sufficient time for review and issue discussion=20
on the maillist.

We would also like to urge everybody = on the=20 NETCONF
maillist to READ AND = REVIEW the=20 document updates and
send = their review=20 comments and requests to the maillist.
The issue discussion is definitely needed before the WG=20
session and is the only way = to get the=20 issues solved and
the = documents stable.=20
If you see any open gaps, any = problems,=20 or things that
you think = could be done=20 better, then PLEASE POST those
to the=20 maillist rather sooner than later. It will help some
discussion on the mailing list. Hopefully we = can solve the=20
issues and address the = concerns on the=20 list and come to
convergence. =

Those issues that we seem to not be = able to find=20 a
solution for, or for which = we do not=20 come to convergence,
ONLY = THOSE deserve=20 serious face to face time at the
upcoming=20 IETF meeting.
We want to have = only=20 serious discussion of open and/or
controversial issues in the NETCONF session in Dublin. =

But we all need to prepare for that. = Let us=20 prepare for
the NETCONF = session at the=20 IETF #72 in time and have
a = successful=20 session with solid results.

Thank you all for your support and = enthusiasm.=20

Bert & Mehmet=20

------_=_NextPart_001_01C8BEE3.3F0BE9F6-- --===============0667433657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0667433657==-- From netconf-bounces@ietf.org Mon May 26 02:00:04 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9355E28C137; Mon, 26 May 2008 02:00:04 -0700 (PDT) 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 00F9D3A6B02 for ; Mon, 26 May 2008 02:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, 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 U38uNyYpE4tZ for ; Mon, 26 May 2008 02:00:01 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 059363A683E for ; Mon, 26 May 2008 01:59:58 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4Q8xucD024446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 May 2008 10:59:56 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4Q8xhfX026126; Mon, 26 May 2008 10:59:56 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 10:59:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 10:59:51 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of the WG Items and Issue Discussion thread-index: Aci+mLaMwHWy9eEIRRyJ6qE5bwAjUwASh7lwAArnTsA= References: From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 26 May 2008 08:59:53.0760 (UTC) FILETIME=[DCF5C200:01C8BF0E] Subject: Re: [Netconf] Update of the WG Items and Issue Discussion X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0491640918==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0491640918== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8BF0E.DC91090A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BF0E.DC91090A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops, this is true. Below are some of the important meeting dates: July 2, Wednesday - Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PDT (24:00 UTC/GMT) July 7, Monday - Final agenda to be published.=20 July 7, Monday - Internet Draft Cut-off for initial document (-00) submFrom netconf-bounces@ietf.org Mon May 26 02:00:04 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9355E28C137; Mon, 26 May 2008 02:00:04 -0700 (PDT) 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 00F9D3A6B02 for ; Mon, 26 May 2008 02:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, 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 U38uNyYpE4tZ for ; Mon, 26 May 2008 02:00:01 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 059363A683E for ; Mon, 26 May 2008 01:59:58 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m4Q8xucD024446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 May 2008 10:59:56 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4Q8xhfX026126; Mon, 26 May 2008 10:59:56 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 10:59:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 10:59:51 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update of the WG Items and Issue Discussion thread-index: Aci+mLaMwHWy9eEIRRyJ6qE5bwAjUwASh7lwAArnTsA= References: From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 26 May 2008 08:59:53.0760 (UTC) FILETIME=[DCF5C200:01C8BF0E] Subject: Re: [Netconf] Update of the WG Items and Issue Discussion X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0491640918==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0491640918== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8BF0E.DC91090A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BF0E.DC91090A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops, this is true. Below are some of the important meeting dates: July 2, Wednesday - Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PDT (24:00 UTC/GMT) July 7, Monday - Final agenda to be published.=20 July 7, Monday - Internet Draft Cut-off for initial document (-00) submissionission by 17:00 PDT (24:00 UTC/GMT) July 14, Monday - Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT) July 21, Monday - Revised Working Group agendas due by 17:00 PDT (24:00 UTC/GMT) Cheers, Mehmet=20 =20 ________________________________ From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Monday, May 26, 2008 5:48 AM To: Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Cc: ext Bert Wijnen - IETF Subject: RE: Update of the WG Items and Issue Discussion =09 =09 Please pay attention, the final submission date for Dublin is JULY 14 and not July 24! =20 Of course, as Mehmet indicates, in order to prepare well the WG session in Dublin submitting early is very much recommended in order to ensure that the session is successful.=20 =20 Dan =20 ________________________________ From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com]=20 Sent: Sunday, May 25, 2008 9:54 PM To: netconf@ietf.org Cc: ext Bert Wijnen - IETF; Romascanu, Dan (Dan) Subject: Update of the WG Items and Issue Discussion =09 =09 =09 =09 Dear WG members,=20 as you know, we have requested a session slot for IETF 72.=20 But in order for such a session to be usefull, we MUST prepare.=20 Currently we have 4 chartered WG items. The notification draft will be updated soon based on the changes for the=20 IESG discusses. The other 3 WG documents need a regular=20 update and issue discussion on the WG list.=20 We would like to encourage the I-D authors NOT TO WAIT=20 until the final I-D submission deadline on July 24. Please=20 submit your draft update in the next 1-2 weeks so that=20 we have sufficient time for review and issue discussion=20 on the maillist.=20 We would also like to urge everybody on the NETCONF=20 maillist to READ AND REVIEW the document updates and=20 send their review comments and requests to the maillist. The issue discussion is definitely needed before the WG=20 session and is the only way to get the issues solved and the documents stable.=20 If you see any open gaps, any problems, or things that=20 you think could be done better, then PLEASE POST those=20 to the maillist rather sooner than later. It will help some=20 discussion on the mailing list. Hopefully we can solve the=20 issues and address the concerns on the list and come to=20 convergence.=20 Those issues that we seem to not be able to find a=20 solution for, or for which we do not come to convergence,=20 ONLY THOSE deserve serious face to face time at the=20 upcoming IETF meeting.=20 We want to have only serious discussion of open and/or=20 controversial issues in the NETCONF session in Dublin.=20 But we all need to prepare for that. Let us prepare for=20 the NETCONF session at the IETF #72 in time and have=20 a successful session with solid results.=20 Thank you all for your support and enthusiasm.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C8BF0E.DC91090A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Update of the WG Items and Issue Discussion

Oops, this is true.
Below are=20 some of the important meeting dates:

July 2, Wednesday - Cutoff date for requests to reschedule Working = Group and=20 BOF meetings 17:00 PDT (24:00 UTC/GMT)
July 7, Monday - Final agenda = to be=20 published.
July 7, Monday - Internet Draft Cut-off for initial = document=20 (-00) submission by 17:00 PDT (24:00 UTC/GMT)
July 14,=20 Monday - Internet Draft final submission cut-off by 17:00 PDT = (24:00=20 UTC/GMT)
July 21, Monday - Revised Working Group agendas due by 17:00 = PDT=20 (24:00 by 17:00 PDT (24:00 UTC/GMT) July 14, Monday - Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT) July 21, Monday - Revised Working Group agendas due by 17:00 PDT (24:00 UTC/GMT) Cheers, Mehmet=20 =20 ________________________________ From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Monday, May 26, 2008 5:48 AM To: Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Cc: ext Bert Wijnen - IETF Subject: RE: Update of the WG Items and Issue Discussion =09 =09 Please pay attention, the final submission date for Dublin is JULY 14 and not July 24! =20 Of course, as Mehmet indicates, in order to prepare well the WG session in Dublin submitting early is very much recommended in order to ensure that the session is successful.=20 =20 Dan =20 ________________________________ From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com]=20 Sent: Sunday, May 25, 2008 9:54 PM To: netconf@ietf.org Cc: ext Bert Wijnen - IETF; Romascanu, Dan (Dan) Subject: Update of the WG Items and Issue Discussion =09 =09 =09 =09 Dear WG members,=20 as you know, we have requested a session slot for IETF 72.=20 But in order for such a session to be usefull, we MUST prepare.=20 Currently we have 4 chartered WG items. The notification draft will be updated soon based on the changes for the=20 IESG discusses. The other 3 WG documents need a regular=20 update and issue discussion on the WG list.=20 We would like to encourage the I-D authors NOT TO WAIT=20 until the final I-D submission deadline on July 24. Please=20 submit your draft update in the next 1-2 weeks so that=20 we have sufficient time for review and issue discussion=20 on the maillist.=20 We would also like to urge everybody on the NETCONF=20 maillist to READ AND REVIEW the document updates and=20 send their review comments and requests to the maillist. The issue discussion is definitely needed before the WG=20 session and is the only way to get the issues solved and the documents stable.=20 If you see any open gaps, any problems, or things that=20 you think could be done better, then PLEASE POST those=20 to the maillist rather sooner than later. It will help some=20 discussion on the mailing list. Hopefully we can solve the=20 issues and address the concerns on the list and come to=20 convergence.=20 Those issues that we seem to not be able to find a=20 solution for, or for which we do not come to convergence,=20 ONLY THOSE deserve serious face to face time at the=20 upcoming IETF meeting.=20 We want to have only serious discussion of open and/or=20 controversial issues in the NETCONF session in Dublin.=20 But we all need to prepare for that. Let us prepare for=20 the NETCONF session at the IETF #72 in time and have=20 a successful session with solid results.=20 Thank you all for your support and enthusiasm.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C8BF0E.DC91090A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Update of the WG Items and Issue Discussion

Oops, this is true.
Below are=20 some of the important meeting dates:

July 2, Wednesday - Cutoff date for requests to reschedule Working = Group and=20 BOF meetings 17:00 PDT (24:00 UTC/GMT)
July 7, Monday - Final agenda = to be=20 published.
July 7, Monday - Internet Draft Cut-off for initial = document=20 (-00) submission by 17:00 PDT (24:00 UTC/GMT)
July 14,=20 Monday - Internet Draft final submission cut-off by 17:00 PDT = (24:00=20 UTC/GMT)
July 21, Monday - Revised Working Group agendas due by 17:00 = PDT=20 (24:00 UTC/GMUTC/GMT)

Cheers,
Mehmet =
 

From: ext Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Monday, May 26, 2008 5:48 = AM
To: Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Cc: ext Bert Wijnen - = IETF
Subject: RE:=20 Update of the WG Items and Issue Discussion

Please pay attention, the final submission date = for Dublin=20 is JULY 14 and not July 24!
 
Of course, as Mehmet indicates, in order to prepare well the = WG session=20 in Dublin submitting early is very much recommended in order to ensure = that=20 the session is successful.
 
Dan
 

From: Ersue, Mehmet (NSN - = DE/Muenich)=20 [mailto:mehmet.ersue@nsn.com]
Sent: Sunday, May 25, 2008 = 9:54=20 PM
To: netconf@ietf.org
Cc: ext Bert Wijnen - = IETF;=20 Romascanu, Dan (Dan)
Subject: Update of the WG Items and = Issue=20 Discussion


Dear WG members,

as you know, we have requested a = session slot=20 for IETF 72.
But in order = for such a=20 session to be usefull, we MUST prepare.

Currently we have 4 chartered WG = items. The=20 notification
draft will be = updated soon=20 based on the changes for the
IESG=20 discusses. The other 3 WG documents need a regular
update and issue discussion on the WG list. =

We would like to encourage the I-D = authors NOT=20 TO WAIT
until the final I-D = submission=20 deadline on July 24. Please
submit your=20 draft update in the next 1-2 weeks so that
we have sufficient time for review and issue discussion=20
on the maillist. =

We would also like to urge = everybody on the=20 NETCONF
maillist to READ = AND REVIEW the=20 document updates and

Cheers,
Mehmet =
 

From: ext Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Monday, May 26, 2008 5:48 = AM
To: Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Cc: ext Bert Wijnen - = IETF
Subject: RE:=20 Update of the WG Items and Issue Discussion

Please pay attention, the final submission date = for Dublin=20 is JULY 14 and not July 24!
 
Of course, as Mehmet indicates, in order to prepare well the = WG session=20 in Dublin submitting early is very much recommended in order to ensure = that=20 the session is successful.
 
Dan
 

From: Ersue, Mehmet (NSN - = DE/Muenich)=20 [mailto:mehmet.ersue@nsn.com]
Sent: Sunday, May 25, 2008 = 9:54=20 PM
To: netconf@ietf.org
Cc: ext Bert Wijnen - = IETF;=20 Romascanu, Dan (Dan)
Subject: Update of the WG Items and = Issue=20 Discussion


Dear WG members,

as you know, we have requested a = session slot=20 for IETF 72.
But in order = for such a=20 session to be usefull, we MUST prepare.

Currently we have 4 chartered WG = items. The=20 notification
draft will be = updated soon=20 based on the changes for the
IESG=20 discusses. The other 3 WG documents need a regular
update and issue discussion on the WG list. =

We would like to encourage the I-D = authors NOT=20 TO WAIT
until the final I-D = submission=20 deadline on July 24. Please
submit your=20 draft update in the next 1-2 weeks so that
we have sufficient time for review and issue discussion=20
on the maillist. =

We would also like to urge = everybody on the=20 NETCONF
maillist to READ = AND REVIEW the=20 document updates and
e=3D2>send = their review=20 comments and requests to the maillist.
The issue discussion is definitely needed before the WG=20
session and is the only way = to get the=20 issues solved and
the = documents stable.=20
If you see any open gaps, = any problems,=20 or things that
you think = could be done=20 better, then PLEASE POST those
to the=20 maillist rather sooner than later. It will help some =
discussion on the mailing list. Hopefully we = can solve=20 the
issues and address the = concerns on=20 the list and come to
convergence.=20

Those issues that we seem to not be = able to=20 find a
solution for, or for = which we do=20 not come to convergence,
ONLY THOSE=20 deserve serious face to face time at the
upcoming IETF meeting.
We want=20 to have only serious discussion of open and/or
controversial issues in the NETCONF session in Dublin. =

But we all need to prepare for = that. Let us=20 prepare for
the NETCONF = session at the=20 IETF #72 in time and have
a = successful=20 session with solid results.

Thank you all for your support and = enthusiasm.=20

Bert & Mehmet=20

------_=_NextPart_001_01C8BF0E.DC91090A-- --===============0491640918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0491640918==-- send = their review=20 comments and requests to the maillist.
The issue discussion is definitely needed before the WG=20
session and is the only way = to get the=20 issues solved and
the = documents stable.=20
If you see any open gaps, = any problems,=20 or things that
you think = could be done=20 better, then PLEASE POST those
to the=20 maillist rather sooner than later. It will help some =
discussion on the mailing list. Hopefully we = can solve=20 the
issues and address the = concerns on=20 the list and come to
convergence.=20

Those issues that we seem to not be = able to=20 find a
solution for, or for = which we do=20 not come to convergence,
ONLY THOSE=20 deserve serious face to face time at the
upcoming IETF meeting.
We want=20 to have only serious discussion of open and/or
controversial issues in the NETCONF session in Dublin. =

But we all need to prepare for = that. Let us=20 prepare for
the NETCONF = session at the=20 IETF #72 in time and have
a = successful=20 session with solid results.

Thank you all for your support and = enthusiasm.=20

Bert & Mehmet=20

------_=_NextPart_001_01C8BF0E.DC91090A-- --===============0491640918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0491640918==-- From netconf-bounces@ietf.org Mon May 26 06:17:56 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B578E3A6846; Mon, 26 May 2008 06:17:56 -0700 (PDT) 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 5A65F3A694B for ; Mon, 26 May 2008 06:17:55 -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 BQKfjSVaP9bp for ; Mon, 26 May 2008 06:17:50 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id A376B3A67A9 for ; Mon, 26 May 2008 06:17:49 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4QDHm009347 for ; Mon, 26 May 2008 13:17:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 09:17:46 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414B1CB68@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus: A, B, C, D, E, F Security Considerations Thread-Index: Aci/MuOqL/IGMblOTr6ZM4UtTtMZlQ== From: "Sharon Chisholm" To: Subject: [Netconf] Consensus: A, B, C, D, E, F Security Considerations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi There were a large number of choices provided to replace that paragraph in the security considerations section. They all seemed to agree that authorization models were out of scope of the document so we should be careful what we said and that they should only talk about the contents of the notification, not the other operations (although there was some disagreement on the relationship of notification authorization model to that used for all other content, this is beyond the scope of this discussion). They seemed to differ then mainly on the strength of the language and how detailed things got. -- I think we agreed on these two sentences: - The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. - If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user. It wasn't clear there was agreement to add this one: - It is an administrative policy decision to determine who (or what) is authorized to have access to the information contained in notifications. --- I went back and reread the DISCUSS comment and I think this still clarifies the information they wanted clarified. I propose then that we replace the appropriate text in the security section with the two sentences identified above. I'll send out a draft update so people will be able to read the text in coFrom netconf-bounces@ietf.org Mon May 26 06:17:56 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B578E3A6846; Mon, 26 May 2008 06:17:56 -0700 (PDT) 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 5A65F3A694B for ; Mon, 26 May 2008 06:17:55 -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 BQKfjSVaP9bp for ; Mon, 26 May 2008 06:17:50 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id A376B3A67A9 for ; Mon, 26 May 2008 06:17:49 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4QDHm009347 for ; Mon, 26 May 2008 13:17:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 09:17:46 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414B1CB68@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus: A, B, C, D, E, F Security Considerations Thread-Index: Aci/MuOqL/IGMblOTr6ZM4UtTtMZlQ== From: "Sharon Chisholm" To: Subject: [Netconf] Consensus: A, B, C, D, E, F Security Considerations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi There were a large number of choices provided to replace that paragraph in the security considerations section. They all seemed to agree that authorization models were out of scope of the document so we should be careful what we said and that they should only talk about the contents of the notification, not the other operations (although there was some disagreement on the relationship of notification authorization model to that used for all other content, this is beyond the scope of this discussion). They seemed to differ then mainly on the strength of the language and how detailed things got. -- I think we agreed on these two sentences: - The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. - If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user. It wasn't clear there was agreement to add this one: - It is an administrative policy decision to determine who (or what) is authorized to have access to the information contained in notifications. --- I went back and reread the DISCUSS comment and I think this still clarifies the information they wanted clarified. I propose then that we replace the appropriate text in the security section with the two sentences identified above. I'll send out a draft update so people will be able to read the text in context.ntext. ---------- Old Text The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view content via other NETCONF operations, she must not have access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. ------- New Text The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ---------- Old Text The contents of notifications as well as the name of event streams may contain sensitive information and care should be taken to ensure that it is viewed only by authorized users. If a user does not have permission to view content via other NETCONF operations, she must not have access to that content via Notifications. If a user is not permitted to view one element in the content of the notification, the notification is not sent to that user. ------- New Text The contents of notifications as well as the names of event streams may contain sensitive information and care should be taken to ensure that they are viewed only by authorized users. If a user is not authorized to view all elements in the content of the notification, the notification is not sent to that user. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 27 05:20:48 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788BF3A6BDA; Tue, 27 May 2008 05:20:48 -0700 (PDT) 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 BC2ED3A6BD3 for ; Tue, 27 May 2008 05:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=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 KNdu8AcGucZI for ; Tue, 27 May 2008 05:20:46 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id A81E528C25F for ; Tue, 27 May 2008 05:17:11 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m4RDDlmJ704650 for ; Tue, 27 May 2008 14:13:47 +0100 Message-ID: <483BFB95.2020700@isima.fr> Date: Tue, 27 May 2008 14:16:21 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: netconf@ietf.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 27 May 2008 14:13:47 +0100 (WEST) Subject: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear all, We would encourage any contribution that could be used in combination with existing user authentication databases. Please don't hesitate to submit your comments on the options described through "NETCONF over TLS" [1] document in Appendix B, or to post your proposal on the mailing list to try to reach WG consensus. [1] http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-02.txt Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 27 05:20:48 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788BF3A6BDA; Tue, 27 May 2008 05:20:48 -0700 (PDT) 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 BC2ED3A6BD3 for ; Tue, 27 May 2008 05:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=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 KNdu8AcGucZI for ; Tue, 27 May 2008 05:20:46 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id A81E528C25F for ; Tue, 27 May 2008 05:17:11 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m4RDDlmJ704650 for ; Tue, 27 May 2008 14:13:47 +0100 Message-ID: <483BFB95.2020700@isima.fr> Date: Tue, 27 May 2008 14:16:21 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: netconf@ietf.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 27 May 2008 14:13:47 +0100 (WEST) Subject: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear all, We would encourage any contribution that could be used in combination with existing user authentication databases. Please don't hesitate to submit your comments on the options described through "NETCONF over TLS" [1] document in Appendix B, or to post your proposal on the mailing list to try to reach WG consensus. [1] http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-02.txt Best regards, -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 27 05:41:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4F73A69F0; Tue, 27 May 2008 05:41:54 -0700 (PDT) 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 0444E3A69F0 for ; Tue, 27 May 2008 05:41:54 -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 Mgf+NVZnfyZN for ; Tue, 27 May 2008 05:41:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B0EB93A69E8 for ; Tue, 27 May 2008 05:41:52 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54A42C0017; Tue, 27 May 2008 14:41:57 +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 JQPG-rVdS416; Tue, 27 May 2008 14:41:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 075E2C0011; Tue, 27 May 2008 14:41:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C69A85A32EF; Tue, 27 May 2008 14:41:49 +0200 (CEST) Date: Tue, 27 May 2008 14:41:49 +0200 From: Juergen Schoenwaelder To: Mohamad Badra Message-ID: <20080527124149.GA17077@elstar.local> Mail-Followup-To: Mohamad Badra , netconf@ietf.org References: <483BFB95.2020700@isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <483BFB95.2020700@isima.fr> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, May 27, 2008 at 02:16:21PM +0200, Mohamad Badra wrote: > We would encourage any contribution that could be used in combination > with existing user authentication databases. Please don't hesitate to > submit your comments on the options described through "NETCONF over TLS" > [1] document in Appendix B, or to post your proposal on the mailing > list to try to reach WG consensus. My $.02 worth of comments: : 1. Defining RPC: I share that the doubt that this will fly. Plain password authentication is just one out of many authentication methods out there. : 2. Enhancing TLS: Does not belong into the WG. : 3. Running BEEP over TLS This is already defined as part of the BEEP transport mapping. : 4. Extending NETCONF with a message to start TLS Extending NETCONF with a SASL hook is an architecture violation.From netconf-bounces@ietf.org Tue May 27 05:41:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4F73A69F0; Tue, 27 May 2008 05:41:54 -0700 (PDT) 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 0444E3A69F0 for ; Tue, 27 May 2008 05:41:54 -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 Mgf+NVZnfyZN for ; Tue, 27 May 2008 05:41:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B0EB93A69E8 for ; Tue, 27 May 2008 05:41:52 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54A42C0017; Tue, 27 May 2008 14:41:57 +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 JQPG-rVdS416; Tue, 27 May 2008 14:41:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 075E2C0011; Tue, 27 May 2008 14:41:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C69A85A32EF; Tue, 27 May 2008 14:41:49 +0200 (CEST) Date: Tue, 27 May 2008 14:41:49 +0200 From: Juergen Schoenwaelder To: Mohamad Badra Message-ID: <20080527124149.GA17077@elstar.local> Mail-Followup-To: Mohamad Badra , netconf@ietf.org References: <483BFB95.2020700@isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <483BFB95.2020700@isima.fr> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, May 27, 2008 at 02:16:21PM +0200, Mohamad Badra wrote: > We would encourage any contribution that could be used in combination > with existing user authentication databases. Please don't hesitate to > submit your comments on the options described through "NETCONF over TLS" > [1] document in Appendix B, or to post your proposal on the mailing > list to try to reach WG consensus. My $.02 worth of comments: : 1. Defining RPC: I share that the doubt that this will fly. Plain password authentication is just one out of many authentication methods out there. : 2. Enhancing TLS: Does not belong into the WG. : 3. Running BEEP over TLS This is already defined as part of the BEEP transport mapping. : 4. Extending NETCONF with a message to start TLS Extending NETCONF with a SASL hook is an architecture viol But this does not preclude the option that the TLS transport for NETCONF does provide hooks for SASL. : 5. Enable SSH (RFC4742 and TLS (as defined through this document: This does not make any sense to me. My suggestion is to actually do nothing to enable 3rd party authentication using passwords in this document other then wording things carefully such that something like this can be added in the future should this need ever arise. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ation. But this does not preclude the option that the TLS transport for NETCONF does provide hooks for SASL. : 5. Enable SSH (RFC4742 and TLS (as defined through this document: This does not make any sense to me. My suggestion is to actually do nothing to enable 3rd party authentication using passwords in this document other then wording things carefully such that something like this can be added in the future should this need ever arise. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 27 06:27:21 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAFA3A6A0B; Tue, 27 May 2008 06:27:21 -0700 (PDT) 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 87B7B3A6BAA for ; Tue, 27 May 2008 06:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_FR=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 aN8doa7gFbbf for ; Tue, 27 May 2008 06:27:19 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 1046D3A6A09 for ; Tue, 27 May 2008 06:26:25 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m4REN2e2827578; Tue, 27 May 2008 15:23:02 +0100 Message-ID: <483C0BCF.6060404@isima.fr> Date: Tue, 27 May 2008 15:25:35 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Juergen Schoenwaelder , netconf@ietf.org References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> In-Reply-To: <20080527124149.GA17077@elstar.local> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 27 May 2008 15:23:02 +0100 (WEST) Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder a =E9crit : > My suggestion is to actually do nothing to enable 3rd party > authentication using passwords in this document other then wording > things carefully such that something like this can be added in the > future should this need ever arise. I haven't any problem with that, this could be option #6 :) Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 27 06:27:21 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAFA3A6A0B; Tue, 27 May 2008 06:27:21 -0700 (PDT) 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 87B7B3A6BAA for ; Tue, 27 May 2008 06:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_FR=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 aN8doa7gFbbf for ; Tue, 27 May 2008 06:27:19 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 1046D3A6A09 for ; Tue, 27 May 2008 06:26:25 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m4REN2e2827578; Tue, 27 May 2008 15:23:02 +0100 Message-ID: <483C0BCF.6060404@isima.fr> Date: Tue, 27 May 2008 15:25:35 +0200 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Juergen Schoenwaelder , netconf@ietf.org References: <483BFB95.2020700@isima.fr> <20080527124149.GA17077@elstar.local> In-Reply-To: <20080527124149.GA17077@elstar.local> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 27 May 2008 15:23:02 +0100 (WEST) Subject: Re: [Netconf] WG Consensus on options 1, 2, 3, 4, 5 for Enabling Third Party Authentication using Passwords X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder a =E9crit : > My suggestion is to actually do nothing to enable 3rd party > authentication using passwords in this document other then wording > things carefully such that something like this can be added in the > future should this need ever arise. I haven't any problem with that, this could be option #6 :) Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue May 27 12:46:11 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E69C3A6A85; Tue, 27 May 2008 12:46:11 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 847BA28C224; Tue, 27 May 2008 05:15:00 -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: <20080527121501.847BA28C224@core3.amsl.com> Date: Tue, 27 May 2008 05:15:01 -0700 (PDT) X-Mailman-Approved-At: Tue, 27 May 2008 12:46:10 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF over Transport Layer Security (TLS) Author(s) : M. Badra, I. Hajjeh Filename : draft-ietf-netconf-tls-02.txt Pages : 15 Date : 2008-05-27 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Protocol (TLS) to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-02.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-tls-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-27051013.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Tue May 27 12:46:11 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E69C3A6A85; Tue, 27 May 2008 12:46:11 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 847BA28C224; Tue, 27 May 2008 05:15:00 -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: <20080527121501.847BA28C224@core3.amsl.com> Date: Tue, 27 May 2008 05:15:01 -0700 (PDT) X-Mailman-Approved-At: Tue, 27 May 2008 12:46:10 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF over Transport Layer Security (TLS) Author(s) : M. Badra, I. Hajjeh Filename : draft-ietf-netconf-tls-02.txt Pages : 15 Date : 2008-05-27 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Protocol (TLS) to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-02.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-tls-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-27051013.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Thu May 29 10:02:03 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFBF3A6B82; Thu, 29 May 2008 10:02:03 -0700 (PDT) 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 3537F3A6B08 for ; Thu, 29 May 2008 10:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.565 X-Spam-Level: X-Spam-Status: No, score=-4.565 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_ASCII_ART_SPACINGc=0.833, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 rk6N2X7Fkczv for ; Thu, 29 May 2008 10:01:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2DAEC3A6B16 for ; Thu, 29 May 2008 10:01:56 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m4TH0do01334 for ; Thu, 29 May 2008 17:00:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8C1AD.B10CE57C" Date: Thu, 29 May 2008 13:01:50 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Pre-13 Notification (take 2) Thread-Index: AcjBra+2ZE5YaljMRpaNnIGofrgosg== From: "Sharon Chisholm" To: Subject: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C1AD.B10CE57C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Attached is the update to the Notification draft that I will be posting later today. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada ------_=_NextPart_001_01C8C1AD.B10CE57C Content-Type: text/html; name="pre_13_2.htm" Content-Transfer-Encoding: base64 Content-Description: pre_13_2.htm Content-Disposition: attachment; filename="pre_13_2.htm" CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9u LTEyLnR4dCBuZXRjb25mX2V2ZW50LnR4dDwvdGl0bGU+PC9oZWFkPjxib2R5Pgo8cHJlPgoKTmV0 d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFMuIENoaXNob2xtCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE5vcnRlbApJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBU cmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEguIFRyZXZpbm8KRXhwaXJlczogPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5BdWd1c3QgMjgsPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+Tm92ZW1iZXIgMzAsPC9mb250Pjwvc3Ryb25nPiAyMDA4ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz5GZWJydWFyeSAyNSw8L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzdHJvbmFrom netconf-bounces@ietf.org Thu May 29 10:02:03 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFBF3A6B82; Thu, 29 May 2008 10:02:03 -0700 (PDT) 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 3537F3A6B08 for ; Thu, 29 May 2008 10:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.565 X-Spam-Level: X-Spam-Status: No, score=-4.565 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_ASCII_ART_SPACINGc=0.833, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 rk6N2X7Fkczv for ; Thu, 29 May 2008 10:01:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2DAEC3A6B16 for ; Thu, 29 May 2008 10:01:56 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m4TH0do01334 for ; Thu, 29 May 2008 17:00:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8C1AD.B10CE57C" Date: Thu, 29 May 2008 13:01:50 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Pre-13 Notification (take 2) Thread-Index: AcjBra+2ZE5YaljMRpaNnIGofrgosg== From: "Sharon Chisholm" To: Subject: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C1AD.B10CE57C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Attached is the update to the Notification draft that I will be posting later today. Sharon Chisholm Nortel=20 Ottawa, Ontario Canada ------_=_NextPart_001_01C8C1AD.B10CE57C Content-Type: text/html; name="pre_13_2.htm" Content-Transfer-Encoding: base64 Content-Description: pre_13_2.htm Content-Disposition: attachment; filename="pre_13_2.htm" CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9u LTEyLnR4dCBuZXRjb25mX2V2ZW50LnR4dDwvdGl0bGU+PC9oZWFkPjxib2R5Pgo8cHJlPgoKTmV0 d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFMuIENoaXNob2xtCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE5vcnRlbApJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBU cmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEguIFRyZXZpbm8KRXhwaXJlczogPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5BdWd1c3QgMjgsPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+Tm92ZW1iZXIgMzAsPC9mb250Pjwvc3Ryb25nPiAyMDA4ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz5GZWJydWFyeSAyNSw8L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzc+PGZvbnQg Y29sb3I9J2dyZWVuJz5NYXkgMjksPC9mb250Pjwvc3Ryb25nPiAyMDA4CgogICAgICAgICAgICAg ICAgICAgICAgTkVUQ09ORiBFdmVudCBOb3RpZmljYXRpb25zCiAgICAgICAgICAgICAgICAgPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLTEy LnR4dDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi0xMy50eHQ8L2ZvbnQ+PC9z dHJvbmc+CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJu ZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBwbGljYWJsZSBw YXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUKICAg aGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNo ZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGgg U2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBp dHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3Jv dXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAg IERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQK ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxp c3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPkF1Z3VzdCAyOCw8 L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5Ob3ZlbWJlciAzMCw8 L2ZvbnQ+PC9zdHJvbmc+IDIwMDguCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKEMp IFRoZSBJRVRGIFRydXN0ICgyMDA4KS4KCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgbWVjaGFuaXNtcyB0aGF0IHByb3ZpZGUgYW4gYXN5bmNocm9ub3VzIG1lc3NhZ2UKICAgbm90 aWZpY2F0aW9uIGRlbGl2ZXJ5IHNlcnZpY2UgZm9yIHRoZSBORVRDT05GIHByb3RvY29sLiAgVGhp cyBpcyBhbgogICBvcHRpb25hbCBjYXBhYmlsaXR5IGJ1aWx0IG9uIHRvcCBvZiB0aGUgYmFzZSBO RVRDT05GIGRlZmluaXRpb24uCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgY2FwYWJpbGl0 aWVzIGFuZCBvcGVyYXRpb25zIG5lY2Vzc2FyeSB0bwogICBzdXBwb3J0IHRoaXMgc2VydmljZS4K ClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAxLjEuICBEZWZpbml0aW9u IG9mIFRlcm1zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgICAg MS4yLiAgTW90aXZhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNQogICAgIDEuMy4gIEV2ZW50IE5vdGlmaWNhdGlvbnMgaW4gTkVUQ09ORiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgMi4gIE5vdGlmaWNhdGlvbi1SZWxhdGVkIE9w ZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgMi4xLiAgU3Vi c2NyaWJpbmcgdG8gUmVjZWl2ZSBFdmVudCBOb3RpZmljYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAg NwogICAgICAgMi4xLjEuICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgICAyLjIuICBTZW5kaW5nIEV2ZW50IE5vdGlmaWNh dGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgICAgICAyLjIuMS4gICZs dDtub3RpZmljYXRpb24mZ3Q7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMAogICAgIDIuMy4gIFRlcm1pbmF0aW5nIHRoZSBTdWJzY3JpcHRpb24gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgMy4gIFN1cHBvcnRpbmcgQ29uY2VwdHMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgMy4xLiAgQ2FwYWJpbGl0 aWVzIEV4Y2hhbmdlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAg ICAgMy4xLjEuICBDYXBhYmlsaXR5IElkZW50aWZpZXIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTEKICAgICAgIDMuMS4yLiAgQ2FwYWJpbGl0eSBFeGFtcGxlIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgMy4yLiAgRXZlbnQgU3RyZWFtcyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgICAgMy4yLjEu ICBFdmVudCBTdHJlYW0gRGVmaW5pdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTMKdHJvbmc+PGZvbnQg Y29sb3I9J2dyZWVuJz5NYXkgMjksPC9mb250Pjwvc3Ryb25nPiAyMDA4CgogICAgICAgICAgICAg ICAgICAgICAgTkVUQ09ORiBFdmVudCBOb3RpZmljYXRpb25zCiAgICAgICAgICAgICAgICAgPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLTEy LnR4dDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi0xMy50eHQ8L2ZvbnQ+PC9z dHJvbmc+CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJu ZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBwbGljYWJsZSBw YXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUKICAg aGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNo ZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGgg U2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBp dHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3Jv dXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAg IERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQK ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxp c3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPkF1Z3VzdCAyOCw8 L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5Ob3ZlbWJlciAzMCw8 L2ZvbnQ+PC9zdHJvbmc+IDIwMDguCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKEMp IFRoZSBJRVRGIFRydXN0ICgyMDA4KS4KCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IGRlZmlu ZXMgbWVjaGFuaXNtcyB0aGF0IHByb3ZpZGUgYW4gYXN5bmNocm9ub3VzIG1lc3NhZ2UKICAgbm90 aWZpY2F0aW9uIGRlbGl2ZXJ5IHNlcnZpY2UgZm9yIHRoZSBORVRDT05GIHByb3RvY29sLiAgVGhp cyBpcyBhbgogICBvcHRpb25hbCBjYXBhYmlsaXR5IGJ1aWx0IG9uIHRvcCBvZiB0aGUgYmFzZSBO RVRDT05GIGRlZmluaXRpb24uCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgY2FwYWJpbGl0 aWVzIGFuZCBvcGVyYXRpb25zIG5lY2Vzc2FyeSB0bwogICBzdXBwb3J0IHRoaXMgc2VydmljZS4K ClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAxLjEuICBEZWZpbml0aW9u IG9mIFRlcm1zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgICAg MS4yLiAgTW90aXZhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNQogICAgIDEuMy4gIEV2ZW50IE5vdGlmaWNhdGlvbnMgaW4gTkVUQ09ORiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgMi4gIE5vdGlmaWNhdGlvbi1SZWxhdGVkIE9w ZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3CiAgICAgMi4xLiAgU3Vi c2NyaWJpbmcgdG8gUmVjZWl2ZSBFdmVudCBOb3RpZmljYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAg NwogICAgICAgMi4xLjEuICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgICAyLjIuICBTZW5kaW5nIEV2ZW50IE5vdGlmaWNh dGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgICAgICAyLjIuMS4gICZs dDtub3RpZmljYXRpb24mZ3Q7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMAogICAgIDIuMy4gIFRlcm1pbmF0aW5nIHRoZSBTdWJzY3JpcHRpb24gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgMy4gIFN1cHBvcnRpbmcgQ29uY2VwdHMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgMy4xLiAgQ2FwYWJpbGl0 aWVzIEV4Y2hhbmdlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAg ICAgMy4xLjEuICBDYXBhYmlsaXR5IElkZW50aWZpZXIgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTEKICAgICAgIDMuMS4yLiAgQ2FwYWJpbGl0eSBFeGFtcGxlIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgMy4yLiAgRXZlbnQgU3RyZWFtcyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICAgICAgMy4yLjEu ICBFdmVudCBTdHJlYW0gRGVmaW5pdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4ICAgICAgIDMuMi4yLiAgRXZlbnQgU3RyZWFtIENvbnRlbnQgRm9ybWF0ICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgICAzLjIuMy4gIERlZmF1bHQgRXZlbnQgU3RyZWFtIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgICAgMy4yLjQuICBFdmVudCBT dHJlYW0gU291cmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgICAg IDMuMi41LiAgRXZlbnQgU3RyZWFtIERpc2NvdmVyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDEzCiAgICAgMy4zLiAgTm90aWZpY2F0aW9uIFJlcGxheSAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgICAgMy4zLjEuICBPdmVydmlldyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgICAgIDMuMy4yLiAg Q3JlYXRpbmcgYSBTdWJzY3JpcHRpb24gd2l0aCBSZXBsYXkgIC4gLiAuIC4gLiAuIC4gLiAuIDE3 CiAgICAgMy40LiAgTm90aWZpY2F0aW9uIE1hbmFnZW1lbnQgU2NoZW1hIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNwogICAgIDMuNS4gIFN1YnNjcmlwdGlvbnMgRGF0YSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgICAzLjYuICBGaWx0ZXIgTWVjaGFu aWNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIxCiAgICAgICAz LjYuMS4gIEZpbHRlcmluZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyMQogICAgIDMuNy4gIE1lc3NhZ2UgRmxvdyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgNC4gIFhNTCBTY2hlbWEgZm9yIEV2ZW50IE5vdGlm aWNhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0CiAgIDUuICBGaWx0ZXJpbmcg RXhhbXBsZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOAog ICAgIDUuMS4gIFN1YnRyZWUgRmlsdGVyaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zMjwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjMxPC9mb250Pjwvc3Ryb25nPgogICAgIDUuMi4g IFhQQVRIIGZpbHRlcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zMzwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nPjMyPC9mb250Pjwvc3Ryb25nPgogICA2LiAgSW50ZXJsZWF2ZSBD YXBhYmlsaXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz4zNTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0nZ3JlZW4nPjM0PC9mb250Pjwvc3Ryb25nPgogICAgIDYuMS4gIERlc2NyaXB0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz4zNTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4n PjM0PC9mb250Pjwvc3Ryb25nPgogICAgIDYuMi4gIERlcGVuZGVuY2llcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk Jz4zNTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjM0PC9mb250 Pjwvc3Ryb25nPgogICAgIDYuMy4gIENhcGFiaWxpdHkgSWRlbnRpZmllciAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zNTwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjM0PC9mb250Pjwvc3Ryb25n PgogICAgIDYuNC4gIE5ldyBPcGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zNTwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjM0PC9mb250Pjwvc3Ryb25nPgogICAgIDYu NS4gIE1vZGlmaWNhdGlvbnMgdG8gRXhpc3RpbmcgT3BlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zNTwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nPjM0PC9mb250Pjwvc3Ryb25nPgogICA3LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zNjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBj b2xvcj0nZ3JlZW4nPjM1PC9mb250Pjwvc3Ryb25nPgogICA4LiAgSUFOQSBDb25zaWRlcmF0aW9u cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcKICAgOS4gIEFj a25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDM4CiAgIDEwLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAzOQogICBBcHBlbmRpeCBBLiAgQ2hhbmdlIExvZyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDAKICAgICBBLjEuICBWZXJzaW9u IC0wOCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwCiAg ICAgQS4yLiAgVmVyc2lvbiAtMDkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA0MgogICAgIEEuMy4gIFZlcnNpb24gLTEwICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDQKICAgICBBLjQuICBWZXJzaW9uIC0xMSAgLiAu IC4gLiAuIC4gLiAuIC4g MTMKICAgICAgIDMuMi4yLiAgRXZlbnQgU3RyZWFtIENvbnRlbnQgRm9ybWF0ICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgICAzLjIuMy4gIERlZmF1bHQgRXZlbnQgU3RyZWFtIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgICAgMy4yLjQuICBFdmVudCBT dHJlYW0gU291cmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMKICAgICAg IDMuMi41LiAgRXZlbnQgU3RyZWFtIERpc2NvdmVyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDEzCiAgICAgMy4zLiAgTm90aWZpY2F0aW9uIFJlcGxheSAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgICAgMy4zLjEuICBPdmVydmlldyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgICAgIDMuMy4yLiAg Q3JlYXRpbmcgYSBTdWJzY3JpcHRpb24gd2l0aCBSZXBsYXkgIC4gLiAuIC4gLiAuIC4gLiAuIDE3 CiAgICAgMy40LiAgTm90aWZpY2F0aW9uIE1hbmFnZW1lbnQgU2NoZW1hIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNwogICAgIDMuNS4gIFN1YnNjcmlwdGlvbnMgRGF0YSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgICAzLjYuICBGaWx0ZXIgTWVjaGFu aWNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIxCiAgICAgICAz LjYuMS4gIEZpbHRlcmluZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyMQogICAgIDMuNy4gIE1lc3NhZ2UgRmxvdyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgNC4gIFhNTCBTY2hlbWEgZm9yIEV2ZW50IE5vdGlm aWNhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0CiAgIDUuICBGaWx0ZXJpbmcg RXhhbXBsZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOAog ICAgIDUuMS4gIFN1YnRyZWUgRmlsdGVyaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zMjwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjMxPC9mb250Pjwvc3Ryb25nPgogICAgIDUuMi4g IFhQQVRIIGZpbHRlcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zMzwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nPjMyPC9mb250Pjwvc3Ryb25nPgogICA2LiAgSW50ZXJsZWF2ZSBD YXBhYmlsaXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz4zNTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xv cj0nZ3JlZW4nPjM0PC9mb250Pjwvc3Ryb25nPgogICAgIDYuMS4gIERlc2NyaXB0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz4zNTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4n PjM0PC9mb250Pjwvc3Ryb25nPgogICAgIDYuMi4gIERlcGVuZGVuY2llcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk Jz4zNTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjM0PC9mb250 Pjwvc3Ryb25nPgogICAgIDYuMy4gIENhcGFiaWxpdHkgSWRlbnRpZmllciAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zNTwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjM0PC9mb250Pjwvc3Ryb25n PgogICAgIDYuNC4gIE5ldyBPcGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zNTwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPjM0PC9mb250Pjwvc3Ryb25nPgogICAgIDYu NS4gIE1vZGlmaWNhdGlvbnMgdG8gRXhpc3RpbmcgT3BlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zNTwvZm9udD48L3N0cmlrZT4gPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nPjM0PC9mb250Pjwvc3Ryb25nPgogICA3LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz4zNjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBj b2xvcj0nZ3JlZW4nPjM1PC9mb250Pjwvc3Ryb25nPgogICA4LiAgSUFOQSBDb25zaWRlcmF0aW9u cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzcKICAgOS4gIEFj a25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDM4CiAgIDEwLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAzOQogICBBcHBlbmRpeCBBLiAgQ2hhbmdlIExvZyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDAKICAgICBBLjEuICBWZXJzaW9u IC0wOCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwCiAg ICAgQS4yLiAgVmVyc2lvbiAtMDkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA0MgogICAgIEEuMy4gIFZlcnNpb24gLTEwICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDQKICAgICBBLjQuICBWZXJzaW9uIC0xMSAgLiAu IC4gLiAuIC4gLgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ0CiAgICAgQS41LiAg PHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5WZXNyaW9uPC9mb250Pjwvc3RyaWtlPiAgPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nPlZlcnNpb248L2ZvbnQ+PC9zdHJvbmc+IC0xMiAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ1CiAgICAgPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nPkEuNi4gIFZlcnNpb24gLTEzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDU8L2ZvbnQ+PC9zdHJvbmc+CiAgIEF1dGhvcnMn IEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjQ2PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+NDg8L2ZvbnQ+PC9zdHJvbmc+CiAgIEludGVsbGVjdHVhbCBQcm9w ZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtl Pjxmb250IGNvbG9yPSdyZWQnPjQ3PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+NDk8L2ZvbnQ+PC9zdHJvbmc+CgoxLiAgSW50cm9kdWN0aW9uCgogICBbTkVUQ09O Rl0gY2FuIGJlIGNvbmNlcHR1YWxseSBwYXJ0aXRpb25lZCBpbnRvIGZvdXIgbGF5ZXJzOgoKICAg ICAgICBMYXllciAgICAgICAgICAgICAgICAgICAgICAgICAgICBFeGFtcGxlCiAgICArLS0tLS0t LS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsKICAgIHwgICBDb250ZW50ICAgfCAgICAgIHwgICAgIENvbmZpZ3VyYXRpb24gZGF0YSAgICAg ICAgICAgICAgICAgICAgfAogICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgfCBPcGVyYXRpb25zICB8ICAgICAg fCAmbHQ7Z2V0LWNvbmZpZyZndDssICZsdDtlZGl0LWNvbmZpZyZndDsgJmx0O25vdGlmaWNhdGlv biZndDt8CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgfAogICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICB8CiAgICB8ICAgICBSUEMgICAgIHwg ICAgICB8ICAgICZsdDtycGMmZ3Q7LCAmbHQ7cnBjLXJlcGx5Jmd0OyAgICAgICB8ICAgICAgIHwK ICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsg ICAgICAgfAogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICB8CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgIHwgIFRyYW5zcG9ydCAgfCAgICAgIHwg ICBCRUVQLCBTU0gsIFNTTCwgY29uc29sZSAgICAgICAgICAgICAgICAgfAogICAgfCAgUHJvdG9j b2wgICB8ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAx CgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgbWVjaGFuaXNtcyB3aGljaCBwcm92aWRlIGFuIGFz eW5jaHJvbm91cwogICBtZXNzYWdlIG5vdGlmaWNhdGlvbiBkZWxpdmVyeSBzZXJ2aWNlIGZvciB0 aGUgW05FVENPTkZdIHByb3RvY29sLgogICBUaGlzIGlzIGFuIG9wdGlvbmFsIGNhcGFiaWxpdHkg YnVpbHQgb24gdG9wIG9mIHRoZSBiYXNlIE5FVENPTkYKICAgZGVmaW5pdGlvbi4gIFRoaXMgbWVt byBkZWZpbmVzIHRoZSBjYXBhYmlsaXRpZXMgYW5kIG9wZXJhdGlvbnMKICAgbmVjZXNzYXJ5IHRv IHN1cHBvcnQgdGhpcyBzZXJ2aWNlLgoKMS4xLiAgRGVmaW5pdGlvbiBvZiBUZXJtcwoKICAgVGhl IGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFM TCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4KCiAgIEVsZW1lbnQ6ICBBbiBbWE1MXSBFbGVtZW50 LgoKICAgU3Vic2NyaXB0aW9uOiAgQW4gYWdyZWVtZW50IGFuZCBtZXRob2QgdG8gcmVjZWl2ZSBl dmVudCBub3RpZmljYXRpb25zCiAgICAgIG92ZXIgYSBORVRDT05GIHNlc3Npb24uICBBIGNvbmNl cHQgcmVsYXRlZCB0byB0aGUgZGVsaXZlcnkgb2YKICAgICAgbm90aWZpY2F0aW9ucyAoaWYgdGhl cmUgYXJlIGFueSB0byBzZW5kKSBpbnZvbHZpbmcgZGVzdGluYXRpb24gYW5kCiAgICAgIHNlbGVj dGlvbiBvZiBub3RpZmljYXRpb25zLiAgSXQgaXMgYm91bmQgdG8gdGhlIGxpZmV0aW1lIG9mIGEK ICAgICAgc2Vzc2lvbi4KCiAgIE9wZXJhdGlvbjogIFRoaXMgdGVybSBpcyB1c2VkIHRvIHJlZmVy IHRvIE5FVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucwogICAgICBbTkVUQ09ORl0uICBXaXRoaW4g dGhpcyBkb2N1bWVudCwgb3BlcmF0aW9uIHJlZmVycyB0byBORVRDT05GCiAgICAgIHByb3RvY29s IG9wZXJhdGlvbnMgZGVmaW5lZCBpbiBzdXBwb3J0IG9mIE5FVENPTkYgbm90aWZpY2F0aW9ucy4K CiAgIEV2ZW50OiAgQW4gZXZlbnQgaXMgc2iAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ0CiAgICAgQS41LiAg PHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5WZXNyaW9uPC9mb250Pjwvc3RyaWtlPiAgPHN0cm9u Zz48Zm9udCBjb2xvcj0nZ3JlZW4nPlZlcnNpb248L2ZvbnQ+PC9zdHJvbmc+IC0xMiAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ1CiAgICAgPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nPkEuNi4gIFZlcnNpb24gLTEzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDU8L2ZvbnQ+PC9zdHJvbmc+CiAgIEF1dGhvcnMn IEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjQ2PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+NDg8L2ZvbnQ+PC9zdHJvbmc+CiAgIEludGVsbGVjdHVhbCBQcm9w ZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtl Pjxmb250IGNvbG9yPSdyZWQnPjQ3PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+NDk8L2ZvbnQ+PC9zdHJvbmc+CgoxLiAgSW50cm9kdWN0aW9uCgogICBbTkVUQ09O Rl0gY2FuIGJlIGNvbmNlcHR1YWxseSBwYXJ0aXRpb25lZCBpbnRvIGZvdXIgbGF5ZXJzOgoKICAg ICAgICBMYXllciAgICAgICAgICAgICAgICAgICAgICAgICAgICBFeGFtcGxlCiAgICArLS0tLS0t LS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsKICAgIHwgICBDb250ZW50ICAgfCAgICAgIHwgICAgIENvbmZpZ3VyYXRpb24gZGF0YSAgICAg ICAgICAgICAgICAgICAgfAogICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgfCBPcGVyYXRpb25zICB8ICAgICAg fCAmbHQ7Z2V0LWNvbmZpZyZndDssICZsdDtlZGl0LWNvbmZpZyZndDsgJmx0O25vdGlmaWNhdGlv biZndDt8CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgfAogICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICB8CiAgICB8ICAgICBSUEMgICAgIHwg ICAgICB8ICAgICZsdDtycGMmZ3Q7LCAmbHQ7cnBjLXJlcGx5Jmd0OyAgICAgICB8ICAgICAgIHwK ICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsg ICAgICAgfAogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICB8CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgIHwgIFRyYW5zcG9ydCAgfCAgICAgIHwg ICBCRUVQLCBTU0gsIFNTTCwgY29uc29sZSAgICAgICAgICAgICAgICAgfAogICAgfCAgUHJvdG9j b2wgICB8ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsKCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAx CgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgbWVjaGFuaXNtcyB3aGljaCBwcm92aWRlIGFuIGFz eW5jaHJvbm91cwogICBtZXNzYWdlIG5vdGlmaWNhdGlvbiBkZWxpdmVyeSBzZXJ2aWNlIGZvciB0 aGUgW05FVENPTkZdIHByb3RvY29sLgogICBUaGlzIGlzIGFuIG9wdGlvbmFsIGNhcGFiaWxpdHkg YnVpbHQgb24gdG9wIG9mIHRoZSBiYXNlIE5FVENPTkYKICAgZGVmaW5pdGlvbi4gIFRoaXMgbWVt byBkZWZpbmVzIHRoZSBjYXBhYmlsaXRpZXMgYW5kIG9wZXJhdGlvbnMKICAgbmVjZXNzYXJ5IHRv IHN1cHBvcnQgdGhpcyBzZXJ2aWNlLgoKMS4xLiAgRGVmaW5pdGlvbiBvZiBUZXJtcwoKICAgVGhl IGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFM TCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4KCiAgIEVsZW1lbnQ6ICBBbiBbWE1MXSBFbGVtZW50 LgoKICAgU3Vic2NyaXB0aW9uOiAgQW4gYWdyZWVtZW50IGFuZCBtZXRob2QgdG8gcmVjZWl2ZSBl dmVudCBub3RpZmljYXRpb25zCiAgICAgIG92ZXIgYSBORVRDT05GIHNlc3Npb24uICBBIGNvbmNl cHQgcmVsYXRlZCB0byB0aGUgZGVsaXZlcnkgb2YKICAgICAgbm90aWZpY2F0aW9ucyAoaWYgdGhl cmUgYXJlIGFueSB0byBzZW5kKSBpbnZvbHZpbmcgZGVzdGluYXRpb24gYW5kCiAgICAgIHNlbGVj dGlvbiBvZiBub3RpZmljYXRpb25zLiAgSXQgaXMgYm91bmQgdG8gdGhlIGxpZmV0aW1lIG9mIGEK ICAgICAgc2Vzc2lvbi4KCiAgIE9wZXJhdGlvbjogIFRoaXMgdGVybSBpcyB1c2VkIHRvIHJlZmVy IHRvIE5FVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucwogICAgICBbTkVUQ09ORl0uICBXaXRoaW4g dGhpcyBkb2N1bWVudCwgb3BlcmF0aW9uIHJlZmVycyB0byBORVRDT05GCiAgICAgIHByb3RvY29s IG9wZXJhdGlvbnMgZGVmaW5lZCBpbiBzdXBwb3J0IG9mIE5FVENPTkYgbm90aWZpY2F0aW9ucy4K CiAgIEV2ZW50OiAgQW4gZXZlbnQg9tZXRoaW5nIHRoYXQgaGFwcGVucyB3aGljaCBtYXkg YmUgb2YgaW50ZXJlc3QgLQogICAgICBhIGNvbmZpZ3VyYXRpb24gY2hhbmdlLCBhIGZhdWx0LCBh IGNoYW5nZSBpbiBzdGF0dXMsIGNyb3NzaW5nIGEKICAgICAgdGhyZXNob2xkLCBvciBhbiBleHRl cm5hbCBpbnB1dCB0byB0aGUgc3lzdGVtLCBmb3IgZXhhbXBsZS4gIE9mdGVuCiAgICAgIHRoaXMg cmVzdWx0cyBpbiBhbiBhc3luY2hyb25vdXMgbWVzc2FnZSwgc29tZXRpbWVzIHJlZmVycmVkIHRv IGFzCiAgICAgIGEgbm90aWZpY2F0aW9uIG9yIGV2ZW50IG5vdGlmaWNhdGlvbiwgYmVpbmcgc2Vu dCB0byBpbnRlcmVzdGVkCiAgICAgIHBhcnRpZXMgdG8gbm90aWZ5IHRoZW0gdGhhdCB0aGlzIGV2 ZW50IGhhcyBvY2N1cnJlZC4KCiAgIFJlcGxheTogIFRoZSBhYmlsaXR5IHRvIHNlbmQvcmUtc2Vu ZCBwcmV2aW91c2x5IGxvZ2dlZCBub3RpZmljYXRpb25zCiAgICAgIHVwb24gcmVxdWVzdC4gIFRo ZXNlIG5vdGlmaWNhdGlvbnMgYXJlIHNlbnQgYXN5bmNocm9ub3VzbHkuICBUaGlzCiAgICAgIGZl YXR1cmUgaXMgaW1wbGVtZW50ZWQgYnkgdGhlIE5FVENPTkYgc2VydmVyIGFuZCBpbnZva2VkIGJ5 IHRoZQogICAgICBORVRDT05GIGNsaWVudC4KCiAgIFN0cmVhbTogIEFuIGV2ZW50IHN0cmVhbSBp cyBhIHNldCBvZiBldmVudCBub3RpZmljYXRpb25zIG1hdGNoaW5nCiAgICAgIHNvbWUgZm9yd2Fy ZGluZyBjcml0ZXJpYSBhbmQgYXZhaWxhYmxlIHRvIE5FVENPTkYgY2xpZW50cyBmb3IKICAgICAg c3Vic2NyaXB0aW9uLgoKICAgRmlsdGVyOiAgQSBwYXJhbWV0ZXIgdGhhdCBpbmRpY2F0ZXMgd2hp Y2ggc3Vic2V0IG9mIGFsbCBwb3NzaWJsZQogICAgICBldmVudHMgYXJlIG9mIGludGVyZXN0LiAg QSBmaWx0ZXIgaXMgZGVmaW5lZCBhcyBvbmUgb3IgbW9yZSBmaWx0ZXIKICAgICAgZWxlbWVudCBb TkVUQ09ORl0sIHdoaWNoIGVhY2ggaWRlbnRpZmllcyBhIHBvcnRpb24gb2YgdGhlIG92ZXJhbGwK ICAgICAgZmlsdGVyLgoKMS4yLiAgTW90aXZhdGlvbgoKICAgVGhlIG1vdGl2YXRpb24gZm9yIHRo aXMgd29yayBpcyB0byBlbmFibGUgdGhlIHNlbmRpbmcgb2YgYXN5bmNocm9ub3VzCiAgIG1lc3Nh Z2VzIHRoYXQgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgZGF0YSBtb2RlbCAoY29udGVudCkgYW5k CiAgIHNlY3VyaXR5IG1vZGVsIHVzZWQgd2l0aGluIGEgTkVUQ09ORiBpbXBsZW1lbnRhdGlvbi4K CiAgIFRoZSBzY29wZSBvZiB0aGUgd29yayBhaW1zIG1lZXRpbmcgdGhlIGZvbGxvd2luZyBvcGVy YXRpb25hbCBuZWVkczoKCiAgIG8gIEluaXRpYWwgcmVsZWFzZSBzaG91bGQgZW5zdXJlIGl0IHN1 cHBvcnRzIG5vdGlmaWNhdGlvbnMgaW4gc3VwcG9ydAogICAgICBvZiBjb25maWd1cmF0aW9uIG9w ZXJhdGlvbnMuCgogICBvICBJdCBzaG91bGQgYmUgcG9zc2libGUgdG8gdXNlIHRoZSBzYW1lIGRh dGEgbW9kZWwgZm9yIG5vdGlmaWNhdGlvbnMKICAgICAgYXMgZm9yIGNvbmZpZ3VyYXRpb24gb3Bl cmF0aW9ucy4KCiAgIG8gIFNvbHV0aW9uIHNob3VsZCBzdXBwb3J0IGEgcmVhc29uYWJsZSBtZXNz YWdlIHNpemUgbGltaXQgKGkuZS4sIG5vdAogICAgICB0b28gc2hvcnQpCgogICBvICBUaGUgbm90 aWZpY2F0aW9ucyBzaG91bGQgYmUgY2FycmllZCBvdmVyIGEgY29ubmVjdGlvbi1vcmllbnRlZAog ICAgICBkZWxpdmVyeSBtZWNoYW5pc20uCgogICBvICBBIHN1YnNjcmlwdGlvbiBtZWNoYW5pc20g Zm9yIG5vdGlmaWNhdGlvbnMgc2hvdWxkIGJlIHByb3ZpZGVkLgogICAgICBUaGlzIHRha2VzIGlu dG8gYWNjb3VudCB0aGF0IGEgTkVUQ09ORiBzZXJ2ZXIgZG9lcyBub3Qgc2VuZAogICAgICBub3Rp ZmljYXRpb25zIGJlZm9yZSBiZWluZyBhc2tlZCB0byBkbyBzbyBhbmQgdGhhdCBpdCBpcyB0aGUK ICAgICAgTkVUQ09ORiBjbGllbnQgd2hvIGluaXRpYXRlcyB0aGUgZmxvdyBvZiBub3RpZmljYXRp b25zLgoKICAgbyAgQSBmaWx0ZXJpbmcgbWVjaGFuaXNtIGZvciBzZW5kaW5nIG5vdGlmaWNhdGlv bnMgc2hvdWxkIGJlIHB1dCBpbgogICAgICBwbGFjZSB3aXRoaW4gdGhlIE5FVENPTkYgc2VydmVy LgoKICAgbyAgVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBhIG5vdGlmaWNhdGlvbiBzaG91 bGQgYmUgc3VmZmljaWVudAogICAgICBzbyB0aGF0IGl0IGNhbiBiZSBhbmFseXplZCBpbmRlcGVu ZGVudCBvZiB0aGUgdHJhbnNwb3J0IG1lY2hhbmlzbS4KICAgICAgSW4gb3RoZXIgd29yZHMgdGhl IGRhdGEgY29udGVudCBmdWxseSBkZXNjcmliZXMgYSBub3RpZmljYXRpb247CiAgICAgIHByb3Rv Y29sIGluZm9ybWF0aW9uIGlzIG5vdCBuZWVkZWQgdG8gdW5kZXJzdGFuZCBhIG5vdGlmaWNhdGlv bi4KCiAgIG8gIFRoZSBzZXJ2ZXIgc2hvdWxkIGhhdmUgdGhlIGNhcGFiaWxpdHkgdG8gcmVwbGF5 IGxvY2FsbHkgbG9nZ2VkCiAgICAgIG5vdGlmaWNhdGlvbnMuCgoxLjMuICBFdmVudCBOb3RpZmlj YXRpb25zIGluIE5FVENPTkYKCiAgIFRoaXMgbWVtbyBkZWZpbmVzIGEgbWVjaGFuaXNtIHdoZXJl YnkgdGhlIE5FVENPTkYgY2xpZW50IGluZGljYXRlcwogICBpbnRlcmVzdCBpbiByZWNlaXZpbmcg ZXZlbnQgbm90aWZpY2F0aW9ucyBmcm9tIGEgTkVUQ09ORiBzZXJ2ZXIgYnkKICAgY3JlYXRpbmcg YSBzdWJzY3JpcHRpb24gdG8gcmVjZWl2ZSBldmVudCBub3RpZmljYXRpb25zLiAgVGhlIE5FVENP TkYKICAgc2VydmVyIHJlcGxpZXMgdG8gaW5kaWNhdGUgd2hldGhlciB0aGUgc3Vic2NyaXB0aW9u IHJlcXVlc3Qgd2FzCiAgIHN1Y2Nlc3NmdWwgYW5kLCBpZiBpdCB3YXMgc3VjY2Vzc2Z1bCwgYmVn aW5zIHNlbmRpbmcgdGhlIGV2ZW50CiAgIG5vdGlmaWNhdGlvbnMgdG8gdGhlIE5FVENPTkYgY2xp ZW50IGFzIHRoZSBldmVudHMgb2NjdXIgd2l0aGluIHRoZQogICBzeXN0ZW0uICBUaGVzZSBldmVu dCBub3RpZmljYXRpb25zIHdpbGwgY29udGludWUgdG8gYmUgc2VudCB1bnRpbAogICBlaXRoZXIg dGhlIE5FVENPTkYgc2Vzc2lvbiBpcyB0ZXJtaW5hdGVkIG9yIaXMgc29tZXRoaW5nIHRoYXQgaGFwcGVucyB3aGljaCBtYXkg YmUgb2YgaW50ZXJlc3QgLQogICAgICBhIGNvbmZpZ3VyYXRpb24gY2hhbmdlLCBhIGZhdWx0LCBh IGNoYW5nZSBpbiBzdGF0dXMsIGNyb3NzaW5nIGEKICAgICAgdGhyZXNob2xkLCBvciBhbiBleHRl cm5hbCBpbnB1dCB0byB0aGUgc3lzdGVtLCBmb3IgZXhhbXBsZS4gIE9mdGVuCiAgICAgIHRoaXMg cmVzdWx0cyBpbiBhbiBhc3luY2hyb25vdXMgbWVzc2FnZSwgc29tZXRpbWVzIHJlZmVycmVkIHRv IGFzCiAgICAgIGEgbm90aWZpY2F0aW9uIG9yIGV2ZW50IG5vdGlmaWNhdGlvbiwgYmVpbmcgc2Vu dCB0byBpbnRlcmVzdGVkCiAgICAgIHBhcnRpZXMgdG8gbm90aWZ5IHRoZW0gdGhhdCB0aGlzIGV2 ZW50IGhhcyBvY2N1cnJlZC4KCiAgIFJlcGxheTogIFRoZSBhYmlsaXR5IHRvIHNlbmQvcmUtc2Vu ZCBwcmV2aW91c2x5IGxvZ2dlZCBub3RpZmljYXRpb25zCiAgICAgIHVwb24gcmVxdWVzdC4gIFRo ZXNlIG5vdGlmaWNhdGlvbnMgYXJlIHNlbnQgYXN5bmNocm9ub3VzbHkuICBUaGlzCiAgICAgIGZl YXR1cmUgaXMgaW1wbGVtZW50ZWQgYnkgdGhlIE5FVENPTkYgc2VydmVyIGFuZCBpbnZva2VkIGJ5 IHRoZQogICAgICBORVRDT05GIGNsaWVudC4KCiAgIFN0cmVhbTogIEFuIGV2ZW50IHN0cmVhbSBp cyBhIHNldCBvZiBldmVudCBub3RpZmljYXRpb25zIG1hdGNoaW5nCiAgICAgIHNvbWUgZm9yd2Fy ZGluZyBjcml0ZXJpYSBhbmQgYXZhaWxhYmxlIHRvIE5FVENPTkYgY2xpZW50cyBmb3IKICAgICAg c3Vic2NyaXB0aW9uLgoKICAgRmlsdGVyOiAgQSBwYXJhbWV0ZXIgdGhhdCBpbmRpY2F0ZXMgd2hp Y2ggc3Vic2V0IG9mIGFsbCBwb3NzaWJsZQogICAgICBldmVudHMgYXJlIG9mIGludGVyZXN0LiAg QSBmaWx0ZXIgaXMgZGVmaW5lZCBhcyBvbmUgb3IgbW9yZSBmaWx0ZXIKICAgICAgZWxlbWVudCBb TkVUQ09ORl0sIHdoaWNoIGVhY2ggaWRlbnRpZmllcyBhIHBvcnRpb24gb2YgdGhlIG92ZXJhbGwK ICAgICAgZmlsdGVyLgoKMS4yLiAgTW90aXZhdGlvbgoKICAgVGhlIG1vdGl2YXRpb24gZm9yIHRo aXMgd29yayBpcyB0byBlbmFibGUgdGhlIHNlbmRpbmcgb2YgYXN5bmNocm9ub3VzCiAgIG1lc3Nh Z2VzIHRoYXQgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgZGF0YSBtb2RlbCAoY29udGVudCkgYW5k CiAgIHNlY3VyaXR5IG1vZGVsIHVzZWQgd2l0aGluIGEgTkVUQ09ORiBpbXBsZW1lbnRhdGlvbi4K CiAgIFRoZSBzY29wZSBvZiB0aGUgd29yayBhaW1zIG1lZXRpbmcgdGhlIGZvbGxvd2luZyBvcGVy YXRpb25hbCBuZWVkczoKCiAgIG8gIEluaXRpYWwgcmVsZWFzZSBzaG91bGQgZW5zdXJlIGl0IHN1 cHBvcnRzIG5vdGlmaWNhdGlvbnMgaW4gc3VwcG9ydAogICAgICBvZiBjb25maWd1cmF0aW9uIG9w ZXJhdGlvbnMuCgogICBvICBJdCBzaG91bGQgYmUgcG9zc2libGUgdG8gdXNlIHRoZSBzYW1lIGRh dGEgbW9kZWwgZm9yIG5vdGlmaWNhdGlvbnMKICAgICAgYXMgZm9yIGNvbmZpZ3VyYXRpb24gb3Bl cmF0aW9ucy4KCiAgIG8gIFNvbHV0aW9uIHNob3VsZCBzdXBwb3J0IGEgcmVhc29uYWJsZSBtZXNz YWdlIHNpemUgbGltaXQgKGkuZS4sIG5vdAogICAgICB0b28gc2hvcnQpCgogICBvICBUaGUgbm90 aWZpY2F0aW9ucyBzaG91bGQgYmUgY2FycmllZCBvdmVyIGEgY29ubmVjdGlvbi1vcmllbnRlZAog ICAgICBkZWxpdmVyeSBtZWNoYW5pc20uCgogICBvICBBIHN1YnNjcmlwdGlvbiBtZWNoYW5pc20g Zm9yIG5vdGlmaWNhdGlvbnMgc2hvdWxkIGJlIHByb3ZpZGVkLgogICAgICBUaGlzIHRha2VzIGlu dG8gYWNjb3VudCB0aGF0IGEgTkVUQ09ORiBzZXJ2ZXIgZG9lcyBub3Qgc2VuZAogICAgICBub3Rp ZmljYXRpb25zIGJlZm9yZSBiZWluZyBhc2tlZCB0byBkbyBzbyBhbmQgdGhhdCBpdCBpcyB0aGUK ICAgICAgTkVUQ09ORiBjbGllbnQgd2hvIGluaXRpYXRlcyB0aGUgZmxvdyBvZiBub3RpZmljYXRp b25zLgoKICAgbyAgQSBmaWx0ZXJpbmcgbWVjaGFuaXNtIGZvciBzZW5kaW5nIG5vdGlmaWNhdGlv bnMgc2hvdWxkIGJlIHB1dCBpbgogICAgICBwbGFjZSB3aXRoaW4gdGhlIE5FVENPTkYgc2VydmVy LgoKICAgbyAgVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBhIG5vdGlmaWNhdGlvbiBzaG91 bGQgYmUgc3VmZmljaWVudAogICAgICBzbyB0aGF0IGl0IGNhbiBiZSBhbmFseXplZCBpbmRlcGVu ZGVudCBvZiB0aGUgdHJhbnNwb3J0IG1lY2hhbmlzbS4KICAgICAgSW4gb3RoZXIgd29yZHMgdGhl IGRhdGEgY29udGVudCBmdWxseSBkZXNjcmliZXMgYSBub3RpZmljYXRpb247CiAgICAgIHByb3Rv Y29sIGluZm9ybWF0aW9uIGlzIG5vdCBuZWVkZWQgdG8gdW5kZXJzdGFuZCBhIG5vdGlmaWNhdGlv bi4KCiAgIG8gIFRoZSBzZXJ2ZXIgc2hvdWxkIGhhdmUgdGhlIGNhcGFiaWxpdHkgdG8gcmVwbGF5 IGxvY2FsbHkgbG9nZ2VkCiAgICAgIG5vdGlmaWNhdGlvbnMuCgoxLjMuICBFdmVudCBOb3RpZmlj YXRpb25zIGluIE5FVENPTkYKCiAgIFRoaXMgbWVtbyBkZWZpbmVzIGEgbWVjaGFuaXNtIHdoZXJl YnkgdGhlIE5FVENPTkYgY2xpZW50IGluZGljYXRlcwogICBpbnRlcmVzdCBpbiByZWNlaXZpbmcg ZXZlbnQgbm90aWZpY2F0aW9ucyBmcm9tIGEgTkVUQ09ORiBzZXJ2ZXIgYnkKICAgY3JlYXRpbmcg YSBzdWJzY3JpcHRpb24gdG8gcmVjZWl2ZSBldmVudCBub3RpZmljYXRpb25zLiAgVGhlIE5FVENP TkYKICAgc2VydmVyIHJlcGxpZXMgdG8gaW5kaWNhdGUgd2hldGhlciB0aGUgc3Vic2NyaXB0aW9u IHJlcXVlc3Qgd2FzCiAgIHN1Y2Nlc3NmdWwgYW5kLCBpZiBpdCB3YXMgc3VjY2Vzc2Z1bCwgYmVn aW5zIHNlbmRpbmcgdGhlIGV2ZW50CiAgIG5vdGlmaWNhdGlvbnMgdG8gdGhlIE5FVENPTkYgY2xp ZW50IGFzIHRoZSBldmVudHMgb2NjdXIgd2l0aGluIHRoZQogICBzeXN0ZW0uICBUaGVzZSBldmVu dCBub3RpZmljYXRpb25zIHdpbGwgY29udGludWUgdG8gYmUgc2VudCB1bnRpbAogICBlaXRoZXIg dGhlIE5FVENPTkYgc2Vzc2lvbiBpcyB0ZXJtaW5hdGVHRoZSBzdWJzY3JpcHRpb24KICAg dGVybWluYXRlcyBmb3Igc29tZSBvdGhlciByZWFzb24uICBUaGUgZXZlbnQgbm90aWZpY2F0aW9u CiAgIHN1YnNjcmlwdGlvbiBhbGxvd3MgYSBudW1iZXIgb2Ygb3B0aW9ucyB0byBlbmFibGUgdGhl IE5FVENPTkYgY2xpZW50CiAgIHRvIHNwZWNpZnkgd2hpY2ggZXZlbnRzIGFyZSBvZiBpbnRlcmVz dC4gIFRoZXNlIGFyZSBzcGVjaWZpZWQgd2hlbgogICB0aGUgc3Vic2NyaXB0aW9uIGlzIGNyZWF0 ZWQuICBOb3RlIHRoYXQgYSBzdWJzY3JpcHRpb24gY2Fubm90IGJlCiAgIG1vZGlmaWVkIG9uY2Ug Y3JlYXRlZC4KCiAgIFRoZSBORVRDT05GIHNlcnZlciBNVVNUIGFjY2VwdCBhbmQgcHJvY2VzcyB0 aGUgJmx0O2Nsb3NlLXNlc3Npb24mZ3Q7CiAgIG9wZXJhdGlvbiwgZXZlbiB3aGlsZSB0aGUgbm90 aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiBpcyBhY3RpdmUuICBUaGUKICAgTkVUQ09ORiBzZXJ2ZXIg TUFZIGFjY2VwdCBhbmQgcHJvY2VzcyBvdGhlciBjb21tYW5kcywgb3RoZXJ3aXNlIHRoZXkKICAg d2lsbCBiZSByZWplY3RlZCBhbmQgdGhlIHNlcnZlciBNVVNUIHNlbmQgYSAncmVzb3VyY2UtZGVu aWVkJyBlcnJvci4KICAgQSBORVRDT05GIHNlcnZlciBhZHZlcnRpc2VzIHN1cHBvcnQgb2YgdGhl IGFiaWxpdHkgdG8gcHJvY2VzcyBvdGhlcgogICBjb21tYW5kcyB2aWEgdGhlIGludGVybGVhdmUg Y2FwYWJpbGl0eS4KCjIuICBOb3RpZmljYXRpb24tUmVsYXRlZCBPcGVyYXRpb25zCgoyLjEuICBT dWJzY3JpYmluZyB0byBSZWNlaXZlIEV2ZW50IE5vdGlmaWNhdGlvbnMKCiAgIFRoZSBldmVudCBu b3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIGlzIGluaXRpYXRlZCBieSB0aGUgTkVUQ09ORgogICBj bGllbnQgYW5kIHJlc3BvbmRlZCB0byBieSB0aGUgTkVUQ09ORiBzZXJ2ZXIuICBBIHN1YnNjcmlw dGlvbiBpcwogICBib3VuZCB0byBhIHNpbmdsZSBzdHJlYW0gZm9yIHRoZSBsaWZldGltZSBvZiB0 aGUgc3Vic2NyaXB0aW9uLiAgV2hlbgogICB0aGUgZXZlbnQgbm90aWZpY2F0aW9uIHN1YnNjcmlw dGlvbiBpcyBjcmVhdGVkLCB0aGUgZXZlbnRzIG9mCiAgIGludGVyZXN0IGFyZSBzcGVjaWZpZWQu CgogICBDb250ZW50IGZvciBhbiBldmVudCBub3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIGNhbiBi ZSBzZWxlY3RlZCBieQogICBhcHBseWluZyB1c2VyLXNwZWNpZmllZCBmaWx0ZXJzLgoKMi4xLjEu ICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsKCiAgIERlc2NyaXB0aW9uOgoKICAgICAgVGhp cyBvcGVyYXRpb24gaW5pdGlhdGVzIGFuIGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24g d2hpY2gKICAgICAgd2lsbCBzZW5kIGFzeW5jaHJvbm91cyBldmVudCBub3RpZmljYXRpb25zIHRv IHRoZSBpbml0aWF0b3Igb2YgdGhlCiAgICAgIGNvbW1hbmQgdW50aWwgdGhlIHN1YnNjcmlwdGlv biB0ZXJtaW5hdGVzLgoKICAgUGFyYW1ldGVyczoKCiAgICAgIFN0cmVhbToKCiAgICAgICAgIEFu IG9wdGlvbmFsIHBhcmFtZXRlciwgJmx0O3N0cmVhbSZndDssIHRoYXQgaW5kaWNhdGVzIHdoaWNo IHN0cmVhbSBvZgogICAgICAgICBldmVudHMgaXMgb2YgaW50ZXJlc3QuICBJZiBub3QgcHJlc2Vu dCwgZXZlbnRzIGluIHRoZSBkZWZhdWx0CiAgICAgICAgIE5FVENPTkYgc3RyZWFtIHdpbGwgYmUg c2VudC4KCiAgICAgIEZpbHRlcjoKCiAgICAgICAgIEFuIG9wdGlvbmFsIHBhcmFtZXRlciwgJmx0 O2ZpbHRlciZndDssIHRoYXQgaW5kaWNhdGVzIHdoaWNoIHN1YnNldCBvZgogICAgICAgICBhbGwg cG9zc2libGUgZXZlbnRzIGlzIG9mIGludGVyZXN0LiAgVGhlIGZvcm1hdCBvZiB0aGlzCiAgICAg ICAgIHBhcmFtZXRlciBpcyB0aGUgc2FtZSBhcyB0aGF0IG9mIHRoZSBmaWx0ZXIgcGFyYW1ldGVy IGluIHRoZQogICAgICAgICBORVRDT05GIHByb3RvY29sIG9wZXJhdGlvbnMuICBJZiBub3QgcHJl c2VudCwgYWxsIGV2ZW50cyBub3QKICAgICAgICAgcHJlY2x1ZGVkIGJ5IG90aGVyIHBhcmFtZXRl cnMgd2lsbCBiZSBzZW50LiAgU2VlIHNlY3Rpb24gMy42CiAgICAgICAgIGZvciBtb3JlIGluZm9y bWF0aW9uIG9uIGZpbHRlcnMuCgogICAgICBTdGFydCBUaW1lOgoKICAgICAgICAgQSBwYXJhbWV0 ZXIsICZsdDtzdGFydFRpbWUmZ3Q7LCB1c2VkIHRvIHRyaWdnZXIgdGhlIHJlcGxheSBmZWF0dXJl CiAgICAgICAgIGFuZCBpbmRpY2F0ZSB0aGF0IHRoZSByZXBsYXkgc2hvdWxkIHN0YXJ0IGF0IHRo ZSB0aW1lCiAgICAgICAgIHNwZWNpZmllZC4gIElmICZsdDtzdGFydFRpbWUmZ3Q7IGlzIG5vdCBw cmVzZW50LCB0aGlzIGlzIG5vdCBhIHJlcGxheQogICAgICAgICBzdWJzY3JpcHRpb24uICBJdCBp cyBub3QgdmFsaWQgdG8gc3BlY2lmeSBzdGFydCB0aW1lcyB0aGF0IGFyZQogICAgICAgICBsYXRl ciB0aGFuIHRoZSBjdXJyZW50IHRpbWUuICBJZiB0aGUgJmx0O3N0YXJ0VGltZSZndDsgc3BlY2lm aWVkIGlzCiAgICAgICAgIGVhcmxpZXIgdGhhbiB0aGUgbG9nIGNhbiBzdXBwb3J0LCB0aGUgcmVw bGF5IHdpbGwgYmVnaW4gd2l0aAogICAgICAgICB0aGUgZWFybGllc3QgYXZhaWxhYmxlIG5vdGlm aWNhdGlvbi4gIFRoaXMgcGFyYW1ldGVyIGlzIG9mIHR5cGUKICAgICAgICAgPHN0cmlrZT48Zm9u dCBjb2xvcj0ncmVkJz5kYXRlVGltZS48L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAgIDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJz5kYXRlVGltZSBhbmQgY29tcGxpYW50IHRvIFtSRkMzMzM5XS4g IEltcGxlbWVudGF0aW9ucyBtdXN0CiAgICAgICAgIHN1cHBvcnQgdGltZSB6b25lcy48L2ZvbnQ+ PC9zdHJvbmc+CgogICAgICBTdG9wIFRpbWU6CgogICAgICAgICBBbiBvcHRpb25hbCBwYXJhbWV0 ZXIsICZsdDtzdG9wVGltZSZndDssIHVzZWQgd2l0aCB0aGUgb3B0aW9uYWwKICAgICAgICAgcmVw bGF5IGZlYXR1cmUgdG8gaW5kaWNhdGUgdGhlIG5ld2VzdCBub3RpZmljYXRpb25zIG9mCiAgICAg ICAgIGludGVyZXN0LiAgSWYgc3RvcCB0aW1lIGlzIG5vdCBwcmVzZW50LCB0aGUgkIG9yIHRoZSBzdWJzY3JpcHRpb24KICAg dGVybWluYXRlcyBmb3Igc29tZSBvdGhlciByZWFzb24uICBUaGUgZXZlbnQgbm90aWZpY2F0aW9u CiAgIHN1YnNjcmlwdGlvbiBhbGxvd3MgYSBudW1iZXIgb2Ygb3B0aW9ucyB0byBlbmFibGUgdGhl IE5FVENPTkYgY2xpZW50CiAgIHRvIHNwZWNpZnkgd2hpY2ggZXZlbnRzIGFyZSBvZiBpbnRlcmVz dC4gIFRoZXNlIGFyZSBzcGVjaWZpZWQgd2hlbgogICB0aGUgc3Vic2NyaXB0aW9uIGlzIGNyZWF0 ZWQuICBOb3RlIHRoYXQgYSBzdWJzY3JpcHRpb24gY2Fubm90IGJlCiAgIG1vZGlmaWVkIG9uY2Ug Y3JlYXRlZC4KCiAgIFRoZSBORVRDT05GIHNlcnZlciBNVVNUIGFjY2VwdCBhbmQgcHJvY2VzcyB0 aGUgJmx0O2Nsb3NlLXNlc3Npb24mZ3Q7CiAgIG9wZXJhdGlvbiwgZXZlbiB3aGlsZSB0aGUgbm90 aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiBpcyBhY3RpdmUuICBUaGUKICAgTkVUQ09ORiBzZXJ2ZXIg TUFZIGFjY2VwdCBhbmQgcHJvY2VzcyBvdGhlciBjb21tYW5kcywgb3RoZXJ3aXNlIHRoZXkKICAg d2lsbCBiZSByZWplY3RlZCBhbmQgdGhlIHNlcnZlciBNVVNUIHNlbmQgYSAncmVzb3VyY2UtZGVu aWVkJyBlcnJvci4KICAgQSBORVRDT05GIHNlcnZlciBhZHZlcnRpc2VzIHN1cHBvcnQgb2YgdGhl IGFiaWxpdHkgdG8gcHJvY2VzcyBvdGhlcgogICBjb21tYW5kcyB2aWEgdGhlIGludGVybGVhdmUg Y2FwYWJpbGl0eS4KCjIuICBOb3RpZmljYXRpb24tUmVsYXRlZCBPcGVyYXRpb25zCgoyLjEuICBT dWJzY3JpYmluZyB0byBSZWNlaXZlIEV2ZW50IE5vdGlmaWNhdGlvbnMKCiAgIFRoZSBldmVudCBu b3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIGlzIGluaXRpYXRlZCBieSB0aGUgTkVUQ09ORgogICBj bGllbnQgYW5kIHJlc3BvbmRlZCB0byBieSB0aGUgTkVUQ09ORiBzZXJ2ZXIuICBBIHN1YnNjcmlw dGlvbiBpcwogICBib3VuZCB0byBhIHNpbmdsZSBzdHJlYW0gZm9yIHRoZSBsaWZldGltZSBvZiB0 aGUgc3Vic2NyaXB0aW9uLiAgV2hlbgogICB0aGUgZXZlbnQgbm90aWZpY2F0aW9uIHN1YnNjcmlw dGlvbiBpcyBjcmVhdGVkLCB0aGUgZXZlbnRzIG9mCiAgIGludGVyZXN0IGFyZSBzcGVjaWZpZWQu CgogICBDb250ZW50IGZvciBhbiBldmVudCBub3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIGNhbiBi ZSBzZWxlY3RlZCBieQogICBhcHBseWluZyB1c2VyLXNwZWNpZmllZCBmaWx0ZXJzLgoKMi4xLjEu ICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsKCiAgIERlc2NyaXB0aW9uOgoKICAgICAgVGhp cyBvcGVyYXRpb24gaW5pdGlhdGVzIGFuIGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24g d2hpY2gKICAgICAgd2lsbCBzZW5kIGFzeW5jaHJvbm91cyBldmVudCBub3RpZmljYXRpb25zIHRv IHRoZSBpbml0aWF0b3Igb2YgdGhlCiAgICAgIGNvbW1hbmQgdW50aWwgdGhlIHN1YnNjcmlwdGlv biB0ZXJtaW5hdGVzLgoKICAgUGFyYW1ldGVyczoKCiAgICAgIFN0cmVhbToKCiAgICAgICAgIEFu IG9wdGlvbmFsIHBhcmFtZXRlciwgJmx0O3N0cmVhbSZndDssIHRoYXQgaW5kaWNhdGVzIHdoaWNo IHN0cmVhbSBvZgogICAgICAgICBldmVudHMgaXMgb2YgaW50ZXJlc3QuICBJZiBub3QgcHJlc2Vu dCwgZXZlbnRzIGluIHRoZSBkZWZhdWx0CiAgICAgICAgIE5FVENPTkYgc3RyZWFtIHdpbGwgYmUg c2VudC4KCiAgICAgIEZpbHRlcjoKCiAgICAgICAgIEFuIG9wdGlvbmFsIHBhcmFtZXRlciwgJmx0 O2ZpbHRlciZndDssIHRoYXQgaW5kaWNhdGVzIHdoaWNoIHN1YnNldCBvZgogICAgICAgICBhbGwg cG9zc2libGUgZXZlbnRzIGlzIG9mIGludGVyZXN0LiAgVGhlIGZvcm1hdCBvZiB0aGlzCiAgICAg ICAgIHBhcmFtZXRlciBpcyB0aGUgc2FtZSBhcyB0aGF0IG9mIHRoZSBmaWx0ZXIgcGFyYW1ldGVy IGluIHRoZQogICAgICAgICBORVRDT05GIHByb3RvY29sIG9wZXJhdGlvbnMuICBJZiBub3QgcHJl c2VudCwgYWxsIGV2ZW50cyBub3QKICAgICAgICAgcHJlY2x1ZGVkIGJ5IG90aGVyIHBhcmFtZXRl cnMgd2lsbCBiZSBzZW50LiAgU2VlIHNlY3Rpb24gMy42CiAgICAgICAgIGZvciBtb3JlIGluZm9y bWF0aW9uIG9uIGZpbHRlcnMuCgogICAgICBTdGFydCBUaW1lOgoKICAgICAgICAgQSBwYXJhbWV0 ZXIsICZsdDtzdGFydFRpbWUmZ3Q7LCB1c2VkIHRvIHRyaWdnZXIgdGhlIHJlcGxheSBmZWF0dXJl CiAgICAgICAgIGFuZCBpbmRpY2F0ZSB0aGF0IHRoZSByZXBsYXkgc2hvdWxkIHN0YXJ0IGF0IHRo ZSB0aW1lCiAgICAgICAgIHNwZWNpZmllZC4gIElmICZsdDtzdGFydFRpbWUmZ3Q7IGlzIG5vdCBw cmVzZW50LCB0aGlzIGlzIG5vdCBhIHJlcGxheQogICAgICAgICBzdWJzY3JpcHRpb24uICBJdCBp cyBub3QgdmFsaWQgdG8gc3BlY2lmeSBzdGFydCB0aW1lcyB0aGF0IGFyZQogICAgICAgICBsYXRl ciB0aGFuIHRoZSBjdXJyZW50IHRpbWUuICBJZiB0aGUgJmx0O3N0YXJ0VGltZSZndDsgc3BlY2lm aWVkIGlzCiAgICAgICAgIGVhcmxpZXIgdGhhbiB0aGUgbG9nIGNhbiBzdXBwb3J0LCB0aGUgcmVw bGF5IHdpbGwgYmVnaW4gd2l0aAogICAgICAgICB0aGUgZWFybGllc3QgYXZhaWxhYmxlIG5vdGlm aWNhdGlvbi4gIFRoaXMgcGFyYW1ldGVyIGlzIG9mIHR5cGUKICAgICAgICAgPHN0cmlrZT48Zm9u dCBjb2xvcj0ncmVkJz5kYXRlVGltZS48L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAgIDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJz5kYXRlVGltZSBhbmQgY29tcGxpYW50IHRvIFtSRkMzMzM5XS4g IEltcGxlbWVudGF0aW9ucyBtdXN0CiAgICAgICAgIHN1cHBvcnQgdGltZSB6b25lcy48L2ZvbnQ+ PC9zdHJvbmc+CgogICAgICBTdG9wIFRpbWU6CgogICAgICAgICBBbiBvcHRpb25hbCBwYXJhbWV0 ZXIsICZsdDtzdG9wVGltZSZndDssIHVzZWQgd2l0aCB0aGUgb3B0aW9uYWwKICAgICAgICAgcmVw bGF5IGZlYXR1cmUgdG8gaW5kaWNhdGUgdGhlIG5ld2VzdCBub3RpZmljYXRpb25zIG9mCiAgICAg ICAgIGludGVyZXN0LiAgSWYgc3RvcCB0aW1lIGlzIG5vdCBwcmVzZW50LCbm90aWZpY2F0 aW9ucyB3aWxsCiAgICAgICAgIGNvbnRpbnVlIHVudGlsIHRoZSBzdWJzY3JpcHRpb24gaXMgdGVy bWluYXRlZC4gIE11c3QgYmUgdXNlZAogICAgICAgICB3aXRoIGFuZCBiZSBsYXRlciB0aGFuICZs dDtzdGFydFRpbWUmZ3Q7LiAgVmFsdWVzIG9mICZsdDtzdG9wVGltZSZndDsgaW4KICAgICAgICAg dGhlIGZ1dHVyZSBhcmUgdmFsaWQuICBUaGlzIHBhcmFtZXRlciBpcyBvZiB0eXBlIDxzdHJpa2U+ PGZvbnQgY29sb3I9J3JlZCc+ZGF0ZVRpbWUuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbic+ZGF0ZVRpbWUgYW5kCiAgICAgICAgIGNvbXBsaWFudCB0byBbUkZDMzMz OV0uICBJbXBsZW1lbnRhdGlvbnMgbXVzdCBzdXBwb3J0IHRpbWUKICAgICAgICAgem9uZXMuPC9m b250Pjwvc3Ryb25nPgoKICAgUG9zaXRpdmUgUmVzcG9uc2U6CgogICAgICBJZiB0aGUgTkVUQ09O RiBzZXJ2ZXIgY2FuIHNhdGlzZnkgdGhlIHJlcXVlc3QsIHRoZSBzZXJ2ZXIgc2VuZHMgYW4KICAg ICAgJmx0O29rJmd0OyBlbGVtZW50LgoKICAgTmVnYXRpdmUgUmVzcG9uc2U6CgogICAgICBBbiAm bHQ7cnBjLWVycm9yJmd0OyBlbGVtZW50IGlzIGluY2x1ZGVkIHdpdGhpbiB0aGUgJmx0O3JwYy1y ZXBseSZndDsgaWYgdGhlCiAgICAgIHJlcXVlc3QgY2Fubm90IGJlIGNvbXBsZXRlZCBmb3IgYW55 IHJlYXNvbi4gIFN1YnNjcmlwdGlvbiByZXF1ZXN0cwogICAgICB3aWxsIGZhaWwgaWYgYSBmaWx0 ZXIgd2l0aCBpbnZhbGlkIHN5bnRheCBpcyBwcm92aWRlZCBvciBpZiB0aGUKICAgICAgbmFtZSBv ZiBhIG5vbi1leGlzdGVudCBzdHJlYW0gaXMgcHJvdmlkZWQuCgogICAgICBJZiBhICZsdDtzdG9w VGltZSZndDsgaXMgc3BlY2lmaWVkIGluIGEgcmVxdWVzdCB3aXRob3V0IGhhdmluZyBzcGVjaWZp ZWQKICAgICAgYSAmbHQ7c3RhcnRUaW1lJmd0OywgdGhlIGZvbGxvd2luZyBlcnJvciBpcyByZXR1 cm5lZDoKCiAgICAgICAgIFRhZzogbWlzc2luZy1lbGVtZW50CgogICAgICAgICBFcnJvci10eXBl OiBwcm90b2NvbAoKICAgICAgICAgU2V2ZXJpdHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZv OiAmbHQ7YmFkLWVsZW1lbnQmZ3Q7OiBzdGFydFRpbWUKCiAgICAgICAgIERlc2NyaXB0aW9uOiBB biBleHBlY3RlZCBlbGVtZW50IGlzIG1pc3NpbmcuCgogICAgICBJZiB0aGUgb3B0aW9uYWwgcmVw bGF5IGZlYXR1cmUgaXMgcmVxdWVzdGVkIGJ1dCBpdCBpcyBub3QKICAgICAgc3VwcG9ydGVkIGJ5 IHRoZSBORVRDT05GIHNlcnZlciwgdGhlIGZvbGxvd2luZyBlcnJvciBpcyByZXR1cm5lZDoKCiAg ICAgICAgIFRhZzogb3BlcmF0aW9uLWZhaWxlZAoKICAgICAgICAgRXJyb3ItdHlwZTogcHJvdG9j b2wKICAgICAgICAgU2V2ZXJpdHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZvOiBub25lCgog ICAgICAgICBEZXNjcmlwdGlvbjogUmVxdWVzdCBjb3VsZCBub3QgYmUgY29tcGxldGVkIGJlY2F1 c2UgdGhlCiAgICAgICAgIHJlcXVlc3RlZCBvcGVyYXRpb24gZmFpbGVkIGZvciBzb21lIHJlYXNv biBub3QgY292ZXJlZCBieSBhbnkKICAgICAgICAgb3RoZXIgZXJyb3IgY29uZGl0aW9uCgogICAg ICBJZiBhICZsdDtzdG9wVGltZSZndDsgaXMgcmVxdWVzdGVkIHdoaWNoIGlzIGVhcmxpZXIgdGhl biB0aGUgc3BlY2lmaWVkCiAgICAgICZsdDtzdGFydFRpbWUmZ3Q7LCB0aGUgZm9sbG93aW5nIGVy cm9yIGlzIHJldHVybmVkOgoKICAgICAgICAgVGFnOiBiYWQtZWxlbWVudAoKICAgICAgICAgRXJy b3ItdHlwZTogcHJvdG9jb2wKCiAgICAgICAgIFNldmVyaXR5OiBlcnJvcgoKICAgICAgICAgRXJy b3ItaW5mbzogJmx0O2JhZC1lbGVtZW50Jmd0Ozogc3RvcFRpbWUKCiAgICAgICAgIERlc2NyaXB0 aW9uOiBBbiBlbGVtZW50IHZhbHVlIGlzIG5vdCBjb3JyZWN0OyBlLmcuLCB3cm9uZyB0eXBlLAog ICAgICAgICBvdXQgb2YgcmFuZ2UsIHBhdHRlcm4gbWlzbWF0Y2guCgogICAgICBJZiBhICZsdDtz dGFydFRpbWUmZ3Q7IGlzIHJlcXVlc3RlZCB3aGljaCBpcyBsYXRlciB0aGVuIHRoZSBjdXJyZW50 CiAgICAgIHRpbWUsIHRoZSBmb2xsb3dpbmcgZXJyb3IgaXMgcmV0dXJuZWQ6CgogICAgICAgICBU YWc6IGJhZC1lbGVtZW50CgogICAgICAgICBFcnJvci10eXBlOiBwcm90b2NvbAoKICAgICAgICAg U2V2ZXJpdHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZvOiAmbHQ7YmFkLWVsZW1lbnQmZ3Q7 OiBzdGFydFRpbWUKCiAgICAgICAgIERlc2NyaXB0aW9uOiBBbiBlbGVtZW50IHZhbHVlIGlzIG5v dCBjb3JyZWN0OyBlLmcuLCB3cm9uZyB0eXBlLAogICAgICAgICBvdXQgb2YgcmFuZ2UsIHBhdHRl cm4gbWlzbWF0Y2guCgoyLjEuMS4xLiAgVXNhZ2UgRXhhbXBsZQoKICAgVGhlIGZvbGxvd2luZyBk ZW1vbnN0cmF0ZXMgY3JlYXRpbmcgYSBzaW1wbGUgc3Vic2NyaXB0aW9uLiAgTW9yZQogICBjb21w bGV4IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiBzZWN0aW9uIDUuCgogICAmbHQ7bmV0Y29uZjpy cGMgbWVzc2FnZS1pZD0iMTAxIgogICAgICAgICB4bWxuczpuZXRjb25mPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiLyZndDsKICAgICAgICZsdDtjcmVhdGUtc3Vic2Ny aXB0aW9uCiAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpu b3RpZmljYXRpb246MS4wIiZndDsKICAgICAgICZsdDsvY3JlYXRlLXN1YnNjcmlwdGlvbiZndDsK ICAgJmx0Oy9uZXRjb25mOnJwYyZndDsKCjIuMi4gIFNlbmRpbmcgRXZlbnQgTm90aWZpY2F0aW9u cwoKICAgT25jZSB0aGUgc3Vic2NyaXB0aW9uIGhhcyBiZWVuIHNldCB1cCwgdGhlIE5FVENPTkYg c2VydmVyIHNlbmRzIHRoZQogICBldmVudCBub3RpZmljYXRpb25zIGFzeW5jaHJvbm91c2x5IG92 ZXIgdGhlIGNvbm5lY3Rpb24uCgoyLjIuMS4gICZsdDtub3RpZmljYXRpb24mZ3Q7CgogICBEZXNj cmlwdGlvbjoKCiAgICAgIEFuIGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBzZW50IHRvIHRoZSBjbGll bnB0aGUgbm90aWZpY2F0 aW9ucyB3aWxsCiAgICAgICAgIGNvbnRpbnVlIHVudGlsIHRoZSBzdWJzY3JpcHRpb24gaXMgdGVy bWluYXRlZC4gIE11c3QgYmUgdXNlZAogICAgICAgICB3aXRoIGFuZCBiZSBsYXRlciB0aGFuICZs dDtzdGFydFRpbWUmZ3Q7LiAgVmFsdWVzIG9mICZsdDtzdG9wVGltZSZndDsgaW4KICAgICAgICAg dGhlIGZ1dHVyZSBhcmUgdmFsaWQuICBUaGlzIHBhcmFtZXRlciBpcyBvZiB0eXBlIDxzdHJpa2U+ PGZvbnQgY29sb3I9J3JlZCc+ZGF0ZVRpbWUuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbic+ZGF0ZVRpbWUgYW5kCiAgICAgICAgIGNvbXBsaWFudCB0byBbUkZDMzMz OV0uICBJbXBsZW1lbnRhdGlvbnMgbXVzdCBzdXBwb3J0IHRpbWUKICAgICAgICAgem9uZXMuPC9m b250Pjwvc3Ryb25nPgoKICAgUG9zaXRpdmUgUmVzcG9uc2U6CgogICAgICBJZiB0aGUgTkVUQ09O RiBzZXJ2ZXIgY2FuIHNhdGlzZnkgdGhlIHJlcXVlc3QsIHRoZSBzZXJ2ZXIgc2VuZHMgYW4KICAg ICAgJmx0O29rJmd0OyBlbGVtZW50LgoKICAgTmVnYXRpdmUgUmVzcG9uc2U6CgogICAgICBBbiAm bHQ7cnBjLWVycm9yJmd0OyBlbGVtZW50IGlzIGluY2x1ZGVkIHdpdGhpbiB0aGUgJmx0O3JwYy1y ZXBseSZndDsgaWYgdGhlCiAgICAgIHJlcXVlc3QgY2Fubm90IGJlIGNvbXBsZXRlZCBmb3IgYW55 IHJlYXNvbi4gIFN1YnNjcmlwdGlvbiByZXF1ZXN0cwogICAgICB3aWxsIGZhaWwgaWYgYSBmaWx0 ZXIgd2l0aCBpbnZhbGlkIHN5bnRheCBpcyBwcm92aWRlZCBvciBpZiB0aGUKICAgICAgbmFtZSBv ZiBhIG5vbi1leGlzdGVudCBzdHJlYW0gaXMgcHJvdmlkZWQuCgogICAgICBJZiBhICZsdDtzdG9w VGltZSZndDsgaXMgc3BlY2lmaWVkIGluIGEgcmVxdWVzdCB3aXRob3V0IGhhdmluZyBzcGVjaWZp ZWQKICAgICAgYSAmbHQ7c3RhcnRUaW1lJmd0OywgdGhlIGZvbGxvd2luZyBlcnJvciBpcyByZXR1 cm5lZDoKCiAgICAgICAgIFRhZzogbWlzc2luZy1lbGVtZW50CgogICAgICAgICBFcnJvci10eXBl OiBwcm90b2NvbAoKICAgICAgICAgU2V2ZXJpdHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZv OiAmbHQ7YmFkLWVsZW1lbnQmZ3Q7OiBzdGFydFRpbWUKCiAgICAgICAgIERlc2NyaXB0aW9uOiBB biBleHBlY3RlZCBlbGVtZW50IGlzIG1pc3NpbmcuCgogICAgICBJZiB0aGUgb3B0aW9uYWwgcmVw bGF5IGZlYXR1cmUgaXMgcmVxdWVzdGVkIGJ1dCBpdCBpcyBub3QKICAgICAgc3VwcG9ydGVkIGJ5 IHRoZSBORVRDT05GIHNlcnZlciwgdGhlIGZvbGxvd2luZyBlcnJvciBpcyByZXR1cm5lZDoKCiAg ICAgICAgIFRhZzogb3BlcmF0aW9uLWZhaWxlZAoKICAgICAgICAgRXJyb3ItdHlwZTogcHJvdG9j b2wKICAgICAgICAgU2V2ZXJpdHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZvOiBub25lCgog ICAgICAgICBEZXNjcmlwdGlvbjogUmVxdWVzdCBjb3VsZCBub3QgYmUgY29tcGxldGVkIGJlY2F1 c2UgdGhlCiAgICAgICAgIHJlcXVlc3RlZCBvcGVyYXRpb24gZmFpbGVkIGZvciBzb21lIHJlYXNv biBub3QgY292ZXJlZCBieSBhbnkKICAgICAgICAgb3RoZXIgZXJyb3IgY29uZGl0aW9uCgogICAg ICBJZiBhICZsdDtzdG9wVGltZSZndDsgaXMgcmVxdWVzdGVkIHdoaWNoIGlzIGVhcmxpZXIgdGhl biB0aGUgc3BlY2lmaWVkCiAgICAgICZsdDtzdGFydFRpbWUmZ3Q7LCB0aGUgZm9sbG93aW5nIGVy cm9yIGlzIHJldHVybmVkOgoKICAgICAgICAgVGFnOiBiYWQtZWxlbWVudAoKICAgICAgICAgRXJy b3ItdHlwZTogcHJvdG9jb2wKCiAgICAgICAgIFNldmVyaXR5OiBlcnJvcgoKICAgICAgICAgRXJy b3ItaW5mbzogJmx0O2JhZC1lbGVtZW50Jmd0Ozogc3RvcFRpbWUKCiAgICAgICAgIERlc2NyaXB0 aW9uOiBBbiBlbGVtZW50IHZhbHVlIGlzIG5vdCBjb3JyZWN0OyBlLmcuLCB3cm9uZyB0eXBlLAog ICAgICAgICBvdXQgb2YgcmFuZ2UsIHBhdHRlcm4gbWlzbWF0Y2guCgogICAgICBJZiBhICZsdDtz dGFydFRpbWUmZ3Q7IGlzIHJlcXVlc3RlZCB3aGljaCBpcyBsYXRlciB0aGVuIHRoZSBjdXJyZW50 CiAgICAgIHRpbWUsIHRoZSBmb2xsb3dpbmcgZXJyb3IgaXMgcmV0dXJuZWQ6CgogICAgICAgICBU YWc6IGJhZC1lbGVtZW50CgogICAgICAgICBFcnJvci10eXBlOiBwcm90b2NvbAoKICAgICAgICAg U2V2ZXJpdHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZvOiAmbHQ7YmFkLWVsZW1lbnQmZ3Q7 OiBzdGFydFRpbWUKCiAgICAgICAgIERlc2NyaXB0aW9uOiBBbiBlbGVtZW50IHZhbHVlIGlzIG5v dCBjb3JyZWN0OyBlLmcuLCB3cm9uZyB0eXBlLAogICAgICAgICBvdXQgb2YgcmFuZ2UsIHBhdHRl cm4gbWlzbWF0Y2guCgoyLjEuMS4xLiAgVXNhZ2UgRXhhbXBsZQoKICAgVGhlIGZvbGxvd2luZyBk ZW1vbnN0cmF0ZXMgY3JlYXRpbmcgYSBzaW1wbGUgc3Vic2NyaXB0aW9uLiAgTW9yZQogICBjb21w bGV4IGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiBzZWN0aW9uIDUuCgogICAmbHQ7bmV0Y29uZjpy cGMgbWVzc2FnZS1pZD0iMTAxIgogICAgICAgICB4bWxuczpuZXRjb25mPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiLyZndDsKICAgICAgICZsdDtjcmVhdGUtc3Vic2Ny aXB0aW9uCiAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpu b3RpZmljYXRpb246MS4wIiZndDsKICAgICAgICZsdDsvY3JlYXRlLXN1YnNjcmlwdGlvbiZndDsK ICAgJmx0Oy9uZXRjb25mOnJwYyZndDsKCjIuMi4gIFNlbmRpbmcgRXZlbnQgTm90aWZpY2F0aW9u cwoKICAgT25jZSB0aGUgc3Vic2NyaXB0aW9uIGhhcyBiZWVuIHNldCB1cCwgdGhlIE5FVENPTkYg c2VydmVyIHNlbmRzIHRoZQogICBldmVudCBub3RpZmljYXRpb25zIGFzeW5jaHJvbm91c2x5IG92 ZXIgdGhlIGNvbm5lY3Rpb24uCgoyLjIuMS4gICZsdDtub3RpZmljYXRpb24mZ3Q7CgogICBEZXNj cmlwdGlvbjoKCiAgICAgIEFuIGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBzZW50IHRvIHRoZSBjbQgd2hvIGluaXRpYXRlZCBhCiAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0OyBjb21t YW5kIGFzeW5jaHJvbm91c2x5IHdoZW4gYW4gZXZlbnQgb2YKICAgICAgaW50ZXJlc3QgKGkuZS4s IG1lZXRpbmcgdGhlIHNwZWNpZmllZCBmaWx0ZXJpbmcgY3JpdGVyaWEpIGhhcwogICAgICBvY2N1 cnJlZC4gIEFuIGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBhIGNvbXBsZXRlIGFuZCB3ZWxsLWZvcm1l ZCBYTUwKICAgICAgZG9jdW1lbnQuICBOb3RlIHRoYXQgJmx0O25vdGlmaWNhdGlvbiZndDsgaXMg bm90IGFuIFJQQyBtZXRob2QgYnV0CiAgICAgIHJhdGhlciB0aGUgdG9wIGxldmVsIGVsZW1lbnQg aWRlbnRpZnlpbmcgdGhlIG9uZS13YXkgbWVzc2FnZSBhcyBhCiAgICAgIG5vdGlmaWNhdGlvbi4K CiAgIFBhcmFtZXRlcnM6CgogICAgICBldmVudFRpbWUKCiAgICAgICAgIFRoZSB0aW1lIHRoZSBl dmVudCB3YXMgZ2VuZXJhdGVkIGJ5IHRoZSBldmVudCBzb3VyY2UuICBUaGlzCiAgICAgICAgIHBh cmFtZXRlciBpcyBvZiB0eXBlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ZGF0ZVRpbWUuPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ZGF0ZVRpbWUgYW5kIGNv bXBsaWFudCB0byBbUkZDMzMzOV0uCiAgICAgICAgIEltcGxlbWVudGF0aW9ucyBtdXN0IHN1cHBv cnQgdGltZSB6b25lcy48L2ZvbnQ+PC9zdHJvbmc+CgogICAgICBBbHNvIGNvbnRhaW5zIG5vdGlm aWNhdGlvbi1zcGVjaWZpYyB0YWdnZWQgY29udGVudCwgaWYgYW55LiAgV2l0aAogICAgICB0aGUg ZXhjZXB0aW9uIG9mICZsdDtldmVudFRpbWUmZ3Q7LCB0aGUgY29udGVudCBvZiB0aGUgbm90aWZp Y2F0aW9uIGlzCiAgICAgIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCiAgIFJl c3BvbnNlOgoKICAgICAgTm8gcmVzcG9uc2UuICBOb3QgYXBwbGljYWJsZS4KCjIuMy4gIFRlcm1p bmF0aW5nIHRoZSBTdWJzY3JpcHRpb24KCiAgIENsb3Npbmcgb2YgdGhlIGV2ZW50IG5vdGlmaWNh dGlvbiBzdWJzY3JpcHRpb24gY2FuIGJlIGRvbmUgYnkgdXNpbmcKICAgdGhlICZsdDtjbG9zZS1z ZXNzaW9uJmd0OyBvcGVyYXRpb24gZnJvbSB0aGUgc3Vic2NyaXB0aW9ucyBzZXNzaW9uIG9yCiAg IHRlcm1pbmF0aW5nIHRoZSBORVRDT05GIHNlc3Npb24gKCAmbHQ7a2lsbC1zZXNzaW9uJmd0OyAp IG9yIHRoZSB1bmRlcmx5aW5nCiAgIHRyYW5zcG9ydCBzZXNzaW9uIGZyb20gYW5vdGhlciBzZXNz aW9uLiAgSWYgYSBzdG9wIHRpbWUgaXMgcHJvdmlkZWQKICAgd2hlbiB0aGUgc3Vic2NyaXB0aW9u IGlzIGNyZWF0ZWQsIHRoZSBzdWJzY3JpcHRpb24gd2lsbCB0ZXJtaW5hdGUKICAgYWZ0ZXIgdGhl IHN0b3AgdGltZSBpcyByZWFjaGVkLiAgSW4gdGhpcyBjYXNlLCB0aGUgTkVUQ09ORiBzZXNzaW9u CiAgIHdpbGwgc3RpbGwgYmUgYW4gYWN0aXZlIHNlc3Npb24uCgozLiAgU3VwcG9ydGluZyBDb25j ZXB0cwoKMy4xLiAgQ2FwYWJpbGl0aWVzIEV4Y2hhbmdlCgogICBUaGUgYWJpbGl0eSB0byBwcm9j ZXNzIGFuZCBzZW5kIGV2ZW50IG5vdGlmaWNhdGlvbnMgaXMgYWR2ZXJ0aXNlZAogICBkdXJpbmcg dGhlIGNhcGFiaWxpdHkgZXhjaGFuZ2UgYmV0d2VlbiB0aGUgTkVUQ09ORiBjbGllbnQgYW5kIHNl cnZlci4KCjMuMS4xLiAgQ2FwYWJpbGl0eSBJZGVudGlmaWVyCgogICAidXJuOmlldGY6cGFyYW1z Om5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIgoKMy4xLjIuICBDYXBhYmlsaXR5 IEV4YW1wbGUKCiAgICZsdDtoZWxsbyB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIiZndDsKICAgICAmbHQ7Y2FwYWJpbGl0aWVzJmd0OwogICAgICAgICZsdDtj YXBhYmlsaXR5Jmd0OwogICAgICAgICAgICB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6 YmFzZToxLjAKICAgICAgICAgICZsdDsvY2FwYWJpbGl0eSZndDsKICAgICAgICAgICZsdDtjYXBh YmlsaXR5Jmd0OwogICAgICAgICAgICB1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5 OnN0YXJ0dXA6MS4wCiAgICAgICAgICAmbHQ7L2NhcGFiaWxpdHkmZ3Q7CiAgICAgICAgICAmbHQ7 Y2FwYWJpbGl0eSZndDsKICAgICAgICAgICAgdXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJp bGl0eTpub3RpZmljYXRpb246MS4wCiAgICAgICAgICAmbHQ7L2NhcGFiaWxpdHkmZ3Q7CiAgICAg ICAmbHQ7L2NhcGFiaWxpdGllcyZndDsKICAgICAmbHQ7c2Vzc2lvbi1pZCZndDs0Jmx0Oy9zZXNz aW9uLWlkJmd0OwogICAmbHQ7L2hlbGxvJmd0OwoKMy4yLiAgRXZlbnQgU3RyZWFtcwoKICAgQW4g ZXZlbnQgc3RyZWFtIGlzIGRlZmluZWQgYXMgYSBzZXQgb2YgZXZlbnQgbm90aWZpY2F0aW9ucyBt YXRjaGluZwogICBzb21lIGZvcndhcmRpbmcgY3JpdGVyaWEuCgogICBGaWd1cmUgMiBpbGx1c3Ry YXRlcyB0aGUgbm90aWZpY2F0aW9uIGZsb3cgYW5kIGNvbmNlcHRzIGlkZW50aWZpZWQgaW4KICAg dGhpcyBkb2N1bWVudC4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5JdCBkb2VzIG5vdCBt YW5kYXRlIGFuZC9vciBwcmVjbHVkZSBhbgogICBpbXBsZW1lbnRhdGlvbi48L2ZvbnQ+PC9zdHJv bmc+ICBUaGUgZm9sbG93aW5nIGlzIG9ic2VydmVkIGZyb20gdGhlIGRpYWdyYW0gYmVsb3c6CiAg IFN5c3RlbSBjb21wb25lbnRzIChjMS4uY24pIGdlbmVyYXRlIGV2ZW50IG5vdGlmaWNhdGlvbnMg d2hpY2ggYXJlCiAgIHBhc3NlZCB0byBhIGNlbnRyYWwgY29tcG9uZW50IGZvciBjbGFzc2lmaWNh dGlvbiBhbmQgZGlzdHJpYnV0aW9uLgogICBUaGUgY2VudHJhbCBjb21wb25lbnQgaW5zcGVjdHMg ZWFjaCBldmVudCBub3RpZmljYXRpb24gYW5kIG1hdGNoZXMKICAgdGhlIGV2ZW50IG5vdGlmaWNh dGlvbiBhZ2FpbnN0IHRoZSBzZXQgb2Ygc3RyZWFtIGRlZmluaXRpb25zLiAgV2hlbiBhCiAgIG1h dGNoIG9jY3VycywgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBjb25zaWRlcmVkIHRvIGJlIGEg bWVtYmVyIG9mCiAgIGll bnQgd2hvIGluaXRpYXRlZCBhCiAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0OyBjb21t YW5kIGFzeW5jaHJvbm91c2x5IHdoZW4gYW4gZXZlbnQgb2YKICAgICAgaW50ZXJlc3QgKGkuZS4s IG1lZXRpbmcgdGhlIHNwZWNpZmllZCBmaWx0ZXJpbmcgY3JpdGVyaWEpIGhhcwogICAgICBvY2N1 cnJlZC4gIEFuIGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBhIGNvbXBsZXRlIGFuZCB3ZWxsLWZvcm1l ZCBYTUwKICAgICAgZG9jdW1lbnQuICBOb3RlIHRoYXQgJmx0O25vdGlmaWNhdGlvbiZndDsgaXMg bm90IGFuIFJQQyBtZXRob2QgYnV0CiAgICAgIHJhdGhlciB0aGUgdG9wIGxldmVsIGVsZW1lbnQg aWRlbnRpZnlpbmcgdGhlIG9uZS13YXkgbWVzc2FnZSBhcyBhCiAgICAgIG5vdGlmaWNhdGlvbi4K CiAgIFBhcmFtZXRlcnM6CgogICAgICBldmVudFRpbWUKCiAgICAgICAgIFRoZSB0aW1lIHRoZSBl dmVudCB3YXMgZ2VuZXJhdGVkIGJ5IHRoZSBldmVudCBzb3VyY2UuICBUaGlzCiAgICAgICAgIHBh cmFtZXRlciBpcyBvZiB0eXBlIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ZGF0ZVRpbWUuPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ZGF0ZVRpbWUgYW5kIGNv bXBsaWFudCB0byBbUkZDMzMzOV0uCiAgICAgICAgIEltcGxlbWVudGF0aW9ucyBtdXN0IHN1cHBv cnQgdGltZSB6b25lcy48L2ZvbnQ+PC9zdHJvbmc+CgogICAgICBBbHNvIGNvbnRhaW5zIG5vdGlm aWNhdGlvbi1zcGVjaWZpYyB0YWdnZWQgY29udGVudCwgaWYgYW55LiAgV2l0aAogICAgICB0aGUg ZXhjZXB0aW9uIG9mICZsdDtldmVudFRpbWUmZ3Q7LCB0aGUgY29udGVudCBvZiB0aGUgbm90aWZp Y2F0aW9uIGlzCiAgICAgIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCiAgIFJl c3BvbnNlOgoKICAgICAgTm8gcmVzcG9uc2UuICBOb3QgYXBwbGljYWJsZS4KCjIuMy4gIFRlcm1p bmF0aW5nIHRoZSBTdWJzY3JpcHRpb24KCiAgIENsb3Npbmcgb2YgdGhlIGV2ZW50IG5vdGlmaWNh dGlvbiBzdWJzY3JpcHRpb24gY2FuIGJlIGRvbmUgYnkgdXNpbmcKICAgdGhlICZsdDtjbG9zZS1z ZXNzaW9uJmd0OyBvcGVyYXRpb24gZnJvbSB0aGUgc3Vic2NyaXB0aW9ucyBzZXNzaW9uIG9yCiAg IHRlcm1pbmF0aW5nIHRoZSBORVRDT05GIHNlc3Npb24gKCAmbHQ7a2lsbC1zZXNzaW9uJmd0OyAp IG9yIHRoZSB1bmRlcmx5aW5nCiAgIHRyYW5zcG9ydCBzZXNzaW9uIGZyb20gYW5vdGhlciBzZXNz aW9uLiAgSWYgYSBzdG9wIHRpbWUgaXMgcHJvdmlkZWQKICAgd2hlbiB0aGUgc3Vic2NyaXB0aW9u IGlzIGNyZWF0ZWQsIHRoZSBzdWJzY3JpcHRpb24gd2lsbCB0ZXJtaW5hdGUKICAgYWZ0ZXIgdGhl IHN0b3AgdGltZSBpcyByZWFjaGVkLiAgSW4gdGhpcyBjYXNlLCB0aGUgTkVUQ09ORiBzZXNzaW9u CiAgIHdpbGwgc3RpbGwgYmUgYW4gYWN0aXZlIHNlc3Npb24uCgozLiAgU3VwcG9ydGluZyBDb25j ZXB0cwoKMy4xLiAgQ2FwYWJpbGl0aWVzIEV4Y2hhbmdlCgogICBUaGUgYWJpbGl0eSB0byBwcm9j ZXNzIGFuZCBzZW5kIGV2ZW50IG5vdGlmaWNhdGlvbnMgaXMgYWR2ZXJ0aXNlZAogICBkdXJpbmcg dGhlIGNhcGFiaWxpdHkgZXhjaGFuZ2UgYmV0d2VlbiB0aGUgTkVUQ09ORiBjbGllbnQgYW5kIHNl cnZlci4KCjMuMS4xLiAgQ2FwYWJpbGl0eSBJZGVudGlmaWVyCgogICAidXJuOmlldGY6cGFyYW1z Om5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIgoKMy4xLjIuICBDYXBhYmlsaXR5 IEV4YW1wbGUKCiAgICZsdDtoZWxsbyB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIiZndDsKICAgICAmbHQ7Y2FwYWJpbGl0aWVzJmd0OwogICAgICAgICZsdDtj YXBhYmlsaXR5Jmd0OwogICAgICAgICAgICB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6 YmFzZToxLjAKICAgICAgICAgICZsdDsvY2FwYWJpbGl0eSZndDsKICAgICAgICAgICZsdDtjYXBh YmlsaXR5Jmd0OwogICAgICAgICAgICB1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5 OnN0YXJ0dXA6MS4wCiAgICAgICAgICAmbHQ7L2NhcGFiaWxpdHkmZ3Q7CiAgICAgICAgICAmbHQ7 Y2FwYWJpbGl0eSZndDsKICAgICAgICAgICAgdXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJp bGl0eTpub3RpZmljYXRpb246MS4wCiAgICAgICAgICAmbHQ7L2NhcGFiaWxpdHkmZ3Q7CiAgICAg ICAmbHQ7L2NhcGFiaWxpdGllcyZndDsKICAgICAmbHQ7c2Vzc2lvbi1pZCZndDs0Jmx0Oy9zZXNz aW9uLWlkJmd0OwogICAmbHQ7L2hlbGxvJmd0OwoKMy4yLiAgRXZlbnQgU3RyZWFtcwoKICAgQW4g ZXZlbnQgc3RyZWFtIGlzIGRlZmluZWQgYXMgYSBzZXQgb2YgZXZlbnQgbm90aWZpY2F0aW9ucyBt YXRjaGluZwogICBzb21lIGZvcndhcmRpbmcgY3JpdGVyaWEuCgogICBGaWd1cmUgMiBpbGx1c3Ry YXRlcyB0aGUgbm90aWZpY2F0aW9uIGZsb3cgYW5kIGNvbmNlcHRzIGlkZW50aWZpZWQgaW4KICAg dGhpcyBkb2N1bWVudC4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5JdCBkb2VzIG5vdCBt YW5kYXRlIGFuZC9vciBwcmVjbHVkZSBhbgogICBpbXBsZW1lbnRhdGlvbi48L2ZvbnQ+PC9zdHJv bmc+ICBUaGUgZm9sbG93aW5nIGlzIG9ic2VydmVkIGZyb20gdGhlIGRpYWdyYW0gYmVsb3c6CiAg IFN5c3RlbSBjb21wb25lbnRzIChjMS4uY24pIGdlbmVyYXRlIGV2ZW50IG5vdGlmaWNhdGlvbnMg d2hpY2ggYXJlCiAgIHBhc3NlZCB0byBhIGNlbnRyYWwgY29tcG9uZW50IGZvciBjbGFzc2lmaWNh dGlvbiBhbmQgZGlzdHJpYnV0aW9uLgogICBUaGUgY2VudHJhbCBjb21wb25lbnQgaW5zcGVjdHMg ZWFjaCBldmVudCBub3RpZmljYXRpb24gYW5kIG1hdGNoZXMKICAgdGhlIGV2ZW50IG5vdGlmaWNh dGlvbiBhZ2FpbnN0IHRoZSBzZXQgb2Ygc3RyZWFtIGRlZmluaXRpb25zLiAgV2hlbiBhCiAgIG1h dGNoIG9jY3VycywgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBjb25zaWRlcmVkIHRvIGJlIGEg bWVtYmVyIG9HRoYXQgZXZlbnQgc3RyZWFtIChzdHJlYW0gMS4uc3RyZWFtIG4pLiAgQW4g ZXZlbnQgbm90aWZpY2F0aW9uIG1heSBiZQogICBwYXJ0IG9mIG11bHRpcGxlIGV2ZW50IHN0cmVh bXMuCgogICBBdCBzb21lIHBvaW50IGFmdGVyIHRoZSBORVRDT05GIHNlcnZlciByZWNlaXZlcyB0 aGUgaW50ZXJuYWwgZXZlbnQKICAgZnJvbSBhIHN0cmVhbSwgaXQgaXMgY29udmVydGVkIHRvIGFu IGFwcHJvcHJpYXRlIFhNTCBlbmNvZGluZyBieSB0aGUKICAgc2VydmVyLCBhbmQgYSAmbHQ7bm90 aWZpY2F0aW9uJmd0OyBlbGVtZW50IGlzIHJlYWR5IHRvIHNlbmQgdG8gYWxsIE5FVENPTkYKICAg c2Vzc2lvbnMgc3Vic2NyaWJlZCB0byB0aGF0IHN0cmVhbS4KCiAgIEFmdGVyIGdlbmVyYXRpb24g b2YgdGhlICZsdDtub3RpZmljYXRpb24mZ3Q7IGVsZW1lbnQsIGFjY2VzcyBjb250cm9sIGlzCiAg IGFwcGxpZWQgYnkgdGhlIHNlcnZlci4gIElmIGEgc2Vzc2lvbiBkb2VzIG5vdCBoYXZlIHBlcm1p c3Npb24gdG8KICAgcmVjZWl2ZSB0aGUgJmx0O25vdGlmaWNhdGlvbiZndDssIHRoZW4gaXQgaXMg ZGlzY2FyZGVkIGZvciB0aGF0IHNlc3Npb24sCiAgIGFuZCBwcm9jZXNzaW5nIG9mIHRoZSBpbnRl cm5hbCBldmVudCBpcyBjb21wbGV0ZWQgZm9yIHRoYXQgc2Vzc2lvbi4KCiAgIFdoZW4gYSBORVRD T05GIGNsaWVudCBzdWJzY3JpYmVzIHRvIGEgZ2l2ZW4gZXZlbnQgc3RyZWFtLCB1c2VyLQogICBk ZWZpbmVkIGZpbHRlciBlbGVtZW50cywgaWYgYXBwbGljYWJsZSwgYXJlIGFwcGxpZWQgdG8gdGhl IGV2ZW50CiAgIHN0cmVhbSBhbmQgbWF0Y2hpbmcgZXZlbnQgbm90aWZpY2F0aW9ucyBhcmUgZm9y d2FyZGVkIHRvIHRoZSBORVRDT05GCiAgIHNlcnZlciBmb3IgZGlzdHJpYnV0aW9uIHRvIHN1YnNj cmliZWQgTkVUQ09ORiBjbGllbnRzLiAgQSBmaWx0ZXIgaXMKICAgdHJhbnNmZXJyZWQgZnJvbSB0 aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIgZHVyaW5nIHRoZSAmbHQ7Y3JlYXRlLQogICBzdWJzY3Jp cHRpb24mZ3Q7IG9wZXJhdGlvbiBhbmQgYXBwbGllZCBhZ2FpbnN0IGVhY2ggJmx0O25vdGlmaWNh dGlvbiZndDsKICAgZWxlbWVudCBnZW5lcmF0ZWQgYnkgdGhlIHN0cmVhbS4gIEZvciBtb3JlIGlu Zm9ybWF0aW9uIG9uIGZpbHRlcmluZywKICAgc2VlIHNlY3Rpb24gMy42LgoKICAgQSBub3RpZmlj YXRpb24gbG9nZ2luZyBzZXJ2aWNlIG1heSBhbHNvIGJlIGF2YWlsYWJsZSwgaW4gd2hpY2ggY2Fz ZSwKICAgdGhlIGNlbnRyYWwgY29tcG9uZW50IGxvZ3Mgbm90aWZpY2F0aW9ucy4gIFRoZSBORVRD T05GIHNlcnZlciBtYXkKICAgbGF0ZXIgcmV0cmlldmUgbG9nZ2VkIG5vdGlmaWNhdGlvbnMgdmlh IHRoZSBvcHRpb25hbCByZXBsYXkgZmVhdHVyZS4KICAgRm9yIG1vcmUgaW5mb3JtYXRpb24gb24g cmVwbGF5LCBzZWUgc2VjdGlvbiAzLjMuCgogICArLS0tLSsKICAgfCBjMSB8LS0tLSsgICAgICAg ICAgICAgYXZhaWxhYmxlIHN0cmVhbXMKICAgKy0tLS0rICAgIHwgICAgKy0tLS0tLS0tLSsKICAg Ky0tLS0rICAgIHwgICAgfGNlbnRyYWwgIHwtJmd0OyBzdHJlYW0gMQogICB8IGMyIHwgICAgKy0t LSZndDt8ZXZlbnQgICAgfC0mZ3Q7IHN0cmVhbSAyICAgICBmaWx0ZXIgICstLS0tLS0tKwogICAr LS0tLSsgICAgfCAgICB8cHJvY2Vzc29yfC0mZ3Q7IE5FVENPTkYgc3RyZWFtIC0tLS0tJmd0O3xO RVRDT05GfAogICAgLi4uICAgICAgfCAgICB8ICAgICAgICAgfC0mZ3Q7IHN0cmVhbSBuICAgICAg ICAgICAgIHxzZXJ2ZXIgfAogICBTeXN0ZW0gICAgfCAgICArLS0tLS0tLS0tKyAgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0tKwogICBDb21wb25lbnRzfCAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC9cCiAgICAuLi4gICAgICB8ICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgKy0tLS0rICAgIHwgICAgICAgIHwgICAgICAg KC0tLS0tLS0tLS0tLSkgICAgICAgICAgICB8fAogICB8IGNuIHwtLS0tKyAgICAgICAgfCAgICAg ICAobm90aWZpY2F0aW9uKSAgICAgICAgICAgIHx8CiAgICstLS0tKyAgICAgICAgICAgICArLS0t LS0mZ3Q7ICggIGxvZ2dpbmcgICApICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKCAgc2VydmljZSAgICkgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAoLS0tLS0tLS0tLS0tKSAgICAgICAgICAgIHx8CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwvCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxORVRDT05GfAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfGNsaWVu dCB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDIKCjMuMi4x LiAgRXZlbnQgU3RyZWFtIERlZmluaXRpb24KCiAgIEV2ZW50IHN0cmVhbXMgYXJlIHByZWRlZmlu ZWQgb24gdGhlIG1hbmFnZWQgZGV2aWNlLiAgVGhlCiAgIGNvbmZpZ3VyYXRpb24gb2YgZXZlbnQg c3RyZWFtcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LgogICBIb3dldmVy LCBpdCBpcyBlbnZpc2lvbmVkIHRoYXQgZXZlbnQgc3RyZWFtcyBhcmUgZWl0aGVyIHByZS0KICAg ZXN0YWJsaXNoZWQgYnkgdGhlIHZlbmRvciAocHJlLWNvbmZpZ3VyZWQpLCB1c2VyIGNvbmZpZ3Vy YWJsZSAoZS5nLiwKICAgcGFydCBvZiB0mCiAgIHRoYXQgZXZlbnQgc3RyZWFtIChzdHJlYW0gMS4uc3RyZWFtIG4pLiAgQW4g ZXZlbnQgbm90aWZpY2F0aW9uIG1heSBiZQogICBwYXJ0IG9mIG11bHRpcGxlIGV2ZW50IHN0cmVh bXMuCgogICBBdCBzb21lIHBvaW50IGFmdGVyIHRoZSBORVRDT05GIHNlcnZlciByZWNlaXZlcyB0 aGUgaW50ZXJuYWwgZXZlbnQKICAgZnJvbSBhIHN0cmVhbSwgaXQgaXMgY29udmVydGVkIHRvIGFu IGFwcHJvcHJpYXRlIFhNTCBlbmNvZGluZyBieSB0aGUKICAgc2VydmVyLCBhbmQgYSAmbHQ7bm90 aWZpY2F0aW9uJmd0OyBlbGVtZW50IGlzIHJlYWR5IHRvIHNlbmQgdG8gYWxsIE5FVENPTkYKICAg c2Vzc2lvbnMgc3Vic2NyaWJlZCB0byB0aGF0IHN0cmVhbS4KCiAgIEFmdGVyIGdlbmVyYXRpb24g b2YgdGhlICZsdDtub3RpZmljYXRpb24mZ3Q7IGVsZW1lbnQsIGFjY2VzcyBjb250cm9sIGlzCiAg IGFwcGxpZWQgYnkgdGhlIHNlcnZlci4gIElmIGEgc2Vzc2lvbiBkb2VzIG5vdCBoYXZlIHBlcm1p c3Npb24gdG8KICAgcmVjZWl2ZSB0aGUgJmx0O25vdGlmaWNhdGlvbiZndDssIHRoZW4gaXQgaXMg ZGlzY2FyZGVkIGZvciB0aGF0IHNlc3Npb24sCiAgIGFuZCBwcm9jZXNzaW5nIG9mIHRoZSBpbnRl cm5hbCBldmVudCBpcyBjb21wbGV0ZWQgZm9yIHRoYXQgc2Vzc2lvbi4KCiAgIFdoZW4gYSBORVRD T05GIGNsaWVudCBzdWJzY3JpYmVzIHRvIGEgZ2l2ZW4gZXZlbnQgc3RyZWFtLCB1c2VyLQogICBk ZWZpbmVkIGZpbHRlciBlbGVtZW50cywgaWYgYXBwbGljYWJsZSwgYXJlIGFwcGxpZWQgdG8gdGhl IGV2ZW50CiAgIHN0cmVhbSBhbmQgbWF0Y2hpbmcgZXZlbnQgbm90aWZpY2F0aW9ucyBhcmUgZm9y d2FyZGVkIHRvIHRoZSBORVRDT05GCiAgIHNlcnZlciBmb3IgZGlzdHJpYnV0aW9uIHRvIHN1YnNj cmliZWQgTkVUQ09ORiBjbGllbnRzLiAgQSBmaWx0ZXIgaXMKICAgdHJhbnNmZXJyZWQgZnJvbSB0 aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIgZHVyaW5nIHRoZSAmbHQ7Y3JlYXRlLQogICBzdWJzY3Jp cHRpb24mZ3Q7IG9wZXJhdGlvbiBhbmQgYXBwbGllZCBhZ2FpbnN0IGVhY2ggJmx0O25vdGlmaWNh dGlvbiZndDsKICAgZWxlbWVudCBnZW5lcmF0ZWQgYnkgdGhlIHN0cmVhbS4gIEZvciBtb3JlIGlu Zm9ybWF0aW9uIG9uIGZpbHRlcmluZywKICAgc2VlIHNlY3Rpb24gMy42LgoKICAgQSBub3RpZmlj YXRpb24gbG9nZ2luZyBzZXJ2aWNlIG1heSBhbHNvIGJlIGF2YWlsYWJsZSwgaW4gd2hpY2ggY2Fz ZSwKICAgdGhlIGNlbnRyYWwgY29tcG9uZW50IGxvZ3Mgbm90aWZpY2F0aW9ucy4gIFRoZSBORVRD T05GIHNlcnZlciBtYXkKICAgbGF0ZXIgcmV0cmlldmUgbG9nZ2VkIG5vdGlmaWNhdGlvbnMgdmlh IHRoZSBvcHRpb25hbCByZXBsYXkgZmVhdHVyZS4KICAgRm9yIG1vcmUgaW5mb3JtYXRpb24gb24g cmVwbGF5LCBzZWUgc2VjdGlvbiAzLjMuCgogICArLS0tLSsKICAgfCBjMSB8LS0tLSsgICAgICAg ICAgICAgYXZhaWxhYmxlIHN0cmVhbXMKICAgKy0tLS0rICAgIHwgICAgKy0tLS0tLS0tLSsKICAg Ky0tLS0rICAgIHwgICAgfGNlbnRyYWwgIHwtJmd0OyBzdHJlYW0gMQogICB8IGMyIHwgICAgKy0t LSZndDt8ZXZlbnQgICAgfC0mZ3Q7IHN0cmVhbSAyICAgICBmaWx0ZXIgICstLS0tLS0tKwogICAr LS0tLSsgICAgfCAgICB8cHJvY2Vzc29yfC0mZ3Q7IE5FVENPTkYgc3RyZWFtIC0tLS0tJmd0O3xO RVRDT05GfAogICAgLi4uICAgICAgfCAgICB8ICAgICAgICAgfC0mZ3Q7IHN0cmVhbSBuICAgICAg ICAgICAgIHxzZXJ2ZXIgfAogICBTeXN0ZW0gICAgfCAgICArLS0tLS0tLS0tKyAgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0tKwogICBDb21wb25lbnRzfCAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC9cCiAgICAuLi4gICAgICB8ICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgKy0tLS0rICAgIHwgICAgICAgIHwgICAgICAg KC0tLS0tLS0tLS0tLSkgICAgICAgICAgICB8fAogICB8IGNuIHwtLS0tKyAgICAgICAgfCAgICAg ICAobm90aWZpY2F0aW9uKSAgICAgICAgICAgIHx8CiAgICstLS0tKyAgICAgICAgICAgICArLS0t LS0mZ3Q7ICggIGxvZ2dpbmcgICApICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKCAgc2VydmljZSAgICkgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAoLS0tLS0tLS0tLS0tKSAgICAgICAgICAgIHx8CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwvCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxORVRDT05GfAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfGNsaWVu dCB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDIKCjMuMi4x LiAgRXZlbnQgU3RyZWFtIERlZmluaXRpb24KCiAgIEV2ZW50IHN0cmVhbXMgYXJlIHByZWRlZmlu ZWQgb24gdGhlIG1hbmFnZWQgZGV2aWNlLiAgVGhlCiAgIGNvbmZpZ3VyYXRpb24gb2YgZXZlbnQg c3RyZWFtcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LgogICBIb3dldmVy LCBpdCBpcyBlbnZpc2lvbmVkIHRoYXQgZXZlbnQgc3RyZWFtcyBhcmUgZWl0aGVyIHByZS0KICAg ZXN0YWJsaXNoZWQgYnkgdGhlIHZlbmRvciAocHJlLWNvbmZpZ3VyZWQpLCB1c2VyIGNvbmZpZ3Vy YWJsZSAoZS5nLiwKICAgcGFydCaGUgZGV2aWNlJ3MgY29uZmlndXJhdGlvbikgb3IgYm90 aC4gIERldmljZSB2ZW5kb3JzIG1heQogICBhbGxvdyBldmVudCBzdHJlYW0gY29uZmlndXJhdGlv biB2aWEgdGhlIE5FVENPTkYgcHJvdG9jb2wgKGkuZS4sCiAgICZsdDtlZGl0LWNvbmZpZyZndDsg b3BlcmF0aW9uKS4KCjMuMi4yLiAgRXZlbnQgU3RyZWFtIENvbnRlbnQgRm9ybWF0CgogICBUaGUg Y29udGVudHMgb2YgYWxsIGV2ZW50IHN0cmVhbXMgbWFkZSBhdmFpbGFibGUgdG8gYSBORVRDT05G IGNsaWVudAogICAoaS5lLiwgdGhlIG5vdGlmaWNhdGlvbiBzZW50IGJ5IHRoZSBORVRDT05GIHNl cnZlcikgTVVTVCBiZSBlbmNvZGVkCiAgIGluIFhNTC4KCjMuMi4zLiAgRGVmYXVsdCBFdmVudCBT dHJlYW0KCiAgIEEgTkVUQ09ORiBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gc3VwcG9ydGluZyB0aGUg bm90aWZpY2F0aW9uCiAgIGNhcGFiaWxpdHkgTVVTVCBzdXBwb3J0IHRoZSAiTkVUQ09ORiIgbm90 aWZpY2F0aW9uIGV2ZW50IHN0cmVhbS4KICAgVGhpcyBzdHJlYW0gY29udGFpbnMgYWxsIE5FVENP TkYgWE1MIGV2ZW50IG5vdGlmaWNhdGlvbnMgc3VwcG9ydGVkIGJ5CiAgIHRoZSBORVRDT05GIHNl cnZlci4gIFRoZSBleGFjdCBzdHJpbmcgIk5FVENPTkYiIGlzIHVzZWQgZHVyaW5nCiAgIGFkdmVy dGlzZW1lbnQgb2Ygc3RyZWFtIHN1cHBvcnQgZHVyaW5nIHRoZSAmbHQ7Z2V0Jmd0OyBvcGVyYXRp b24gb24KICAgJmx0O3N0cmVhbXMmZ3Q7IGFuZCBkdXJpbmcgdGhlICZsdDtjcmVhdGUtc3Vic2Ny aXB0aW9uJmd0OyBvcGVyYXRpb24uICBEZWZpbml0aW9uCiAgIG9mIHRoZSBldmVudCBub3RpZmlj YXRpb25zIGFuZCB0aGVpciBjb250ZW50cywgYmV5b25kIHRoZSBpbmNsdXNpb24KICAgb2YgJmx0 O2V2ZW50VGltZSZndDssIGZvciB0aGlzIGV2ZW50IHN0cmVhbSBpcyBvdXRzaWRlIHRoZSBzY29w ZSBvZiB0aGlzCiAgIGRvY3VtZW50LgoKMy4yLjQuICBFdmVudCBTdHJlYW0gU291cmNlcwoKICAg V2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSBkZWZhdWx0IGV2ZW50IHN0cmVhbSAoTkVUQ09ORiks CiAgIHNwZWNpZmljYXRpb24gb2YgYWRkaXRpb25hbCBldmVudCBzdHJlYW0gc291cmNlcyAoZS5n LiwgU05NUCwgc3lzbG9nKQogICBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50 LiAgTkVUQ09ORiBzZXJ2ZXIKICAgaW1wbGVtZW50YXRpb25zIG1heSBsZXZlcmFnZSBhbnkgZGVz aXJlZCBldmVudCBzdHJlYW0gc291cmNlIGluIHRoZQogICBjcmVhdGlvbiBvZiBzdXBwb3J0ZWQg ZXZlbnQgc3RyZWFtcy4KCjMuMi41LiAgRXZlbnQgU3RyZWFtIERpc2NvdmVyeQoKICAgQSBORVRD T05GIGNsaWVudCByZXRyaWV2ZXMgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIGV2ZW50IHN0cmVhbXMg ZnJvbSBhCiAgIE5FVENPTkYgc2VydmVyIHVzaW5nIHRoZSAmbHQ7Z2V0Jmd0OyBvcGVyYXRpb24u CgozLjIuNS4xLiAgTmFtZSBSZXRyaWV2YWwgdXNpbmcgJmx0O2dldCZndDsgb3BlcmF0aW9uCgog ICBUaGUgbGlzdCBvZiBhdmFpbGFibGUgZXZlbnQgc3RyZWFtcyBpcyByZXRyaWV2ZWQgYnkgcmVx dWVzdGluZyB0aGUKICAgJmx0O3N0cmVhbXMmZ3Q7IHN1YnRyZWUgdmlhIGEgJmx0O2dldCZndDsg b3BlcmF0aW9uLiAgQXZhaWxhYmxlIGV2ZW50IHN0cmVhbXMgZm9yCiAgIHRoZSByZXF1ZXN0aW5n IHNlc3Npb24gYXJlIHJldHVybmVkIGluIHRoZSByZXBseSBjb250YWluaW5nIHRoZQogICAmbHQ7 bmFtZSZndDsgYW5kICZsdDtkZXNjcmlwdGlvbiZndDsgZWxlbWVudHMsIHdoZXJlIHRoZSAmbHQ7 bmFtZSZndDsgZWxlbWVudCBpcwogICBtYW5kYXRvcnksIGFuZCBpdHMgdmFsdWUgaXMgdW5pcXVl IHdpdGhpbiB0aGUgc2NvcGUgb2YgYSBORVRDT05GCiAgIHNlcnZlci4gIEFuIGVtcHR5IHJlcGx5 IGlzIHJldHVybmVkIGlmIHRoZXJlIGFyZSBubyBhdmFpbGFibGUgZXZlbnQKICAgc3RyZWFtcywg ZHVlIHRvIHVzZXItc3BlY2lmaWVkIGZpbHRlcnMgb24gdGhlICZsdDtnZXQmZ3Q7IG9wZXJhdGlv biAuCgogICBBZGRpdGlvbmFsIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhYm91dCBhIHN0cmVhbSBp bmNsdWRlIHdoZXRoZXIKICAgbm90aWZpY2F0aW9uIHJlcGxheSBpcyBhdmFpbGFibGUgYW5kIGlm IHNvLCB0aGUgdGltZXN0YW1wIG9mIHRoZQogICBlYXJsaWVzdCBwb3NzaWJsZSBub3RpZmljYXRp b24gdG8gcmVwbGF5LgoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHJldHJpZXZpbmcg dGhlIGxpc3Qgb2YgYXZhaWxhYmxlIGV2ZW50CiAgIHN0cmVhbSBsaXN0IHVzaW5nIHRoZSAmbHQ7 Z2V0Jmd0OyBvcGVyYXRpb24uCgogICAmbHQ7cnBjIG1lc3NhZ2UtaWQ9IjEwMSIKICAgICAgeG1s bnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCImZ3Q7CiAgICAgJmx0 O2dldCZndDsKICAgICAgJmx0O2ZpbHRlciB0eXBlPSJzdWJ0cmVlIiZndDsKICAgICAgICAmbHQ7 bmV0Y29uZiB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZpY2F0aW9u IiZndDsKICAgICAgICAgICAmbHQ7c3RyZWFtcy8mZ3Q7CiAgICAgICAgICZsdDsvbmV0Y29uZiZn dDsKICAgICAgJmx0Oy9maWx0ZXImZ3Q7CiAgICAgJmx0Oy9nZXQmZ3Q7CiAgICZsdDsvcnBjJmd0 OwogICBUaGUgTkVUQ09ORiBzZXJ2ZXIgcmV0dXJucyBhIGxpc3Qgb2YgZXZlbnQgc3RyZWFtcyBh dmFpbGFibGUgZm9yCiAgIHN1YnNjcmlwdGlvbjogTkVUQ09ORiwgU05NUCwgYW5kIHN5c2xvZy1j cml0aWNhbCBpbiB0aGlzIGV4YW1wbGUuCgogICAmbHQ7cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEw MSIKICAgICAgICAgICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIiZndDsKICAgICAmbHQ7ZGF0YSZndDsKICAgICAgICZsdDtuZXRjb25mICB4 bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZpY2F0aW9uIiZndDsKICAg ICAgICAmbHQ7c3RyZWFtcyZndDsKICAgICAgICAgICAmbHQBvZiB0aGUgZGV2aWNlJ3MgY29uZmlndXJhdGlvbikgb3IgYm90 aC4gIERldmljZSB2ZW5kb3JzIG1heQogICBhbGxvdyBldmVudCBzdHJlYW0gY29uZmlndXJhdGlv biB2aWEgdGhlIE5FVENPTkYgcHJvdG9jb2wgKGkuZS4sCiAgICZsdDtlZGl0LWNvbmZpZyZndDsg b3BlcmF0aW9uKS4KCjMuMi4yLiAgRXZlbnQgU3RyZWFtIENvbnRlbnQgRm9ybWF0CgogICBUaGUg Y29udGVudHMgb2YgYWxsIGV2ZW50IHN0cmVhbXMgbWFkZSBhdmFpbGFibGUgdG8gYSBORVRDT05G IGNsaWVudAogICAoaS5lLiwgdGhlIG5vdGlmaWNhdGlvbiBzZW50IGJ5IHRoZSBORVRDT05GIHNl cnZlcikgTVVTVCBiZSBlbmNvZGVkCiAgIGluIFhNTC4KCjMuMi4zLiAgRGVmYXVsdCBFdmVudCBT dHJlYW0KCiAgIEEgTkVUQ09ORiBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gc3VwcG9ydGluZyB0aGUg bm90aWZpY2F0aW9uCiAgIGNhcGFiaWxpdHkgTVVTVCBzdXBwb3J0IHRoZSAiTkVUQ09ORiIgbm90 aWZpY2F0aW9uIGV2ZW50IHN0cmVhbS4KICAgVGhpcyBzdHJlYW0gY29udGFpbnMgYWxsIE5FVENP TkYgWE1MIGV2ZW50IG5vdGlmaWNhdGlvbnMgc3VwcG9ydGVkIGJ5CiAgIHRoZSBORVRDT05GIHNl cnZlci4gIFRoZSBleGFjdCBzdHJpbmcgIk5FVENPTkYiIGlzIHVzZWQgZHVyaW5nCiAgIGFkdmVy dGlzZW1lbnQgb2Ygc3RyZWFtIHN1cHBvcnQgZHVyaW5nIHRoZSAmbHQ7Z2V0Jmd0OyBvcGVyYXRp b24gb24KICAgJmx0O3N0cmVhbXMmZ3Q7IGFuZCBkdXJpbmcgdGhlICZsdDtjcmVhdGUtc3Vic2Ny aXB0aW9uJmd0OyBvcGVyYXRpb24uICBEZWZpbml0aW9uCiAgIG9mIHRoZSBldmVudCBub3RpZmlj YXRpb25zIGFuZCB0aGVpciBjb250ZW50cywgYmV5b25kIHRoZSBpbmNsdXNpb24KICAgb2YgJmx0 O2V2ZW50VGltZSZndDssIGZvciB0aGlzIGV2ZW50IHN0cmVhbSBpcyBvdXRzaWRlIHRoZSBzY29w ZSBvZiB0aGlzCiAgIGRvY3VtZW50LgoKMy4yLjQuICBFdmVudCBTdHJlYW0gU291cmNlcwoKICAg V2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSBkZWZhdWx0IGV2ZW50IHN0cmVhbSAoTkVUQ09ORiks CiAgIHNwZWNpZmljYXRpb24gb2YgYWRkaXRpb25hbCBldmVudCBzdHJlYW0gc291cmNlcyAoZS5n LiwgU05NUCwgc3lzbG9nKQogICBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50 LiAgTkVUQ09ORiBzZXJ2ZXIKICAgaW1wbGVtZW50YXRpb25zIG1heSBsZXZlcmFnZSBhbnkgZGVz aXJlZCBldmVudCBzdHJlYW0gc291cmNlIGluIHRoZQogICBjcmVhdGlvbiBvZiBzdXBwb3J0ZWQg ZXZlbnQgc3RyZWFtcy4KCjMuMi41LiAgRXZlbnQgU3RyZWFtIERpc2NvdmVyeQoKICAgQSBORVRD T05GIGNsaWVudCByZXRyaWV2ZXMgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIGV2ZW50IHN0cmVhbXMg ZnJvbSBhCiAgIE5FVENPTkYgc2VydmVyIHVzaW5nIHRoZSAmbHQ7Z2V0Jmd0OyBvcGVyYXRpb24u CgozLjIuNS4xLiAgTmFtZSBSZXRyaWV2YWwgdXNpbmcgJmx0O2dldCZndDsgb3BlcmF0aW9uCgog ICBUaGUgbGlzdCBvZiBhdmFpbGFibGUgZXZlbnQgc3RyZWFtcyBpcyByZXRyaWV2ZWQgYnkgcmVx dWVzdGluZyB0aGUKICAgJmx0O3N0cmVhbXMmZ3Q7IHN1YnRyZWUgdmlhIGEgJmx0O2dldCZndDsg b3BlcmF0aW9uLiAgQXZhaWxhYmxlIGV2ZW50IHN0cmVhbXMgZm9yCiAgIHRoZSByZXF1ZXN0aW5n IHNlc3Npb24gYXJlIHJldHVybmVkIGluIHRoZSByZXBseSBjb250YWluaW5nIHRoZQogICAmbHQ7 bmFtZSZndDsgYW5kICZsdDtkZXNjcmlwdGlvbiZndDsgZWxlbWVudHMsIHdoZXJlIHRoZSAmbHQ7 bmFtZSZndDsgZWxlbWVudCBpcwogICBtYW5kYXRvcnksIGFuZCBpdHMgdmFsdWUgaXMgdW5pcXVl IHdpdGhpbiB0aGUgc2NvcGUgb2YgYSBORVRDT05GCiAgIHNlcnZlci4gIEFuIGVtcHR5IHJlcGx5 IGlzIHJldHVybmVkIGlmIHRoZXJlIGFyZSBubyBhdmFpbGFibGUgZXZlbnQKICAgc3RyZWFtcywg ZHVlIHRvIHVzZXItc3BlY2lmaWVkIGZpbHRlcnMgb24gdGhlICZsdDtnZXQmZ3Q7IG9wZXJhdGlv biAuCgogICBBZGRpdGlvbmFsIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhYm91dCBhIHN0cmVhbSBp bmNsdWRlIHdoZXRoZXIKICAgbm90aWZpY2F0aW9uIHJlcGxheSBpcyBhdmFpbGFibGUgYW5kIGlm IHNvLCB0aGUgdGltZXN0YW1wIG9mIHRoZQogICBlYXJsaWVzdCBwb3NzaWJsZSBub3RpZmljYXRp b24gdG8gcmVwbGF5LgoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHJldHJpZXZpbmcg dGhlIGxpc3Qgb2YgYXZhaWxhYmxlIGV2ZW50CiAgIHN0cmVhbSBsaXN0IHVzaW5nIHRoZSAmbHQ7 Z2V0Jmd0OyBvcGVyYXRpb24uCgogICAmbHQ7cnBjIG1lc3NhZ2UtaWQ9IjEwMSIKICAgICAgeG1s bnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCImZ3Q7CiAgICAgJmx0 O2dldCZndDsKICAgICAgJmx0O2ZpbHRlciB0eXBlPSJzdWJ0cmVlIiZndDsKICAgICAgICAmbHQ7 bmV0Y29uZiB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZpY2F0aW9u IiZndDsKICAgICAgICAgICAmbHQ7c3RyZWFtcy8mZ3Q7CiAgICAgICAgICZsdDsvbmV0Y29uZiZn dDsKICAgICAgJmx0Oy9maWx0ZXImZ3Q7CiAgICAgJmx0Oy9nZXQmZ3Q7CiAgICZsdDsvcnBjJmd0 OwogICBUaGUgTkVUQ09ORiBzZXJ2ZXIgcmV0dXJucyBhIGxpc3Qgb2YgZXZlbnQgc3RyZWFtcyBh dmFpbGFibGUgZm9yCiAgIHN1YnNjcmlwdGlvbjogTkVUQ09ORiwgU05NUCwgYW5kIHN5c2xvZy1j cml0aWNhbCBpbiB0aGlzIGV4YW1wbGUuCgogICAmbHQ7cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEw MSIKICAgICAgICAgICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIiZndDsKICAgICAmbHQ7ZGF0YSZndDsKICAgICAgICZsdDtuZXRjb25mICB4 bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZpY2F0aW9uIiZndDsKICAg ICAgICAmbHQ7c3RyZWFtcyZndDsKICAgICAgICAgI7c3RyZWFtJmd0OwogICAgICAgICAg ICAgICZsdDtuYW1lJmd0O05FVENPTkYmbHQ7L25hbWUmZ3Q7CiAgICAgICAgICAgICAgJmx0O2Rl c2NyaXB0aW9uJmd0O2RlZmF1bHQgTkVUQ09ORiBldmVudCBzdHJlYW0KICAgICAgICAgICAgICAm bHQ7L2Rlc2NyaXB0aW9uJmd0OwogICAgICAgICAgICAgICZsdDtyZXBsYXlTdXBwb3J0Jmd0O3Ry dWUmbHQ7L3JlcGxheVN1cHBvcnQmZ3Q7CiAgICAgICAgICAgICAgJmx0O3JlcGxheUxvZ0NyZWF0 aW9uVGltZSZndDsKICAgICAgICAgICAgICAgIDIwMDctMDctMDhUMDA6MDA6MDBaCiAgICAgICAg ICAgICAgJmx0Oy9yZXBsYXlMb2dDcmVhdGlvblRpbWUmZ3Q7CiAgICAgICAgICAgJmx0Oy9zdHJl YW0mZ3Q7CiAgICAgICAgICAgJmx0O3N0cmVhbSZndDsKICAgICAgICAgICAgICAmbHQ7bmFtZSZn dDtTTk1QJmx0Oy9uYW1lJmd0OwogICAgICAgICAgICAgICZsdDtkZXNjcmlwdGlvbiZndDtTTk1Q IG5vdGlmaWNhdGlvbnMmbHQ7L2Rlc2NyaXB0aW9uJmd0OwogICAgICAgICAgICAgICZsdDtyZXBs YXlTdXBwb3J0Jmd0O2ZhbHNlJmx0Oy9yZXBsYXlTdXBwb3J0Jmd0OwogICAgICAgICAgICZsdDsv c3RyZWFtJmd0OwogICAgICAgICAgICZsdDtzdHJlYW0mZ3Q7CiAgICAgICAgICAgICAmbHQ7bmFt ZSZndDtzeXNsb2ctY3JpdGljYWwmbHQ7L25hbWUmZ3Q7CiAgICAgICAgICAgICAmbHQ7ZGVzY3Jp cHRpb24mZ3Q7Q3JpdGljYWwgYW5kIGhpZ2hlciBzZXZlcml0eQogICAgICAgICAgICAgJmx0Oy9k ZXNjcmlwdGlvbiZndDsKICAgICAgICAgICAgICZsdDtyZXBsYXlTdXBwb3J0Jmd0O3RydWUmbHQ7 L3JlcGxheVN1cHBvcnQmZ3Q7CiAgICAgICAgICAgICAmbHQ7cmVwbGF5TG9nQ3JlYXRpb25UaW1l Jmd0OwogICAgICAgICAgICAgICAyMDA3LTA3LTAxVDAwOjAwOjAwWgogICAgICAgICAgICAgJmx0 Oy9yZXBsYXlMb2dDcmVhdGlvblRpbWUmZ3Q7CiAgICAgICAgICAgICZsdDsvc3RyZWFtJmd0Owog ICAgICAgICAgICZsdDsvc3RyZWFtcyZndDsKICAgICAgICAgJmx0Oy9uZXRjb25mJmd0OwogICAg ICZsdDsvZGF0YSZndDsKICAgJmx0Oy9ycGMtcmVwbHkmZ3Q7CgozLjIuNS4yLiAgRXZlbnQgU3Ry ZWFtIFN1YnNjcmlwdGlvbgoKICAgQSBORVRDT05GIGNsaWVudCBtYXkgcmVxdWVzdCBmcm9tIHRo ZSBORVRDT05GIHNlcnZlciB0aGUgbGlzdCBvZgogICBldmVudCBzdHJlYW1zIGF2YWlsYWJsZSB0 byB0aGlzIHNlc3Npb24gYW5kIHRoZW4gaXNzdWUgYSAmbHQ7Y3JlYXRlLQogICBzdWJzY3JpcHRp b24mZ3Q7IHJlcXVlc3Qgd2l0aCB0aGUgZGVzaXJlZCBldmVudCBzdHJlYW0gbmFtZS4gIE9taXR0 aW5nCiAgIHRoZSBldmVudCBzdHJlYW0gbmFtZSBmcm9tIHRoZSAmbHQ7Y3JlYXRlLXN1YnNjcmlw dGlvbiZndDsgcmVxdWVzdCByZXN1bHRzCiAgIGluIHN1YnNjcmlwdGlvbiB0byB0aGUgZGVmYXVs dCBORVRDT05GIGV2ZW50IHN0cmVhbS4KCjMuMi41LjIuMS4gIEZpbHRlcmluZyBFdmVudCBTdHJl YW0gQ29udGVudHMKCiAgIFRoZSBzZXQgb2YgZXZlbnQgbm90aWZpY2F0aW9ucyBkZWxpdmVyZWQg aW4gYW4gZXZlbnQgc3RyZWFtIG1heSBiZQogICBmdXJ0aGVyIHJlZmluZWQgYnkgYXBwbHlpbmcg YSB1c2VyLXNwZWNpZmllZCBmaWx0ZXIgc3VwcGxpZWQgYXQKICAgc3Vic2NyaXB0aW9uIGNyZWF0 aW9uIHRpbWUgKCAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsgKS4gIFRoaXMgaXMgYQogICB0 cmFuc2llbnQgZmlsdGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUgZXZlbnQgbm90aWZpY2F0aW9uIHN1 YnNjcmlwdGlvbgogICBhbmQgZG9lcyBub3QgbW9kaWZ5IHRoZSBldmVudCBzdHJlYW0gY29uZmln dXJhdGlvbi4gIFRoZSBmaWx0ZXIKICAgZWxlbWVudCBpcyBhcHBsaWVkIGFnYWluc3QgdGhlIGNv bnRlbnRzIG9mIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyB3cmFwcGVyCiAgIGFuZCBub3QgdGhl IHdyYXBwZXIgaXRzZWxmLiAgU2VlIHNlY3Rpb24gNSBmb3IgZXhhbXBsZXMuICBFaXRoZXIKICAg c3VidHJlZSBvciBYUEFUSCBmaWx0ZXJpbmcgY2FuIGJlIHVzZWQuCgogICBYUEFUSCBzdXBwb3J0 IGZvciB0aGUgTm90aWZpY2F0aW9uIGNhcGFiaWxpdHkgaXMgYWR2ZXJ0aXNlZCBhcyBwYXJ0CiAg IG9mIHRoZSBub3JtYWwgWFBBVEggY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50LiAgSWYgWFBBVEgg c3VwcG9ydCBpcwogICBhZHZlcnRpc2VkIHZpYSB0aGUgWFBBVEggY2FwYWJpbGl0eSB0aGVuIFhQ QVRIIGlzIHN1cHBvcnRlZCBmb3IKICAgbm90aWZpY2F0aW9uIGZpbHRlcmluZyBhbmQgaWYgdGhp cyBjYXBhYmlsaXR5IGlzIG5vdCBhZHZlcnRpc2VkLAogICBYUEFUSCBpcyBub3Qgc3VwcG9ydGVk IGZvciBub3RpZmljYXRpb24gZmlsdGVyaW5nLgoKMy4zLiAgIE5vdGlmaWNhdGlvbiBSZXBsYXkK CjMuMy4xLiAgT3ZlcnZpZXcKCiAgIFJlcGxheSBpcyB0aGUgYWJpbGl0eSB0byBjcmVhdGUgYW4g ZXZlbnQgc3Vic2NyaXB0aW9uIHRoYXQgd2lsbAogICByZXNlbmQgcmVjZW50bHkgZ2VuZXJhdGVk IG5vdGlmaWNhdGlvbnMsIG9yIGluIHNvbWUgY2FzZXMgc2VuZCB0aGVtCiAgIGZvciB0aGUgZmly c3QgdGltZSB0byBhIHBhcnRpY3VsYXIgTkVUQ09ORiBjbGllbnQuICBUaGVzZQogICBub3RpZmlj YXRpb25zIGFyZSBzZW50IHRoZSBzYW1lIHdheSBhcyBub3JtYWwgbm90aWZpY2F0aW9ucy4KCiAg IEEgcmVwbGF5IG9mIG5vdGlmaWNhdGlvbnMgaXMgc3BlY2lmaWVkIGJ5IGluY2x1ZGluZyB0aGUg b3B0aW9uYWwKICAgJmx0O3N0YXJ0VGltZSZndDsgcGFyYW1ldGVyIHRvIHRoZSBzdWJzY3JpcHRp b24gY29tbWFuZCwgd2hpY2ggaW5kaWNhdGVzCiAgIHRoZSBzdGFydCB0aW1lIG9mIHRoZSByZXBs YXkuICBUaGUgZW5kIHRpbWUgaXMgc3BlY2lmaWVkIHVzaW5nIHRoZQogICBvcHRpb25hbCAmbHQ7 c3RvcFRpbWUmZ3Q7IHBhcmFtZXRlci4gIElmIG5vdCBwcmVzZW50LCBub3RpZmljYXRpb25zIHdp bGwKICAgY29udGludWUgdG8gYmUgc2VudCB1bnRpbCB0aGUgc3Vic2NyaXB0aWCAmbHQ7c3RyZWFtJmd0OwogICAgICAgICAg ICAgICZsdDtuYW1lJmd0O05FVENPTkYmbHQ7L25hbWUmZ3Q7CiAgICAgICAgICAgICAgJmx0O2Rl c2NyaXB0aW9uJmd0O2RlZmF1bHQgTkVUQ09ORiBldmVudCBzdHJlYW0KICAgICAgICAgICAgICAm bHQ7L2Rlc2NyaXB0aW9uJmd0OwogICAgICAgICAgICAgICZsdDtyZXBsYXlTdXBwb3J0Jmd0O3Ry dWUmbHQ7L3JlcGxheVN1cHBvcnQmZ3Q7CiAgICAgICAgICAgICAgJmx0O3JlcGxheUxvZ0NyZWF0 aW9uVGltZSZndDsKICAgICAgICAgICAgICAgIDIwMDctMDctMDhUMDA6MDA6MDBaCiAgICAgICAg ICAgICAgJmx0Oy9yZXBsYXlMb2dDcmVhdGlvblRpbWUmZ3Q7CiAgICAgICAgICAgJmx0Oy9zdHJl YW0mZ3Q7CiAgICAgICAgICAgJmx0O3N0cmVhbSZndDsKICAgICAgICAgICAgICAmbHQ7bmFtZSZn dDtTTk1QJmx0Oy9uYW1lJmd0OwogICAgICAgICAgICAgICZsdDtkZXNjcmlwdGlvbiZndDtTTk1Q IG5vdGlmaWNhdGlvbnMmbHQ7L2Rlc2NyaXB0aW9uJmd0OwogICAgICAgICAgICAgICZsdDtyZXBs YXlTdXBwb3J0Jmd0O2ZhbHNlJmx0Oy9yZXBsYXlTdXBwb3J0Jmd0OwogICAgICAgICAgICZsdDsv c3RyZWFtJmd0OwogICAgICAgICAgICZsdDtzdHJlYW0mZ3Q7CiAgICAgICAgICAgICAmbHQ7bmFt ZSZndDtzeXNsb2ctY3JpdGljYWwmbHQ7L25hbWUmZ3Q7CiAgICAgICAgICAgICAmbHQ7ZGVzY3Jp cHRpb24mZ3Q7Q3JpdGljYWwgYW5kIGhpZ2hlciBzZXZlcml0eQogICAgICAgICAgICAgJmx0Oy9k ZXNjcmlwdGlvbiZndDsKICAgICAgICAgICAgICZsdDtyZXBsYXlTdXBwb3J0Jmd0O3RydWUmbHQ7 L3JlcGxheVN1cHBvcnQmZ3Q7CiAgICAgICAgICAgICAmbHQ7cmVwbGF5TG9nQ3JlYXRpb25UaW1l Jmd0OwogICAgICAgICAgICAgICAyMDA3LTA3LTAxVDAwOjAwOjAwWgogICAgICAgICAgICAgJmx0 Oy9yZXBsYXlMb2dDcmVhdGlvblRpbWUmZ3Q7CiAgICAgICAgICAgICZsdDsvc3RyZWFtJmd0Owog ICAgICAgICAgICZsdDsvc3RyZWFtcyZndDsKICAgICAgICAgJmx0Oy9uZXRjb25mJmd0OwogICAg ICZsdDsvZGF0YSZndDsKICAgJmx0Oy9ycGMtcmVwbHkmZ3Q7CgozLjIuNS4yLiAgRXZlbnQgU3Ry ZWFtIFN1YnNjcmlwdGlvbgoKICAgQSBORVRDT05GIGNsaWVudCBtYXkgcmVxdWVzdCBmcm9tIHRo ZSBORVRDT05GIHNlcnZlciB0aGUgbGlzdCBvZgogICBldmVudCBzdHJlYW1zIGF2YWlsYWJsZSB0 byB0aGlzIHNlc3Npb24gYW5kIHRoZW4gaXNzdWUgYSAmbHQ7Y3JlYXRlLQogICBzdWJzY3JpcHRp b24mZ3Q7IHJlcXVlc3Qgd2l0aCB0aGUgZGVzaXJlZCBldmVudCBzdHJlYW0gbmFtZS4gIE9taXR0 aW5nCiAgIHRoZSBldmVudCBzdHJlYW0gbmFtZSBmcm9tIHRoZSAmbHQ7Y3JlYXRlLXN1YnNjcmlw dGlvbiZndDsgcmVxdWVzdCByZXN1bHRzCiAgIGluIHN1YnNjcmlwdGlvbiB0byB0aGUgZGVmYXVs dCBORVRDT05GIGV2ZW50IHN0cmVhbS4KCjMuMi41LjIuMS4gIEZpbHRlcmluZyBFdmVudCBTdHJl YW0gQ29udGVudHMKCiAgIFRoZSBzZXQgb2YgZXZlbnQgbm90aWZpY2F0aW9ucyBkZWxpdmVyZWQg aW4gYW4gZXZlbnQgc3RyZWFtIG1heSBiZQogICBmdXJ0aGVyIHJlZmluZWQgYnkgYXBwbHlpbmcg YSB1c2VyLXNwZWNpZmllZCBmaWx0ZXIgc3VwcGxpZWQgYXQKICAgc3Vic2NyaXB0aW9uIGNyZWF0 aW9uIHRpbWUgKCAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsgKS4gIFRoaXMgaXMgYQogICB0 cmFuc2llbnQgZmlsdGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUgZXZlbnQgbm90aWZpY2F0aW9uIHN1 YnNjcmlwdGlvbgogICBhbmQgZG9lcyBub3QgbW9kaWZ5IHRoZSBldmVudCBzdHJlYW0gY29uZmln dXJhdGlvbi4gIFRoZSBmaWx0ZXIKICAgZWxlbWVudCBpcyBhcHBsaWVkIGFnYWluc3QgdGhlIGNv bnRlbnRzIG9mIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyB3cmFwcGVyCiAgIGFuZCBub3QgdGhl IHdyYXBwZXIgaXRzZWxmLiAgU2VlIHNlY3Rpb24gNSBmb3IgZXhhbXBsZXMuICBFaXRoZXIKICAg c3VidHJlZSBvciBYUEFUSCBmaWx0ZXJpbmcgY2FuIGJlIHVzZWQuCgogICBYUEFUSCBzdXBwb3J0 IGZvciB0aGUgTm90aWZpY2F0aW9uIGNhcGFiaWxpdHkgaXMgYWR2ZXJ0aXNlZCBhcyBwYXJ0CiAg IG9mIHRoZSBub3JtYWwgWFBBVEggY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50LiAgSWYgWFBBVEgg c3VwcG9ydCBpcwogICBhZHZlcnRpc2VkIHZpYSB0aGUgWFBBVEggY2FwYWJpbGl0eSB0aGVuIFhQ QVRIIGlzIHN1cHBvcnRlZCBmb3IKICAgbm90aWZpY2F0aW9uIGZpbHRlcmluZyBhbmQgaWYgdGhp cyBjYXBhYmlsaXR5IGlzIG5vdCBhZHZlcnRpc2VkLAogICBYUEFUSCBpcyBub3Qgc3VwcG9ydGVk IGZvciBub3RpZmljYXRpb24gZmlsdGVyaW5nLgoKMy4zLiAgIE5vdGlmaWNhdGlvbiBSZXBsYXkK CjMuMy4xLiAgT3ZlcnZpZXcKCiAgIFJlcGxheSBpcyB0aGUgYWJpbGl0eSB0byBjcmVhdGUgYW4g ZXZlbnQgc3Vic2NyaXB0aW9uIHRoYXQgd2lsbAogICByZXNlbmQgcmVjZW50bHkgZ2VuZXJhdGVk IG5vdGlmaWNhdGlvbnMsIG9yIGluIHNvbWUgY2FzZXMgc2VuZCB0aGVtCiAgIGZvciB0aGUgZmly c3QgdGltZSB0byBhIHBhcnRpY3VsYXIgTkVUQ09ORiBjbGllbnQuICBUaGVzZQogICBub3RpZmlj YXRpb25zIGFyZSBzZW50IHRoZSBzYW1lIHdheSBhcyBub3JtYWwgbm90aWZpY2F0aW9ucy4KCiAg IEEgcmVwbGF5IG9mIG5vdGlmaWNhdGlvbnMgaXMgc3BlY2lmaWVkIGJ5IGluY2x1ZGluZyB0aGUg b3B0aW9uYWwKICAgJmx0O3N0YXJ0VGltZSZndDsgcGFyYW1ldGVyIHRvIHRoZSBzdWJzY3JpcHRp b24gY29tbWFuZCwgd2hpY2ggaW5kaWNhdGVzCiAgIHRoZSBzdGFydCB0aW1lIG9mIHRoZSByZXBs YXkuICBUaGUgZW5kIHRpbWUgaXMgc3BlY2lmaWVkIHVzaW5nIHRoZQogICBvcHRpb25hbCAmbHQ7 c3RvcFRpbWUmZ3Q7IHBhcmFtZXRlci4gIElmIG5vdCBwcmVzZW50LCBub3RpZmljYXRpb25zIHdp bGwKICAgY29udGludWUgdG8gYmUgc2VudCB1bnRpbCB0aGUgc3Vic2Ny9uIGlzIHRlcm1p bmF0ZWQuCgogICBBIG5vdGlmaWNhdGlvbiBzdHJlYW0gdGhhdCBzdXBwb3J0cyByZXBsYXkgaXMg bm90IGV4cGVjdGVkIHRvIGhhdmUgYW4KICAgdW5saW1pdGVkIHN1cHBseSBvZiBzYXZlZCBub3Rp ZmljYXRpb25zIGF2YWlsYWJsZSB0byBhY2NvbW1vZGF0ZSBhbnkKICAgcmVwbGF5IHJlcXVlc3Qu ICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Q2xpZW50cyBjYW4gcXVlcnkgJmx0O3JlcGxh eUxvZ0NyZWF0aW9uVGltZSZndDsgYW5kCiAgICZsdDtyZXBsYXlMb2dBZ2VkVGltZSZndDsgdG8g bGVhcm4gYWJvdXQgdGhlIGF2YWlsYWJpbGl0eSBvZiBub3RpZmljYXRpb25zCiAgIGZvciByZXBs YXkuPC9mb250Pjwvc3Ryb25nPgoKICAgVGhlIGFjdHVhbCBudW1iZXIgb2Ygc3RvcmVkIG5vdGlm aWNhdGlvbnMgYXZhaWxhYmxlIGZvciByZXRyaWV2YWwgYXQKICAgYW55IGdpdmVuIHRpbWUgaXMg YSBORVRDT05GIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBtYXR0ZXIuCiAgIENvbnRy b2wgcGFyYW1ldGVycyBmb3IgdGhpcyBhc3BlY3Qgb2YgdGhlIGZlYXR1cmUgYXJlIG91dHNpZGUg dGhlCiAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgogICBSZXBsYXkgaXMgZGVwZW5kZW50IG9u IGEgbm90aWZpY2F0aW9uIHN0cmVhbSBzdXBwb3J0aW5nIHNvbWUgZm9ybSBvZgogICBub3RpZmlj YXRpb24gbG9nZ2luZywgYWx0aG91Z2ggaXQgcHV0cyBubyByZXN0cmljdGlvbnMgb24gdGhlIHNp emUgb3IKICAgZm9ybSBvZiB0aGUgbG9nLCBvciB3aGVyZSBpdCByZXNpZGVzIHdpdGhpbiB0aGUg ZGV2aWNlLiAgV2hldGhlciBvcgogICBub3QgYSBzdHJlYW0gc3VwcG9ydHMgcmVwbGF5IGNhbiBi ZSBkaXNjb3ZlcmVkIGJ5IGRvaW5nIGEgJmx0O2dldCZndDsKICAgb3BlcmF0aW9uIG9uIHRoZSAm bHQ7c3RyZWFtcyZndDsgZWxlbWVudCBvZiB0aGUgTm90aWZpY2F0aW9uIE1hbmFnZW1lbnQKICAg U2NoZW1hIGFuZCBsb29raW5nIGF0IHRoZSB2YWx1ZSBvZiB0aGUgJmx0O3JlcGxheVN1cHBvcnQm Z3Q7IG9iamVjdC4gIFRoaXMKICAgc2NoZW1hIGFsc28gcHJvdmlkZXMgdGhlICZsdDtyZXBsYXlM b2dDcmVhdGlvblRpbWUmZ3Q7IGVsZW1lbnQgdG8gaW5kaWNhdGUKICAgdGhlIGVhcmxpZXN0IGF2 YWlsYWJsZSBsb2dnZWQgbm90aWZpY2F0aW9uLgoKMy4zLjIuICBDcmVhdGluZyBhIFN1YnNjcmlw dGlvbiB3aXRoIFJlcGxheQoKICAgVGhpcyBmZWF0dXJlIHVzZXMgb3B0aW9uYWwgcGFyYW1ldGVy cyB0byB0aGUgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiAgIGNvbW1hbmQgY2FsbGVkICZs dDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7c3RvcFRpbWUmZ3Q7LiAmbHQ7c3RhcnRUaW1lJmd0OyBp ZGVudGlmaWVzIHRoZQogICBlYXJsaWVzdCBkYXRlIGFuZCB0aW1lIG9mIGludGVyZXN0IGZvciBl dmVudCBub3RpZmljYXRpb25zIGJlaW5nCiAgIHJlcGxheWVkIGFuZCBhbHNvIGluZGljYXRlcyB0 aGF0IGEgc3Vic2NyaXB0aW9uIHdpbGwgYmUgcHJvdmlkaW5nCiAgIHJlcGxheSBvZiBub3RpZmlj YXRpb25zLiAgRXZlbnRzIGdlbmVyYXRlZCBiZWZvcmUgdGhpcyB0aW1lIGFyZSBub3QKICAgbWF0 Y2hlZC4gJmx0O3N0b3BUaW1lJmd0OyBzcGVjaWZpZXMgdGhlIGxhdGVzdCBkYXRlIGFuZCB0aW1l IG9mIGludGVyZXN0CiAgIGZvciBldmVudCBub3RpZmljYXRpb25zIGJlaW5nIHJlcGxheWVkLiAg SWYgaXQgaXMgbm90IHByZXNlbnQsIHRoZW4KICAgbm90aWZpY2F0aW9ucyB3aWxsIGNvbnRpbnVl IHRvIGJlIHNlbnQgdW50aWwgdGhlIHN1YnNjcmlwdGlvbiBpcwogICB0ZXJtaW5hdGVkLgoKICAg Tm90ZSB0aGF0ICZsdDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7c3RvcFRpbWUmZ3Q7IGFyZSBhc3Nv Y2lhdGVkIHdpdGggdGhlIHRpbWUgYW4KICAgZXZlbnQgd2FzIGdlbmVyYXRlZCBieSB0aGUgZXZl bnQgc291cmNlLgoKICAgQSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbiBpcyBz ZW50IHRvIGluZGljYXRlIHRoYXQgYWxsIG9mIHRoZQogICByZXBsYXkgbm90aWZpY2F0aW9ucyBo YXZlIGJlZW4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5zZW50LjwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnNlbnQgYW5kIG11c3Qgbm90IGJlIHNlbnQgZm9y IGFueQogICBvdGhlciByZWFzb24uPC9mb250Pjwvc3Ryb25nPiAgSWYgdGhpcyBzdWJzY3JpcHRp b24gaGFzIGEgc3RvcCB0aW1lLCB0aGVuIHRoaXMKICAgc2Vzc2lvbiBiZWNvbWVzIGEgbm9ybWFs IE5FVENPTkYgc2Vzc2lvbiBhZ2Fpbi4gIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+V2hlbgog ICBhICZsdDtzdG9wVGltZSZndDsgaGFzIGJlZW4gc3BlY2lmaWVkLCAmbHQ7bm90aWZpY2F0aW9u Q29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbgogICBpcyB0aGUgbGFzdCBub3RpZmljYXRpb24gc2Vu dCBvbiB0aGUgc3Vic2NyaXB0aW9uIGJlZm9yZSBpdAogICB0ZXJtaW5hdGVzIGFuZCB0aGUgTkVU Q09ORiBzZXNzaW9uIHJldHVybnMgdG8gYmVpbmcgYSBub3JtYWwgTkVUQ09ORgogICBzZXNzaW9u LjwvZm9udD48L3N0cmlrZT4gIFRoZSBORVRDT05GIHNlcnZlcgogICB3aWxsIHRoZW4gYWNjZXB0 ICZsdDtycGMmZ3Q7IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+b3BlcmF0aW9ucy48L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5vcGVyYXRpb25zIGV2ZW4gaWYg dGhlIHNlcnZlciBkaWQgbm90CiAgIHByZXZpb3VzbHkgYWNjZXB0IHN1Y2ggb3BlcmF0aW9ucyBk dWUgdG8gbGFjayBvZiBpbnRlcmxlYXZlIHN1cHBvcnQuPC9mb250Pjwvc3Ryb25nPgogICBJbiB0 aGUgY2FzZSBvZiBhIHN1YnNjcmlwdGlvbiB3aXRob3V0IGEgc3RvcCB0aW1lLCBhZnRlciB0aGUK ICAgJmx0O3JlcGxheUNvbXBsZXRlJmd0OyBub3RpZmljYXRpb24gaGFzIGJlZW4gc2VudCwgaXQg Y2FuIGJlIGV4cGVjdGVkIHRoYXQKICAgYW55IG5vdGlmaWNhdGlvbnMgZ2VuZXJhdGVkIHNpbmNl aXB0aW9uIGlzIHRlcm1p bmF0ZWQuCgogICBBIG5vdGlmaWNhdGlvbiBzdHJlYW0gdGhhdCBzdXBwb3J0cyByZXBsYXkgaXMg bm90IGV4cGVjdGVkIHRvIGhhdmUgYW4KICAgdW5saW1pdGVkIHN1cHBseSBvZiBzYXZlZCBub3Rp ZmljYXRpb25zIGF2YWlsYWJsZSB0byBhY2NvbW1vZGF0ZSBhbnkKICAgcmVwbGF5IHJlcXVlc3Qu ICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Q2xpZW50cyBjYW4gcXVlcnkgJmx0O3JlcGxh eUxvZ0NyZWF0aW9uVGltZSZndDsgYW5kCiAgICZsdDtyZXBsYXlMb2dBZ2VkVGltZSZndDsgdG8g bGVhcm4gYWJvdXQgdGhlIGF2YWlsYWJpbGl0eSBvZiBub3RpZmljYXRpb25zCiAgIGZvciByZXBs YXkuPC9mb250Pjwvc3Ryb25nPgoKICAgVGhlIGFjdHVhbCBudW1iZXIgb2Ygc3RvcmVkIG5vdGlm aWNhdGlvbnMgYXZhaWxhYmxlIGZvciByZXRyaWV2YWwgYXQKICAgYW55IGdpdmVuIHRpbWUgaXMg YSBORVRDT05GIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBtYXR0ZXIuCiAgIENvbnRy b2wgcGFyYW1ldGVycyBmb3IgdGhpcyBhc3BlY3Qgb2YgdGhlIGZlYXR1cmUgYXJlIG91dHNpZGUg dGhlCiAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgogICBSZXBsYXkgaXMgZGVwZW5kZW50IG9u IGEgbm90aWZpY2F0aW9uIHN0cmVhbSBzdXBwb3J0aW5nIHNvbWUgZm9ybSBvZgogICBub3RpZmlj YXRpb24gbG9nZ2luZywgYWx0aG91Z2ggaXQgcHV0cyBubyByZXN0cmljdGlvbnMgb24gdGhlIHNp emUgb3IKICAgZm9ybSBvZiB0aGUgbG9nLCBvciB3aGVyZSBpdCByZXNpZGVzIHdpdGhpbiB0aGUg ZGV2aWNlLiAgV2hldGhlciBvcgogICBub3QgYSBzdHJlYW0gc3VwcG9ydHMgcmVwbGF5IGNhbiBi ZSBkaXNjb3ZlcmVkIGJ5IGRvaW5nIGEgJmx0O2dldCZndDsKICAgb3BlcmF0aW9uIG9uIHRoZSAm bHQ7c3RyZWFtcyZndDsgZWxlbWVudCBvZiB0aGUgTm90aWZpY2F0aW9uIE1hbmFnZW1lbnQKICAg U2NoZW1hIGFuZCBsb29raW5nIGF0IHRoZSB2YWx1ZSBvZiB0aGUgJmx0O3JlcGxheVN1cHBvcnQm Z3Q7IG9iamVjdC4gIFRoaXMKICAgc2NoZW1hIGFsc28gcHJvdmlkZXMgdGhlICZsdDtyZXBsYXlM b2dDcmVhdGlvblRpbWUmZ3Q7IGVsZW1lbnQgdG8gaW5kaWNhdGUKICAgdGhlIGVhcmxpZXN0IGF2 YWlsYWJsZSBsb2dnZWQgbm90aWZpY2F0aW9uLgoKMy4zLjIuICBDcmVhdGluZyBhIFN1YnNjcmlw dGlvbiB3aXRoIFJlcGxheQoKICAgVGhpcyBmZWF0dXJlIHVzZXMgb3B0aW9uYWwgcGFyYW1ldGVy cyB0byB0aGUgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiAgIGNvbW1hbmQgY2FsbGVkICZs dDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7c3RvcFRpbWUmZ3Q7LiAmbHQ7c3RhcnRUaW1lJmd0OyBp ZGVudGlmaWVzIHRoZQogICBlYXJsaWVzdCBkYXRlIGFuZCB0aW1lIG9mIGludGVyZXN0IGZvciBl dmVudCBub3RpZmljYXRpb25zIGJlaW5nCiAgIHJlcGxheWVkIGFuZCBhbHNvIGluZGljYXRlcyB0 aGF0IGEgc3Vic2NyaXB0aW9uIHdpbGwgYmUgcHJvdmlkaW5nCiAgIHJlcGxheSBvZiBub3RpZmlj YXRpb25zLiAgRXZlbnRzIGdlbmVyYXRlZCBiZWZvcmUgdGhpcyB0aW1lIGFyZSBub3QKICAgbWF0 Y2hlZC4gJmx0O3N0b3BUaW1lJmd0OyBzcGVjaWZpZXMgdGhlIGxhdGVzdCBkYXRlIGFuZCB0aW1l IG9mIGludGVyZXN0CiAgIGZvciBldmVudCBub3RpZmljYXRpb25zIGJlaW5nIHJlcGxheWVkLiAg SWYgaXQgaXMgbm90IHByZXNlbnQsIHRoZW4KICAgbm90aWZpY2F0aW9ucyB3aWxsIGNvbnRpbnVl IHRvIGJlIHNlbnQgdW50aWwgdGhlIHN1YnNjcmlwdGlvbiBpcwogICB0ZXJtaW5hdGVkLgoKICAg Tm90ZSB0aGF0ICZsdDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7c3RvcFRpbWUmZ3Q7IGFyZSBhc3Nv Y2lhdGVkIHdpdGggdGhlIHRpbWUgYW4KICAgZXZlbnQgd2FzIGdlbmVyYXRlZCBieSB0aGUgZXZl bnQgc291cmNlLgoKICAgQSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbiBpcyBz ZW50IHRvIGluZGljYXRlIHRoYXQgYWxsIG9mIHRoZQogICByZXBsYXkgbm90aWZpY2F0aW9ucyBo YXZlIGJlZW4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5zZW50LjwvZm9udD48L3N0cmlrZT4g PHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnNlbnQgYW5kIG11c3Qgbm90IGJlIHNlbnQgZm9y IGFueQogICBvdGhlciByZWFzb24uPC9mb250Pjwvc3Ryb25nPiAgSWYgdGhpcyBzdWJzY3JpcHRp b24gaGFzIGEgc3RvcCB0aW1lLCB0aGVuIHRoaXMKICAgc2Vzc2lvbiBiZWNvbWVzIGEgbm9ybWFs IE5FVENPTkYgc2Vzc2lvbiBhZ2Fpbi4gIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+V2hlbgog ICBhICZsdDtzdG9wVGltZSZndDsgaGFzIGJlZW4gc3BlY2lmaWVkLCAmbHQ7bm90aWZpY2F0aW9u Q29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbgogICBpcyB0aGUgbGFzdCBub3RpZmljYXRpb24gc2Vu dCBvbiB0aGUgc3Vic2NyaXB0aW9uIGJlZm9yZSBpdAogICB0ZXJtaW5hdGVzIGFuZCB0aGUgTkVU Q09ORiBzZXNzaW9uIHJldHVybnMgdG8gYmVpbmcgYSBub3JtYWwgTkVUQ09ORgogICBzZXNzaW9u LjwvZm9udD48L3N0cmlrZT4gIFRoZSBORVRDT05GIHNlcnZlcgogICB3aWxsIHRoZW4gYWNjZXB0 ICZsdDtycGMmZ3Q7IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+b3BlcmF0aW9ucy48L2ZvbnQ+ PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5vcGVyYXRpb25zIGV2ZW4gaWYg dGhlIHNlcnZlciBkaWQgbm90CiAgIHByZXZpb3VzbHkgYWNjZXB0IHN1Y2ggb3BlcmF0aW9ucyBk dWUgdG8gbGFjayBvZiBpbnRlcmxlYXZlIHN1cHBvcnQuPC9mb250Pjwvc3Ryb25nPgogICBJbiB0 aGUgY2FzZSBvZiBhIHN1YnNjcmlwdGlvbiB3aXRob3V0IGEgc3RvcCB0aW1lLCBhZnRlciB0aGUK ICAgJmx0O3JlcGxheUNvbXBsZXRlJmd0OyBub3RpZmljYXRpb24gaGFzIGJlZW4gc2VudCwgaXQg Y2FuIGJlIGV4cGVjdGVkIHRoYXQKICAgYW55IG5vdGlmaWNhdGlvbnMgZ2VuZXJhdGVkIHNIHRoZSBzdGFydCBvZiB0aGUgc3Vic2NyaXB0aW9uCiAgIGNyZWF0aW9uIHdpbGwgYmUgc2VudCwg Zm9sbG93ZWQgYnkgbm90aWZpY2F0aW9ucyBhcyB0aGV5IGFyaXNlCiAgIG5hdHVyYWxseSB3aXRo aW4gdGhlIHN5c3RlbS4KCiAgIFRoZSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IGFuZCAmbHQ7bm90 aWZpY2F0aW9uQ29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbnMgY2Fubm90CiAgIGJlIGZpbHRlcmVk IG91dC4gIFRoZXkgd2lsbCBhbHdheXMgYmUgc2VudCBvbiBhIHJlcGxheSBzdWJzY3JpcHRpb24K ICAgdGhhdCBzcGVjaWZpZWQgYSBzdGFydFRpbWUgYW5kIHN0b3BUaW1lIHJlc3BlY3RpdmVseS4K CjMuNC4gIE5vdGlmaWNhdGlvbiBNYW5hZ2VtZW50IFNjaGVtYQoKICAgVGhpcyBTY2hlbWEgaXMg dXNlZCB0byBsZWFybiBhYm91dCB0aGUgZXZlbnQgc3RyZWFtcyBzdXBwb3J0ZWQgb24gdGhlCiAg IHN5c3RlbS4gIEl0IGFsc28gY29udGFpbnMgdGhlIGRlZmluaXRpb24gb2YgdGhlICZsdDtyZXBs YXlDb21wbGV0ZSZndDsgYW5kCiAgICZsdDtub3RpZmljYXRpb25Db21wbGV0ZSZndDsgbm90aWZp Y2F0aW9ucywgd2hpY2ggYXJlIHNlbnQgdG8gaW5kaWNhdGUgdGhhdAogICBhbiBldmVudCByZXBs YXkgaGFzIHNlbnQgYWxsIGFwcGxpY2FibGUgbm90aWZpY2F0aW9ucyBhbmQgdGhhdCB0aGUKICAg c3Vic2NyaXB0aW9uIGhhcyB0ZXJtaW5hdGVkLCByZXNwZWN0aXZlbHkuCgombHQ7P3htbCB2ZXJz aW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0OwombHQ7eHM6c2NoZW1hIHhtbG5zOnhzPSJo dHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIKICAgIHhtbG5zOm5ldGNvbmY9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIKICAgIHhtbG5zOm5jRXZlbnQ9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIgogICAgeG1sbnM6 bWFuYWdlRXZlbnQ9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0bW9kOm5vdGlmaWNhdGlvbiIK ICAgIHRhcmdldE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZp Y2F0aW9uIgogICAgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZpZWQiCiAgICBhdHRyaWJ1dGVG b3JtRGVmYXVsdD0idW5xdWFsaWZpZWQiCiAgICB4bWw6bGFuZz0iZW4iIHZlcnNpb249IjEuMCIm Z3Q7CiAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlv biB4bWw6bGFuZz0iZW4iJmd0OwogICAgICAgICAgICBBIHNjaGVtYSB0aGF0IGNhbiBiZSB1c2Vk IHRvIGxlYXJuIGFib3V0IGN1cnJlbnQKICAgICAgICAgICAgZXZlbnQgc3RyZWFtcy4gSXQgYWxz byBjb250YWlucyB0aGUgcmVwbGF5Q29tcGxldGUKICAgICAgICAgICAgYW5kIG5vdGlmaWNhdGlv bkNvbXBsZXRlICBub3RpZmljYXRpb24uCiAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0 OwogICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwoKJmx0O3hzOmltcG9ydCBuYW1lc3BhY2U9Imh0 dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4L25hbWVzcGFjZSIKICAgICAgICBzY2hlbWFMb2NhdGlv bj0iaHR0cDovL3d3dy53My5vcmcvMjAwMS94bWwueHNkIi8mZ3Q7CiZsdDt4czppbXBvcnQgbmFt ZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiCiAgICA8c3Ry aWtlPjxmb250IGNvbG9yPSdyZWQnPnNjaGVtYUxvY2F0aW9uPQogICAgICJodHRwOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbmV0Y29uZi54c2QiLyZndDs8 L2ZvbnQ+PC9zdHJpa2U+CiAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+c2NoZW1hTG9j YXRpb249Im5ldGNvbmYueHNkIi8mZ3Q7PC9mb250Pjwvc3Ryb25nPgombHQ7eHM6aW1wb3J0IG5h bWVzcGFjZT0KICAgICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9u OjEuMCIKICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5zY2hlbWFMb2NhdGlvbj0KImh0 dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lzdHJ5L3NjaGVtYS9ub3RpZmlj YXRpb24ueHNkIi8mZ3Q7PC9mb250Pjwvc3RyaWtlPgogICAgICA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+c2NoZW1hTG9jYXRpb249Im5vdGlmaWNhdGlvbi54c2QiLyZndDs8L2ZvbnQ+PC9z dHJvbmc+CiZsdDshLS0gVGhlIGFib3ZlICBzY2hlbWFMb2NhdGlvbiB2YWx1ZSBpcyBhIHBsYWNl aG9sZGVyIGFuZCB0aGUgYWN0dWFsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdmFsdWUgd2lsbCBiZSBhc3NpZ25lZCBieSBJQU5BIC0tJmd0OwoKJmx0O3hzOmVsZW1lbnQg bmFtZT0ibmV0Y29uZiIgdHlwZT0ibWFuYWdlRXZlbnQ6TmV0Y29uZiIvJmd0OwoKJmx0O3hzOmNv bXBsZXhUeXBlIG5hbWU9Ik5ldGNvbmYiJmd0OwogICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAg Jmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtcyIgJmd0OwogICAgICAgICZsdDt4czphbm5vdGF0 aW9uJmd0OwogICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAg VGhlIGxpc3Qgb2YgZXZlbnQgc3RyZWFtcyBzdXBwb3J0ZWQgYnkgdGhlCiAgICAgICAgICAgICBz eXN0ZW0uIFdoZW4gYSBxdWVyeSBpcyBpc3N1ZWQsIHRoZSByZXR1cm5lZAogICAgICAgICAgICAg c2V0IG9mIHN0cmVhbXMgaXMgZGV0ZXJtaW5lZCBiYXNlZCBvbiB1c2VyCiAgICAgICAgICAgICBw cml2aWxlZ2VzLgogICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAg Jmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAg ICAgICAgICAgJmx0O3hzOnNlcXVlbmNlIG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSJ1bmJvdW5k ZWQiJmd0OwogICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtIiZndDsKICAg ICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAmbHQ7 eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICBTdHJlYW0gbmFtZSwgZGVz Y3JpcHRpb24gYW5kIG90aGVyIGluZm9ybWF0aW9uLgogICAgICAgICAgICAgICAgICAmbHQ7L3hz OmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7 CiAgICAgICAgICAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICAgICAgICAgICAg ICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBu YW1lPSJuYW1lIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0ibmNFdmVudDpzdHJl YW1OYW1lVHlwZSImZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRpb24m Z3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgVGhlIG5hbWUgb2YgdGhlIGV2ZW50IHN0cmVhbS4gSWYg dGhpcyBpcwogICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZGVmYXVsdCBORVRDT05GIHN0 cmVhbSwgdGhpcyBtdXN0IGhhdmUKICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHZhbHVl ICJORVRDT05GIi4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlv biZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAg ICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAgICZs dDt4czplbGVtZW50IG5hbWU9ImRlc2NyaXB0aW9uIgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdHlwZT0ieHM6c3RyaW5nIiZndDsKICAgICAgICAgICAgICAgICAgICAg ICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICZsdDt4czpk b2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICBBIGRlc2NyaXB0aW9u IG9mIHRoZSBldmVudCBzdHJlYW0sIGluY2x1ZGluZwogICAgICAgICAgICAgICAgICAgICAgICAg ICBzdWNoIGluZm9ybWF0aW9uIGFzIHRoZSB0eXBlIG9mIGV2ZW50cyB0aGF0CiAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFyZSBzZW50IG92ZXIgdGhpcyBzdHJlYW0uCiAgICAgICAgICAgICAg ICAgICAgICAgICAmbHQ7L3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAg ICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxl bWVudCZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBsYXlT dXBwb3J0IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0ieHM6 Ym9vbGVhbiImZ3Q7CiAgICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0Owog ICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFuIGluZGljYXRpb24gb2Ygd2hldGhlciBvciBub3QgZXZlbnQg cmVwbGF5CiAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIGF2YWlsYWJsZSBvbiB0aGlzIHN0 cmVhbS4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsK ICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAg ICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAgICZsdDt4czpl bGVtZW50IG5hbWU9InJlcGxheUxvZ0NyZWF0aW9uVGltZSIKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB0eXBlPSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiZndDsKICAgICAg ICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICBUaGUg dGltZXN0YW1wIG9mIHRoZSBjcmVhdGlvbiBvZiB0aGUgbG9nCiAgICAgICAgICAgICAgICAgICAg ICAgdXNlZCB0byBzdXBwb3J0IHRoZSByZXBsYXkgZnVuY3Rpb24gb24KICAgICAgICAgICAgICAg ICAgICAgICB0aGlzIHN0cmVhbS4KICAgICAgICAgICAgICAgICAgICAgICBOb3RlIHRoYXQgdGhp cyBtaWdodCBiZSBlYXJsaWVyIHRoZW4KICAgICAgICAgICAgICAgICAgICAgICB0aGUgZWFybGll c3QgYXZhaWxhYmxlCiAgICAgICAgICAgICAgICAgICAgICAgbm90aWZpY2F0aW9uIGluIHRoZSBs b2cuIFRoaXMgb2JqZWN0CiAgICAgICAgICAgICAgICAgICAgICAgaXMgdXBkYXRlZCBpZiB0aGUg bG9nIHJlc2V0cwogICAgICAgICAgICAgICAgICAgICAgIGZvciBzb21lIHJlYXNvbi4gVGhpcwog ICAgICAgICAgICAgICAgICAgICAgIG9iamVjdCBNVVNUIGJlIHByZXNlbnQgaWYgcmVwbGF5IGlz CiAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkLgogICAgICAgICAgICAgICAgICAgICAg ICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICZsdDsv eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0 OwogICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBsYXlMb2dBZ2Vk VGltZSIKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGU9InhzOmRhdGVUaW1lIiBtaW5P Y2N1cnM9IjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0 OwogICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAg ICAgICAgICAgICAgICAgICAgICAgIFRoZSB0aW1lc3RhbXAgb2YgdGhlIGxhc3Qgbm90aWZpY2F0 aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGFnZWQgb3V0IG9mIHRoZSBsb2cuIFRoaXMK ICAgICAgICAgICAgICAgICAgICAgICAgICAgb2JqZWN0IE1VU1QgYmUgcHJlc2VudCBpZiByZXBs YXkgaXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkIGFuZCBhbnkgbm90aWZp Y2F0aW9ucwogICAgICAgICAgICAgICAgICAgICAgICAgICBoYXZlIGJlZW4gYWdlZCBvdXQgb2Yg dGhlIGxvZy4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZn dDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAg ICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAgICAgICAgICAgICZsdDsv eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsK ICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgJmx0Oy94czpz ZXF1ZW5jZSZndDsKICAgICAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICAgICAgICAm bHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAgJmx0Oy94czpj b21wbGV4VHlwZSZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iUmVwbGF5Q29tcGxl dGVOb3RpZmljYXRpb25UeXBlIiZndDsKICAgICAgICAmbHQ7eHM6Y29tcGxleENvbnRlbnQmZ3Q7 CiAgICAgICAgICAgICZsdDt4czpleHRlbnNpb24gYmFzZT0ibmNFdmVudDpOb3RpZmljYXRpb25D b250ZW50VHlwZSIvJmd0OwogICAgICAgICZsdDsveHM6Y29tcGxleENvbnRlbnQmZ3Q7CiAgICAm bHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwoKICAgICZsdDt4czplbGVtZW50IG5hbWU9InJlcGxheUNv bXBsZXRlIgogICAgICAgIHR5cGU9Im1hbmFnZUV2ZW50OlJlcGxheUNvbXBsZXRlTm90aWZpY2F0 aW9uVHlwZSIKICAgICAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmNFdmVudDpub3RpZmljYXRpb25D b250ZW50IiZndDsKICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAg ICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgIFRoaXMgbm90aWZpY2F0aW9u IGlzIHNlbnQgdG8gc2lnbmFsIHRoZSBlbmQgb2YgYSByZXBsYXkKICAgICAgICAgICAgcG9ydGlv biBvZiBhIHN1YnNjcmlwdGlvbi4KICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsK ICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0 OwoKICAgICZsdDt4czpjb21wbGV4VHlwZSBuYW1lPSJOb3RpZmljYXRpb25Db21wbGV0ZU5vdGlm aWNhdGlvblR5cGUiJmd0OwogICAgICAgICZsdDt4czpjb21wbGV4Q29udGVudCZndDsKICAgICAg ICAgICAgJmx0O3hzOmV4dGVuc2lvbiBiYXNlPSJuY0V2ZW50Ok5vdGlmaWNhdGlvbkNvbnRlbnRU eXBlIi8mZ3Q7CiAgICAgICAgJmx0Oy94czpjb21wbGV4Q29udGVudCZndDsKICAgICZsdDsveHM6 Y29tcGxleFR5cGUmZ3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibm90aWZpY2F0aW9uQ29t cGxldGUiCiAgICAgICAgdHlwZT0ibWFuYWdlRXZlbnQ6Tm90aWZpY2F0aW9uQ29tcGxldGVOb3Rp ZmljYXRpb25UeXBlIgogICAgICAgIHN1YnN0aXR1dGlvbkdyb3VwPSJuY0V2ZW50Om5vdGlmaWNh dGlvbkNvbnRlbnQiJmd0OwogICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAg ICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgVGhpcyBub3RpZmlj YXRpb24gaXMgc2VudCB0byBzaWduYWwgdGhlIGVuZCBvZiBhCiAgICAgICAgICAgIG5vdGlmaWNh dGlvbiBzdWJzY3JpcHRpb24uIEl0IGlzIHNlbnQgaW4gdGhlIGNhc2UKICAgICAgICAgICAgdGhh dCBzdG9wVGltZSB3YXMgc3BlY2lmaWVkIGR1cmluZyB0aGUgY3JlYXRpb24gb2YKICAgICAgICAg ICAgdGhlIHN1YnNjcmlwdGlvbi4KICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsK ICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0 OwoKJmx0Oy94czpzY2hlbWEmZ3Q7CgozLjUuICBTdWJzY3JpcHRpb25zIERhdGEKCiAgIFN1YnNj cmlwdGlvbnMgYXJlIG5vbi1wZXJzaXN0ZW50IHN0YXRlIGluZm9ybWF0aW9uIGFuZCB0aGVpciBs aWZldGltZQogICBpcyBkZWZpbmVkIGJ5IHRoZWlyIHNlc3Npb24gb3IgYnkgdGhlICZsdDtzdG9w VGltZSZndDsgcGFyYW1ldGVyLgoKMy42LiAgRmlsdGVyIE1lY2hhbmljcwoKICAgPHN0cmlrZT48 Zm9udCBjb2xvcj0ncmVkJz5XaGVuIG11bHRpcGxlIGZpbHRlciBlbGVtZW50cyBhcmUgc3BlY2lm aWVkLCB0aGV5IGFyZSBhcHBsaWVkCiAgIGNvbGxlY3RpdmVseSwgc28gZXZlbnQgbm90aWZpY2F0 aW9ucyBuZWVkIHRvIHBhc3MgYWxsIHNwZWNpZmllZAogICBmaWx0ZXIgZWxlbWVudHMgaW4gb3Jk ZXIgdG8gYmUgc2VudCB0byB0aGUgc3Vic2NyaWJlci48L2ZvbnQ+PC9zdHJpa2U+CgogICBJZiBh IGZpbHRlciBlbGVtZW50IGlzIHNwZWNpZmllZCB0byBsb29rIGZvciBkYXRhIG9mIGEgcGFydGlj dWxhcgogICB2YWx1ZSwgYW5kIHRoZSBkYXRhIGl0ZW0gaXMgbm90IHByZXNlbnQgd2l0aGluIGEg cGFydGljdWxhciBldmVudAogICBub3RpZmljYXRpb24gZm9yIGl0cyB2YWx1ZSB0byBiZSBjaGVj a2VkIGFnYWluc3QsIHRoZSBub3RpZmljYXRpb24KICAgd2lsbCBiZSBmaWx0ZXJlZCBvdXQuICBG b3IgZXhhbXBsZSwgaWYgb25lIHdlcmUgdG8gY2hlY2sgZm9yCiAgICdzZXZlcml0eT1jcml0aWNh bCcgaW4gYSBjb25maWd1cmF0aW9uIGV2ZW50IG5vdGlmaWNhdGlvbiB3aGVyZSB0aGlzCiAgIGZp ZWxkIHdhcyBub3Qgc3VwcG9ydGVkLCB0aGVuIHRoZSBub3RpZmljYXRpb24gd291bGQgYmUgZmls dGVyZWQgb3V0LgoKICAgRm9yIHN1YnRyZWUgZmlsdGVyaW5nLCBhIG5vbi1lbXB0eSBub2RlIHNl dCBtZWFucyB0aGF0IHRoZSBmaWx0ZXIKICAgbWF0Y2hlcy4gIEZvciBYUGF0aCBmaWx0ZXJpbmcs IHRoZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gW1hQQVRIXQogICBzaG91bGQgYmUgdXNlZCB0byBj b252ZXJ0IHRoZSByZXR1cm5lZCB2YWx1ZSB0byBib29sZWFuLgoKMy42LjEuICBGaWx0ZXJpbmcK CiAgIEZpbHRlcmluZyBpcyBleHBsaWNpdGx5IHN0YXRlZCB3aGVuIHRoZSBldmVudCBub3RpZmlj YXRpb24KICAgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQuICBUaGlzIGlzIHNwZWNpZmllZCB2aWEg dGhlICdmaWx0ZXInCiAgIHBhcmFtZXRlci4gIEEgRmlsdGVyIG9ubHkgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz5leGlzdDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3Jl ZW4nPmV4aXN0czwvZm9udD48L3N0cm9uZz4gYXMgYSBwYXJhbWV0ZXIgdG8gdGhlIHN1YnNjcmlw dGlvbi4KCjMuNy4gIE1lc3NhZ2UgRmxvdwogICBUaGUgZm9sbG93aW5nIGZpZ3VyZSBkZXBpY3Rz IG1lc3NhZ2UgZmxvdyBiZXR3ZWVuIGEgTkVUQ09ORiBjbGllbnQKICAgKEMpIGFuZCBORVRDT05G IHNlcnZlciAoUykgaW4gb3JkZXIgdG8gY3JlYXRlIGEgc3Vic2NyaXB0aW9uIGFuZAogICBiZWdp biB0aGUgZmxvdyBvZiBub3RpZmljYXRpb25zLiAgVGhpcyBzdWJzY3JpcHRpb24gc3BlY2lmaWVk IGEKICAgJmx0O3N0YXJ0VGltZSZndDssIHNvIHRoZSBzZXJ2ZXIgc3RhcnRzIGJ5IHJlcGxheWlu ZyBsb2dnZWQgbm90aWZpY2F0aW9ucy4KICAgSXQgaXMgcG9zc2libGUgdGhhdCBtYW55IHJwYy9y cGMtcmVwbHkgc2VxdWVuY2VzIG9jY3VyIGJlZm9yZSB0aGUKICAgc3Vic2NyaXB0aW9uIGlzIGNy ZWF0ZWQsIGJ1dCB0aGlzIGlzIG5vdCBkZXBpY3RlZCBpbiB0aGUgZmlndXJlLgoKICAgICAgICAg ICAgICAgICAgICAgICAgQyAgICAgICAgICAgICAgICAgICAgICAgICAgIFMKICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgICAgfCAgY2FwYWJpbGl0eSBleGNoYW5nZSAgICAgIHwKICAgICAgICAgICAgICAgICAg ICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAgICAgICAgICAg ICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAg ICAgICAgfCAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7ICAgIHwgKHN0YXJ0VGltZSkKICAg ICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAg ICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O3JwYy1yZXBseSZndDsgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICZsdDtub3RpZmljYXRpb24mZ3Q7ICAgICAg IHwgKHJlcGxheUNvbXBsZXRlKQogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9u Jmd0OyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0 OyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDMKICAgVGhlIGZv bGxvd2luZyBmaWd1cmUgZGVwaWN0cyBtZXNzYWdlIGZsb3cgYmV0d2VlbiBhIE5FVENPTkYgY2xp ZW50CiAgIChDKSBhbmQgTkVUQ09ORiBzZXJ2ZXIgKFMpIGluIG9yZGVyIHRvIGNyZWF0ZSBhIHN1 YnNjcmlwdGlvbiBhbmQKICAgYmVnaW4gdGhlIGZsb3cgb2Ygbm90aWZpY2F0aW9ucy4gIFRoaXMg c3Vic2NyaXB0aW9uIHNwZWNpZmllZCBhCiAgICZsdDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7c3Rv cFRpbWUmZ3Q7IHNvIGl0IHN0YXJ0cyBieSByZXBsYXlpbmcgbG9nZ2VkCiAgIG5vdGlmaWNhdGlv bnMgYW5kIHRoZW4gcmV0dXJucyB0byBiZSBhIG5vcm1hbCBjb21tYW5kLXJlc3BvbnNlCiAgIE5F VENPTkYgc2Vzc2lvbiBhZnRlciB0aGUgJmx0O3JlcGxheUNvbXBsZXRlJmd0OyBhbmQgJmx0O25v dGlmaWNhdGlvbkNvbXBsZXRlJmd0OwogICBub3RpZmljYXRpb25zIGFyZSBzZW50IGFuZCBpdCBp cyBhdmFpbGFibGUgdG8gcHJvY2VzcyAmbHQ7cnBjJmd0OyByZXF1ZXN0cy4KICAgSXQgaXMgcG9z c2libGUgdGhhdCBtYW55IHJwYy9ycGMtcmVwbHkgc2VxdWVuY2VzIG9jY3VyIGJlZm9yZSB0aGUK ICAgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQsIGJ1dCB0aGlzIGlzIG5vdCBkZXBpY3RlZCBpbiB0 aGUgZmlndXJlLgoKICAgICAgICAgICAgICAgICAgICAgQyAgICAgICAgICAgICAgICAgICAgICAg ICAgIFMKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgfCAgY2FwYWJpbGl0eSBleGNoYW5nZSAgICAgIHwKICAgICAg ICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAg ICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgfCAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7ICAgIHwgKHN0YXJ0VGltZSwKICAg ICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgIHN0b3BU aW1lKQogICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t fAogICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7cnBjLXJlcGx5Jmd0OyAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAogICAg ICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAg ICAgICB8ICAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAgfCAocmVwbGF5Q29tcGxldGUp CiAgICAgICAgICAgICAgICAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICB8KG5v dGlmaWNhdGlvbkNvbXBsZXRlKQogICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICZsdDtycGMmZ3Q7ICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fAogICAg ICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICZsdDtycGMtcmVwbHkmZ3Q7ICAgICAgICAgfAogICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAoKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDQKCjQuICBYTUwgU2NoZW1hIGZvciBFdmVudCBO b3RpZmljYXRpb25zCgogICBUaGUgZm9sbG93aW5nIFtYTUwgU2NoZW1hXSBkZWZpbmVzIE5FVENP TkYgRXZlbnQgTm90aWZpY2F0aW9ucy4KCiZsdDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9 IlVURi04Ij8mZ3Q7CiAgJmx0O3hzOnNjaGVtYSB4bWxuczp4cz0iaHR0cDovL3d3dy53My5vcmcv MjAwMS9YTUxTY2hlbWEiCiAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29u Zjpub3RpZmljYXRpb246MS4wIgogICAgIHhtbG5zOm5ldGNvbmY9InVybjppZXRmOnBhcmFtczp4 bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIKICAgICB0YXJnZXROYW1lc3BhY2U9CiAgICAgICAgInVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIgogICAgIGVsZW1l bnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIgogICAgIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1bnF1 YWxpZmllZCIKICAgICAgIHhtbDpsYW5nPSJlbiImZ3Q7CgogICAgJmx0OyEtLSBpbXBvcnQgc3Rh bmRhcmQgWE1MIGRlZmluaXRpb25zIC0tJmd0OwoKICAgICAmbHQ7eHM6aW1wb3J0IG5hbWVzcGFj ZT0iaHR0cDovL3d3dy53My5vcmcvWE1MLzE5OTgvbmFtZXNwYWNlIgogICAgICAgICAgICAgICAg c2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cudzMub3JnLzIwMDEveG1sLnhzZCImZ3Q7CiAgICAg ICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7 CiAgICAgICAgICAgVGhpcyBpbXBvcnQgYWNjZXNzZXMgdGhlIHhtbDogYXR0cmlidXRlIGdyb3Vw cyBmb3IgdGhlCiAgICAgICAgICAgeG1sOmxhbmcgYXMgZGVjbGFyZWQgb24gdGhlIGVycm9yLW1l c3NhZ2UgZWxlbWVudC4KICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAg Jmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICZsdDsveHM6aW1wb3J0Jmd0OwoKICAgICAmbHQ7 IS0tIGltcG9ydCBiYXNlIG5ldGNvbmYgZGVmaW5pdGlvbnMgLS0mZ3Q7CiAgICAgJmx0O3hzOmlt cG9ydCBuYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIK ICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+c2NoZW1hTG9jYXRpb249CiAgICAgImh0 dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lzdHJ5L3NjaGVtYS9uZXRjb25m LnhzZCIvJmd0OzwvZm9udD48L3N0cmlrZT4KICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dy ZWVuJz5zY2hlbWFMb2NhdGlvbj0ibmV0Y29uZi54c2QiLyZndDs8L2ZvbnQ+PC9zdHJvbmc+Cgom bHQ7IS0tICoqKioqKioqKioqKioqIFN5bW1ldHJpY2FsIE9wZXJhdGlvbnMgICoqKioqKioqKioq KioqKioqKioqLS0mZ3Q7CgogICAgICZsdDshLS0gJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7 IG9wZXJhdGlvbiAtLSZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iY3JlYXRlU3Vi c2NyaXB0aW9uVHlwZSImZ3Q7CiAgICAgICAgJmx0O3hzOmNvbXBsZXhDb250ZW50Jmd0OwogICAg ICAgICAgICAmbHQ7eHM6ZXh0ZW5zaW9uIGJhc2U9Im5ldGNvbmY6cnBjT3BlcmF0aW9uVHlwZSIm Z3Q7CiAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAg ICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtIgogICAgICAgICAgICAgICAgICAgICAgICB0 eXBlPSJzdHJlYW1OYW1lVHlwZSIgbWluT2NjdXJzPSIwIiZndDsKICAgICAgICAgICAgICAgICAg ICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAm bHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFu IG9wdGlvbmFsIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcwogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgd2hpY2ggc3RyZWFtIG9mIGV2ZW50cyBpcyBvZiBpbnRlcmVzdC4gSWYKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIG5vdCBwcmVzZW50LCB0aGVuIGV2ZW50cyBpbiB0aGUg ZGVmYXVsdAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTkVUQ09ORiBzdHJlYW0gd2ls bCBiZSBzZW50LgogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0 aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAg ICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJmaWx0ZXIiCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0eXBlPSJuZXRjb25mOmZpbHRlcklubGluZVR5cGUiCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBtaW5PY2N1cnM9IjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0 O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hz OmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFu IG9wdGlvbmFsIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcwogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB3aGljaCBzdWJzZXQgb2YgYWxsIHBvc3NpYmxlIGV2ZW50cwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpcyBvZiBpbnRlcmVzdC4gVGhlIGZvcm1hdCBv ZiB0aGlzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhcmFtZXRlciBpcyB0 aGUgc2FtZSBhcyB0aGF0IG9mIHRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBmaWx0ZXIgcGFyYW1ldGVyIGluIHRoZSBORVRDT05GCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHByb3RvY29sIG9wZXJhdGlvbnMuIElmIG5vdCBwcmVzZW50LAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbGwgZXZlbnRzIG5vdCBwcmVjbHVkZWQgYnkg b3RoZXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFyYW1ldGVycyB3aWxs IGJlIHNlbnQuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVu dGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czphbm5vdGF0aW9u Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAgICAg ICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RhcnRUaW1lIiB0eXBlPSJ4czpkYXRl VGltZSIKICAgICAgICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiAmZ3Q7CiAgICAgICAg ICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQSBwYXJhbWV0ZXIgdXNlZCB0byB0cmlnZ2VyIHRoZSByZXBsYXkKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBmZWF0dXJlIGFuZCBpbmRpY2F0ZXMgdGhhdCB0aGUgcmVw bGF5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2hvdWxkIHN0YXJ0IGF0IHRoZSB0 aW1lIHNwZWNpZmllZC4gSWYKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdGFydCB0 aW1lIGlzIG5vdCBwcmVzZW50LCB0aGlzIGlzIG5vdCBhCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgcmVwbGF5IHN1YnNjcmlwdGlvbi4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94 czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsK ICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzdG9wVGltZSIgdHlwZT0i eHM6ZGF0ZVRpbWUiCiAgICAgICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgJmd0Owog ICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEFuIG9wdGlvbmFsIHBhcmFtZXRlciB1c2VkIHdpdGggdGhlCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgb3B0aW9uYWwgcmVwbGF5IGZlYXR1cmUgdG8gaW5k aWNhdGUgdGhlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV3ZXN0IG5vdGlmaWNh dGlvbnMgb2YgaW50ZXJlc3QuIElmCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Rv cCB0aW1lIGlzIG5vdCBwcmVzZW50LCB0aGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBub3RpZmljYXRpb25zIHdpbGwgY29udGludWUgdW50aWwgdGhlCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3Vic2NyaXB0aW9uIGlzIHRlcm1pbmF0ZWQuIE11c3QgYmUgdXNlZAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGggc3RhcnRUaW1lLgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAg ICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgJmx0 Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAg ICAgICAgICAgJmx0Oy94czpleHRlbnNpb24mZ3Q7CiAgICAgICAgJmx0Oy94czpjb21wbGV4Q29u dGVudCZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CgogICAgJmx0O3hzOnNpbXBsZVR5 cGUgbmFtZT0ic3RyZWFtTmFtZVR5cGUiJmd0OwogICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0 OwogICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgIFRo ZSBuYW1lIG9mIGFuIGV2ZW50IHN0cmVhbS4KICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0 aW9uJmd0OwogICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAmbHQ7eHM6cmVz dHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIi8mZ3Q7CiAgICAmbHQ7L3hzOnNpbXBsZVR5cGUmZ3Q7 CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iY3JlYXRlLXN1YnNjcmlwdGlvbiIKICAgICAgICB0 eXBlPSJjcmVhdGVTdWJzY3JpcHRpb25UeXBlIgogICAgICAgIHN1YnN0aXR1dGlvbkdyb3VwPSJu ZXRjb25mOnJwY09wZXJhdGlvbiImZ3Q7CiAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAg ICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgVGhlIGNv bW1hbmQgdG8gY3JlYXRlIGEgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbi4gSXQKICAgICAgICAg ICAgICAgIHRha2VzIGFzIGFyZ3VtZW50IHRoZSBuYW1lIG9mIHRoZSBub3RpZmljYXRpb24gc3Ry ZWFtCiAgICAgICAgICAgICAgICBhbmQgZmlsdGVyLiBCb3RoIG9mIHRob3NlIG9wdGlvbnMKICAg ICAgICAgICAgICAgIGxpbWl0IHRoZSBjb250ZW50IG9mIHRoZSBzdWJzY3JpcHRpb24uIEluIGFk ZGl0aW9uLAogICAgICAgICAgICAgICAgdGhlcmUgYXJlIHR3byB0aW1lLXJlbGF0ZWQgcGFyYW1l dGVycywgc3RhcnRUaW1lIGFuZAogICAgICAgICAgICAgICAgc3RvcFRpbWUsIHdoaWNoIGNhbiBi ZSB1c2VkIHRvIHNlbGVjdCB0aGUgdGltZSBpbnRlcnZhbAogICAgICAgICAgICAgICAgb2YgaW50 ZXJlc3QgdG8gdGhlIG5vdGlmaWNhdGlvbiByZXBsYXkgZmVhdHVyZS4KICAgICAgICAgICAgJmx0 Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsKICAg ICZsdDsveHM6ZWxlbWVudCZndDsKCiZsdDshLS0gKioqKioqKioqKioqKiogT25lLXdheSBPcGVy YXRpb25zICAqKioqKioqKioqKioqKioqKiotLSZndDsKCiAgICAgJmx0OyEtLSAmbHQ7Tm90aWZp Y2F0aW9uJmd0OyBvcGVyYXRpb24gLS0mZ3Q7CiAgICAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9 Ik5vdGlmaWNhdGlvbkNvbnRlbnRUeXBlIi8mZ3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0i bm90aWZpY2F0aW9uQ29udGVudCIKICAgICAgICB0eXBlPSJOb3RpZmljYXRpb25Db250ZW50VHlw ZSIgYWJzdHJhY3Q9InRydWUiLyZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iTm90 aWZpY2F0aW9uVHlwZSImZ3Q7CiAgICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAgICAg ICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJldmVudFRpbWUiIHR5cGU9InhzOmRhdGVUaW1lIiZndDsK ICAgICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICZsdDt4 czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgVGhlIHRpbWUgdGhlIGV2ZW50IHdh cyBnZW5lcmF0ZWQgYnkgdGhlIGV2ZW50IHNvdXJjZQogICAgICAgICAgICAgICAgJmx0Oy94czpk b2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsKICAg ICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBy ZWY9Im5vdGlmaWNhdGlvbkNvbnRlbnQiLyZndDsKICAgICAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0 OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKCiAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJu b3RpZmljYXRpb24iIHR5cGU9Ik5vdGlmaWNhdGlvblR5cGUiLyZndDsKCiAgJmx0Oy94czpzY2hl bWEmZ3Q7Cgo1LiAgRmlsdGVyaW5nIEV4YW1wbGVzCgogICBUaGUgZm9sbG93aW5nIHNlY3Rpb24g cHJvdmlkZXMgZXhhbXBsZXMgdG8gaWxsdXN0cmF0ZSB0aGUgdmFyaW91cwogICBtZXRob2RzIG9m IGZpbHRlcmluZyBjb250ZW50IG9uIGFuIGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24u CgogICBJbiBvcmRlciB0byBpbGx1c3RyYXRlIHRoZSB1c2Ugb2YgZmlsdGVyIGV4cHJlc3Npb25z LCBpdCBpcyBuZWNlc3NhcnkKICAgdG8gYXNzdW1lIHNvbWUgb2YgdGhlIGV2ZW50IG5vdGlmaWNh dGlvbiBjb250ZW50LiAgVGhlIGV4YW1wbGVzIGJlbG93CiAgIGFzc3VtZSB0aGF0IHRoZSBldmVu dCBub3RpZmljYXRpb24gc2NoZW1hIGRlZmluaXRpb24gaGFzIGFuICZsdDtldmVudCZndDsKICAg ZWxlbWVudCBhdCB0aGUgdG9wIGxldmVsIGNvbnNpc3Rpbmcgb2YgdGhlIGV2ZW50IGNsYXNzIChl LmcuLCBmYXVsdCwKICAgc3RhdGUsIGNvbmZpZyksIHJlcG9ydGluZyBlbnRpdHkgYW5kIGVpdGhl ciBzZXZlcml0eSBvciBvcGVyYXRpb25hbAogICBzdGF0ZS4KCiAgIEV4YW1wbGVzIGluIHRoaXMg c2VjdGlvbiBhcmUgZ2VuZXJhdGVkIGZyb20gdGhlIGZvbGxvd2luZyBmaWN0aW9uYWwKICAgU2No ZW1hLgoKICAgICZsdDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7CiAg ICZsdDt4czpzY2hlbWEgdGFyZ2V0TmFtZXNwYWNlPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQv MS4wIgogICAgICAgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiCiAgICAgICBl bGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCIKICAgICAgIHhtbG5zOnhzPSJodHRwOi8vd3d3 LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIKICAgICAgIHhtbG5zOm5jRXZlbnQ9InVybjppZXRmOnBh cmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIiZndDsKCiAgICAgICAmbHQ7eHM6 aW1wb3J0IG5hbWVzcGFjZT0KICAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOm5vdGlmaWNhdGlvbjoxLjAiCiAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5z Y2hlbWFMb2NhdGlvbj0KImh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lz dHJ5L3NjaGVtYS9ub3RpZmljYXRpb24ueHNkIi8mZ3Q7PC9mb250Pjwvc3RyaWtlPgogICAgICAg ICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5zY2hlbWFMb2NhdGlvbj0ibm90aWZpY2F0 aW9uLnhzZCIvJmd0OzwvZm9udD48L3N0cm9uZz4KCiAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUg bmFtZT0iZXZlbnRUeXBlIiZndDsKICAgICAgICAgICAmbHQ7eHM6Y29tcGxleENvbnRlbnQmZ3Q7 CiAgICAgICAgICAgICAgICZsdDt4czpleHRlbnNpb24gYmFzZT0ibmNFdmVudDpOb3RpZmljYXRp b25Db250ZW50VHlwZSImZ3Q7CiAgICAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7 CiAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZXZlbnRDbGFzcyIg LyZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBvcnRp bmdFbnRpdHkiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6Y29tcGxleFR5 cGUmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFueSBuYW1lc3BhY2U9 IiMjYW55IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb2Nlc3NDb250ZW50 cz0ibGF4Ii8mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOnNlcXVl bmNlJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0 OwogICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAgICAg ICAgICAgICAgICAmbHQ7eHM6Y2hvaWNlJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAm bHQ7eHM6ZWxlbWVudCBuYW1lPSJzZXZlcml0eSIvJmd0OwogICAgICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJvcGVyU3RhdGUiLyZndDsKICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7L3hzOmNob2ljZSZndDsKICAgICAgICAgICAgICAgICAgICZsdDsveHM6c2Vx dWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICZsdDsveHM6ZXh0ZW5zaW9uJmd0OwogICAgICAgICAg ICZsdDsveHM6Y29tcGxleENvbnRlbnQmZ3Q7CiAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0 OwoKICAgICAgICZsdDt4czplbGVtZW50IG5hbWU9ImV2ZW50IgogICAgICAgICAgIHR5cGU9ImV2 ZW50VHlwZSIKICAgICAgICAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmNFdmVudDpub3RpZmljYXRp b25Db250ZW50Ii8mZ3Q7CgogICAmbHQ7L3hzOnNjaGVtYSZndDsKCiAgIFRoZSBhYm92ZSBmaWN0 aW9uYWwgbm90aWZpY2F0aW9uIGRlZmluaXRpb24gY291bGQgcmVzdWx0IGluIHRoZQogICBmb2xs b3dpbmcgc2FtcGxlIG5vdGlmaWNhdGlvbiBsaXN0LCB3aGljaCBpcyB1c2VkIGluIHRoZSBleGFt cGxlcyBpbgogICB0aGlzIHNlY3Rpb24uCgogICAmbHQ7bm90aWZpY2F0aW9uCiAgICAgIHhtbG5z PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAg ICAgICZsdDtldmVudFRpbWUmZ3Q7MjAwNy0wNy0wOFQwMDowMTowMFombHQ7L2V2ZW50VGltZSZn dDsKICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZn dDsKICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAg ICAgICAgICZsdDtyZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICAgICAmbHQ7Y2FyZCZndDtF dGhlcm5ldDAmbHQ7L2NhcmQmZ3Q7CiAgICAgICAgICZsdDsvcmVwb3J0aW5nRW50aXR5Jmd0Owog ICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7bWFqb3ImbHQ7L3NldmVyaXR5Jmd0OwogICAgICAgJmx0 Oy9ldmVudCZndDsKICAgJmx0Oy9ub3RpZmljYXRpb24mZ3Q7CgogICAmbHQ7bm90aWZpY2F0aW9u CiAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246 MS4wIiZndDsKICAgICAgJmx0O2V2ZW50VGltZSZndDsyMDA3LTA3LTA4VDAwOjAyOjAwWiZsdDsv ZXZlbnRUaW1lJmd0OwogICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9l dmVudC8xLjAiJmd0OwogICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50 Q2xhc3MmZ3Q7CiAgICAgICAgICAmbHQ7cmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgICAg ICZsdDtjYXJkJmd0O0V0aGVybmV0MiZsdDsvY2FyZCZndDsKICAgICAgICAgICZsdDsvcmVwb3J0 aW5nRW50aXR5Jmd0OwogICAgICAgICAgJmx0O3NldmVyaXR5Jmd0O2NyaXRpY2FsJmx0Oy9zZXZl cml0eSZndDsKICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICZsdDsvbm90aWZpY2F0aW9uJmd0OwoK ICAgJmx0O25vdGlmaWNhdGlvbgogICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5l dGNvbmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAgICAgICZsdDtldmVudFRpbWUmZ3Q7MjAwNy0w Ny0wOFQwMDowNDowMFombHQ7L2V2ZW50VGltZSZndDsKICAgICAgJmx0O2V2ZW50IHhtbG5zPSJo dHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICZsdDtldmVudENsYXNz Jmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgJmx0O3JlcG9ydGluZ0VudGl0 eSZndDsKICAgICAgICAgICAgICAgJmx0O2NhcmQmZ3Q7QVRNMSZsdDsvY2FyZCZndDsKICAgICAg ICAgICAmbHQ7L3JlcG9ydGluZ0VudGl0eSZndDsKICAgICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7 bWlub3ImbHQ7L3NldmVyaXR5Jmd0OwogICAgICAmbHQ7L2V2ZW50Jmd0OwogICAmbHQ7L25vdGlm aWNhdGlvbiZndDsKCiAgICZsdDtub3RpZmljYXRpb24KICAgICB4bWxucz0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiJmd0OwogICAgICZsdDtldmVudFRp bWUmZ3Q7MjAwNy0wNy0wOFQwMDoxMDowMFombHQ7L2V2ZW50VGltZSZndDsKICAgICAmbHQ7ZXZl bnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiJmd0OwogICAgICAgICAmbHQ7 ZXZlbnRDbGFzcyZndDtzdGF0ZSZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgJmx0O3JlcG9y dGluZ0VudGl0eSZndDsKICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0aGVybmV0MCZsdDsvY2Fy ZCZndDsKICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICZsdDtvcGVy U3RhdGUmZ3Q7ZW5hYmxlZCZsdDsvb3BlclN0YXRlJmd0OwogICAgICAmbHQ7L2V2ZW50Jmd0Owog ICAmbHQ7L25vdGlmaWNhdGlvbiZndDsKCjUuMS4gIFN1YnRyZWUgRmlsdGVyaW5nCgogICBYTUwg c3VidHJlZSBmaWx0ZXJpbmcgaXMgbm90IHdlbGwtc3VpdGVkIGZvciBjcmVhdGluZyBlbGFib3Jh dGUKICAgZmlsdGVyIGRlZmluaXRpb25zIGdpdmVuIHRoYXQgaXQgb25seSBzdXBwb3J0cyBlcXVh bGl0eSBjb21wYXJpc29ucwogICBhbmQgYXBwbGljYXRpb24gb2YgdGhlIGxvZ2ljYWwgT1Igb3Bl cmF0b3JzIChlLmcuLCBpbiBhbiBldmVudAogICBzdWJ0cmVlIGdpdmUgbWUgYWxsIGV2ZW50IG5v dGlmaWNhdGlvbnMgd2hpY2ggaGF2ZSBzZXZlcml0eT1jcml0aWNhbAogICBvciBzZXZlcml0eT1t YWpvciBvciBzZXZlcml0eT1taW5vcikuICBOZXZlcnRoZWxlc3MsIGl0IG1heSBiZSB1c2VkCiAg IGZvciBkZWZpbmluZyBzaW1wbGUgZXZlbnQgbm90aWZpY2F0aW9uIGZvcndhcmRpbmcgZmlsdGVy cyBhcyBzaG93bgogICBiZWxvdy4KCiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBpbGx1c3RyYXRl cyBob3cgdG8gc2VsZWN0IGZhdWx0IGV2ZW50cyB3aGljaAogICBoYXZlIHNldmVyaXRpZXMgb2Yg Y3JpdGljYWwsIG1ham9yLCBvciBtaW5vci4gIFRoZSBmaWx0ZXJpbmcgY3JpdGVyaWEKICAgZXZh bHVhdGlvbiBpcyBhcyBmb2xsb3dzOgoKICAgKChmYXVsdCAmYW1wOyBzZXZlcml0eT1jcml0aWNh bCkgfCAoZmF1bHQgJmFtcDsgc2V2ZXJpdHk9bWFqb3IpIHwgKGZhdWx0ICZhbXA7CiAgIHNldmVy aXR5PW1pbm9yKSkKCiAgICAgICAgJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0i MTAxIgogICAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpu czpuZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9u CiAgICAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3Rp ZmljYXRpb246MS4wIiZndDsKICAgICAgICAgICAgJmx0O2ZpbHRlciBuZXRjb25mOnR5cGU9InN1 YnRyZWUiJmd0OwogICAgICAgICAgICAgICZsdDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUu Y29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7ZXZlbnRDbGFzcyZndDtmYXVs dCZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgICAgICAgICZsdDtzZXZlcml0eSZndDtjcml0 aWNhbCZsdDsvc2V2ZXJpdHkmZ3Q7CiAgICAgICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAgICAg ICAgICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiJmd0 OwogICAgICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xhc3Mm Z3Q7CiAgICAgICAgICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7bWFqb3ImbHQ7L3NldmVyaXR5Jmd0 OwogICAgICAgICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICAgICAgICAgICAgJmx0O2V2ZW50IHht bG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgICAgICZs dDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgICAgICAg Jmx0O3NldmVyaXR5Jmd0O21pbm9yJmx0Oy9zZXZlcml0eSZndDsKICAgICAgICAgICAgICAmbHQ7 L2V2ZW50Jmd0OwogICAgICAgICAgICAmbHQ7L2ZpbHRlciZndDsKICAgICAgICAgICZsdDsvY3Jl YXRlLXN1YnNjcmlwdGlvbiZndDsKICAgICAgICAmbHQ7L25ldGNvbmY6cnBjJmd0OwoKICAgVGhl IGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVzIGhvdyB0byBzZWxlY3Qgc3RhdGUgb3IgY29u ZmlnCiAgIEV2ZW50Q2xhc3NlcyBvciBmYXVsdCBldmVudHMgdGhhdCBhcmUgcmVsYXRlZCB0byBj YXJkIEV0aGVybmV0MC4gIFRoZQogICBmaWx0ZXJpbmcgY3JpdGVyaWEgZXZhbHVhdGlvbiBpcyBh cyBmb2xsb3dzOgoKICAgKCBzdGF0ZSB8IGNvbmZpZyB8ICggZmF1bHQgJmFtcDsgKCBjYXJkPUV0 aGVybmV0MCkpKQoKJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAxIgogICAg ICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25m OmJhc2U6MS4wIiZndDsKICAgICAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24KICAgICAgICAgIHht bG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7 CiAgICAgICAgJmx0O2ZpbHRlciBuZXRjb25mOnR5cGU9InN1YnRyZWUiJmd0OwogICAgICAgICAg Jmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAg ICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7c3RhdGUmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAgICAgICAg ICAmbHQ7L2V2ZW50Jmd0OwogICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBs ZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7Y29uZmln Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAgICAgICAgICZs dDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAg ICAgICZsdDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAg ICAmbHQ7cmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0aGVy bmV0MCZsdDsvY2FyZCZndDsKICAgICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7CiAg ICAgICAgICAmbHQ7L2V2ZW50Jmd0OwogICAgICAgICZsdDsvZmlsdGVyJmd0OwogICAgICAmbHQ7 L2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiZsdDsvbmV0Y29uZjpycGMmZ3Q7Cgo1LjIuICBYUEFU SCBmaWx0ZXJzCgogICBUaGUgZm9sbG93aW5nIFtYUEFUSF0gZXhhbXBsZSBpbGx1c3RyYXRlcyBo b3cgdG8gc2VsZWN0IGZhdWx0CiAgIEV2ZW50Q2xhc3Mgbm90aWZpY2F0aW9ucyB0aGF0IGhhdmUg c2V2ZXJpdGllcyBvZiBjcml0aWNhbCwgbWFqb3IsIG9yCiAgIG1pbm9yLiAgVGhlIGZpbHRlcmlu ZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoKGZhdWx0KSAmYW1wOyAo KHNldmVyaXR5PWNyaXRpY2FsKSB8IChzZXZlcml0eT1tYWpvcikgfCAoc2V2ZXJpdHkgPQogICBt aW5vcikpKQoKICAgICAgJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAxIgog ICAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIiZndDsKICAgICAgICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbgogICAgICAg ICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9u OjEuMCImZ3Q7CiAgICAgICAgICAmbHQ7ZmlsdGVyIG5ldGNvbmY6dHlwZT0ieHBhdGgiCiAgICAg ICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIgogICAg ICAgICAgICAgc2VsZWN0PSIvZXg6ZXZlbnRbZXg6ZXZlbnRDbGFzcz0nZmF1bHQnIGFuZAogICAg ICAgICAgICAgICAgICAoZXg6c2V2ZXJpdHk9J21pbm9yJyBvciBleDpzZXZlcml0eT0nbWFqb3In CiAgICAgICAgICAgICAgICAgICAgICAgb3IgZXg6c2V2ZXJpdHk9J2NyaXRpY2FsJyldIi8mZ3Q7 CiAgICAgICAgJmx0Oy9jcmVhdGUtc3Vic2NyaXB0aW9uJmd0OwogICAgICAmbHQ7L25ldGNvbmY6 cnBjJmd0OwogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgaWxsdXN0cmF0ZXMgaG93IHRvIHNlbGVj dCBzdGF0ZSBhbmQgY29uZmlnCiAgIEV2ZW50Q2xhc3NlcyBvciBmYXVsdCBldmVudHMgb2YgYW55 IHNldmVyaXR5IHRoYXQgY29tZSBmcm9tIGNhcmQKICAgRXRoZXJuZXQwLiAgVGhlIGZpbHRlcmlu ZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoIHN0YXRlIHwgY29uZmln IHwgKGZhdWx0ICZhbXA7IGNhcmQ9RXRoZXJuZXQwKSkKCiAgICAgICZsdDtuZXRjb25mOnJwYyBt ZXNzYWdlLWlkPSIxMDEiCiAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAmbHQ7Y3JlYXRlLXN1YnNj cmlwdGlvbgogICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6 bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAgICAgICAgICAgICAmbHQ7ZmlsdGVyIG5ldGNvbmY6dHlw ZT0ieHBhdGgiCiAgICAgICAgICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5j b20vZXZlbnQvMS4wIgogICAgICAgICAgICAgICAgc2VsZWN0PSIvZXg6ZXZlbnRbCiAgICAgICAg ICAgICAgICAgICAoZXg6ZXZlbnRDbGFzcz0nc3RhdGUnIG9yIGV4OmV2ZW50Q2xhc3M9J2NvbmZp ZycpIG9yCiAgICAgICAgICAgICAgICAgICAoKGV4OmV2ZW50Q2xhc3M9J2ZhdWx0JyBhbmQgZXg6 Y2FyZD0nRXRoZXJuZXQwJykpXSIvJmd0OwogICAgICAgJmx0Oy9jcmVhdGUtc3Vic2NyaXB0aW9u Jmd0OwogICAgICZsdDsvbmV0Y29uZjpycGMmZ3Q7Cgo2LiAgSW50ZXJsZWF2ZSBDYXBhYmlsaXR5 Cgo2LjEuICBEZXNjcmlwdGlvbgoKICAgVGhlIEludGVybGVhdmUgY2FwYWJpbGl0eSBpbmRpY2F0 ZXMgdGhhdCB0aGUgTkVUQ09ORiBwZWVyIHN1cHBvcnRzCiAgIHRoZSBhYmlsaXR5IHRvIGludGVy bGVhdmUgb3RoZXIgTkVUQ09ORiBvcGVyYXRpb25zIHdpdGhpbiBhCiAgIE5vdGlmaWNhdGlvbiBz dWJzY3JpcHRpb24uICBUaGlzIG1lYW5zIHRoZSBORVRDT05GIHNlcnZlciBNVVNUCiAgIHJlY2Vp dmUsIHByb2Nlc3MgYW5kIHJlc3BvbmQgdG8gTkVUQ09ORiByZXF1ZXN0cyBvbiBhIHNlc3Npb24g d2l0aCBhbgogICBhY3RpdmUgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbi4gIDxzdHJvbmc+PGZv bnQgY29sb3I9J2dyZWVuJz5UaGlzIGNhcGFiaWxpdHkgaGVscHMgc2NhbGFiaWxpdHkKICAgYnkg cmVkdWNpbmcgdGhlIHRvdGFsIG51bWJlciBvZiBORVRDT05GIHNlc3Npb25zIHJlcXVpcmVkIGJ5 IGEgZ2l2ZW4KICAgb3BlcmF0b3Igb3IgbWFuYWdlbWVudCBhcHBsaWNhdGlvbi48L2ZvbnQ+PC9z dHJvbmc+Cgo2LjIuICBEZXBlbmRlbmNpZXMKCiAgIFRoaXMgY2FwYWJpbGl0eSBpcyBkZXBlbmRh bnQgb24gdGhlIG5vdGlmaWNhdGlvbiBjYXBhYmlsaXR5IGJlaW5nCiAgIHN1cHBvcnRlZC4KCjYu My4gIENhcGFiaWxpdHkgSWRlbnRpZmllcgoKICAgVGhlIDppbnRlcmxlYXZlIGNhcGFiaWxpdHkg aXMgaWRlbnRpZmllZCBieSB0aGUgZm9sbG93aW5nIGNhcGFiaWxpdHkKICAgc3RyaW5nOgoKICAg dXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTppbnRlcmxlYXZlOjEuMAoKNi40LiAg TmV3IE9wZXJhdGlvbnMKCiAgIE5vbmUuCgo2LjUuICBNb2RpZmljYXRpb25zIHRvIEV4aXN0aW5n IE9wZXJhdGlvbnMKCiAgIFdoZW4gYSAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsgaXMgc2Vu dCB3aGlsZSBhbm90aGVyIHN1YnNjcmlwdGlvbiBpcwogICBhY3RpdmUgb24gdGhhdCBzZXNzaW9u LCB0aGUgZm9sbG93aW5nIGVycm9yIHdpbGwgYmUgcmV0dXJuZWQ6CgogICAgICBUYWc6IG9wZXJh dGlvbi1mYWlsZWQKCiAgICAgIEVycm9yLXR5cGU6IHByb3RvY29sCgogICAgICBTZXZlcml0eTog ZXJyb3IKCiAgICAgIEVycm9yLWluZm86IG5vbmUKCiAgICAgIERlc2NyaXB0aW9uOiBSZXF1ZXN0 IGNvdWxkIG5vdCBiZSBjb21wbGV0ZWQgYmVjYXVzZSB0aGUgcmVxdWVzdGVkCiAgICAgIG9wZXJh dGlvbiBmYWlsZWQgZm9yIHNvbWUgcmVhc29uIG5vdCBjb3ZlcmVkIGJ5IGFueSBvdGhlciBlcnJv cgogICAgICBjb25kaXRpb24uCgo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmcm9tIHRoZSBiYXNlIFtORVRDT05GXSBkb2N1bWVudCBh bHNvCiAgIGFwcGx5IHRvIHRoZSBOb3RpZmljYXRpb24gY2FwYWJpbGl0eS4KCiAgIFRoZSBhY2Nl c3MgY29udHJvbCBmcmFtZXdvcmsgYW5kIHRoZSBjaG9pY2Ugb2YgdHJhbnNwb3J0IHdpbGwgaGF2 ZSBhCiAgIG1ham9yIGltcGFjdCBvbiB0aGUgc2VjdXJpdHkgb2YgdGhlIHNvbHV0aW9uLgoKICAg VGhlICZsdDtub3RpZmljYXRpb24mZ3Q7IGVsZW1lbnRzIGFyZSBuZXZlciBzZW50IGJlZm9yZSB0 aGUgdHJhbnNwb3J0IGxheWVyCiAgIGFuZCB0aGUgTkVUQ09ORiBsYXllciwgaW5jbHVkaW5nIGNh cGFiaWxpdGllcyBleGNoYW5nZSwgaGF2ZSBiZWVuCiAgIGVzdGFibGlzaGVkLCBhbmQgdGhlIG1h bmFnZXIgaGFzIGJlZW4gaWRlbnRpZmllZCBhbmQgYXV0aGVudGljYXRlZC4KCiAgIEl0IGlzIHJl Y29tbWVuZGVkIHRoYXQgY2FyZSBiZSB0YWtlbiB0byBzZWN1cmUgZXhlY3V0aW9uOgoKICAgbyAg Jmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IGludm9jYXRpb24KCiAgIG8gICZsdDtnZXQmZ3Q7 IG9uIHJlYWQtb25seSBkYXRhIG1vZGVscwoKICAgbyAgJmx0O25vdGlmaWNhdGlvbiZndDsgY29u dGVudAoKICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPlNlY3VyZSBleGVjdXRpb24gbWVh bnMgZW5zdXJpbmcgdGhhdCBhIHNlY3VyZSB0cmFuc3BvcnQgaXMgdXNlZCBhcwogICB3ZWxsIGFz IGVuc3VyaW5nIHRoYXQgdGhlIHVzZXIgaGFzIHN1ZmZpY2llbnQgYXV0aG9yaXphdGlvbiB0bwog ICBwZXJmb3JtIHRoZSBmdW5jdGlvbiB0aGV5IGFyZSByZXF1ZXN0aW5nIGFnYWluc3QgdGhlIHNw ZWNpZmljIHBpZWNlCiAgIG9mIE5FVENPTkYgY29udGVudCBpbnZvbHZlZC4gIFdoZW4gYSAmbHQ7 Z2V0Jmd0OyBpcyByZWNlaXZlZCBhZ2FpbnN0IHRoZQogICBjb250ZW50IGRlZmluZWQgaW4gdGhp cyBtZW1vLCBjbGllbnRzIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gdmlldyB0aGUKICAgY29udGVu dCBmb3Igd2hpY2ggdGhleSBoYXZlIHN1ZmZpY2llbnQgcHJpdmlsZWdlcy4gIEEgY3JlYXRlICZs dDtjcmVhdGUtCiAgIHN1YnNjcmlwdGlvbiZndDsgb3BlcmF0aW9uIGNhbiBiZSBjb25zaWRlcmVk IGxpa2UgYSBkZWZlcnJlZCAmbHQ7Z2V0Jmd0OywgYW5kCiAgIHRoZSBjb250ZW50IHRoYXQgZGlm ZmVyZW50IHVzZXJzIGNhbiBhY2Nlc3MgbWF5IHZhcnkuICBUaGlzIGRpZmZlcmVudAogICBhY2Nl c3MgaXMgcmVmbGVjdGVkIGluIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyB0aGF0IGRpZmZlcmVu dCB1c2VycyBhcmUKICAgYWJsZSB0byBzdWJzY3JpYmUgdG8uPC9mb250Pjwvc3Ryb25nPgoKICAg T25lIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZSBpcyB0aGUgdHJhbnNwb3J0IG9mIGRhdGEgZnJv bSBub24tCiAgIE5FVENPTkYgc3RyZWFtcywgc3VjaCBhcyBzeXNsb2cgYW5kIFNOTVAuICBUaGlz IGRhdGEgbWF5IGJlIG1vcmUKICAgdnVsbmVyYWJsZSAob3IgbGVzcyB2dWxuZXJhYmxlKSB3aGVu IGJlaW5nIHRyYW5zcG9ydGVkIG92ZXIgTkVUQ09ORgogICB0aGFuIHdoZW4gYmVpbmcgdHJhbnNw b3J0ZWQgdXNpbmcgdGhlIHByb3RvY29sIG5vcm1hbGx5IHVzZWQgZm9yCiAgIHRyYW5zcG9ydGlu ZyBpdCwgZGVwZW5kaW5nIG9uIHRoZSBzZWN1cml0eSBjcmVkZW50aWFscyBvZiB0aGUgdHdvCiAg IHN1YnN5c3RlbXMuICBUaGUgTkVUQ09ORiBzZXJ2ZXIgaXMgcmVzcG9uc2libGUgZm9yIGFwcGx5 aW5nIGFjY2VzcwogICBjb250cm9sIHRvIHN0cmVhbSBjb250ZW50LgoKICAgVGhlIGNvbnRlbnRz IG9mIG5vdGlmaWNhdGlvbnMgYXMgd2VsbCBhcyB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk Jz5uYW1lPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+bmFtZXM8 L2ZvbnQ+PC9zdHJvbmc+IG9mIGV2ZW50IHN0cmVhbXMKICAgbWF5IGNvbnRhaW4gc2Vuc2l0aXZl IGluZm9ybWF0aW9uIGFuZCBjYXJlIHNob3VsZCBiZSB0YWtlbiB0byBlbnN1cmUKICAgdGhhdCA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPml0IGlzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+dGhleSBhcmU8L2ZvbnQ+PC9zdHJvbmc+IHZpZXdlZCBvbmx5IGJ5 IGF1dGhvcml6ZWQgdXNlcnMuICBJZiBhIHVzZXIgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5k b2VzIG5vdCBoYXZlCiAgIHBlcm1pc3Npb24gdG8gdmlldyBjb250ZW50IHZpYSBvdGhlciBORVRD T05GIG9wZXJhdGlvbnMsIGl0IG11c3Qgbm90CiAgIGhhdmUgYWNjZXNzIHRoYXQgY29udGVudCB2 aWEgTm90aWZpY2F0aW9ucy4gIElmIGEgdXNlcjwvZm9udD48L3N0cmlrZT4gaXMgbm90CiAgIDxz dHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+cGVybWl0dGVkPC9mb250Pjwvc3RyaWtlPgogICA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbic+YXV0aG9yaXplZDwvZm9udD48L3N0cm9uZz4gdG8gdmll dyA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPm9uZSBlbGVtZW50PC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+YWxsIGVsZW1lbnRzPC9mb250Pjwvc3Ryb25nPiBp biB0aGUgY29udGVudCBvZiB0aGUgbm90aWZpY2F0aW9uLAogICB0aGUgbm90aWZpY2F0aW9uIGlz IG5vdCBzZW50IHRvIHRoYXQgdXNlci4KCiAgIElmIGEgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQg d2l0aCBhICZsdDtzdG9wVGltZSZndDssIHRoZSBORVRDT05GIHNlc3Npb24KICAgd2lsbCByZXR1 cm4gdG8gYmVpbmcgYSBub3JtYWwgY29tbWFuZC1yZXNwb25zZSBORVRDT05GIHNlc3Npb24gd2hl bgogICB0aGUgcmVwbGF5IGlzIGNvbXBsZXRlZC4gIEl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBv ZiB0aGUgTkVUQ09ORgogICBjbGllbnQgdG8gY2xvc2UgdGhpcyBzZXNzaW9uIHdoZW4gaXQgaXMg bm8gbG9uZ2VyIG9mIHVzZS4KCjguICBJQU5BIENvbnNpZGVyYXRpb25zCgogICAtLSBFZGl0b3Ig bm90ZSB0byBJQU5BL1JGQy1FZGl0b3I6IHdlIHJlcXVlc3QgdGhhdCB5b3UgbWFrZSB0aGVzZQog ICBhc3NpZ25tZW50cywgaW4gd2hpY2ggY2FzZSBpdCBpcyB0byBiZSBkb2N1bWVudGVkIGFzIGJl bG93CgogICBUaGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0aHJlZSBVUklzIGZvciB0aGUgTkVUQ09O RiBYTUwgbmFtZXNwYWNlIGluCiAgIHRoZSBJRVRGIFhNTCByZWdpc3RyeSBbUkZDMzY4OF0uCgog ICBGb2xsb3dpbmcgdGhlIGZvcm1hdCBpbiBSRkMgMzY4OCwgSUFOQSBoYXMgbWFkZSB0aGUgZm9s bG93aW5nCiAgIHJlZ2lzdHJhdGlvbi4gIE5vdGUgdGhhdCB0aGUgY2FwYWJpbGl0eSB1cm5zIGFz IGFsc28gY29tcGxpYW50IHRvCiAgIFtORVRDT05GXSBzZWN0aW9uIDEwLjMuCgogICArLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsKICAgfCBJbmRleCAgICAgICAgICAgICAgfCBDYXBhYmlsaXR5IElkZW50aWZpZXIgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IDpub3RpZmljYXRpb24g ICAgICB8IHVybjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6ICAgICAgICAgIHwKICAg fCAgICAgICAgICAgICAgICAgICAgfCBub3RpZmljYXRpb246MS4wICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDppbnRlcmxlYXZlICAgICAgICB8IHVy bjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6ICAgICAgICAgIHwKICAgfCAgICAgICAg ICAgICAgICAgICAgfCBpbnRlcmxlYXZlOjEuMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgVVJJOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldG1v ZDpub3RpZmljYXRpb24KCiAgIFVSSTogdXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOm5v dGlmaWNhdGlvbjoxLjAKCiAgIFJlZ2lzdHJhbnQgQ29udGFjdDogVGhlIElFU0cuCgogICBYTUw6 IE4vQSwgdGhlIHJlcXVlc3RlZCBVUkkgaXMgYW4gWE1MIG5hbWVzcGFjZS4KCiAgIEluIGFkZGl0 aW9uLCBJQU5BIHJlZ2lzdGVyZWQgdGhlIGZvbGxvd2luZyBYTUwgU2NoZW1hLCB0aGUgZGVmaW5p dGlvbgogICBvZiB3aGljaCBjYW4gYmUgZm91bmQgaW4gU2VjdGlvbiA0OgogICBodHRwOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbm90aWZpY2F0aW9uLnhz ZAoKOS4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoYW5rcyB0byBHaWxiZXJ0IEdhZ25vbiwgR3Jl ZyBXaWxidXIgYW5kIEtpbSBDdXJyYW4gZm9yIHByb3ZpZGluZwogICB0aGVpciBpbnB1dCBpbnRv IHRoZSBlYXJseSB3b3JrIG9uIHRoaXMgZG9jdW1lbnQuICBJbiBhZGRpdGlvbiwgdGhlCiAgIGVk aXRvcnMgd291bGQgbGlrZSB0byBhY2tub3dsZWRnZSBpbnB1dCBhdCB0aGUgVmFuY291dmVyIGVk aXRpbmcKICAgc2Vzc2lvbiBmcm9tIHRoZSBmb2xsb3dpbmcgcGVvcGxlOiBPcmx5IE5pY2tsYXNz LCBKYW1lcyBCYWxlc3RyaWVyZSwKICAgWW9zaGlmdW1pIEF0YXJhc2hpLCBHbGVubiBXYXRlcnMs IEFsZXhhbmRlciBDbGVtbSwgRGF2ZSBIYXJyaW5ndG9uLAogICBEYXZlIFBhcnRhaW4sIFJheSBB dGFyYXNoaSBhbmQgRGF2aWQgUGVya2lucyBhbmQgdGhlIGZvbGxvd2luZwogICBhZGRpdGlvbmFs IHBlb3BsZSBmcm9tIHRoZSBNb250cmVhbCBlZGl0aW5nIHNlc3Npb246IEJhbGF6cyBMZW5neWVs LAogICBQaGlsIFNoYWZlciwgUm9iIEVubnMsIEFuZHkgQmllcm1hbiwgRGFuIFJvbWFzY2FudSwg QmVydCBXaWpuZW4sCiAgIFNpbW9uIExlaW5lbiwgSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBIaWRl a2kgT2tpdGEsIFZpbmNlbnQgQ3JpZGxpZywKICAgTWFydGluIEJqb3JrbHVuZCwgT2xpdmllciBG ZXN0b3IsIFJhZHUgU3RhdGUsIEJyaWFuIFRyYW1tZWxsLCBXaWxsaWFtCiAgIENob3cuICBXZSB3 b3VsZCBhbHNvIGxpa2UgdG8gdGhhbmsgTGkgWWFuIGZvciBoaXMgbnVtZXJvdXMgcmV2aWV3cyBh cwogICB3ZWxsIGFzIFN1cmVzaCBLcmlzaG5hbiBmb3IgaGlzIGdlbi1hcnQgcmV2aWV3IG9mIHRo ZSBkb2N1bWVudC4KCjEwLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtORVRDT05GXSAgRW5u cywgUi4sICJORVRDT05GIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wiLCBSRkMgNDc0MSwKICAgICAg ICAgICAgICBEZWNlbWJlciAyMDA2LgoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBzLiwgIktleSB3 b3JkcyBmb3IgUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudHMKICAgICAgICAgICAgICBMZXZl bHMiLCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu Jz5bUkZDMzMzOV0gIEtseW5lLCBHLiwgRWQuIGFuZCBDLiBOZXdtYW4sICJEYXRlIGFuZCBUaW1l IG9uIHRoZQogICAgICAgICAgICAgIEludGVybmV0OiBUaW1lc3RhbXBzIiwgUkZDIDMzMzksIEp1 bHkgMjAwMi48L2ZvbnQ+PC9zdHJvbmc+CgogICBbUkZDMzY4OF0gIEJyYWRuZXIsIHMuLCAiVGhl IElFVEYgWE1MIFJlZ2lzdHJ5IiwgUkZDIDM2ODgsIEphbnVhcnkKICAgICAgICAgICAgICAgMjAw NC4KCiAgIFtYTUxdICAgICAgV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSwgIkV4dGVuc2libGUg TWFya3VwIExhbmd1YWdlCiAgICAgICAgICAgICAgKFhNTCkgMS4wIiwgVzNDIFhNTCwgRmVicnVh cnkgMTk5OCwKICAgICAgICAgICAgICAmbHQ7aHR0cDovL3d3dy53My5vcmcvVFIvMTk5OC9SRUMt eG1sLTE5OTgwMjEwJmd0Oy4KCiAgIFtYTUwgU2NoZW1hXQogICAgICAgICAgICAgIFRob21wc29u LCBILiwgQmVlY2gsIEQuLCBNYWxvbmV5LCBNLiwgYW5kIE4uIE1lbmRlbHNvaG4sCiAgICAgICAg ICAgICAgIlhNTCBTY2hlbWEgUGFydCAxOiBTdHJ1Y3R1cmVzIFNlY29uZCBFZGl0aW9uIiwgVzND IGh0dHA6LwogICAgICAgICAgICAgIC93d3cudzMub3JnL1RSLzIwMDQvUkVDLXhtbHNjaGVtYS0x LTIwMDQxMDI4LwogICAgICAgICAgICAgIHN0cnVjdHVyZXMuaHRtbCwgT2N0b2JlciAyMDA0LgoK ICAgW1hQQVRIXSAgICBDbGFyaywgSi4gYW5kIFMuIERlUm9zZSwgIlhNTCBQYXRoIExhbmd1YWdl IChYUGF0aCkKICAgICAgICAgICAgICBWZXJzaW9uIDEuMCIsCiAgICAgICAgICAgICAgVzNDIGh0 dHA6Ly93d3cudzMub3JnL1RSLzE5OTkvUkVDLXhwYXRoLTE5OTkxMTE2LAogICAgICAgICAgICAg IE5vdmVtYmVyIDE5OTkuCgpBcHBlbmRpeCBBLiAgQ2hhbmdlIExvZwoKICAgLS0gRWRpdG9yIG5v dGUgdG8gUkZDLUVkaXRvcjogd2UgcmVxdWVzdCB0aGF0IHlvdSByZW1vdmUgdGhpcyBzZWN0aW9u CiAgIGJlZm9yZSBwdWJsaXNoaW5nLgoKQS4xLiAgVmVyc2lvbiAtMDgKCiAgIDEuICAgUmVtb3Zl ZCBuYW1lZCBwcm9maWxlcwoKICAgMi4gICBSZW1vdmVkIGV2ZW50Q2xhc3MgdGhhdCB3YXMgYWNj aWRlbnRhbGx5IGluY2x1ZGVkIGluIHRoZQogICAgICAgIGRlZmluaXRpb24gb2YgdGhlIHJlcGxh eUNvbXBsZXRlIG5vdGlmaWNhdGlvbgoKICAgMy4gICBEZWxldGVkIGRhdGEgd3JhcHBlciBmcm9t IG5vdGlmaWNhdGlvbgoKICAgNC4gICBDaGFuZ2VkIHJlcGxheUxvZ1N0YXJ0VGltZSB0byBoYXZl IGEgbWluT2NjdXJzIG9mIDAuICBJdCB3aWxsCiAgICAgICAgb25seSBiZSB0aGVyZSB3aGVuIHJl cGxheSBpcyBzdXBwb3J0ZWQuICBWZXJpZnkgZXhhbXBsZXMgaW4KICAgICAgICBzZWN0aW9uIDMu Mi41LjEgYXJlIGNvcnJlY3Qgd2l0aCByZXNwZWN0IHRvIHRoaXMgZWxlbWVudC4KCiAgIDUuICAg RXJyb3IgY29kZXMgaW4gc2VjdGlvbiAyLjEuMSwgZml4ZWQgZm9ybWF0dGluZyBpc3N1ZQoKICAg Ni4gICBNb3ZlZCByZXBsYXlDb21wbGV0ZSB0byBub3QgYmUgdW5kZXIgJmx0O25ldGNvbmYmZ3Q7 CgogICA3LiAgIFNlY3Rpb24gMi4xLCBmaXhlZCBjYXBpdGFsaXphdGlvbgoKICAgOC4gICBJbiBm aWd1cmUgNCwgdGhlIGxpbmUgd2FzIHB1c2hlZCBvdXQgYnkgJ3N5c3RlbSBjb21wb25lbnRzJywK ICAgICAgICBmaXhlZCB0aGlzLgoKICAgOS4gICBPbiBwYWdlIDgsIHJlcGxhY2VkICJJZiB0aGUg c3RhcnRUaW1lIHNwZWNpZmllZCBpcyBlYXJsaWVyIHRoZW4KICAgICAgICB0aGUiIHdpdGggJ0lm IHRoZSBzdGFydFRpbWUgc3BlY2lmaWVkIGlzIGVhcmxpZXIgdGhhbiB0aGUiCgogICAxMC4gIFVw ZGF0ZWQgc29tZSBuYW1lIHNwYWNlcyBhbmQgc2NoZW1hTG9jYXRpb25zIGFzIHBlciBBbmR5J3Mg SnVuZQogICAgICAgIDNyZCBlbWFpbC4KCiAgIDExLiAgQWRkZWQgZGlzY3Vzc2lvbiBvZiByZXBs YXlMb2dTdGFydFRpbWUgdG8gZHJhZnQgaW4gc2VjdGlvbiAzLjMuMQogICAgICAgIGFzIGZvbGxv d3MgIldoZXRoZXIgb3Igbm90IGEgc3RyZWFtIHN1cHBvcnRzIHJlcGxheSBjYW4gYmUKICAgICAg ICBkaXNjb3ZlcmVkIGJ5IGRvaW5nIGEgJmx0O2dldCZndDsgb3BlcmF0aW9uIG9uIHRoZSAmbHQ7 c3RyZWFtcyZndDsgZWxlbWVudHMKICAgICAgICBvZiB0aGUgTm90aWZpY2F0aW9uIE1hbmFnZW1l bnQgU2NoZW1hLiAgVGhpcyBzY2hlbWEgYWxzbwogICAgICAgIHByb3ZpZGVzIHRoZSByZXBsYXlM b2dTdGFydFRpbWUgZWxlbWVudCB0byBpbmRpY2F0ZSB0aGUgZWFybGllc3QKICAgICAgICBhdmFp bGFibGUgbG9nZ2VkIG5vdGlmaWNhdGlvbi4iCgogICAxMi4gIFJlbW92ZWQgbW9zdCBvZiB0aGUg dXNlcyBvZiB0aGUgcGhyYXNlICdOb3RlIHRoYXQnLiAgSSBrZXB0IHR3bwogICAgICAgIHVzZXMg dGhhdCBwcmV2ZW50IHNlbnRlbmNlcyBmcm9tIHN0YXJ0aW5nIHdpdGggZWl0aGVyIGEgbG93ZXIK ICAgICAgICBjYXNlIGxldHRlciBvciBhbiBhbmdsZSBicmFja2V0LgoKICAgMTMuICBJbiBzZWN0 aW9uIDMuNiByZXBsYWNlZCAiaXQgd2lsbCBiZSBmaWx0ZXJlZCBvdXQiIHdpdGggInRoZQogICAg ICAgIG5vdGlmaWNhdGlvbiB3aWxsIGJlIGZpbHRlcmVkIG91dCIKICAgMTQuICBJbiBzZWN0aW9u IDMuNCwgcmVwbGFjZWQgImFuZCB0aGUgcXVlcnkiIHdpdGggImFuZCB0byBxdWVyeSIKCiAgIDE1 LiAgUmVwbGFjZWQgMyBpbnN0YW5jZXMgb2YgInJlcGxheSBjb21wbGV0ZSBub3RpZmljYXRpb24i IHdpdGgKICAgICAgICAicmVwbGF5Q29tcGxldGUgbm90aWZpY2F0aW9uIgoKICAgMTYuICBJbiBz ZWN0aW9uIDMuMy4yLCByZXBsYWNlZCAibm9ybWFsIE5FVENPTkYgc2Vzc2lvbiIgd2l0aCAibm9y bWFsCiAgICAgICAgY29tbWFuZC1yZXNwb25zZSBORVRDT05GIHNlc3Npb24iCgogICAxNy4gIElu IHNlY3Rpb24gMy4zLjEsIHJlcGxhY2VkICJjcmVhdGUgYW4gZXZlbnQgc3Vic2NyaXB0aW9uIHRo YXQKICAgICAgICB3aWxsIHJlc2VuZCByZWNlbnRseSBnZW5lcmF0ZWQgbm90aWZpY2F0aW9uIiB3 aXRoICJjcmVhdGUgYW4KICAgICAgICBldmVudCBzdWJzY3JpcHRpb24gdGhhdCB3aWxsIHJlc2Vu ZCByZWNlbnRseSBnZW5lcmF0ZWQKICAgICAgICBub3RpZmljYXRpb24sIG9yIGlzIHNvbWUgY2Fz ZXMgc2VuZCB0aGVtIGZvciB0aGUgZmlyc3QgdGltZSB0byBhCiAgICAgICAgcGFydGljdWxhciBO RVRDT05GIGNsaWVudC4iCgogICAxOC4gIEluIHNlY3Rpb24gMy4yLjUuMiwgcy9hdmFpbGFibGUg ZXZlbnQgc3RyZWFtcyB0by9ldmVudCBzdHJlYW1zCiAgICAgICAgYXZhaWxhYmxlIHRvLwoKICAg MTkuICBJbiBvbmUgc3BvdCwgY2hhbmdlZCBzbm1wIHRvIFNOTVAgKHRoZSBvdGhlciBnZXRzIGRl bGV0ZWQpCgogICAyMC4gIEluIHNlY3Rpb24gMy4yLjUuMSBzL3doZXJlICZsdDtuYW1lJmd0OyBl bGVtZW50IGlzL3doZXJlIHRoZSAmbHQ7bmFtZSZndDsKICAgICAgICBlbGVtZW50IGlzLwoKICAg MjEuICBJbiBzZWN0aW9uIDMuMi41LjEsIGNsYXJpZmllZCB0aGF0ICJ2YWx1ZSBpcyB1bmlxdWUi IC0gd2l0aGluCiAgICAgICAgdGhlIHNjb3BlIG9mIGEgTkVUQ09ORiBzZXJ2ZXIuCgogICAyMi4g IEluIHNlY3Rpb24gMi4xLjEsIGNsYXJpZmllZCB0aGF0IHN0b3BUaW1lIGNhbm5vdCBwcmVjZWRl ZCBzdGFydAogICAgICAgIHRpbWUuCgogICAyMy4gIEluIHNlY3Rpb24gMi4xLjEsIGluIFN0YXJ0 IFRpbWUgcy9pbmRpY2F0ZXMvaW5kaWNhdGUvCgogICAyNC4gIEluIHNlY3Rpb24gMi4xLjEsIGlu IEZpbHRlcjogcy9UaGlzIGlzIG11dHVhbGx5IGV4Y2x1c2l2ZS9UaGUKICAgICAgICBmaWx0ZXIg cGFyYW1ldGVyIGlzIG11dHVhbGx5IGV4Y2x1c2l2ZS8gKCJ0aGlzIiBjb3VsZCByZWZlciB0bwog ICAgICAgIHRoZSBiZWhhdmlvdXIgZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZW50ZW5jZS4p CgogICAyNS4gIEluIHNlY3Rpb24gMS40LCB0aGlyZCBidWxsZXQsIHJlcGxhY2VkICJzeXNsb2cg YW5kIFNOTVAgYXJlCiAgICAgICAgcmF0aGVyIGNvbnN0cmFpbmVkIGluIHRlcm1zIG9mIG1lc3Nh Z2Ugc2l6ZXMpIiB3aXRoIChpZSwgbm90IHRvbwogICAgICAgIHNob3J0KQoKICAgMjYuICBJbiBz ZWN0aW9uIDEuNCwgbWFkZSBhbGwgYnVsbGV0cyBzdGFydCB3aXRoIGNhcGl0YWwgbGV0dGVycy4K CiAgIDI3LiAgQWRkZWQgZGVmaW5pdGlvbiBvZiBGaWx0ZXIgdG8gc2VjdGlvbiAxLjEKCiAgIDI4 LiAgSW4gc2VjdGlvbiAxLjEsIGltcHJvdmVkIHRoZSBkZWZpbml0aW9uIG9mIHN1YnNjcmlwdGlv biB3aXRoICJBbgogICAgICAgIGFncmVlbWVudCBhbmQgbWV0aG9kIHRvIHJlY2VpdmUgZXZlbnQg bm90aWZpY2F0aW9ucyBvdmVyIGEKICAgICAgICBORVRDT05GIHNlc3Npb24uIgoKICAgMjkuICBJ biBzZWN0aW9uIDEuMSwgaW4gdGhlIGRlZmluaXRpb24gb2Ygb3BlcmF0aW9uLCBhZGRlZCBhCiAg ICAgICAgcmVmZXJlbmNlIHRvIFtORVRDT05GXS4KCiAgIDMwLiAgQ3JlYXRlZCBhIGNoYW5nZSBs b2cgc2VjdGlvbgoKICAgMzEuICBGaXhlZCByZWZlcmVuY2UgdG8gSUVURiBYTUwgUmVnaXN0cnkg aW4gSUFOQSBDb25zaWRlcmF0aW9ucwogICAgICAgIHNlY3Rpb24uCgogICAzMi4gIEluIHNlY3Rp b24gMy4zLjMsIGRlbGV0ZWQgIlRoaXMgbm90aWZpY2F0aW9uIHdpbGwgb25seSBiZSBzZW50CiAg ICAgICAgaWYgYSAnc3RvcFRpbWUnIHdhcyBzcGVjaWZpZWQgd2hlbiB0aGUgcmVwbGF5IHN1YnNj cmlwdGlvbiB3YXMKICAgICAgICBjcmVhdGVkLiIKCiAgIDMzLiAgQWRkZWQgdGV4dCB0byB0aGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0aGF0IHNheXMgIklmCiAgICAgICAgYSBz dWJzY3JpcHRpb24gaXMgY3JlYXRlZCB3aXRoIGEgc3RvcFRpbWUsIHRoZSBORVRDT05GIHNlc3Np b24KICAgICAgICB3aWxsIHJldHVybiB0byBiZWluZyBhIG5vcm1hbCBjb21tYW5kLXJlc3BvbnNl IE5FVENPTkYgc2Vzc2lvbgogICAgICAgIHdoZW4gdGhlIHJlcGxheSBpcyBjb21wbGV0ZWQuICBJ dCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlCiAgICAgICAgTkVUQ09ORiBjbGllbnQgdG8g Y2xvc2Ugb2ZmIHRoaXMgc2Vzc2lvbiB3aGVuIGl0IGlzIG5vIGxvbmdlciBvZgogICAgICAgIHVz ZSIuCgogICAzNC4gIFVwZGF0ZSBleGFtcGxlcyBpbiBzZWN0aW9uIDUgdG8gZ2V0IHJpZCBvZiBl eHRyYSB3cmFwcGVyIHRhZy4KCiAgIDM1LiAgSW4gc2VjdGlvbiAyLjEsIHJlcGxhY2UgIkEgTkVU Q09ORiBzZXJ2ZXIgaXMgbm90IHJlcXVpcmVkIHRvCiAgICAgICAgcHJvY2VzcyBSUEMgcmVxdWVz dHMgb24gdGhlIHNlc3Npb24gYXNzb2NpYXRlZCB3aXRoIHRoZQogICAgICAgIHN1YnNjcmlwdGlv biB1bnRpbCB0aGUgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiBpcyBkb25lIGFuZCBtYXkKICAg ICAgICBzaWxlbnRseSBkaXNjYXJkIHRoZXNlIHJlcXVlc3RzLiIgd2l0aCAiQSBORVRDT05GIHNl cnZlciBpcyB3aWxsCiAgICAgICAgbm90IHJlYWQgUlBDIHJlcXVlc3RzLCBieSBkZWZhdWx0LCBv biB0aGUgc2Vzc2lvbiBhc3NvY2lhdGVkCiAgICAgICAgd2l0aCB0aGUgc3Vic2NyaXB0aW9uIHVu dGlsIHRoZSBub3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIGlzCiAgICAgICAgZG9uZS4KCiAgIDM2 LiAgVXBkYXRlZCB0aGUgbm90aWZpY2F0aW9uIGRlZmluaXRpb24gYW5kIHRoZSByZXBseUNvbXBs ZXRlCiAgICAgICAgbm90aWZpY2F0aW9uIGRlZmluaXRpb24gdG8gdXNlIGEgc3Vic3RpdHV0aW9u IGdyb3VwLgoKQS4yLiAgVmVyc2lvbiAtMDkKCiAgIDEuICAgSW4gc2VjdGlvbiA1LjEgImxvZ2lj YWwgT1Igb3BlcmF0aW9uIiAtJmd0OyAiYXBwbGljYXRpb24gb2YgdGhlCiAgICAgICAgbG9naWNh bCBPUiBvcGVyYXRvciIKCiAgIDIuICAgSW4gc2VjdGlvbiA2ICJlbnN1cmUgdGhlIHNlY3VyZSBv cGVyYXRpb24gb2YgdGhlIGZvbGxvd2luZwogICAgICAgIGNvbW1hbmRzIiAtJmd0OyAic2VjdXJl IGV4ZWN1dGlvbiIKCiAgIDMuICAgUmVtb3ZlZCBhIGNvdXBsZSByZW1haW5pbmcgcmVmZXJlbmNl cyB0byBuYW1lZCBwcm9maWxlcy4KCiAgIDQuICAgVXBkYXRlZCBuYW1lIGRhdGF0eXBlIGluIGV2 ZW50U3RyZWFtcyBlbGVtZW50LgoKICAgNS4gICBNb2RpZmllZCB0aGUgY2FyZGluYWxpdHkgb2Yg ZXZlbnRTdHJlYW1zIHRvIHJlZmxlY3QgdGhhdCB0aGVyZQogICAgICAgIHdpbGwgYWx3YXlzIGJl IGF0IGxlYXN0IG9uZSBldmVudCBzdHJlYW0uCgogICA2LiAgIEZpeGVkIGRlc2NyaXB0aW9uIG9m IGV4YW1wbGVzIHRvIHJlbW92ZSByZWZlcmVuY2UgdG8gZXZlbnRFbnRyeSwKICAgICAgICB3aGlj aCBpcyBubyBsb25nZXIgcGFydCBvZiB0aGUgYWN0dWFsIGV4YW1wbGUuCgogICA3LiAgIEluIGV4 YW1wbGVzLCBmb3IgY29uc2lzdGVuY3kgY2hhbmdlZCBzb21lIHJlZmVyZW5jZXMgdG8KICAgICAg ICByZXBvcnRpbmdFbGVtZW50IHRvIGJlIHJlcG9ydGluZ0VudGl0eQoKICAgOC4gICBGaXhlZCBz ZWN0aW9uIDMuMiwgdGhpcmQgcGFyYWdyYXBoIHRvIHRhbGsgYWJvdXQgZmlsdGVyIGVsZW1lbnRz CiAgICAgICAgaW5zdGVhZCBvZiBmaWx0ZXJzLgoKICAgOS4gICBNZXJnZSBzZWN0aW9uIDMuMy4y IGFuZCBzZWN0aW9uIDMuMy4zLiAgRGVsZXRlIHRoZSBmaXJzdAogICAgICAgIHBhcmFncmFwaCBp biAob2xkKSBzZWN0aW9uIDMuMy4zIHNpbmNlIGl0IGJvdGggZHVwbGljYXRlcyBhbmQKICAgICAg ICBjb250cmFkaWN0cyB0ZXh0IGluIHNlY3Rpb24gMy4zLjIKCiAgIDEwLiAgSW4gc2VjdGlvbiAz LjIuNS4yLjEsIGFkZGVkIGNsYXJpZmljYXRpb24gdG8gZmlyc3QgcGFyYWdyYXBoCiAgICAgICAg dGhhdCAiRWl0aGVyIHN1YnRyZWUgb3IgWFBBVEggZmlsdGVyaW5nIGNhbiBiZSB1c2VkLiAgIgoK ICAgMTEuICBSZW1vdmVkIGRpc2N1c3Npb24gb2Ygbm90IGFsbG93aW5nIHRoZSByZXR1cm4gb2Yg c3RyZWFtIG5hbWVzCiAgICAgICAgZm9yIHdoaWNoIHRoZSB1c2VyIGRvZXMgbm90IGhhdmUgcGVy bWlzc2lvbnMgZnJvbSB0aGUgYm9keSBvZgogICAgICAgIHRoZSBkb2N1bWVudCB0byB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4KCiAgIDEyLiAgRml4ZWQgdHlwb3MgYW5kIGRp ZCB3b3Jkc21pdGhpbmcgaW4gdmFyaW91cyBwYXJ0cyBvZiB0aGUKICAgICAgICBkb2N1bWVudC4K CiAgIDEzLiAgSW4gc2VjdGlvbiAyLjEsIGV4cGxpY2l0bHkgc3RhdGVkIHRoYXQgYSBzdWJzY3Jp cHRpb24gaXMgYm91bmQKICAgICAgICB0byBhIHNpbmdsZSBzdHJlYW0gZm9yIHRoZSBsaWZldGlt ZSBvZiB0aGUgc3Vic2NyaXB0aW9uLgoKICAgMTQuICByZW1vdmVkIHNpbmdsZSBxdW90ZXMgYXJv dW5kIHNvbWUgaW5zdGFuY2VzIG9mIHN0b3BUaW1lIGFuZAogICAgICAgIHN0YXJ0VGltZSBmb3Ig Y29uc2lzdGVuY3kuICBXaGVuIGFwcHJvcHJpYXRlLCBwdXQgYmV0d2VlbiBhbmdsZQogICAgICAg IGJyYWNrZXRzLgoKICAgMTUuICBJbiBzZWN0aW9uIDIuMS4xLCBjaGFuZ2VkICJFcnJvci1pbmZv OiAmbHQ7YmFkRWxlbWVudCZndDs6IHN0YXJ0VGltZSIKICAgICAgICB0byB1c2UgYmFkLWVsZW1l bnQuCgogICAxNi4gIEluIHNlY3Rpb24gMi4yLjEsIHVuZGVyIHRoZSBwYXJhbWV0ZXIgdGFnLCBy ZXBsYWNlZCAiQ29udGFpbnMKICAgICAgICBub3RpZmljYXRpb24tc3BlY2lmaWMgdGFnZ2VkIGNv bnRlbnQuIiB3aXRoICJDb250YWlucwogICAgICAgIG5vdGlmaWNhdGlvbi1zcGVjaWZpYyB0YWdn ZWQgY29udGVudCwgaWYgYW55LiAgIgoKICAgMTcuICBDbGFyaWZpZWQgc29tZSB0ZXh0IGluIHNl Y3Rpb24gMy4yLCBwYXJhZ3JhcGggMyBhcm91bmQgc2VuZGluZwogICAgICAgIG9mIGZpbHRlcnMg ZnJvbSBjbGllbnQgYW5kIHRoZSBmaWx0ZXJzIGxhdGVyIGJlaW5nIGFwcGxpZWQgdG8KICAgICAg ICB0aGUgbm90aWZpY2F0aW9ucy4KCiAgIDE4LiAgRml4ZWQgdGFyZ2V0IG5hbWVzcGFjZSBpbiBz ZWN0aW9uIDQuCgogICAxOS4gIEFkZGVkIG1pc3NpbmcgbGFuZyBhbmQgdmVyc2lvbiBpbmZvcm1h dGlvbiB0byBzY2hlbWEgaW4gc2VjdGlvbgogICAgICAgIDMuNAoKICAgMjAuICBDbGFyaWZpZWQg dGhhdCB0aGUgZXhhbXBsZXMgaW4gc2VjdGlvbiA1IGFsbCB1c2VkIHRoZSBzYW1lCiAgICAgICAg ZXhhbXBsZSBldmVudCBsaXN0LgoKICAgMjEuICBDbGVhbmVkIHVwIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNlY3Rpb24uCgogICAyMi4gIEluIHNlY3Rpb24gMy40LCBjbGFyaWZpZWQgdGhlIGRl ZmluaXRpb24gb2YgcmVwbGF5TG9nU3RhcnQgdGltZQogICAgICAgIHRvIGJlIHRoZSB0aW1lc3Rh bXAgb2YgdGhlIGVhcmxpZXN0IGF2YWlsYWJsZSBub3RpZmljYXRpb24gaW4KICAgICAgICB0aGUg bG9nIHVzZWQgdG8gc3VwcG9ydCB0aGUgcmVwbGF5IGZ1bmN0aW9uIGluIHRoZSBkZXNjcmlwdGlv bgogICAgICAgIHRhZyBmb3IgdGhlIG9iamVjdCBkZWZpbml0aW9uLgoKICAgMjMuICBJbiBzZWN0 aW9uIDMuMy4yLCBjbGFyaWZpZWQgdGhhdCB0aGUgdGltZSBhbiBldmVudCB3YXMgZ2VuZXJhdGVk CiAgICAgICAgYnkgdGhlIHN5c3RlbSBtZWFucyB0aW1lIGFuIGV2ZW50IHdhcyBnZW5lcmF0ZWQg YnkgdGhlIGV2ZW50CiAgICAgICAgc291cmNlLgoKICAgMjQuICBJbiBzZWN0aW9uIDMuNSwgZGVs ZXRlZCBkaXNjdXNzaW9uIGFib3V0IHBvc3NpYmx5IGRlZmluaW5nCiAgICAgICAgc3Vic2NyaXB0 aW9ucyBpbiBYTUwgU2NoZW1hLgoKICAgMjUuICBJbiBzZWN0aW9uIDMuNiwgZGVsZXRlZCBkaXNj dXNzaW9uIGFib3V0IGZpbHRlciBlbGVtZW50CiAgICAgICAgZXhlY3V0aW9uIG9yZGVyIG5vdCBt YXR0ZXJpbmcuCgogICAyNi4gIEZpeGVkIGV4YW1wbGVzIGluIHNlY3Rpb24gNSB0byBhZGQgJmx0 O25ldGNvbmYmZ3Q7IHRhZyBhbmQgdG8gbWFrZQogICAgICAgIG90aGVyIGNvcnJlY3Rpb25zCgog ICAyNy4gIEFkZGVkIFhNTCBTY2hlbWEgZGVmaW5pdGlvbiBmb3IgZXhhbXBsZXMgaW4gc2VjdGlv biA1IGFuZCBzaG93ZWQKICAgICAgICB0aGUgZXZlbnQgbGlzdCB3aXRoICZsdDtub3RpZmljYXRp b24mZ3Q7IHdyYXBwZXJzLgoKICAgMjguICBBZGRlZCAmbHQ7bm90aWZpY2F0aW9uQ29tcGxldGUm Z3Q7IG5vdGlmaWNhdGlvbgoKICAgMjkuICBSZW1vdmVkIHN1cHBvcnQgb2Ygc3RhcnRUaW1lIGFu ZCBzdG9wVGltZSBpbiB0aGUgZnV0dXJlLgoKICAgMzAuICBSZXBsYWNlZCByZXBsYXlMb2dTdGFy dFRpbWUgd2l0aCByZXBsYXlMb2dDcmVhdGlvblRpbWUgYW5kCiAgICAgICAgcmVwbGF5TG9nQWdl ZFRpbWUuCgpBLjMuICBWZXJzaW9uIC0xMAoKICAgMS4gIENoYW5nZWQgdGhlIGRlc2NyaXB0aW9u IG9mIHN0b3BUaW1lIHRvIGFsbG93IHN0b3BUaW1lcyBpbiB0aGUKICAgICAgIGZ1dHVyZS4KCiAg IDIuICBBZGRlZCBpbnRlcmxlYXZlIGNhcGFiaWxpdHkKCiAgIDMuICBDbGFyaWZpZWQgY3JlYXRl LXN1YnNjcmlwdGlvbiBlcnJvciBtZXNzYWdlcy4KCiAgIDQuICBDb3JyZWN0ZWQgdGFyZ2V0TmFt ZXNwYWNlIGluIE5ldGNvbmYgTm90aWZpY2F0aW9uIFhTRAoKICAgNS4gIEZpeGVkIHR5cG9zIGFu ZCBtYWRlIG1pbm9yIGVkaXRzLgoKQS40LiAgVmVyc2lvbiAtMTEKCiAgIDEuICBGaXhlZCBuYW1l c3BhY2VzCgogICAyLiAgSW4gc2VjdGlvbiA2LjUsIGZpeGVkIGVycm9yIG1lc3NhZ2UgRXJyb3It aW5mbwogICAzLiAgSW4gc2VjdGlvbiA2LjEgY2xhcmlmeSB0aGF0IGlmIHRoZSBpbnRlcmxlYXZl IGNhcGFiaWxpdHkgaXMKICAgICAgIHN1cHBvcnRlZCwgdGhlbiB0aGUgc2VydmVyIG11c3QgcmVz cG9uZCB0byByZXF1ZXN0cy4KCkEuNS4gIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+VmVzcmlv bjwvZm9udD48L3N0cmlrZT4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5WZXJzaW9uPC9m b250Pjwvc3Ryb25nPiAtMTIKCiAgIDEuICBBZGQgdG8gc2VjdGlvbiAxLjMgdGhlIGNsYXJpZmlj YXRpb24gIk5vdGUgdGhhdCBhIHN1YnNjcmlwdGlvbgogICAgICAgY2Fubm90IGJlIG1vZGlmaWVk IG9uY2UgY3JlYXRlZC4iCgogICAyLiAgSW4gc2VjdGlvbiAyLjIuMSwgaW4gdGhlIGRlc2NyaXB0 aW9uIG9mIGV2ZW50VGltZSwgYWRkZWQgdGhlCiAgICAgICBmb2xsb3dpbmcgdGV4dDogIlRoaXMg cGFyYW1ldGVyIGlzIG9mIHR5cGUgZGF0ZVRpbWUuIgoKICAgMy4gIEZpeGVkIHNldmVyYWwgdHlw b3MuCgogICA0LiAgQWRkZWQgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIHRoZSBJQU5BIGNvbnNpZGVy YXRpb25zIHNlY3Rpb246ICItLQogICAgICAgRWRpdG9yIG5vdGUgdG8gSUFOQS9SRkMtRWRpdG9y OiB3ZSByZXF1ZXN0IHRoYXQgeW91IG1ha2UgdGhlc2UKICAgICAgIGFzc2lnbm1lbnRzLCBpbiB3 aGljaCBjYXNlIGl0IGlzIHRvcCBiZSBkb2N1bWVudGVkIGFzIGJlbG93IiAiCgogICA1LiAgUmVw bGFjZWQvVXBkYXRlZCBYTUwgU2NoZW1hIHJlZmVyZW5jZSB0byBiZSAiIFtYTUwgU2NoZW1hXQog ICAgICAgVGhvbXBzb24sIEguLCBCZWVjaCwgRC4sIE1hbG9uZXksIE0uLCBNZW5kZWxzb2huLCBO LiwgIlhNTCBTY2hlbWEKICAgICAgIFBhcnQgMTogU3RydWN0dXJlcyBTZWNvbmQgRWRpdGlvbiIs IFczQyBSZWNvbW1lbmRhdGlvbiwgMjgKICAgICAgIE9jdG9iZXIgMjAwNCAmbHQ7aHR0cDovL3d3 dy53My5vcmcvVFIvMjAwNC9SRUMteG1sc2NoZW1hLTEtMjAwNDEwMjgvCiAgICAgICBzdHJ1Y3R1 cmVzLmh0bWwmZ3Q7ICIKCiAgIDYuICBBZGQgaW5zdHJ1Y3Rpb25zIHRvIFJGQyBlZGl0b3IgdG8g cmVtb3ZlIGNoYW5nZSBsb2cgYmVmb3JlCiAgICAgICBwdWJsaWNhdGlvbgoKICAgNy4gIEFkZGVk IElBTkEgcmVnaXN0cmF0aW9uIGl0ZW0gZm9yIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvCiAgICAgICB4bWwtcmVnaXN0cnkvc2NoZW1hL25vdGlmaWNhdGlvbi54c2QKCiAgIDguICBD bGFyaWZpZWQgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0aGF0IHRoZSBjYXBh YmlsaXR5CiAgICAgICBVUklzIHdlcmUgY29tcGxhaW50IHRvIFJGQzQ3NDEgc2VjdGlvbiAxMC4z Cgo8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+QS42LiAgVmVyc2lvbiAtMTMKCiAgIDEuICAg SW4gc2VjdGlvbiAyLjEuMSwgZm9yIGJvdGggaW5zdGFuY2VzIGFuZCBpbiBzZWN0aW9uIDIuMi4x LAogICAgICAgIHJlcGxhY2VkICJUaGlzIHBhcmFtZXRlciBpcyBvZiB0eXBlIGRhdGVUaW1lLiIg IFdpdGggIlRoaXMKICAgICAgICBwYXJhbWV0ZXIgaXMgb2YgdHlwZSBkYXRlVGltZSBhbmQgY29t cGxpYW50IHRvIFtSRkMzMzM5XS4iCgogICAyLiAgIEluIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNl IHNlY3Rpb24sIGFkZGVkIHRoZSBmb2xsb3dpbmcKICAgICAgICByZWZlcmVuY2UgW1JGQzMzMzld IEtseW5lLCBHLiwgRWQuIGFuZCBDLiBOZXdtYW4sICJEYXRlIGFuZCBUaW1lCiAgICAgICAgb24g dGhlIEludGVybmV0OiBUaW1lc3RhbXBzIiwgUkZDIDMzMzksIEp1bHkgMjAwMi4KCiAgIDMuICAg SW4gc2VjdGlvbiAyLjEuMSwgZm9yIGJvdGggaW5zdGFuY2VzIGFuZCBpbiBzZWN0aW9uIDIuMi4x LCBhZGRlZAogICAgICAgIHRoZSBmb2xsb3dpbmcgYWZ0ZXIgdGhlIHRleHQgXCBpbmRpY2F0aW5n IHRoYXQgdGhlIHRpbWUgZmllbGRzCiAgICAgICAgYXJlIGRhdGVUaW1lICh0aGlzIGNvdmVycyBl dmVudFRpbWUsIHN0YXJ0VGltZSBhbmQgc3RvcFRpbWUpLgogICAgICAgICJJbXBsZW1lbnRhdGlv bnMgbXVzdCBzdXBwb3J0IHRpbWUgem9uZXMuIgogICA0LiAgIEluIFNlY3Rpb24gMy42LjEgInBh cmFtZXRlci4gIEEgRmlsdGVyIG9ubHkgZXhpc3QgYXMgYSBwYXJhbWV0ZXIKICAgICAgICB0byB0 aGUgc3Vic2NyaXB0aW9uLiIgcy9leGlzdC9leGlzdHMvCgogICA1LiAgIEluIFNlY3Rpb24gNzog UmVwbGFjZWQgc2Vjb25kIGxhc3QgcGFyYWdyYXBoIHdpdGggIlRoZSBjb250ZW50cwogICAgICAg IG9mIG5vdGlmaWNhdGlvbnMgYXMgd2VsbCBhcyB0aGUgbmFtZXMgb2YgZXZlbnQgc3RyZWFtcyBt YXkKICAgICAgICBjb250YWluIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhbmQgY2FyZSBzaG91bGQg YmUgdGFrZW4gdG8gZW5zdXJlCiAgICAgICAgdGhhdCB0aGV5IGFyZSB2aWV3ZWQgb25seSBieSBh dXRob3JpemVkIHVzZXJzLiAgSWYgYSB1c2VyIGlzIG5vdAogICAgICAgIGF1dGhvcml6ZWQgdG8g dmlldyBhbGwgZWxlbWVudHMgaW4gdGhlIGNvbnRlbnQgb2YgdGhlCiAgICAgICAgbm90aWZpY2F0 aW9uLCB0aGUgbm90aWZpY2F0aW9uIGlzIG5vdCBzZW50IHRvIHRoYXQgdXNlci4iCgogICA2LiAg IEluIHNlY3Rpb24gMy4zLjIsIHJlcGxhY2VkICJUaGUgTkVUQ09ORiBzZXJ2ZXIgd2lsbCB0aGVu IGFjY2VwdAogICAgICAgICZsdDtycGMmZ3Q7IG9wZXJhdGlvbnMuIiAgV2l0aCAiVGhlIE5FVENP TkYgc2VydmVyIHdpbGwgdGhlbiBhY2NlcHQKICAgICAgICAmbHQ7cnBjJmd0OyBvcGVyYXRpb25z IGV2ZW4gaWYgdGhlIHNlcnZlciBkaWQgbm90IHByZXZpb3VzbHkgYWNjZXB0CiAgICAgICAgc3Vj aCBvcGVyYXRpb25zIGR1ZSB0byBsYWNrIG9mIGludGVybGVhdmUgc3VwcG9ydC4iCgogICA3LiAg IEluIHNlY3Rpb24gMy4zLjIsIHJlcGxhY2VkICJBICZsdDtyZXBsYXlDb21wbGV0ZSZndDsgbm90 aWZpY2F0aW9uIGlzCiAgICAgICAgc2VudCB0byBpbmRpY2F0ZSB0aGF0IGFsbCBvZiB0aGUgcmVw bGF5IG5vdGlmaWNhdGlvbnMgaGF2ZSBiZWVuCiAgICAgICAgc2VudC4gIElmIHRoaXMgc3Vic2Ny aXB0aW9uIGhhcyBhIHN0b3AgdGltZSwgdGhlbiB0aGlzIHNlc3Npb24KICAgICAgICBiZWNvbWVz IGEgbm9ybWFsIE5FVENPTkYgc2Vzc2lvbiBhZ2Fpbi4gIFdoZW4gYSAmbHQ7c3RvcFRpbWUmZ3Q7 IGhhcwogICAgICAgIGJlZW4gc3BlY2lmaWVkLCAmbHQ7bm90aWZpY2F0aW9uQ29tcGxldGUmZ3Q7 IG5vdGlmaWNhdGlvbiBpcyB0aGUgbGFzdAogICAgICAgIG5vdGlmaWNhdGlvbiBzZW50IG9uIHRo ZSBzdWJzY3JpcHRpb24gYmVmb3JlIGl0IHRlcm1pbmF0ZXMgYW5kCiAgICAgICAgdGhlIE5FVENP TkYgc2Vzc2lvbiByZXR1cm5zIHRvIGJlaW5nIGEgbm9ybWFsIE5FVENPTkYgc2Vzc2lvbi4iCiAg ICAgICAgV2l0aCAiQSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbiBpcyBzZW50 IHRvIGluZGljYXRlIHRoYXQKICAgICAgICBhbGwgb2YgdGhlIHJlcGxheSBub3RpZmljYXRpb25z IGhhdmUgYmVlbiBzZW50LiAgV2hlbiBhCiAgICAgICAgJmx0O3N0b3BUaW1lJmd0OyBoYXMgYmVl biBzcGVjaWZpZWQsICZsdDtub3RpZmljYXRpb25Db21wbGV0ZSZndDsKICAgICAgICBub3RpZmlj YXRpb24gaXMgdGhlIGxhc3Qgbm90aWZpY2F0aW9uIHNlbnQgb24gdGhlIHN1YnNjcmlwdGlvbgog ICAgICAgIGJlZm9yZSBpdCB0ZXJtaW5hdGVzIGFuZCB0aGUgTkVUQ09ORiBzZXNzaW9uIHJldHVy bnMgdG8gYmVpbmcgYQogICAgICAgIG5vcm1hbCBORVRDT05GIHNlc3Npb24uICIKCiAgIDguICAg SW4gc2VjdGlvbiAzLjMuMiwgcmVwbGFjZWQsICJBICZsdDtyZXBsYXlDb21wbGV0ZSZndDsgbm90 aWZpY2F0aW9uIGlzCiAgICAgICAgc2VudCB0byBpbmRpY2F0ZSB0aGF0IGFsbCBvZiB0aGUgcmVw bGF5IG5vdGlmaWNhdGlvbnMgaGF2ZSBiZWVuCiAgICAgICAgc2VudC4iICBXaXRoICJBICZsdDty ZXBsYXlDb21wbGV0ZSZndDsgbm90aWZpY2F0aW9uIGlzIHNlbnQgdG8KICAgICAgICBpbmRpY2F0 ZSB0aGF0IGFsbCBvZiB0aGUgcmVwbGF5IG5vdGlmaWNhdGlvbnMgaGF2ZSBiZWVuIHNlbnQgYW5k CiAgICAgICAgbXVzdCBub3QgYmUgc2VudCBmb3IgYW55IG90aGVyIHJlYXNvbi4iCgogICA5LiAg IEluIHNlY3Rpb24gMy4zLjEsIHJlcGxhY2VkICJBIG5vdGlmaWNhdGlvbiBzdHJlYW0gdGhhdCBz dXBwb3J0cwogICAgICAgIHJlcGxheSBpcyBub3QgZXhwZWN0ZWQgdG8gaGF2ZSBhbiB1bmxpbWl0 ZWQgc3VwcGx5IG9mIHNhdmVkCiAgICAgICAgbm90aWZpY2F0aW9ucyBhdmFpbGFibGUgdG8gYWNj b21tb2RhdGUgYW55IHJlcGxheSByZXF1ZXN0LiIKICAgICAgICBXaXRoICJBIG5vdGlmaWNhdGlv biBzdHJlYW0gdGhhdCBzdXBwb3J0cyByZXBsYXkgaXMgbm90IGV4cGVjdGVkCiAgICAgICAgdG8g aGF2ZSBhbiB1bmxpbWl0ZWQgc3VwcGx5IG9mIHNhdmVkIG5vdGlmaWNhdGlvbnMgYXZhaWxhYmxl IHRvCiAgICAgICAgYWNjb21tb2RhdGUgYW55IHJlcGxheSByZXF1ZXN0LiAgQ2xpZW50cyBjYW4g cXVlcnkKICAgICAgICAmbHQ7cmVwbGF5TG9nQ3JlYXRpb25UaW1lJmd0OyBhbmQgJmx0O3JlcGxh eUxvZ0FnZWRUaW1lJmd0OyB0byBsZWFybiBhYm91dAogICAgICAgIHRoZSBhdmFpbGFiaWxpdHkg b2Ygbm90aWZpY2F0aW9ucyBmb3IgcmVwbGF5LiIKCiAgIDEwLiAgSW4gc2VjdGlvbiAzLjIsIHJl cGxhY2VkICJGaWd1cmUgMiBpbGx1c3RyYXRlcyB0aGUgbm90aWZpY2F0aW9uCiAgICAgICAgZmxv dyBhbmQgY29uY2VwdHMgaWRlbnRpZmllZCBpbiB0aGlzIGRvY3VtZW50LiIgIFdpdGggIkZpZ3Vy ZSAyCiAgICAgICAgaWxsdXN0cmF0ZXMgdGhlIG5vdGlmaWNhdGlvbiBmbG93IGFuZCBjb25jZXB0 cyBpZGVudGlmaWVkIGluCiAgICAgICAgdGhpcyBkb2N1bWVudC4gIEl0IGRvZXMgbm90IG1hbmRh dGUgYW5kL29yIHByZWNsdWRlIGFuCiAgICAgICAgaW1wbGVtZW50YXRpb24uIgoKICAgMTEuICBJ biBzZWN0aW9uIDYuMSwgYWRkZWQgdGhlIGZvbGxvd2luZyB0ZXh0ICJUaGlzIGNhcGFiaWxpdHkg aGVscHMKICAgICAgICBzY2FsYWJpbGl0eSBieSByZWR1Y2luZyB0aGUgdG90YWwgbnVtYmVyIG9m IE5FVENPTkYgc2Vzc2lvbnMKICAgICAgICByZXF1aXJlZCBieSBhIGdpdmVuIG9wZXJhdG9yIG9y IG1hbmFnZW1lbnQgYXBwbGljYXRpb24uIgoKICAgMTIuICBJbiBzZWN0aW9uIDMuNiwgZGVsZXRl ZCAiV2hlbiBtdWx0aXBsZSBmaWx0ZXIgZWxlbWVudHMgYXJlCiAgICAgICAgc3BlY2lmaWVkLCB0 aGV5IGFyZSBhcHBsaWVkIGNvbGxlY3RpdmVseSwgc28gZXZlbnQgbm90aWZpY2F0aW9ucwogICAg ICAgIG5lZWQgdG8gcGFzcyBhbGwgc3BlY2lmaWVkIGZpbHRlciBlbGVtZW50cyBpbiBvcmRlciB0 byBiZSBzZW50CiAgICAgICAgdG8gdGhlIHN1YnNjcmliZXIuICIKCiAgIDEzLiAgSW4gc2VjdGlv biA3IChTZWN1cml0eSBDb25zaWRlcmF0aW9ucykgYWZ0ZXIgdGhlIGJ1bGxldHMgYWRkZWQKICAg ICAgICB0aGUgZm9sbG93aW5nOiBTZWN1cmUgZXhlY3V0aW9uIG1lYW5zIGVuc3VyaW5nIHRoYXQg YSBzZWN1cmUKICAgICAgICB0cmFuc3BvcnQgaXMgdXNlZCBhcyB3ZWxsIGFzIGVuc3VyaW5nIHRo YXQgdGhlIHVzZXIgaGFzCiAgICAgICAgc3VmZmljaWVudCBhdXRob3JpemF0aW9uIHRvIHBlcmZv cm0gdGhlIGZ1bmN0aW9uIHRoZXkgYXJlCiAgICAgICAgcmVxdWVzdGluZyBhZ2FpbnN0IHRoZSBz cGVjaWZpYyBwaWVjZSBvZiBORVRDT05GIGNvbnRlbnQKICAgICAgICBpbnZvbHZlZC4gIFdoZW4g YSAmbHQ7Z2V0Jmd0OyBpcyByZWNlaXZlZCBhZ2FpbnN0IHRoZSBjb250ZW50IGRlZmluZWQKICAg ICAgICBpbiB0aGlzIG1lbW8sIGNsaWVudHMgc2hvdWxkIG9ubHkgYmUgYWJsZSB0byB2aWV3IHRo ZSBjb250ZW50CiAgICAgICAgZm9yIHdoaWNoIHRoZXkgaGF2ZSBzdWZmaWNpZW50IHByaXZpbGVn ZXMuICBBIGNyZWF0ZSAmbHQ7Y3JlYXRlLQogICAgICAgIHN1YnNjcmlwdGlvbiZndDsgb3BlcmF0 aW9uIGNhbiBiZSBjb25zaWRlcmVkIGxpa2UgYSBkZWZlcnJlZCAmbHQ7Z2V0Jmd0OywKICAgICAg ICBhbmQgdGhlIGNvbnRlbnQgdGhhdCBkaWZmZXJlbnQgdXNlcnMgY2FuIGFjY2VzcyBtYXkgdmFy eS4gIFRoaXMKICAgICAgICBkaWZmZXJlbnQgYWNjZXNzIGlzIHJlZmxlY3RlZCBpbiB0aGUgJmx0 O25vdGlmaWNhdGlvbiZndDsgdGhhdAogICAgICAgIGRpZmZlcmVudCB1c2VycyBhcmUgYWJsZSB0 byBzdWJzY3JpYmUgdG8uCgogICAxNC4gIFVwZGF0ZWQgaW1wb3J0IHN0YXRlbWVudHMgdG8gbm90 IHVzZWQgZnVsbHkgcXVhbGlmaWVkIFVSTHMuPC9mb250Pjwvc3Ryb25nPgoKQXV0aG9ycycgQWRk cmVzc2VzCgogICBTaGFyb24gQ2hpc2hvbG0KICAgTm9ydGVsCiAgIDM1MDAgQ2FybGluZyBBdmUK ICAgTmVwZWFuLCBPbnRhcmlvICBLMkggOEU5CiAgIENhbmFkYQoKICAgRW1haWw6IHNjaGlzaG9s QG5vcnRlbC5jb20KCiAgIEhlY3RvciBUcmV2aW5vCiAgIENpc2NvCiAgIFN1aXRlIDQwMAogICA5 MTU1IEUuIE5pY2hvbHMgQXZlCiAgIEVuZ2xld29vZCwgQ08gIDgwMTEyCiAgIFVTQQoKICAgRW1h aWw6IGh0cmV2aW5vQGNpc2NvLmNvbQoKRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50CgogICBDb3B5 cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA4KS4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3Vi amVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zCiAgIGNvbnRhaW5l ZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3Jz CiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLgoKICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuCiAgICJBUyBJUyIg YmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVT RU5UUwogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZ LCBUSEUgSUVURiBUUlVTVCBBTkQKICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9S Q0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MKICAgT1IgSU1QTElFRCwgSU5DTFVE SU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GCiAgIFRI RSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkg SU1QTElFRAogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBB IFBBUlRJQ1VMQVIgUFVSUE9TRS4KCkludGVsbGVjdHVhbCBQcm9wZXJ0eQoKICAgVGhlIElFVEYg dGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkK ICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdo dCBiZSBjbGFpbWVkIHRvCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBv ZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0 ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzCiAgIG1pZ2h0IG9yIG1p Z2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcwog ICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRz LiAgSW5mb3JtYXRpb24KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0 cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4K CiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlh dCBhbmQgYW55CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUs IG9yIHRoZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwg bGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mCiAgIHN1Y2ggcHJvcHJpZXRhcnkg cmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24g Y2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdAog ICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4KCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVy ZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkKICAgY29weXJpZ2h0cywg cGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQogICBy aWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBp bXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlv biB0byB0aGUgSUVURiBhdAogICBpZXRmLWlwckBpZXRmLm9yZy4KCkFja25vd2xlZGdtZW50Cgog ICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBwcm92aWRlZCBieSB0aGUg SUVURgogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJQVNBKS4KPC9wcmU+Cjwv Ym9keT48L2h0bWw+Cg== ------_=_NextPart_001_01C8C1AD.B10CE57C Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8C1AD.B10CE57C-- pbmNl IHRoZSBzdGFydCBvZiB0aGUgc3Vic2NyaXB0aW9uCiAgIGNyZWF0aW9uIHdpbGwgYmUgc2VudCwg Zm9sbG93ZWQgYnkgbm90aWZpY2F0aW9ucyBhcyB0aGV5IGFyaXNlCiAgIG5hdHVyYWxseSB3aXRo aW4gdGhlIHN5c3RlbS4KCiAgIFRoZSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IGFuZCAmbHQ7bm90 aWZpY2F0aW9uQ29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbnMgY2Fubm90CiAgIGJlIGZpbHRlcmVk IG91dC4gIFRoZXkgd2lsbCBhbHdheXMgYmUgc2VudCBvbiBhIHJlcGxheSBzdWJzY3JpcHRpb24K ICAgdGhhdCBzcGVjaWZpZWQgYSBzdGFydFRpbWUgYW5kIHN0b3BUaW1lIHJlc3BlY3RpdmVseS4K CjMuNC4gIE5vdGlmaWNhdGlvbiBNYW5hZ2VtZW50IFNjaGVtYQoKICAgVGhpcyBTY2hlbWEgaXMg dXNlZCB0byBsZWFybiBhYm91dCB0aGUgZXZlbnQgc3RyZWFtcyBzdXBwb3J0ZWQgb24gdGhlCiAg IHN5c3RlbS4gIEl0IGFsc28gY29udGFpbnMgdGhlIGRlZmluaXRpb24gb2YgdGhlICZsdDtyZXBs YXlDb21wbGV0ZSZndDsgYW5kCiAgICZsdDtub3RpZmljYXRpb25Db21wbGV0ZSZndDsgbm90aWZp Y2F0aW9ucywgd2hpY2ggYXJlIHNlbnQgdG8gaW5kaWNhdGUgdGhhdAogICBhbiBldmVudCByZXBs YXkgaGFzIHNlbnQgYWxsIGFwcGxpY2FibGUgbm90aWZpY2F0aW9ucyBhbmQgdGhhdCB0aGUKICAg c3Vic2NyaXB0aW9uIGhhcyB0ZXJtaW5hdGVkLCByZXNwZWN0aXZlbHkuCgombHQ7P3htbCB2ZXJz aW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0OwombHQ7eHM6c2NoZW1hIHhtbG5zOnhzPSJo dHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIKICAgIHhtbG5zOm5ldGNvbmY9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIKICAgIHhtbG5zOm5jRXZlbnQ9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIgogICAgeG1sbnM6 bWFuYWdlRXZlbnQ9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0bW9kOm5vdGlmaWNhdGlvbiIK ICAgIHRhcmdldE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZp Y2F0aW9uIgogICAgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZpZWQiCiAgICBhdHRyaWJ1dGVG b3JtRGVmYXVsdD0idW5xdWFsaWZpZWQiCiAgICB4bWw6bGFuZz0iZW4iIHZlcnNpb249IjEuMCIm Z3Q7CiAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlv biB4bWw6bGFuZz0iZW4iJmd0OwogICAgICAgICAgICBBIHNjaGVtYSB0aGF0IGNhbiBiZSB1c2Vk IHRvIGxlYXJuIGFib3V0IGN1cnJlbnQKICAgICAgICAgICAgZXZlbnQgc3RyZWFtcy4gSXQgYWxz byBjb250YWlucyB0aGUgcmVwbGF5Q29tcGxldGUKICAgICAgICAgICAgYW5kIG5vdGlmaWNhdGlv bkNvbXBsZXRlICBub3RpZmljYXRpb24uCiAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0 OwogICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwoKJmx0O3hzOmltcG9ydCBuYW1lc3BhY2U9Imh0 dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4L25hbWVzcGFjZSIKICAgICAgICBzY2hlbWFMb2NhdGlv bj0iaHR0cDovL3d3dy53My5vcmcvMjAwMS94bWwueHNkIi8mZ3Q7CiZsdDt4czppbXBvcnQgbmFt ZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiCiAgICA8c3Ry aWtlPjxmb250IGNvbG9yPSdyZWQnPnNjaGVtYUxvY2F0aW9uPQogICAgICJodHRwOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbmV0Y29uZi54c2QiLyZndDs8 L2ZvbnQ+PC9zdHJpa2U+CiAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+c2NoZW1hTG9j YXRpb249Im5ldGNvbmYueHNkIi8mZ3Q7PC9mb250Pjwvc3Ryb25nPgombHQ7eHM6aW1wb3J0IG5h bWVzcGFjZT0KICAgICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9u OjEuMCIKICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5zY2hlbWFMb2NhdGlvbj0KImh0 dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lzdHJ5L3NjaGVtYS9ub3RpZmlj YXRpb24ueHNkIi8mZ3Q7PC9mb250Pjwvc3RyaWtlPgogICAgICA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+c2NoZW1hTG9jYXRpb249Im5vdGlmaWNhdGlvbi54c2QiLyZndDs8L2ZvbnQ+PC9z dHJvbmc+CiZsdDshLS0gVGhlIGFib3ZlICBzY2hlbWFMb2NhdGlvbiB2YWx1ZSBpcyBhIHBsYWNl aG9sZGVyIGFuZCB0aGUgYWN0dWFsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdmFsdWUgd2lsbCBiZSBhc3NpZ25lZCBieSBJQU5BIC0tJmd0OwoKJmx0O3hzOmVsZW1lbnQg bmFtZT0ibmV0Y29uZiIgdHlwZT0ibWFuYWdlRXZlbnQ6TmV0Y29uZiIvJmd0OwoKJmx0O3hzOmNv bXBsZXhUeXBlIG5hbWU9Ik5ldGNvbmYiJmd0OwogICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAg Jmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtcyIgJmd0OwogICAgICAgICZsdDt4czphbm5vdGF0 aW9uJmd0OwogICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAg VGhlIGxpc3Qgb2YgZXZlbnQgc3RyZWFtcyBzdXBwb3J0ZWQgYnkgdGhlCiAgICAgICAgICAgICBz eXN0ZW0uIFdoZW4gYSBxdWVyeSBpcyBpc3N1ZWQsIHRoZSByZXR1cm5lZAogICAgICAgICAgICAg c2V0IG9mIHN0cmVhbXMgaXMgZGV0ZXJtaW5lZCBiYXNlZCBvbiB1c2VyCiAgICAgICAgICAgICBw cml2aWxlZ2VzLgogICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAg Jmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAg ICAgICAgICAgJmx0O3hzOnNlcXVlbmNlIG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSJ1bmJvdW5k ZWQiJmd0OwogICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtIiZndDsKICAg ICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAmbHQ7 eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICBTdHJlYW0gbmFtZSwgZGVz Y3JpcHRpb24gYW5kIG90aGVyIGluZm9ybWF0aW9uLgogICAgICAgICAgICAgICAgICAmbHQ7L3hz OmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7 CiAgICAgICAgICAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICAgICAgICAgICAg ICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBu YW1lPSJuYW1lIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0ibmNFdmVudDpzdHJl YW1OYW1lVHlwZSImZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRpb24m Z3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgVGhlIG5hbWUgb2YgdGhlIGV2ZW50IHN0cmVhbS4gSWYg dGhpcyBpcwogICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZGVmYXVsdCBORVRDT05GIHN0 cmVhbSwgdGhpcyBtdXN0IGhhdmUKICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHZhbHVl ICJORVRDT05GIi4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlv biZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAg ICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAgICZs dDt4czplbGVtZW50IG5hbWU9ImRlc2NyaXB0aW9uIgogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdHlwZT0ieHM6c3RyaW5nIiZndDsKICAgICAgICAgICAgICAgICAgICAg ICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICZsdDt4czpk b2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICBBIGRlc2NyaXB0aW9u IG9mIHRoZSBldmVudCBzdHJlYW0sIGluY2x1ZGluZwogICAgICAgICAgICAgICAgICAgICAgICAg ICBzdWNoIGluZm9ybWF0aW9uIGFzIHRoZSB0eXBlIG9mIGV2ZW50cyB0aGF0CiAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFyZSBzZW50IG92ZXIgdGhpcyBzdHJlYW0uCiAgICAgICAgICAgICAg ICAgICAgICAgICAmbHQ7L3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAg ICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxl bWVudCZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBsYXlT dXBwb3J0IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0ieHM6 Ym9vbGVhbiImZ3Q7CiAgICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0Owog ICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFuIGluZGljYXRpb24gb2Ygd2hldGhlciBvciBub3QgZXZlbnQg cmVwbGF5CiAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIGF2YWlsYWJsZSBvbiB0aGlzIHN0 cmVhbS4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsK ICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAg ICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAgICZsdDt4czpl bGVtZW50IG5hbWU9InJlcGxheUxvZ0NyZWF0aW9uVGltZSIKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB0eXBlPSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiZndDsKICAgICAg ICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICBUaGUg dGltZXN0YW1wIG9mIHRoZSBjcmVhdGlvbiBvZiB0aGUgbG9nCiAgICAgICAgICAgICAgICAgICAg ICAgdXNlZCB0byBzdXBwb3J0IHRoZSByZXBsYXkgZnVuY3Rpb24gb24KICAgICAgICAgICAgICAg ICAgICAgICB0aGlzIHN0cmVhbS4KICAgICAgICAgICAgICAgICAgICAgICBOb3RlIHRoYXQgdGhp cyBtaWdodCBiZSBlYXJsaWVyIHRoZW4KICAgICAgICAgICAgICAgICAgICAgICB0aGUgZWFybGll c3QgYXZhaWxhYmxlCiAgICAgICAgICAgICAgICAgICAgICAgbm90aWZpY2F0aW9uIGluIHRoZSBs b2cuIFRoaXMgb2JqZWN0CiAgICAgICAgICAgICAgICAgICAgICAgaXMgdXBkYXRlZCBpZiB0aGUg bG9nIHJlc2V0cwogICAgICAgICAgICAgICAgICAgICAgIGZvciBzb21lIHJlYXNvbi4gVGhpcwog ICAgICAgICAgICAgICAgICAgICAgIG9iamVjdCBNVVNUIGJlIHByZXNlbnQgaWYgcmVwbGF5IGlz CiAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkLgogICAgICAgICAgICAgICAgICAgICAg ICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICZsdDsv eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0 OwogICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBsYXlMb2dBZ2Vk VGltZSIKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGU9InhzOmRhdGVUaW1lIiBtaW5P Y2N1cnM9IjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0 OwogICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAg ICAgICAgICAgICAgICAgICAgICAgIFRoZSB0aW1lc3RhbXAgb2YgdGhlIGxhc3Qgbm90aWZpY2F0 aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGFnZWQgb3V0IG9mIHRoZSBsb2cuIFRoaXMK ICAgICAgICAgICAgICAgICAgICAgICAgICAgb2JqZWN0IE1VU1QgYmUgcHJlc2VudCBpZiByZXBs YXkgaXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkIGFuZCBhbnkgbm90aWZp Y2F0aW9ucwogICAgICAgICAgICAgICAgICAgICAgICAgICBoYXZlIGJlZW4gYWdlZCBvdXQgb2Yg dGhlIGxvZy4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZn dDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAg ICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAgICAgICAgICAgICZsdDsv eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsK ICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgJmx0Oy94czpz ZXF1ZW5jZSZndDsKICAgICAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICAgICAgICAm bHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAgJmx0Oy94czpj b21wbGV4VHlwZSZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iUmVwbGF5Q29tcGxl dGVOb3RpZmljYXRpb25UeXBlIiZndDsKICAgICAgICAmbHQ7eHM6Y29tcGxleENvbnRlbnQmZ3Q7 CiAgICAgICAgICAgICZsdDt4czpleHRlbnNpb24gYmFzZT0ibmNFdmVudDpOb3RpZmljYXRpb25D b250ZW50VHlwZSIvJmd0OwogICAgICAgICZsdDsveHM6Y29tcGxleENvbnRlbnQmZ3Q7CiAgICAm bHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwoKICAgICZsdDt4czplbGVtZW50IG5hbWU9InJlcGxheUNv bXBsZXRlIgogICAgICAgIHR5cGU9Im1hbmFnZUV2ZW50OlJlcGxheUNvbXBsZXRlTm90aWZpY2F0 aW9uVHlwZSIKICAgICAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmNFdmVudDpub3RpZmljYXRpb25D b250ZW50IiZndDsKICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAg ICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgIFRoaXMgbm90aWZpY2F0aW9u IGlzIHNlbnQgdG8gc2lnbmFsIHRoZSBlbmQgb2YgYSByZXBsYXkKICAgICAgICAgICAgcG9ydGlv biBvZiBhIHN1YnNjcmlwdGlvbi4KICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsK ICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0 OwoKICAgICZsdDt4czpjb21wbGV4VHlwZSBuYW1lPSJOb3RpZmljYXRpb25Db21wbGV0ZU5vdGlm aWNhdGlvblR5cGUiJmd0OwogICAgICAgICZsdDt4czpjb21wbGV4Q29udGVudCZndDsKICAgICAg ICAgICAgJmx0O3hzOmV4dGVuc2lvbiBiYXNlPSJuY0V2ZW50Ok5vdGlmaWNhdGlvbkNvbnRlbnRU eXBlIi8mZ3Q7CiAgICAgICAgJmx0Oy94czpjb21wbGV4Q29udGVudCZndDsKICAgICZsdDsveHM6 Y29tcGxleFR5cGUmZ3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibm90aWZpY2F0aW9uQ29t cGxldGUiCiAgICAgICAgdHlwZT0ibWFuYWdlRXZlbnQ6Tm90aWZpY2F0aW9uQ29tcGxldGVOb3Rp ZmljYXRpb25UeXBlIgogICAgICAgIHN1YnN0aXR1dGlvbkdyb3VwPSJuY0V2ZW50Om5vdGlmaWNh dGlvbkNvbnRlbnQiJmd0OwogICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAg ICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgVGhpcyBub3RpZmlj YXRpb24gaXMgc2VudCB0byBzaWduYWwgdGhlIGVuZCBvZiBhCiAgICAgICAgICAgIG5vdGlmaWNh dGlvbiBzdWJzY3JpcHRpb24uIEl0IGlzIHNlbnQgaW4gdGhlIGNhc2UKICAgICAgICAgICAgdGhh dCBzdG9wVGltZSB3YXMgc3BlY2lmaWVkIGR1cmluZyB0aGUgY3JlYXRpb24gb2YKICAgICAgICAg ICAgdGhlIHN1YnNjcmlwdGlvbi4KICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsK ICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0 OwoKJmx0Oy94czpzY2hlbWEmZ3Q7CgozLjUuICBTdWJzY3JpcHRpb25zIERhdGEKCiAgIFN1YnNj cmlwdGlvbnMgYXJlIG5vbi1wZXJzaXN0ZW50IHN0YXRlIGluZm9ybWF0aW9uIGFuZCB0aGVpciBs aWZldGltZQogICBpcyBkZWZpbmVkIGJ5IHRoZWlyIHNlc3Npb24gb3IgYnkgdGhlICZsdDtzdG9w VGltZSZndDsgcGFyYW1ldGVyLgoKMy42LiAgRmlsdGVyIE1lY2hhbmljcwoKICAgPHN0cmlrZT48 Zm9udCBjb2xvcj0ncmVkJz5XaGVuIG11bHRpcGxlIGZpbHRlciBlbGVtZW50cyBhcmUgc3BlY2lm aWVkLCB0aGV5IGFyZSBhcHBsaWVkCiAgIGNvbGxlY3RpdmVseSwgc28gZXZlbnQgbm90aWZpY2F0 aW9ucyBuZWVkIHRvIHBhc3MgYWxsIHNwZWNpZmllZAogICBmaWx0ZXIgZWxlbWVudHMgaW4gb3Jk ZXIgdG8gYmUgc2VudCB0byB0aGUgc3Vic2NyaWJlci48L2ZvbnQ+PC9zdHJpa2U+CgogICBJZiBh IGZpbHRlciBlbGVtZW50IGlzIHNwZWNpZmllZCB0byBsb29rIGZvciBkYXRhIG9mIGEgcGFydGlj dWxhcgogICB2YWx1ZSwgYW5kIHRoZSBkYXRhIGl0ZW0gaXMgbm90IHByZXNlbnQgd2l0aGluIGEg cGFydGljdWxhciBldmVudAogICBub3RpZmljYXRpb24gZm9yIGl0cyB2YWx1ZSB0byBiZSBjaGVj a2VkIGFnYWluc3QsIHRoZSBub3RpZmljYXRpb24KICAgd2lsbCBiZSBmaWx0ZXJlZCBvdXQuICBG b3IgZXhhbXBsZSwgaWYgb25lIHdlcmUgdG8gY2hlY2sgZm9yCiAgICdzZXZlcml0eT1jcml0aWNh bCcgaW4gYSBjb25maWd1cmF0aW9uIGV2ZW50IG5vdGlmaWNhdGlvbiB3aGVyZSB0aGlzCiAgIGZp ZWxkIHdhcyBub3Qgc3VwcG9ydGVkLCB0aGVuIHRoZSBub3RpZmljYXRpb24gd291bGQgYmUgZmls dGVyZWQgb3V0LgoKICAgRm9yIHN1YnRyZWUgZmlsdGVyaW5nLCBhIG5vbi1lbXB0eSBub2RlIHNl dCBtZWFucyB0aGF0IHRoZSBmaWx0ZXIKICAgbWF0Y2hlcy4gIEZvciBYUGF0aCBmaWx0ZXJpbmcs IHRoZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gW1hQQVRIXQogICBzaG91bGQgYmUgdXNlZCB0byBj b252ZXJ0IHRoZSByZXR1cm5lZCB2YWx1ZSB0byBib29sZWFuLgoKMy42LjEuICBGaWx0ZXJpbmcK CiAgIEZpbHRlcmluZyBpcyBleHBsaWNpdGx5IHN0YXRlZCB3aGVuIHRoZSBldmVudCBub3RpZmlj YXRpb24KICAgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQuICBUaGlzIGlzIHNwZWNpZmllZCB2aWEg dGhlICdmaWx0ZXInCiAgIHBhcmFtZXRlci4gIEEgRmlsdGVyIG9ubHkgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz5leGlzdDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3Jl ZW4nPmV4aXN0czwvZm9udD48L3N0cm9uZz4gYXMgYSBwYXJhbWV0ZXIgdG8gdGhlIHN1YnNjcmlw dGlvbi4KCjMuNy4gIE1lc3NhZ2UgRmxvdwogICBUaGUgZm9sbG93aW5nIGZpZ3VyZSBkZXBpY3Rz IG1lc3NhZ2UgZmxvdyBiZXR3ZWVuIGEgTkVUQ09ORiBjbGllbnQKICAgKEMpIGFuZCBORVRDT05G IHNlcnZlciAoUykgaW4gb3JkZXIgdG8gY3JlYXRlIGEgc3Vic2NyaXB0aW9uIGFuZAogICBiZWdp biB0aGUgZmxvdyBvZiBub3RpZmljYXRpb25zLiAgVGhpcyBzdWJzY3JpcHRpb24gc3BlY2lmaWVk IGEKICAgJmx0O3N0YXJ0VGltZSZndDssIHNvIHRoZSBzZXJ2ZXIgc3RhcnRzIGJ5IHJlcGxheWlu ZyBsb2dnZWQgbm90aWZpY2F0aW9ucy4KICAgSXQgaXMgcG9zc2libGUgdGhhdCBtYW55IHJwYy9y cGMtcmVwbHkgc2VxdWVuY2VzIG9jY3VyIGJlZm9yZSB0aGUKICAgc3Vic2NyaXB0aW9uIGlzIGNy ZWF0ZWQsIGJ1dCB0aGlzIGlzIG5vdCBkZXBpY3RlZCBpbiB0aGUgZmlndXJlLgoKICAgICAgICAg ICAgICAgICAgICAgICAgQyAgICAgICAgICAgICAgICAgICAgICAgICAgIFMKICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgICAgfCAgY2FwYWJpbGl0eSBleGNoYW5nZSAgICAgIHwKICAgICAgICAgICAgICAgICAg ICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAgICAgICAgICAg ICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAg ICAgICAgfCAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7ICAgIHwgKHN0YXJ0VGltZSkKICAg ICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAg ICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O3JwYy1yZXBseSZndDsgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICZsdDtub3RpZmljYXRpb24mZ3Q7ICAgICAg IHwgKHJlcGxheUNvbXBsZXRlKQogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9u Jmd0OyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0 OyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDMKICAgVGhlIGZv bGxvd2luZyBmaWd1cmUgZGVwaWN0cyBtZXNzYWdlIGZsb3cgYmV0d2VlbiBhIE5FVENPTkYgY2xp ZW50CiAgIChDKSBhbmQgTkVUQ09ORiBzZXJ2ZXIgKFMpIGluIG9yZGVyIHRvIGNyZWF0ZSBhIHN1 YnNjcmlwdGlvbiBhbmQKICAgYmVnaW4gdGhlIGZsb3cgb2Ygbm90aWZpY2F0aW9ucy4gIFRoaXMg c3Vic2NyaXB0aW9uIHNwZWNpZmllZCBhCiAgICZsdDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7c3Rv cFRpbWUmZ3Q7IHNvIGl0IHN0YXJ0cyBieSByZXBsYXlpbmcgbG9nZ2VkCiAgIG5vdGlmaWNhdGlv bnMgYW5kIHRoZW4gcmV0dXJucyB0byBiZSBhIG5vcm1hbCBjb21tYW5kLXJlc3BvbnNlCiAgIE5F VENPTkYgc2Vzc2lvbiBhZnRlciB0aGUgJmx0O3JlcGxheUNvbXBsZXRlJmd0OyBhbmQgJmx0O25v dGlmaWNhdGlvbkNvbXBsZXRlJmd0OwogICBub3RpZmljYXRpb25zIGFyZSBzZW50IGFuZCBpdCBp cyBhdmFpbGFibGUgdG8gcHJvY2VzcyAmbHQ7cnBjJmd0OyByZXF1ZXN0cy4KICAgSXQgaXMgcG9z c2libGUgdGhhdCBtYW55IHJwYy9ycGMtcmVwbHkgc2VxdWVuY2VzIG9jY3VyIGJlZm9yZSB0aGUK ICAgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQsIGJ1dCB0aGlzIGlzIG5vdCBkZXBpY3RlZCBpbiB0 aGUgZmlndXJlLgoKICAgICAgICAgICAgICAgICAgICAgQyAgICAgICAgICAgICAgICAgICAgICAg ICAgIFMKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgfCAgY2FwYWJpbGl0eSBleGNoYW5nZSAgICAgIHwKICAgICAg ICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAg ICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgfCAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7ICAgIHwgKHN0YXJ0VGltZSwKICAg ICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgIHN0b3BU aW1lKQogICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t fAogICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7cnBjLXJlcGx5Jmd0OyAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAogICAg ICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAogICAgICAgICAgICAg ICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAg ICAgICB8ICAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAgfCAocmVwbGF5Q29tcGxldGUp CiAgICAgICAgICAgICAgICAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18CiAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICB8KG5v dGlmaWNhdGlvbkNvbXBsZXRlKQogICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICZsdDtycGMmZ3Q7ICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fAogICAg ICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICZsdDtycGMtcmVwbHkmZ3Q7ICAgICAgICAgfAogICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAoKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDQKCjQuICBYTUwgU2NoZW1hIGZvciBFdmVudCBO b3RpZmljYXRpb25zCgogICBUaGUgZm9sbG93aW5nIFtYTUwgU2NoZW1hXSBkZWZpbmVzIE5FVENP TkYgRXZlbnQgTm90aWZpY2F0aW9ucy4KCiZsdDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9 IlVURi04Ij8mZ3Q7CiAgJmx0O3hzOnNjaGVtYSB4bWxuczp4cz0iaHR0cDovL3d3dy53My5vcmcv MjAwMS9YTUxTY2hlbWEiCiAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29u Zjpub3RpZmljYXRpb246MS4wIgogICAgIHhtbG5zOm5ldGNvbmY9InVybjppZXRmOnBhcmFtczp4 bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIKICAgICB0YXJnZXROYW1lc3BhY2U9CiAgICAgICAgInVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIgogICAgIGVsZW1l bnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIgogICAgIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1bnF1 YWxpZmllZCIKICAgICAgIHhtbDpsYW5nPSJlbiImZ3Q7CgogICAgJmx0OyEtLSBpbXBvcnQgc3Rh bmRhcmQgWE1MIGRlZmluaXRpb25zIC0tJmd0OwoKICAgICAmbHQ7eHM6aW1wb3J0IG5hbWVzcGFj ZT0iaHR0cDovL3d3dy53My5vcmcvWE1MLzE5OTgvbmFtZXNwYWNlIgogICAgICAgICAgICAgICAg c2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cudzMub3JnLzIwMDEveG1sLnhzZCImZ3Q7CiAgICAg ICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7 CiAgICAgICAgICAgVGhpcyBpbXBvcnQgYWNjZXNzZXMgdGhlIHhtbDogYXR0cmlidXRlIGdyb3Vw cyBmb3IgdGhlCiAgICAgICAgICAgeG1sOmxhbmcgYXMgZGVjbGFyZWQgb24gdGhlIGVycm9yLW1l c3NhZ2UgZWxlbWVudC4KICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAg Jmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICZsdDsveHM6aW1wb3J0Jmd0OwoKICAgICAmbHQ7 IS0tIGltcG9ydCBiYXNlIG5ldGNvbmYgZGVmaW5pdGlvbnMgLS0mZ3Q7CiAgICAgJmx0O3hzOmlt cG9ydCBuYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIK ICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+c2NoZW1hTG9jYXRpb249CiAgICAgImh0 dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lzdHJ5L3NjaGVtYS9uZXRjb25m LnhzZCIvJmd0OzwvZm9udD48L3N0cmlrZT4KICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dy ZWVuJz5zY2hlbWFMb2NhdGlvbj0ibmV0Y29uZi54c2QiLyZndDs8L2ZvbnQ+PC9zdHJvbmc+Cgom bHQ7IS0tICoqKioqKioqKioqKioqIFN5bW1ldHJpY2FsIE9wZXJhdGlvbnMgICoqKioqKioqKioq KioqKioqKioqLS0mZ3Q7CgogICAgICZsdDshLS0gJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7 IG9wZXJhdGlvbiAtLSZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iY3JlYXRlU3Vi c2NyaXB0aW9uVHlwZSImZ3Q7CiAgICAgICAgJmx0O3hzOmNvbXBsZXhDb250ZW50Jmd0OwogICAg ICAgICAgICAmbHQ7eHM6ZXh0ZW5zaW9uIGJhc2U9Im5ldGNvbmY6cnBjT3BlcmF0aW9uVHlwZSIm Z3Q7CiAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAg ICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtIgogICAgICAgICAgICAgICAgICAgICAgICB0 eXBlPSJzdHJlYW1OYW1lVHlwZSIgbWluT2NjdXJzPSIwIiZndDsKICAgICAgICAgICAgICAgICAg ICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAm bHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFu IG9wdGlvbmFsIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcwogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgd2hpY2ggc3RyZWFtIG9mIGV2ZW50cyBpcyBvZiBpbnRlcmVzdC4gSWYKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIG5vdCBwcmVzZW50LCB0aGVuIGV2ZW50cyBpbiB0aGUg ZGVmYXVsdAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTkVUQ09ORiBzdHJlYW0gd2ls bCBiZSBzZW50LgogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0 aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAg ICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJmaWx0ZXIiCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0eXBlPSJuZXRjb25mOmZpbHRlcklubGluZVR5cGUiCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBtaW5PY2N1cnM9IjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0 O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hz OmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFu IG9wdGlvbmFsIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcwogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB3aGljaCBzdWJzZXQgb2YgYWxsIHBvc3NpYmxlIGV2ZW50cwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpcyBvZiBpbnRlcmVzdC4gVGhlIGZvcm1hdCBv ZiB0aGlzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhcmFtZXRlciBpcyB0 aGUgc2FtZSBhcyB0aGF0IG9mIHRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBmaWx0ZXIgcGFyYW1ldGVyIGluIHRoZSBORVRDT05GCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHByb3RvY29sIG9wZXJhdGlvbnMuIElmIG5vdCBwcmVzZW50LAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbGwgZXZlbnRzIG5vdCBwcmVjbHVkZWQgYnkg b3RoZXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFyYW1ldGVycyB3aWxs IGJlIHNlbnQuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVu dGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czphbm5vdGF0aW9u Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAgICAg ICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RhcnRUaW1lIiB0eXBlPSJ4czpkYXRl VGltZSIKICAgICAgICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiAmZ3Q7CiAgICAgICAg ICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQSBwYXJhbWV0ZXIgdXNlZCB0byB0cmlnZ2VyIHRoZSByZXBsYXkKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBmZWF0dXJlIGFuZCBpbmRpY2F0ZXMgdGhhdCB0aGUgcmVw bGF5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2hvdWxkIHN0YXJ0IGF0IHRoZSB0 aW1lIHNwZWNpZmllZC4gSWYKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdGFydCB0 aW1lIGlzIG5vdCBwcmVzZW50LCB0aGlzIGlzIG5vdCBhCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgcmVwbGF5IHN1YnNjcmlwdGlvbi4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94 czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsK ICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzdG9wVGltZSIgdHlwZT0i eHM6ZGF0ZVRpbWUiCiAgICAgICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgJmd0Owog ICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEFuIG9wdGlvbmFsIHBhcmFtZXRlciB1c2VkIHdpdGggdGhlCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgb3B0aW9uYWwgcmVwbGF5IGZlYXR1cmUgdG8gaW5k aWNhdGUgdGhlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV3ZXN0IG5vdGlmaWNh dGlvbnMgb2YgaW50ZXJlc3QuIElmCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Rv cCB0aW1lIGlzIG5vdCBwcmVzZW50LCB0aGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBub3RpZmljYXRpb25zIHdpbGwgY29udGludWUgdW50aWwgdGhlCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3Vic2NyaXB0aW9uIGlzIHRlcm1pbmF0ZWQuIE11c3QgYmUgdXNlZAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGggc3RhcnRUaW1lLgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAg ICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgJmx0 Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAg ICAgICAgICAgJmx0Oy94czpleHRlbnNpb24mZ3Q7CiAgICAgICAgJmx0Oy94czpjb21wbGV4Q29u dGVudCZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CgogICAgJmx0O3hzOnNpbXBsZVR5 cGUgbmFtZT0ic3RyZWFtTmFtZVR5cGUiJmd0OwogICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0 OwogICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgIFRo ZSBuYW1lIG9mIGFuIGV2ZW50IHN0cmVhbS4KICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0 aW9uJmd0OwogICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAmbHQ7eHM6cmVz dHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIi8mZ3Q7CiAgICAmbHQ7L3hzOnNpbXBsZVR5cGUmZ3Q7 CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iY3JlYXRlLXN1YnNjcmlwdGlvbiIKICAgICAgICB0 eXBlPSJjcmVhdGVTdWJzY3JpcHRpb25UeXBlIgogICAgICAgIHN1YnN0aXR1dGlvbkdyb3VwPSJu ZXRjb25mOnJwY09wZXJhdGlvbiImZ3Q7CiAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAg ICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgVGhlIGNv bW1hbmQgdG8gY3JlYXRlIGEgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbi4gSXQKICAgICAgICAg ICAgICAgIHRha2VzIGFzIGFyZ3VtZW50IHRoZSBuYW1lIG9mIHRoZSBub3RpZmljYXRpb24gc3Ry ZWFtCiAgICAgICAgICAgICAgICBhbmQgZmlsdGVyLiBCb3RoIG9mIHRob3NlIG9wdGlvbnMKICAg ICAgICAgICAgICAgIGxpbWl0IHRoZSBjb250ZW50IG9mIHRoZSBzdWJzY3JpcHRpb24uIEluIGFk ZGl0aW9uLAogICAgICAgICAgICAgICAgdGhlcmUgYXJlIHR3byB0aW1lLXJlbGF0ZWQgcGFyYW1l dGVycywgc3RhcnRUaW1lIGFuZAogICAgICAgICAgICAgICAgc3RvcFRpbWUsIHdoaWNoIGNhbiBi ZSB1c2VkIHRvIHNlbGVjdCB0aGUgdGltZSBpbnRlcnZhbAogICAgICAgICAgICAgICAgb2YgaW50 ZXJlc3QgdG8gdGhlIG5vdGlmaWNhdGlvbiByZXBsYXkgZmVhdHVyZS4KICAgICAgICAgICAgJmx0 Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsKICAg ICZsdDsveHM6ZWxlbWVudCZndDsKCiZsdDshLS0gKioqKioqKioqKioqKiogT25lLXdheSBPcGVy YXRpb25zICAqKioqKioqKioqKioqKioqKiotLSZndDsKCiAgICAgJmx0OyEtLSAmbHQ7Tm90aWZp Y2F0aW9uJmd0OyBvcGVyYXRpb24gLS0mZ3Q7CiAgICAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9 Ik5vdGlmaWNhdGlvbkNvbnRlbnRUeXBlIi8mZ3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0i bm90aWZpY2F0aW9uQ29udGVudCIKICAgICAgICB0eXBlPSJOb3RpZmljYXRpb25Db250ZW50VHlw ZSIgYWJzdHJhY3Q9InRydWUiLyZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iTm90 aWZpY2F0aW9uVHlwZSImZ3Q7CiAgICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAgICAg ICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJldmVudFRpbWUiIHR5cGU9InhzOmRhdGVUaW1lIiZndDsK ICAgICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICZsdDt4 czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgVGhlIHRpbWUgdGhlIGV2ZW50IHdh cyBnZW5lcmF0ZWQgYnkgdGhlIGV2ZW50IHNvdXJjZQogICAgICAgICAgICAgICAgJmx0Oy94czpk b2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsKICAg ICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBy ZWY9Im5vdGlmaWNhdGlvbkNvbnRlbnQiLyZndDsKICAgICAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0 OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKCiAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJu b3RpZmljYXRpb24iIHR5cGU9Ik5vdGlmaWNhdGlvblR5cGUiLyZndDsKCiAgJmx0Oy94czpzY2hl bWEmZ3Q7Cgo1LiAgRmlsdGVyaW5nIEV4YW1wbGVzCgogICBUaGUgZm9sbG93aW5nIHNlY3Rpb24g cHJvdmlkZXMgZXhhbXBsZXMgdG8gaWxsdXN0cmF0ZSB0aGUgdmFyaW91cwogICBtZXRob2RzIG9m IGZpbHRlcmluZyBjb250ZW50IG9uIGFuIGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24u CgogICBJbiBvcmRlciB0byBpbGx1c3RyYXRlIHRoZSB1c2Ugb2YgZmlsdGVyIGV4cHJlc3Npb25z LCBpdCBpcyBuZWNlc3NhcnkKICAgdG8gYXNzdW1lIHNvbWUgb2YgdGhlIGV2ZW50IG5vdGlmaWNh dGlvbiBjb250ZW50LiAgVGhlIGV4YW1wbGVzIGJlbG93CiAgIGFzc3VtZSB0aGF0IHRoZSBldmVu dCBub3RpZmljYXRpb24gc2NoZW1hIGRlZmluaXRpb24gaGFzIGFuICZsdDtldmVudCZndDsKICAg ZWxlbWVudCBhdCB0aGUgdG9wIGxldmVsIGNvbnNpc3Rpbmcgb2YgdGhlIGV2ZW50IGNsYXNzIChl LmcuLCBmYXVsdCwKICAgc3RhdGUsIGNvbmZpZyksIHJlcG9ydGluZyBlbnRpdHkgYW5kIGVpdGhl ciBzZXZlcml0eSBvciBvcGVyYXRpb25hbAogICBzdGF0ZS4KCiAgIEV4YW1wbGVzIGluIHRoaXMg c2VjdGlvbiBhcmUgZ2VuZXJhdGVkIGZyb20gdGhlIGZvbGxvd2luZyBmaWN0aW9uYWwKICAgU2No ZW1hLgoKICAgICZsdDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7CiAg ICZsdDt4czpzY2hlbWEgdGFyZ2V0TmFtZXNwYWNlPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQv MS4wIgogICAgICAgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiCiAgICAgICBl bGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCIKICAgICAgIHhtbG5zOnhzPSJodHRwOi8vd3d3 LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIKICAgICAgIHhtbG5zOm5jRXZlbnQ9InVybjppZXRmOnBh cmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIiZndDsKCiAgICAgICAmbHQ7eHM6 aW1wb3J0IG5hbWVzcGFjZT0KICAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOm5vdGlmaWNhdGlvbjoxLjAiCiAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5z Y2hlbWFMb2NhdGlvbj0KImh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lz dHJ5L3NjaGVtYS9ub3RpZmljYXRpb24ueHNkIi8mZ3Q7PC9mb250Pjwvc3RyaWtlPgogICAgICAg ICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5zY2hlbWFMb2NhdGlvbj0ibm90aWZpY2F0 aW9uLnhzZCIvJmd0OzwvZm9udD48L3N0cm9uZz4KCiAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUg bmFtZT0iZXZlbnRUeXBlIiZndDsKICAgICAgICAgICAmbHQ7eHM6Y29tcGxleENvbnRlbnQmZ3Q7 CiAgICAgICAgICAgICAgICZsdDt4czpleHRlbnNpb24gYmFzZT0ibmNFdmVudDpOb3RpZmljYXRp b25Db250ZW50VHlwZSImZ3Q7CiAgICAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7 CiAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZXZlbnRDbGFzcyIg LyZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBvcnRp bmdFbnRpdHkiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6Y29tcGxleFR5 cGUmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7 CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFueSBuYW1lc3BhY2U9 IiMjYW55IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb2Nlc3NDb250ZW50 cz0ibGF4Ii8mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOnNlcXVl bmNlJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0 OwogICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAgICAg ICAgICAgICAgICAmbHQ7eHM6Y2hvaWNlJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAm bHQ7eHM6ZWxlbWVudCBuYW1lPSJzZXZlcml0eSIvJmd0OwogICAgICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJvcGVyU3RhdGUiLyZndDsKICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7L3hzOmNob2ljZSZndDsKICAgICAgICAgICAgICAgICAgICZsdDsveHM6c2Vx dWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICZsdDsveHM6ZXh0ZW5zaW9uJmd0OwogICAgICAgICAg ICZsdDsveHM6Y29tcGxleENvbnRlbnQmZ3Q7CiAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0 OwoKICAgICAgICZsdDt4czplbGVtZW50IG5hbWU9ImV2ZW50IgogICAgICAgICAgIHR5cGU9ImV2 ZW50VHlwZSIKICAgICAgICAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmNFdmVudDpub3RpZmljYXRp b25Db250ZW50Ii8mZ3Q7CgogICAmbHQ7L3hzOnNjaGVtYSZndDsKCiAgIFRoZSBhYm92ZSBmaWN0 aW9uYWwgbm90aWZpY2F0aW9uIGRlZmluaXRpb24gY291bGQgcmVzdWx0IGluIHRoZQogICBmb2xs b3dpbmcgc2FtcGxlIG5vdGlmaWNhdGlvbiBsaXN0LCB3aGljaCBpcyB1c2VkIGluIHRoZSBleGFt cGxlcyBpbgogICB0aGlzIHNlY3Rpb24uCgogICAmbHQ7bm90aWZpY2F0aW9uCiAgICAgIHhtbG5z PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAg ICAgICZsdDtldmVudFRpbWUmZ3Q7MjAwNy0wNy0wOFQwMDowMTowMFombHQ7L2V2ZW50VGltZSZn dDsKICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZn dDsKICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAg ICAgICAgICZsdDtyZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICAgICAmbHQ7Y2FyZCZndDtF dGhlcm5ldDAmbHQ7L2NhcmQmZ3Q7CiAgICAgICAgICZsdDsvcmVwb3J0aW5nRW50aXR5Jmd0Owog ICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7bWFqb3ImbHQ7L3NldmVyaXR5Jmd0OwogICAgICAgJmx0 Oy9ldmVudCZndDsKICAgJmx0Oy9ub3RpZmljYXRpb24mZ3Q7CgogICAmbHQ7bm90aWZpY2F0aW9u CiAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246 MS4wIiZndDsKICAgICAgJmx0O2V2ZW50VGltZSZndDsyMDA3LTA3LTA4VDAwOjAyOjAwWiZsdDsv ZXZlbnRUaW1lJmd0OwogICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9l dmVudC8xLjAiJmd0OwogICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50 Q2xhc3MmZ3Q7CiAgICAgICAgICAmbHQ7cmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgICAg ICZsdDtjYXJkJmd0O0V0aGVybmV0MiZsdDsvY2FyZCZndDsKICAgICAgICAgICZsdDsvcmVwb3J0 aW5nRW50aXR5Jmd0OwogICAgICAgICAgJmx0O3NldmVyaXR5Jmd0O2NyaXRpY2FsJmx0Oy9zZXZl cml0eSZndDsKICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICZsdDsvbm90aWZpY2F0aW9uJmd0OwoK ICAgJmx0O25vdGlmaWNhdGlvbgogICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5l dGNvbmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAgICAgICZsdDtldmVudFRpbWUmZ3Q7MjAwNy0w Ny0wOFQwMDowNDowMFombHQ7L2V2ZW50VGltZSZndDsKICAgICAgJmx0O2V2ZW50IHhtbG5zPSJo dHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICZsdDtldmVudENsYXNz Jmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgJmx0O3JlcG9ydGluZ0VudGl0 eSZndDsKICAgICAgICAgICAgICAgJmx0O2NhcmQmZ3Q7QVRNMSZsdDsvY2FyZCZndDsKICAgICAg ICAgICAmbHQ7L3JlcG9ydGluZ0VudGl0eSZndDsKICAgICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7 bWlub3ImbHQ7L3NldmVyaXR5Jmd0OwogICAgICAmbHQ7L2V2ZW50Jmd0OwogICAmbHQ7L25vdGlm aWNhdGlvbiZndDsKCiAgICZsdDtub3RpZmljYXRpb24KICAgICB4bWxucz0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiJmd0OwogICAgICZsdDtldmVudFRp bWUmZ3Q7MjAwNy0wNy0wOFQwMDoxMDowMFombHQ7L2V2ZW50VGltZSZndDsKICAgICAmbHQ7ZXZl bnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiJmd0OwogICAgICAgICAmbHQ7 ZXZlbnRDbGFzcyZndDtzdGF0ZSZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgJmx0O3JlcG9y dGluZ0VudGl0eSZndDsKICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0aGVybmV0MCZsdDsvY2Fy ZCZndDsKICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICZsdDtvcGVy U3RhdGUmZ3Q7ZW5hYmxlZCZsdDsvb3BlclN0YXRlJmd0OwogICAgICAmbHQ7L2V2ZW50Jmd0Owog ICAmbHQ7L25vdGlmaWNhdGlvbiZndDsKCjUuMS4gIFN1YnRyZWUgRmlsdGVyaW5nCgogICBYTUwg c3VidHJlZSBmaWx0ZXJpbmcgaXMgbm90IHdlbGwtc3VpdGVkIGZvciBjcmVhdGluZyBlbGFib3Jh dGUKICAgZmlsdGVyIGRlZmluaXRpb25zIGdpdmVuIHRoYXQgaXQgb25seSBzdXBwb3J0cyBlcXVh bGl0eSBjb21wYXJpc29ucwogICBhbmQgYXBwbGljYXRpb24gb2YgdGhlIGxvZ2ljYWwgT1Igb3Bl cmF0b3JzIChlLmcuLCBpbiBhbiBldmVudAogICBzdWJ0cmVlIGdpdmUgbWUgYWxsIGV2ZW50IG5v dGlmaWNhdGlvbnMgd2hpY2ggaGF2ZSBzZXZlcml0eT1jcml0aWNhbAogICBvciBzZXZlcml0eT1t YWpvciBvciBzZXZlcml0eT1taW5vcikuICBOZXZlcnRoZWxlc3MsIGl0IG1heSBiZSB1c2VkCiAg IGZvciBkZWZpbmluZyBzaW1wbGUgZXZlbnQgbm90aWZpY2F0aW9uIGZvcndhcmRpbmcgZmlsdGVy cyBhcyBzaG93bgogICBiZWxvdy4KCiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBpbGx1c3RyYXRl cyBob3cgdG8gc2VsZWN0IGZhdWx0IGV2ZW50cyB3aGljaAogICBoYXZlIHNldmVyaXRpZXMgb2Yg Y3JpdGljYWwsIG1ham9yLCBvciBtaW5vci4gIFRoZSBmaWx0ZXJpbmcgY3JpdGVyaWEKICAgZXZh bHVhdGlvbiBpcyBhcyBmb2xsb3dzOgoKICAgKChmYXVsdCAmYW1wOyBzZXZlcml0eT1jcml0aWNh bCkgfCAoZmF1bHQgJmFtcDsgc2V2ZXJpdHk9bWFqb3IpIHwgKGZhdWx0ICZhbXA7CiAgIHNldmVy aXR5PW1pbm9yKSkKCiAgICAgICAgJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0i MTAxIgogICAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpu czpuZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9u CiAgICAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3Rp ZmljYXRpb246MS4wIiZndDsKICAgICAgICAgICAgJmx0O2ZpbHRlciBuZXRjb25mOnR5cGU9InN1 YnRyZWUiJmd0OwogICAgICAgICAgICAgICZsdDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUu Y29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7ZXZlbnRDbGFzcyZndDtmYXVs dCZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgICAgICAgICZsdDtzZXZlcml0eSZndDtjcml0 aWNhbCZsdDsvc2V2ZXJpdHkmZ3Q7CiAgICAgICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAgICAg ICAgICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiJmd0 OwogICAgICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xhc3Mm Z3Q7CiAgICAgICAgICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7bWFqb3ImbHQ7L3NldmVyaXR5Jmd0 OwogICAgICAgICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICAgICAgICAgICAgJmx0O2V2ZW50IHht bG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgICAgICZs dDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgICAgICAg Jmx0O3NldmVyaXR5Jmd0O21pbm9yJmx0Oy9zZXZlcml0eSZndDsKICAgICAgICAgICAgICAmbHQ7 L2V2ZW50Jmd0OwogICAgICAgICAgICAmbHQ7L2ZpbHRlciZndDsKICAgICAgICAgICZsdDsvY3Jl YXRlLXN1YnNjcmlwdGlvbiZndDsKICAgICAgICAmbHQ7L25ldGNvbmY6cnBjJmd0OwoKICAgVGhl IGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVzIGhvdyB0byBzZWxlY3Qgc3RhdGUgb3IgY29u ZmlnCiAgIEV2ZW50Q2xhc3NlcyBvciBmYXVsdCBldmVudHMgdGhhdCBhcmUgcmVsYXRlZCB0byBj YXJkIEV0aGVybmV0MC4gIFRoZQogICBmaWx0ZXJpbmcgY3JpdGVyaWEgZXZhbHVhdGlvbiBpcyBh cyBmb2xsb3dzOgoKICAgKCBzdGF0ZSB8IGNvbmZpZyB8ICggZmF1bHQgJmFtcDsgKCBjYXJkPUV0 aGVybmV0MCkpKQoKJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAxIgogICAg ICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25m OmJhc2U6MS4wIiZndDsKICAgICAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24KICAgICAgICAgIHht bG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7 CiAgICAgICAgJmx0O2ZpbHRlciBuZXRjb25mOnR5cGU9InN1YnRyZWUiJmd0OwogICAgICAgICAg Jmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAg ICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7c3RhdGUmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAgICAgICAg ICAmbHQ7L2V2ZW50Jmd0OwogICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBs ZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7Y29uZmln Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAgICAgICAgICZs dDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAg ICAgICZsdDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAg ICAmbHQ7cmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0aGVy bmV0MCZsdDsvY2FyZCZndDsKICAgICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7CiAg ICAgICAgICAmbHQ7L2V2ZW50Jmd0OwogICAgICAgICZsdDsvZmlsdGVyJmd0OwogICAgICAmbHQ7 L2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiZsdDsvbmV0Y29uZjpycGMmZ3Q7Cgo1LjIuICBYUEFU SCBmaWx0ZXJzCgogICBUaGUgZm9sbG93aW5nIFtYUEFUSF0gZXhhbXBsZSBpbGx1c3RyYXRlcyBo b3cgdG8gc2VsZWN0IGZhdWx0CiAgIEV2ZW50Q2xhc3Mgbm90aWZpY2F0aW9ucyB0aGF0IGhhdmUg c2V2ZXJpdGllcyBvZiBjcml0aWNhbCwgbWFqb3IsIG9yCiAgIG1pbm9yLiAgVGhlIGZpbHRlcmlu ZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoKGZhdWx0KSAmYW1wOyAo KHNldmVyaXR5PWNyaXRpY2FsKSB8IChzZXZlcml0eT1tYWpvcikgfCAoc2V2ZXJpdHkgPQogICBt aW5vcikpKQoKICAgICAgJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAxIgog ICAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIiZndDsKICAgICAgICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbgogICAgICAg ICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9u OjEuMCImZ3Q7CiAgICAgICAgICAmbHQ7ZmlsdGVyIG5ldGNvbmY6dHlwZT0ieHBhdGgiCiAgICAg ICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIgogICAg ICAgICAgICAgc2VsZWN0PSIvZXg6ZXZlbnRbZXg6ZXZlbnRDbGFzcz0nZmF1bHQnIGFuZAogICAg ICAgICAgICAgICAgICAoZXg6c2V2ZXJpdHk9J21pbm9yJyBvciBleDpzZXZlcml0eT0nbWFqb3In CiAgICAgICAgICAgICAgICAgICAgICAgb3IgZXg6c2V2ZXJpdHk9J2NyaXRpY2FsJyldIi8mZ3Q7 CiAgICAgICAgJmx0Oy9jcmVhdGUtc3Vic2NyaXB0aW9uJmd0OwogICAgICAmbHQ7L25ldGNvbmY6 cnBjJmd0OwogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgaWxsdXN0cmF0ZXMgaG93IHRvIHNlbGVj dCBzdGF0ZSBhbmQgY29uZmlnCiAgIEV2ZW50Q2xhc3NlcyBvciBmYXVsdCBldmVudHMgb2YgYW55 IHNldmVyaXR5IHRoYXQgY29tZSBmcm9tIGNhcmQKICAgRXRoZXJuZXQwLiAgVGhlIGZpbHRlcmlu ZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoIHN0YXRlIHwgY29uZmln IHwgKGZhdWx0ICZhbXA7IGNhcmQ9RXRoZXJuZXQwKSkKCiAgICAgICZsdDtuZXRjb25mOnJwYyBt ZXNzYWdlLWlkPSIxMDEiCiAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAmbHQ7Y3JlYXRlLXN1YnNj cmlwdGlvbgogICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6 bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAgICAgICAgICAgICAmbHQ7ZmlsdGVyIG5ldGNvbmY6dHlw ZT0ieHBhdGgiCiAgICAgICAgICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5j b20vZXZlbnQvMS4wIgogICAgICAgICAgICAgICAgc2VsZWN0PSIvZXg6ZXZlbnRbCiAgICAgICAg ICAgICAgICAgICAoZXg6ZXZlbnRDbGFzcz0nc3RhdGUnIG9yIGV4OmV2ZW50Q2xhc3M9J2NvbmZp ZycpIG9yCiAgICAgICAgICAgICAgICAgICAoKGV4OmV2ZW50Q2xhc3M9J2ZhdWx0JyBhbmQgZXg6 Y2FyZD0nRXRoZXJuZXQwJykpXSIvJmd0OwogICAgICAgJmx0Oy9jcmVhdGUtc3Vic2NyaXB0aW9u Jmd0OwogICAgICZsdDsvbmV0Y29uZjpycGMmZ3Q7Cgo2LiAgSW50ZXJsZWF2ZSBDYXBhYmlsaXR5 Cgo2LjEuICBEZXNjcmlwdGlvbgoKICAgVGhlIEludGVybGVhdmUgY2FwYWJpbGl0eSBpbmRpY2F0 ZXMgdGhhdCB0aGUgTkVUQ09ORiBwZWVyIHN1cHBvcnRzCiAgIHRoZSBhYmlsaXR5IHRvIGludGVy bGVhdmUgb3RoZXIgTkVUQ09ORiBvcGVyYXRpb25zIHdpdGhpbiBhCiAgIE5vdGlmaWNhdGlvbiBz dWJzY3JpcHRpb24uICBUaGlzIG1lYW5zIHRoZSBORVRDT05GIHNlcnZlciBNVVNUCiAgIHJlY2Vp dmUsIHByb2Nlc3MgYW5kIHJlc3BvbmQgdG8gTkVUQ09ORiByZXF1ZXN0cyBvbiBhIHNlc3Npb24g d2l0aCBhbgogICBhY3RpdmUgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbi4gIDxzdHJvbmc+PGZv bnQgY29sb3I9J2dyZWVuJz5UaGlzIGNhcGFiaWxpdHkgaGVscHMgc2NhbGFiaWxpdHkKICAgYnkg cmVkdWNpbmcgdGhlIHRvdGFsIG51bWJlciBvZiBORVRDT05GIHNlc3Npb25zIHJlcXVpcmVkIGJ5 IGEgZ2l2ZW4KICAgb3BlcmF0b3Igb3IgbWFuYWdlbWVudCBhcHBsaWNhdGlvbi48L2ZvbnQ+PC9z dHJvbmc+Cgo2LjIuICBEZXBlbmRlbmNpZXMKCiAgIFRoaXMgY2FwYWJpbGl0eSBpcyBkZXBlbmRh bnQgb24gdGhlIG5vdGlmaWNhdGlvbiBjYXBhYmlsaXR5IGJlaW5nCiAgIHN1cHBvcnRlZC4KCjYu My4gIENhcGFiaWxpdHkgSWRlbnRpZmllcgoKICAgVGhlIDppbnRlcmxlYXZlIGNhcGFiaWxpdHkg aXMgaWRlbnRpZmllZCBieSB0aGUgZm9sbG93aW5nIGNhcGFiaWxpdHkKICAgc3RyaW5nOgoKICAg dXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTppbnRlcmxlYXZlOjEuMAoKNi40LiAg TmV3IE9wZXJhdGlvbnMKCiAgIE5vbmUuCgo2LjUuICBNb2RpZmljYXRpb25zIHRvIEV4aXN0aW5n IE9wZXJhdGlvbnMKCiAgIFdoZW4gYSAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsgaXMgc2Vu dCB3aGlsZSBhbm90aGVyIHN1YnNjcmlwdGlvbiBpcwogICBhY3RpdmUgb24gdGhhdCBzZXNzaW9u LCB0aGUgZm9sbG93aW5nIGVycm9yIHdpbGwgYmUgcmV0dXJuZWQ6CgogICAgICBUYWc6IG9wZXJh dGlvbi1mYWlsZWQKCiAgICAgIEVycm9yLXR5cGU6IHByb3RvY29sCgogICAgICBTZXZlcml0eTog ZXJyb3IKCiAgICAgIEVycm9yLWluZm86IG5vbmUKCiAgICAgIERlc2NyaXB0aW9uOiBSZXF1ZXN0 IGNvdWxkIG5vdCBiZSBjb21wbGV0ZWQgYmVjYXVzZSB0aGUgcmVxdWVzdGVkCiAgICAgIG9wZXJh dGlvbiBmYWlsZWQgZm9yIHNvbWUgcmVhc29uIG5vdCBjb3ZlcmVkIGJ5IGFueSBvdGhlciBlcnJv cgogICAgICBjb25kaXRpb24uCgo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmcm9tIHRoZSBiYXNlIFtORVRDT05GXSBkb2N1bWVudCBh bHNvCiAgIGFwcGx5IHRvIHRoZSBOb3RpZmljYXRpb24gY2FwYWJpbGl0eS4KCiAgIFRoZSBhY2Nl c3MgY29udHJvbCBmcmFtZXdvcmsgYW5kIHRoZSBjaG9pY2Ugb2YgdHJhbnNwb3J0IHdpbGwgaGF2 ZSBhCiAgIG1ham9yIGltcGFjdCBvbiB0aGUgc2VjdXJpdHkgb2YgdGhlIHNvbHV0aW9uLgoKICAg VGhlICZsdDtub3RpZmljYXRpb24mZ3Q7IGVsZW1lbnRzIGFyZSBuZXZlciBzZW50IGJlZm9yZSB0 aGUgdHJhbnNwb3J0IGxheWVyCiAgIGFuZCB0aGUgTkVUQ09ORiBsYXllciwgaW5jbHVkaW5nIGNh cGFiaWxpdGllcyBleGNoYW5nZSwgaGF2ZSBiZWVuCiAgIGVzdGFibGlzaGVkLCBhbmQgdGhlIG1h bmFnZXIgaGFzIGJlZW4gaWRlbnRpZmllZCBhbmQgYXV0aGVudGljYXRlZC4KCiAgIEl0IGlzIHJl Y29tbWVuZGVkIHRoYXQgY2FyZSBiZSB0YWtlbiB0byBzZWN1cmUgZXhlY3V0aW9uOgoKICAgbyAg Jmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IGludm9jYXRpb24KCiAgIG8gICZsdDtnZXQmZ3Q7 IG9uIHJlYWQtb25seSBkYXRhIG1vZGVscwoKICAgbyAgJmx0O25vdGlmaWNhdGlvbiZndDsgY29u dGVudAoKICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPlNlY3VyZSBleGVjdXRpb24gbWVh bnMgZW5zdXJpbmcgdGhhdCBhIHNlY3VyZSB0cmFuc3BvcnQgaXMgdXNlZCBhcwogICB3ZWxsIGFz IGVuc3VyaW5nIHRoYXQgdGhlIHVzZXIgaGFzIHN1ZmZpY2llbnQgYXV0aG9yaXphdGlvbiB0bwog ICBwZXJmb3JtIHRoZSBmdW5jdGlvbiB0aGV5IGFyZSByZXF1ZXN0aW5nIGFnYWluc3QgdGhlIHNw ZWNpZmljIHBpZWNlCiAgIG9mIE5FVENPTkYgY29udGVudCBpbnZvbHZlZC4gIFdoZW4gYSAmbHQ7 Z2V0Jmd0OyBpcyByZWNlaXZlZCBhZ2FpbnN0IHRoZQogICBjb250ZW50IGRlZmluZWQgaW4gdGhp cyBtZW1vLCBjbGllbnRzIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gdmlldyB0aGUKICAgY29udGVu dCBmb3Igd2hpY2ggdGhleSBoYXZlIHN1ZmZpY2llbnQgcHJpdmlsZWdlcy4gIEEgY3JlYXRlICZs dDtjcmVhdGUtCiAgIHN1YnNjcmlwdGlvbiZndDsgb3BlcmF0aW9uIGNhbiBiZSBjb25zaWRlcmVk IGxpa2UgYSBkZWZlcnJlZCAmbHQ7Z2V0Jmd0OywgYW5kCiAgIHRoZSBjb250ZW50IHRoYXQgZGlm ZmVyZW50IHVzZXJzIGNhbiBhY2Nlc3MgbWF5IHZhcnkuICBUaGlzIGRpZmZlcmVudAogICBhY2Nl c3MgaXMgcmVmbGVjdGVkIGluIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyB0aGF0IGRpZmZlcmVu dCB1c2VycyBhcmUKICAgYWJsZSB0byBzdWJzY3JpYmUgdG8uPC9mb250Pjwvc3Ryb25nPgoKICAg T25lIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZSBpcyB0aGUgdHJhbnNwb3J0IG9mIGRhdGEgZnJv bSBub24tCiAgIE5FVENPTkYgc3RyZWFtcywgc3VjaCBhcyBzeXNsb2cgYW5kIFNOTVAuICBUaGlz IGRhdGEgbWF5IGJlIG1vcmUKICAgdnVsbmVyYWJsZSAob3IgbGVzcyB2dWxuZXJhYmxlKSB3aGVu IGJlaW5nIHRyYW5zcG9ydGVkIG92ZXIgTkVUQ09ORgogICB0aGFuIHdoZW4gYmVpbmcgdHJhbnNw b3J0ZWQgdXNpbmcgdGhlIHByb3RvY29sIG5vcm1hbGx5IHVzZWQgZm9yCiAgIHRyYW5zcG9ydGlu ZyBpdCwgZGVwZW5kaW5nIG9uIHRoZSBzZWN1cml0eSBjcmVkZW50aWFscyBvZiB0aGUgdHdvCiAg IHN1YnN5c3RlbXMuICBUaGUgTkVUQ09ORiBzZXJ2ZXIgaXMgcmVzcG9uc2libGUgZm9yIGFwcGx5 aW5nIGFjY2VzcwogICBjb250cm9sIHRvIHN0cmVhbSBjb250ZW50LgoKICAgVGhlIGNvbnRlbnRz IG9mIG5vdGlmaWNhdGlvbnMgYXMgd2VsbCBhcyB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk Jz5uYW1lPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+bmFtZXM8 L2ZvbnQ+PC9zdHJvbmc+IG9mIGV2ZW50IHN0cmVhbXMKICAgbWF5IGNvbnRhaW4gc2Vuc2l0aXZl IGluZm9ybWF0aW9uIGFuZCBjYXJlIHNob3VsZCBiZSB0YWtlbiB0byBlbnN1cmUKICAgdGhhdCA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPml0IGlzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+dGhleSBhcmU8L2ZvbnQ+PC9zdHJvbmc+IHZpZXdlZCBvbmx5IGJ5 IGF1dGhvcml6ZWQgdXNlcnMuICBJZiBhIHVzZXIgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5k b2VzIG5vdCBoYXZlCiAgIHBlcm1pc3Npb24gdG8gdmlldyBjb250ZW50IHZpYSBvdGhlciBORVRD T05GIG9wZXJhdGlvbnMsIGl0IG11c3Qgbm90CiAgIGhhdmUgYWNjZXNzIHRoYXQgY29udGVudCB2 aWEgTm90aWZpY2F0aW9ucy4gIElmIGEgdXNlcjwvZm9udD48L3N0cmlrZT4gaXMgbm90CiAgIDxz dHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+cGVybWl0dGVkPC9mb250Pjwvc3RyaWtlPgogICA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbic+YXV0aG9yaXplZDwvZm9udD48L3N0cm9uZz4gdG8gdmll dyA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPm9uZSBlbGVtZW50PC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+YWxsIGVsZW1lbnRzPC9mb250Pjwvc3Ryb25nPiBp biB0aGUgY29udGVudCBvZiB0aGUgbm90aWZpY2F0aW9uLAogICB0aGUgbm90aWZpY2F0aW9uIGlz IG5vdCBzZW50IHRvIHRoYXQgdXNlci4KCiAgIElmIGEgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQg d2l0aCBhICZsdDtzdG9wVGltZSZndDssIHRoZSBORVRDT05GIHNlc3Npb24KICAgd2lsbCByZXR1 cm4gdG8gYmVpbmcgYSBub3JtYWwgY29tbWFuZC1yZXNwb25zZSBORVRDT05GIHNlc3Npb24gd2hl bgogICB0aGUgcmVwbGF5IGlzIGNvbXBsZXRlZC4gIEl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBv ZiB0aGUgTkVUQ09ORgogICBjbGllbnQgdG8gY2xvc2UgdGhpcyBzZXNzaW9uIHdoZW4gaXQgaXMg bm8gbG9uZ2VyIG9mIHVzZS4KCjguICBJQU5BIENvbnNpZGVyYXRpb25zCgogICAtLSBFZGl0b3Ig bm90ZSB0byBJQU5BL1JGQy1FZGl0b3I6IHdlIHJlcXVlc3QgdGhhdCB5b3UgbWFrZSB0aGVzZQog ICBhc3NpZ25tZW50cywgaW4gd2hpY2ggY2FzZSBpdCBpcyB0byBiZSBkb2N1bWVudGVkIGFzIGJl bG93CgogICBUaGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0aHJlZSBVUklzIGZvciB0aGUgTkVUQ09O RiBYTUwgbmFtZXNwYWNlIGluCiAgIHRoZSBJRVRGIFhNTCByZWdpc3RyeSBbUkZDMzY4OF0uCgog ICBGb2xsb3dpbmcgdGhlIGZvcm1hdCBpbiBSRkMgMzY4OCwgSUFOQSBoYXMgbWFkZSB0aGUgZm9s bG93aW5nCiAgIHJlZ2lzdHJhdGlvbi4gIE5vdGUgdGhhdCB0aGUgY2FwYWJpbGl0eSB1cm5zIGFz IGFsc28gY29tcGxpYW50IHRvCiAgIFtORVRDT05GXSBzZWN0aW9uIDEwLjMuCgogICArLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsKICAgfCBJbmRleCAgICAgICAgICAgICAgfCBDYXBhYmlsaXR5IElkZW50aWZpZXIgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IDpub3RpZmljYXRpb24g ICAgICB8IHVybjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6ICAgICAgICAgIHwKICAg fCAgICAgICAgICAgICAgICAgICAgfCBub3RpZmljYXRpb246MS4wICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDppbnRlcmxlYXZlICAgICAgICB8IHVy bjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6ICAgICAgICAgIHwKICAgfCAgICAgICAg ICAgICAgICAgICAgfCBpbnRlcmxlYXZlOjEuMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwoKICAgVVJJOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldG1v ZDpub3RpZmljYXRpb24KCiAgIFVSSTogdXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOm5v dGlmaWNhdGlvbjoxLjAKCiAgIFJlZ2lzdHJhbnQgQ29udGFjdDogVGhlIElFU0cuCgogICBYTUw6 IE4vQSwgdGhlIHJlcXVlc3RlZCBVUkkgaXMgYW4gWE1MIG5hbWVzcGFjZS4KCiAgIEluIGFkZGl0 aW9uLCBJQU5BIHJlZ2lzdGVyZWQgdGhlIGZvbGxvd2luZyBYTUwgU2NoZW1hLCB0aGUgZGVmaW5p dGlvbgogICBvZiB3aGljaCBjYW4gYmUgZm91bmQgaW4gU2VjdGlvbiA0OgogICBodHRwOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbm90aWZpY2F0aW9uLnhz ZAoKOS4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoYW5rcyB0byBHaWxiZXJ0IEdhZ25vbiwgR3Jl ZyBXaWxidXIgYW5kIEtpbSBDdXJyYW4gZm9yIHByb3ZpZGluZwogICB0aGVpciBpbnB1dCBpbnRv IHRoZSBlYXJseSB3b3JrIG9uIHRoaXMgZG9jdW1lbnQuICBJbiBhZGRpdGlvbiwgdGhlCiAgIGVk aXRvcnMgd291bGQgbGlrZSB0byBhY2tub3dsZWRnZSBpbnB1dCBhdCB0aGUgVmFuY291dmVyIGVk aXRpbmcKICAgc2Vzc2lvbiBmcm9tIHRoZSBmb2xsb3dpbmcgcGVvcGxlOiBPcmx5IE5pY2tsYXNz LCBKYW1lcyBCYWxlc3RyaWVyZSwKICAgWW9zaGlmdW1pIEF0YXJhc2hpLCBHbGVubiBXYXRlcnMs IEFsZXhhbmRlciBDbGVtbSwgRGF2ZSBIYXJyaW5ndG9uLAogICBEYXZlIFBhcnRhaW4sIFJheSBB dGFyYXNoaSBhbmQgRGF2aWQgUGVya2lucyBhbmQgdGhlIGZvbGxvd2luZwogICBhZGRpdGlvbmFs IHBlb3BsZSBmcm9tIHRoZSBNb250cmVhbCBlZGl0aW5nIHNlc3Npb246IEJhbGF6cyBMZW5neWVs LAogICBQaGlsIFNoYWZlciwgUm9iIEVubnMsIEFuZHkgQmllcm1hbiwgRGFuIFJvbWFzY2FudSwg QmVydCBXaWpuZW4sCiAgIFNpbW9uIExlaW5lbiwgSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBIaWRl a2kgT2tpdGEsIFZpbmNlbnQgQ3JpZGxpZywKICAgTWFydGluIEJqb3JrbHVuZCwgT2xpdmllciBG ZXN0b3IsIFJhZHUgU3RhdGUsIEJyaWFuIFRyYW1tZWxsLCBXaWxsaWFtCiAgIENob3cuICBXZSB3 b3VsZCBhbHNvIGxpa2UgdG8gdGhhbmsgTGkgWWFuIGZvciBoaXMgbnVtZXJvdXMgcmV2aWV3cyBh cwogICB3ZWxsIGFzIFN1cmVzaCBLcmlzaG5hbiBmb3IgaGlzIGdlbi1hcnQgcmV2aWV3IG9mIHRo ZSBkb2N1bWVudC4KCjEwLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtORVRDT05GXSAgRW5u cywgUi4sICJORVRDT05GIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wiLCBSRkMgNDc0MSwKICAgICAg ICAgICAgICBEZWNlbWJlciAyMDA2LgoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBzLiwgIktleSB3 b3JkcyBmb3IgUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudHMKICAgICAgICAgICAgICBMZXZl bHMiLCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVu Jz5bUkZDMzMzOV0gIEtseW5lLCBHLiwgRWQuIGFuZCBDLiBOZXdtYW4sICJEYXRlIGFuZCBUaW1l IG9uIHRoZQogICAgICAgICAgICAgIEludGVybmV0OiBUaW1lc3RhbXBzIiwgUkZDIDMzMzksIEp1 bHkgMjAwMi48L2ZvbnQ+PC9zdHJvbmc+CgogICBbUkZDMzY4OF0gIEJyYWRuZXIsIHMuLCAiVGhl IElFVEYgWE1MIFJlZ2lzdHJ5IiwgUkZDIDM2ODgsIEphbnVhcnkKICAgICAgICAgICAgICAgMjAw NC4KCiAgIFtYTUxdICAgICAgV29ybGQgV2lkZSBXZWIgQ29uc29ydGl1bSwgIkV4dGVuc2libGUg TWFya3VwIExhbmd1YWdlCiAgICAgICAgICAgICAgKFhNTCkgMS4wIiwgVzNDIFhNTCwgRmVicnVh cnkgMTk5OCwKICAgICAgICAgICAgICAmbHQ7aHR0cDovL3d3dy53My5vcmcvVFIvMTk5OC9SRUMt eG1sLTE5OTgwMjEwJmd0Oy4KCiAgIFtYTUwgU2NoZW1hXQogICAgICAgICAgICAgIFRob21wc29u LCBILiwgQmVlY2gsIEQuLCBNYWxvbmV5LCBNLiwgYW5kIE4uIE1lbmRlbHNvaG4sCiAgICAgICAg ICAgICAgIlhNTCBTY2hlbWEgUGFydCAxOiBTdHJ1Y3R1cmVzIFNlY29uZCBFZGl0aW9uIiwgVzND IGh0dHA6LwogICAgICAgICAgICAgIC93d3cudzMub3JnL1RSLzIwMDQvUkVDLXhtbHNjaGVtYS0x LTIwMDQxMDI4LwogICAgICAgICAgICAgIHN0cnVjdHVyZXMuaHRtbCwgT2N0b2JlciAyMDA0LgoK ICAgW1hQQVRIXSAgICBDbGFyaywgSi4gYW5kIFMuIERlUm9zZSwgIlhNTCBQYXRoIExhbmd1YWdl IChYUGF0aCkKICAgICAgICAgICAgICBWZXJzaW9uIDEuMCIsCiAgICAgICAgICAgICAgVzNDIGh0 dHA6Ly93d3cudzMub3JnL1RSLzE5OTkvUkVDLXhwYXRoLTE5OTkxMTE2LAogICAgICAgICAgICAg IE5vdmVtYmVyIDE5OTkuCgpBcHBlbmRpeCBBLiAgQ2hhbmdlIExvZwoKICAgLS0gRWRpdG9yIG5v dGUgdG8gUkZDLUVkaXRvcjogd2UgcmVxdWVzdCB0aGF0IHlvdSByZW1vdmUgdGhpcyBzZWN0aW9u CiAgIGJlZm9yZSBwdWJsaXNoaW5nLgoKQS4xLiAgVmVyc2lvbiAtMDgKCiAgIDEuICAgUmVtb3Zl ZCBuYW1lZCBwcm9maWxlcwoKICAgMi4gICBSZW1vdmVkIGV2ZW50Q2xhc3MgdGhhdCB3YXMgYWNj aWRlbnRhbGx5IGluY2x1ZGVkIGluIHRoZQogICAgICAgIGRlZmluaXRpb24gb2YgdGhlIHJlcGxh eUNvbXBsZXRlIG5vdGlmaWNhdGlvbgoKICAgMy4gICBEZWxldGVkIGRhdGEgd3JhcHBlciBmcm9t IG5vdGlmaWNhdGlvbgoKICAgNC4gICBDaGFuZ2VkIHJlcGxheUxvZ1N0YXJ0VGltZSB0byBoYXZl IGEgbWluT2NjdXJzIG9mIDAuICBJdCB3aWxsCiAgICAgICAgb25seSBiZSB0aGVyZSB3aGVuIHJl cGxheSBpcyBzdXBwb3J0ZWQuICBWZXJpZnkgZXhhbXBsZXMgaW4KICAgICAgICBzZWN0aW9uIDMu Mi41LjEgYXJlIGNvcnJlY3Qgd2l0aCByZXNwZWN0IHRvIHRoaXMgZWxlbWVudC4KCiAgIDUuICAg RXJyb3IgY29kZXMgaW4gc2VjdGlvbiAyLjEuMSwgZml4ZWQgZm9ybWF0dGluZyBpc3N1ZQoKICAg Ni4gICBNb3ZlZCByZXBsYXlDb21wbGV0ZSB0byBub3QgYmUgdW5kZXIgJmx0O25ldGNvbmYmZ3Q7 CgogICA3LiAgIFNlY3Rpb24gMi4xLCBmaXhlZCBjYXBpdGFsaXphdGlvbgoKICAgOC4gICBJbiBm aWd1cmUgNCwgdGhlIGxpbmUgd2FzIHB1c2hlZCBvdXQgYnkgJ3N5c3RlbSBjb21wb25lbnRzJywK ICAgICAgICBmaXhlZCB0aGlzLgoKICAgOS4gICBPbiBwYWdlIDgsIHJlcGxhY2VkICJJZiB0aGUg c3RhcnRUaW1lIHNwZWNpZmllZCBpcyBlYXJsaWVyIHRoZW4KICAgICAgICB0aGUiIHdpdGggJ0lm IHRoZSBzdGFydFRpbWUgc3BlY2lmaWVkIGlzIGVhcmxpZXIgdGhhbiB0aGUiCgogICAxMC4gIFVw ZGF0ZWQgc29tZSBuYW1lIHNwYWNlcyBhbmQgc2NoZW1hTG9jYXRpb25zIGFzIHBlciBBbmR5J3Mg SnVuZQogICAgICAgIDNyZCBlbWFpbC4KCiAgIDExLiAgQWRkZWQgZGlzY3Vzc2lvbiBvZiByZXBs YXlMb2dTdGFydFRpbWUgdG8gZHJhZnQgaW4gc2VjdGlvbiAzLjMuMQogICAgICAgIGFzIGZvbGxv d3MgIldoZXRoZXIgb3Igbm90IGEgc3RyZWFtIHN1cHBvcnRzIHJlcGxheSBjYW4gYmUKICAgICAg ICBkaXNjb3ZlcmVkIGJ5IGRvaW5nIGEgJmx0O2dldCZndDsgb3BlcmF0aW9uIG9uIHRoZSAmbHQ7 c3RyZWFtcyZndDsgZWxlbWVudHMKICAgICAgICBvZiB0aGUgTm90aWZpY2F0aW9uIE1hbmFnZW1l bnQgU2NoZW1hLiAgVGhpcyBzY2hlbWEgYWxzbwogICAgICAgIHByb3ZpZGVzIHRoZSByZXBsYXlM b2dTdGFydFRpbWUgZWxlbWVudCB0byBpbmRpY2F0ZSB0aGUgZWFybGllc3QKICAgICAgICBhdmFp bGFibGUgbG9nZ2VkIG5vdGlmaWNhdGlvbi4iCgogICAxMi4gIFJlbW92ZWQgbW9zdCBvZiB0aGUg dXNlcyBvZiB0aGUgcGhyYXNlICdOb3RlIHRoYXQnLiAgSSBrZXB0IHR3bwogICAgICAgIHVzZXMg dGhhdCBwcmV2ZW50IHNlbnRlbmNlcyBmcm9tIHN0YXJ0aW5nIHdpdGggZWl0aGVyIGEgbG93ZXIK ICAgICAgICBjYXNlIGxldHRlciBvciBhbiBhbmdsZSBicmFja2V0LgoKICAgMTMuICBJbiBzZWN0 aW9uIDMuNiByZXBsYWNlZCAiaXQgd2lsbCBiZSBmaWx0ZXJlZCBvdXQiIHdpdGggInRoZQogICAg ICAgIG5vdGlmaWNhdGlvbiB3aWxsIGJlIGZpbHRlcmVkIG91dCIKICAgMTQuICBJbiBzZWN0aW9u IDMuNCwgcmVwbGFjZWQgImFuZCB0aGUgcXVlcnkiIHdpdGggImFuZCB0byBxdWVyeSIKCiAgIDE1 LiAgUmVwbGFjZWQgMyBpbnN0YW5jZXMgb2YgInJlcGxheSBjb21wbGV0ZSBub3RpZmljYXRpb24i IHdpdGgKICAgICAgICAicmVwbGF5Q29tcGxldGUgbm90aWZpY2F0aW9uIgoKICAgMTYuICBJbiBz ZWN0aW9uIDMuMy4yLCByZXBsYWNlZCAibm9ybWFsIE5FVENPTkYgc2Vzc2lvbiIgd2l0aCAibm9y bWFsCiAgICAgICAgY29tbWFuZC1yZXNwb25zZSBORVRDT05GIHNlc3Npb24iCgogICAxNy4gIElu IHNlY3Rpb24gMy4zLjEsIHJlcGxhY2VkICJjcmVhdGUgYW4gZXZlbnQgc3Vic2NyaXB0aW9uIHRo YXQKICAgICAgICB3aWxsIHJlc2VuZCByZWNlbnRseSBnZW5lcmF0ZWQgbm90aWZpY2F0aW9uIiB3 aXRoICJjcmVhdGUgYW4KICAgICAgICBldmVudCBzdWJzY3JpcHRpb24gdGhhdCB3aWxsIHJlc2Vu ZCByZWNlbnRseSBnZW5lcmF0ZWQKICAgICAgICBub3RpZmljYXRpb24sIG9yIGlzIHNvbWUgY2Fz ZXMgc2VuZCB0aGVtIGZvciB0aGUgZmlyc3QgdGltZSB0byBhCiAgICAgICAgcGFydGljdWxhciBO RVRDT05GIGNsaWVudC4iCgogICAxOC4gIEluIHNlY3Rpb24gMy4yLjUuMiwgcy9hdmFpbGFibGUg ZXZlbnQgc3RyZWFtcyB0by9ldmVudCBzdHJlYW1zCiAgICAgICAgYXZhaWxhYmxlIHRvLwoKICAg MTkuICBJbiBvbmUgc3BvdCwgY2hhbmdlZCBzbm1wIHRvIFNOTVAgKHRoZSBvdGhlciBnZXRzIGRl bGV0ZWQpCgogICAyMC4gIEluIHNlY3Rpb24gMy4yLjUuMSBzL3doZXJlICZsdDtuYW1lJmd0OyBl bGVtZW50IGlzL3doZXJlIHRoZSAmbHQ7bmFtZSZndDsKICAgICAgICBlbGVtZW50IGlzLwoKICAg MjEuICBJbiBzZWN0aW9uIDMuMi41LjEsIGNsYXJpZmllZCB0aGF0ICJ2YWx1ZSBpcyB1bmlxdWUi IC0gd2l0aGluCiAgICAgICAgdGhlIHNjb3BlIG9mIGEgTkVUQ09ORiBzZXJ2ZXIuCgogICAyMi4g IEluIHNlY3Rpb24gMi4xLjEsIGNsYXJpZmllZCB0aGF0IHN0b3BUaW1lIGNhbm5vdCBwcmVjZWRl ZCBzdGFydAogICAgICAgIHRpbWUuCgogICAyMy4gIEluIHNlY3Rpb24gMi4xLjEsIGluIFN0YXJ0 IFRpbWUgcy9pbmRpY2F0ZXMvaW5kaWNhdGUvCgogICAyNC4gIEluIHNlY3Rpb24gMi4xLjEsIGlu IEZpbHRlcjogcy9UaGlzIGlzIG11dHVhbGx5IGV4Y2x1c2l2ZS9UaGUKICAgICAgICBmaWx0ZXIg cGFyYW1ldGVyIGlzIG11dHVhbGx5IGV4Y2x1c2l2ZS8gKCJ0aGlzIiBjb3VsZCByZWZlciB0bwog ICAgICAgIHRoZSBiZWhhdmlvdXIgZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZW50ZW5jZS4p CgogICAyNS4gIEluIHNlY3Rpb24gMS40LCB0aGlyZCBidWxsZXQsIHJlcGxhY2VkICJzeXNsb2cg YW5kIFNOTVAgYXJlCiAgICAgICAgcmF0aGVyIGNvbnN0cmFpbmVkIGluIHRlcm1zIG9mIG1lc3Nh Z2Ugc2l6ZXMpIiB3aXRoIChpZSwgbm90IHRvbwogICAgICAgIHNob3J0KQoKICAgMjYuICBJbiBz ZWN0aW9uIDEuNCwgbWFkZSBhbGwgYnVsbGV0cyBzdGFydCB3aXRoIGNhcGl0YWwgbGV0dGVycy4K CiAgIDI3LiAgQWRkZWQgZGVmaW5pdGlvbiBvZiBGaWx0ZXIgdG8gc2VjdGlvbiAxLjEKCiAgIDI4 LiAgSW4gc2VjdGlvbiAxLjEsIGltcHJvdmVkIHRoZSBkZWZpbml0aW9uIG9mIHN1YnNjcmlwdGlv biB3aXRoICJBbgogICAgICAgIGFncmVlbWVudCBhbmQgbWV0aG9kIHRvIHJlY2VpdmUgZXZlbnQg bm90aWZpY2F0aW9ucyBvdmVyIGEKICAgICAgICBORVRDT05GIHNlc3Npb24uIgoKICAgMjkuICBJ biBzZWN0aW9uIDEuMSwgaW4gdGhlIGRlZmluaXRpb24gb2Ygb3BlcmF0aW9uLCBhZGRlZCBhCiAg ICAgICAgcmVmZXJlbmNlIHRvIFtORVRDT05GXS4KCiAgIDMwLiAgQ3JlYXRlZCBhIGNoYW5nZSBs b2cgc2VjdGlvbgoKICAgMzEuICBGaXhlZCByZWZlcmVuY2UgdG8gSUVURiBYTUwgUmVnaXN0cnkg aW4gSUFOQSBDb25zaWRlcmF0aW9ucwogICAgICAgIHNlY3Rpb24uCgogICAzMi4gIEluIHNlY3Rp b24gMy4zLjMsIGRlbGV0ZWQgIlRoaXMgbm90aWZpY2F0aW9uIHdpbGwgb25seSBiZSBzZW50CiAg ICAgICAgaWYgYSAnc3RvcFRpbWUnIHdhcyBzcGVjaWZpZWQgd2hlbiB0aGUgcmVwbGF5IHN1YnNj cmlwdGlvbiB3YXMKICAgICAgICBjcmVhdGVkLiIKCiAgIDMzLiAgQWRkZWQgdGV4dCB0byB0aGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0aGF0IHNheXMgIklmCiAgICAgICAgYSBz dWJzY3JpcHRpb24gaXMgY3JlYXRlZCB3aXRoIGEgc3RvcFRpbWUsIHRoZSBORVRDT05GIHNlc3Np b24KICAgICAgICB3aWxsIHJldHVybiB0byBiZWluZyBhIG5vcm1hbCBjb21tYW5kLXJlc3BvbnNl IE5FVENPTkYgc2Vzc2lvbgogICAgICAgIHdoZW4gdGhlIHJlcGxheSBpcyBjb21wbGV0ZWQuICBJ dCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlCiAgICAgICAgTkVUQ09ORiBjbGllbnQgdG8g Y2xvc2Ugb2ZmIHRoaXMgc2Vzc2lvbiB3aGVuIGl0IGlzIG5vIGxvbmdlciBvZgogICAgICAgIHVz ZSIuCgogICAzNC4gIFVwZGF0ZSBleGFtcGxlcyBpbiBzZWN0aW9uIDUgdG8gZ2V0IHJpZCBvZiBl eHRyYSB3cmFwcGVyIHRhZy4KCiAgIDM1LiAgSW4gc2VjdGlvbiAyLjEsIHJlcGxhY2UgIkEgTkVU Q09ORiBzZXJ2ZXIgaXMgbm90IHJlcXVpcmVkIHRvCiAgICAgICAgcHJvY2VzcyBSUEMgcmVxdWVz dHMgb24gdGhlIHNlc3Npb24gYXNzb2NpYXRlZCB3aXRoIHRoZQogICAgICAgIHN1YnNjcmlwdGlv biB1bnRpbCB0aGUgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiBpcyBkb25lIGFuZCBtYXkKICAg ICAgICBzaWxlbnRseSBkaXNjYXJkIHRoZXNlIHJlcXVlc3RzLiIgd2l0aCAiQSBORVRDT05GIHNl cnZlciBpcyB3aWxsCiAgICAgICAgbm90IHJlYWQgUlBDIHJlcXVlc3RzLCBieSBkZWZhdWx0LCBv biB0aGUgc2Vzc2lvbiBhc3NvY2lhdGVkCiAgICAgICAgd2l0aCB0aGUgc3Vic2NyaXB0aW9uIHVu dGlsIHRoZSBub3RpZmljYXRpb24gc3Vic2NyaXB0aW9uIGlzCiAgICAgICAgZG9uZS4KCiAgIDM2 LiAgVXBkYXRlZCB0aGUgbm90aWZpY2F0aW9uIGRlZmluaXRpb24gYW5kIHRoZSByZXBseUNvbXBs ZXRlCiAgICAgICAgbm90aWZpY2F0aW9uIGRlZmluaXRpb24gdG8gdXNlIGEgc3Vic3RpdHV0aW9u IGdyb3VwLgoKQS4yLiAgVmVyc2lvbiAtMDkKCiAgIDEuICAgSW4gc2VjdGlvbiA1LjEgImxvZ2lj YWwgT1Igb3BlcmF0aW9uIiAtJmd0OyAiYXBwbGljYXRpb24gb2YgdGhlCiAgICAgICAgbG9naWNh bCBPUiBvcGVyYXRvciIKCiAgIDIuICAgSW4gc2VjdGlvbiA2ICJlbnN1cmUgdGhlIHNlY3VyZSBv cGVyYXRpb24gb2YgdGhlIGZvbGxvd2luZwogICAgICAgIGNvbW1hbmRzIiAtJmd0OyAic2VjdXJl IGV4ZWN1dGlvbiIKCiAgIDMuICAgUmVtb3ZlZCBhIGNvdXBsZSByZW1haW5pbmcgcmVmZXJlbmNl cyB0byBuYW1lZCBwcm9maWxlcy4KCiAgIDQuICAgVXBkYXRlZCBuYW1lIGRhdGF0eXBlIGluIGV2 ZW50U3RyZWFtcyBlbGVtZW50LgoKICAgNS4gICBNb2RpZmllZCB0aGUgY2FyZGluYWxpdHkgb2Yg ZXZlbnRTdHJlYW1zIHRvIHJlZmxlY3QgdGhhdCB0aGVyZQogICAgICAgIHdpbGwgYWx3YXlzIGJl IGF0IGxlYXN0IG9uZSBldmVudCBzdHJlYW0uCgogICA2LiAgIEZpeGVkIGRlc2NyaXB0aW9uIG9m IGV4YW1wbGVzIHRvIHJlbW92ZSByZWZlcmVuY2UgdG8gZXZlbnRFbnRyeSwKICAgICAgICB3aGlj aCBpcyBubyBsb25nZXIgcGFydCBvZiB0aGUgYWN0dWFsIGV4YW1wbGUuCgogICA3LiAgIEluIGV4 YW1wbGVzLCBmb3IgY29uc2lzdGVuY3kgY2hhbmdlZCBzb21lIHJlZmVyZW5jZXMgdG8KICAgICAg ICByZXBvcnRpbmdFbGVtZW50IHRvIGJlIHJlcG9ydGluZ0VudGl0eQoKICAgOC4gICBGaXhlZCBz ZWN0aW9uIDMuMiwgdGhpcmQgcGFyYWdyYXBoIHRvIHRhbGsgYWJvdXQgZmlsdGVyIGVsZW1lbnRz CiAgICAgICAgaW5zdGVhZCBvZiBmaWx0ZXJzLgoKICAgOS4gICBNZXJnZSBzZWN0aW9uIDMuMy4y IGFuZCBzZWN0aW9uIDMuMy4zLiAgRGVsZXRlIHRoZSBmaXJzdAogICAgICAgIHBhcmFncmFwaCBp biAob2xkKSBzZWN0aW9uIDMuMy4zIHNpbmNlIGl0IGJvdGggZHVwbGljYXRlcyBhbmQKICAgICAg ICBjb250cmFkaWN0cyB0ZXh0IGluIHNlY3Rpb24gMy4zLjIKCiAgIDEwLiAgSW4gc2VjdGlvbiAz LjIuNS4yLjEsIGFkZGVkIGNsYXJpZmljYXRpb24gdG8gZmlyc3QgcGFyYWdyYXBoCiAgICAgICAg dGhhdCAiRWl0aGVyIHN1YnRyZWUgb3IgWFBBVEggZmlsdGVyaW5nIGNhbiBiZSB1c2VkLiAgIgoK ICAgMTEuICBSZW1vdmVkIGRpc2N1c3Npb24gb2Ygbm90IGFsbG93aW5nIHRoZSByZXR1cm4gb2Yg c3RyZWFtIG5hbWVzCiAgICAgICAgZm9yIHdoaWNoIHRoZSB1c2VyIGRvZXMgbm90IGhhdmUgcGVy bWlzc2lvbnMgZnJvbSB0aGUgYm9keSBvZgogICAgICAgIHRoZSBkb2N1bWVudCB0byB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4KCiAgIDEyLiAgRml4ZWQgdHlwb3MgYW5kIGRp ZCB3b3Jkc21pdGhpbmcgaW4gdmFyaW91cyBwYXJ0cyBvZiB0aGUKICAgICAgICBkb2N1bWVudC4K CiAgIDEzLiAgSW4gc2VjdGlvbiAyLjEsIGV4cGxpY2l0bHkgc3RhdGVkIHRoYXQgYSBzdWJzY3Jp cHRpb24gaXMgYm91bmQKICAgICAgICB0byBhIHNpbmdsZSBzdHJlYW0gZm9yIHRoZSBsaWZldGlt ZSBvZiB0aGUgc3Vic2NyaXB0aW9uLgoKICAgMTQuICByZW1vdmVkIHNpbmdsZSBxdW90ZXMgYXJv dW5kIHNvbWUgaW5zdGFuY2VzIG9mIHN0b3BUaW1lIGFuZAogICAgICAgIHN0YXJ0VGltZSBmb3Ig Y29uc2lzdGVuY3kuICBXaGVuIGFwcHJvcHJpYXRlLCBwdXQgYmV0d2VlbiBhbmdsZQogICAgICAg IGJyYWNrZXRzLgoKICAgMTUuICBJbiBzZWN0aW9uIDIuMS4xLCBjaGFuZ2VkICJFcnJvci1pbmZv OiAmbHQ7YmFkRWxlbWVudCZndDs6IHN0YXJ0VGltZSIKICAgICAgICB0byB1c2UgYmFkLWVsZW1l bnQuCgogICAxNi4gIEluIHNlY3Rpb24gMi4yLjEsIHVuZGVyIHRoZSBwYXJhbWV0ZXIgdGFnLCBy ZXBsYWNlZCAiQ29udGFpbnMKICAgICAgICBub3RpZmljYXRpb24tc3BlY2lmaWMgdGFnZ2VkIGNv bnRlbnQuIiB3aXRoICJDb250YWlucwogICAgICAgIG5vdGlmaWNhdGlvbi1zcGVjaWZpYyB0YWdn ZWQgY29udGVudCwgaWYgYW55LiAgIgoKICAgMTcuICBDbGFyaWZpZWQgc29tZSB0ZXh0IGluIHNl Y3Rpb24gMy4yLCBwYXJhZ3JhcGggMyBhcm91bmQgc2VuZGluZwogICAgICAgIG9mIGZpbHRlcnMg ZnJvbSBjbGllbnQgYW5kIHRoZSBmaWx0ZXJzIGxhdGVyIGJlaW5nIGFwcGxpZWQgdG8KICAgICAg ICB0aGUgbm90aWZpY2F0aW9ucy4KCiAgIDE4LiAgRml4ZWQgdGFyZ2V0IG5hbWVzcGFjZSBpbiBz ZWN0aW9uIDQuCgogICAxOS4gIEFkZGVkIG1pc3NpbmcgbGFuZyBhbmQgdmVyc2lvbiBpbmZvcm1h dGlvbiB0byBzY2hlbWEgaW4gc2VjdGlvbgogICAgICAgIDMuNAoKICAgMjAuICBDbGFyaWZpZWQg dGhhdCB0aGUgZXhhbXBsZXMgaW4gc2VjdGlvbiA1IGFsbCB1c2VkIHRoZSBzYW1lCiAgICAgICAg ZXhhbXBsZSBldmVudCBsaXN0LgoKICAgMjEuICBDbGVhbmVkIHVwIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNlY3Rpb24uCgogICAyMi4gIEluIHNlY3Rpb24gMy40LCBjbGFyaWZpZWQgdGhlIGRl ZmluaXRpb24gb2YgcmVwbGF5TG9nU3RhcnQgdGltZQogICAgICAgIHRvIGJlIHRoZSB0aW1lc3Rh bXAgb2YgdGhlIGVhcmxpZXN0IGF2YWlsYWJsZSBub3RpZmljYXRpb24gaW4KICAgICAgICB0aGUg bG9nIHVzZWQgdG8gc3VwcG9ydCB0aGUgcmVwbGF5IGZ1bmN0aW9uIGluIHRoZSBkZXNjcmlwdGlv bgogICAgICAgIHRhZyBmb3IgdGhlIG9iamVjdCBkZWZpbml0aW9uLgoKICAgMjMuICBJbiBzZWN0 aW9uIDMuMy4yLCBjbGFyaWZpZWQgdGhhdCB0aGUgdGltZSBhbiBldmVudCB3YXMgZ2VuZXJhdGVk CiAgICAgICAgYnkgdGhlIHN5c3RlbSBtZWFucyB0aW1lIGFuIGV2ZW50IHdhcyBnZW5lcmF0ZWQg YnkgdGhlIGV2ZW50CiAgICAgICAgc291cmNlLgoKICAgMjQuICBJbiBzZWN0aW9uIDMuNSwgZGVs ZXRlZCBkaXNjdXNzaW9uIGFib3V0IHBvc3NpYmx5IGRlZmluaW5nCiAgICAgICAgc3Vic2NyaXB0 aW9ucyBpbiBYTUwgU2NoZW1hLgoKICAgMjUuICBJbiBzZWN0aW9uIDMuNiwgZGVsZXRlZCBkaXNj dXNzaW9uIGFib3V0IGZpbHRlciBlbGVtZW50CiAgICAgICAgZXhlY3V0aW9uIG9yZGVyIG5vdCBt YXR0ZXJpbmcuCgogICAyNi4gIEZpeGVkIGV4YW1wbGVzIGluIHNlY3Rpb24gNSB0byBhZGQgJmx0 O25ldGNvbmYmZ3Q7IHRhZyBhbmQgdG8gbWFrZQogICAgICAgIG90aGVyIGNvcnJlY3Rpb25zCgog ICAyNy4gIEFkZGVkIFhNTCBTY2hlbWEgZGVmaW5pdGlvbiBmb3IgZXhhbXBsZXMgaW4gc2VjdGlv biA1IGFuZCBzaG93ZWQKICAgICAgICB0aGUgZXZlbnQgbGlzdCB3aXRoICZsdDtub3RpZmljYXRp b24mZ3Q7IHdyYXBwZXJzLgoKICAgMjguICBBZGRlZCAmbHQ7bm90aWZpY2F0aW9uQ29tcGxldGUm Z3Q7IG5vdGlmaWNhdGlvbgoKICAgMjkuICBSZW1vdmVkIHN1cHBvcnQgb2Ygc3RhcnRUaW1lIGFu ZCBzdG9wVGltZSBpbiB0aGUgZnV0dXJlLgoKICAgMzAuICBSZXBsYWNlZCByZXBsYXlMb2dTdGFy dFRpbWUgd2l0aCByZXBsYXlMb2dDcmVhdGlvblRpbWUgYW5kCiAgICAgICAgcmVwbGF5TG9nQWdl ZFRpbWUuCgpBLjMuICBWZXJzaW9uIC0xMAoKICAgMS4gIENoYW5nZWQgdGhlIGRlc2NyaXB0aW9u IG9mIHN0b3BUaW1lIHRvIGFsbG93IHN0b3BUaW1lcyBpbiB0aGUKICAgICAgIGZ1dHVyZS4KCiAg IDIuICBBZGRlZCBpbnRlcmxlYXZlIGNhcGFiaWxpdHkKCiAgIDMuICBDbGFyaWZpZWQgY3JlYXRl LXN1YnNjcmlwdGlvbiBlcnJvciBtZXNzYWdlcy4KCiAgIDQuICBDb3JyZWN0ZWQgdGFyZ2V0TmFt ZXNwYWNlIGluIE5ldGNvbmYgTm90aWZpY2F0aW9uIFhTRAoKICAgNS4gIEZpeGVkIHR5cG9zIGFu ZCBtYWRlIG1pbm9yIGVkaXRzLgoKQS40LiAgVmVyc2lvbiAtMTEKCiAgIDEuICBGaXhlZCBuYW1l c3BhY2VzCgogICAyLiAgSW4gc2VjdGlvbiA2LjUsIGZpeGVkIGVycm9yIG1lc3NhZ2UgRXJyb3It aW5mbwogICAzLiAgSW4gc2VjdGlvbiA2LjEgY2xhcmlmeSB0aGF0IGlmIHRoZSBpbnRlcmxlYXZl IGNhcGFiaWxpdHkgaXMKICAgICAgIHN1cHBvcnRlZCwgdGhlbiB0aGUgc2VydmVyIG11c3QgcmVz cG9uZCB0byByZXF1ZXN0cy4KCkEuNS4gIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+VmVzcmlv bjwvZm9udD48L3N0cmlrZT4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5WZXJzaW9uPC9m b250Pjwvc3Ryb25nPiAtMTIKCiAgIDEuICBBZGQgdG8gc2VjdGlvbiAxLjMgdGhlIGNsYXJpZmlj YXRpb24gIk5vdGUgdGhhdCBhIHN1YnNjcmlwdGlvbgogICAgICAgY2Fubm90IGJlIG1vZGlmaWVk IG9uY2UgY3JlYXRlZC4iCgogICAyLiAgSW4gc2VjdGlvbiAyLjIuMSwgaW4gdGhlIGRlc2NyaXB0 aW9uIG9mIGV2ZW50VGltZSwgYWRkZWQgdGhlCiAgICAgICBmb2xsb3dpbmcgdGV4dDogIlRoaXMg cGFyYW1ldGVyIGlzIG9mIHR5cGUgZGF0ZVRpbWUuIgoKICAgMy4gIEZpeGVkIHNldmVyYWwgdHlw b3MuCgogICA0LiAgQWRkZWQgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIHRoZSBJQU5BIGNvbnNpZGVy YXRpb25zIHNlY3Rpb246ICItLQogICAgICAgRWRpdG9yIG5vdGUgdG8gSUFOQS9SRkMtRWRpdG9y OiB3ZSByZXF1ZXN0IHRoYXQgeW91IG1ha2UgdGhlc2UKICAgICAgIGFzc2lnbm1lbnRzLCBpbiB3 aGljaCBjYXNlIGl0IGlzIHRvcCBiZSBkb2N1bWVudGVkIGFzIGJlbG93IiAiCgogICA1LiAgUmVw bGFjZWQvVXBkYXRlZCBYTUwgU2NoZW1hIHJlZmVyZW5jZSB0byBiZSAiIFtYTUwgU2NoZW1hXQog ICAgICAgVGhvbXBzb24sIEguLCBCZWVjaCwgRC4sIE1hbG9uZXksIE0uLCBNZW5kZWxzb2huLCBO LiwgIlhNTCBTY2hlbWEKICAgICAgIFBhcnQgMTogU3RydWN0dXJlcyBTZWNvbmQgRWRpdGlvbiIs IFczQyBSZWNvbW1lbmRhdGlvbiwgMjgKICAgICAgIE9jdG9iZXIgMjAwNCAmbHQ7aHR0cDovL3d3 dy53My5vcmcvVFIvMjAwNC9SRUMteG1sc2NoZW1hLTEtMjAwNDEwMjgvCiAgICAgICBzdHJ1Y3R1 cmVzLmh0bWwmZ3Q7ICIKCiAgIDYuICBBZGQgaW5zdHJ1Y3Rpb25zIHRvIFJGQyBlZGl0b3IgdG8g cmVtb3ZlIGNoYW5nZSBsb2cgYmVmb3JlCiAgICAgICBwdWJsaWNhdGlvbgoKICAgNy4gIEFkZGVk IElBTkEgcmVnaXN0cmF0aW9uIGl0ZW0gZm9yIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvCiAgICAgICB4bWwtcmVnaXN0cnkvc2NoZW1hL25vdGlmaWNhdGlvbi54c2QKCiAgIDguICBD bGFyaWZpZWQgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0aGF0IHRoZSBjYXBh YmlsaXR5CiAgICAgICBVUklzIHdlcmUgY29tcGxhaW50IHRvIFJGQzQ3NDEgc2VjdGlvbiAxMC4z Cgo8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+QS42LiAgVmVyc2lvbiAtMTMKCiAgIDEuICAg SW4gc2VjdGlvbiAyLjEuMSwgZm9yIGJvdGggaW5zdGFuY2VzIGFuZCBpbiBzZWN0aW9uIDIuMi4x LAogICAgICAgIHJlcGxhY2VkICJUaGlzIHBhcmFtZXRlciBpcyBvZiB0eXBlIGRhdGVUaW1lLiIg IFdpdGggIlRoaXMKICAgICAgICBwYXJhbWV0ZXIgaXMgb2YgdHlwZSBkYXRlVGltZSBhbmQgY29t cGxpYW50IHRvIFtSRkMzMzM5XS4iCgogICAyLiAgIEluIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNl IHNlY3Rpb24sIGFkZGVkIHRoZSBmb2xsb3dpbmcKICAgICAgICByZWZlcmVuY2UgW1JGQzMzMzld IEtseW5lLCBHLiwgRWQuIGFuZCBDLiBOZXdtYW4sICJEYXRlIGFuZCBUaW1lCiAgICAgICAgb24g dGhlIEludGVybmV0OiBUaW1lc3RhbXBzIiwgUkZDIDMzMzksIEp1bHkgMjAwMi4KCiAgIDMuICAg SW4gc2VjdGlvbiAyLjEuMSwgZm9yIGJvdGggaW5zdGFuY2VzIGFuZCBpbiBzZWN0aW9uIDIuMi4x LCBhZGRlZAogICAgICAgIHRoZSBmb2xsb3dpbmcgYWZ0ZXIgdGhlIHRleHQgXCBpbmRpY2F0aW5n IHRoYXQgdGhlIHRpbWUgZmllbGRzCiAgICAgICAgYXJlIGRhdGVUaW1lICh0aGlzIGNvdmVycyBl dmVudFRpbWUsIHN0YXJ0VGltZSBhbmQgc3RvcFRpbWUpLgogICAgICAgICJJbXBsZW1lbnRhdGlv bnMgbXVzdCBzdXBwb3J0IHRpbWUgem9uZXMuIgogICA0LiAgIEluIFNlY3Rpb24gMy42LjEgInBh cmFtZXRlci4gIEEgRmlsdGVyIG9ubHkgZXhpc3QgYXMgYSBwYXJhbWV0ZXIKICAgICAgICB0byB0 aGUgc3Vic2NyaXB0aW9uLiIgcy9leGlzdC9leGlzdHMvCgogICA1LiAgIEluIFNlY3Rpb24gNzog UmVwbGFjZWQgc2Vjb25kIGxhc3QgcGFyYWdyYXBoIHdpdGggIlRoZSBjb250ZW50cwogICAgICAg IG9mIG5vdGlmaWNhdGlvbnMgYXMgd2VsbCBhcyB0aGUgbmFtZXMgb2YgZXZlbnQgc3RyZWFtcyBt YXkKICAgICAgICBjb250YWluIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhbmQgY2FyZSBzaG91bGQg YmUgdGFrZW4gdG8gZW5zdXJlCiAgICAgICAgdGhhdCB0aGV5IGFyZSB2aWV3ZWQgb25seSBieSBh dXRob3JpemVkIHVzZXJzLiAgSWYgYSB1c2VyIGlzIG5vdAogICAgICAgIGF1dGhvcml6ZWQgdG8g dmlldyBhbGwgZWxlbWVudHMgaW4gdGhlIGNvbnRlbnQgb2YgdGhlCiAgICAgICAgbm90aWZpY2F0 aW9uLCB0aGUgbm90aWZpY2F0aW9uIGlzIG5vdCBzZW50IHRvIHRoYXQgdXNlci4iCgogICA2LiAg IEluIHNlY3Rpb24gMy4zLjIsIHJlcGxhY2VkICJUaGUgTkVUQ09ORiBzZXJ2ZXIgd2lsbCB0aGVu IGFjY2VwdAogICAgICAgICZsdDtycGMmZ3Q7IG9wZXJhdGlvbnMuIiAgV2l0aCAiVGhlIE5FVENP TkYgc2VydmVyIHdpbGwgdGhlbiBhY2NlcHQKICAgICAgICAmbHQ7cnBjJmd0OyBvcGVyYXRpb25z IGV2ZW4gaWYgdGhlIHNlcnZlciBkaWQgbm90IHByZXZpb3VzbHkgYWNjZXB0CiAgICAgICAgc3Vj aCBvcGVyYXRpb25zIGR1ZSB0byBsYWNrIG9mIGludGVybGVhdmUgc3VwcG9ydC4iCgogICA3LiAg IEluIHNlY3Rpb24gMy4zLjIsIHJlcGxhY2VkICJBICZsdDtyZXBsYXlDb21wbGV0ZSZndDsgbm90 aWZpY2F0aW9uIGlzCiAgICAgICAgc2VudCB0byBpbmRpY2F0ZSB0aGF0IGFsbCBvZiB0aGUgcmVw bGF5IG5vdGlmaWNhdGlvbnMgaGF2ZSBiZWVuCiAgICAgICAgc2VudC4gIElmIHRoaXMgc3Vic2Ny aXB0aW9uIGhhcyBhIHN0b3AgdGltZSwgdGhlbiB0aGlzIHNlc3Npb24KICAgICAgICBiZWNvbWVz IGEgbm9ybWFsIE5FVENPTkYgc2Vzc2lvbiBhZ2Fpbi4gIFdoZW4gYSAmbHQ7c3RvcFRpbWUmZ3Q7 IGhhcwogICAgICAgIGJlZW4gc3BlY2lmaWVkLCAmbHQ7bm90aWZpY2F0aW9uQ29tcGxldGUmZ3Q7 IG5vdGlmaWNhdGlvbiBpcyB0aGUgbGFzdAogICAgICAgIG5vdGlmaWNhdGlvbiBzZW50IG9uIHRo ZSBzdWJzY3JpcHRpb24gYmVmb3JlIGl0IHRlcm1pbmF0ZXMgYW5kCiAgICAgICAgdGhlIE5FVENP TkYgc2Vzc2lvbiByZXR1cm5zIHRvIGJlaW5nIGEgbm9ybWFsIE5FVENPTkYgc2Vzc2lvbi4iCiAg ICAgICAgV2l0aCAiQSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbiBpcyBzZW50 IHRvIGluZGljYXRlIHRoYXQKICAgICAgICBhbGwgb2YgdGhlIHJlcGxheSBub3RpZmljYXRpb25z IGhhdmUgYmVlbiBzZW50LiAgV2hlbiBhCiAgICAgICAgJmx0O3N0b3BUaW1lJmd0OyBoYXMgYmVl biBzcGVjaWZpZWQsICZsdDtub3RpZmljYXRpb25Db21wbGV0ZSZndDsKICAgICAgICBub3RpZmlj YXRpb24gaXMgdGhlIGxhc3Qgbm90aWZpY2F0aW9uIHNlbnQgb24gdGhlIHN1YnNjcmlwdGlvbgog ICAgICAgIGJlZm9yZSBpdCB0ZXJtaW5hdGVzIGFuZCB0aGUgTkVUQ09ORiBzZXNzaW9uIHJldHVy bnMgdG8gYmVpbmcgYQogICAgICAgIG5vcm1hbCBORVRDT05GIHNlc3Npb24uICIKCiAgIDguICAg SW4gc2VjdGlvbiAzLjMuMiwgcmVwbGFjZWQsICJBICZsdDtyZXBsYXlDb21wbGV0ZSZndDsgbm90 aWZpY2F0aW9uIGlzCiAgICAgICAgc2VudCB0byBpbmRpY2F0ZSB0aGF0IGFsbCBvZiB0aGUgcmVw bGF5IG5vdGlmaWNhdGlvbnMgaGF2ZSBiZWVuCiAgICAgICAgc2VudC4iICBXaXRoICJBICZsdDty ZXBsYXlDb21wbGV0ZSZndDsgbm90aWZpY2F0aW9uIGlzIHNlbnQgdG8KICAgICAgICBpbmRpY2F0 ZSB0aGF0IGFsbCBvZiB0aGUgcmVwbGF5IG5vdGlmaWNhdGlvbnMgaGF2ZSBiZWVuIHNlbnQgYW5k CiAgICAgICAgbXVzdCBub3QgYmUgc2VudCBmb3IgYW55IG90aGVyIHJlYXNvbi4iCgogICA5LiAg IEluIHNlY3Rpb24gMy4zLjEsIHJlcGxhY2VkICJBIG5vdGlmaWNhdGlvbiBzdHJlYW0gdGhhdCBz dXBwb3J0cwogICAgICAgIHJlcGxheSBpcyBub3QgZXhwZWN0ZWQgdG8gaGF2ZSBhbiB1bmxpbWl0 ZWQgc3VwcGx5IG9mIHNhdmVkCiAgICAgICAgbm90aWZpY2F0aW9ucyBhdmFpbGFibGUgdG8gYWNj b21tb2RhdGUgYW55IHJlcGxheSByZXF1ZXN0LiIKICAgICAgICBXaXRoICJBIG5vdGlmaWNhdGlv biBzdHJlYW0gdGhhdCBzdXBwb3J0cyByZXBsYXkgaXMgbm90IGV4cGVjdGVkCiAgICAgICAgdG8g aGF2ZSBhbiB1bmxpbWl0ZWQgc3VwcGx5IG9mIHNhdmVkIG5vdGlmaWNhdGlvbnMgYXZhaWxhYmxl IHRvCiAgICAgICAgYWNjb21tb2RhdGUgYW55IHJlcGxheSByZXF1ZXN0LiAgQ2xpZW50cyBjYW4g cXVlcnkKICAgICAgICAmbHQ7cmVwbGF5TG9nQ3JlYXRpb25UaW1lJmd0OyBhbmQgJmx0O3JlcGxh eUxvZ0FnZWRUaW1lJmd0OyB0byBsZWFybiBhYm91dAogICAgICAgIHRoZSBhdmFpbGFiaWxpdHkg b2Ygbm90aWZpY2F0aW9ucyBmb3IgcmVwbGF5LiIKCiAgIDEwLiAgSW4gc2VjdGlvbiAzLjIsIHJl cGxhY2VkICJGaWd1cmUgMiBpbGx1c3RyYXRlcyB0aGUgbm90aWZpY2F0aW9uCiAgICAgICAgZmxv dyBhbmQgY29uY2VwdHMgaWRlbnRpZmllZCBpbiB0aGlzIGRvY3VtZW50LiIgIFdpdGggIkZpZ3Vy ZSAyCiAgICAgICAgaWxsdXN0cmF0ZXMgdGhlIG5vdGlmaWNhdGlvbiBmbG93IGFuZCBjb25jZXB0 cyBpZGVudGlmaWVkIGluCiAgICAgICAgdGhpcyBkb2N1bWVudC4gIEl0IGRvZXMgbm90IG1hbmRh dGUgYW5kL29yIHByZWNsdWRlIGFuCiAgICAgICAgaW1wbGVtZW50YXRpb24uIgoKICAgMTEuICBJ biBzZWN0aW9uIDYuMSwgYWRkZWQgdGhlIGZvbGxvd2luZyB0ZXh0ICJUaGlzIGNhcGFiaWxpdHkg aGVscHMKICAgICAgICBzY2FsYWJpbGl0eSBieSByZWR1Y2luZyB0aGUgdG90YWwgbnVtYmVyIG9m IE5FVENPTkYgc2Vzc2lvbnMKICAgICAgICByZXF1aXJlZCBieSBhIGdpdmVuIG9wZXJhdG9yIG9y IG1hbmFnZW1lbnQgYXBwbGljYXRpb24uIgoKICAgMTIuICBJbiBzZWN0aW9uIDMuNiwgZGVsZXRl ZCAiV2hlbiBtdWx0aXBsZSBmaWx0ZXIgZWxlbWVudHMgYXJlCiAgICAgICAgc3BlY2lmaWVkLCB0 aGV5IGFyZSBhcHBsaWVkIGNvbGxlY3RpdmVseSwgc28gZXZlbnQgbm90aWZpY2F0aW9ucwogICAg ICAgIG5lZWQgdG8gcGFzcyBhbGwgc3BlY2lmaWVkIGZpbHRlciBlbGVtZW50cyBpbiBvcmRlciB0 byBiZSBzZW50CiAgICAgICAgdG8gdGhlIHN1YnNjcmliZXIuICIKCiAgIDEzLiAgSW4gc2VjdGlv biA3IChTZWN1cml0eSBDb25zaWRlcmF0aW9ucykgYWZ0ZXIgdGhlIGJ1bGxldHMgYWRkZWQKICAg ICAgICB0aGUgZm9sbG93aW5nOiBTZWN1cmUgZXhlY3V0aW9uIG1lYW5zIGVuc3VyaW5nIHRoYXQg YSBzZWN1cmUKICAgICAgICB0cmFuc3BvcnQgaXMgdXNlZCBhcyB3ZWxsIGFzIGVuc3VyaW5nIHRo YXQgdGhlIHVzZXIgaGFzCiAgICAgICAgc3VmZmljaWVudCBhdXRob3JpemF0aW9uIHRvIHBlcmZv cm0gdGhlIGZ1bmN0aW9uIHRoZXkgYXJlCiAgICAgICAgcmVxdWVzdGluZyBhZ2FpbnN0IHRoZSBz cGVjaWZpYyBwaWVjZSBvZiBORVRDT05GIGNvbnRlbnQKICAgICAgICBpbnZvbHZlZC4gIFdoZW4g YSAmbHQ7Z2V0Jmd0OyBpcyByZWNlaXZlZCBhZ2FpbnN0IHRoZSBjb250ZW50IGRlZmluZWQKICAg ICAgICBpbiB0aGlzIG1lbW8sIGNsaWVudHMgc2hvdWxkIG9ubHkgYmUgYWJsZSB0byB2aWV3IHRo ZSBjb250ZW50CiAgICAgICAgZm9yIHdoaWNoIHRoZXkgaGF2ZSBzdWZmaWNpZW50IHByaXZpbGVn ZXMuICBBIGNyZWF0ZSAmbHQ7Y3JlYXRlLQogICAgICAgIHN1YnNjcmlwdGlvbiZndDsgb3BlcmF0 aW9uIGNhbiBiZSBjb25zaWRlcmVkIGxpa2UgYSBkZWZlcnJlZCAmbHQ7Z2V0Jmd0OywKICAgICAg ICBhbmQgdGhlIGNvbnRlbnQgdGhhdCBkaWZmZXJlbnQgdXNlcnMgY2FuIGFjY2VzcyBtYXkgdmFy eS4gIFRoaXMKICAgICAgICBkaWZmZXJlbnQgYWNjZXNzIGlzIHJlZmxlY3RlZCBpbiB0aGUgJmx0 O25vdGlmaWNhdGlvbiZndDsgdGhhdAogICAgICAgIGRpZmZlcmVudCB1c2VycyBhcmUgYWJsZSB0 byBzdWJzY3JpYmUgdG8uCgogICAxNC4gIFVwZGF0ZWQgaW1wb3J0IHN0YXRlbWVudHMgdG8gbm90 IHVzZWQgZnVsbHkgcXVhbGlmaWVkIFVSTHMuPC9mb250Pjwvc3Ryb25nPgoKQXV0aG9ycycgQWRk cmVzc2VzCgogICBTaGFyb24gQ2hpc2hvbG0KICAgTm9ydGVsCiAgIDM1MDAgQ2FybGluZyBBdmUK ICAgTmVwZWFuLCBPbnRhcmlvICBLMkggOEU5CiAgIENhbmFkYQoKICAgRW1haWw6IHNjaGlzaG9s QG5vcnRlbC5jb20KCiAgIEhlY3RvciBUcmV2aW5vCiAgIENpc2NvCiAgIFN1aXRlIDQwMAogICA5 MTU1IEUuIE5pY2hvbHMgQXZlCiAgIEVuZ2xld29vZCwgQ08gIDgwMTEyCiAgIFVTQQoKICAgRW1h aWw6IGh0cmV2aW5vQGNpc2NvLmNvbQoKRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50CgogICBDb3B5 cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA4KS4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3Vi amVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zCiAgIGNvbnRhaW5l ZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3Jz CiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLgoKICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuCiAgICJBUyBJUyIg YmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVT RU5UUwogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZ LCBUSEUgSUVURiBUUlVTVCBBTkQKICAgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9S Q0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MKICAgT1IgSU1QTElFRCwgSU5DTFVE SU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GCiAgIFRI RSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkg SU1QTElFRAogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBB IFBBUlRJQ1VMQVIgUFVSUE9TRS4KCkludGVsbGVjdHVhbCBQcm9wZXJ0eQoKICAgVGhlIElFVEYg dGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkK ICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdo dCBiZSBjbGFpbWVkIHRvCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBv ZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0 ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzCiAgIG1pZ2h0IG9yIG1p Z2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcwog ICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRz LiAgSW5mb3JtYXRpb24KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0 cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4K CiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlh dCBhbmQgYW55CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUs IG9yIHRoZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwg bGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mCiAgIHN1Y2ggcHJvcHJpZXRhcnkg cmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24g Y2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdAog ICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4KCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVy ZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkKICAgY29weXJpZ2h0cywg cGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQogICBy aWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBp bXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlv biB0byB0aGUgSUVURiBhdAogICBpZXRmLWlwckBpZXRmLm9yZy4KCkFja25vd2xlZGdtZW50Cgog ICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBwcm92aWRlZCBieSB0aGUg SUVURgogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJQVNBKS4KPC9wcmU+Cjwv Ym9keT48L2h0bWw+Cg== ------_=_NextPart_001_01C8C1AD.B10CE57C Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8C1AD.B10CE57C-- From netconf-bounces@ietf.org Thu May 29 10:19:41 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD893A6B8B; Thu, 29 May 2008 10:19:41 -0700 (PDT) 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 1068E3A6B8B for ; Thu, 29 May 2008 10:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 AUu7u6d9OjnR for ; Thu, 29 May 2008 10:19:40 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 6013A3A69B8 for ; Thu, 29 May 2008 10:19:40 -0700 (PDT) Received: (qmail 31034 invoked from network); 29 May 2008 17:19:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.108 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 29 May 2008 17:19:37 -0000 X-YMail-OSG: IEq46ksVM1mQU8pePeBQ7k5J2unsJ5jiqCm2gZEysWbLkcyWPZfoB0RO7IAlt3ad5AGXQqtuDpLR9HBNShNV8tZ2cG9IV56hHB_V5pwuFCBy77R5r9zY_Ovb4Wd5PQ_0igM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <483EE5A8.1070500@netconfcentral.com> Date: Thu, 29 May 2008 10:19:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > Attached is the update to the Notification draft that I will be posting > later today. > > The following new paragraph is a bit confusing: * Secure execution means ensuring that a secure transport is used as well as ensuring that the user has sufficient authorization to perform the function they are requesting against the specific piece of NETCONF content involved. When a is received against the content defined in this memo, clients should only be able to view the content for which they have sufficient privileges. A create operation can be considered like a deferred , and the content that different users can access may vary. This different access is reflected in the that different users are able to subscribe to.* I suggest: line 3: s/piece/subset/ line 4: s/against/which refers to/ I don't really understand the normative implications of the last 2 sentences. What do they mean for an implementor and for an operator? (note email address change from ietf@andybierman.com -- that address is retired ;-) > Sharon Chisholm > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 29 10:19:41 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD893A6B8B; Thu, 29 May 2008 10:19:41 -0700 (PDT) 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 1068E3A6B8B for ; Thu, 29 May 2008 10:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 AUu7u6d9OjnR for ; Thu, 29 May 2008 10:19:40 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 6013A3A69B8 for ; Thu, 29 May 2008 10:19:40 -0700 (PDT) Received: (qmail 31034 invoked from network); 29 May 2008 17:19:39 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.108 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 29 May 2008 17:19:37 -0000 X-YMail-OSG: IEq46ksVM1mQU8pePeBQ7k5J2unsJ5jiqCm2gZEysWbLkcyWPZfoB0RO7IAlt3ad5AGXQqtuDpLR9HBNShNV8tZ2cG9IV56hHB_V5pwuFCBy77R5r9zY_Ovb4Wd5PQ_0igM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <483EE5A8.1070500@netconfcentral.com> Date: Thu, 29 May 2008 10:19:36 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > Attached is the update to the Notification draft that I will be posting > later today. > > The following new paragraph is a bit confusing: * Secure execution means ensuring that a secure transport is used as well as ensuring that the user has sufficient authorization to perform the function they are requesting against the specific piece of NETCONF content involved. When a is received against the content defined in this memo, clients should only be able to view the content for which they have sufficient privileges. A create operation can be considered like a deferred , and the content that different users can access may vary. This different access is reflected in the that different users are able to subscribe to.* I suggest: line 3: s/piece/subset/ line 4: s/against/which refers to/ I don't really understand the normative implications of the last 2 sentences. What do they mean for an implementor and for an operator? (note email address change from ietf@andybierman.com -- that address is retired ;-) > Sharon Chisholm > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu May 29 18:30:04 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9655628C195; Thu, 29 May 2008 18:30:04 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AF33928C107; Thu, 29 May 2008 18:30: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: <20080530013001.AF33928C107@core3.amsl.com> Date: Thu, 29 May 2008 18:30:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-notification-13.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Event Notifications Author(s) : S. Chisholm, H. Trevino Filename : draft-ietf-netconf-notification-13.txt Pages : 49 Date : 2008-05-29 This document defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-13.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-notification-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-29182631.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Thu May 29 18:30:04 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9655628C195; Thu, 29 May 2008 18:30:04 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AF33928C107; Thu, 29 May 2008 18:30: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: <20080530013001.AF33928C107@core3.amsl.com> Date: Thu, 29 May 2008 18:30:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-notification-13.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Event Notifications Author(s) : S. Chisholm, H. Trevino Filename : draft-ietf-netconf-notification-13.txt Pages : 49 Date : 2008-05-29 This document defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-13.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-notification-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-29182631.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --NextPart-- From netconf-bounces@ietf.org Fri May 30 05:39:24 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB52928C15D; Fri, 30 May 2008 05:39:24 -0700 (PDT) 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 AB5713A6960 for ; Fri, 30 May 2008 05:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=1.017, 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 FJu1EEHWvnd2 for ; Fri, 30 May 2008 05:39:16 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 0DE1D3A69C2 for ; Fri, 30 May 2008 05:38:31 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4UCcQ811426; Fri, 30 May 2008 12:38:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 08:38:07 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> In-Reply-To: <483EE5A8.1070500@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Pre-13 Notification (take 2) Thread-Index: AcjBsC9qz3pzY/3YQsCvD95s+vU+ewAoWbsQ References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> <483EE5A8.1070500@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I made those two changes in the version I posted last night. I don't think there are any normative implications of the last two sentences. It was a way of describing things that someone used (I think it was Charlie), which seemed to be helpful in the DISCUSS discussion so I included it in the draft. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Thursday, May 29, 2008 1:20 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) Sharon Chisholm wrote: > Hi > > Attached is the update to the Notification draft that I will be > posting later today. > > The following new paragraph is a bit confusing: * Secure execution means ensuring that a secure transport is used as well as ensuring that the user has sufficient authorization to perform the function they are requesting against the specific piece of NETCONF content involved. When a is received against the content defined in this memo, clients should only be able to view the content for which they have sufficient privileges. A create operation can be considered like a deferred , and the content that different users can access may vary. This different access is reflected From netconf-bounces@ietf.org Fri May 30 05:39:24 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB52928C15D; Fri, 30 May 2008 05:39:24 -0700 (PDT) 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 AB5713A6960 for ; Fri, 30 May 2008 05:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=1.017, 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 FJu1EEHWvnd2 for ; Fri, 30 May 2008 05:39:16 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 0DE1D3A69C2 for ; Fri, 30 May 2008 05:38:31 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4UCcQ811426; Fri, 30 May 2008 12:38:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 08:38:07 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> In-Reply-To: <483EE5A8.1070500@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Pre-13 Notification (take 2) Thread-Index: AcjBsC9qz3pzY/3YQsCvD95s+vU+ewAoWbsQ References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> <483EE5A8.1070500@netconfcentral.com> From: "Sharon Chisholm" To: "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I made those two changes in the version I posted last night. I don't think there are any normative implications of the last two sentences. It was a way of describing things that someone used (I think it was Charlie), which seemed to be helpful in the DISCUSS discussion so I included it in the draft. Sharon -----Original Message----- From: Andy Bierman [mailto:andy@netconfcentral.com] Sent: Thursday, May 29, 2008 1:20 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) Sharon Chisholm wrote: > Hi > > Attached is the update to the Notification draft that I will be > posting later today. > > The following new paragraph is a bit confusing: * Secure execution means ensuring that a secure transport is used as well as ensuring that the user has sufficient authorization to perform the function they are requesting against the specific piece of NETCONF content involved. When a is received against the content defined in this memo, clients should only be able to view the content for which they have sufficient privileges. A create operation can be considered like a deferred , and the content that different users can access may vary. This different access is reflected in thein the that different users are able to subscribe to.* I suggest: line 3: s/piece/subset/ line 4: s/against/which refers to/ I don't really understand the normative implications of the last 2 sentences. What do they mean for an implementor and for an operator? (note email address change from ietf@andybierman.com -- that address is retired ;-) > Sharon Chisholm > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf that different users are able to subscribe to.* I suggest: line 3: s/piece/subset/ line 4: s/against/which refers to/ I don't really understand the normative implications of the last 2 sentences. What do they mean for an implementor and for an operator? (note email address change from ietf@andybierman.com -- that address is retired ;-) > Sharon Chisholm > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 30 07:58:23 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5035728C1DB; Fri, 30 May 2008 07:58:23 -0700 (PDT) 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 C68E728C1D6 for ; Fri, 30 May 2008 07:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 TX1f1xOPO152 for ; Fri, 30 May 2008 07:58:16 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 7A3CF28C282 for ; Fri, 30 May 2008 07:57:38 -0700 (PDT) Received: (qmail 66288 invoked from network); 30 May 2008 14:57:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.108 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 30 May 2008 14:57:35 -0000 X-YMail-OSG: 6.QA_k8VM1mkot_VJV0XTPp7OUU_M3S.2n012FspoitpCb341BewFEptj9qlYxXExWRPbrwXxm0DNbDbO5CY6JvEGPM5lbX.WGe1w5CrGPR6DxfeNI5_1FnEtJ9aDZQxi9sKszdzUfJASks9EoWbkrxh X-Yahoo-Newman-Property: ymail-3 Message-ID: <484015DD.4090206@netconfcentral.com> Date: Fri, 30 May 2008 07:57:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> <483EE5A8.1070500@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > I made those two changes in the version I posted last night. > > I don't think there are any normative implications of the last two > sentences. It was a way of describing things that someone used (I think > it was Charlie), which seemed to be helpful in the DISCUSS discussion so > I included it in the draft. > I read it 3 more times. I think I see the intent. A will return the subset of that the user is authorized to view. A will likewise leave out elements that the user is not authorized to view. NETCONF is silent wrt/ when an access-denied error is returned. When does the agent skip over the node vs. return an error? Is it when the agent determines the filter is so specific there cannot be any other possible instance match? Can the implementation always detect this condition? (Some of the reasons I prefer the standard to remain silent on access control until a standard ACM exists.) > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Thursday, May 29, 2008 1:20 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netFrom netconf-bounces@ietf.org Fri May 30 07:58:23 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5035728C1DB; Fri, 30 May 2008 07:58:23 -0700 (PDT) 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 C68E728C1D6 for ; Fri, 30 May 2008 07:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 TX1f1xOPO152 for ; Fri, 30 May 2008 07:58:16 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id 7A3CF28C282 for ; Fri, 30 May 2008 07:57:38 -0700 (PDT) Received: (qmail 66288 invoked from network); 30 May 2008 14:57:38 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.108 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 30 May 2008 14:57:35 -0000 X-YMail-OSG: 6.QA_k8VM1mkot_VJV0XTPp7OUU_M3S.2n012FspoitpCb341BewFEptj9qlYxXExWRPbrwXxm0DNbDbO5CY6JvEGPM5lbX.WGe1w5CrGPR6DxfeNI5_1FnEtJ9aDZQxi9sKszdzUfJASks9EoWbkrxh X-Yahoo-Newman-Property: ymail-3 Message-ID: <484015DD.4090206@netconfcentral.com> Date: Fri, 30 May 2008 07:57:33 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> <483EE5A8.1070500@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > I made those two changes in the version I posted last night. > > I don't think there are any normative implications of the last two > sentences. It was a way of describing things that someone used (I think > it was Charlie), which seemed to be helpful in the DISCUSS discussion so > I included it in the draft. > I read it 3 more times. I think I see the intent. A will return the subset of that the user is authorized to view. A will likewise leave out elements that the user is not authorized to view. NETCONF is silent wrt/ when an access-denied error is returned. When does the agent skip over the node vs. return an error? Is it when the agent determines the filter is so specific there cannot be any other possible instance match? Can the implementation always detect this condition? (Some of the reasons I prefer the standard to remain silent on access control until a standard ACM exists.) > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Thursday, May 29, 2008 1:20 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Sharon Chisholm wrote: >> Hi >> >> Attached is the update to the Notification draft that I will be >> posting later today. >> >> > > The following new paragraph is a bit confusing: > > * Secure execution means ensuring that a secure transport is used as > well as ensuring that the user has sufficient authorization to > perform the function they are requesting against the specific piece > of NETCONF content involved. When a is received against the > content defined in this memo, clients should only be able to view the > content for which they have sufficient privileges. A create subscription> operation can be considered like a deferred , and > the content that different users can access may vary. This different > access is reflected in the that different users are > able to subscribe to.* > > > I suggest: > > line 3: > s/piece/subset/ > > line 4: > s/against/which refers to/ > > I don't really understand the normative implications of the last 2 > sentences. > What do they mean for an implementor and for an operator? > > (note email address change from ietf@andybierman.com -- that address is > retired ;-) > > >> Sharon Chisholm >> > > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf c: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Sharon Chisholm wrote: >> Hi >> >> Attached is the update to the Notification draft that I will be >> posting later today. >> >> > > The following new paragraph is a bit confusing: > > * Secure execution means ensuring that a secure transport is used as > well as ensuring that the user has sufficient authorization to > perform the function they are requesting against the specific piece > of NETCONF content involved. When a is received against the > content defined in this memo, clients should only be able to view the > content for which they have sufficient privileges. A create subscription> operation can be considered like a deferred , and > the content that different users can access may vary. This different > access is reflected in the that different users are > able to subscribe to.* > > > I suggest: > > line 3: > s/piece/subset/ > > line 4: > s/against/which refers to/ > > I don't really understand the normative implications of the last 2 > sentences. > What do they mean for an implementor and for an operator? > > (note email address change from ietf@andybierman.com -- that address is > retired ;-) > > >> Sharon Chisholm >> > > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 30 08:15:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B325128C1D9; Fri, 30 May 2008 08:15:00 -0700 (PDT) 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 323C83A6A0B for ; Fri, 30 May 2008 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 itO6nlzBLfnp for ; Fri, 30 May 2008 08:14:58 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id CC6373A6A0F for ; Fri, 30 May 2008 08:14:55 -0700 (PDT) Received: (qmail 15255 invoked from network); 30 May 2008 15:14:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.108 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 30 May 2008 15:14:53 -0000 X-YMail-OSG: Nb8S8loVM1k6wj82te1d2AvtV4VacHONrHcMH3mZ5IS5UCkss5Cfrd36n.mNBmc9Lpyb0YOPoIJI8bjqhD_UJqUiLqccxFEzNxUhHfMv1cqVflFE1fXBLEglZISpuOF.3Ewt380x978KLYeMhgSYTK4V X-Yahoo-Newman-Property: ymail-3 Message-ID: <484019EC.20800@netconfcentral.com> Date: Fri, 30 May 2008 08:14:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> <483EE5A8.1070500@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > I made those two changes in the version I posted last night. > > I don't think there are any normative implications of the last two > sentences. It was a way of describing things that someone used (I think > it was Charlie), which seemed to be helpful in the DISCUSS discussion so > I included it in the draft. > The text is also confusing me because access control for and are not the same at all. A response will only exclude the unauthorized nested elements, and return any other content the user is authorized to view. A must be buffered by the agent so that if any unauthorized sub-nodes are encountered, the entire is considered unauthorized (and dropped for that session). This makes some assumptions about how/why the internal ACM is behaving in certain ways. Why is is OK for a to drop only the unauthorized content, but it is not OK for a to do the same thing, even for the exact same subset of data? > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Thursday, May 29, 2008 1:20 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Sharon Chisholm wrote: >> Hi >> >> Attached is the update to the Notification draft that I will be >> posting later today. >> >> > > The following new paragraph is a bit confusing: > > * Secure execution means ensuring that a secure transport is used as > well as ensuring that the user has sufficient authorization to > perform the function they are requesting against the specific piece > of NETCONF content involved. When a is received against the > content defined in this memo, clients should only be able to view the > content for which they have sufficient privileges. A create subscription> operation can be considered like a deferred , and > the content that different users can access may vary. This different > access is reflected in the that different users are > able to subscribe to.* > > > I suggest: > > line 3: > s/piece/subset/ > > line 4: > s/against/which refers to/ > > I don't really understand the normative implications of the last 2 > sentences. > What do they mean for an implementor and for an operator? > > (note email address change from ietf@andybierman.com -- that address is > retired ;-) > > >> Sharon Chisholm >> > > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 30 08:15:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B325128C1D9; Fri, 30 May 2008 08:15:00 -0700 (PDT) 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 323C83A6A0B for ; Fri, 30 May 2008 08:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 itO6nlzBLfnp for ; Fri, 30 May 2008 08:14:58 -0700 (PDT) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by core3.amsl.com (Postfix) with SMTP id CC6373A6A0F for ; Fri, 30 May 2008 08:14:55 -0700 (PDT) Received: (qmail 15255 invoked from network); 30 May 2008 15:14:55 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.108 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 30 May 2008 15:14:53 -0000 X-YMail-OSG: Nb8S8loVM1k6wj82te1d2AvtV4VacHONrHcMH3mZ5IS5UCkss5Cfrd36n.mNBmc9Lpyb0YOPoIJI8bjqhD_UJqUiLqccxFEzNxUhHfMv1cqVflFE1fXBLEglZISpuOF.3Ewt380x978KLYeMhgSYTK4V X-Yahoo-Newman-Property: ymail-3 Message-ID: <484019EC.20800@netconfcentral.com> Date: Fri, 30 May 2008 08:14:52 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> <483EE5A8.1070500@netconfcentral.com> <713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > I made those two changes in the version I posted last night. > > I don't think there are any normative implications of the last two > sentences. It was a way of describing things that someone used (I think > it was Charlie), which seemed to be helpful in the DISCUSS discussion so > I included it in the draft. > The text is also confusing me because access control for and are not the same at all. A response will only exclude the unauthorized nested elements, and return any other content the user is authorized to view. A must be buffered by the agent so that if any unauthorized sub-nodes are encountered, the entire is considered unauthorized (and dropped for that session). This makes some assumptions about how/why the internal ACM is behaving in certain ways. Why is is OK for a to drop only the unauthorized content, but it is not OK for a to do the same thing, even for the exact same subset of data? > Sharon Andy > > -----Original Message----- > From: Andy Bierman [mailto:andy@netconfcentral.com] > Sent: Thursday, May 29, 2008 1:20 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netconf@ietf.org > Subject: Re: [Netconf] Pre-13 Notification (take 2) > > Sharon Chisholm wrote: >> Hi >> >> Attached is the update to the Notification draft that I will be >> posting later today. >> >> > > The following new paragraph is a bit confusing: > > * Secure execution means ensuring that a secure transport is used as > well as ensuring that the user has sufficient authorization to > perform the function they are requesting against the specific piece > of NETCONF content involved. When a is received against the > content defined in this memo, clients should only be able to view the > content for which they have sufficient privileges. A create subscription> operation can be considered like a deferred , and > the content that different users can access may vary. This different > access is reflected in the that different users are > able to subscribe to.* > > > I suggest: > > line 3: > s/piece/subset/ > > line 4: > s/against/which refers to/ > > I don't really understand the normative implications of the last 2 > sentences. > What do they mean for an implementor and for an operator? > > (note email address change from ietf@andybierman.com -- that address is > retired ;-) > > >> Sharon Chisholm >> > > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 30 11:38:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B243A6A3B; Fri, 30 May 2008 11:38:55 -0700 (PDT) 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 949E13A67DB for ; Fri, 30 May 2008 11:38:54 -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 kMMW9F62dZMq for ; Fri, 30 May 2008 11:38:53 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 0CD213A6C5E for ; Fri, 30 May 2008 11:36:17 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Xmde1Z0040bG4ec570Sh00; Fri, 30 May 2008 18:35:27 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.westchester.pa.mail.comcast.net with comcast id XucC1Z0064HwxpC3P00000; Fri, 30 May 2008 18:36:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=BaajDAp7ME0A:10 a=iNPBq3vamVAA:10 a=AVUMXvHFx5KjFdB5yQYA:9 a=CgYHpGTUtBHXlHkTOOcA:7 a=kkItSb5S-o-yryX4wmsvsNlGqagA:4 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'Andy Bierman'" , "'Sharon Chisholm'" References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> <483EE5A8.1070500@netconfcentral.com><713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> <484019EC.20800@netconfcentral.com> Date: Fri, 30 May 2008 14:36:12 -0400 Message-ID: <01ec01c8c284$0b7ea560$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjCZ/BbJx1eZAgeRR6tBohUKeSUtAAFdBmw In-Reply-To: <484019EC.20800@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > The text is also confusing me because access control for > and are not the same at all. A response > will only exclude the unauthorized nested elements, and return > any other content the user is authorized to view. > > A must be buffered by the agent so that if any > unauthorized sub-nodes are encountered, the entire > is considered unauthorized (and dropped for that session). > > This makes some assumptions about how/why the > internal ACM is behaving in certain ways. Why is is OK > for a to drop only the unauthorized content, but > it is not OK for a to do the same thing, > even for the exact same subset of data? I agree with this concern about embedded assumptions. In SNMPv3, if a principal is not allowed access to all the varbinds in the notification, the notification gets dropped. This makes sense in SNMP because we define the varbinds that must be in the notification (although even if an appended varbind is not authorized the whole thing gets dropped). I am not sure this must-drop-behavior should be a requirement for the **protocol** definition of Netconf notifications, especially if Netconf notifications might carry data from SNMP or syslog. This should probably be a function of the access control model(s), not the protocol. -- There may be a case for arguing that notifications are different than . If a system reports on an event, specifying certain related information, and the subscription only allows the operator to see a subset of the information, might that be misleading to the operator? In SNMPv1, we had to deal with implementations that, when they didn't support a counter, returned a zero value. This was misleading because, even if the underlying functionality was operating, and the events that were to be counted (e.g., packets out) occurred, the SNMP counters still said '0'. We want to avoid misleading the operator. Would reporting only part of the data, and not reporting exceptions for the missing data, be worse than reporting no data for some events? Would reporting exceptions for the missing data be a problem because it gives an attacker information about what a user is not authorized to see? Maybe the data model for notification definitions should be able to specify whether 1) all info must be authorized or do not send, or 2) unauthorized data should have an exception reported, or 3) partial data is acceptable. I think an access control model is a better place than either the protocol or the data model to make such a determination. I can envision wanting to let the helpdesk (support level 1) receive an alert with only partial information to make him aware that an event occurred, while a level 2 support person can subscribe for the same notification, and get more (potentially sensitive) information in the notification he receives. But I am not an operator, and operators may be fine with an all-or-nothing decision. dbh _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 30 11:38:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B243A6A3B; Fri, 30 May 2008 11:38:55 -0700 (PDT) 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 949E13A67DB for ; Fri, 30 May 2008 11:38:54 -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 kMMW9F62dZMq for ; Fri, 30 May 2008 11:38:53 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 0CD213A6C5E for ; Fri, 30 May 2008 11:36:17 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Xmde1Z0040bG4ec570Sh00; Fri, 30 May 2008 18:35:27 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.westchester.pa.mail.comcast.net with comcast id XucC1Z0064HwxpC3P00000; Fri, 30 May 2008 18:36:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=BaajDAp7ME0A:10 a=iNPBq3vamVAA:10 a=AVUMXvHFx5KjFdB5yQYA:9 a=CgYHpGTUtBHXlHkTOOcA:7 a=kkItSb5S-o-yryX4wmsvsNlGqagA:4 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'Andy Bierman'" , "'Sharon Chisholm'" References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> <483EE5A8.1070500@netconfcentral.com><713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> <484019EC.20800@netconfcentral.com> Date: Fri, 30 May 2008 14:36:12 -0400 Message-ID: <01ec01c8c284$0b7ea560$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjCZ/BbJx1eZAgeRR6tBohUKeSUtAAFdBmw In-Reply-To: <484019EC.20800@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > The text is also confusing me because access control for > and are not the same at all. A response > will only exclude the unauthorized nested elements, and return > any other content the user is authorized to view. > > A must be buffered by the agent so that if any > unauthorized sub-nodes are encountered, the entire > is considered unauthorized (and dropped for that session). > > This makes some assumptions about how/why the > internal ACM is behaving in certain ways. Why is is OK > for a to drop only the unauthorized content, but > it is not OK for a to do the same thing, > even for the exact same subset of data? I agree with this concern about embedded assumptions. In SNMPv3, if a principal is not allowed access to all the varbinds in the notification, the notification gets dropped. This makes sense in SNMP because we define the varbinds that must be in the notification (although even if an appended varbind is not authorized the whole thing gets dropped). I am not sure this must-drop-behavior should be a requirement for the **protocol** definition of Netconf notifications, especially if Netconf notifications might carry data from SNMP or syslog. This should probably be a function of the access control model(s), not the protocol. -- There may be a case for arguing that notifications are different than . If a system reports on an event, specifying certain related information, and the subscription only allows the operator to see a subset of the information, might that be misleading to the operator? In SNMPv1, we had to deal with implementations that, when they didn't support a counter, returned a zero value. This was misleading because, even if the underlying functionality was operating, and the events that were to be counted (e.g., packets out) occurred, the SNMP counters still said '0'. We want to avoid misleading the operator. Would reporting only part of the data, and not reporting exceptions for the missing data, be worse than reporting no data for some events? Would reporting exceptions for the missing data be a problem because it gives an attacker information about what a user is not authorized to see? Maybe the data model for notification definitions should be able to specify whether 1) all info must be authorized or do not send, or 2) unauthorized data should have an exception reported, or 3) partial data is acceptable. I think an access control model is a better place than either the protocol or the data model to make such a determination. I can envision wanting to let the helpdesk (support level 1) receive an alert with only partial information to make him aware that an event occurred, while a level 2 support person can subscribe for the same notification, and get more (potentially sensitive) information in the notification he receives. But I am not an operator, and operators may be fine with an all-or-nothing decision. dbh _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri May 30 12:30:34 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4613A68EB; Fri, 30 May 2008 12:30:34 -0700 (PDT) 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 265023A68C0 for ; Fri, 30 May 2008 12:30:33 -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 OQ3u8sDNTlBo for ; Fri, 30 May 2008 12:30:32 -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 E77563A67A4 for ; Fri, 30 May 2008 12:30:31 -0700 (PDT) Received: (qmail 57018 invoked from network); 30 May 2008 19:30:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.108 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 30 May 2008 19:30:29 -0000 X-YMail-OSG: 06LX3ZYVM1nDCenUNZwL5r02aUynYeUdIEbFl55HaijdWoaq.fAmPr3ldtDE.HuIflxwnLb_r_.Lp_hBHy4uljGv9VP5wJuo5h2Nc1lrZKXhyevWcxrnqouNefu_XZljswc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <484055D2.1090505@netconfcentral.com> Date: Fri, 30 May 2008 12:30:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David B Harrington References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> <483EE5A8.1070500@netconfcentral.com><713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> <484019EC.20800@netconfcentral.com> <01ec01c8c284$0b7ea560$0600a8c0@china.huawei.com> In-Reply-To: <01ec01c8c284$0b7ea560$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > > >> The text is also confusing me because access control for >> and are not the same at all. A response >> will only exclude the unauthorized nested elements, and return >> any other content the user is authorized to view. >> >> A must be buffered by the agent so that if any >> unauthorized sub-nodes are encountered, the entire >> is considered unauthorized (and dropped for that session). >> >> This makes some assumptions about how/why the >> internal ACM is behaving in certain ways. Why is is OK >> for a to drop only the unauthorized content, but >> it is not OK for a to do the same thing, >> even for the exact same subset of data? > > I agree with this concern about embedded assumptions. > > In SNMPv3, if a principal is not allowed access to all the varbinds in > the notification, the notification gets dropped. This makes sense in > SNMP because we define the varbinds that must be in the notification > (although even if an appended varbind is not authorized the whole > thing gets dropped). > > I aFrom netconf-bounces@ietf.org Fri May 30 12:30:34 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4613A68EB; Fri, 30 May 2008 12:30:34 -0700 (PDT) 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 265023A68C0 for ; Fri, 30 May 2008 12:30:33 -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 OQ3u8sDNTlBo for ; Fri, 30 May 2008 12:30:32 -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 E77563A67A4 for ; Fri, 30 May 2008 12:30:31 -0700 (PDT) Received: (qmail 57018 invoked from network); 30 May 2008 19:30:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.108 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 30 May 2008 19:30:29 -0000 X-YMail-OSG: 06LX3ZYVM1nDCenUNZwL5r02aUynYeUdIEbFl55HaijdWoaq.fAmPr3ldtDE.HuIflxwnLb_r_.Lp_hBHy4uljGv9VP5wJuo5h2Nc1lrZKXhyevWcxrnqouNefu_XZljswc- X-Yahoo-Newman-Property: ymail-3 Message-ID: <484055D2.1090505@netconfcentral.com> Date: Fri, 30 May 2008 12:30:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David B Harrington References: <713043CE8B8E1348AF3C546DBE02C1B414C64475@zcarhxm2.corp.nortel.com> <483EE5A8.1070500@netconfcentral.com><713043CE8B8E1348AF3C546DBE02C1B414CA5915@zcarhxm2.corp.nortel.com> <484019EC.20800@netconfcentral.com> <01ec01c8c284$0b7ea560$0600a8c0@china.huawei.com> In-Reply-To: <01ec01c8c284$0b7ea560$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Pre-13 Notification (take 2) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > > >> The text is also confusing me because access control for >> and are not the same at all. A response >> will only exclude the unauthorized nested elements, and return >> any other content the user is authorized to view. >> >> A must be buffered by the agent so that if any >> unauthorized sub-nodes are encountered, the entire >> is considered unauthorized (and dropped for that session). >> >> This makes some assumptions about how/why the >> internal ACM is behaving in certain ways. Why is is OK >> for a to drop only the unauthorized content, but >> it is not OK for a to do the same thing, >> even for the exact same subset of data? > > I agree with this concern about embedded assumptions. > > In SNMPv3, if a principal is not allowed access to all the varbinds in > the notification, the notification gets dropped. This makes sense in > SNMP because we define the varbinds that must be in the notification > (although even if an appended varbind is not authorized the whole > thing gets dropped). > > I am not m not sure this must-drop-behavior should be a requirement for the > **protocol** definition of Netconf notifications, especially if > Netconf notifications might carry data from SNMP or syslog. This > should probably be a function of the access control model(s), not the > protocol. I am also concerned about a MUST drop directive cast-in-stone, without much thought about the overall access control model or security use cases. Clearly, the method needs to work as currently defined. NETCONF would be completely unusable if an operator had to specify exact leafs to retrieve because access control on some nested subtree causes normal filters to be unusable. Won't the all-or-nothing restriction cause similar problems for operators wrt/ notification receiver applications? Won't this force data model writers to create multiple versions of any notification that includes some (but not all) sensitive data? SNMP is somewhat different because the varbinds are all leafs and non-extensible. NETCONF content can be complex, nested, and include multiple namespaces. The likelihood that a complex structure sill have some optional (yet sensitive) data is much higher. SNMP is UDP-based, and very few mandatory varbinds are usually defined for a notification. If implementors take advantage of NETCONF's unlimited notification payload size, this all-or-nothing restriction is going to become a DM design factor. This would be a serious protocol design flaw. It should be up to the network administrator, not the protocol, to decide how access control should handle notification content (and all other content). At a minimum, the draft should explain in detail why the entire notification must be dropped but no access control restrictions for other types of NETCONF operations exist at all. Explain the access control model in detail or take out the ad-hoc bits and pieces. Andy > > -- > There may be a case for arguing that notifications are different than > . If a system reports on an event, specifying certain related > information, and the subscription only allows the operator to see a > subset of the information, might that be misleading to the operator? > In SNMPv1, we had to deal with implementations that, when they didn't > support a counter, returned a zero value. This was misleading because, > even if the underlying functionality was operating, and the events > that were to be counted (e.g., packets out) occurred, the SNMP > counters still said '0'. We want to avoid misleading the operator. > > Would reporting only part of the data, and not reporting exceptions > for the missing data, be worse than reporting no data for some events? > Would reporting exceptions for the missing data be a problem because > it gives an attacker information about what a user is not authorized > to see? > > Maybe the data model for notification definitions should be able to > specify whether 1) all info must be authorized or do not send, or 2) > unauthorized data should have an exception reported, or 3) partial > data is acceptable. > > I think an access control model is a better place than either the > protocol or the data model to make such a determination. I can > envision wanting to let the helpdesk (support level 1) receive an > alert with only partial information to make him aware that an event > occurred, while a level 2 support person can subscribe for the same > notification, and get more (potentially sensitive) information in the > notification he receives. > > But I am not an operator, and operators may be fine with an > all-or-nothing decision. > > dbh > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf sure this must-drop-behavior should be a requirement for the > **protocol** definition of Netconf notifications, especially if > Netconf notifications might carry data from SNMP or syslog. This > should probably be a function of the access control model(s), not the > protocol. I am also concerned about a MUST drop directive cast-in-stone, without much thought about the overall access control model or security use cases. Clearly, the method needs to work as currently defined. NETCONF would be completely unusable if an operator had to specify exact leafs to retrieve because access control on some nested subtree causes normal filters to be unusable. Won't the all-or-nothing restriction cause similar problems for operators wrt/ notification receiver applications? Won't this force data model writers to create multiple versions of any notification that includes some (but not all) sensitive data? SNMP is somewhat different because the varbinds are all leafs and non-extensible. NETCONF content can be complex, nested, and include multiple namespaces. The likelihood that a complex structure sill have some optional (yet sensitive) data is much higher. SNMP is UDP-based, and very few mandatory varbinds are usually defined for a notification. If implementors take advantage of NETCONF's unlimited notification payload size, this all-or-nothing restriction is going to become a DM design factor. This would be a serious protocol design flaw. It should be up to the network administrator, not the protocol, to decide how access control should handle notification content (and all other content). At a minimum, the draft should explain in detail why the entire notification must be dropped but no access control restrictions for other types of NETCONF operations exist at all. Explain the access control model in detail or take out the ad-hoc bits and pieces. Andy > > -- > There may be a case for arguing that notifications are different than > . If a system reports on an event, specifying certain related > information, and the subscription only allows the operator to see a > subset of the information, might that be misleading to the operator? > In SNMPv1, we had to deal with implementations that, when they didn't > support a counter, returned a zero value. This was misleading because, > even if the underlying functionality was operating, and the events > that were to be counted (e.g., packets out) occurred, the SNMP > counters still said '0'. We want to avoid misleading the operator. > > Would reporting only part of the data, and not reporting exceptions > for the missing data, be worse than reporting no data for some events? > Would reporting exceptions for the missing data be a problem because > it gives an attacker information about what a user is not authorized > to see? > > Maybe the data model for notification definitions should be able to > specify whether 1) all info must be authorized or do not send, or 2) > unauthorized data should have an exception reported, or 3) partial > data is acceptable. > > I think an access control model is a better place than either the > protocol or the data model to make such a determination. I can > envision wanting to let the helpdesk (support level 1) receive an > alert with only partial information to make him aware that an event > occurred, while a level 2 support person can subscribe for the same > notification, and get more (potentially sensitive) information in the > notification he receives. > > But I am not an operator, and operators may be fine with an > all-or-nothing decision. > > dbh > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf