Re: DHCP retransmission behaviour
On Mon, Mar 22, 2010 at 11:22:49AM +0100, Lorenzo Ruggiero wrote: I want to understand better the DHCP retransmit behaviour suggested in RFC 2131. RFC says that the client retrive using a backoff algorithm. This backoff algorithm will chose retransmission time using a value of a uniform random number chosen from the range -1 to +1. My question is what 's happen if value is negative(-1,0)? If is negative the client won't retransmit? I think the intent of the RFC 2131 retransmission strategy is for each retransmission interval to be summed with a random number in the range (-1,1), clock granularity permitting. So the example initial 4 second timer would be between 3 and 5 seconds inclusive, the next retransmission is exampled to be between 7 and 9 seconds inclusive. This strategy isn't well defined, most of the behaviour is not described in normative language, and the strongest indication otherwise is a SHOULD. Combine this with the problem that 4 second retransmission timeouts isn't something most users are willing to endure while waiting for a network connection, and I think you'll find a lot of DHCP clients don't precisely implement this falloff mechanism. As RFC 2131 says, or how we choose to interpret it today, what's important is that you use an algorithm that has an exponential growth and some randomization to keep clients from marching together. As an example, ISC dhclient starts every query with a fixed interval with no randomness. Every subsequent retransmission is determined by; interval += random() % (2 * interval); Then if the new interval exceeds the backoff_cutoff; interval = (backoff_cutoff / 2) + (random() % backoff_cutoff); The implication is that on average the interval will double every round, until it reaches our cutoff boundary where it will remain bound between 50% and 150% of the backoff cutoff. If you want to discuss this further, I invite you to ask on the DHC WG mailing list (dh...@ietf.org); https://www.ietf.org/mailman/listinfo/dhcwg -- David W. HankinsBIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ pgpWeY2mHBbPQ.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Beyond reproach, accountability and regulation
On Wed, Apr 29, 2009 at 02:03:00PM -0400, Phillip Hallam-Baker wrote: In theory we have a consensus based organization. In practice we have a system where it is rather easy for some people to take strategic offense as a tactic to shut down debate. 'Establishing (rough) consensus' is, at its root, Sophistic debate. To be complete: The IETF system relies upon those presenting drafts to be judged as having consensus to progress, or not. It is not required (by either the draft authors or the audience) to provide proof outside of convincing the judges - those who measure and form consensus - about whether or not to progress a draft (this does not mean that people do not supply proof, it merely is not required; one only needs to be convincing, and certainly proof can be very convincing). Of course Sophists was more in the realm of determining the truth or falsehood of a given statement, but the boolean nature of true and false tracks well with the IETF's boolean nature of 'progress or not,' and this system of consensus suffuses both draft progression and the debate of draft contents. It should therefore not be surprising that all manner of classical Sophist rhetoric is used by the IETF's volunteers to their own ends, successfully. Although today we may have a negative stereotype of Sophism, I think collectively we believe there can be no other way (than Sophistic debate) for the IETF to pursue its agenda on the basis that we often argue issues that simply cannot be fully explained or brought into evidence, and even more frequently enter into the realm of politics (and what place would logic have there?). I was very dissatisfied with the IETF's performance towards its agenda until this occurred to me. It would have helped me immensely if it were formally identified in this way (but then that would require the IETF carry a 'Philosophy Area'), and to some extent I imagine that this is also the problem some of the IETF's more vocal detractors are wrestling with; the belief that the IETF does or should follow a Socratic, Aristotelian, or even Democratic methodology, and the resulting confusion and hurt feelings to discover that blatantly Sophist rhetoric has succeeded where their deductions or even elections have failed. And yes, claiming that some person or ideaology is beyond reproach (the end to end principle, the collective phrasology of John Postel) is a valid, if unfortunate, Sophist technique to convince. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpwQdl4Je2Td.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Subscriptions to ietf-honest
On Wed, Mar 25, 2009 at 10:10:04AM -0700, Joe Abley wrote: I have lost my sense of humour about this. It's hard to see this as anything other than a systematic attempt to disrupt IETF activities. It is my suspicion that the perpetrating gang is attempting to goad volunteers into legal recourse. I suspect this gang believes that their actions will either cause IETF volunteers to create a legal context for them to exploit (CAN SPAM suits), or that IETF's attempts to filter or restrict access will create a legal context for them to attack (the gang's leadership cites Exactis vs MAPS with fervor, which I think they believe proves a network cannot restrict access to itself). Heads we win, tails you lose. Anyone who's ever participated in an Internet community knows the score here. There are trolls for whom ostracization from the community solves the problem; they find another community to infect and become distracted. There are trolls that never believed they were part of the community to start with, bold adventurers or risk takers, individualists outside the realm of conformity, lone rangers who must stand alone against a tide of injustice. Ostracization does not quiet their discomfort, it justifies it. The only thing I have seen work for this second category of troll is to talk to their mother. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpABhYUNxp2E.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The internet architecture
On Fri, Dec 05, 2008 at 08:46:48AM -0800, Dave CROCKER wrote: John Day wrote: discussed since 1972. But you are correct, that there were still a large unwashed that didn't and I am still not sure why that was. This seems to After your or I or whoever indulges in our flash of brilliant insight, it is the unwashed who do all the work. I'm assuming you are using the term 'unwashed' to refer to the simple act of bathing, rather than as in my background I understand it as a metaphor for Christian baptism. Surely neither Mr. Crocker nor Mr. Day are referring to IETF baptismal practices? Could either of you two elaborate on why you think that bathing (or the evident lack thereof) is at all relevant to Internet standards? I'm aware that in the ~400AD's there was actually quite a lot of (religio) philosophical debate over the practice of bathing (which I rather would think we'd put behind us after 1600 years), but I've never heard it said that good engineers do (or don't) bathe. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpUdvlx8jwJb.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-trill-prob-05
(replying to ietf@) On Wed, Nov 26, 2008 at 09:38:02AM -0800, Bernard Aboba wrote: One such issue is how to rapidly seed the learning tables and ARP caches on movement between attachment points. ARP cache updates shouldn't be necessary when changing attachment points unless the client's MAC address has changed. If you change both, then you need to update both. I think they are separate issues; but in ARP's case it is somewhat unfortunate...you have to update all ARP caches that may contain an entry for you, for although you are immediately interested in updating the caches of those devices with which you are actively communicating, you may start communicating with other devices at any time (they may initiate or resume an exchange), and a stale cache entry from an erstwhile exchange would mean an unfortunate delay. Additionally, some deployments (passively or actively) attempt to suppress IPv4 spoofing in BCP-38 similar ways, at the switching layer, often by intercepting or participating with DHCPv4. In which case a gratuitous ARP or a DNAv4-like ARP would fail (and in DNAv4's case it would fall back to INIT behaviour, as I recall, optimizing for the case where the client has changed networks). So possibly all three should be considered as sets (a gratuitous multicast updates learning tables, a broadcast gratuitous ARP updates ARP caches and learning tables, DHCPv4 updates ACL's, learning tables, but not ARP caches). And then of course there's SIP, but let's move on. learning tables in advance of station attachment. In DNAv4 (RFC 4436), unicast ARP-Requests are sent in order to seed the router ARP cache, providing for return reachability within a single exchange. The motivation behind both of these devices is to minimize handoff latency and frame loss. I think that DNAv4's primary purpose was to provide a very good indication that the client had not moved to a different network (the same IP-addressed, same MAC-addressed router is probably on the same broadcast domain as I used to be). Having determined this, the client excercises its right not to restart DHCPv4 in order to reassert its configuration for the network (a lease is good for as long as its lease-time option says). The main upshots are that ARP completes much faster for the client, and in comparison to doing a DHCPv4 INIT-REBOOT; ARP does not require any 'update to persistent storage' (so it is _far_ less costly). Any ARP cache update is secondary, and only serves to reinforce contact between the DNAv4'ing client and the default router(s). It does not assist with conversations between the client and its peers. In fact, DNAv4 is likely to suceed in situations where the client has not changed MAC addresses, but rather has merely been intermittently offline, such as when losing and re-associating with an AP, having its ethernet link toggled, or resuming from a powersave mode (in which case you will be re-associating with an AP or having your ethernet link toggled anyway, modulo 'wake-on-lan' features). In these cases, it is actually pretty unlikely that the router's ARP cache is incorrect for the selected client. If the client was offline for an extended period (such as in powersaving), then the router may have no cache entry for the client, but it should not have an incorrect ARP cache entry in this case. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpyHtMHKKUDm.pgp Description: PGP signature ___ 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
On Thu, Oct 23, 2008 at 06:35:13PM -0700, Randy Presuhn wrote: Finally, getting to the use cases: what criteria most frequently determine the set of interesting (for management purposes) leases? Why does it matter if we've already agreed that SNMP's autodetection mechanisms are shit? -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpNXZwlTmU1Y.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
a modern-day SNMP use
and precisely two power supplies, they were always at precisely the same OIDs), keyed again by sysObjectID. But for example, we couldn't do this for MAC address accounting features, a feature commonly used to track bandwidth traded with multiple peers on one interface. The pain involved in autodetecting the MAC accounting MIB (because it could change more frequently than once per half hour) successfully kept me from using it. That is a challenge that exceeded either my interest or my ability, I'm not sure which. I'm sure the ops team is still using their expect script to fetch MAC accounting data out of the routers' CLI. I find that preferrable either way. So, yes Randy, there are folks who use SNMP routinely in this way, and there are also folks who refuse to use SNMP in this way. The lesson is that madness is relative, and you must often do insane things to avoid even more insane consequences. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpChPqnWzQv0.pgp Description: PGP signature ___ 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
On Fri, Oct 24, 2008 at 12:31:40PM -0700, Randy Presuhn wrote: I'm not part of your we. Wow, this is a situation I did not anticipate. You know about all the handstanding, all the backwards thinking, all the extra overhead in putting scatter/gather to work. And you think that's the way it should be. Someone who cares can give the rest of the tutorial. Yeah, I don't think I can help you either. We're both failures as teachers. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpNdj1BZTERf.pgp Description: PGP signature ___ 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) to Proposed Standard
On Wed, Oct 22, 2008 at 09:15:01PM -0700, Randy Presuhn wrote: 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. I don't remember referring to GetBulk, and I don't understand why I would have. 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. 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. Efficiency is often subjective. Are you optimizing for simplicity of design (using one walk to traverse an entire mib), or are you optimizing for the lowest latency to complete configurations? Are you optimizing out variables you have no interest in (most MIBs are half extra data you don't require)? What kind of device are you querying? 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. The typical snmpwalk or even bulkwalk scenario means every interface is queried multiple times; once for each table they appear in. 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. 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. An application requiring not to live in 1985 definitely will find itself queuing more than one packet to a single SNMP server at a time. In this case, walking some number of tables in one session, while queuing query packets filled to the brim with GET's for all specific relevant data for each interface in series. Unless you're querying a Cisco Catalyst, in which case queuing more than one packet at a time is foolish; the Cat will drop the second packet if it is busy with a request already, and you'll have to sit in retransmission hell. But I'm getting sidetracked. The advantages here I am describing are twofold; 1) The object for interface 5 is read in the least time possible, even though the time to read the entire dataset remains constant (due more to RTT than to bandwidth). interface 5 can move on to the next stage in processing while SNMP data continues to flow, rather than waiting for the walk to finally reach the last table of variables. 2) The router is not flagellated needlessly, resulting in a lower time to complete the operation overall. 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. Possibly this is a kind of brain damage that arises from the SNMP library I once used, which describes multiple query commands in one packet as PDU's, even if they are labeled internally to SNMP as being 'variable bindings' attached to the end of the PDU. I wind up using the terms interchangeably as a result. This depends on the design of the MIB module in general, and the selection of the INDEX elements in particular. I don't see how any SNMP MIB design cleverness can get around the SNMP way of requiring strictly ordered datasets for GETNEXT support. But good luck with that, and I look forward to reading your DHCP MIB's draft. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgppkdaTI6HQu.pgp
Re: [dhcwg] Last Call:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6 Bulk Leasequery) toProposed Standard
Now I'm hearing you say what I'm saying, that is good, but we're not quite done; On Thu, Oct 23, 2008 at 09:41:49AM -0700, Randy Presuhn wrote: 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. 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. Now you see the conundrum. The process to use SNMP to meet leasequery's ends (to find out what leases it needs to query about, and then finally also do that) would be to use SNMP in precisely the way we are both saying is idiotic! I have to agree completely and wholeheartedly: SNMP is just broken for this use case. The requirement for ordering is inherent in the protocol, and I agree it makes interfacing with, e.g., an underlying SQL infrastructure (for which ordering entails extra processing) a pain. But the point is that deciding which indexes to use needs to be driven by management use cases, in order to minimize the situations in which one would need to walk through an entire table to find the useful bits. There simply is no usable index. There is no database in our DHCP implementation that is consistently sorted no matter what time (over the runtime) you query it; in order to support GETNEXT to be able to walk the various lists of leases and allow the clients to perform the required discovery, we would have to change literally everything, and vastly complicate our software. It is work all around to shoehorn SNMP into this picture, for the client, for the server, for everyone. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpelFXjayed5.pgp Description: PGP signature ___ 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) to Proposed Standard
On Wed, Oct 22, 2008 at 08:36:22AM +0300, Pekka Savola wrote: $ snmpwalk -m IP-FORWARD-MIB -v 2c -c foo foo-rtr This essentially would be identical to DHCP leasequery, minus the bulk. Even if transported via TCP, on the wire it would look like a single client-server GETNEXT, waiting for a server-client reply before sending the next one. One PDU and one OID in it at a time. snmpbulkwalk is a minor improvement; a single UDP reply can contain many iterated GETNEXT's, or similarly over TCP. There is still a 'pause' between the client's request and reply. What the leasequery bulk methods are looking for is all at once. The objective is to fill the socket at maximum window size. I am not aware of a means to do this with SNMP considering the kinds of data in DHCP lease tables, and the usual ways MIBs are constructed. ip.ipForward.ipCidrRouteTable.ipCidrRouteEntry.ipCidrRouteProto.128.214.46 IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.0.255.255.255.0.0.0.0.0.0 = INTEGER: netmgmt(3) IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.254.255.255.255.255.0.0.0.0.0 = INTEGER: local(2) This kind of underlines a qualm with SNMP data management (as opposed to network management). For each iterated GETNEXT or GETBULK both rely upon a fixed point in the database (node n), which was present in the database and was the last PDU in the server's reply in the previous packet. But it may not be present in the database at the time the next request is made. This requires the database models used by the servers to be able to find a reliable sorting, where the previously-valid-now-invalid OID can still be used as an index to provide continuation; it can still grant the next OID. This essentially is a problem, or at least a facility not present in some DHCP databases, which caused us to motivate away from UDP based bulk queries (the original bulk leasequery proposal was more similar to snmpwalk in this regard, and this was a concern raised by implementers). In addition... 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. The problem is that most leasequery clients are not positioned to allocate fields of temporary memory in order to make sense of SNMP's kind of scatter-gather approach to this kind of data transfer. To make sense of SNMP MIBs you have to develop some strategy to receive multiple datapoints from different locations and times. 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, ...). 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). 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 is different from the proposed bulk leasequery models, where the server writes to the TCP socket all at once, with all data for a given lease spatially located in the same position in the TCP stream, and a primitive query language (by query type) to provide subsets. This doesn't mean a standard DHCP MIB isn't a bad idea for entirely different reasons. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpWCakKMUnRv.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Beggars _can_ be choosers?
On Wed, Aug 01, 2007 at 03:01:40PM -0400, John C Klensin wrote: I think you misunderstand my comment, or at least its intent. I absolutely did, but I think reasonably so. This version is no longer crazy, even noble. But I'm not sold on it. Or do you still think we disagree or that my comments are fallacious? We're half in agreement. Where a problem manifests, and an operator intended the configuration as being reasonable and correct, then the reasons why the setup is neither, or what failed, should be documented. I would expect we should hear very loud noises in any event where this is the case. Where a problem manifests, and it was an accidental mishap of misconfiguration? It's a waste of time to pursue and document these with the kind of rigorous investigation you suggest. I suspect this is just a position we will disagree on, but I will explain myself a little; First, people who make mistakes on accident are not going to read a document telling them not to do that beforehand. If they did read the document beforehand, well we're talking about _mistakes_ here... they're going to make mistakes anyway. Nor will they look to an RFC after it is done. They'll seek FAQs, mailing lists, and their products' support chains. They'll seek an expert on the subject because there are simply too many references to read in a timely fashion to find the one that tells you what mistake you made. So it is certain that documenting this will make no real difference to anyone, and I think the IETF Mindshare gains are dubious at best. Second, there are just so many different ways to misconfigure your network, we would be working at this until the heat death of the universe. Of course we'd want this to be a general investigation into accidental configurations, and not a DHCP Witch-Hunt. For IETF 69 alone, we'd have to look into why the DNS servers were reliably reachable but not reliably answering until Tuesday. To continue on beyond merely the mishaps of IETF 69, we'd have to provide such advice as: Do not accidentally create ethernet duplex mismatches. Do not accidentally load the full Internet BGP table into a 2501. Use Filters. Do not accidentally urinate on your router while it is running. In fact, avoid accidental urination altogether. Messy. (True story, a housecat in Maui did this to one of our Portmasters) Do not make typos, especially not ones which happen to pass parsing tests, such as but not limited to reversing digits on subnet masks. Or my personal favorite: Do not accidentally run outdated software with known bugs, possibly including well-used security vulnerabilities. Upgrade! This list could go on! Basically, I think the best thing to do is to just expect our network's operators to raise the flag themselves if they think it is useful. That is, that something might come of it. This ietf@ business of inserting ourselves into the situation because of some possibility of a difficult problem that we hope we might be useful in addressing is another waste of time. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpkb6Lj8m9Fa.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beggars _can_ be choosers?
On Thu, Aug 02, 2007 at 11:55:12AM -0400, Keith Moore wrote: DHCP, in particular, strikes me as a nightmare - a hodgepodge of unrelated attributes, many of which have no business being dictated to hosts by the network. gluing DHCP to DNS creates another set of problems, also based on dubious assumptions about the relationship between a host's identity and the attachment point of a host to the network. and this all strikes me as a consequence of developing network configuration protocols organically, i.e. without much forethought. We clearly have a very different perception of reality. more broadly, I wish there were a better feedback path from operators to IETF to take advantage of the breadth of operational experience. it's not as if the incidents occurring in IETF meeting networks are typical; it's just that we experience them directly and as a group rather than indirectly or as individuals. Contrarily, we should specifically seek not to make decisions about events that have affected us personally, because we have biases in our position towards recommended changes. That is, it further closes the gap on making IETF protocols designed explicitly for operation at IETF meetings, and nowhere else. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpYD8kMXuEV6.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Beggars _can_ be choosers?
On Tue, Jul 31, 2007 at 06:59:58PM -0400, John C Klensin wrote: Almost independent of the IPv6 autoconfig issues, I find it deeply troubling that we seem to be unable to both * get the ducks lined up to run IPv6 fully and smoothly, with and without local/auto config. * get a DHCP arrangement (IPv4 and, for those who want to use it, IPv6) that performs reliably, consistently, and largely invisibly (if I have to worry about what a DHCP server is doing, it isn't working well). and have both of those working seamlessly no later than Sunday afternoon of the meeting. If we can't do that, we should be very seriously reviewing our protocols and specifications: that sort of thing shouldn't be, in any sense, an experiment at this stage. Wow! Is that an IETF First for anyone else? Ever since my first IETF, I was well aware that many folks held to the unfortunate fallacy that, because we do X at IETF meetings and it works allright, it is therefore sufficient for the rest of the Internet. No matter how much people point out the error in this thinking, it is perpetuated...as recently as the IETF 69 tech plenary, where we were told that firewalls were becoming obsolete, evidenced by their lack of use at IETF meetings. There's only one word for it: Astounding. I have never, until now, heard the contrary fallacy attempted. That is, because we did X at an IETF meeting and it did not work allright, it is therefore insufficient for the Internet. That's a new one on me. Clever, but wrong: networks much larger than 1,200 laptops use DHCPv4 on a daily basis all over the Internet without similar symptoms. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpB7Zvj2H3rz.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beggars _can_ be choosers?
On Wed, Aug 01, 2007 at 09:12:14AM -0700, Joel Jaeggli wrote: Told by whom? Hain...something like that? I can't remember. You'll have to check whatever minutes or recordings are up. Start by asking the contractor, the volunteers and the IAD for a postmortem on the operation of the network. anything else is just speculation. Why? It's a lot of work, and I think we already know the conclusion, given what we can observe as users. It berates our volunteers and sponsors who provide us with the network services during our stay...treating them like children that have to be kept after school to explain themselves. It embarrasses vendors who provide us with gear or software, making them less likely to provide either. And all we're going to discover is, It hurts when you go like this, so don't do that then. A useless and frivolous excercise. If we wanted to stop begging, and really buy a network for every IETF meeting, complete with SLA's and funding extensive testing before opening it 'live', then that's one thing. One totally rediculous thing. But in lieu of an absence of begging, we should stop being so choosy. They did a good job, and we more or less had net the entire meeting. I don't think we have anything to complain about. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgppYuDELAq6F.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beggars _can_ be choosers?
On Wed, Aug 01, 2007 at 11:11:18AM -0700, Joel Jaeggli wrote: I'm one of those volunteers, operating that part of the service was not my responsibility... My point is to both you and the people complaining about the network, Drawing conclusions from an incomplete picture is fraught with peril. I've drawn no final conclusions, and would similarly advise others not to do so. I certainly would say that, given what we can observe as users, the possible explanations for the DNS and DHCP service outages reside in a _very_ limited set; hardware, software, configuration, or some combination. None of those are IETF business in the sense of things which we can observe or change through Reviewing our protocols and specifications as John Klensin appears to have suggested. At IETF 55 I had issues with all the terminal room macs coming up with A volunteer writing up an essay on the goings on, because he knows the work to be fruitful, is one thing. A bunch of bearded geeks surrounding a table, pounding their fists, and demanding the proverbial answers is entirely another. So if you feel like doing it, do it. But it shouldn't be an imperative. We have a network contractor who has provided services at the ietf68 and ietf69. We pay them money, they do stuff. We also have volunteers. If the contractor has an SLA to provide DHCP services, that's something IETF's administrative staff should take up with them. I suspect they don't. Indeed. How do we (I'm being rather inclusive here) do better next time? I don't think we can. By its definition, the IETF network is built with different hardware, different software running on it, and different operators every time. This is an entropic nightmare...you're not just changing one variable... you change all of them. There's no sane way to expect 100% resilient network operations at every event put together like that unless you _really_ start spending money like water on it. Just give up and stop being so choosy. I ask myself fairly frequently (about 3 times a year) What can I do to make the next one better? Not everyone can or should volunteer to help but the pool of volunteers is not that big... Involve the vendors earlier. They're probably (not) using the network that's broken anyway. Speaking from my own experience, I don't find out that our software is in use until after things are broken and someone manages to find me through a network of friends (7 layers of separation seems to be more like 3). Take ten minutes to write us a note with your plans beforehand, page us on ietf@ if you can't find us, and maybe we'll answer back with the cellphone that will work while we're in town, and ignore us if we send back a you need to use fancy new features x, y z to test them for me. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpTOxP65LUPY.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
On Wed, Apr 25, 2007 at 06:50:28AM -0700, Hallam-Baker, Phillip wrote: But how does my application access it? The proper way from my point of view would be to read from your system's option cache, so whatever DHCP the system does filters down to applications. DHCP is not something that an application layer program should be allowed to perform. Amen, brother! But, you're preaching to the choir. Macromedia Flash Proxy whatsimahoosits...sends a DHCPINFORM. Doesn't set ciaddr, chaddr, htype or hlen. Let me tell you, becoming similarly compatible to this as other servers evidently are was not an experience I would like to repeat. [1] Microsoft Industry Update Control. Refuses to stop sending DHCPINFORMs until any server responds with the WPAD option, without placing that option on the PRL. [2] It is a security issue. For good reason performing DHCP operations requires privileges beyond mere network connectivity on Windows. I expect it doesn't, actually, as the relevant flash proxy bits are sufficiently nonpriveleged. That's via a dot net facility, I've been told. I see no reason to hold the system's option cache secret from applications, when taht cache is got by a packet that anyone can sniff off the wire. I understand that applications such as Opera, Firefox, and ID [3], are said to digest at least one option in this way. But, I'm not a Windows guy, so if someone knows how that actually works it would be helpful. I just know that it works from the outside looking in. That is why configuring application programs from DHCP never caught on. The reason you have made this statement is false. But that doesn't, on its own, mean that the conclusion is false. I would say it certainly is not mainstream, but it is pervasive. [1] http://marc.info/?l=dhcp-serverm=113466843320099w=2 [2] http://marc.info/?l=dhcp-serverm=110928450802695w=2 [3] http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol [4] http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-wrec-wpad-01.txt The DHCP option code for WPAD is 252 by agreement of the DHC working group chair. Possible alternative text: I can't believe it's not IANA! -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpALeINh5ezC.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
On Fri, Apr 20, 2007 at 02:02:18PM -0400, Ralph Droms wrote: Set up the relay agent in your router to point at my DHCP server. There are also DHCPINFORM (v4) and Information-Request (v6) messages which can transit the public Internet. I think however, v4 fails with NAT. They are also not widely used for this purpose at the moment. I was thinking about this while swimming yesterday. Phillip's abstract problem is that multiple administrative domains exist. There is the physically attached network, which represents one administrative domain which reaches to every place the broadcast domain touches. Someone is responsible for that network, and the services it provides which facillitate access. There is his 'home' network, which represents a second administrative domain. There is his 'work' network, which represents a final third domain (or more). It is likely that each of these three domains will wish to present dynamic configuration contents. One subset of them are only contextually useful when the physical and administrative domains match (such as what's the default gateway? and where on earth is the network port I'm attached to?). A second subset of them are contextually useful no matter where on the Internet Phillip's laptop is connected (such as where is my Inbox? or where should I send my lat/long to?). Right now, DHCP(v4|v6) has only been used to solve for the case where the physical and administrative domains match. Operationally. DHCPv6 could easily be used for the case where the administrative domain is extra to the physical broadcast domain by making use of the Information-Request, and sorting values fetched this way ahead of values got off the link. DHCPv4 could potentially also be used for the same case, as the same message exists, but we would need to introduce a signal for alternative server behaviour (reply to source address and port) to work around NAT if that were desirable. Both would require a single manual configuration element - the address(es) of the DHCP servers the laptop wishes to acquire super-administrative configuration from. Probably delivered as a domain name, possibly also advertised eg via DHCP while the client is on the administrative domain's physical links. Firewalls or NAT, even if a problem, really aren't, since software can cache old values until it can freely observe the system again. This is just the same as network partition or packet loss problems. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpky1jeKfyzI.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
I'm sorry this reply is late. I suspect you were stuck in ISC's greylisters. On Fri, Apr 20, 2007 at 10:48:14AM -0700, Hallam-Baker, Phillip wrote: That's not the point, the point here is that DHCP is not an Internet protocol. It is an IETF protocol but not an Internet protocol. It does not layer on the IP stack. You're right, I muddled the point. The point is that the ISO L(x) is not what one considers when judging wether or not a certain configuration value would make a good band name. I mean DHCP option. What we (strive to) consider instead is the administrative scope of the configuration information, and wether it matches common and practical use of DHCP. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgphoF5V2vJn7.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: DHCP is a layer 3 technology that talks directly to layer 2. DHCP is a technology that dynamically configures hosts. If a host has a configuration knob that might reasonably and properly be set by the systems administrator or the network you are presently attached to, then it is reasonable and proper to configure it via DHCP. DHCP would be the wrong tool to configure how, in what frequency, or in what manner an application would directly contact a specific remotely administered service, such as a distant web server. DNS would be the correct tool for that sort of job, having as it does a global reach, and fate sharing. If GEOPRIV is truthfully a global service the client communicates with directly without the local network operator's involvement, then I think it should be configured by whatever global distribution means is reasonable. My impression is that GEOPRIV is a service that is provided by the local network to which the client is attached, and as such under the purview of that network's operator and DHCP, but I admit to not following it very closely. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpUBecRJKYQm.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-syslog-protocol: Reliabledeliveryconsidered harmful.
On Thu, Feb 08, 2007 at 02:32:00PM +0100, Rainer Gerhards wrote: I also agree with the observation that reliable - and blocking - logging can cause harm to a system. However, I do not think that this is anything that the protocol can do something against. It is not the protocol that causes harm. If we say if we support a reliable syslog protocol, we can block the system and thus the protocol is harmful, we can also say if we deliver mail messages via a reliable protocol (SMTP), we can use up all system ressources (e.g. fill the disk), so SMTP is harmful. RFC2821 (SMTP) defines a queueing behaviour and that servers should retry transmission for some reasonable number of times at intervals as specified in section 4.5.4. should there be problems at the reliable transmission layer. It seems your example does what the syslog draft does not, so I'm not sure what your point really is. My point is that we must differentiate between the protocol and its implementations. A reliable syslog protocol offers the foundation on which a reliable syslog implementation can be build. It is the task of the application designer to take care of the operating environment specifics while implementing the protocol. A good design for Unix will probably take into consideration that a blocking syslogd does not do any good and leave options to the operator to discard messages when needed (and probably have turned them on by default). Even in such a You must differentiate between the protocol and implementation, but not to the extent of denying the implementor guidance on how to proceed in a way that will promote the health of the protocol. The wholesale promotion of reliable transport without the disclaimer that the protocol-level process probably wants to enter into discarding behaviour in effect promotes the unhealthy condition. My hope is that a simple acknowledgement of this evidently common implementation mistake would substantially increase the quality of syslog implementations that are updated for it. design. Think about it: how can an IETF document specify what a syslogd should do if its sending queue is filled up? How could we word this so that it becomes part of an on-the-wire protocol? If you were going to update syslog so that it might be transported over a reliable channel, then I think the only right answer is to define how the protocol-level process, independent of which reliable transport is selected, deals with congestion or failure. Barring that, there are many duct tape approaches. Updating the security section to weigh the cons of denial of service against the pros of reliable delivery. Adding a glossary entry for reasonably reliable, and using such terms instead of the absolute reliable as is currently in place. Numerous others. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpCs7DtX1Fl6.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-syslog-protocol: Reliable delivery considered harmful.
On Fri, Feb 02, 2007 at 08:31:49AM +0100, Stephane Bortzmeyer wrote: Wether it is a bug or a feature depends on your requirments. On some high-security environments, people prefer to suspend the service rather than not being able to log it. (Otherwise, an attacker could easily attempt many attacks, fill in the hard disk and then perform the real attack unlogged). I'd just like to point out that you're choosing one bug over another. A DOS in preference to lack of observance of events. In my opinion, that's a bad selection, but it's your selection to make. That kind of preference, that kind of choice, is a good thing to have, but it would be unwise to apply to the general case a systematic selection of DOS over observation. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpMzYQozE74u.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-ietf-syslog-protocol: Reliable delivery considered harmful.
On Thu, Feb 01, 2007 at 08:09:29AM -0500, Sam Hartman wrote: Mark == Mark Andrews [EMAIL PROTECTED] writes: - 'The syslog Protocol ' draft-ietf-syslog-protocol-19.txt as a Proposed Standard Mark draft-ietf-syslog-protocol-19.txt recommends using a Mark reliable protocol. Existing implementations of syslog do Mark this and deadlock with nameservers which are logging via Mark syslog. Please explain the deadlock in more detail. One of the primary reasons for the syslog working group is reliable syslog, so I think we need to focus on how to avoid the deadlock in other ways rather than avoiding reliability. If you have 50,000 syslog lines to put out, and only enough network/disk/something bandwidth for 5,000 within the same time frame, that's a problem. If you insist on keeping all 50,000 lines of output, there is no solution to that problem. If you block, that's a big problem as it ultimatley totally disables the service attempting to log information. If you write to a growing backing store, well you'll run out of space eventually (even disk is not infinite). Compression can only get you so far. Ultimately you have to drop something, and if it's not the syslog output, it's the service's output. Reliability is the problem, and the advice we give our users is not to log reliably (or even to configure servers to log to a local file, circumventing syslog entirely). Note that reliable network transport of syslog information is equally damaging as reliable local storage of syslog output (eg by forcing disk synchronization of each line). At least one of today's syslog implementations insists that you prefix your filenames with a - if you /don't/ want it to fsync() every line. This default cripples DHCP servers. The current words in the draft; It may be desirable to use a transport with guaranteed delivery to mitigate congestion. May be adequate to the point of suggesting that reliable delivery might not be desirable. But on the whole the draft doesn't read that way, and it doesn't state the truth: reliable delivery of syslog output is always harmful. The point of bothering with reliable syslog delivery, if there is one, is for those very rare cases where losing the data is more harmful than harming system services. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgps8wAs1jFzh.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-syslog-protocol: Reliable delivery considered harmful.
On Thu, Feb 01, 2007 at 10:08:39AM -0800, David W. Hankins wrote: If you have 50,000 syslog lines to put out, and only enough network/disk/something bandwidth for 5,000 within the same time frame, that's a problem. s/5,000/49,999/ Apologies for the clerical error. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpYLLs4BKYVl.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-syslog-protocol: Reliable delivery considered harmful.
On Thu, Feb 01, 2007 at 10:30:17PM +0200, Pekka Savola wrote: It's acceptable for the syslog sender to replace overflowing lines of syslog (if some messages need to be dropped due to lack of resources) with a message about rate-limiting, messages being dropped, or whatever -- just the same way as messages might get dropped when syslogging to a local media. Then the word that should be used here is not reliable without any exceptions tagged on. As long as a) there is a message about syslogs getting dropped, and b) this is infrequent in a well operated system (i.e. the system log levels are set so that typically the amount of logging is OK), this should be no problem. I should note that while this would be just fine, this is not in fact what presently deployed syslog implementations that implement reliable delivery (wether to network sockets or local files) do. Today they block. To use the world 'reliable' without illuminating clearly that exceptions must be made is dangerous. IMHO, reliable delivery of syslog output is always harmful is very much an over-statement. Well, I wasn't counting on shifting the definition of reliable to somewhat reliable. Sure, somewhat reliable delivery of syslog output is always harmful is very much an over-statement, I'll agree with that. But I stand by what I said. get even more syslog to send. While this is a serious problem when it occurs, it should be easily solvable: just drop the messages (with a suitable note in syslog or in the local log) that exceed the buffer size or prune messages from the buffer using some more advanced strategy. That would be fine. But again, this is not what current implementations do, and that is not reliable without exception. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpwXrSTU9ytL.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
On Fri, Oct 13, 2006 at 10:31:57AM +0200, Frank Ellermann wrote: http://tools.ietf.org/html/draft-kolkman-appeal-support ...it's just wrong. I think he's got a good idea. It maybe could use some tweaking. The IETF should stop doing things that are not relevant to its constituency and serve only to waste its (donated) time-dollars. This includes but is not limited to: appeals from total nuts. One perfectly acceptable tactic, which Olafur has codified in this draft, is to limit appeals to only those made by mixed nuts. I think it would be more productive to suggest alternative tactics than to ask Olafur to withdraw his draft. We would all like to know what other options there are. I didn't try to find three paying members to support that opinion, and nobody else is qualified to support it :-( ...nor would you have had to. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpgEUoU6KKuA.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
On Fri, Oct 13, 2006 at 01:16:53PM -0400, Keith Moore wrote: I just don't think that IETF meeting attendance is an appropriate way to decide who is a nutcase and who isn't. Appropriate or not, it's not an effective way to distinguish nuts, as it should not surprise you to learn that most of the people who come to IETF meetings are nuts as well. Nor does it have to be if the goal is to reduce the frequency of incidence rather than a complete shut-out. By asking for a 'conspiracy of mixed nuts' rather than a 'single nut acting alone', the frequency of incidence should be drastically reduced. But, we mustn't let nuts use their mom as a supporter, or else such conspiracies of mixed nuts would ultimately be the rule. So, some limitations must be made. The definitions in Olafur's draft for qualified supporters shouldn't be considered exclusionary. People in that position can still participate by expressing opinions, or possibly might convince someone else to offer their support in proxy. Perhaps Olafur might even be convinced to produce text in his draft that encourages individuals to provide their support in proxy, or to allow IAB/IESG members to waive. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpWNczhFGKEg.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-kolkman-appeal-support
On Fri, Oct 13, 2006 at 10:03:39AM -0700, David W. Hankins wrote: One perfectly acceptable tactic, which Olafur has codified in this s/Olafur/Olaf/g How embarrassing. Sorry, Olaf. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpFN2OZwLMXW.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
On Mon, Oct 09, 2006 at 09:08:42AM -0700, todd glassey wrote: No it wasn't Brian - the WIPO IP Framework calls for a set of protections for Industrial Designs which ALL of the work that happens here is controlled by right? I suppose you might consider ALL IETF work as protected or threatened by WIPO Inustrial Designs [1] treaties if you first accept that ALL IETF work is ornamental. But of course, the joke isn't funny if you have to explain it. [1] http://www.wipo.int/designs/en/designs.html -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpDD8XpWGVLf.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proceeding CDs
On Fri, Oct 06, 2006 at 10:56:51PM +, [EMAIL PROTECTED] wrote: Remove that, and the question might be asked? What do we get for our money? more often. Are you suggesting that proceeding CD's are actually a valid answer to this question, or that people should merely be convinced to ask this question less frequently by any means available other than actually providing answers? -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpaoLTjtfkUZ.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: zone is not a DNS name semantic
I am flattered that my simple opinion required not one but two such voluminous responses. Thank both of you for the compliment. I don't think repeating my (unchanged) opinion is useful or will have any real impact on the Internet, so I had not planned on responding. But there is something in Dave Crocker's reply that I need to clear up, as I gather it is my fault: On Wed, Sep 27, 2006 at 10:32:58AM -0700, Dave Crocker wrote: David W. Hankins wrote: Quite the opposite. DHCP server software commonly refers to shared code to process DHCP option contents. So citing this section of RFC3315 is telling an implementor to reuse that code. Oh. So there is a specification for existing DHCP mechanism(s) that use this construct? If I gave you the impression that the ISC DHCP server and client software shared common code or libraries with, say, the Kame server and, say, the Apple OSX client (if there is one), that is incorrect. I was referring to practices internal to implementations, reuse of code internal to each. And so long as I'm transmitting, there is one other thing; | returns. And what you, as a server implementer, already know | or can take advantage of is of absolutely no use to them. One might infer from this that I am creditable for ISC's DHCPv6 Server implementation, and that isn't correct. Let me be clear: the only person who deserves that credit is Shane Kerr. If I deserve any credit, it is for helping him find bugs. We are both, however, equally culpable for any blame. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED] -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpTDLVdafIz3.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)
I'm not sure why this discussion has broken out on [EMAIL PROTECTED]
Is it not better for iesg@ and [EMAIL PROTECTED]
On Wed, Sep 27, 2006 at 08:41:27AM -0700, Dave Crocker wrote:
as John noted, the term item is not defined, so we don't know how many
labels (dns fields) are permitted. This certainly encourages the
confusion between TLD and organization base.
It's hard to disagree with the term 'item' being more vague than is
ideal. To be clearest it should probaly say having exactly one root
label (one domain name) or similar.
I am, however, a little skeptical at how useful it is going to be
to define the term 'domain name suffix'. I suspect the author of
this draft started by calling them 'zone suffixes' and was asked by
DNS people to switch to 'domain name' instead of 'zone' because
the principle concept of a 'zone name' is different from a 'domain'
(although they overlap and are sometimes equal).
That's judging by the history of edits of this document and others
it at one time referenced (which looks to be a bid to place the
suffix in RS/RA, calling it a 'zone suffix' at that time).
I think operators know what this term means intuitively. We can
define what it means all we want, but they already know and don't
care what we think it means. So it seems like a lot of work with
very little payout and a high degree of probability it will turn
into a windmill designed for tilting at.
Once standing upon that ground, one questions why there would be
any wonderment about the meaning of the word 'item' in this context,
where the term 'domain name suffix' is already well understood.
I'm also a tad uncomfortable with the levels of indirection in the cited
reference. The 3315 section really points to a section in 1035, modulo
prohibiting compressed form. The cited section in 1035 defines a basic
syntax but then relies on a different section in 1035. This all seems
likely to invite different interpretations.
Quite the opposite. DHCP server software commonly refers to shared
code to process DHCP option contents.
So citing this section of RFC3315 is telling an implementor to
reuse that code.
Literally, when I read an option document for DHCPv6 that cites
this section of 3315, all I have to do is turn that into:
{ option-name, D, dhcpv6_universe, CODE_NUM, 1 },
I don't even need to look up that section of 3315 nor the 1035
document. This is just a standard DHCPv6 domain name format.
Note that if we take this stance, that every draft must redefine
the meaning or cite some new work that does so, then we should have
done that in RFC3319, RFC3646, RFC3898, and RFC4280. Possibly the
DHCPv6 FQDN draft (still waiting for RFC assignment) as well, I can't
remember.
All of these used this method to define options of this format, to my
recent memory at least. It is common DHC WG guidance to authors to
cite 3315 rather than reinventing.
DHCPv4 has taught us that, while clarity is important and we strive
for it, consistency is more important of these two.
It is better that one implementation treat all similarly formatted
options the same (poor) way, than for any implementation to treat
some options differently from others.
The former is easy for implementations to construct workarounds -
in single, reused-code ways. The latter is a nightmare construct
of matrixes of option codes and special-case code.
--
ISC Training! October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS DHCP. Email [EMAIL PROTECTED]
--
David W. HankinsIf you don't do it right the first time,
Software Engineer you'll just have to do it again.
Internet Systems Consortium, Inc. -- Jack T. Hankins
pgpytmkNZO4Dg.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF lists as RSS?
On Wed, Apr 26, 2006 at 11:38:30PM +0200, Stephane Bortzmeyer wrote: On Wed, Apr 26, 2006 at 10:24:22PM +0200, Alexandru Petrescu [EMAIL PROTECTED] wrote Is it possible to read content of the IETF lists (WG discussions, announce, etc) as RSS feeds? It would be strange to use one of the many RSS formats while there is a technically superior IETF standard (RFC 4287). It would certainly be strange, at the IETF, for anyone to suggest using a technology that is known to be pervasively deployed and functional. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpHnXWYFvlKS.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
I haven't seen any replies in this corner of the thread. Apologies if this has been covered elsehwere. On Sat, Nov 26, 2005 at 04:27:27PM +0200, Pekka Savola wrote: I have one major issue with 'Resolution of FQDN Conflicts among DHCP Clients', the first issue below. It fails to properly describe the threats caused by DHCP clients requesting updating non-DHCP FQDN's (like a random host from example.com requesting www.example.com). While this may not be a problem if DHCP clients belong to different zones from non-DHCP clients, this is not discussed at all in the document -- except ruled out of scope. The WG felt that it was necessary to include language in the document that gives implementors freedom to use alternative algorithms. This is one such case...where the 'example algorithm' the document set out to describe handles the condition you describe easily (without a need for security consideration) because the existence of an A record without a DHCID results in update failure and the client is given a unique name instead. Admittedly, this makes the document 'mosey' a bit. But it would be foolhardy to ask the authors to document every single possible security implication of every single possible alternate algorithm, including the alternative possibilities the WG discussion asked it to explicitly permit. I think the security section would rapidly become larger than the document in total. Now, perhaps RFCs shouldn't read like Choose your own Adventure novels. And asking the authors to mud the language to endorse alternative algorithms was a waste of their time. Perhaps the document should have documented one algorithm, noted the possible existence of others only, and continued to document exactly one algorithm implementing exactly one administrative policy consistently throughout. And leave all else to future work. I seem to recall someone actually saying that in the WG traffic on the subject. I think it was the author. Perhaps we should have listened, or more of us should have agreed. Overall, that's probably healthier for the DHCP-accessed dynamic DNS universe...that the RFCfoo compliant text on each product be the same only on those products that are actually intercompatible, not merely those who once met the algorithm described in the draft in a subway. I've got to agree on this tangent with Pekka here. 6.3.2. DNS UPDATE When FQDN in Use 2. A delete of the existing RRs on the FQDN if the updater does not desire records on the FQDN or this update is adding an and the updater only desires a single IP address on the FQDN. == how does the code know whether the updates only desires a single IP address on the FQDN or not? AFAICS, there's no way to signal this from the DHCP client! That's correct, this is the operator's decision, which may be made for them by software of specific manufacture (or defaults of same). A system administrator may preside over an array of DHCP clients, let us imagine, that do not tell the DHCP server to RELEASE their lease prior to being uncerimoniously removed from the networks to which they are attached. In this case, it is desirable for the clients to be treated as though they only ever have a single address. The old addresses are stale, and continued resolution of them in the DNS only produces timeouts (or failure to operate if the software can't seek to the working address). A client or server implementation may elect to simply delete all old A/ records whenever it updates. Or it may elect to teardown the previous records prior to updating (ISC DHCP one-lease-per-client true; syntax for example). Or, if it believes both addresses are actually in use or at least leaves it up to the client to release their leases if they aren't, it can allow multiple addresses. So if the 'updater', be that client or server, be that software of ISC or Kame or Cisco or Nominum manufacture, be that Fred or George's system, chooses, it can do what it pleases. Through the use of the client FQDN option, DHCP clients and servers can negotiate the client's FQDN and the allocation of responsibility for updating the DHCP client's A and/or RRs. == also PTR records, not just A/.. No. Only A/. The PTR is always updated by the server. Hence the responsibility of updating the A/ is the only thing that's negotiated in the FQDN option. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpJz33ROsXol.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
On Wed, Nov 30, 2005 at 03:51:13AM -0500, Sam Hartman wrote: Phil is suggesting something like _dhcid.domain . Except the difference between NXDOMAIN and NXRRSET is important for the DHCID. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
On Thu, Dec 01, 2005 at 03:00:49PM +0200, Pekka Savola wrote: On Wed, 30 Nov 2005, David W. Hankins wrote: Now, perhaps RFCs shouldn't read like Choose your own Adventure novels. My problem is that the spec leaves the algorithm completely open. There is at least one simple algorithm (just blindly update if there's no DHCID) has severe problems in certain kinds of zones. This doc should discourage or disallow that algorithm by default. As for the rest, I don't really care (though as a user, it would likely have been nice if the behaviour between different vendors would have been consistent, but we aren't going to get that it seems..). I think we should take this one back to the WG. Find out how many algorithms there are which people actually want to use, within each how many administrative policies there are (and name them all), and who is interested in each one (more importantly, which One Bernie still has the strength to document, if any). Split up and go our separate ways, make new documents for the additional algorithms (or don't if the interested parties don't feel a need to). That's correct, this is the operator's decision, which may be made for them by software of specific manufacture (or defaults of same). This is exactly the problem: the software choosing what's best for the user. Welcome to DHCP? I'm sorry, that wasn't fair. When, for example, at an IETF, where the systems operators are engineers of similar character and capability as the clients (IETF attendees), this solution can mix like water and oil. Especially if any of the involved individuals have opinions on how things should work, and choose to share them, which is about like applying a match to the solution. An IETF Molotov cocktail, if you will. But, on a campus of some 100,000 Windows boxes, for example, where the system operator has very limited experience with networks much less DHCP much less DNS (because this is a job they give 'the new guy'), and a drinking problem to boot, and the users surprise us daily by their ability to mimic human speech, even forming rudimentary sentences such as I want net! or Fix magic electric box now!, this is ultimately the only sane approach. Obviously, between those two there are a variety of equally painful scenarios, and we hope a bell curve where reasonably skilled operators are asked to preside over reasonably computer literate client users. Only some skeptics say the bell is upside-down. Software will exist that is tailored to at least those two extremes, if not more. I suspect most software (or most widely used software) will need to be readily adaptable to either. So the draft really needs to document both ends of the spectrum. [looks like I oversnipped bits about A/ genocide] That would be unfortunate. Wouldn't it be sufficient that the server removes the DNS records after the lease expires? Then if the user doesn't reconnect anywhere else prior to lease expiry, all is cool. That is one approach, but it is the road generally not taken. Lease times in campuses are often 24 hours, or more (I've seen 3-month lease times, although they are rare...1 week is fairly common. Also let us not forget that RFC2131 explicitly has a special-case value (all-ones) for the lease-time that is defined to mean infinite...there are some actual field cases where this is used (I get patches from these people). Is it wise to leave forward records up indefinitely? One operational impact of lease time is frequency of interruption for the client. Some clients either return to INIT state immediately should the renewal time out (so brief interruptions in the DHCP service are painful for some sysops), and some are known to 'hang' the IP layer while the renewal is underway (painful for the user, more painful when the systems administrator gets phonecalls asking why). And in my own experimentation, I was able to consistently crash an array of Windows 95, 98, and 2000 boxes simply by using a 30 second lease time. Wether these behaviours are in the spirit of the RFCs or not is immaterial to an operator. Add to this that larger times result in lower rate of activity on a DHCP server (or cluster of same) in the center of a large campus. So, larger lease times are preferred by admins. Generally the question is how much advance notice are you required to give for network downtime? Often 24, or 48 hours. Letting these large times expire isn't tractable if the client has a need to be reached by its name (which would be the whole point of DDNS via DHCP - not mere vanity we would hope). -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpo75ElKoQSB.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
On Mon, Nov 28, 2005 at 05:20:09PM -0500, Bernie Volz (volz) wrote: Yes, I can. The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it uses MD5 to encode the client identity or not). Ted might know for sure. It does, though it only encodes the client identity (client identifier option or chaddr), it does not include the FQDN like the current DHCID draft does. There are a few niggling bits that are different, and obviously incompatible (not just because it's encoded as hexadecimal in a TXT record), but on all points that are topical to this discussion it's the same. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] DHCP and FQDN conflicts [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
On Mon, Nov 28, 2005 at 01:13:43PM -0500, Sam Hartman wrote: You need to get sufficiently specific that in practice, the implementation of this option is not influencing addressing plans. For example if servers tend to get this wrong in a way that makes it difficult for me to have multiple addresses for client then you were not specific enough. In practice, at least one implementation today will fail (logging an error) if more than one A record on a given FQDN is present. Will more specific text change that? It's actually the current wording of the drafts that first imparted to me the contrary, and the means to acheive that, and you might see a future version of ISC DHCP moving in that direction as a consequence. So, in my unreliable opinion, it's fine the way it is. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
