Re: Terms and Conditions May Apply
On 13/10/2013 20:16, Brian E Carpenter wrote: I know we don't normally do movie plugs on this list, but anyone who's planning to attend the technical plenary in Vancouver could do worse than watch Terms and Conditions May Apply. It covers both commercial and governmental invasions of privacy, and how they are interlinked. http://www.imdb.com/title/tt2084953/ or http://tacma.net/ (but you might not want to click on the 'I agree' button until you've seen the movie...) Brian Seeming terms and conditions means that terms and conditions is not available in the UK. Stewart
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 06/09/2013 04:19, Brian E Carpenter wrote: On 06/09/2013 15:08, Ted Lemon wrote: On Sep 5, 2013, at 9:36 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I'm sorry, I don't detect the emergency. I think we all knew NSA was collecting the data. Why didn't we do something about it sooner? Wasn't it an emergency when the PATRIOT act was passed? We certainly thought it was an emergency back in the days of Skipjack, but then they convinced us we'd won. Turns out they just went around us. Tell me what the IETF could be doing that it isn't already doing. I'm not talking about what implementors and operators and users should be doing; still less about what legislators should or shouldn't be doing. I care about all those things, but the question here is what standards or informational outputs from the IETF are needed, in addition to what's already done or in the works. There is a whole bunch of stuff we can do to make transit traffic less observable. In other words we can modify things so the only think you know about a packet is where it is going, not what it is or who it came from. Stewart
Re: making our meetings more worth the time/expense
On 31/07/2013 15:00, Barry Leiba wrote: The most valuable part of IETF meeting is and has always been the hall conversations and side meetings I think *side meetings* are killing IETF, I call it *hidden meetings*, there is no input for IETF when we have side meetings. The input to IETF in through meeting sessions and discussion lists. I have no argument with your last sentence; it's absolutely correct. But I think you misunderstand the point Donald is making about things such as small hallway conversations. Example: A few people get together in a corner and one says, About that point I made on the list that you brushed off... here's what I'm talking about:, and five or ten minutes of discussion ensues. At the end, either the guy with the point now understands why he's wrong (or why his point isn't practical), or the document editor says, OK, I get your point now. Let me work up some proposed text and post it to the list. Example: A few people get together during a session time they have free, and they bash out some text to resolve an issue that came up. They come to the working group meeting session with an explanation of their conversation and the proposed text, and it's discussed in the meeting session (and posted to the list afterward). Example: Someone has an idea for a new document or other new work, so he gathers some people to have breakfast one morning, explains his idea, bashes it around with his colleagues, and as a result of that breakfast chat he goes home after the IETF meeting and writes up an Internet Draft. None of this is hidden; none of this is secret. It's all the way work gets done efficiently: a small group of people crack some tough nuts, and present the results to a wider audience. I agree with Barry. That is, and always will be, the dynamic at any conference like meeting, it's a fundamental of human behavior. Equally there is nothing to stop folks gathering together for a short conference call outside IETF week to move a point forward. That also happen all the time and is something that those unable to get to meetings can do. Stewart
Re: Weekly posting summary for ietf@ietf.org
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
Re: Last Call: draft-ietf-ospf-manet-single-hop-mdr-03.txt (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
On 07/06/2013 09:23, Abdussalam Baryun wrote: Thanks for your respond below, AB Thank you Richard and Abdussalam for reaching agreement on this. I regard the issue as now closed. Regards Stewart Bryant (speaking as responsible Area Director)
Re: When to adopt a WG I-D
On 28/05/2013 15:36, Abdussalam Baryun wrote: It is difficult to read, because I am expecting a process and find something else, I started to read, but got confused (stoped reading), why you are titling it as creating WG-draft and mentioning the adoption into the document. I understand that the creating first is *individual-draft* not *WG-draft*, Incorrect, the first incarnation of a draft can be a WG draft. The only requirement is that the chairs conclude that the existence such a draft has WG consensus. the adoption happens after the creation of individual draft. If creating is WG creation, then it is already adopted as *idea* not *draft*, and then draft-00 is the WG-draft. I don't see the process clear at all, I maybe missing something, Yes you are. Stewart AB On Tue, May 28, 2013 at 10:32 AM, Adrian Farrel adr...@olddog.co.uk mailto:adr...@olddog.co.uk 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 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: IETF Diversity Question on Berlin Registration?
On 29/04/2013 01:53, Margaret Wasserman wrote: Hi Tom, On Apr 19, 2013, at 6:03 AM, t.p. daedu...@btconnect.com wrote: If we required the IETF to reflect the diversity of people who are, e.g., IT network professionals, then the IETF would fall apart for lack of ability. […] If the ADs of the IETF have to represent the diversity of the world - which could in extremes.. Has anyone even suggested that IESG should reflect the diversity of these groups? Where is this coming from? You are putting up strawmen, so that you can tear them down… The question that people are asking is why the diversity of the IETF leadership doesn't reflect the diversity of _the IETF_. The evidence seems to be that human's are terrible at guessing statistics, and the only statistics that are reliable as those objectively gathered and subjected to rigorous statistical analysis. You can often see this in human assessments of risk. It is also in the nature of statistics that you get long runs of outliers, and that only when you take a long view to you see the averages you would expect. Again Humans are terrible with this, assuming for example that a coin that comes up heads 10 times in a row the assumption is that this is bias, and not a normal statistical variation that you would expect in an infinite number of throws. Given the diversity ratios that we see, it is unclear to me whether we are observing a systematic effect or a statistical effect. It would be useful to the discussion if we could see data on diversity that was the output of a rigorous statistical analysis. i.e. one that included a confidence analysis and not a simple average in a few spot years. - Stewart
Re: IETF Diversity Question on Berlin Registration?
On 29/04/2013 05:05, Michael StJohns wrote: At 08:53 PM 4/28/2013, Margaret Wasserman wrote: The question that people are asking is why the diversity of the IETF leadership doesn't reflect the diversity of _the IETF_. Let's consider for a moment that this may not actually be the correct question. Instead, consider Why the diversity of the IETF leadership doesn't reflect the diversity of the set of the IETF WG chairs? I believe this is a more representative candidate population for the IAB and IESG. By my count (using the WG chairs picture page), there are 202 current working group chairs. Of these 15 are female - or 7.4% of the population [It would be more reliable to do this for any WG chair in the last 5-10 years, but the above was readily available and I think provides at least the basis for discussion. Anticipating the argument, I would assume for the sake of discussion a fairly similar percentage of ex-working group chairs per gender unless there is evidence to the contrary] There are 14 (current area directors plus the chair) members of the IESG, of which none are currently female. There are 12 current IAB members of which 1 member is female. Assuming perfect distribution, that would suggest that 14 * (15/202) or 1.03 IESG members should be female. Assuming perfect distribution, that would suggest that 12 * (15/202) or .89 IAB members should be female. Assuming perfect distribution, that would suggest that 26 * (15/202) or 1.93 IAB + IESG members should be female. And pretending for a moment that picks for the IAB and IESG are completely random from the candidate set of Working group chairs, the binomial distribution for 7.4% for 27 positions is: 0 - 12.5%, 1 - 27.0%, 2 - 28.1%, 3 or more - 32.5%. (e.g. about 40% of the time, the IAB and IESG combined will have 0 or 1 female members). for 7.4% for 15 positions (IESG) is: 0 - 31.4%, 1 - 37.8%, 2 - 21.2%, 3 or more - 9.5% for 7.4% for 12 positions (IAB) is: 0 - 39.6%, 1 - 38.1%, 2 - 16.8%, 3 or more - 5.4% But the actual one you should consider is 7.4% for 14 positions (annual replacement): 0 - 34%, 1 - 38.1%, 2 - 19.9%, 3 or more - 8%. This last one says that for any given nomcom selection, assuming strict random selection, 72% of the time 0 or 1 females will be selected across both the IAB and IESG. You should use this one as the actual compositions of the IAB/IESG are the sum of all the nomcom actions that have happened before. There are statistical tests to determine whether there is a statistically significant difference in populations, but my admittedly ancient memories of statistics suggest that the population size of the IAB/IESG is too small for a statistically valid comparison with either the WG chair population or the IETF population. Of course, the nomcom doesn't select and the confirming bodies do not confirm based on a roll of the dice. But looking at this analysis, it's unclear - for this one axis of gender - that the question why the diversity of the IETF leadership does not reflect the diversity of the set of IETF WG chairs has a more correct answer than the luck of the draw. My base premise may be incorrect: That you need to have been a WG chair prior to service as an IAB or IESG member. I hope it isn't as I think this level of expertise is useful for success in these bodies. Assuming it is correct, then the next question is whether or not there is a significant difference in percentage of female attendees vs percentage of female working group chairs and is there a root cause for that difference that the IETF can address in a useful manner. Mike This is in line with my own estimate based on an approximation of 1:10 which with random selection gives an error approximation of sqrt(1)=1 The other thing to remember is that whilst your proportional estimates are likely to be correct, in a random process you will get long runs of bias that only average out in the long run. So you will get long runs of 0. Very infrequently you will also get long runs of 27. In both cases it is in human nature to would assume something is wrong, when it is an artifact of random numbers. Humans have considerable difficulty discriminating between systematic and statistical problems, and taking the long view rather than the short view. For that reason, as I noted in my previous post, we need a rigorous statistical analysis with proper confidence intervals, rather than simple averages on spot years. - Stewart
Re: IETF Diversity Question on Berlin Registration?
On 29/04/2013 06:57, Dave Crocker wrote: On 4/28/2013 10:52 PM, Christian Huitema wrote: Except that the IESG members select the wg chairs, which makes your baseline stastistic suspect; it's too easy for all sorts of biasing factors to sway the allocation of wg chair positions. Mike actually mentioned that. Let's assume a simplified curriculum of participant - author/editor - WG chair - IESG, which more or less reflects increasing seniority in the IETF. We may suspect that there is bias that, at each step, privileges some candidates over others. However, the mechanisms are different at each step. Exactly. Complicated processes, needing high quality data that gets complicated analysis, that we aren't well-enough trained to do well and aren't going to be doing. Dave Of all the social mixes you would anticipate the IETF to be in the likely to do it, likely to do it correctly quadrant. Stewart
Re: IETF Diversity Question on Berlin Registration?
On 29/04/2013 20:39, Sam Hartman wrote: For what it's worth, I'm not finding the current discussion is providing me useful information for making decisions. It doesn't really matter to me whether the problem is selection of WG chairs or selection of IAB/IESG/IAOC after WG chairs are selected. I think it is valuable to attempt to improve both situations in parallel, and the sorts of conclusions being drawn from the statistical discussion we're currently having cannot possibly change my opinion on that issue. I'm not saying that my mind is closed to being changed; simply that I've considered all the possible conclusions that I think could be drawn from the analysis being considered and from my standpoint they don't affect how I'd feel about various proposals that could be brought forward. Which I guess speaks to John's point that I at least am a member of the community who doesn't think the hard statistical analysis is useful here. Sam, Why would you disregard a statistical analysis? That seems akin to disregarding the fundamentals of science and engineering. Stewart
Re: Meritocracy, diversity, and leaning on the people you know
On 19/04/2013 19:13, Ted Hardie wrote: As a working group chair, when I stare out at a sea of faces looking for a scribe, the chances of my asking someone I know produces good minutes is much higher than my asking someone whose work I don't know. Think about how this often works in WGs without a secretary or regular scribe. Chair says we need a volunteer for a scribe. Everyone looks away and sits on their hands. Chair says no scribe, no meeting. Everyone looks away and hangs their head even lower melting into the floor. Chair pleads a bit more. Silence. Chair asks someone they know since they are less likely to refuse. There maybe a refusal or two by people who expect to be at the mic a lot, or need to leave early, or are only there to catch up with their email. Eventually someone committed to the WG, and usually well known to the chairs, frequently a name called by the chair, offers to scribe in order to the meeting started. The strong temptation is to just ask one of the well known good scribes before the meeting in order not to waste time in a tight agenda. Stewart
Re: Purpose of IESG Review
On 12/04/2013 14:17, Fred Baker (fred) wrote: On Apr 12, 2013, at 12:13 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Seeing randomly selected drafts as a Gen-ART reviewer, I can say that serious defects quite often survive WG review and sometimes survive IETF Last Call review, so the final review by the IESG does serve a purpose. I'm not saying it doesn't serve a purpose. I'm saying that I know of drafts that have been nearly rewritten during such back-and-forth, so what popped out was largely unrelated to what went in. In such cases, I think the document should have been returned to the working group with comments, not worked on privately. Fred The Discusses and Comments are public, all versions of the draft are public, the authors and chairs (who are usually the shepherds) see all the review emails. Now maybe the IESG need to be more pro-active in sending drafts back to the WG, although that may also be unpopular, but if an author, shepherd or chair made that request I can think of few circumstances where an AD that would likely refuse. - Stewart
Re: Purpose of IESG Review
AB Have you considered that the key thing to remember in the IETF is that: Foo is broken because of (carefully reasoned) Bar always trumps Foo is OK because of who I am ... and of course vise versa. Thus in the IETF influence is a function of the ability to carefully construct a well reasoned technical argument rather than organizational position. Of course you have to accept that no matter how carefully reasoned your case for Bar is, your reasoning may be flawed, and if that is the case you will normally be told so, sometimes fairly bluntly, and that the NULL argument will likely be ignored as noise. - Stewart On 12/04/2013 20:24, Abdussalam Baryun wrote: How can a memebr of staff in a company argue with the manager about the manager's decisions or performance? Only Owners/shareholders can question managers and staff. IMO, the meeting/list discussions on any issue without an I-D written is the staff talking/working. If you write an I-D and to update the procedure related to the subject, you should consider many issues and I think will need many years of discussions, but then better effort result. IMHO, writing an I-D and getting back up by community discussion (with rough consensus) is in the top level and is the owner talking. I hope that when I review and comment on an I-D, it should be considered as one owner is talking, but seems like editors think they are the only owners. When IESG comment on the I-D it is managers/excutives talking. All parts are important to the best of output. AB
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
On 02/04/2013 15:28, Richard Barnes wrote: Thanks for following up, and for the re-send. Just to be clear, I do not mean these as blocking points. On the former point, I might just suggest a minor edit to the introduction: OLD: This document specifies the options for determination and selection of next-hop Ethernet MAC addressing under these circumstances. NEW: This document specifies the options for determination and selection of next-hop Ethernet MAC addressing when MPLS-TP is used in a pure Ethernet manner, without any IP forwarding capability. After various rounds of tweeking: This document specifies the options for the determination and selection of the next-hop Ethernet MAC address when MPLS-TP is used between nodes that do not have an IP dataplane. The subtly is the network may be mixed IP capable and non-IP capable. On the latter point, I can understand the desire to make the simple case simple, and the text at the end of Section 2 sends a clear warning. It does seems like GAP would also allow autoconfiguration without further NMS interaction. (Unless the NMS is configuring per-Ethernet-address policies, e.g., forward packets with this label to 00:11:22:33:44:55. Is that the case?) Yes. One case is a network that is generally NMS configured, and wants to use unicast MAC addresses, but wants to allow the craft people to plug in a new linecard without talking to the NMS. In such circumstances the only auto config would be teh MAC addresses. Stewart On Tue, Apr 2, 2013 at 9:10 AM, Stewart Bryant stbry...@cisco.com mailto:stbry...@cisco.com wrote: Resending due to Richards change of address. Stewart On 11/02/2013 23:45, Richard Barnes wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mpls-tp-ethernet- addressing-05 Reviewer: Richard Barnes Review Date: 2013-02-11 IETF LC End Date: 2013-02-18 IESG Telechat date: TBD Summary: Ready, with a couple of minor questions / clarifications. Comment: The document is mostly very clearly written. (Thanks!) It would have helped me understand if it could have been clarified up front that the mechanism in this document is intended for pure Ethernet MPLS-TP (without assumptions about layer 3+). The current introduction says as much, but in a negative way, in terms of ARP or ND not being available. I have some minor unease about the distinction that this document makes between point-to-point and multipoint links. The document correctly notes that a point-to-point link might become multipoint without either end being aware. I would have thought this would argue for using GAP in all cases, but instead the document carries on with addressing the point-to-point case separately.. Richard It is always difficult when writing a simple draft dealing with a small component of a larger technology to know how much tutorial to include, but I believe the point about operation in the absence IP would be well known to anyone implementing this. In particular we assume that anyone implementing the draft would have read the required references called up in the first paragraph of the Introduction: The MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol functions that meet the requirements [RFC5654] for the application of MPLS to the construction and operation of packet-switched transport networks. The MPLS-TP data plane consists of those MPLS-TP functions concerned with the encapsulation and forwarding of MPLS-TP packets and is described in [RFC5960]. RFC5654 says: 36 It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label. Thus I think that the text is complete as it stands and requires no further clarification for anyone that needs to consider the technology it describes. With regard to your second point, the issue that we are have, is that there are a number of deployment scenarios where the operator knows that the link is Pt-Pt, and there is a reluctance by that community to use anything other than NMS configuration. That has lead them to use Ethernet broadcast addressing which allows the crafts to change h/w without the need for reconfiguration by the NMS. Against that background moving them onto the use of a Ethernet m/c address is a step forward. To require using the GAP to that community would illustrate that the IETF is out of touch
Re: Gen-ART LC Review of draft-ietf-ospf-ospfv3-iid-registry-update-00
Alvaro Please can you add a line or two of motivation to the draft. I don't think it needs to be major text, but it will be useful to record the reason for the update to the registry. Thanks Stewart On 06/03/2013 15:05, Acee Lindem wrote: I think the draft can talk to the motivation in general terms with the embedded routing draft cited as an example. Thanks, Acee On 3/6/13 7:01 AM, Stewart Bryant stbry...@cisco.com wrote: Chairs Please can you re on the question posed by Alvaro below. Do you have any objection to adding motivation text to the draft? Certainly I think it would be useful in IESG review. Stewart On 11/02/2013 21:15, Alvaro Retana (aretana) wrote: On 1/16/13 5:17 PM, Ben Campbell b...@nostrum.com wrote: Ben: Hi! Sorry for the delay, my filters put this in a different place.. I'm explicitly adding the OSPF chairs. Comments below. 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-ospf-ospfv3-iid-registry-update-00 Reviewer: Ben Campbell Review Date: 2013-01-16 IETF LC End Date: 2013-01-24 Summary: This draft is not ready for publication as a proposed standard. There is a significant IANA registration issue described in the review body. Major issues: This draft carves out a significant part of a registry with an assignment policy of standards action for private use. It offers very little motivation for the change. In my opinion, this sort of change should come with a clear justification. Specifically, the draft modifies the OSPFv3 Address Family Instance ID registry to carve out half of the unassigned space for private use. The justification for this is a single sentence saying that some networks need to use IIDs to identify specific applications. I think that needs significant elaboration in order to motivate the change in a way that the reader can evaluate. My understanding from the OFPS list is that this is in support of draft-ietf-ospf-ipv4-embedded-ipv6-routing, which is an informational draft. I have to wonder why the draft under review was not simply the IANA considerations for that draft. I suggest one of two paths forward: 1) If this change is in support of that draft in particular, then this draft should say that, and include a _normative_ reference. I recognize the normative downref would complicate things--but I think that complication is reasonable under the circumstances. 2) If this change is to support a general need that goes beyond draft-ietf-ospf-ipv4-embedded-ipv6-routing, then this draft should describe that need in enough detail for people to think about it, perhaps with an informative reference to draft-ietf-ospf-ipv4-embedded-ipv6-routing as an _example_. In short (from the shepherd write-up): The new range is for applications that do not justify a standards track OSPFv3 Instance ID allocation. An example would be Routing for IPv4-embedded IPv6 Packets. During pre-publication review, the WG chairs asked us to not include explicit references to draft-ietf-ospf-ipv4-embedded-ipv6-routing as that is just an example and not the only potential user/driver. I don't have a problem adding an example, but I want to get agreement/comments/guidance from the chairs before adding the text. Acee/Abhay?? Minor issues: -- section 3: I don't think it's appropriate to use normative language for IANA requests. Especially not MUST. (I think the strongest thing we can do here is a polite request :-) ) I suggest recasting that to descriptive language, and removing section 2 and the RFC 2119 reference. Yes, we already removed that in the -01 version. Thanks!! Alvaro. . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first
Sent from my iPad On 6 Apr 2013, at 14:04, Abdussalam Baryun abdussalambar...@gmail.com wrote: If the date is special then thoes RFCs SHOULD be *historical*. Surely the correct requirement is : If the date is special then those RFCs MUST be *hysterical*. - Stewart
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
Resending due to Richards change of address. Stewart On 11/02/2013 23:45, Richard Barnes wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mpls-tp-ethernet-addressing-05 Reviewer: Richard Barnes Review Date: 2013-02-11 IETF LC End Date: 2013-02-18 IESG Telechat date: TBD Summary: Ready, with a couple of minor questions / clarifications. Comment: The document is mostly very clearly written. (Thanks!) It would have helped me understand if it could have been clarified up front that the mechanism in this document is intended for pure Ethernet MPLS-TP (without assumptions about layer 3+). The current introduction says as much, but in a negative way, in terms of ARP or ND not being available. I have some minor unease about the distinction that this document makes between point-to-point and multipoint links. The document correctly notes that a point-to-point link might become multipoint without either end being aware. I would have thought this would argue for using GAP in all cases, but instead the document carries on with addressing the point-to-point case separately.. Richard It is always difficult when writing a simple draft dealing with a small component of a larger technology to know how much tutorial to include, but I believe the point about operation in the absence IP would be well known to anyone implementing this. In particular we assume that anyone implementing the draft would have read the required references called up in the first paragraph of the Introduction: The MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol functions that meet the requirements [RFC5654] for the application of MPLS to the construction and operation of packet-switched transport networks. The MPLS-TP data plane consists of those MPLS-TP functions concerned with the encapsulation and forwarding of MPLS-TP packets and is described in [RFC5960]. RFC5654 says: 36 It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label. Thus I think that the text is complete as it stands and requires no further clarification for anyone that needs to consider the technology it describes. With regard to your second point, the issue that we are have, is that there are a number of deployment scenarios where the operator knows that the link is Pt-Pt, and there is a reluctance by that community to use anything other than NMS configuration. That has lead them to use Ethernet broadcast addressing which allows the crafts to change h/w without the need for reconfiguration by the NMS. Against that background moving them onto the use of a Ethernet m/c address is a step forward. To require using the GAP to that community would illustrate that the IETF is out of touch with their needs and methods of network operation. Hopefully this additional background, which I believe is well known to the MPLS-TP community to which this draft is directed, satisfies your concern on the latter point. - Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
On 11/02/2013 23:45, Richard Barnes wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mpls-tp-ethernet-addressing-05 Reviewer: Richard Barnes Review Date: 2013-02-11 IETF LC End Date: 2013-02-18 IESG Telechat date: TBD Summary: Ready, with a couple of minor questions / clarifications. Comment: The document is mostly very clearly written. (Thanks!) It would have helped me understand if it could have been clarified up front that the mechanism in this document is intended for pure Ethernet MPLS-TP (without assumptions about layer 3+). The current introduction says as much, but in a negative way, in terms of ARP or ND not being available. I have some minor unease about the distinction that this document makes between point-to-point and multipoint links. The document correctly notes that a point-to-point link might become multipoint without either end being aware. I would have thought this would argue for using GAP in all cases, but instead the document carries on with addressing the point-to-point case separately.. Richard It is always difficult when writing a simple draft dealing with a small component of a larger technology to know how much tutorial to include, but I believe the point about operation in the absence IP would be well known to anyone implementing this. In particular we assume that anyone implementing the draft would have read the required references called up in the first paragraph of the Introduction: The MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol functions that meet the requirements [RFC5654] for the application of MPLS to the construction and operation of packet-switched transport networks. The MPLS-TP data plane consists of those MPLS-TP functions concerned with the encapsulation and forwarding of MPLS-TP packets and is described in [RFC5960]. RFC5654 says: 36 It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. That is, the data plane only operates on the MPLS label. Thus I think that the text is complete as it stands and requires no further clarification for anyone that needs to consider the technology it describes. With regard to your second point, the issue that we are have, is that there are a number of deployment scenarios where the operator knows that the link is Pt-Pt, and there is a reluctance by that community to use anything other than NMS configuration. That has lead them to use Ethernet broadcast addressing which allows the crafts to change h/w without the need for reconfiguration by the NMS. Against that background moving them onto the use of a Ethernet m/c address is a step forward. To require using the GAP to that community would illustrate that the IETF is out of touch with their needs and methods of network operation. Hopefully this additional background, which I believe is well known to the MPLS-TP community to which this draft is directed, satisfies your concern on the latter point. - Stewart
Re: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T
David In this particular case the candidate pool would have been tiny, because the criteria would surely have included being experienced with both the ITU process and the IETF liaison process, including knowing and understanding the liaison history. Therefore it seems unlikely that there would be any candidate that the IAB did not already know about. So whilst I agree in general, this is not a case that should raise any concerns. Scott BTW is an excellent choice and is well qualified on all of the above counts. - Stewart (who did not take part in the selection process) On 27/03/2013 21:26, David Kessens wrote: Russ, Jari, IAB, Recently, there has been a lot of discussion in the IETF about diversity. A lot of people observed that the IETF is not good in fostering a culture that naturally promotes diversity and that is attractive for younger people to join. One way to make the IETF more accessible and approachable is to stop making appointments for open positions by recruiting only behind closed doors. I am very disappointed that the IAB again has chosen to fill a position without a clear and open call for volunteers. We can talk a long time about diversity in this community, but it is time to take concrete actions. David Kessens PS This message doesn't in any way intends to doubt Scott's skills. I am disappointed about the process used. --- On Wed, Mar 27, 2013 at 03:13:33PM -0400, IAB Chair wrote: The IAB has just notified the ITU-T that Scott mansfield will be the new IETF Liaison Manager to the ITU-T. Please congratulate Scott when you see him. He has done a good job as liaison manager for MPLS, and I am sure he will do a good job in his new role. Please thank Eliot Lear for his past service in this role. Eliot no has a seat on the IAB, and I am sure he will provide valuable support for Scott. Thanks, Russ = = = = = = = = = = Liaison Statement: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T Submission Date: 27 March 2013 From: The IAB (Russ Housley) To: ITU-T TSAG (tsbt...@itu.int) Cc: IAB i...@iab.org, The IAB Executive Director ex...@iab.org, tsbd...@itu.int tsb...@itu.int, IESG i...@ietf.org Title: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T The IAB would like to bring to the ITU-T's attention the appointment of Mr. Scott Mansfield as the new IETF Liaison Manager to the ITU-T. The IETF Liaison Manager to the ITU-T sees to the day to day aspects of the relationship with the ITU-T, provides guidance to the IESG, IAB, and the IETF as a whole on strategic matters involving both organizations. In addition, Mr. Mansfield will work closely with our other liaison managers to assure consistency of approach across technologies, as well as see that liaisons from the ITU-T to the IETF are appropriately allocated and responded to. We expect Mr. Mansfield to play a significant supporting role in strategic discussions between the IETF and ITU leadership. Mr. Scott Mansfield has over twenty of experience in software development and network management. He is a Principal Engineer in Ericsson’s DUIB Technology Network Architecture group. A long time technologist, Scott has built object-oriented workflow systems for the US Treasury Department, The United States Naval Reserve, Federal Express, and the United Parcel Service. Scott has also been the Lead Architect for Ericsson’s North American Mobile Backhaul Solutions, before moving into a position of Standards Engineer. Scott has been Ericsson’s MEF Coordinator for the past 5 years and is also an active contributor to the IETF and the ITU-T, and has been liaison manager from the IETF to ITU-T for MPLS for the past two years. The IAB thanks the outgoing Liaison Manager, Mr. Eliot Lear, for his valuable service. For the IAB, Russ Housley IAB Chair David Kessens --- . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T
That was the British use of the term unlikely. Stewart Sent from my iPad On 28 Mar 2013, at 14:05, Dave Crocker d...@dcrocker.net wrote: On 3/28/2013 6:13 AM, Stewart Bryant wrote: In this particular case the candidate pool would have been tiny, because the criteria would surely have included being experienced with both the ITU process and the IETF liaison process, including knowing and understanding the liaison history. Therefore it seems unlikely that there would be any candidate that the IAB did not already know about. Stuart, It's important that you used the word unlikely, since it underscores the legitimacy of the problem being raised: The issue is not that there probably would not have been a better choice, but the lack of certitude about it. Further, the rationale you offer essentially is one of efficiency, but open processes rarely stand the scrutiny of 'efficiency' concerns. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Diversity of IETF Leadership
On 19/03/2013 12:59, Margaret Wasserman wrote: On Mar 12, 2013, at 2:24 PM, Dan Harkins dhark...@lounge.org wrote: I'd love to get out of this rat hole. Perhaps the signatories of the open letter can restate the problem they see so it isn't made in terms of race and gender. The letter specifically mentioned the axes of race, gender, geographic location and corporate affiliation, so the letter was not only about race and gender. Other people have mentioned other pertinent axes in the e-mail discussion, such as industry segment and background/experience. I don't think it is possible for remove race and gender from the list of axes, though, since there is a notable lack of diversity in those areas. Margaret As I pointed out on an earlier thread, the relevant EU policy body, which I assume has a lot of expertise on this, defines the following protected characteristics, i.e. characteristics that you are NOT permitted to discriminate on in the EU: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. Stewart
Re: Diversity of IETF Leadership
On 20/03/2013 10:53, Margaret Wasserman wrote: Hi Stewart, On Mar 20, 2013, at 2:04 AM, Stewart Bryant stbry...@cisco.com wrote: Age Disability Gender reassignment Marriage and civil partnership Pregnancy and maternity Race Religion and belief Sex Sexual orientation The U.S. has a similar (although not identical) list, and it may vary a bit state-by-state. If we are going to have an itemized list of diversity characteristics, we should not pick and choose, we should include the full list. While I certainly wouldn't suggest we start discriminating based on _any_ of these factors, it is very difficult to measure our results in some of these areas, as we do not collect this information from IETF attendees, nor do we publish the age, disability status, gender status, marital status, religion or sexual orientation of our I* members. I am not suggesting that we start collecting or publishing this information, just saying that it makes it hard to tell whether our leadership is reasonably representative of the community in some of these areas. Also, I think there are some area where diversity is important to the IETF that are not on this list, like geographic location, corporate affiliation and industry segment (vendor, operator, researcher, etc.). Margaret . There are methods of anonymously determining the profile of the IETF in the above terms, but to preserve the anonymity of such information, and understand its statistical significance this should probably be gathered by a specialist organization outside the IETF but on our behalf. The extended list needs further review and consideration. For example, perhaps we should take a leaf from the IEEE and consider who funds work items rather than simply use current affiliation as we do today. This makes things more transparent both at the corporate and the consulting level. Stewart
Re: Diversity of IETF Leadership
A person's sex is of course only one of the recognized protected characteristics. *http://www.equalityhumanrights.com/advice-and-guidance/new-equality-act-guidance/protected-characteristics-definitions/* The full set is: Age Disability Gender ressignment Marriage and civil partnetship Pregnancy and maternity Race Religion and belief Sex Sexual orientation If we formally recognize one of the protected characteristics we surely have to formally recognize and make provision within our rules and operating procedures for all of them. Although I point to a UK site my understanding is that these protected characteristics are enacted in European Union law and thus apply across the whole of the EU. Stewart
Re: Gen-ART LC Review of draft-ietf-ospf-ospfv3-iid-registry-update-00
Chairs Please can you re on the question posed by Alvaro below. Do you have any objection to adding motivation text to the draft? Certainly I think it would be useful in IESG review. Stewart On 11/02/2013 21:15, Alvaro Retana (aretana) wrote: On 1/16/13 5:17 PM, Ben Campbell b...@nostrum.com wrote: Ben: Hi! Sorry for the delay, my filters put this in a different place.. I'm explicitly adding the OSPF chairs. Comments below. 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-ospf-ospfv3-iid-registry-update-00 Reviewer: Ben Campbell Review Date: 2013-01-16 IETF LC End Date: 2013-01-24 Summary: This draft is not ready for publication as a proposed standard. There is a significant IANA registration issue described in the review body. Major issues: This draft carves out a significant part of a registry with an assignment policy of standards action for private use. It offers very little motivation for the change. In my opinion, this sort of change should come with a clear justification. Specifically, the draft modifies the OSPFv3 Address Family Instance ID registry to carve out half of the unassigned space for private use. The justification for this is a single sentence saying that some networks need to use IIDs to identify specific applications. I think that needs significant elaboration in order to motivate the change in a way that the reader can evaluate. My understanding from the OFPS list is that this is in support of draft-ietf-ospf-ipv4-embedded-ipv6-routing, which is an informational draft. I have to wonder why the draft under review was not simply the IANA considerations for that draft. I suggest one of two paths forward: 1) If this change is in support of that draft in particular, then this draft should say that, and include a _normative_ reference. I recognize the normative downref would complicate things--but I think that complication is reasonable under the circumstances. 2) If this change is to support a general need that goes beyond draft-ietf-ospf-ipv4-embedded-ipv6-routing, then this draft should describe that need in enough detail for people to think about it, perhaps with an informative reference to draft-ietf-ospf-ipv4-embedded-ipv6-routing as an _example_. In short (from the shepherd write-up): The new range is for applications that do not justify a standards track OSPFv3 Instance ID allocation. An example would be Routing for IPv4-embedded IPv6 Packets. During pre-publication review, the WG chairs asked us to not include explicit references to draft-ietf-ospf-ipv4-embedded-ipv6-routing as that is just an example and not the only potential user/driver. I don't have a problem adding an example, but I want to get agreement/comments/guidance from the chairs before adding the text. Acee/Abhay?? Minor issues: -- section 3: I don't think it's appropriate to use normative language for IANA requests. Especially not MUST. (I think the strongest thing we can do here is a polite request :-) ) I suggest recasting that to descriptive language, and removing section 2 and the RFC 2119 reference. Yes, we already removed that in the -01 version. Thanks!! Alvaro. . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: Appointment of a Transport Area Director
On 03/03/2013 14:25, Brian E Carpenter wrote: Clearly the NomCom felt it was between a rock and a hard place; I just want to assert the principle that balancing both managerial and technical abilities is within NomCom's remit. Brian There is a subtly in the manager vs technical expert debate that is worth noting. There are some technical managers who could do the job by leveraging the use of experts and coming up to speed on the key issues very quickly. However I would suggest that they are at least as rare and certainly at least as valuable to their employers as technical experts pool that we normally draw on. The level of competence needed would put such managers on a xVP or C* trajectory, and it seems to me that they are likely to be even more reluctant to take a career gap than the academic community. So it's not that the managers concept does not work, it's that it is even harder to identify them with some degree of certainly and then recruit the ones that the IETF would need. - Stewart
Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]
Speaking as both a reviewer and an author, I would like to ground this thread to some form of reality. Can anyone point to specific cases where absence or over use of an RFC2119 key word caused an interoperability failure, or excessive development time? - Stewart
Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]
Indeed an interesting additional question. My view is that you MUST NOT use RFC2119 language, unless you MUST use it, for exactly that reason. What is important is on the wire (a term that from experience is very difficult to define) inter-operation, and implementers need to be free to achieve that though any means that suits them. - Stewart On 07/01/2013 12:22, John Day wrote: As you are guessing that is unlikely, however, the more pertinent question is whether it has prevented some innovative approach to implementations. This would be the more interesting question. We tend to think of these as state machines and describe them accordingly. There are other approaches which might be prevented if using a MUST when it wasn't needed. At 10:53 AM + 1/7/13, Stewart Bryant wrote: Speaking as both a reviewer and an author, I would like to ground this thread to some form of reality. Can anyone point to specific cases where absence or over use of an RFC2119 key word caused an interoperability failure, or excessive development time? - Stewart . -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: WCIT outcome?
On 02/01/2013 13:44, Carlos M. Martinez wrote: Radio spectrum allocation was a critical task at the time (it still is, although the world doesn't depend that much on it anymore), and one of the task the ITU actually has performed very well, being a positive and constructive player. I don't know if it's true, but I've read in the past that one of the first events that brought up the need for spectrum regulation, and thus ushered in the role of the ITU in it was the Titanic disaster. Yes, there was chaos until the CCIR (ITU-R) process of international radio regulation came into being. However it remains to be seen what will happen as the various computerized dynamic forms of frequency co-ordination (in all their forms) replace the essentially static frequency co- ordination method that has prevailed over the past 100 years, and as SDR deployment allows radios to use more dynamic/ agile waveforms than were the possible up until quite recently. Just as the Internet has challenged the ITU-T model of operation, the computerization of radio (with the help of the Internet) will to some degree or other challenge the ITU-R model of operation. - Stewart
Re: Idea for a process experiment to reward running code...
On 01/12/2012 20:12, Stephen Farrell wrote: Hi all, I've just posted an idea [1] for a small process improvement. If it doesn't seem crazy I'll try pursue it with the IESG as an RFC 3933 process experiment. If its universally hated then that's fine, it can die. The IESG have seen (more-or-less) this already but it hasn't be discussed, so this is just a proposal from me and has no official status whatsoever. Any comments, suggestions or better ideas are very welcome. Feel free to send me comments off list for now, or on this list I guess. If there's loads of email (always possible, this being a process thing;-) we can move to some other list. Regards, Stephen. [1] http://tools.ietf.org/id/draft-farrell-ft I find this a worrying proposal. In the just-in-time world that we live in, too much of the review is already tail driven. Reducing the time that people have to notice that a doc is up for final review and then clear enough time in their calendar against a myriad of other tasks makes it more likely that the quality of review will diminish and hence the quality of our documents will diminish. I would hate for us to act like an SDO that regards publication milestones as crucial and ship the draft regardless of the state of the technical design. I would also note that sometimes it just takes time during review to mull over the full implications of the design and to surface the issues. With the current scheme if you miss a problem in WGLC, you can raise it during IETF LC. - Stewart
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 07/09/2012 07:49, Eliot Lear wrote: An I-D will only be removed from the public I-D archive in compliance with a duly authorized court order. Would An I-D will only be removed from the public I-D archive if legally required to do so. fix the ambiguity? Stewart
Re: [IAB] Last Call: Modern Global Standards Paradigm
Dave If I interpret what you seem to be saying, it is that you care more for the micro-observance of IETF protocol, than taking steps to avoid Internet governance being transferred by government decree to a secretive agency of the UN that runs by government majority. Is that a correct assessments of your priorities? Stewart
Re: [MARKETING] Re: VS: Re: [IAB] Last Call: Modern Global Standards Paradigm
On 11/08/2012 16:20, Brian E Carpenter wrote: When the goal is agreed wording between several organisations, and it seems clear that the two chairs are representing the ethos of the IETF in the discussion, I don't see how we can reasonably ask for more in the time available. Brian +1 Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: Updating RFC2119
On 22/07/2012 17:26, Melinda Shore wrote: On 7/22/12 3:17 AM, Abdussalam Baryun wrote: IF x, THEN y: ELSE: ELSE IF: Please send your comments or advise, thanking you, Yes: you might try to explain what problem you think you're solving. Melinda Preferable with a list of RFC text snippets that would have been more readable if these keywords had been used. Stewart
Fwd: Re: [Idr] Last Call: draft-ietf-idr-rfc4893bis-06.txt (BGP Support for Four-octet AS Number Space) to Proposed Standard
FYI Copying to IETF list as this is an IETF LC Stewart Original Message Subject: Re: [Idr] Last Call: (BGP Support for Four-octet AS Number Space) to Proposed Standard Date: Tue, 12 Jun 2012 15:54:55 +0200 From: Claudio Jeker cje...@diehard.n-r-g.com To: Stewart Bryant stbry...@cisco.com CC: i...@ietf.org On Tue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote: On 01/06/2012 23:00, Claudio Jeker wrote: On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote: The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'BGP Support for Four-octet AS Number Space' draft-ietf-idr-rfc4893bis-06.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-15. 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 Autonomous System (AS) number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893. Just for the sake of clarity, OpenBGPD will not do the following: In addition, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute of an UPDATE message. A NEW BGP speaker that receives these path segment types in the AS4_PATH attribute of an UPDATE message from an OLD BGP speaker MUST discard these path segments, adjust the relevant attribute fields accordingly, and continue processing the UPDATE message. This case SHOULD be logged locally for analysis. There is no point to do this fiddeling instead we will treat this like any other parse error of AS4_PATH. Claudio Since this is in last call, I have to ask whether you have objection to the publication of the above text, or have any proposed text changes? I see no reason to enforce AS_CONFED_SEQUENCE and AS_CONFED_SET stripping on all AS4 implementations. It forces bgp implementations that don't have confederation support to strip out something that will cause an error in the regular path and for those systems ignoring the AS4_PATH attribute is perfectly fine. I do not understand how a workaround needs to be a MUST for something that is a MUST NOT at the same time? Why MUST we workaround something that MUST NOT appear? Why do we need to add extra code that is hard to test and maybe cause for further errors because it modifies attributes in very uncommon way? I propose to remove that paragraph entierly since it does only add complexity to the protocol for no reason and therefor is only a source of errors without any benefit. -- :wq Claudio
Re: Gen-ART LC Review of draft-ietf-pwe3-static-pw-status-10
On 26/04/2012 23:55, Ben Campbell 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: (Proposed RFC 6478) (was draft-ietf-pwe3-static-pw-status-10) Reviewer: Ben Campbell Review Date: 2012-04-26 IETF LC End Date: 2012-04-30 Note: This draft has previously been approved as RFC 6478, but I understand we are last calling it again due to some material changes in AUTH48. Therefore this is a review of the diff between revision 10 and the text at http://www.rfc-editor.org/authors/rfc6478.txt Summary: The edited text is essentially ready for publication, but I have a couple of minor issues that might should be considered first. Major issues: None Minor issues: -- 5.3, last paragraph: The last sentence changed from a non-normative statement to This SHOULD cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. Is that really intended as a normative statement, or a statement of fact? I suspect it's the latter, but if the former, then it should be stated more of the form If the sending PE receives ... it SHOULD stop ... -- IANA considerations: Maybe I missed it, but I don't see a registration policy for adding things to the new registry. This wasn't an AUTH48 change, but it should probably be there. Hi Ben Thank you for your review. The IANA policy is stated as IETF Review (end of first para in IANA) The normative text is deliberate - this was part of the change that we needed to make. - Stewart
Re: [nvo3] Key difference between DCVPN and L2VPN/L3VPN
On 25/04/2012 14:57, Marshall Eubanks wrote: A question in line. On Wed, Apr 25, 2012 at 6:01 AM, Adrian Farreladr...@olddog.co.uk wrote: Hi Linda, Respect your advice. However, some wording in the proposed charter are too ambiguous, is it the intent? For example: An NVO3 solution (known here as a Data Center Virtual Private Network (DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs to several million VMs running on greater than 100K physical servers. Do you mean one VPN across a scaling range of million VMs? or many VPNs combined to scale range of million VMs? I don't find the text ambiguous at all. You might disagree with what it says (a VPN), but you can't claim it is ambiguous. Another example: NVO3 will consider approaches to multi-tenancy that reside at the network layer rather than using traditional isolation mechanisms that rely on the underlying layer 2 technology (e.g., VLANs) network layer can mean different things to different people. Why not simply say NV03 will consider approaches to multi-tenancy which do not rely on Layer 2 VLANs? There are also layers above the network layer. The charter rules them out of scope. This is good. Stewart has clarified that network layer includes IP and MPLS, and that it is the bit of the hourglass that we all know as the network layer. The charter talks about The NVO3 WG will determine which types of service are needed by typical DC deployments (for example, IP and/or Ethernet). I generally think of Ethernet as being Layer 2. Does this charter envision Ethernet as being part of the network layer? What was intended with having it mentioned there? Regards Marshall Hi Marshall The client VMs *may* need to talk Ethernet to their peers, but it is intended that VPNs that convey the client packets will run over the network layer i.e. IP and or MPLS. Stewart
WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update
This version of the NVO3 charter reflects the discussions on the list and comments received as of this afternoon. I propose to take this to the IESG for their second review tomorrow. Stewart == NVO3: Network Virtualization Over Layer 3 Chairs - TBD Area - Routing Area Director - Stewart Bryant INT Area Adviser - TBD OPS Area Adviser - TBD Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized hosts known as virtual machines (VMs). Three key requirements needed to support multi-tenancy are: o Traffic isolation, so that a tenant's traffic is not visible to any other tenant, and o Address independence, so that one tenant's addressing scheme does not collide with other tenant's addressing schemes or with addresses used within the data center itself. o Support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network. An NVO3 solution (known here as a Data Center Virtual Private Network (DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs to several million VMs running on greater than one hundred thousand physical servers. It thus has good scaling properties from relatively small networks to networks with several million DCVPN endpoints and hundreds of thousands of DCVPNs within a single administrative domain. A DCVPN also supports VM migration between physical servers in a sub-second timeframe. Note that although this charter uses the term VM throughout, NVO3 must also support connectivity to traditional hosts e.g. hosts that do not have hypervisors. NVO3 will consider approaches to multi-tenancy that reside at the network layer rather than using traditional isolation mechanisms that rely on the underlying layer 2 technology (e.g., VLANs). The NVO3 WG will determine which types of connectivity services are needed by typical DC deployments (for example, IP and/or Ethernet). NVO3 will document the problem statement, the applicability, and an architectural framework for DCVPNs within a data center environment. Within this framework, functional blocks will be defined to allow the dynamic attachment / detachment of VMs to their DCVPN, and the interconnection of elements of the DCVPNs over the underlying physical network. This will support the delivery of packets to the destination VM within the scaling and migration limits described above. Based on this framework, the NVO3 WG will develop requirements for both control plane protocol(s) and data plane encapsulation format(s), and perform a gap analysis of existing candidate mechanisms. In addition to functional and architectural requirements, the NVO3 WG will develop management, operational, maintenance, troubleshooting, security and OAM protocol requirements. The NVO3 WG will investigate the interconnection of the DCVPNs and their tenants with non-NVO3 IP network(s) to determine if any specific work is needed. The NVO3 WG will write the following informational RFCs, which must have completed Working Group Last Call before rechartering can be considered: Problem Statement Framework document Control plane requirements document Data plane requirements document Operational Requirements Gap Analysis Driven by the requirements and consistent with the gap analysis, the NVO3 WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable. Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for non-IETF protocols. If the WG anticipates the adoption of the technologies of another SDO, such as the IEEE, as part of the solution, it will liaise with that SDO to ensure the compatibility of the approach. Milestones: Dec 2012 Problem Statement submitted for IESG review Dec 2012 Framework document submitted for IESG review Dec 2012 Data plane requirements submitted for IESG review Dec 2012 Operational Requirements submitted for IESG review Mar 2013 Control plane requirements submitted for IESG review Mar 2013 Gap Analysis submitted for IESG review Apr 2013 Recharter or close Working Group
Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update
Does deleting IETF in the following sentence: Any documented solutions will use existing IETF protocols if suitable. satisfy your concerns? - Stewart
Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update
Those were my thoughts when the text was written. Stewart On 26/04/2012 00:57, david.bl...@emc.com wrote: Joe and Pat, I'm less concerned about this - I think the words if suitable regarding use of existing IETF protocols are sufficient to support choosing the best solution whether it comes from IETF or elsewhere. As Pat notes: when the time comes, we will debate what is suitable anyway. I agree that such a debate is inevitable. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.comMobile: +1 (978) 394-7754 -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Joe Pelissier (jopeliss) Sent: Wednesday, April 25, 2012 7:35 PM To: n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25- Apr-2012 update I too am uncomfortable with the wording regarding the IETF protocols. It seems that we should be striving to choose the best technical solution regardless of whether its an IETF protocol or that from another SDO. This can, and should, be covered as part of the gap analysis. Also, we should give preference to using existing suitable protocols (IETF or from other SDOs) over development of new protocols. Regards, Joe Pelissier -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Pat Thaler Sent: Wednesday, April 25, 2012 5:55 PM To: Stewart Bryant (stbryant); n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update Stewart, The charter is looking pretty good. I'd like to get on to the next phase, but not with this text: Driven by the requirements and consistent with the gap analysis, the NVO3 WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable. Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol. There are two issues with this: Is now the right time to be defining the boundaries on what we might request being chartered next? Framework, requirements and gap analysis drafts are still to be written. If we get to the end and find we need something other than or in addition to a data plan encapsulation or control plane protocol, would we not request it to be chartered? Surely once the work is done. Secondly, as this text got rewritten, it gives a preference for IETF protocols over other protocols even if they are standards. There is a part of the work where an IEEE 802.1 protocol, VDP, may turn out to be suitable. Obviously any IETF protocols that are also suitable should be considered but not to the exclusion of consideration for an IEEE protocol. Presumably there is always a preference for using existing protocol if suitable rather than inventing new. It seems unnecessary to state that - when the time comes, we will debate what is suitable anyway. Therefore, at least Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for a non-IETF protocol. should be deleted. Regards, Pat -Original Message- From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, April 25, 2012 2:39 PM To: n...@ietf.org; i...@ietf.org Cc: IETF Discussion Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update This version of the NVO3 charter reflects the discussions on the list and comments received as of this afternoon. I propose to take this to the IESG for their second review tomorrow. Stewart == NVO3: Network Virtualization Over Layer 3 Chairs - TBD Area - Routing Area Director - Stewart Bryant INT Area Adviser - TBD OPS Area Adviser - TBD Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized hosts known as virtual machines (VMs). Three key requirements needed to support multi-tenancy are: o Traffic isolation, so that a tenant's traffic is not visible to any other tenant, and o Address independence, so that one tenant's addressing scheme does not collide with other tenant's addressing schemes or with addresses used within the data center itself. o Support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC
Re: SIDR WG Virtual Interim Meeting, March 24, 2012
Ted I knew that SIDR was planning to hold this meeting. The SIDR WG currently needs more interaction time than can be accommodated within IETF week. I verified with a number of IESG colleagues that holding a meeting adjacent to an IETF meeting was within the guidelines. The important point is that it is an addition and not a replacement for a normal IETF WG meeting. Any outcome from the interim (together with the results of their previous interim) will be reported at the start of the SIDR WG session later that week in Paris. As a VM the WG Chairs can call this provided they give two weeks notice to the appropriate lists. Two weeks notice was given on the SIDR list. I accept the chairs explanation that the failure to copy iesg-secret...@ietf.org was a genuine emailing error, and that they had intended to follow correct procedure. No one raised any concerns on the SIDR list to the meeting when it was announced. It is my view that the meeting is useful in progressing the SIDR work and that despite the procedural error by the SIDR Chairs the VM should go ahead as planned. Stewart On 15/03/2012 23:50, Ted Hardie wrote: Is this date right? The SIDR working group has decided to hold a virtual interim meeting the day before the IETF, when it is holding a working group meeting four days later on the 28th? And it is announcing this 9 days before the event? If this date is correct, this seems to violate both the summary guidance at http://www.ietf.org/meeting/interim-meetings.html and both the letter and the spirit of http://www.ietf.org/iesg/statement/interim-meetings.html . Many, many people (including me) have booked travel that runs over this time period, and they cannot thus make even a virtual interim meeting. Explanation please? thanks, Ted Hardie On Thu, Mar 15, 2012 at 4:39 PM, IESG Secretaryiesg-secret...@ietf.org wrote: The co-chairs have arranged a virtual meeting for Mar 24, 2012. As per process, an agenda will be announced by one week before the event. This is scheduled for a full day - we will use this experience to gauge future meetings. --Sandy, speaking as wg co-chair From: messen...@webex.com [messen...@webex.com] Subject: Invitation to Web seminar: Virtual meeting - Mar 2012 Hello, Secure Inter-Domain Routing Working Group invites you to attend a Web seminar using WebEx. Topic: Virtual meeting - Mar 2012 Host: Secure Inter-Domain Routing Working Group Date and Time: Saturday, March 24, 2012 8:00 am, GMT Time (London, GMT) Event number: 648 807 999 Event password: VIRTUAL --- To join the online event --- 1. Click here to join the online event. Or copy and paste the following link to a browser: https://ietf.webex.com/ietf/onstage/g.php?d=648807999t=aEA=sandra.murphy%40sparta.comET=49da78014cc5d3aacc1a55e34a2cff7dETR=75b14f07e621faef30fd3542aeaa8773RT=MiMxMQ==p 2. Click Join Now. --- To join the teleconference only --- Call-in toll number (US/Canada): +1-408-600-3600 Access code: 648 807 999 --- For assistance --- You can contact Secure Inter-Domain Routing Working Group at: sidr-cha...@tools.ietf.org The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/onstage/systemdiagnosis.php http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Re: Last Call:draft-betts-itu-oam-ach-code-point-03.txt(Allocationof an Associated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC
On 16/03/2012 08:46, t.petch wrote:
- Original Message -
From: Stewart Bryantstbry...@cisco.com
To: Fangyu Lifangyuli1...@gmail.com
Cc:lif...@catr.cn;ietf@ietf.org
Sent: Wednesday, March 14, 2012 4:53 PM
On 14/03/2012 13:36, Fangyu Li wrote:
I support the allocation of an ACH codepoint to G.8113.1.
For G.8113.1 had reached the technical and industry maturity to be
assigned a code point, the codepoint allocation from IETF should allow
the ITU-T to progress refinements to G.8113.1 such that it could
satisfy all the functional requirements defined in RFC 5860.
Please can you tell me version of the G.8113.1 text one would
need to implement to be able to seamlessly interwork with the
equipment that has already been been deployed?
Stewart
I am sure you already know the answer to that from posts made to the mpls list,
where we have been told that there is currently an extensive deployment
('running code') using an experimental value (interesting that there is a last
call just ending seeking to exterminate such practice, at least for application
protocols) and that the wish is to move to a standards-based value which will,
perforce, be a different value.
Tom Petch
Tom,
I don't think you understood my question.
There are several version of the G.8113.1 text in circulation within
the ITU-T. I was asking which version accurately describes the
deployed protocol.
I would be interested to also know what ACh Type it is actually running
on.
Stewart
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
On 14/03/2012 13:36, Fangyu Li wrote: I support the allocation of an ACH codepoint to G.8113.1. For G.8113.1 had reached the technical and industry maturity to be assigned a code point, the codepoint allocation from IETF should allow the ITU-T to progress refinements to G.8113.1 such that it could satisfy all the functional requirements defined in RFC 5860. Please can you tell me version of the G.8113.1 text one would need to implement to be able to seamlessly interwork with the equipment that has already been been deployed? - Stewart
Fwd: Last Call: draft-ietf-pwe3-pw-typed-wc-fec-03.txt (LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements) to Proposed Standard
FYI MPLS and L2VPN WGs. Stewart Original Message Subject: Last Call: (LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements) to Proposed Standard Date: Wed, 07 Mar 2012 08:33:04 -0800 From: The IESG iesg-secret...@ietf.org Reply-To: ietf@ietf.org To: IETF-Announce ietf-annou...@ietf.org CC: p...@ietf.org The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements' draft-ietf-pwe3-pw-typed-wc-fec-03.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 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 The Typed Wildcard Forwarding Equivalence Class (FEC) Element defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ballot/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
Authors There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment: In section 10 you say: This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' draft-ietf-pwe3-redundancy-bit-06.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 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 describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ 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 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PWE3] Last Call: draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard
It cannot be an erratum. An erratum indicated an error a the time of writing and that is clearly not the case. Is the text For example, the PW Preferential Forwarding status state machine as defined in [RFC (this document)] is in state STANDBY. actually in the MIB definition itself? If so it's an update to the MIB (as explained in the draft). If not then why not simply explain the event's action on the MIB and not update the MIB itself? - Stewart On 07/03/2012 19:31, Thomas Nadeau wrote: After looking over this just now - and forgive me as I didn't realize it contained a reference to 5542 until now - it seems to me that rather that including this in the RFC as an update to RFC5542, this be added as an errata entry to 5542. It seems odd to me to note that the single sentence represented here updates the RFC version, when what it does is really clarify it based on the new behavior outlined in the redundancy-bit draft, and even then clarify is difficult to use since it is more of an example of such a case of a 'dormant' interface. --Tom On Mar 7, 2012, at 12:49 PM, Aissaoui, Mustapha (Mustapha) wrote: Ooops. Thank you for pointing this out Stewart. I will make the update and publish a new revision. Mustapha. -Original Message- From: Stewart Bryant [mailto:stbry...@cisco.com] Sent: Wednesday, March 07, 2012 12:48 PM To: draft-ietf-pwe3-redundancy-...@tools.ietf.org Cc: ietf@ietf.org; p...@ietf.org Subject: Re: Last Call:draft-ietf-pwe3-redundancy-bit-06.txt (Pseudowire Preferential Forwarding Status Bit) to Proposed Standard Authors There was on point that I notice that you did not address from the AD review and so I am picking it up as a LC comment: In section 10 you say: This document makes the following update to the PwOperStatusTC textual convention in RFC5542 [8]: This update should be recorded in the metadata (top left front page) and it is usual to put a one line note in the abstract. Stewart On 07/03/2012 17:00, The IESG wrote: The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudowire Preferential Forwarding Status Bit' draft-ietf-pwe3-redundancy-bit-06.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 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 describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/ballot/ 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 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ pwe3 mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
On 01/03/2012 18:28, John C Klensin wrote: --On Thursday, March 01, 2012 13:02 -0500 Russ Housley hous...@vigilsec.com wrote: Loa: Right now, there is no ITU-T approved document to reference. I am certainly not an expert on ITU-T process, but my understanding is that earliest that we could see an approved G.8113.1 is December 2012. My point is that we don't want to assign a code point until the ITU-T approves their document. However, if we are willing to assign a code point to G.8113.1 once it is approved, then this would be an approach where the code point assignment would block on the approval of the normative reference. I like this approach from the political point of view. With this approach the IETF tells the ITU-T that if and only if they are able to achieve consensus on G.8113.1, then a code point will be assigned. FWIW, this seems entirely appropriate to me. If we do it this way, I think it is important to note --for the benefit of those more historically involved with the ITU and others-- that we routinely block our own documents on normative references to work that is still in progress and, usually, do not do related code point allocations until the blocking referenced documents are ready. Once the present I-D is judged to be sufficiently ready, this approach would therefore be IETF approval and a formal guarantee to the ITU that a code point will be allocated if an when G.8113.1 is approved and published, but not assignment of that code point until the referenced base document is finished. Completely normal procedurally. john To be clear John our normal requirement would be that the technical community achieved consensus that the base document was ready. I have never seen ITU-T consensus on the contents of G.8113.1 at any meeting that I have observed. What in your view is the criteria for determining that G.8113.1 has achieved consensus? Stewart ___ 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
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 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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 Surely you agree with me that the primary consideration is that we should do what what we collectively believe is best for the Internet in the long term? There are many cases where the IETF has been presented with an existing implementation, but the collective view is that the pre-standards implementation is NOT RECOMMENDED for deployment going forward. Draft spercher-mpls-tp-oam-considerations raises a number of concerns with the deployment of the proposal that underlines draft-betts-itu-oam-ach-code-point, which surely need to be taken into consideration. - Stewart On 27/02/2012 03: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 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PWE3] FW: 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
PWE3 WG Please see the note further down the thread requesting that any discussion take place on ietf@ietf.org Stewart On 27/02/2012 14:27, Stewart Bryant wrote: My understanding is that the Recommendation called up by this draft proposes this as a new OAM be used for PWs. I do not think that PWE3 has considered the implications of adding this OAM in a PW context. - Stewart On 22/02/2012 15:16, Adrian Farrel wrote: Hi PWE3 WG, You will want to be aware of this IETF Last Call. Please send any comments as per the instructions for IETF Last Call (i.e., see below) and not to the MPLS mailing list. Thanks, Adrian -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 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Auth48 comments on draft-ietf-pwe3-static-pw-status-10
Having spoken to a number of the authors at length I think the text changes that Matthew has proposed are correct (with Greg's change) and thank the authors for picking this up. I propose to let this sit until a week tomorrow (23/Feb) and provided that there are no technical issues with the proposed changes I will ask the RFC Editor to make the changes and to publish the RFC. - Stewart On 16/02/2012 10:02, Bocci, Matthew (Matthew) wrote: Greg, That is fine with me. Best regards Matthew On 15/02/2012 22:14, Gregory Mirsky gregory.mir...@ericsson.com mailto:gregory.mir...@ericsson.com wrote: Dear Matthew, Authors, et al., I think that new text of fourth para in Section 5.3 adds some confusion. If intension is to stop sending 'all clear' after three one-second intervals went unacknowledged but before refresh timer expires then perhpas new text can be more explicit: NEW: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, transmission will cease after 3 PW status messages have been sent/_at one second intervals and before refresh timer expires_/. A PW status message of zero MAY be acknowledged as per the procedures described in Section 5.3.1. If it is acknowledged, then a timer value of zero MUST be used. This SHOULD cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. Regards, Greg *From:* pwe3-boun...@ietf.org mailto:pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] *On Behalf Of *Bocci, Matthew (Matthew) *Sent:* Wednesday, February 15, 2012 7:10 AM *To:* p...@ietf.org mailto:p...@ietf.org; ietf@ietf.org mailto:ietf@ietf.org *Cc:* pwe3-cha...@tools.ietf.org mailto:pwe3-cha...@tools.ietf.org; Stewart Bryant *Subject:* [PWE3] Auth48 comments on draft-ietf-pwe3-static-pw-status-10 During Auth 48, the authors of draft-ietf-pwe3-static-pw-status found some issues with the acknowledgement procedures in Section 5.3 of the draft that we feel should be addressed before publication. Since the draft has already been through WG and IETF last call, we would like to highlight the proposed changes to the working group and solicit feedback. Best regards, Matthew Section 5.3, 3rd paragraph: Reason for change: The current suggested default refresh timer value is too short to allow scaling to very large numbers of PWs while minimising the overhead. It is also inconsistent with the suggested default requested in an ACK packet. Therefore we suggest increasing the default to 600secs. OLD: The suggested default value for the refresh timer is 30 seconds. NEW: The suggested default value for the refresh timer is 600 seconds. Section 5.3, 4th paragraph: Reason for change: The current text requires that a receiving PE must acknowledge a PW status message of 'clear all faults' in order to force a transmitter to stop sending PW status messages at 1 second intervals. We are concerned that a mandatory acknowledgement adds an unnecessary complexity to the protocol which is inconsistent with the use of the acknowledgement as per the following section (5.3.1). Additionally, we are also concerned that this may cause problems if a transmitter is flapping between 'clear all faults' and a non-zero value, and if the acknowledgement is lost. We therefore suggest that the acknowledgement to 'clear all faults' be made optional, and that the transmitter behavior be changed so that it sends up to 3 status messages of zero in a row, and then goes silent. OLD: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, it MUST be acknowledged with a packet with a timer value of zero. This will cause the PE sending the PW status notification message with a PW status code equal to zero to stop sending and to continue normal operation. NEW: To clear a particular status fault, the PE need only send an updated message with the corresponding bit cleared. If the PW status code is zero, the PW OAM message will be sent like any other PW OAM status message using the procedures described above; however, transmission will cease after 3 PW status messages have been sent. A PW status message of zero MAY
draft-ietf-sidr-rpki-rtr-24.txt
I believe that version 24 addresses all of the actionable comments that the authors have received and I propose to continue with the publication process by requesting IESG review. Stewart Original Message Subject:Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-24.txt Date: Thu, 12 Jan 2012 17:33:22 -0800 From: Randy Bush ra...@psg.com To: internet-dra...@ietf.org CC: s...@ietf.org this draft a result of helpful security and routing ad reviews Title : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename: draft-ietf-sidr-rpki-rtr-24.txt Pages : 25 Date: 2012-01-12 and the tasty bit tools neglects to tell the wg Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-24 randy ___ sidr mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/sidr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Errata against RFC 5226 rejected
On 08/12/2011 18:51, Russ Housley wrote: Errata 2684 was entered against RFC 5226, Guidelines for Writing an IANA Considerations Section in RFCs. After discussion with one of the RFC authors and IANA staff, I rejected the errata. The errata author is saying that in many registries, there are no unreserved values. For registries where there are a finite number of entries possible, the unreserved has a clear meaning. For registries with an unbounded number of potential entries (such as media-types), the errata author is claiming that the unreserved label does not make sense. I'd like to know what others think about this errata. Russ The text is in an etc sequence, and in some cases unreserved may be appropriate, although some other notation may be appropriate and the text makes it clear that a term that is appropriate to the registry may be used. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Errata against RFC 5226 rejected
On 08/12/2011 19:18, Barry Leiba wrote: Errata 2684 was entered against RFC 5226, Guidelines for Writing an IANA Considerations Section in RFCs. After discussion with one of the RFC authors and IANA staff, I rejected the errata. The errata author is saying that in many registries, there are no unreserved values. For registries where there are a finite number of entries possible, the unreserved has a clear meaning. For registries with an unbounded number of potential entries (such as media-types), the errata author is claiming that the unreserved label does not make sense. First, Thomas, in his response, is addressing the wrong errata report. 2715 is a report submitted by Mykyta that makes reference to Julian's report (2684). The latter is the one that Russ has rejected. The former is still in reported status. I agree with Thomas that the SHALL changes in 2715 are unnecessary, but that's not what Russ is asking about. Russ, you talk about unreserved, but never mention the word that Julian is asking to have removed, unassigned, which is not the same thing. Do registries explicitly need to *list* the entries that are *unassigned*? As he says, this makes no sense for registries with unlimited (or even very many) possible entries. Even for those with a small number, the value is questionable. For example, suppose we had a registry of three-bit unsigned integer values, and we said the initial registry looked like this: 0 - reserved 1 - blue 2 - red 3 - purple 4 - private use 5 - reserved 6 - unassigned 7 - unassigned That would indicate that 6 and 7 are available for future assignment. But so would this: 0 - reserved 1 - blue 2 - red 3 - purple 4 - private use 5 - reserved In the case of this hypothetical registry, with eight possible values, there might be some use in explicitly saying that 6 and 7 are currently unassigned. But even extending this a little, if it were a four-bit integer field we'd now be listing ten values as unassigned. Make it six bits, and it's just plain silly. Julian's right about that. That said, the best I can see for this report is held for document update. It's one of those things that's not worth spending time on, and, as Thomas says, the should language makes it fine as it is. Barry In a small registry like this, it is useful to have something in the box in the table that makes it less likely that the value will be squatted on. In the above example it is clearer in the 0..7 case that there are only two free values and I will need a real good use case. In the 0..5 case, someone might be more tempted to say, they are only using up to 5 I will take 6 and hope no one notices. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt
Adrian It is the opinion of the document shepherd that discussion of this document on the working group lists would be a distraction from the technical protocol work that the working groups need to do. I disagree with the document shepherd in his evaluation. The draft clearly sets out to enable the standardization of an additional OAM for MPLS, and as such the MPLS WG need to review the document and its references to determine the consequences of the technology being deployed. Furthermore, all MPLS documents that have so far requested ACH codepoints have I believe been standards track. Why is this not also a standards track document? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt
On 02/12/2011 13:29, t.petch wrote: Original Message - From: Thomas Nadeautnad...@lucidvision.com To: Huub helvoorthuub.van.helvo...@huawei.com Cc: Adrian Farreladr...@olddog.co.uk; draft-betts-itu-oam-ach-code-po...@tools.ietf.org; The IESG iesg-secret...@ietf.org;Ietf@ietf.org Sent: Friday, December 02, 2011 2:40 PM I disagree with the document shepherd's evaluation of this document. This document sets out to standardize an additional code point to support a type of OAM for MPLS, and as such the MPLS WG must review the document for technical correctness. As far as I understand things, all MPLS documents that have requested ACH code points to-date have been on the standards track with MPLS expert WG review, and so this one should as well. I don't doubt the history, but IANA gives a policy of IETF Consensus (referencing [RFC4385]) which is defined as IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). [RFC2434] If Standards Action had been the intention, then the WG should have said so in RFC4385. Tom Petch --Tom You are correct Tom that SA is not required by the registry policy. However the observation is that all other documents that have requested an ACH have been SA, and the question is hence whether the contents of this document are such that it also needs to be SA. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 30/11/2011 05:46, Mark Andrews wrote: In messagem2r50q42nn.wl%ra...@psg.com, Randy Bush writes: skype etc. will learn. This does prevent the breakage it just makes it more controlled. What's the bet Skype has a patched released within a week of this being made available? Aren't there a whole lot of other user gadgets that also need to work their way round this? Dyndns perhaps? How about some of the home VPN packages? Will remote desktop continue to work? The list looks large in the draft, but just how large is it in reality? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
On 28/11/2011 19:38, Marshall Eubanks wrote: Dear Sam; Wearing no hats. This is my own personal take on matters. Also, I am not a lawyer, and this is not legal advice. Please note that I, personally, do not think that this will be trivial or easy to come up with. On Mon, Nov 28, 2011 at 1:59 PM, Sam Hartmanhartmans-i...@mit.edu wrote: I support the general approach you outline in terms of process. However it would really help me if you could write a non-normative paragraph describing what you think is involved in an anti-trust policy? I think that this should be a work product here. However, here are some considerations. First, I should note that our counsel has advised us to do this. As you may know, SDO's have a certain protection against antitrust actions, but that is not absolute, and can be lost if the SDO behaves inappropriately. I think that at least a review of our policies and procedures with this in mind is called for. Note that the IEEE has an anti-Trust policy : http://standards.ieee.org/develop/policies/antitrust.pdf This paper provides some of their reasoning : http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4292061 Note the following : the IEEE and other standard-setting organizations were afraid to demand advance notice from patentees of what the allegedly RAND terms would really be, lest the courts hold the organizations liable for engaging in a price-fixing cartel. We have a procedure in place to deal with this, but it would be IMO a good idea to consider whether it is adequate. Also, SDO protection against antitrust actions were extended in the Standards Development Organization Advancement Act of 2004 https://standards.nasa.gov/documents/AntitrustProtectionForStandardsDevelopers.pdf (which talks about pattern lawsuits including SDOs), see also http://www.venable.com/new-antitrust-protection-for-standards-development-organizations-09-01-2004/ The Act provides protection of SDOs against treble damages, if the SDO has filed notice with the US government : The notification provisions of the SDOAA are set out in Section 4305 of the Act, which provides that an SDO that wishes to claim the benefits of the de-trebling provision must submit notice of its planned activity to the FTC and DOJ The IETF has never done this. Whether or not it should do it, I think that that decision should go through legal and community review, and that in general we should review what we are doing against the 2004 Act. Finally, just for clarification please note that the IETF Trust is not really involved at all with this type of Antitrust, as the policy would not be concerned with protecting the IETF's Intellectual Property. Regards Marshall Marshall We presumably need to take a global perspective on this. There are 192 UN recognized countries, and I would assume that we need to consider the worst case across some large number of them. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] R: FW: Last Call: draft-sprecher-mpls-tp-oam-considerations-01.txt (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote: major unresolved technical concerns Alessandro Please can I suggest that you write an internet draft detailing these major unresolved technical concerns so that we can all understand them. Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts. Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is. I believe that this request has been made a number of times, in various forums, and, as far as I know, no document has yet been produced. An argument of the form you must standardize what I want will not fly. What is needed is a very clear technical definition of the issue(s). When we have the major unresolved technical concerns on the table, we will be in a position to determine the best disposition of those issues. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ 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 would take issue with OSPF/ISIS and IPv4/IPv6. Please can you expand a little on this. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] R: FW: LastCall: draft-sprecher-mpls-tp-oam-considerations-01.txt(The Reasons for Selecting a Single Solution for MPLS-TP OAM
3) The global wide application of Ethernet services requires that the operator’s network must support Y.1731 Ethernet OAM, to guaranteeing the SLA for customers. Although many operators had expressed their requirements for MPLS-TP OAM using draft-bhh/G.8113.1 in IETF meetings and mail-list, but these were always been ignored. The IETF is concerned with the design of an MPLS technology, not an Ethernet technology. What technical problem exists with the IETF OAM solution that prevents the operator from guaranteeing the SLA for customers? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC
It is clear that: 1) RFC6074 is the IETF recommended approach. 2) That draft-kompella-l2vpn-l2vpn is in active deployment. The question is whether the number of independent deployments of draft-kompella-l2vpn-l2vpn is increasing or not. In other words is this a legacy approach that will over time decline, or is it a parallel alternative that will be actively chosen by some subset of operators going forward and which will be implemented by more than one vendor. - Stewart On 13/09/2011 21:14, Alexander Vainshtein wrote: Luca, The draft in question exists for almost 8 years (the -00 version has been posted 2004-01-13), has been implemented and deployed. I have not heard that solutions compliant with RFC 6074 (which is the proper analog of 4447 in this case IMO) have been deployed in this interval - and that in spite of 6074 sitting in the RFC Editor queue (i.e., sufficiently stable for any potential implementer) for almost 6 years (from 2006-06-12). Hence I do not see this case as similar to what happened to the original draft-martini vs. RFC 4447. Do I miss something substantial here? Regards, Sasha From: Luca Martini [lmart...@cisco.com] Sent: Tuesday, September 13, 2011 9:16 PM To: Alexander Vainshtein Cc: l2...@ietf.org; pwe3; IETF Discussion; Andrew G. Malis Subject: Re: Last Call:draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC On 09/13/11 10:03, Alexander Vainshtein wrote: Luca, and all, I concur with Andy's opinion that the reference to RFC 4447 must become Normative (this will not delay the publication is too often the case:-). As for Informational vs. Historical, I think that Informational is more appropriate because, AFAIK, the technique defined in draft-kompella is not just a documenting an existing solution - it describes is THE ONLY deployed solution for the problem. (If this statement happens to be factually incorrect, I would be happy to learn about the deployed alternatives.) no, there are several ( I think 3 ) implementations of the l2vpn-singalling standards track document also known as rfc6074. There are several deployments of rfc6074. As 10 years ago we had several deployments of draft-martini which over time are being updated to rfc4447 , there are some deployments of the solution described in the draft-kompella-l2vpn-l2vpn-07.txt. I still think that an historical RFC would fit this solution , unless we plan on expanding it , and pursuing new enhancements to it. Luca Regards, Sasha -Original Message- From: l2vpn-boun...@ietf.org [mailto:l2vpn-boun...@ietf.org] On Behalf Of Luca Martini Sent: Tuesday, September 13, 2011 6:24 PM To: Andrew G. Malis Cc: l2...@ietf.org; pwe3; IETF Discussion Subject: Re: Last Call:draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC I concurr with Andy. Given that the WG has made a decision on which control plane technology is the standard track technology we should have a statement in this document pointing to the standard track rfc4447 so it is clear to anyone reading the document. In the same way we published the draft-martini documents as historical ee should publish this document as historical rfc, to document existing implementations. Luca On 09/01/11 05:42, Andrew G. Malis wrote: Speaking as an individual, the solution in this draft has been has been operationally deployed in a number of service provider networks, and it should be documented in an informational RFC. Speaking as PWE3 co-chair, I would be happier if this draft required that routers that implement this solution also implement RFC 4447, that RFC 4447 be configured as the default mechanism for pseudowire signaling, and that RFC 4447 was moved from an informational to a normative reference. In practice, I know that routers that implement this also do implement RFC 4447, but I would like to see it in the RFC as well. Thanks, Andy Subject:Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Date: Tue, 30 Aug 2011 10:50:05 -0700 From: The IESGiesg-secret...@ietf.org mailto:iesg-secret...@ietf.org Reply-To: ietf@ietf.orgmailto:ietf@ietf.org To: IETF-Announceietf-annou...@ietf.org mailto:ietf-annou...@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling' draft-kompella-l2vpn-l2vpn-07.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.orgmailto:ietf@ietf.org mailing lists by 2011-09-27. Exceptionally,
Re: FW: [PWE3] Last Call: draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt (Using the Generic Associated Channel Label for Pseudowire in MPLS-TP) to Proposed Standard
On 01/09/2011 15:37, Yaakov Stein wrote: Stewart Was this email meant to address my email to the IETF discussion list (from Tues 16 Aug) or just the discussion on MPLS and PWE lists ? It does to SOME extent, as it leaves open the possibility of the GAL not being at BoS; but it does not rule out that possibility either. Indeed, but a draft would need to make the case for it to be anywhere other than BOS. The only case that I can think of at the moment is where a FAT label is being used, but that is out of scope in this draft and would need to be resolved in the draft describing the co-existance of the two labels. However, you did not address my other final comment that a PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain. What does one do then ? That is a general issue rather than a TP issue. When you get to the PW label and you would find that it was not BOS. If you you are not running FAT that that is a detectable. If you are running FAT the presence of the GAL (which is not an allowed FAT label) is also a detectable. (My email also identified a wording issue and what I consider to be a completely inaccurate explanation of what the draft is trying to accomplish.) architectures appropriate Seems to have the word as missing. I will add an editors note. You say: Bottom of stack has been the label position of the PW label for many years, and this position is mandated by multiple RFCs, e.g. 3985 and 4447 Note that the PW label must always be at the bottom of the packet's label stack. That is no longer true with the introduction of FAT. Then you say: Present PW implementations receiving the PW label with stack bit cleared, and a GAL at the bottom position will choke and, at best, discard the packet. At worst, the GAL may coincide with a legitimate PW label, and the customer will be flooded with garbage. Your first case is sort of correct - the packet should be silently discarded as it was clearly not intended for that PW - but it had better not choke as this would be an attack vector. You second case cannot happen because a GAL is a reserved label and a reserved label can never be a legitimate PW label. Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
On 01/09/2011 17:07, Alexander Vainshtein wrote: Yaakov, You've written PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain This is exactly the point that I've raised in my IETF LC comment on the draft (for MS-PW) - please see my email (to several lists) that explains that in some detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html. Regards, Sasha The operator intends to improve traffic distribution in the IP/MPLS domain, hence he enables insertionand discard of flow labels at the two S-PEs. Speaking as an author of the FAT-PW draft I do not recall any text that proposes that S-PEs insert FLs in the stack, and it never occurred to me that anyone anyone would try, since would require a change to the design of the S-PEs. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be resolved in any PWE3 draft that describes the use of the GAL. To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01 -Section 4.2 http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586 http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack. = should be replaced by = -Section 4.2 http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586 http://tools.ietf.org/html/rfc5586], the original text: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. is replaced by: In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MAY be used with PWs. The presence of a GAL indicates that an ACH immediately follows the MPLS label stack. == - Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw
Sasha On 30/08/2011 13:22, Alexander Vainshtein wrote: Stewart, I believe that your item #1 is presumably addressed by draft-ietf-pwe3-gal-in-pw (with the changes you’ve proposed), draft-nadeau-pwe3-vccv-2 is an attempt to address your item #2, and your item #3 is not yet addressed. Is this understanding correct? Yes I also think that one of the items in the discussion was the restriction on ECMP in MPLS to skip reserved labels. I am not sure if it has been properly addressed anywhere, so should not it constitute item #4? Yes-ish, here I am concerned about the practical ability to do that given the extent of deployed LSRs that do not do that. My point here was to note the scope of this draft (which is is IESG review). Other drafts need to make their own case for what they want to do and how they propose to do it. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On 25/08/2011 18:12, Mary Barnes wrote: I am also a fan of Minneapolis for meetings - the facilities at the Hilton are perfect for our needs. There's lots of food options. It has good air connections and there is decent pubic transport from the airport to the city. However, this seems to be a minority perspective. If we were to do votes again, the results might be interesting. Mary. I like Minneapolis as well, but then, speaking personally, I like US IETF venues in general. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-shiomoto-ccamp-switch-programming
On 10/08/2011 19:35, Adrian Farrel wrote: Hi Ben, Thanks for reading. Nits/editorial comments: -- section 1, paragraph 4: ...with relation to the programming... ... in relation to... Yeah. RFC Editor note if Stewart is watching (although I'm guessing the RFC Editor might just fix this anyway). -- 3.1, last paragraph: Note that the references say SHOULD rather than MUST. Using must not here, even non-normatively, seems a bit overstated. Disagree. The caveat is that we are defining something different. We are looking at the case where we want to know that it is safe to start sending data. We are using the existence of some SHOULD statements in related RFCs that describe related behavior, to derive a must that covers when it is known to be safe. Point 1 in the RFC editor's note, point 2 assumed to be addressed by the above email. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
On 12/07/2011 23:23, Joe Touch wrote: Hi, Joel (et al.), On 7/10/2011 7:10 AM, Joel Halpern wrote: Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. That's a great example of why this term should be removed. The message sent from one BGP to another is sent *inside* a TCP connection, and nobody would ever call the TCP bytestream payload the message on the wire. This term is simply sloppy, and just as the security community rightly raises issues with similarly poor use of its terms (e.g., random where pseudorandom or arbitrary are intended, or authenticated where integrity protection is intended), I consider this a *significant* transport issue. Joe Please can you suggest a suitable generic term that covers the set of cases that we need to deal with in routing - i.e. over the MAC, over IP, over UDP and over TCP, so that we can discuss inter routing entity message passing as an abstract operation. As Joel says when we get to the detailed design of each routing protocol we will discuss the details, but we want a high level discussion in this document. Note BTW that 186 RFCs use the term on the wire in this sort of situation. - Stewart With regard to your comment about identifiers, we can add in the description of protocol reviews indications that such reviews should be clear about what IDs the review considers need protecting, as that is important context for the protocol review. OK. As noted in other exchanges, the document abstract needs a complete rewrite. It should be just an abstract, with the rest of the context either removed or moved to the introduction. In doing so, we will add text describing briefly the general concept of the routing protocol transport. OK. In general however, protocol specific behaviors are to be left to the protocol analysis documents. Equally, descriptions of detailed threats will be left either to the threat document or to the individual protocol analysis document as appropriate. My goal is to make some transport properties as notable and discussed in as much (or as little) detail as, e.g., multicast and unicast already are in the current document. There are several items in your comments indicating that you would like to see more discussion in the design guidelines of the protocol layering. That does not seem to be a useful addition to this document. Again, individual protocol analysis documents will deal with that where it is appropriate, and avoid it where it is a distraction. We do not see useful general statements of guidance that can be put into this document. As noted above, this is already in the document w.r.t. multicast/unicast; I'm suggesting that it's equally appropriate to include similar discussion of the issues of other layers on routing protocol security. Adding some general text in the discussion of communication modes elaborating on the difference between the communication as seen by the routing and security components, and the actual communication (e.g. that what is seen as multicast may be delivered as broadcast or multiple uni-cast) does seem a helpful addition to the document, and we will do that. I'm not sure if this is basically all I'm asking for; see above. The intent was to add discussion of some known transport issues that are as relevant as the multicast/unicast difference already discussed, in similar detail. Joe -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: tsv-dir review of draft-ietf-pwe3-fat-pw-06
Rolf Thank you for the review On 19/05/2011 14:24, Rolf Winter wrote: CONTENT: Section 3 says: If a flow LSE is present, it MUST be checked to determine whether it carries a reserved label. If it is a reserved label the packet is processed according to the rules associated with that reserved label, otherwise the LSE is discarded. However section 1.2 states: Note that the flow label MUST NOT be an MPLS reserved label. Isn't that a contradiction to a certain extend. I mean, if there is a reserved label in the flow LSE, isn't that an error and should not be processed? Section 1.2 is saying that the flow label generator MUST NOT generate and apply a reserved label. Section 3 is saying that if there is a label put in that position it must have been put there by some application that wanted a diagnostic so process it. The intent is careful what you send, liberal with what you receive. section 8.4: The second bullet in the section under: The issues described above are mitigated by the following two factors:. I wonder whether that isn't a bit farfetched. I mean, in principle you suggest that customers could change e.g. the way their applications behave to let the ingress PE to be able to better apply the flow label. That sounds like asking a customer to change something on their application end to have a better network connectivity. This is dealing with the single large flow case. There is no way to load balance a single large flow at the speeds we need to operate and at the price performance point needed. This is noting that the customer needs to help out. Clearly if the user is unable to modify their application they get the performance they get, and indeed risk running foul of ingress policing by the provider. section 8.5. Isn't a bigger problem here that you cannot guarantee that the OAM packets follow the same ECMP path and that violates the fate sharing requirement? I added: In addition MPLS-TP makes extensive use of the fate sharing between OAM and data packets, which is defeated by the flow LSE. section 12: You essentially say that the behaviour of IP packets are well defined regarding congestion and nothing needs to be done. Other payload needs to be dealt with by PW congestion avoidance (whatever that means). So IP packets that are not reacting to congestion (such as UDP) are no concern but other packets with the same behaviour are? Is that a correct reading of the text? Yes. The PW assumes that all IP packets are as well behaved as the IETF requires them to be. It is not the job of PWE3 to specify or influence the congestion behavior of IP packets, we just carry them as a wire would. section 2: s/identify flows/identifies flows/ I am not sure. Let's leave it to RFCed. section 8.4: Option one says: The operator can choose to do nothing and the system will work as it does without the flow label. Isn't this option to not use the flow label. If so a better wording would maybe be: The operator can choose to do nothing, i.e. to not employ the flow label The point is that the operator would prefer for their own reasons to see load balancing so they probably want to turn it on and hope that at some future stage the user modifies their profile to the mutual benefit of user and provider. The do nothing refers to taking no further action. Option 3: 2/flows,/flows./ Why is section 9 not section 8.7? I mean it is concerned with applicability which is what section 8 is about. PWS are not LSPs and there is work on this WRT LSPs in MPLS WG. This is a heads up that this other work is happening, that both parties are aware of what the other is doing. It seems reasonable to put it in its own section. section 9: s/This is can be regarded as/This can be regarded as/ This section was re-written following genart f/b from Mary Barns. Regards Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Proposed text for IESG Processing of RFC Errata concerning RFC Metadata
The IESG is considering making this statement on the processing of RFC Errata concerning RFC Metadata. We would appreciate community feedback. Please can we have feedback by Thursday 9th June. Thanks Stewart == Draft text for IESG Statement on RFC Metadata Date: xx-xxx- This IESG statement describes the manner in which the IESG will process RFC Errata concerning RFC Metadata [RFC5741]. Metadata is used, for example, in the compilation of the RFC Index. The Area Director responsible for processing the RFC erratum will review the RFC and document history recorded in various IETF archives such as the datatracker. Where the error is major, for example an error in the document track, the Area Director SHOULD reject the erratum, and initiate the publication of a replacement RFC. Where - The error is minor, for example where there is a minor error in the list of updated RFCs, and - The intent of the IETF community as determined from the RFC and the records is clear, and - The RFC has been processed correctly in all other regards, the Area Director MAY accept the erratum. The Area Director MAY consult with the IESG in making this determination. If the above minor error conditions are met, but the Area Director responsible for processing the metadata is of the view that the best interests of the community are served by holding the RFC erratum for document update, or rejecting the erratum and initiating the publication of a replacement RFC they MAY process the RFC erratum accordingly. Where there is doubt as to the intent of the IETF community or where the RFC has not been processed in accordance with the rules governing the proposed change to the RFC metadata, the RFC erratum MUST be rejected. == ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-pppext-trill-protocol-06.txt (PPP TRILL Protocol Control Protocol) to Proposed Standard
The RTG-dir review comments : http://www.ietf.org/mail-archive/web/rtg-dir/current/msg01533.html Should be addressed before publication. - Stewart On 25/05/2011 17:13, The IESG wrote: The IESG has received a request from the Point-to-Point Protocol Extensions WG (pppext) to consider the following document: - 'PPP TRILL Protocol Control Protocol' draft-ietf-pppext-trill-protocol-06.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-06-08. 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 Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ 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 -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Telechat review of draft-ietf-isis-genapp-04
I will put a note in the tracker Stewart On 15/03/2011 19:52, Les Ginsberg (ginsberg) wrote: -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Tuesday, March 15, 2011 12:26 PM To: draft-ietf-isis-genapp@tools.ietf.org Cc: General Area Review Team; The IETF Subject: Gen-ART Telechat review of draft-ietf-isis-genapp-04 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-isis-genapp-04 Reviewer: Ben Campbell Review Date: 2011-03-15 IESG Telechat date: 2011-03-17 Summary: This draft is ready for publication as a proposed standard. Major issues: None Minor issues: None Nits/editorial comments: IDNits still emits some minor warnings and comments--please check. -- Security Considerations, 2nd paragraph: It is possible that information advertised in a GENINFO TLV by a given Application MAY introduce new security issues. I assume that was not meant as a normative MAY? Not intentionally. I am fine with converting this to lower case. Les -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
On 20/12/2010 18:43, Donald Eastlake wrote: Hi, On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartmanhartmans-i...@mit.edu wrote: Radia == Radia Perlmanradiaperl...@gmail.com writes: Radia No objections. Radia Can I get someone to confirm that the text in the proposed sentences is substantially true? I think so but I'm not an IS-IS expert. LSPs have sequences number, etc., and are idempotent. I think only Hellos have the potential replay Denial of Service problem. So I would suggest changing to: Even when the IS-IS authentication is used, replays of Hello packets can create denial-of-service conditaions; see RFC 6039 for details. These issues are similar in scope to those discussed in section 6.2 of draft-ietf-trill-rbridge-protocol, and the same mitigations may apply. Thanks, Donald ... as I recall from discussions with the ISIS WG the changes that were made to ISIS for TRILL make it more vulnerable to a hello attack than vanilla ISIS. This I understand is because there is more work to be done in processing a TRILL hello. Is that correct? - Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
Michel Py wrote: Jorge Amodio wrote: Hard to believe but Morse is still in use and required for certain classes of radio operators. For good reasons; in difficult conditions, Morse still delivers the message when the voice has long stopped being recognizable. Morse would be like ASCII: definitely not the prettiest solution, but if something still works it would be it. Sure, but modern digital modes such as WSTJ will beat Morse at SNR. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Corporate email attachment filters and IETF emails
Dave Cridland wrote: On Tue Dec 15 02:08:08 2009, IETF Member Dave Aronson wrote: On Mon, Dec XIV, MMIX at XX:X, Loa Andersson l...@pi.nu wrote: great idea - and we should als adopt Latin numbers! ... Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 10 717 52 13 +46 767 72 92 13 Shouldn't you therefore have written: phone: +XLVI X DCCXVII LII XIII +XLVI DCCLXVII LXXII XCII XIII I was going to send a flippant and trivial message to the list on this, but I was concerned I may be raising the tone. Dave. -//.-././. .../-.--/--/-.../---/.-../... -../---/- -../.-/.../ .-/-./-.. .../.--./.-/-.-./. .-/.-./. ./-./---/..-/--./ ..-./---/.-. --/. -../. .../-/./.--/.-/.-./- ___ 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
Sadler, Jonathan B. wrote: ITU-T SG15 has a history of OAM protocol development for transport technologies. This expertise has led to development of an OAM methodology and definition approach as documented in G.806. Jonathan Unfortunately the latest version of G.806 is showing up as pre-published, only available for purchase at a cost of 64CHF, please can you make a copy of this available to the IETF so that we can review the relevant content in order to consider this as input to this last call process. Regards Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
Noel Chiappa wrote: Are our members who are Falun Gong practitioners going to be persecuted for their beliefs while attending IETF? Are our members who are active in Tibetan or Taiwanese independence movements going to be quietly picked up off the street outside our venue? More likely they just wouldn't be given visas to begin with. That happened at the Olympics, too. So we need to know how many people who would normally attend would expect to be denied visas. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
Colin Perkins wrote: I have no significant problems using xml2rfc, and find it easier to write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or Microsoft Word. +1 ... and I am quite happy to use the online compiler. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Paul It appears that people have forgotten that, when needed for clear artwork, RFCs can be published in PDF format. This has been done in the past, and can be done again in the future. If WGs are not doing some work because of fear of not having it published as an RFC because of the artwork, they are working under a misconception. Talk about premature anti-optimization! We know this, the problem is that you cannot publish a standards track document in this format. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Iljitsch van Beijnum wrote: On 3 jul 2009, at 0:35, Pete Resnick wrote: A much better solution would be HTML, if it's sufficiently constrained. Or, gee, we could generalize to a very constrained XML format XML isn't a display format. As Dave put it, the current RFC format is unfriendly, unnecessary, possibly unethical and just plain wrong. I'd remove the possibly. Please elaborate; this statement goes far beyond the inconvenience of having fixed line and page breaks and the lack of non-7-bit-ASCII characters. I wonder what people think about the need (or lack of need) to have graphical images. Having written a book or two, I can tell you that getting text right is hard, but this pales in comparison to the difficulty of getting images right. Most people, including myself, don't have the skills to create decent artwork. The formats are infinitely less open (in a variety of senses), so modifying someone else's images is extremely difficult unless you happen to use the same tools or go to the lowest common denominator = bitmaps. And images are of course impossible to use on text-only terminals. On constrained devices they're hard to work with because the text doesn't scale. So I think a good argument could be made that in general, RFCs shouldn't have images. That is an author centric view. It is far more important to take a reader centric view. Do we have any objective information on what format produced the clearest information transfer in the reader. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Iljitsch van Beijnum wrote: On 3 jul 2009, at 13:13, Stewart Bryant wrote: That is an author centric view. It is far more important to take a reader centric view. Do we have any objective information on what format produced the clearest information transfer in the reader. Well, readers can't read what authors can't produce. Perhaps a good image trumps good text, but I don't think we can assume that this is the choice we'll be faced with in general, mediocre image vs good text or bad image vs mediocre text seems more likely. Images of any quality do not excuse poor text. Producing good text is not negotiable and we have mechanisms in place to ensure the quality of the text. However it is our job to produce the most lucid description of the specification and I go back to my question, what format is most effective for the readers? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
John Leslie wrote: Stewart Bryant stbry...@cisco.com wrote: That is an author centric view. It is far more important to take a reader centric view. I must dissent. Reader-centric views belong to publishing entities that generate income (whether by purchase, subscription, or advertising). There have always been book publishers that generate reader-centric interpretations of RFCs. It's expensive to do so; and such publishing entities are careful to evaluate the potential market before producing one. IETF publications produce _no_ income; so we need to minimize the expenses. That leaves us concentrating on the author-centric and editor-centric views. I in no way dispute that other presentations can be better for the reader; I only remind folks that we subsidize IETF publications through our meeting fees, and other avenues are always available to publish reader-centric versions. For one simple example, I know of nothing preventing citations of self-published guides as Informative References in RFCs. Ah. I thought we wrote RFCs so that others could read them and translate the content into some locally meaningful combination of hardware and software. If that is not the case I wonder why we spend our time writing them? My overarching point of course is the style of an RFC should be so as to maximize the probability that the implementation is correct, and that the preference for style should be driven by that need. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Pete Getting rid of a page-layout format as our authoritative form is primary. Using characters that do not occur in English is next down the list. Everything else is extra. Surely maximizing the probability of correct understanding by the reader is primary. Everything else is just a mechanism. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
Tim Bray wrote: On Thu, Jul 2, 2009 at 2:01 AM, Iljitsch van Beijnumiljit...@muada.com wrote: A much better solution would be HTML, if it's sufficiently constrained. HTML allows for the reflowing of text, solving issues with text and screen sizes. It's also extremely widely implemented, so it's easy to display reasonably well without special tools. It also allows for semantic tagging, allowing for easy scraping. This seems obviously true everywhere outside the IETF mailing list. The showstopper has always been with figures which need to do in separate files. How do you manipulate the collection of files as a single object? At least with pdf you know you have the whole thing. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
To save time, I would suggest adopting the Patent Office rules on Perpetual Motion. People advocating for a change to facilitate figures (or to allow complicated math, such as tensor analysis) should have an existence proof, i.e., a document that requires the change to be published. (A document that left the IETF to be published elsewhere for this reason would also do.) RFC1305 which states Note: This document consists of an approximate rendering in ASCII of the PostScript document of the same name. It is provided for convenience and for use in searches, etc. However, most tables, figures, equations and captions have not been rendered and the pagination and section headings are not available. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP
Stephen Farrell wrote: Something like: This is the list of those nominated (or self-nominated) for IESG positions. The nominees have said that they're willing to serve if selected, but there is no implication that they consider the incumbent unsuited for re-appointment. Presumably there would need to be a second list of names with the text: These nominees have said that they're willing to serve because they think the incumbent is unsuitable for re-appointment. ... or maybe this would be expresses as just a second list of names. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: gen-art review of draft-ietf-pwe3-ms-pw-arch-06.txt
Scott - In this one paragraph: Note that although Figure 4 only shows a single S-PE, a PW may transit more one S-PE along its path. This architecture is applicable when the S-PEs are statically chosen, or when they are chosen using a dynamic path selection mechanism. Both directions of an MS-PW must traverse the same set of S-PEs on a reciprocal path. Note that although the S-PE path is therefore reciprocal, the path taken by the PSN tunnels between the T-PEs and S-PEs may not be reciprocal due to choices made by the PSN routing protocol. ... reciprocal is used, but nowhere else in the document. Should it be bi-directional (used elsewhere)? I am not sure. In propagation and navigation a reciprocal path is the exact reverse of the outward path, and that is exactly what we want to say. I this context it is also bidirectional. - 15.1 References should be Normative References We will split the list tomorrow. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
Margaret Wasserman wrote: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. I don't believe that there are any legal implications to moving our IPR information to the back of the document, and it would be great not to have to page down at the beginning of every I-D to skip over it. If someone wants to check the licensing details, they could look at the end of the document. Margaret ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Margaret Will this break any official or unofficial ID processing tools? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: LORAN is making a comeback..
Lyndon Nerenberg wrote: Take it off line. This has nothing to do with the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Except as requirements for TICTOC. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Friday experiment
Another option would be to run until 1300, that's still early enough to have lunch but it does give us a 1.5 hour extra timeslot but only takes that 1.5 hours, not 3.5 like the 1300 - 1500 timeslot so people with flights at 1700 or even 1600 can possibly attend. We could maybe start earlier on Friday as well - say 8am - i.e. run 0800 till 1300 with only only a 10 min coffee break. That would put nearly 5 hours into the schedule. I agree with using the Friday for meetings, but not if the cost is staying over Friday night and maybe not getting home until Sunday. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Missing Materials
Eric Missing drafts draft-shen-csi-ecc-00.txt (wg=csi) draft-ietf-ccid4-02.txt (wg=dccp) draft-ietf-eai-smtpext-11.txt (wg=eai) draft-ietf-eai-utf8headers-09.txt (wg=eai) draft-ietf-ntp-dhcpv6-ntp-opt-00.txt (wg=ntp) draft-ietf-psamp-info-07.txt (wg=ipfix) draft-aitken-ipfix-new-infos-01.txt (wg=ipfix) draft-dietz-ipfix-mib-04.txt (wg=ipfix) draft-kang-ccamp-wdm-switch-info-00.txt (wg=ccamp) draft-ietf-ntp-dhcpv6-ntp-opt-00.txt (wg=dhc) draft-willis-sip-infopackage-00.txt (wg=sip) draft-martini-pwe3-iccp-00.txt (wg=pwe3) draft-ietf-ecrit-location-hiding-requirements-00.txt (wg=ecrit) draft-ietf-pim-port-00.txt (wg=pim) draft-dekok-radext-dtls-01.txt (wg=radext) draft-mediactrl-ivr-control-package-00.txt (wg=mediactrl) draft-mediactrl-mixer-control-package-00.txt (wg=mediactrl) draft-nishioka-pce-sve-list-02.txt (wg=pce) draft-eardley-pcn-marking-behavior-01.txt (wg=pcn) draft-ietf-sieve-notify-mailto-06.txt (wg=sieve) draft-freed-sieve-notary-01.txt (wg=sieve) draft-ietf-dnsext-29.txt (wg=dnsext) draft-ietf-dna-frd-02.txt (wg=dna) draft-ietf-radext-management-authorization-03.txt (wg=isms) I had a report of three PWE3 related drafts submitted by email not appearing in the archive. One is in your list above. I wonder if any of the other authors had a similar problem. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
At least three ADs believe that the examples should be changed I agree with them. Use of any identifier outside the example space may cause real harm to the owner, where that harm may range from serious harm (technical and/or financial) to mild embarrassment. If anyone wants to use an identifier outside the example space, then to protect both the owner of the identifier and the IETF, the author really needs to provide the IETF with evidence of written authorization to use it for this purpose. In the case of this draft, have the owners of the identifiers been contacted by the author, and do they agree to this use? Stewart ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-rtgwg-ipfrr-spec-base (Basic Specification for IP ...
Beginning Stewart [EMAIL PROTECTED] wrote: Question: Is the accomplishment of this document considered to be the end or rather the beginning of activities on the rerouting topic ? Heiner In einer eMail vom 29.04.2008 22:35:53 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]: The IESG has received a request from the Routing Area Working Group WG (rtgwg) to consider the following document: - 'Basic Specification for IP Fast-Reroute: Loop-free Alternates ' draft-ietf-rtgwg-ipfrr-spec-base-12.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 2008-05-13. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-rtgwg-ipfrr-spec-base-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12272rfc_flag=0 ___ rtgwg mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/rtgwg ___ rtgwg mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/rtgwg ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reminder for people working on -bis documents
Adrian Farrel wrote: Good point Jari, Can I also remind you to check in the RFC Errata pages to make sure you pick up any errors that have been flagged since RFC publication. Of course you mean the *relevant* errata - the RFC Erratas page is so full of junk these days that it is virtually unusable. Stewart ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confirming vs. second-guessing
I believe that it's appropriate for the confirming bodies to ask for additional information if they have reason to doubt that due proces has been followed or that some of the proposed appointees are suitable. Isn't one of the roles of the liaisons to ensure that due process is followed to the extent required by the body they represent, and to give advanced notice when the choice of candidate is likely to be unacceptable to their body? Stewart ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Deployment Cases
Ping Pan wrote: Exactly! It is one impressive spec: clean and simple. Looking at its adaptation, I wonder why in the world it was not adapted and done in IETF. On the other hand, it may take too long in IETF, and would require extensive debate over architecture, framework, requirements... ;-) - Ping Wouldn't Bittorrent fail congestion considerations review? Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
What's the worst that can happen - we have to listen to the plenary speakers without jabber sessions? That would be pretty major! We have had PWE3 contributors who were unable to be present in the meeting, listen on audio and use IM for questions. Lets do the experiment, but lets not run it in prime time until we know how it will impact productivity. Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Travel Considerations
Eric Burger wrote: See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf Which seems to be only available to those prepared to pay. Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt
Scott Historically the biggest issue with IPFIX has been that most implementers want to run it over UDP with consequences be dammed. - this was weaseled in the IPFIX Requirements document (RFC 3917) by requiring (in section 6.3.1) that For the data transfer, a congestion aware protocol must be supported. This draft meets that requirement by making the implementation of SCTP a MUST. That will not stop many implementers from ignoring the requirement for implementation or users to enable UDP and thus creating a potentially very high bandwidth non-congestion avoiding fire hose that can quite easily wipe out a net by misconfiguration or become a DoS engine by purposeful configuration. I'm not sure if anything can be actually be done about this risk - It might help some to say that UDP is a MUST NOT but I doubt it - in any case it would help somewhat, imho, to expand section 10.3 to be clearer about the threats posed by any use of a non-congestion avoiding transport protocol or to do that in the Security Considerations section There is text in section 10.1 which states: UDP MAY be used although it is not a congestion aware protocol. However, the IPFIX traffic between Exporter and Collector MUST run in an environment where IPFIX traffic has been provisioned for or is contained through some other means. This sets out the set of conditions that MUST be fulfilled in order to run IPFIX over UDP safely. Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Do we have any firm evidence that we would get more work done if we had more meetings outside the US? Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
