From wjhns1@hardakers.net Mon Aug 1 09:28:04 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A67B21F8E06 for ; Mon, 1 Aug 2011 09:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr7qL+xEEJ9O for ; Mon, 1 Aug 2011 09:28:03 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id C17D121F88DD for ; Mon, 1 Aug 2011 09:27:43 -0700 (PDT) Received: from localhost (unknown [10.1.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 6FF2A175; Mon, 1 Aug 2011 09:27:19 -0700 (PDT) From: Wes Hardaker To: "Bert \(IETF\) Wijnen" References: <4E1DB164.5090007@bwijnen.net> <4E32E057.7030707@bwijnen.net> Date: Mon, 01 Aug 2011 09:27:18 -0700 In-Reply-To: <4E32E057.7030707@bwijnen.net> (Bert Wijnen's message of "Fri, 29 Jul 2011 12:31:19 -0400") Message-ID: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: Tim Polk , netconf Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:28:04 -0000 >>>>> On Fri, 29 Jul 2011 12:31:19 -0400, "Bert (IETF) Wijnen" said: BW> Pls review BEFORE or BY August 1 if you have not already done so. BW> A "I read it and see no issues or have no concerns" is also very welcome! I read this document on the way home. There is no really easy way to say this, so I'll be blunt: this document is not ready to go forward. I'm very happy that this document exists and is trying to go forward, and I very much want a standardized access control model, so I'm making this statement even knowing it'll hamper my desire to get something standardized. Though I have technical comments too, the real show-stoppers were the document layout and readability. I started marking up the paper with editorial notes and wording suggestions, but eventually started marking only the major issues. So the items listed below are a summary of the larger issues I have and I skipped documenting my minor-edits. Unfortunately, my available time in the next month especially is pretty much non-existent (which is why I read it on the plane: I knew I couldn't get to at all otherwise). I'd love to help out with some real edits, but my time [and job] won't permit it. I feel guilty dropping this on the doorstep, but I don't have another alternative. I suppose that gives you the right to say "not helpful" and delete this message :-) == Document structure issues == * Document structure: requirements vs NACM definition The document actually tries to do 2 things: + define a set of requirements that every netconf ACM must fulfill + define an instance of a netconf ACM that meets some of the requirements The problem is that the document isn't divided into parts that make this double-role readable. Section 2 is listed as "access control design requirements" but isn't really worded with an introduction that indicates this and is also sprinkled with text that seems to apply to the specific implementation of the requirements too (eg, 2.4.1 isn't really a requirement but is one implementation). IMHO, if we need to define a set of requirements they should really be in a separate draft. The choices I see to go forward: 1) split the requirements into a second draft 2) remove the requirements and don't try to state what NACM is being held up against. 3) do a really good job separating them from the NACM specific implementation * Section 2 even starts off with an "Editor's note", which made me immediately wonder if I really was reading the "last call" document, but I checked in the second airport to confirm I really was reading the most recent version. Multiple other "Editor's notes" exist in the document as well and certainly shouldn't be there. * Figure 1 makes no sense as currently drawn. It likely needs some missing arrows or something (and it's also not referenced anywhere in the text). * Notification content is referred to in a number of places restricting access on "event types" but doesn't discuss other included data that will go along inside the notification. == Technical Reservations == * I'm not convinced, but not against, that a single ACM model should be applied across candidate, running and startup. I could see not wanting people to copy the config from running to startup, eg. * I'd make the text more clear about that access control is only applied to netconf sessions. In a few places it says things like "after boot", etc, but the wording is fuzzy. Simply stating that it is only applied to operations received over the netconf protocol would make it more clear. * the security considerations needs to discuss that the protocol can be used to probe for information via some of the error/no-error cases that are discussed in a few places. * The whole "read and execute" by default still makes me cringe inside. Especially with the execute bit being on by default. The ACM should stop a user from executing a command that twiddles configuration, because the write-access implemented within an rpc operation would be trumped on data-modification. But I could certainly see people defining dangerous execute operations that don't twiddle config. EG, does the equivalent of "" actually modify config data (insert long standing debate about control vs config data here). Or what about "" (which hasn't been written yet, but thinking about the future is critical in cases like this). Fortunately, not every system user will have netconf access without being assigned into a group. This is straight forward for groups that were configured manually, but is much less so for group memberships configured via RADIUS or another "central server" outside the box. * 2.4.4 (copy-config) needs a discussion on data deletion too. * 2.4.4 (copy-config) discusses that a operator MUST have full read access but doesn't say what happens when an operator doesn't. * 2.9 (data shadowing) fails to bring a clear point to the text and seems to be discussing actually two different topics. * 3.1.3 (Message Processing Model) Is figure 2 a netconf standard processing model? Is implementing this flow as is a requirement? The document doesn't state this (or is it an "example" model). * 3.1.3 (and other places) mentions that the close-session message is exempt from processing. I think it'd be easier to define a list of message types that *don't* get access control processing with only a single entry in it for the time being. But doing it this way would let other documents add to the list, if need be, and the named list could be used consistently in the rest of the document. Sub question: is the message technically an RPC message or not? (I didn't read other documentation to find out). * 3.1.2 (users) needs to discuss naming conflicts. I believe the document intentionally shys away from this, but that doesn't solve the problem. At a minimum the security consideration section needs to mention that users coming in over the different channels may have the same user name since the users are not zoned by incoming protocol. * 3.2.5.3 write-default switch: does this apply to create, update and delete uniformly. If so, it needs to be stated. * 3.3.2 session establishment: why is the prohibition against sensitive data in the capability elements a SHOULD NOT and not a MUST NOT? * 3.3.5 and following: the rules don't discuss what happens when data exists in the config that doesn't exist (but maybe should). IE, what happens when the access-operations node doesn't exist? The default for a access-operations is a '*' but what if a user deletes the config node? (the answer is probably mostly obvious but needs to be stated; though some would argue that if the result is supposed to be a 'deny' and there is missing data, then it should always deny by default because the rule is broken and you shouldn't skip it, where as a 'permit' rule should deny by default with missing data) * The "secure" and "very-secure" names are cute, but they're generally meaningless to the reader. I'd suggest renaming them to keywords that include the functionality underneath. Maybe: secure -> nacm:default-deny-modification very-security -> nacm:default-deny-all * yang model: ** user-name-type max: implementations must support any string length that a transport model returns for a user name? Even if it's really long (consider a base64 name of an x.509 certificate; yes I realize this example is silly). ** node-instance-identifier So xpath 1.0 is required for nacm, right? What happened to the whole "we can't make everything require xpath because it's too much overhead" from the early netconf days. Or is it expected that devices that don't want to do xpath won't want access control mechanisms? * installing yang models into devices may change the security ramifications on the system. EG, if the internal implementation is reading yang modules to apply access control settings on (IE, they're not hard-coded but the definitions are read from a .yang file itself), then a user might have a way to install a new version of the module without the yang:very-secure flags, etc, thus suddenly allowing access. I'd mention this in the security considerations at a minimum. * somewhere (security considerations) should mention that when editing rules on the running config container, it is critical to insert rules in an order that doesn't give access to users by mistakenly inserting the permissive rules before the denial rules. There is a paragraph in the security considerations that hints at this, but I'd make it more clear by stating "operators should insert denial rules first" or something and specifically mention that the running container is critical to get right. * the security considerations (and maybe elsewhere) should discuss data references, where dealing with external keys, etc, are explicitly spelled out. * might want to list rollbacks, etc, somewhere as write-operations that need to be checked too. * Nowhere does it discuss what it means to lock (or partial-lock) a container when you don't have access to the whole container. * If the exmaples in A.3 don't have an end "deny-all" rule or "permit-all" rule, then text needs to be inserted stating what will happen to help the user understand the dependency on the global flags, etc. * A.3, example rule-list #2: access-operations is 'exec' but the comment talks about writing. * A.3, since the "monitor" group is used in many places to provide more than just monitoring access, I'd suggest renaming the group to "limited" or something. -- Wes Hardaker SPARTA, Inc. From ietf@andybierman.com Mon Aug 1 09:46:36 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A6E11E80EA for ; Mon, 1 Aug 2011 09:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fenc+3C8gGnx for ; Mon, 1 Aug 2011 09:46:35 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0393411E80D5 for ; Mon, 1 Aug 2011 09:46:34 -0700 (PDT) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p71GkcGY022210 for ; Mon, 1 Aug 2011 12:46:41 -0400 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59041] helo=[192.168.0.146]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 96/67-10157-D68D63E4; Mon, 01 Aug 2011 12:46:38 -0400 Message-ID: <4E36D86A.5010903@andybierman.com> Date: Mon, 01 Aug 2011 09:46:34 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Wes Hardaker References: <4E1DB164.5090007@bwijnen.net> <4E32E057.7030707@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Polk , netconf Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:46:36 -0000 On 08/01/2011 09:27 AM, Wes Hardaker wrote: >>>>>> On Fri, 29 Jul 2011 12:31:19 -0400, "Bert (IETF) Wijnen" said: > > BW> Pls review BEFORE or BY August 1 if you have not already done so. > BW> A "I read it and see no issues or have no concerns" is also very welcome! > > I read this document on the way home. There is no really easy way to > say this, so I'll be blunt: this document is not ready to go forward. > I'm very happy that this document exists and is trying to go forward, > and I very much want a standardized access control model, so I'm making > this statement even knowing it'll hamper my desire to get something > standardized. > > Though I have technical comments too, the real show-stoppers were the > document layout and readability. I started marking up the paper with > editorial notes and wording suggestions, but eventually started marking > only the major issues. So the items listed below are a summary of the > larger issues I have and I skipped documenting my minor-edits. > I think you should review the next version. Many of the issues you raise are going to be addressed, and were already raised by Juergen. Will will look at your new issues as well. The normative text will be moved from the objectives section, but a separate draft for objectives is already out of scope. > Unfortunately, my available time in the next month especially is pretty > much non-existent (which is why I read it on the plane: I knew I > couldn't get to at all otherwise). I'd love to help out with some real > edits, but my time [and job] won't permit it. I feel guilty dropping > this on the doorstep, but I don't have another alternative. I suppose > that gives you the right to say "not helpful" and delete this message :-) > > > == Document structure issues == > > * Document structure: requirements vs NACM definition > > The document actually tries to do 2 things: > > + define a set of requirements that every netconf ACM must fulfill > + define an instance of a netconf ACM that meets some of the requirements > > The problem is that the document isn't divided into parts that make > this double-role readable. Section 2 is listed as "access control > design requirements" but isn't really worded with an introduction that > indicates this and is also sprinkled with text that seems to apply to > the specific implementation of the requirements too (eg, 2.4.1 isn't > really a requirement but is one implementation). > > IMHO, if we need to define a set of requirements they should really be > in a separate draft. The choices I see to go forward: > > 1) split the requirements into a second draft > 2) remove the requirements and don't try to state what NACM is being > held up against. > 3) do a really good job separating them from the NACM specific implementation > > > > * Section 2 even starts off with an "Editor's note", which made me > immediately wonder if I really was reading the "last call" document, > but I checked in the second airport to confirm I really was reading > the most recent version. Multiple other "Editor's notes" exist in the > document as well and certainly shouldn't be there. This was resolved at the WG meeting and will be finalized in the next rev. > > * Figure 1 makes no sense as currently drawn. It likely needs some > missing arrows or something (and it's also not referenced anywhere in > the text). It will be redrawn, along with some changes to fig. 2 > > * Notification content is referred to in a number of places restricting > access on "event types" but doesn't discuss other included data that > will go along inside the notification. this inside data is out of scope. NACM only filters notifications on event type, not the contents. Same for protocol operations that do not touch a datastore. One lesson from VACM: you can make access control so hard to use, that it doesn't get used. > > == Technical Reservations == > > * I'm not convinced, but not against, that a single ACM model should be > applied across candidate, running and startup. I could see not > wanting people to copy the config from running to startup, eg. > > * I'd make the text more clear about that access control is only applied > to netconf sessions. In a few places it says things like "after > boot", etc, but the wording is fuzzy. Simply stating that it is only > applied to operations received over the netconf protocol would make it > more clear. > > * the security considerations needs to discuss that the protocol can be > used to probe for information via some of the error/no-error cases > that are discussed in a few places. > > * The whole "read and execute" by default still makes me cringe inside. > Especially with the execute bit being on by default. The ACM should > stop a user from executing a command that twiddles configuration, > because the write-access implemented within an rpc operation would be > trumped on data-modification. But I could certainly see people > defining dangerous execute operations that don't twiddle config. EG, > does the equivalent of "" actually modify config data > (insert long standing debate about control vs config data here). Or > what about "" (which hasn't been written yet, but > thinking about the future is critical in cases like this). > > Fortunately, not every system user will have netconf access without > being assigned into a group. This is straight forward for groups that > were configured manually, but is much less so for group memberships > configured via RADIUS or another "central server" outside the box. > > * 2.4.4 (copy-config) needs a discussion on data deletion too. > > * 2.4.4 (copy-config) discusses that a operator MUST have full read > access but doesn't say what happens when an operator doesn't. > > * 2.9 (data shadowing) fails to bring a clear point to the text and > seems to be discussing actually two different topics. > > * 3.1.3 (Message Processing Model) Is figure 2 a netconf standard > processing model? Is implementing this flow as is a requirement? The > document doesn't state this (or is it an "example" model). > > * 3.1.3 (and other places) mentions that the close-session message is > exempt from processing. I think it'd be easier to define a list of > message types that *don't* get access control processing with only a > single entry in it for the time being. But doing it this way would > let other documents add to the list, if need be, and the named list > could be used consistently in the rest of the document. > > Sub question: is the message technically an RPC message or not? > (I didn't read other documentation to find out). > > * 3.1.2 (users) needs to discuss naming conflicts. I believe the > document intentionally shys away from this, but that doesn't solve the > problem. At a minimum the security consideration section needs to > mention that users coming in over the different channels may have the > same user name since the users are not zoned by incoming protocol. > > * 3.2.5.3 write-default switch: does this apply to create, update and > delete uniformly. If so, it needs to be stated. > > * 3.3.2 session establishment: why is the prohibition against sensitive > data in the capability elements a SHOULD NOT and not a MUST NOT? > > * 3.3.5 and following: the rules don't discuss what happens when data > exists in the config that doesn't exist (but maybe should). IE, what > happens when the access-operations node doesn't exist? The default > for a access-operations is a '*' but what if a user deletes the config > node? > > (the answer is probably mostly obvious but needs to be stated; though > some would argue that if the result is supposed to be a 'deny' and > there is missing data, then it should always deny by default because > the rule is broken and you shouldn't skip it, where as a 'permit' rule > should deny by default with missing data) > > * The "secure" and "very-secure" names are cute, but they're generally > meaningless to the reader. I'd suggest renaming them to keywords that > include the functionality underneath. Maybe: > > secure -> nacm:default-deny-modification > very-security -> nacm:default-deny-all > > * yang model: > > ** user-name-type max: implementations must support any string length > that a transport model returns for a user name? Even if it's really > long (consider a base64 name of an x.509 certificate; yes I realize > this example is silly). > > ** node-instance-identifier > > So xpath 1.0 is required for nacm, right? What happened to the whole > "we can't make everything require xpath because it's too much > overhead" from the early netconf days. Or is it expected that > devices that don't want to do xpath won't want access control mechanisms? > > * installing yang models into devices may change the security > ramifications on the system. EG, if the internal implementation is > reading yang modules to apply access control settings on (IE, they're > not hard-coded but the definitions are read from a .yang file itself), > then a user might have a way to install a new version of the module > without the yang:very-secure flags, etc, thus suddenly allowing > access. I'd mention this in the security considerations at a minimum. > > * somewhere (security considerations) should mention that when editing > rules on the running config container, it is critical to insert rules > in an order that doesn't give access to users by mistakenly inserting > the permissive rules before the denial rules. There is a paragraph in > the security considerations that hints at this, but I'd make it more > clear by stating "operators should insert denial rules first" or > something and specifically mention that the running container is > critical to get right. > > * the security considerations (and maybe elsewhere) should discuss data > references, where dealing with external keys, etc, are explicitly > spelled out. > > * might want to list rollbacks, etc, somewhere as write-operations that > need to be checked too. > > * Nowhere does it discuss what it means to lock (or partial-lock) a > container when you don't have access to the whole container. > > * If the exmaples in A.3 don't have an end "deny-all" rule or > "permit-all" rule, then text needs to be inserted stating what will > happen to help the user understand the dependency on the global flags, > etc. > > * A.3, example rule-list #2: access-operations is 'exec' but the comment > talks about writing. > > * A.3, since the "monitor" group is used in many places to provide more > than just monitoring access, I'd suggest renaming the group to > "limited" or something. > From ietf@andybierman.com Mon Aug 1 13:45:10 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180CB1F0C40 for ; Mon, 1 Aug 2011 13:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8f9Ryr-E7Rs for ; Mon, 1 Aug 2011 13:45:09 -0700 (PDT) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by ietfa.amsl.com (Postfix) with ESMTP id E3F291F0C3F for ; Mon, 1 Aug 2011 13:45:08 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p71KjDri008442 for ; Mon, 1 Aug 2011 16:45:13 -0400 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:33251] helo=[192.168.0.146]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 82/DE-07466-850173E4; Mon, 01 Aug 2011 16:45:13 -0400 Message-ID: <4E371055.1030509@andybierman.com> Date: Mon, 01 Aug 2011 13:45:09 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Phil Shafer References: <201107291336.p6TDalN0092145@idle.juniper.net> In-Reply-To: <201107291336.p6TDalN0092145@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:45:10 -0000 On 07/29/2011 06:36 AM, Phil Shafer wrote: > Martin Bjorklund writes: >> NEW: >> leaf killed-by { >> when "../termination-reason = 'killed'"; >> type nc:session-id-type-or-zero; >> description >> "The ID of the session that terminated this session, or the >> value '0' if it was terminated in some other way."; > > Why emit the leaf at all if it doesn't have a valuable value? > It could be valuable to know a non-NETCONF session killed your session. I do not think all servers are required to give non-zero session IDs to non-NETCONF sessions. I know they MAY do that, but not MUST do that. So it is possible for a server to know a non-NETCONF session killed a NETCONF session without assigning it a non-zero session ID. > Thanks, > Phil Andy From phil@juniper.net Mon Aug 1 13:57:44 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C45E1F0C3E for ; Mon, 1 Aug 2011 13:57:44 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBbpHT2x5zoB for ; Mon, 1 Aug 2011 13:57:43 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 790231F0C39 for ; Mon, 1 Aug 2011 13:57:40 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTjcTS27jbcz8Iy4mxCfMKE0nkYpEh+dC@postini.com; Mon, 01 Aug 2011 13:57:50 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 1 Aug 2011 13:57:02 -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 p71Kuwv67685; Mon, 1 Aug 2011 13:56:58 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p71KUS7D013580; Mon, 1 Aug 2011 20:30:29 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201108012030.p71KUS7D013580@idle.juniper.net> To: Andy Bierman In-Reply-To: <4E371055.1030509@andybierman.com> Date: Mon, 1 Aug 2011 16:30:28 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:57:44 -0000 Andy Bierman writes: >On 07/29/2011 06:36 AM, Phil Shafer wrote: >> Martin Bjorklund writes: >>> NEW: >>> leaf killed-by { >>> when "../termination-reason = 'killed'"; >>> type nc:session-id-type-or-zero; >>> description >>> "The ID of the session that terminated this session, or the >>> value '0' if it was terminated in some other way."; >> >> Why emit the leaf at all if it doesn't have a valuable value? >> > >It could be valuable to know a non-NETCONF session killed your session. >I do not think all servers are required to give non-zero session IDs >to non-NETCONF sessions. I know they MAY do that, but not MUST do that. >So it is possible for a server to know a non-NETCONF session killed a >NETCONF session without assigning it a non-zero session ID. Sorry, but I might have confused you. I'll try again. If you want to indicate that a session was not terminated by another session, you can represent this in two ways. Your proposal is: 0 But I'm asked why you would emit this tag if the value it contains is not valuable. If you don't know the session that killed it, then don't emit the tag at all. This is a general topic where folks use "magic numbers" to change the meaning of a field. I'd rather see a leaf than see the value zero mean there is no foo. Thanks, Phil From ietf@andybierman.com Mon Aug 1 14:07:09 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6573F1F0C47 for ; Mon, 1 Aug 2011 14:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujPNLO7u3x8V for ; Mon, 1 Aug 2011 14:07:08 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 764191F0C3F for ; Mon, 1 Aug 2011 14:07:07 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p71L7EuU031805 for ; Mon, 1 Aug 2011 17:07:14 -0400 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:55105] helo=[192.168.0.146]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 28/6B-11423-085173E4; Mon, 01 Aug 2011 17:07:14 -0400 Message-ID: <4E37157E.80005@andybierman.com> Date: Mon, 01 Aug 2011 14:07:10 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Phil Shafer References: <201108012030.p71KUS7D013580@idle.juniper.net> In-Reply-To: <201108012030.p71KUS7D013580@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 21:07:09 -0000 On 08/01/2011 01:30 PM, Phil Shafer wrote: > Andy Bierman writes: >> On 07/29/2011 06:36 AM, Phil Shafer wrote: >>> Martin Bjorklund writes: >>>> NEW: >>>> leaf killed-by { >>>> when "../termination-reason = 'killed'"; >>>> type nc:session-id-type-or-zero; >>>> description >>>> "The ID of the session that terminated this session, or the >>>> value '0' if it was terminated in some other way."; >>> >>> Why emit the leaf at all if it doesn't have a valuable value? >>> >> >> It could be valuable to know a non-NETCONF session killed your session. >> I do not think all servers are required to give non-zero session IDs >> to non-NETCONF sessions. I know they MAY do that, but not MUST do that. >> So it is possible for a server to know a non-NETCONF session killed a >> NETCONF session without assigning it a non-zero session ID. > > Sorry, but I might have confused you. I'll try again. > I think you are confused. It is possible for the session doing the abnormal terminating to be a non-NETCONF session which is identified by the value '0'. A server MAY choose to identify all such sessions with the value '0', or represent all of them with a single ID -- 0. leaf killed-by { when "../termination-reason = 'killed'"; type nc:session-id-type-or-zero; description "The ID of the session that terminated this session, or the value '0' if it was terminated by a non-NETCONF session identified to this server with the ID '0'."; Andy > If you want to indicate that a session was not terminated by another > session, you can represent this in two ways. Your proposal is: > > 0 > > But I'm asked why you would emit this tag if the value it contains > is not valuable. If you don't know the session that killed it, > then don't emit the tag at all. > > This is a general topic where folks use "magic numbers" to change > the meaning of a field. I'd rather see a > leaf than see the value zero mean there is no foo. > > Thanks, > Phil > > From wjhns1@hardakers.net Mon Aug 1 14:14:40 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADA21F0C3D for ; Mon, 1 Aug 2011 14:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43wg5WlyneGn for ; Mon, 1 Aug 2011 14:14:40 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 451C91F0C39 for ; Mon, 1 Aug 2011 14:14:40 -0700 (PDT) Received: from localhost (unknown [10.1.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 238F6179; Mon, 1 Aug 2011 14:14:17 -0700 (PDT) From: Wes Hardaker To: Andy Bierman References: <4E1DB164.5090007@bwijnen.net> <4E32E057.7030707@bwijnen.net> <4E36D86A.5010903@andybierman.com> Date: Mon, 01 Aug 2011 14:14:16 -0700 In-Reply-To: <4E36D86A.5010903@andybierman.com> (Andy Bierman's message of "Mon, 01 Aug 2011 09:46:34 -0700") Message-ID: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netconf , Tim Polk Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 21:14:40 -0000 AB> The normative text will be moved from the objectives section, AB> but a separate draft for objectives is already out of scope. Just make sure it's *really* clear that you're defining ACM requirements in the same document as you're defining an ACM itself. AB> This was resolved at the WG meeting and will be finalized in the AB> next rev. FYI, I should have mentioned I had to miss both the netconf and netmod meetings because of conflicts with real paid work (which always has to take priority). Sorry if I've mentioned things that were already mentioned there. -- Wes Hardaker SPARTA, Inc. From phil@juniper.net Mon Aug 1 14:16:20 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61851F0C4B for ; Mon, 1 Aug 2011 14:16:20 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9igtvcEcTfp for ; Mon, 1 Aug 2011 14:16:20 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 12C901F0C44 for ; Mon, 1 Aug 2011 14:16:17 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTjcXqFD+8idr+viIa7gypfW4HR0UU+WG@postini.com; Mon, 01 Aug 2011 14:16:27 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 1 Aug 2011 14:15: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 p71LFIv78234; Mon, 1 Aug 2011 14:15:18 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p71KmmB8013805; Mon, 1 Aug 2011 20:48:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201108012048.p71KmmB8013805@idle.juniper.net> To: Andy Bierman In-Reply-To: <4E37157E.80005@andybierman.com> Date: Mon, 1 Aug 2011 16:48:48 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 21:16:20 -0000 Andy Bierman writes: >I think you are confused. Entirely possible. >It is possible for the session doing the abnormal terminating >to be a non-NETCONF session which is identified by the value '0'. That session can't be "identified" by 0 if 0 means "non-netconf". So the question is why emit the field at all? If it's not there, the caller knows it was a non-netconf session. >A server MAY choose to identify all such sessions with the value '0', >or represent all of them with a single ID -- 0. Huh? Thanks, Phil From ietf@andybierman.com Mon Aug 1 14:18:24 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AE021F8C7D for ; Mon, 1 Aug 2011 14:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vscCdpFa9RpC for ; Mon, 1 Aug 2011 14:18:24 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 17D0721F8C74 for ; Mon, 1 Aug 2011 14:18:24 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p71LIUT5031148 for ; Mon, 1 Aug 2011 17:18:30 -0400 Authentication-Results: cm-omr7 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:43724] helo=[192.168.0.146]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 7A/29-15811-528173E4; Mon, 01 Aug 2011 17:18:30 -0400 Message-ID: <4E371822.3050409@andybierman.com> Date: Mon, 01 Aug 2011 14:18:26 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Wes Hardaker References: <4E1DB164.5090007@bwijnen.net> <4E32E057.7030707@bwijnen.net> <4E36D86A.5010903@andybierman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Polk , netconf Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 21:18:24 -0000 On 08/01/2011 02:14 PM, Wes Hardaker wrote: > > AB> The normative text will be moved from the objectives section, > AB> but a separate draft for objectives is already out of scope. > > Just make sure it's *really* clear that you're defining ACM requirements > in the same document as you're defining an ACM itself. > OK -- that is the plan. > AB> This was resolved at the WG meeting and will be finalized in the > AB> next rev. > > FYI, I should have mentioned I had to miss both the netconf and netmod > meetings because of conflicts with real paid work (which always has to > take priority). Sorry if I've mentioned things that were already > mentioned there. Well it would have helped to have a f2f discussion on these issues, even in the hallway. At least you read the draft on one of your flights. Andy From ietf@andybierman.com Tue Aug 2 08:50:14 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B29921F865B for ; Tue, 2 Aug 2011 08:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ptg1-d3BmVm for ; Tue, 2 Aug 2011 08:50:13 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by ietfa.amsl.com (Postfix) with ESMTP id 21B2B21F84BF for ; Tue, 2 Aug 2011 08:50:13 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p72FoHXX017499 for ; Tue, 2 Aug 2011 11:50:21 -0400 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:45017] helo=[192.168.0.146]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id A8/16-20635-9BC183E4; Tue, 02 Aug 2011 11:50:17 -0400 Message-ID: <4E381CB4.4030407@andybierman.com> Date: Tue, 02 Aug 2011 08:50:12 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Phil Shafer References: <201108012048.p71KmmB8013805@idle.juniper.net> In-Reply-To: <201108012048.p71KmmB8013805@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:50:14 -0000 On 08/01/2011 01:48 PM, Phil Shafer wrote: > Andy Bierman writes: >> I think you are confused. > > Entirely possible. > Ditto for me. >> It is possible for the session doing the abnormal terminating >> to be a non-NETCONF session which is identified by the value '0'. > > That session can't be "identified" by 0 if 0 means "non-netconf". > So the question is why emit the field at all? If it's not there, > the caller knows it was a non-netconf session. > From RFC 6022: leaf locked-by-session: If the lock is held by a session that is not managed by the NETCONF server (e.g., a CLI session), a session id of 0 (zero) is reported."; list session { key session-id; description "All NETCONF sessions managed by the NETCONF server MUST be reported in this list."; leaf session-id { type uint32 { range "1..max"; } This is the text that sets the precedent for the notifications draft. According to Martin, a server MAY include non-NETCONF sessions in the session list -- as long as the ID is '1..max'. IMO the text clearly says NETCONF sessions. The only mention in any RFC I can find about NETCONF reported non-NETCONF sessions is from locked-by-session. Perhaps the server has non-NETCONF sessions that have non-zero IDs, and are not reported in this list. Then could be non-zero. Summary of issues here: a) It is possible the session ID does not represent a NETCONF session (consensus: yes?) b) It is possible a non-NETCONF session can be identified to the NETCONF server with the ID value '0' (consensus: yes?) c) It is possible a non-NETCONF session can be identified to the NETCONF server with the ID value in the range '1..max' (consensus: yes?) NEW: leaf killed-by { when "../termination-reason = 'killed' and ."; type nc:session-id-type; description "The ID of the session that directly caused this session to be abnormally terminated. If this session was abnormally terminated by a non-NETCONF session unknown to the server, then this leaf will not be present."; } I think this text conveys the correct session-id semantics. It will not be present if 0, as you requested. IMO, it should be possible to look this session ID up in the list. Clearly, that is not the case with zero (b). Not sure about (c) above either. The data model allows it, but the description-stmts are clearly NETCONF-only. >> A server MAY choose to identify all such sessions with the value '0', >> or represent all of them with a single ID -- 0. > > Huh? > > Thanks, > Phil > > Andy From ietf@andybierman.com Tue Aug 2 11:52:02 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC4221F85EE for ; Tue, 2 Aug 2011 11:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-RjDURLY4hN for ; Tue, 2 Aug 2011 11:52:01 -0700 (PDT) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by ietfa.amsl.com (Postfix) with ESMTP id AA74B21F85EC for ; Tue, 2 Aug 2011 11:52:01 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p72Iq946014430 for ; Tue, 2 Aug 2011 14:52:11 -0400 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:50686] helo=[192.168.0.146]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id BD/8B-29950-857483E4; Tue, 02 Aug 2011 14:52:08 -0400 Message-ID: <4E384753.70604@andybierman.com> Date: Tue, 02 Aug 2011 11:52:03 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Phil Shafer References: <201108012048.p71KmmB8013805@idle.juniper.net> <4E381CB4.4030407@andybierman.com> In-Reply-To: <4E381CB4.4030407@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 18:52:02 -0000 On 08/02/2011 08:50 AM, Andy Bierman wrote: > On 08/01/2011 01:48 PM, Phil Shafer wrote: >> Andy Bierman writes: >>> I think you are confused. >> >> Entirely possible. >> > > Ditto for me. > I have not heard any response, so I will go with the last iteration of . The session-id description-stmt will also be changed: NEW: leaf session-id { description "Identifier of the session. A NETCONF session MUST be identified by a non-zero value. A non-NETCONF session MAY be identified by the value zero."; type nc:session-id-or-zero-type; mandatory true; } Andy From kwatsen@juniper.net Wed Aug 3 09:47:53 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE8221F86D6 for ; Wed, 3 Aug 2011 09:47:53 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb2poR50k5DP for ; Wed, 3 Aug 2011 09:47:52 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 89B3A21F8548 for ; Wed, 3 Aug 2011 09:47:52 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTjl7wakPtAdAT5PqtQoKFdipX82wG7m0@postini.com; Wed, 03 Aug 2011 09:48:05 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 3 Aug 2011 07:55:51 -0700 From: Kent Watsen To: "Bert (IETF) Wijnen" , netconf Date: Wed, 3 Aug 2011 07:55:48 -0700 Thread-Topic: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt Thread-Index: AcxODPeXulcqbXuwS8eYx9bauJdjBQD1SsDg Message-ID: <84600D05C20FF943918238042D7670FD3E871944E2@EMBX01-HQ.jnpr.net> References: <4E1DB164.5090007@bwijnen.net> <4E32E057.7030707@bwijnen.net> In-Reply-To: <4E32E057.7030707@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:47:53 -0000 > Pls review BEFORE or BY August 1 if you have not already done so. > A "I read it and see no issues or have no concerns" is also very welcome! I continue to struggle with why this is an important problem to solve (see = http://www.ietf.org/mail-archive/web/netconf/current/msg06962.html). First off, from an implementation perspective, I feel that this I-D would o= nly be implemented for green-field developments. Having a common access-mo= del for those systems would be nice indeed, but I don't imagine any existin= g Juniper or similar gear ever supporting it. This means it has little imp= act for a multi-vendor NMS, which is my focus. Keep in mind that this data= -model is different than others that we might talk about in that it's not j= ust an abstraction, it goes to the core of how the device works. Presumabl= y this I-D only impacts the NetConf interface, but vendors will likely not = see it that way after needing to pass a Common Criteria certification. Next I question the utility of the I-D. IMO, the purpose for common data-m= odels is so an off-box tool (NMS) can interoperate with many devices. As I= wrote before (see above link), this typically results in the NMS logging i= nto *all* the devices with root-like permissions and then itself presenting= its own RBAC model to its users. With this in mind, it seems that this I-= D only impacts tools that talk to one device at a time, such that when it i= s interacting with the device, it can use the device-provided NACM model to= restrict access to stuff in its UI. This use-case is weak as it seems cus= tomers would more likely use a device's native management interfaces (Web, = CLI, etc.) I understand that this I-D is chartered work and my comments aren't very he= lpful towards reaching that goal, but I can't support this I-D in its curre= nt form either knowing that it won't be picked up by Juniper. Thanks, Kent From bertietf@bwijnen.net Wed Aug 3 10:31:30 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A71F21F8AAA for ; Wed, 3 Aug 2011 10:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf+69ETYi-5i for ; Wed, 3 Aug 2011 10:31:30 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA2721F8A7E for ; Wed, 3 Aug 2011 10:31:28 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QofI8-0003f0-8h; Wed, 03 Aug 2011 19:31:38 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QofI8-0007Uu-3V; Wed, 03 Aug 2011 19:31:36 +0200 Message-ID: <4E3985F7.4030404@bwijnen.net> Date: Wed, 03 Aug 2011 19:31:35 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Kent Watsen References: <4E1DB164.5090007@bwijnen.net> <4E32E057.7030707@bwijnen.net> <84600D05C20FF943918238042D7670FD3E871944E2@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E871944E2@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd47f010535fc39ce4f9f5995e0211d0649 Cc: netconf Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:31:30 -0000 On 8/3/11 4:55 PM, Kent Watsen wrote: > Next I question the utility of the I-D. IMO, the purpose for common data-models is so an off-box tool (NMS) can interoperate with many devices. As I wrote before (see above link), this typically results in the NMS logging into*all* the devices with root-like permissions and then itself presenting its own RBAC model to its users. With this in mind, it seems that this I-D only impacts tools that talk to one device at a time, such that when it is interacting with the device, it can use the device-provided NACM model to restrict access to stuff in its UI. This use-case is weak as it seems customers would more likely use a device's native management interfaces (Web, CLI, etc.) > > I understand that this I-D is chartered work and my comments aren't very helpful towards reaching that goal, but I can't support this I-D in its current form either knowing that it won't be picked up by Juniper. Thanks for repeating (and explaining) your statement that you made earlier (as pointed to by your email) as well. On that earlier note, nobody picked up on that, so my personal conclusion there is that nobody had similar strong feelings. At the same time, I guess I can conclude that not many people really object too strongly either. The latter could be for several reasons: - they did not see the need to express objection (to your note) because they figured the support FOR doing this work was/is much bigger than the objections AGAINST this work. - they do not strongly object and will let the market decide once the standard has been approved. - they certainly do not agree strongly, because if they oppose this work, then they SHOULD have made objections at the time we asked if the WG wants to be chartered or not. Personally, I can see the Juniper approach that you describe. And for controlling user access to the configurations, I think it makes sense. Nonetheless, you want some access control at every box to make sure that people with sll sorts of client NETCONF tools do not accidentally access your box. I also wonder how your/a multi-vendor NMS then deals with getting access to all boxes of different vendors? Are you going to qwork with all their proprietary access control mechanisms? Or would you rather prefer one single standard access control mechanism? I would prefer a standard. And if I have a multi-vendor NMS station that controls end-user access through the UI as you suggest, then I will put very strict access control on my managed devices. I will use the standardized NACM for that. And at the same time, we allow for people who do not use these fancy (possibly expensive) multi-vendor NMSes to still do their own thing. The above was my personal opinion. The below is my view as co-chair of the WG: So, unless other people strongly support your view, we will mark your comments as one viewpoint that has been expressed, and we will (as a WG) continue to work towards finalizing this WG work item. Bert From ietf@andybierman.com Wed Aug 3 11:33:36 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB9211E807B for ; Wed, 3 Aug 2011 11:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfIemEFZ+LzB for ; Wed, 3 Aug 2011 11:33:35 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCF011E8078 for ; Wed, 3 Aug 2011 11:33:34 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p73IXi8g009847 for ; Wed, 3 Aug 2011 14:33:46 -0400 Authentication-Results: cm-omr5 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [70.0.72.187] ([70.0.72.187:58304] helo=[70.0.72.187]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id BC/2C-04676-684993E4; Wed, 03 Aug 2011 14:33:44 -0400 To: "=?utf-8?B?QmVydCAoSUVURikgV2lqbmVu?=" , "=?utf-8?B?S2VudCBXYXRzZW4=?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 03 Aug 2011 11:33:57 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1312396437084" Cc: netconf Subject: Re: [Netconf] =?utf-8?q?Reminder=3A_WG_Last_Call_for=09draft-ietf-net?= =?utf-8?q?conf-access-control-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:33:36 -0000 ------=_Part_0_1312396437084 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBkbyBub3QgYWdyZWUgdGhhdCBjdXN0b21lcnMgZXhwZWN0IGEgcHJvcHJpZXRhcnkgTk1TIHRv IGJlIHJlc3BvbnNpYmxlIGZvciBhbGwgUkJBQy4gIFNvbWUgb2Ygb3VyIGN1c3RvbWVycyBpbnNp c3QgdGhhdCBkZXZpY2UgaGF2ZSBhIGNvbmZpZ3VyYWJsZSBSQkFDIHN5c3RlbS4gIAoKT3VyIG5l dGNvbmYgdmVuZG9yIGlzIHBsYW5uaW5nIHRvIGltcGxlbWVudCB0aGlzIGRhdGEgbW9kZWwgYW5k IHdlIHBsYW4gdG8gZGVwbG95IGl0LgoKQW5keQoKCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0K RnJvbTogIkJlcnQgKElFVEYpIFdpam5lbiIgPGJlcnRpZXRmQGJ3aWpuZW4ubmV0PgpEYXRlOiBX ZWQsIEF1ZyAzLCAyMDExIDEwOjMxClN1YmplY3Q6IFtOZXRjb25mXSBSZW1pbmRlcjogV0cgTGFz dCBDYWxsIGZvcglkcmFmdC1pZXRmLW5ldGNvbmYtYWNjZXNzLWNvbnRyb2wtMDQudHh0ClRvOiAi S2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0PgpDYzogIm5ldGNvbmYiIDxuZXRjb25m QGlldGYub3JnPgoKCk9uIDgvMy8xMSA0OjU1IFBNLCBLZW50IFdhdHNlbiB3cm90ZToKPiBOZXh0 IEkgcXVlc3Rpb24gdGhlIHV0aWxpdHkgb2YgdGhlIEktRC4gIElNTywgdGhlIHB1cnBvc2UgZm9y IGNvbW1vbiBkYXRhLW1vZGVscyBpcyBzbyBhbiBvZmYtYm94IHRvb2wgKE5NUykgY2FuIGludGVy b3BlcmF0ZSB3aXRoIG1hbnkgZGV2aWNlcy4gIEFzIEkgd3JvdGUgYmVmb3JlIChzZWUgYWJvdmUg bGluayksIHRoaXMgdHlwaWNhbGx5IHJlc3VsdHMgaW4gdGhlIE5NUyBsb2dnaW5nIGludG8qYWxs KiAgdGhlIGRldmljZXMgd2l0aCByb290LWxpa2UgcGVybWlzc2lvbnMgYW5kIHRoZW4gaXRzZWxm IHByZXNlbnRpbmcgaXRzIG93biBSQkFDIG1vZGVsIHRvIGl0cyB1c2Vycy4gIFdpdGggdGhpcyBp biBtaW5kLCBpdCBzZWVtcyB0aGF0IHRoaXMgSS1EIG9ubHkgaW1wYWN0cyB0b29scyB0aGF0IHRh bGsgdG8gb25lIGRldmljZSBhdCBhIHRpbWUsIHN1Y2ggdGhhdCB3aGVuIGl0IGlzIGludGVyYWN0 aW5nIHdpdGggdGhlIGRldmljZSwgaXQgY2FuIHVzZSB0aGUgZGV2aWNlLXByb3ZpZGVkIE5BQ00g bW9kZWwgdG8gcmVzdHJpY3QgYWNjZXNzIHRvIHN0dWZmIGluIGl0cyBVSS4gIFRoaXMgdXNlLWNh c2UgaXMgd2VhayBhcyBpdCBzZWVtcyBjdXN0b21lcnMgd291bGQgbW9yZSBsaWtlbHkgdXNlIGEg ZGV2aWNlJ3MgbmF0aXZlIG1hbmFnZW1lbnQgaW50ZXJmYWNlcyAoV2ViLCBDTEksIGV0Yy4pCj4K PiBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIEktRCBpcyBjaGFydGVyZWQgd29yayBhbmQgbXkgY29t bWVudHMgYXJlbid0IHZlcnkgaGVscGZ1bCB0b3dhcmRzIHJlYWNoaW5nIHRoYXQgZ29hbCwgYnV0 IEkgY2FuJ3Qgc3VwcG9ydCB0aGlzIEktRCBpbiBpdHMgY3VycmVudCBmb3JtIGVpdGhlciBrbm93 aW5nIHRoYXQgaXQgd29uJ3QgYmUgcGlja2VkIHVwIGJ5IEp1bmlwZXIuCgpUaGFua3MgZm9yIHJl cGVhdGluZyAoYW5kIGV4cGxhaW5pbmcpIHlvdXIgc3RhdGVtZW50IHRoYXQgeW91IG1hZGUgZWFy bGllciAoYXMgcG9pbnRlZCB0bwpieSB5b3VyIGVtYWlsKSBhcyB3ZWxsLiBPbiB0aGF0IGVhcmxp ZXIgbm90ZSwgbm9ib2R5IHBpY2tlZCB1cCBvbiB0aGF0LCBzbyBteSBwZXJzb25hbApjb25jbHVz aW9uIHRoZXJlIGlzIHRoYXQgbm9ib2R5IGhhZCBzaW1pbGFyIHN0cm9uZyBmZWVsaW5ncy4KQXQg dGhlIHNhbWUgdGltZSwgSSBndWVzcyBJIGNhbiBjb25jbHVkZSB0aGF0IG5vdCBtYW55IHBlb3Bs ZSByZWFsbHkgb2JqZWN0IHRvbwpzdHJvbmdseSBlaXRoZXIuIFRoZSBsYXR0ZXIgY291bGQgYmUg Zm9yIHNldmVyYWwgcmVhc29uczoKLSB0aGV5IGRpZCBub3Qgc2VlIHRoZSBuZWVkIHRvIGV4cHJl c3Mgb2JqZWN0aW9uICh0byB5b3VyIG5vdGUpIGJlY2F1c2UKICB0aGV5IGZpZ3VyZWQgdGhlIHN1 cHBvcnQgRk9SIGRvaW5nIHRoaXMgd29yayB3YXMvaXMgbXVjaCBiaWdnZXIKICB0aGFuIHRoZSBv YmplY3Rpb25zIEFHQUlOU1QgdGhpcyB3b3JrLgotIHRoZXkgZG8gbm90IHN0cm9uZ2x5IG9iamVj dCBhbmQgd2lsbCBsZXQgdGhlIG1hcmtldCBkZWNpZGUgb25jZSB0aGUKICBzdGFuZGFyZCBoYXMg YmVlbiBhcHByb3ZlZC4KLSB0aGV5IGNlcnRhaW5seSBkbyBub3QgYWdyZWUgc3Ryb25nbHksIGJl Y2F1c2UgaWYgdGhleSBvcHBvc2UgdGhpcyB3b3JrLCB0aGVuCiAgdGhleSBTSE9VTEQgaGF2ZSBt YWRlIG9iamVjdGlvbnMgYXQgdGhlIHRpbWUgd2UgYXNrZWQgaWYgdGhlIFdHIHdhbnRzIHRvCiAg YmUgY2hhcnRlcmVkIG9yIG5vdC4KClBlcnNvbmFsbHksIEkgY2FuIHNlZSB0aGUgSnVuaXBlciBh cHByb2FjaCB0aGF0IHlvdSBkZXNjcmliZS4gQW5kIGZvciBjb250cm9sbGluZwp1c2VyIGFjY2Vz cyB0byB0aGUgY29uZmlndXJhdGlvbnMsIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UuIE5vbmV0aGVs ZXNzLCB5b3Ugd2FudApzb21lIGFjY2VzcyBjb250cm9sIGF0IGV2ZXJ5IGJveCB0byBtYWtlIHN1 cmUgdGhhdCBwZW9wbGUgd2l0aCBzbGwgc29ydHMgb2YgY2xpZW50Ck5FVENPTkYgdG9vbHMgZG8g bm90IGFjY2lkZW50YWxseSBhY2Nlc3MgeW91ciBib3guCkkgYWxzbyB3b25kZXIgaG93IHlvdXIv YSBtdWx0aS12ZW5kb3IgTk1TIHRoZW4gZGVhbHMgd2l0aCBnZXR0aW5nIGFjY2VzcyB0byBhbGwK Ym94ZXMgb2YgZGlmZmVyZW50IHZlbmRvcnM/IEFyZSB5b3UgZ29pbmcgdG8gcXdvcmsgd2l0aCBh bGwgdGhlaXIgcHJvcHJpZXRhcnkKYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtcz8gT3Igd291bGQg eW91IHJhdGhlciBwcmVmZXIgb25lIHNpbmdsZSBzdGFuZGFyZCBhY2Nlc3MgY29udHJvbAptZWNo YW5pc20/IEkgd291bGQgcHJlZmVyIGEgc3RhbmRhcmQuCgpBbmQgaWYgSSBoYXZlIGEgbXVsdGkt dmVuZG9yIE5NUyBzdGF0aW9uIHRoYXQgY29udHJvbHMgZW5kLXVzZXIgYWNjZXNzIHRocm91Z2gg dGhlClVJIGFzIHlvdSBzdWdnZXN0LCB0aGVuIEkgd2lsbCBwdXQgdmVyeSBzdHJpY3QgYWNjZXNz IGNvbnRyb2wgb24gbXkgbWFuYWdlZCBkZXZpY2VzLgpJIHdpbGwgdXNlIHRoZSBzdGFuZGFyZGl6 ZWQgTkFDTSBmb3IgdGhhdC4gQW5kIGF0IHRoZSBzYW1lIHRpbWUsIHdlIGFsbG93IGZvcgpwZW9w bGUgd2hvIGRvIG5vdCB1c2UgdGhlc2UgZmFuY3kgKHBvc3NpYmx5IGV4cGVuc2l2ZSkgbXVsdGkt dmVuZG9yIE5NU2VzIHRvCnN0aWxsIGRvIHRoZWlyIG93biB0aGluZy4KClRoZSBhYm92ZSB3YXMg bXkgcGVyc29uYWwgb3Bpbmlvbi4KVGhlIGJlbG93IGlzIG15IHZpZXcgYXMgY28tY2hhaXIgb2Yg dGhlIFdHOgoKU28sIHVubGVzcyBvdGhlciBwZW9wbGUgc3Ryb25nbHkgc3VwcG9ydCB5b3VyIHZp ZXcsIHdlIHdpbGwgbWFyayB5b3VyIGNvbW1lbnRzCmFzIG9uZSB2aWV3cG9pbnQgdGhhdCBoYXMg YmVlbiBleHByZXNzZWQsIGFuZCB3ZSB3aWxsIChhcyBhIFdHKSBjb250aW51ZQp0byB3b3JrIHRv d2FyZHMgZmluYWxpemluZyB0aGlzIFdHIHdvcmsgaXRlbS4KCkJlcnQKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0 Y29uZkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYKCg== ------=_Part_0_1312396437084 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBkbyBub3QgYWdyZWUgdGhhdCBjdXN0b21lcnMgZXhwZWN0IGEgcHJvcHJpZXRhcnkgTk1TIHRv IGJlIHJlc3BvbnNpYmxlIGZvciBhbGwgUkJBQy4gJm5ic3A7U29tZSBvZiBvdXIgY3VzdG9tZXJz IGluc2lzdCB0aGF0IGRldmljZSBoYXZlIGEgY29uZmlndXJhYmxlIFJCQUMgc3lzdGVtLiAmbmJz cDs8YnI+PGJyPk91ciBuZXRjb25mIHZlbmRvciBpcyBwbGFubmluZyB0byBpbXBsZW1lbnQgdGhp cyBkYXRhIG1vZGVsIGFuZCB3ZSBwbGFuIHRvIGRlcGxveSBpdC48YnI+PGJyPkFuZHk8YnI+PGJy Pjxicj4tLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tPGJyPkZyb206ICZxdW90O0JlcnQgKElFVEYp IFdpam5lbiZxdW90OyAmbHQ7YmVydGlldGZAYndpam5lbi5uZXQmZ3Q7PGJyPkRhdGU6IFdlZCwg QXVnIDMsIDIwMTEgMTA6MzE8YnI+U3ViamVjdDogW05ldGNvbmZdIFJlbWluZGVyOiBXRyBMYXN0 IENhbGwgZm9yCWRyYWZ0LWlldGYtbmV0Y29uZi1hY2Nlc3MtY29udHJvbC0wNC50eHQ8YnI+VG86 ICZxdW90O0tlbnQgV2F0c2VuJnF1b3Q7ICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0Ozxicj5D YzogJnF1b3Q7bmV0Y29uZiZxdW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+PGJyPjxi cj5PbiA4LzMvMTEgNDo1NSBQTSwgS2VudCBXYXRzZW4gd3JvdGU6PGJyPiZndDsgTmV4dCBJIHF1 ZXN0aW9uIHRoZSB1dGlsaXR5IG9mIHRoZSBJLUQuICZuYnNwO0lNTywgdGhlIHB1cnBvc2UgZm9y IGNvbW1vbiBkYXRhLW1vZGVscyBpcyBzbyBhbiBvZmYtYm94IHRvb2wgKE5NUykgY2FuIGludGVy b3BlcmF0ZSB3aXRoIG1hbnkgZGV2aWNlcy4gJm5ic3A7QXMgSSB3cm90ZSBiZWZvcmUgKHNlZSBh Ym92ZSBsaW5rKSwgdGhpcyB0eXBpY2FsbHkgcmVzdWx0cyBpbiB0aGUgTk1TIGxvZ2dpbmcgaW50 byphbGwqICZuYnNwO3RoZSBkZXZpY2VzIHdpdGggcm9vdC1saWtlIHBlcm1pc3Npb25zIGFuZCB0 aGVuIGl0c2VsZiBwcmVzZW50aW5nIGl0cyBvd24gUkJBQyBtb2RlbCB0byBpdHMgdXNlcnMuICZu YnNwO1dpdGggdGhpcyBpbiBtaW5kLCBpdCBzZWVtcyB0aGF0IHRoaXMgSS1EIG9ubHkgaW1wYWN0 cyB0b29scyB0aGF0IHRhbGsgdG8gb25lIGRldmljZSBhdCBhIHRpbWUsIHN1Y2ggdGhhdCB3aGVu IGl0IGlzIGludGVyYWN0aW5nIHdpdGggdGhlIGRldmljZSwgaXQgY2FuIHVzZSB0aGUgZGV2aWNl LXByb3ZpZGVkIE5BQ00gbW9kZWwgdG8gcmVzdHJpY3QgYWNjZXNzIHRvIHN0dWZmIGluIGl0cyBV SS4gJm5ic3A7VGhpcyB1c2UtY2FzZSBpcyB3ZWFrIGFzIGl0IHNlZW1zIGN1c3RvbWVycyB3b3Vs ZCBtb3JlIGxpa2VseSB1c2UgYSBkZXZpY2UmIzM5O3MgbmF0aXZlIG1hbmFnZW1lbnQgaW50ZXJm YWNlcyAoV2ViLCBDTEksIGV0Yy4pPGJyPiZndDs8YnI+Jmd0OyBJIHVuZGVyc3RhbmQgdGhhdCB0 aGlzIEktRCBpcyBjaGFydGVyZWQgd29yayBhbmQgbXkgY29tbWVudHMgYXJlbiYjMzk7dCB2ZXJ5 IGhlbHBmdWwgdG93YXJkcyByZWFjaGluZyB0aGF0IGdvYWwsIGJ1dCBJIGNhbiYjMzk7dCBzdXBw b3J0IHRoaXMgSS1EIGluIGl0cyBjdXJyZW50IGZvcm0gZWl0aGVyIGtub3dpbmcgdGhhdCBpdCB3 b24mIzM5O3QgYmUgcGlja2VkIHVwIGJ5IEp1bmlwZXIuPGJyPjxicj5UaGFua3MgZm9yIHJlcGVh dGluZyAoYW5kIGV4cGxhaW5pbmcpIHlvdXIgc3RhdGVtZW50IHRoYXQgeW91IG1hZGUgZWFybGll ciAoYXMgcG9pbnRlZCB0bzxicj5ieSB5b3VyIGVtYWlsKSBhcyB3ZWxsLiBPbiB0aGF0IGVhcmxp ZXIgbm90ZSwgbm9ib2R5IHBpY2tlZCB1cCBvbiB0aGF0LCBzbyBteSBwZXJzb25hbDxicj5jb25j bHVzaW9uIHRoZXJlIGlzIHRoYXQgbm9ib2R5IGhhZCBzaW1pbGFyIHN0cm9uZyBmZWVsaW5ncy48 YnI+QXQgdGhlIHNhbWUgdGltZSwgSSBndWVzcyBJIGNhbiBjb25jbHVkZSB0aGF0IG5vdCBtYW55 IHBlb3BsZSByZWFsbHkgb2JqZWN0IHRvbzxicj5zdHJvbmdseSBlaXRoZXIuIFRoZSBsYXR0ZXIg Y291bGQgYmUgZm9yIHNldmVyYWwgcmVhc29uczo8YnI+LSB0aGV5IGRpZCBub3Qgc2VlIHRoZSBu ZWVkIHRvIGV4cHJlc3Mgb2JqZWN0aW9uICh0byB5b3VyIG5vdGUpIGJlY2F1c2U8YnI+ICZuYnNw O3RoZXkgZmlndXJlZCB0aGUgc3VwcG9ydCBGT1IgZG9pbmcgdGhpcyB3b3JrIHdhcy9pcyBtdWNo IGJpZ2dlcjxicj4gJm5ic3A7dGhhbiB0aGUgb2JqZWN0aW9ucyBBR0FJTlNUIHRoaXMgd29yay48 YnI+LSB0aGV5IGRvIG5vdCBzdHJvbmdseSBvYmplY3QgYW5kIHdpbGwgbGV0IHRoZSBtYXJrZXQg ZGVjaWRlIG9uY2UgdGhlPGJyPiAmbmJzcDtzdGFuZGFyZCBoYXMgYmVlbiBhcHByb3ZlZC48YnI+ LSB0aGV5IGNlcnRhaW5seSBkbyBub3QgYWdyZWUgc3Ryb25nbHksIGJlY2F1c2UgaWYgdGhleSBv cHBvc2UgdGhpcyB3b3JrLCB0aGVuPGJyPiAmbmJzcDt0aGV5IFNIT1VMRCBoYXZlIG1hZGUgb2Jq ZWN0aW9ucyBhdCB0aGUgdGltZSB3ZSBhc2tlZCBpZiB0aGUgV0cgd2FudHMgdG88YnI+ICZuYnNw O2JlIGNoYXJ0ZXJlZCBvciBub3QuPGJyPjxicj5QZXJzb25hbGx5LCBJIGNhbiBzZWUgdGhlIEp1 bmlwZXIgYXBwcm9hY2ggdGhhdCB5b3UgZGVzY3JpYmUuIEFuZCBmb3IgY29udHJvbGxpbmc8YnI+ dXNlciBhY2Nlc3MgdG8gdGhlIGNvbmZpZ3VyYXRpb25zLCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNl LiBOb25ldGhlbGVzcywgeW91IHdhbnQ8YnI+c29tZSBhY2Nlc3MgY29udHJvbCBhdCBldmVyeSBi b3ggdG8gbWFrZSBzdXJlIHRoYXQgcGVvcGxlIHdpdGggc2xsIHNvcnRzIG9mIGNsaWVudDxicj5O RVRDT05GIHRvb2xzIGRvIG5vdCBhY2NpZGVudGFsbHkgYWNjZXNzIHlvdXIgYm94Ljxicj5JIGFs c28gd29uZGVyIGhvdyB5b3VyL2EgbXVsdGktdmVuZG9yIE5NUyB0aGVuIGRlYWxzIHdpdGggZ2V0 dGluZyBhY2Nlc3MgdG8gYWxsPGJyPmJveGVzIG9mIGRpZmZlcmVudCB2ZW5kb3JzPyBBcmUgeW91 IGdvaW5nIHRvIHF3b3JrIHdpdGggYWxsIHRoZWlyIHByb3ByaWV0YXJ5PGJyPmFjY2VzcyBjb250 cm9sIG1lY2hhbmlzbXM/IE9yIHdvdWxkIHlvdSByYXRoZXIgcHJlZmVyIG9uZSBzaW5nbGUgc3Rh bmRhcmQgYWNjZXNzIGNvbnRyb2w8YnI+bWVjaGFuaXNtPyBJIHdvdWxkIHByZWZlciBhIHN0YW5k YXJkLjxicj48YnI+QW5kIGlmIEkgaGF2ZSBhIG11bHRpLXZlbmRvciBOTVMgc3RhdGlvbiB0aGF0 IGNvbnRyb2xzIGVuZC11c2VyIGFjY2VzcyB0aHJvdWdoIHRoZTxicj5VSSBhcyB5b3Ugc3VnZ2Vz dCwgdGhlbiBJIHdpbGwgcHV0IHZlcnkgc3RyaWN0IGFjY2VzcyBjb250cm9sIG9uIG15IG1hbmFn ZWQgZGV2aWNlcy48YnI+SSB3aWxsIHVzZSB0aGUgc3RhbmRhcmRpemVkIE5BQ00gZm9yIHRoYXQu IEFuZCBhdCB0aGUgc2FtZSB0aW1lLCB3ZSBhbGxvdyBmb3I8YnI+cGVvcGxlIHdobyBkbyBub3Qg dXNlIHRoZXNlIGZhbmN5IChwb3NzaWJseSBleHBlbnNpdmUpIG11bHRpLXZlbmRvciBOTVNlcyB0 bzxicj5zdGlsbCBkbyB0aGVpciBvd24gdGhpbmcuPGJyPjxicj5UaGUgYWJvdmUgd2FzIG15IHBl cnNvbmFsIG9waW5pb24uPGJyPlRoZSBiZWxvdyBpcyBteSB2aWV3IGFzIGNvLWNoYWlyIG9mIHRo ZSBXRzo8YnI+PGJyPlNvLCB1bmxlc3Mgb3RoZXIgcGVvcGxlIHN0cm9uZ2x5IHN1cHBvcnQgeW91 ciB2aWV3LCB3ZSB3aWxsIG1hcmsgeW91ciBjb21tZW50czxicj5hcyBvbmUgdmlld3BvaW50IHRo YXQgaGFzIGJlZW4gZXhwcmVzc2VkLCBhbmQgd2Ugd2lsbCAoYXMgYSBXRykgY29udGludWU8YnI+ dG8gd29yayB0b3dhcmRzIGZpbmFsaXppbmcgdGhpcyBXRyB3b3JrIGl0ZW0uPGJyPjxicj5CZXJ0 PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPk5l dGNvbmYgbWFpbGluZyBsaXN0PGJyPk5ldGNvbmZAaWV0Zi5vcmc8YnI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PGJyPjxicj48YnI+PGJyPg== ------=_Part_0_1312396437084-- From randy_presuhn@mindspring.com Wed Aug 3 12:17:08 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B5B21F889F for ; Wed, 3 Aug 2011 12:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezlu3za7piJ5 for ; Wed, 3 Aug 2011 12:17:08 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 690CD21F885A for ; Wed, 3 Aug 2011 12:17:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OeU5YXv/pB2M0x49wbTmISEc3VLJKqHljAMp+zfClKEoeBos+XexXGdXqFScV72K; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.55.172.135] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QogwQ-0001fa-JI for netconf@ietf.org; Wed, 03 Aug 2011 15:17:18 -0400 Message-ID: <00d801cc5212$ceb8ac80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "netconf" References: Date: Wed, 3 Aug 2011 12:23:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee2886338e10829fa0efae55c309f0ae0d556350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.172.135 Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:17:09 -0000 Hi - > From: "Andy Bierman" > To: "Bert (IETF) Wijnen" ; "Kent Watsen" > Cc: "netconf" > Sent: Wednesday, August 03, 2011 11:33 AM > Subject: Re: [Netconf]Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt > > I do not agree that customers expect a proprietary NMS to be responsible > for all RBAC. Some of our customers insist that device have a configurable > RBAC system. ... In further support of what Andy wrote - Giving responsibility the access decision function to the NMS seems seriously at odds with the principle of least privilege. Randy From kwatsen@juniper.net Wed Aug 3 14:25:28 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB97011E80B4 for ; Wed, 3 Aug 2011 14:25:28 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5hgPCHYOGo3 for ; Wed, 3 Aug 2011 14:25:28 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1FC11E807C for ; Wed, 3 Aug 2011 14:25:28 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTjm81PlNoe5xF/vxBeQNoKCbdBxa1Xhv@postini.com; Wed, 03 Aug 2011 14:25:41 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 3 Aug 2011 14:23:21 -0700 From: Kent Watsen To: netconf Date: Wed, 3 Aug 2011 14:23:19 -0700 Thread-Topic: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt Thread-Index: AcxSEf8ahQSF994yTv+qP1l55UxFwAABhd6Q Message-ID: <84600D05C20FF943918238042D7670FD3E871949CD@EMBX01-HQ.jnpr.net> References: <00d801cc5212$ceb8ac80$6801a8c0@oemcomputer> In-Reply-To: <00d801cc5212$ceb8ac80$6801a8c0@oemcomputer> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:25:29 -0000 Bert, To your WG co-chair comment, that is how I had hoped it would be interpre= ted, thanks. Andy, Both NMS and devices must have RBAC systems, at least so long as they're = Common Criteria certified. Our NSM has been able to provide path-based acc= ess to configuration for a long time now. It's necessary for it to do this= because it also supports the concept of live configuration templates that = are applied to many devices at once. Further, the NMS supports high-level = abstractions that have to be compiled down to device-specific data models, = again emphasizing the need for the NMS to implement the RBAC. I never said= devices shouldn't have configurable RBAC systems, only that their RBAC is = not configured much in an NMS environment. Again, I think this I-D may be = helpful for new device development efforts, and even for a device-specific = EMS, but once you get to the NMS-level, it doesn't matter much anymore sinc= e the abstractions negate the need for device-specific interactions. Randy, It is still with the concept with least privilege. I wrote that the NMS = "typically" has root-like access because sometimes a customer can provide a= restricted account instead (e.g. for PCI DSS compliance), and we support t= hat case too, but this is exceedingly rare since the reason most customers = installed the NMS in the first place was to manage the *entire* device, whi= ch requires the root-like access. One interesting data point to this discu= ssion would be to know what the operator-specific systems are doing - that = is, are their systems also typically logging into devices with a root-like = account or not... Thanks, Kent From ietf@andybierman.com Wed Aug 3 18:04:11 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE8721F883A for ; Wed, 3 Aug 2011 18:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIH2jIbl2jpI for ; Wed, 3 Aug 2011 18:04:10 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id A1EE621F8834 for ; Wed, 3 Aug 2011 18:04:10 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p7414L63015807 for ; Wed, 3 Aug 2011 21:04:21 -0400 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:41071] helo=[192.168.0.146]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 90/25-04676-510F93E4; Wed, 03 Aug 2011 21:04:21 -0400 Message-ID: <4E39F014.204@andybierman.com> Date: Wed, 03 Aug 2011 18:04:20 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Kent Watsen References: <00d801cc5212$ceb8ac80$6801a8c0@oemcomputer> <84600D05C20FF943918238042D7670FD3E871949CD@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E871949CD@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 01:04:11 -0000 On 08/03/2011 02:23 PM, Kent Watsen wrote: > Bert, > > To your WG co-chair comment, that is how I had hoped it would be interpreted, thanks. > > > Andy, > > Both NMS and devices must have RBAC systems, at least so long as they're Common Criteria certified. Our NSM has been able to provide path-based access to configuration for a long time now. It's > necessary for it to do this because it also supports the concept of live configuration templates that are applied to many devices at once. Further, the NMS supports high-level abstractions that > have to be compiled down to device-specific data models, again emphasizing the need for the NMS to implement the RBAC. I never said devices shouldn't have configurable RBAC systems, only that > their RBAC is not configured much in an NMS environment. Again, I think this I-D may be helpful for new device development efforts, and even for a device-specific EMS, but once you get to the > NMS-level, it doesn't matter much anymore since the abstractions negate the need for device-specific interactions. > > Some people want a standard RBAC model in the NETCONF server. Perhaps every vendor will continue using their own data models. Perhaps not. We do not standardize NMS applications in the IETF, so that seems out of scope. I don't understand the comment about device-specific data models. The point of a standard data model is to configure access control for a user/session based on the standard abstraction model, i.e., protocol operations, notifications, and YANG datastore content. Andy > Randy, > > It is still with the concept with least privilege. I wrote that the NMS "typically" has root-like access because sometimes a customer can provide a restricted account instead (e.g. for PCI DSS > compliance), and we support that case too, but this is exceedingly rare since the reason most customers installed the NMS in the first place was to manage the *entire* device, which requires the > root-like access. One interesting data point to this discussion would be to know what the operator-specific systems are doing - that is, are their systems also typically logging into devices with > a root-like account or not... > > > Thanks, Kent > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf > > From randy_presuhn@mindspring.com Wed Aug 3 19:48:13 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FA35E800A for ; Wed, 3 Aug 2011 19:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Csvktq4RP3fM for ; Wed, 3 Aug 2011 19:48:12 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 15ECC5E8001 for ; Wed, 3 Aug 2011 19:48:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NzeyN9kmUTkOY6S+cDTUn0DV8Rh6Zi1B3BgImPzeR4IEL33aglLoyPDFOcD5zu9N; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.237.157] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Qonyy-0004fV-Ub for netconf@ietf.org; Wed, 03 Aug 2011 22:48:25 -0400 Message-ID: <001c01cc5251$d35cba80$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "netconf" References: <00d801cc5212$ceb8ac80$6801a8c0@oemcomputer> <84600D05C20FF943918238042D7670FD3E871949CD@EMBX01-HQ.jnpr.net> Date: Wed, 3 Aug 2011 19:54:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8887f779e183b2ee2882bb5d5dc6ec329a5d74b894f521068ee350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.237.157 Subject: Re: [Netconf] Reminder: WG LastCall for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 02:48:13 -0000 Hi - > From: "Kent Watsen" > To: "netconf" > Sent: Wednesday, August 03, 2011 2:23 PM > Subject: Re: [Netconf] Reminder: WG LastCall for draft-ietf-netconf-access-control-04.txt ... > It is still with the concept with least privilege. I wrote that the NMS > "typically" has root-like access because sometimes a customer > can provide a restricted account instead (e.g. for PCI DSS > compliance), and we support that case too, but this is exceedingly > rare since the reason most customers installed the NMS in the first > place was to manage the *entire* device, which requires the root-like > access. As soon as there is more than one NMS, or aspects of the device are of interest to more than one administrative domain, the argument that putting the access decision function in the NMS would somehow be consistent with the principle of least privilege does not hold. Randy From bertietf@bwijnen.net Thu Aug 4 00:10:55 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E210F11E80AA for ; Thu, 4 Aug 2011 00:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkVxICNPMbeE for ; Thu, 4 Aug 2011 00:10:55 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 062ED21F8A7E for ; Thu, 4 Aug 2011 00:10:53 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qos57-0003Lf-NT for netconf@ietf.org; Thu, 04 Aug 2011 09:11:03 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qos57-0006Fm-IU for netconf@ietf.org; Thu, 04 Aug 2011 09:11:01 +0200 Message-ID: <4E3A4605.2030009@bwijnen.net> Date: Thu, 04 Aug 2011 09:11:01 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf References: <4E1DB164.5090007@bwijnen.net> <4E32E057.7030707@bwijnen.net> In-Reply-To: <4E32E057.7030707@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a360e959f23dc8de74994a0e0072adb9 Subject: Re: [Netconf] Reminder: WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 07:10:56 -0000 We did not get any requests for extension of the WGLC end date. So WGLC has ended for this document. The authors will address all comments with a new revision. Bert and Mehmet On 7/29/11 6:31 PM, Bert (IETF) Wijnen wrote: > WG participants, > > Pls review BEFORE or BY August 1 if you have not already done so. > A "I read it and see no issues or have no concerns" is also very welcome! > > I case you need a couple of days extra time (and commit a date for > your review), we're willing to consider a short extension. > > Bert and Mehmet > > -------- Original Message -------- > Subject: [Netconf] WG Last Call for draft-ietf-netconf-access-control-04.txt > Date: Wed, 13 Jul 2011 16:53:24 +0200 > From: Bert (IETF) Wijnen > To: netconf > > > > Dear WG participants, > > This document was published mid-June, and we have not had much comments > sofar. So we conclude it must be ready for WG Last Call. > > This is a formal WG Last call for draft-ietf-netconf-access-control-04.txt > Please review and send any comments BEFORE August 1. > Best would be if you can send it BEFORE July 24, so that we can discuss > any open issues during our Netconf session at IETF81 in Quebec. > > Bert and Mehmet > > From bertietf@bwijnen.net Thu Aug 4 00:11:37 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C6711E80AA for ; Thu, 4 Aug 2011 00:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKJWbjBvvF+B for ; Thu, 4 Aug 2011 00:11:34 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 5288921F8A7A for ; Thu, 4 Aug 2011 00:11:33 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Qos5o-0001qj-Jd for netconf@ietf.org; Thu, 04 Aug 2011 09:11:46 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Qos5o-0006Hp-Ec for netconf@ietf.org; Thu, 04 Aug 2011 09:11:44 +0200 Message-ID: <4E3A4630.3010902@bwijnen.net> Date: Thu, 04 Aug 2011 09:11:44 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf References: <4E1DB161.2060707@bwijnen.net> <4E32E026.5000305@bwijnen.net> In-Reply-To: <4E32E026.5000305@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd48599239bf6393340553cb26c31a38dff Subject: [Netconf] Finished WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 07:11:37 -0000 We did not get any requests for extension of the WGLC end date. So WGLC has ended for this document. The authors will address all comments with a new revision. Bert and Mehmet On 7/29/11 6:30 PM, Bert (IETF) Wijnen wrote: > WG participants, > > Pls review BEFORE or BY August 1 if you have not already done so. > A "I read it and see no issues or have no concerns" is also very welcome! > > I case you need a couple of days extra time (and commit a date for > your review), we're willing to consider a short extension. > > Bert and Mehmet > -------- Original Message -------- > Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt > Date: Wed, 13 Jul 2011 16:53:21 +0200 > From: Bert (IETF) Wijnen > To: netconf > > > > Dear WG participants, > > This document was published mid-June, and we have not had much comments > sofar. So we conclude it must be ready for WG Last Call. > > This is a formal WG Last call for draft-ietf-netconf-system-notifications-04.txt > Please review and send any comments BEFORE August 1. > Best would be if you can send it BEFORE July 24, so that we can discuss > any open issues during our Netconf session at IETF81 in Quebec. > > Bert and Mehmet > _______________________________________________ > 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 bertietf@bwijnen.net Thu Aug 4 00:16:29 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F11311E8089 for ; Thu, 4 Aug 2011 00:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oJspLeL-VrB for ; Thu, 4 Aug 2011 00:16:28 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 312A221F8B63 for ; Thu, 4 Aug 2011 00:16:28 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QosAa-0003SX-25 for netconf@ietf.org; Thu, 04 Aug 2011 09:16:41 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QosAZ-0006aw-MX for netconf@ietf.org; Thu, 04 Aug 2011 09:16:40 +0200 Message-ID: <4E3A4757.3000601@bwijnen.net> Date: Thu, 04 Aug 2011 09:16:39 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: netconf References: <4E1DB164.5090007@bwijnen.net> <4E32E057.7030707@bwijnen.net> <4E3A4605.2030009@bwijnen.net> In-Reply-To: <4E3A4605.2030009@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4344abe7805509dcaf80565b7f4a1eeab Subject: [Netconf] Finished WG Last Call for draft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 07:16:29 -0000 My quick evaluation as co-chair: - quite a set of good comments/concerns from various reviewers will be addressed by editors/authors in a new revision - we got a commitment from our Securoty Advisor (Tim Polk) that he will review as well and give us feedback. If he is timely, then authors will address his comments in new revision. If not, then he will review the next revision - The comments from Kent Watson ("abandon this I-D and this work, it is not needed") was already brought up when we started/chartered the work. Nobody seems to have picked up on that and so Kent seems to be the lonely dissenter in this case. So I consider this matter closed and I read WG consensus that the WG DOES want to finish and standardize this work. Bert (speaking as co-chair) On 8/4/11 9:11 AM, Bert (IETF) Wijnen wrote: > We did not get any requests for extension of the WGLC end date. > So WGLC has ended for this document. > > The authors will address all comments with a new revision. > > Bert and Mehmet > > On 7/29/11 6:31 PM, Bert (IETF) Wijnen wrote: >> WG participants, >> >> Pls review BEFORE or BY August 1 if you have not already done so. >> A "I read it and see no issues or have no concerns" is also very welcome! >> >> I case you need a couple of days extra time (and commit a date for >> your review), we're willing to consider a short extension. >> >> Bert and Mehmet >> >> -------- Original Message -------- >> Subject: [Netconf] WG Last Call for draft-ietf-netconf-access-control-04.txt >> Date: Wed, 13 Jul 2011 16:53:24 +0200 >> From: Bert (IETF) Wijnen >> To: netconf >> >> >> >> Dear WG participants, >> >> This document was published mid-June, and we have not had much comments >> sofar. So we conclude it must be ready for WG Last Call. >> >> This is a formal WG Last call for draft-ietf-netconf-access-control-04.txt >> Please review and send any comments BEFORE August 1. >> Best would be if you can send it BEFORE July 24, so that we can discuss >> any open issues during our Netconf session at IETF81 in Quebec. >> >> Bert and Mehmet From mehmet.ersue@nsn.com Thu Aug 4 08:50:53 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB4521F8B47 for ; Thu, 4 Aug 2011 08:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.875 X-Spam-Level: X-Spam-Status: No, score=-105.875 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk0msw9ZpRqc for ; Thu, 4 Aug 2011 08:50:53 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CDC5121F8B36 for ; Thu, 4 Aug 2011 08:50:52 -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 p74Fp6Z8001159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2011 17:51:06 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p74Fp3AW006457; Thu, 4 Aug 2011 17:51:06 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Aug 2011 17:50:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2011 17:50:53 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6402752B18@DEMUEXC006.nsn-intra.net> In-Reply-To: <4E3A4757.3000601@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Finished WG Last Call fordraft-ietf-netconf-access-control-04.txt thread-index: AcxSdnlfY9gD1GpOQvCAWAuEp1F36gAR6CuA References: <4E1DB164.5090007@bwijnen.net> <4E32E057.7030707@bwijnen.net><4E3A4605.2030009@bwijnen.net> <4E3A4757.3000601@bwijnen.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 04 Aug 2011 15:50:54.0447 (UTC) FILETIME=[4B1EB7F0:01CC52BE] Subject: Re: [Netconf] Finished WG Last Call fordraft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:50:53 -0000 > - The comments from Kent Watson ("abandon this I-D and this work, it is > not needed") was already brought up when we started/chartered the work. > Nobody seems to have picked up on that and so Kent seems to be the > lonely dissenter in this case. So I consider this matter closed > and I read WG consensus that the WG DOES want to finish and standardize > this work. This is also my understanding. Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of > ext Bert (IETF) Wijnen > Sent: Thursday, August 04, 2011 9:17 AM > To: netconf > Subject: [Netconf] Finished WG Last Call fordraft-ietf-netconf-access- > control-04.txt >=20 > My quick evaluation as co-chair: >=20 > - quite a set of good comments/concerns from various reviewers > will be addressed by editors/authors in a new revision > - we got a commitment from our Securoty Advisor (Tim Polk) that he will > review > as well and give us feedback. If he is timely, then authors will address > his > comments in new revision. If not, then he will review the next revision > - The comments from Kent Watson ("abandon this I-D and this work, it is > not needed") was already brought up when we started/chartered the work. > Nobody seems to have picked up on that and so Kent seems to be the > lonely dissenter in this case. So I consider this matter closed > and I read WG consensus that the WG DOES want to finish and standardize > this work. >=20 > Bert (speaking as co-chair) >=20 > On 8/4/11 9:11 AM, Bert (IETF) Wijnen wrote: > > We did not get any requests for extension of the WGLC end date. > > So WGLC has ended for this document. > > > > The authors will address all comments with a new revision. > > > > Bert and Mehmet > > > > On 7/29/11 6:31 PM, Bert (IETF) Wijnen wrote: > >> WG participants, > >> > >> Pls review BEFORE or BY August 1 if you have not already done so. > >> A "I read it and see no issues or have no concerns" is also very welcome! > >> > >> I case you need a couple of days extra time (and commit a date for > >> your review), we're willing to consider a short extension. > >> > >> Bert and Mehmet > >> > >> -------- Original Message -------- > >> Subject: [Netconf] WG Last Call for draft-ietf-netconf-access-control- > 04.txt > >> Date: Wed, 13 Jul 2011 16:53:24 +0200 > >> From: Bert (IETF) Wijnen > >> To: netconf > >> > >> > >> > >> Dear WG participants, > >> > >> This document was published mid-June, and we have not had much comments > >> sofar. So we conclude it must be ready for WG Last Call. > >> > >> This is a formal WG Last call for draft-ietf-netconf-access-control-04.txt > >> Please review and send any comments BEFORE August 1. > >> Best would be if you can send it BEFORE July 24, so that we can discuss > >> any open issues during our Netconf session at IETF81 in Quebec. > >> > >> Bert and Mehmet >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From kwatsen@juniper.net Thu Aug 4 10:39:43 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA8011E8081 for ; Thu, 4 Aug 2011 10:39:43 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRZpWj8j9+wN for ; Thu, 4 Aug 2011 10:39:42 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 623EB11E8077 for ; Thu, 4 Aug 2011 10:39:42 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTjrZa7ITWp/Fkd3BMNGcKfexIpnL1Bkv@postini.com; Thu, 04 Aug 2011 10:39:57 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 4 Aug 2011 10:39:04 -0700 From: Kent Watsen To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf Date: Thu, 4 Aug 2011 10:38:59 -0700 Thread-Topic: [Netconf] Finished WG Last Call fordraft-ietf-netconf-access-control-04.txt Thread-Index: AcxSdnlfY9gD1GpOQvCAWAuEp1F36gAR6CuAAAO1DGA= Message-ID: <84600D05C20FF943918238042D7670FD3E87195031@EMBX01-HQ.jnpr.net> References: <4E1DB164.5090007@bwijnen.net> <4E32E057.7030707@bwijnen.net><4E3A4605.2030009@bwijnen.net> <4E3A4757.3000601@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A6402752B18@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6402752B18@DEMUEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Finished WG Last Call fordraft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 17:39:43 -0000 Just to be clear, I didn't say to abandon it. I just said it wasn't an imp= ortant problem to Juniper, which is why I was neither supporting or not-sup= porting it. Same as in the WG meeting in Quebec, I neither raised my hand = in favor or against it... Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Ersue, Mehmet (NSN - DE/Munich) Sent: Thursday, August 04, 2011 11:51 AM To: netconf Subject: Re: [Netconf] Finished WG Last Call fordraft-ietf-netconf-access-c= ontrol-04.txt > - The comments from Kent Watson ("abandon this I-D and this work, it is > not needed") was already brought up when we started/chartered the work. > Nobody seems to have picked up on that and so Kent seems to be the > lonely dissenter in this case. So I consider this matter closed > and I read WG consensus that the WG DOES want to finish and standardize > this work. This is also my understanding. Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of > ext Bert (IETF) Wijnen > Sent: Thursday, August 04, 2011 9:17 AM > To: netconf > Subject: [Netconf] Finished WG Last Call fordraft-ietf-netconf-access- > control-04.txt >=20 > My quick evaluation as co-chair: >=20 > - quite a set of good comments/concerns from various reviewers > will be addressed by editors/authors in a new revision > - we got a commitment from our Securoty Advisor (Tim Polk) that he will > review > as well and give us feedback. If he is timely, then authors will address > his > comments in new revision. If not, then he will review the next revision > - The comments from Kent Watson ("abandon this I-D and this work, it is > not needed") was already brought up when we started/chartered the work. > Nobody seems to have picked up on that and so Kent seems to be the > lonely dissenter in this case. So I consider this matter closed > and I read WG consensus that the WG DOES want to finish and standardize > this work. >=20 > Bert (speaking as co-chair) >=20 > On 8/4/11 9:11 AM, Bert (IETF) Wijnen wrote: > > We did not get any requests for extension of the WGLC end date. > > So WGLC has ended for this document. > > > > The authors will address all comments with a new revision. > > > > Bert and Mehmet > > > > On 7/29/11 6:31 PM, Bert (IETF) Wijnen wrote: > >> WG participants, > >> > >> Pls review BEFORE or BY August 1 if you have not already done so. > >> A "I read it and see no issues or have no concerns" is also very welcome! > >> > >> I case you need a couple of days extra time (and commit a date for > >> your review), we're willing to consider a short extension. > >> > >> Bert and Mehmet > >> > >> -------- Original Message -------- > >> Subject: [Netconf] WG Last Call for draft-ietf-netconf-access-control- > 04.txt > >> Date: Wed, 13 Jul 2011 16:53:24 +0200 > >> From: Bert (IETF) Wijnen > >> To: netconf > >> > >> > >> > >> Dear WG participants, > >> > >> This document was published mid-June, and we have not had much comments > >> sofar. So we conclude it must be ready for WG Last Call. > >> > >> This is a formal WG Last call for draft-ietf-netconf-access-control-04.txt > >> Please review and send any comments BEFORE August 1. > >> Best would be if you can send it BEFORE July 24, so that we can discuss > >> any open issues during our Netconf session at IETF81 in Quebec. > >> > >> Bert and Mehmet >=20 > _______________________________________________ > 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 bertietf@bwijnen.net Thu Aug 4 11:22:51 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C3B21F867F for ; Thu, 4 Aug 2011 11:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.271 X-Spam-Level: X-Spam-Status: No, score=-100.271 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCF4TjvgluA2 for ; Thu, 4 Aug 2011 11:22:50 -0700 (PDT) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0A321F8634 for ; Thu, 4 Aug 2011 11:22:49 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1Qp2ZT-0007Dg-S0; Thu, 04 Aug 2011 20:23:04 +0200 Message-ID: <3939A17E86274BA98DAE294B93318BB1@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Kent Watsen" , "netconf" References: <4E1DB164.5090007@bwijnen.net><4E32E057.7030707@bwijnen.net><4E3A4605.2030009@bwijnen.net><4E3A4757.3000601@bwijnen.net><80A0822C5E9A4440A5117C2F4CD36A6402752B18@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD3E87195031@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E87195031@EMBX01-HQ.jnpr.net> Date: Thu, 4 Aug 2011 20:22:57 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Subject: Re: [Netconf] Finished WG LastCall fordraft-ietf-netconf-access-control-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 18:22:51 -0000 OK, Thanks Kent, that is a clearer statement (at least in my ears/reading). Bert ----- Original Message ----- From: "Kent Watsen" To: "Ersue, Mehmet (NSN - DE/Munich)" ; "netconf" Sent: Thursday, August 04, 2011 7:38 PM Subject: Re: [Netconf] Finished WG LastCall fordraft-ietf-netconf-access-control-04.txt > Just to be clear, I didn't say to abandon it. I just said it wasn't an > important problem to Juniper, which is why I was neither supporting or > not-supporting it. Same as in the WG meeting in Quebec, I neither raised my > hand in favor or against it... > > Thanks, > Kent > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of > Ersue, Mehmet (NSN - DE/Munich) > Sent: Thursday, August 04, 2011 11:51 AM > To: netconf > Subject: Re: [Netconf] Finished WG Last Call > fordraft-ietf-netconf-access-control-04.txt > >> - The comments from Kent Watson ("abandon this I-D and this work, it > is >> not needed") was already brought up when we started/chartered the > work. >> Nobody seems to have picked up on that and so Kent seems to be the >> lonely dissenter in this case. So I consider this matter closed >> and I read WG consensus that the WG DOES want to finish and > standardize >> this work. > > This is also my understanding. > > Mehmet > > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of >> ext Bert (IETF) Wijnen >> Sent: Thursday, August 04, 2011 9:17 AM >> To: netconf >> Subject: [Netconf] Finished WG Last Call fordraft-ietf-netconf-access- >> control-04.txt >> >> My quick evaluation as co-chair: >> >> - quite a set of good comments/concerns from various reviewers >> will be addressed by editors/authors in a new revision >> - we got a commitment from our Securoty Advisor (Tim Polk) that he > will >> review >> as well and give us feedback. If he is timely, then authors will > address >> his >> comments in new revision. If not, then he will review the next > revision >> - The comments from Kent Watson ("abandon this I-D and this work, it > is >> not needed") was already brought up when we started/chartered the > work. >> Nobody seems to have picked up on that and so Kent seems to be the >> lonely dissenter in this case. So I consider this matter closed >> and I read WG consensus that the WG DOES want to finish and > standardize >> this work. >> >> Bert (speaking as co-chair) >> >> On 8/4/11 9:11 AM, Bert (IETF) Wijnen wrote: >> > We did not get any requests for extension of the WGLC end date. >> > So WGLC has ended for this document. >> > >> > The authors will address all comments with a new revision. >> > >> > Bert and Mehmet >> > >> > On 7/29/11 6:31 PM, Bert (IETF) Wijnen wrote: >> >> WG participants, >> >> >> >> Pls review BEFORE or BY August 1 if you have not already done so. >> >> A "I read it and see no issues or have no concerns" is also very > welcome! >> >> >> >> I case you need a couple of days extra time (and commit a date for >> >> your review), we're willing to consider a short extension. >> >> >> >> Bert and Mehmet >> >> >> >> -------- Original Message -------- >> >> Subject: [Netconf] WG Last Call for > draft-ietf-netconf-access-control- >> 04.txt >> >> Date: Wed, 13 Jul 2011 16:53:24 +0200 >> >> From: Bert (IETF) Wijnen >> >> To: netconf >> >> >> >> >> >> >> >> Dear WG participants, >> >> >> >> This document was published mid-June, and we have not had much > comments >> >> sofar. So we conclude it must be ready for WG Last Call. >> >> >> >> This is a formal WG Last call for > draft-ietf-netconf-access-control-04.txt >> >> Please review and send any comments BEFORE August 1. >> >> Best would be if you can send it BEFORE July 24, so that we can > discuss >> >> any open issues during our Netconf session at IETF81 in Quebec. >> >> >> >> Bert and Mehmet >> >> _______________________________________________ >> 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 internet-drafts@ietf.org Sun Aug 7 09:59:11 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABE421F857D; Sun, 7 Aug 2011 09:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjIeth0+3AsY; Sun, 7 Aug 2011 09:59:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B088921F8507; Sun, 7 Aug 2011 09:59:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110807165910.14868.70087.idtracker@ietfa.amsl.com> Date: Sun, 07 Aug 2011 09:59:10 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-system-notifications-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 16:59:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group o= f the IETF. Title : Network Configuration Protocol (NETCONF) Base Notificati= ons Author(s) : Andy Bierman Filename : draft-ietf-netconf-system-notifications-05.txt Pages : 16 Date : 2011-08-07 The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications= -05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-= 05.txt From ietf@andybierman.com Tue Aug 9 10:04:06 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B013421F8C63 for ; Tue, 9 Aug 2011 10:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc0giL2DttGH for ; Tue, 9 Aug 2011 10:04:05 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 98EC621F8B44 for ; Tue, 9 Aug 2011 10:04:05 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p79H4Uuo006547 for ; Tue, 9 Aug 2011 13:04:34 -0400 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:57017] helo=[192.168.0.146]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 89/33-22625-D98614E4; Tue, 09 Aug 2011 13:04:30 -0400 Message-ID: <4E41689D.1020901@andybierman.com> Date: Tue, 09 Aug 2011 10:04:29 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Bert (IETF) Wijnen" References: <4E1DB161.2060707@bwijnen.net> <4E32E026.5000305@bwijnen.net> <4E3A4630.3010902@bwijnen.net> In-Reply-To: <4E3A4630.3010902@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] Finished WG Last Call for draft-ietf-netconf-system-notifications-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 17:04:06 -0000 On 08/04/2011 12:11 AM, Bert (IETF) Wijnen wrote: > We did not get any requests for extension of the WGLC end date. > So WGLC has ended for this document. > > The authors will address all comments with a new revision. > A new version (-05) has been posted: http://www.ietf.org/id/draft-ietf-netconf-system-notifications-05.txt Please verify that the disputed text has been adjusted correctly. > Bert and Mehmet Andy > > On 7/29/11 6:30 PM, Bert (IETF) Wijnen wrote: >> WG participants, >> >> Pls review BEFORE or BY August 1 if you have not already done so. >> A "I read it and see no issues or have no concerns" is also very welcome! >> >> I case you need a couple of days extra time (and commit a date for >> your review), we're willing to consider a short extension. >> >> Bert and Mehmet >> -------- Original Message -------- >> Subject: [Netconf] WG Last Call for draft-ietf-netconf-system-notifications-04.txt >> Date: Wed, 13 Jul 2011 16:53:21 +0200 >> From: Bert (IETF) Wijnen >> To: netconf >> >> >> >> Dear WG participants, >> >> This document was published mid-June, and we have not had much comments >> sofar. So we conclude it must be ready for WG Last Call. >> >> This is a formal WG Last call for draft-ietf-netconf-system-notifications-04.txt >> Please review and send any comments BEFORE August 1. >> Best would be if you can send it BEFORE July 24, so that we can discuss >> any open issues during our Netconf session at IETF81 in Quebec. >> >> Bert and Mehmet >> _______________________________________________ >> 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 mehmet.ersue@nsn.com Sun Aug 14 09:50:15 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BD121F8A56 for ; Sun, 14 Aug 2011 09:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.02 X-Spam-Level: X-Spam-Status: No, score=-106.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTEX7qujHV5T for ; Sun, 14 Aug 2011 09:50:15 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id F2CC221F87C5 for ; Sun, 14 Aug 2011 09:50:14 -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 p7EGouOq015385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 14 Aug 2011 18:50:56 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p7EGotIn003138 for ; Sun, 14 Aug 2011 18:50:56 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Aug 2011 18:50:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Aug 2011 18:45:14 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64027FB16B@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft IETF 81 NETCONF Session Minutes thread-index: AcuIxfysvrwoNFw7R/2gcNQWxZGCxwEx0b0gG0EF1KAYA+zpIA== From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 14 Aug 2011 16:50:55.0987 (UTC) FILETIME=[55EF9C30:01CC5AA2] Subject: [Netconf] Draft IETF 81 NETCONF Session Minutes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 16:50:15 -0000 Dear NETCONF WG, please find below the draft minutes of the NETCONF session in IETF 81. Pls send us your comments by August 26, 2011. http://www.ietf.org/proceedings/81/minutes/netconf.txt Many thanks to the minute takers Juergen Schoenwaelder, Lada=20 Lhotka and Jabber scribe Bill Fenner. Mehmet & Bert From mehmet.ersue@nsn.com Tue Aug 23 03:23:13 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474AD21F8AFA for ; Tue, 23 Aug 2011 03:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.047 X-Spam-Level: X-Spam-Status: No, score=-106.047 tagged_above=-999 required=5 tests=[AWL=0.552, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alb0Qcf9uvwJ for ; Tue, 23 Aug 2011 03:23:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 31D8F21F8AE4 for ; Tue, 23 Aug 2011 03:23:12 -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 p7NAOA10008092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 23 Aug 2011 12:24:10 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p7NAO1LX010115 for ; Tue, 23 Aug 2011 12:24:10 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 12:24:03 +0200 Received: from 10.150.128.35 ([10.150.128.35]) by DEMUEXC006.nsn-intra.net ([10.150.128.22]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Aug 2011 10:24:02 +0000 Content-Type: multipart/mixed; boundary="----=_NextPart_000_20E1E_01CC617E.C75B15AA" From: "Ersue, Mehmet (NSN - DE/Munich)" thread-topic: [opsarea-chairs] FW: Nomcom 2011-2012: Call for Nominations thread-index: AcxhG01w9oRbuMZLT9WacWEwRtiq/AAW9pWgAAHn5X4= X-MimeOLE: Produced By Microsoft Exchange V6.5 To: Date: Tue, 23 Aug 2011 12:24:02 +0200 Message-ID: <20e1d01cc617e$c75b15aa$2380960a@nsnintra.net> X-Mailer: EAS Version 1.00 MIME-Version: 1.0 Content-Language: i-default X-OriginalArrivalTime: 23 Aug 2011 10:24:03.0109 (UTC) FILETIME=[C7B34550:01CC617E] Subject: [Netconf] WG: [opsarea-chairs] FW: Nomcom 2011-2012: Call for Nominations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 10:23:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_20E1E_01CC617E.C75B15AA Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable FYI Mehmet ------=_NextPart_000_20E1E_01CC617E.C75B15AA Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from demuexc022.nsn-intra.net ([10.150.128.35]) by DEMUEXC006.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 11:31:01 +0200 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Aug 2011 11:31:01 +0200 Received: from mumrelp001.nsn-inter.net (mumrelp001.nsn-inter.net [93.183.13.135]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p7N9V0mE011227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2011 11:31:00 +0200 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mumrelp001.nsn-inter.net (8.13.8/8.13.8) with ESMTP id p7N9Ux4W002109; Tue, 23 Aug 2011 11:31:00 +0200 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3B721F8AF8; Tue, 23 Aug 2011 02:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1314091791; bh=9yTgxj6lb/q45DqdPsMpn4G/UaPYRNHwifWFNcPLfkM=; h=MIME-Version:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=qDClxQ1NmYIHEQEki8fNHbYCxZ8zP0FQgqJCGvbI1ak1mIoQ7ZsspNM0WRoh+GTUw PeHTe4/VJmZAeXB7DTloEiBR0rjTJWsNuOrkFPuEppzma12GRSNRJrZ6uaXyhelO6q oh6tQGOrvtQnAx1/4E6lNlXBtNUFBcXpbQT40J5s= X-Original-To: opsarea-chairs@ietfa.amsl.com Delivered-To: opsarea-chairs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F4E21F8AF2 for ; Tue, 23 Aug 2011 02:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa8yFyeHtmRE for ; Tue, 23 Aug 2011 02:29:50 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 21D7E21F8AF1 for ; Tue, 23 Aug 2011 02:29:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswAAI9yU07GmAcF/2dsb2JhbABBmEmPV3eBQAEBAQEDAQEBDwsTCjQXBgEIDQQEAQELBgwLAQcmHwcBAQUEAQQTCAwOh1OWeIQJApxNhWlfBJhEi1E X-IronPort-AV: E=Sophos;i="4.68,268,1312171200"; d="scan'208";a="203552330" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Aug 2011 05:30:56 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Aug 2011 05:27:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Aug 2011 11:30:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2011-2012: Call for Nominations Thread-Index: AcxhG01w9oRbuMZLT9WacWEwRtiq/AAW9pWg From: "ext Romascanu, Dan (Dan)" To: Subject: [opsarea-chairs] FW: Nomcom 2011-2012: Call for Nominations X-BeenThere: opsarea-chairs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Archived discussions of OPS Area WG Chairs and ADs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: opsarea-chairs-bounces@ietf.org Errors-To: opsarea-chairs-bounces@ietf.org X-purgate-type: bulk X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: bulk X-purgate: This mail is sent in bulk (visit http://www.eleven.de for further information) X-purgate-size: 3620 X-purgate-ID: 151667::1314091860-00000F95-FA0A356F/0-0/30015-9 X-Scanned-By: MIMEDefang 2.71 on 93.183.13.135 Return-Path: opsarea-chairs-bounces@ietf.org X-OriginalArrivalTime: 23 Aug 2011 09:31:01.0426 (UTC) FILETIME=[5F44F920:01CC6177] Hi, Please distribute the Nomcom message to the WG mail lists and invite participants to nominate the best candidates for the positions that need to be filled. Thanks and Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Tuesday, August 23, 2011 1:30 AM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2011-2012: Call for Nominations Hi All, The 2011-2012 Nominating committee is seeking nominations from now until October 2, 2011. The list of open positions can be found at: https://www.ietf.org/group/nomcom/2011/ Nominations may be made directly on the NomCom 2011-2012 pages by selecting the Nominate link at the top of the page. The URL for NomCom 2011-2012 pages is: https://www.ietf.org/group/nomcom/2011/ Nominations may also be made by email to nomcom11@ietf.org. If you do so, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self nomination is welcome. NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential". Willing Nominees for each position will be publicly listed. The public nominee list will be updated at least once a week and possibly more often as nominations are received. With the exception of publicly listing willing nominees, the confidentiality requirements of RFC 3777 remain in effect. All feedback and NomCom deliberations will remain confidential and not disclosed. Because the list of nominees this year is public, we will accept feedback on the nominees starting August 23, 2011. Per RFC 5680, we will accept feedback from the entire IETF community on all the nominees. If you wish to provide anonymous feedback, the chair or any of the members will be happy to handle this for you. The Nominating Committee chair can be reached at nomcom-chair@ietf.org and the entire nominating committee can be reached at nomcom11@ietf.org. The email addresses of individual NomCom members is also on the NomCom 2011-2012 pages. In addition to nominations, the Nominating Committee is actively seeking community input on the jobs that need to be filled. We have received the job descriptions from the IAB, IESG, and IAOC and they can be found at: https://www.ietf.org/group/nomcom/2011/iab-requirements https://www.ietf.org/group/nomcom/2011/iesg-requirements https://www.ietf.org/group/nomcom/2011/iaoc-requirements However, we also need the community's views and input on the jobs within each organization. If you have ideas on job responsibilities (more, less, different), please let us know. Please send suggestions and feedback to nomcom11@ietf.org. Thank you, Suresh Krishnan Chair, NomCom 2011-2012 nomcom-chair@ietf.org suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ opsarea-chairs mailing list opsarea-chairs@ietf.org https://www.ietf.org/mailman/listinfo/opsarea-chairs ------=_NextPart_000_20E1E_01CC617E.C75B15AA--