Re: [Gen-art] Gen-ART review of draft-ietf-abfab-eapapplicability-05
And the -05 version includes the text to address that editorial nit - it's ready for publication as a Proposed Standard RFC. Many thanks to the authors for productively addressing the review comments. And many thanks to you, David, for your review. Based on this review and my own review of this document, I have balloted Yes on the document. Jari
Re: The case of dotless domains
Hi Doug, At 22:38 15-07-2013, Doug Barton wrote: Interesting, but pardon my being blunt, it does not seem to cover any new ground. You did say one useful thing: IETF specifications usually provide guidance to ensure interoperability. Whether dotless domains are harmful or not is a policy matter. It's a -00 draft. The above paragraph is one of the two arguments in the draft. Can you (or Ofer) define how you're using the terms explicit and implicit in terms of DNS search, and what their relevance is to the topic of dotless domains? And no, I'm not being snarky, I think part of the problem here is a fundamental misunderstanding of how the vast majority of hosts are configured currently. Speaking for myself, I would say that explicit is what the user configured and implicit is what the is not used-configured. I haven't seen anyone in the IETF arguing that the moon is made of green cheese either. What does your comment have to do with anything? Sorry (again) to be blunt, but the IETF pounding the this thing is bad! drum is not a particularly effective tool. [1] I hope that market forces, whatever that means, is not the main argument to dispel problems. We have to be realistic about how and where our influence is relevant, and more importantly how and where it is not. Detailing the technical problems with the proposal is relevant IETF work, but that job has already been done more thoroughly by my esteemed former colleagues on the SSAC. I don't have any influence. I take no position on the SSAC report. What I did was to read all the IETF specifications referenced in the draft and write a draft. It does not bother me to be unrealistic. :-) It is up to those who decide to decide whether dotless domains is a good idea that will gain traction or a bad idea that will go away on it own. You vastly overestimate your own importance in the grand scheme of things. Don't worry, it's a common human problem. :) Rather than repeating my point for the third time, see what I wrote just above. I left in the paragraph that was quoted for context. The text says those who decide. I don't have anything to do with the decision about dotless domains. As I am not important it is unlikely that I might overestimate my importance. :-) I don't know the grand scheme of things and I do not need to know the grand scheme of things. Regards, S. Moonesamy
RE: Sunday IAOC Overview Session at the Berlin IETF
One can't 100% protect against disruption from emergency situations. I'm Vice Chair of IEEE 802 and there was a case where a venue became unavailable due to a disaster. In that case it was enough before the meeting that it worked as Bob described - the hotel chain worked with us to identify and contract an acceptable alternative. On the other hand, the tsunami hit Japan just before the IEEE 802 Singapore meeting - close enough to it that some folks were in the air on the way to the meeting when it hit. Many attendees had travel disrupted and arrived late. Some even were unable to attend due to problems getting an alternative routing. Fortunately, enough were able to arrive so that we had an effective meeting, but it was difficult. There are also cases where a wide spread weather disruption has caused problems for meeting effectiveness - e.g. a blizzard on the east coast of the USA. Pat -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Bob Hinden Sent: Monday, July 15, 2013 12:56 PM To: Abdussalam Baryun Cc: Bob Hinden; ietf@ietf.org Subject: Re: Sunday IAOC Overview Session at the Berlin IETF AB, snip - Is there an alternative venue if the venue was closed for any emergency reason at any time? or only one plan so if the plan changes there can be problems with the communities expected plan because they were not aware of the needed information per time. No, there is not an alternative venue under contract. It isn't practical to have two venues under contract, build two networks, etc. It is technically feasable, but would cause the registration fee to go up significantly to cover the extra costs. If there was, for example, a fire at a venue months before the the meeting we would look for an alternate, but what happens would depend on availability of alternative venues. We have good relationships with the hotel chains we use and they would work very hard to find an alternative venue, as would the effected venue.
Re: Regarding call Chinese names
On Tue, Jul 16, 2013 at 12:04 AM, Ted Hardie ted.i...@gmail.com wrote: On Sun, Jul 14, 2013 at 5:26 PM, Hui Deng denghu...@gmail.com wrote: Hi Ted, I did explain them in the 1st paragraph about minorities (not mentioned that they could have two kids in mainland) anyway, I will revise the title by adding Chinese Han people, hope that will be ok -Hui While it is always valuable to note national minorities, I believe you missed the point. In some territories, there are dialects of Chinese other than Mandarin and romanizations other than pinyin which are common and normatively correct. For those Chinese people, your document does not apply. As an example, the current chief executive of Hong Kong is properly called Leung Chun Ying (梁振英); his predecessor in that role was Tung Chee Hwa (董建華). Similar situations arise in Taiwan and in many territories where Chinese people are themselves national minorities. That's not Pinyin system. I have a question for you, do you think these spellings are self pronounciable? Clarifying that your document is specific to the pinyin romanization is likely enough (since that romanization is based on Mandarin). We actually clarify that in pinyin draft, http://tools.ietf.org/id/draft-zcao-chinese-pronounce-01 Thanks, caozhen
Announcement improvement (was: Re: Last Call: RFC 2050 to historic)
For the benefits of those (few and far between) IETF participants that haven't memorized all RFC numbers, it would be great if announcement such as the one below would contain a tiny bit more information about the document itself. E.g. just having the title of the document in announcement would make it a lot easier to decide whether this warrants further attention or not, without additional lookup. Many thanks in advance! Regards, Martin. On 2013/07/11 6:39, The IESG wrote: The IESG has received a request from an individual participant to make the following status changes: - RFC2050 from Best Current Practice to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-2050-to-historic/ 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 2013-08-07. 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 affected document can be obtained via http://datatracker.ietf.org/doc/rfc2050/ IESG discussion of this request can be tracked via http://datatracker.ietf.org/doc/status-change-2050-to-historic/ballot/
Re: Sunday IAOC Overview Session at the Berlin IETF
Hi Pat, Thanks. My concerns is that do we have a plan for disaster recovery/management in IETF or IEEE802. Including meetings which is the important time we come together for. Usually now organisations are looking into defining plans so the staff/participants are aware of procedures. I was thinking if I was to go to any organisation these days I will ask is there a plan and alternatives. Usually communication and information is the key to a better solution per person or per organisation. As IETF and IEEE802 standard communication technology then it is good if we have the best practice in the world. AB On Tue, Jul 16, 2013 at 9:33 AM, Pat Thaler ptha...@broadcom.com wrote: One can't 100% protect against disruption from emergency situations. I'm Vice Chair of IEEE 802 and there was a case where a venue became unavailable due to a disaster. In that case it was enough before the meeting that it worked as Bob described - the hotel chain worked with us to identify and contract an acceptable alternative. On the other hand, the tsunami hit Japan just before the IEEE 802 Singapore meeting - close enough to it that some folks were in the air on the way to the meeting when it hit. Many attendees had travel disrupted and arrived late. Some even were unable to attend due to problems getting an alternative routing. Fortunately, enough were able to arrive so that we had an effective meeting, but it was difficult. There are also cases where a wide spread weather disruption has caused problems for meeting effectiveness - e.g. a blizzard on the east coast of the USA. Pat -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Bob Hinden Sent: Monday, July 15, 2013 12:56 PM To: Abdussalam Baryun Cc: Bob Hinden; ietf@ietf.org Subject: Re: Sunday IAOC Overview Session at the Berlin IETF AB, snip - Is there an alternative venue if the venue was closed for any emergency reason at any time? or only one plan so if the plan changes there can be problems with the communities expected plan because they were not aware of the needed information per time. No, there is not an alternative venue under contract. It isn't practical to have two venues under contract, build two networks, etc. It is technically feasable, but would cause the registration fee to go up significantly to cover the extra costs. If there was, for example, a fire at a venue months before the the meeting we would look for an alternate, but what happens would depend on availability of alternative venues. We have good relationships with the hotel chains we use and they would work very hard to find an alternative venue, as would the effected venue.
RE: Sunday IAOC Overview Session at the Berlin IETF
AB How many IETFs have you attended? How many professional meetings have you organised? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 16 July 2013 12:26 To: Pat Thaler Cc: Bob Hinden; ietf@ietf.org Subject: Re: Sunday IAOC Overview Session at the Berlin IETF Hi Pat, Thanks. My concerns is that do we have a plan for disaster recovery/management in IETF or IEEE802. Including meetings which is the important time we come together for. Usually now organisations are looking into defining plans so the staff/participants are aware of procedures. I was thinking if I was to go to any organisation these days I will ask is there a plan and alternatives. Usually communication and information is the key to a better solution per person or per organisation. As IETF and IEEE802 standard communication technology then it is good if we have the best practice in the world. AB On Tue, Jul 16, 2013 at 9:33 AM, Pat Thaler ptha...@broadcom.commailto:ptha...@broadcom.com wrote: One can't 100% protect against disruption from emergency situations. I'm Vice Chair of IEEE 802 and there was a case where a venue became unavailable due to a disaster. In that case it was enough before the meeting that it worked as Bob described - the hotel chain worked with us to identify and contract an acceptable alternative. On the other hand, the tsunami hit Japan just before the IEEE 802 Singapore meeting - close enough to it that some folks were in the air on the way to the meeting when it hit. Many attendees had travel disrupted and arrived late. Some even were unable to attend due to problems getting an alternative routing. Fortunately, enough were able to arrive so that we had an effective meeting, but it was difficult. There are also cases where a wide spread weather disruption has caused problems for meeting effectiveness - e.g. a blizzard on the east coast of the USA. Pat -Original Message- From: ietf-boun...@ietf.orgmailto:ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.orgmailto:ietf-boun...@ietf.org] On Behalf Of Bob Hinden Sent: Monday, July 15, 2013 12:56 PM To: Abdussalam Baryun Cc: Bob Hinden; ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: Sunday IAOC Overview Session at the Berlin IETF AB, snip - Is there an alternative venue if the venue was closed for any emergency reason at any time? or only one plan so if the plan changes there can be problems with the communities expected plan because they were not aware of the needed information per time. No, there is not an alternative venue under contract. It isn't practical to have two venues under contract, build two networks, etc. It is technically feasable, but would cause the registration fee to go up significantly to cover the extra costs. If there was, for example, a fire at a venue months before the the meeting we would look for an alternate, but what happens would depend on availability of alternative venues. We have good relationships with the hotel chains we use and they would work very hard to find an alternative venue, as would the effected venue.
LC of draft-ietf-jcardcal-jcard-05
In the context of writing both an RDAP client and server for the weirds activity, I have read draft-ietf-jcardcal-jcard-05 and found no issues. -andy
Re: The case of dotless domains
What this brings to mind is that we used to have implicit DNS domain search in the early days of DNS. When edu.com accidentally hijacked a huge chunk of the Internet, most of the net very quickly got rid of implicit search, and we got the explicit DNS search feature that many people are discussing now. Yes. Can you (or Ofer) define how you're using the terms explicit and implicit in terms of DNS search, and what their relevance is to the topic of dotless domains? And no, I'm not being snarky, I think part of the problem here is a fundamental misunderstanding of how the vast majority of hosts are configured currently. You're not being snarky, but that indicates that you seem to have missed my point, which is not about the technical details of how domain search got changed after the edu.com disaster. My point is not to make a direct parallel between how domain search changed, and dotless domains, and you seem to be looking at it in that light. What this brings to mind is that we had a DNS system that was vulnerable to the addition of something to the DNS that people had expected nobody would make the mistake of doing, but it happened and caused damage, and the net reacted by altering how DNS software works in order to protect against that damage. At the time, the obvious defensive change was don't do implicit domain search. If dotless domains cause damage as many people here predict, what I'm saying is that I think we'll react similarly, and that I guess the defensive change people will widely deploy is to reject A//MX records at the top level. You really do not need to drill into the specifics of the change from implicit to explicit domain search in reaction to edu.com, in this context. So it sounds to me like you have something quite different in mind. I don't know what you think I was trying to say - it's not anything I said explicitly, so perhaps you think I was trying to subtly say something between the lines. To be clear: I wasn't. -- Cos
Re: Regarding call Chinese names
On Tue, Jul 16, 2013 at 4:35 AM, Cao,Zhen zehn@gmail.com wrote: On Tue, Jul 16, 2013 at 12:04 AM, Ted Hardie ted.i...@gmail.com wrote: On Sun, Jul 14, 2013 at 5:26 PM, Hui Deng denghu...@gmail.com wrote: Hi Ted, I did explain them in the 1st paragraph about minorities (not mentioned that they could have two kids in mainland) anyway, I will revise the title by adding Chinese Han people, hope that will be ok -Hui While it is always valuable to note national minorities, I believe you missed the point. In some territories, there are dialects of Chinese other than Mandarin and romanizations other than pinyin which are common and normatively correct. For those Chinese people, your document does not apply. As an example, the current chief executive of Hong Kong is properly called Leung Chun Ying (梁振英); his predecessor in that role was Tung Chee Hwa (董建華). Similar situations arise in Taiwan and in many territories where Chinese people are themselves national minorities. That's not Pinyin system. I have a question for you, do you think these spellings are self pronounciable? You mean how accurate they sound? They sound right for the intended dialect, just they are not Mandarin. Joseph Clarifying that your document is specific to the pinyin romanization is likely enough (since that romanization is based on Mandarin). We actually clarify that in pinyin draft, http://tools.ietf.org/id/draft-zcao-chinese-pronounce-01 Thanks, caozhen
I-D Action: draft-barnes-healthy-food-07.txt
Mary, I appreciate your work on this document, but I don't know where or how to draw the line. Personally, I will strongly try to be vegetarian, but eat meat rather than starve (a situation that arises when travelling). But I will also try to eat fairly traded produce, and also try to reduce the food-miles. I prefer food that can be traced to source (which is hopefully local). I wonder whether your draft should either go into *all* details, or try to up-level a bit to limit itself to imperatives (such as allergies and religious requirements). Adrian -Original Message- From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: 16 July 2013 17:32 To: i-d-annou...@ietf.org Subject: I-D Action: draft-barnes-healthy-food-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Healthy Food and Special Dietary Requirements for IETF meetings Author(s) : Mary Barnes Filename: draft-barnes-healthy-food-07.txt Pages : 18 Date: 2013-07-15 Abstract: This document describes the basic requirements for food for folks that attend IETF meetings require special diets, as well as those that prefer to eat healthy. While, the variety of special diets is quite broad, the most general categories are described. There can be controversy as to what constitutes healthy eating, but there are some common, generally available foods that comprise the basis for healthy eating and special diets. This document provides some recommendations to meeting planners, as well as participants, in handling these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-barnes-healthy-food There's also a htmlized version available at: http://tools.ietf.org/html/draft-barnes-healthy-food-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-barnes-healthy-food-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Re: I-D Action: draft-barnes-healthy-food-07.txt
As I mentioned to Mary privately, yogurt with fish in it is very common (yoplait, for example) and vegetarians who know that kosher gelatin is made of fish don't eat it; this can result in the food options at the cookie table being, essentially, cookies, which are of course a terrible thing to eat if you will be needing to concentrate during the next session. Because of this I tend to consider the break food to be an attractive nuisance rather than a benefit. I don't know if it's even possible to get people at venues to be sensitive to these issues, but I certainly support the effort Mary is making to get them to try, and I think specificity is a good thing. I applaud your flexibility, but not everyone is in a position to be as flexible; in particular, given the number of graybeards who attend IETF, I think paying attention to the problem of excessive sugar in break foods is really important.
Re: The case of dotless domains
--On Tuesday, July 16, 2013 11:07 -0400 Ofer Inbar c...@a.org wrote: ... What this brings to mind is that we had a DNS system that was vulnerable to the addition of something to the DNS that people had expected nobody would make the mistake of doing, but it happened and caused damage, and the net reacted by altering how DNS software works in order to protect against that damage. At the time, the obvious defensive change was don't do implicit domain search. If dotless domains cause damage as many people here predict, what I'm saying is that I think we'll react similarly, and that I guess the defensive change people will widely deploy is to reject A//MX records at the top level. Two additional observations about this. Ofer's explanation about the edu.com example and the resultant ban on heuristic search is consistent with RFC 1535 and what little I remember of the history. However... * The RFC 1535 defensive change was far more practical in 1993 than it is today, just because of the size of the Internet, the number of deployed DNS servers and resolvers, and the difficulties of deploying required upgrades. So the harm level or likely duration of harm should dotless TLDs be deployed is greater today or at least less likely to yield quickly to a defensive change. * A different example of searching issues caused a good deal of disruption when it came up (several years earlier than the EDU.COM. case) and may be relevant to ICANN's current plans and their likely effects. In that case, a very large number of computer science departments in universities all over the world quite reasonably were delegated domains like CS.university-name.EDU, often resulting in host1.CS.university.EDU, host2.CS.university.EDU and email addresses like usern...@cs.university.edu. Whether by relying on the heuristics that RFC 1535 banned or by explicit search, institutions set up name completion so that a reference from within that institution to username@CS (or username2@chem or username3@art -- you get the idea) worked as everyone expected, yielding usern...@cs.university.edu, etc. Usually, host1.CS did too -- this is not just about dotless domains. Then the TLD for Czechoslovakia was delegated under the then-assigned ISO 3166 code of CS and unpleasant things started happening. Users in some institutions couldn't find Czech sites at all; others had no problems. In some cases in which search rather than mere completion was used, some names would be found, some names wouldn't, and false positives become possible. If there is advice for ICANN in this it is that, when DNS searching scenarios are involved, it is not sufficient to worry about possible conflicts between proposed new TLDs and existing private-use pseudo-TLDs (such as local.) Instead, conflicts with existing second or third-level labels (and perhaps ones even further down the tree) have to be considered if completion or search configurations involving those labels might give them the same appearance as a TLD or subdomains of that TLD. Whether the IAB should have included any of this in its Statement is, IMO, another matter. My personal bias is that, if the IAB starts making Statements about the implications of a technological choice, they should be comprehensive about the relevant subject. That principle would call for discussion, not only of the email issues that started this thread, but the CS. case and many of the other issues that have been mentioned. On the other hand, there are arguments against that principle, especially when a body like ICANN is concerned and there is reason to believe that any statement more than a paragraph or two long will be unread by many people in the intended audience. Personally, I would have preferred it had the IAB been explicit about what issues they were and were not addressing if they decided to avoid a comprehensive discussion -- at least then, people might be debating their choices but not whether they are exhibiting their ignorance. But that is just my opinion. john
Re: I-D Action: draft-barnes-healthy-food-07.txt
--On Tuesday, July 16, 2013 18:09 +0100 Adrian Farrel adr...@olddog.co.uk wrote: ... Personally, I will strongly try to be vegetarian, but eat meat rather than starve (a situation that arises when travelling). ... I'm in much the same situation, but suggests that part of this feeds back into some of the venue selection issues: if a venue is chosen that forces you (or me or others) into a meat or starve or, much worse, eat something severely damaging to health or beliefs or starve situation, is that really an acceptable venue? And, if it is not and it is chosen anyway (either deliberately after considering other factors or out of ignorance), who is accountable and to whom? john
Re: I-D Action: draft-barnes-healthy-food-07.txt
On Jul 16, 2013, at 11:03 AM, John C Klensin john-i...@jck.com wrote: And, if it is not and it is chosen anyway (either deliberately after considering other factors or out of ignorance), who is accountable and to whom? Part of the value of writing a document like this is to capture the issues in such a way that the venue can answer the question can you accommodate our needs accurately. Dietary health issues are very important, and not everybody has the level of expertise that would allow them to even know that they were giving an incorrect answer to a question about them, so the better the questions you can ask, the more likely it is that we will avoid problems. If there is someone to blame or to be accountable, it's already too late, and furthermore there's absolutely no benefit to someone feeling bad about getting it wrong, or getting yelled at because they got it wrong. Certainly on our side of the negotiation everybody _wants_ to get it right, and I seriously doubt that that would not be the case for the operators of a meeting venue either.
RE: I-D Action: draft-barnes-healthy-food-07.txt
Personally, I will strongly try to be vegetarian, but eat meat rather than starve (a situation that arises when travelling). if a venue is chosen that forces you (or me or others) into a meat or starve or, much worse, eat something severely damaging to health or beliefs or starve situation, is that really an acceptable venue? Yes, it is. If a venue is inconvenient or uncomfortable for a small percentage of regular IETF participants, that does not make it a poor choice of venue. We might as well go back to the debate about location: only a venue that is a convenient 10 minutes from my home is really a suitable venue. I venture that starve is never a real outcome, but go to a supermarket or bring food in your luggage are alternatives that need some planning and are a small inconvenience. Adrian
Re: I-D Action: draft-barnes-healthy-food-07.txt
Hi, On Tue, Jul 16, 2013 at 10:17 AM, Ted Lemon ted.le...@nominum.com wrote: ... given the number of graybeards who attend IETF, I think paying attention to the problem of excessive sugar in break foods is really important. I'm not supposed to have sugar, so the massive quantities of cookies, brownies, ice cream, etc. in the breaks are an unwanted distraction. But that doesn't mean I want celery and carrots instead. :-) I suggest more cheese and crackers, sandwiches, etc. and perhaps less cookies. Andy
Re: I-D Action: draft-barnes-healthy-food-07.txt
two hypotheses: o there is no venue which is easy/acceptable to all ietf participants o there is no ietf participant for whom all venues are easy/acceptable randy, who is happy not to be on the meetings committee
Re: I-D Action: draft-barnes-healthy-food-07.txt
On Jul 16, 2013, at 11:43 AM, Andy Bierman a...@yumaworks.com wrote: I suggest more cheese and crackers, sandwiches, etc. and perhaps less cookies. +1 Celery will not prevent a blood sugar crash.
Re: I-D Action: draft-barnes-healthy-food-07.txt
On Jul 16, 2013, at 11:37 AM, Adrian Farrel adr...@olddog.co.uk wrote: I venture that starve is never a real outcome, but go to a supermarket or bring food in your luggage are alternatives that need some planning and are a small inconvenience. Try it sometime, then get back to us. :) I rented a car in Orlando, which just about doubled the cost of my stay. This is a pretty strong negative for a venue. And I suspect that needs some kind of nonstandard food is not quite as small a minority as you imagine it is. Particularly when nonstandard==what is served in the hotel restaurant, which, in large hotels, tends to actually be a very constrained, unhealthy diet even for those who can eat it. I was feeling so crappy after several days of the hotel food at the most recent venue we shared together that I had to flee the meeting and search Dublin for some probiotics and roughage. I am happy for you that you don't have this problem.
Re: Sunday IAOC Overview Session at the Berlin IETF
Hi Bob, thanks and respond below, On Mon, Jul 15, 2013 at 8:55 PM, Bob Hinden bob.hin...@gmail.com wrote: AB, IMO the questions/comments that may be ok to see added to discuss are: 1) Venue selection and operation of the IETF meetings - Selection of the current venue and was there difficulties until getting to this meeting session time. From the managing meeting (providing services) and the community use of the meeting. (10 minute discuss if needed). I don't understand your question, please clarify. sorry, I ment meetings in the past were they all using the selected venue successfully, if there was difficulty (in attending, in using the avenue, in venue resources). Note that the IAOC selects the venue, provides the network, contracts with the hotel, etc., it is the IESG who is responsible for the agenda for the meeting, agenda planning, etc. - Is there an alternative venue if the venue was closed for any emergency reason at any time? or only one plan so if the plan changes there can be problems with the communities expected plan because they were not aware of the needed information per time. No, there is not an alternative venue under contract. It isn't practical to have two venues under contract, build two networks, etc. It is technically feasable, but would cause the registration fee to go up significantly to cover the extra costs. I ment that does the contract mention if there was difficulty in using the venue then an alternative may be an option. Does the finance of the venue contract is non-refundable ( a plan for service and maintenance). If there was, for example, a fire at a venue months before the the meeting we would look for an alternate, but what happens would depend on availability of alternative venues. We have good relationships with the hotel chains we use and they would work very hard to find an alternative venue, as would the effected venue. So I understand there is no plan, we only think about alternative when a problem appears. I wanted if possible a discuss on this issue. - Is there an historic/informational RFC issued by IAOC of difficulties or important comments in past of venues attended? No. There is an extensive record of comments about venue on the attendees list for individual meetings and the IAOC reports to the community. Also, meeting surveys with community feedback: http://iaoc.ietf.org/surveys.html Ok - Regarding advice within emergency situations (in or out the meeting venue), is it considered within chosing the managing meeting plan/venue, and is the emergency solution an available information for attended participants and who will attend within a meeting day. Assuming you mean while the meeting is taking place, the secretariat and venue have emergency plans in place. The secretariat discuses safety and emergency medial procedures with the venue to be prepared if anything should happen. Ok, so I understand that the safety procedure is discussed but not emailed/sended to registered participants. - Someone may like to know if is going to attend at a meeting, how is the meeting venue managed per time slots, is there a way of quick feedback/communication of registered-community for meetings (you may say IETF list but are they connected). The information availability can be used for others not attended and whom may attend at any time. (the venue ran out of coffee/water, so I may buy one while going to venue, or any other issue which can happen out of expected/plan). The IETF meeting agenda is managed by the IESG. Problems with the meeting venue can be reported to the Meeting Trouble Desk at m...@ietf.org. Problems with the network can be reported to the NOC at n...@ietf.org. ok thanks, 2) Other issue: + -Is there a future work plan milestones discussed? can be added to [*] Not sure what your are asking about, but future meetings are posted on the IETF web site and the process and timeline for meeting planning is part of the IAOC overview presentation. sorry, I ment what to discuss, is the community work plan of discuss, so IAOC knows what it is discussing each time, but does the community just follow presented issues, or we can come together and plan how we discuss/influence with IAOC. (this point was trigered when I read your call to community to suggest what to discuss). Each WG in IETF has milestones, but I not sure of the general area milestones related to meetings selections. -I am not sure if was discussed before and answered (I am sorry if repeated), where do I go to find important past/current QA for IAOC (to avoid efforts to be wasted, and unite best answers)? if not available it can be good to find it at [*]. Recent plenaries reports and the last IAOC overview session have been recored by Meetecho. The last IAOC overview is on the main page at http://iaoc.ietf.org. Also, plenary
Re: I-D Action: draft-barnes-healthy-food-07.txt
On Tue, Jul 16, 2013 at 1:47 PM, Ted Lemon ted.le...@nominum.com wrote: On Jul 16, 2013, at 11:37 AM, Adrian Farrel adr...@olddog.co.uk wrote: I venture that starve is never a real outcome, but go to a supermarket or bring food in your luggage are alternatives that need some planning and are a small inconvenience. Try it sometime, then get back to us. :) [MB] Exactly. This was the same sort of response that we had when we raised these concerns after the meeting in Dublin (and later in Maastricht). Many countries limit the food that you can bring in your luggage. And, in the case of Dublin (and Maastricht on Sunday) there were no markets to go to in order to buy food. Yes, I can subsist on the pumpkin seeds and raisins that I carry in my pocket and backpack but to do so for 36-48 hours is really unpleasant and isn't healthy for me personally who needs more fresh foods to feel well. [/MB] I rented a car in Orlando, which just about doubled the cost of my stay. This is a pretty strong negative for a venue. And I suspect that needs some kind of nonstandard food is not quite as small a minority as you imagine it is. Particularly when nonstandard==what is served in the hotel restaurant, which, in large hotels, tends to actually be a very constrained, unhealthy diet even for those who can eat it. I was feeling so crappy after several days of the hotel food at the most recent venue we shared together that I had to flee the meeting and search Dublin for some probiotics and roughage. I am happy for you that you don't have this problem. [MB] I did the same in Orlando and will do so in cases where we may end up in the boondocks or tiny cities in Europe again, but my company covers that cost and not everyone has the financial support that I do when I go to meetings. [/MB]
Internationalization and draft-ietf-abfab-eapapplicability
After reading this document, I believe that this document omits discussion of an important aspect, which is internationalization. Since the contents of the EAP Identity and RADIUS User-Name attributes are specified to be encoded in UTF-8, application protocols that utilize encodings other than UTF-8 for user identities and passwords could have issues utilizing EAP (and RADIUS). Currently RFC 4282bis proposes that all EAP implementations normalize identities and passwords before utilizing them, and therefore application protocols that do not do this will be at variance with RFC 4282bis. IMHO the document needs to state what the internationalization requirements are for application-layer protocol use of EAP. There are potential workarounds, such as requiring that application protocols convert identities and passwords to UTF-8 prior to use of EAP, or modifying RFC 4282bis so as to require normalization in RADIUS proxies or servers. However, without fixes being applied and/or changes to RFC 4282bis, use of EAP by applications may not be compatible with either existing specifications or implementations. Background EAP and protocols that carry it (e.g. RADIUS) assume that the EAP-Response/Identity is encoded in UTF-8. For example, RFC 3748 Section 1.2 defines displayable message as follows: Displayable Message This is interpreted to be a human readable string of characters. The message encoding MUST follow the UTF-8 transformation format [RFC2279]. Therefore EAP messages including EAP Identity and Notification that are described as displayable messages have a UTF-8 encoding requirement applied to them. Since RFC 3579 Section 2.1 specifies that the EAP-Response/Identity is copied into the RADIUS User-Name Attribute:In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. Therefore for use with EAP, the User-Name Attribute also inherits a UTF-8 encoding requirement, restricting the potential encodings permitted by RFC 2865 Section 5.1 (User-Name Attribute): The format of the username MAY be one of several forms: text Consisting only of UTF-8 encoded 10646 [7] characters. network access identifier A Network Access Identifier as described in RFC 2486 [8]. distinguished name A name in ASN.1 form used in Public Key authentication systems.
Re: I-D Action: draft-barnes-healthy-food-07.txt
On Tue, Jul 16, 2013 at 1:37 PM, Adrian Farrel adr...@olddog.co.uk wrote: Personally, I will strongly try to be vegetarian, but eat meat rather than starve (a situation that arises when travelling). if a venue is chosen that forces you (or me or others) into a meat or starve or, much worse, eat something severely damaging to health or beliefs or starve situation, is that really an acceptable venue? Yes, it is. If a venue is inconvenient or uncomfortable for a small percentage of regular IETF participants, that does not make it a poor choice of venue. [MB] This is the exact reason I had some stats in the doc previously as it's not as small a percentage as you think. Also, as the document highlights, in cases of medical conditions, one might consider this to violate the American Disability Act in the US. Celiac disease, for example, is considered an invisible disability in the US. One can debate whether or not IETF/ISOC must comply with the American Disability Act, but as I have posited IETF claims to be an open organization so I would think they would want the meetings to be accessible to all, which means ensuring there is food readily available to accommodate those with dietary restrictions. The example of your situation is a matter of personal choice. For some of us it can be a matter of life or death (e.g., peanut allergies). [/MB] We might as well go back to the debate about location: only a venue that is a convenient 10 minutes from my home is really a suitable venue. I venture that starve is never a real outcome, but go to a supermarket or bring food in your luggage are alternatives that need some planning and are a small inconvenience. [MB] I already responded to this one, but I'll go ahead again, because this attitude is the reason why I wrote this document after Dublin. There was no supermarket near the venue at all, thus that wasn't possible. I did the right thing and checked out the hotel restaurants on the Sunday before the meeting started and found they could easily accommodate my GF diet. However, at Monday lunchtime we could not order off the menu and were given something like 3 choices of entrees. The staff serving the food had no idea about preparation. Folks that are vegan/vegetarian/kosher couldn't even eat the french fries because they couldn't be certain whether they were cooked in a meat based oil or vegetable oil.I have celiac and thus I cannot eat anything unless I have a very high level of confidence that it is gluten free - my reaction can be extremely severe and at it's mildest, it's like having a miserable 24 hour flu. [/MB] Adrian
Re: I-D Action: draft-barnes-healthy-food-07.txt
On 7/16/2013 11:37 AM, Adrian Farrel wrote: If a venue is inconvenient or uncomfortable for a small percentage of regular IETF participants, that does not make it a poor choice of venue. How about unworkable or only marginally tolerable? For example imposing a 'meat or die' model onto almost any kind of vegetarian seems to me frankly offensive (and I'm not a member of that demographic). In this day and age, ensuring good vegan options -- which therefore work for most vegetarians -- should not be viewed as unusual or difficult; but it does need to be an explicit goal. Then there's the question of how small a percentage is acceptable? If someone is allergic to literally everything, we can't do much to help them. On the other hand, if someone has special needs that can reasonably be accommodated by a typical, modern, urban grocery store, then we can help them by choosing a venue near such a place and publishing information about access to it. This is the ultimate fallback. Similarly, there are snack foods that are basic an healthy and run into relatively few allergy, belief or religious limitations. Providing such choices during IETF breaks is a version of being more inclusive, to encourage more diversity. I've intentionally invoked the current buzzword, because ultimately these various accommodations have to do with making the IETF more (or less) friendly to the widest range of participants we can manage. Some organizational empathy that is applied to event logistics will go a long way here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
RE: I-D Action: draft-barnes-healthy-food-07.txt
My point, of course, is not to disparage those with medical conditions, or even those with philosophical/religious convictions. Google shows me a supermarket within 1km of the venue in Dublin. I walked to one while I was there. I also caught the free shuttle to down-town Dublin where I saw several shops. I know folk who travel with suitcases of special food. It is hard. We should do what we can to be accommodating. It should be one of the factors we consider in selecting/briefing a venue. It should not be an over-riding consideration. Adrian From: Mary Barnes [mailto:mary.h.bar...@gmail.com] Sent: 16 July 2013 20:49 To: adr...@olddog.co.uk Cc: John C Klensin; draft-barnes-healthy-f...@tools.ietf.org; ietf@ietf.org Subject: Re: I-D Action: draft-barnes-healthy-food-07.txt On Tue, Jul 16, 2013 at 1:37 PM, Adrian Farrel adr...@olddog.co.uk wrote: Personally, I will strongly try to be vegetarian, but eat meat rather than starve (a situation that arises when travelling). if a venue is chosen that forces you (or me or others) into a meat or starve or, much worse, eat something severely damaging to health or beliefs or starve situation, is that really an acceptable venue? Yes, it is. If a venue is inconvenient or uncomfortable for a small percentage of regular IETF participants, that does not make it a poor choice of venue. [MB] This is the exact reason I had some stats in the doc previously as it's not as small a percentage as you think. Also, as the document highlights, in cases of medical conditions, one might consider this to violate the American Disability Act in the US. Celiac disease, for example, is considered an invisible disability in the US. One can debate whether or not IETF/ISOC must comply with the American Disability Act, but as I have posited IETF claims to be an open organization so I would think they would want the meetings to be accessible to all, which means ensuring there is food readily available to accommodate those with dietary restrictions. The example of your situation is a matter of personal choice. For some of us it can be a matter of life or death (e.g., peanut allergies). [/MB] We might as well go back to the debate about location: only a venue that is a convenient 10 minutes from my home is really a suitable venue. I venture that starve is never a real outcome, but go to a supermarket or bring food in your luggage are alternatives that need some planning and are a small inconvenience. [MB] I already responded to this one, but I'll go ahead again, because this attitude is the reason why I wrote this document after Dublin. There was no supermarket near the venue at all, thus that wasn't possible. I did the right thing and checked out the hotel restaurants on the Sunday before the meeting started and found they could easily accommodate my GF diet. However, at Monday lunchtime we could not order off the menu and were given something like 3 choices of entrees. The staff serving the food had no idea about preparation. Folks that are vegan/vegetarian/kosher couldn't even eat the french fries because they couldn't be certain whether they were cooked in a meat based oil or vegetable oil.I have celiac and thus I cannot eat anything unless I have a very high level of confidence that it is gluten free - my reaction can be extremely severe and at it's mildest, it's like having a miserable 24 hour flu. [/MB] Adrian
Re: I-D Action: draft-barnes-healthy-food-07.txt
On Tue, Jul 16, 2013 at 3:10 PM, Adrian Farrel adr...@olddog.co.uk wrote: My point, of course, is not to disparage those with medical conditions, or even those with philosophical/religious convictions. ** ** Google shows me a supermarket within 1km of the venue in Dublin. I walked to one while I was there. I also caught the free shuttle to down-town Dublin where I saw several shops. [MB] The market within walking distance was poorly stocked when I went there. The only thing I found that I could possibly eat was canned vegetables.Yes, I did take the shuttle to the city at night for dinner, but that didn't solve the lunch issue at all and the speciality food markets weren't open that late. Did you subsist on the food that you bought at the supermarket or did you partake of the food that you could eat that was offered at the hotel buffet?[/MB] ** ** I know folk who travel with suitcases of special food. [MB] Sure. And, in many cases we are violating local laws by bringing food into the country. Most of the food I carry with me is nuts, pumpkin seeds, dried fruit and some snack bars. All of those things would be confiscated if I declared them as they have been when I have been searched and they have found them. I asked someone to bring a packaged food product from Stockholm to me when we were meeting in the US. It got confiscated. [/MB] ** ** It is hard. We should do what we can to be accommodating. It should be one of the factors we consider in selecting/briefing a venue. ** ** It should not be an over-riding consideration. [MB] This is the very reason I wrote this document - being able to eat SHOULD be an over-riding consideration for meetings. That's a basic human requirement for survival.Certainly, most of us won't die if we have to subsist on nuts, seeds and dried fruit, canned veggies, etc during an IETF meeting. But, most of us will not function well without proper nutrition, somewhat equivalent to what we are used to on a daily basis. While, at this point, I might benefit from some fasting, I would never choose a week where I am working 12-16 hours a day to do so. [/MB] ** ** Adrian ** ** *From:* Mary Barnes [mailto:mary.h.bar...@gmail.com] *Sent:* 16 July 2013 20:49 *To:* adr...@olddog.co.uk *Cc:* John C Klensin; draft-barnes-healthy-f...@tools.ietf.org; ietf@ietf.org *Subject:* Re: I-D Action: draft-barnes-healthy-food-07.txt ** ** On Tue, Jul 16, 2013 at 1:37 PM, Adrian Farrel adr...@olddog.co.uk wrote: Personally, I will strongly try to be vegetarian, but eat meat rather than starve (a situation that arises when travelling). if a venue is chosen that forces you (or me or others) into a meat or starve or, much worse, eat something severely damaging to health or beliefs or starve situation, is that really an acceptable venue? Yes, it is. If a venue is inconvenient or uncomfortable for a small percentage of regular IETF participants, that does not make it a poor choice of venue. [MB] This is the exact reason I had some stats in the doc previously as it's not as small a percentage as you think. Also, as the document highlights, in cases of medical conditions, one might consider this to violate the American Disability Act in the US. Celiac disease, for example, is considered an invisible disability in the US. One can debate whether or not IETF/ISOC must comply with the American Disability Act, but as I have posited IETF claims to be an open organization so I would think they would want the meetings to be accessible to all, which means ensuring there is food readily available to accommodate those with dietary restrictions. ** ** The example of your situation is a matter of personal choice. For some of us it can be a matter of life or death (e.g., peanut allergies). [/MB]*** * ** ** We might as well go back to the debate about location: only a venue that is a convenient 10 minutes from my home is really a suitable venue. I venture that starve is never a real outcome, but go to a supermarket or bring food in your luggage are alternatives that need some planning and are a small inconvenience. [MB] I already responded to this one, but I'll go ahead again, because this attitude is the reason why I wrote this document after Dublin. There was no supermarket near the venue at all, thus that wasn't possible. I did the right thing and checked out the hotel restaurants on the Sunday before the meeting started and found they could easily accommodate my GF diet. However, at Monday lunchtime we could not order off the menu and were given something like 3 choices of entrees. The staff serving the food had no idea about preparation. Folks that are vegan/vegetarian/kosher couldn't even eat the french fries because they couldn't be certain whether they were cooked in a meat based oil or vegetable oil.
Time Change [Sunday IAOC Overview Session at the Berlin IETF]
The time of the IAOC overview session has changed to 1300-1450 (still in Potsdam 1) to avoid overlapping with the Newcomers's Meet and Greet. Bob On Jul 12, 2013, at 1:58 PM, The IAOC bob.hin...@gmail.com wrote: The IETF Administrative Oversight Committee (IAOC) will hold a session from 1500-1650 in Potsdam 1 at the Berlin IETF on Sunday July 28, 2013. The purpose is to provide an overview of the IAOC to allow the community to better understand what the IAOC does, how the finances work, venue selection, and provide the IAOC feedback on the job they are doing. Remote participation support for this session will be provided by Meetecho. This will be similar to the session held at IETF86 in Orlando. The IAOC's responsibilities include: - Managing the IETF finances - Oversight of the IETF Administrative Director (IAD) - Selection and oversight of contracted services - Venue selection and operation of the IETF meetings - Support for the IETF's IT services (data tracker, web sites, tools, etc.) The topics that will be discussed include: - BCP101 - Structure of the IETF Administrative Support Activity (IASA) - Operation of the IAOC - Financial model and relationship with ISOC - Venue selection - Q A We hope this will improve the community understanding of how the IAOC works and provide the community an opportunity to provide feedback to the IAOC. Please let us know ahead of time if you have specific questions you would like to see discussed. Bob Hinden IAOC Chair
Re: Time Change [Sunday IAOC Overview Session at the Berlin IETF]
but now it overlaps with the newcomers tutorial so I will not be there Scott On Jul 16, 2013, at 4:42 PM, The IAOC bob.hin...@gmail.com wrote: The time of the IAOC overview session has changed to 1300-1450 (still in Potsdam 1) to avoid overlapping with the Newcomers's Meet and Greet. Bob On Jul 12, 2013, at 1:58 PM, The IAOC bob.hin...@gmail.com wrote: The IETF Administrative Oversight Committee (IAOC) will hold a session from 1500-1650 in Potsdam 1 at the Berlin IETF on Sunday July 28, 2013. The purpose is to provide an overview of the IAOC to allow the community to better understand what the IAOC does, how the finances work, venue selection, and provide the IAOC feedback on the job they are doing. Remote participation support for this session will be provided by Meetecho. This will be similar to the session held at IETF86 in Orlando. The IAOC's responsibilities include: - Managing the IETF finances - Oversight of the IETF Administrative Director (IAD) - Selection and oversight of contracted services - Venue selection and operation of the IETF meetings - Support for the IETF's IT services (data tracker, web sites, tools, etc.) The topics that will be discussed include: - BCP101 - Structure of the IETF Administrative Support Activity (IASA) - Operation of the IAOC - Financial model and relationship with ISOC - Venue selection - Q A We hope this will improve the community understanding of how the IAOC works and provide the community an opportunity to provide feedback to the IAOC. Please let us know ahead of time if you have specific questions you would like to see discussed. Bob Hinden IAOC Chair
Re: I-D Action: draft-barnes-healthy-food-07.txt
On 07/16/2013 11:46, Randy Bush wrote: two hypotheses: o there is no venue which is easy/acceptable to all ietf participants o there is no ietf participant for whom all venues are easy/acceptable o there is some ietf participant for whom no venue is easy/acceptable Yet, we persevere. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG signature.asc Description: OpenPGP digital signature
Re: I-D Action: draft-barnes-healthy-food-07.txt
On Jul 16, 2013, at 1:10 PM, Adrian Farrel adr...@olddog.co.uk wrote: It should not be an over-riding consideration. If not, then what _would_ be an over-riding consideration? I did the research on the venue for the Dublin IETF and concluded that I could not stay at the hotel, so I stayed elsewhere and commuted to the venue. This made my IETF visit quite a bit less effective than it would otherwise have been, because I was about an hour from the venue by reasonably priced transportation. In Orlando, as an AD, I was still driving fifteen to twenty minutes each way at least once a day to get food, which was a huge waste of time that left me badly sleep-deprived one morning. I still managed to get to the point where I had to eat a cookie or faint at one point, and that pretty much wrecked me for the rest of the day. Expecting there to be healthy food at an IETF venue is _not_ unreasonable, and the lack of it _does_ impact productivity. (When I mentioned Dublin previously, I was referring to our recent mutual visit to downtown Dublin, not to the Dublin IETF.) BTW, on the topic of diversity, I'd just like to point out that understanding really matters. Dave Crocker's message on this topic was really touching, and much appreciated. I think this is something that we could stand to see more of in the IETF, not just on the topic of food, but various other diversity topics that we discuss from time to time (or perhaps even now, in another thread).
Re: Time Change [Sunday IAOC Overview Session at the Berlin IETF]
I had previously asked if the tutorials couldn't be shortened and start 30 minutes earlier so that none of them conflict the with newcomer's meet and greet. It makes little sense to me to have tutorials conflict with an event targeted at newcomers. While those of us that have been around for a while benefit from some of these other tutorials, I would think that the majority of newcomers would have an even higher level of interest in attending them. Mary. On Tue, Jul 16, 2013 at 3:44 PM, Bradner, Scott s...@harvard.edu wrote: but now it overlaps with the newcomers tutorial so I will not be there Scott On Jul 16, 2013, at 4:42 PM, The IAOC bob.hin...@gmail.com wrote: The time of the IAOC overview session has changed to 1300-1450 (still in Potsdam 1) to avoid overlapping with the Newcomers's Meet and Greet. Bob On Jul 12, 2013, at 1:58 PM, The IAOC bob.hin...@gmail.com wrote: The IETF Administrative Oversight Committee (IAOC) will hold a session from 1500-1650 in Potsdam 1 at the Berlin IETF on Sunday July 28, 2013. The purpose is to provide an overview of the IAOC to allow the community to better understand what the IAOC does, how the finances work, venue selection, and provide the IAOC feedback on the job they are doing. Remote participation support for this session will be provided by Meetecho. This will be similar to the session held at IETF86 in Orlando. The IAOC's responsibilities include: - Managing the IETF finances - Oversight of the IETF Administrative Director (IAD) - Selection and oversight of contracted services - Venue selection and operation of the IETF meetings - Support for the IETF's IT services (data tracker, web sites, tools, etc.) The topics that will be discussed include: - BCP101 - Structure of the IETF Administrative Support Activity (IASA) - Operation of the IAOC - Financial model and relationship with ISOC - Venue selection - Q A We hope this will improve the community understanding of how the IAOC works and provide the community an opportunity to provide feedback to the IAOC. Please let us know ahead of time if you have specific questions you would like to see discussed. Bob Hinden IAOC Chair
Gen-ART LC/Telechat Review of draft-ietf-jcardcal-jcard-04
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-jcardcal-jcard-04 Reviewer: Ben Campbell Review Date: 2013-07-16 IETF LC End Date: 2013-07-18 IESG Telechat date: 2013-07-18 Note: This draft is on the IESG Telechat agenda on the same date as it completes IETF Last Call. Therefore, this review serves both purposes. Summary: This draft is almost ready for publication as a proposed standard. There are a few minor issues and editorial nits that should be considered prior to publication. Major issues: -- None Minor issues: -- Section 1, design considerations: You mention that the semantic results should survive round-tripping, but the order of fields might not. I gather there are other changes that might occur from the literal text, right? (e.g. Case changes, some optional parameter usage). If so, it might be worth clarifying that. -- 3.1, 2nd paragraph: I assume the removal of escaping means that one renders the escaped text, not simply removes it, right? Is that as simple as removing the escape characters in vCards? I assume this doesn't apply to any content-specific escaping inside vCard fields, e.g. URI escaping, right? If so, it might be worth mentioning. -- 3.2.1.1: What happens for future versions of vCard? Do you simply use the new version number, or would we need a new version of this spec? I suspect the latter. If true, it might be worth mentioning that, or somewhere early in the draft mention that this spec is for vCard 4.0 only. -- sections 3.4.3 and 3.4.4: Is the included ABNF a quotation of that in the referenced RFCs, or is it new and authoritative? If the former, it would be helpful to mention that in the text. (I note you did say that about the ABNF in the appendix). -- 3.4.11: If RFC6350 says that use of the timezone offset is NOT RECOMMENDED, can you elaborate on why it's included here? (I can guess it's because people may still use it in vCards since it was a MUST NOT, but it would be good to say something to that effect in the text.) Nits/editorial comments: -- Section 1, paragraph 1: Please expand JSON on first mention. -- Section 1, paragraph 3: This paragraph seems redundant to paragraph 1. -- 1, paragraph 7: Preserve the semantics of the vCard data. Imperative form sentence is confusing in context, and inconsistent with surrounding text. -- 1, paragraph 8: Sentence Fragment. -- 3.2, Last Paragraph: ... for a parser check the data type... Missing to? -- 3.2.1.2, last paragraph before example: Should the iCalendar reference be vCard instead? -- 3.2.1.3, Last Paragraph: RFCTODO? I gather in the IANA section, that may be a placeholder for this RFC, but that doesn't seem to fit here. -- 3.3.2: Example 1: Other examples are not numbered. -- 5: More occurrences of RFCTODO
Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-yusef-dispatch-ccmp-indication-04 Reviewer: Ben Campbell Review Date: 2013-07-16 IETF LC End Date: 2013-07-16 Summary: This draft is almost ready for publication as a proposed standard, but I think there are some clarifications needed first. Major issues: -- None Minor issues: -- Abstract: Is the abstract current? It says you will discuss pros and cons of a few options, and recommend two. I guess you did recommend two, but the others have been relegated to the appendix. There are no pros and cons listed for the two recommended choices, which seems rather odd. It also mentions that these are mechanisms to be used by SIP clients. That's not repeated in the introduction. Is this entire draft intended exclusively for SIP clients? -- 2. It would be helpful to give more guidance on when one would use one method over the other. 2.1 mentions that it might be an easier way for a UA that is not interested in the URI. I'm not sure what it means for a UA to be interested or not interested in a URI--maybe you mean A UA that does not otherwise need to parse the URI? -- 2.1: I assume this section is intended to be SIP specific. It would help to say that somewhere, and include a 3261 citation for Call-Info. There are hints that the entire draft is SIP specific in the abstract, but that doesn't get repeated elsewhere. (In fact, the only non-abstract citation to 3261 is in the IANA considerations.) Also, the section seems underspecified. It says the ccmp value can go in any INVITE, INVITE response, or OPTIONS response. It would help to describe how UAs would actually use it. Simply naming the actors would help; as it is, they are obscured by the passive voice in ... can be used..., and the reader is left to infer the intent based on his knowledge of SIP. --2.2: I assume this section is _not_ necessarily SIP specific. If that's the intent, it would be helpful to say so. -- Appendices: There's more detail and discussion around the discarded methods than the recommended ones in sections 2.X. It would be helpful to have those sections have at least this much explanation. -- section 3: You say this draft introduces no additional security considerations. Statements like that turn out false more often than not. For example, is there no security consideration created by having a SIP UA identify itself as a conference focus in an INVITE? (Even if the answer is no, it's helpful to have text along the line of we thought about this and decided it was not a consideration due reasons Further, you say ... beyond those applicable to the mechanisms described within. The mechanisms in sections 2.X are described within. I assume those aren't the ones you mean here. Nits/editorial comments: -- Abstract: The abstract should not contain citations. It will be published in multiple places without the rest of the document, orphaning the citations.
Re: The case of dotless domains
In message 20130716150721.gg29...@mip.a.org, Ofer Inbar writes: What this brings to mind is that we used to have implicit DNS domain search in the early days of DNS. When edu.com accidentally hijacked a huge chunk of the Internet, most of the net very quickly got rid of implicit search, and we got the explicit DNS search feature that many people are discussing now. Yes. Can you (or Ofer) define how you're using the terms explicit and implicit in terms of DNS search, and what their relevance is to the topic of dotless domains? And no, I'm not being snarky, I think part of the problem here is a fundamental misunderstanding of how the vast majority of hosts are configured currently. You're not being snarky, but that indicates that you seem to have missed my point, which is not about the technical details of how domain search got changed after the edu.com disaster. My point is not to make a direct parallel between how domain search changed, and dotless domains, and you seem to be looking at it in that light. What this brings to mind is that we had a DNS system that was vulnerable to the addition of something to the DNS that people had expected nobody would make the mistake of doing, but it happened and caused damage, and the net reacted by altering how DNS software works in order to protect against that damage. At the time, the obvious defensive change was don't do implicit domain search. If dotless domains cause damage as many people here predict, what I'm saying is that I think we'll react similarly, and that I guess the defensive change people will widely deploy is to reject A//MX records at the top level. You really do not need to drill into the specifics of the change from implicit to explicit domain search in reaction to edu.com, in this context. So it sounds to me like you have something quite different in mind. I don't know what you think I was trying to say - it's not anything I said explicitly, so perhaps you think I was trying to subtly say something between the lines. To be clear: I wasn't. -- Cos It was more than implicit to explicit. It was also trying domains with dots as is first. Domains with perids were treated as fully qualified until proved otherwise. Unqualified domains were qualified then tried as is if a match was not found. It is bad to treat domains with periods as partially qualified. It is bad to treat domains without periods as qualified. Note it is also more than A, and MX record at the tld label. It is also SRV records where they are used with a base name in a host context. _http._tcp.tld/SRV is equally bad as tld/A where as _whois._tcp.tld/SRV would not be a issue as it would point to the whois service for names that end in .tld. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
RE: Announcement improvement (was: Re: Last Call: RFC 2050 to historic)
+1. Likewise, if I may add; the summary of the progress specifically on the MPLS-TP (i.e. Ratified / Pending / On-going / Expired). Thanks Medel + -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin J. D端rst Sent: Tuesday, July 16, 2013 5:32 PM To: ietf@ietf.org Cc: The IESG; IETF-Announce Subject: Announcement improvement (was: Re: Last Call: RFC 2050 to historic) For the benefits of those (few and far between) IETF participants that haven't memorized all RFC numbers, it would be great if announcement such as the one below would contain a tiny bit more information about the document itself. E.g. just having the title of the document in announcement would make it a lot easier to decide whether this warrants further attention or not, without additional lookup. Many thanks in advance! Regards, Martin. On 2013/07/11 6:39, The IESG wrote: The IESG has received a request from an individual participant to make the following status changes: - RFC2050 from Best Current Practice to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-2050-to-historic/ 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 2013-08-07. 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 affected document can be obtained via http://datatracker.ietf.org/doc/rfc2050/ IESG discussion of this request can be tracked via http://datatracker.ietf.org/doc/status-change-2050-to-historic/ballot/ This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately.
Re: Last Call: draft-ietf-weirds-using-http-07.txt (HTTP usage in the Registration Data Access Protocol (RDAP)) to Proposed Standard
At 16:05 15-07-2013, The IESG wrote: The IESG has received a request from the Web Extensible Internet Registration Data Service WG (weirds) to consider the following document: - 'HTTP usage in the Registration Data Access Protocol (RDAP)' draft-ietf-weirds-using-http-07.txt as Proposed Standard The Abstract mentions that: This document is one of a collection that together describe the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). In Section 2 it is mentioned that: RDAP query and response formats are described in other documents in the collection of RDAP specifications, while this document describes how RDAP clients and servers use HTTP to exchange queries and responses. I read the document and I did not find any other information about collection of RDAP specifications. According to Section 1: This document describes the usage of HTTP for Registration Data Directory Services. From Section 2: In accordance with [SAC-051], this document describes the base behavior for a Registration Data Access Protocol (RDAP). [SAC-051] describes a protocol profile of RDAP for Domain Name Registries (DNRs), the Domain Name Registration Data Access Protocol (DNRD-AP). The recommendation in SAC051 is to adopt the following terminology: Domain Name Registration Data Access Protocol (DNRD-AP). The components of a (standard) communications exchangequeries and responsesthat specify the access to DNRD I did not find any other information about the Registration Data Access Protocol. It is weird that the IETF is standardizing a collection of documents which is undocumented. It is also weird that the IETF is standardizing the Registration Data Access Protocol when there isn't any information about the said protocol except for the terminology mentioned above. From Section 1: A replacement protocol is expected to retain the simple transactional nature of WHOIS, while providing a specification for queries and responses, redirection to authoritative sources, support for Internationalized Domain Names (IDNs, [RFC5890]), and support for localized registration data such as addresses and organisation or person names. I read the draft again and I still did not know what the replacement protocol is. I suggest clarifying where the Registration Data Access Protocol actually exists and where is it specified. In Section 1: This is the basic usage pattern for this protocol: 1. A client issues an HTTP query using GET. As an example, a query for the network registration 192.0.2.0 might be http:// example.com/ip/192.0.2.0. 2. If the receiving server has the information for the query, it examines the Accept header field of the query and returns a 200 response with a response entity appropriate for the requested format. 3. If the receiving server does not have the information for the query but does have knowledge of where the information can be found, it will return a redirection response (3xx) with the Location: header field containing an HTTP(S) URL (Uniform Resource Locator) pointing to the information or another server known to have knowledge of the location of the information. The client is expected to re-query using that HTTP URL. 4. If the receiving server does not have the information being requested and does not have knowledge of where the information can be found, it returns a 404 response. 5. If the receiving server will not answer a request for policy reasons, it will return an error response (4xx) indicating the reason for giving no answer. The above is basically HTTP being given another name. Section 3 of the draft says that: HTTP also benefits from widespread investment in scalability, reliability, and performance, and widespread programmer understanding of client behaviours for RESTful web services, reducing the cost to deploy Registration Data Directory Services and clients. It seems that someone decided to choose port 80 and then went to find the reasons for that choice. Can I ask for some references for the above? I am okay if I am told that I have to believe that it is true because it is written in a RFC. From Section 4.2: Servers MUST ignore unknown query parameters. Use of unknown query parameters for cache-busting is described in Appendix B. If I understood the requirement it is that the servers must ignore unknown query parameters while the draft documents usage of unknown query parameters in Appendix B. This doesn't make sense to me. From Section 5: While no standard HTTP response code is forbidden in usage, at a minimum clients SHOULD understand the response codes described in this section as they will be in common use by servers. I don't understand the SHOULD
Re: Internationalization and draft-ietf-abfab-eapapplicability
On 16 jul 2013, at 21:42, Bernard Aboba bernard_ab...@hotmail.com wrote: After reading this document, I believe that this document omits discussion of an important aspect, which is internationalization. Since the contents of the EAP Identity and RADIUS User-Name attributes are specified to be encoded in UTF-8, application protocols that utilize encodings other than UTF-8 for user identities and passwords could have issues utilizing EAP (and RADIUS). Currently RFC 4282bis proposes that all EAP implementations normalize identities and passwords before utilizing them, and therefore application protocols that do not do this will be at variance with RFC 4282bis. IMHO the document needs to state what the internationalization requirements are for application-layer protocol use of EAP. There are potential workarounds, such as requiring that application protocols convert identities and passwords to UTF-8 prior to use of EAP, or modifying RFC 4282bis so as to require normalization in RADIUS proxies or servers. However, without fixes being applied and/or changes to RFC 4282bis, use of EAP by applications may not be compatible with either existing specifications or implementations. In addition to this, if the string is to be compared with other strings (directly or indirectly) just specifying encoding is not enough. You must also specify the matching algorithm used, and one such can be for example to normalize the string(s) before doing character by character comparison and specifying what the normalization algorithm is. Patrik Fältström Background EAP and protocols that carry it (e.g. RADIUS) assume that the EAP-Response/Identity is encoded in UTF-8. For example, RFC 3748 Section 1.2 defines displayable message as follows: Displayable Message This is interpreted to be a human readable string of characters. The message encoding MUST follow the UTF-8 transformation format [RFC2279]. Therefore EAP messages including EAP Identity and Notification that are described as displayable messages have a UTF-8 encoding requirement applied to them. Since RFC 3579 Section 2.1 specifies that the EAP-Response/Identity is copied into the RADIUS User-Name Attribute: In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. Therefore for use with EAP, the User-Name Attribute also inherits a UTF-8 encoding requirement, restricting the potential encodings permitted by RFC 2865 Section 5.1 (User-Name Attribute): The format of the username MAY be one of several forms: text Consisting only of UTF-8 encoded 10646 [7] characters. network access identifier A Network Access Identifier as described in RFC 2486 [8]. distinguished name A name in ASN.1 form used in Public Key authentication systems.
Last Call: draft-ietf-emu-eap-tunnel-method-07.txt (Tunnel EAP Method (TEAP) Version 1) to Proposed Standard
The IESG has received a request from the EAP Method Update WG (emu) to consider the following document: - 'Tunnel EAP Method (TEAP) Version 1' draft-ietf-emu-eap-tunnel-method-07.txt as 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 2013-07-30. 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 This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1902/
IETF 87 - Early Bird Registration Cutoff: Friday, 19 July
87th IETF Meeting Berlin, Germany July 28-August 2, 2013 Platinum Sponsor: DENIC Gold Sponsors: Deutsche Telekom and EURid Bronze Sponsor: Dyn Meeting venue: InterContinental Berlin: http://www.berlin.intercontinental.com/ Register online at: http://www.ietf.org/meetings/87/ 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday, 19 July 2013 UTC 24:00 B. After Early-Bird cutoff - USD 800.00 C. Full-time Student Registrations - USD 150.00 (with proper ID) D. One Day Pass Registration - USD 350.00 E. All fees include 19% VAT F. Registration Cancellation Cut-off for registration cancellation is Monday, 22 July 2013 at UTC 24:00. Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. G. Online Registration and Payment ends Friday, 26 July 2013, 1700 local Berlin time. H. On-site Registration starting Sunday, 28 July 2013 at 1100 local Berlin time. Only 12 days until the Berlin IETF!
