Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Jul 13, 2009, at 7:58 PM, Doug Ewell wrote: Why on Earth would someone use Visual Basic within Word to write a utility to convert Microsoft Word ***XML*** documents to an IETF- acceptable format, when there are much better tools for processing XML? For a third-party application to interpret the changing Word document format, even in XML form, would require extensive and ongoing support. This support would go well beyond what is currently needed to interpret the simpler xml2rfc structures. Using Word input files alone is likely to represent an effort few could afford to support. Why would someone not specifically write such a utility to ignore or reject any Word document containing executable code? Use of the bundled program language that operates at an object level can hide underlying format changes and avoid the related support effort. Using the bundled programming language likely represents the _only_ practical method for directly utilizing Word input files, as was suggested. IMHO, this was a logical conclusion. This, on the other hand, from Iljitsch van Beijnum iljitsch at muada dot com: This solves the problem that converting anything else into XML2RFC a reverse lossy process: XML2RFC needs more than what other formats can supply so automatic conversion (from, for instance, Word) is impossible. is a genuinely useful and productive counterargument against the whole word2rfc concept. Disagree. The goal would be to generate RFC and ID documents. Requiring XML2RFC intermediaries negates the benefit of using Word. Beyond security concerns related to relying upon the bundled program language, not having this feature supported in OSX or Unix represents yet another concern. Iljitsch view of XML2RFC intermediaries is not practical, but Word2rfc is not impossible when the bundled program language is used. It can be done, but it would not be wise. On Jul 13, 2009, at 1:10 PM, Julian Reschke wrote: The experimental version (http://xml.resource.org/ experimental.html) is as stable as predecessor versions; the main reason it hasn't been released is that the authors (IMHO) expected more boilerplate changes to occur. And what exactly do you mean by cryptic entries? There was little documentation for what would satisfy the nit checker a few months ago. It was a challenge to know what was needed for the rfc structure. The needed ipr parameter appeared rather cryptic. I think the right approach is to either help maintaining the TCL code, or to rewrite xml2rfc in a different language. To support the generation of MHTML, as some have suggested, the logical intermediary format seems to be XSLT (for defining xml2rfc constructs). http://tools.ietf.org/html/rfc2557 http://people.dsv.su.se/~jpalme/ietf/mhtml.html IMHO, pre-processors with roff might offer simpler and cleaner inputs, especially for the vision impaired. A post process could then generate simpler MHTML formats. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Doug Otis wrote: ... On Jul 13, 2009, at 1:10 PM, Julian Reschke wrote: The experimental version (http://xml.resource.org/experimental.html) is as stable as predecessor versions; the main reason it hasn't been released is that the authors (IMHO) expected more boilerplate changes to occur. And what exactly do you mean by cryptic entries? There was little documentation for what would satisfy the nit checker a few months ago. It was a challenge to know what was needed for the rfc structure. The needed ipr parameter appeared rather cryptic. ... Well, the @ipr value needs to capture several dimensions, such as type of IPR *and* time scale (because the IETF rules keep changing). Of course the values could be made less cryptic, but this seems to be something of a bike shed discussion, as long as the values a well documented. I think the right approach is to either help maintaining the TCL code, or to rewrite xml2rfc in a different language. To support the generation of MHTML, as some have suggested, the logical intermediary format seems to be XSLT (for defining xml2rfc constructs). We have that already (xml2rfc-XSLT-(X)HTML), in case you didn't notice. http://tools.ietf.org/html/rfc2557 http://people.dsv.su.se/~jpalme/ietf/mhtml.html IMHO, pre-processors with roff might offer simpler and cleaner inputs, especially for the vision impaired. A post process could then generate simpler MHTML formats. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 14 jul 2009, at 11:20, Doug Otis wrote: For a third-party application to interpret the changing Word document format, even in XML form, would require extensive and ongoing support. In principle, yes. In practice this would probably not be a huge deal compared to what needs to happen to conform to new ideas from the lawyers. Obviously Microsoft didn't come up with an XML file format and then push it through standardization to do all of that again a few years from now. We can expect the format to be extended, but the basic stuff will probably remain the same for a long time. (And we only need the REALLY basic stuff here!) This solves the problem that converting anything else into XML2RFC a reverse lossy process: XML2RFC needs more than what other formats can supply so automatic conversion (from, for instance, Word) is impossible. is a genuinely useful and productive counterargument against the whole word2rfc concept. Disagree. The goal would be to generate RFC and ID documents. Directly from .docx files? Requiring XML2RFC intermediaries negates the benefit of using Word. I disagree. If it were possible to generate XML2RFC format from Word format that would be extremely useful, because that way people who can work with Word can generate XML2RFC that can then be used by people who work in that format, including the RFC editor. But as I've said before, the semantic markup in XML2RFC makes it impossible to create a working XML2RFC file from an input that doesn't have the same semantic markup. Although tagging semantics can probably be a bit more pleasant in a WYSIWYG tool than in XML source, it still has all the documentation and version breaking issues that XML2RFC has, so that doesn't really buy us much. Iljitsch view of XML2RFC intermediaries is not practical, but Word2rfc is not impossible when the bundled program language is used. I was talking about a new intermediate format. What I'm thinking of is a constrained HTML. HTML can be used both as input and output in word processors and text editors with only minimal extra steps, if any. A lot of those generate atrocious HTML, but this can easily be fixed by removing everything that doesn't conform to the constraints. Converting from XML2RFC format to HTML would be lossy, so converting in the other direction would entail some manual work. But for the basic text in the middle a 1-to-1 mapping would be possible, which would help a lot. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Telechat review of draft-hollenbeck-rfc4933bis-02
On Jul 14, 2009, at 6:07 AM, Hollenbeck, Scott wrote: I have a a couple comments about the implementation report. I do not necessarily consider them blocking issues; I bring them up merely for consideration. -- The implementation report refers to RFC and draft versions that are (at least) a couple of generations old. I assume that the authors believe that they also apply to this draft, but it would be good to have an explicit assertion of that. -- It would help to have an explicit assertion whether the report author believes the standard meets the requirements to progress to draft. I think the report implies a yes, but it leaves the reader to draw that conclusion. 4933bis is a candidate for progression to Standard, not Draft Standard, as 4933 is already a Draft Standard. The implementation report was written as part of the effort to publish 3733bis (which became 4933 in May 2007) as a Draft Standard. That's why things appear dated. -Scott- Oops, sorry, I got confused on that point since the 01 review. Am I correct in assuming that you, as the author of the implementation report, believe that the it is still applicable to 4933bis, and that it meets the requirements for _full_ standard? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART Telechat review of draft-hollenbeck-rfc4933bis-02
-Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Tuesday, July 14, 2009 9:19 AM To: Hollenbeck, Scott Cc: General Area Review Team; Alexey Melnikov; ietf@ietf.org Subject: Re: Gen-ART Telechat review of draft-hollenbeck-rfc4933bis-02 On Jul 14, 2009, at 6:07 AM, Hollenbeck, Scott wrote: I have a a couple comments about the implementation report. I do not necessarily consider them blocking issues; I bring them up merely for consideration. -- The implementation report refers to RFC and draft versions that are (at least) a couple of generations old. I assume that the authors believe that they also apply to this draft, but it would be good to have an explicit assertion of that. -- It would help to have an explicit assertion whether the report author believes the standard meets the requirements to progress to draft. I think the report implies a yes, but it leaves the reader to draw that conclusion. 4933bis is a candidate for progression to Standard, not Draft Standard, as 4933 is already a Draft Standard. The implementation report was written as part of the effort to publish 3733bis (which became 4933 in May 2007) as a Draft Standard. That's why things appear dated. -Scott- Oops, sorry, I got confused on that point since the 01 review. Am I correct in assuming that you, as the author of the implementation report, believe that the it is still applicable to 4933bis, and that it meets the requirements for _full_ standard? Yes, I believe that the report is still applicable and that all requirements for progression have been met. -Scott- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART Telechat review of draft-hollenbeck-rfc4933bis-02
-Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Monday, July 13, 2009 6:23 PM To: Hollenbeck, Scott; General Area Review Team Cc: Alexey Melnikov; ietf@ietf.org Subject: Gen-ART Telechat review of draft-hollenbeck-rfc4933bis-02 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-hollenbeck-rfc4933bis-02 Reviewer: Ben Campbell Review Date: 13 July 2009 IESG Telechat date: 16 July 2009 Summary: The draft is ready for publication. However, I have a couple of minor comments about the implementation report at http://www.ietf.org/IESG/Implementations/RFCs3730-3734_implem.txt that may relate to the progression to draft standard. (I apologize for not making these comments sooner--this is the first progression to draft that I have reviewed, and only recently had thoughts on the implementation report.) Major issues: None. Minor issues: I have a a couple comments about the implementation report. I do not necessarily consider them blocking issues; I bring them up merely for consideration. -- The implementation report refers to RFC and draft versions that are (at least) a couple of generations old. I assume that the authors believe that they also apply to this draft, but it would be good to have an explicit assertion of that. -- It would help to have an explicit assertion whether the report author believes the standard meets the requirements to progress to draft. I think the report implies a yes, but it leaves the reader to draw that conclusion. 4933bis is a candidate for progression to Standard, not Draft Standard, as 4933 is already a Draft Standard. The implementation report was written as part of the effort to publish 3733bis (which became 4933 in May 2007) as a Draft Standard. That's why things appear dated. -Scott- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update to the IETF Web Site
Barry, The old WG charter pages will redirect to the new URLs, so all bookmarked links will continue to function. Regards, Alexa On Jun 24, 2009, at 1:45 PM, Barry Leiba wrote: an overhaul of the IETF web site. The goals for the new site were simple and included: 1) Make it easier for those who are new to the IETF to get involved; 2) Make it easier for experienced community members to access the tools and information they most need; and 3) Ensure that the web site is compliant with W3C standards and accessible to as many people as possible. Going at number two: I see that the URLs for the working group charters change: OLD... http://www.ietf.org/html.charters/dkim-charter.html NEW... http://www6.ietf.org/dyn/wg/charter/dkim.html The thing is that people have placed links to the working group charters in many, many places, some of which will be cumbersome to update (blogs, for example). The same is true for RFCs, and, less importantly, though not to be ignored, Internet Drafts. Because the documents don't have links off of www.ietf.org, they'll probably be OK. Please, I strongly urge you to at least make aliases so that the old .../html.charters/WGNAME-charter.html links still work. There really are links to them all over the place. Thanks... Barry Leiba --- 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
Automatically updated Table of Contents with Nroff
As I know there are quite some Nroff users still out there, this might be welcome news. While I quite like Nroff for its easy to use and readability. one of the problem that always have annoyed me with Nroff is to manually update the Table of Content. This is something where xml2rfc have a great edge, over Nroff, or at least had. So the good news is that version 1.0 of NroffEdit includes a feature for an automatically updated Table of Contents. All you need to do is to click where you want the TOC and paste it there. Once you done that it will automatically update as you change name of titles, change page locations or even add or remove titles. More information about this is no my web: http://aaa-sec.com/nroffedit/index.html I want to thank for the feedback I have received so far. If you like this or have any feedback of any kind, feel free to let me know. /Stefan ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Carl, I think the critique of the TSL work is well founded from the perspective of TAM, but there is nevertheless an important point here. While TSL might not be an ideal standard for automated trust anchor management, very much caused by its mixed scope of fields for both human and machine consumption, it has despite this become a central component for efforts in Europe, supported by the EU commission, to provide a common framework for trust in CAs in Europe. There is a substantial risk that we will see two very different approaches that at least overlap in scope, which may harm interoperability. /Stefan On 09-07-10 1:50 PM, Carl Wallace cwall...@cygnacom.com wrote: This document has been discussed previously relative to TAF. A portion of that discussion is here: http://www.imc.org/ietf-pkix/mail-archive/msg05573.html. -Original Message- From: owner-ietf-p...@mail.imc.org [mailto:owner-ietf- p...@mail.imc.org] On Behalf Of Pope, Nick Sent: Friday, July 10, 2009 4:02 AM To: 'ietf@ietf.org'; ietf-p...@imc.org Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard Perhaps the authors should be aware of the existing European Technical Specification for trust status lists (TS 102 231), which have some overlap in function with the Trust anchor list in this internet draft. This is being adopted by all EU member states as a means of publishing information on CA recognised as trustworthy under the national accreditation or supervisory schemes. To obtain a copy go to: http://pda.etsi.org/pda/queryform.asp and enter TS 102 231 in the search box. Nick Pope Thales e-Security Ltd -Original Message- From: owner-ietf-p...@mail.imc.org [mailto:owner-ietf- p...@mail.imc.org] On Behalf Of The IESG Sent: 10 July 2009 01:14 To: IETF-Announce Cc: ietf-p...@imc.org Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Trust Anchor Format ' draft-ietf-pkix-ta-format-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 ietf@ietf.org mailing lists by 2009-07-23. 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-pkix-ta-format-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag =17 759rfc_flag=0 Consider the environment before printing this mail. Thales e-Security Limited is incorporated in England and Wales with company registration number 2518805. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is only intended for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error please delete it (and all copies) from your system, please also inform us immediately on +44 (0)1844 201800 or email postmas...@thales- esecurity.com. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales e-Security Limited. ___ 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
Re: Automatically updated Table of Contents with Nroff
It's trivial to define nroff macros to create a Table of Contents. Donald = Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Tue, Jul 14, 2009 at 4:56 PM, Stefan Santessonste...@aaa-sec.com wrote: As I know there are quite some Nroff users still out there, this might be welcome news. While I quite like Nroff for its easy to use and readability. one of the problem that always have annoyed me with Nroff is to manually update the Table of Content. This is something where xml2rfc have a great edge, over Nroff, or at least had. So the good news is that version 1.0 of NroffEdit includes a feature for an automatically updated Table of Contents. All you need to do is to click where you want the TOC and paste it there. Once you done that it will automatically update as you change name of titles, change page locations or even add or remove titles. More information about this is no my web: http://aaa-sec.com/nroffedit/index.html I want to thank for the feedback I have received so far. If you like this or have any feedback of any kind, feel free to let me know. /Stefan ___ 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
Review of draft-ietf-sip-eku
I reviewed the document draft-ietf-sip-eku 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: Proposed Standard This specification documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with SIP. 1. Is the document readable? Yes. 2. Does it contain nits? 3. Is the document class appropriate? Previous EKU extensions (such as [RFC 4334]) have not been widely deployed, due to the additional operational complexity they would have introduced, and the limited benefits. Given this, and the potential interoperability impact of this document, the Experimental classification would probably be more appropriate. 4. Does the document consider existing solutions? I don't believe that the document adequately discusses transition issues, or existing practices. See below for detailed comments. 5. Does the solution break existing technology? In situations where there are pre-existing certificates without the EKU extensions, this specification could result in interoperability problems if the local policy is not carefully implemented. One concern is that the language on local policy could be used by implementers to justify refusing to support existing certificate formats. I do not think that the document adequately addresses how to manage the transition. For example, during an interim period, it would be necessary for implementations to support both legacy certificates as well as certificates with the new extensions. At some point, once the legacy certificates have expired, local policy could be changed to require only certificates with extensions. At various points in the document, I was unsure whether the term implementations was referring to implementations of this specification, or pre-existing implementations. See below for detailed comments. 6. Does the solution preclude future activity? Adding this EKU extension on the Standards Track is likely to create a need for backward compatibility in the future. 7. Is the solution sufficiently configurable? The document does not discuss what kinds of local policy are appropriate in various situations or how the local policy can be configured or managed. Some additional discussion in this area would be helpful. 8. Can performance be measured? The document does not address performance measurement. 9. Does the solution scale well? Introducing this extension into an existing large scale certificate deployments would require a lot of care, to avoid interoperability problems. 10. Is Security Management discussed? The document does not discuss how certificate interoperability issues can be dealt with, or how operational problems could be diagnosed. Detailed comments Section 3 A Certificate Authority issuing a certificate whose purpose is to bind a SIP domain identity without binding other non-SIP identities MUST include an id-kp-SIPdomain attribute in the Extended Key Usage extension value (see Section 3.1). [BA] Question: What is the definition of SIP domain identity? This is not included in the terminology section. Section 4 Section 7.1 of Domain Certificates in the Session Initiation Protocol [8] contains the steps for finding an identity (or a set of identities) in an X.509 certificate for SIP. In order to determine whether the usage of a certificate is restricted to serve as a SIP certificate only, implementations MUST perform the step given below as a part of the certificate validation: [BA] Not sure how the first sentence relates to the rest of the paragraph. Is the intent to suggest that the process for finding the identity needs to be carried out in order to make the determination? If so, then [8] would be a normative reference. o If the certificate does not contain any EKU values (the Extended Key Usage extension does not exist), it is a matter of local
Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
At 12:42 AM +0200 7/15/09, Stefan Santesson wrote: There is a substantial risk that we will see two very different approaches that at least overlap in scope, which may harm interoperability. And? Are you proposing that the IETF abandon its efforts because of the EU's? Or that the EU abandon its work because of the IETF's? Or that the two dissimilar protocols somehow be merged (in a way that would cause less, not greater, confusion)? Or something else? This is IETF Last Call. Please say what you think should happen in the IETF context with respect to this document. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Paul, I just provided information. I don't think we can do anything. It is not reasonable for IETF to accept TSL as bases for our work and it is not possible to turn EU around and abandon TSL. However, it has a value to be aware of the situation. /Stefan On 09-07-15 1:49 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: At 12:42 AM +0200 7/15/09, Stefan Santesson wrote: There is a substantial risk that we will see two very different approaches that at least overlap in scope, which may harm interoperability. And? Are you proposing that the IETF abandon its efforts because of the EU's? Or that the EU abandon its work because of the IETF's? Or that the two dissimilar protocols somehow be merged (in a way that would cause less, not greater, confusion)? Or something else? This is IETF Last Call. Please say what you think should happen in the IETF context with respect to this document. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
Sounds interesting. Do you by any chance have a source where this trivial information is available? All I have managed to get across are ways to generate a TOC in the end of the document, that you have to move manually. When doing that move, your page numbering and formatting may change. Anyway, the trick/attempt here is to generate a TOC within a WYSIWYG editor for instant view without ever touching a command line tool, and not having to index all your titles with macros, but simply through letting the tool analyze the typical Nroff I-D. /Stefan On 09-07-15 1:27 AM, Donald Eastlake d3e...@gmail.com wrote: It's trivial to define nroff macros to create a Table of Contents. Donald = Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Tue, Jul 14, 2009 at 4:56 PM, Stefan Santessonste...@aaa-sec.com wrote: As I know there are quite some Nroff users still out there, this might be welcome news. While I quite like Nroff for its easy to use and readability. one of the problem that always have annoyed me with Nroff is to manually update the Table of Content. This is something where xml2rfc have a great edge, over Nroff, or at least had. So the good news is that version 1.0 of NroffEdit includes a feature for an automatically updated Table of Contents. All you need to do is to click where you want the TOC and paste it there. Once you done that it will automatically update as you change name of titles, change page locations or even add or remove titles. More information about this is no my web: http://aaa-sec.com/nroffedit/index.html I want to thank for the feedback I have received so far. If you like this or have any feedback of any kind, feel free to let me know. /Stefan ___ 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
Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Web Linking ' draft-nottingham-http-link-header-06.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-08-11. 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-nottingham-http-link-header-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14833rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)' to Proposed Standard
The IESG has approved the following document: - 'Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) ' draft-ietf-adslmib-vdsl2-07.txt as a Proposed Standard This document is the product of the ADSL MIB Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-vdsl2-07.txt Technical Summary This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the Very High Speed Digital Subscriber Line 2 (VDSL2) interface type, which are also applicable for managing Asymmetric Digital Subscriber Line ADSL, ADSL2, and ADSL2+ interfaces. Working Group Summary The WG process was smooth with no real controversies. This is a small WG and only a small number of individuals participated in reviewing and commenting on the document. Document Quality The initial draft of the document was based on the ADSL2 MIB, and thus it has benefited from all the comments, feedback and reviews that were done on that document. The model and objects follow the ITU-T G.997.1 document. No information is available about implementations. Personnel Menahem Dodge is the Document Shepherd. Dan Romascanu is the Responsible Area Director and MIB Doctor. Clay Sikes, David Harrington and Bert Wijnen also contributed with expert reviews. RFC Editor Note In the Abstract section please expand ADSL as Assymetric Digital Subscriber Line at the first occurence. Add the following people to the list in paragraph 6 (Acknowledgments): - David B Harrington (dbharring...@comcast.net) - Smadar Tauber (smada...@rad.com) Correct the following spelling errors: 4th line on page 4 OLD: ASDSL2 NEW: ADSL2 7th line on page 4 OLD: mopdule NEW: module 3rd line in paragraph 2.1 OLD: ENITY NEW: ENTITY Page 8 OLD: Inpulse NEW: Impulse OLD: Netwrok NEW: Network OLD: transmittible NEW: transmittable 7th line from bottom of page 21 OLD: optionaly NEW: optionally 14th line on page 61 OLD: procedue NEW: procedure Middle of page 64 OLD: successfull NEW: successful 6th line on page 71 OLD: downstreasm NEW: downstream 19th line on page 71 OLD: upstreasm NEW: upstream Top of page 211 OLD: xdsl2ChAlarmConfProfileXtucThresh15MinCodingViol ations NEW: xdsl2ChAlarmConfProfileXtucThresh15MinCodingViolations OLD: xdsl2ChAlarmConfProfileXturThresh15MinCodingViol ations NEW: xdsl2ChAlarmConfProfileXturThresh15MinCodingViolations ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5603 on Ethernet Pseudowire (PW) Management Information Base (MIB)
A new Request for Comments is now available in online RFC libraries. RFC 5603 Title: Ethernet Pseudowire (PW) Management Information Base (MIB) Author: D. Zelig, Ed., T. Nadeau, Ed. Status: Standards Track Date: July 2009 Mailbox:dav...@oversi.com, tom.nad...@bt.com Pages: 23 Characters: 44125 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pwe3-enet-mib-14.txt URL:http://www.rfc-editor.org/rfc/rfc5603.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge 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 5598 on Internet Mail Architecture
A new Request for Comments is now available in online RFC libraries. RFC 5598 Title: Internet Mail Architecture Author: D. Crocker Status: Informational Date: July 2009 Mailbox:dcroc...@bbiw.net Pages: 54 Characters: 115741 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-crocker-email-arch-14.txt URL:http://www.rfc-editor.org/rfc/rfc5598.txt Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 5605 on Managed Objects for ATM over Packet Switched Networks (PSNs)
A new Request for Comments is now available in online RFC libraries. RFC 5605 Title: Managed Objects for ATM over Packet Switched Networks (PSNs) Author: O. Nicklass, T. Nadeau Status: Standards Track Date: July 2009 Mailbox:or...@radvision.com, tom.nad...@bt.com Pages: 36 Characters: 69401 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pwe3-pw-atm-mib-06.txt URL:http://www.rfc-editor.org/rfc/rfc5605.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge 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 5604 on Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs)
A new Request for Comments is now available in online RFC libraries. RFC 5604 Title: Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) Author: O. Nicklass Status: Standards Track Date: July 2009 Mailbox:or...@radvision.com Pages: 41 Characters: 80002 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pwe3-tdm-mib-11.txt URL:http://www.rfc-editor.org/rfc/rfc5604.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge 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
IETF 75 - Early Bird Cutoff and Social Event
75th IETF Meeting Stockholm, Sweden July 26-31, 2009 Host: .SE EARLY-BIRD REGISTRATION Early-Bird registration cutoff is Friday, July 17 at 17:00 PT (24:00 UTC). After that time, the registration fee will increase by $150 USD to $785 USD. Online registration for the IETF meeting is at: http://www.ietf.org/meetings/75/ LOCAL MAPS The link below is a map showing the area around the conference venue as well as the location of other IETF events: http://maps.google.com/maps/ms?ie=UTF8hl=enoe=UTF8msa=0msid=100589894371058605953.00046436ad89be4d84d44ll=59.334579,18.058927spn=0.007792,0.01929z=16 This link is to a map showing areas with restaurants close the meeting venue as well as recommendations by .SE (blue marked streets show areas with a lot of lunch restaurants): http://maps.google.com/maps/ms?ie=UTF8hl=enoe=UTF8msa=0msid=103783640006729987431.00046e305ddb5a62781e9ll=59.334596,18.061112spn=0.031168,0.077162z=14 SOCIAL EVENT Where: Vasa Museum (http://www.vasamuseet.se/InEnglish/about.aspx) When: Tuesday, July 28, 2009 Time: 7:00pm - 11:00pm Host: .SE The Vasa Museum is the most visited museum in Scandinavia. The Vasa is the world�s only surviving 17th-century ship and one of the foremost tourist sights in the world. More information and Social Registration: http://www.ietf.org/meetings/75/social-event.html Note: You must be registered for IETF 75 to purchase a Social Ticket. Only 12 days until the Stockholm IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meetings/75/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5601 on Pseudowire (PW) Management Information Base (MIB)
A new Request for Comments is now available in online RFC libraries. RFC 5601 Title: Pseudowire (PW) Management Information Base (MIB) Author: T. Nadeau, Ed., D. Zelig, Ed. Status: Standards Track Date: July 2009 Mailbox:thomas.nad...@bt.com, dav...@oversi.com Pages: 67 Characters: 129328 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pwe3-pw-mib-14.txt URL:http://www.rfc-editor.org/rfc/rfc5601.txt This memo defines a Standards Track portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge 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 5570 on Common Architecture Label IPv6 Security Option (CALIPSO)
A new Request for Comments is now available in online RFC libraries. RFC 5570 Title: Common Architecture Label IPv6 Security Option (CALIPSO) Author: M. StJohns, R. Atkinson, G. Thomas Status: Informational Date: July 2009 Mailbox:mstjo...@comcast.net, r...@extremenetworks.com, none Pages: 52 Characters: 128032 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-stjohns-sipso-11.txt URL:http://www.rfc-editor.org/rfc/rfc5570.txt This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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 5602 on Pseudowire (PW) over MPLS PSN Management Information Base (MIB)
A new Request for Comments is now available in online RFC libraries. RFC 5602 Title: Pseudowire (PW) over MPLS PSN Management Information Base (MIB) Author: D. Zelig, Ed., T. Nadeau, Ed. Status: Standards Track Date: July 2009 Mailbox:dav...@oversi.com, tom.nad...@bt.com Pages: 31 Characters: 62005 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pwe3-pw-mpls-mib-14.txt URL:http://www.rfc-editor.org/rfc/rfc5602.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge 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
