RE: LC summary for draft-ietf-opsawg-operations-and-management
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On There is currently a Secdir review for Internet-Drafts. If operations and management considerations are included, the documents will need an Opsdir review and a mandatory Management Considerations section. Just to clarify - there is an OPS-Dir review process in place now for Internet-Drafts as well, but no requirement for a mandatory operations and management considerations section. Dan ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
On 29 jun 2009, at 0:34, John C Klensin wrote: I've had few of those problems when I edit with emacs or its clones. I guess that doesn't qualify as today's tools in your book but, if so, your issue is much broader than xml2rfc. There are probably IETF contributors who are younger than emacs. Although I am reasonably familiar with a couple of old school text editors (vi and pico), as far as I am aware those don't handle hard line endings transparently, which is the ultimate source of most of the problems. The problem is that the Secretariat likes (or has been told to) published a page count as part of the I-D announcement and that they can't figure out the page count without page breaks. They could publish a word count instead. In most areas of writing word counts are used to evaluate the length of a text. Line breaks are because a situation in which some documents have them and others interfere with a different set of reading (and printing) tools. Just as you want to be able to say I want to be able to submit drafts without using xml2rfc to format them, I want to be able to say I don't want my drafts to require processing through some display formatter It's true that you can't load a text file without hard line breaks in a browser and have the browser wrap the lines. However, printing a draft or RFC requires processing today as the page break characters no longer seem to work these days. With soft line breaks you can easily load the text into an editor and print from there. before I can read them or have a discussion with someone else that includes references to Line M of Paragraph 2 of Section 5.2. I also note that some of us are very dependent of diffs and the like which also depend on well-defined lines. So your soft line break requirement is the one that strikes me as completely unreasonable. Well, creating line breaks is not exactly rocket science so it should be easy enough to create a tool that breaks lines in a consistent way. However, once the lines are broken editing and printing become harder so I think the official version of a draft should have unbroken lines. I'd be happier if xml2rfc permitted me to write something like: reference anchor=FooBar status=later / Yes, this is the problem with XLM2RFC. It's trying to be way too smart, usually unsuccessfully. So now I have to remember that I need to call an experimental draft exp, while just typing experimental would be so much easier. Or it insists that it knows how to create my full name from my first and last names, but of course it doesn't know that in Dutch a last name on its own starting with van has the V capitalized (Van Beijnum) but if there are initials or first names it's lower case (I. van Beijnum). Life is too short to battle with your tools. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
I remain heartily fed up that the HTML versions of documents that I know were submitted with XML source are not available, nor is the XML source. The TXT versions do not print on my printer and have not printed reliably on any printer I have ever owned. I know that some UNIX folk just love to rub the noses of the rest of us in this dog poop but it gets tiresome. Just because it works for some people does not mean that it is the best way to do things. The W3C has worked out how to print professional looking standards in a format that we can safely assume will be readable for the next thousand years at least. We will lose the ability to read bits long before we lose the ability to read HTML, or for that matter reverse engineer PDF. On Sun, Jun 28, 2009 at 12:33 PM, Iljitsch van Beijnumiljit...@muada.com wrote: Hi, XML2RFC isn't working for me. For instance, We are now required to use boilerplate that the official version of XML2RFC doesn't recognize so it's necessary to use a beta version that is even more undocumented than the regular undocumentedness of the official version of XML2RFC. Of course such things tend to only surface the day of the cutoff. I used to write drafts by hand sometimes in the past, but this is also very hard, because today's tools just don't have any notion of hard line endings, let alone with spaces at the beginning of all lines and hard page breaks (at places that make no sense in an A4 world, too). This is getting worse because the checks done on IDs upon submission are getting stricter and stricter. See http://www.educatedguesswork.org/movabletype/archives/2007/11/curse_you_xml2r.html for a long story that I mostly agree with. As such, I want to see the following: - the latest boilerplate is published in an easy to copypaste format - drafts may omit page breaks - drafts may omit indentation and hard line breaks - no requirements for reference formats Note that this is for drafts in general. If the RFC editor wishes to impose stricter formatting rules I can live with that. Please don't reply with helpful hints on how to work with XML2RFC. Even with a perfect XML2RFC I would still be forced to create XML, which is something I desperately long to avoid. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
On Sun, Jun 28, 2009 at 10:45 AM, Phillip Hallam-Bakerhal...@gmail.com wrote: The TXT versions do not print on my printer and have not printed reliably on any printer I have ever owned. Yes, and that history goes back a couple of decades for me. I know that some UNIX folk just love to rub the noses of the rest of us in this dog poop but it gets tiresome. Just because it works for some people does not mean that it is the best way to do things. Hey, I'm as Unix-y a person as there is, and simultaneously as fierce a despiser as you can find of 80-character 66-line hard-to-read impossible-to-print ignores-decades-of-advances-in-publishing-tech i18n-oblivious ASCIIlicious IETF worst practices. Another data point, by the way. I am a major consumer of the Internet through a mobile device (an Android phone in my case, but whatever). RFCs are essentially unusable on this device in the legacy text format, but work fine in xml2rfc-generated HTML. I think that in the big picture, usability on a mobile device is several times as important as usability on the hypothetical ASCII-capable line printer that presumably must have once existed somewhere. The W3C has worked out how to print professional looking standards in a format that we can safely assume will be readable for the next thousand years at least. We will lose the ability to read bits long before we lose the ability to read HTML, or for that matter reverse engineer PDF. Yes, although I wouldn't recommend adopting their publishing system. Can we please join the current millennium? I'd be happy to help. -Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
The TXT versions do not print on my printer and have not printed reliably on any printer I have ever owned. Yes, and that history goes back a couple of decades for me. Probably says more about ones skills than either the printers one uses or ASCII as a document interchange format. I'm sure reading an RFC on a mobile device is important to the community as a whole. Not! 1000 years from now, it will certainly be easier to recover content from an ascii 'file' than an html, xml, or pdf 'file' created now. It is probably an unjustified assumption that 'software' available 1000 years from now will be able to render today's html, xml, or pdf. The more tools required to access binary content, the more opportunities for access denied. ASCII has the advantage that many programs can provide adequate access to data encoded in ASCII. It also has the advantage that authors don't feel compelled to create pretty documents which may increse the visual appeal but do nothing to enhance the content. On the other hand, more advanced formats allow for decent technical drawings and electronic references to related content. Striking the right balance between the efficiencies of minimalist formatting and the capabilities of richer formatting will be a difficult challenge. A primary requirement should be maintaining access in the widest possible set of computing environments. The adoption of modern technologies is not in and of itself justification for change. David Morris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
On Mon, Jun 29, 2009 at 01:37:31PM -0700, David Morris wrote: 1000 years from now, it will certainly be easier to recover content from an ascii 'file' than an html, xml, or pdf 'file' created now. It is probably an unjustified assumption that 'software' available 1000 years from now will be able to render today's html, xml, or pdf. I am not sure I agree with this assertion. In 1000 years, I have every hope that some versions of PDF will be widely usable; but the currently prescribed format of electronic versions of RFCs I think is already obsolete, and will be unreadable in 1000 years. PDF/A-1 is an ISO standard preferred by the U.S. Library of Congress for page-oriented textual (or primarily textual) documents when layout and visual characteristics are more significant than logical structure. (http://www.digitalpreservation.gov/formats/fdd/fdd000125.shtml, visited 2009-06-29) One could construct a reasonable argument that in the case of RFCs, the layout and visual characteristics are _not_ more siginficant than logical structure. But under the current publication regime, they are in fact more significant: we have significant rules for publication about the exact page layout, the number of lines, the margins, the headers and footers, and even what character (i.e. line-printer character) ends a page. We have practically no guidance about the logical structure of documents, except that if the document is a given number of pages, it needs a table of contents. Whether the logical structure of the document ought to be of higher concern in relation to the publication form is a topic argued elsewhere in this thread. I want to pay attention to whether PDF will be usable in 1000 years. The Library of Congress, and librarians generally, take archival formats terribly seriously. There is just about no hope of dislodging the MARC standard, for instance, even though every librarian I ever spoke to in my admittedly brief library career granted that MARC is miserably adapted to relational databases (which hadn't been invented when MARC was settled upon). The reason MARC can't be replaced is because that's the format they picked, and so everything has to work around it. Period. The technology it was invented around was obsolete before the standard even got widely adopted? Too bad. This is an _archival_ format, and therefore it Will Not Change. All future technology will simply be specified to use it. And it is so specified: one library automation system I knew of when I last looked at this (nearly 10 years ago, mind) stored every MARC record in BLOBs, and just did everything up in the application. Everyone except the sales people thought this a miserable hack, but the MARC format was preserved. Thus do relational theorists go slowly insane. If librarians have picked PDF/A-1 as an electronic format that they're going to use -- particularly, if LC has picked it -- then I have every confidence that the format will be supported somewhere for roughly as long as there remain readers on Earth. I am more concerned, in fact, about widespread inability to read than I am about librarians stopping support of some archival format they selected. They are way more serious about keeping old archival formats working than the IETF has even been about making FTP continue to work everywhere. ASCII, on the other hand, doesn't meet any of the librarians' criteria, and never did. It is too restrictive even to deal with non-American titles in the library catalogue (e.g. books priced in pounds sterling), never mind to deal with non-English titles. ASCII was a bugbear in library automation systems from the very beginning. Certainly, files of supposedly plain text containing the occasional control character used to format pages for a specific line printer that was once attached to some ancient computer system on the Internet is not an archival format that any responsible librarian would sign up for. Best regards, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
At 1:45 PM -0400 6/28/09, Phillip Hallam-Baker wrote: I remain heartily fed up that the HTML versions of documents that I know were submitted with XML source are not available, nor is the XML source. The original thread is about Internet Draft submission, not RFC publication format. The two topics are completely disjoint in the IETF procedures. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
On Jun 29, 2009, at 15:01, Paul Hoffman wrote: The original thread is about Internet Draft submission, not RFC publication format. The two topics are completely disjoint in the IETF procedures. Disagree. The two topics are intimately related by their functions in IETF policy and process. Internet Drafts are our slushpile. It the manuscript format required by the RFC Editor does not closely match the manuscript format required for consideration as an Internet Draft, then we will only be making the task of reviewing the slush and preparing manuscripts for publication all the more difficult for ourselves. Do we really want to loosen *only* the I-D submission requirements and not the RFC Editor requirements as well? I don't think so. We would only want to do that because we think we're not getting enough slush to review, and we're worried that we might be losing valuable contributions because the barrier to submit is too high. Honestly, is that *really* the problem IETF is facing? (Note well: I am not expressing an opinion about whether IETF should or should not change its archival format. I'm still forming an opinion about that. This message is about editorial process.) -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-opsawg-syslog-msg-mib (Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications ' draft-ietf-opsawg-syslog-msg-mib-04.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-07-13. 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-opsawg-syslog-msg-mib-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18178rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-opsawg-syslog-snmp (Mapping Simple Network
Management Protocol (SNMP) Notifications to SYSLOG Messages) to Proposed Standard The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages ' draft-ietf-opsawg-syslog-snmp-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-07-13. 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-opsawg-syslog-snmp-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18179rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Softwire Security Analysis and Requirements' to Proposed Standard
The IESG has approved the following document: - 'Softwire Security Analysis and Requirements ' draft-ietf-softwire-security-requirements-09.txt as a Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-security-requirements-09.txt Technical Summary This document describes the security guidelines for the softwire Hubs and Spokes and Mesh solutions. Together with the discussion of the softwire deployment scenarios, the vulnerability to the security attacks is analyzed to provide the security protection mechanism such as authentication, integrity and confidentiality to the softwire control and data packets. Working Group Summary The SOFTWIRE WG supports the development and advancement of this document. Protocol Quality This document was thoroughly reviewed by WG chairs and WG members, including those with expertise in security, IPv4 to IPv6 transitions and interworking. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5593 on Internet Message Access Protocol (IMAP) - URL Access Identifier Extension
A new Request for Comments is now available in online RFC libraries. RFC 5593 Title: Internet Message Access Protocol (IMAP) - URL Access Identifier Extension Author: N. Cook Status: Standards Track Date: June 2009 Mailbox:neil.c...@noware.co.uk Pages: 10 Characters: 18149 Updates:RFC5092 I-D Tag:draft-ncook-urlauth-accessid-02.txt URL:http://www.rfc-editor.org/rfc/rfc5593.txt The existing IMAP URL specification (RFC 5092) lists several access identifiers and access identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new access identifiers as well as an IANA mechanism to register new access identifiers for future applications. This document updates RFC 5092. [STANDARDS TRACK] 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
