Re: Gen-ART LC review of draft-ietf-mpls-tp-rosetta-stone-12
AB, ITU and ITU-T are both in http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt listed as one of the well-known acronyms we can use without expanding it; all the specific definition you need :) ! /Loa On 2013-10-13 17:39, Abdussalam Baryun wrote: The draft does not list ITU in abbreviation, there are many terminology not clear but more general definition. I prefer specific defining. Also many times refers to references to define without mentioning what was that definition, is that defined only in ITU and IETF cannot define its technology, or is it agreeing on a joint definition so IETF is just following ITU in some terms. AB On Sunday, October 13, 2013, Roni Even wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-tp-rosetta-stone-12 Reviewer: Roni Even Review Date:2013–10–12 IETF LC End Date: 2013-10–16 IESG Telechat date: __ __ Summary: This draft is ready for publication as an Informational RFC. __ __ __ __ Major issues: Minor issues: __ __ Nits/editorial comments: __ __ __ __ -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Last calling draft-resnick-on-consensus
. But that would be a different example. I don't understand your concern here. 5) Good WG chairs, and happily there are plenty of them, make their presumptions plain, as in asking for information about implementations at or around judging consensus. The views of someone who has independently produced rough code is then likely to outweigh those of a dozen people who have not, so three such expressing a view in one direction will prevail over several dozen who have not in the opposite direction. (This is all right as far as it goes, but I would like the views of users and operators to count for even more, since it is they who have the most to gain or lose; but sadly, their representation here is small and often not apparent). You quote Dave Clark's aphorism but then ignore half of it. Two things about this: 1. This document is about how we can come to consensus, not about the criteria around which we get that consensus (of which running code is one). And interesting document could be written about how we do (and sometimes don't) take running code into account, but it's not this document. 2. I take issue with one thing you do say above: The views of someone who has independently produced rough code is then likely to outweigh those of a dozen people who have not. I think this is actually wrong: It is not that the implementer's view is given more weight *because it came from the implementer*; that would be an ad hominem judgement. The implementer's view is given more weight when it contains a solid technical case based on implementation experience. If an implementer says, I've implemented this code and I can tell you that the way you are proposing won't interoperate, and someone with no implementation experience is able to say, I can point you to implementations X Y and Z that implemented it my way and do interoperate, the fact that it's an implementer should make no difference at all. It is the existence of the implementation and how well it works that's the trump card, not who talks about it. 6) The document is strangely silent about what the vast mass of the IETF who are not WG Chairs might do to help reach a consensus, such as express an opinion, clearly, technically; else, perhaps, keep quiet. I think the document is useful without this discussion. I certainly would not object to adding such a section in the future, but I don't think it's necessary in this version. Again, this is mostly aimed at discussions of how leaders can facilitate getting to consensus. 7) As has been said before when documents like this are up for discussion, the IETF is an organisation of engineers and, for the most part, we do it rather well. Managing and leading loose and diverse groups of people is more psychology or sociology than technology, at which we are mostly amateurs. We then go beyond our capabilities and get it wrong. As here. I'm not clear on how the discussions of how to manage and lead consensus discussion that are presented in the document you think gets it wrong. Quite a few folks have found it useful and productive. More specifics welcome. pr -- Pete Resnickhttp://www.qualcomm.__com/~presnick/ http://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 tel:%2B1%20%28858%29651-4478 -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 2013-10-09 20:35, Ted Lemon wrote: On Oct 9, 2013, at 1:30 AM, Melinda Shore melinda.sh...@gmail.com wrote: Rough consensus - An agreement by almost everyone that the proposed That's a lot like voting, I think. It's worse than voting, because it encourages people to invite their friends to sway the consensus. At least with voting you have the transparency of knowing who the electorate is. So if this were what rough consensus meant, rough consensus would most often be won by whoever has the most friends, which in practice is probably whoever works for the biggest company. So whatever rough consensus means, it can't mean only a few people disagree. OK - I don't know what is wrong, but either - I can't write; or - some leading members of our community can't or don't care to read Ted, what you are describing is is not a group, it is a group or a loosely collection of people subject to manipulation. There is no room for that type of manipulation if we shall be able to talk about consensus/rough consensus (at least we seem to agree on that). If we have wg-chairs, ADs or chairs that are not able to detect this kind of manipulation we are in bad shape. What I tried to talk about is the the state of mind the (un-manipulated) group needs to be in before someone can make a consensus call; again not a definition, just a way of thinking about it. With that I rest my case. /Loa -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
All, FWIW - my personal way of thinking about consensus vd. rough consensus, please note that it my personal view not a definition. Consensus - An agreement by everyone in a group that a proposed solution is the best of all of all possible solutions Rough consensus - An agreement by almost everyone that the proposed solution is good enough for everyone to live with. /Loa On 2013-10-09 11:23, Melinda Shore wrote: On 10/8/13 3:21 PM, Fred Baker (fred) wrote: To my small and somewhat naive mind, the difference between rough consensus on a topic and a vote on the same topic is something about winners and losers. In a purely political process, when a set of parties vote on something and the preponderance (by some definition of preponderance) say something, the views of the losing set of parties are deemed irrelevant. In IETF process, and hopefully in any technical process, there is understanding that the parties who disagree may have valid reasons to disagree, and a phase of negotiation. When we talk about rough consensus, I understand it to mean - and would like to believe that we all understand it this way - that we investigate the reasons for disagreement, perhaps discover that some of them are valid, and address those issues to the satisfaction of those who raised them. As a result, the ultimate solution, even though it may not be the specific solution we would all have designed or selected, is one that in fact addresses all known issues. While we may not all agree, we don't disagree. I've done a lot of work on consensus over the years and I think this is fundamentally correct, although I'd amend the last sentence to something along the lines of While we may not all agree, those who disagree can live with it. That is to say, it's not a binary question, and sometimes things we disagree with just aren't showstoppers. (I'd like to see people take that position more often - for some reason a lot of people seem to take disagreement as a reason to block a decision even when it doesn't matter that much). Melinda -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 2013-10-09 13:30, Melinda Shore wrote: On 10/8/13 9:20 PM, Loa Andersson wrote: FWIW - my personal way of thinking about consensus vs. rough consensus, please note that it my personal view not a definition. Consensus - An agreement by everyone in a group that a proposed solution is the best of all of all possible solutions Rough consensus - An agreement by almost everyone that the proposed solution is good enough for everyone to live with. That's a lot like voting, I think. Well - if you say so, but then we don't have even a rough consensus on what consensus and rough consensus means. Note I talked about what a group need to reach to be able to say that there is consensus or rough consensus. Not how it is measured, in IETF we trust the wg chairs to correctly judge if we have reached a rough consensus. /Loa Melinda -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12
that can be registered. So, for Section 6.2, to make it cleaner and more explicit, how about this change: Old: No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are copied from the assignments made for TLV Type 1. Assignments of sub-... New: No assignments of sub-TLVs in the range of 0-16383 and 32768-49161 are made directly for TLV Type 21, sub-TLVs in these ranges are copied from the assignments (including existing and future allocations) made for TLV Type 1. Assignments of sub-... 2. For the vendor or private use why a difference policy than the rest of the sub-TLV registry This document does not make any changes to the Vendor and Private use definition, range and policy as defined in RFC4379. In RFC4379, it's policy is defined different from other ranges. Nits/editorial comments: 1. In section 3.4 I assume that TC is traffic class. It will be good to expand and have reference. OK, will fix it when all last call comments received. Best regards, Mach -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12
Roni, Thanks for an insightful review, you have captured much of what we been struggling with when it comes to the IANA allocations. On 2013-08-28 15:06, Roni Even wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-return-path-specified-lsp-ping-12 Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: I am not clear on the sub-TLV in section 6.2 1. If a new sub-TLV is defined for TLV type 1 do they need also to be added to TLV type 21. Yes the document says Directly copied from TLV Type 1, MUST NOT be assigned the intention is that this applies to future sub-TLVs also. I guess it could be changed to Directly copied from TLV Type 1 (including future allocations for TLV Type 1, MUST NOT be assigned if that makes thing clearer. This should be clear, and if there is some relation I think it should be reflected in the IANA registry for TLV type 1 I guess that makes sense - but it has not been the what we've done earlier - I think we could add this where needed by directly communicate this to IANA. 2. For the vendor or private use why a difference policy than the rest of the sub-TLV registry We don't assign vendor private use at all, so by default it is different. I don't see that it could be different. /Loa Nits/editorial comments: 1. In section 3.4 I assume that “TC” is traffic class. It will be good to expand and have reference. -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)
All, If there is a serious drive to discontinue the weekly posting summary - I strongly object. I don't think its main benefit is be to stop excessive or of topic posting. I'm not saying that list managers and list owners should look at that aspect. At least for me it serves as a safety net where I can look if I missed anything and need to go back and look. /Loa On 2013-08-04 10:31, Roger Jørgensen wrote: On 3 Aug 2013 11:14, Ole Jacobsen (ole) o...@cisco.com mailto:o...@cisco.com wrote: It was never a distraction until AB started complaining about it. Been serving a useful purpose for many, many years. Procmail is your friend. +1 for that --- Roger --- Ole J. Jacobsen Editor Publisher http://cisco.com/ipj Sent from my iPhone On Aug 3, 2013, at 9:12, Heasley h...@shrubbery.net mailto:h...@shrubbery.net wrote: Am Aug 3, 2013 um 9:05 schrieb Abdussalam Baryun abdussalambar...@gmail.com mailto:abdussalambar...@gmail.com: On 8/3/13, Patrik Fältström p...@frobbit.se mailto:p...@frobbit.se wrote: On 3 aug 2013, at 08:46, Abdussalam Baryun abdussalambar...@gmail.com mailto:abdussalambar...@gmail.com wrote: I prefer if you post at end of Friday (as in the end of working days of 5 in each week). However, in my comment below I will follow the week as done in world calender, start from Sunday (mornings) and ends on Saturday (nights). The day a week starts, and what days are working days in a week, differs between cultures. Many have Sunday-Thursday as working days. Many have Monday as the first day of the week. I suggested to Thomas to submit report in end of Friday (read what i I suggest eliminating the report. As it doesn't measure content quality, one's contribution can't be measured by the email they produce. So, it is only a guage of the distraction they produce. The report itself is a distraction. -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Weekly posting summary for ietf@ietf.org
+1 (and that will be my only posting on this subject, I suggest that if you don't get Stewart's drift you stop sending mails to the list until you do) /Loa On 2013-06-21 15:00, Stewart Bryant wrote: AB Thomas started posting these weekly reports many years ago as a service to the community to remind us all that posting to ietf@ietf.org contributes to the information and work overload of the IETF community as a whole. The numbers are a reminder to think carefully about what you send to the list and to only send what you consider to be sufficiently important that the community as a whole needs to be aware of it. Most members of the IETF community try their best to minimize their so called Narten Number. Many regard these postings as a useful service, and I for one, thank him for doing it. - Stewart -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: When to adopt a WG I-D
On 2013-05-28 13:09, Romascanu, Dan (Dan) wrote: Hi, Good work. Here are a few thoughts after a first reading. - We seem not to have a definition of what a WG I-D is, although we know how to recognize a WG I-D because of the naming convention. So, if I am not mistaken the phrase Working Group drafts are documents that are subject to IETF Working Group revision control. in section 1.1 introduces such a definition. Is everybody happy with this? No not really - first it is not a definition - it is something that follow from that the document is a wg document. I guess the following is closer to a definition: A working group document is any document that the working group chairs says is a working group document. The revision control follows from that, but is nevertheless necessary. /Loa - I am lacking from the criteria in 2.2 the stability of the technical solution (as per WG consensus). In my mind this is in current practice the principal specific difference between individual submission I-Ds and WG I-Ds - the fact that the I-D makes a clear (it may be drafty but yet clear) statement about what the technical solution is. - I less like the following: * If not already in scope, is a simple modification to the charter feasible and warranted? Without being extremely strict on the process aspect, I believe that WGs should not work on items that are not chartered, and even less adopt WG I-Ds on non-chartered items. If they feel that something is missing from the charter they can ask the ADs for a charter update, or for adding milestones, we have today at hand light processes which can lead to fast incremental additions to charters, and if the addition is more than incremental than it should go through a proper rechartering process. - * What is the position of the working group chairs, concerning the draft? [[editor note: I am not sure this is relevant. Indeed is might be specifically not relevant. /a]] Not relevant IMO. Regards, Dan -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, May 28, 2013 12:33 PM To: ietf@ietf.org Subject: When to adopt a WG I-D Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: When to adopt a WG I-D
Adrian, I'm fine with this draft as long as it stays informational and is viewed as a commentary on how what we are doing in the border land between individual and formal working group documents, i.e. this is not an IETF process text. Names of ID file are a bit trickier than what I get from this draft It is true that a document with a file name as: draft-wgname-ietf-... uniquely is a working group document; you need the approval of the wg chair(s) to have a draft with that file name posted. However, a draft with the file name: draft-individual-ietf... may or may not be wg document, and it is actually so when the the working group chairs states on the wg mailing list that it is. Admittedly this is often followed by a request to re-post it with the common format of file names for wg documents, but it is not the posting with the wg name format that makes it a wg document, it is the announcement from wg chairs. It is nowhere required to change the file name just because the document has become a working group document. Stupid not to do it, but not required. For example the appsawg does have two parked *wg documents* that does not follow the naming convention above. Now in section 5.1. you talk about a special case documents supported by a working, but that remains an individual draft but progress according to the wg processes. I think that what is now RFC 3468 was such a case; even though we at that did not talk about in those terms. I think it would be clearer if you in section 5.1. just said that there might be individual documents that is supported by a working group, and that follows the naming conventions for individual documents. /Loa On 2013-05-28 11:32, Adrian Farrel wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
On 2013-05-16 14:38, Abdussalam Baryun wrote: Discussions should have a time limit (can be one week), I totally disagree, DISCUSSES are our friends, they need to be discussed until we have rough consensus; it seems to be a manifestly bad idea to draw a deadline after seven days, if someone come up with a satisfactory solution on the eighth. 99,9% of the DISCUSSES improve our documents or the understanding of them. /Loa like we have in meetings (2hours), if there is time we can know when things are needed to respond to, I usually ignore when there is no milestones or planing-time. Does IESG have milestones for documents processing/discussions? -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
Bob, thinking about this and assuming that the FTL Communication are deployed in a not too far distant future, wouldn't we have started to receive packets that was sent in the future already now? /Loa On 2013-04-02 18:19, Bob Hinden wrote: AB, On Apr 1, 2013, at 5:45 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: RFC6921It is well known that as we approach the speed of light, time slows down. AB I know that time slows for something when it is in speed of light, but communication is not something moving. If the packet is in speed of light we may reduce the comm-delay but never less than zero. The communication times don't change if at least one communicator is not moving in light speed. My comment is that I think this RFC is not logical, and I don't understand its recommendations. There is no way that a packet can be received before send, packet-time never changes communicators-time while the positions of both Tx and Rx are semi-fixed (change is relative to communicators' times not their signal). I think the communication-times may change when the communicators are at/above speed of light not the signal/packet. Is my physics correct? Only time will tell. Bob -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
On 2013-04-05 11:11, Brian E Carpenter wrote: On 05/04/2013 10:03, Dave Cridland wrote: On 5 Apr 2013 09:47, Loa Andersson l...@pi.nu wrote: Bob, thinking about this and assuming that the FTL Communication are deployed in a not too far distant future, wouldn't we have started to receive packets that was sent in the future already now? Indeed, and this tells us that publication of this was important, since we'll need to be in a position to handle the issues that will occur much sooner than deployment, and for that matter development of the technology. If the announcement of the RFC had arrived on March 31st, that would have demonstrated running code. Are you sure that this was not published April 1, 2014 or even 2015?? /Loa -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: On the tradition of I-D Acknowledgements sections
AB, I've been following this first with increasing amusement, ... not! A search on Baryun for IDs on the RFC Editors web page gives the following result: o Based on your search of [Baryun] in the All Fields field zero matches were made. Time to terminate this discussion? /Loa On 2013-03-25 07:32, Abdussalam Baryun wrote: I already did write many I-Ds and may write one to fix this in IETF as many do fix things by I-Ds. This discussion and others are just start to see opinions, AB On 3/25/13, l.w...@surrey.ac.uk l.w...@surrey.ac.uk wrote: Abusallam, if you want namecheck credit on an internet draft, may I suggest simply writing an internet draft yourself? (I would also recommend leaving writing drafts until after a PhD is complete; for the PhD, it's academic papers that matter.) Lloyd Wood http://sat-net.com/L.Wood/ _ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 25 March 2013 06:02 To: melinda.shore Cc: ietf Subject: Re: On the tradition of I-D Acknowledgements sections Hi Melinda I like what we have so far, but are those connected processes/information reflected into the produced document? Why ignoring names of volunteers? I suggest to fix this, AB + We have the mailing list archives, we've got the document shepherd writeups, we've got the IESG evaluation record, we've got the IESG writeups, we've got meeting minutes, we've got jabber session archives, we've got audio recordings of meetings, and we've got the document history. Melinda So when I read a RFC I may go through the document process and its draft versions, while going through the drafts related I see acknowledged names so I may find the input on the list for such name. In this way we have connections between inputs otherwise the IETF system has no connection between its important information. AB -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64
Re: Mentoring
All, This is the agenda for Sunday: 1000-1200 EDTIEPG Meeting - Caribbean 4 1100-1900 EDTIETF Registration - Caribbean Registration 1300-1450 EDTIEEE 802.1Q - Caribbean 5 1300-1450 EDTNewcomers' Orientation - Caribbean 4 1500-1650 EDTIAOC Overview Session - Caribbean 6 1500-1650 EDT Introduction to RAI Development in the IETF Tutorial - Caribbean 5 1500-1650 EDTWG Leadership - Caribbean 4 1600-1700 EDT Newcomers' Meet and Greet (open to Newcomers and WG chairs only) - Boca Patio 1700-1900 EDTWelcome Reception - Grand Sierra D That overlap does not seem serious. /Loa On 2013-03-14 13:30, Adrian Farrel wrote: Mary, I need to check but... [MB] What I find interesting is that there was 200+ newcomers, but I certainly didn't find that many at the meet and greet. I have to wonder whether this doesn't have to do with the overlap between Sunday tutorials and this event. I think that needs to be fixed. Very right that it would need to be fixed, but I thought that it was avoided explicitly and deliberately. Anyone got a copy of the agenda in front of them? Maybe we could do a little research on why newcomers don't show at this meeting. Are they tired? Shy? Unaware? Not perceiving the value? Adrian -- Loa Anderssonemail: l...@mail01.huawei.com Senior MPLS Expert l...@pi.nu Huawei Technologies (consult)phone: +46 739 81 21 64
Re: FW: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFCwith Running Code) to Experimental RFC
may be the real requirement. 5. The responsible AD for the WG concerned makes the decision as to whether changes are required as a result of review comments, and determines whether or not those have been completed. If significant change or extended discussion is required, or if changes are not complete within two weeks after the end of fast- track last call, then the draft is returned to the WG by the responsible AD and the document is withdrawn from the experiment. The two week figure is too stringent. The above is too prescriptive to be practical. For starters, how will the IESG telechat align with the ending of LC? Or what if an IESG member issues a defer (or will those be disallowed?). Section 4 has a bit too much detail and process in it. I'm sure it has both too much and too little actually. I.e., it probably misses some corner cases, and then what do you do given how prescriptive the rest of the section is? But overall, I see this document at best as a no-op. However, I fear that it can be used to short-circuit our review processes in a way that doesn't help the IETF and that won't really speed things up enough to justify the downsides. Thomas -- Loa Anderssonemail: l...@mail01.huawei.com MPLS Expert l...@pi.nu Huawei Technologies (consult)phone: +46 739 81 21 64
Re: [PWE3] Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06
defect reporting behavior. The draft is generally in good shape. I found a few minor nits. 1) The draft uses a lot of acronyms - while each acronym appears to be expanded on first use, an additional section near the start of the draft listing all of them would be helpful. NB Done. 2) There's a typo in the first paragraph of section 2: covers the following Ethernet OAM (Opertaions, Administration and Opertaions - Operations. NB Thanks. Done. 3) The following normative reference is incomplete - please add additional information that will enable a reader to locate the referenced document: [MEF16] Ethernet Local Management Interface, MEF16, January 2006. [MEF16] Ethernet Local Management Interface, Metro Ethernet Forum Technical Specification MEF16, January 2006. NB changed it to : 4) idnits2.12.13 did not like the pagination: == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 1) being 61 lines NB That will be fixed. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 tel:%2B1%20%28508%29%20293-7953 FAX: +1 (508) 293-7786 tel:%2B1%20%28508%29%20293-7786 david.bl...@emc.com mailto:david.bl...@emc.comMobile: +1 (978) 394-7754 tel:%2B1%20%28978%29%20394-7754 ___ pwe3 mailing list p...@ietf.org mailto:p...@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 ___ pwe3 mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13
Re: Running code, take 2
Folks, I agree that understanding the implementation status of a draft sometimes is essential, but not for all drafts and not always. Today wg chairs do this type of info collection at the shepherd write-up. Have anyone thought about how much work goes into compiling this type of information. There are vendors that by policy decided not to disclose implementation information, before the implementation is done and the document has become an RFC. Most of the time it is possible to to get some understanding, with a promise not to make the info public and only use it for a rather cryptic statement in the shepherd write-up - we know of existing or intended implementations of this draft. A second, rather new problem, is that for some drafts the IANA assignment is the singular most important part of the ID. We have heard vendors say We'll wait for the IANA assignment until we implement! /Loa On 2012-12-13 16:10, Adrian Farrel wrote: How about... Start with Yaron's proposal to include in the I-D. This is easy as a starting point. Duplicate documentation in wiki may be useful and provide a place to track text for inclusion in the next revision. When/if inclusion in the I-D gets messy, replace text in I-D with pointer to wiki. When/if experiment looks like a success, replace all above with data tracker tool and allow it to persist for RFCs. Adrian -Original Message- From: Marc Blanchet [mailto:marc.blanc...@viagenie.ca] Sent: 13 December 2012 15:05 To: Yaron Sheffer Cc: adr...@olddog.co.uk; ietf@ietf.org; 'Alessandro Vesely' Subject: Re: Running code, take 2 Le 2012-12-13 à 10:00, Yaron Sheffer a écrit : Hi Marc, I think it's critical that a person reading a draft (e.g. going to http://tools.ietf.org/html/draft-blanchet-iab-internetoverport443-01) will have a direct way to check out on the implementation status. This is trivial if it's a section in the document. It's simple if it's linked from the Tools page. Otherwise, e.g. if you put it on the wiki, only IETF insiders will be aware of it. sure. Let me restart: - I like Adrian proposal: instead of in RFC, put it online within our site - but you wrote: requires implementation effort. - I replied: well, phase 1 (of put it online within our site) can be done with almost zero implementation effort. phase 2 requires some work (I'd say not that big) for implementation/tools. Regards, Marc. Thanks, Yaron On 12/13/2012 04:55 PM, Marc Blanchet wrote: Le 2012-12-13 à 09:52, Yaron Sheffer a écrit : Hi Adrian, I would suggest to start with my proposal, because it requires zero implementation effort. disagree. phase 1: use IETF wiki. phase 2: develop an widget within data tracker. Marc. If this catches on, I see a lot of value in your proposal. Please also note that the implementation status section (according to my proposal) is not frozen when published as an RFC, rather it is deleted. RFCs are forever, and I think a point-in-time implementation status is not appropriate in an RFC. Thanks, Yaron On 12/13/2012 04:16 PM, Adrian Farrel wrote: I'm interested in this idea. However, I note that an implementation status section of a document is frozen in time when a document goes to RFC. I wonder whether we could leverage our tools and do something similar to IPR disclosures. That is, provide a semi-formal web page where implementation details could be recorded and updated. These would then be searchable and linked to from the tools page for the I-D / RFC. They could record the document version that has been implemented, and also allow space for other notes. Adrian (Just thinking aloud) -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alessandro Vesely Sent: 13 December 2012 13:58 To: ietf@ietf.org Subject: Re: Running code, take 2 On Wed 12/Dec/2012 20:31:04 +0100 Yaron Sheffer wrote: I have just published a draft that proposes an alternative to Stephen's fast track. My proposal simply allows authors to document, in a semi-standard way, whatever implementations exist for their protocol, as well as their interoperability. http://www.ietf.org/id/draft-sheffer-running-code-00.txt [...] I am looking forward to comments and discussion on this list. As an occasional I-D reader, I'd appreciate Implementation Status sections, including IPR info. I don't think anything forbids to add such sections, if the authors wish. I'd add a count of the number of I-Ds that actually have it among the experiment's success criteria. -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13
Re: Running code, take 2
Marc, inline please! On 2012-12-13 16:39, Marc Blanchet wrote: Le 2012-12-13 à 10:22, Loa Andersson a écrit : Folks, I agree that understanding the implementation status of a draft sometimes is essential, but not for all drafts and not always. Today wg chairs do this type of info collection at the shepherd write-up. Have anyone thought about how much work goes into compiling this type of information. There are vendors that by policy decided not to disclose implementation information, before the implementation is done and the document has become an RFC. Most of the time it is possible to to get some understanding, with a promise not to make the info public and only use it for a rather cryptic statement in the shepherd write-up - we know of existing or intended implementations of this draft. A second, rather new problem, is that for some drafts the IANA assignment is the singular most important part of the ID. We have heard vendors say We'll wait for the IANA assignment until we implement! right. but that does not preclude doing the proposal. What you are saying is that maybe the info (in draft, wiki, tracker) may not be complete since some may not disclose. But the available information would be valuable. Marc. that entirely depends on the policy of the 4-5 dominating vendors in the area that the draft is applicable for. I know of people writing drafts there their own companies say that they can disclose implementation information in public. Why would anyone else want to supply their information to that draft. I think the key word here is in public, a trustful relationship between working group chairs gives you enough information to progress the document through the IESG, I'm afraid that this will be much harder if we have an empty (or single company) Implementation Status section in the drafts. /Loa /Loa On 2012-12-13 16:10, Adrian Farrel wrote: How about... Start with Yaron's proposal to include in the I-D. This is easy as a starting point. Duplicate documentation in wiki may be useful and provide a place to track text for inclusion in the next revision. When/if inclusion in the I-D gets messy, replace text in I-D with pointer to wiki. When/if experiment looks like a success, replace all above with data tracker tool and allow it to persist for RFCs. Adrian -Original Message- From: Marc Blanchet [mailto:marc.blanc...@viagenie.ca] Sent: 13 December 2012 15:05 To: Yaron Sheffer Cc: adr...@olddog.co.uk; ietf@ietf.org; 'Alessandro Vesely' Subject: Re: Running code, take 2 Le 2012-12-13 à 10:00, Yaron Sheffer a écrit : Hi Marc, I think it's critical that a person reading a draft (e.g. going to http://tools.ietf.org/html/draft-blanchet-iab-internetoverport443-01) will have a direct way to check out on the implementation status. This is trivial if it's a section in the document. It's simple if it's linked from the Tools page. Otherwise, e.g. if you put it on the wiki, only IETF insiders will be aware of it. sure. Let me restart: - I like Adrian proposal: instead of in RFC, put it online within our site - but you wrote: requires implementation effort. - I replied: well, phase 1 (of put it online within our site) can be done with almost zero implementation effort. phase 2 requires some work (I'd say not that big) for implementation/tools. Regards, Marc. Thanks, Yaron On 12/13/2012 04:55 PM, Marc Blanchet wrote: Le 2012-12-13 à 09:52, Yaron Sheffer a écrit : Hi Adrian, I would suggest to start with my proposal, because it requires zero implementation effort. disagree. phase 1: use IETF wiki. phase 2: develop an widget within data tracker. Marc. If this catches on, I see a lot of value in your proposal. Please also note that the implementation status section (according to my proposal) is not frozen when published as an RFC, rather it is deleted. RFCs are forever, and I think a point-in-time implementation status is not appropriate in an RFC. Thanks, Yaron On 12/13/2012 04:16 PM, Adrian Farrel wrote: I'm interested in this idea. However, I note that an implementation status section of a document is frozen in time when a document goes to RFC. I wonder whether we could leverage our tools and do something similar to IPR disclosures. That is, provide a semi-formal web page where implementation details could be recorded and updated. These would then be searchable and linked to from the tools page for the I-D / RFC. They could record the document version that has been implemented, and also allow space for other notes. Adrian (Just thinking aloud) -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alessandro Vesely Sent: 13 December 2012 13:58 To: ietf@ietf.org Subject: Re: Running code, take 2 On Wed 12/Dec/2012 20:31:04 +0100 Yaron Sheffer wrote: I have just published a draft that proposes an alternative to Stephen's fast track. My proposal simply
comment on draft-crocker-id-adoption
Dave and Adrian, I looked at section 1.1 of What is a Working Group Draft? I find that the draft does not really answers that question. The draft demonstrates how to recognize a wg draft in the IETF repository and it also talks about the very common practice to keep the author/editor team unchanged when the document is adopted as a working group document. Though this strictly not necessary. It also says that working groups use working group documents to produce their official output. While all this is true I think it would be more accurate to say that Working Group documents are documents where an IETF Working Group exercise the revision control, i.e. other than editorial changes to a Working Group document need to have a rough consensus by the Working Group to be introduced. /Loa -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13
Re: request to make the tools version of the agenda the default
John, I took this request as request to change the default, given that the tool-version is what I use (mostly) that change would be beneficial, but I'd be reluctant to see the HTML-version go away immediately. /Loa On 2012-11-30 15:51, John C Klensin wrote: --On Thursday, 29 November, 2012 10:11 -0800 Wes Hardaker wjh...@hardakers.net wrote: So, the 'tools version' with all the wonderful spiffy links to helpful things (the materials, the etherpad, the ...) and the spiffy highlighting ability (Dark Red! I love dark red!) has been very stable and highly useful for quite a while now. But the default link on the web page still points to the less-useful HTML version (which has a link at the top to get to the tools version). FWIW, I agree that the tools version is better in every way that I can think of than the static HTML version. But for those of us who are still enough members of the dinosaur age to still sometimes read things on WiFi-free airplanes and trains and (shudder) still sometimes mark up paper, _please_ don't implement this change the way the change to the I-D announcements was done, i.e., by forcing a several-stage click-through process to get to whatever versions are not the preferred version of the year. john -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13
Re: Proposed IETF Meeting Calendar 2018 - 2022
Tom, the overlap with school holidays might be true from some perspective, but the two countries (Sweden and Philippines) I'm most familiar with show that if there is a goal to avoid that it is not doable. In Sweden there is school holidays from around June 10th and into August. In the Philippines the school starts around June 10th. /Loa On 2012-09-07 13:42, t.p. wrote: We seem to have adopted a policy of making the summer meeting overlap what is for me the start of school holidays, and a time to avoid travelling. I used to think of IETF54, IETF57 and IETF66 as the norm and anything else as an aberration, but now it seems the reverse is true. Incidentally, I notice that we are now staying well away from that other holiday season, sometimes known in the Western world as 'Easter', which seems prudent. Tom Petch - Original Message - From: IETF Administrative Director i...@ietf.org To: IETF Announcement List ietf-annou...@ietf.org Cc: i...@ietf.org; i...@iab.org; ietf@ietf.org; wgcha...@ietf.org; i...@ietf.org Sent: Thursday, September 06, 2012 8:15 PM Subject: Proposed IETF Meeting Calendar 2018 - 2022 All; Below are suggested Meeting dates for 2018 - 2022, IETF's 101 - 115. The IAOC is soliciting the community's feedback before adopting. Comments appreciated to ietf@ietf.org by 20 September 2012. Ray 2018 IETF 101 18-23 March 2018 IETF 102 22-27 July 2018 IETF 103 4 - 9 November 2018 2019 IETF 104 24 - 29 March 2019 IETF 105 21 - 26 July 2019 IETF 106 17 - 22 November 2019 2020 IETF 107 22 - 27 March 2020 IETF 108 26 - 31 July 2020 IETF 109 15 - 20 November 2020 2021 IETF 110 21 - 26 March 2021 IETF 111 25 - 30 July 2021 IETF 112 7 - 12 November 2021 2022 IETF 113 20 - 25 March 2022 IETF 114 24 - 29 July 2022 IETF 115 6 - 11 November 2022 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13
Re: Minutes SHOULD include participants number
AB, I think what Andy says is that percentage nothing to do with rough consensus. Rough consensus has everything to do with finding ways forward that the entire wg can live with. Sometimes people find themselves in the rough, we don't fully agree with what working group chairs says is the wg (rough) consensus. Toe be in the rough It is a critical skill that IETFers need to acquire. I can assure you that being a wg chair and in the rough, when you call wg consensus is not easy - but again it has nothing to do with percentage. /Loa On 2012-08-29 10:33, Andrew G. Malis wrote: Just on a practical matter, many of us WG chairs like to get the minutes uploaded as quickly as possible, before the blue sheet numbers are available. Like John, I fail to see the value of recording the number of people sitting in chairs, except to size the room for the next meeting. One of the most productive WGs I ever participated in usually had fewer than 10 people at a meeting, but every single one of those people contributed to the documents. Regarding consensus, that's a different matter altogether, and one you didn't mention in your original email. In most WGs (certainly in mine), consensus is not determined in the meeting, but on the list. In the minutes, we'll sometimes report on the sense of the room, but it's nothing more than that. Cheers, Andy On Wed, Aug 29, 2012 at 11:12 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi John, Thanks for your advise and comments. I prefered that consensus is documented to know its value/level as was it 60% or 70% or 80%...etc. How do Chairs in IETF decide on the agree/disagree/no-reply from WGs Note that 51% of the working group does not qualify as rough consensus and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached. I see that minutes just mention WG agreed to ..., but would suggest the value, so it does not become below 51%. Also, most participants need more time to decide on such request from Chairs because they use their variable-available-volunteering time to do reading/work within each 28 days. Regards AB --- On 8/28/12, John C Klensin john-i...@jck.com wrote: --On Tuesday, August 28, 2012 11:17 +0100 Abdussalam Baryun abdussalambar...@gmail.com wrote: Hi Reading through some IETF WGs minutes of meetings, is it possible that we follow a procedure in writting minutes. I think the following items are important that SHOULD be included: 1) name of the chair, minute taker, and jabber reader. 2) number of participant in the meeting room. 3) number of participants at jabber. It seems to me that the latter two would fall somewhere between useless and misleading. I don't have any idea how to count participants in the meeting room. The only numbers that are reasonably easy to capture are the number of people who signed the blue sheets, but that doesn't capture either non-signers or those who sign and then sit in the room and pay more attention to email or other topics than the meeting. If we used the number of people signed into Jabber for anything, we'd create a count that was extremely easy to pack as well as not distinguishing between people who were on Jabber but in the room, on Jabber but elsewhere at the IETF meeting (conflicts or couldn't be bothered to attend), remote and actively following the meeting, or others (and there are likely to be some others). I could see somewhat more value if actual names and organizational affiliations were listed, but the community has (for plausible reasons, IMO) decided to not do that. This is just a personal opinion/request, but I would really appreciate it if you (or others making procedural suggestions/requests like this) would carefully think through the implications of what they are asking for and how the information would be used before making the request. It would be even better if you then included an explanation of the value that you think would occur, and maybe the tradeoffs you see, with the request, not just is it possible that we follow a procedure That would have an advantage for you too because such suggestions are more likely to be taken seriously by more people in the IETF rather than, in the extreme case, going unread because you have developed a history of bad and/or unjustified ideas. regards, john -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13
Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
Scott, would you say that drafts aimed for experimental status are standards work. /Loa On 2012-07-30 18:33, Scott O Bradner wrote: 2804 does not say not to talk about such things - or that such documents should not be published as RFCs - 2804 says that the IETF will not do standards work in this area Scott On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote: Under the long-standing IETF policy defined in RFC 2804, I trust we will not be discussing this draft, or draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF. Regards Brian Carpenter On 30/07/2012 09:26, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Label-based Provider-Provisioned Lawful Intercept for L3 VPNs Author(s) : Shankar Raman Balaji Venkat Venkataswami Gaurav Raina Vasan Srini Bhargav Bhikkaji Filename: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt Pages : 12 Date: 2012-07-30 Abstract: In models of Single-AS and inter-provider Multi- Protocol Label Switching (MPLS) based Virtual Private Networks (VPNs) Lawful Intercept is a key requirement. For example, MPLS-based Layer 3 VPN models like VPLS and the like do not have any provider provisioned methods of lawful intercept that are comprehensive, quick and easy to provision from one single point. More particularly the auto- provisioning of lawful intercept for all sets of streams travelling between VPN sites and consequent re-direction of these streams to the appropriate government network has not been covered without multiple instances of having to configure the intercept at various points in the network both in the Single-AS case and the Inter-Provider VPN case. this paper, we propose a technique which uses a set of pre-defined labels called Lawful Intercept labels and a method for provisioning lawful intercept amongst the various PE devices using these labels both in the Single-AS and the inter-provider VPN cases. A single point of configuration is the key to this idea. The intercepted traffic is mirrored on a PE or a whole set of PEs or on all the PEs participating in the VPN. A technique called the Domino-effect provisioning of these Label-based Provider Provisioned Lawful Intercept mechanism is also outlined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis There's also a htmlized version available at: http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13
Re: [PWE3] FW: Last Call: draft-betts-itu-oam-ach-code-point-03.txt(Allocation of an Associated Channel Code Point for Use byITU-T Ethernet based OAM) to Informational RFC
Malcolm, good that we are making some progress! On the experimental code point -- I doesn't seem appropriate to call out the fact that some commercial products has been using an experimental code point in production setting! On the remain (key) disagreements - I will let other people comment for now. /Loa On 2012-03-21 21:33, malcolm.be...@zte.com.cn wrote: Loa, Thank you for your comments and suggestions, please see in line below. Regards, Malcolm ietf-boun...@ietf.org wrote on 12/03/2012 04:31:43 AM: Loa Andersson l...@pi.nu Sent by: ietf-boun...@ietf.org 12/03/2012 04:31 AM To ietf@ietf.org cc Subject Re: [PWE3] FW: Last Call: draft-betts-itu-oam-ach-code- point-03.txt(Allocation of an Associated Channel Code Point for Use byITU-T Ethernet based OAM) to Informational RFC All, I've been asked to clarify thee comments in this mail, I done so by proposing new text to draft-betts-. I hope this helps. Title = Comment: We want to assign a Associated Channel Type. The registry that it will be assigned from is Pseudowire Associated Channel Types; however RFC 5586, makes the Channel Types generic and I think the title should be changed as follows: OLD: Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM NEW: Allocation of an Generic Associated Channel Type for ITU-T MPLS-TP OAM Note: Neither MPLS-TP or OAM are in the RFC Editors list of wellknown acronyms, therfore the title probably should be: NEW: Allocation of an Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance and Administration. MB: No objection to this change Introduction - first paragraph == In the first paragraph of the introduction, there seems to be an oddity in the description of the role of the ietf-tp-oam-analysis document. Instead of: OLD tools defined by the IETF [I-D.ietf-mpls-tp-oam-analysis], that are intended to meet the OAM functional requirements defined in [RFC5860]. NEW: tools described by the IETF [I-D.ietf-mpls-tp-oam-analysis], which are used to meet the OAM functional requirements defined in [RFC5860]. MB: No objection to this change Intrduction - second paragraph == The next paragraph in describing G.8113.1, stumbles over the current vs anticipated future state of G.8113.1 and its relationship to its antecedents. I'm a bit un-certain about the correct terminology, but I think the following change would improve the document. OLD: The ITU-T has documented, in draft new Recommendation [G.8113.1], the use of Ethernet based OAM mechanisms, originally defined in [Y.1731], carried in the MPLS Generic Associated Channel (G-ACh). This approach requires the allocation of an ACH Type from the registry of ACH types maintained by IANA in order that the messages that will be described in [G.8113.1] can be identified by an implementation. NEW: The ITU-T has Draft Recommendation [G.8113.1] documented MPLS OAM which as of this writing is undergoing the ITU-T Traditional Approval Process (TAP). This Recommendation builds upon Ethernet OAM as documented in [Y.1731]. The messages in [G.8113.1] are defined to be carried in a new Associated Channel Type in the MPLS Generaic Associated Channel (G-Ach). In order to carry these messages in an interoperable fashion, an Associated Channel Type from the IANA maintained registry Pseudowire Associated Channel Types is to be used. MB: Since the draft will not be published as an RFC until after G.8113.1 is approved we can directly reference the approved Recommendation and I suggest that we modify paragraph to: ITU-T Recommendation [G.8113.1] documents MPLS OAM. This Recommendation builds upon Ethernet OAM as documented in [Y.1731]. The messages in [G.8113.1] are defined to be carried in a new Associated Channel Type in the MPLS Generaic Associated Channel (G-Ach). In order to carry these messages in an interoperable fashion, an Associated Channel Type from the IANA maintained registry Pseudowire Associated Channel Types is to be used. Note there are confusion around some of the Associated Channel acronyms that are refledted in this document. ACh is Associated Channel ACH is Associated Chamnnel Header G-ACh is Generic Associated Channel ACH Type is not used anywhere in IETF documents; we talk about Associated Channel Type or Generic Associated Channel Type (G-ACh Type). MB: Thank you, I will fix this. Introduction - third paragraph == In the third paragraph, there seems to be an unnecessary reference to experimental types. When asking for a code point for a standard, it is not helped to bring up experimental code space. Can we remove the text reading
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 based OAM) to Informational RFC
Maarten, please be aware of what u asking for - you won't have a an ACH codepoint to G.8113.1. First, what is requested is an Associated Channel Type and it will be assigned to the RFC resulting from draft-betts-. I will not do my tutorial on Associated Channel acronyms, but it could do it if needed, but some other venue. Assigning the Associated Channel Type is what I see that a solid majority want to happen! This is not an attempt to end-run the consensus call by the AD, just my personal read of the situation. The first remaining caveat is the draft-betts is too poorly written and need to be improve, suggestions has been sent to this mailing list, I take it that people who send mails to this list saying that they support Russ' proposal also implicitly support these improvements. The second caveat is that an ITU-T Recommendation is not stable according to the criteria we normally apply to RFCs. We are solving this by generating a RFC from draft-betts-. I believe that the way out here is to update RFC draft-betts- every time ITU-T rev G.8113.1. That way we will have our stable reference pointing to the right version of G.8113.1. I'd like to hear from the process people on this, but not as part of this last call. /Loa On 2012-03-19 11:55, Maarten vissers wrote: +1 Original Message From: Rui Costarco...@ptinovacao.pt Sent: zaterdag 17 maart 2012 12:00:56 + To: ietf@ietf.orgietf@ietf.org Subject: 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 based OAM) to Informational RFC Hello, I support the allocation of an ACH codepoint to G.8113.1, not precluding the ITU-T to progress refinements. Ergo, i support this draft and proposal http://www.ietf.org/mail-archive/web/ietf/current/msg72191.html IMHO, the status quo analysis expressed in both http://www.ietf.org/mail-archive/web/ietf/current/msg72188.html and http://www.ietf.org/mail-archive/web/ietf/current/msg72273.html is accurate. Regards, Rui = Original Message From: The IESGiesg-secret...@ietf.org Sent: Wed, 22 Feb 2012 07:12:52 -0800 To: IETF-Announceietf-annou...@ietf.org Subject: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernetbased OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM' draft-betts-itu-oam-ach-code-point-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document assigns an Associated Channel Type code point for carrying Ethernet based Operations, Administration, and Management messages in the MPLS Generic Associated Channel (G-ACh). The file can be obtained via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ No IPR declarations have been submitted directly on this I-D. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13
Re: [PWE3] FW: Last Call: draft-betts-itu-oam-ach-code-point-03.txt(Allocation of an Associated Channel Code Point for Use byITU-T Ethernet based OAM) to Informational RFC
think the third paragraph is about, I am not clear what you are trying to say. A code point allocation must point to a stable referent. If the desired referent changes, then process needs to be followed to make sure that the IANA is updated in accordance with IETF procedures. Hence, I am left to the conclusion that the third paragraph is actually asking for something we can not do. Can we remove that? OLD: All ITU-T Recommendations are subject to revisions. Therefore, the code point allocated by this document may be used for future versions of [G.8113.1]. NEW: - On 2012-02-27 14:51, Loa Andersson wrote: All, I agree with Stewart, while shortage of code points might be a reason to think twice before allocating one, abundance in itself is never a reason to allocate code points. I'm way less inclined to approve of this draft in the condition it is now. Actually I believe that we should think very careful before approving it at all. /Loa On 2012-02-27 14:01, Stewart Bryant wrote: Daniel Shortage of ACh types was never an issue. The issue issue is the concerns articulated in draft-sprecher-mpls-tp-oam-considerations Stewart On 23/02/2012 10:35, Daniel Cohn wrote: Support - as there is no foreseen shortage in ACH types, I don't see a reason why this code point should not be allocated to an ITU developed protocol that is already deployed in the field. DC -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 22 February 2012 15:13 To: IETF-Announce Subject: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM' draft-betts-itu-oam-ach-code-point-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document assigns an Associated Channel Type code point for carrying Ethernet based Operations, Administration, and Management messages in the MPLS Generic Associated Channel (G-ACh). The file can be obtained via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ pwe3 mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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 based OAM) to Informational RFC
Russ, I'm not KY, but I feel that your question is a bit loaded. Certainly if the document is reviewed and approved by the IETF/IESG it would be no problem to support the assignment of a ACh Type. But I can't see that approval by some other instance actually carry the same merit - so exactly what do u mean by approved G.8113.1? /Loa On 2012-03-01 17:06, Russ Housley wrote: KY: Would you support the assignment to an approved G.8113.1? That is, if the document contained a normative reference to the approved G.8113.1, then the document that makes the code point allocations would sit in the RFC Editor queue until the ITU-T reaches consensus and approves G.8113.1. Russ On Mar 1, 2012, at 10:14 AM, Kyung-Yeop Hong (hongk) wrote: No/do not support. One of the issues with G.8113.1 in LS370 is its stability and maturity. That was one of the reasons why it was not approved. The Ethernet based OAM protocol documented in the LS370 version is intended to be deployed for MPLS networks. I think the IETF has a duty to ensure that a solution is stable and works for MPLS networks before the code point allocation. A number of concerns with the deployment of this proposed protocol raised in draft-spercher-mpls-tp-oam-considerations are critical to the Internet and must be taken into consideration in this Last Call. KY -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 22 February 2012 15:13 To: IETF-Announce Subject: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM' draft-betts-itu-oam-ach-code-point-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document assigns an Associated Channel Type code point for carrying Ethernet based Operations, Administration, and Management messages in the MPLS Generic Associated Channel (G-ACh). The file can be obtained via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ 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 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PWE3] FW: Last Call: draft-betts-itu-oam-ach-code-point-03.txt(Allocation of an Associated Channel Code Point for Use byITU-T Ethernet based OAM) to Informational RFC
Feng, there is an interesting contradiction in your position. You quote Dave when he says We reject presidents and kings Yet you seen to support the political intervention by certain nations in the MPLS-TP project! Why is that? /Loa On 2012-02-27 04:58, HUANG Feng F wrote: +1 The Internet Engineering Task Force (IETF) is a large open international community, it should support running code has been deployed in real network. Quote from David Clark: We reject kings, presidents and voting. We believe in rough consensus and running code. B.R. Feng -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Daniel Cohn Sent: 2012年2月23日 18:35 To: ietf@ietf.org Subject: RE: [PWE3] FW: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocation of an Associated Channel Code Point for Use byITU-T Ethernet based OAM) to Informational RFC Support - as there is no foreseen shortage in ACH types, I don't see a reason why this code point should not be allocated to an ITU developed protocol that is already deployed in the field. DC -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: 22 February 2012 15:13 To: IETF-Announce Subject: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM' draft-betts-itu-oam-ach-code-point-03.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document assigns an Associated Channel Type code point for carrying Ethernet based Operations, Administration, and Management messages in the MPLS Generic Associated Channel (G-ACh). The file can be obtained via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ pwe3 mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 ___ 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 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] point 3 in... RE: Questions about draft-betts-itu-oam-ach-code-point
All (taking chair hat off), I agree with Ross's comments below that if the document is last called it should go through a wg last call (pwe3 and mpls) and through an IETF last call. I agree that these last calls could be in parallel is necessary, but I believe that running the wg last call first and the IETF last call would be beneficial. Given that we have a stable document with stable references to last call. /Loa On 2012-01-13 06:43, Ross Callon wrote: Adrian wrote: My review of the write-up and discussions... 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. My personal opinion (speaking as an individual)... It is pretty clear that there is a lot of interest in this topic in the MPLS WG. It also is clear that this proposal is very much about MPLS. Thus draft-betts-itu-oam-ach-code-point needs to be last called in the MPLS WG. It seems clear that the document also needs IETF last call. I assume this means that one last call would be posted to both the MPLS and IETF WG lists. It seems that this same last call should also be copied to the PWE3 list. Ross ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ 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
All, I've taken time to re-read this draft over the weekend. I still think it is well-written and extremely to the point; it is in the interest of the IETF to publish. I support publication of the draft. Admittedly there are some issues around the e.g. the description of the SDH/SONNET and the standardization of those technologies. Having been involved in development of equipment that could run both SDH and SONET, my understanding is that both when it comes to chips and SW the split, even after the compromise, lead to higher costs and longer schedules. we would have been in a better shape with one standard also that time. Maybe the authors should reflect the facts that Huub correctly point out in his early mail on this thread, where he describes a situation that was much worse than what is in the document. /Loa On 2011-09-26 12:42, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.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 i...@ietf.org mailing lists by 2011-10-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address these OAM requirements, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. The file can be obtained via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Requirement to go to meetings
Nurit, I'm in the same situation, but part of the argument is right. If we do one North America, one Europe and one Asian meeting per year; places like Minneapolis and Phoenix is cheaper regardless where you come from. That is if you compare with high end cities like SF, NY AND DC. ALso places where you need an extra hop to get there. /Loa On 2011-10-23 09:43, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: Both Minneapolis and Phoenix have huge conference facilities, are easy to go to, and can get cheap off-season discount For whom? For me it is much cheaper and easier to go to Europe….:-( *From:*ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] *On Behalf Of *ext Ping Pan *Sent:* Sunday, October 23, 2011 3:13 PM *To:* Eric Burger *Cc:* IETF list discussion *Subject:* Re: Requirement to go to meetings In the past three IETF meetings, I have traveled to Beijing, Prague and Quebec City to meet most who live within a few hours (air, car, walking etc.) from me. The next two will be in Taipei (in Winter) and Paris (in Spring). This is more like a vacation package than a get-together for engineers to solve problems face-to-face. Several of us have chatted about this last week. How about this as a recommendation? We have two meetings in fixed locations each year: Minneapolis in winter, and Phoenix in summer. The other one can be somewhere in Europe or Asia. Both Minneapolis and Phoenix have huge conference facilities, are easy to go to, and can get cheap off-season discount. Most of all, it encourages the participants who want to do work going there. Make sense? Ping On Sun, Oct 23, 2011 at 7:50 AM, Eric Burger ebur...@standardstrack.com mailto:ebur...@standardstrack.com wrote: It gets worse. To attend every IETF meeting costs about $10,000 per year. If we say one has to go to the face-to-face meetings, we limit the IETF to participants from corporations or entities that will sponsor the individual (pay to play?), IETF participants that have independent funds, or people that can generate significantly more than $10,000 per year from their IETF activities. $10,000 per year is not within a typical individual's budget. This is more especially so if the individual comes from a region of the world where the per-capita GDP is below $10,000 per year. Where does the $10,000 figure come from? It is based on the following assumptions: One trip is far, so $2,000 for airfare One trip is near, so $400 for airfare One trip is in between, so $1,200 for airfare Hotel: 6 nights (Sunday - Friday) at $200 average per night (including tax). I know, Taipei is much more than that and Vancouver, including tax, will be exactly that. However, the numbers are nice and round at $200. I often cannot afford to stay at the conference hotel; use your own numbers for your own circumstances. Meals Misc Expenses: $50/day for 6 days So, the calculation is: 3x ($650 registration fee + $1,200 average airfare + $1,200 average hotel cost + $300 meals/other) = $10,050 It is critically important to note the cost is dominated by travel and hotel. The only parameter in IETF's control is the registration fee. Even if ISOC, sponsors, or someone else endowed the IETF so we could drop the registration fee to zero, the annual cost for travel is over $8,000, which is still rather expensive. I do not believe we consciously want to prohibit individuals from participating in the IETF. I do not believe we consciously want to prohibit individuals from outside North America, Europe, and select (wealthy) Asian countries. However, this is one logical result of mandating people go to the face-to-face to get work done. On Oct 23, 2011, at 6:26 AM, Dave CROCKER wrote: On 10/21/2011 7:58 PM, Melinda Shore wrote: It's increasingly the case that if you want to do work at the IETF, you need to go to meetings. I'd have considerable reservations about asking for the kind of money you're suggesting. Melinda, I've changed the subject line because the point you raise is orthogonal to the main thread, but since you raise it, it's worth exploring a bit (since I happen to agree with your observation.) The dynamics that make this true seem to have to do with changes in our community rather than in the nature of the technical work or the online tools. So the question is how to move the center of gravity back to mailing lists? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net http://bbiw.net ___ Ietf mailing list Ietf@ietf.org mailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org mailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy
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've taken time to re-read this draft over the weekend. I still think it is well-written and extremely to the point; it is in the interest of the IETF to publish. I support publication of the draft. Admittedly there are some issues around the e.g. the description of the SDH/SONNET and the standardization of those technologies. Having been involved in development of equipment that could run both SDH and SONET, my understanding is that both when it comes to chips and SW the split, even after the compromise, lead to higher costs and longer schedules. we would have been in a better shape with one standard also that time. Maybe the authors should reflect the facts that Huub correctly point out in his early mail on this thread, where he describes a situation that was much worse than what is in the document. /Loa On 2011-09-26 12:42, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address these OAM requirements, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. The file can be obtained via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
Randy, I might be old-fashioned, but I think the net will give us more tools that can be used together with what we already have, not (necessarily) replace them /Loa On 2011-10-23 10:47, Randy Bush wrote: perhaps we could model using the assumption that, a decade or so hence, there will be no physical meetings, [almost] all will be net-based. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ 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 - comment 2
Malcolm, seems that you have the problem claiming text refers to assumptions or discussion points, especially since the format of the text is clearly decision. /Loa On 2011-10-15 02:37, malcolm.be...@zte.com.cn wrote: Loa, I still do not understand how you can claim that the words from slide 113 of RFC 5317 and quoted in section 1.1 of draft-sprecher-mpls-tp-oam-considerations-01: It is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile The architecture allows for a single OAM technology for LSPs, PWE and a deeply nested network Represent a decision or even a recommendation. However, if as you insist it was a decision can you explain why the IETF chose to ignore this decision and initially defined different encapsulations for the PW and LSP OAM and subsequently defined a second encapsulation for PW OAM. So that now we have two encapsulations for OAM in MPLS-TP PWs. Regards, Malcolm *Loa Andersson l...@pi.nu* 14/10/2011 10:37 AM To malcolm.be...@zte.com.cn cc Ietf@ietf.org 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 - comment 2 Malocolm, there is no conflict - the one OAM solution was and is a decision. /Loa On 2011-10-14 15:59, malcolm.be...@zte.com.cn wrote: Loa, I have added - comment 2 to the subject line and deleted all the other comments. I cannot find section 1.1 or the text one OAM solution in the PDF version of RFC 5317. The last paragraph of section 1 states: In the case of a conflict between the summary and the slides, the slides take precedence. Since those slides were the basis of an important agreement between the IETF and the ITU-T, it should further be noted that in the event that the PDF version of the slides differs from those emailed to ITU-T and IETF management on 18 April 2008 by the co-chairs of the JWT, the emailed slides take precedence. The full quote from slide 12 is: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the **agreed upon starting point** for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements I must also remind you that the JWT did not have the power to make decision for the ITU or IETF as stated in TD515/PLEN that established the ad group on MPLS-TP and the JWT: The Joint Working Team is the union of the ad hoc and design teams. It has no official affiliation or status with either the ITU-T or the IETF but will provide a forum for open communication and cooperative work This is aligned with normal process in the IETF where a design team cannot make decisions for a Working Group. Therefore, my proposed clarification of the context of the one solution statement should be included in draft-sprecher-mpls-tp-oam-considerations. Regards, Malcolm *Loa Andersson l...@pi.nu* 14/10/2011 02:15 AM To malcolm.be...@zte.com.cn cc Ietf@ietf.org 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, juat one small comment on how slide 12 of the JWT report is (mis)used in this debate. The text says: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008. The paragraph is correct and it says that the presentation includes - assumptions - discussion points - decisions The statement on one OAM solution from section 1.1 of RFC5317 clearly falls into the *decision* category. As such it rather support publishing the draft rather than indicating that we shouldn't. /Loa On 2011-10-14 04:31, malcolm.be...@zte.com.cn wrote: Below are my comments on this draft, these are in addition to the comments that I have provided previously. I also support the comments that propose the deletion of sections 4, 5 and 6. I have numbered my comments (1-12) to simplify identification for those who wish to respond. I do not support approval of this draft in its current form. Regards, Malcolm 2) Quote from RFC5317 Section 1.1 includes the following: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. The context of this quote from slide 113 should be clarified; slide 12 states of RFC 5317 states
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
signaling extensions to also configure OAM when a connection is established. 11e) - The market should be allowed to decide between competing solutions. It must be noted that 300,000+ nodes using an Ethernet based OAM solution have already been deployed. These deployments will continue to exist and grow, this reality should be acknowledged. 12) Section 8. Security Considerations All text except the first line should be deleted since it contains general information that is not relevant to the use of a second solution for MPLS-TP OAM. For example the text: - One OAM protocol may be used as a vector to attack the other. Inserting an OAM message of the other OAM protocol onto a link may cause the service to be disrupted and, because some nodes may support both OAM protocols, it may be possible to cause the disruption at a remote point in the network. How is this possible when the use of the ACh to distinguish between protocols allows the “other” protocol to be silently discarded. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ 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 - comment 2
Malocolm, there is no conflict - the one OAM solution was and is a decision. /Loa On 2011-10-14 15:59, malcolm.be...@zte.com.cn wrote: Loa, I have added - comment 2 to the subject line and deleted all the other comments. I cannot find section 1.1 or the text one OAM solution in the PDF version of RFC 5317. The last paragraph of section 1 states: In the case of a conflict between the summary and the slides, the slides take precedence. Since those slides were the basis of an important agreement between the IETF and the ITU-T, it should further be noted that in the event that the PDF version of the slides differs from those emailed to ITU-T and IETF management on 18 April 2008 by the co-chairs of the JWT, the emailed slides take precedence. The full quote from slide 12 is: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the **agreed upon starting point** for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements I must also remind you that the JWT did not have the power to make decision for the ITU or IETF as stated in TD515/PLEN that established the ad group on MPLS-TP and the JWT: The Joint Working Team is the union of the ad hoc and design teams. It has no official affiliation or status with either the ITU-T or the IETF but will provide a forum for open communication and cooperative work This is aligned with normal process in the IETF where a design team cannot make decisions for a Working Group. Therefore, my proposed clarification of the context of the one solution statement should be included in draft-sprecher-mpls-tp-oam-considerations. Regards, Malcolm *Loa Andersson l...@pi.nu* 14/10/2011 02:15 AM To malcolm.be...@zte.com.cn cc Ietf@ietf.org 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, juat one small comment on how slide 12 of the JWT report is (mis)used in this debate. The text says: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008. The paragraph is correct and it says that the presentation includes - assumptions - discussion points - decisions The statement on one OAM solution from section 1.1 of RFC5317 clearly falls into the *decision* category. As such it rather support publishing the draft rather than indicating that we shouldn't. /Loa On 2011-10-14 04:31, malcolm.be...@zte.com.cn wrote: Below are my comments on this draft, these are in addition to the comments that I have provided previously. I also support the comments that propose the deletion of sections 4, 5 and 6. I have numbered my comments (1-12) to simplify identification for those who wish to respond. I do not support approval of this draft in its current form. Regards, Malcolm 2) Quote from RFC5317 Section 1.1 includes the following: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. The context of this quote from slide 113 should be clarified; slide 12 states of RFC 5317 states: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements Proposal: Insert the following text before the quoted text: [RFC 5317] provides a collection of assumptions, discussion points and decisions that the JWT has had during the months of March and April, 2008. This represents the agreed upon starting point for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements. Included in this analysis is the statement that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Manager l...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards
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
Huub, you are partly right - slide 9 says that there are open issues. But at the last meeting with the JWT consensus on the *summary* was the issue. The questions was put explicitly. At that time no one voiced another opinion! /Loa On 2011-10-09 12:58, Huub van Helvoort wrote: Hello Russ, You write: RFC 5317 calls for one, and only one, protocol solution. At least that is how I read JWT Agreement. How the JWT report should be read is written on slide 9 in the PDF: This presentation is a collection of *assumptions*, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements The most relevant text seems to be in Section 9: This text is one of the assumptions, that is why we wrote: *They stated that in their view*: it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. The OAM technology in this text refers to to way the OAM frames can be detected in a data-stream. The text you quote is from the summary section, it summarizes the slides 19 - 22: *MPLS-TP Major Solution Constructs* which address the GAL-GAch solution. We now have the GAL-GAch technology (RFC5586) to detect OAM frames and this technology will be used in PW and LSP, and enables the use of OAM in deeply nested networks. Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard. All MPLS-TP OAM tools should comply with RFC5586. A service provider can now pick any set or sub-set of the available OAM tools and use them without fear to disrupt the internet. Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools. Best regards, Huub (JWT, Ad-Hoc, MEAD member). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ 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) toInformational RFC
Feng, I'm not sure how to parse this, but personal attacks on ietf mailing should at least be substantiated with evidence. Like been said before we discuss thing over and over and come to an working group or IETF consensus call, and then the discussion starts over again. /Loa On 2011-10-05 13:58, HUANG Feng F wrote: Loa, YES, but there are only someone (not organization-that's a individual draft and MEAD team-not ietf mpls group or ietf group, which has been disbanded by themselves one years ago) make decision to done a single solution! B.R. Feng -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: 2011年10月5日 19:53 To: HUANG Feng F Cc: ietf@ietf.org Subject: Re: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC Feng, there were only one organization invbolved in the decision to develop two OAM solutions! /Loa On 2011-10-05 13:29, HUANG Feng F wrote: Dear Loa, Life is not simple, mpls-tp is joint developed by IETF and ITU-T, so it is complicated, the decision should be done by two orgnizations. There are many errors about in this draft as many, for example, Rolf, Huub, Malcolm, Tom Petch and I, point out in emails, it is a bad draft, it should be stop. B.R. Feng -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Loa Andersson Sent: 2011年10月5日 18:48 To: ietf@ietf.org; Rolf Winter Subject: Re: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC Rolf, are you saying that if we just liaise RFC1958 to the ITU-T they will stop developing a competing OAM for MPLS? Sometimes the life is simple, though I doubt that it is this simple. My 2c's is that this a good draft and should be progressed. /Lao On 2011-10-04 11:16, Rolf Winter wrote: Hi, I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 To: huubatw...@gmail.com Cc: ietf@ietf.org 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 Huub, On 2011-09-30 20:19, Huub van Helvoort wrote: All, Section 1,1 also contains the text: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. This is a quote from slide 113 in the PDF version of RFC5317 and should be read in realtion to the statement on slide 12 of the same RFC: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements So the quoted text in the draft is one of the assumptions. The fact that there are currently *two* OAM mechanisms (and not a *single*), i.e. one for PW and one for LSP proves that the assumption was not correct. I'm sorry, I don't understand your logic. You seem to be saying that the fact that two solutions have been designed proves that the assumption that a single solution is possible was false. That doesn't follow at all. The engineering profession has a long history of producing multiple solutions where a single one was possible, and this seems to be just another such case. This isn't news. I quote from RFC 1958 (June 1996): 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list 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
Rolf, are you saying that if we just liaise RFC1958 to the ITU-T they will stop developing a competing OAM for MPLS? Sometimes the life is simple, though I doubt that it is this simple. My 2c's is that this a good draft and should be progressed. /Lao On 2011-10-04 11:16, Rolf Winter wrote: Hi, I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 To: huubatw...@gmail.com Cc: ietf@ietf.org 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 Huub, On 2011-09-30 20:19, Huub van Helvoort wrote: All, Section 1,1 also contains the text: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. This is a quote from slide 113 in the PDF version of RFC5317 and should be read in realtion to the statement on slide 12 of the same RFC: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements So the quoted text in the draft is one of the assumptions. The fact that there are currently *two* OAM mechanisms (and not a *single*), i.e. one for PW and one for LSP proves that the assumption was not correct. I'm sorry, I don't understand your logic. You seem to be saying that the fact that two solutions have been designed proves that the assumption that a single solution is possible was false. That doesn't follow at all. The engineering profession has a long history of producing multiple solutions where a single one was possible, and this seems to be just another such case. This isn't news. I quote from RFC 1958 (June 1996): 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Brian ___ 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 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
Tom, I don't think there is any objections to improving the document, the most straight-forward way of doing this is the time-honored IETF method supply the text! /Loa On 2011-10-05 10:01, t.petch wrote: I oppose publication of this I-D in its present form. The idea of having an I-D that says two OAM solutions will cost is fine, but there are too many technical errors, especially in sections 4 and 5 (better as Brian suggested as appendices), for it to go forward as it stands. Huub, Malcolm and Andy have pointed out the errors in SONET/SDH, I would take issue with OSPF/ISIS and IPv4/IPv6. The errors aren't gross, but they add up to too many. The sponsoring AD has given his reasons why this is an individual submission but I think that the consequence is that the document quality is too low to be published. It needs the review of a wider body of expertise, the routing area perhaps, before it is published. Tom Petch - Original Message - From: The IESGiesg-secret...@ietf.org To: IETF-Announceietf-annou...@ietf.org Sent: Monday, September 26, 2011 9:42 PM Subject: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' draft-sprecher-mpls-tp-oam-considerations-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address these OAM requirements, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. The file can be obtained via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ 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
Rolf, I don't remember saying the sole purpose, the IETF way is to document requirements, specifications, processes and agreements in RFCs; this is just another document in this tradition. ANd as such a very good document. /Loa On 2011-10-05 13:31, Rolf Winter wrote: Hi Loa, Let me answer with a counter-question. If the sole purpose of this document is to stop the development of two OAM solutions, do you think this RFC-to-be will achieve that? Seriously? The problem I see here is that we start a habit of writing politically motivated documents. We have this issue documented already all over the place in the form of minutes, web sites, press releases etc. I think this is enough and the right place. Let the I* and liaisons figure this out so that we all can go back to protocol design and development. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: Loa Andersson [mailto:l...@pi.nu] Sent: Mittwoch, 5. Oktober 2011 12:48 To: ietf@ietf.org; Rolf Winter 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 Rolf, are you saying that if we just liaise RFC1958 to the ITU-T they will stop developing a competing OAM for MPLS? Sometimes the life is simple, though I doubt that it is this simple. My 2c's is that this a good draft and should be progressed. /Lao On 2011-10-04 11:16, Rolf Winter wrote: Hi, I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 To: huubatw...@gmail.com Cc: ietf@ietf.org 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 Huub, On 2011-09-30 20:19, Huub van Helvoort wrote: All, Section 1,1 also contains the text: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. This is a quote from slide 113 in the PDF version of RFC5317 and should be read in realtion to the statement on slide 12 of the same RFC: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements So the quoted text in the draft is one of the assumptions. The fact that there are currently *two* OAM mechanisms (and not a *single*), i.e. one for PW and one for LSP proves that the assumption was not correct. I'm sorry, I don't understand your logic. You seem to be saying that the fact that two solutions have been designed proves that the assumption that a single solution is possible was false. That doesn't follow at all. The engineering profession has a long history of producing multiple solutions where a single one was possible, and this seems to be just another such case. This isn't news. I quote from RFC 1958 (June 1996): 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Brian ___ 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 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717
Re: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
Feng, there were only one organization invbolved in the decision to develop two OAM solutions! /Loa On 2011-10-05 13:29, HUANG Feng F wrote: Dear Loa, Life is not simple, mpls-tp is joint developed by IETF and ITU-T, so it is complicated, the decision should be done by two orgnizations. There are many errors about in this draft as many, for example, Rolf, Huub, Malcolm, Tom Petch and I, point out in emails, it is a bad draft, it should be stop. B.R. Feng -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Loa Andersson Sent: 2011年10月5日 18:48 To: ietf@ietf.org; Rolf Winter Subject: Re: Last Call:draft-sprecher-mpls-tp-oam-considerations-01.txt(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC Rolf, are you saying that if we just liaise RFC1958 to the ITU-T they will stop developing a competing OAM for MPLS? Sometimes the life is simple, though I doubt that it is this simple. My 2c's is that this a good draft and should be progressed. /Lao On 2011-10-04 11:16, Rolf Winter wrote: Hi, I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Freitag, 30. September 2011 21:48 To: huubatw...@gmail.com Cc: ietf@ietf.org 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 Huub, On 2011-09-30 20:19, Huub van Helvoort wrote: All, Section 1,1 also contains the text: [RFC5317] includes the analysis that it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network. This is a quote from slide 113 in the PDF version of RFC5317 and should be read in realtion to the statement on slide 12 of the same RFC: This presentation is a collection of assumptions, discussion points and decisions that the combined group has had during the months of March and April, 2008 This represents the *agreed upon starting point* for the technical analysis of the T-MPLS requirements from the ITU-T and the MPLS architecture to meet those requirements So the quoted text in the draft is one of the assumptions. The fact that there are currently *two* OAM mechanisms (and not a *single*), i.e. one for PW and one for LSP proves that the assumption was not correct. I'm sorry, I don't understand your logic. You seem to be saying that the fact that two solutions have been designed proves that the assumption that a single solution is possible was false. That doesn't follow at all. The engineering profession has a long history of producing multiple solutions where a single one was possible, and this seems to be just another such case. This isn't news. I quote from RFC 1958 (June 1996): 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. Brian ___ 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 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
All, Since someone has commented about the process used for resolving questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below. The history of draft-ietf-mpls-tp-cc-cv-rdi working group review process is: On February 3rd 2011 the working group last call was issued on version -03 This was copied to the the Ad Hoc Team List and liaised to SG15 also on February 3rd This working group last call ended om Feb 28 On Feb 28 we also received a liaison with comments from SG15 The authors compiled a list of all comments received as part the MPLS working group last call; these comments - and the intended resolution - is included in the meeting minutes from the Prague meeting: http://www.ietf.org/proceedings/80/slides/mpls-9.pdf During the IETF meeting in Prague, we agreed with the BFD working group to do a separate working group last callfor the BFD working group The (BFD) working group last call was started on March 30th and ran for 13 days. The last call ended on April 11th. The authors have since worked hard to resolve comments, some issue has been brought to the working group mailing list for resolution. Version -04 of the document was published June 28th. The publication request for draft-ietf-mpls-tp-cc-cv-rdi was sent June 29th. The AD review resulted in a New ID needed due to mostly editorial comments. Version -05 was published on June 29 and the IETF last call started as soon as the new ID was avaialbe. The current list of Last Call Comments resoltion is also avaiable at: http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls The list of issues that the authors kept very carefully, shows without doubt that no comments been ignored. Loa mpls wg document shepherd On 2011-07-05 00:02, Rui Costa wrote: IMHO and for the record: ITU-T comments regarding this draft haven't been discussed with ITU-T but were simply ignored. No LS describing these comments' resolution was sent. Several service providers regarded this draft as not meeting their transport networks' needs. [The v03 draft was published in Feb and went to WG LC. The v04 draft addressing WG LC comments was published on the 28th June (same date as the proto write-up). When was the WG LC launched, to verify LC comments resolution?] Regards, Rui -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: quinta-feira, 30 de Junho de 2011 14:47 To: IETF-Announce Cc: m...@ietf.org Subject: [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 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile' draft-ietf-mpls-tp-cc-cv-rdi-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Continuity Check, Proactive Connectivity Verification and Remote Defect Indication functionalities are required for MPLS-TP OAM. Continuity Check monitors the integrity of the continuity of the label switched path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the label switched path between sink and source for any connectivity issues. Remote defect indication enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a pseudo wire, label switched path or Section. This document specifies methods for proactive continuity check, continuity verification, and remote defect indication for MPLS-TP label switched paths, pseudo wires and Sections using Bidirectional Forwarding Detection. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ No IPR declarations have been submitted directly on this I-D. ___ 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 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13
Re: Poster sessions
ALl, what is here called poster session reminds me a awful lot of the bar bof's we been running for a long time. Anyone care to draw the line between the two and try to motivate why we need boths. As I see nothing stops from bringing a poster to a bar bof, or a white board for taht matter. /Loa On 2011-01-10 12:09, Henk Uijterwaal wrote: On 10/01/2011 11:14, Yoav Nir wrote: On Jan 10, 2011, at 11:31 AM, Lars Eggert wrote: Hi, On 2011-1-8, at 19:41, R. B. wrote: I'm really in a rush, but I want to send my 0.02 too. I like the idea of a poster session, since a single I-D could go unobserved in the churn of other I-Ds. many areas have open meetings where folks already can present such ideas. It's up to the ADs or chairs of such meetings to decide if presentation time is warranted, with or without an accompanying ID. True, but in those meetings you usually get about 5 minutes to present (which is good), but then some other people present other things. Following that, those people in the audience who are interested will have to seek you out among the 1200 participants, or go to a mailing list just to ask questions. A poster session would allow for more interaction. I think that there is another issue. Some people are good at doing 5 minute pitches of an idea, others aren't. In case one is not, then I think a poster session might be a good alternative. The costs for a poster session are almost 0. Isn't this something we can just try? Henk -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-tp-framework (A Framework for MPLS in Transport Networks) to Informational RFC
...@ietf.org Sent: Wednesday, April 07, 2010 4:33 PM Subject: [mpls] Last Call: draft-ietf-mpls-tp-framework (A Framework forMPLS in Transport Networks) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Framework for MPLS in Transport Networks ' draft-ietf-mpls-tp-framework-11.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-04-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18027rf c_flag=0 ___ 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 -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What day is 2010-01-02
would Thursday be an acceptable answer? /Loa -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Corporate email attachment filters and IETF emails
All, Hi - From: Richard L. Barnes rbar...@bbn.com To: IETF Member Dave Aronson ietf2d...@davearonson.com Cc: IETF Discussion ietf@ietf.org Sent: Monday, December 14, 2009 9:46 AM Subject: Re: Corporate email attachment filters and IETF emails Clearly, the best solution to this problem is to enforce Latin as the official language of the Internet. Lots of people already use the Latin character set! It's about time we got rid of that pesky J and W, and we don't *really *need both V and U, do uue? :-) great idea - and we should als adopt Latin numbers! /Loa Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 10 717 52 13 +46 767 72 92 13 email: loa.anders...@ericsson.com l...@pi.nu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
Adrian, I think both statements are true. I've seen operators putting almost any RFC in RFPs, (actually done it myself) STD, DS, PS, Informational, Experimental, Historic and April 1st. An RFC is an RFC is an RFC! On the other hand talking to folks active in other SDOs you very often hear the no standards argument. Renaming without changing definitions should part of the job. /Loa Adrian Farrel wrote: Hi, From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... I don't think this is a truth universally acknowledged. I have heard the IETF disparaged a number of times on account of hardly having any standards. For example, a full Standard is equated by some people with an ITU-T Recommendation with the implication that a DS and PS are significantly inferior to a Recommendation. Whatever we might think of the value of this statement and the motives of the people who make it, it is clear that the names of the different levels of RFC are perceived outside the IETF. Over dinner this evening we wondered whether something as simple as looking again at the names of the stages in the three phase RFC process might serve to address both the perceptions and the motivations for progression. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for OAMin MPLS Transport Networks) to Proposed Standard
All, comments as the document shepherd. We have comments on the draft-ietf-mpls-tp-oam-framework in IETF last call from Yoshinori Koike, Jonathan Sadler and Ruiquan Jing. All are subscribed to IETF lists that were included in the working group last calls. 1. There are comments for the same the look and feel for operations across different networks based on different technologies, on OAM interoperability between different technologies. 2. There are comments on interworking/ineroperability/translation between networks based on different technologies. 3. There is a comment that the involvement (awarness) of the MPLS-TP work is not good enough on the ITU-T side. 4. There is a requirement to change the MEP/MIP architecture. 5. There is a comment that wants to add new information that is not technical in it character to the document. For comments on (1), this is a bit unclear, I assume that we are not talking about look and feel of bits on the wire but look and feel for the operational interfaces and procedures. This is captured in the overall MPLS-TP requirements: To realize these goals, it is essential that packet-transport technology be available that can support the same high benchmarks for reliability and operational simplicity set by SDH/SONET and OTN technologies. and Furthermore, for carriers it is important that operation of such packet transport networks should preserve the look-and-feel to which carriers have become accustomed in deploying their optical transport networks, while providing common, multi-layer operations, resiliency, control, and multi-technology management. So this is taken care of. For comments on (2). This was discussed during working group last call and prior, and it was discussed on the ITU-T ad hoc team list during the period when a response was written in response to the MPLS WG last call. The IESG position is that interworking different technologies is out of scope for the MPLS-TP project. The ITU-T did not make a request to include this requirement within MPLS-TP. In liaison https://datatracker.ietf.org/documents/LIAISON/file706.pdf from the ITU-T it was agreed that if and when ITU-T converges on such requirements they will be taken to the IETF through the MPLS change process (RFC4929). This comment should also be resolved. Comment 3, on ITU-T participation in the MPLS-TP project and in the review of the MPLS-TP documents I strongly object to to this comment, the entire project has been set up to guarantee that we have a good flow of information between the two organizations. Tthere are plenty of opportunities for the ITU-T to provide input both through their own procedures and through normal IETF procedures. Comments 4. The maintenance architecture as it is defined operates with functional groups that could be attached to e.g. an LSP at different points. MEPs are Maintenance End Points and can actively generate e.g. OAM flows and traffic to localize failures. MIPs are Maintenance Intermediate Points, which are passive and can only respond if a request are sent to them. The requirements involves a total re-wrap of the Maintenance architecture, it was discussed in Q10/15 and turned down as not aligned with the rest of the requirements we received form other operators. The MPLS-TP maintenace architecture is further explained and expanded upon in draft-ietf-mpls-tp-oam-framework. Further discussion on the maintenance architecture should take place in the context of that document, rather han in the context of the requirements document that should focus on functional requirements. Comment 5. This is a bit trickier since it asks for substantial additions, that is not requirements but descriptive text and tables. Given the nature of the information I'd would like to take it as an input to the MPLS-TP OAM Framework where it would fit nicely. /Loa -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[ Re: [mpls] WG Review: Recharter of Multiprotocol Label Switching (mpls)]
Eric, Eric Rosen wrote: - Define requirements, mechanisms and protocol extensions for point-to-multipoint (P2MP) MPLS Should be P2MP and MP2MP (multipoint-to-multipoint) MPLS; we wouldn't want to suddenly find out that half of draft-ietf-mpls-ldp-p2mp is out of charter ;-) What I (with the wg chair hat on) think this is about is to add the piece about mpls-tp to the mpls wg charter. We've discussed in the wg and have wg consensus to do that. A couple of milestones are also being changed. Having said that, I'm also of the opinion that we need a major revision of the mpls wg charter, e.g. for the reasons Eric discusses above. However, that process needs to start in the working and have wg consensus when we ask the IESG for the update. I can see that it will be necessary to start process during the autumn. /Loa ___ mpls mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
hmmm... Henrik Levkowetz wrote: On 2007-12-02 10:38 Bob Hinden said the following: ... Based on the past record, we're talking about something that happens 0.58% of the time, or less. Of course, predicting the future from the past is iffy; there have been 10 appeals in 2006 and only one (not document related) in 2007, so it varies. Thanks for looking at the data. It seems to me that we shouldn't be delaying all new RFCs for a problem that only occurs .58% of the time. so if we are talking about all documents; what is the percentage that is (could be) actually published before 60 days and how many days before day 60 is that (typically) /Loa +1 Henrik -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: [EMAIL PROTECTED] [EMAIL PROTECTED] This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-aboba-sg-experiment-02
Inline please, Eric Rescorla wrote: At Mon, 08 Oct 2007 10:03:35 +0300, Jari Arkko wrote: But the issues with scheduling, lack of attention for important topics, and low quality of new work proposals are real concerns. I have a slightly different take on this than what you had above, however. INT is probably the most troublesome area with respect to scheduling, and I generally do not have any free slots during an IETF meeting. However, I don't think this implies we shouldn't consider new work. Its not as if the Internet was ready and nothing new was ever needed. We have a number of serious issues and new demands to meet. But we need to actively manage the set of things we work on. Some of the tools we need to consider include actually stopping WGs that have completed their task, rechartering, management restructuring (e.g., merging groups), questioning whether a non-delivering WG needs to continue to exist and consume slots, and yes, even new work. I'm not saying that we shouldn't consider new work either, and we do consider new work under the current system. However, since the amount of work we can do is to a great degree constant, that means that any new work should be more important than whatever we're doing now. Making it easier to start new work (which is pretty much an explicit goal of this proposal) is likely to create a situation in which more new work gets done at the expense of current work. That might or might not be good depending on what one thinks of the current work. Finally, it's unclear the extent to which SGs are intended to transition directly to WGs without going through another BOF phase. I have two concerns here: 1. It will be hard for the IESG to deny successful SGs the right to form a WG. Saying NO is still going to be needed. Absolutely. But I think this is going to create a structural near-imperative to saying yes, in the same way that the IESG feels strong pressure to advance documents from chartered WGs, even if it's clear in retrospect that the output isn't of much value and probably shouldn't have been chartered in the first place. don't no if I and Ekr is saying the same thing, what I'm wary about is expectations created, an AD accepting a BoF creates expectations, creating a Study Group would do so to a larger extent /Loa -Ekr -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: [EMAIL PROTECTED] [EMAIL PROTECTED] This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area]
All, I support starting this area, but am a bit confused on what goes in there and not. Espcially on video, if is video conferencing is is fine but if it is video on demand it will have (more or less) the same requirements as TV over Internet. So why is video there but not TV or why isn't TV there when video is? /Loa Original Message Subject: Possible new Real-Time Applications and Infrastucture (RAI) Area Date: Fri, 16 Sep 2005 09:14:15 -0400 From: IETF Chair [EMAIL PROTECTED] To: IETF Announcement list ietf-announce@ietf.org As mentioned in the recent call for NomCom volunteers, the IESG is considering the creation of a new area, as set out below. We solicit feedback from the community on the scope of this potential new area as well as the impact on the IETF's infrastructure and efficiency of setting up this new area. We need to decide quite quickly, to fit the NomCom schedule. Please write to iesg@ietf.org, or to ietf@ietf.org if you want community discussion of your comment. (There's no need to write to both!) Brian Carpenter - Real-Time Applications and Infrastucture (RAI) Area Description The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications. Work in this area serves an emerging industry whose applications and services include voice and video over IP, instant messaging and presence. These applications and services are real-time in the sense that delay impedes human participation in the associated systems. The RAI Area is seeded with existing working groups from the Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, and SIGTRAN. A good rule of thumb for the incorporation of new work into RAI, as opposed to Transport or Applications, is that the work in question has major goals supporting instant interpersonal communication or its infrastructure. For example, they can range from applications to help users make decisions about how best to communicate using presence services, to session signaling protocols and emergency call routing solutions, to work on the layer five issues for Internet telephony. Like all areas of the IETF, the RAI Area draws on the work of numerous other areas, and as such there can be no neat mathematical boundaries delineating RAI's work from the rest of the IETF. The new area will allow an existing community within the IETF to solidify its vision and to benefit from increased institutional support. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 address space lifetime, was: national security
Iljitsch van Beijnum wrote: I have a slightly better than handwaving indication that the current statistics don't show the full picture. In the past 4 years we've seen large scale always-on internet access deployment. However, this doesn't show up in the address space usage statistics. So addresses must be coming from other places than just the IANA storage rooms. have an always on - address is 192.169.0.102 /Loa -- Loa Andersson mobile +46 739 81 21 64
Re: Protocol Action: iSCSI to Proposed Standard
Ran, would agree to this, and put even stronger ... Internet RFCs the normal Inernet terminology SHOULD be used, unless there are very stong and explicitly stated reasons not to ... it should als be that the I* have a guiding role in this /Loa RJ Atkinson wrote: On Wednesday, Feb 12, 2003, at 13:24 America/Montreal, Mallikarjun C. wrote: All the Internet documentation with which I am familiar, as well as the I think we have a case of overlapping vocabulary from two different domains. Per SCSI Architecture Model (SAM-2, SAM-3), iSCSI is very clearly a SCSI transport protocol (as opposed to a SCSI application layer protocol). Parallel SCSI, Fibre Channel etc. are all SCSI transports per SCSI conventions. That is all the critiqued abstract is trying to describe. In the context of an *Internet* RFC, it seems sensible to use the normal Internet terminology -- unless one very very clearly indicates that a term is being used in some different semantic. One might postulate that the document's editors and RFC-Editor could work out a mutually agreeable editorial change here to add clarity. Ran
Re: Last Call: CR-LDP Extensions for ASON to Informational]
Steve, it appears to me that you decribes a situation that many of us we are very familiar with, most of us have sent -00.txt IDs to working groups, and have been met by a complete lack of interest. In retrospect I have to say that most of the time the wg was right - bad idea. To bring work into the working group(s) you have to generate interest and discussion, lack of interest signifies end of the road. What you say is that you had (have) very little interest for the work you proposed, so under normal circumstances this would just have been dropped. Given current circumstances - with a great deal of interest elsewhere this came back again and again and we now even have the IESG taken a decision to approve work (that require IETF consensus) on very shaky grounds. For my part that is history! But it seems to me that putting the blame on the ietf when one fail to create interest for a work is self-defeating. What we need to do now is looking in to to things - how codepoints for the (G)MPLS namespace are allocated and make certain that we have a uniform approach to this and common guidelines for the whole namespace - how wi handle requirements on extensions/changes in the protocols specified for (G)MPLS and come up with a process that guarantee that IETF acts correctly and timely when other organizations request such changes/extensions, but also that the IETF is in control of what is happening to the (G)MPLS and that such a process is accepted and used by parties asking for extensions/changes. I sincerly hope to get your support for such a process, I'm working on a -00.txt version and would hate to get into a no response siutation ;) /Loa Jerry, Lets be clear on the timeline and what you consider to be recent. - The ASON requirements were communicated October 2001 - request for help from ccamp (no response) - Analysis of ASON requirements against GMPLS protocols, identifying gaps, completed Febrary 2002 - request ccamp to help close gaps (no response) - Proposals into ITU-T agreed about how to close gaps communicated May 2002, with request now to align the GMPLS documents with ITU-T work (again, no response) - Final request for comments, October 2002, (again no response)
Re: Last Call: CR-LDP Extensions for ASON to Informational
Bert, my bad - what I meant was that the extensions in the normative references would be ietf approved by indirection, when the documents asking for code points were approved was not obvious to people reviewing (at least it was not obvious to me, not that anyone tried to run a secret process and I'm concerned that the OIF has specified extension to LDP, and preliminary allocated message names from the IETF concnsus space more than a year ago and that this does not show in the IANA registry yet. there are (I believe) implementations of the UNI spec deployed. /Loa Wijnen, Bert (Bert) wrote: loa The consequence of approving the drafts will be that the extensions loa by OIF and ITU will be approved by the IETF. I'm not sure that this loa has been in the open. Two points: - the extensions to LDP were found to be in space that requires IETF Consensus, and so Scott and I asked for an IETF Last Call on the document. That is an explicit OPEN process Bert -- Loa Andersson Mobile +46 739 81 21 64 Email [EMAIL PROTECTED]
Re: Last Call: CR-LDP Extensions for ASON to Informational
All, taking a step back - I think we are discussing several issues in a mix that makes it very hard to sort this out. 1. What other organizations may do to IETF (in this context (G)MPLS) protocols This won't be sorted out in this thread - and the only opinion so far is that it is a bad idea to let anyone else change or extend IETF protocols. This will require at statement from involved wg chairs and ADs and an approval from the IESG. I will push for such a statement. 2. Have the IETF protocols been changed This is is a matter of how changed is defined. Clearly the OIF UNI signaling spec extends the LDP protocol, message and new TLV. This is referenced by a normative reference in the three drafts discussed here draft-lin-ccamp-gmpls-ason-rsvpte-04.txt draft-aboulmagd-ccamp-crldp-ason-ext-02.txt draft-bala-uni-ldp-rsvp-extensions-04.txt I understand that the IESG wants to treat those as a packet, and that the last call on the CR-LDP Extensions for ASON to Informational in fact is a last call on all three of them. Further this could be construed to be seen as an last call on normative references - after all normative references are considered to necessary for implementing a spec. Also, the ITU work extends the IETF protocols, new objects, new TLVs and new error codes, that is why the drafts were written - to make it possible for IANA to approve the needed code points. In our normal use of terms change includes extends, but we should probably make that clear. The consequence of approving the drafts will be that the extensions by OIF and ITU will be approved by the IETF. I'm not sure that this has been in the open. However, not having a change process that relates to these protocols I'm not sure if the IESG can do anything else than approving that the IANA allocate the code points. 3. The quality of the drafts In my opinion (if I were to review them as a wg chair, but I'm not sure that those criteria apply to informational documents) we have a problem here. The draft-lin-ccamp-gmpls-ason-rsvpte-04.txt and the draft-bala-uni-ldp-rsvp-extensions-04.txt is an a shape such that I would (reluctantly) request publishing. But the draft-aboulmagd-ccamp-crldp-ason-ext-02.txt is not, there is a long series of points that needs to be updated. References, TLV description, un-expanded acronyms, etc. Would have returned this to the author for further work. Aside from that I have a couple of technical issues. Now, if the IESG considers them to be a package, this would effect all of them. I guess that it would be possible to weed the draft after it has been approved, but it deviates from normal practice. My belief is that we should try to separate these issues from each other. /Loa -- Loa Andersson Mobile +46 739 81 21 64 Email [EMAIL PROTECTED]
Re: Last Call: CR-LDP Extensions for ASON to Informational
All, Zhi-Wei is right this is procedural and intentionally so. I do not criticize ITU or people that are active in the ITU for not following the IETF procedures, especially since there is a big hole in the procedural framework here. The only one to blame for the lack in procedure are ourselves :(, but we can't cry over spilled milk, but need to do something about it. What I'm saying is that what happened here very acutely demonstrates this need to document such a procedure. /Loa Lin, Zhi-Wei (Zhi) wrote: Hi Loa, See comments below...I guess none of these comments are technical, but more procedural... -Original Message- From: Loa Andersson [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 6:59 AM To: Lin, Zhi-Wei (Zhi) Cc: Wijnen, Bert (Bert); Scott Bradner (E-mail); '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; Lam, Hing-Kam (Kam); Malcolm Betts (E-mail); Stephen Shew (E-mail); Lyndon Ong (E-mail); Alan McGuire (E-mail); Trowbridge, Stephen J (Steve) Subject: Re: Last Call: CR-LDP Extensions for ASON to Informational All, taking a step back - I think we are discussing several issues in a mix that makes it very hard to sort this out. 1. What other organizations may do to IETF (in this context (G)MPLS) protocols This won't be sorted out in this thread - and the only opinion so far is that it is a bad idea to let anyone else change or extend IETF protocols. zhiLast time I checked, the IETF didn't change the protocols, individuals did through contributions. The extensions requested for Call/Connection control were submitted by an individual. The fact the ITU weighed in requesting approval of the changes is a separate issue./zhi This will require at statement from involved wg chairs and ADs and an approval from the IESG. I will push for such a statement. 2. Have the IETF protocols been changed This is is a matter of how changed is defined. Clearly the OIF UNI signaling spec extends the LDP protocol, message and new TLV. This is referenced by a normative reference in the three drafts discussed here draft-lin-ccamp-gmpls-ason-rsvpte-04.txt draft-aboulmagd-ccamp-crldp-ason-ext-02.txt draft-bala-uni-ldp-rsvp-extensions-04.txt I understand that the IESG wants to treat those as a packet, and that the last call on the CR-LDP Extensions for ASON to Informational in fact is a last call on all three of them. Further this could be construed to be seen as an last call on normative references - after all normative references are considered to necessary for implementing a spec. Also, the ITU work extends the IETF protocols, new objects, new TLVs and new error codes, that is why the drafts were written - to make it possible for IANA to approve the needed code points. In our normal use of terms change includes extends, but we should probably make that clear. The consequence of approving the drafts will be that the extensions by OIF and ITU will be approved by the IETF. I'm not sure that this has been in the open. zhiThis has been presented at the last few IETF ccamp meetings. I don't know how else to make it more clear the intention./zhi However, not having a change process that relates to these protocols I'm not sure if the IESG can do anything else than approving that the IANA allocate the code points. 3. The quality of the drafts In my opinion (if I were to review them as a wg chair, but I'm not sure that those criteria apply to informational documents) we have a problem here. The draft-lin-ccamp-gmpls-ason-rsvpte-04.txt and the draft-bala-uni-ldp-rsvp-extensions-04.txt is an a shape such that I would (reluctantly) request publishing. But the draft-aboulmagd-ccamp-crldp-ason-ext-02.txt is not, there is a long series of points that needs to be updated. References, TLV description, un-expanded acronyms, etc. Would have returned this to the author for further work. Aside from that I have a couple of technical issues. Now, if the IESG considers them to be a package, this would effect all of them. I guess that it would be possible to weed the draft after it has been approved, but it deviates from normal practice. My belief is that we should try to separate these issues from each other. /Loa -- Loa Andersson Mobile +46 739 81 21 64 Email [EMAIL PROTECTED]
Re: CORRECTION: Last Call: CR-LDP Extensions for ASON to Informational
Osama, sorry our mails crossed each other on the wire. I see your point, but doi not really understand why you need the actual code points to reach consensus - as long as you know you will get them? But, I will not try to stop publishing the draft - as long as the note on cr-ldp not scheduled for further development is added. /Loa Osama Aboul-Magd wrote: Hi Adrian, The ITU is scheduled to consent G.7713.3 by the end of the month. In order for this to happen we need the IANA code points, and this is the only purpose of this draft. I hope now you see the urgency of this draft. Regards; Osama Aboul-Magd ATI Strategic Standards and Protocols Nortel Networks P.O. Box 3511, Station C Ottawa, Ontario, Canada K1Y-4H7 Tel: +1 613 763 5827 e.mail:[EMAIL PROTECTED] -Original Message- From: Adrian Farrel [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 12:20 PM To: Loa Andersson Cc: [EMAIL PROTECTED]; Aboul-Magd, Osama [CAR:1A00:EXCH]; [EMAIL PROTECTED] Subject: Re: CORRECTION: Last Call: CR-LDP Extensions for ASON to Informational trying to understand what you are saying - it seems like you are implying that there is no consensus with in ITU on how to progress this, and that therefore would be premature for IETF to publish this as an informational RFC. Correct? I'm not quite saying that. I am saying that it sounds to me from the discussion that the ITU has not yet reached consent. It seemed to me that if the draft is intended to document the ITU preferences as informational, it would be as well to wait until the ITU has fully signed off. I don't see any rush for this. Anyhow - I think it would be appropriate to add a note clarifying that IETF will not progress cr-ldp beyond Proposed Standard. Adrian -- Loa Andersson Mobile +46 739 81 21 64 Email [EMAIL PROTECTED]
Re: CORRECTION: Last Call: CR-LDP Extensions for ASON to Informational
Adrian, trying to understand what you are saying - it seems like you are implying that there is no consensus with in ITU on how to progress this, and that therefore would be premature for IETF to publish this as an informational RFC. Correct? Anyhow - I think it would be appropriate to add a note clarifying that IETF will not progress cr-ldp beyond Proposed Standard. /Loa Adrian Farrel wrote: snip I would caution against progressing this draft until the referenced ITU material (G.7713.3) has reached consent within the ITU since to move it forward at this stage as an informational RFC might be misleading. -- Loa Andersson Mobile +46 739 81 21 64 Email [EMAIL PROTECTED]
Re: CORRECTION: Last Call: CR-LDP Extensions for ASON to Informational
Adrian, Adrian Farrel wrote: trying to understand what you are saying - it seems like you are implying that there is no consensus with in ITU on how to progress this, and that therefore would be premature for IETF to publish this as an informational RFC. Correct? I'm not quite saying that. I am saying that it sounds to me from the discussion that the ITU has not yet reached consent. It seemed to me that if the draft is intended to document the ITU preferences as informational, it would be as well to wait until the ITU has fully signed off. I don't see any rush for this. ok - I can see the difference - and it seems that you are correct. If the ITU discussion still has some way to go before the discussion settles and the preferences better known - wouldn't it be appropriate to wait until this happens? Osama, care to comment? /Loa Anyhow - I think it would be appropriate to add a note clarifying that IETF will not progress cr-ldp beyond Proposed Standard. Adrian -- Loa Andersson Mobile +46 739 81 21 64 Email [EMAIL PROTECTED]
Re: Reminder: Deadline for input on sub-ip discussion
Harald Tveit Alvestrand wrote: All, snip If you have a strong preference for one (or two) of these, and have not yet said so, please indicate your opinion (and your reasons) by mail to [EMAIL PROTECTED] before Thursday. my preferences are 2 or 3, so far i've not seen any other argument for 1 other than it was decided 2 years ago, if we really want the 3 of the wg's to finish let them do so with re-org i strongly doubt that ccamp, mpls and ppvpn are candidates for closing down in 6 months it seems like the arguments by keith, fred and joe are good arguments for that these wg's need a focus of their own if you believ that they are doing harm, that is not reason to re-org, closing down would be called for if you believe they are doing good, let them continue to do so in neither case shuffle groups around helps i can live with status quo /Loa -- Loa Andersson Mobile +46 739 81 21 64 Email [EMAIL PROTECTED]
Re: Heard at the IETF
Lloyd, I thought that the code was that if there were no objections you had a (at least passive) support. /Loa Lloyd Wood wrote: I imagine that the worst thing about IETF'ers in lifts is that when the lift door opens you can't just ask e.g. 'going up?'. You have to ask 'going up?', get a hummed response, then 'going down?', get a second hummed response, and evaluate the loudness of the two responses before deciding to enter the lift or not. L. lift muzak with quiet passages can play havoc with this process. [EMAIL PROTECTED]PGPhttp://www.ee.surrey.ac.uk/Personal/L.Wood/ -- Loa Andersson Director Routing Architecture Lab, EMEA St Eriksgatan 115A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 e-mail: [EMAIL PROTECTED]
