RE: [Tools-discuss] independant submissions that update standards track, and datatracker
Irrepressible Yours Irrespectively, John From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun Sent: Wednesday, October 02, 2013 5:19 AM To: Michael Richardson Cc: ietf; tools-disc...@ietf.org Subject: Re: [Tools-discuss] independant submissions that update standards track, and datatracker Hi Michael, I agree that it should appear in related WG's field or area. I see in IETF we have WGs documents list but not areas' documents list, so the individual document may not be found or discovered. I think any document of IETF should be listed in its field area or related charter, but it seems like the culture of IETF focusing on groups work not on the IETF documents. For example, when I first joined MANET WG I thought that RFC3753 is related because it is IETF, but in one discussion one participant did not accept to use that document even though it was related. Fuethermore, some WGs don't comment on related documents to their WG, which I think this should change in future IETF culture (e.g. there was one individual doc that was requested by AD to comment on by the WG but no respond). Therefore, IMHO, the IETF is divided by groups with different point of views/documents and they force their WG Adopted-Work to list documents (not all related to Group-Charters), but it seems that managemnet does not see that there is a division in knowledge or in outputs of the IETF, which a new comer may see it clearly. I recommend to focus/list documents related to Charter, not related to WG adoptions, because all IETF document are examined by IESG. AB On Tue, Oct 1, 2013 at 7:29 PM, Michael Richardson mcr+i...@sandelman.camailto:mcr+i...@sandelman.ca wrote: This morning I had reason to re-read parts of RFC3777, and anything that updated it. I find the datatracker WG interface to really be useful, and so I visited http://datatracker.ietf.org/wg/nomcom/ first. I guess I could have instead gone to: http://www.rfc-editor.org/info/rfc3777 but frankly, I'm often bad with numbers, especially when they repeat... (3777? 3737? 3733?) While http://datatracker.ietf.org/wg/nomcom/ lists RFC3777, and in that line, it lists the things that update it, it doesn't actually list the other documents. Thinking this was an error, I asked, and Cindy kindly explained: http://datatracker.ietf.org/wg/nomcom/ lists the documents that were published by the NOMCOM Working Group. The NOMCOM Working Group was open from 2002-2004, and only produced one RFC, which is RFC 3777. The RFCs that update 3777 were all produced by individuals (that is, outside of the NOMCOM Working Group), and so aren't listed individually on the NOMCOM Working Group documents page. I wonder about this as a policy. Seeing the titles of those documents would have helped me find what I wanted quickly (RFC5680 it was)... While I think that individual submissions that are not the result of consensus do not belong on a WG page. But, if the document was the result of consensus, but did not occur in a WG because the WG had closed, I think that perhaps it should appear there anyway. -- Michael Richardson mcr+i...@sandelman.camailto:mcr%2bi...@sandelman.ca, Sandelman Software Works ___ Tools-discuss mailing list tools-disc...@ietf.orgmailto:tools-disc...@ietf.org https://www.ietf.org/mailman/listinfo/tools-discuss
RE: RSOC Appointments
But they have different ages, IQs, and shoe sizes. Yours Irrespectively, John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Bush Sent: Monday, June 24, 2013 10:54 PM To: Fred Baker (fred) Cc: ietf list; Nevil Brownlee; Bob Hinden; IAB; Joe Hildebrand (jhildebr); Alexey Melnikov; Bernard Aboba Subject: Re: RSOC Appointments Congratulations, gentlemen. and they are all male
Re: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
AB, This may surprise you, but not everyone cares what you think. John Sent from my iPhone On Jun 8, 2013, at 1:51 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Dear Routing Area AD, I had many comments/issues regarding your area always addressed to you and including this issue which I hope my all comments (past/present) will help to make better practice/procedural progresses in this IETF Area. I am sorry also to any one receiving this email but I send it only to an AD, IETF, and IESG. This is not noise but a signal to IETF to progress, if you think it is noise please explain, and please notice that all particpants have rights under the IETF procedures not only managements. My reply below and if you want to continue discussing on any other list please inform me, but if you reply copying any list, I will have to do the same because you are part of management and I am not. On 6/6/13, Adrian Farrel adr...@olddog.co.uk wrote: Sorry to everyone for the noise this thread is creating. This thread containing my messages never creates noise, I beleive you may ne refering to your messages only as noise. Please note that I don't accept this describtion, I think that community messages regarding any I-D is never noise even if the IETF management could not handle the volume. I RECOMMEND any receiver that has noise in it to fix its problem without blaming transmitters. Multiple questions that I have to answer. ok, that is why this list is discussing list for ietf progress, It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. What was the WG decision? Are you asking whether there was an explicit consensus call within the working group on whether or not you should be acknowledged in this document? I think the question is clear, and is easy to answer. The answer is, there was no decision made by the WG or the community regarding my request of adding a name in the ack section. You send me back a question saying explicit consensus, it is simpler to make my question asking of notification of such reaction from management, which was not either established. I did not get a message saying that any kind of consensus was established privately/publicly on any IETF lists (please ask the WG chair because I am sure I did not received any answer for my request by the WG/community). There was no such call in the working group or on the IETF list. Thanks for the answer, so I understand that the editors/management did not answer my request (one person from the community), just because they or AD did not beleive in my concerns without consulting the WG in any way. Why any contribution that influnces the I-D ideas is not acknowledged? IMO, if a technical-idea within the I-D was discovered wrong by a participant, or a new technical-idea added to I-D from an input, then the I-D should be acknowledged. This opinion does not apply to your comments on this document. You did not discover a wrong technical-idea. Your comments did not lead directly to the addition of any new technical-idea. The question of I-D managers not acknowledging such input/contribution, was not answered if you agree to acknowledge discovering an error or adding a new idea. Regarding the opinion, do you agree with the opinion first? Regarding the error and missing information, I did discover error in the document and did found missing definitions if this informational I-D (after my contribution there was changes made to the document, please notice that) I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. Didn't that person make review and discovered errors? That person is you. Yes but I said that because this message it not me defending me, it is me defending future wrong reaction of ignoring to acknowledge the persons in the community. If any I-D authors are best knowledgeable people in a special field they should not try to seek to dis-acknowledge the community efforts that changed few I-D ideas (even if the community person is not expert, that does not mean that authors have right to exclude contributors). Yes, you made a review. Reviewing a document is not something authors acknowledge in the IETF or (AFAIK) in academic journals. I disagree with your opinion, but do you think your opinion is in the IETF procedure, if yes please provide me with that procedure of not acknowledgement. I respect your opinion but it is wrong because in one sense yes documents in the world don't acknowledge all
RE: IETF Diversity Question on Berlin Registration?
What a concept. Irrespectively Yours, John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda Shore Sent: Monday, April 29, 2013 9:52 AM To: ietf@ietf.org Subject: Re: IETF Diversity Question on Berlin Registration? On 4/29/13 1:11 AM, Stewart Bryant wrote: The other thing to remember is that whilst your proportional estimates are likely to be correct, in a random process you will get long runs of bias that only average out in the long run. Right, although if normal statistical fluctuation gives us a long period of woman-free leadership, somewhere in your long run we might expect the same statistical fluctuation to deliver unto us a stretch in which women are overrepresented in the leadership. Melinda
RE: IETF Diversity Question on Berlin Registration?
Age, IQ, shoe size? (Ideally, they should be equal.) Irrespectively Yours, John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eliot Lear Sent: Thursday, April 18, 2013 9:01 AM To: Dan Harkins Cc: ietf@ietf.org Subject: Re: IETF Diversity Question on Berlin Registration? Self inflicted confusion. Please see below: On 4/18/13 5:17 PM, Dan Harkins wrote: Hi Eliot, On Wed, April 17, 2013 12:48 pm, Eliot Lear wrote: Pardon me, but that makes no sense. Asking about the gender make-up of those who elect to register for a future meeting is going to tell us little about who we are. It will be a snapshot in time and it will not representative of who we are because we are more than just the people who register to go to any particular meeting. And let's stop there. The point of my originally muddled note was that we shouldn't just ask about gender. For that I apologize. Also, I wouldn't do this just one time. The facts are already not in dispute. The I* leadership is predominantly white and male. The fallacy works like this: We don't have facts in evidence, and as I wrote above, I'm not even sure we know which facts we need. I can say that gender is probably one, country of residence is something we have, age is something we don't ask, but we do ask how many meetings you've been to. We don't ask why you're at the IETF and we don't ask which groups are important to you. We don't ask whether you plan to attend other IETFs and we don't ask anyone who has attended an IETF but isn't back, why they didn't show. We don't ask questions about the experience, in terms of how people are able to find their way through the process. There are many questions we don't ask. Now granted, some of this is more than who we are, but also how easy are we to work with. How does language and location play into this? Personally I'd love to survey people going to OTHER standards organizations and find out why they chose those other organizations to pursue work, but then I'm not footing the bill for all of this, so... This is not just about one attribute. You're ALMOST right in that a lot of us know each other. Perhaps that's even a problem, in that others can't break in. Much of this is what I would expect the diversity team to explore. Eliot
RE: IETF Diversity Question on Berlin Registration?
AB, Is it true that you are really Professor Irwin Corey? Irrespectively Yours, John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun Sent: Tuesday, April 16, 2013 9:51 PM To: ietf Subject: Re: IETF Diversity Question on Berlin Registration? My own feeling is that if we were to find that the numbers supported the notion that there's bias present in the system we probably couldn't do anything about it without tearing the organization apart, so, Is there a way to increase #countries #small companies #women etc? Be it about the participants or the leadership. Could we set a goal that we'll increase some aspect every year, 2014 to be better than 2013? IMO we can do many thing about it, if we discuss these issues into an I-D. - There is a way to increase #women when they decide together as a group what is missing, and what should be done, - There is a way to increase #small companies when they are accepted/involved in IETF WGs documents. If individuals are encouraged then SMEs will be as well, - There is a way to increase #countries/states when each have their accepted access to the IETF WG system. I may suggest that each WG system to not only have two chairs, but also 5 administrated participants (for each continent, they may give chance to SMEs access and new I-Ds) that should look into the implementation/running-code of the IETF WG standards in real life. They can look into countries/states challenges/involvement in such work of the WG, to be documented if available. Countries will only increase- in/use IETF if their SMEs are using IETF systems. Now it seems that there are influences/directions from the industry/countries to IETF WGs' work but not seen/clear to others. For women, I think there must be at least 10% of women in the IETF leadership, as we should not ignore that many research/SMEs in industry are directed by women. They should publish an I-D related if they are interested. Is IETF still directed by men or both? AB
RE: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T
Smoke filled rooms Irrespectively Yours, John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of David Kessens Sent: Thursday, March 28, 2013 10:04 AM To: Stewart Bryant Cc: ietf@ietf.org Subject: Re: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T Stewart, On Thu, Mar 28, 2013 at 01:13:44PM +, Stewart Bryant wrote: In this particular case the candidate pool would have been tiny, because the criteria would surely have included being experienced with both the ITU process and the IETF liaison process, including knowing and understanding the liaison history. Therefore it seems unlikely that there would be any candidate that the IAB did not already know about. So whilst I agree in general, this is not a case that should raise any concerns. This is exactly the reaction that makes me worried: if the pool of candidates is already considered to be thin to begin with, it makes even more sense to do a call for volunteers to make 100% sure that nobody gets overlooked. It's not a healthy culture to only allow positions to be filled from the inside crowd. It's time to fix that. David Kessens ---
RE: congestion control? - (was Re: Appointment of a Transport AreaDirector)
See also: http://www.akamai.com/html/about/press/releases/2012/press_091312.html Irrespectively Yours, John From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Cameron Byrne Sent: Wednesday, March 06, 2013 8:12 AM To: Brian E Carpenter Cc: bra...@isi.edu; IETF-Discussion Subject: Re: congestion control? - (was Re: Appointment of a Transport AreaDirector) On Mar 6, 2013 1:03 AM, Brian E Carpenter brian.e.carpen...@gmail.commailto:brian.e.carpen...@gmail.com wrote: On 06/03/2013 08:36, t.p. wrote: ... Interesting, there is more life in Congestion Control than I might have thought. But it begs the question, is this something that the IETF should be involved with or is it better handled by those who are developping LTE etc? From the little I know about TCP proxies, they are horrible beasts that can impact application layer semantics. Figuring out how to deal with mixed e2e paths (partly lossy, partly congested) seems to me very much an IRTF/IETF topic, even if we don't have an AD who is a subject matter expert. Brian There is a huge cross layer optimization issue between 3gpp and the ietf. It is worse than you can imagine, highly akin to how the industry moved passed the ietf with Nat. The same thing is happening with tcp. Tcp is simply not fit for these high latency high jitter low loss networks. Google is a player in the e2e space for various business reasons and it appears they are now in an arms race with these horrible mobile carrier proxies (which in many cases do on the fly transcoding of video). There are 2 fronts. 1 is quic as linked above. Another is their own transcoding https proxy https://developers.google.com/chrome/mobile/docs/data-compression This is not novel. Opera mini has been doing this for years, otherwise know as opera turbo. Oh, and Nokia has been doing it too. They even help by bypassing pki and any sense of internet security. http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799 Hold on to your hats. CB
RE: Nomcom off in the wilderness: Transport AD
Eric, This was exactly the point I made earlier in an email to Dave Crocker. Irrespectively Yours, John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric Gray Sent: Wednesday, March 06, 2013 12:59 PM To: Bob Hinden; dcroc...@bbiw.net Cc: ietf@ietf.org Subject: RE: Nomcom off in the wilderness: Transport AD Bob, This confuses me. Are you saying that you would be more able to give feedback on someone you don't know if you knew what they might have to say about themselves? I would think that - if you don't know somebody - you can't give feedback on them (and that is precisely as it should be). -- Eric -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Bob Hinden Sent: Wednesday, March 06, 2013 2:45 PM To: dcroc...@bbiw.net Cc: Bob Hinden; ietf@ietf.org Subject: Re: Nomcom off in the wilderness: Transport AD Hi, Just to be clear: I am not suggesting public discussion. I'm suggesting that candidates make their responses available to the community, so the community can have additional information for providing feedback to the Nomcom. I agree with Dave on this. I try to give feedback on the NomCom lists of candidates. For people I know, I can do this, for people I don't know well it's difficult. It would help me if I could read some of the material they submitted with their acceptance of the nomination to see why they want the job, and their qualifications and experience. The IETF has grown a lot over the years to the point where most people don't know all of the candidates. Bob
RE: Nomcom off in the wilderness: Transport AD
Mary, As a potential nominee I considered the questionnaire to be a barrier to entry and as a NomCom member I considered the questionnaire answers to be useless. Irrespectively Yours, John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, March 06, 2013 1:22 PM To: Eric Gray Cc: Bob Hinden; dcroc...@bbiw.net; ietf@ietf.org Subject: Re: Nomcom off in the wilderness: Transport AD Eric, On Wed, Mar 6, 2013 at 2:59 PM, Eric Gray eric.g...@ericsson.com wrote: Bob, This confuses me. Are you saying that you would be more able to give feedback on someone you don't know if you knew what they might have to say about themselves? I would think that - if you don't know somebody - you can't give feedback on them (and that is precisely as it should be). [MB] This then begs the question in my opinion as to how Nomcom can evaluate nominees from the questionnaires then? Also, As I noted in my previous response, even when you know someone you likely don't know everything about what they have accomplished or you have forgotten some things. [/MB] -- Eric -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Bob Hinden Sent: Wednesday, March 06, 2013 2:45 PM To: dcroc...@bbiw.net Cc: Bob Hinden; ietf@ietf.org Subject: Re: Nomcom off in the wilderness: Transport AD Hi, Just to be clear: I am not suggesting public discussion. I'm suggesting that candidates make their responses available to the community, so the community can have additional information for providing feedback to the Nomcom. I agree with Dave on this. I try to give feedback on the NomCom lists of candidates. For people I know, I can do this, for people I don't know well it's difficult. It would help me if I could read some of the material they submitted with their acceptance of the nomination to see why they want the job, and their qualifications and experience. The IETF has grown a lot over the years to the point where most people don't know all of the candidates. Bob
RE: FW: Affirmation of the Modern Global Standards Paradigm
Comment inline Sent from my iPhone -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Wednesday, August 15, 2012 12:00 AM To: Eliot Lear Cc: John E Drake; i...@iab.org; ietf@ietf.org Subject: Re: FW: Affirmation of the Modern Global Standards Paradigm On 15/08/2012 07:24, Eliot Lear wrote: John, On 8/15/12 12:03 AM, John E Drake wrote: Hi, Does this document actually have a purpose, and if so, what is it? To me (and I speak only for me here), the purpose of this document is to articulate principles that have made the Internet a success. It is a means to invite others to subscribe to those same principles, and there are many standards organizations that do not. Customers and society can demand better, and this is an avenue for that. I take it that John's question is really *why* do these principles need to be articulated in public. Perhaps the IAB should answer that, but my answer is: because there is a real danger of some SDOs, including but not limited to the ITU-T, breaking them for a variety of commercial or political reasons. JD: And how does this document prevent this abuse? Brian
RE: FW: Affirmation of the Modern Global Standards Paradigm
Sent from my iPhone From: Eliot Lear [mailto:l...@cisco.com] Sent: Tuesday, August 14, 2012 11:25 PM To: John E Drake Cc: i...@iab.org; ietf@ietf.org Subject: Re: FW: Affirmation of the Modern Global Standards Paradigm John, On 8/15/12 12:03 AM, John E Drake wrote: Hi, Does this document actually have a purpose, and if so, what is it? To me (and I speak only for me here), the purpose of this document is to articulate principles that have made the Internet a success. JD: This seems a bit presumptuous to me. It is a means to invite others to subscribe to those same principles, and there are many standards organizations that do not. JD: I would be willing to bet that nearly every SDO would claim they embrace these same principles. Customers and society can demand better, and this is an avenue for that. JD: How, exactly? Eliot
RE: Affirmation of the Modern Global Standards Paradigm
Comment inline Sent from my iPhone -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Wednesday, August 15, 2012 5:38 AM To: John E Drake Cc: Hannes Tschofenig; Brian E Carpenter; Eliot Lear; i...@iab.org; ietf@ietf.org Subject: Re: Affirmation of the Modern Global Standards Paradigm On Aug 15, 2012, at 3:16 PM, John E Drake wrote: I take it that John's question is really *why* do these principles need to be articulated in public. Perhaps the IAB should answer that, but my answer is: because there is a real danger of some SDOs, including but not limited to the ITU-T, breaking them for a variety of commercial or political reasons. JD: And how does this document prevent this abuse? Of course a document by itself, even if it contains the nicest principles, cannot prevent abuse. So, see it rather as a writeup that tries to capture the understanding of a number of SDOs. JD: To what purpose? As an aside, I get the 'feel-good' aspect, but is there anything more?
RE: FW: Affirmation of the Modern Global Standards Paradigm
Eliot, Your explanation of the document’s efficacy leaves me skeptical. We should always do something for a reason. Thanks, John Sent from my iPhone From: Eliot Lear [mailto:l...@cisco.com] Sent: Wednesday, August 15, 2012 5:44 AM To: John E Drake Cc: i...@iab.org; IETF Discussion Subject: Re: FW: Affirmation of the Modern Global Standards Paradigm Hi John, On 8/15/12 2:15 PM, John E Drake wrote: To me (and I speak only for me here), the purpose of this document is to articulate principles that have made the Internet a success. JD: This seems a bit presumptuous to me. It's an assertion. I wouldn't claim, by the way, that this was the only factor. IMHO, it was a contributing factor. Moore's Law and the development of technology in general all contributed, but you had to have a process that was open for the technology to flourish. IMHO this is why SNA, DECNET, Appletalk, XNS, OSI, and others did not win, where IP did. It is a means to invite others to subscribe to those same principles, and there are many standards organizations that do not. JD: I would be willing to bet that nearly every SDO would claim they embrace these same principles. And that's a fair point. The proof is in the pudding. I believe, and I know you do too, that the IETF itself can explain in clear indisputable terms how it fulfills the principles of openness. Anyone can join a WG list. Anyone can submit an Internet-Draft, anyone can comment on that draft, anyone can request that draft's advancement, anyone can comment on or contribute to or object to that draft's advancement, anyone can be a part of the leadership (one needn't even have ever participated in the IETF before!!). Decisions are made through a consensus process. That process is designed to be transparent. There are appellate avenues for abuse of process. They have worked and are working. I am told for instance that at this very moment there is an appeal before the applications area director that seems to me particularly meaty. That's good. It's important that people know that there is an appeals avenue available. The W3C is very similar. The IEEE SA is also similar. So are others, and that's fine. But there are many other organizations where it's just not the case, and so... Customers and society can demand better, and this is an avenue for that. JD: How, exactly? How about a phone call? A blog? A press release? Laws and regulations requiring the use of standards based on those principles? Eliot
RE: FW: Affirmation of the Modern Global Standards Paradigm
AB, I don't think the principles articulated in this document will come as a surprise to any SDO with which the IETF interacts and I don't think this document will prevent another SDO from acting badly wrt the IETF if it so chooses. Also, bear in mind that 'acting badly' is entirely subjective. For example, if you were to ask the ITU leadership if they 'acted badly' during the MPLS-TP imbroglio, I think they would counter that it was the IETF that 'acted badly'. In fact, I have seen them say exactly this. And lest we forget, we had a much more comprehensive agreement in place for MPLS-TP. Thanks, John Sent from my iPhone From: Abdussalam Baryun [mailto:abdussalambar...@gmail.com] Sent: Wednesday, August 15, 2012 6:29 AM To: John E Drake Cc: ietf Subject: Re: FW: Affirmation of the Modern Global Standards Paradigm Hi John, Does this document actually have a purpose, and if so, what is it? IMO the document introduces important statements (purpose and objectives) so that other organisations and SDOs recognise while interacting with IETF. It may look simple or known, but necessary for IETF future cooperations. I agree that your question is very important and that the best person to answer is the Chair of IETF or IAB. AB
RE: FW: Affirmation of the Modern Global Standards Paradigm
AB, I couldn't answer this until I get an answer to my original question regarding the document's purpose. I also have a related question, viz, is there a plan of some sort of which this document is a component, or is the document simply a one-off? Thanks, John Sent from my iPhone From: Abdussalam Baryun [mailto:abdussalambar...@gmail.com] Sent: Wednesday, August 15, 2012 6:57 AM To: John E Drake Cc: ietf; i...@iab.org Subject: Re: FW: Affirmation of the Modern Global Standards Paradigm John, Could you suggest a solution to this issue or an additional statements to the document, I think then the document may need amendment, to consider your advise/experience. AB On Wed, Aug 15, 2012 at 2:46 PM, John E Drake jdr...@juniper.netmailto:jdr...@juniper.net wrote: AB, I don't think the principles articulated in this document will come as a surprise to any SDO with which the IETF interacts and I don't think this document will prevent another SDO from acting badly wrt the IETF if it so chooses. Also, bear in mind that 'acting badly' is entirely subjective. For example, if you were to ask the ITU leadership if they 'acted badly' during the MPLS-TP imbroglio, I think they would counter that it was the IETF that 'acted badly'. In fact, I have seen them say exactly this. And lest we forget, we had a much more comprehensive agreement in place for MPLS-TP. Thanks, John Sent from my iPhone From: Abdussalam Baryun [mailto:abdussalambar...@gmail.commailto:abdussalambar...@gmail.com] Sent: Wednesday, August 15, 2012 6:29 AM To: John E Drake Cc: ietf Subject: Re: FW: Affirmation of the Modern Global Standards Paradigm Hi John, Does this document actually have a purpose, and if so, what is it? IMO the document introduces important statements (purpose and objectives) so that other organisations and SDOs recognise while interacting with IETF. It may look simple or known, but necessary for IETF future cooperations. I agree that your question is very important and that the best person to answer is the Chair of IETF or IAB. AB
RE: Affirmation of the Modern Global Standards Paradigm
Hannes, Let me try a different tack: 1) Is this document intended to change the way that the IETF interacts with other SDOs? 2) What is the document's marginal utility? I.e., what changes if it is published? 3) Is there a plan of which this document is a part or is it simply a 'one-off'? 4) What is the relationship between this document and the mission of the ISOC, which, as I understand it, is to promote the open development, evolution, and use of the Internet? Thanks, John Sent from my iPhone -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Wednesday, August 15, 2012 7:33 AM To: John E Drake Cc: Hannes Tschofenig; Brian E Carpenter; Eliot Lear; i...@iab.org; ietf@ietf.org Subject: Re: Affirmation of the Modern Global Standards Paradigm Hi John, On Aug 15, 2012, at 3:41 PM, John E Drake wrote: JD: To what purpose? As an aside, I get the 'feel-good' aspect, but is there anything more? I like the term - IAB documents as 'feel-good' publications. The IAB publishes a variety of different documents. Some of them are formal communication interactions with other organizations and others are documenting topics that could be of interest to the IETF community or even beyond. These documents are not enforceable in a legal sense (which is good). The content of this specific document did not surprise you and, as a regular IETF participant, it shouldn't. You look at the list of principles and they sound familiar - they make sense (at least to most of us, as folks noted in this discussion thread). The 'Openness', for example, is in my view extremely important since it allows relevant stakeholders to participate: Think about how low the barrier is to participate in the IETF. If you believe that the process has any impact on the quality of the specifications then the principles listed in the document may resonate with you. Many may consider these principles as so obvious that they are not worthwhile to write down. Unfortunately, they are not as obvious as one might think. There are other ways to do standardization and, as we have seen in the discussions on this list, some would like to change the rules of the game. I believe that this will have negative consequences for the Internet eco-system and for the speed of innovation we had gotten so used to. Whether this document can prevent bad things from happening is of course a separate story but it, at least, captures the views of a list of organizations active in Internet standardization. I hope that this makes sense to you. Ciao Hannes
FW: Affirmation of the Modern Global Standards Paradigm
Hi, Does this document actually have a purpose, and if so, what is it? Thanks, John Sent from my iPhone From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of IAB Chair Sent: Wednesday, August 01, 2012 7:19 PM To: ietf-annou...@ietf.org Subject: Affirmation of the Modern Global Standards Paradigm The IAB, IESG, IEEE-SA and W3C have been developing an Affirmation of the Modern Global Standards Paradigmhttp://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-4.pdf. Comments may be sent to i...@iab.orgmailto:i...@iab.org.
RE: Is the IETF aging?
Maybe we would do better if we required attendees to dress as furries. Their conventions seem to attract a younger crowd. Sent from my iPhone -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Friday, April 27, 2012 7:07 AM To: IETF Discussion Mailing List Subject: Is the IETF aging? A question arose on the RFC-interest list, I observed that 20 years ago I was one of the youngest IETF participants and 20 years later that still seems to be the case. I see some grad students and some postdocs in their 20s but not as many as I think there should be. By now at least a third of the organization should be younger than me, preferably half. That is certainly not what I see when I attend IETFs. And yes, the lack of women is also highly noticeable. If this is the case it should worry us greatly. But first I think we need to determine if it is the case or not. I suggest an optional demographic survey of participants in the next IETF meeting to be repeated at regular intervals (no more than 5 years apart). People can argue about process, RFC formats and governance but it should be beyond argument that any institution that cannot recruit younger members is going to die. -- Website: http://hallambaker.com/
RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC
Hi, I agree with the proposal that Russ Housley made, below, but before even provisionally granting G.8113.1 a code point by placing draft-betts in the RFC editor's queue until G.8113.1 is approved, I would like to understand whether there is a reasonable chance for it to be approved at WTSA next fall. Draft-betts was already in the IETF approval process at the time that G.8113.1 was disapproved, so I don't see why lack of a code point was given as a reason for its disapproval. It is my understanding that it is very unusual to send a document to WTSA for approval, so would the authors please indicate the other issues causing G.8113.1 to be disapproved and the plan by which the ITU will address these issues? Thanks, John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley Sent: Thursday, March 01, 2012 3:52 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: IETF Subject: Re: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC Nurit: Some people are using the lack of a code point as the reason that the cannot support the ITU-T document. My approach tells the ITU-T that a code point is available to them IFF they are able to reach consensus. The removes IETF from the discussion. This creates a situation where G.8113.1 succeeded or fails based on the ITU-T members actions, with no finger pointing at the IETF. This is completely a Layer 9 consideration, and it has noting to do with the technical content of the document. Russ On Mar 1, 2012, at 2:33 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: Russ, I propose to simply re-discuss it when and IFF G.8113.1 is mature and approved... Best regards, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Russ Housley Sent: Thursday, March 01, 2012 9:12 PM To: IETF Subject: Re: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC Right now, there is no ITU-T approved document to reference. I am certainly not an expert on ITU-T process, but my understanding is that earliest that we could see an approved G.8113.1 is December 2012. My point is that we don't want to assign a code point until the ITU-T approves their document. However, if we are willing to assign a code point to G.8113.1 once it is approved, then this would be an approach where the code point assignment would block on the approval of the normative reference. I like this approach from the political point of view. With this approach the IETF tells the ITU-T that if and only if they are able to achieve consensus on G.8113.1, then a code point will be assigned. FWIW, this seems entirely appropriate to me. If we do it this way, I think it is important to note --for the benefit of those more historically involved with the ITU and others-- that we routinely block our own documents on normative references to work that is still in progress and, usually, do not do related code point allocations until the blocking referenced documents are ready. Once the present I-D is judged to be sufficiently ready, this approach would therefore be IETF approval and a formal guarantee to the ITU that a code point will be allocated if an when G.8113.1 is approved and published, but not assignment of that code point until the referenced base document is finished. Completely normal procedurally. To be clear John our normal requirement would be that the technical community achieved consensus that the base document was ready. I have never seen ITU-T consensus on the contents of G.8113.1 at any meeting that I have observed. What in your view is the criteria for determining that G.8113.1 has achieved consensus? This is not an IETF problem, and I do not think that the IETF ought to be discussing the internal workings of the ITU-T process. The point is to come up with a mechanism that allows the code point to be assigned if and only if the ITU-T does come to a consensus by whatever means is allowed by their own process. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Questions about draft-betts-itu-oam-ach-code-point
Snipped, comments inline. 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list. However, the MPLS WG have, by rough consensus, adopted a different approach. Therefore, further review by the MPLS WG is of little value. [JD] Um, I don't think so. Since, as you state above, G.8113.1 is effectively draft-bhh and since draft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a code point for G.8113.1, is basically an attempt to subvert the decision by the MPLS WG to reject draft-bhh by attempting to bypass the WG with an individual submission. So, I think it is clear that your draft belongs in the MPLS WG. Incidentally, the MPLS/GMPLS change process was put in place in reaction to the publication of another individual submission, RFC3474, which was completely non-interoperable with standard RSVP, a surprisingly similar situation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt
Huub, In your email, below, you state: This protocol has been defined in the ITU-T and should not be considered to be a MPLS protocol and therefore should not subject to the provisions of RFC 4929. The subject protocol is used to provide OAM for MPLS networks. You seem to be saying that because this protocol was developed by the ITU, it is not subject to the provisions of RFC 4929. However, it is my understanding that RFC 4929 was put in place in order to ensure that all enhancements to MPLS are done in the IETF using the process defined in RFC 4929. Perhaps rather than asserting that it is exempt from RFC 4929, you could share the reasoning that leads you to this assertion? You also state: It does not make any proposals to modify the MPLS data plane forwarding behaviour or of the any IETF defined protocols. Therefore, review by the MPLS WG is not required. However, it is my understanding that the subject protocol is the same as that defined in 'MPLS-TP OAM based on Y.1731' ( http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-07). As I am sure you are aware, that protocol was fully discussed by the MPLS working group at both the Maastricht and Beijing meetings, and was explicitly rejected by the working group. Doesn't this request for a code point for the subject protocol without review by the MPLS working group constitute an attempt to circumvent the decision made by that working group? I call on the nominated AD to redirect this work to the MPLS working group using the MPLS change process. Thanks, John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub helvoort Sent: Thursday, December 01, 2011 1:17 PM To: Adrian Farrel Cc: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; The IESG; Ietf@ietf.org Subject: Request to publish draft-betts-itu-oam-ach-code-point-01.txt Document Writeup for draft-betts-itu-oam-ach-code-point-01.txt As required by RFC-to-be draft-iesg-sponsoring-guidelines, this is the current template for the Document Shepherd Write-Up for individual submissions via the IESG. Changes are expected over time. This version is dated February 5, 2007. -- (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Huub van Helvoort (huub.van.helvo...@huawei.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG to be published. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document was first posted on 16th October; no discussion has taken place on any email lists. However, this draft is addressing a well know issue that was first brought to the attention of the IETF in a request from the director of the ITU-T in June 2010 requesting the assignment of an ACh code point that would be used to run Ethernet based OAM on MPLS-TP networks. The draft requests IANA to assign a code point from the registry of Pseudowire Associated Channel Types. It does not make any proposals to modify the MPLS data plane forwarding behaviour or of the any IETF defined protocols. Therefore, review by the MPLS WG is not required. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. The purpose of the document is clear and the scope is limited to the assignment of a code point for (restricted) use by the ITU-T. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The issue of supporting an alternative set of OAM mechanisms for MPLS- TP based on Ethernet OAM has been widely discussed without reaching any firm conclusion. Note that more than 350,000 nodes have now been deployed with Ethernet based OAM using a code point from the experimental range. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested
RE: LISP is not a Loc-ID Separation protocol
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robin Whittle Sent: Saturday, October 29, 2011 3:07 AM To: ietf@ietf.org Subject: Re: LISP is not a Loc-ID Separation protocol Hi Masataka, I mean no offence. I try to keep my messages brief, [JD] This is a joke, right? and it would be tortuous to write the LISP protocol at every point in this discussion. In the context of the IETF, I think LISP means the protocol. I was not discussing the LISP programming language at all. - Robin On 29/10/2011 7:52 PM, Masataka Ohta wrote: Robin Whittle wrote: Hi Luigi (and other LISP people), As a member of the LISP people (I wrote an interpreter and a compiler for 8080), your statement above is irritating. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Re: [mpls] unresolved technical concerns
Alessandro, Most of the comments I remember reading were of the form we don't like MPLS OAM because it has 'major unresolved technical concerns' and draft-bhh is *so* much better. I.e., they were neither constructive nor actionable. Thanks, John -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, October 19, 2011 1:50 PM To: John E Drake; Luyuan Fang (lufang); Alexander Vainshtein; D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: m...@ietf.org; ietf@ietf.org Subject: R: Re: [mpls] unresolved technical concerns What about going into the mailing list and LS logs and read the comments provided by several service providers before asking for them being repeated again in a I-D that will fate share with the past comments (i.e., ignored)? The comments have been already made. It is now the duty of the party which has so far ignored them to provide an answer. It is also so easy to keep ingnoring drafts and technical comments and request people to continue to produce drafts Messaggio originale Da: jdr...@juniper.net Data: 5-ott-2011 23.20 A: Luyuan Fang (lufang)luf...@cisco.com, Alexander VainshteinAlexander. vainsht...@ecitele.com, D'Alessandro Alessandro Gerardoalessandro. dalessan...@telecomitalia.it, Stewart Bryant (stbryant)stbry...@cisco.com Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org Ogg: Re: [mpls] unresolved technical concerns That's because it is *so* much easier to just keep mumbling 'major unresolved technical concerns'. I expect it is something learned in Yoga class. -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Luyuan Fang (lufang) Sent: Wednesday, October 05, 2011 5:11 PM To: Alexander Vainshtein; D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] unresolved technical concerns Yep. We are going in circles again. We need to see technical details on the issues documented in an I-D as Stewart suggested. Don't remember seeing such document either. Luyuan -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, October 05, 2011 4:18 PM To: D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: ietf@ietf.org; m...@ietf.org Subject: Re: [mpls] unresolved technical concerns Dear Alessandro, Lots of thanks for a prompt response. Unfortunately your response does not really help (at least, me) to identify even a single specific technical issue. You may attribute it to my faulty memory, but I could not remember any. Presenting these cocerns in the form of an I-D as suggested by Stewart would be the right first step. My 2c Sasha From: D'Alessandro Alessandro Gerardo [alessandro.dalessan...@telecomitalia.it] Sent: Wednesday, October 05, 2011 6:54 PM To: stbry...@cisco.com; Alexander Vainshtein Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Subject: unresolved technical concerns Dear Stewart, Dear Sasha, I think there are already enough contributions in that direction I (with many other experts) contributed to in the form of IETF mailing list discussion and ITU-T liaisons. Unfortunately I regret to say that some questions for clarification and concerns risen in those emails (for sure some of mine) still remain without an answer. At the same time, some comments provided by ITU-T liaisons still remain unresolved. Best regards, Alessandro -- Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -Messaggio originale- Da: Stewart Bryant [mailto:stbry...@cisco.com] Inviato: mercoledì 5 ottobre 2011 12:24 A: D'Alessandro Alessandro Gerardo Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Oggetto: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring
RE: [mpls] R: Re: 答复: 回复： R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Alessandro, Apparently, the advice given regarding the risks and costs associated with deploying proprietary or pre-standard solutions didn't resonate with you. Do you really expect the rest of us to clean up after you? Thanks, John -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, October 19, 2011 1:49 PM To: brian.e.carpen...@gmail.com; yang.jia...@zte.com.cn Cc: m...@ietf.org; mpls-bounces@ietf.orgLarry; ietf@ietf.org Subject: [mpls] R: Re: 答复: 回复： R: FW: Last Call: draft-sprecher- mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC If the MPLS WG had selected the OAM solution that was already existing (as indicated multiple times by the operators which have already massively deployed it), we would have had a single OAM solution both in the market and in the IETF RFCs. We now have two OAM solutions: one (which is not actually really singular) documented by IETF RFCs and one widely implemented and deployed. This draft is not resolving this issue at all. Messaggio originale Da: brian.e.carpen...@gmail.com Data: 5-ott-2011 22.16 A: yang.jia...@zte.com.cn Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, mpls- bounces@ietf.orgLarry Ogg: Re: [mpls] 答复: 回复： R: FW: Last Call: lt;draft-sprecher- mpls-tp-oam- considerations-01.txtgt; (The Reasons for Selecting a Single Solution for MPLS- TP OAM) to Informational RFC Hi Jian, On 2011-10-06 03:53, yang.jia...@zte.com.cn wrote: Dear All, I do not support either. In section 3.5: If two MPLS OAM protocols were to be deployed we would have to consider three possible scenarios: 1) Isolation of the network into two incompatible and unconnected islands. Two OAM solutions have been discussed for a long time in both ITU-T and IETF. Each solution has their own supporters inculding carriers and vendors. So I don't think there is any interworking issue between two OAM solutions. Carrier will select one OAM solution, A or B, in their network. No need to select A and B at one network at the same time. There are two large costs that you are ignoring: a) all vendors wishing to bid for business from A and B will have to implement and support both solutions. b) when A buys B or B buys A, the incompatible networks will have to be merged. These are costs that run to hundreds of millions of USD, EUR or CNY. They are costs caused directly by SDOs creating rival solutions. I think it would be irresponsible of the IETF not to document this situation. As engineers, we have an ethical responsibility here. Brian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Snipped, comment inline You are making a point on which I picked earlier because it is stated in the document as well. In case there are multiple solutions, documenting, but at the same time discouraging the other one has happened before. Why is this not possible in this case? Make one the default, the other optional with a big red warning sign. Best, Rolf This is indeed possible in this case. It has been privately suggested multiple times, but I agree that this should have been publicly suggested as well (and thus I guess that I am publicly suggesting it now). Ross [JD] How does the IETF put a big red warning sign on a document produced by another standards body? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Are we now going to be subject to daily updates? -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub van Helvoort Sent: Sunday, October 09, 2011 7:42 AM To: IETF Discussion Subject: Re: Last Call: draft-sprecher-mpls-tp-oam-considerations- 01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC All, I still do not support this draft. Section 6 focusses on the interworking between two toolsets In transport networks we *never* have peer-2-peer OAM interworking. If it was required it would have explicitly been mentioned in the MPLS-TP requirements RFC. Why don't you simply read draft-tsb-mpls-tp-ach-ptn or Annex B of G.8110.1 where it is documented how different toolsets can be deployed in a network without any issues. Section 6 is totally irrelevant. Regards, Huub. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
As do I -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of David Sinicrope Sent: Wednesday, October 05, 2011 7:11 PM To: David Allan I Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC I concur with Dave's comment and support publication of the draft. Dave On Oct 5, 2011, at 7:06 PM, David Allan I david.i.al...@ericsson.com wrote: I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does. Therefore I support the publication of draft-sprecher... D MPLS Working Group, Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship. This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the two solutions problem with special reference to MPLS-TP OAM. Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy. As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG. Thanks, Adrian ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] unresolved technical concerns
That's because it is *so* much easier to just keep mumbling 'major unresolved technical concerns'. I expect it is something learned in Yoga class. -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Luyuan Fang (lufang) Sent: Wednesday, October 05, 2011 5:11 PM To: Alexander Vainshtein; D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: m...@ietf.org; ietf@ietf.org Subject: Re: [mpls] unresolved technical concerns Yep. We are going in circles again. We need to see technical details on the issues documented in an I-D as Stewart suggested. Don't remember seeing such document either. Luyuan -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, October 05, 2011 4:18 PM To: D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant) Cc: ietf@ietf.org; m...@ietf.org Subject: Re: [mpls] unresolved technical concerns Dear Alessandro, Lots of thanks for a prompt response. Unfortunately your response does not really help (at least, me) to identify even a single specific technical issue. You may attribute it to my faulty memory, but I could not remember any. Presenting these cocerns in the form of an I-D as suggested by Stewart would be the right first step. My 2c Sasha From: D'Alessandro Alessandro Gerardo [alessandro.dalessan...@telecomitalia.it] Sent: Wednesday, October 05, 2011 6:54 PM To: stbry...@cisco.com; Alexander Vainshtein Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Subject: unresolved technical concerns Dear Stewart, Dear Sasha, I think there are already enough contributions in that direction I (with many other experts) contributed to in the form of IETF mailing list discussion and ITU-T liaisons. Unfortunately I regret to say that some questions for clarification and concerns risen in those emails (for sure some of mine) still remain without an answer. At the same time, some comments provided by ITU-T liaisons still remain unresolved. Best regards, Alessandro -- Telecom Italia Alessandro D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -Messaggio originale- Da: Stewart Bryant [mailto:stbry...@cisco.com] Inviato: mercoledì 5 ottobre 2011 12:24 A: D'Alessandro Alessandro Gerardo Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org Oggetto: Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam- considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form you must standardize what I want will not fly. What is needed is a very clear technical definition of the issue(s). When we have the major unresolved technical concerns on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
RE: Hyatt Taipei cancellation policy?
How about Fresno? Sent from my iPhone -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, August 25, 2011 11:09 AM To: ietf@ietf.org Subject: Re: Hyatt Taipei cancellation policy? On 25/08/2011 18:12, Mary Barnes wrote: I am also a fan of Minneapolis for meetings - the facilities at the Hilton are perfect for our needs. There's lots of food options. It has good air connections and there is decent pubic transport from the airport to the city. However, this seems to be a minority perspective. If we were to do votes again, the results might be interesting. Mary. I like Minneapolis as well, but then, speaking personally, I like US IETF venues in general. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Luca, So, you are considering weighted ECMP, with FAT and entropy label, to be an application? We are also releasing the GAL to float until it finds its proper level within the MPLS label stack? Thanks, John Sent from my iPhone -Original Message- From: Luca Martini [mailto:lmart...@cisco.com] Sent: Friday, August 19, 2011 1:17 PM To: John E Drake Cc: Alexander Vainshtein; m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- gal-in-pw John, I would like to let applications decide how they design the use of the gal. So I would propose a simple change , that will move any discussions to the specific applications: The next text would be as follows: - Section 4.2. (GAL Applicability and Usage) in [RFC5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. Does this work ? Thanks. Luca On 08/18/11 08:00, John E Drake wrote: Sasha, I completely agree with your recommendations: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, August 17, 2011 9:52 PM To: Luca Martini Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf- pwe3- gal-in-pw Luca and all, I have not found the statement you've proposed in draft-ietf-pwe3- fat- pw-06. Instead, it contans the following text in Section 8.5 Applicability to MPLS-TP: quote The flow aware transport of a PW reorders packets, therefore MUST NOT be deployed in a network conforming to the MPLS-TP unless these integrity requirements specified in the SLA can be satisfied. end quote (In the -07 version this text is repeated but followed by an incomplete statement In a immediately followed by the heading of Section 8.6. Since this addition is difficult to parse, I will ignore it for the moment.) IMHO and FWIW this means that prohibition on using flow aware PW in MPLS-TP environments is conditional on meeting specific SLA requirements for the service. So I think that the use case I've presented still holds. Please note also that, regardless of the restriction in draft-ietf- pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the label stack and taking one of multiple NHLFEs for the given incoming label in the ILM) were not used in this domain, e.g., by associating exactly one ILM entry with each incoming label in the ILM. And since MPLS-TP is supposed to carry not just PW clients but also IP ones, I would expect that this would be the case in any MPLS-TP deployment. I also think that releasing one restriction (on using GAL in PWs) at the expense of making another, conditional one (on usage of flow labels in MPLS-TP environments) absolute is not the most appropriate method for resolving technical issues. IMHO and FWIW better way to resolve the problem would be by: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels. I think that these considerations have been presented already in the discussion on draft-nadeau-pwe-vccv-2. Of course it would be even better if we could agree on transition to universal usage of the CW and VCCV Type 1 in PWs. But this is a different story. Regards, Sasha From: Luca Martini [lmart...@cisco.com] Sent: Wednesday, August 17, 2011 9:58 PM
RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Sasha, I completely agree with your recommendations: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Wednesday, August 17, 2011 9:52 PM To: Luca Martini Cc: m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3- gal-in-pw Luca and all, I have not found the statement you've proposed in draft-ietf-pwe3-fat- pw-06. Instead, it contans the following text in Section 8.5 Applicability to MPLS-TP: quote The flow aware transport of a PW reorders packets, therefore MUST NOT be deployed in a network conforming to the MPLS-TP unless these integrity requirements specified in the SLA can be satisfied. end quote (In the -07 version this text is repeated but followed by an incomplete statement In a immediately followed by the heading of Section 8.6. Since this addition is difficult to parse, I will ignore it for the moment.) IMHO and FWIW this means that prohibition on using flow aware PW in MPLS-TP environments is conditional on meeting specific SLA requirements for the service. So I think that the use case I've presented still holds. Please note also that, regardless of the restriction in draft-ietf- pwe3-fat-pw, be it conditional or absolute, usage of flow labels in an MPLS-TP domain would be perfectly safe if ECMP (i.e., hashing of the label stack and taking one of multiple NHLFEs for the given incoming label in the ILM) were not used in this domain, e.g., by associating exactly one ILM entry with each incoming label in the ILM. And since MPLS-TP is supposed to carry not just PW clients but also IP ones, I would expect that this would be the case in any MPLS-TP deployment. I also think that releasing one restriction (on using GAL in PWs) at the expense of making another, conditional one (on usage of flow labels in MPLS-TP environments) absolute is not the most appropriate method for resolving technical issues. IMHO and FWIW better way to resolve the problem would be by: - releasing the bottom-of-stack requirement on GAL - making use of the statement in RFC 5586 that if GAL is encountered in a packet then G-ACh header MUST be present immediately after the bottom of the label stack (and not immediately after GAL) - specifying that ECMP on labeled packets MUST ignore reserved labels. I think that these considerations have been presented already in the discussion on draft-nadeau-pwe-vccv-2. Of course it would be even better if we could agree on transition to universal usage of the CW and VCCV Type 1 in PWs. But this is a different story. Regards, Sasha From: Luca Martini [lmart...@cisco.com] Sent: Wednesday, August 17, 2011 9:58 PM To: Alexander Vainshtein Cc: Pablo Frank; m...@ietf.org; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen Subject: Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw The solution is quite simple: Flow Labels MUST not be used in an MPLS-TP environment. Luca On 08/16/11 21:46, Alexander Vainshtein wrote: Pablo, Sorry, but I think you're wrong. Only T-PE can insert the flow label (because only T=PE can be flow-aware). S-PE simply performs swap on PW label. Regards, Sasha - --- *From:* Pablo Frank [pablois...@gmail.com] *Sent:* Wednesday, August 17, 2011 12:17 AM *To:* Alexander Vainshtein *Cc:* ietf@ietf.org; m...@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen *Subject:* Re: [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal- in-pw I think it's okay because as the PW crosses the ECMP-enabled IP/MPLS domain in the middle segment, you're no longer in an MPLS-TP environment and so the GAL is not required to be BOS. During that middle segment, the PW flow label would be placed below the GAL and above the GACh. It gets removed when it hits the S-PE that switches you back into the MPLS-TP environment. In other words, whether you're in an MPLS-TP environment is determined segment by segment in a MS- PW. Pablo On Tue, Aug 16, 2011 at 1:02 PM, Alexander Vainshtein alexander.vainsht...@ecitele.com mailto:alexander.vainsht...@ecitele.com wrote: Hi all, After having sent out my comments I've noticed that the specific example to
RE: RE: [mpls] R: RE: R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Propose
Italo, Comments inline. Thanks, John Sent from my iPhone -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, July 13, 2011 2:04 PM To: John E Drake; david.i.al...@ericsson.com; rco...@ptinovacao.pt; i...@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: R: RE: [mpls] R: RE: R: Re: Last Call: draft-ietf-mpls-tp-cc- cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard The JWT report is aligned with my statement. JD: As SG15 management is fond of pointing out, when it suits them, the JWT operated on a very compressed time scale and didn't fully explore all of the technical issues The decision at IETF75 has been taken by the MPLS WG after the JWT and has never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he later removed his name because the other editors of the OAM Analysis draft were not considering his input to the document). JD: I'm not sure what your point is The BFD-based solution accepted by IETF75 for pro-active CC/CV/RDI was completely different (and technically much superior) than the one described by this draft. JD: Obviously we disagree Accepting a solution that meets the requirements does not mean signing a blank cheque that whichever changes is done is acceptable regarless whether it meets or not the requirements. JD: The requirements as documented in RFCs 5654, 5860, and 5951, or the requirements that seem to change based upon the phases of the moon? Messaggio originale Da: jdr...@juniper.net Data: 13-lug-2011 22.46 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, david.i. al...@ericsson.comdavid.i.al...@ericsson.com, rco...@ptinovacao.pt rco...@ptinovacao.pt, i...@ietf.orgi...@ietf.org, IETF- Announceietf- annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: RE: R: Re:LastCall: lt;draft-ietf-mpls-tp- cc-cv-rdi-05. txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defectindication for MPLSTransport Profile) to Proposed Standard Italo, The design team report (http://www.ietf.org/proceedings/75/slides/mpls- 17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU- T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 13, 2011 1:27 PM To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; i...@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: [mpls] R: RE: R: Re: Last Call: draft-ietf-mpls-tp-cc-cv- rdi- 05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard However this is a consequence of adapting an existing technology to a new application. I do not see any way around that. And the entire joint project was based on the premise of engineering re-use not greenfield design. That is what it said on the tin up front, and IMO why when the IETF started down
RE: [mpls] R: RE: R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed St
Italo, The design team report (http://www.ietf.org/proceedings/75/slides/mpls-17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU-T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 13, 2011 1:27 PM To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: [mpls] R: RE: R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi- 05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard However this is a consequence of adapting an existing technology to a new application. I do not see any way around that. And the entire joint project was based on the premise of engineering re-use not greenfield design. That is what it said on the tin up front, and IMO why when the IETF started down this path packet transport transitioned from being a minority sport to mainstream, so it is a bit late to cry foul This is not what the IETF has committed to deliver to ITU-T and in fact slide 44 postpones to the OAM design phase decide whether LSP-Ping or BFD can or should be tweaked or not and slide 46 reckons many options including non IP BFD is an option encapsulation of Y.1731 PDU It seems to me after having read the draft and followed this very long thread that tweaking BFD is not the right approach to meet ITU-T requirements so it would be worth evaluating the other alternative considered viable by the JWT which is encapulating Y.1731 PDUs. Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 20.24 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, rco...@ptinovacao.ptrco...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF-Announceietf-annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi- 05.txtgt; (ProactiveConnectivityVerification, Continuity Check and Remote Defect indicationfor MPLSTransport Profile) to Proposed Standard Hi Erminio: snipped Several service providers regarded this draft as not meeting their transport networks' needs. E This is a true statement: the solution in this draft is useless for many MPLS- TP deployments. The two statements do not necessarily follow. What we established during discussions at the SG15 plenary in February was that the issue some service providers had was that the IETF BFD solution exceeded their requirements in that there was additional functionality they did not see a need for, and that they considered any additional functionality parasitic. However this is a consequence of adapting an existing technology to a new application. I do not see any way around that. And the entire joint project was based on the premise of engineering re-use not greenfield design. That is what it said on the tin up front, and IMO why when the IETF started down this path packet transport transitioned from being a minority sport to mainstream, so it is a bit late to cry foul My 2 cents Dave
RE: RE: [mpls] R: RE: R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Propose
Italo, Comments inline. Thanks, John Sent from my iPhone -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, July 13, 2011 2:04 PM To: John E Drake; david.i.al...@ericsson.com; rco...@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: R: RE: [mpls] R: RE: R: Re: Last Call: draft-ietf-mpls-tp-cc- cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard The JWT report is aligned with my statement. JD: As SG15 management is fond of pointing out, when it suits them, the JWT operated on a very compressed time scale and didn't fully explore all of the technical issues The decision at IETF75 has been taken by the MPLS WG after the JWT and has never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he later removed his name because the other editors of the OAM Analysis draft were not considering his input to the document). JD: I'm not sure what your point is The BFD-based solution accepted by IETF75 for pro-active CC/CV/RDI was completely different (and technically much superior) than the one described by this draft. JD: Obviously we disagree Accepting a solution that meets the requirements does not mean signing a blank cheque that whichever changes is done is acceptable regarless whether it meets or not the requirements. JD: The requirements as documented in RFCs 5654, 5860, and 5951, or the requirements that seem to change based upon the phases of the moon? Messaggio originale Da: jdr...@juniper.net Data: 13-lug-2011 22.46 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, david.i. al...@ericsson.comdavid.i.al...@ericsson.com, rco...@ptinovacao.pt rco...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF- Announceietf- annou...@ietf.org Cc: m...@ietf.orgm...@ietf.org Ogg: RE: [mpls] R: RE: R: Re:LastCall: lt;draft-ietf-mpls-tp- cc-cv-rdi-05. txtgt; (Proactive ConnectivityVerification, Continuity Check and Remote Defectindication for MPLSTransport Profile) to Proposed Standard Italo, The design team report (http://www.ietf.org/proceedings/75/slides/mpls- 17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU- T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of erminio.ottone...@libero.it Sent: Wednesday, July 13, 2011 1:27 PM To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; ietf@ietf.org; IETF-Announce Cc: m...@ietf.org Subject: [mpls] R: RE: R: Re: Last Call: draft-ietf-mpls-tp-cc-cv- rdi- 05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard However this is a consequence of adapting an existing technology to a new application. I do not see any way around that. And the entire joint project was based on the premise of engineering re-use not greenfield design. That is what it said on the tin up front, and IMO why when the IETF started down
RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
Neil, I have a question for clarification. Have you actually read draft-ietf-mpls-tp-cc-cv-rdi-05.txt? I know you don't like doing this but generally it is considered good form to read something before commenting on it. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of neil.2.harri...@bt.com Sent: Friday, July 08, 2011 12:16 AM To: rco...@ptinovacao.pt; david.i.al...@ericsson.com; stbry...@cisco.com Cc: m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliablewe do not want to consciously build in weaknesses, esp unnecessary ones this also implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). - all packet layer networks should not have an AIS OAM messagevery obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps modewho may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. - creating preconfigured TCM sublayers is just asking for trouble IMO. It is far smarter to simply create a single end-end OAM CV (and when required PM) flow and tap this off at intermediate nodes on the *rare* occasions one wants to do. regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of Rui Costa Sent: 08 July 2011 01:15 To: David Allan I; Stewart Bryant Cc: ietf@ietf.org; IETF-Announce; m...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard David, Reading something, keeping it on record, without effect in the draft and ignoring comments have IMHO similar outcomes. As author of the draft you are free to do it. These standards have a great impact in our work, so i'm also free to write what i did. Stewart, My technical concerns regarding this draft were expressed... ...in the (ITU-T - IETF, Feb/2011) liaison regarding it (LS281, i believe); ...in operators' meetings' that took place during ITU-T's Feb/2011 plenary meeting; ...in a comparison session that took place during that same ITU-T meeting. Some: CC/CV I don't understand the need for 2 types of packets: a single type allows CC; mismatching identifiers in the same CC packets allow CV. Besides adding complexity, we whether always activate both or potentiate undetected mismerges. (BTW: can't understand how we propose one ACH codepoint to CC, another for CV, [counting other drafts, another for frame loss ...] but don't consider assigning 1 single ACH protocol identifier codepoint as requested by ITU-T) Uni P2P / P2MP I can't see how BFD will support unidir and hence P2MP other than... ...eliminating the session state variable (down, init, up), aiming just the state variables we really need, bringing us to something similar to 1731, eventually with other bits on the wire or... ...using IP to create the reverse way, which we cannot assume per requirements; Will we create a complete different tool for that? (BFD's B=bidirectional) Provisioning list This is an MPLS profile/subset (and i heard) achievable through a particular configuration. So, i expect each
RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
Neil, AIS and CC are ITU requirements but I personally agree with you regarding their utility. TCM is an ITU concept that doesn't really apply in an MPLS context because of the way the label stack works, and as I have told you before, the tap-off function you mention is sensible but it is strictly an implementation issue - no protocol work is required. Thanks, John Sent from my iPhone -Original Message- From: neil.2.harri...@bt.com [mailto:neil.2.harri...@bt.com] Sent: Friday, July 08, 2011 6:37 AM To: John E Drake; rco...@ptinovacao.pt; david.i.al...@ericsson.com; stbry...@cisco.com Cc: m...@ietf.org; ietf@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Not recently John. But my comments are general and not specific to this draft. But it seems you are implying that the draft recognises my points. If so I will look forward to reading it later today when I get chance and seeing AIS deprecated, TCM deprecated, CC functions deprecated, ability to tap off end-end CV/PM flows at intermediate nodes. regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 180 -Original Message- From: John E Drake [mailto:jdr...@juniper.net] Sent: 08 July 2011 14:26 To: Harrison,N,Neil,DKQ7 R; rco...@ptinovacao.pt; david.i.al...@ericsson.com; stbry...@cisco.com Cc: m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Neil, I have a question for clarification. Have you actually read draft- ietf-mpls-tp-cc-cv-rdi-05.txt? I know you don't like doing this but generally it is considered good form to read something before commenting on it. Thanks, John Sent from my iPhone -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of neil.2.harri...@bt.com Sent: Friday, July 08, 2011 12:16 AM To: rco...@ptinovacao.pt; david.i.al...@ericsson.com; stbry...@cisco.com Cc: m...@ietf.org; ietf@ietf.org; ietf-annou...@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-cc-cv-rdi- 05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Got to say I agree with Rui on much of what he says here. And I absolutely resonate with his point on the need for simplicity. The reason OAM needs to be as simple as possible is because it must be super reliablewe do not want to consciously build in weaknesses, esp unnecessary ones this also implies minimal config. We could all do better on this. For example: - Rui is dead right a CC function is fairly useless, we only need a CV function...the ATM OAM in I.610 suffers from this problem (and few others like AIS and the assumed use of request/response MLT to diagnose leaking/mismerging traffic...request/response OAM won't work with unidirectional defects). - all packet layer networks should not have an AIS OAM messagevery obvious for the cl-ps mode of course. The co-ps mode is also not like the co-cs mode. One has to consciously manufacture AIS messages and target them to specific clients in the co-ps modewho may have taken action in their own layer network and 'moved elsewhere' anyway, ie a total waste of time now. AIS is actually unnecessary wrt providing information anyway, it simply represents an in-built weakness of just something else to go wrong which itself will create problems. - creating preconfigured TCM sublayers is just asking for trouble IMO. It is far smarter to simply create a single end-end OAM CV (and when required PM) flow and tap this off at intermediate nodes on the *rare* occasions one wants to do. regards, Neil This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email
RE: Has anyone found a hotel for Quebec City that isn't exorbitant?
But that was then and now is now 8-. One could simply say suck it up. Sent from my iPhone -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Henk Uijterwaal Sent: Sunday, June 19, 2011 6:55 PM To: ietf@ietf.org Subject: Re: Has anyone found a hotel for Quebec City that isn't exorbitant? On 19/06/2011 08:01, Glen Zorn wrote: On 6/18/2011 9:52 PM, Keith Moore wrote: Frankly, I'm appalled at the prices and think it's highly inappropriate for IETF to be meeting in venues where the conference hotels are so expensive. May I point out that there has been a survey on the topic and the community expressed a clear preference for Quebec over other Canadian cities, knowing that travel would be longer and the number of cheap alternative hotels smaller. Henk -- --- --- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 --- --- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: My comments to the press about OAM for MPLS
Hi, I think we should be sad, though, that Huub's feelings were hurt when the team was disbanded. Here is the liaison to the ITU describing the disbanding of the design team: https://datatracker.ietf.org/liaison/593/. Interestingly, I can't find a reply from the ITU. This implies they didn't consider it important at the time. The design team report (http://www.ietf.org/proceedings/75/slides/mpls-17/mpls-17_files/frame.htm), with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG has followed to this day. I think the report is compelling evidence that the claim that a packet transport network is an MPLS application that intrinsically requires a different OAM solution is simply a lame ex post facto attempt to justify the ITU's abrogation of the agreement with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15): The ITU-T accepts these recommendations and states that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in RFC 4929 (Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures). Experts from the ITU-T will assist the IETF in the development of RFCs that describe the transport extensions by providing input to and review of the drafts as they are progressed via the IETF standards process.. The ITU-T will develop new or revised Recommendations that will allow IETF MPLS-TP to be integrated into the transport network including integration with the existing equipment, and operations infrastructure. These Recommendations will make normative references to the base IETF MPLS-TP technology and will be developed with input from and review by experts from the IETF to ensure consistency with MPLS-TP... The ITU-T has accepted the proposals from the JWT and we look forward to continuing the cooperative development of IETF MPLS to address the needs of the transport network. We also believe that this resolution will fulfil the mutual goal of improve the functionality of the internet and transport networks and guaranteeing complete interoperability and architectural soundness. Thanks, John Sent from my iPhone -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, March 03, 2011 12:05 PM To: Russ Housley Cc: IETF Subject: Re: My comments to the press about OAM for MPLS On 2011-03-04 06:51, Russ Housley wrote: Nurit: Not to mention including the canard that the IETF unilaterally disbanded its group assigned to work with ITU in 2009. Others with more detailed knowledge can explain exactly why this is, er, a lie. Here are some facts: === I was member of the MEAD team. A meeting of the MEAD team was scheduled to meet in Munich 12-14 October 2009. It was scheduled right after an ITU-T SG15 plenary meeting (September 28 - October 9) because MEAD team members attended that meeting too. On Friday October 2nd an agenda was distributed for the MEAD team for the meeting in Munich on the MEAD team list m...@ietf.org. On Monday October 5th an email was sent to m...@ietf.org announcing the disbanding of the MEAD team, and that the meeting in Munich should not be considered a MEAD team meeting. The decision to disband the MEAD team was liaised to the ITU-T on the same day (October 5). Do I need to say more. It does not sound like the shutdown of the MEAD team was smooth. However, the closure of a design team when their output is being handled by a working group is quite normal. That's the point. A design team is always a short term mechanism and once it reports back to the WG, it closes down. Not having been personally involved, I can't judge whether the process was clear to those involved, especially people with more experience in ITU-T than in the IETF. Just so we are all talking about the same thing, here is the official description from BCP 25 (RFC 2418): 6.5. Design teams It is often useful, and perhaps inevitable, for a sub-group of a working group to develop a proposal to solve a particular problem. Such a sub-group is called a design team. In order for a design team to remain small and agile, it is acceptable to have closed membership and private meetings. Design teams may range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair or AD appoints to attack a controversial problem. The output of a design team is always subject to approval, rejection or modification by the WG as a whole. In other words, what counts in the IETF process is the WG consensus, not the design team consensus. There are cases where the WG refuses or significantly changes the design team proposal; RFC 3246 and RFC 3248 make a good example. Brian
RE: what is the problem ter
An I-D usually needs to get WG consensus before it becomes a WG draft. Getting consensus from the wider community at this point, as you suggest, seems very reasonable. In my experience, once a document is issued as an RFC, it is considered to be a standard. The steps beyond that are largely irrelevant. Sent from my iPhone -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Friday, October 29, 2010 5:14 AM To: t.petch Cc: ietf@ietf.org Subject: what is the problem ter On Oct 29, 2010, at 4:54 AM, t.petch wrote: By contrast, the delays in producing an RFC seem to revolve around WG process, where Last Call causes people to come out of the woodwork with delaying suggestions, something a good chair or AD would stamp on, and IESG process, where certain hot buttons - eg security, flow control - produce some ludicrous DISCUSS' which delay the process for months. Tom Petch What I get from this is that the entire community needs to be involved in review and input of future RFCs much earlier in the process than Last Call. In my experience, the problem is generally not that the people coming out of the woodwork are making irrelevant suggestions, because IESG is fairly good at ignoring these. The problem seems to be that by the time a document as reached Last Call, the working group is past the point where it can meaningfully consider input from outside for anything but the most trivial changes - and the problems identified in Last Call are often much more fundamental than that. Often in my experience, outside reviewers and IESG members have been compelled to try to suggest minor wording changes to address what they saw as fundamental problems of architecture or scope in the proposed protocol. And yet, there are far too many Internet-Drafts published for the community to notice and consistently provide early review of every proposal, and far too many WGs even in a particular subject area to permit most community members to keep track of those documents and WGs with which they might be concerned. I'm not sure exactly where this leads, but I'm sort of thinking it might be nice if there were a First Call for community review much earlier in a document's life cycle. The I-D associated with a First Call should outline the solution that is being proposed, and all of the major considerations (e.g. security) should be dealt with - though perhaps not specified in detail. There wouldn't be any expectation that the document should be polished, that every aspect of the protocol being proposed should be nailed down, every option defined, every reference included or current, and so forth. The First Call I-D would not be published as an RFC, unless perhaps the WG died prematurely and there were a desire to publish it as Informational. It's just an I-D for which the WG requests wide community review. The WG would be expected to take First Call comments seriously and to report to the responsible AD how it was considering First Call comments into account in the development of its protocol. The tradeoff is that WGs would not be expected to deal with major structural/scope challenges at Last Call - provided, of course that they hadn't changed the structure/scope drastically from First Call. Obviously this is not even half-baked yet. Biggest problem I see is that the community would initially have no idea what level of detail should be specified by First Call. Some well-written (but incomplete!) examples, perhaps of imagined First Calls for well-established protocols, or early Internet-Drafts for protocols that were eventually standardized, might help. There are lots of other potential problems also. But in general I think the idea of getting earlier community feedback is a sound one. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Nomcom 2010-2011: READ THIS: Important Information on Open Disclosure
Tom, Thanks, this is very helpful. As I read RFC 5680, it does not change in any way the handling of confidential information (e.g., feedback on candidates, or its deliberations) specified in RFC 3777. Is that correct? Thanks, John Sent from my iPhone -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Thomas Walsh Sent: Wednesday, September 22, 2010 1:02 PM To: Ross Callon; dcroc...@bbiw.net; IETF discussion list; NomCom Chair Subject: RE: Nomcom 2010-2011: READ THIS: Important Information on Open Disclosure All the points being raised are very worthy of discussion and I suggest these be considered and clarified in a future update to RFC 5680 (should it be needed). Until there is such an update, NomCom must work with RFC 5680 as written. Open Disclosure and Feedback are closely tied per RFC 5680: --- Note that Section 5, Disclosing a Nominee List, of RFC 5680 specifically ties disclosing a nominee list as part of the NomCom's request for feedback from the community. The disclosure by this NomCom is to support the feedback process. There is no language in RFC 5680 for the list to be disclosed for any other purpose. Maybe that is a point to be addressed in the future. Is Disclosure Mandated by RFC 5680: -- No, it is not. RFC 5680 does not require any NomCom to disclose the list at all nor to disclose the entire list for that matter. Since this is the first time the open disclosure has been instituted, NomCom is taking a careful course. In the past, such information was available only to a subset of the community. Now, for this NomCom, it is available to anyone in the community who wants it and it is easy to obtain. How to disclose has not been specified: --- How the Open Disclosure is implemented is not specified in RFC 5680. If the community wants to specify this in detail for future NomCom's that can certainly be done. Summary: The purpose of Open Disclosure is to allow feedback from the entire community rather than a highly restricted subset. No other purpose has been specified. For NomCom to do more than what RFC 5680 specifies would be to over step its bounds. Tom Walsh Chair, NomCom 2010-2011 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ross Callon Sent: Wednesday, September 22, 2010 12:28 PM To: dcroc...@bbiw.net Cc: IETF discussion list; NomCom Chair Subject: RE: Nomcom 2010-2011: READ THIS: Important Information on Open Disclosure --On Wednesday, September 22, 2010 08:53 -0700 Dave CROCKER d...@dcrocker.net wrote: ...On the other hand, the practical reality is that getting an IETF login is easy enough to make this issue pretty minor, IMO. I have two thoughts on this: One the one hand, I agree with the part of Dave Crocker's email that getting an IETF login is easy enough that the approach that the current nomcom is taking seems to be workable. Also, I don't think that we want press articles about who is running for IETF leadership positions, who was rejected and who was accepted, and so on. Thus the fact that the current approach makes you agree to keep the names confidential would appear to be a very strong statement to the press not to publish the contents of the list. Ross ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Tourist or business visa from US?
You, or a visa company on your behalf, will be asking the Chinese consulate for a visa and as part of the application there will be an explanation of your planned activities in China. The consulate will decide whether the type of visa requested is consistent with your planned activities and if so, it will grant you the visa. Otherwise, the consulate will reject the application and tell you to re-apply for a different type of visa. Once you have the visa, you are done. I.e., Customs is not going to second-guess the validity of a visa issued by the Chinese consulate. Issuing visas is the consulate's responsibility. Sent from my iPhone -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Cullen Jennings Sent: Thursday, August 26, 2010 1:50 PM To: Mary Barnes Cc: IETF Discussion Subject: Re: Tourist or business visa from US? Wow, I find this whole email thread shocking. Given the text explanation you get of F and L visa from the embassy web site, which Mary quoted below, I have a very hard time seeing how anyone comes to the conclusion that L (tourist) visa is the right visa for an IETF meeting. I believe the the explanations that you are likely to get away with it, but I have a very hard time believing it is not breaking the law. I'd be fascinated to hear the reasoning of people who think it is legal. On Aug 24, 2010, at 9:21 AM, Mary Barnes wrote: The note posted suggested that if you were planning to sightsee a day or more before or after the meeting that a tourist visa might be sufficient. However, I prefer to err on the side of caution in this situation since it clearly states on the chinese visa website: Business Visa (F Visa) is issued to an alien who is invited to China for a visit, an investigation, a lecture, to do business, scientific- technological and culture exchanges, short-term advanced studies or internship for a period of no more than six months. versus Tourist Visa (L Visa) is issued to an alien who comes to China for sightseeing or visiting family members or friends or for other personal affairs. Personally, I'd rather not risk any problems in this area. Since, my company is sponsoring to attend the meeting, I don't consider that I'm going to China for personal affairs. In my experience, you're typically asked why you're visiting a country and sometimes the questioner wants more details as to what you'll be doing. So, unless you have figured out a detailed sightseeing itinerary in advance, I would think it's possible you could easily answer that question unsatisfactorily. Just my opinion, Mary. On Tue, Aug 24, 2010 at 9:43 AM, Andrew G. Malis agma...@gmail.com wrote: Is there a consensus that a tourist visa is sufficient to attend the IETF from the US? Thanks, Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC
+1 Sent from my iPhone On May 5, 2010, at 3:42 PM, Varma, Eve L (Eve) eve.va...@alcatel-lucent.commailto:eve.va...@alcatel-lucent.com wrote: Dear editors, In reviewing draft-ietf-mpls-tp-survive-fwk, I noticed that in Section 4.7.4, Triggers for the Linear Protection Switching Action, the next to the last paragraph includes a reference to a solution that is work in progress. Specifically, see italicized text below – In order to achieve 50ms protection switching it is recommended to use in-band data-plane driven signaling protocol to coordinate the protection states. An in-band data-plane PSC (Protection State Coordination) protocol is defined in [MPLS-TP-Linear-Protection] for this purpose. This protocol is also used to detect mismatches between the configuration provisioned at the ends of the Protection Domain. Given draft-ietf-mpls-tp-linear-protection is a work in progress – and not a pre-existing protocol, I do not believe it is appropriate to reference it from within the framework document. Thus, I propose that the italicized sentences be deleted. With best regards, Eve -Original Message- From: mpls-boun...@ietf.orgmailto:mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, April 22, 2010 3:03 PM To: IETF-Announce Cc: mailto:m...@ietf.org m...@ietf.orgmailto:m...@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-survive-fwk (Multiprotocol Label Switching Transport Profile Survivability Framework) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Multiprotocol Label Switching Transport Profile Survivability Framework ' draft-ietf-mpls-tp-survive-fwk-05.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.orgmailto:ietf@ietf.org mailing lists by 2010-05-06. Exceptionally, comments may be sent to i...@ietf.orgmailto:i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18472rfc_flag=0 ___ mpls mailing list m...@ietf.orgmailto:m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.orgmailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
