Re: Hyatt Taipei cancellation policy?
On 8/30/2011 2:30 PM, Ole Jacobsen wrote: Dean, Before you give up completely I would check out: http://wikitravel.org/en/Taipei Taxis are not expensive, the Metro even less so, and there are at least some budget hotels nearby. I expect the local hosts to provide more information soon -- they already have some info on the website. I agree about the Hyatt hotel price. I agree with Ole. Staying in a different hotel (easily found for $150/night in TPE) will give some budget back into the taxi column, and they're inexpensive in TPE. The Metro even more so. Case in point: I stayed at a $120/night hotel in Quebec, so I didn't mind spending $7 on a taxi when it rained and I couldn't walk. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [sidr] Last Call: draft-ietf-sidr-ghostbusters-12.txt (The RPKI Ghostbusters Record) to Proposed Standard
The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The RPKI Ghostbusters Record' draft-ietf-sidr-ghostbusters-12.txt as a Proposed Standard note that some apps-area fixes have caused me to revise to -13 randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-melnikov-mmhs-header-fields-04.txt (Registrationof Military Message Handling System (MMHS) header fields foruse in Internet Mail) to Informational RFC
I notice that section 3, to which IANA are directed, contains many formulations such as Specification document(s): [[anchor14: this document]] Would I be right in thinking that this is what other documents would refer to as RFC -- Note to RFC-Editor - replace RFC by the RFC Number assigned to this document ? Tom Petch - Original Message - From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Sent: Wednesday, September 14, 2011 9:53 PM Subject: Last Call: draft-melnikov-mmhs-header-fields-04.txt (Registrationof Military Message Handling System (MMHS) header fields foruse in Internet Mail) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail' draft-melnikov-mmhs-header-fields-04.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-12. 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. Abstract A Miltary Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2. This document describes a method for enabling those MMHS Elements of Service that are defined as Heading Extension to be encoded as RFC 5322 (Internet Email) message header fields. These header field definitions support the provision of a STANAG 4406 MMHS over Internet Email, and also provides for a STANAG 4406 / Internet Email Gateway supporting message conversion compliant to this specification. The file can be obtained via http://datatracker.ietf.org/doc/draft-melnikov-mmhs-header-fields/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-melnikov-mmhs-header-fields/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-melnikov-mmhs-header-fields-04.txt (Registrationof Military Message Handling System (MMHS) header fields foruse in Internet Mail) to Informational RFC
t.petch wrote: I notice that section 3, to which IANA are directed, contains many formulations such as Specification document(s): [[anchor14: this document]] Would I be right in thinking that this is what other documents would refer to as RFC -- Note to RFC-Editor - replace RFC by the RFC Number assigned to this document ? Yes, that was the intent. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-vcarddav-birth-death-extensions-00.txt (vCard Format Extensions : place of birth, place and date of death) to Proposed Standard
14.09.2011 20:14, Simon Perreault wrote: Mykyta Yevstifeyev wrote, on 09/14/2011 01:10 PM: Of course, you should have changed all references to vCard 4 to vCard 5, and reference to VCARDDAV WG draft to RFC 6350. vCard 4 is the latest version, specified in RFC 6350. We'll make a note to the RFC Editor to update the references. Yes, I thought RFC 6350 defined vCard 5 and its predecessor - vCard 4. My apologies. Mykyta Yevstifeyev Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-melnikov-mmhs-header-fields-04.txt (Registrationof Military Message Handling System (MMHS) header fields foruse in Internet Mail) to Informational RFC
15.09.2011 11:59, Alexey Melnikov wrote: t.petch wrote: I notice that section 3, to which IANA are directed, contains many formulations such as Specification document(s): [[anchor14: this document]] Would I be right in thinking that this is what other documents would refer to as RFC -- Note to RFC-Editor - replace RFC by the RFC Number assigned to this document ? There is no significant difference between these forms. I don't think this is an issue which we need to care about. Mykyta Yes, that was the intent. ___ 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: Last Call: draft-melnikov-mmhs-header-fields-04.txt (Registrationof Military Message Handling System (MMHS) header fields foruse in Internet Mail) to Informational RFC
Mykyta Yevstifeyev wrote: 15.09.2011 11:59, Alexey Melnikov wrote: t.petch wrote: I notice that section 3, to which IANA are directed, contains many formulations such as Specification document(s): [[anchor14: this document]] Would I be right in thinking that this is what other documents would refer to as RFC -- Note to RFC-Editor - replace RFC by the RFC Number assigned to this document ? There is no significant difference between these forms. I don't think this is an issue which we need to care about. Agreed. I think RFC Editor can figure this out. Mykyta Yes, that was the intent. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-melnikov-mmhs-header-fields-04.txt (Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail) to Informational RFC
So some small comments: 1) A nit in Change controller field for all the header fields: you should either change it to IESG (i...@ietf.org) or IETF with subsequent address ietf@ietf.org. 2) Also, it might be useful to point out in the sub-sections of Section 3 which ABNF productions do the header fields match. 3) Section 4: Terms not defined here are taken from [RFC5322] and [RFC2156]. You probably missed RFC 5234 (with e. g. DQUOTE) here. Some ABNF nits: 4) military-string = 1*69( ps-char ) No harm to change it to 1*69ps-char 5) std-precedence = deferred / routine / priority / immediate / flash / override std-message-type = exercise / operation / project / drill Is there an ability to extend the allowed range of parameters here? 6) nonneg-integer = 0 / (NZ-DIGIT *DIGIT) Should this be nonneg-integer = 0 / ( [ + ] NZ-DIGIT *DIGIT) as non-negative integer implies that it may be prepended by + (as well as zero - I don't know exactly). 7) military-string-sequence = military-string [ [FWS] ; [FWS] military-string-sequence ] I think military-string-sequence = military-string [ [FWS] ; [FWS] military-string ] is just the same but improves readability (unless you make this intentionally, but I see no reason). 8) Subject-Indicator-Codes = MMHS-Subject-Indicator-Codes: [FWS] [sic-sequence] [FWS] CRLF Can the header field appear to be: MMHS-Subject-Indicator-Codes: as you allow. Maybe removing [] around sic-sequence? 9) I'd like you hereby disallowed further registration of header fields beginning with MMHS, likewise RFC 5504 Downgraded prefix (http://tools.ietf.org/html/rfc5504#page-18). Mykyta Yevstifeyev 14.09.2011 22:53, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail' draft-melnikov-mmhs-header-fields-04.txt as an Informational RFC ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-melnikov-mmhs-header-fields-04.txt (Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail) to Informational RFC
On 2011-09-15 18:46, Mykyta Yevstifeyev wrote: ... 9) I'd like you hereby disallowed further registration of header fields beginning with MMHS, likewise RFC 5504 Downgraded prefix (http://tools.ietf.org/html/rfc5504#page-18). ... No. It's a bad idea in RFC 5504, and it would be a bad idea here. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Pre-IETF RFCs to Historic (not really proposing)
Dear all, I've recently received a message from Ronald Bonica, one of the ADs, proposing undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic. However, I initially had a concern regarding community consensus on such effort, and whether it will be accepted so that the IESG may claim the former. Since I've already suggested a very similar proposal, and there was a negative reaction of community, I assumed the same would happen in the case Ronald pursued the work and forwarded it to the IESG. So am I right? Mykyta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [PWE3] Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC
I do not have a strong opinion on historical vs. experimental but I want to say that solutions based on RFC 6074 (so called BGP-AD) have been deployed in multiple networks some of them with mixed vendor environment. -Original Message- From: pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Tuesday, September 13, 2011 1:15 PM To: Luca Martini Cc: l2...@ietf.org; pwe3; IETF Discussion Subject: Re: [PWE3] Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Luca, The draft in question exists for almost 8 years (the -00 version has been posted 2004-01-13), has been implemented and deployed. I have not heard that solutions compliant with RFC 6074 (which is the proper analog of 4447 in this case IMO) have been deployed in this interval - and that in spite of 6074 sitting in the RFC Editor queue (i.e., sufficiently stable for any potential implementer) for almost 6 years (from 2006-06-12). Hence I do not see this case as similar to what happened to the original draft-martini vs. RFC 4447. Do I miss something substantial here? Regards, Sasha From: Luca Martini [lmart...@cisco.com] Sent: Tuesday, September 13, 2011 9:16 PM To: Alexander Vainshtein Cc: l2...@ietf.org; pwe3; IETF Discussion; Andrew G. Malis Subject: Re: Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC On 09/13/11 10:03, Alexander Vainshtein wrote: Luca, and all, I concur with Andy's opinion that the reference to RFC 4447 must become Normative (this will not delay the publication is too often the case:-). As for Informational vs. Historical, I think that Informational is more appropriate because, AFAIK, the technique defined in draft-kompella is not just a documenting an existing solution - it describes is THE ONLY deployed solution for the problem. (If this statement happens to be factually incorrect, I would be happy to learn about the deployed alternatives.) no, there are several ( I think 3 ) implementations of the l2vpn-singalling standards track document also known as rfc6074. There are several deployments of rfc6074. As 10 years ago we had several deployments of draft-martini which over time are being updated to rfc4447 , there are some deployments of the solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still think that an historical RFC would fit this solution , unless we plan on expanding it , and pursuing new enhancements to it. Luca Regards, Sasha -Original Message- From: l2vpn-boun...@ietf.org [mailto:l2vpn-boun...@ietf.org] On Behalf Of Luca Martini Sent: Tuesday, September 13, 2011 6:24 PM To: Andrew G. Malis Cc: l2...@ietf.org; pwe3; IETF Discussion Subject: Re: Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC I concurr with Andy. Given that the WG has made a decision on which control plane technology is the standard track technology we should have a statement in this document pointing to the standard track rfc4447 so it is clear to anyone reading the document. In the same way we published the draft-martini documents as historical ee should publish this document as historical rfc, to document existing implementations. Luca On 09/01/11 05:42, Andrew G. Malis wrote: Speaking as an individual, the solution in this draft has been has been operationally deployed in a number of service provider networks, and it should be documented in an informational RFC. Speaking as PWE3 co-chair, I would be happier if this draft required that routers that implement this solution also implement RFC 4447, that RFC 4447 be configured as the default mechanism for pseudowire signaling, and that RFC 4447 was moved from an informational to a normative reference. In practice, I know that routers that implement this also do implement RFC 4447, but I would like to see it in the RFC as well. Thanks, Andy Subject:Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Date: Tue, 30 Aug 2011 10:50:05 -0700 From: The IESG iesg-secret...@ietf.org mailto:iesg-secret...@ietf.org Reply-To: ietf@ietf.org mailto:ietf@ietf.org To: IETF-Announce ietf-annou...@ietf.org mailto:ietf-annou...@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling' draft-kompella-l2vpn-l2vpn-07.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send
Re: Pre-IETF RFCs to Historic (not really proposing)
My recollection is that this has already been done to a large degree. Also, focusing on this specific set of RFCs would be a lot of work, for very little actual value to the community. On the other hand, I'd be very much in favor of IETF periodically reviewing ALL standards-track RFCs for applicability. But reclassifying as Historic is rarely appropriate. Instead what should be done is to write an applicability statement for the protocols for which none exist, or for which the previous applicability statements are no longer correct. Keith On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev wrote: Dear all, I've recently received a message from Ronald Bonica, one of the ADs, proposing undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic. However, I initially had a concern regarding community consensus on such effort, and whether it will be accepted so that the IESG may claim the former. Since I've already suggested a very similar proposal, and there was a negative reaction of community, I assumed the same would happen in the case Ronald pursued the work and forwarded it to the IESG. So am I right? Mykyta ___ 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: Pre-IETF RFCs to Historic (not really proposing)
I'm fully supportive of reclassifying any RFCs that pose a risk to the Internet to historic but fail to see the usefulness of doing so for RFCs that describe unused but non-harmful technologies - seems like busywork and useless at best. Scott On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev wrote: Dear all, I've recently received a message from Ronald Bonica, one of the ADs, proposing undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic. However, I initially had a concern regarding community consensus on such effort, and whether it will be accepted so that the IESG may claim the former. Since I've already suggested a very similar proposal, and there was a negative reaction of community, I assumed the same would happen in the case Ronald pursued the work and forwarded it to the IESG. So am I right? Mykyta ___ 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: Pre-IETF RFCs to Historic (not really proposing)
ps - as Keith points out - a round of this type of effort was undertaken by the newtrk working group a while back (I was the chair and did not see much reason to do so at the time but there was consensus in the WG to proceed) - I will note that it took quite a bit of work to ensure that technologies were actually unused Scott On Sep 15, 2011, at 2:36 PM, Scott O Bradner wrote: I'm fully supportive of reclassifying any RFCs that pose a risk to the Internet to historic but fail to see the usefulness of doing so for RFCs that describe unused but non-harmful technologies - seems like busywork and useless at best. Scott On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev wrote: Dear all, I've recently received a message from Ronald Bonica, one of the ADs, proposing undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic. However, I initially had a concern regarding community consensus on such effort, and whether it will be accepted so that the IESG may claim the former. Since I've already suggested a very similar proposal, and there was a negative reaction of community, I assumed the same would happen in the case Ronald pursued the work and forwarded it to the IESG. So am I right? Mykyta ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pre-IETF RFCs to Historic (not really proposing)
On 15 September 2011 20:39, Scott O Bradner wrote: as Keith points out - a round of this type of effort was undertaken by the newtrk working group a while back About five years back, IIRC, and with some limiting parameters. I think this clean up was brilliant, and a new round with new parameters would be a very good thing. I will note that it took quite a bit of work to ensure that technologies were actually unused Again IIRC, you somehow created a list of candidates, and folks could object if they felt that something is still used. If a new round picks only RFCs at a time when the concept of normative references already existed it might be slightly less work. -Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-melnikov-mmhs-header-fields-04.txt (Registration of Military Message Handling System (MMHS) header fields for use in Internet Mail) to Informational RFC
On 9/15/11 11:11 AM, Julian Reschke wrote: On 2011-09-15 18:46, Mykyta Yevstifeyev wrote: ... 9) I'd like you hereby disallowed further registration of header fields beginning with MMHS, likewise RFC 5504 Downgraded prefix (http://tools.ietf.org/html/rfc5504#page-18). ... No. It's a bad idea in RFC 5504, and it would be a bad idea here. +1 to that! Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pre-IETF RFCs to Historic (not really proposing)
On Sep 15, 2011, at 3:17 PM, Frank Ellermann wrote: On 15 September 2011 20:39, Scott O Bradner wrote: as Keith points out - a round of this type of effort was undertaken by the newtrk working group a while back About five years back, IIRC, and with some limiting parameters. I think this clean up was brilliant, and a new round with new parameters would be a very good thing. I will note that it took quite a bit of work to ensure that technologies were actually unused Again IIRC, you somehow created a list of candidates, and folks could object if they felt that something is still used. Problem is, the IETF isn't really big enough to have a good idea about whether some technologies are still used. Example: A few years ago I started doing some work in an industry which makes extensive use of 3-way FTP, because they have very large files that they have to move around, and they need for those transfers to be mediated by 3rd parties. IIRC, the prevailing view in the IETF ftpext working group was that 3-way FTP was obsolete and should be deprecated due to security issues and because it wouldn't work through NATs. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pre-IETF RFCs to Historic (not really proposing)
On 9/15/11 11:45 AM, Mykyta Yevstifeyev wrote: undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic. Given that these are pre-IETF RFCs, I move that we create a new designation of Pre-Historic. /psa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pre-IETF RFCs to Historic (not really proposing)
Keith Moore wrote: Problem is, the IETF isn't really big enough to have a good idea about whether some technologies are still used. +1 Another example: TLS Transport Layer Security. If you look at the approx. current usage of the existing protocol revisions: SSLv3 (1996): 5% TLSv1.0 (1999): 90% TLSv1.1 (2006): 5% TLSv1.2 (2008): 0% If we would base the decision to move a protocol revision to historic on the usage 2 years after publication, then for TLS, we clearly should have moved TLSv1.2 (rfc5246) to historic this year because of its complete failure in the marketplace. Instead, a document describing SSLv3 was (finally) published as historic informational RFC this year. I hope we can get the critical mass (and get over blocking issues of pride) to fix the problems that stick like buckets of concrete on the feet of TLSv1.2 one of these days... -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pre-IETF RFCs to Historic (not really proposing)
I'm speaking as an individual, albeit an individual who helped with the decrufting effort in NEWTRK ... http://www.ietf.org/rfc/rfc4450.txt, for those who missed it. undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs as Historic. Given that these are pre-IETF RFCs, I move that we create a new designation of Pre-Historic. I think Peter's suggestion is brilliant, but it point out a disagreement about what Historic means, in the IETF. Quoting Keith Moore, from later in this thread: Problem is, the IETF isn't really big enough to have a good idea about whether some technologies are still used. Keith is mirroring the criteria used in the RFC 4450 decrufting effort, which was not reflecting documented practice in the world today, which the IETF community isn't well-placed to know. So moving things to Historic is Really Hard. A different but related problem is that moving a specification to Historic, for at least a significant part of the community, doesn't just mean it's old, it means and you shouldn't use it. The issue *I* thought we were dealing with in the decrufting effort wasn't specifications that had been superceded or otherwise obsolete (the RFC 2026 definition of Historic); the problem was specifications that no one still active in the IETF had worked on - or at least, no one would admit it! - and no one was willing and able to work on. I thought at the time that our criteria shouldn't be whether anyone was USING the specification, what mattered was whether anyone in the community had the interest and expertise to maintain or extend the specification. It's not as if the RFCs disappear in a puff of smoke when they are recategorized, ... I was in the rough on that one in 2005, but since we're looking at another bulk recategorization effort, I might make this suggestion again - perhaps we could define a new level, which might be called something like Not Maintained, with the criteria as, we can't identify anyone who is willing and able to maintain the specification That's actually something the IETF COULD know. We could ask, and if we hear crickets, Not Maintained. If somebody shows up later, recategorize. No presumption that you shouldn't use the specification, only that you shouldn't expect the IETF to maintain it. And if that's a problem for you, please feel free to start identifying people who are willing and able to maintain it. If Mykyta was planning to identify pre-IETF RFCs as Not Maintained, that might be less controversial. And I'll leave the suggestion to move the Historic parts of 2026 to Historic, to someone else :D Spencer, as an individual ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pre-IETF RFCs to Historic (not really proposing)
Indeed. In fact there is a conversation currently on the pppext WG list in which certain people are claiming that PPP (?!) is obsolete, demonstrating that even subject-matter experts are often clueless about what's happening in the real world... Sent from Samsung tablet Keith Moore mo...@network-heretics.com wrote: On Sep 15, 2011, at 3:17 PM, Frank Ellermann wrote: On 15 September 2011 20:39, Scott O Bradner wrote: as Keith points out - a round of this type of effort was undertaken by the newtrk working group a while back About five years back, IIRC, and with some limiting parameters. I think this clean up was brilliant, and a new round with new parameters would be a very good thing. I will note that it took quite a bit of work to ensure that technologies were actually unused Again IIRC, you somehow created a list of candidates, and folks could object if they felt that something is still used. Problem is, the IETF isn't really big enough to have a good idea about whether some technologies are still used. Example: A few years ago I started doing some work in an industry which makes extensive use of 3-way FTP, because they have very large files that they have to move around, and they need for those transfers to be mediated by 3rd parties. IIRC, the prevailing view in the IETF ftpext working group was that 3-way FTP was obsolete and should be deprecated due to security issues and because it wouldn't work through NATs. Keith ___ 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
Weekly posting summary for ietf@ietf.org
Total of 155 messages in the last 7 days. script run at: Fri Sep 16 00:53:02 EDT 2011 Messages | Bytes| Who +--++--+ 16.77% | 26 | 16.19% | 201369 | to...@isi.edu 12.90% | 20 | 15.71% | 195482 | mo...@network-heretics.com 6.45% | 10 | 5.64% |70202 | evniki...@gmail.com 5.81% |9 | 4.72% |58783 | john-i...@jck.com 5.16% |8 | 4.83% |60047 | n...@cryptonector.com 4.52% |7 | 5.46% |67973 | sant9...@gmail.com 3.23% |5 | 2.80% |34778 | barryle...@computer.org 1.94% |3 | 2.44% |30414 | flu...@cisco.com 1.94% |3 | 2.33% |28951 | lmart...@cisco.com 2.58% |4 | 1.62% |20094 | stpe...@stpeter.im 1.94% |3 | 1.70% |21188 | b...@nostrum.com 1.94% |3 | 1.68% |20866 | hous...@vigilsec.com 1.94% |3 | 1.66% |20651 | brian.e.carpen...@gmail.com 1.29% |2 | 2.25% |27978 | lars.egg...@nokia.com 1.29% |2 | 2.09% |25983 | alexander.vainsht...@ecitele.com 1.94% |3 | 1.36% |16888 | s...@harvard.edu 1.29% |2 | 1.37% |16996 | nar...@us.ibm.com 1.29% |2 | 1.27% |15845 | gmail.sant9...@winserver.com 1.29% |2 | 1.27% |15792 | daedu...@btconnect.com 1.29% |2 | 1.21% |15074 | spen...@wonderhamster.org 1.29% |2 | 1.17% |14555 | sshep...@microsoft.com 1.29% |2 | 1.14% |14222 | jari.ar...@piuha.net 1.29% |2 | 1.12% |13960 | s...@resistor.net 1.29% |2 | 0.98% |12151 | hartmans-i...@mit.edu 1.29% |2 | 0.79% | 9798 | m...@sap.com 1.29% |2 | 0.79% | 9793 | alexey.melni...@isode.com 0.65% |1 | 1.14% |14187 | kire...@juniper.net 0.65% |1 | 1.09% |13534 | stbry...@cisco.com 0.65% |1 | 1.08% |13425 | florin.ba...@alcatel-lucent.com 0.65% |1 | 1.03% |12783 | craig.everh...@netapp.com 0.65% |1 | 1.00% |12457 | cb.li...@gmail.com 0.65% |1 | 1.00% |12423 | ferna...@gont.com.ar 0.65% |1 | 0.86% |10648 | tnad...@lucidvision.com 0.65% |1 | 0.83% |10359 | rog...@gmail.com 0.65% |1 | 0.81% |10079 | glenz...@gmail.com 0.65% |1 | 0.69% | 8623 | d...@dcrocker.net 0.65% |1 | 0.67% | 8358 | j...@joelhalpern.com 0.65% |1 | 0.64% | 7907 | m...@lilacglade.org 0.65% |1 | 0.59% | 7392 | do...@mail-abuse.org 0.65% |1 | 0.57% | 7122 | i...@adambarth.com 0.65% |1 | 0.56% | 6973 | satoru.matsush...@gmail.com 0.65% |1 | 0.53% | 6615 | robert.thur...@oracle.com 0.65% |1 | 0.49% | 6137 | dw...@cisco.com 0.65% |1 | 0.46% | 5678 | eburge...@standardstrack.com 0.65% |1 | 0.43% | 5396 | hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com 0.65% |1 | 0.42% | 5254 | mo...@necom830.hpcl.titech.ac.jp 0.65% |1 | 0.41% | 5130 | a...@sneep.net 0.65% |1 | 0.39% | 4796 | julian.resc...@gmx.de 0.65% |1 | 0.37% | 4632 | simon.perrea...@viagenie.ca 0.65% |1 | 0.35% | 4371 | ra...@psg.com +--++--+ 100.00% | 155 |100.00% | 1244112 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pre-IETF RFCs to Historic (not really proposing)
On Sep 15, 2011, at 6:44 PM, Spencer Dawkins wrote: I was in the rough on that one in 2005, but since we're looking at another bulk recategorization effort, I might make this suggestion again - perhaps we could define a new level, which might be called something like Not Maintained, with the criteria as, we can't identify anyone who is willing and able to maintain the specification That's actually something the IETF COULD know. We could ask, and if we hear crickets, Not Maintained. If somebody shows up later, recategorize. Part of the problem is the expectation that some single label should entirely define the status of a specification. There are several almost-orthogonal variables that the community cares about (or should care about): - currency - does the document (still) reflect best current practice for implementations of this protocol to work well? - maintenance status - is the specification still being actively maintained? - technical soundness - does the protocol described meet current criteria for technical soundness? (okay, this is similar to currency) - applicability - is this protocol (still) recommended for general use in this space, or for use only in corner cases, or is its use generally discouraged (presumably in favor of something else)? - maturity - has this specification been implemented for long enough and enough times to have confidence in the quality of the protocol described and the specification for it? - market penetration - is the protocol widely used in practice? is it generally necessary for applications in this space to support it? Trying to collapse all of these into X standard / informational / experimental / historic quite naturally leads to some tension between different interpretations of those terms. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Conclusion of the last call on draft-housley-two-maturity-levels
I thought the counting of votes was finished on this topic but people seem to keep emailing their support/lack-of, so naturally I will be a good lemming and do the same. 1) I am in favor of the two-maturity-levels draft and change. I have consulted a textbook on Euclidean geometry and determined that the distance from level 2 to 1 is shorter than 3 to 1, getting us closer to the actual location most of us are at (which is of course 1 maturity level). 2) I am strongly opposed to draft-loughney-newtrk-one-size-fits-all-01, because it is far too rational and sane, and would prevent this topic from continuing forever. Furthermore, I am against any move to 1 maturity level because apparently there are one or two people with so much free time or posterity they actually bother moving PS to higher levels these days, and who are we to squash their hobby/passion/disorder? (In fact, I was almost going to suggest we go to a 4 or 5 maturity level process just to give these people more harmless things to do, but I digress...) 3) The IESG should be applauded/thanked for recognizing there is only one maturity level (PS), and taking the steps necessary to treat potential RFCs as such from a quality perspective. But they should be denigrated for not telling us they did that. So they come out even. 4) Regarding the discussion in this thread about what types of comments should be counted or not: I believe we should produce a new RFC concerning what response phrases in emails are going to be counted or not for consensus counting, so that we may know what to say in the future to get our votes counted. (Of course the big question everyone wants to know is when will such a new RFC reach the second maturity level?) -hadriel p.s. in all seriousness, I'm in favor of this two-maturiy-level draft. I do not think it is change for change's sake, but rather a change attempting to accommodate differing viewpoints of our present location and where we want to be. If it fails to change the status-quo of 1 level, that's *OK*, we can try again - the Internet won't collapse because of this document, and neither will the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Document Action: 'Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)' to Informational RFC (draft-ietf-radext-crypto-agility-requirements-07.txt)
The IESG has approved the following document: - 'Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)' (draft-ietf-radext-crypto-agility-requirements-07.txt) as an Informational RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-crypto-agility-requirements/ Technical Summary This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS) as well as the process by which crypto-agility solutions will be developed and published by the RADEXT working group. Crypto- agility is defined as the ability of RADIUS implementations to automatically negotiate cryptographic algorithms for use in RADIUS exchanges, including the algorithms used to integrity protect and authenticate RADIUS packets and to hide RADIUS attributes. Negotiation of cryptographic algorithms may occur within the RADIUS protocol, or within a lower layer such as the transport layer. Working Group Summary The document has adequate review from members of the community. Work on crypto-agility requirements began at IETF 66. A working definition of crypto-agility was discussed during the RADEXT WG session at IETF 68. The initial WG last call completed on August 10, 2008, and the WG last call issues were resolved at IETF 73 and on the mailing list. The document was then reviewed by the Security Area Director (Pasi Eronen) on February 18, 2009. The major items brought up during this review and subsequent discussions related to the role of automated key management, as well as security properties such as perfect forward secrecy. The final RADEXT WG last call completed on May 1, 2011. There appears to be strong consensus behind the document. Document Quality The document has been reviewed by participants within the IETF RADEXT WG, as well as by external reviewers. It has completed two RADEXT WG last calls. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
