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
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 i...@andybierman.com 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
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 editor
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman i...@andybierman.com 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: secdir review of draft-ietf-netconf-partial-lock-09.txt
On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman i...@andybierman.com 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
RFC Series Editor Nominees (Feedback Requested) and Independent Stream Editor Process
Dear Colleagues, With reference to the call for nominations [1,2] for an RFC Series Editor (RSE) and Independent Stream Editor (ISE) and the extension for the of the call [3], there are two two things I would like to bring to your attention. = RFC Series Editor Nominations I would like to inform you that at the close of the extended nomination period we received 4 nominations: - Shreedeep Rayamajhi - Paul Hoffman - David E. Martin - Ole Jacobsen The IAB invites community feedback on these candidates, specifically in relation to the how the expertise and profile of the candidates maps to the function as described in http://iaoc.ietf.org/rfced-procurement.html and http://tools.ietf.org/html/draft-iab-rfc-editor-model Please send your feedback to the Ad Hoc Advisory Committee (ACEF) a...@iab.org by August 23, 2009. Your feedback will be shared with the members (see [4]) of the ACEF and, at a later stage, with the IAB. We understand there may be potential candidates that are still contemplating their nomination. Therefore, and without reflection on the current candidates, we will continue to entertain nominations for the RSE position for a short time. = Independent Series Editor Nominations and selection process After consulting with the ACEF (who assist the IAB in the selection of candidates) the IAB has decided that we will first work through the RSE candidates and then proceed with assessment of the ISE candidates. Nominations for the ISE are still welcome during the period in which the ACEF is formulating its advice on the RSE appointment. Please refer to [2] for the exact nomination procedure. The timeline for the selection of the RSE remains as published in our extensions for the call[2] while the timeline for the selection and appointment of the ISE will shift a little more than a month. This may mean that there is little or no overlapping time for transition of the ISE. While this is not the optimum situation, the IAB and the ACEF believe that there will not be significant problems by shifting the timescale and thereby potentially not having an overlap. Modified ISE timeline: 1st week of October - ISE Nominees announced; community input solicited mid-October - Community input ends mid-October through end October - IAB appointed Advisory Committee conducts interviews begin November - Advisory Committee recommends individuals to IAB for ISE position mid November - IAB appoints ISE end Nov - Agreement Executed with IAD for expenses and transition begins 1 Jan - Appointments take effect With kind regards, --Olaf Kolkman IAB chair. [1] RSE call for nomination: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06167.html [2] ISE call for nomination: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06168.html [3] Extension of the call for nominations: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06303.html [4] RFC Editor related appointments: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06260.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-sipcore-presence-scaling-requirements (Scaling Requirements for Presence in SIP/SIMPLE) to Informational RFC
The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Scaling Requirements for Presence in SIP/SIMPLE ' draft-ietf-sipcore-presence-scaling-requirements-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-08-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipcore-presence-scaling-requirements-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18507rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5613 on OSPF Link-Local Signaling
A new Request for Comments is now available in online RFC libraries. RFC 5613 Title: OSPF Link-Local Signaling Author: A. Zinin, A. Roy, L. Nguyen, B. Friedman, D. Yeung Status: Standards Track Date: August 2009 Mailbox:alex.zi...@alcatel-lucent.com, a...@cisco.com, lhngu...@cisco.com, bar...@google.com, mye...@cisco.com Pages: 12 Characters: 23092 Obsoletes: RFC4813 I-D Tag:draft-ietf-ospf-lls-08.txt URL:http://www.rfc-editor.org/rfc/rfc5613.txt OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well-defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track. This document is a product of the Open Shortest Path First IGP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
