Re: Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04
Hi Ben, On Fri, Jun 1, 2012 at 3:18 PM, Ben Campbell b...@nostrum.com wrote: Thanks for the quick response. Further comments inline. I deleted sections that do not appear to need further discussion. Thanks! Ben. On Jun 1, 2012, at 10:45 AM, Donald Eastlake wrote: Hi Ben, Thanks for your review. See responses below. On Thu, May 31, 2012 at 6:08 PM, Ben Campbell b...@nostrum.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-trill-rbridge-extension-04 Reviewer: Ben Campbell Review Date: 2012-05-31 IETF LC End Date: 2012-06-07 IESG Telechat date: 2012-06-07 Note: Since this draft is on the agenda of the IESG Telechat on the same day that the IETF last call expires, this review is intended for both purposes. Summary: This draft is almost ready for publication as a proposed standard, but I have some clarification questions and comments that should be considered prior to publication. Major issues: None Minor issues: -- section 2, general: Do the authors assume that all TRILL extensions will follow this spec? Since RFC6325 already specifies an extension mechanism, what stops an extension from ignoring this spec and doing something different? Does it hurt if they do? I am not aware of any conflicts between this draft and RFC 6325. RFC 6325 provides the broadest header option framework, for example specifying the field for the length of the options area and the initial two critical summary bits. This document fills in the structure and allocation mechanism of the remaining bits in the first 4-byte word of the options area, consistent with and repeating some material from RFC 6325, but leaving specification of the remainder of the options area for future documents, which should be consistent with both RFC 6325 and this document. (For example, some future version of draft-ietf-trill-rbridge-options.) I agree there is no conflict--this draft adds details, but doesn't seem to contradict anything in the RFC. However, neither RFC 6325 nor this document can actually actually bind the IETF against adopting future standards describing extensions that do not conform. Certainly. Nothing can do that. The IETF can always update a protocol to change normative language, no matter how strongly it was stated originally :-) If future changes do not follow RFC 6325 or this document, for example changing the location or interpretation of the option length field in the TRILL Header or changing the interpretation of the critical summary bits in the first word of the options area, then this would break hardware and software implementations that depend on RFC 6325 and/or this document. But I trust the IETF to adhere to its usually high standards for backwards compatibility. Perhaps this draft should, in the first page header, say Updates: 6325, not in the sense that it makes a change but in the sense that it fills in more details. Assuming the additional details in this draft comprise preferred extension mechanism, then I think it makes sense to say that somewhere (perhaps a SHOULD strength), and also mark it as updating 6325. Adding details is still an update. OK. -- section 2, 3rd paragraph from end: Non-critical extensions can be safely ignored. Is that intended to be normative? (Seems like it should be, since behavior for critical extensions is normative). I think of it as more like the definition of non-critical. Sure--I mainly mention it to be consistent with the text for critical extensions, since it did use normative language about dropping frames. -- section 2.1, 1st paragraph, last sentence: Redundant with normative language in previous section. ? There is a normative requirement to discard frames with any unimplemented critical hop-by-hop options present, which might be thought to require examination of all options (something manifestly impossible since the format of options beyond the first word of the options area is not yet normatively specified). The sentence to which you refer just clarifies that testing the appropriate crtical summary bit(s) in the first word of the options area, if that word is present, is all that is required. section 2 says Any RBridge receiving a frame with a critical hop-by-hop extension that it does not implement MUST discard the frame Section 2.1 says If an RBridge does not implement all critical flags in a TRILL Data frame, it MUST discard the frame... These really seem like the same MUST (i.e, if you updated one but not the other, you would have an ambiguous state). The same is true for the egress bit. I understand that you want to draw the connection between a critical extension and critical flags, but it's
Re: [IETF] Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
-- No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft. --Anon. On Jun 3, 2012, at 12:34 AM, C. M. Heard wrote: On Sat, 2 Jun 2012, Masataka Ohta wrote: Existing routers, which was relying on ID uniqueness of atomic packets, are now broken when they fragment the atomic packets. Such routers were always broken. An atomic packet has DF=0 and any router fragmenting such a packet was and is non-compliant with the relevant specifications (RFCs 791, 1122, 1812). Sorry, but no…. Not following the RFC != broken. Not following the RFC == non-compliant. There are numerous places where implementations do not follow the specs for various reasons, ranging from simply not bothering, through philosophical differences to customers paying for non-compliant feature X. Sorry, I'm in a somewhat pedantic mood, and I saw a soapbox, so I climbed up on it… W //cmh
maybe it's getting real
Sitting in a pub in the Tiergarten metro station, in Berlin, today, I checked whether there were any open-access wireless points around. There weren't. But one of the nets had an SSID of IPV6... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: maybe it's getting real
On Sun, 3 Jun 2012, Dave Crocker wrote: Subject: maybe it's getting real Sitting in a pub in the Tiergarten metro station, in Berlin, today, I checked whether there were any open-access wireless points around. There weren't. It's very unfortunate not sharing bandwidth is getting real. Paul
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
C. M. Heard wrote: Existing routers, which was relying on ID uniqueness of atomic packets, are now broken when they fragment the atomic packets. Such routers were always broken. An atomic packet has DF=0 and any router fragmenting such a packet was and is non-compliant with the relevant specifications (RFCs 791, 1122, 1812). Thank you. I have overlooked that atomic implied DF=1. But, then, Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID values within one MSL for a given source address/destination address/protocol triple. makes most, if not all, IPv4 hosts non compliant if MSL=2min. Worse, without hard value of MSL, it is a meaningless requirement. Note that MSL=2min derived from RFC793 breaks 150Mbps TCP. The proper solution, IMHO, to the ID uniqueness is to request a destination host drop fragments from a source host after it receives tens (or hundreds) of packets with different IDs from the same source host. A source host, then, is only required to remember the previous ID used for each destination. Masataka Ohta
Re: maybe it's getting real
On 6/3/12 11:13 , Dave Crocker wrote: Sitting in a pub in the Tiergarten metro station, in Berlin, today, I checked whether there were any open-access wireless points around. http://www.msnbc.msn.com/id/37107291/ns/technology_and_science-security/ There weren't. But one of the nets had an SSID of IPV6... d/
Re: Making the Tao a web page
What we have now *is* sclerotic. See Russ' email above yours. Can we PLEASE eat our own dog food? Wikipedia managed not to melt down when they decided NOT TO BUILD WALLS so there were no gates for the barbarians to crush. Let's just turn on a wiki. Wiki's have a lot of technical measures to deal with problem edits as well as social measures to ensure quality. Unlike a protocol that needs one editor, I do not think we will run into interoperability problems by having an open Wiki. Yes, you and I and others can think of exactly four individuals who will try to crash the party. There are technical measures to keep them out without burdening one or even four people with keeping up the wiki. On Jun 1, 2012, at 5:33 PM, Russ Housley wrote: I have a concern here. When I did the AD review for this document, I was quite surprised how stale it had become. For example, the document told people to send I-Ds to the Secretariat for posting instead of pointing to the online I-D submission tool. If we put it in a wiki, there will be more people that can make update, but the publication process ensure that an end-to-end read takes place when an update published as an RFC. So, I am left with a few questions: - What is the similar forcing function if we use a wiki? - Will the number of people that can make updates eliminate the need for such a forcing function? - Who designates the editor-in-chief of the wiki? Russ On May 31, 2012, at 7:50 PM, Paul Hoffman wrote: On May 31, 2012, at 4:30 PM, Nick Hilliard wrote: On 01/06/2012 00:04, Paul Hoffman wrote: Works for me, other than it should not be a wiki. It should have one editor who takes proposed changes from the community the same way we do it now. Not all suggestions from this community, even from individuals in the leadership, are ones that should appear in such a document. In practice, if this is to be a living document then it should be open for inspection and poking rather than preserved in formaldehyde and put in a display case, only to be opened occasionally when the curator decides the glass needs some dusting. That way leads to sclerosis. Thank you for that most colorful analogy. :-) What I proposed is exactly what we are doing now, except that the changes would appear on the web page instead of an Internet-Draft and, five years later, an RFC. Are you saying that the current system (which you have not commented on until now) is sclerotic (a word that I have wanted to use since I learned it in high school)? Please put it on a wiki and put all changes through a lightweight review system. If someone makes a change which doesn't work, then it can be reverted quickly and easily. This approach is much more in line with the ietf approach of informality / asking for forgiveness rather than permission / rough consensus + running code / etc. In the IETF approach, only the authors of an Internet-Draft can change the contents of that draft. I hope you are not proposing a change to that as well. --Paul Hoffman
Re: Making the Tao a web page
--On Sunday, June 03, 2012 17:40 -0400 Eric Burger eburge...@standardstrack.com wrote: What we have now *is* sclerotic. See Russ' email above yours. Can we PLEASE eat our own dog food? Wikipedia managed not to melt down when they decided NOT TO BUILD WALLS so there were no gates for the barbarians to crush. Let's just turn on a wiki. Wiki's have a lot of technical measures to deal with problem edits as well as social measures to ensure quality. Unlike a protocol that needs one editor, I do not think we will run into interoperability problems by having an open Wiki. Yes, you and I and others can think of exactly four individuals who will try to crash the party. There are technical measures to keep them out without burdening one or even four people with keeping up the wiki. Eric, FWIW, I think Paul is completely correct. First of all, what is sclerotic is RFC 4677. Paul has been updating the I-D which is much less of a problem. Most of those in the know point people to the I-D. I think that having 4677 be the official copy that some people consult as authoritative is a problem, but it is another problem. Those wiki technical measures depend on someone actively watching for changes and having the time to step in. I don't think we can count on that, at least without a greater level of effort that is required for an editor to receive comments and integrate them. I might change my mind if you, personally, agreed to monitor the wiki in real time and alert the IETF list to any possibly-questionable postings _and_ there was consensus that those on the list wanted that additional traffic. FWIW, I had a need on Friday to look up some details and information that are fairly directly related to the IETF and its relationships to some other bodies and decided to check the Wikipedia pages that showed up in the search. I'd give what I found a score on accuracy and completeness of joke -- a few identifiable falsehoods and a lot of convenient omissions (I don't know or care whether those are the result of carelessness, ignorance, or malice). The most relevant of those pages wasn't even flagged with may be incomplete, insufficient references, or may be biased, etc. If you want to demonstrate how well the Wiki system works, drop me a note volunteering to fix the primary page involved and I'll tell you what it is and, if you can't figure it out on your own in under two minutes, where to get authoritative information. In principle, I could do it myself, but I just don't have time... and that, and the fact that no one with the facts and time has spotted those pages, is a large part of the problem with doing something like the Tao by Wiki. Also, perhaps because I have a more vivid (or paranoid) imagination than you do, I can think of a lot more than four individuals who would be inclined to wreck the party. Some of the individuals I can think of also have multiple personalities or collections of sympathetic fellow-travelers (not just multiple email addresses). And, while I would hope they wouldn't engage in such thing, if only because of the risk of getting caught, I can think of a large and well-endowed organization or three who might have incentives to put highly distorted information onto an IETF Wiki that described how the IETF worked, copy that material before it were taken down, and then quote it in other sources. Finally, as far as our dogfood is concerned, I just made a careful search through the RFC index and a few other sources and couldn't find an IETF Standards Track document describing the Wiki technology and approach. I couldn't even find an Informational document. So, unless I've missed something, this particular food belongs to some other dog. _Our_ dog food would be to follow the precedent set with RFC 5000. And I think that is exactly what Paul and several others, including myself, have been suggesting. best, john
Re: Making the Tao a web page
On 6/3/12 2:46 PM, John C Klensin wrote: Also, perhaps because I have a more vivid (or paranoid) imagination than you do, I can think of a lot more than four individuals who would be inclined to wreck the party. This, I think, is the show-stopper. Back when the internet started to become popular a well-known open access advocate put his system, which had a passwordless root account, online, and it was basically vandalized immediately, then vandalized again, and again, and again, until he finally surrendered. I really prefer to keep things as open as possible and I would love it if the Tao were a wiki article, but transitioning to that model would essentially mean making a commitment for the life of the page to keeping a very close eye on it with a quick response to vandalism. I also think that enough of our process is actually disputed to make a living document hard to handle. At least with an RFC we can say this is what we thought it was on a given date, with considerable review prior to publication. Melinda
Re: Making the Tao a web page
At 14:33 01-06-2012, Russ Housley wrote: it in a wiki, there will be more people that can make update, but the publication process ensure that an end-to-end read takes place when an update published as an RFC. Seven individuals (approximate) submitted comments during the Last Call. That's not much in terms of end-to-end read of the draft. So, I am left with a few questions: - What is the similar forcing function if we use a wiki? - Will the number of people that can make updates eliminate the need for such a forcing function? - Who designates the editor-in-chief of the wiki? HTTPbis has a good Wiki due to the efforts of two persons. The rest of the IETF, excluding the IESG, do not believe that it is worth the effort updating a Wiki. Instead of discussing the above questions it is easier to create an Wiki page and leave it to anyone with a tools login who cares to update it. Regards, -sm
Re: Making the Tao a web page
--On Sunday, June 03, 2012 14:58 -0800 Melinda Shore melinda.sh...@gmail.com wrote: On 6/3/12 2:46 PM, John C Klensin wrote: Also, perhaps because I have a more vivid (or paranoid) imagination than you do, I can think of a lot more than four individuals who would be inclined to wreck the party. This, I think, is the show-stopper. Back when the internet started to become popular a well-known open access advocate put his system, which had a passwordless root account, online, and it was basically vandalized immediately, then vandalized again, and again, and again, until he finally surrendered. I really prefer to keep things as open as possible and I would love it if the Tao were a wiki article, but transitioning to that model would essentially mean making a commitment for the life of the page to keeping a very close eye on it with a quick response to vandalism. Indeed. I also think that enough of our process is actually disputed to make a living document hard to handle. At least with an RFC we can say this is what we thought it was on a given date, with considerable review prior to publication. Well, as long as the document is informational and an overview, I think that can be accomplished as easily with a web page, an editor who can be trusted to exercise a certain amount of good sense (and whose intentions are trusted) and a process for forcing a review if needed. The thing that bothers me about trying to do this by RFC is that the entire community then wastes a huge amount of time debating the choice and style of words and relatively minor details, after which everyone runs out of energy to make further changes for years (other than posting I-Ds on which there are no real controls, even an appeal process (not that I'd expect Paul to ignore input)). If we go the web page and editor route, expect revisions only when real problems are identified and otherwise do a review every year or so, I think we can get a pretty good balance between the slowness of the RFC-and-community-consensus process and the difficulties of the Wiki one. best, john
Re: Making the Tao a web page
--On Sunday, June 03, 2012 15:36 -0700 SM s...@resistor.net wrote: At 14:33 01-06-2012, Russ Housley wrote: it in a wiki, there will be more people that can make update, but the publication process ensure that an end-to-end read takes place when an update published as an RFC. Seven individuals (approximate) submitted comments during the Last Call. That's not much in terms of end-to-end read of the draft. Subramanian, I don't think that is a fair comparison. First of all, the Last Call spawned the whole thread about colloquial language. I don't have any way to know how many of those who participated in that thread read all the way through the document and even less way to guess how many people were enough turned off by it to lose interest in the Last Call, maybe after having read the document. Second and more important, my suggestion that we go in the direction of a web page or wiki spawned a separate thread that is more about the philosophy of how to handle the document rather than about the detailed content of the document itself. Again, I have no idea how many people other than myself looked through the document, decided that publish as RFC? was the wrong question, and as the result of that decision, concluded that my time was better spent on medium and editorial process than on reporting specific document comments. So you don't know to what extent I, or anyone else in the making it a web page threads read the document through either. My guess is that more people have volunteered to help with the web page approach on an ongoing basis than have read the document carefully in the last week or so. I further guess that on an ongoing basis will be better for the document than getting a new snapshot out as an RFC and seeing how long it takes to get stale and how long after that it takes the community to notice. But those are just guesses and my opinion. YMMD. ... HTTPbis has a good Wiki due to the efforts of two persons. The rest of the IETF, excluding the IESG, do not believe that it is worth the effort updating a Wiki. Instead of discussing the above questions it is easier to create an Wiki page and leave it to anyone with a tools login who cares to update it. See my responses to Eric and Melinda. john
Re: Making the Tao a web page
On Jun 3, 2012, at 6:34 PM, John C Klensin wrote: ... I further guess that on an ongoing basis will be better for the document than getting a new snapshot out as an RFC and seeing how long it takes to get stale and how long after that it takes the community to notice. ... I second the above statement (my apology to John for quoting this single sentence out of his whole msg) Lixia
Re: Making the Tao a web page
Hi John, At 18:34 03-06-2012, John C Klensin wrote: I don't think that is a fair comparison. First of all, the Last Call spawned the whole thread about colloquial language. I don't have any way to know how many of those who participated in that thread read all the way through the document and even less way to guess how many people were enough turned off by it to lose interest in the Last Call, maybe after having read the document. Second and more important, my suggestion that we go Fair enough. My guess was that the Last Call was not really a Last Call. :-) in the direction of a web page or wiki spawned a separate thread that is more about the philosophy of how to handle the document rather than about the detailed content of the document itself. Again, I have no idea how many people other than myself looked through the document, decided that publish as RFC? was the wrong question, and as the result of that decision, concluded that my time was better spent on medium and editorial process than on reporting specific document comments. So you don't know to what extent I, or anyone else in the making it a web page threads read the document through either. Yes. At 18:14 03-06-2012, John C Klensin wrote: Well, as long as the document is informational and an overview, I think that can be accomplished as easily with a web page, an editor who can be trusted to exercise a certain amount of good sense (and whose intentions are trusted) and a process for forcing a review if needed. The thing that bothers me about trying to do this by RFC is that the entire community then wastes a huge amount of time debating the choice and style of words and relatively minor details, after which everyone runs out of energy to make further changes for years (other than posting I-Ds on which there are no real controls, even an appeal process (not that I'd expect Paul to ignore input)). If we go the web page and editor route, expect revisions only when real problems are identified and otherwise do a review every year or so, I think we can get a pretty good balance between the slowness of the RFC-and-community-consensus process and the difficulties of the Wiki one. In 1994 it was mentioned that due to the nature of the document it can become outdated quite quickly. The web page approach was recommended. The EDU Team ( http://wiki.tools.ietf.org/group/edu/wiki/EduCharter ) could be an alternative to take on the task. Regards, -sm
