Re: IETF, IAB, RFC-Editor
Ran, RJ Atkinson wrote: Previously, someone wrote: I finished reading the RFC editor document and have one major concern. Ultimately, the rfc-editor function needs to be accountable to the IETF community because we're the ones paying for it. Incorrect. As I pointed out some weeks ago, and Leslie has recently repeated, IETF has never paid for the RFC-Editor. Historically, RFC-Editor was created by (D)ARPA and paid by (D)ARPA. More recently, some large commercial firms have donated substantial funds to ISOC -- with the understanding that the RFC-Editor would be among the functions paid for from those funds. [1] I would like to suggest a qualification to this. Things have changed over time. When DARPA stopped funding ISI to perform the RFC Editor function, ISOC stepped in to fill the gap. Subsequently, ISOC also provided a discretionary fund for the IETF Chair, and extended its liability insurance to cover the IETF leadership. (At some point, the discretionary fund was split between the IETF Chair and the IAB Chair.) In 2000/2001, ISOC consolidated these expenditures in its standards pillar accounting. Subsequently, and most recently, ISOC agreed to host IASA, which is now the funding agency for all of the above plus meeting expenses and the Secretariat. So whatever the historical situation, the *current* situation is that a single budget is fed by ISOC member contributions, ISOC donations, and IETF attendance fees, and the RFC Editor contract is just one item in that budget. This doesn't contradict Ran's statement of the history in the least. With reference to Ran's note [1], my recollection of numerous meetings of the ISOC Advisory Council of organizational members is that representatives there consistently stated support of the standards pillar as their primary motivation for supporting ISOC. Of course they knew that historically the bulk of the money in that pillar was going to support the RFC publication process, prior to the creation of IASA. In particular I believe that the IETF should be able to pass a BCP placing requirements on an rfc-editor stream. We've done this with RFC 3932 for example, and I think that was a good thing. In effect, community consensus within the IETF should trump anything else. It has NOT been the case in the past that IETF was the community in control of RFC-Editor. In fact, that would represent a major, and in many people's view highly undesirable, change. Historically, RFC-Editor has served the broader Internet community, including but not limited to the IETF. In fact, the RFC-Editor has existed since the late 1960s, yet the IETF did not even exist until the middle 1980s. Historically, yes. But I think we're discussing the future. Nevertheless, I personally support the existence of an independent submission mechanism, as part of a general pattern of checks and balances. (See below.) However, I'd like to ask for a definition of the broader Internet community. Since about 1995, the Internet has been a public access network, so I could interpret the phrase as referring to several hundred million people at this point. Since the IETF is open to all, I'm puzzled how to draw a line around the broader Internet community that is meaningfully different from the IETF/IRTF/IAB community but less than the entire on-line population. Now, we need to be careful about how to use that consensus. Several RFC streams serve communities broader than the IETF. Unless we have good reason to do so, we should not step on those communities by overriding their requirements. Indeed, it would be a gross assumption of non-existent authority for the IETF to over-ride the broader Internet community. In the narrow situation of preserving the integrity of the standards process, existing procedures ensure that the standards process is not bypassed by some 3rd party. There is not a problem here, nor a reason for IETF to shut down the very important non-IETF uses of the RFC publication process. Despite the best efforts of new technologies (e.g. combining Google Scholar and institutional technical reports), there are still numerous RFCs each year that are not published by IETF and yet are important for the broader Internet community (which by definition includes, but is not limited to, the IETF). There are roughly 3 categories of such documents: - independent submissions to the RFC Editor relating to technology, research, or other (non-standards) issues. - IRTF submissions to the RFC Editor (as a reminder to newcomers, the IRTF also reports to the IAB, NOT to the IETF). - publications by IAB or ISOC All 3 of those categories are important. Generally speaking, none of those categories are within the purview of the IESG or the IETF -- and NEVER have been historically (with the narrow and important exception, both historically and now, that the IESG has a chance to object to publication of something that is trying to make an end run
Re: IETF, IAB, RFC-Editor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I suppose you are aware of the next ISOC board meeting in Marrakesh is on the 1/2 July 2006 (www.isoc.org) While I have kept an eye on the IETF list for qite some time, I still consider myself a newbie in the relationship ISOC/IETF. I'm trying to better understand it especially with this reform process, so any point of view is interesting for me. I also find the IETF is doing a great job but not sure how to best help it. IETF is 20 years old, I also hope to learn more during a workshop at www.egeni.org on the historic role of IETF (22 June 2006, Paris). Cheers Brian E Carpenter wrote: | Ran, | | RJ Atkinson wrote: | | Previously, someone wrote: | | I finished reading the RFC editor document and have one major | concern. | | Ultimately, the rfc-editor function needs to be accountable to | the IETF community because we're the ones paying for it. | | | | Incorrect. As I pointed out some weeks ago, and Leslie has | recently repeated, IETF has never paid for the RFC-Editor. | | Historically, RFC-Editor was created by (D)ARPA and paid by | (D)ARPA. More recently, some large commercial firms have donated | substantial funds to ISOC -- with the understanding that the | RFC-Editor would be among the functions paid for from those | funds. [1] | | | I would like to suggest a qualification to this. Things have | changed over time. When DARPA stopped funding ISI to perform the | RFC Editor function, ISOC stepped in to fill the gap. Subsequently, | ISOC also provided a discretionary fund for the IETF Chair, and | extended its liability insurance to cover the IETF leadership. (At | some point, the discretionary fund was split between the IETF Chair | and the IAB Chair.) In 2000/2001, ISOC consolidated these | expenditures in its standards pillar accounting. Subsequently, | and most recently, ISOC agreed to host IASA, which is now the | funding agency for all of the above plus meeting expenses and the | Secretariat. So whatever the historical situation, the *current* | situation is that a single budget is fed by ISOC member | contributions, ISOC donations, and IETF attendance fees, and the | RFC Editor contract is just one item in that budget. | | This doesn't contradict Ran's statement of the history in the | least. | | With reference to Ran's note [1], my recollection of numerous | meetings of the ISOC Advisory Council of organizational members is | that representatives there consistently stated support of the | standards pillar as their primary motivation for supporting ISOC. | Of course they knew that historically the bulk of the money in that | pillar was going to support the RFC publication process, prior to | the creation of IASA. | | - -- - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Franck Martin franck@sopac.org Toute connaissance est une réponse à une question G. Bachelard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFEhCTlvnmeYIHZEyARAtTBAJwLUb5A7+mdSjDPGxaVY/9LGSDMlACeIYxh MWceB9CzA8a/Wr6V7oZZSfM= =vYIH -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF, IAB, RFC-Editor
On 5 Jun 2006, at 02:54, Brian E Carpenter wrote: Earlier, Ran Atkinson wrote: It has NOT been the case in the past that IETF was the community in control of RFC-Editor. In fact, that would represent a major, and in many people's view highly undesirable, change. Historically, RFC-Editor has served the broader Internet community, including but not limited to the IETF. In fact, the RFC-Editor has existed since the late 1960s, yet the IETF did not even exist until the middle 1980s. Historically, yes. But I think we're discussing the future. Nevertheless, I personally support the existence of an independent submission mechanism, as part of a general pattern of checks and balances. (See below.) However, I'd like to ask for a definition of the broader Internet community. Since about 1995, the Internet has been a public access network, so I could interpret the phrase as referring to several hundred million people at this point. Since the IETF is open to all, I'm puzzled how to draw a line around the broader Internet community that is meaningfully different from the IETF/IRTF/IAB community but less than the entire on-line population. Brian, It is a fair question. Different people might have slightly different formulations, but I don't think that those would be meaningfully different. Here is a starting point for a definition... I think that the broader Internet community at least includes folks around the world who are engaged in (non-IAB, non-IRTF, and non-IETF) Internet research and development or are academics otherwise involved with the Internet (e.g. through educating college students). That collective group is not nearly several hundred million people. Further, that group also has a RFC Editor relationship that long predates the existence of IETF/IRTF -- and also has a current active relationship with the RFC-Editor that is separate from the IETF/IRTF. Their needs primarily relate to a substantial and workable mechanism for individual submissions to actually get published in a timely manner. As the IETF has become MUCH more commercially influenced over the past ~10-15 years, the non-product perspectives that such people often bring to the published RFC document series is increasingly important to the overall health of the Internet. IMHO. All, It is not an accident that the criteria for candidates for IAB are different than for IESG. In my experience, and I'm told that this is not a strange perspective, the IAB functions best when IAB has several members who come from the non-commercial RD/Academic communities -- particularly members who are not particularly involved in IETF standards activities. Those folks can bring a fresh, non-commercial perspective to IAB functions, including but not limited to advice to the IETF/IRTF or input to the RFC-Editor function. Historically, such folks have often done so. As an example, Jon Crowcroft did a wonderful job, yet had not been active in IETF prior to his appointment to the IAB. Of course, he was already quite well known for his Internet research before then. For some years, I've been making this same general observation to the Nominating Committee. Yours, Ran [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Considerations on the IPv6 Host density Metric' to Informational RFC (draft-huston-hd-metric)
On Sun, 2006-06-04 at 10:39 +1000, Geoff Huston wrote: At 01:33 PM 3/06/2006, Steven Blake wrote: I am concerned about the conclusion reached in this document (that HD ratios 0.8 and closer to 0.94 should be considered when making address allocations to larger providers). This is a topic of interest both to the IETF and to regional addressing policy fora, and some care needs to be taken in reaching an understanding of relative roles. As compared to your opening statement relating to the conclusion of this document, I must correct you by noting that this document makes NO specific recommendation as to an optimal HD Ratio value to be used in the context of a threshold address utilization efficiency metric. This document provides a refinement to the work reported in RFC1715, RFC 3177 and RFC 3194 that recommended the use of an HD Ratio of 0.8 for assessment of threshold address utilization efficiencies in an address allocation context. The refinement proposed in this document is, and I quote: This study concludes that consideration should be given to the viability of specifying a higher HD-Ratio value as representing a more relevant model of internal network structure, internal routing and internal address aggregation structures in the context of IPv6 network deployment. Your representation as to the document's conclusions is simply not supported by the document itself. Geoff, I don't understand why you think my paraphrase of your document's conclusions (including the quoted text above) is unfair or inaccurate. What is the concern that would make such consideration (of specifying a higher HD ratio) worthwhile? I assume that it is address allocation inefficiency with HD = 0.80, as suggested in your comments on Figure 4, and the implied risk (which you have described in much more detail elsewhere) that IPv6 unicast address space is a resource at plausible risk of being exhausted at some point in the future, without changes to the HD ratio. Am I mistaken? I've read your arguments elsewhere that we are at risk of allocating a /1 - /4 worth of space in the next 60 years under current polices. I don't find your arguments convincing, and further, I'm not convinced that this would pose some sort of catastrophe, rather than the achievement of a steady state. And even if it is a real risk, then a switch to /56 allocations for residential/SOHO is a preferable solution to increasing HD, because we don't know what the design for an internet- sized IGP would look like. I am concerned that this document sends the wrong message to providers, and I fear that their likely reaction to the perceived risk of tighter allocation policies by the RIRs with be more harmful to the IPv6 internet that the potential risk of address space exhaustion. Regards, // Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'Considerations on the IPv6 Host density Metric' to Informational RFC (draft-huston-hd-metric)
I am concerned about the conclusion reached in this document (that HD ratios 0.8 and closer to 0.94 should be considered when making address allocations to larger providers). I believe that: (1) this would not solve a real problem, (2) it is risky to infer too much from existing network design practice when considering future provider networks that may be much larger, and (3) there is a better solution to the alleged problem. 1. To begin, the following number of /48 site prefixes can be allocated out of 2000::/3, for various values of the HD ratio: HD 0.800.85 0.90 0.94 /48s 68.7e9 327e9 1.56e12 5.42e12 Note that for HD = 0.80, that is 6 site allocations per-person, when the world reaches peak population of ~10e9 around 2050. Recall that site allocations are not permanent, so they can be recycled as the population rolls over. Assuming that 6 site allocations per-person is insufficiently conservative, then consider the scenario where the RIRs issue maximum size allocations of /16. There are 2^13 possible /16s under 2000::/3. If half of these /16s are utilized at HD = 0.80, and the other half are empty, then 2000::/3 could accommodate 208e9 /48s (632e9 for HD = 0.85). We could quadruple these numbers while only allocating approximately half of the total available IPv6 address space. Under these assumptions we could very easily imagine a future internet supporting 800e9 subscriber sites (80 per-person!), while still holding to the HD = 0.80 allocation policy (2.53e12 for HD = 0.85). Of all the challenges that will have to be solved to realize such a large internet, IPv6 address exhaustion should be the least of our worries. 2. Assume that the previous assumptions are unwarranted, 68.7e9 is the maximum number of /48 site allocations that can be supported with HD = 0.80, and that this number of sites is insufficient. Note that the number of possible providers cannot grow by more than an order of magnitude from today's number, for a variety of economic and logistical reasons (and some would argue that the number has already peaked). In a world with tens or hundreds of billions of subscriber sites, the largest providers may have more than a billion subscribers. Consider a future (large? medium-sized?) provider serving 2^28 = 268e6 subscriber sites. The following is the allocation size needed by this provider for a range of HD values: Efficiency Allocated prefix -- 100% efficiency /20 HD = 0.80/13.0 HD = 0.85/15.1 HD = 0.90/16.9 HD = 0.94/18.2 For HD = 0.94, there are ~2 bits of slack to allocate for internal hierarchy, less than 1 bit per-level assuming four levels of provider-internal hierarchy (= 50% utilization efficiency/level). Is it reasonable to assume that such a large network can be engineered and maintained with only two bits of allocation slack, without frequent renumberings? Experience from existing networks which are typically much smaller might not hold for much larger networks. 3. /48 site allocations are massive overkill for residences and SOHOs. Assume 10e9 organizations (~1 per-person) needing four /48 allocations each (for multi-homing). Assume that the remaining hundreds of billions of residence/SOHO sites can function with /56 site allocations. 2000::/3 can accommodate these 40e9 /48s plus an additional 2.89e12 /56s with HD = 0.80 (with no tricks, such as the max /16 assignments suggested above). A /56 allocation is more or less equivalent to an IPv4 /16 allocation (256 Class C subnets). I will be delighted if my residential provider ever offers me a /60 IPv6 allocation. Being unnecessarily conservative with address allocations to providers will only increase the chance that they will be unnecessarily conservative with address allocations to subscribers. Regards, // Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF, IAB, RFC-Editor
Dear Franck, the reference is not ISOC nor the IETF. The reference is the user. Hence, the networking solution people may use on the digital ecosystem they built and own in common. The difficulty is to evaluate from past and present IETF/ISOC contributions their future cons and pros; and the methods for their pros to keep being efficient and their cons to be corrected. This concerns the time proven/dusted approach of their affinity group (RFC 3774) - among the billions mentionned by Brian. Can they still deliver? Not easy as those who think no, or are confused (the users?) are not available for comment, or PR-actionned. Some questions are: - what are the users' needs which are solved, and not solved? - why was the IETF good as solving them, poor at not solving them? - what should be the resulting architecture we should support and how should we support it? - is the IETF/IAB/IESG/IASA/ISOC adapted to produce the deliverables this architecture requires? - what about users' QA? Please reread RFC 3774, 3935, 3968. This kind of self-analysis is impressive. It should help. They all tell what is to be corrected. Starting with the mission and purpose of the IETF. It is not to make the Internet work better in influencing people (where legitimacy, capacity and competence would come from?). But it is to tell people how they can better build, manage and interopate their own system. jfc At 14:34 05/06/2006, Franck Martin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I suppose you are aware of the next ISOC board meeting in Marrakesh is on the 1/2 July 2006 (www.isoc.org) While I have kept an eye on the IETF list for qite some time, I still consider myself a newbie in the relationship ISOC/IETF. I'm trying to better understand it especially with this reform process, so any point of view is interesting for me. I also find the IETF is doing a great job but not sure how to best help it. IETF is 20 years old, I also hope to learn more during a workshop at www.egeni.org on the historic role of IETF (22 June 2006, Paris). Cheers Brian E Carpenter wrote: | Ran, | | RJ Atkinson wrote: | | Previously, someone wrote: | | I finished reading the RFC editor document and have one major | concern. | | Ultimately, the rfc-editor function needs to be accountable to | the IETF community because we're the ones paying for it. | | | | Incorrect. As I pointed out some weeks ago, and Leslie has | recently repeated, IETF has never paid for the RFC-Editor. | | Historically, RFC-Editor was created by (D)ARPA and paid by | (D)ARPA. More recently, some large commercial firms have donated | substantial funds to ISOC -- with the understanding that the | RFC-Editor would be among the functions paid for from those | funds. [1] | | | I would like to suggest a qualification to this. Things have | changed over time. When DARPA stopped funding ISI to perform the | RFC Editor function, ISOC stepped in to fill the gap. Subsequently, | ISOC also provided a discretionary fund for the IETF Chair, and | extended its liability insurance to cover the IETF leadership. (At | some point, the discretionary fund was split between the IETF Chair | and the IAB Chair.) In 2000/2001, ISOC consolidated these | expenditures in its standards pillar accounting. Subsequently, | and most recently, ISOC agreed to host IASA, which is now the | funding agency for all of the above plus meeting expenses and the | Secretariat. So whatever the historical situation, the *current* | situation is that a single budget is fed by ISOC member | contributions, ISOC donations, and IETF attendance fees, and the | RFC Editor contract is just one item in that budget. | | This doesn't contradict Ran's statement of the history in the | least. | | With reference to Ran's note [1], my recollection of numerous | meetings of the ISOC Advisory Council of organizational members is | that representatives there consistently stated support of the | standards pillar as their primary motivation for supporting ISOC. | Of course they knew that historically the bulk of the money in that | pillar was going to support the RFC publication process, prior to | the creation of IASA. | | - -- - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Franck Martin franck@sopac.org Toute connaissance est une réponse à une question G. Bachelard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFEhCTlvnmeYIHZEyARAtTBAJwLUb5A7+mdSjDPGxaVY/9LGSDMlACeIYxh MWceB9CzA8a/Wr6V7oZZSfM= =vYIH -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Re: IETF, IAB, RFC-Editor
Can someone please explain to me how to remove my email address from the ietf mailing list? Can I just go to ietf.org?PhilMaceri10247BarlowCrossingPerrysburg,OH43551Cell:248-250-1194Home:586-435-9542 Date: Mon, 5 Jun 2006 15:35:41 +0200 To: franck@sopac.org; [EMAIL PROTECTED] From: [EMAIL PROTECTED] CC: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: IETF, IAB, RFC-Editor DearFranck, thereferenceisnotISOCnortheIETF.Thereferenceistheuser. Hence,thenetworkingsolutionpeoplemayuseonthedigital ecosystemtheybuiltandownincommon.Thedifficultyistoevaluate frompastandpresentIETF/ISOCcontributionstheirfutureconsand pros;andthemethodsfortheirprostokeepbeingefficientand theirconstobecorrected.Thisconcernsthetimeproven/dusted approachoftheir"affinitygroup"(RFC3774)-amongthebillions mentionnedbyBrian.Cantheystilldeliver?Noteasyasthosewho think"no",orareconfused(theusers?)arenotavailablefor comment,orPR-actionned. Somequestionsare: -whataretheusers'needswhicharesolved,andnotsolved? -whywastheIETFgoodassolvingthem,pooratnotsolvingthem? -whatshouldbetheresultingarchitectureweshouldsupportandhow shouldwesupportit? -istheIETF/IAB/IESG/IASA/ISOCadaptedtoproducethedeliverables thisarchitecturerequires? -whataboutusers'QA? PleaserereadRFC3774,3935,3968.Thiskindofself-analysisis impressive.Itshouldhelp.Theyalltellwhatistobecorrected. StartingwiththemissionandpurposeoftheIETF.Itisnottomake theInternetworkbetterininfluencingpeople(wherelegitimacy, capacityandcompetencewouldcomefrom?).Butitistotellpeople howtheycanbetterbuild,manageandinteropatetheirownsystem. jfcAt14:3405/06/2006,FranckMartinwrote: -BEGINPGPSIGNEDMESSAGE- Hash:SHA1 All, IsupposeyouareawareofthenextISOCboardmeetinginMarrakeshis onthe1/2July2006(www.isoc.org) WhileIhavekeptaneyeontheIETFlistforqitesometime,Istill considermyselfanewbieintherelationshipISOC/IETF.I'mtryingto betterunderstanditespeciallywiththisreformprocess,soanypoint ofviewisinterestingforme. IalsofindtheIETFisdoingagreatjobbutnotsurehowtobest helpit. IETFis20yearsold,Ialsohopetolearnmoreduringaworkshopat www.egeni.orgonthehistoricroleofIETF(22June2006,Paris). Cheers BrianECarpenterwrote: |Ran, | |RJAtkinsonwrote: | |Previously,someonewrote: | |IfinishedreadingtheRFCeditordocumentandhaveonemajor |concern. | |Ultimately,therfc-editorfunctionneedstobeaccountableto |theIETFcommunitybecausewe'retheonespayingforit. | | | |Incorrect.AsIpointedoutsomeweeksago,andLesliehas |recentlyrepeated,IETFhasneverpaidfortheRFC-Editor. | |Historically,RFC-Editorwascreatedby(D)ARPAandpaidby |(D)ARPA.Morerecently,somelargecommercialfirmshavedonated |substantialfundstoISOC--withtheunderstandingthatthe |RFC-Editorwouldbeamongthefunctionspaidforfromthose |funds.[1] | | |Iwouldliketosuggestaqualificationtothis.Thingshave |changedovertime.WhenDARPAstoppedfundingISItoperformthe |RFCEditorfunction,ISOCsteppedintofillthegap.Subsequently, |ISOCalsoprovidedadiscretionaryfundfortheIETFChair,and |extendeditsliabilityinsurancetocovertheIETFleadership.(At |somepoint,thediscretionaryfundwassplitbetweentheIETFChair |andtheIABChair.)In2000/2001,ISOCconsolidatedthese |expendituresinits"standardspillar"accounting.Subsequently, |andmostrecently,ISOCagreedtohostIASA,whichisnowthe |fundingagencyforalloftheaboveplusmeetingexpensesandthe |Secretariat.Sowhateverthehistoricalsituation,the*current* |situationisthatasinglebudgetisfedbyISOCmember |contributions,ISOCdonations,andIETFattendancefees,andthe |RFCEditorcontractisjustoneiteminthatbudget. | |Thisdoesn'tcontradictRan'sstatementofthehistoryinthe |least. | |WithreferencetoRan'snote[1],myrecollectionofnumerous |meetingsoftheISOCAdvisoryCounciloforganizationalmembersis |thatrepresentativesthereconsistentlystatedsupportofthe |"standardspillar"astheirprimarymotivationforsupportingISOC. |Ofcoursetheyknewthathistoricallythebulkofthemoneyinthat |pillarwasgoingtosupporttheRFCpublicationprocess,priorto |thecreationofIASA. | | --- --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- FranckMartin franck@sopac.org "Touteconnaissanceestuneréponseàunequestion" G.Bachelard -BEGINPGPSIGNATURE- Version:GnuPGv1.4.2(GNU/Linux) Comment:UsingGnuPGwithMandriva-http://enigmail.mozdev.org iD8DBQFEhCTlvnmeYIHZEyARAtTBAJwLUb5A7+mdSjDPGxaVY/9LGSDMlACeIYxh MWceB9CzA8a/Wr6V7oZZSfM= =vYIH -ENDPGPSIGNATURE- ___ Ietfmailinglist Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietfmailinglist Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Re: IETF, IAB, RFC-Editor
nevermind. figured it out.PhilMaceri10247BarlowCrossingPerrysburg,OH43551Cell:248-250-1194Home:586-435-9542 Date: Mon, 5 Jun 2006 15:35:41 +0200 To: franck@sopac.org; [EMAIL PROTECTED] From: [EMAIL PROTECTED] CC: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: IETF, IAB, RFC-Editor DearFranck, thereferenceisnotISOCnortheIETF.Thereferenceistheuser. Hence,thenetworkingsolutionpeoplemayuseonthedigital ecosystemtheybuiltandownincommon.Thedifficultyistoevaluate frompastandpresentIETF/ISOCcontributionstheirfutureconsand pros;andthemethodsfortheirprostokeepbeingefficientand theirconstobecorrected.Thisconcernsthetimeproven/dusted approachoftheir"affinitygroup"(RFC3774)-amongthebillions mentionnedbyBrian.Cantheystilldeliver?Noteasyasthosewho think"no",orareconfused(theusers?)arenotavailablefor comment,orPR-actionned. Somequestionsare: -whataretheusers'needswhicharesolved,andnotsolved? -whywastheIETFgoodassolvingthem,pooratnotsolvingthem? -whatshouldbetheresultingarchitectureweshouldsupportandhow shouldwesupportit? -istheIETF/IAB/IESG/IASA/ISOCadaptedtoproducethedeliverables thisarchitecturerequires? -whataboutusers'QA? PleaserereadRFC3774,3935,3968.Thiskindofself-analysisis impressive.Itshouldhelp.Theyalltellwhatistobecorrected. StartingwiththemissionandpurposeoftheIETF.Itisnottomake theInternetworkbetterininfluencingpeople(wherelegitimacy, capacityandcompetencewouldcomefrom?).Butitistotellpeople howtheycanbetterbuild,manageandinteropatetheirownsystem. jfcAt14:3405/06/2006,FranckMartinwrote: -BEGINPGPSIGNEDMESSAGE- Hash:SHA1 All, IsupposeyouareawareofthenextISOCboardmeetinginMarrakeshis onthe1/2July2006(www.isoc.org) WhileIhavekeptaneyeontheIETFlistforqitesometime,Istill considermyselfanewbieintherelationshipISOC/IETF.I'mtryingto betterunderstanditespeciallywiththisreformprocess,soanypoint ofviewisinterestingforme. IalsofindtheIETFisdoingagreatjobbutnotsurehowtobest helpit. IETFis20yearsold,Ialsohopetolearnmoreduringaworkshopat www.egeni.orgonthehistoricroleofIETF(22June2006,Paris). Cheers BrianECarpenterwrote: |Ran, | |RJAtkinsonwrote: | |Previously,someonewrote: | |IfinishedreadingtheRFCeditordocumentandhaveonemajor |concern. | |Ultimately,therfc-editorfunctionneedstobeaccountableto |theIETFcommunitybecausewe'retheonespayingforit. | | | |Incorrect.AsIpointedoutsomeweeksago,andLesliehas |recentlyrepeated,IETFhasneverpaidfortheRFC-Editor. | |Historically,RFC-Editorwascreatedby(D)ARPAandpaidby |(D)ARPA.Morerecently,somelargecommercialfirmshavedonated |substantialfundstoISOC--withtheunderstandingthatthe |RFC-Editorwouldbeamongthefunctionspaidforfromthose |funds.[1] | | |Iwouldliketosuggestaqualificationtothis.Thingshave |changedovertime.WhenDARPAstoppedfundingISItoperformthe |RFCEditorfunction,ISOCsteppedintofillthegap.Subsequently, |ISOCalsoprovidedadiscretionaryfundfortheIETFChair,and |extendeditsliabilityinsurancetocovertheIETFleadership.(At |somepoint,thediscretionaryfundwassplitbetweentheIETFChair |andtheIABChair.)In2000/2001,ISOCconsolidatedthese |expendituresinits"standardspillar"accounting.Subsequently, |andmostrecently,ISOCagreedtohostIASA,whichisnowthe |fundingagencyforalloftheaboveplusmeetingexpensesandthe |Secretariat.Sowhateverthehistoricalsituation,the*current* |situationisthatasinglebudgetisfedbyISOCmember |contributions,ISOCdonations,andIETFattendancefees,andthe |RFCEditorcontractisjustoneiteminthatbudget. | |Thisdoesn'tcontradictRan'sstatementofthehistoryinthe |least. | |WithreferencetoRan'snote[1],myrecollectionofnumerous |meetingsoftheISOCAdvisoryCounciloforganizationalmembersis |thatrepresentativesthereconsistentlystatedsupportofthe |"standardspillar"astheirprimarymotivationforsupportingISOC. |Ofcoursetheyknewthathistoricallythebulkofthemoneyinthat |pillarwasgoingtosupporttheRFCpublicationprocess,priorto |thecreationofIASA. | | --- --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- FranckMartin franck@sopac.org "Touteconnaissanceestuneréponseàunequestion" G.Bachelard -BEGINPGPSIGNATURE- Version:GnuPGv1.4.2(GNU/Linux) Comment:UsingGnuPGwithMandriva-http://enigmail.mozdev.org iD8DBQFEhCTlvnmeYIHZEyARAtTBAJwLUb5A7+mdSjDPGxaVY/9LGSDMlACeIYxh MWceB9CzA8a/Wr6V7oZZSfM= =vYIH -ENDPGPSIGNATURE- ___ Ietfmailinglist Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietfmailinglist Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
Russ Housley wrote: Sam: If the people with copyright interest are the combination of the authors plus the contributors, then we need to specify this in a BCP. Does the RFC Editor have to contact the members of both lists during Auth48? If so, I would suggest that the RFf Editor only needs a positive reply from the authors, but that the contributors only need to respond if they discover a change that is needed. In looking over the various sub-threads on this topic, it is feeling an awful lot like the discussion is trying to attend to legal issues, without benefit of legal counsel. (I know that a number of the participants in the thread have been dealing with this topic, for a long time, including contact with legal counsel. My point is that the current discussion either ought to include direct contribution by an intellectual property attorney or we should largely drop the issue.) Wouldn't it make more sense for the rules concerning author list to be dictated by the combination of the needs to state primary resonsibility, ie, those writing the docs, and logistics/processing needs of those publishing it? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
On Monday, June 05, 2006 09:16:18 AM -0700 Dave Crocker [EMAIL PROTECTED] wrote: Wouldn't it make more sense for the rules concerning author list to be dictated by the combination of the needs to state primary resonsibility, ie, those writing the docs, and logistics/processing needs of those publishing it? I certainly think it would. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Wasting address space (was: Re: Last Call: 'Considerations on the IPv6 Host density Metric' to Informational RFC (draft-huston-hd-metric))
On 3-jun-2006, at 5:33, Steven Blake wrote: I am concerned about the conclusion reached in this document (that HD ratios 0.8 and closer to 0.94 should be considered when making address allocations to larger providers). I believe that: (1) this would not solve a real problem, A little foresight never hurt anyone. If IPv4 space had been given out using today's policies from the start, that would have given us a decade or so more time with IPv4. (2) it is risky to infer too much from existing network design practice when considering future provider networks that may be much larger, and I agree. (3) there is a better solution to the alleged problem. 1. To begin, the following number of /48 site prefixes can be allocated out of 2000::/3, for various values of the HD ratio: You assume that all address space given out will actually be used to address customers. That's unlikely, especially as address blocks get larger: when the blocks get larger, both the likelihood of it all being used (for your favorite defintion of all) decreases, along with the likelihood of enough of it being used so that it can't be reclaimed. I think we're going to see this with IPv4 too. Today, some 10% of all allocations/assignments account for some 90% of the address space used, with block sizes in the million range. For instance, France Telecom got a /9 earlier this year. If they somehow fail to connect millions of customers in the forseeable future, a very big chunk of those 8 million+ addresses are going to be left sitting on a shelf where they can't be used by anyone else. [...] Of all the challenges that will have to be solved to realize such a large internet, IPv6 address exhaustion should be the least of our worries. I agree that we shouldn't impose stricter policies than necesssary, but allowing people to waste one address bit out of every five between their prefix length and /48 is completely unnecessary. You lose a maximum of one digit (bit in our universe) per aggregation level so 80% = lose 20% of your address bits means assuming a level of aggregation for every four address bits. In other words, creating an aggregate that covers 16 routes. That's fairly ridiculous. An aggregate per 1024 or _maybe_ 256 routes makes sense. That would be 91% or 86%. But I see no reason why people requesting a prefix shorter than, say, a /28, wouldn't be able to provide insight into their _actual_ internal address aggregation. And yes, we should limit the maximum block sizes people can get. The risks increase as blocks get larger while the benefit of having a single large block rather than several small ones decrease. At some point, it's not worth it anymore. Note that the number of possible providers cannot grow by more than an order of magnitude from today's number, for a variety of economic and logistical reasons (and some would argue that the number has already peaked). That's economics which is much, much harder to predict than technology, which we have a hard enough time with anyway. In a world with tens or hundreds of billions of subscriber sites, the largest providers may have more than a billion subscribers. Under one prefix? Yeah right. 3. /48 site allocations are massive overkill for residences and SOHOs. Assume 10e9 organizations (~1 per-person) needing four /48 allocations each (for multi-homing). Assume that the remaining hundreds of billions of residence/SOHO sites can function with /56 site allocations. 2000::/3 can accommodate these 40e9 /48s plus an additional 2.89e12 /56s with HD = 0.80 (with no tricks, such as the max /16 assignments suggested above). A /56 allocation is more or less equivalent to an IPv4 /16 allocation (256 Class C subnets). I will be delighted if my residential provider ever offers me a /60 IPv6 allocation. /56 is a very bad prefix size, as it's still way too large for SOHO use, and for people needing more it's both small enough to grow out of after some time, but big enough to be really inconvenient to reengineer into a /48. (Which is more than simply renumber.) Having to choose between /60 and /48 would be much better than having to choose between /64 and bigger in general, as it removes the will I ever need a second subnet consideration, the average allocation size goes down and moving to a /48 after having grown out of a /60 isn't too painful. Being unnecessarily conservative with address allocations to providers will only increase the chance that they will be unnecessarily conservative with address allocations to subscribers. It's also really helpful if all ISPs use the same subnet sizes. For instance, I can set up my routes as DHCPv6 prefix delegation clients, so they can be reconfigured with new address prefixes automatically when changing ISPs, but I still need to put the subnet bits (and therefore the subnet size) in the configuration by
Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12
Hi. I notice that draft-dusseault-caldav-12 now is in IESG Evaluation (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=11253). For the record: as far as I can tell, the issue that I raised below is critical (given the fact that we have a separate activity to clarify this in HTTP), and has not been addressed. It's not clear to me whether the client issue it attempts to solve really is important. If it is, there is a simpler way to accomplish this ([1]) that doesn't risk making CalDAV incompatible with other specs extending HTTP (or HTTP itself, for that matter). Best regards, Julian [1] http://lists.osafoundation.org/pipermail/ietf-caldav/2006-April/000787.html Julian Reschke wrote: Lisa Dusseault wrote: Thanks for the input. Speaking as a document author here, I'm confident we've made a decent set of tradeoffs, balancing possible risks against benefits, and attempting to minimize the risks too. The basic risk is that any requirements related to ETags may conflict with future requirements. We've attempted to minimize this risk by making only one requirement -- that servers MUST NOT return strong ETags if they have changed the data provided to be stored. We believe that this requirement is quite within the spirit of ETag design. We didn't make any requirements about weak ETags, nor did we require any behavior that future specs might make illegal. Since today with HTTP it's perfectly acceptable not to return an ETag at all, future requirements on ETags would at least have to work with a huge deployed base of HTTP servers that don't return any ETag on PUT responses. Thus, any future ETag-related requirements that invalidated this CalDAV requirement, would also conflict with the huge deployed base of HTTP. I How so? A potential requirement of an XyzDav spec to return ETags even though the content was rewritten wouldn't be in conflict with HTTP at all. It would just be impossible to implement a resource that's both compliant to CalDAV and XyzDav. This is why I think CalDav uses the wrong approach. There's a simple way to give CalDav clients that piece of information and which is guaranteed to be compatible with other specs, and that's what CalDav should do. Or, alternatively, it could just stay silent and let that other spec work out the solution, instead of trying to come up with a fait accompli. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Wasting address space (was: Re: Last Call: 'Considerations on the IPv6 Host density Metric' to Informational RFC (draft-huston-hd-metric))
On Mon, Jun 05, 2006 at 08:12:28PM +0200, Iljitsch van Beijnum wrote: On 3-jun-2006, at 5:33, Steven Blake wrote: I am concerned about the conclusion reached in this document (that HD ratios 0.8 and closer to 0.94 should be considered when making address allocations to larger providers). I believe that: (1) this would not solve a real problem, A little foresight never hurt anyone. If IPv4 space had been given out using today's policies from the start, that would have given us a decade or so more time with IPv4. one should remember that when IP blocks were first handed out, there was the expectation that there would be very few networks with 10s or 100s of thousands of hosts (pre A/B/C/D split) which is a shadowy reflection of todays IPv6 aggreagates to Tier1 model... kind of spooky eh? modern delegation policy follows the CIDR construct, which strives to only delegated the amount of space that will actually be used... if this were more strict, then the RIRs would have significantly larger free pool from which to make delegations... but it would wreck havoc on the iten of a single, global routing system.. granted, these are gross generalizations, but the trends are there. --bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12
Hi Julian, --On June 5, 2006 8:30:25 PM +0200 Julian Reschke [EMAIL PROTECTED] wrote: I notice that draft-dusseault-caldav-12 now is in IESG Evaluation (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag =11253). For the record: as far as I can tell, the issue that I raised below is critical (given the fact that we have a separate activity to clarify this in HTTP), and has not been addressed. It's not clear to me whether the client issue it attempts to solve really is important. If it is, there is a simpler way to accomplish this ([1]) that doesn't risk making CalDAV incompatible with other specs extending HTTP (or HTTP itself, for that matter). We are planning on addressing this ETag issue in a revision now that last-call is over. Authors are discussing right now. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Best practice for data encoding?
I was wondering: What is considered best practice for encoding data in protocols within the IETF's purview? Traditionally, many protocols use text but obviously this doesn't really work for protocols that carry a lot of data, because text lacks structure so it's hard to parse. XML and the like are text- based and structured, but take huge amounts of code and processing time to parse (especially on embedded CPUs that lack the more advanced branch prediction available in the fastest desktop and server CPUs). Then there is the ASN.1 route, but as we can see with SNMP, this also requires lots of code and is very (security) bug prone. Many protocols use hand crafted binary formats, which has the advantage that the format can be tailored to the application but it requires custom code for every protocol and it's hard to get right, especially the simplicity/extendability tradeoff. The ideal way to encode data would be a standard that requires relatively little code to implement, makes for small files/packets that are fast to process but remains reasonably extensible. So, any thoughts? Binary XML, maybe? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
On Jun 05 2006, at 23:43 , Iljitsch van Beijnum wrote: What is considered best practice for encoding data in protocols within the IETF's purview? The best practice is to choose an encoding that is appropriate for the protocol being designed. (There is no single answer.) Maybe you can be more specific in your question, then maybe people can be more specific in their answers? Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
Hi - From: Iljitsch van Beijnum [EMAIL PROTECTED] To: IETF Discussion ietf@ietf.org Sent: Monday, June 05, 2006 2:43 PM Subject: Best practice for data encoding? ... Then there is the ASN.1 route, but as we can see with SNMP, this also requires lots of code and is very (security) bug prone. ... Having worked on SNMP toolkits for a long time, I'd have to strenuously disagree. In my experience, the ASN.1/BER-related code is a rather small portion of an SNMP protocol engine. The code related to the SNMP protocol's quirks, such as Get-Next/Bulk processing and the mangling of index values into object identifiers (which is far removed from how ASN.1 intended object identifiers to be used) require much more code and complexity. I'm curious, too, about the claim that this has resulted in security problems. Could someone elaborate? Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
On Mon, 5 Jun 2006 16:06:28 -0700, Randy Presuhn [EMAIL PROTECTED] wrote: Hi - From: Iljitsch van Beijnum [EMAIL PROTECTED] To: IETF Discussion ietf@ietf.org Sent: Monday, June 05, 2006 2:43 PM Subject: Best practice for data encoding? ... Then there is the ASN.1 route, but as we can see with SNMP, this also requires lots of code and is very (security) bug prone. ... Having worked on SNMP toolkits for a long time, I'd have to strenuously disagree. In my experience, the ASN.1/BER-related code is a rather small portion of an SNMP protocol engine. The code related to the SNMP protocol's quirks, such as Get-Next/Bulk processing and the mangling of index values into object identifiers (which is far removed from how ASN.1 intended object identifiers to be used) require much more code and complexity. Yah -- measure first, then optimize. I'm curious, too, about the claim that this has resulted in security problems. Could someone elaborate? See http://www.cert.org/advisories/CA-2002-03.html --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
Hi - From: Steven M. Bellovin [EMAIL PROTECTED] To: Randy Presuhn [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Monday, June 05, 2006 4:09 PM Subject: Re: Best practice for data encoding? ... I'm curious, too, about the claim that this has resulted in security problems. Could someone elaborate? See http://www.cert.org/advisories/CA-2002-03.html ... I remember that exercise. I don't see it as convincing evidence that the use of ASN.1 was the cause of the problems some implementations had; I doubt that someone who had buffer overflow problems when processing a BER-encoded octet string (where the length is explicitly encoded) would have had any better results with XML or any other representation. Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Best practice for data encoding?
Hi The security problems identified in http://www.cert.org/advisories/CA-2002-03.html Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP) are not caused by the protocol choice to use ASN.1, but by vendors incorrectly implementing the protocol (which was made worse by vendors using toolkits that had the problems). If Multiple Vulnerabilities in Implementations were used to condemn the encoding methods of protocols that have been incorrectly implemented, then we would have to condemn an awful lot of IETF protocols as being very (security) bug prone: CERT Advisory CA-2003-26 Multiple Vulnerabilities in SSL/TLS Implementations US-CERT Vulnerability Note VU#459371 Multiple IPsec implementations do not adequately validate CERTR Advisory CA-2001-18 Multiple Vulnerabilities in Several Implementations of the Lightweight Directory Access Protocol (LDAP) CERT Advisory CA-2002-36 Multiple Vulnerabilities in SSH Implementations CERTR Advisory CA-2003-06 Multiple vulnerabilities in implementations of the Session Initiation Protocol (SIP) Vulnerability Note VU#428230 Multiple vulnerabilities in S/MIME implementations Vulnerability Note VU#955777 Multiple vulnerabilities in DNS implementations Vulnerability Note VU#226364 Multiple vulnerabilities in Internet Key Exchange (IKE) version 1 implementations CERTR Advisory CA-2002-06 Vulnerabilities in Various Implementations of the RADIUS Protocol CERTR Advisory CA-2000-06 Multiple Buffer Overflows in Kerberos Authenticated Services Vulnerability Note VU#836088 Multiple vendors' email content/virus scanners do not adequately check message/partial MIME entities David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 7:10 PM To: Randy Presuhn Cc: ietf@ietf.org Subject: Re: Best practice for data encoding? On Mon, 5 Jun 2006 16:06:28 -0700, Randy Presuhn [EMAIL PROTECTED] wrote: Hi - From: Iljitsch van Beijnum [EMAIL PROTECTED] To: IETF Discussion ietf@ietf.org Sent: Monday, June 05, 2006 2:43 PM Subject: Best practice for data encoding? ... Then there is the ASN.1 route, but as we can see with SNMP, this also requires lots of code and is very (security) bug prone. ... Having worked on SNMP toolkits for a long time, I'd have to strenuously disagree. In my experience, the ASN.1/BER-related code is a rather small portion of an SNMP protocol engine. The code related to the SNMP protocol's quirks, such as Get-Next/Bulk processing and the mangling of index values into object identifiers (which is far removed from how ASN.1 intended object identifiers to be used) require much more code and complexity. Yah -- measure first, then optimize. I'm curious, too, about the claim that this has resulted in security problems. Could someone elaborate? See http://www.cert.org/advisories/CA-2002-03.html --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
On Mon, 5 Jun 2006 20:07:24 -0400, David Harrington [EMAIL PROTECTED] wrote: Hi The security problems identified in http://www.cert.org/advisories/CA-2002-03.html Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP) are not caused by the protocol choice to use ASN.1, but by vendors incorrectly implementing the protocol (which was made worse by vendors using toolkits that had the problems). If Multiple Vulnerabilities in Implementations were used to condemn the encoding methods of protocols that have been incorrectly implemented, then we would have to condemn an awful lot of IETF protocols as being very (security) bug prone: Works for me More precisely -- when something is sufficiently complex, it's inherently bug-prone. That is indeed a good reason to push back on a design. The question to ask is whether the *problem* is inherently complex -- when the complexity of the solution significanlty exceeds the inherent complexity of the problem, you've probably made a mistake. When the problem itself is sufficiently complex, it's fair to ask if it should be solved. Remember point (3) of RFC 1925. I'll note that a number of the protocols you cite were indeed criticized *during the design process* as too complex. The objectors were overruled. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Best practice for data encoding?
I agree that complexity breeds bug-prone implementations. I wasn't around then; did anybody push back on SNMPv1 as being too complex? http://www.cert.org/advisories/CA-2002-03.html is mainly about SNMPv1 implementations. ;-) dbh -Original Message- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 8:21 PM To: David Harrington Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: Best practice for data encoding? On Mon, 5 Jun 2006 20:07:24 -0400, David Harrington [EMAIL PROTECTED] wrote: Hi The security problems identified in http://www.cert.org/advisories/CA-2002-03.html Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP) are not caused by the protocol choice to use ASN.1, but by vendors incorrectly implementing the protocol (which was made worse by vendors using toolkits that had the problems). If Multiple Vulnerabilities in Implementations were used to condemn the encoding methods of protocols that have been incorrectly implemented, then we would have to condemn an awful lot of IETF protocols as being very (security) bug prone: Works for me More precisely -- when something is sufficiently complex, it's inherently bug-prone. That is indeed a good reason to push back on a design. The question to ask is whether the *problem* is inherently complex -- when the complexity of the solution significanlty exceeds the inherent complexity of the problem, you've probably made a mistake. When the problem itself is sufficiently complex, it's fair to ask if it should be solved. Remember point (3) of RFC 1925. I'll note that a number of the protocols you cite were indeed criticized *during the design process* as too complex. The objectors were overruled. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Best practice for data encoding?
Let's not forget that the S in SNMP stands for simple. Simple is a relative term. In this case, SNMP is simple when compared to CMIP. -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 5:33 PM I agree that complexity breeds bug-prone implementations. I wasn't around then; did anybody push back on SNMPv1 as being too complex? http://www.cert.org/advisories/CA-2002-03.html is mainly about SNMPv1 implementations. ;-) dbh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Best practice for data encoding?
On Monday, June 05, 2006 08:32:58 PM -0400 David Harrington [EMAIL PROTECTED] wrote: I agree that complexity breeds bug-prone implementations. I wasn't around then; did anybody push back on SNMPv1 as being too complex? I don't think anyone pushed back on SNMPv1 as being inherently insecure. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
David Harrington wrote: I agree that complexity breeds bug-prone implementations. I wasn't around then; did anybody push back on SNMPv1 as being too complex? http://www.cert.org/advisories/CA-2002-03.html is mainly about SNMPv1 implementations. ;-) I wasn't there to push back, but when I got asked to implement it back then the Simple part such seemed like something between a fib and the Big Lie. Did we really need ASN.1 to define a debug peek/poke-like protocol? Mike dbh -Original Message- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 8:21 PM To: David Harrington Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: Best practice for data encoding? On Mon, 5 Jun 2006 20:07:24 -0400, David Harrington [EMAIL PROTECTED] wrote: Hi The security problems identified in http://www.cert.org/advisories/CA-2002-03.html Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP) are not caused by the protocol choice to use ASN.1, but by vendors incorrectly implementing the protocol (which was made worse by vendors using toolkits that had the problems). If Multiple Vulnerabilities in Implementations were used to condemn the encoding methods of protocols that have been incorrectly implemented, then we would have to condemn an awful lot of IETF protocols as being very (security) bug prone: Works for me More precisely -- when something is sufficiently complex, it's inherently bug-prone. That is indeed a good reason to push back on a design. The question to ask is whether the *problem* is inherently complex -- when the complexity of the solution significanlty exceeds the inherent complexity of the problem, you've probably made a mistake. When the problem itself is sufficiently complex, it's fair to ask if it should be solved. Remember point (3) of RFC 1925. I'll note that a number of the protocols you cite were indeed criticized *during the design process* as too complex. The objectors were overruled. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Best practice for data encoding?
Steven, I'm not sure what you mean by saying that a problem that is highly complex should not be solved (or, at least, that we should consider not solving it). That seems like a cop-out. Minimally, every problem we've ever faced, we've tried to solve (where we refers to us weak-kneed Homo Sapiens) - no matter how hard it was to do so - and I like to think that is the right thing to do. In fairness, I am reasonably sure that point 3 in RFC 1925 refers to making a complex solution work, even if a simpler answer might be found, simply because enough people want that solution. It does not - IMO - rule out solving complex problems using as simple a solution as possible, however complex that might be. -- Eric -- -Original Message- -- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] -- Sent: Monday, June 05, 2006 8:21 PM -- To: David Harrington -- Cc: ietf@ietf.org -- Subject: Re: Best practice for data encoding? -- -- On Mon, 5 Jun 2006 20:07:24 -0400, David Harrington -- [EMAIL PROTECTED] wrote: -- -- Hi -- -- The security problems identified in -- http://www.cert.org/advisories/CA-2002-03.html Multiple -- Vulnerabilities in Many Implementations of the Simple Network -- Management Protocol (SNMP) are not caused by the -- protocol choice to -- use ASN.1, but by vendors incorrectly implementing the -- protocol (which -- was made worse by vendors using toolkits that had the problems). -- -- If Multiple Vulnerabilities in Implementations were -- used to condemn -- the encoding methods of protocols that have been incorrectly -- implemented, then we would have to condemn an awful lot of IETF -- protocols as being very (security) bug prone: -- -- -- Works for me -- -- More precisely -- when something is sufficiently complex, -- it's inherently -- bug-prone. That is indeed a good reason to push back on a -- design. The -- question to ask is whether the *problem* is inherently -- complex -- when the -- complexity of the solution significanlty exceeds the -- inherent complexity of -- the problem, you've probably made a mistake. When the -- problem itself is -- sufficiently complex, it's fair to ask if it should be -- solved. Remember -- point (3) of RFC 1925. -- -- I'll note that a number of the protocols you cite were -- indeed criticized -- *during the design process* as too complex. The objectors -- were overruled. -- -- --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
Hi - From: Fleischman, Eric [EMAIL PROTECTED] To: David Harrington [EMAIL PROTECTED]; Steven M. Bellovin [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Monday, June 05, 2006 5:41 PM Subject: RE: Best practice for data encoding? Let's not forget that the S in SNMP stands for simple. Simple is a relative term. In this case, SNMP is simple when compared to CMIP We implemented both protocols. The core protocol engine for SNMP ended up being larger and more complex than that for CMIP. The complexity of GetNext, along with OID mangling, accounted for much of the difference. The S in SNMP was half marketing and half politics, and had very little to do with actual implementation or use. Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Questions about draft-lear-iana-no-more-well-known-ports-00.txt
Eliot Lear wrote: Jeff, Disclaimer - I wasn't even aware of this document before reading this thread. However, I have now read it, so feel prepared to comment. As it only just came out, you haven't missed much of a debate. (1) The IANA is a group of adults, but it is no longer a group of protocol subject matter experts. IMHO there is probably no need for IESG oversight of port number allocation, especially if we are eliminating the (artificial) scarcity of so-called well-known ports. The point of the document is NOT really to deal with scarcity but to deal with an outdated process, and to attempt to encourage use of SRV records where appropriate, and to have some documentation for the port use. ... SRV records are not equivalent to either assigned or mutually-negotiated ports; they would require extra messages, extra round-trip times, and/or extra services (DNS) beyond what is currently required. There are other ways to reduce the limits of the current port space, as well as to reduce the dual-registration of service names (which are unique) and port numbers. See: draft-touch-tcp-portnames-00.txt (FYI there is a pending update that includes more detail on the difference between this and Tim Shepard's dynamic port reassignment proposal from 2004) Further discussion on this has already ensued on the TCPM WG mailing list, whose archives may be a useful resource as well. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
On Mon, 5 Jun 2006 20:59:32 -0400 , Gray, Eric [EMAIL PROTECTED] wrote: Steven, I'm not sure what you mean by saying that a problem that is highly complex should not be solved (or, at least, that we should consider not solving it). That seems like a cop-out. Minimally, every problem we've ever faced, we've tried to solve (where we refers to us weak-kneed Homo Sapiens) - no matter how hard it was to do so - and I like to think that is the right thing to do. In fairness, I am reasonably sure that point 3 in RFC 1925 refers to making a complex solution work, even if a simpler answer might be found, simply because enough people want that solution. It does not - IMO - rule out solving complex problems using as simple a solution as possible, however complex that might be. I meant exactly what I said. The reason to avoid certain solutions is that you'll then behave as if the problem is really solved, with bad consequences if you're wrong -- and for some problems, you probably are wrong. Read David Parnas' Software Aspects of Strategic Defense Systems (available at http://klabs.org/richcontent/software_content/papers/parnas_acm_85.pdf); also consider the historical record on why the US and the USSR signed a treaty banning most anti-missile systems, and in particular why the existence of such systems made the existing nuclear deterrent standoff unstable. Note carefully that I didn't say we shouldn't do research on how to solve things. But doing research and declaring that we know how to do something are two very different things. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Provisioning, Autodiscovery, and Signaling in L2VPNs' to Proposed Standard
The IESG has approved the following document: - 'Provisioning, Autodiscovery, and Signaling in L2VPNs ' draft-ietf-l2vpn-signaling-08.txt as a Proposed Standard This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt Technical Summary There are a number of different kinds of Provider Provisioned Layer 2 VPNs (L2VPNs). The different kinds of L2VPN may have different provisioning models, i.e., different models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a discovery process. When the discovery process is complete, a signaling protocol is automatically invoked. The signaling protocol sets up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any PW signaling protocol needs to have a method which allows each PW endpoint to identify the other; thus a PW signaling protocol will have the notion of an endpoint identifier. The semantics of the endpoint identifiers which the signaling protocol uses for a particular type of L2VPN are determined by the provisioning model. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each provisioning model. It discusses the way in which the endpoint identifiers are distributed by the discovery process, especially when the discovery process is based upon the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). Working Group Summary After WG Last Call, Luca Martini had raised an issue with respect to whether or not there needed to be coordination of AII Types between the l2vpn-signaling draft and the emergent MS-PW work. Luca proposed a solution to this dilemma on the L2VPN WG list: http://www.ietf.org/mail-archive/web/l2vpn/current/msg01121.html A discussion ensued between Bruce, Luca, Chris Metz, Florin, Mustapha, Vach Shane to resolve it. In summary, we have all agreed that l2vpn-signaling is its own application and its use of Type-1 AII's is sufficient for it. In fact, procedures developed in l2vpn-signaling already account for PW routing/stitching signaling as it relates to D-VPLS, (with Type-1 AII's), but do not give one the granularity of routing that MS-PW is aiming for. Another key difference is that l2vpn-signaling is focused on auto-discovery mechanisms for groups of PW's (e.g.: L2VPN's), whereas MS-PW is focused on both routing and signaling invidual PW's (not groups of PW's). In fact, it's not clear that MS-PW will initially be designed to support routing+signaling of groups of PW's, (which is another thing that distinguishes it from l2vpn-signaling). Protocol Quality The protocol is being implemented by at least two vendors. RFC Editor Note: Please add a normative reference for RFC 2119 and a citation to it at the end of section 1. Please replace: 3.3.2.1. BGP-based auto-discovery A framework for BGP-based auto-discovery for a generic L2VPN service is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this section we specify how BGP-based auto-discovery can be used to build VPWS instances. With: 3.3.2.1. BGP-based auto-discovery In this section we specify how BGP can be used to discover the information necessary to build VPWS instances. And replace: A framework for BGP-based auto-discovery for a generic L2VPN service is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this section we specify how BGP-based auto-discovery can be used to build VPLS instances. With: In this section we specify how BGP can be used to discover the information necessary to build a VPLS instance. Also, please remove the bibliographic reference to [I-D.ietf-l3vpn-bgpvpn-auto] in its entirety. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Matching of Language Tags' to Proposed Standard (draft-ietf-ltru-matching)
The IESG has received a request from the Language Tag Registry Update WG to consider the following document: - 'Matching of Language Tags ' draft-ietf-ltru-matching-14.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-14.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
