Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman > said: AB> Oherwise the agent would deadlock. AB> discard-changes does not affect the running configuration. No, but it does affect the other users notion of changes. You should never be allowed to discard changes that another user has made. AB> It just resets the scratchpad database. AB> Why bother applying the ACLs before the edit operation AB> is attempted for real? user 1: add new important policy configuration user 2: discard-changes user 1: commit Granted, user 1 should be using locks of some kind. To undo changes it's rather important that someone with proper authorization to the everything changed (IE, an admin) performs the discard. Or are you suggesting that one shouldn't ever have access control applied to the candidate store in the first place? (I hope not). AB> Requiring small embedded devices to serve as robust AB> database engines may be more expensive than AB> the rest of the code combined. We are coming from AB> an operational environment based on humans using the CLI, AB> which has no locking at all. The globally locked AB> candidate "edit, validate, and commit" model AB> is way better than anything we ever had in SNMP or CLI. If you look at history of operating just about anything, after it gets to a point where multiple operators need to scale things up you'll find that eventually stuff gets put into a multi-user revision database type system. We are far beyond the point where operators are editing single flat-files using "vi" and hitting "save" without any form of revision control. After that point, then went to locking version control systems (sccs? I'm forgetting the early version-control system names). Then people realized that caused huge headaches because the global file locking, although it prevented some types of problems, caused a bunch of other problems. Eventually more modern version control systems were developed that allowed people to simultaneously edit things and only get bothered when conflicts happen. This was a huge win, ask anyone who works with version control systems. But now, in this space, we're going back to the older methodologies of editing a single file and hoping that two people don't conflict (with or without a lock). I've said this before, but I'll repeat it now: netconf, from a protocol-operation point of view, is designed to work in a single-operator type environment. The instant you add multiple-users with or without different roles all these problems come up. This is actually just fine, but it needs to either: 1) be fixed so that these problems go away. 2) stop being advertised as a multi-operator type solution. I think "being fixed" is a great long term goal. But for right now, I'd suggest we simple say "this is version 1 at the moment and it is currently designed for use by single-operator systems". (And it doesn't prevent an external version-control system for being the master and pushing the config down. It just doesn't work on the device itself). -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
> On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman > said: AB> discard-changes only works because authorization is ignored, AB> otherwise the agent would be deadlocked. Huh why would discard-changes be authorization ignorant??? That's just as unsafe (unless you're only discarding your own changes). AB> Only the global lock operation defined in RFC 4741 AB> can prevent this problem. The global lock has different issues. The problem isn't with the locking. Locking, and partial locking are good. It's with the global-level commit operation. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Obnoxious license
In article <6.2.5.6.2.20090813134034.0331e...@elandnews.com>, SM wrote: >I was discussing RFC 5617 with someone and the person mentioned that >the copyright in the middle of the document is obnoxious. The >copyright statement for the code is 32 lines while the code (ABNF) is >only five lines. Can a copyright even be valid for just five lines of code? -- http://yosemitenews.info/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC/Telechat review of draft-freed-sieve-in-xml-05
On Aug 13, 2009, at 9:47 AM, Ned Freed wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-freed-sieve-in-xml-05 Reviewer: Ben Campbell Review Date: 2009-08-11 IETF LC End Date: 2009-08-13 IESG Telechat date: 2009-08-13 Note: The LC end and the Telechat are on the same day, so this review serves as both a last call and telechat review. Summary: This draft is almost ready for publication as a draft standard. There are some issues and questions that I think should be resolved prior to publication. Note: I am not an XML expert. I have not attempted any sort of mechanical validation of the schema or style sheet included in this draft. If this has not been done already, it probably should prior to final publication. FWIW, it looks like there's a serious problem with the XML Schema that's going to require some changes to address. Major issues: -- This draft depends heavily on the premise that SIEVE control structures are rarely extended, and can be known to a conversion process in advance. However, if I understand correctly, there is another draft under review right now that adds new controls (namely draft-ietf-sieve-mime-loop)--so I'm not sure I accept that premise. OK, let's look at the facts. Sieve was iniitally standarded in 1991 (RFC 3028), a document that defined three control elements: if, stop, and require. There have subsequenty been, by my count, 29 revisions or new documents written that extent or enhance Sieve in some way, including at least one that applies Sieve in a very different context than it was designed for. Of those around 16 have been published as RFCs. In all of those documents there has been exactly one that proposed new controls: The MIME loops document now under consideration, which defines the controls foreverypart and break. (I note in passing that the language used in the draft is incorrect - it calls them actions, not contorls.) Moreoever, work on Sieve extensions is finally winding down - the rate at which entirely new proposals are being created right now is for all intents and purposes zero. So we started with a list of 3 items, and in almost 9 years it's had one addition, extending it to 5 items. And that's over a period of active development, which is now coming to an end. And when such a change occurs all that needs to be done to satisfy this language requirement is add the new items to an internal list. Whereas in order to actually support the procesing of a new control in any nontrivial fashion that would actually call for distinguising it from an action would almost certainly require quite a lot more work. This is an update problem and associated rate of change I for one can live with very easily. Nevertheless, it seemed like a good idea to make the current list explicit in the document, so I've gone ahead and done that: The separation of controls from actions in the XML representation means that conversion from normal Sieve format to XML has to be able to distinguish between controls and actions. This is easily done by maintaining a list of all known controls since experience indicates new controls are rarely added. At the time of this writing the list of defined and proposed controls consists of: 1. if [RFC5228], 2. stop [RFC5228], 3. require [RFC5228], 4. foreverypart [I-D.ietf-sieve-mime-loop], and 5. break [I-D.ietf-sieve-mime-loop]. At the least, the draft should discuss what would happen if a conversion process encounters an unknown control, and how a human user might detect and correct the problem. In particular, would a round-trip conversion process on a sieve script that contained an unknown control render the equivalent script? OK, so how about: It should be noted that with this approach unknown controls will simply be treated as actions and can be passed back and forthe between the two representations. The treatment of a control as an aciton is unlikely to cause other issues since knowledge of a control's language semantics is almost always required to take of advantage of it. Thanks, I think the proposed text helps. Minor issues: -- General: It would be helpful to have up front definitions of the terms "editor" and "processor". They are used throughout the document, and have normative requirements placed on them. I gather from context that "editor" is a UI, and "processor" is something that performs the sieve- to-xml round trip transformations? I don't think this is really necessary, but it seems mostly harmless, so how about: The term "processor" is used throughout this document to refer to agents that convert Sieve to and from the XML representation. The term "
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
Wes Hardaker wrote: >> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman >> said: > > AB> Oherwise the agent would deadlock. > AB> discard-changes does not affect the running configuration. > > No, but it does affect the other users notion of changes. You should > never be allowed to discard changes that another user has made. > this assumes you have an access control model in mind. I do too -- they aren't the same. Without any standards for this, neither of us are wrong. > AB> It just resets the scratchpad database. > AB> Why bother applying the ACLs before the edit operation > AB> is attempted for real? > > user 1: add new important policy configuration > user 2: discard-changes > user 1: commit > > Granted, user 1 should be using locks of some kind. > what is the NETCONF 'add new' operation? step 1 is very unclear. > To undo changes it's rather important that someone with proper > authorization to the everything changed (IE, an admin) performs the > discard. > > Or are you suggesting that one shouldn't ever have access control > applied to the candidate store in the first place? (I hope not). > I apply it to the candidate and to running, except discard-changes, otherwise the agent would deadlock often and that would be counter-productive to network operations. When you start with an awful design premises like locking should be optional to use, then you might end up with messy code. Nothing new there. > AB> Requiring small embedded devices to serve as robust > AB> database engines may be more expensive than > AB> the rest of the code combined. We are coming from > AB> an operational environment based on humans using the CLI, > AB> which has no locking at all. The globally locked > AB> candidate "edit, validate, and commit" model > AB> is way better than anything we ever had in SNMP or CLI. > > If you look at history of operating just about anything, after it gets > to a point where multiple operators need to scale things up you'll find > that eventually stuff gets put into a multi-user revision database type > system. We are far beyond the point where operators are editing single > flat-files using "vi" and hitting "save" without any form of revision > control. After that point, then went to locking version control systems > (sccs? I'm forgetting the early version-control system names). Then > people realized that caused huge headaches because the global file > locking, although it prevented some types of problems, caused a bunch of > other problems. Eventually more modern version control systems were > developed that allowed people to simultaneously edit things and only > get bothered when conflicts happen. This was a huge win, ask anyone who > works with version control systems. > > But now, in this space, we're going back to the older methodologies of > editing a single file and hoping that two people don't conflict (with or > without a lock). > again -- when locking is optional to use, the database is never going to be very good. > > I've said this before, but I'll repeat it now: netconf, from a > protocol-operation point of view, is designed to work in a > single-operator type environment. The instant you add multiple-users > with or without different roles all these problems come up. This is > actually just fine, but it needs to either: > > 1) be fixed so that these problems go away. > 2) stop being advertised as a multi-operator type solution. > I disagree. The partial-lock feature is not needed in every environment. NETCONF supports the SQL-like model (write directly to the persistent datastore) and that is good enough. Why does the scratchpad model need to be per-session? That is nice-to-have, but not important. > I think "being fixed" is a great long term goal. But for right now, I'd > suggest we simple say "this is version 1 at the moment and it is > currently designed for use by single-operator systems". > > (And it doesn't prevent an external version-control system for being the > master and pushing the config down. It just doesn't work on the device > itself). Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC/Telechat review of draft-freed-sieve-in-xml-05
ned+i...@mauve.mrochek.com wrote: -- Section 4.2, paragraph 5: " ... SHOULD use the structured comment format shown above." Why not MUST? Wouldn't violation of this requirement introduce interoperability problems between different implementations? It's a SHOULD because the WG believed that there may be some exception cases where an alternate format makes more sense. Speaking as an implementor, who implemented something similar: I think SHOULD is exactly right here. I would personally object to making this mandatory. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
