Re: More liberal draft formatting standards required
On 29 jun 2009, at 23:32, Andrew Sullivan wrote: 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. My original message was about problems _creating_ a certain format. But this is of course related to _reading_ a format. Don't underestimate how quickly formats go away. Anyone here try to open a Wordperfect document recently? Assuming that in 1000 years people still understand English and can still read latin script, it's trivial to decode a plain ASCII file. HTML is only slightly more difficult: just remove everything between and and you have something that's mostly readable. With XML you should be able to recover most of the text, but I'm pretty sure in 1000 years nobody is going to understand what rfc ipr=trust200902 category=exp means. Not exactly sure what the insides of a PDF file look like, but I'll go on a limb and say that it won't be possible to get anything useful out of a PDF file without software that understands PDF. I don't think that will be around in 1000 years. However, because PDF unambiguously maps to an image it should be possible to convert from PDF to other image formats without losing any content. (And then a decade or two later run OCR on that to retreive the original text...) So I'd say that if we want to change our archival format a carefully documented subset of HTML would probably be a good choice. This is easy to display on a variety of screen sizes and prints reasonably without effort, can be made to print very well with additional tools. It has a lot more structure than flat text so scraping tools could potentially be more effective than today's, especially considering that old RFCs weren't formatted as rigorously as recent ones. PDF would be a disaster because it's not compatible with text-only displays, not compatible with any scraping tools, can't be viewed without non-trivial software and doesn't scale to display size. 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. Last time I checked RFCs were free and in English... Consider this: even if we could use non-latin scripts for author names in RFCs, would that be a good idea? Back to my original problem: although there are tons of modern tools that create HTML, they usually create completely unstructured and very messy HTML that would be unusable for archiving or pretty much anything else. With a modern word processor you can basically create an unstructured and unformatted ASCII file without even line and page breaks, or create something highly structured that requires conversion tools to create something that looks like draft format. We've really painted ourselves in a corner here. ___ 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. I discovered by accident that, on my machine, simply opening a text version in Microsoft Word gives a document which prints properly, page breaks and all. (10 point Courier I think.) Maybe not a purists' solution, but good enough to allow me to move on. This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
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 TXT versions do not print on my printer and have not printed reliably on any printer I have ever owned. just an aside: the way I've found that works reliably these days for printing I-Ds and RFCs is to load them into OpenOffice's editor (oowriter) and use print from there. Somehow, OpenOffice managed to understand the formfeed character. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
On 30 jun 2009, at 12:38, Harald Alvestrand wrote: the way I've found that works reliably these days for printing I-Ds and RFCs is to load them into OpenOffice's editor (oowriter) and use print from there. Somehow, OpenOffice managed to understand the formfeed character. On the Mac you can still use lpr file but unfortunately the formfeeds get lost when you do that. Pages also doesn't recognize them. But Textedit does if you use format - wrap to page. However, the lines probably don't fit anymore after that, fix this by making the document rich text and selecting a 10 point fixed width font. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Iljitsch van Beijnum wrote: On the Mac you can still use lpr file but unfortunately the formfeeds get lost when you do that. I use enscript. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Please do not insult other people's abilities. The fact that some of us can find something more fun to do than get a document without embeded form feeds to print properly does not mean that we are less expert than you. If a grad student handed me a paper to review formatted in RFC format I would hand it straight back and tell him to work out how to use Word or HTML. Here we have a lot of people wasting cycles over precise adherence to a formatting standard that is rubbish. If we are going to accept a crappy TXT format then stop griping about the details. There is a particular view that computing and computer expertise is some kind of exclusive priesthood and that the objective of those learned in the craft should be to preserve the obscurity and thus the value of those skills. It is a shortsighted view. The best way to maximize the value of a computing skill is to render it obsolete. Cobol programmers make more than C++ Jockeys who make more than folk who program in modern languages like Java, C# and C. Oh and please no more of the thousand years nonsense. If mankind can decipher Linear-B after three millenia on the basis of two shopping lists and an op-ed piece then there is never going to be any problem with PDF or HTML. The idea that we would lose the ability to process those formats is simply too ridiculous for words. On Mon, Jun 29, 2009 at 4:37 PM, David Morrisd...@xpasc.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. 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 -- -- 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
It is not the height of the barrier, it is the perception that people are making nit-picking objections for the sake of rubbing people's noses in the fact that they can decide where to put the bar. If this was about really about quality or readability I would be a lot more sympathetic. But when a draft is rejected because xml2rfc produces a txt file that is rejected because some nit-picker does not quite like the exact TXT format then the whole process is bogus. Just make xml2rfc the default input format and let the secretariat use the perl script of their choice to produce the output versions. Just make sure that one of those output versions is HTML. On Mon, Jun 29, 2009 at 6:26 PM, james woodyattj...@apple.com wrote: 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 -- -- 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
OPS-DIR review of draft-ietf-speermint-requirements
I reviewed the document draft-ietf-speermint-requirements-07.txt in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Informational This document discusses requirements for session peering in voice, presence, instant messaging and multimedia. 1. Is the document readable? In general, the document provides a readable listing of requirements. However additional background on the requirements could have been provided, which would make the document easier to understand. 2. Does it contain nits? Yes. See below. 3. Is the document class appropriate? Yes. 4. Does the document consider existing solutions? This is a requirements document, so it largely focuses on requirements rather than solutions. However, there are instances where the document does not sufficiently discuss existing practices. For example, in Section 3.2 the document refers to limitations of DNS in providing different responses based on the querier: However, this DNS-based solution may be limited in cases where the DNS response varies based on who sends the query (peer-dependent SBEs, see below) Notes on solution space: For advertising peer-dependent SBEs (peer variability), the solution space based on [RFC3263] is under specified and there are no know best current practices. Is DNS the right place for putting data that varies based on who asks? Content Distribution Networks (CDNs) have quite a bit of operational experience with use of DNS to provide data that varies based on who asks. Information on existing approaches is provided in RFCs 3466, 3568, and 3570. CDNs also have experience in use of application re-direct for global load balancing. I was therefore somewhat surprised that this document did not discuss or reference work on CDNs. While the document focuses on layer 5 peering, it does seem like it would be worthwhile to at least have some discussion of lower layer load balancing techniques such as anycast (e.g. RFC 4786), which when combined with DNS can be used to provide data that varies based on who asks. 5. Does the solution break existing technology? This is a requirements document, so that it doesn't specify solutions. However, as described above I would like to see a more in-depth discussion of the capabilities and limitations of existing technology. 6. Does the solution preclude future activity? As a requirements document, the goal is to guide future activity. 7. Is the solution sufficiently configurable? While the document focuses on requirements rather than solutions, I do think it would be valuable to discuss the potential service provider objectives in more detail. For example, specifying exit and entry points is a means, not an end. Within the CDN space, we have come to understand that the best server may depend on whether the goal is to optimize latency or throughput. 8. Can performance be measured? Performance metrics are discussed in Appendix A.1. 9. Does the solution scale well? Given that the document focuses on requirements, the scalability of the (as yet to be determined) solution is out of scope. 10. Is Security Management discussed? Section 5 discusses security requirements. Note that since the publication of RFC 3263, a number of additional documents have been dealt with the issue of TLS session establishment. These documents (such as draft-ietf-sip-sips) may be worth referencing in addition to RFC 3263 within Section 3.2: The mechanisms recommended for locating a peer's SBE MUST be able to convey how a peer should initiate secure session establishment. Notes : some mechanisms exist. For example, the required protocol use of SIP over TLS may be discovered via [RFC3263]. idnits 2.11.11 tmp/draft-ietf-speermint-requirements-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License
Possible TLP discussion list
Hello; I am writing this to see what people think about creating a tlp- discuss mailing list. While I hope that the need for TLP revisions will diminish after the current round is completed, it seems to several of the other Trustees and to me that it might be a good idea to have an open mailing list devoted to TLP issues. Although it will not be possible to hold all discussions with legal counsel on this list, and although the Trustees have the responsibility for approving documents issued in the Trust's name, there is no reason why much of the TLP revision wordsmithing and discussion could not be carried on a an open list. Please express interest yeah or nay here on this list Regards Marshall Eubanks ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible TLP discussion list
The TLP is the Trust Legal Provisions relating to IETF Documents. The current TLP is located here: http://trustee.ietf.org/license-info/ These Legal Provisions describe the rights and licenses that the IETF Trust grants to others with respect to IETF Contributions and IETF Documents; as well as certain restrictions, limitations and notices relating to IETF Documents pursuant to RFCs 5378 and 5377. Ray On Jun 30, 2009, at 12:54 PM, Marshall Eubanks wrote: Hello; I am writing this to see what people think about creating a tlp- discuss mailing list. While I hope that the need for TLP revisions will diminish after the current round is completed, it seems to several of the other Trustees and to me that it might be a good idea to have an open mailing list devoted to TLP issues. Although it will not be possible to hold all discussions with legal counsel on this list, and although the Trustees have the responsibility for approving documents issued in the Trust's name, there is no reason why much of the TLP revision wordsmithing and discussion could not be carried on a an open list. Please express interest yeah or nay here on this list Regards Marshall Eubanks ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Bidders Announced for RFC Production Center RFP
The IAOC received three proposals in response to the RFC Production Center RFP by the 5:00 PM EDT deadline on June 29, 2009. The proposers include: 1. Association Management Solutions, LLC www.amsl.com 2. HCL Technologies Ltd., www.hcl.in 3. Wipro Limited, www.wipro.com The IAOC anticipates having a vendor under contract in September so that a transition could begin in October. The successful bidder will assume responsibilities on January 1, 2010. Ray Pelletier IETF Administrative Director. ___ 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 16:22, Phillip Hallam-Baker wrote: It is not the height of the barrier, it is the perception that people are making nit-picking objections for the sake of rubbing people's noses in the fact that they can decide where to put the bar. In the more traditional publishing milieus of which I'm aware, that sort of perception is the shibboleth that separates the serious writers from the unpublishable wankers. Prospective authors who express a sense of entitlement to the submission of their manuscripts in formats that don't meet the requirements of the editors who review them are usually encouraged to start their own publishing outfits and see if they can do it all better by themselves. Occasionally, this encouragement is even delivered without the use of coarse language. We participants are our own acquisitions editors here, of course, so the height of the barrier is what we should be thinking about. It makes sense to me that we should be automating the mechanical screening of manuscripts coming into the slushpile so that they meet the machine-scriptable subset of the requirements of the RFC Editor as closely as possible. Are there any nitpicks the draft submission service enforces that aren't really RFC Editor requirements? What are they? Let's fix those. What I don't want to see is a lot of drafts start piling up without even coming close to meeting the *mechanical* requirements of the RFC Editor, much less the more difficult syntax requirements of the working natural language we've chosen. It won't help anyone if we allow authors to defer the process of cleaning up the formatting and boilerplate of a draft until late enough in the review cycle that major reformatting deltas look to the differencing tools like all-new content. If this was about really about quality or readability I would be a lot more sympathetic. But when a draft is rejected because xml2rfc produces a txt file that is rejected because some nit-picker does not quite like the exact TXT format then the whole process is bogus. For my part, I haven't any serious complaints about the status quo (plenty of unserious ones, but no serious ones). The process works well enough for me-- modulo the limitations imposed by our choice of archival format, and my general complaints about the open usability issues of XML2RFC on which I mostly agree with EKR, and on which I'm no more prepared to do anything about than either he or Iljitsch seems to be. So long as we are not discussing any proposals to *change* the set of approved archival formats, I'll continue to be happy-- nay, very impressed, actually-- with how well XML2RFC meets our needs, despite the its obvious warts. If we decide to open another discussion about new archival formats, then I'll be interested to follow along, but archival formats aren't on the table here-- at least, I hope not. - Shorter james: I'm far from convinced that changing the draft submission server to be more lenient is the best way to address the deficiencies in the software we're using, and I also think that opening a new discussion about archival formats will mean unleashing a yet another force-ten maelstrom of controversy that I'd prefer to observe from a very, very safe distance, i.e. one measured in parsecs. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-iana-special-ipv4-registry-01
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 resolve these comments along with any other Last Call comments you may receive. Document: draft-iana-special-ipv4-registry-01 Reviewer: Ben Campbell Review Date: 2009-06-30 IETF LC End Date: 2009-07-01 IESG Telechat date: (if known) Summary: This draft is almost ready for publication as an informational RFC. I have some minor comments that should be addressed first. Major issues: None. Minor issues: -- section 2, first paragraph: Text refers to [rfc3330bis] but there is no corresponding entry in the references section. -- section 3, 2nd paragraph: Is [date] supposed to be a reference? If so, there is no corresponding item in the references section. If not, then I don't understand the intent of ...in [date]... -- section 3, third paragraph: Should RFC5226 be a normative reference? It's not clear to me if the text means to say this draft follows the policies... or further allocations MUST follow the policies. If the second, it would require a normative reference. -- IANA considerations, 2nd to last paragraph: How does this relate to the ability to state routing scopes in item 7? Nits/editorial comments: -- section 2, paragraph 1: Should the . be a :? -- References The entries [IANA] and [RFC2928] are not referred to in the body of the draft. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Transition to new website postponed to Friday, July 17th
As announced previously, the revamped IETF website was scheduled to go live this Monday, July 6th. However, given that the .00 version Internet Draft deadline is also on Monday, we decided to postpone the switchover to avoid the possibility, however slim, that I-D submissions would be affected by a change. The new date for the website transition is Friday July 17th. The actual switchover will occur some time in the evening Pacific time, so that any issues can be addressed over the weekend, when traffic is likely to be slower. As always, please feel free to contact me if you have any questions or concerns. Regards, Alexa -- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-iana-special-ipv4-registry-01
(oops, forgot the gen-art list. Sorry for the repeat.) 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 resolve these comments along with any other Last Call comments you may receive. Document: draft-iana-special-ipv4-registry-01 Reviewer: Ben Campbell Review Date: 2009-06-30 IETF LC End Date: 2009-07-01 IESG Telechat date: (if known) Summary: This draft is almost ready for publication as an informational RFC. I have some minor comments that should be addressed first. Major issues: None. Minor issues: -- section 2, first paragraph: Text refers to [rfc3330bis] but there is no corresponding entry in the references section. -- section 3, 2nd paragraph: Is [date] supposed to be a reference? If so, there is no corresponding item in the references section. If not, then I don't understand the intent of ...in [date]... -- section 3, third paragraph: Should RFC5226 be a normative reference? It's not clear to me if the text means to say this draft follows the policies... or further allocations MUST follow the policies. If the second, it would require a normative reference. -- IANA considerations, 2nd to last paragraph: How does this relate to the ability to state routing scopes in item 7? Nits/editorial comments: -- section 2, paragraph 1: Should the . be a :? -- References The entries [IANA] and [RFC2928] are not referred to in the body of the draft. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-ietf-l3vpn-as4octet-ext-community-03
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 resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-l3vpn-as4octet-ext-community-03 Reviewer: Ben Campbell Review Date: 2009-06-30 IETF LC End Date: 2009-07-07 IESG Telechat date: (if known) Summary: This draft is ready for publication as a proposed standard. I have a couple of comments that may be worth addressing if there is other reason to revise the draft. Major issues: None Minor issues: None Nits/editorial comments: -- Abstract: ...allows to carry 4 octet autonomous system numbers Missing word(s)? -- Introduction There's no motivational text. A paragraph describing (very briefly) why you would want 4 octet extended communities might be helpful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Bidders Announced for RFC Production Center RFP
The IAOC received three proposals in response to the RFC Production Center RFP by the 5:00 PM EDT deadline on June 29, 2009. The proposers include: 1. Association Management Solutions, LLC www.amsl.com 2. HCL Technologies Ltd., www.hcl.in 3. Wipro Limited, www.wipro.com The IAOC anticipates having a vendor under contract in September so that a transition could begin in October. The successful bidder will assume responsibilities on January 1, 2010. Ray Pelletier IETF Administrative Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Transition to new website postponed to Friday, July 17th
As announced previously, the revamped IETF website was scheduled to go live this Monday, July 6th. However, given that the .00 version Internet Draft deadline is also on Monday, we decided to postpone the switchover to avoid the possibility, however slim, that I-D submissions would be affected by a change. The new date for the website transition is Friday July 17th. The actual switchover will occur some time in the evening Pacific time, so that any issues can be addressed over the weekend, when traffic is likely to be slower. As always, please feel free to contact me if you have any questions or concerns. Regards, Alexa -- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5576 on Source-Specific Media Attributes in the Session Description Protocol (SDP)
A new Request for Comments is now available in online RFC libraries. RFC 5576 Title: Source-Specific Media Attributes in the Session Description Protocol (SDP) Author: J. Lennox, J. Ott, T. Schierl Status: Standards Track Date: June 2009 Mailbox:jonat...@vidyo.com, j...@acm.org, t...@thomas-schierl.de Pages: 18 Characters: 40454 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mmusic-sdp-source-attributes-02.txt URL:http://www.rfc-editor.org/rfc/rfc5576.txt The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS TRACK] This document is a product of the Multiparty Multimedia Session Control 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
RFC 5592 on Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)
A new Request for Comments is now available in online RFC libraries. RFC 5592 Title: Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) Author: D. Harrington, J. Salowey, W. Hardaker Status: Standards Track Date: June 2009 Mailbox:ietf...@comcast.net, jsalo...@cisco.com, i...@hardakers.net Pages: 36 Characters: 82822 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-isms-secshell-18.txt URL:http://www.rfc-editor.org/rfc/rfc5592.txt This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS TRACK] This document is a product of the Integrated Security Model for SNMP 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
RFC 5590 on Transport Subsystem for the Simple Network Management Protocol (SNMP)
A new Request for Comments is now available in online RFC libraries. RFC 5590 Title: Transport Subsystem for the Simple Network Management Protocol (SNMP) Author: D. Harrington, J. Schoenwaelder Status: Standards Track Date: June 2009 Mailbox:ietf...@comcast.net, j.schoenwael...@jacobs-university.de Pages: 34 Characters: 84513 Updates:RFC3411, RFC3412, RFC3414, RFC3417 I-D Tag:draft-ietf-isms-tmsm-18.txt URL:http://www.rfc-editor.org/rfc/rfc5590.txt This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS TRACK] This document is a product of the Integrated Security Model for SNMP 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
