Re: voting system for future venues?
Dave, On 8/29/2011 8:01 AM, Henk Uijterwaal wrote: If we want more flexibility in order to find better hotel deals, then we have to do something like: dates are fixed approximately 1.5 years out, and we do not mind having meetings back-to-back with other organizations on the clash list. As we have been told for many years and experienced directly, hotel schedules become crowded 2-3 years ahead of time. That means we must fix our dates farther ahead than we have been doing. 1.5 years essentially guarantees our having very limited choice. Yes, I agree. My point was the change that was proposed. Currently the algorithm is something like: T-6 years:Announce date of meeting T-3 years:Start finding a hotel T-2 years:Select hotel T-1.5 years: Announce venue to community. Obvious advantage of this model is that all other organizations know when we will meet and clashes are minimal. Also, people who asked for early announcements of meeting dates, get what they want. If we change to a model where we are more flexible in order to find the best hotel deal, this becomes something like: T-6 years Announce that we have meeting in say March/July/November T-3 years Start finding a hotel for that month. T-2 years Select hotel and set exact meeting dates. T-1.5 years Announce to community. That is a 4.5 year difference in when the exact date is announced. This increase the risk that there is a clash with another meeting and people cannot plan much in advance. The question is what we, as a community, want: dates known early or flexibility to select the best venue at a late stage. Henk -- -- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 -- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
On 2011-08-30 at 07:36:58, Peter Saint-Andre wrote: for long enough, I finally decided to submit an I-D that is intended to obsolete RFC 2119. bike-shed IS THERE ANY CHANCE OF AGREEING THAT SHOUTING IS BAD? (i.e., Burger's first anti-law.) As opposed to mandating that requirements ought to be shouted. Lowercase must can be as effective as uppercase as long as it is consistently applied. /bike-shed On a more serious note, many documents lean too heavily on conformance terms. A gentle reminder that conformance terms ought to be sparingly used might not go astray here. It's just like the F-bomb, it's a F-ing big deal if used infrequently enough. People are more likely to pay attention when it's rare. --Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 8/30/11, Murray S. Kucherawy m...@cloudmark.com wrote: Mark Nottingham: 1) I agree that the SHOULD... UNLESS pattern ought be documented. I had never thought of this before. I kind of like the idea, especially since SHOULD has always meant MUST unless you really know what you're doing Such an odd reading. Does it mean you MUST because you could not handle it otherwise? It takes two to tango. One side reasons can be different than the other. If a software breaks down because it read SHOULD as a MUST and expected the other end will also view is a MUST, then it didn't know what it was doing. Things break down. Implementors on either side can't depend on it and need to function in lieu of it. There is always the possibility one decided Na, not needed, not worth the cost. Its not required. etc, and no one should die because of that decision. I think it MUST be noted that a Minimum Implementation for a protocol is all anyone can expect. If a SHOULD item is among the listed minimum requirements, it MUST be removed from the list or changed to a MUST. Maybe the term Minimum Implementation (is part of, is not part of) can be incorporated into each of the key word text. -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Frank, On 8/30/11 12:15 AM, Frank Ellermann wrote: On 29 August 2011 23:36, Peter Saint-Andre wrote: staring at http://www.rfc-editor.org/errata_search.php?eid=499 for long enough, I finally decided to submit an I-D that is intended to obsolete RFC 2119. There are literally thousands of documents (not only RFCs, also W3C standards, etc.) with normative references to RFC 2119 (sic!) instead of BCP 14, and I see no compelling reason to render these references as historic. On the basis of this logic we wouldn't be able to supercede any of our key RFCs. [...] How about trying an updates 2119 and status BCP, where BCP 14 then consists of 2119 and 2119bis, and old RFC 2119 references are still okay as is. What ends up happening, then, is that we need Internet lawyers to traipse through references. I challenge you or anyone else here to list all the process RFCs that update RFC 2026. Let's not repeat that fiasco with 2119. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Frank, 2119bis is going to replace RFC 2119, and Obsoletes: 2119 header is fine here. Updates: header means that some changes are made, and these specific changes are clearly indicated; 2119bis imports all the content of 2119 plus adding own changes, and is a significant update of 2119, so Updates: 2119 is inappropriate (sorry for pun). I would rather object to making RFC 2119 Historic; I remember RFC 2026 discusses such case (probably Section 6.3, which is also applicable to BCPs). So, the following change is necessary: Abstract and Introduction (similar text). OLD: If approved, this document obsoletes RFC 2119 and changes its status to Historic.; NEW: This document obsoletes RFC 2119. Mykyta Yevstifeyev 30.08.2011 1:15, Frank Ellermann wrote: On 29 August 2011 23:36, Peter Saint-Andre wrote: staring at http://www.rfc-editor.org/errata_search.php?eid=499 for long enough, I finally decided to submit an I-D that is intended to obsolete RFC 2119. There are literally thousands of documents (not only RFCs, also W3C standards, etc.) with normative references to RFC 2119 (sic!) instead of BCP 14, and I see no compelling reason to render these references as historic. For starters simply confirm the erratum, I don't see why that caused you headaches. IMO it is not necessary (but allowed) to import any BCP 14 terms not actually used in a document, i.e., I disagree with section 4 in your draft. How about trying an updates 2119 and status BCP, where BCP 14 then consists of 2119 and 2119bis, and old RFC 2119 references are still okay as is. Readers with difficulties to figure out what RFC 2119 meant might find the confirmed erratum and the updated by 2119bis with better answers. Authors could use RFC 2119, 2119bis, or even BCP 14 in the references of new documents, where BCP 14 would be new, IIRC RFC 2119 did not permit this -- fearing precisely what is happening now, somebody trying to update critical terms. I think that your new definitions match precisely what RFC 2119 wanted, but I'm also almost sure that some old 2119 clients will disagree. -Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
30.08.2011 3:08, Mark Nottingham wrote: Thanks for starting this, Peter. A few comments / topics for discussion: 1) I agree that the SHOULD... UNLESS pattern ought be documented. I think 2119bis should discuss use of the keywords in conditional clauses, how to interpret something like a MUST be set to b if c is d, or a SHOULD be b if c and SHOULD be d if e etc. Defining the keyword ... IF/keyword ... UNLESS constructions for all of them? 2) I strongly believe that authors should be encouraged to enumerate the potential subjects of conformance terms, and to use them in every instance. For example, a requirement like this: The Foo header MUST contain the bar directive is ambiguous; it doesn't specify who has to do what. Rather, Senders MUST include the bar directive when producing the Foo header; recipients that receive a Foo header without a bar directive MUST ... is unambiguous (assuming that the spec defines the terms sender and recipient). +1. 3) It may be worth further cautioning against over-use of MAY; this is the most-abused term, IME. Perhaps encouraging people to make requirements testable on the wire would help. My personal observation is that MAY is often used in sense of can, i.e. to designate possibility rather than optionality. So 2119bis should be clear that MAY is used for describing discretionary actions/behavior, and those authors who wish to denote possible action should use can, which shouldn't be included in the repertoire as being irrelevant to conformance. 4) WRT to the status of the document -- if people really feel that we don't need to revise 2119, I'd define this as a superset of 2119 and NOT obsolete it; i.e., have documents opt into it. However, I'd hope that we can get consensus that it's time to build on what 2119 offers. See my previous message. Mykyta Yevstifeyev Cheers, On 30/08/2011, at 7:36 AM, Peter Saint-Andre wrote: After staring at http://www.rfc-editor.org/errata_search.php?eid=499 for long enough, I finally decided to submit an I-D that is intended to obsolete RFC 2119. I hope that I've been able to update and clarify the text in a way that is respectful of the original. Feedback is welcome. http://www.ietf.org/id/draft-saintandre-2119bis-01.txt Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 30 aug 2011, at 9:22, Henk Uijterwaal wrote: That is a 4.5 year difference in when the exact date is announced. This increase the risk that there is a clash with another meeting and people cannot plan much in advance. Come on, the idea that people need to know the date of a meeting more than 1.5 years out or they won't be able to plan their attendance is ridiculous. I don't even know which country I'll be living in 1.5 years from now. You also only look at the situation where the dates are completely open until after the venue negotiations are complete. I don't think we need to go that far, we could start by selecting two weeks long in advance and then choosing between those as the negotiations happen. This could be especially useful for a meeting in a region where more contraints than usual are expected. The question is what we, as a community, want: dates known early or flexibility to select the best venue at a late stage. I can only speak for myself, but $300/night is a big problem for me. I have no problem staying in non-official hotels, but obviously that only works when those are available and have more reasonable prices. Then again, I don't need to go to _every_ IETF meeting (I think I'm at 12 meetings in 9 years now) so I'm ok having a mix of cheaper and more expensive meetings. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Routing at the Edges of the Internet
On 30/Aug/11 04:50, Michel Py wrote: The mechanism (ICMP redirects) is technically fine and socially not. People have become paranoid and now they firewall everything. It is a behavioral animal. I'm not saying it's a good idea; the market answer to crossing firewalls is to encapsulate everything into HTTPS, which is probably worse. But then again, we have to deal with market pressure against technically sound solutions, and the market almost always wins. That brings us back to the problem that free routing is apparently insecure. OTOH, there are large expectations from RIRs and network providers, about security and policy routing, especially on port 25. On closer inspection, though, those chaps don't seem to be eager to play net-cops. Should we go for secure routing, now that we have secure DNS? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Scheduling years in advance [Re: voting system for future venues?]
On 2011-08-30 22:04, Iljitsch van Beijnum wrote: On 30 aug 2011, at 9:22, Henk Uijterwaal wrote: That is a 4.5 year difference in when the exact date is announced. This increase the risk that there is a clash with another meeting and people cannot plan much in advance. Come on, the idea that people need to know the date of a meeting more than 1.5 years out or they won't be able to plan their attendance is ridiculous. I don't even know which country I'll be living in 1.5 years from now. That isn't the point. It's to avoid clashes with IEEE, ITU-T, W3C and numerous others standards bodies that have overlapping participants. There were constant problems in the past, until we went to the current advance scheduling. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Scheduling years in advance [Re: voting system for future venues?]
That isn't the point. It's to avoid clashes with IEEE, ITU-T, W3C and numerous others standards bodies that have overlapping participants. There were constant problems in the past, until we went to the current advance scheduling. Understood. But I wonder of we've forgotten the original motivation for this rule and it has become an unchangable slogan (e.g., four legs good, two legs bad) If, in fact, a date we've chosen turns out to be problematic in terms of getting a good site, the IAOC should consider (emphasis on *consider*) whether an alternate date would be better. Of course, such a change in date should not be done lightly. And it should not be done with out checking with the specific organizations we try to avoid clashes with, etc. But to say the dates are fixed and immovable no matter what seems unhelpful. At the plenary, I recall it being said that for one of the upcoming asian meetings, the exact dates were problematical, and alternate dates would have had better options/rates. When I suggested privately to the IAOC that they should *consider* changing the date, I got (what to me) felt like one big knee jerk we can't change the dates, period. Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Scheduling years in advance [Re: voting system for future venues?]
On Tue, Aug 30, 2011 at 8:33 AM, Thomas Narten nar...@us.ibm.com wrote: That isn't the point. It's to avoid clashes with IEEE, ITU-T, W3C and numerous others standards bodies that have overlapping participants. There were constant problems in the past, until we went to the current advance scheduling. Understood. But I wonder of we've forgotten the original motivation for this rule and it has become an unchangable slogan (e.g., four legs good, two legs bad) If, in fact, a date we've chosen turns out to be problematic in terms of getting a good site, the IAOC should consider (emphasis on *consider*) whether an alternate date would be better. Of course, such a change in date should not be done lightly. And it should not be done with out checking with the specific organizations we try to avoid clashes with, etc. But to say the dates are fixed and immovable no matter what seems unhelpful. At the plenary, I recall it being said that for one of the upcoming asian meetings, the exact dates were problematical, and alternate dates would have had better options/rates. When I suggested privately to the IAOC that they should *consider* changing the date, I got (what to me) felt like one big knee jerk we can't change the dates, period. As we move the meeting scheduling window from 1.5 years out to 3 years, I think that that is one of the things we should consider when necessary. Of course, hopefully that same move will make it less necessary. Regards Marshall Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Dear Eric; I support adding the SHOULD ... UNLESS formalism (although maybe it should be MUST... UNLESS). It would be useful as there will be times where the UNLESS can be specified and has been given due consideration at the time of writing. That, however, will not always be the case. (More inline). On Mon, Aug 29, 2011 at 10:44 PM, Eric Burger ebur...@standardstrack.comwrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. But how about SHOULD do FOO UNLESS you have given serious consideration as to the consequences of not doing FOO. Isn't that really the original intention of SHOULD ? Do we gain anything if that is added every time it is used? I would offer that ANY construction of SHOULD without an UNLESS is a MAY. How about this as a counterexample. In London, you MAY use the tube for transport. Given the weather, you SHOULD carry an umbrella. This SHOULD and MAY convey different things, in a way that I would argue is useful, and enumerating a list of UNLESSes is not going to be exhaustive. Unless of course one considers us the Protocol Nanny's(tm) - if do not do a SHOULD, we will send you to bed without your treacle! Now, now, now. This is the IETF. We use cookies for motivation. Regards Marshall I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY. On Aug 29, 2011, at 9:47 PM, ned+i...@mauve.mrochek.com wrote: Hi - From: Eric Burger eburge...@standardstrack.com To: Narten Thomas nar...@us.ibm.com; Saint-Andre Peter stpe...@stpeter.im Cc: IETF discussion list ietf@ietf.org Sent: Monday, August 29, 2011 3:08 PM Subject: Re: 2119bis I would assume in the text of the document. This paragraph is simply an enumeration of Burger's Axiom: For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a MAY. I disagree. I concur with your disagreement. SHOULD should *not* be used when the list of exceptions is known and practically enumerable. If the UNLESS cases can be fully enumerated, then SHOULD x UNLESS y is equivalent to WHEN NOT y MUST X. (Both beg the question of whether we would need to spell out that WHEN y MUST NOT X is not necessarily an appropriate inference.) RFC 2119 SHOULD is appropriate when the UNLESS cases are known (or suspected) to exist, but it is not practical to exhaustively identify them all. Let's not gild this lily. +1 Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Routing at the Edges of the Internet
You could start by looking at MANET work, both in the WG of that name and work outside the IETF under that name and as ad hoc networks (the mobile in MANET can be misleading, D for dynamic might be mor to the point) and mesh networks. There are real networks (such as the Freifunk network in Germany) that do some of what you are talking about, and use protocols based on IETF work. (Freifunk uses OLSR - RFC 3626 - and intends, as I understand, to use OLSRv2, once we manage to finish it.) Note: I'm an author of OLSRv2, but have no connection to Freifunk. There are more issues, some of which you touch on, such as with regard to addressing issues (the MANET WG is about routing). The AUTOCONF WG was intended to address these but that has not been a great success. Nor am I claiming MANET has produced all the answers to all the routing-related problems. Part of what's missing is rationale and explanatory material explaining how you can do more than might be obvious with what does exist. (There are RFCs 2501 and 5889, but there is more material known to people working in these areas than those capture.) -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Adam Novak Sent: 26 August 2011 02:58 To: ietf@ietf.org Subject: Routing at the Edges of the Internet *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. I trust that some of you have seen this article from a while back: http://moblog.wiredwings.com/archives/20110315/How-We-Killed-The-Intern et-And-Nobody-Noticed.html An informative except: When I open my laptop, I see over ten different wifi access points. Say I wanted to send data to my friend in the flat next to mine. It is idiotic that nowadays, I would use the bottleneck subscriber line to my upstream ISP and my crippled upload speed and push it all the way across their infrastructure to my neighbors ISP and back to the Wifi router in reach of mine. The Internet is not meant to be used that way. Instead, all these wifi networks should be configured to talk to each other. I also trust that you are aware of what happened to the Internet in Egypt (and elsewhere) this spring, where Internet connectivity was disrupted by shutting down major ISP networks. I would like to bring the attention of the IETF to what I see as a fundamental problem with the current architecture of the Internet: The Internet is not a network. As part of the development of the Internet, fault-tolerant routing protocols have been developed that allow a connecdestined fortion to be maintained, even if the link that was carrying goes down, by routing packets around the problem. Similarly, packets can be load-balanced over multiple links for increased bandwidth. However, the benefits of these technologies are not available to end users. If I have a smartphone with both a 3G and a Wi-Fi connection, downloads cannot currently be load-balanced across them. The two interfaces are on two different networks, which are almost certainly part of two different autonomous systems. Packets must be addressed to one of the two interfaces, not the device, and packets addressed to one interface have no way to be routed to the other. Similar problems arise when a laptop has both a wired and a wireless connection. Wired networks also suffer from related difficulties: If I have Verizon and my friend has Comcast, and we string an Ethernet cable between our houses, packets for me will still all come down my connection, and packets for my friend will still all come down theirs. The Internet, as it currently appears to end-users, has a logical tree topology: computers connect to your home router, which connects to your ISP, which connects to the rest of the Internet. Cell phones connect to the tower, which connects through a backhaul link to the rest of the Internet. Almost all of the devices involved have multiple physical interfaces and full IP routing implementations, but only the default route is ever used. This results in a brittle Internet: the failure of one ISP router can disconnect a large number of end-users from the Internet, as well as interrupting communication between those users, even when those users are, physically, only a few feet from each other. My question is this: what IETF work would be needed to add more routing to the edges of the Internet? If each home or mobile device was essentially it's own autonomous
Re: 2119bis
+1, too. This goes along with my strong desire to eliminate passive voice, unless the goal is to have the actor be obfuscated (as an example). On Aug 30, 2011, at 5:29 AM, Mykyta Yevstifeyev wrote: 2) I strongly believe that authors should be encouraged to enumerate the potential subjects of conformance terms, and to use them in every instance. For example, a requirement like this: The Foo header MUST contain the bar directive is ambiguous; it doesn't specify who has to do what. Rather, Senders MUST include the bar directive when producing the Foo header; recipients that receive a Foo header without a bar directive MUST ... is unambiguous (assuming that the spec defines the terms sender and recipient). +1. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: Dear Eric; I support adding the SHOULD ... UNLESS formalism (although maybe it should be MUST... UNLESS). It would be useful as there will be times where the UNLESS can be specified and has been given due consideration at the time of writing. That, however, will not always be the case. (More inline). [snip] But how about SHOULD do FOO UNLESS you have given serious consideration as to the consequences of not doing FOO. Isn't that really the original intention of SHOULD ? Do we gain anything if that is added every time it is used? Looking at this from a protocol perspective, SHOULD now equals MAY. There is no objective way of deciding when to do FOO or not. [snip] smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
I would offer that working groups that say to do something that may or may not hold in foreseen or unforeseen circumstances is most likely working on a protocol that is way too complex and is begging for interoperability problems. What ever happened to building simple, point-solution protocols that followed the hour-glass and end-to-end principles, and then building your complex protocols out of them? On Aug 29, 2011, at 11:11 PM, Keith Moore wrote: On Aug 29, 2011, at 10:44 PM, Eric Burger wrote: I would offer that ANY construction of SHOULD without an UNLESS is a MAY. The essential beauty of SHOULD is that it gets specification writers and working groups out of the all-too-common rathole of trying to anticipate and nail down every exceptional case. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. Keith On Aug 30, 2011, at 9:51 AM, Eric Burger wrote: I would offer that working groups that say to do something that may or may not hold in foreseen or unforeseen circumstances is most likely working on a protocol that is way too complex and is begging for interoperability problems. What ever happened to building simple, point-solution protocols that followed the hour-glass and end-to-end principles, and then building your complex protocols out of them? On Aug 29, 2011, at 11:11 PM, Keith Moore wrote: On Aug 29, 2011, at 10:44 PM, Eric Burger wrote: I would offer that ANY construction of SHOULD without an UNLESS is a MAY. The essential beauty of SHOULD is that it gets specification writers and working groups out of the all-too-common rathole of trying to anticipate and nail down every exceptional case. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: I support adding the SHOULD ... UNLESS formalism (although maybe it should be MUST... UNLESS). It would be useful as there will be times where the UNLESS can be specified and has been given due consideration at the time of writing. That, however, will not always be the case. (More inline). How would SHOULD...UNLESS or MUST...UNLESS differ from using the current 2119 definitions and just writing SHOULD...unless or MUST ... unless? Personally I think 2119 is just fine and doesn't need to be updated. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
This sentiment mostly makes sense. If an endpoint expects SHOULD/MAY items implemented as MUSTs on the remote end, then one should slap the endpoint developer silly. Read the RFC! If it says SHOULD/MAY, then your implementation MUST be able to handle the feature present *and* absent. Note that every SHOULD/MAY in a specification introduces cyclomatic complexity. Every SHOULD/MAY results in at least one if statement, to test the presence or absence of the feature in the remote end. Protocols will be much simpler to implement. Moreover, given the results in the software engineering literature that indicate latent defects appear super-linearly with cyclomatic complexity, protocols without (or a minimum) of SHOULD/MAY features will have fewer defects in the field. Remember, we are working on Internet protocols, where a one-in-a-million corner case happens many times per day. On Aug 30, 2011, at 4:00 AM, HLS wrote: On 8/30/11, Murray S. Kucherawy m...@cloudmark.com wrote: Mark Nottingham: 1) I agree that the SHOULD... UNLESS pattern ought be documented. I had never thought of this before. I kind of like the idea, especially since SHOULD has always meant MUST unless you really know what you're doing Such an odd reading. Does it mean you MUST because you could not handle it otherwise? It takes two to tango. One side reasons can be different than the other. If a software breaks down because it read SHOULD as a MUST and expected the other end will also view is a MUST, then it didn't know what it was doing. Things break down. Implementors on either side can't depend on it and need to function in lieu of it. There is always the possibility one decided Na, not needed, not worth the cost. Its not required. etc, and no one should die because of that decision. I think it MUST be noted that a Minimum Implementation for a protocol is all anyone can expect. If a SHOULD item is among the listed minimum requirements, it MUST be removed from the list or changed to a MUST. Maybe the term Minimum Implementation (is part of, is not part of) can be incorporated into each of the key word text. -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 9:56 AM, Eric Burger wrote: Every SHOULD/MAY results in at least one if statement, to test the presence or absence of the feature in the remote end. false. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Strictly speaking, you are correct, in that if one interprets SHOULD/MAY as 'not bother', one does not need to check, unless the presence of the remote end doing the feature results in your barfing. However, if one interprets SHOULD/MAY as 'bother', then one most likely needs to check on the capabilities of the far end or handle the varying data elements or protocol states that will or will not happen. On Aug 30, 2011, at 9:58 AM, Keith Moore wrote: On Aug 30, 2011, at 9:56 AM, Eric Burger wrote: Every SHOULD/MAY results in at least one if statement, to test the presence or absence of the feature in the remote end. false. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 06:54 AM, Keith Moore wrote: I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. But using SHOULD does not make the implementation less complex, it simply decreases the complexity for the *author* and increases the probability that two independent implementations will have interoperability problems. As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT RECOMMENDED. Keith On Aug 30, 2011, at 9:51 AM, Eric Burger wrote: I would offer that working groups that say to do something that may or may not hold in foreseen or unforeseen circumstances is most likely working on a protocol that is way too complex and is begging for interoperability problems. What ever happened to building simple, point-solution protocols that followed the hour-glass and end-to-end principles, and then building your complex protocols out of them? On Aug 29, 2011, at 11:11 PM, Keith Moore wrote: On Aug 29, 2011, at 10:44 PM, Eric Burger wrote: I would offer that ANY construction of SHOULD without an UNLESS is a MAY. The essential beauty of SHOULD is that it gets specification writers and working groups out of the all-too-common rathole of trying to anticipate and nail down every exceptional case. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5c8DMACgkQ9RoMZyVa61dv/ACfRCGdkyioOtkcLOR5P5AT7EGE y/gAn2LtqRUztE/HJEpTAMuY2eoVrRjp =VFmG -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 8/30/11, Keith Moore mo...@network-heretics.com wrote: On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: Personally I think 2119 is just fine and doesn't need to be updated. Keith +1 -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 10:13 AM, Eric Burger wrote: On Aug 30, 2011, at 9:58 AM, Keith Moore wrote: On Aug 30, 2011, at 9:56 AM, Eric Burger wrote: Every SHOULD/MAY results in at least one if statement, to test the presence or absence of the feature in the remote end. false. Strictly speaking, you are correct, in that if one interprets SHOULD/MAY as 'not bother', one does not need to check, unless the presence of the remote end doing the feature results in your barfing. However, if one interprets SHOULD/MAY as 'bother', then one most likely needs to check on the capabilities of the far end or handle the varying data elements or protocol states that will or will not happen. SHOULD/MAY is used for many other cases than whether to implement a protocol feature that changes how the protocol works as viewed by its peer. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 06:54 AM, Keith Moore wrote: I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. But using SHOULD does not make the implementation less complex, it simply decreases the complexity for the *author* and increases the probability that two independent implementations will have interoperability problems. To the extent that SHOULD is causing interoperability problems, it may be that some authors are misusing SHOULD. But it's not an inherent problem with SHOULD. As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT RECOMMENDED. I'm an implementor also, and I've found SHOULD to be very helpful. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 07:35 AM, Keith Moore wrote: On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 06:54 AM, Keith Moore wrote: I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. But using SHOULD does not make the implementation less complex, it simply decreases the complexity for the *author* and increases the probability that two independent implementations will have interoperability problems. To the extent that SHOULD is causing interoperability problems, it may be that some authors are misusing SHOULD. But it's not an inherent problem with SHOULD. As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT RECOMMENDED. I'm an implementor also, and I've found SHOULD to be very helpful. Yes, it is very helpful in convincing one's PHB that one does not have to implement something, or in convincing another company to reactivate a feature during interop tests because one did not bother to implement it. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5c+YgACgkQ9RoMZyVa61fVhACeKsjqPX1ckD572A+wpb2AKQA/ 3qUAoJz3M9ORMxmCGksApSlxu5sEQbdk =r9Bf -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 10:54 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 07:35 AM, Keith Moore wrote: On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 06:54 AM, Keith Moore wrote: I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. But using SHOULD does not make the implementation less complex, it simply decreases the complexity for the *author* and increases the probability that two independent implementations will have interoperability problems. To the extent that SHOULD is causing interoperability problems, it may be that some authors are misusing SHOULD. But it's not an inherent problem with SHOULD. As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT RECOMMENDED. I'm an implementor also, and I've found SHOULD to be very helpful. Yes, it is very helpful in convincing one's PHB that one does not have to implement something, or in convincing another company to reactivate a feature during interop tests because one did not bother to implement it. Rather than vaguely attacking SHOULD, maybe it would be more illuminating to cite specific examples? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Limitations in RFC Errata mechanism
Hello all, I've observed several problems with submission mechanism for RFC Errata. Here they are: First, we have only two types of errata - Technical or Editorial. In presence of http://www.ietf.org/iesg/statement/rfc-metadata-errata.html, IESG Statement on IESG Processing of RFC Errata concerning RFC Metadata, I think the third type is necessary - Metadata. Second, the Section field at http://www.rfc-editor.org/errata_report.php implies that only numerical sections will contain something an erratum can be reported against (overlooking the GLOBAL option). However, Appendices, Abstract, Index, Author Info, different Notes exist, that aren't covered here. Third, Original text and Corrected text fields imply that only before-and-after errata may be submitted. However, there might be errata like Erratum # 6 (http://www.rfc-editor.org/errata_search.php?eid=6), with an only Report text field. I understand this feature was present in previous versions of errata mechanism but removed from the current. So, taking this into consideration, some specific proposals: 1) Additional Metedata erratum type. The fields which will be required to be filled in are: (a) metadata type: document source, RFC number, subseries*, obsoletes header*, updates header*, obsoleted-by header*, updated-by header*, category, (b) current value, and (c) correct value. Values marked under * in (a) may be available in the case when such metainfo is present in the RFC. 2) Replace the Section field with the drop-down list containing the following options: Section, Appendix, Abstract, Table of Contents, Note, Author information, Index. In the case of the first two an additional field for number is available; in the case with Note - type of Note (RFC Editor, IESG etc.). 3) Allow user to choose whether they will enter old_text-new_text erratum or single_text erratum. Also, several issues not related to submission mechanism. 1) Specific mailing lists devoted to discussion of errata against RFCs from different areas. I've proposed this on rfc-interest list; see rationale at http://www.rfc-editor.org/pipermail/rfc-interest/2011-August/002672.html.; 2) Users might want to submit comments which could be displayable at erratum's page, similar to the mechanim employed by some IETF WGs in issue trackers. This also includes ability to add myself to cc list. 3) Verified technical errata may be incorporated in the references. Eg. 4 technical errata were reported against RFC 793 and verified; so the reference may be: Postel, J., Transmission Control Protocol, STD 7, RFC 793, September 1981. Ammended by RFC Errata Reports 573, 1562, 1564, 1572. So, further discussion is welcome... Mykyta Yevstifeyev ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 07:58 AM, Keith Moore wrote: On Aug 30, 2011, at 10:54 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 07:35 AM, Keith Moore wrote: On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 06:54 AM, Keith Moore wrote: I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. But using SHOULD does not make the implementation less complex, it simply decreases the complexity for the *author* and increases the probability that two independent implementations will have interoperability problems. To the extent that SHOULD is causing interoperability problems, it may be that some authors are misusing SHOULD. But it's not an inherent problem with SHOULD. As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT RECOMMENDED. I'm an implementor also, and I've found SHOULD to be very helpful. Yes, it is very helpful in convincing one's PHB that one does not have to implement something, or in convincing another company to reactivate a feature during interop tests because one did not bother to implement it. Rather than vaguely attacking SHOULD, maybe it would be more illuminating to cite specific examples? It is difficult because of a mix of NDAs, employment confidentiality agreements and desire to not single out individuals. I'll send you an example in a private email. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5dBA0ACgkQ9RoMZyVa61cu4gCfTBpCbDMdZry14MxAA32zhFe8 oMwAn3dTiHuqO90Kb9SmC0etND8YT9px =Nht0 -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 11:38 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 07:58 AM, Keith Moore wrote: On Aug 30, 2011, at 10:54 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 07:35 AM, Keith Moore wrote: On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 06:54 AM, Keith Moore wrote: I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. But using SHOULD does not make the implementation less complex, it simply decreases the complexity for the *author* and increases the probability that two independent implementations will have interoperability problems. To the extent that SHOULD is causing interoperability problems, it may be that some authors are misusing SHOULD. But it's not an inherent problem with SHOULD. As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT RECOMMENDED. I'm an implementor also, and I've found SHOULD to be very helpful. Yes, it is very helpful in convincing one's PHB that one does not have to implement something, or in convincing another company to reactivate a feature during interop tests because one did not bother to implement it. Rather than vaguely attacking SHOULD, maybe it would be more illuminating to cite specific examples? It is difficult because of a mix of NDAs, employment confidentiality agreements and desire to not single out individuals. I'll send you an example in a private email. I look forward to seeing it. But in general I get the impression that people are attacking SHOULD because of specific problems rather than general problems. Since I find SHOULD very useful, to me it makes more sense to try to outline cases where SHOULD is problematic, and provide advice for those cases, than to try to get rid of it or change what it means. e.g. For the specific case of optional features that must be negotiated, I don't think that SHOULD is the problem. Rather I think that optional features are too common. That's not to say that optional features and feature negotiation are never useful, particularly when extending a protocol that is already well-established in the field. But if making features optional is seen by WGs as a way to avoid making hard decisions about what is required to interoperate, that really is a problem. It just doesn't have anything to do with SHOULD. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
I think you have hit the root cause on the head. I would also offer that by removing the crutch, or raising the bar to using the crutch, will help alleviate the root cause. On Aug 30, 2011, at 11:44 AM, Keith Moore wrote: e.g. For the specific case of optional features that must be negotiated, I don't think that SHOULD is the problem. Rather I think that optional features are too common. That's not to say that optional features and feature negotiation are never useful, particularly when extending a protocol that is already well-established in the field. But if making features optional is seen by WGs as a way to avoid making hard decisions about what is required to interoperate, that really is a problem. It just doesn't have anything to do with SHOULD. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
e.g. SHOULD, SHOULD NOT, RECOMMENDED, and NOT RECOMMENDED are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them. However, they should not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure. On Aug 30, 2011, at 11:46 AM, Eric Burger wrote: I think you have hit the root cause on the head. I would also offer that by removing the crutch, or raising the bar to using the crutch, will help alleviate the root cause. On Aug 30, 2011, at 11:44 AM, Keith Moore wrote: e.g. For the specific case of optional features that must be negotiated, I don't think that SHOULD is the problem. Rather I think that optional features are too common. That's not to say that optional features and feature negotiation are never useful, particularly when extending a protocol that is already well-established in the field. But if making features optional is seen by WGs as a way to avoid making hard decisions about what is required to interoperate, that really is a problem. It just doesn't have anything to do with SHOULD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 08:44 AM, Keith Moore wrote: On Aug 30, 2011, at 11:38 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 07:58 AM, Keith Moore wrote: On Aug 30, 2011, at 10:54 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 07:35 AM, Keith Moore wrote: On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 06:54 AM, Keith Moore wrote: I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. But using SHOULD does not make the implementation less complex, it simply decreases the complexity for the *author* and increases the probability that two independent implementations will have interoperability problems. To the extent that SHOULD is causing interoperability problems, it may be that some authors are misusing SHOULD. But it's not an inherent problem with SHOULD. As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT RECOMMENDED. I'm an implementor also, and I've found SHOULD to be very helpful. Yes, it is very helpful in convincing one's PHB that one does not have to implement something, or in convincing another company to reactivate a feature during interop tests because one did not bother to implement it. Rather than vaguely attacking SHOULD, maybe it would be more illuminating to cite specific examples? It is difficult because of a mix of NDAs, employment confidentiality agreements and desire to not single out individuals. I'll send you an example in a private email. I look forward to seeing it. But in general I get the impression that people are attacking SHOULD because of specific problems rather than general problems. Since I find SHOULD very useful, to me it makes more sense to try to outline cases where SHOULD is problematic, and provide advice for those cases, than to try to get rid of it or change what it means. The meaning of SHOULD is clear for the authors (it mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.), the problem is that some implementers use a different meaning (I do not have to implement this if it is inconvenient or difficult for me to implement), vendors another one (SHOULD gave us the right to not implement it). I even read somewhere, perhaps on this list, about a vendor that rejected any bug report against a SHOULD. Conditional MUST, in my opinion, does not have this problem. e.g. For the specific case of optional features that must be negotiated, I don't think that SHOULD is the problem. Rather I think that optional features are too common. That's not to say that optional features and feature negotiation are never useful, particularly when extending a protocol that is already well-established in the field. But if making features optional is seen by WGs as a way to avoid making hard decisions about what is required to interoperate, that really is a problem. It just doesn't have anything to do with SHOULD. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5dCosACgkQ9RoMZyVa61e8iwCfZccbWf20L0VaDtBFH6ekmhm5 l30AoJmTDscY/dAGwjfU3toAnydGZHft =pbTY -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Tue, 2011-08-30, Keith Moore wrote: But in general I get the impression that people are attacking SHOULD because of specific problems rather than general problems. Since I find SHOULD very useful, to me it makes more sense to try to outline cases where SHOULD is problematic, and provide advice for those cases, than to try to get rid of it or change what it means. e.g. For the specific case of optional features that must be negotiated, I don't think that SHOULD is the problem. Rather I think that optional features are too common. That's not to say that optional features and feature negotiation are never useful, particularly when extending a protocol that is already well-established in the field. But if making features optional is seen by WGs as a way to avoid making hard decisions about what is required to interoperate, that really is a problem. It just doesn't have anything to do with SHOULD. How about recommending SHOULD ... BECAUSE to encourage the author to justify the SHOULD. I suspect that this would reduce the number of SHOULDs, that would be better as MAYs, due to the author's personal preference. My impression is that the 2119 limitation on MUST and SHOULD for only necessary protocol features is sometimes forgotten. -- Bill McQuillan mcqui...@pobox.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: The meaning of SHOULD is clear for the authors (it mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.), the problem is that some implementers use a different meaning (I do not have to implement this if it is inconvenient or difficult for me to implement), vendors another one (SHOULD gave us the right to not implement it). I even read somewhere, perhaps on this list, about a vendor that rejected any bug report against a SHOULD. Conditional MUST, in my opinion, does not have this problem. But conditional MUST has other problems, namely that you have to enumerate the exceptions for the MUST, and that's not always practical. Implementors who think that SHOULD gives them a free pass to avoid implementing something that's needed to interoperate are misreading 2119. But document editors should avoid using SHOULD for cases where failure to implement the requirement will result in interoperability failure. I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea. And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 08/30/2011 06:07 PM, Bill McQuillan wrote: How about recommending SHOULD ... BECAUSE to encourage the author to justify the SHOULD. +1 Although saying something like this should do: If there's a SHOULD clause in the document, the document MUST provide background and rationale for making the behaviour optional. For an implementor it's often pretty hard to decide whether to implement functionality marked as SHOULD given that he has zero context and no idea whether the reason he has for not implementing the feature is at all in line with RFC authors' intentions. Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 09:11 AM, Keith Moore wrote: On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: The meaning of SHOULD is clear for the authors (it mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.), the problem is that some implementers use a different meaning (I do not have to implement this if it is inconvenient or difficult for me to implement), vendors another one (SHOULD gave us the right to not implement it). I even read somewhere, perhaps on this list, about a vendor that rejected any bug report against a SHOULD. Conditional MUST, in my opinion, does not have this problem. But conditional MUST has other problems, namely that you have to enumerate the exceptions for the MUST, and that's not always practical. Implementors who think that SHOULD gives them a free pass to avoid implementing something that's needed to interoperate are misreading 2119. But document editors should avoid using SHOULD for cases where failure to implement the requirement will result in interoperability failure. I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea. And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents. I like your definition a previous email, so perhaps an alternative solution to updating 2119 is for authors who really care about this subject is to integrate it in the Terminology section, something like this: 2. Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119]. SHOULD, SHOULD NOT, RECOMMENDED, and NOT RECOMMENDED are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them. However, they should not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5dDYkACgkQ9RoMZyVa61fA6gCfYTawSM53Uy7okAgidhSyQZzH 8JUAn3AwH0wz96A9K2EfyALIsVkjAFJP =L35E -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 12:07 PM, Bill McQuillan wrote: On Tue, 2011-08-30, Keith Moore wrote: But in general I get the impression that people are attacking SHOULD because of specific problems rather than general problems. Since I find SHOULD very useful, to me it makes more sense to try to outline cases where SHOULD is problematic, and provide advice for those cases, than to try to get rid of it or change what it means. e.g. For the specific case of optional features that must be negotiated, I don't think that SHOULD is the problem. Rather I think that optional features are too common. That's not to say that optional features and feature negotiation are never useful, particularly when extending a protocol that is already well-established in the field. But if making features optional is seen by WGs as a way to avoid making hard decisions about what is required to interoperate, that really is a problem. It just doesn't have anything to do with SHOULD. How about recommending SHOULD ... BECAUSE to encourage the author to justify the SHOULD. I suspect that this would reduce the number of SHOULDs, that would be better as MAYs, due to the author's personal preference. I think 1122 and 1123 did this very well. State the general requirement briefly in terms of MUST or SHOULD or whatever, then follow that by an explanation written in normal language. What I see far too often these days is an attempt to write both complicated requirements and the explanations in terms of 2119 conditional keywords. This makes the requirements difficult for an implementor to understand and perhaps more ambiguous than was intended. My impression is that the 2119 limitation on MUST and SHOULD for only necessary protocol features is sometimes forgotten. This is actually one case where I think 2119 misstated things. The problem is that it's not just protocol features (as viewed on the wire) that matter in practice. SHOULD and its friends are really useful for cases where you can't precisely nail down what should happen on every particular platform on which the protocol might be implemented, but it's quite reasonable to state the intent. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security On Aug 30, 2011, at 12:11 PM, Keith Moore wrote: On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: The meaning of SHOULD is clear for the authors (it mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.), the problem is that some implementers use a different meaning (I do not have to implement this if it is inconvenient or difficult for me to implement), vendors another one (SHOULD gave us the right to not implement it). I even read somewhere, perhaps on this list, about a vendor that rejected any bug report against a SHOULD. Conditional MUST, in my opinion, does not have this problem. But conditional MUST has other problems, namely that you have to enumerate the exceptions for the MUST, and that's not always practical. Implementors who think that SHOULD gives them a free pass to avoid implementing something that's needed to interoperate are misreading 2119. But document editors should avoid using SHOULD for cases where failure to implement the requirement will result in interoperability failure. I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea. And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Umm, wait. I'm confused. The boilerplate in existing documents points to 2119, right? and the updated boilerplate would point to this spec, if approved, right? so we're not retroactively changing the meaning of anything, right? What am I missing? Spencer - Original Message - From: Keith Moore To: Marc Petit-Huguenin Cc: IETF discussion list ; Eric Burger Sent: Tuesday, August 30, 2011 11:11 AM Subject: Re: 2119bis I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea. And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents. Keith -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
In the perfect written technical specification, if you pulled out all the SHOULDs, the protocol still survives. But if a required functionality breaks down, then it wasn't well written. On 8/30/11, Eric Burger ebur...@standardstrack.com wrote: Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security On Aug 30, 2011, at 12:11 PM, Keith Moore wrote: On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: The meaning of SHOULD is clear for the authors (it mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.), the problem is that some implementers use a different meaning (I do not have to implement this if it is inconvenient or difficult for me to implement), vendors another one (SHOULD gave us the right to not implement it). I even read somewhere, perhaps on this list, about a vendor that rejected any bug report against a SHOULD. Conditional MUST, in my opinion, does not have this problem. But conditional MUST has other problems, namely that you have to enumerate the exceptions for the MUST, and that's not always practical. Implementors who think that SHOULD gives them a free pass to avoid implementing something that's needed to interoperate are misreading 2119. But document editors should avoid using SHOULD for cases where failure to implement the requirement will result in interoperability failure. I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea. And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 12:46 PM, Eric Burger wrote: Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security That wording doesn't make any sense. Security implementation should almost always be a MUST, regardless of what any particular government might say. We shouldn't relax the security requirements of our protocols because of brain-damaged governments (and I include my own country's government in that list). In cases like this it's sometimes important to distinguish between implementation and use. MUST implement, SHOULD use is a common compromise. Note also that MUST doesn't mean you have to do this. It means if you don't do this, you don't comply with the specification. I don't think the example above is a typical use of SHOULD, though it might be too common. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 1:11 PM, Spencer Dawkins wrote: Umm, wait. I'm confused. The boilerplate in existing documents points to 2119, right? and the updated boilerplate would point to this spec, if approved, right? so we're not retroactively changing the meaning of anything, right? What am I missing? If 2119 were to be updated, that's how it should work. If we're going to retroactively clarify the meanings of the keywords, that should probably be done on a per-document basis. (here's what we really meant when we said SHOULD in RFC ...) I think it's very premature to assume that 2119 will be updated. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of HLS Sent: Tuesday, August 30, 2011 1:00 AM To: IETF discussion list Subject: Re: 2119bis I had never thought of this before. I kind of like the idea, especially since SHOULD has always meant MUST unless you really know what you're doing Such an odd reading. Does it mean you MUST because you could not handle it otherwise? I'm sorry if you think it's odd, but it's correct. Read RFC2119 again: 3. SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Note the language MUST implement, SHOULD use is a common compromise. ^^^ This is my heartache. Why is it a compromise? Most use of SHOULD I run into in WG's is either this precise one: I don't want to make this a MUST use, because I will have deployments *THAT ARE NOT FOR THE INTERNET* but I want to market them as if they were. Example: instant messaging systems for enterprises where tapping is a legal requirement, not something to be avoided. Example: instant messaging systems deployed where governments want to do warrantless, undetectable tapping I would offer neither of these examples are Internet examples, and we should get some iron underpants on and say so. Internet protocols need Internet protections. SHOULD should neither be a crutch for making a proprietary protocol look like an Internet protocol nor for making two proprietary protocols look like a single, Internet protocol. On Aug 30, 2011, at 1:50 PM, Keith Moore wrote: On Aug 30, 2011, at 12:46 PM, Eric Burger wrote: Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security That wording doesn't make any sense. Security implementation should almost always be a MUST, regardless of what any particular government might say. We shouldn't relax the security requirements of our protocols because of brain-damaged governments (and I include my own country's government in that list). In cases like this it's sometimes important to distinguish between implementation and use. MUST implement, SHOULD use is a common compromise. Note also that MUST doesn't mean you have to do this. It means if you don't do this, you don't comply with the specification. I don't think the example above is a typical use of SHOULD, though it might be too common. Keith smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Tuesday, August 30, 2011 7:35 AM To: Marc Petit-Huguenin Cc: IETF discussion list; Eric Burger Subject: Re: 2119bis To the extent that SHOULD is causing interoperability problems, it may be that some authors are misusing SHOULD. But it's not an inherent problem with SHOULD. [...] I'm an implementor also, and I've found SHOULD to be very helpful. +1 to both points. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 09:11 AM, Keith Moore wrote: On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: The meaning of SHOULD is clear for the authors (it mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.), the problem is that some implementers use a different meaning (I do not have to implement this if it is inconvenient or difficult for me to implement), vendors another one (SHOULD gave us the right to not implement it). I even read somewhere, perhaps on this list, about a vendor that rejected any bug report against a SHOULD. Conditional MUST, in my opinion, does not have this problem. But conditional MUST has other problems, namely that you have to enumerate the exceptions for the MUST, and that's not always practical. No, you just have to list the known cases. Here's an example of a SHOULD that creates a lot of problems. This is from RFC 1889 (RFC 3550 has a slightly better statement, but the damage was done by the time it was published): Functions 1-3 [i.e. RTCP feedback, RTCP CNAME and RTCP rate limit] are mandatory when RTP is used in the IP multicast environment, and are recommended for all environments. If I remember correctly the reason was that it is not always possible for the receiver to send back the RR packets, for example on satellite links. But VoIP implementations more or less all decided to not implement RTCP using this statement (feedback is very important even on unicast RTP for congestion control). A conditional MUST could have been written this way: Functions 1-3 are mandatory for all environments that permit a channel back to the sender. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5dKFgACgkQ9RoMZyVa61d7ZACgn3U/lqN14YWy3TPGArqtN7AO yrwAmwcccGVHNOm0AsbeUIdj/0MxFG1p =91cE -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
It seems to me RFC2119bis might benefit from some consensus text on what proper use of each is, beyond defining their respective meanings. From the discussion, this is obviously true for SHOULD at least. The discussion around use of MAY in RFC2119 is fairly thorough, so maybe SHOULD needs to be similarly expanded. And I suspect some distillation of this discussion might provide some ideal text. -MSK From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric Burger Sent: Tuesday, August 30, 2011 11:03 AM To: IETF discussion list Subject: Re: 2119bis Note the language MUST implement, SHOULD use is a common compromise. ^^^ This is my heartache. Why is it a compromise? Most use of SHOULD I run into in WG's is either this precise one: I don't want to make this a MUST use, because I will have deployments *THAT ARE NOT FOR THE INTERNET* but I want to market them as if they were. Example: instant messaging systems for enterprises where tapping is a legal requirement, not something to be avoided. Example: instant messaging systems deployed where governments want to do warrantless, undetectable tapping I would offer neither of these examples are Internet examples, and we should get some iron underpants on and say so. Internet protocols need Internet protections. SHOULD should neither be a crutch for making a proprietary protocol look like an Internet protocol nor for making two proprietary protocols look like a single, Internet protocol. On Aug 30, 2011, at 1:50 PM, Keith Moore wrote: On Aug 30, 2011, at 12:46 PM, Eric Burger wrote: Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security That wording doesn't make any sense. Security implementation should almost always be a MUST, regardless of what any particular government might say. We shouldn't relax the security requirements of our protocols because of brain-damaged governments (and I include my own country's government in that list). In cases like this it's sometimes important to distinguish between implementation and use. MUST implement, SHOULD use is a common compromise. Note also that MUST doesn't mean you have to do this. It means if you don't do this, you don't comply with the specification. I don't think the example above is a typical use of SHOULD, though it might be too common. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 2:02 PM, Eric Burger wrote: Note the language MUST implement, SHOULD use is a common compromise. ^^^ This is my heartache. Why is it a compromise? Most use of SHOULD I run into in WG's is either this precise one: I don't want to make this a MUST use, because I will have deployments *THAT ARE NOT FOR THE INTERNET* but I want to market them as if they were. Example: instant messaging systems for enterprises where tapping is a legal requirement, not something to be avoided. Example: instant messaging systems deployed where governments want to do warrantless, undetectable tapping I would offer neither of these examples are Internet examples, and we should get some iron underpants on and say so. Mumble. I fundamentally don't buy the argument that things that are used on both local networks and the Internet should not be subject to Internet-strength security. And even where recording is a legal requirement, that's NOT an argument for sending traffic in cleartext or with weak encryption. That might be an argument for some kind of backdoor - e.g. a trusted proxy or key escrow or whatever, but it's not an argument for making the traffic available for those without a legal need to see it. SHOULD should neither be a crutch for making a proprietary protocol look like an Internet protocol nor for making two proprietary protocols look like a single, Internet protocol. agree. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
We violently agree. However, the most cited reason I get for watering down security requirements are what I mentioned below. On Aug 30, 2011, at 2:19 PM, Keith Moore wrote: On Aug 30, 2011, at 2:02 PM, Eric Burger wrote: Note the language MUST implement, SHOULD use is a common compromise. ^^^ This is my heartache. Why is it a compromise? Most use of SHOULD I run into in WG's is either this precise one: I don't want to make this a MUST use, because I will have deployments *THAT ARE NOT FOR THE INTERNET* but I want to market them as if they were. Example: instant messaging systems for enterprises where tapping is a legal requirement, not something to be avoided. Example: instant messaging systems deployed where governments want to do warrantless, undetectable tapping I would offer neither of these examples are Internet examples, and we should get some iron underpants on and say so. Mumble. I fundamentally don't buy the argument that things that are used on both local networks and the Internet should not be subject to Internet-strength security. And even where recording is a legal requirement, that's NOT an argument for sending traffic in cleartext or with weak encryption. That might be an argument for some kind of backdoor - e.g. a trusted proxy or key escrow or whatever, but it's not an argument for making the traffic available for those without a legal need to see it. SHOULD should neither be a crutch for making a proprietary protocol look like an Internet protocol nor for making two proprietary protocols look like a single, Internet protocol. agree. Keith smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Limitations in RFC Errata mechanism
On 8/30/2011 11:19 AM, Mykyta Yevstifeyev wrote: Hello all, I've observed several problems with submission mechanism for RFC Errata. Here they are: First, we have only two types of errata - Technical or Editorial. In presence of http://www.ietf.org/iesg/statement/rfc-metadata-errata.html, IESG Statement on IESG Processing of RFC Errata concerning RFC Metadata, I think the third type is necessary - Metadata. I agree with this part of the proposal, at least. -- Wes Eddy MTI Systems ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Its not correct if its doesn't state it how you interpreted it. A recommendation is not a MUST or a mandate, and using a SHOULD as if its required feature is pretty much guaranteed to cause problems when this MUST expectation is not met. Sounds like we are trying to remove the idea that implementators really don't have valid reasons to ignore it. IMV, the problem here is that we can't generalized how protocol recommendations are implemented across the board equally and its not correct to be begin using this as a mandate for forcing deployment of what may be deemed unnecessary, controversial and automatically begin classifying existing minimum requirements implementators as non-compliant. Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of HLS Sent: Tuesday, August 30, 2011 1:00 AM To: IETF discussion list Subject: Re: 2119bis I had never thought of this before. I kind of like the idea, especially since SHOULD has always meant MUST unless you really know what you're doing Such an odd reading. Does it mean you MUST because you could not handle it otherwise? I'm sorry if you think it's odd, but it's correct. Read RFC2119 again: 3. SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis -- Tying our hands?
On 8/30/11 2:23 AM, Thomson, Martin wrote: On 2011-08-30 at 07:36:58, Peter Saint-Andre wrote: for long enough, I finally decided to submit an I-D that is intended to obsolete RFC 2119. bike-shed IS THERE ANY CHANCE OF AGREEING THAT SHOUTING IS BAD? (i.e., Burger's first anti-law.) As opposed to mandating that requirements ought to be shouted. Lowercase must can be as effective as uppercase as long as it is consistently applied. /bike-shed You paint that as tongue-in-cheek, but Peter's draft does go down the rat-hole of picking out a color scheme for this particular bike shed, when doing so is really unwarranted. In addition to the SHOULD co brouhaha, I have serious heartburn over this passage: When it is not appropriate to use the conformance terms, authors can use a variety of alternative words and phrases, such as: need to or mandatory instead of MUST; ought to or strongly encouraged instead of SHOULD; and might or discretionary instead of MAY. To prevent confusion, authors ought to use these alternative words and phrases instead of the lowercase versions of the conformance terms, and to use the conformance terms only in their uppercase versions. There is no reason to tie authors' hands by restricting them from using perfectly good English words just because they happen to be the same symbols used by RFC 2119. If we're going down this path, let's scrap using MUST/SHOULD/MAY/etc, and formalize our conformance terms with symbols that aren't English words. Because the current suggestion -- which turns RFC writing into the game Taboo [1], but with incredibly common English words [2] as the forbidden list -- is ridiculous on its face. /a [1] http://en.wikipedia.org/wiki/Taboo_%28game%29 [2] According to Project Gutenberg, must and may are among the 100 words most frequently used in written literature. See http://en.wiktionary.org/wiki/Wiktionary:Frequency_lists#Project_Gutenberg ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
When I approach a protocol to implement, the first thing I typically do is extract and develop the basic wiring of the protocol, the minimum requirements. Make sure the basic framework is correct 100%, then I look for the SHOULDs and also MAYS which are the easiest to add. I look at the SHOULD by order of importance and also complexity. How much CANDY is it? It is a security feature? What are the other implementation requirements, tools, APIs, etc. Generally I want to get security out the way. Its like SMTP AUTH - its not required but anyone cleaning up and rewriting an SMTP spec today, might include the AUTH extension as a SHOULD. And implementators are keen to the importance of it. But nothing won't break down if you don't, less functionality but the basic structure is still there. Its the same approach used for all the protocols we support. Start with the basics and then add on as necessary. Eric Burger wrote: What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Limitations in RFC Errata mechanism
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mykyta Yevstifeyev Sent: Tuesday, August 30, 2011 8:19 AM To: IETF Discussion Subject: Limitations in RFC Errata mechanism First, we have only two types of errata - Technical or Editorial. In presence of http://www.ietf.org/iesg/statement/rfc-metadata-errata.html, IESG Statement on IESG Processing of RFC Errata concerning RFC Metadata, I think the third type is necessary - Metadata. I think given the current mechanism I would just submit such things under Editorial. Second, the Section field at http://www.rfc-editor.org/errata_report.php implies that only numerical sections will contain something an erratum can be reported against (overlooking the GLOBAL option). However, Appendices, Abstract, Index, Author Info, different Notes exist, that aren't covered here. I was able to type Appendix A just now into that section without difficulty. The preview page shows Section Appendix A says:, but that hardly seems a difficulty. Third, Original text and Corrected text fields imply that only before-and-after errata may be submitted. However, there might be errata like Erratum # 6 (http://www.rfc-editor.org/errata_search.php?eid=6), with an only Report text field. I understand this feature was present in previous versions of errata mechanism but removed from the current. I don't understand the problem here. That report seems pretty clear to me. Also, several issues not related to submission mechanism. 1) Specific mailing lists devoted to discussion of errata against RFCs from different areas. I've proposed this on rfc-interest list; see rationale at http://www.rfc-editor.org/pipermail/rfc-interest/2011- August/002672.html.; Typically a working group discusses an erratum when it is raised, and then it sits in limbo until a document update occurs. Isn't the right place for discussion about a particular one the mailing list of that working group or, if it's disbanded, the main IETF list? 3) Verified technical errata may be incorporated in the references. Eg. 4 technical errata were reported against RFC 793 and verified; so the reference may be: Postel, J., Transmission Control Protocol, STD 7, RFC 793, September 1981. Ammended by RFC Errata Reports 573, 1562, 1564, 1572. I don't think verified errata have any force or effect until the document is actually updated, so this really just becomes clutter in the references. Moreover, if I'm implementing some RFC that references another which itself has errata, I will want to know about all of them, not the ones that were present and verified at the time of publication. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
In this case, unless the implementation has a good reason, failing to re-subscribe will result in behavior that the user perceives as broken. I don't think that's really MAY territory. /a On 8/30/11 1:57 PM, Eric Burger wrote: What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 12:18 PM, Keith Moore wrote: On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. +1 I am wondering if having an Implementers Directorate, tasked to do reviews from an implementation point of view, could not help discovering when a SHOULD can create interoperability problems. I would certainly volunteer in such group. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5dQT4ACgkQ9RoMZyVa61eU3gCglqmaf07bpE1RJU9oN3YotGgS T+oAoKeRCXuB2Ea+Bzy+nw+A7er0kURv =bHul -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On 8/23/11 9:24 AM, John C Klensin wrote: So I'm opposed to a USD 200 (or any other number) firm limit on hotel rates. At the same time, I continue to wish that the IAOC would be more open with the community about how these decisions are made and, in particular, how the tradeoffs between sponsorship (and hence lower costs to the IETF for meeting infrastructure and arrangements) and meetings costs to attendees are made... open enough that the community could give substantive guidance on the subject, guidance that I assume the IAOC would follow if it were coherent and plausible. Quite right. There's more than just the hotel rates. My budget is about $2500 US per IETF meeting. That has to cover airfare, the IETF meeting fee, the hotel, meals, service charges, ground transport, mobile phone roaming, incidentals, etc. $300 a night counting taxes and surcharge is just ABSOLUTELY OUT OF THE FREAKING QUESTION. Having the backup hotel a 10 minute taxi ride away is out of the question -- I can't afford taxis. If I can't walk, I can't go. So guess what? I told the wife last night that I wasn't planning to go to the Taiwan meeting. I wanted to go, but I just don't see how it can happen. Maybe I'll win the lottery between now and then... I'm disappointed. I'm hurt. I'm angry. And the trend has just been getting worse and worse with every venue. I want the IAOC's heads on a platter (preferably an inexpensive, disposable platter, like maybe the lid off an old pizza box) for signing us up to this venue. And I want a travel budget no larger than mine for the people we send to future meetings. If we can't find a reasonably inexpensive place to have a meeting, DON'T HAVE THE MEETING! -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Conclusion of the last call on draft-housley-two-maturity-levels
I have reviewed the discussion from the last call on this document. My conclusion as the sponsoring AD is that we have consensus to move forward. There was clearly a constituency who believed this is a good (albeit small) step forward. A number of other people did not care so much; did not believe there was either harm or benefit. I also saw a couple of opposing opinions, though some of them were more about a desire to do something else than specific objections about this proposal. I will be recommending that the IESG approve the draft. There were a number of smaller details raised in the discussion. But I did not see an overwhelming consensus on any specific issue to make changes. But I will ask Russ to take a look at the issue raised by Scott, whether he wants to add an informative reference to RFC 5657. Another issue that I wanted to highlight is the question of what kinds of discusses are desirable/acceptable for documents that move from PS to IS. It is outside the scope of Russ' document, but generated nevertheless some interest. The IESG has discussed this matter and drafted some suggested guidelines. Look for a different thread on this list, under Discuss criteria for documents that advance on the standards track. Feedback on the guidelines would be appreciated. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Discuss criteria for documents that advance on the standards track
During the discussion of the two maturity levels change, a question was brought up about DISCUSSes appropriate for documents that advance on the standards track. We discussed this in the IESG and I drafted some suggested guidelines. Feedback on these suggestions would be welcome. The intent is to publish an IESG statement to complement the already existing general-purpose DISCUSS criteria IESG statement (http://www.ietf.org/iesg/statement/discuss-criteria.html). Here are the suggested guidelines for documents that advance to IS: http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt Comments appreciated. Please send comments either on this list or to the IESG (i...@ietf.org) in time before our next telechat (Thursday, September 8, 2011). Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
I was thinking that if it's a proprietary OTP, we can still use it even if the algorithm is secret. If we know we're getting a clear text OTP value and we have an (unspecified) method of verifying it against some external infrastructure, that's enough to use otp-preauth. However I don't think this actually requires a complete registry. A single undefined/external entry for the existing PSKC registry would be sufficient, wouldn't it? On Aug 29, 2011, at 7:03 AM, Sam Hartman wrote: What information required by the PSC registry do we not need? The only thing I see is the XML information, but it looks like that could be blank. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Thanks for doing this Peter. I only have one input regarding SHOULD. Recently an AD entered an WG during LC, apologized for not being involved more and specifically called out the 4-5 people who had rejected a SHOULD text injection proposal as not understanding RFC2119. He also added that software which does not implement a SHOULD is broken already. In fact, his interpretation is ironically very close to what you have for SHOULD in this I-D. So I wonder if this I-D SHOULD text is the same AD view and a result of what happen in the WG. This is not a disrespect of AD, but I vocalized my exception to the AD description when: A) There was no RFC2119 material text or copy that even came close to AD interpretation, and B) RFC2119 states SHOULD is the same as the adjective RECOMMENDED. As far I am concern, a recommendation is not a mandate nor obligation. The text is very vague and the original RFC2119 is simpler to understand and IMO, closer to practical realities faced for implementators. Of course, none of this is cut and dry and I understand the intent of the text is to encourage implementators to update their software, especially for enhanced protocol and/or new integrated ideas where one protocol requires the help of another protocol, a situation where ideally one would like something to be written as a MUST but for legacy reasons a fallback is available, thus written as a SHOULD. The dilemma begin that unless it is more described with some level of obligation, people don't upgrade as fast or as wide as one would like. My concerns are when a protocol SHOULD is read as an obligation, then two things can and has happen: - Any software that is not currently supportive of a SHOULD or even aware of it, is instantly classified as broken software. This was one of the concerns in the WG when the AD issued the same description as you have here. When the feature was not already support and especially not required, or worst viewed as a temporary short term solution, a SHOULD defined as an Obligation is not going to go smoothly by all responsible implementators. - A feature that was a highly controversial decision and was added as a SHOULD with a rough consensus with lack compromise, an obligation interpretation will cause implementators to not follow it nor support something else that requires an additional SHOULD. It could even be a cost reason, an expensive design change that is require to accommodate a SHOULD not believed to be worth the effort. I think rephrasing is necessary. I think what is important, no matter which way the text wants it convey SHOULD as an important obligated feature to support, no protocol error can occur due to lack of support on either end or disabled by operators. So if anything, I believe removing the final sentence would be more correct because its no longer a recommendation but an obligation. This is not a suggestion, but to highlight it it can probably be said in two sentences to convey the point: A SHOULD is a MUST with a fallback. Implementators are not considered NON-COMPLIANT if a SHOULD is not implemented as long as the fallback is already possible. Thanks Peter Saint-Andre wrote: After staring at http://www.rfc-editor.org/errata_search.php?eid=499 for long enough, I finally decided to submit an I-D that is intended to obsolete RFC 2119. I hope that I've been able to update and clarify the text in a way that is respectful of the original. Feedback is welcome. http://www.ietf.org/id/draft-saintandre-2119bis-01.txt Peter -- Sincerely Hector Santos http://www.santronics.com I addition, even if it was added by a piece of software, it does not mean the operator MUST enabled it or that the software prevent him from turning it off. I venture most implementations will not provide an MUST turn off switch but will provide a SHOULD turn off switch. I also stated more importantly that even if it was a mandate for a server, since it must be ready for clients that do not support it and there is no operational repercussions for its lack of usage, thus by this consideration, there is no mandate or obligation by either side to support it. In my view, if one end expects a feature, then its a MUST. But if its able to fall back, then its a SHOULD. ___ 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
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? 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? Regards, Sasha From: Stewart Bryant [mailto:stbry...@cisco.com] Sent: Tuesday, August 30, 2011 3:05 PM To: Luca Martini; IETF Discussion Cc: John E Drake; m...@ietf.org; Alexander Vainshtein; ietf@ietf.org; Vladimir Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; pwe3-cha...@tools.ietf.org; i...@ietf.org Subject: 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.2http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586http://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.2http://tools.ietf.org/html/draft-ietf-pwe3-mpls-tp-gal-in-pw-01#section-4.2. (GAL Applicability and Usage) in [RFC5586http://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 This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___ 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: Discuss criteria for documents that advance on the standards track
There's something inherently wrong with trying to establish criteria for voting DISCUSS. My understanding was always that DISCUSS was supposed to be an indication that, at a minimum, the AD needs to understand the situation better before casting a yea or nay vote. The resolution of a DISCUSS might end up being a yes vote, a no objection vote, a request for clarification of the document. It should also be possible for an AD to say now that I've understood better, I can't support this going forward (for which ABSTAIN is not an appropriate label). It should never be wrong for an AD to vote DISCUSS, though it's reasonable to limit the amount of time during which a DISCUSS can stand for a particular document. It should also never be wrong for an AD to vote NO if the AD has initially voted DISCUSS, made a sincere effort to understand the issues, believes that he does so, and can state 2026 or other documented criteria for why the document is not suitable for approval. So my recommendations are: 1. Fix the broken IESG voting system before you try to establish more decision criteria. I'm serious. The system you have now is just too broken, and has been broken for a long time. It places too much pressure on ADs to cave in when a WG produces flawed output that isn't easily fixed. It is weighed too heavily in favor of approving a document - such that one AD can vote YES, another vote DISCUSS, no other ADs read the document and all vote NO OBJECTION, and the AD that votes DISCUSS will be expected to change that vote to ABSTAIN because nobody else felt like reading it. And the idea that an AD should ever, ever, be compelled to change his vote to an ABSTAIN is completely unacceptable. And the votes of ADs who haven't read the document should not count AT ALL. Here is a stab at better voting criteria: - The possible votes are: Yes, No, No Objection, Discuss, Abstain, Recuse - Yes means I've read it, I believe it meets applicable criteria (2026 or whatever else is applicable), that there's community-wide consensus to support the document, and that all issues raised by reviewers (including directorate, last call comments, etc.) have been adequately addressed. - No means I've read it, but one or more of the above criteria have failed to have been met. The criteria must be documented. - No Objection means I've read it, and I think there are issues with it, but I don't think those issues are sufficient to block the document. The criteria should be documented, but the AD isn't compelled to do so. - Discuss means I have read the document and see at least one potential issue which needs to be discussed. Discuss should always be raised before voting No. However, Discuss votes should time out and be replaced by Abstain (if not explicitly changed by the AD) after say 45 days. (however, nothing should ever stop an AD from changing his vote to No.) Note that the ADs, WG chairs, authors, etc. should attempt to resolve the issue offline (not during the telechat or other IESG meeting) but the discussion should be archived. - Abstain means I did not read this, and/or I don't consider myself competent to review this - Recuse means I have a conflict of interest with stating a position on this document All Discuss votes must be changed (whether explicitly by the AD or by automatic timeout) before a ballot is finished. If there are two or more No votes, all ADs without a conflict of interest are expected to read the document, and the vote is taken again. In order to approve a document or standards action, there must be twice as many Yes + No Objection votes as No votes. 2. Don't overconstrain the use of DISCUSS. In particular, don't ever create a situation where a reviewer can't cite a problem with a document, regardless of whether that problem has previously been enumerated.It's fine to have guidelines for the benefit of new ADs but they should be nonbinding. You need to have other ways of dealing with the occasional stubborn AD who votes DISCUSS or whatever without a defensible reason. This applies to all IESG voting actions, not just moving from PS-DS/IS. 3. I take serious issue with the statement in the draft that IESG reviews are reviews of last resort and the implication that WG reviews are sufficient. In numerous situations this has not been the case. I'm all for having IESG place greater reliance on directorates (especially if this is formalized to some degree), so as to lessen IESG's workload to to get individual ADs out of the hot seat. But for IESG to presume by default that the WG has done due diligence is for IESG to shirk its responsibility. 4. When evaluating PS-DS/IS actions, IESG should avoid repeating the PS review. Instead it should look at what has changed between PS and DS/IS, and what has been learned as a result of implementation and deployment experience. The changes have to be minimal and safe.No new features can
Re: Hyatt Taipei cancellation policy?
Dean, Before you give up completely I would check out: http://wikitravel.org/en/Taipei Taxis are not expensive, the Metro even less so, and there are at least some budget hotels nearby. I expect the local hosts to provide more information soon -- they already have some info on the website. I agree about the Hyatt hotel price. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Tue, 30 Aug 2011, Dean Willis wrote: On 8/23/11 9:24 AM, John C Klensin wrote: So I'm opposed to a USD 200 (or any other number) firm limit on hotel rates. At the same time, I continue to wish that the IAOC would be more open with the community about how these decisions are made and, in particular, how the tradeoffs between sponsorship (and hence lower costs to the IETF for meeting infrastructure and arrangements) and meetings costs to attendees are made... open enough that the community could give substantive guidance on the subject, guidance that I assume the IAOC would follow if it were coherent and plausible. Quite right. There's more than just the hotel rates. My budget is about $2500 US per IETF meeting. That has to cover airfare, the IETF meeting fee, the hotel, meals, service charges, ground transport, mobile phone roaming, incidentals, etc. $300 a night counting taxes and surcharge is just ABSOLUTELY OUT OF THE FREAKING QUESTION. Having the backup hotel a 10 minute taxi ride away is out of the question -- I can't afford taxis. If I can't walk, I can't go. So guess what? I told the wife last night that I wasn't planning to go to the Taiwan meeting. I wanted to go, but I just don't see how it can happen. Maybe I'll win the lottery between now and then... I'm disappointed. I'm hurt. I'm angry. And the trend has just been getting worse and worse with every venue. I want the IAOC's heads on a platter (preferably an inexpensive, disposable platter, like maybe the lid off an old pizza box) for signing us up to this venue. And I want a travel budget no larger than mine for the people we send to future meetings. If we can't find a reasonably inexpensive place to have a meeting, DON'T HAVE THE MEETING! -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
On Aug 30, 2011, at 2:17 PM, Keith Moore wrote: My understanding was always that DISCUSS was supposed to be an indication that, at a minimum, the AD needs to understand the situation better before casting a yea or nay vote. The resolution of a DISCUSS might end up being a yes vote, a no objection vote, a request for clarification of the document. It should also be possible for an AD to say now that I've understood better, I can't support this going forward (for which ABSTAIN is not an appropriate label). It should never be wrong for an AD to vote DISCUSS, though it's reasonable to limit the amount of time during which a DISCUSS can stand for a particular document. It should also never be wrong for an AD to vote NO if the AD has initially voted DISCUSS, made a sincere effort to understand the issues, believes that he does so, and can state 2026 or other documented criteria for why the document is not suitable for approval. I agree in part. My problem is that even some ADs tell me that ADs sometimes behave as if they haven't done their job if they haven't produced a discuss. A few months ago, I got a discuss on a document that in essence said what should I be writing a 'discuss' about?. I have no problem with valid concerns, and many of the concerns raised are valid. It should be possible for a working group to produce a quality document and have the IESG simply approve it, however. I'm not sure it is. Discuss votes should time out and be replaced by Abstain (if not explicitly changed by the AD) after say 45 days. There I disagree. If the AD raised a valid issue, the ball is in the author/wg's court to address it. They can game this rule by not responding until after 45 days. Personally, I would rather see the document returned to the author/wg if review results in a request for major changes. In my working group, we recently had one draft completely rewritten in the response to discusses, and I pulled it back for the WG to decide whether it still had consensus around the resulting draft. I would say the same about a discuss that is not adequately responded to in 45 days; the IESG should clean it off their plate. What's also not fair game is to raise the bar - to expect the document at DS to meet more stringent criteria than it was required to meet at the time of PS approval. Hmmm, the demonstrated interoperability requirement of DS/IS is in fact a raising of the bar,and one that has served us well. We don't (although IMHO we should) require even an implementation to go to PS. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
On Aug 30, 2011, at 5:51 PM, Fred Baker wrote: On Aug 30, 2011, at 2:17 PM, Keith Moore wrote: My understanding was always that DISCUSS was supposed to be an indication that, at a minimum, the AD needs to understand the situation better before casting a yea or nay vote. The resolution of a DISCUSS might end up being a yes vote, a no objection vote, a request for clarification of the document. It should also be possible for an AD to say now that I've understood better, I can't support this going forward (for which ABSTAIN is not an appropriate label). It should never be wrong for an AD to vote DISCUSS, though it's reasonable to limit the amount of time during which a DISCUSS can stand for a particular document. It should also never be wrong for an AD to vote NO if the AD has initially voted DISCUSS, made a sincere effort to understand the issues, believes that he does so, and can state 2026 or other documented criteria for why the document is not suitable for approval. I agree in part. My problem is that even some ADs tell me that ADs sometimes behave as if they haven't done their job if they haven't produced a discuss. A few months ago, I got a discuss on a document that in essence said what should I be writing a 'discuss' about?. I have no problem with valid concerns, and many of the concerns raised are valid. It should be possible for a working group to produce a quality document and have the IESG simply approve it, however. I'm not sure it is. The first time I reviewed a document as an AD, I realized I was working very hard to find something wrong. And I did - I found a bona fide (and uncontroversial) technical flaw - actually an incorrect value for a constant. But after that I got over needing to find things that were wrong. I found plenty of issues without trying to do anything more than read and understand the documents - and had quite enough work to do just reading and understanding them and writing up those issues without making more work for myself. (Especially when other ADs would often demand that I not only identify the issues but also specify the fixes - something I always regarded as out-of-scope for an AD and even potentially tampering with WG output.) So I don't disagree that ADs sometime believe that they need to vote Discuss or they're not doing their jobs. Though I have a hard time believing that the drafts coming out of WGs these days are so good that ADs have to work hard to find things that are wrong with many of them. If they're trying to find a reason to Discuss every document, well I guess that is a problem. But overall, it seems like there are far more incentives to avoid finding reasons to object to a document, than there are to find them. Discuss votes should time out and be replaced by Abstain (if not explicitly changed by the AD) after say 45 days. There I disagree. If the AD raised a valid issue, the ball is in the author/wg's court to address it. They can game this rule by not responding until after 45 days. I don't think I stated that rule very well. If the author/wg fail to address the issue within 45 days, the AD should of course be able to change the vote to No. The point is that the Discuss should inherently be a temporary state, a time during which the AD doesn't vote No (yet) but lets the author/WG know that he has issues with a document. And the idea is to encourage those parties enough time to understand each other and work out their differences before bringing the issue to a firm vote. But I don't think that the WG should be able to game the rule to force the AD's objection to go away, nor should the AD be able to singlehandedly block a document. Personally, I would rather see the document returned to the author/wg if review results in a request for major changes. In my working group, we recently had one draft completely rewritten in the response to discusses, and I pulled it back for the WG to decide whether it still had consensus around the resulting draft. I would say the same about a discuss that is not adequately responded to in 45 days; the IESG should clean it off their plate. IMO, any time a document is significantly revised, IESG should consider it a separate item, requiring a new Last Call, writeup, ballot, etc. What's also not fair game is to raise the bar - to expect the document at DS to meet more stringent criteria than it was required to meet at the time of PS approval. Hmmm, the demonstrated interoperability requirement of DS/IS is in fact a raising of the bar,and one that has served us well. We don't (although IMHO we should) require even an implementation to go to PS. I should have been more specific. By raising the bar I was thinking about things like design decisions, and document quality. If feature FOO was judged to be of adequate design at PS, it's not fair to say it's not adequate on DS review unless
Re: 2119bis
On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: I support adding the SHOULD ... UNLESS formalism (although maybe it should be MUST... UNLESS). It would be useful as there will be times where the UNLESS can be specified and has been given due consideration at the time of writing. That, however, will not always be the case. (More inline). How would SHOULD...UNLESS or MUST...UNLESS differ from using the current 2119 definitions and just writing SHOULD...unless or MUST ... unless? Personally I think 2119 is just fine and doesn't need to be updated. +1. I'm still not seeing sufficient justification to open this particular can of worms at this juncture. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
On 2011-08-31 09:51, Fred Baker wrote: ... If the AD raised a valid issue, the ball is in the author/wg's court to address it. They can game this rule by not responding until after 45 days. Not if the draft has been updated and the AD doesn't either cancel the DISCUSS within a reasonable time*, or explain why the update is insufficient. This happens, probably as often as authors failing to address an issue within a reasonable time. Whichever party is responsible for the delay should be subject to a timeout, surely. That said, I disagree with Keith. The current DISCUSS criteria were written for a very specific reason - to get rid of the type of DISCUSS listed in the non-criteria. There was a lot of analysis done of documents that were stuck in the IESG for months in the 2004/2005 timeframe, and the non-criteria describe the problem cases - DISCUSSes that were not actionable or simply expressed the fact that the AD didn't like the WG's informed consensus. Of course nothing's perfect and I'm sure the criteria could be improved. But not having them was much worse. * for example, is IESG Evaluation::AD Followup (for 32 days) a reasonable delay for a Discussing AD to review an updated draft [hint, hint]? Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
On 2011-08-31 08:18, Jari Arkko wrote: ... Here are the suggested guidelines for documents that advance to IS: http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt Comments appreciated. To answer Jari's original request: +1 to these new guidelines. Not worth nit-picking until we have some experience. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 2011-08-31 10:38, ned+i...@mauve.mrochek.com wrote: On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: I support adding the SHOULD ... UNLESS formalism (although maybe it should be MUST... UNLESS). It would be useful as there will be times where the UNLESS can be specified and has been given due consideration at the time of writing. That, however, will not always be the case. (More inline). How would SHOULD...UNLESS or MUST...UNLESS differ from using the current 2119 definitions and just writing SHOULD...unless or MUST ... unless? Personally I think 2119 is just fine and doesn't need to be updated. +1. I'm still not seeing sufficient justification to open this particular can of worms at this juncture. + another 1. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Just responding to a small part, here: B) RFC2119 states SHOULD is the same as the adjective RECOMMENDED. As far I am concern, a recommendation is not a mandate nor obligation. The problem we have with using what look like English words for these things is that people have expectations about what those words mean. Notwithstanding that, these words, in this context, are technical terms, not English words. One can't look them up in a dictionary, nor use one's own sense, as a speaker of English, to determine what they mean. One must only use what RFC 2119 says. It says this: 3. SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. That's not the same as many people's understanding of the English meaning of the words should and recommended, which are similar in appearance to the technical terms defined in RFC 2119. Of course, then we run into interpretations of the definitions of the terms, and exactly what that sentence in item 3 in RFC 2119 *means*, but I'm not getting into that here. This may be where you, I, Peter, and/or the AD in question differ. But don't make the mistake of thinking that, in the context of RFC 2119, one can use one's own English sense of what the meanings of these terms are. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Friendly reminder from BCP 61: Security is a MUST implement http://tools.ietf.org/html/bcp61#section-7 On 8/30/11 12:46 PM, Eric Burger wrote: Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security On Aug 30, 2011, at 12:11 PM, Keith Moore wrote: On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: The meaning of SHOULD is clear for the authors (it mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.), the problem is that some implementers use a different meaning (I do not have to implement this if it is inconvenient or difficult for me to implement), vendors another one (SHOULD gave us the right to not implement it). I even read somewhere, perhaps on this list, about a vendor that rejected any bug report against a SHOULD. Conditional MUST, in my opinion, does not have this problem. But conditional MUST has other problems, namely that you have to enumerate the exceptions for the MUST, and that's not always practical. Implementors who think that SHOULD gives them a free pass to avoid implementing something that's needed to interoperate are misreading 2119. But document editors should avoid using SHOULD for cases where failure to implement the requirement will result in interoperability failure. I could see maybe posting an erratum or a brief update to 2119, but I think that reopening that document in general is a Very bad Idea. And for existing documents that misuse SHOULD, the appropriate thing to do is to update those documents or post errata to those documents, rather than try to retroactively change the meaning of the keywords in those documents. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis -- Tying our hands?
On 8/30/11 2:08 PM, Adam Roach wrote: Because the current suggestion -- which turns RFC writing into the game Taboo [1], but with incredibly common English words [2] as the forbidden list -- is ridiculous on its face. Don't use requirements language unless you absolutely have to. Otherwise, explain things in clear prose, describing what happens in normal and error cases, and the logic used in distinguishing them. If you absolutely require RFC 2119 requirements language to make something clear, I suggest the following symbology: ✔: MUST ☂: SHOULD ♥: MAY ✖: MUST NOT ♠: SHOULD NOT ☹: MAY NOT And the fact that the above is garbled for some large percentage of readers explains why we use 7-bit ASCII in drafts, so let's just stop that argument now, ok? -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis -- Tying our hands?
My first reaction was that the entire topic is a bike shed. The goal is clear and understandable specifications and 2119 is just a tool we use to make the process of producing and reading specifications more efficient. What I'm getting from this is that there are a significant number of drafts being submitted to the IESG for publication that are not sufficiently precise in their use of language. Deciding to revise 2119 seems - at first blush - an interesting reaction to this problem. But it's become evident that we don't share a common understanding of the language, nor are we consistent in its application. Formalizing usage patterns (c.f. server MUST/client MAY, MUST...UNLESS...) does help, if only because you've made it easier to do the right thing in more cases. If the problem is that authors and editors don't have the tools they need, then maybe a revision is the right approach. However, I'd still like to see more RFCs that describe something without resorting to using these crude implements. On 2011-08-31 at 05:08:15, Adam Roach wrote: There is no reason to tie authors' hands by restricting them from using perfectly good English words just because they happen to be the same symbols used by RFC 2119. If we're going down this path, let's scrap using MUST/SHOULD/MAY/etc, and formalize our conformance terms with symbols that aren't English words. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Limitations in RFC Errata mechanism
30.08.2011 22:09, Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mykyta Yevstifeyev Sent: Tuesday, August 30, 2011 8:19 AM To: IETF Discussion Subject: Limitations in RFC Errata mechanism First, we have only two types of errata - Technical or Editorial. In presence of http://www.ietf.org/iesg/statement/rfc-metadata-errata.html, IESG Statement on IESG Processing of RFC Errata concerning RFC Metadata, I think the third type is necessary - Metadata. I think given the current mechanism I would just submit such things under Editorial. This is an option; but doing so makes work of RFC Editor when incorporating metadata errata harder. If we have such thing as Metadata erratum type, and if such erratum gets verified, RFC Editor will be capable of noticing and acting quickly (I doubt RFC Editor pays much attention to Editorial errata when submitted/verified). Second, the Section field at http://www.rfc-editor.org/errata_report.php implies that only numerical sections will contain something an erratum can be reported against (overlooking the GLOBAL option). However, Appendices, Abstract, Index, Author Info, different Notes exist, that aren't covered here. I was able to type Appendix A just now into that section without difficulty. The preview page shows Section Appendix A says:, but that hardly seems a difficulty. This limitation makes submitters find the way to put what they want in this field whose entity, I think, should be limited to digits and .. This issue is probably of aesthetic importance. Third, Original text and Corrected text fields imply that only before-and-after errata may be submitted. However, there might be errata like Erratum # 6 (http://www.rfc-editor.org/errata_search.php?eid=6), with an only Report text field. I understand this feature was present in previous versions of errata mechanism but removed from the current. I don't understand the problem here. That report seems pretty clear to me. There used to be a Text Report option for submitting errata. This implied filling in the only field, not Current Text and Corrected Text. Now it is unavailable, and this makes submitters write smth like this: Scope: GLOBAL; Current text: N/A; Corrected text: what they want to say and this results in a report saying that Throughout the document, when it says N/A, it should say what submitter wanted to say. If the one-field errata existed, this would be: Scope: not filled in; Report Text: what they want to say and the erratum will look like: [For this document] the following erratum was reported: what submitter wanted to say. (The scope-indicating field when submitting such errata should be made optional, BTW.) Also, several issues not related to submission mechanism. 1) Specific mailing lists devoted to discussion of errata against RFCs from different areas. I've proposed this on rfc-interest list; see rationale at http://www.rfc-editor.org/pipermail/rfc-interest/2011- August/002672.html.; Typically a working group discusses an erratum when it is raised, and then it sits in limbo until a document update occurs. Isn't the right place for discussion about a particular one the mailing list of that working group or, if it's disbanded, the main IETF list? Well, there are AD-sponsored Individual Submissions, which have no associated WG, and IAB, IRTF and Independent docs which IETF community might have a limited interest in. If we had the lists where errata for: 1. IETF Stream: a. Apps Area; b. Int Area; c. Gen Area; d. Ops Area; e. RAI Area; f. Rtg area; g. Sec Area; h. Tsv-Area i. Legacy (published bu concluded areas); j. Individual Submissions; 2. IAB Stream; 3. IRTF Stream; 4. Independent Submissions folks who don't have ability or willing to join corresponding groups' lists will be capable of joining these lists. Discussing errata on IETF Discussion list will increase our traffic and will soon bore many people who aren't particularly interested in a variety of topics errata are submitted on. 3) Verified technical errata may be incorporated in the references. Eg. 4 technical errata were reported against RFC 793 and verified; so the reference may be: Postel, J., Transmission Control Protocol, STD 7, RFC 793, September 1981. Ammended by RFC Errata Reports 573, 1562, 1564, 1572. I don't think verified errata have any force or effect until the document is actually updated, so this really just becomes clutter in the references. Moreover, if I'm implementing some RFC that references another which itself has errata, I will want to know about all of them, not the ones that were present and verified at the time of publication. Well, a reasonable argument. At Appendix A of draft-rfc-editor-errata-process-02 (http://tools.ietf.org/html/draft-rfc-editor-errata-process-02#appendix-A) I found a proposal from Brian Carpenter to point to errata
RE: Limitations in RFC Errata mechanism
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mykyta Yevstifeyev Sent: Tuesday, August 30, 2011 9:05 PM To: ietf@ietf.org Subject: Re: Limitations in RFC Errata mechanism I think given the current mechanism I would just submit such things under Editorial. This is an option; but doing so makes work of RFC Editor when incorporating metadata errata harder. If we have such thing as Metadata erratum type, and if such erratum gets verified, RFC Editor will be capable of noticing and acting quickly (I doubt RFC Editor pays much attention to Editorial errata when submitted/verified). I'm sure the RFC Editor appreciates people in the IETF trying to make their work easier, but since so far they haven't complained about this in particular, I'm not sure it's something that actually needs fixing. I was able to type Appendix A just now into that section without difficulty. The preview page shows Section Appendix A says:, but that hardly seems a difficulty. This limitation makes submitters find the way to put what they want in this field whose entity, I think, should be limited to digits and .. This issue is probably of aesthetic importance. As a submitter, I didn't find typing Appendix A into that box and decoding the output to be at all inconvenient. It may not be perfect, but it's not terribly broken either. Typically a working group discusses an erratum when it is raised, and then it sits in limbo until a document update occurs. Isn't the right place for discussion about a particular one the mailing list of that working group or, if it's disbanded, the main IETF list? Well, there are AD-sponsored Individual Submissions, which have no associated WG, and IAB, IRTF and Independent docs which IETF community might have a limited interest in. If we had the lists where errata for: [...] I still don't see this as evidence that we need to have a forum specifically for discussing errata. I would have to subscribe to that list just in case there's ever any erratum opened for an RFC that interests me, and deal with the (possibly huge) amount of traffic that is not of interest. It seems to me that ietf@ietf.org is just fine for this purpose, and most of us already are on that one. I also haven't seen any demand prior to this for a special forum where errata are discussed, separate from the list(s) we already have. Discussing errata on IETF Discussion list will increase our traffic and will soon bore many people who aren't particularly interested in a variety of topics errata are submitted on. As far as I can tell, that's where this happens now, and I don't see it being much of a burden. I could be wrong, but I don't see much evidence that any of this stuff is broken enough to warrant a bunch of form changes, new mailing lists, or other new infrastructure. If it ain't broke, don't fix it. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dime-rfc3588bis-29.txt (Diameter Base Protocol) to Proposed Standard
The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Base Protocol' draft-ietf-dime-rfc3588bis-29.txt as a Proposed Standard The document was already last-called, but because of the extensive and non-editorial changes it went through, the editors, document shepherd and Area Director decided to submit it again to broad IETF review. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-09-13. 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 Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and must be supported by all new Diameter implementations. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dime-rfc3588bis/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1437/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Current Practices for Multiple Interface Hosts' to Informational RFC (draft-ietf-mif-current-practices-12.txt)
The IESG has approved the following document: - 'Current Practices for Multiple Interface Hosts' (draft-ietf-mif-current-practices-12.txt) as an Informational RFC This document is the product of the Multiple Interfaces Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mif-current-practices/ Technical Summary An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document summarizes current practices in this area, and describes in detail how some common operating systems cope with these challenges. Working Group Summary There is a consensus in the MIF WG for publication as an informational RFC. Document Quality The document has gone through various reviews and a successful WGLC. Personnel Responsible AD is Jari Arkko and the document shepherd is Hui Deng. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to Proposed Standard (draft-ietf-dime-local-keytran-14.txt)
The IESG has approved the following document: - 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' (draft-ietf-dime-local-keytran-14.txt) as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-local-keytran/ Technical Summary Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. Working Group Summary The document was discussed for more than one year in the WG and the document captures the results of the collaborative WG work. Document Quality The document is complete, straightforward, simple and well-written. Personnel Dan Romascanu is the Document Shepherd for this document. Lionel Morand is Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Javascript Object Signing and Encryption (jose)
A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, September 6, 2011 Javascript Object Signing and Encryption (jose) = Status: Proposed Working Group Last updated: 2011-08-18 Chairs TBD Security Area Directors: Stephen Farrell stephen.farr...@cs.tcd.ie Sean Turner turn...@ieca.com Security Area Advisor: Sean Turner turn...@ieca.com Mailing Lists: General Discussion: j...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jose Archive: http://www.ietf.org/mail-archive/web/jose/ Description of Working Group Javascript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services such as encryption, digital signatures, and message authentication codes (MACs) for data that is being carried in JSON format. Different proposals for providing such security services have already been defined and implemented. This Working Group's task is to standardize two security services, integrity protection (signature and MAC) and encryption, in order to increase interoperability of security features between protocols that use JSON. The Working Group will base its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is correct. This group is chartered to work on four documents: 1) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures. Integrity protection includes public-key digital signatures as well as symmetric-key MACs. 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures. 3) A Standards Track document specifying how to encode public keys as JSON-structured objects. 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents. The working group may decide to address one or more of these goals in a single document, in which case the concrete milestones for signing/encryption below will both be satisfied by the single document. Goals and Milestones Jan 2012Submit JSON object integrity document as a WG item. Jan 2012Submit JSON object encryption document as a WG item. Jan 2012Submit JSON key format document as a WG item. Jan 2012Submit JSON algorithm document as a WG item. Jun 2012Start Working Group Last Call on JSON object integrity document. Jun 2012Start Working Group Last Call on JSON object encryption document. Jun 2012Start Working Group Last Call on JSON key format document. Jun 2012Start Working Group Last Call on JSON algorithm document. Jul 2012Submit JSON object integrity document to IESG for consideration as Standards Track document. Jul 2012Submit JSON object encryption document to IESG for consideration as Standards Track document. Jul 2012Submit JSON key format document to IESG for consideration as Standards Track document. Jul 2012Submit JSON algorithm document to IESG for consideration as Standards Track document. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Recharter of Layer 2 Virtual Private Networks (l2vpn)
A modified charter has been submitted for the Layer 2 Virtual Private Networks (l2vpn) working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, September 6, 2011. Layer 2 Virtual Private Networks (l2vpn) Last updated: 2011-08-30 Current Status: Active Chairs: Nabil Bitar nabil.n.bi...@verizon.com Giles Heron gihe...@cisco.com Routing Area Directors: Stewart Bryant stbry...@cisco.com Adrian Farrel adr...@olddog.co.uk Routing Area Advisor: Stewart Bryant stbry...@cisco.com Mailing Lists: General Discussion: l2...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2vpn Archive: http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.html Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services. Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as defined by the PWE3 WG or over IP or MPLS PSN tunnels. A L2VPN emulates a native service over a PSN that is adequately faithful to, but may not be entirely indistinguishable from the native service itself. Further, following in the edge-to-edge nature of the service, the L2VPN WG will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between the PEs which provide the L2VPN connectivity. Layer-2 VPNs comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates a switched Ethernet (V)LAN across a PSN. 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across a PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across a PSN. 4. IP-only L2VPN, an IP-only service over a PSN. The WG will address two specific types of IP-only L2VPN: a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also supports heterogenous Attachment Circuits at either end of a single point-to-point service. b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that emulates an Ethernet (V)LAN across a PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree, a Layer-2 service defined by the MEF, which provides connectivity between one or more root nodes and one or more leaf nodes, with the restriction that leaf nodes may only communicate with root node(s) (and not with each other). L2VPNs will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PEs participating in a Layer-2 VPN as well as the membership of CE devices for a specific instance of an L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WGs. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms for VPLS. Those extensions will be reviewed by the PWE3 WG to ensure they are aligned with the overall design/architecture of PWE3. The L2VPN WG will not define new encapsulations, control, or resiliency mechanisms specifically related to pseudowires. Furthermore, when the L2VPN solution is based on PWs, the L2VPN WG will not define protocol inter-working between an L2VPN and native service Layer-2 OAM or resiliency mechanisms. The L2VPN WG may define how to operate native service-layer control, OAM or resiliency mechanisms on top of an L2VPN. In addition, it may define native data plane and/or control plane interworking between an L2VPN and an associated native Layer-2 service. The L2VPN WG scope includes the following: 1. Discovery of PEs participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN service. 2. Signaling of information related to the discovery and membership of PEs within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for
WG Action: RECHARTER: STORage Maintenance (storm)
The STORage Maintenance (storm) working group in the Transport Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. STORage Maintenance (storm) Last updated: 2011-08-18 Current Status: Active Working Group Chairs: Tom Talpey ttal...@microsoft.com David Black black_da...@emc.com Transport Area Directors: Wesley Eddy w...@mti-systems.com David Harrington ietf...@comcast.net Transport Area Advisor: David Harrington ietf...@comcast.net Mailing Lists: General Discussion: st...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/storm Archive:http://www.ietf.org/mail-archive/web/storm/ Description of Working Group: The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the running code). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Security for these protocols is based on the functionality specified in RFC 3723 (Securing Block Storage Protocols over IP); the working group does not intend to make major changes or updates to that RFC. Stability is critical to the usage of these protocols, so backwards compatibility with existing implementations will be a requirement imposed on for all protocol changes and additions. Note that this is a requirement for implementation compatibility - if it is the case that all implementations of a protocol have done something different than what the RFC specifies, it is appropriate for a new RFC to document what the running code actually does and deprecate the unused original behavior. List of work items: (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft (3720bis), removing features that are not implemented in practice. This draft should be prepared so that it could become a Draft Standard RFC, but the Working Group has decided not to advance it to Draft Standard status. (2) iSCSI: Add features to support at least SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the previous item. The Working Group may add additional minor useful iSCSI features to this draft, including features from draft versions of SAM-5. The iSCSI MIB (RFC 4544) should be updated to provide SNMP support for new features as appropriate. (3) FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but this allocated number is not used by FCIP. The Working Group has documented the deployed pre-standard use of this protocol number in RFC 6172, and IANA has updated the registry entry to reference RFC 6172. (4) iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with its specification, and moreover, only the Address Transparent mode of iFCP is in use. This will be done via a short draft that updates RFC 4172, and not via a complete rewrite of RFC 4172. The Working Group has deprecated iFCP Address Translation mode in RFC 6172 and made the corresponding changes to the iFCP MIB (originally RFC 4369) in RFC 6173. (5) RDDP MPA: Good support for MPI applications requires a small update to the startup functionality to allow either end of the connection to initiate. In addition, a couple of minor changes to RDDP connection setup are needed based on implementation experience. (6) iSER: Experience with Infiniband implementations suggest a few minor updates to reflect what has been done in practice. (7) RDMA Protocol: Experience with the rddp (iWARP) RDMA Protocol (RFC 5040) suggests that some minor extensions are needed, specifically, the addition of immediate data support and remote atomic operations. The Working Group is expected to maintain good working relationships with INCITS Technical Committee T10 (SCSI standards) and INCITS Technical Committee T11 (Fibre Channel standards) via overlaps in membership as opposed to appointment of formal liaisons. The liaison process (including IAB appointment of a liaison or liaisons) remains available for use if needed. Recent changes in INCITS rules have removed public access to some T10 and T11 standards documents that are expected to be
Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC
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 i...@ietf.org mailing lists by 2011-09-27. 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 Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type, and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional Layer 2 VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs and the Internet, as well as a common provisioning methodology for all services. The file can be obtained via http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1149/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-baker-bmwg-testing-eyeball-happiness-05.txt (Testing Eyeball Happiness) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Testing Eyeball Happiness' draft-baker-bmwg-testing-eyeball-happiness-05.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-09-27. 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 amount of time it takes to establish a session using common transport APIs in dual stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it. The file can be obtained via http://datatracker.ietf.org/doc/draft-baker-bmwg-testing-eyeball-happiness/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-baker-bmwg-testing-eyeball-happiness/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-trill-rbridge-af-04.txt (RBridges: Appointed Forwarders) to Proposed Standard
The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'RBridges: Appointed Forwarders' draft-ietf-trill-rbridge-af-04.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 i...@ietf.org mailing lists by 2011-09-13. 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 IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called RBridges. TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called Appointed Forwarders, with the intent that native traffic in each VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-af/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-af/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
