Re: [DNSOP] Practical issues deploying DNSSEC into the home.
Hi - >From: Olafur Gudmundsson >Sent: Sep 11, 2013 7:19 AM >To: Evan Hunt >Cc: "dn...@ietf.org WG" , "ietf@ietf.org TF" >Subject: Re: [DNSOP] Practical issues deploying DNSSEC into the home. ... >RRSIG on the SOA or NS or DNSKEY also is fine timestamp except when it is a >replay attack or a forgery, ... RFC 3414 separates the notion of timeliness (replay detection) from authentication without requiring NTP or overly elaborate clock acquisition dances. Some of the ideas from that protocol's design might be useful in addressing this problem. Randy
Re: Charging remote participants
Hi - > From: "Dave Aronson" > To: "IETF Discussion Mailing List" ; "Janet P Gunn" > > Sent: Monday, August 26, 2013 9:54 AM > Subject: Re: Charging remote participants ... > I had to go Google that. To save others the trouble: it seems to > refer to rides at a carnival, and mean "whatever losses you suffer in > one place, you usually make up elsewhere", implying that it all > balances out in the end. I had to google it as well. The word "roundabout" (in the sense of "traffic circle") led me to mistakenly think it had something to do with navigating British streets, but this seems to be where the idiom comes from: http://www.oldpoetry.com/Patrick_R_Chalmers/Roundabouts_and_Swings Randy
re: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard
Hi - >From: Yaron Sheffer >Sent: Aug 13, 2013 2:11 PM >To: IETF Discussion Mailing List >Subject: re: Last Call: (Concise Binary Object >Representation (CBOR)) to Proposed Standard ... >- The "diagnostic notation" can be used very effectively for things like >configuration files, e.g. if an application already uses CBOR on the >wire. Therefore I would suggest to formalize it a bit more, so that we >also have interoperability at this level. Do you envision it as an encoding for Netconf? Randy
Re: IETF Diversity
Hi - It seems as though participants in this thread are operating with different understandings of what constitutes "institutional bias." A critical difference is whether *intent* is necessary for bias to exist. As I understand it, institutional bias can exist in the absence of ill intent, and can even be an unintended consequence of efforts to *reduce* bias. If something about the way we do business makes it more difficult for otherwise qualified individuals from some group to participate at a given level, then we have to admit the possibility that we have a case of institutional bias. The available remedies might be worse than the problem, but we shouldn't fool ourselves into thinking that we're any better at this stuff than any other well-meaning bunch of people, and we shouldn't pretend that privilege doesn't exist, no matter how much that conflicts with our self-image fantasy of being a meritocracy. Embracing an ideal does not mean ignoring reality. For a hopefully non-controversial example, consider how excessively idiomatic English, over-reliance on sports metaphors, and obscure cultural references all serve as barriers to participation. It doesn't matter whether I intend to exclude anyone through, for example, my use of long sentences. But if my long sentences make it too much harder for others to participate, then I *am* part of the problem, and need to think about how that effect might be mitigated. Randy
Re: Content-free Last Call comments
Hi - >From: Ted Lemon >Sent: Jun 12, 2013 12:42 PM >To: Peter Saint-Andre >Cc: "" , Alexey >Melnikov , Pete Resnick >, "ietf@ietf.org Discussion" >Subject: Re: Content-free Last Call comments > >On Jun 12, 2013, at 3:31 PM, Peter Saint-Andre wrote: >> I think these messages are useless, not harmful. But perhaps I have >> more confidence in the inherent skepticism of your average IETF >> participant than Pete does... > >FWIW, until I read Pete's document on consensus, I thought that +1 >statements were part of the consensus process. This was not a >strongly held opinion—it was just my understanding of how >consensus operated, from having watched other working group >chairs run their working groups. I think the point Pete is >making is very important, because the consensus process Pete >describes is more in keeping with how I think the IETF ought >to operate than the process in which +1 counts for something. ... As a former WG chair who's had to deal with some very rough consensus calls... Not "counting" a "+1" is more consistent with a classical definition of consensus. But, particularly at a WG level (less so, perhaps, at the IETF level) "+1" is very helpful in determining whether the previously mentioned "Abilene Paradox" should be of concern. Randy
Re: [IETF] Re: Issues in wider geographic participation
Hi - > From: "Adrian Farrel" ... > But who pays the operators' bills, and do we need to encourage participation > at > that level as well? Participation as: RFC uptake: - using something based on an RFC? - deploying something based on an RFC? - implementing something based on an RFC? - providing useful feedback based on usage/deployment/implementation experience? I-D uptake: - providing I-D reviews? - implementation of something based on an I-D? - providing useful feedback based on usage/deployment/implementation experience? WG participation: - lurking on mailing list(s)? - useful contribution to email conversation? - participation in meetings? - volunteering as scribe? - volunteer as editor? - design team work? - mentoring newcomers? ... For each of the possible target populations, what would be the realistic motivations to do one or more of these? I think factors to consider would include: - tradeoff between time investment required and hoped-for outcome - perceived likelihood that one's participation would make a difference - perceived extent to which this time investment or contribution (not the same thing!) would be favorably recognized by: + one's peers + one's employer + potential future employers + one's customers / clients - whether there would be any personal satisfaction derived from participation - others? Thinking about the cross-product of these lists and the target populations that have been mentioned, it seems a minor miracle that the IETF has had been able to get as much participation and diversity as it has. Particularly when we get to the "user" level, the time investment / payoff ratio seems all wrong unless that user is highly altruistic or has a generous sponsor with "big picture" motivations. It also seems that for specific target populations, it might be useful to identify (1) the specific ways in which that population might have the most positive impact on the IETF and more importantly (2) identify the ways in which IETF participation might have the biggest positive impact on those types participants, their employers, or other constituencies with whom they identify. Not quite a marketing strategy, but until this conversation is centered around learning the needs, gifts, and motivations of these "other" people, it's not going to accomplish much to increase participation. Randy
Re: More participation from under-represented regions
Hi - Watching this discussion scroll by on my screen, I'm amazed how similar it is to discussions of evangelism in congregations. Two things this religious institution might learn from other religious institutions: (1) "need-based" evangelism. Outreach efforts are more effective if they sincerely address specific needs of the target community. Does face-to-face participation in the IETF offer things practitioners in under-represented regions feel they need? As long as we focus on how it could help *us*, rather than what needs it would address for them, it'll be far less effective than it could be. (2) Watch out for "colonialist" attitudes, such as assuming that we know what the needs and priorities of the target communities are, rather than finding out. This can require much more investment than just doing surveys, and may even reveal that certain models of "helping" might be culturally inappropriate, and consequently ineffective or counter- productive. Randy
Re: Language editing
Hi - > From: "Brian E Carpenter" > To: "Ned Freed" > Cc: "John C Klensin" ; ; > > Sent: Tuesday, May 07, 2013 2:19 PM > Subject: Re: Language editing ... > You are correct if only considering the mail standards. I suspect > that a serious attempt at formal verification would have thrown > up an inconsistency between the set of mail-related standards and > the URI standard. However, I think the underlying problem here is > that we ended up defining the text representation of IPv6 addresses > in three different places, rather than having a single normative > source. (ABNF in the mail standards, ABNF in the URI standard, > and English in ipv6/6man standards.) > > > (Formal verification of implementation > > compliance to the standards would of course have prevented Apple's client > > bug, > > but that's a very different thing.) > > > > You are, however, correct that this has nothing to do with specification > > editing. > > > > Ned I'm not so sure about that. To me this seems to be a case of inappropriate use of MUST. First a reminder from RFC 2119: In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) The prohibition against using :: more than once is amply motivated. Multiple occurrances would introduce ambiguities, so that prohibition clearly warrants a MUST. The prohibition against using :: for a single 0 seems to lack such an obvious syntactic / semantic motivation. Does anyone remember why this syntactic limitation was added? Randy
Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06
Hi - > From: "Michael Richardson" > To: "ietf" ; "Andrew McGregor" > Cc: "Christian Huitema" ; "SM" > Sent: Friday, April 26, 2013 5:47 AM > Subject: Re: last call comments for > draft-ietf-6man-stable-privacy-addresses-06 ... > I think that non-contiguous ifindexes are a pain in the ass (based upon > my understanding of enumeration of interfaces in the interface MIB), but > are they essentially forbidden? Having holes would make it easier to > keep things consistent. This is exactly what RFC 2863 (The Interfaces Group MIB) specifies. Non-contiguous ifIndex values are permitted. This issue was considered at some length in the development of RFC 2863. Section 3.1.5 explains in detail why the semantics of ifIndex were changed (from their original MIB-II definition) to permit "holes", while the semantics of ifNumber were left untouched. Randy
Re: Diversity of IETF Leadership
Hi - > From: "Dan Harkins" > To: "Margaret Wasserman" > Cc: > Sent: Tuesday, March 12, 2013 3:56 AM > Subject: Re: Diversity of IETF Leadership ... > If there's some bias involved in the Nomcom's selection process then > point it out and let's address it. The mere fact that there are is > preponderance of white males being selected does not mean bias exists ... If I understand this thread correctly, the result of the process has been consistently less diverse than the pool from which the process has been making selections. I can only see three interpretations: (1) that white males are more likely than other participants to be sufficiently qualified (2) that the selection process (or the Nomcom) itself functions (unintentionally, unconsciously) to favor white males. (3) that past performance is just a massive statistical fluke I doubt that it's (1) or (3). Think a little about social networks and (2) becomes even more plausible. I suggest concentrating on how the system *functions*, rather than inferring hidden accusations of evil intent. Randy
Re: Vestigial Features (was Re: CRLF (was: Re: A modest proposal))
Hi - > From: "John C Klensin" > To: "Carsten Bormann" > Cc: "John Levine" ; ; > > Sent: Wednesday, January 23, 2013 5:20 PM > Subject: Re: Vestigial Features (was Re: CRLF (was: Re: A modest proposal)) ... > So, yes, some TTY units needed padding > characters or other delays and sometimes it varied depending on > the relationship between current carriage position and intended > one. But that was a device driver problem (and lots of the > device drivers ran on peripheral controllers, not the > mainframe)-- no CTSS or Multics program that used the system > device drivers ever had a NUL or character timing as part of its > application-level data stream. It was messier than that in other environments. Yes, device drivers, peripheral processors, or front ends commonly dealt with whether a particular device needed CR, LF, NL, CRLF, or something else, and how many NULs had to be sent in order to deal with device limitations in processing those control codes. But the more "sophisticated" controls, such as VT, FF, and so on, also required delays on some devices. (I remember one device where VT would cause it to suck paper back into the printer in order to return to the top of the current page.) Sequences for line insert, line delete, and region clears / fills on some CRTs also required padding delays. Some got seriously confused if the padding was omitted. However, dealing with this issue was put painfully close to the user application in Unix-land. Look for "padding" in the documentation for termcap and terminfo for a glimpse into how convoluted things became. > As I said, I wasn't part of the committee that did ASCII. I do > know that CR was extensively used, in both our terminal > environment and in a number of ones involving line printers > without LF as a way to arrange overstriking (for bold, > underlining, and composed characters) on line-oriented devices > that couldn't handle backspacing. Again, that was mostly in > the device drivers: an application program would see >xxxo'yyy > whether that was transmitted or >xxxoyyy ' > or, as mentioned earlier, whatever the first-character-of-line > printer control sequence was that would yield the same result. In our CDC shop, security was critically dependent on this. Since the teletypes echoed everything typed locally, there needed to be a way to prevent even a partially-typed password from being visible. This was accomplished by sending a sequence that was something like: Password: Randy
Re: Common sense, process, and the nature of change
Hi - > From: "Scott Brim" > To: "Ted Hardie" > Cc: "IETF" > Sent: Friday, November 09, 2012 6:32 AM > Subject: Re: Common sense, process, and the nature of change > > Ted: Very nice but I would go further. You believe that everyone in the > IETF has either internalized the mission or will in the course of > participating. I think the IETF has already lost that unity of mission, > particularly with the influx of corporate participants who were not > around in the idealistic days. For them the new normal is to use the > IETF as a tool for creating competitive advantage - As I see it, that "new normal" has been the norm as long as I've been working on IETF-related stuff - over twenty years. Every organization has some sort of "mission", though the expectation that all (or even most) participants have fully bought into and internalized that mission is probably at best a useful fiction. It is true that behaving as though one is on board with the mission will help gain the cooperation of others, and, in the case of the IETF's mission, yield useful work. But it's no guarantee, and my experience has been that other considerations seem to take precedence over the IETF mission for many participants. Even in those cases, however, behaving as though those participants were primarily motivated by the IETF mission generally seems the best way to sustain the collaboration, or at least the illusion of collaboration, and hopefully get *something* done. Cynical? Perhaps, but in other threads we get glimpses of the litigious hell that is the probable alternative. Randy
Re: [OPSAWG] Basic ietf process question ...
Hi - > From: "Andy Bierman" > To: "Romascanu, Dan (Dan)" > Cc: ; > Sent: Thursday, August 02, 2012 10:13 AM > Subject: Re: [OPSAWG] Basic ietf process question ... ... > NMS developers need to spend too many resources on translating > naming and other data-modeling specific details so they can be > usable within the application. So if 1 data modeling language > is not used, then deterministic, loss-less, round-trip translation > between data modeling languages is needed. Multiple > protocols are not the problem -- incompatible data from multiple > protocols is the problem. ... Picking a single language or set of round-trip translatable languages also isn't enough. Its a fact of life that vendors will produce models and implementations that are slightly, or even radically different. The differences aren't necessarily even intentional, but nonetheless introduce the need to talk about "similar" models and "operationally equivalent" configurations, where the transformations needed to go from what will do the job on one piece of equipment to what will work on another may be substantial. (From an implementation perspective it might be better to think in terms of transformations necessary to go from a common model of desired operational characteristics to the dial tweaks and button pokes necessary to get a device to do the right thing.) Since great minds often think alike, even in the absence of standards, there is not necessarily a formal "derived from" or "subclass" or "common aspect" relationship between the definitions. This may be an obvious use case for XSLT, but as far as I know nothing has been done about *standardizing* such usage, other than discussions at the IAB workshop oh-so-many years ago, and some ISO/ITU discussions in the 1990s about eventual applications of the General Relationship Model and the management domain/policy stuff in GDMO land. Randy
Re: 'Geek' image scares women away from tech industry ? The Register
Hi - > From: "Yoav Nir" > To: "Mary Barnes" > Cc: "IETF-Discussion list" > Sent: Tuesday, May 01, 2012 9:12 AM > Subject: Re: 'Geek' image scares women away from tech industry ? The Register ... > IOW I don't see the difference between not wanting to spend too > much time at work and wanting to spend more time with your family. I think the notion that one's life is limited to work and family is a great example of what makes for an unsupportive environment, regardless of one's gender. I have no scientific study to back me up, but my experience has been that men (myself included at times) tend to be fairly clueless about what makes for an "uncivil work environment", and in particular, privilege tends to make us oblivious to "condescending or patronizing" behaviour. Randy
Re: Proposed IESG Statement on the Conclusion of Experiments
Hi - > From: "Ronald Bonica" > To: "Randy Presuhn" ; ; > ; "Brian E Carpenter" > Sent: Saturday, April 21, 2012 7:44 AM > Subject: RE: Proposed IESG Statement on the Conclusion of Experiments ... > The proposed IESG statement encourages community members to terminate > their own experiments when they have clearly ended. In many cases, the > experimenter moves on before the experiment is terminated. In that case, > the cleanup chore is left to others. I think there are some fundamental problems in this framing of the question. The use of the phrase "their own" and "clearly" are the ones that concern me. The problems with "clearly" are obvious, particularly for protocols that have a long legacy of "just working", regardless of their theoretical shortcomings. "Their own" assumes a level of "ownership" and, more importantly, *control* which is rarely true, and in some cases the "owners" may actually have a conflict of interest leading them to favor premature termination. > The proposed IESG statement *does not* seek to expedite the termination > of any experiment. Its only goal is to identify experiments that clearly have > terminated. I do not see any way in which this improves the criteria or process for determining "clearly", or even the subtler problem of "terminated." Sometimes the result of the experiment may be "we don't want to standardize this", but also "in the aftermath of the experiment, there are a lot of implementations of this, and insufficient motivation for those who have deployed it to move to something else." Randy
Re: Proposed IESG Statement on the Conclusion of Experiments
Hi - > From: "Ronald Bonica" > To: ; ; > Sent: Friday, April 20, 2012 1:56 PM > Subject: RE: Proposed IESG Statement on the Conclusion of Experiments > If this IESG statement is published, none of that changes. It might be helpful to say what *would* change upon publication of this statement, and why the IESG believes it is important to make that change, because we're obviously not unerstanding the proposal in the same way. Randy
Re: Proposed IESG Statement on the Conclusion of Experiments
Hi - > From: "Randy Bush" > To: "Adrian Farrel" > Cc: "IETF Disgust" ; "IESG" > Sent: Friday, April 20, 2012 2:04 AM > Subject: Re: Proposed IESG Statement on the Conclusion of Experiments > > one aspect that may be missed is that there is a body of experimantal > documents which were not really experiments, but were classified as > such because of layer nine silliness. > > randy And if we look at the body of documents that have been reclasssified as historic, we also see that sometimes reclassification has nothing to do with the "experiment" being terminated (the protocols still in wide use) and can also only be reasonably explained as "layer nine silliness." Randy (a different one)
Re: ITC copped out on UTC again
Hi - > From: "Michael Richardson" > To: "Phillip Hallam-Baker" > Cc: "IETF Discussion Mailing List" > Sent: Friday, January 20, 2012 10:13 AM > Subject: Re: ITC copped out on UTC again ... > Can you tell me which protocols use future timestamps in an moving form > (not stored at rest in a certificate in a DANE RR, for instance), which > care about discrepancies of less than 1 minute? The disman Scheduling MIB (RFC 3231) has future timestamps. They are defined as dates / times, with provision for how discontinuities in civil time (whether due to "summer time", time zone changes, or leap seconds) are to be handled. This definition makes it unlikely that a sane developer would internally represent them as computed intervals. Leap second handling is a big non-issue in SNMP-land, as far as I know. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
merlot.tools.ietf.org getting bounced by Earthlink.net
Hi - If you're using the IETF tools to distribute information, you should be aware of this... ... > host mx4.mindspring.com [207.69.189.220]: 550 IP 194.146.105.14 is > blocked by EarthLink. Go to earthlink.net/block for details. ... 194.146.105.14 is merlot.tools.ietf.org Their support pages provide no avenue for the intended recipient of blocked email to request action be taken. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reading on small devices, was discouraged by .docx
Hi - > From: "John C Klensin" > To: "Ole Jacobsen" > Cc: > Sent: Monday, November 28, 2011 6:28 AM > Subject: RE: reading on small devices, was discouraged by .docx ... > On the other hand, I tried the PDF file out on one of those > small-screen devices and discovered that it preserved the page > format exactly-- by showing pages of the document reduced to > show one page per screen, no scrolling. The resolution isn't up > to it even if my aging eyes are, so that is no solution either. In a way, this discussion seems akin to complaints that it's hard to read RFCs when they're punched onto ticker tape. I think the discussion of ASCII art and tables is a bit of a red herring - at those dimensions, the key value of artwork, giving the user an opportunity to absorb both the gestalt and the details in a single glance, is lost. Likewise tables, either shrunk to illegibility or reduced to one-cell-at-a-time scan for such a display, lose much of their value for organizing information and revealing patterns. 15 or 20 years ago, I might have been able to use one of those small-screen devices. Nowadays - no way. If things are displayed large enough to be legible the amount of vertical scrolling makes reading anything longer than one (short) sentence painfully slow. But here's a solution: let's just wait a few more years, and the folks who are currently so enthusiastic about using these gizmos to read RFCs will have been compelled by their own aging eyes to move on to something else. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Hi - > From: "Hector" > Cc: > Sent: Saturday, September 03, 2011 7:52 AM > Subject: Re: 2119bis ... > For protocol v2.0, X2 is a improved version of X1. > > SHOULD USE X2 IF POSSIBLE, IF NOT > MUST USE X1 > > Its the same as saying > > MUST USE X2 first or X1 as a fallback ... No, those two formulations mean different things. If the first "SHOULD" were a "MUST", then they'd be close but still not equivalent. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Hi - > From: "Murray S. Kucherawy" > To: "IETF discussion list" > Sent: Wednesday, August 31, 2011 11:00 AM > Subject: RE: 2119bis > > > -Original Message- > > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > > Hector > > Sent: Wednesday, August 31, 2011 10:57 AM > > Cc: IETF discussion list > > Subject: Re: 2119bis > > > > > But I don't think there's anything wrong with the definitions as we have > > > them; > > > I think they've served us well for the last fourteen years. > > > > Correct and by far, most deployments have use SHOULD = OPTION with an > > documented right to IGNORE - so be it written so be it followed. > > This sentence is self-contradictory. "SHOULD" is, by definition, not > "OPTIONAL". I disagree with the claim that there is a contradiction there, but I also think "IGNORE" is incorrect. The only difference between "SHOULD" and "MAY" is that the implementor / deployer needs a good excuse to not implement / employ a "SHOULD." That's not the same as "IGNORE". However, looking at an implementation from a conformance testing perspective, these are indistinguishable. If the conditions under which the feature may be omitted are well-defined, then an "if not x MUST y" structure would be much more appropriate, and this can be easily handled with the existing keywords. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Hi - > From: "Eric Burger" > To: "Narten Thomas" ; "Saint-Andre Peter" > > Cc: "IETF discussion list" > 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. 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. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Drafts Submissions cut-off
Hi - > From: "Andrew Sullivan" > To: > Sent: Wednesday, August 03, 2011 6:02 AM > Subject: Re: Drafts Submissions cut-off ... > I like the submission cut-off because it is a useful forcing function > to get drafts in by a reasonable time before the meeting so that > people can read them. But I wouldn't argue for it on principled > grounds, and if people really believe we need to do something, I'm in > favour of getting rid of that. I nevertheless predict that such a > decision will yield less good results than what we have now. Other, less contrived "forcing functions" are possible. For example, I know of at least one WG chair who insisted on including links in meeting agendas to the the exact versions of the drafts to be discussed. This caused the agenda posting cutoff to become the effective deadline. This is also consistent with the expressed goal of giving chairs some flexibility. But we don't need more rules to practice this! It would not bother me at all if the two-week cutoff were eliminated. If anything, it would encourage chairs to be more precise in their meeting agendas. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
Hi - > From: "Noel Chiappa" > To: > Cc: > Sent: Monday, July 25, 2011 3:05 PM > Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again) ... > I think we should only mark things as HISTORIC as a recognition of _what has > already happened_ out in the world, not as an attempt to _make something > happen_. ... Though I think this is a reasonable position, there are examples from history, such as the "historicization" of RFC 1227, that clearly demonstrate that the IETF has historically not consistently maintained this position. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic status (was Another look at 6to4 (and other IPv6 transitionissues))
Hi - > From: "Mykyta Yevstifeyev" > To: > Sent: Friday, July 22, 2011 3:16 AM > Subject: Historic status (was Another look at 6to4 (and other IPv6 > transitionissues)) ... > And what could/should be done? I think, IESG and the whole community, > cooperating with IAB, IRSG and ISE, should determine the definition of > Historic which will be fine enough to cover all existing issues with it, > and then either publish such approach as BCP or incorporate when > updating RFC 2026. This will eliminate the problems with different > issues with procedures for and understanding of Historic RFCs as well as > clear up one of "dark places" in IETF process. ... After universal IPv6 deployment has been achieved, after we have workable standardized configuration management, after all significant protocols have been properly secured, and after NAT has been banished from this planet, I *might* be persuaded to support spending time on this. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call:
Hi - > From: "Keith Moore" > To: "Randy Presuhn" > Cc: > Sent: Thursday, June 09, 2011 5:49 PM > Subject: Re: [v6ops] Last Call: ... > > Consider, then, RFC 1157. > > > > It was, quite rightly, declared historic years ago, even though it > > was a full standard and in rather widespread use at the time. > > Was there a replacement for RFC 1157 (presumably, a new version > of SNMP) generally available at the time that document was moved to Historic? Yes, with some arguments about "generally". > I mean, it would make perfect sense to want to declare 1157 historic > if there were a new version available that clearly worked better. Right > now, there's not a readily available replacement for 6to4 that is clearly > better. > > So I think the comparison is not valid. SNMP (of whatever version) is a > protocol that you can use on your own network if you want to, and that's > where most of its utility is. You don't have to get your ISP to support it > before it's significantly useful to you. By contrast, the very purpose > of 6to4 is to communicate with peers over someone else's network(s). > If you want to run IPv6 over your own IPv4 network, 6rd or maybe > 6over4 are better suited to that. There appears to be some dispute about whether the functionality of 6to4 is really needed. I take no sides in that part of the debate. My comment was in response to the claim (which you have not made, AFAIK) that it was inappropriate to declare a standards-track protocol historic while still in widespread use, for reasonable interpretations of "widespread". I was making no claims about 6to4's (de)merits. Your argument seems to be that the peculiar operational characteristics of 6to4 should give it additional immunity to being declared historic. I don't find that argument persuasive. The history of multiple protocols that have been declared "historic" shows that vendors seem to care about that designation only when it is convenient for them to do so. Installed base, customer demand, operational considerations and so on all trump whatever the IETF might say about a "historic" protocol. This works both ways: folks might decide to kill something before it becomes historic, or support it long after. We can't compel people to continue supporting it any more than we can make them stop. At most, we can give them (hopefully convincing) reasons to change. If the SNMP experience shows anything, it shows that even that isn't enough. For that reason, I find it amusing when others write of "killing" 6to4. We don't have that kind of power. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call:
Hi - > From: "TJ" > To: "Randy Presuhn" > Cc: > Sent: Thursday, June 09, 2011 10:36 AM > Subject: Re: [v6ops] Last Call: ... > > The point is that the "historic" declaration can be a statement > > about how the IETF wants things to be, rather than how they are. > > If one happens to be a user or vendor of a "historic" technology, > > the declaration might sting a little, but it's really not a big deal, IMO. > > Although I have already stated my position in this issue (against, for now), > I have a problem with the above logic. > You are effectively arguing that this move won't really impact anything ... > in which case I would ask, why are we doing it? No, what I'm saying is that declaring a technology "historic" does not make it go away. If accompanied by strong advice and good alternatives, it might contribute to a reduced likelihood that one will encounter the offensive technology, but things rarely disappear completely, nor as quickly as one might like. Speaking in horribly general terms, rather than the specifics of 6to4: The folks who believe they have a legitimate need for a technology will continue to use it as long as they are able to. The folks who don't find it causing problems for them will tend to leave things alone - there's always the fear that turning something off, even if it appears to be little-used, might break some critical but low-frequency application somewhere in the enterprise. The folks for whom the historic technology has been causing a problem will rejoice and turn it off or remove it from their products, but will still need to defend against it, because you never know what's going to come in from the big bad internet. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call:
Hi - > From: "Rémi Després" > To: "Randy Presuhn" > Cc: > Sent: Thursday, June 09, 2011 1:11 AM > Subject: Re: [v6ops] Last Call: ... > > I'm pretty sure Noel was being scarcastic. There's clear precedent in the > > analogous case where RFC 1227 was declared historic, despite its > > widespread use for that particular application at the time. > > RFC 1227 specified an experimental protocol. > The 6to4 specification is standard track. > Declaring historic a standard track specification although it still serves > legitimate needs would, AFAIK, be a precedent, a regrettable one IMHO. Consider, then, RFC 1157. It was, quite rightly, declared historic years ago, even though it was a full standard and in rather widespread use at the time. Despite that declaration, it remains in use. This despite all the good reasons that its replacement should be used instead. The point is that the "historic" declaration can be a statement about how the IETF wants things to be, rather than how they are. If one happens to be a user or vendor of a "historic" technology, the declaration might sting a little, but it's really not a big deal, IMO. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call:
Hi - > From: "james woodyatt" > To: > Cc: > Sent: Wednesday, June 08, 2011 9:17 AM > Subject: Re: [v6ops] Last Call: > > On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote: > > From: Martin Rex > >> > >> Classification of 6to4 as historic is [in]appropriate use of the IETF > >> process, because it would be a political .. statement. > > > > Well, we've never done _that_ before, have we? Wouldn't want to set an > > unfortunate precedent. > > I see no reason for IETF to avoid setting standards for layer-9 protocols. I'm pretty sure Noel was being scarcastic. There's clear precedent in the analogous case where RFC 1227 was declared historic, despite its widespread use for that particular application at the time. On the other side of the argument, declaring RFC 1227 historic had little (I'm being generous) impact on its continued use. The folks that needed it kept using it, in some cases long after the IETF's replacement for it became widely available. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and APIs
Hi -
> From: "Tom Yu"
> To: "Sam Hartman"
> Cc: ;
> Sent: Wednesday, March 30, 2011 2:40 PM
> Subject: Re: IETF and APIs
>
> Personal observation: "API" is a subclass of "interface". "Network
> protocol" is a subclass of "interface". Interfaces (in the general
> case) are valuable things to standardize. An abstract interface
> ("abstract API"?) that gives guidance to implementors above and beyond
> the bare specification of the network protocol is useful for achieving
> conceptual alignment.
>
> Do people agree?
Yes and no. The experience with SNMPv3's ASIs (Abstract Service
Interfaces) might be instructive.
(1) because implementations of the protocol (or something very
similar to it) already existed, requiring conformance to the
ASIs (beyond the externally-visible behaviour they described)
found no support.
(2) Despite (1), there are *still* people who think the ASIs will be
reflected
in implementations' APIs. (They generally aren't.)
(3) Even though there was already considerable experience with the
implementation of the protocol when these Abstract Service
Interfaces were defined, later work (especially in the isms WG)
found that these definitions required some serious tweaks to
handle cases that people were already thinking about when the
interfaces were defined in the first place.
(4) Some of the lengthy WG discussions and awkward hacks
resulting from (3) in subsequent RFCs were only an artifact of
the specification technique, and were not necessitated by
actual protocol or implementation constraints, in my opinion.
Still, I think it can be very helpful to specify a C library API for things
that are
actually intended to be used like libraries, but I also know that it can
be surprisingly difficult to get them "right" for all environments.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Request for review of draft-yevstifeyev-genarea-historic-03
Hi - > From: "Eliot Lear" > To: "RJ Atkinson" > Cc: > Sent: Monday, March 07, 2011 4:06 AM > Subject: Re: Request for review of draft-yevstifeyev-genarea-historic-03 ... > The IAB and IESG control STD1, and have every right and in fact a > responsibility to say what status they think any document has. You or > anyone else can disagree and have your own list. The "historicization" of RFC 1227 provides an interesting example of this. Without speculating on the motivations behind that decision, I think it does provide a clear example of an explicitly experimental protocol that was actually getting significant use at the time being declared historic. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: MHonArc mail archive line wrapping
Hi - > From: "Masataka Ohta" > To: > Sent: Thursday, February 17, 2011 2:14 PM > Subject: Re: MHonArc mail archive line wrapping ... > But, when plain text is good enough, we use plain text. > > Assuming you have ASCII key board, 80-column assumption is > reasonable. For reasonable devices, I would agree. But the use case cited is for people are using devices with display capabilities which are in some respects much more limited than those of the teletypes and CRTs in common use in the 1970s. The question is whether to change email practice in order to better support these limited devices. (My answer would be "no".) Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SDO vs academic conference, was poster sessions
Hi - > From: "DOLLY, MARTIN C (ATTSI)" > To: "Eric Burger" ; "Alessandro Vesely" > > Cc: > Sent: Tuesday, January 11, 2011 4:34 AM > Subject: RE: SDO vs academic conference, was poster sessions > > At issue though is that these individuals get paid (sponsored) by > someone, either directly or indirectly by corporations and/or > governments. Not necessarily. Some of us have no employer and just do this stuff for the fun of it. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call On draft-yevstifeyev-tn3270-uri-12
Hi - > From: "t.petch" > To: "Mykyta Yevstifeyev" ; "IETF Discussion" > > Cc: "iesg" > Sent: Tuesday, January 11, 2011 8:29 AM > Subject: Last Call On draft-yevstifeyev-tn3270-uri-12 > The provenance of the editor is unknown to > me - and of course, once an RFC has been through the IETF processes, > then the editorship is an irrelevance - but I am concerned that I have > no awareness of the contact provided as the scheme 'Author/Change controller', > no track record, no affiliation, a gmail address. This seems more than > discourtesy, this seems wrong. ... As someone with no affiliation and as someone who chooses not to give out his home address indiscriminately, I object to this line of objection. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
Hi - > From: "Martin Rex" > To: "Julian Reschke" > Cc: ; > Sent: Wednesday, December 29, 2010 6:25 PM > Subject: Re: Automatically updated Table of Contents with Nroff ... > I tried to use xml2rfc once and gave up after 3 hours of getting NOWHERE, > not even _running_ xml2rfc. FWIW, I've never been able to get xml3rfc to run on any of my computers. Something horrible usually happens in the process of getting the TCL stuff working. So, I just use the on-line one at http://xml.resource.org/ Getting groff to run, on the other hand, has been fairly easy on every platform I've tried. ... > With most I-Ds you can tell when authors are using xml2rfc instead > of NRoffEdit, because the documents often contain awkward page breaks > positionas within sections such as Authors and References and more > typos. It's easier to control widows / orphans / page breaks with nroff, but I don't usually worry about them because I know the RFC editor is going to fine-tune the layout anyway. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
Hi - > From: "Julian Reschke" > To: "Barry Leiba" > Cc: "IETF Discussion Mailing List" > Sent: Wednesday, December 22, 2010 11:26 AM > Subject: Re: Automatically updated Table of Contents with Nroff ... > Clarifying: the reason why I'm researching is that apparently some > people think it would be good to have a replacement for xml2rfc.tcl that > *emits* nroff (only - as opposed to plain text/nroff/html as the TCL > code does today). ... Though I happen to like nroff (I also like anchovies) please don't count me among those who think the replacement for sml2rfc.tcl should have nroff format as its *only* output format. Good luck with your research! Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
Hi - > From: "Julian Reschke" > To: "Randy Presuhn" > Cc: "IETF Discussion Mailing List" > Sent: Tuesday, December 21, 2010 1:17 PM > Subject: Re: Automatically updated Table of Contents with Nroff ... > > Here's one incarnation of what I used: > > ... > > Thanks a lot. This seems to be a bit less elegant compared to what John > was hinting at, but it *is* running code. I'll probably try this. If you *know* you'll be using a more modern version of, say, groff, then writing to a file (and *not* instantiating the TOC within the document) is definitely more elegant. However, some installations of groff disable that feature, since it introduces additional security risks. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
Hi -
> From: "Julian Reschke"
> To: "Randy Presuhn"
> Cc: "IETF Discussion Mailing List"
> Sent: Tuesday, December 21, 2010 8:43 AM
> Subject: Re: Automatically updated Table of Contents with Nroff
...
> So, I do understand how generate the ToC at the end, and I'll probably
> grok .so, but what is needed to extract the ToC into a separate file? Is
> there anything in nroff supporting that, or were you just referring to a
> set of homegrown tools? Also, as far as I can tell, the generated ToC
> will already be paginated, so do you post-process it again so it can be
> inserted properly?
Here's one incarnation of what I used:
Along with the other macro definitions (for six-month expiration date
generation and so on) I define a custom ".Nh" macro for section headings,
which just turns around an invokes the ms macros for section headers and
for table of contents entry generation.
.\"
.\" * section numbering - built on the ms macro *
.\"
.de Nh
.in 0
.NH \\$1
\\$2
.XS
\\*(SN \\$2
.XE
.in 3
Then, at the point in the document where we actually want the table
of contents to appear:
.\"
.\" Table of contents - we cheat, using the table of contents
.\" file generated on the last pass through nroff.
.\"
.sp
.ne 5
.ti 0
Table of Contents
.sp
.so toc.ms
.bp
Then, at the very end, we spit out the current table of contents:
.\"
.\" Table of contents here
.\"
.TC yes
To process all this, use the following script to invoke nroff, and peel off the
most recently
generated table of contents from the end. This means that the table of
contents that shows
up in the formatted document is actually that from the previous run. Running
the script
twice resolves pagination inconsistencies. "Bootstrapping" the very first run
(empty "txt"
file) will start out with an empty table of contents, but it will be fine the
next time around (for
a single page ToC, second time around for a multi-page ToC.) This also handles
the
FormFeed insertion.
#
# Files used:
# document.ms = input
# txt = intermediate table of contents extracted from previous nroff run
# toc.ms = table of contents data (updated)
# stdout = "real" output
#
#
# extract table of contents from previous run
#
awk < txt 'BEGIN{skipping=1;}
/Table of Contents/{skipping=0;}
/\.\.\.\./{if (skipping) next; print; printf(".br\n");}' |
sed '1,$s/\.\.\.//' >toc.ms
#
# now run nroff using that old table of contents
#
nroff -ms document.ms |
awk '/FORMFEED/{DoFF=1; print; next;}
/^$/{if (DoFF) next; else print; next;}
{if (DoFF) {DoFF = 0; printf(" \n");} print;}' |
sed '1,$s/.//g' |
sed '1,$s/FORMFEED//' >txt
#
# Strip off the trailing table of contents and we're through
#
awk https://www.ietf.org/mailman/listinfo/ietf
Re: Alternate entry document model (was: Re: IETF processes (wasRe:draft-housley-two-maturity-levels))
Hi - > From: "t.petch" > To: "Andrew Sullivan" ; > Sent: Monday, November 01, 2010 3:24 AM > Subject: Re: Alternate entry document model (was: Re: IETF processes > (wasRe:draft-housley-two-maturity-levels)) ... > So whether we have XStandard, YStandard or ZStandard and how we move > between them is irrelevant (to most of the world). > > Hence my focus is on how we can get an RFC published in the first place, in a > more > timely manner with, ideally, an improvement in the quality. ... Ironically, the more we emphasize improving the "quality" of RFCs, the more we reinforce the myth that all RFCs are standards. I higher percentage of obviously immature, speculative, or even outright garbage documents might help dispel the myth. :-) * 0.5 Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: No single problem... (was Re: what is the problem bis)
Hi - > From: "Ted Hardie" > To: "IETF" > Sent: Friday, October 29, 2010 4:15 PM > Subject: No single problem... (was Re: what is the problem bis) ... > As is moderately obvious from the stream of commentary on this > thread and there companions, there is no *one* problem at > the root of all this. One way to draw this is: ... I wonder whether our collective non-enforcement of the last paragraph of RFC 2026 section 6.2 has also contributed to this mess. When a standards-track specification has not reached the Internet Standard level but has remained at the same maturity level for twenty-four (24) months, and every twelve (12) months thereafter until the status is changed, the IESG shall review the viability of the standardization effort responsible for that specification and the usefulness of the technology. Following each such review, the IESG shall approve termination or continuation of the development effort, at the same time the IESG shall decide to maintain the specification at the same maturity level or to move it to Historic status. This decision shall be communicated to the IETF by electronic mail to the IETF Announce mailing list to allow the Internet community an opportunity to comment. This provision is not intended to threaten a legitimate and active Working Group effort, but rather to provide an administrative mechanism for terminating a moribund effort. Our current way of doing business has only a few wilted carrots and no sticks to goad advancement efforts. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: what is the problem bis
Hi - > From: "Phillip Hallam-Baker" > To: "Scott O. Bradner" > Cc: > Sent: Tuesday, October 26, 2010 12:24 PM > Subject: Re: what is the problem bis ... > Most of the documents to reach STANDARD status in recent years have been > SNMP documents. But even though SNMP has its uses, deployment and use hardly > compares with HTTP which is at DRAFT. And nobody should be considering using > the SNMP 2.0 protocol which is the one that is allegedly STANDARD as it has > no security layer. ... Fact check - the STANDARD is SNMPv3, not any of the various flavours of v2, and SNMPv3 has authentication, integrity, confidentiality, and access control. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Query on SNMP Error Fields
Hi - > From: > To: ; > Sent: Saturday, May 15, 2010 9:02 AM > Subject: RE: Query on SNMP Error Fields ... > This is an strict expectation as per SNMP RFC specs , > that the Set/GEt/GetNext requests set the error status > and error-index field to 0. Citation, please? While it is very reasonable and good defensive programming to set those two fields to zero in a request, I'm not aware of any text in the relevant RFCs that would actually *require* it. As long as the values present in the request are within the bounds permitted by the ASN.1 grammar, and implementation has no legitimate reason to reject them, as far as I know. > depending on this, Most of the SNMP agent implementations > copy the request message buffer Not the ones with which I am most familiar. > and modify the error status and error index to non-zero > only if an errror occured. This would be contrary to the elements of procedure in, for example, RFC 3416 clauses 4.2.1 and 4.2.5. The elements of procedure explicitly identify the cases when the error status and error index are set to zero. > if you already set it to non-zero , the response may actually be > meant as a success but, will always show errored value. This is just bad programming, and is not justified by the relevant elements of procedure. > So, IMHO, thism is an unacceptable practice to set the error > index /status to non-zero vaue in request. It's unwise (albeit legal) for the sender of the request, since an over-zealous receiver might (incorrectly) reject the request. What is truly unacceptable is for the responder to ignore the elements of procedure and not fill in the values of error status and error index required in the response by the standard. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Query on SNMP Error Fields
Hi - > From: "deepak rajaram" > To: > Sent: Friday, May 14, 2010 4:18 AM > Subject: Query on SNMP Error Fields ... > While the SNMP RFC(1157/2571/SNMPv3) mentions the behavior of "Error Status" > and "Error Index" field as "will be set in the response" and the value of > these fields in all set/get/getnext request is zero, It does not mention if > it is *mandatory* for these fields to have zero in set/get/getnext. Could > these fields be modifiable in set/get/getnext. As the comments in the ASN.1 say, the values of these two fields are sometimes ignored. In my opinion it would be legal but unwise to use non-zero values in those requests. Some over-zealous implementor's code might actually check for zero, and you'd be in the position of explaining why your implementation doesn't interoperate with deployed systems. Be conservative in what you send... Likewise, if your implementation checks those values in any situation other than the situations spelled out in the specifications, you could also find yourself explaining why your implementation doesn't interoperate with deployed systems. Be liberal in what you accept Randy Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Make HTML and PDF more prominent, was: Re: Why the normative
Hi - > From: "Peter Saint-Andre" > To: > Cc: ; ; ; > > Sent: Friday, March 19, 2010 2:56 PM > Subject: Re: Make HTML and PDF more prominent, was: Re: Why the normative ... > naïveté, à ... > façade ... > übermensch ... > résumé ... > soirée ... > Café ... Modern English spellings, please? If these are the words I think they are, they are loan words that became part of English long ago. Retaining the spellings they had in the languages they were borrowed from provides no value, and seems like an affectation. Or should we start spelling "Hotel" with accent circonflexe, and revive the English letters thorn and eth while we're at it? Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC and 2010?
Hi - > From: "Julian Reschke" > To: "Glen Zorn" > Cc: "'Christian Huitema'" ; "'The IETF'" > > Sent: Monday, January 11, 2010 3:16 AM > Subject: Re: XML2RFC and 2010? ... > Maybe you only have the XML source under version control, and you want > to check the actual text you submitted? (without relying on somebody > else having it archived). ... That will only work if one also has the generating tool and library files (such as the bibliography data) under version control as well, and if one trusts the tool suite to have no other date-dependent behaviour. From a configuration management perspective, those are some huge "ifs". I think one would be safer keeping both the source and the submitted generated files under version control. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Corporate email attachment filters and IETF emails
Hi - > From: "Richard L. Barnes" > To: "IETF Member Dave Aronson" > Cc: "IETF Discussion" > Sent: Monday, December 14, 2009 9:46 AM > Subject: Re: Corporate email attachment filters and IETF emails > > Clearly, the best solution to this problem is to enforce Latin as the > official language of the Internet. Lots of people already use the > Latin character set! It's about time we got rid of that pesky J and W, and we don't *really *need both V and U, do uue? :-) Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IUCG IDNA2010 SIG
Hi - > From: "jean-michel bernier de portzamparc" > To: "internet users contributing group" > Cc: ; > Sent: Sunday, December 06, 2009 3:48 PM > Subject: IUCG IDNA2010 SIG ... > le:///C:%5CDOCUME%7E1%5Cjfcm%5CLOCALS%7E1%5CTemp%5Cmsohtmlclip1%5C01%5Cclip= ... It's interesting what leaks out of some tools. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Regarding RIM's recent IPR disclosures
Hi - > From: "Andrew Allen" > To: > Sent: Thursday, November 19, 2009 6:11 PM > Subject: Regarding RIM's recent IPR disclosures ... > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information > from your system. Use, dissemination, distribution, or reproduction > of this transmission by unintended recipients is not authorized and > may be unlawful. ... This is just plain silly. Or is it willful ignorance of the "Note Well" terms? Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents a URN (and ignores IETF IPR rules)
Hi - > From: "Michael Montemurro" > To: "IETF-Discussion list" ; "Cullen Jennings" > > Sent: Thursday, November 19, 2009 4:38 PM > Subject: Re: RIM patents a URN (and ignores IETF IPR rules) ... > My company > has asked for your patience while they take the time to evaluate the > concerns and determine if there is an appropriate course of action in > this matter to alleviate the concerns of the community. ... With the long history of "Note Well" slides and notices, and the claim of http://tools.ietf.org/html/draft-montemurro-gsma-imei-urn to be in full conformance with BCP 79, it would seem the time for evaluating "an appropriate course of action" was some time in the past. This looks really bad to me, and I'm having a hard time figuring out what an innocent explanation for this might be. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technicalplenary the last IETF session, like it was before
Hi - > From: "John C Klensin" > To: "Stanislav Shalunov" ; > Sent: Tuesday, November 10, 2009 9:43 AM > Subject: Re: Fix the Friday attendance bug: make the technicalplenary the > last IETF session, like it was before ... > Also keep in mind that, as the IETF becomes more international, > Friday is part of the (religious as well as secular) weekend for > some cultures and that the religious weekend starts late Friday > afternoon for others. I think there are reasonable odds that > the problems with Friday meetings --especially those that run > into the afternoon -- are going to get worse over time, no > matter what the IETF does. ... I'm s tired of this line of argumentation. Sunday is part of the (religious as well as secular) weekend for some cultures, too. We've dealt with (or ignored) this reality for decades. If we're going to trample on sensitivities, we may as well be equal-opportunity about it. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
Hi - > From: "Julian Reschke" > To: "Randy Presuhn" > Cc: "IETF Discussion Mailing List" > Sent: Wednesday, July 15, 2009 10:13 AM > Subject: Re: Automatically updated Table of Contents with Nroff ... > And of course you can do that with xml2rfc as well; just automate the > process of converting the source file to something that can be included > into the XML source using the standard XML include mechanisms. I couldn't find such mechanisms described anywhere the first time I used xml2rfc. I just looked at the W3C website XML pages, and still am unable to find them. How does one do a simple ".so" or a "#include" in XML? Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
Hi - > From: "Julian Reschke" > To: "Randy Presuhn" > Cc: "IETF Discussion Mailing List" > Sent: Wednesday, July 15, 2009 10:13 AM > Subject: Re: Automatically updated Table of Contents with Nroff ... > Point is: nroff and xml2rfc share the advantage that they are simple > text based formats, which can be put under version control, and > collaborative editing/change control just works. Missing features can > simply implemented using automated pre- or post-processing stages. ... With respect to boilerplate, xml2rfc lacks this advantage. *It* generates the boilerplate; the user has no way of knowing whether the option present in the source file will result in the same output text today as it did yesterday. From a configuration management / revision control perspective, this is highly undesirable. It would be much better to be able to "#include" a versioned source file for those bits. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
Hi - > From: "Julian Reschke" > To: "Randy Presuhn" > Cc: "IETF Discussion Mailing List" > Sent: Wednesday, July 15, 2009 2:13 AM > Subject: Re: Automatically updated Table of Contents with Nroff ... > > For editing a document, particularly a largish one, the availability of > > .so is for me nroff's biggest advantage over xml2rfc. > > ... > > How exactly is that an advantage of xml2rfc? That's my point. It's a capability xml2rfc lacked, at least the last time I used it. For the user to be able to split stuff up into multiple files is a huge advantage which should be familiar to any programmer. Examples from my own experience: It's cleaner to be able to keep mib modules in a separate files, rather than extracting it from a formatted document. This is particularly true when there are multiple MIB modules in a document. Common references (especially for a bundle of inter-related I-Ds, but also for RFCs) can be handled as macros that result in mnemonic values showing up both in the source and in the generated output. This is especially useful when one RFC is replaced with another: one little edit to the file of reference macros, rather than going through the whole bundle of source files. Finally, it is a much cleaner way to handle boilerplate, particularly if you want to use configuration management software for your sources and have a "paper trail" of boilerplate changes. Now, it is true the RFC editor wanted nroff sources in the form of a single file. Fortunately, this is trivial to produce at publication time using soelim or equivalent. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Automatically updated Table of Contents with Nroff
Hi - > From: "Stefan Santesson" > To: "Donald Eastlake" > Cc: "IETF Discussion Mailing List" > Sent: Tuesday, July 14, 2009 6:03 PM > Subject: Re: Automatically updated Table of Contents with Nroff ... > All I have managed to get across are ways to generate a TOC in the end of > the document, that you have to move manually. When doing that move, your > page numbering and formatting may change. ... No need to manually edit. Use the macros or awk / sed to spit the toc into a file which can be inserted into the correct position by the .so nroff directive. This will result in a table of contents in the correct position. There is the possibility that if the number of toc pages has changed from one iteration to the next that the page numbers will be off by one, but that will go away the next time the process runs. For editing a document, particularly a largish one, the availability of .so is for me nroff's biggest advantage over xml2rfc. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Hi - > From: "Stefan Santesson" > To: "Donald Eastlake" ; "IETF Discussion Mailing List" > > Sent: Wednesday, July 01, 2009 3:42 PM > Subject: Re: More liberal draft formatting standards required > > How do you translate the .nroff formatted document to a readable text > document? One of the advantages of nroff input is that it *is* human readable. (To me it seems much easier to read than HTML, but that's not the issue here.) To generate formatted output (in a variety of possible formats) the freely- available groff program works well. > Can emacs do that for you? I don't know. I prefer vi. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
Hi - > From: "Eliot Lear" > To: "Sam Hartman" > Cc: ; > Sent: Wednesday, June 03, 2009 11:15 PM > Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management > (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP ... > Also, I agree with you that interoperability is not the first and > primary goal. Clearly, and I hope Dave and others will agree, the > primary goal is the ability to roll out new useful functions and > services in a way in which they can be managed in a scalable manner, > where one has understood the network impact (or total cost, if you will) > for that service. And Section 2 provides a really nice illustration of > that, with regard to what happened at Berkeley. Unfortunately, I think the IETF has only adopted the first sentence of this paragraph. The hard work (and it is hard work) to build interoperable *management* seems to have largely been abandoned in the IETF. I think the state of the netconf work attests to the shift to just shoveling around vendor-specific blobs, rather than management information. > I have another problem with 3.2: I think the SMI and other > registry-based forms of structured data may be overrated in some cases. They're not a panacea. The SMI has weaknesses that can make models cumbersome. I haven't seen a data representation or way of representing data semantics that was ideal for all purposes, and I doubt I ever will. Unfortunately, this recognition that nothing is perfect seems to have led the IETF dangerously close to "anything goes." One would hope that this document would help WGs avoid the worst excesses. > Sometimes what is being managed is very simple data, through a central > service. One has to question who the consumer of the data is prior to > determining how one encodes that data, or even what data is truly > necessary. Consider the case of an application that is simply calling > home to determine if there are patches. How much structured data does > that service need? If there will ever be more than one patch, if there are dependencies between patches, if there is every the need to revert, if there are hardware or model dependencies It's really easy to over-simplify, and end up needing a whole bundle of band-aids as the system's needs evolve (or are recognized). ... > What I would suggest is that some additional context is necessary > throughout the document to indicate really who we are talking to. Are > we limiting our role to router management? What happened to the toaster > with an SNMP stack? Would we use SNMP today for that toaster? Who > would manage it? Well, let's put it in a more serious context and swap > toaster for major appliance like air conditioner or refrigerator or PDU. The IETF management discussions have increasingly limited themselves to what it takes to manage a few types of network gear. It seems to me that the IETF abandoned any hope of doing system management, or even management of multi-vendor systems, a long time ago. This may be a bug, this may be a feature. The thrust of this document seems to me to be a recognition of this state of affairs, and that consequently, if we're going to let a thousand vendor- or application-specific flowers bloom, a little advice to help avoid some of the mistakes of the past would be helpful. Consequently, I think having this document is a good thing. The advice it gives reflects the current fragmented state of affairs with respect to management information, and would be useful to folks trying to do a good job in this environment. I can support this as an informational document. I could somewhat reluctantly go along with making it BCP - our experience with that catch-all designation makes it clear that "Best" only means "what we could more-or-less agree on" and "Current" can mean "we really hope something better will come along, but aren't going to hold our breath." Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
Hi - > From: "Iljitsch van Beijnum" > To: "IETF Discussion Mailing List" > Sent: Wednesday, April 15, 2009 2:49 AM > Subject: Re: 75th IETF - Hotels ... > Do we have an RFC for how to format phone numbers? ITU E.123 would be what you want. http://www.itu.int/rec/T-REC-E.123-200102-I/e Clause 2.8 hints at those annoying parenthesized things, and 7.2 makes it clear it's not an appropriate notation for international numbers. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Repair of Public Mail List Archives Complete
Hi - > From: "Tom.Petch" > To: "Alexa Morris" > Cc: > Sent: Tuesday, March 17, 2009 2:34 AM > Subject: Re: Repair of Public Mail List Archives Complete ... > But when I really need an archive, to see what was > agreed in 2006, I have to get there day by day by painstaking day by tedious > day > at a time. I can see no other more direct way. The files at ftp://ftp.ietf.org/ietf-mail-archive/ are much better suited for such searches, especially when the time frame is fuzzy. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU
Hi - > From: "Phillips, Addison" > To: > Sent: Monday, March 02, 2009 9:49 AM > Subject: RE: draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU > > Hi Tex, > > I don't think this is probably appropriate, at least for this list to > consider. Tex's posting came after the document shepherd (co-chair Martin Duerst) had sent the information to our AD requesting that the IESG consider publishing it. So although the IESG has not yet (AFAIK) acted on the request, much less issued an IETF last call, I can understand why ietf@ietf.org might be included. I have already responded to it on both lists, even though I think the issue is probably of little interest to most on the ietf@ietf.org list. Unless instructed to do otherwise by our AD, I would suggest that all follow-on discussion be directed to l...@ietf.org > 1. You haven't posted to LTRU's mailing list, only ietf-languages@, yet. Tex's message was posted to *both* lists. > 2. Even if draft-4645bis is approved, the process for language tags > (in either RFC 4646 or its proposed successor) allow you to register > the information you want, if you think it was inappropriately omitted. ... Correct. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor YU
Hi - > From: "Tex Texin" > To: ; > Sent: Monday, March 02, 2009 1:05 AM > Subject: [Ltru] draft-ietf-ltru-4645bis-10.txt issue with preferred valuefor > YU > > With respect to the proposed update to the Language Subtag Registry > draft-ietf-ltru-4645bis-10: > > I would like to lodge an objection to the deletion of the Preferred-Value for > language subtag YU. As ltru co-chair: it's exceedingly late for such an objection - the issue was discussed at length in the working group over a year ago. A recent revisiting of the question arrived at the same conclusion. > This change breaks the equivalence class relation between YU and CS. > It detrimentally changes the behavior of existing implementations. As a technical contributor: The main reason that CS does not make sense as a preferred value for YU is that there is *not* an "equivalence class relation" between them. There are pieces of what was YU that are not covered by CS. To treat them as an "equivalence class" ignores linguistic, geographic, and political reality. > The loss of the relationship between YU and CS makes documents that were > believed to be tagged equivalently, to no longer be equivalent. In my opinion, regarding them as equivalent is an error, since CS and YU don't encompass the same regions. > There is also no benefit to this change. I disagree. The change removes an error. > To be concrete, assume a user attempts to find documents for languages from > Yugoslavia. Language tags do *not* pretend to be able to answer this sort of query. Using a region subtag (e.g. 'CS') says that the data subtag uses a specific variety of the primary language, and that the party tagging the data believes that this distinction is useful. For example, I could tag this paragraph with 'en' or with 'en-US'. Is that extra distinction necessary or useful? In this case, no. Consequently, the "retrieving documents by region subtag" use case, although technically permitted by RFC 4647, is not realistic, and in many ways contrary to the basic "tag wisely" principle. > Using the then current registry data, a query tool noting the preferred > value relationship, matches either xx-YU and xx-CS. > > Another user searches for documents for Serbia. > > A query tool using the current registry data noting the preferred value > relationship, matches either xx-YU and xx-CS. > > The results are in some sense accurate and complete, given the history of the > subtag. No, they are not. (1) there is no requirement, much less a guarantee, that the data will bear a region subtag at all (2) there are many bits and pieces of YU not covered by CS - even if data always bore a region subtag, the YU->CS mapping would miss all the other territory that once belonged to YU. (3) blindly replacing all YU subtags with CS subtags would in fact falsify some data, since the language could well be of a variety covered by YU but not by CS. > After this change in the preferred value relationship, the query > tool does not know to search for both xx-YU and xx-CS, since the > registry does not indicate a relationship. Only one or the other > subtag is used for each query. However, the query results are now > incomplete since some documents for xx-YU have been tagged with > the one-time preferred tag of xx-CS. The relationship cannot be adequately automated with a simple one-way pointer like "preferred-value". The former YU also encompassed BA, HR, ME, MK, RS, and SI. > Comments in the registry are not a solution. Comments are a good > thing for recording rationale and tangential history. However, > implementers are not going to go thru and read the comments on any > or all tags in order to make a correct implementation. They are going > to implement based on the schema and operate with the data values. If someone (or something) is applying region subtags, they'd better have sufficient knowledge of the language varieties to do so meaningfully. This effectively requires *understanding* those comments and much more. The Language Subtag Registry does *not* attempt to record all the information needed to recognize language varieties. Rather, once someone (or something) has made a distinction, the LSR provides the bits needed to encode a tag for that language variety. In the particular case of the languages of the former YU, the region subtags now available (such as BA, HR, ME, MK, RS, and SI) are arguably far more useful, if someone needs to distinguish regional variations in their Croatian-language data, than just YU. (It's unclear to me whether YU would ever have been terribly useful, since it would allow the distinction of Croatian as spoken there from Croatian spoken somewhere (where?) else.) > The registry should stay as it is with respect to YU and retain > CS as the preferred value. > > As CS is now being used as a preferred value, deprecated or not, > there isn't a compelling motivation to remove the preferred value for YU. Please
Re: It's time for some new steps
Hi - > From: "Wes Hardaker" > To: "Scott Brim" > Cc: > Sent: Monday, February 09, 2009 10:22 PM > Subject: Re: It's time for some new steps ... > FYI, I unsubscribed twice. The first method (logging in with my > assigned password and hitting unsubscribe) failed even though it told me > it succeeded. > > So I tried the second approach which was to simple enter my address and > hit the unsubscribe button to have it mail me a confirmation URL. > Visiting the confirmation URL did seem to work, so I'd suggest people > try this method for unsubscribing if the login method fails for you like > it did me. ... When I finally did manage to unsubscribe, the list owner re-subscribed me. I wonder whether he's doing this to all those FSF posters, too. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: It's time for some new steps (was: [Welcome to the "Ietf-honest"mailing list])
Hi - > From: "Dave CROCKER" > To: "IETF Discussion" > Sent: Monday, February 09, 2009 4:38 PM > Subject: It's time for some new steps (was: [Welcome to the > "Ietf-honest"mailing list]) ... > Normally, I advocate entirely ignoring silliness, but the current version of > it > is more than silly. Particularly since mail to the -request address bounces, and using the web interface to unsubscribe apparently has no effect. Subscribing someone to a list and not allowing them to remove themselves... seems like a page from the same "win friends and influence people" checklist as the fsf campaign seems to be using. :-( Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I Love this subject header! (was Re: Reject TLS!)
Hi - It might be a bit more credible if they offered a plausible alternative technology. Have they said when they'll post their I-D (meeting all RFC 5378 requirements, of course)? Randy > From: "AJ Jaghori" > To: "mshore" ; "Jeffrey Hankins" ; > ; > Sent: Monday, February 09, 2009 3:41 PM > Subject: Re: I Love this subject header! (was Re: Reject TLS!) > > Lol :) > > Its an interesting attempt, to say the least... > > > > On 2/9/09, mshore wrote: > > On 2/8/09 11:22 AM, "Jeffrey Hankins" wrote: > >> Please stand up for software freedom and reject the TLS proposal until > >> RedPhone Security issues a royalty-free patent for TLS. Thank you. > > > > And the content cracks me way the heck up, too. Otherwise > > this is really, really annoying. What, these people think > > the IETF takes votes? > > > > Melinda > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > -- > Sent from my mobile device > > AJ Jaghori > Chief Architect, Author, & Professor | Data Network & Security > ciscowo...@gmail.com > "Sent via my Android Powered Mobile..." > ___ > 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: Please Review Draft IESG Statement on Activities that are OBE
Hi - > From: "John C Klensin" > To: "Spencer Dawkins" ; "Harald Alvestrand" > ; > Sent: Tuesday, February 03, 2009 11:50 AM > Subject: Re: Please Review Draft IESG Statement on Activities that are OBE ... > (1) Anything that clearly shifts this document toward "guidance > to the community about how the IESG is thinking about things" > and away from "more rules" will make me proportionally happier. > Certainly eliminating the 2119 language would help in that > regard. ... The proposal strikes me as largely a statement of common sense. However, "common sense" is notoriously difficult to state correctly in formal terms, and a fear that the 2119 terms lack the fuzziness needed for this kind of proposal. We *generally* don't want to spend resources on things OBE, but there are cases (like TCP/IP) where it might be in the organization's interest to do so anyway. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 "contributions"
Hi - Thanks for the clarification. Does this mean that if a WG really has no concern that the documents it's working on would be spun off to another organization, then it doesn't need to worry about tracking down "contributors"? Randy > From: "Contreras, Jorge" > To: ; > Sent: Wednesday, January 14, 2009 5:33 PM > Subject: Re: RFC 5378 "contributions" > > Re: RFC 5378 "contributions"No, absolutely not. Use of pre-5378 materials in > the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules). > > > - Original Message - > From: ietf-boun...@ietf.org > To: IETF Discussion > Sent: Wed Jan 14 19:32:27 2009 > Subject: RFC 5378 "contributions" > > Hi - > > I originally asked this question on the WG chairs' list, and > was asked to ask again here... > > The discussion about RFC 5378 (what little I've been able to > understand of it, anyway) has focussed on I-Ds and RFCs. > However, the definition of "contribution" in that document > includes, among other things, mailing list discussions. > > Does this mean that we need to get contributor permission > before using, for example, material from a pre-5378 RFC in > a mailing list discussion, or before including text from a > pre-5378 email posting in an internet draft? > > This seems really silly, but that's what the discussion is > starting to sound like to me. > > Randy > > > ___ > 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
RFC 5378 "contributions"
Hi - I originally asked this question on the WG chairs' list, and was asked to ask again here... The discussion about RFC 5378 (what little I've been able to understand of it, anyway) has focussed on I-Ds and RFCs. However, the definition of "contribution" in that document includes, among other things, mailing list discussions. Does this mean that we need to get contributor permission before using, for example, material from a pre-5378 RFC in a mailing list discussion, or before including text from a pre-5378 email posting in an internet draft? This seems really silly, but that's what the discussion is starting to sound like to me. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem
Hi - > From: "Russ Housley" > To: "Doug Ewell" > Cc: ; > Sent: Monday, January 12, 2009 1:07 PM > Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments > on a proposed Work-Around to the Pre-5378 Problem > > Doug: > > I hope this response answers your pragmatic questions. > > >1. What do I, as editor of an I-D and previously editor of a > >related RFC that is not quoted in the current I-D, need to do in > >order to allow the WG chairs to move my draft forward into IETF Last Call? > > You can proceed to IETF Last Call now. However, if updates to the > I-D are needed you may be faced with a problem depending on your > situation. I presume that some or all of the text in the I-D was > contributed before 10 Nov 2008. If so, then an update to that I-D > requires you or the WG chair to determine if the people that made the > contribution are willing to grant the additional rights required by > RFC 5378. If so, you are done. If not, you will need some > work-around like the one being discussed on this thread. When updates have been wordsmithed by the WG, is it true that only a person whose exact N words (where N >= X) were used needs to sign off on it, and we don't need to track down every single variation suggested during the wordsmithing? Can we have a guideline for WG chairs on a value for X? > If IETF Last Call or IESG Evaluation brings comments that require an > update to the I-D, then you end up with the same situation. > > If the document is approved without change, then the RFC Editor will > ask each of the authors to grant the additional rights required by > RFC 5378. If this cannot be done, then the document will sit in the > queue until some work-around like the one being discussed on this > thread is implemented. ... In the particular case Doug mentions, there are *no* authors, only editors working under the direction of a WG. Does this still apply? Wouldn't it make more sense for the WG to grant the additional rights, since it is the WG which authored the work. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewandcomments on a proposed Work-Around to the Pre-5378 Problem
Hi - > From: "Bill Manning" > To: "Lawrence Rosen" > Cc: "'IETF Discussion'" > Sent: Saturday, January 10, 2009 2:42 PM > Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your > reviewandcomments on a proposed Work-Around to the Pre-5378 Problem ... > er... thats -NOT- what I was trying to point out. The IETF > was given permission to publish an authors work but was not > allowed to impune joint authorship. The IETF did not create the > work - it provided a publication vehicle. ... That certainly was *not* my understanding when I offered my services as an editor for the various IDs and RFCs where I've functioned in that role. I, and I'm sure many others in those working groups, thought those documents were products of the working group, which did that work for the IETF. For me to claim authorship of, e.g., RFC 3417, would be intellectually dishonest. For the IETF to claim that I was its author, rather than merely an editor acting on the instruction of a working group, is downright delusional. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
Hi - > From: "John Day" > To: "Rémi Després" ; "John C Klensin" > > Cc: "Bryan Ford" ; > Sent: Monday, December 29, 2008 7:24 AM > Subject: Re: The internet architecture > > No it isn't Transport's job. Transport has one > and only one purpose: end-to-end reliability and > flow control. > > "Managing" the resources of the network is the network layer's job. > > Although, these distinctions of Network and > Transport Layer are . . . shall we say, quaint. > > Multihoming is fundamentally a routing problem. Depends on what one is routing *to* - application, host, or attachment point. ... > It is a problem of routing not be able to > recognize that two points of attachment go to the > same place. Portraying it as anything else is > just deluding yourself. The multiple-entrance, multiple exit problem could also be attacked with a variation on good ol' multi-link procedure, but done just below (or as a sublayer of) transport, but above (connectionless) network, and not restrict it to datalink. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Hi - > From: "Contreras, Jorge" > To: "Randy Presuhn" ; "IETF Discussion" > > Sent: Thursday, December 18, 2008 2:37 PM > Subject: RE: where to send RFC 5378 license forms ... > The boilerplate text is owned by the IETF Trust. No author permissions > are needed. This is good news. Who owns the oft-repeated 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]. > > As a slightly harder example: what is the set of names > > required to cover > > all the boilerplate text that goes into an RFC containing a > > MIB module? > > See above. In addition, MIB modules were licensed broadly under RFC > 3978, so they are less problematic than non-code text. I'm referring to the bits effectively required by the MIB doctors, e.g.: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of ... and For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. and various incarnations of this stuff that appear in the text of RFCs that happen to contain MIB modules, not the stuff that's in the MIB modules. (Earlier versions of this were rather lengthy.) Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Hi - (I trimmed the CC list, assuming that the WG chairs and Trustees that care about this stuff are already listening to the IETF discussion.) > From: "Ray Pelletier" > To: "Sam Hartman" > Cc: "Martin Duerst" ; "Randy Presuhn" > ; "Working Group Chairs" ; "IETF Discussion" ; "Trustees" > Sent: Thursday, December 18, 2008 12:26 PM > Subject: Re: where to send RFC 5378 license forms > > > On Dec 18, 2008, at 2:14 PM, Sam Hartman wrote: > > > Why do we need to send these license forms in at all? > > > > I thought the requirement was that the authors get the necessary > > rights. Are you just conveniently keeping track for us? > > I would envision folks providing 5378 licenses to the Trust or their > pre-5378 work. If licenses are submitted their names could be posted > online for other Contributors to ascertain whether a pre-existing > work has been so licensed. ... >From this list of names and the content of a pre-5378 RFC, how can a contributor ascertain that that pre-existing work has been licensed in its entirety? Suppose, for example, it contained an extended passage which was submitted to the working group either on a mailing list or hammered out in a face-to-face session, but is not identified as such. Particularly in the latter case (but also in the case of incomplete WG archives) there doesn't appear to be any reasonable way for a contributor to make this determination with much confidence. Just as a simple "for example": what is the set of names that needs to be posted just to cover all of the boilerplate text we're required to put in our documents? As a slightly harder example: what is the set of names required to cover all the boilerplate text that goes into an RFC containing a MIB module? Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Hi - > From: "John C Klensin" > To: "Randy Presuhn" ; "IETF discussion list" > > Sent: Wednesday, December 17, 2008 2:40 PM > Subject: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary ... > What gives your WG the ability to function is 5.4, where the > Trust gives back to the IETF participants what the Trust > received under 5.1 and 5.3. But they can't give back what they > don't have, so, if your WG is required to derive its permission > to do work from 5.4 and a previous author takes a walk rather > than making the 5.1 guarantees and 5.3 transfers _to the > Trust_... ... Ok, so if my understanding was incorrect, at what point must we stop work until this is corrected? (I can virtually guarantee that we will not get explicit permission from every individual named in an acknowledgement section of one of the antecedants of the documents we're updating. Paraphrase the whole thing? Ain't gonna happen.) a) We cannot submit any more I-Ds until this is fixed b) We can continue to submit I-Ds, but cannot hand off to the IESG c) We can hand off to the IESG, but not do IETF last call d) We can do IETF last call, but not hand it over to the RFC editor e) We can hand it over to the RFC editor, but not actually publish I'd be willing to wager that, in its current mood, the WG would simply disband rather than deal with any of these. z) We stop updating our documents, hand over an existing I-D without the offensive IPR language, and hope that the IESG requires no changes, and use RFC errata to deal with the (minor) problems that we know exist in that I-D. Somehow this seems totally bogus, since the "authors" were all editors working under the direction of the working group to produce a work for the working group. If anything, the transfer should be from the WG (or the IETF) to the trust, not from the people who were high- stress typists for the WG. Likewise, the various contributors whose words went into the collaborative blender were doing so under the long-standing NOTE WELL provisions, so getting their permission again seems, well, pointless. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Hi - > From: "Dave CROCKER" > To: "John C Klensin" > Cc: "IETF discussion list" > Sent: Wednesday, December 17, 2008 1:05 PM > Subject: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary ... > That is: Working groups are part of the IETF and 'authors' of working group > documents are acting as when writing IETF documents.agents of the IETF. > While I assume the missing word is "editors" > there might be underlying intellectual property owned by the companies that > authors work for, the actual document is commissioned by, and copyright > should > be owned by, the IETF. AMEN! > Let me carry it further: When Erik Huizer and I wrote the first IETF Working > Group Guidelines document, it was at our initiative. (Well, really, Erik's.) > When it was adopted by the IETF, I automatically assumed that the IETF owned > it. That has always been my understanding regarding work I've done for the IETF. > That is, after all, what we assert when outside technology is brought into > the > IETF and we insist that they are handing over "change control". What is > change > control if not the authority to make changes to the document? Yup. > So when Scott Bradner did the revision to the IETF Working Group Guidelines > document the idea that he had a legal obligation to get our permission would > have -- and certainly now does -- strike me as silly. Particularly since the permission to create derivative works and successor standards has been granted as part of the boilerplate for a long long time. > That's me talking as a participant, about pragmatics, not me pretending to be > a > attorney, talking about copyright law. Ditto. Consequently, as a WG co-chair who wants his WG to finish up in this century, I read RFC 5378 section 5.3 as giving working groups what they need so they can ignore all this stuff about tracking down long-gone contributors, and that it's merely a re-incarnation of what has long been the intent behind the NOTE WELL text. One can easily imagine a situation in which a disgruntled party named as a contributor in an early version of work might refuse to give permission under some readings of an RFC 5378 regime, effectively killing the work. As John says, paraphrase is *not* a realistic option, especially with carefully-crafted WG compromise text. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
Hi - > From: "Dave CROCKER" <[EMAIL PROTECTED]> > To: "Theodore Tso" <[EMAIL PROTECTED]> > Cc: > Sent: Wednesday, December 10, 2008 10:23 AM > Subject: Re: How I deal with (false positive) IP-address blacklists... ... > Really: If there is a larger issue that the IETF can and should tackle, then > let's talk about it. But I'm still not seeing how the thread you started > qualifies. ... The problem is a mis-match between the protocol model (and the points for spam blocking it affords) and the economics of actual use. The debate about sender-vs-recipient responsibility for dealing with false positives misses the point that the party usually responsible for the blocking is under the control of neither the sender nor the recipient. I've spent enough time on hold to far-away lands to be skeptical of claims that ISPs are really that interested in resolving false positives, but I recognize that the experience of individual users isn't considered valid data. Ted's core point seems to be that that the "delivery value" economic argument does not always align with the "sender assumes responsibility for out-of-band-delivery when blocked" model, particularly when the cost of out-of-band delivery is far greater than the value of delivery to the sender, no matter how badly the intended recipient who requested the information might want it. By looking only at the SMPT protocol exchange, rather than the next-layer-up request-for-info followed by response, the real use case is distorted. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advice on publishing open standards
Hi - > From: <[EMAIL PROTECTED]> > To: > Sent: Friday, November 28, 2008 10:50 AM > Subject: Advice on publishing open standards ... > For the past 5 years, I've been processing written sign language as data. > I've worked directly with the inventor of the script, which is over 30 > years old. > > We are ready to standardize. The latest symbol was finalized last month > after more than a year of improvements and refining. ... > I believe sumbitting to the IETF will be the best route. I was wondering > if anyone had some advice before I begin the formal preparation of the > Internet Drafts. Have you considered taking this to Unicode? Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to applicationdevelopers
Hi - > From: "james woodyatt" <[EMAIL PROTECTED]> > To: "Behave WG" <[EMAIL PROTECTED]> > Cc: > Sent: Tuesday, November 25, 2008 4:34 PM > Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to > applicationdevelopers ... > The basic problem with NAT66 is that it introduces the possibility of > more than one global IPv6 address realm. Where there is more than > one, there is *any* number, not just the current realm and the single > realm on the other side of the relevant NAT66 box. Fixing your self- > address in whatever address realm any given communications peer > happens to reside is the canonical problem that NAT causes for > applications developers, and NAT66 is no exception to that. ... >From the peanut gallery... The potential disconnect between an application's notion of "self" and how it's identified in the local and big internets is a difficulty with any kind of NAT and cute DNS tricks. But weren't these the kinds of problem HIP was intended to address? Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [73attendees] Is USA qualified for2.3ofdraft-palet-ietf-meeting-venue-selection-criteria?
Hi - > From: "Melinda Shore" <[EMAIL PROTECTED]> > To: "Randy Bush" <[EMAIL PROTECTED]>; "Scott W Brim" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; > Sent: Tuesday, November 18, 2008 11:22 AM > Subject: Re: [73attendees] Is USA qualified > for2.3ofdraft-palet-ietf-meeting-venue-selection-criteria? ... > I don't know what that means. Canada, for example, is a peacekeeper > nation that requires visas for entry from countries from which there are > many IETF participants (India, China). Is the issue the visa requirement > itself or is it how visas are processed? ... I think the key concerns, in order of importance, are: (1) typical time required to process a visa request (2) likelihood that a visa will be granted to an IETF-er (3) cost of the visa application (1) and (2) are the "biggies". (3) gets lost in the noise of meeting expenses for most destinations. As someone who applies for (and gets, usually within three days) visas at least once or twice a year to countries other than the US, I don't think the requirement for a visa is itself a problem. The problem is the processing, and the QoS *does* vary enormously, depending both source and destination address. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
Hi - > From: "David Romerstein" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, November 12, 2008 11:18 AM > Subject: Re: several messages > > On Wed, 12 Nov 2008, Randy Presuhn wrote: > > > Agreed, but if those analogies are correct, they also undermine the > > argument. > > Neither the email sender nor the recipient (the ones to whom email is most > > important) typically have any voice whatsoever in the selection of the > > DNSBL. > > End recipients *absolutely* have a voice in the DNSbl selection process. > They have the option of voting with their feet if their ISP chooses a > DNSbl that negatively impacts them. ... Huh? Concrete, real example: I send a message to an IETF mailing list. A list subscriber's ISP rejects the forwarded message. IETF's mailman drops the subscriber, because this has been happened multiple times. I can't notify the subscriber, because their ISP also rejects my email. My ISP is irrelevant to the scenario, and the (now former) list subscriber doesn't even know this has happened, or why. Another real, concrete example: some (but not all) messages sent via my employer were tossed because one of my employer's mail servers was listed on a blacklist. As an employee, I had no alternatives for sending mail - company policy precluded the use of "webmail" alternatives via company infrastructure. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: several messages
Hi - > From: "der Mouse" <[EMAIL PROTECTED]> > To: ; <[EMAIL PROTECTED]> > Sent: Tuesday, November 11, 2008 3:49 PM > Subject: Re: several messages ... > Irrelevant. The existence of amateurishly-run DNSBLs does not imply > the nonexistence of well-run ones. It _does_ mean that someone to whom > email is important had better do due diligence in selecting DNSBLs - > just as someone to whom a car is important had better do due diligence > in selecting a mechanic, or someone to whom good clothes are important > had better do due diligence in selecting a tailor ... Agreed, but if those analogies are correct, they also undermine the argument. Neither the email sender nor the recipient (the ones to whom email is most important) typically have any voice whatsoever in the selection of the DNSBL. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Comments on Draft IRTF ASRG DNSBL - 07
Hi - > From: "Jonathan Curtis" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, November 11, 2008 12:49 PM > Subject: Comments on Draft IRTF ASRG DNSBL - 07 ... > 2. The impact of DNSxL's when applied on Inbound Email Servers > is significant with very little collateral damage. ... I guess this depends on one's view of what consitutes "very little collateral damage." I've had my own mail blocked, both when sent from my current ISP, Earthlink, as well as when sent via the servers of my last employer, BMC Software. As mailing list admin for three IETF-hosted mailing lists (disman, agentx, and ltru) I've seen bounces and automatic unsubscribes due to IETF's infrastucture having been blacklisted. Thus I'm rather skeptical about "very little collateral damage." This may be due to misuse of DNSxL technology or other reputation systems, but if this small sample is any indication of the extent to which the technology is being used inappropriately or incorrectly, it suggests that significant educational effort in "correct" or "appropriate" uses of the technology is needed. (Assuming that it's not an indication that there are fundamental architectural flaws...) "Informational" makes sense to me at this time. "Proposed Standard" does not. http://www.ietf.org/mail-archive/web/ietf/current/msg53668.html sums up the issues nicely, in my opinion. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] LastCall:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6Bulk Leasequery)toProposed Standard
Hi - > From: "David W. Hankins" <[EMAIL PROTECTED]> > To: > Sent: Friday, October 24, 2008 7:46 AM > Subject: Re: [dhcwg] > LastCall:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6Bulk > Leasequery)toProposed Standard ... > Why does it matter if we've already agreed that SNMP's autodetection ... I'm not part of your "we". Someone who cares can give the rest of the tutorial. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: a modern-day SNMP use
Hi - > From: "David W. Hankins" <[EMAIL PROTECTED]> > To: > Sent: Friday, October 24, 2008 9:26 AM > Subject: a modern-day SNMP use ... > The short answer to your question, is that there exists today at > least one monitoring package, albeit not commercially nor even freely > available to the public (it is a private tool), which autodetects > all the interfaces and other monitorable variables on every router > in that backbone's network. The only thing it knows about what it > is going to monitor, in advance, is the hostnames and community > string(s) of the devices it seeks to monitor. > > It does this autodetect run once every 30 minutes, or when it restarts > or reconfigs, feeding the results of that search into a table of > 'monitored OIDs', which expire out of the table after 90 minutes (or > if it gets an SNMP error indicating future queries would not be > fruitful). If any device's sysUpTime.0 decreases (sysUpTime was > put at the top of every SNMP GET packet), it alone is re- > autoconfigured. > > I would call that 'routine', but again this is fairly subjective. Doing this does *not* require blind MIB walks. One can discover the set of supported MIBs (from a set of MIBs one knows how to manage - there's little point in discovering a MIB one does not know how to manage) with a relatively small number of GetNext requests, where the number of probes needed ends up being (favorably) proportional to the number of MIBs actually supported by the device. Interfaces can be discovered even more economically, thanks to GetBulk and the "non-locality" you complained about in an earlier message. ... > Because we couldn't count on wide implementation of SNMPv2c among > our monitored devices, we used an initial SNMPv1 query against every > device for the sysObjectID (and a couple other things), and then > assigned one of several "handlers" that worked around quirks and > optimized the process for that particular breed of router or switch. > > Both the autodection and polling strategies employed a technique > we found by benchmarking the routers and switches we used; we filled > an SNMP packet with as many variables as possible; so that the reply > packet would approach, but not exceed, 64KB, a UDP fragment. > > It turns out that if you compared the time it took 50 SNMP packets > transmitted in parallel to be replied to, to the time it took a > single SNMP packet with 50 variables that had to be fragmented, > the faster approach was the single, fragmented, packet. We used a > fine-tuned number of variables for each system, again keyed by > sysObjectID. None of this is surprising, and is consistent with what other products do. ... > On some of the handlers, we were able to capitalize on iterating a > series of GETs for every ifIndex from 0 up to ifCount-1 (usually on > ifName.*, but sometimes ifDescr.*, and even other times (those damn > Catalysts) on their enterprise-mib ifAlias.*, and then queuing > additional ifCount,ifCount+1,... GETs to the tail upon every reception > of an error (indicating a gap in ifIndex, which happens on hot swaps). > Successful replies indicated the interface existed, an entry was > created, and we'd start querying the actual data we wanted from other > tables. This tail-inserting strategy meant there was a continuous > flow of valid configuration information from the remote end, something > neither GETNEXT nor GETBULK can supply. ... ??? You'd end up with far fewer exchanges using GetBulk. GetNext would never require more exchanges, and under some circumstances (sparse ifIndex allocation, for example, as you mentioned below, or access control limitations) would require fewer. The approach you describe sounds like a lot of clever for no net gain. But the net of all this is that, as ugly as it is, SNMP can be used efficiently and effectively, and we shouldn't confuse shortcomings of some tools with shortcomings of the protocol or data models. They have enough real ones of their own; we don't need to fret about imaginary ones and spend time knocking down strawmen. Some of this discussion reminds me of early claims that CMIP was spectacularly inefficient. Turns out that protocol can be implemented with roughly the same code size and effort as SNMP, and is quite cheap to parse and encode; the "inefficiency" folks were so worried about was a quirk of an early, freely-available implementation, not something inherent in the protocol. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Last Call:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6Bulk Leasequery) toProposed Standard
Hi - > From: "David W. Hankins" <[EMAIL PROTECTED]> > To: > Sent: Thursday, October 23, 2008 12:36 PM > Subject: Re: [dhcwg] Last > Call:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6Bulk Leasequery) toProposed > Standard ... > If a DHCP relay knew what leases were present in a DHCP server before > it issued a single SNMP packet, and of them which specific ones it > needed to know about, then it probably wouldn't need to issue an SNMP > packet at all. ... Finally, getting to the use cases: what criteria most frequently determine the set of "interesting" (for management purposes) leases? Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Last Call:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6 Bulk Leasequery) toProposed Standard
Hi - > From: "David W. Hankins" <[EMAIL PROTECTED]> > To: > Sent: Thursday, October 23, 2008 8:47 AM > Subject: Re: [dhcwg] Last Call:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6 > Bulk Leasequery) toProposed Standard ... > If you don't know where "a single table of a single variable at time" > comes from, then walk the 'interfaces' mib on any system at your > convenience. Note how 'ifDescr', 'ifInOctets', and etc are all > organized with spatial locality, but the data for "interface 5" is > not. This spatial locality does not track with common application > temporal locality requirements, which wants all the details for one > conceptual object at once so that it may continue with processing it, > rather than waiting. An application that relies on "walking" a MIB to retrieve information in this way is *seriously* broken, IMO. The whole point of the way INDEXes work in SNMP (and the reason the variable binding list can hold multiple variable bindings) is so that one can access a bunch of variables (with same or different index values, from the same or from different MIB modules) in a single request. SNMP has its limitations, but "spatial locality" is a non-issue here - an application design that requests information it doesn't need in an order which is not useful is the fault of the application designer, not the protocol. > > For example, you start by walking a table of "index" advertisements, > > where you receive an 'index number' that can be used into other MIBs > > to find variables associated with that database entry. > > > > For each of these indexes you discover, you could then queue single > > GET PDU's for each separate variable you were interested in (lease > > state, lease expiration time, ...). Spectacularly bad design. It would make much more sense to only ask for the interfaces of interest (if known) in the first place, and in any case, asking for the individual variable bindings one at a time is just silly, if you'll pardon the harsh language. > > That would be a spectacularly inefficient implementation strategy. > > I should hope there's nothing in the SNMP RFCs that would be > > read as encouraging such wasteful behaviour. > > Efficiency is often subjective. Are you optimizing for simplicity > of design (using one walk to traverse an entire mib), Hardly recommended, particularly since there are some boxes which do not respond correctly to GetNext, resulting in a situation where a naive GetNext walk won't terminate. (Also, some implementations which followed the letter of the early RMON specs would result in the same behaviour.) > or are you > optimizing for the lowest latency to complete configurations? Using multiple variable bindings does more that reduce latency due to the number of round trips. It also significantly reduces the per-variable processing cost at both ends (encryption, authentication, for example) subagent/master agent interaction (AgentX exchanges, for example) and, for correlated indexes, may also result in managed device cache advantages. > Are > you optimizing out variables you have no interest in (most MIBs are > half extra data you don't require)? Yet another reason why doing blind MIB walks doesn't make much sense for management applications. > What kind of device are you querying? Shouldn't matter, though in general the more management information available in the device, the bigger the advantages to being smart about what one asks for. > On some models of router, for example, a SNMP query causes a message > to be sent over their own 'control bus' to fetch all statistics for > a single interface. The most recent control command is cached, > because it was designed to be used for a CLI command to display a > single interface's data. This is a good example of why asking for one variable binding at a time in a MIB walk is not a good idea, and why asking for multiple variables with correlated indexes in a single SNMP PDU makes sense. > The typical snmpwalk or even bulkwalk > scenario means every interface is queried multiple times; once for > each table they appear in. Which is why I claim that applications that indulge in such silly behaviour should not be encouraged. > This kills the cached object, by using > none of its locality, and overworks the command bus. Even if the > router's cache were larger, it would have to be equal in size to the > number of (physical and virtual) interfaces in order to have even one > hit. All very good reasons why doing blind, single-variable MIB walks makes no sense. Are there any commercial products that do this routinely? I'm not aware of any. > An application trying not to live in 1985 might find itself doing, > as I describe, a kind of dance to get out of SNMP's spatial locality > mindset. In this case, you would query all the data you required > pertaining to one interface at a time, before moving on to the next > interface. This is normal practice - get all the information in one or two re
Re: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6 Bulk Leasequery) to Proposed Standard
Hi - > From: "David W. Hankins" <[EMAIL PROTECTED]> > To: "DHC WG" <[EMAIL PROTECTED]> > Cc: > Sent: Wednesday, October 22, 2008 10:17 AM > Subject: Re: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6 > Bulk Leasequery) to Proposed Standard ... > SNMP likes to present a single table of a single variable at a time. > I suppose we could overcome this by having the DHCP lease information > in an 'blob of octets' rather than in classical SNMP variable form > (INTEGER etc), so you only have one MIB to walk. But it seems foreign > to SNMP to do so. Uh... One of the useful features of tables is to organize related information into conceptual rows with common INDEX values. I'm not sure where "a single table of a single variable at a time" comes from - GetBulk certainly has no such limitation. ... > For example, you start by walking a table of "index" advertisements, > where you receive an 'index number' that can be used into other MIBs > to find variables associated with that database entry. > > For each of these indexes you discover, you could then queue single > GET PDU's for each separate variable you were interested in (lease > state, lease expiration time, ...). That would be a spectacularly inefficient implementation strategy. I should hope there's nothing in the SNMP RFCs that would be read as encouraging such wasteful behaviour. > There are 'performance alternatives' from there, and they are > fantastic to entertain because so many SNMP server implementations > will outright crash if too many PDUs are queued in a single packet > (others corrupt their replies if there are more than single PDU's). I'm not sure what you're trying to say here. An SNMP message (which would normally be carried in a single UDP datagram) by definition contains exactly one SNMP PDU. > This becomes more problematic when you consider that some leasequery > clients are going to want only a subset of the MIB's total contents. > The question truly is "what leases did I have in my table before I > rebooted?" Such filtration in an SNMP MIB model I think would be > done on the client end, not on the server end, meaning the client > still must traverse some entire MIB one PDU (GETNEXT or GETBULK) at a > time. This depends on the design of the MIB module in general, and the selection of the INDEX elements in particular. Choosing INDEX elements for a MIB module is *not* the same problem as selecting indexes for a database. The use cases for information access, such as "what leases did I have in my table during time period X" are also important. Sometimes it makes to have "shadow" tables that do nothing but provide re-ordered access to the table with the "real" data - but this requires careful thought about what the high-frequency or high-value use cases are. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: About IETF communication skills
Hi - > From: "Keith Moore" <[EMAIL PROTECTED]> > To: "Lixia Zhang" <[EMAIL PROTECTED]> > Cc: ; <[EMAIL PROTECTED]> > Sent: Thursday, July 31, 2008 1:08 PM > Subject: Re: About IETF communication skills ... > My experience with that reporter is similar. I came to believe that she > saw it as her job to misrepresent whatever information was given to her. ... Let's not be too harsh. Do we have any reason to believe that media coverage in this case is less accurate than media coverage in general? The sense I get from this thread (and from my own experience) is that expectations of media accuracy are fairly low. If the only complaint is a misleading headline, we're doing relatively well. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SHOULD vs MUST case sensitivity
Hi - > From: "Dave Crocker" <[EMAIL PROTECTED]> > To: "IETF Discussion" > Sent: Sunday, June 29, 2008 5:31 PM > Subject: Re: SHOULD vs MUST case sensitivity ... > English is not case sensitive. Not so. Case has long been used for emphasis in environments lacking other typographical means, such as bolding, underlining, or italicization. > RFC 2119 does not specify case sensitivity. Agreed. I was long of the opinion that capitalizing the magic words when used in their specialized RFC 2119 senses was overkill. Though I still think it should not be necessary, I've seen enough cases where people failed to correctly disambiguate, and thus conclude that authors and editors SHOULD employ the case distinction. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SHOULD vs MUST case sensitivity
Hi - > From: "Iljitsch van Beijnum" <[EMAIL PROTECTED]> > To: "C. M. Heard" <[EMAIL PROTECTED]> > Cc: "IETF Discussion" > Sent: Saturday, June 28, 2008 1:57 PM > Subject: Re: SHOULD vs MUST case sensitivity ... > Are you saying that according to RFC 2119 "SHOULD" means something > different than "should"? > > In what universe does that make sense? ... One in which when the photocopier's paper jam light goes, the operator SHOULD open the cover and remove any crumpled pieces of paper, which should resolve the problem. These are very distinct senses of the word - one indicating the desirability of a course of action, the other indicating the likelihood of a particular result. Only for the former does any kind of "normative" semantic make sense. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Operation permissions on Read-Only objects in a table
Hi - > From: "Aditya JAIN" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, June 24, 2008 2:56 AM > Subject: Operation permissions on Read-Only objects in a table ... > Suppose we have a table in which some objects are read-only, and at least > one columnar object which has MAX- ACCESS = read-create. Does this imply > that we cannot delete that instance row by setting status to "destroy", if > we have created one? ... No. See the DESCRIPTION of RowStatus in RFC 2579. Successfully setting a RowStatus object to "destroy" deletes all the corresponding instances in a row, regardless of their MAX-ACCESS. Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 64bit time_t
Hi - > From: "Chad Giffin" <[EMAIL PROTECTED]> > To: "IETF" > Sent: Saturday, June 21, 2008 11:38 AM > Subject: 64bit time_t ... > What do you think? ... This has been addressed before. See ITU Rec. X.743 http://www.itu.int/rec/T-REC-X.743/en for one solution. Randy___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Hi - > From: "Debbie Garside" <[EMAIL PROTECTED]> > To: "'John C Klensin'" <[EMAIL PROTECTED]>; "'Dave Cridland'" <[EMAIL > PROTECTED]> > Cc: "'Pete Resnick'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > Sent: Thursday, June 19, 2008 11:54 AM > Subject: RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis ... > Sorry but we have to agree to differ on this. Nothing personal but probably > due to my ISO experience, I am more for going with standards rather than > finding ways around them with MAYs and SHOULDs. If there is a > recommendation within a standard IMHO it should be followed. This is just > my humble opinion - you are welcome to yours. ... > Wrt the author's intention for publishing BCP32, it is irrelevant unless > documented within the BCP itself. We cannot go back to the author for each > BCP or RFC and ask what was the intended use. The document, as with any > standard, has to stand alone. ... Both these arguments get back to the question of the applicability of a standard or BCP. Although we are sometimes rather clear on the scope of applicability for a particular specification, more often things are more or less deliberately left open ended. Whether it makes sense to use SNMPv3 as a file transfer protocol (as in RFC 2592) is left to the user's judgement. The existence of a potentially applicable BCP or standard doesn't imply that it MUST be used - the WG needs to investigate it, and then make the engineering decision whether that specification is the right tool for the job at hand. Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ISSN for RFC Series under Consideration
Hi - > From: "Melinda Shore" <[EMAIL PROTECTED]> > To: "IETF Discussion" > Sent: Wednesday, May 21, 2008 11:16 AM > Subject: Re: ISSN for RFC Series under Consideration ... > The only possible disadvantage I can see is if they're then > cataloged as a serial rather than having individual call numbers > and individual catalog entries, but since the Library of Congress > doesn't seem to be cataloging them today I guess to have them > cataloged at all would be an improvement. ... What would it take to get them cataloged individually? Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Hi - > From: "Bernard Aboba" <[EMAIL PROTECTED]> > To: > Sent: Thursday, April 24, 2008 6:40 PM > Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) > > I echo Tom Petch's concern. > > Given the level of deployment success of IETF management efforts > for the last 5-10 years, I'd suggest that we need both customer > "pull" as well as technical community "push" for such an effort > to succeed. While there have been arguments made for the latter, > I don't see enough evidence of customer (in particular, operator) > involvement to feel confident that the former has been addressed. ... Whether we like it or not, the last five years have been devoted largely to NETCONF. RFC 4741 is already published on the standards track. During that time, the community has been forbidden to work on data models in the IETF. Without data models, NETCONF's utility is rather limited, to say the least. Consequently, a lack of perceived "pull" should hardly be surprising. The choice before us is pretty simple: - allow work to continue on standardized data models, so there will be some hope of interoperability - ignore the need, rely on the continued proliferation of proprietary approaches, and hope someone else figures out how to interoperate (though some may consider the lack of interoperability to be a sales- enhancing feature rather than a problem to be overcome) - hope some other organization will give the work a home if the people willing to do the work are not allowed to do it on IETF turf. The question now is whether the IETF wants NETCONF protocol to succeed. Yes, more operator input is desirable. But in the case of NETCONF, the protocol itself is far removed from what the operators asked for at the IAB workshop. These leaves me wondering whether more input would really change anything. Based on my understanding of the operator input at the IAB workshop, the Yang proposal, of all the ones mentioned at the CANMOD BOF, is by far the best-aligned with the concerns the operators voiced, which were, in a word, "readability". (For the data itself, terms like "screen scraping" came up a lot.) I'm certain something better is possible, but no one has bothered to write an i-d. At some time we have to stop waiting for something better to magically appear and go with something that will be good enough that has the support of implementors. This work should have been undertaken five years ago. How much longer? Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Hi - > From: "Dave Crocker" <[EMAIL PROTECTED]> > To: "Eric Rescorla" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; > Sent: Tuesday, April 22, 2008 10:03 PM > Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) ... > Are they committed to doing the work? The bulk of the work has been done (or close to it) for quite some time. Ideally, it would have been done *before* the NETCONF protocol was cast in concrete, but the NETCONF working group was not allowed to define a modeling approach before finishing a protocol. Without data models, the protocol is useless. Consequently, there are already numerous vendor-specific ways of handling modeling, and even multiple approaches showing up some companies. Not good. > Do they have their own constituency? All the major players in the devlopment of the NETCONF protocol, as far as I know. > Since the topic is not new, where have they been and why have they not > developed their own group consensus? Previous requests for a BOF like the one held in Philadelphia were denied. The various design teams have considerable common ground, and the consensus of the folks who are actually doing work is in my opinion pretty accurately reflected in the charter proposal. > Rather than "perspectives" where are the technical concerns that Bert asked > about? As I see it, the key technical issues are these: 1) Is there a need for a domain-specific language for network configuration management data modeling? Experience in the field gives an unequivocal "yes". GDMO, SMI, and CIM are a few examples of how folks have dealt with the shortcomings of the general-purpose tools available over the years. General-purpose modeling languages are both too much and too little, particularly with regard to issues of inter-version compatibility of models and interoperability. Even if a language can represent an important semantic, there's still the question of whether that particular solution is compact and intuitive. With some, to represent common constraints like uniqueness the designer had to resort to the equivalent of assembler language. 2) Does it make sense to use an XML-based syntax for the "human-friendly" representation of data models? For "industrial-strength" models the answer becomes more and more "no" as the model becomes larger and more semantically rich. This is not a question of expressive power. It's a question of providing a way to support development of *readable* standardized data models for NETCONF. Forgive my impatience. We went through this same debate twenty years ago regarding ASN.1 and GDMO, and only slightly later in de-coupling SNMP SMI from ASN.1 The acronyms may have changed, but the answers haven't. Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Hi - Our ADs worked very hard to prevent us from talking about technology choices at the CANMOD BOF. Our original proposal for consensus hums included getting a of sense of preferences among the various proposals. We were told we could *not* ask these questions, for fear of upsetting Eric Rescorla. (It's unclear to me why his perspectives on configuration management information models should be subject to special consideration, while the folk who have been doing active work and real products in this area over the last two decades are largely ignored.) The people from the various design teams put a great deal of time and energy into understanding each others' proposals and the tradeoffs. The standardazition of a modeling environment for NECONF should have been completed literally five years ago. The notion that further delay is desirable is simply silly. That said, I do agree with the others regarding the charter proposal. While it's probably not exactly what anyone wanted, it does represent something just about everyone who is actually doing work in this area could not just live with, but actually support. Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Hi - > From: "Eric Rescorla" <[EMAIL PROTECTED]> > To: ; <[EMAIL PROTECTED]> > Sent: Tuesday, April 22, 2008 10:10 AM > Subject: Re: WG Review: NETCONF Data Modeling Language (netmod) ... > Accordingly, if this WG is to be formed, the entire section (and > corresponding milestones) which specifies the technology needs to be > removed. Rather, the first work item should be to select a technical > approach. ... I think the simplest answer would be to simply publish the work that's already been done and not bother with the IETF. There is simply no value in wasting electrons on battles like this. Sure, some opportunities for technological refinement and building a stronger community consensus migh tbe lost, but that might be a small price to pay in comparison to the time and energy required for all this pointless hoop-jumping. Particularly since the proposed/ draft/standard distinction has become so meaningless, it makes more sense to just publish the spec and ignore the peanut gallery. Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
Hi - > From: "Ned Freed" <[EMAIL PROTECTED]> > To: "Henrik Levkowetz" <[EMAIL PROTECTED]> > Cc: "Ned Freed" <[EMAIL PROTECTED]>; > Sent: Monday, April 14, 2008 9:12 PM > Subject: Re: IESG Statement on Spam Control on IETF Mailing Lists ... > And there's that word "automatically". There is nothing in the text that says > such arrangements have to be automatic. ... I have the same problem with the text. It says: > * IETF mailing lists MUST provide a mechanism for legitimate technical > participants to bypass moderation, challenge-response, or other techniques > that would interfere with a prompt technical debate on the mailing list > without requiring such participants to receive list traffic. The stated requirement is that it must not "interfere with a prompt technical debate". Clearly, that rules out anything requiring human intervention. What do you have in mind that would allow the spammer^H^H^H^H^H^H^H participant to post without subscribing and without interacting with a chair or list administrator? Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call for two IPR WG Dcouments
Hi - > From: "Peter Saint-Andre" <[EMAIL PROTECTED]> > To: "Ted Hardie" <[EMAIL PROTECTED]> > Cc: > Sent: Sunday, March 30, 2008 6:03 PM > Subject: Re: IETF Last Call for two IPR WG Dcouments ... > And how do we provide suggestions to the Trustees in a formal manner? ... If it's only a suggestion, what's the point of making it formal? Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action.
Hi - > From: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]> > To: "LB" <[EMAIL PROTECTED]>; > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, March 26, 2008 6:29 AM > Subject: Re: Possible RFC 3683 PR-action. ... > c'mon neihter JFC nor LB has ever offered a draft, JFTR https://datatracker.ietf.org/drafts/draft-mltf-jfcm-cctags/ > or even outlined a > comprehensible strategy. ... No comment. Randy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
