Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
David, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC ???tsv-...@ietf.org if you reply to or forward this review. Thanks for your review. Document: draft-ietf-l2vpn-vpls-mcast-14 Reviewer: David L. Black Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes multicast optimizations for VPLS via use of MPLS multicast distribution trees within the service provider (SP) network. In general, the techniques in this draft are an improvement, as they should typically result in reduction of SP network traffic required to carry the same level of multicast traffic originating from the VPLS edges. I have reviewed primarily for transport-related topics; while I don't have the expertise to review for MPLS and VPLS concerns, I'm confident in the expertise of this author team in those technologies. I found a couple of items that are effectively editorial: (1) The techniques in this draft appear to add an MPLS label to the stack in order to identify the MPLS multicast tree. Does that added label raise any MTU concerns in practice? No more than any other use of label stacking (and there are plenty of other uses of label stacking). Furthermore, rfc3032 (MPLS Label Stack Encoding) does cover the MTU issue. (2) Two techniques used by this draft - replication of traffic within a multicast tree, and flooding of traffic (section 14) - could be employed as traffic amplifiers in denial of service attacks. A short discussion of this possibility and the applicability of countermeasures described in this draft, RFC 4761 and/or RFC 4762 would be good to add to the security considerations section. The Security Consideration section already talks about 4761 and 4762: Security considerations discussed in [RFC4761] and [RFC4762] apply to this document. Suggestion on any additional text would be greatly appreciated. Yakov. David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA?? 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com?? Mobile: +1 (978) 394-7754
Time to dump X.400 support?
Looking at the extreme breach of trust by US govt re PRISM, I think it is time to do something we should have done decades ago but were stopped at US Govt request. Lets kill all support for X.400 mail. This is still in use, I know. But looking through the PKIX spec the schema is ten pages long. I count seven pages of garbage that we could kill if we abandoned support for X.400, garbage character sets no longer needed, bogus time formats, etc. etc. Certificates do not need to be as complicated as X.509v3 made them. To work with certificates issued for the Internet, an application needs to support only 20% of the PKIX schema at most. -- Website: http://hallambaker.com/
RE: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
From: Randy Bush [mailto:ra...@psg.com] i think the two paragraphs you would like to see improved are [snip] i am not against further explanation, send text. but short text. :) [WEG] just the first paragraph really, and as I'll note below - I'd love to send text, but I don't understand one of the recommendations experiments have shown that latency between cache and router, and between caches in a cache dag, is not an appreciable issue. [WEG] ok, so why is close important then? i thought bootstrap reachability would be fairly obvious to an operator. but if simple routing and no dns dependency were not obvious to you, then a few words are indeed needed. or am i missing your point here? [WEG] yes, completely obvious. Though the last two sentences of your suggested text in the other email is a useful addition what is missing from the second paragraph? [WEG] I'm actually happy with second para i am not sure it would be useful to go into the general issue of why caches should be proximal to the consumer as it is a rather well- explored area, from akamia and limelight to dns. but if you have a sentence or two that communicates this, send it over. [WEG] Generally, I understand why closer is better for content caches (Akamai/llnw) and DNS, but not for RPKI caches. You're making a link between the two that I'm not following. Both of the former benefit from proximity because it reduces latency and reduces unnecessary backhaul and potentially allows for a geographically customized service, resulting in improved user experience. If latency isn't a factor (at least in the average-sized propagation domain), and RPKI caches aren't particularly bandwidth intensive, why does proximity matter? Is this just an extension of the trust domain and limited dependence on routing protocols? If so, I'd dispense with recommending close because it confuses the issue and just keep the discussion about secondary dependencies and trust domains. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
RE: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
Yakov, First of all, thank you for overlooking the off-by-one error on the year :-) - Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Of course, 2013 was intended, twice ;-). On the two items (both are editorial, IMHO): (1) The techniques in this draft appear to add an MPLS label to the stack in order to identify the MPLS multicast tree. Does that added label raise any MTU concerns in practice? No more than any other use of label stacking (and there are plenty of other uses of label stacking). I concur, which is why I noted this item as editorial - I don't think it's an actual issue. Furthermore, rfc3032 (MPLS Label Stack Encoding) does cover the MTU issue. A sentence to that effect (lots of uses of label stacking, MTU effects are both well understood and not a problem in practice) with a reference to RFC 3032 should suffice. (2) Two techniques used by this draft - replication of traffic within a multicast tree, and flooding of traffic (section 14) - could be employed as traffic amplifiers in denial of service attacks. A short discussion of this possibility and the applicability of countermeasures described in this draft, RFC 4761 and/or RFC 4762 would be good to add to the security considerations section. The Security Consideration section already talks about 4761 and 4762: Security considerations discussed in [RFC4761] and [RFC4762] apply to this document. Suggestion on any additional text would be greatly appreciated. I'd suggest an initial sentence: Replication of traffic within a multicast tree, and flooding of traffic (see section 14) could be employed as traffic amplifiers in denial of service attacks. Followed by a sentence or sentences that list a few important applicable countermeasures (your choice), explaining why each is applicable and indicating where each is described (this document, RFC 4761 or RFC 4762). Thanks, --David -Original Message- From: Yakov Rekhter [mailto:ya...@juniper.net] Sent: Tuesday, September 24, 2013 10:27 AM To: Black, David Cc: tsv-...@ietf.org; raggarw...@yahoo.com; y.kam...@ntt.com; luf...@cisco.com; ya...@juniper.net; ietf@ietf.org; l2...@ietf.org; stbry...@cisco.com; ya...@juniper.net Subject: Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14 David, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Thanks for your review. Document: draft-ietf-l2vpn-vpls-mcast-14 Reviewer: David L. Black Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes multicast optimizations for VPLS via use of MPLS multicast distribution trees within the service provider (SP) network. In general, the techniques in this draft are an improvement, as they should typically result in reduction of SP network traffic required to carry the same level of multicast traffic originating from the VPLS edges. I have reviewed primarily for transport-related topics; while I don't have the expertise to review for MPLS and VPLS concerns, I'm confident in the expertise of this author team in those technologies. I found a couple of items that are effectively editorial: (1) The techniques in this draft appear to add an MPLS label to the stack in order to identify the MPLS multicast tree. Does that added label raise any MTU concerns in practice? No more than any other use of label stacking (and there are plenty of other uses of label stacking). Furthermore, rfc3032 (MPLS Label Stack Encoding) does cover the MTU issue. (2) Two techniques used by this draft - replication of traffic within a multicast tree, and flooding of traffic (section 14) - could be employed as traffic amplifiers in denial of service attacks. A short discussion of this possibility and the applicability of countermeasures described in this draft, RFC 4761 and/or RFC 4762 would be good to add to the security considerations section. The Security Consideration section already talks about 4761 and 4762: Security considerations discussed in [RFC4761] and [RFC4762] apply to this document. Suggestion on any additional text would be greatly appreciated. Yakov. David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA
Re: Time to dump X.400 support?
Phillip Hallam-Baker hal...@gmail.com wrote: Lets kill all support for X.400 mail. +1000. We should do this because nobody new is going to use it. The other reasons you mentioned are just icing. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpYSfDNjZbDG.pgp Description: PGP signature
Re: feedback blog entry
SM: Thanks for the feedback. I read the article. As a comment about the last paragraph, the metric being used is not the best in my humble opinion. You are referring to attendance and authoring RFCs? I agree, of course. I apologize for using a metric that is, at best, partial. My only defense is that it was what I had easily available :-( I do realise that real engagement from different types of organisations and people and areas of the world goes to far more fundamental issues than showing numbers of people. True involvement and effect is what counts. As we know, that does not necessarily correlate with any particular statistic... Spencer Dawkins made an insightful comment which I would look into if I was looking for a better metric. Ok. Which comment are you referring to? I'm sorry, too much e-mail to know what you are referring to. I'd be interested in better metrics. Jari
Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
hi wes, why does proximity matter? Is this just an extension of the trust domain and limited dependence on routing protocols? If so, I'd dispense with recommending close because it confuses the issue and just keep the discussion about secondary dependencies and trust domains. are you really saying that i should be comfortable configuring a seattle router to use a cache in tokyo even though both are in my network and there is a pretty direct hop? 1 r0.sea.rg.net (147.28.0.4) 0.189 ms 0.306 ms 0.230 ms 2 r1.sea.rg.net (147.28.0.5) 0.307 ms 0.259 ms 0.221 ms 3 sea001bf00.iij.net (206.81.80.237) 0.336 ms 0.383 ms 0.348 ms 4 tky008bf00.IIJ.net (206.132.169.110) 88.723 ms 94.377 ms 124.044 ms 5 tky001bb10.IIJ.Net (58.138.80.18) 83.639 ms 83.701 ms 89.133 ms i am willing to hack the text. but i am just not sure that proximity is not a good attribute. the longer the wire the greater the likelihood of it being cut. randy
Re: Time to dump X.400 support?
Phill, On 09/24/2013 05:25 PM, Phillip Hallam-Baker wrote: Looking at the extreme breach of trust by US govt re PRISM, I think it is time to do something we should have done decades ago but were stopped at US Govt request. Lets kill all support for X.400 mail. This is still in use, I know. But looking through the PKIX spec the schema is ten pages long. I count seven pages of garbage that we could kill if we abandoned support for X.400, garbage character sets no longer needed, bogus time formats, etc. etc. Certificates do not need to be as complicated as X.509v3 made them. To work with certificates issued for the Internet, an application needs to support only 20% of the PKIX schema at most. Sure, if we went back to the late 1990's that'd have been worth doing. And sure, if we re-invent rfc 5280 public key certs we can not include some stuff. Not that I see much benefit in re-inventing 5280 PKCs as a thing to do in and of itself. (And of course DANE includes hardly any ASN.1 nonsense if you pick the right options so we already have an option without that baggage.) But I see no benefit in messing around with rfc 5280 at this stage for fun. (I said the same to the ITU-T person who seems to want to do that with their x.509 spec the other day when the topic came up on wpkops.) So -1 to that kind of change unless there's a much better reason. S.
Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
Following this line of reasoning (which is not unreasonable); if the router requires the cache to arrive at correctness, maybe the cache should be _inside_ the router. yep. but no chance of it fitting in existing routers, and routers today don't have the crypto oomph to validate (frequently). hence rpki-rtr protocol, rfc6810. randy
Re: feedback blog entry
On 9/24/2013 1:22 PM, IETF Chair wrote: SM: Thanks for the feedback. I read the article. As a comment about the last paragraph, the metric being used is not the best in my humble opinion. You are referring to attendance and authoring RFCs? I agree, of course. I apologize for using a metric that is, at best, partial. My only defense is that it was what I had easily available :-( I do realise that real engagement from different types of organisations and people and areas of the world goes to far more fundamental issues than showing numbers of people. True involvement and effect is what counts. As we know, that does not necessarily correlate with any particular statistic... Spencer Dawkins made an insightful comment which I would look into if I was looking for a better metric. Ok. Which comment are you referring to? I'm sorry, too much e-mail to know what you are referring to. I'd be interested in better metrics. Hi, Jari, I'm not saying that I make so many insightful comments that I can't keep them straight, but I wasn't sure, either :D I'm guessing SM is referring to this one ... https://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k3=12404k4=1tid=1380055577 Spencer
Re: feedback blog entry
Hi Jari, At 11:22 24-09-2013, IETF Chair wrote: You are referring to attendance and authoring RFCs? I agree, of course. I apologize for using a metric that is, at best, partial. My only defense is that it was what I had easily available :-( I do realise that real engagement from different types of organisations and people and areas of the world goes to far more fundamental issues than showing numbers of people. True involvement and effect is what counts. As we know, that does not necessarily correlate with any particular statistic... The metric which you provided on your own time has been useful. With these statistics there wouldn't have anything to look at to get a view of IETF work. I agree that true involvement and effort is what counts. Showing the number of people might be the least bad way to understand what's happening and whether the efforts are successful. Ok. Which comment are you referring to? I'm sorry, too much e-mail to know what you are referring to. I'd be interested in better metrics. From http://www.ietf.org/mail-archive/web/ietf/current/msg79780.html It's pretty tempting for new participants to submit drafts that they like, and maybe reaching out to their office mates as co-authors, but to be effective in the IETF, participants have to learn how to collaborate with folks from other IETF sponsors How does one collaborate in the IETF? How does one contribute in the IETF? What's the level of involvement at the country level? Is the involvement from a country increasing if we look at the number of people involved? Please note that the questions are not meant as questions for you to reply to. I am not sure whether there is a way to generate statistics to get a view of the above.It may be worth pursuing if other people believe that it would be a better metric. Regards, -sm
Remote participation to igovupdate BoF
Hi, I would like to request (if possible of course) remote participation for this BoF: igovupdate I am not sure what are the proper channels for the request but I think it would be very valuable for remote participants to attend this meeting (including me that won't go to Vanc.). Thanks as
Re: Remote participation to igovupdate BoF
Hi Arturo. This BoF, like any other BoF or WG meeting, will have an audio stream and a jabber room, and comments from the Jabber room will be channeled to the room microphones. The BoF chairs (yet to be determined) or the AD MAY request that the meeting be covered with MeetEcho or WebEx. That's up to them, so you might want to contact Jari about this. Yoav On Sep 25, 2013, at 12:12 AM, Arturo Servin arturo.ser...@gmail.com wrote: Hi, I would like to request (if possible of course) remote participation for this BoF: igovupdate I am not sure what are the proper channels for the request but I think it would be very valuable for remote participants to attend this meeting (including me that won't go to Vanc.). Thanks as
Re: Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04
Hi Mary, I similarly apologize for the delay in responding. It's been a busy week. As I started to go over your responses one by one, I realized I had notated each one as WFM. So rather than send all that, I will summarize as I agree with all of your responses, and updates to these effects will resolve all of my concerns. Thanks! Ben. On Sep 16, 2013, at 2:59 PM, Mary Barnes mary.ietf.bar...@gmail.com wrote: Hi Ben, I apologize for the delay in responding. I had initially missed this review - it either got cached directly with gen-art reviews or the tools alias burped. I'm not on the main IETF list with this email address. Anyways, thank you very much for your thorough review. Our responses are below [MB]. We have an update underway that addresses your's and other's LC comments. We can forward that to you to preview if you would like. Regards, Mary. [...]
Re: Community Feedback: IETF Trust Agreement Issues
Hi Chris, At 23:48 02-08-2013, Chris Griffiths wrote: Issue 1 We have recently been asked permission to republish the TAO with a creative commons license, but according to counsel, the current trust agreement does not give the trustees the rights to do this. - Without specific language being added to the trust agreement, we cannot grant these types of requests. - The current open request for a creative commons license from 6/18/2013 cannot be completed. In term of outgoing rights the Independent Submission Stream is different from the IETF Stream. The draft version of the Tao might offer a path forward. Would it be possible to have it submitted through the Independent Submission Stream and use that version and changes to address the above request? I haven't looked into the process stuff. It might be possible [1] to sort that out once the legal hurdles are settled. Regards, -sm 1. I read the thread :-(
Re: Remote participation to igovupdate BoF
Thanks, Jabber, and audio room is enough for me. Anything else is a plus. Cheers, as On 9/24/13 6:25 PM, Yoav Nir wrote: Hi Arturo. This BoF, like any other BoF or WG meeting, will have an audio stream and a jabber room, and comments from the Jabber room will be channeled to the room microphones. The BoF chairs (yet to be determined) or the AD MAY request that the meeting be covered with MeetEcho or WebEx. That's up to them, so you might want to contact Jari about this. Yoav On Sep 25, 2013, at 12:12 AM, Arturo Servin arturo.ser...@gmail.com wrote: Hi, I would like to request (if possible of course) remote participation for this BoF: igovupdate I am not sure what are the proper channels for the request but I think it would be very valuable for remote participants to attend this meeting (including me that won't go to Vanc.). Thanks as
Re: Gen-ART LC Review of draft-ietf-karp-ops-model-07
Hi, thanks for the response. Comments inline. I've removed sections that do not appear to need further comment. On Sep 17, 2013, at 1:29 PM, Sam Hartman hartmans-i...@mit.edu wrote: genart -- This abstract claims that this draft is a discussion of genart issues. From that per spective, I don't think the use of genart 2119 language is appropriate. There are some specific areas genart (mentioned below) where 2119 language is used in imprecis genart ways, and may do harm to the reader's understanding. There genart are other uses that may be more reasonable. But I think the genart draft would be better off dispensing with 2119 language genart altogether. We disagree. I think that the draft provides requirements that if followed will make management of the security aspects of routers easier to depend on. I believe 2119 language is useful in that. I think that would be true if the intent of this draft was to create a BCP, or something to that effect. That's not what the abstract and intro say. They characterize the draft as discussing issues and begins to develop a model. If you think 2119 language is appropriate, then it might be helpful to update the abstract and intro to make it more clear that the draft offers normative guidance, and make it clear when and to whom it applies. For example, section 3 says Implementations of this model MUST... It's not clear to me what this model means when the abstract and intro make it sound like this draft is early work towards eventually developing such a model. Bottom line is, I think the problem is not with 2119 language in general so much as it is a matter of the draft being inconsistent on whether it is discussing issues that may eventually lead to a model, or actually describing such a model. I think this is well within an area where there is no IETF-wide consessus and the judgment of the individual WGs and to a lesser extent editors should control. Certainly. All I am doing is offering an opinion. genart -- Section 3, paragraph 4: genart This seems like a place where descriptive language would be genart better than 2119 lan guage. In particular, and so on genart leaves things too open ended and imprecise. Al so, the use genart of 2119 language in an example seems a bit off. So, the requirement is stated in the first clause using 2119 language: Operational Requirements: implementations of this model MUST support configuration of keys at the most general scope for the underlying protocol; The sentence goes on to apply that requirement to some common cases: protocols supporting per-peer keys MUST permit configuration of per-peer keys, protocols supporting per-interface keys MUST support configuration of per-interface keys, and so on. You might prefer different style rules; you might prefer that the restatements of the general requirement to specific situations not use 2119 language. I think the right approach for that is to try and build community consensus on those style rules and not to apply those rules until such a consensus is achieved. I do agree that care should be used when using 2119 in a restatement, but in this instance believe it is OK. I've removed the 2119 language from the example, although I think it was harmless. Ok. My concern was that it is open ended. The words and so on tells me that there may be more normative requirements that the reader is left to infer. That could make it hard to know if an implementation fully complies. [snip] genart -- section 3.2, paragraph 2: genart What distinguishes SHOULD from desirable in this context? genart That is, why use 211 9 language for one and not the other? The sentences including desirable are giving motivation for the sentences including SHOULD. That is the SHOULDS are the take-aways, the desirables are expansions/explanations of why the SHOULDS make sense. On re-reading that paragraph, I see your point and retract the comment. genart -- section 3.2, last paragraph: Implementations SHOULD genart permit a configuration i n which if no unexpired key is genart available, existing security associations continu e using genart the expired key with which they were established. genart This may need further guidance. For example, it seems risky genart to do this silently. I think this was explicitly discussed in the WG and is where we got in our discussions. There's discussion of alerts for security events elsewhere. However I think the current text represents a fairly informed WG consensus. You are correct that there is separate text on notification of security events (section 6.2), and that even mentions certificate expiration. But it doesn't explicitly mention continuing to use an expired key. I think that's important enough that it should be explicitly considered. If it was explicitly discussed in the working group,
Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
On Tue, Sep 24, 2013 at 12:26 PM, George, Wes wesley.geo...@twcable.com wrote: From: Randy Bush [mailto:ra...@psg.com] i think the two paragraphs you would like to see improved are [snip] i am not against further explanation, send text. but short text. :) [WEG] just the first paragraph really, and as I'll note below - I'd love to send text, but I don't understand one of the recommendations experiments have shown that latency between cache and router, and between caches in a cache dag, is not an appreciable issue. [WEG] ok, so why is close important then? i thought bootstrap reachability would be fairly obvious to an operator. but if simple routing and no dns dependency were not obvious to you, then a few words are indeed needed. or am i missing your point here? [WEG] yes, completely obvious. Though the last two sentences of your suggested text in the other email is a useful addition what is missing from the second paragraph? [WEG] I'm actually happy with second para i am not sure it would be useful to go into the general issue of why caches should be proximal to the consumer as it is a rather well- explored area, from akamia and limelight to dns. but if you have a sentence or two that communicates this, send it over. [WEG] Generally, I understand why closer is better for content caches (Akamai/llnw) and DNS, but not for RPKI caches. You're making a link between the two that I'm not following. Both of the [CLM] this is about the consumer of the data, right? (and convenience to the operator that hosts the cache). In the akamai/cdn example 'consumer' is 'cable/dsl/etc' user. Close is convenient-to-the-operator close to the 'cable/dsl/etc' user. Perhaps 'metro' is close enough for CDNs, balancing latency and backhaul requirements. In the RPKIcache example, 'consumer' is 'routers in your network'. 'Close' is 'close enough that bootstrapping isn't a problem', balanced with 'gosh, maybe I don't want to put one on top of each router! plus associated management headaches to deal with these new systems/appliances'. former benefit from proximity because it reduces latency and reduces unnecessary backhaul and potentially allows for a geographically customized service, resulting in improved user experience. If latency isn't a factor (at least in the average-sized propagation domain), and RPKI caches aren't particularly bandwidth intensive, why does proximity matter? Is this just an extension of the trust domain and limited dependence on routing protocols? If so, I'd dispense with recommending close because it confuses the issue and just keep the discussion about secondary dependencies and trust domains. [CLM] I guess one way is to say: People should understand the dependencies and engineer appropriately ... which you kind of asked to not say in the original comment. (or is the issue that the dependencies aren't clear?) Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ sidr mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: Time to dump X.400 support?
On Tue, Sep 24, 2013 at 3:19 PM, Stephen Farrell stephen.farr...@cs.tcd.iewrote: Phill, On 09/24/2013 05:25 PM, Phillip Hallam-Baker wrote: Looking at the extreme breach of trust by US govt re PRISM, I think it is time to do something we should have done decades ago but were stopped at US Govt request. Lets kill all support for X.400 mail. This is still in use, I know. But looking through the PKIX spec the schema is ten pages long. I count seven pages of garbage that we could kill if we abandoned support for X.400, garbage character sets no longer needed, bogus time formats, etc. etc. Certificates do not need to be as complicated as X.509v3 made them. To work with certificates issued for the Internet, an application needs to support only 20% of the PKIX schema at most. Sure, if we went back to the late 1990's that'd have been worth doing. And sure, if we re-invent rfc 5280 public key certs we can not include some stuff. Not that I see much benefit in re-inventing 5280 PKCs as a thing to do in and of itself. (And of course DANE includes hardly any ASN.1 nonsense if you pick the right options so we already have an option without that baggage.) But I see no benefit in messing around with rfc 5280 at this stage for fun. (I said the same to the ITU-T person who seems to want to do that with their x.509 spec the other day when the topic came up on wpkops.) So -1 to that kind of change unless there's a much better reason. I wasn't thinking so much of re-opening RFC5280 as declaring them obsolete with the intention to remove them in future editions should those ever occur. Perhaps of more immediate effect, can we revisit the issue of OCSP responders having to report 'VALID' for a non existent certificate? Every one of the people who objected is a US government contractor and the only party that purportedly has a difficulty with the idea that an OCSP responder should be able to provide a definitive statement is the US DoD. As I pointed out in the wake of FLAME, this particular change would have made it easier to detect the type of attack performed on Microsoft in the FLAME malware. -- Website: http://hallambaker.com/
JOSE WG Virtual Interim Meeting Rescheduled: 7 October 2013, 2300 UTC
The JOSE WG virtual interim planned originally for Monday, September 30th will be rescheduled for Monday, October 7th. The time will remain unchanged 2300 UTC time slot (4 pm PTD, 7 pm EDT) The goal of this meeting will be to address issues in the issue tracker. Detailed agendas and webex instructions will follow on the jose mailing list. http://www.ietf.org/mail-archive/web/jose/current/maillist.html
