Re: Consensus Call: draft-weil-shared-transition-space-request
On October 10, 2011, the IESG issued a last call for comments regarding draft-weil-shared-transition-space-request-09 (IANA Reserved IPv4 Prefix for Shared CGN Space). While the community did not display consensus supporting the draft, it also did not display consensus against the draft. Therefore, I will submit the draft to the full IESG for its consideration at its December 1 teleconference. The draft will be published as a BCP if a sufficient number of IESG members ballot Yes or No Objection, and if no IESG member ballots Discuss. If I recall correctly from my days on the IESG, a sufficient number of IESG members with a Yes for document advancement is exactly one. Often, that is the AD bringing the document forward to the IESG. The shepherding AD is saying, Yes I have read this document, seen a sufficient level of support in the IETF for it, etc. Sometimes, other ADs jump on board with their own Yes, but it's not required. Ron, if I read this email from you correctly, you are saying that you have not seen that level of consensus yourself, yet you are bringing the document forward to the IESG to weigh advancement anyway. The process is flexible enough to allow that and I'm not questioning this action alone, but I do think it would be a good idea for you to not put in your own Yes for the document in this case. This raises the bar ever so slightly for advancement, forcing the IESG deliberations to convince at least one AD to stand behind what is being done with a Yes vs. a No Objection. - Mark Because the decision to submit this draft to the full IESG is controversial, I will explain the decision making process. The IETF has a precedent for interpreting silence as consent. Typically, if a last call elicits no response, the draft is brought to the full IESG for consideration. The October 10 last call regarding draft-weil-shared-transition-space-request-09 evoked only two responses. One response supported publication of the draft while the other was opposed to it. The respondent voicing support for the draft offered no rationale. The respondent objecting offered many editorial comments, but almost no rationale for blocking the draft once the editorial comments are addressed. Because the October 10 last call elicited so little response, and because many community members have privately expressed strong opinions regarding this draft, I will summarize outstanding issues below. The following are arguments *against* draft-weil-shared-transition-space-request: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. - If a special-use /10 is allocated, it will encourage others to request still more special-use address space. - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Arguments *supporting* draft-weil-shared-transition-space-request-09 assume that operators will deploy CGNs and will number the interfaces between CGN and CPE. If the /10 proposed by draft-weil-shared-transition-space-request is not allocated, operators will number from one of the following: - public address space - RFC 1918 address space - squat space If operators number from public address space, they will deplete an already scarce resource. If operators number from RFC 1918 space and the same RFC 1918 space is used on the customer premise, some CPE will behave badly. The consequences of numbering from squat space are determined by the squat space that is chosen. In summary, allocation of the /10 will have certain adverse effects upon the community. However, failure to allocate the /10 will have different adverse effects on the community. The IESG is being asked to choose the lesser of two evils. -- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Nov 29, 2011, at 9:13 PM, Chris Donley wrote: Ron, One point of clarification, in your *against* list, you include: On 11/28/11 2:25 PM, Ronald Bonica rbon...@juniper.net wrote: - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Since this address space is between the CPE router and CGN device, and is therefore not globally routable, the same application(s) (e.g. 6to4) will break if public or 'squat' space are used instead of shared CGN space. Such applications rely on the home router detecting that there is private, non-globally routable space (i.e. RFC1918) on the WAN and disabling such an application. While that same detection code will always fail for public address space and squat space since the exact range is not defined, there is the possibility of fixing the detection code in home routers if we do define shared CGN space for that purpose. http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03 has this requirement: DLW-4: If the IPv6 CE Router is configured with a public IPv4 address on its WAN interface, where public IPv4 address is defined as any address which is not in the private IP address space specified in [RFC5735], then the IPv6 CE Router SHOULD disable the DS-Lite B4 element. I'm not sure I personally agree with this requirement, but suffice to say if this kind of language is popping up in our own v6ops documents at this very moment, there is a decent chance that it has made its way into specifications and code elsewhere. - Mark Chris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Softwires] [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
On Sep 28, 2011, at 8:12 PM, Cameron Byrne wrote: On Wed, Sep 28, 2011 at 9:26 AM, Mark Townsley m...@townsley.net wrote: +1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark We're still doing that, and IPv6-only is still my philosophical preference and that is how we are launching the IPv6 + NAT64/DNS64 service into the production mobile network (real soon now). No change in that path. But some power users wanted their IPv4-only applications like Skype to work so they coded a NAT46 work-around for the N900. It is clever, it works. Ah, so it's not a model developed and (necessarily) supported by you. Thanks for the clarification. Yes, it makes sense that this would end up happening as the hosts evolve to what the network provides. - Mark Their process of feeling the pain of a very few pesky IPv4-only apps and working around it is all documented here: http://talk.maemo.org/showthread.php?t=60320 Running NAT46 code here: http://code.google.com/p/n900ipv6/wiki/Nat64D In the end (as well as IPv6-only near term in mobile), IP version agnostic apps will prove to be more reliable and therefore will get more market share. Cameron ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Softwires] [BEHAVE] Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
+1 ... since the alternative is that apps that require ipv4 sockets and pass ipv4 literals are stranded on ipv6 only networks. Running code on the n900 shows that nat464 provides real user and network benefit Frankly, I preferred it when you were running IPv6-only without BIH on your trial, providing pressure to get rid of all those stranded literals and pushing apps to open ipv6 sockets :-/ - Mark ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. +1 - Mark ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On Jun 30, 2011, at 5:46 PM, Keith Moore wrote: On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible I'd like for this group to relax the wherever possible bit, so as to not preclude solutions where IPv6 can do a better job than IPv4. Yes, and I think that IPv6 should naturally do a better job than IPv4 in the cases where it can. My original mail had this restatement of the above, which I think gets closer to what you want: However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. - Mark IPv4 is a dinosaur gasping for its last breaths. Keith ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On Jun 30, 2011, at 6:36 PM, Keith Moore wrote: On Jun 30, 2011, at 12:33 PM, Mark Townsley wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible I'd like for this group to relax the wherever possible bit, so as to not preclude solutions where IPv6 can do a better job than IPv4. Yes, and I think that IPv6 should naturally do a better job than IPv4 in the cases where it can. My original mail had this restatement of the above, which I think gets closer to what you want: However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. when the group can define something that is useful in IPv6, it shouldn't matter whether it's also useful for IPv4. The idea is not to go out of our way for IPv4, but if the topic is IP agnostic anyway, so be it. To be clear, there is no *requirement* to support IPv4 here. However, there is no requirement to avoid IPv4 *if* it doesn't cause significant concession in the IPv6 design either. This cuts both ways, if there is something that is working well in IPv4 that we need to carry over to IPv6 with simple extensions, we'll do that and capitalizing on that running-code should be considered a good thing. We don't want to invent new v6 protocols from scratch that don't work with IPv4 when there is no need. For example (and I think this is hinted at in the charter), we might use naming and service discovery that already exists for IPv4, adapted the the v6 homenet. This doesn't mean we need to re-invent a v6-only naming system from scratch - i'd much rather use one that is there, which very well may support v4 and v6. please don't constrain home networks to work only within the confines of IPv4 brain damage. What I think I am saying here is that we will do our best to perform as if our brains are not damaged, and equally try to avoid damaging our brains in the process. - Mark Keith ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus. However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. - Mark On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: On Thu, 30 Jun 2011, Fernando Gont wrote: My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6. I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On Jun 30, 2011, at 4:55 PM, Stephen [kiwin] PALM wrote: Thanks Mark for stating that. It would really be helpful if this type of text is included in the description/charter. The lack of of this information in the recently distributed material caused several immediate allergic reactions... I'm happy to include it in the next rev. - Mark regards, kiwin On 6/30/2011 2:57 AM, Mark Townsley wrote: I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will: - coexist with (existing) IPv4 protocols, devices, applications, etc. - operate in a (future) IPv6-only home network in the absence of IPv4 - be IP-agnostic whenever possible In other words, anything we do for the IPv6 homenet cannot actively break what's already running on IPv4. Also, trying to define what the IPv4 home network should be has long reached a point of diminishing returns given the effort in doing so coupled with our ability to significantly affect what's already deployed. There's still hope we can help direct IPv6, as such that is homenet's primary focus. However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so. - Mark On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote: On Thu, 30 Jun 2011, Fernando Gont wrote: My point was that, except for the mechanism for PD, I don't see a substantial difference here that would e.g. prevent this from being developed for IPv4 (in addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think you can expect people to get rid of their *working* IPv4 devices... (i.e., not sure why any of this functionality should be v6-only) Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of work to develop IPv4 further, that focus should be put on IPv6. I think this deserves a problem statement that clearly describes what we expect to be able to do (but currently can't), etc. And, if this is meant to be v6-only, state why v4 is excluded -- unless we're happy to have people connect their IPv4-devices, and see that they cannot communicate anymore. IPv4 should be excluded because it's a dead end, and we all know it. We're just disagreeing when it's going to die and how. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate -- Stephen [kiwin] Palm Ph.D. E: p...@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenp...@alumni.uci.edu p...@broadcom.com s.p...@ieee.org p...@itu.ch sp...@cs.cmu.edu p...@ics.t.u-tokyo.ac.jp ___ homegate mailing list homeg...@ietf.org https://www.ietf.org/mailman/listinfo/homegate ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [77all] No Host for IETF 77
On 3/23/10 2:08 PM, Jari Arkko wrote: I propose $40 for a seat at the table in the front of the meeting rooms, $20 for a seat toward the front with extra legroom and $100 for an exit row. Ability to escape seems most valuable ;-) Maybe we could also work out something based on premium Internet access ($29.90/day) vs. ability to read Internet drafts and other ietf.org content (free). Or, charge for IPv4 access and let IPv6 access be available for free. - Mark Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
Dave Cridland wrote: On Tue Nov 4 14:28:19 2008, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC I note that this document is Informational, yet forms the basis for standards track documents both in the IETF and other SDOs. Thank you for your review. Can you point me to any standards track IETF documents which might need normative reference to this document? - Mark It would be, therefore, more useful to tidy up this document and move it to the standards track rather than short-cutting it to an Informational. In the course of reviewing XEP-0174 changes for the XSF, I reviewed this document in detail, particularly on the subject of record formatting. The following are my own views, however, not those of the XSF. I believe the document is exceedingly unclear, and as such unsuitable for publication in its present form. It is badly laid out, and contains a mixture of specification, rationale, marketing, and confusing reiteration of other documents, making the document much harder to extract useful information from than it needs to be. I'm also unconvinced that this represents the state of the protocol as deployed by various Apple devices anyway. If this is to be a serious attempt to document a working protocol, it must reflect reality. Section by Section: 1) The last two paragraphs of the Introduction can largely be snipped. 2) Use of RFC 2119 language in an Informational document is a curious one - I'm not against its use, but in general terms, the document does not appear to use these terms in quite the way I'd expect. In particular, the terms appear to be used to express designer's preferences rather than actual interoperability requirements. 3) Seems okay. 4) Okay. 4.1) The parenthesis in the second paragraph is superfluous - one expects that any reader would surely understand DNS to this level. From about the top of page 6, however, it gets really bad. Only the top paragraph, diagram, and first two sentences of the subsequent paragraph are needed here. The rest of the page is waffle and repetition. Page 7 is mostly okay - it could probably be condensed. I'd question the purpose of Punycode here, though, if the records are already usefully deployed in UTF-8, since the records are only to be found by querying in the first place. Is this actually supported in the field? (As in, do clients try punycode?) 4.2) I'm always a little wary of UI detail in IETF documents, but the suggestions seem reasonable. 4.3) As near as I can tell, the backslah-escaping of DNS-SD instance names is done externally as well as internally, so this section is exceedingly misleading. 4.4) Appears to be largely marketing, or rationale, and is confusing in this section. 4.5) Appears to be largely rationale. 5) Reiterates SRV 6) Okay, although I don't understand the point of mandating an empty TXT record, it being about the only portion of the document not backed up by twenty-five pages of rationale including words like compelling. I'm guessing it might be to avoid negative caching, thus placing the statement This service has no parameters under the control of normal TTL, etc. That would, naturally, be a compelling reason. It's a shame that several TXT records for services are absent on dns-sd.org, then, but it's only a SHOULD - ho, ho. 6.1) Massively confusing, since it reiterates RFC 1035 in such a way that without referring to RFC 1035 to gain the context, one is led to believe that the actual strings must follow this format, instead of it merely being wire format. 6.2) All jolly good, although I note that several Apple devices appear to use a single TXT string containing a comma seperated list of values, that is, if you forgive my pseudo-ABNF: txt_value = txt_record txt_record = keypair [, keypair] Instead of the apparent specification: txt_value = / (1*txt_record) txt_record = keypair I wonder whether this is an earlier version of the specification, or a non-standard usage of a non-standard, or whether even Apple people can't glean the single useful fact from this entire page of prose. 6.3) Astonishingly, this section is reasonably concise, and contains information which is, dare I say it, useful. Thankfully it, too, appears to be ignored by various Apple devices. 6.4) This section could usefully be folded into 6.2, and the resultant prose condensed into perhaps a paragraph or two, and potentially use ABNF for clarity: keypair = key [= value] key = 1*key_char key_char = %x20-%x3C / %x3E-%x7E value = *OCTET 6.5) I seem to have inadvertantly included much of this in my ABNF above in 6 characters. The last two paragraphs seem superfluous - specifications for debugging tools? 6.6) Describes the wire format, which strikes me as very much less than useful. Again, I've seen
Re: [BEHAVE] Can we have on NAT66 discussion?
Eric Klein wrote: Mark, I agree with the sentiment, the problem is that the 5 different groups are doing different things that all relate back to NAT in v6 (rather than just coexistence) each under their own charter. I have had suggestions that I bring this to ietf or inter-area mailing lists for general consensus on a need and IETF overall position prior to defining a solution. Behave seems a little limited in scope for the decision about do we or don't we want to allow any form of native mode NAT into v6. I agree, and it is not behave's place to make that decision at this time. I had originally proposed that this be discussed in int-area (if nothing else because behave's plate is rather full), but some folks pointed out that some modes may have affects on applications and that behave was best able to determine that, particularly within context of the other NATxy work. I'm looking forward to that assessment. So for now this should remain discussion to understand the problem space and potential solution space better, not a final referendum on whether or not the IETF is going to charter work in or otherwise endorse NAT66 in any manner. Thanks, - Mark Eric On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I would prefer not to have the same discussion again and again in multiple places. Let's just try and stick to behave for the moment, though at some point if the work continues it would need to be passed around elsewhere. We are not chartering the work one way or another at the moment, for now this is merely discussion of the topic. - Mark Margaret Wasserman wrote: Hi Eric, According to the ADs and WG chairs, the correct forum for the NAT66 discussion is the BEHAVE WG. So, let's discuss it there. Margaret On Nov 12, 2008, at 9:44 AM, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Cross posted to several lists Can we keep the NAT66 discussion to less than WGs at a time? I am trying to keep up with multiple threads on this and trying to explain that we do not have a valid requirement for NAT66 defined on any of the mailing lists (v6OPS, BEHAVE, Softwires, RRG, and now v6). Le's get this to one group (maybe we need a new mailing list just for NAT66 discussions, but this is getting out of hand. Until now the simple response is that the IETF does not support NAT in the v6 architecture. If this needs changing lets do it right with proper gap analysis and needs assessment, and then seeing if there is a solution (several have been proposed that are not NAT) or if we need to create one, and if those fail then see about changing the architecture of IPv6. Eric ___ Behave mailing list [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Behave mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/behave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Last Call Review of draft-ietf-mipshop-cga-cba-02.txt
Christian Vogt wrote: Eric - For some reason, in your response, my bulletization of the list of the new status codes somehow got re-paragraphed - hopefully my version below does not suffer the same fate. Oh, no, this was probably one of my Thunderbird extensions for nicer quotations. It's now deinstalled. Anyway, your suggested bulletization is fine in your emails and I got your point. Typographical resets should be absolutely disallowed in E-Mail. :-) To the casual reader, it may otherwise be unclear exactly what change I was suggesting... Yes. Will incorporate your suggestions into the draft ASAP. Thanks! I moved the state to revised id needed for now, if you get the new draft in my 2/15 I should be able to get this on the 2/22 telechat. Thanks, - Mark - Christian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-l2tpext-failover-11.txt
Sorry for the spam folks, I responded to the wrong thread. Mark Townsley wrote... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-l2tpext-failover-11.txt
On second look, this is rather small. Vipin, I can do either. If you wish to provide me text in OLD NEW format, or a new document. - Mark Suresh Krishnan wrote: I am the assigned Gen-ART reviewer for draft-ietf-l2tpext-failover-11.txt For background on Gen-ART, please see the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html. Please resolve these comments along with any other Last Call comments you may receive. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: Minor: == * IANA considerations The IANA considerations section does not specify the namespace from which allocation is requested for the AVPs and the message types. Editorial: == * Section 4.2 Failover Session Response This sentence has a typo and does not read well It is not required to respond one FSQ message with just on FSR. I suggest removing it altogether so that the text will simply read An endpoint MAY choose to respond to an FSQ message with multiple FSR messages ___ 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: Last Call: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed Standard (draft-ietf-crisp-iris-lwz)
Sam Hartman wrote: I notice that this transport provides no authentication of the data that is retrieved. The security considerations needs to discuss the potential attacks if an attacker modifies this public data. The security considerations section also needs to point to best practice for avoiding UDP reflection attacks. It is not good enough to say Do what other people do. In both cases these may be included by reference. I noticed this in the draft: 1. If a request requires authentication, confidentiality, or other security, use another transfer protocol. It seems to me that the intent is to not provide authentication here. This seems more fundamental than a fix by reference. In a different vein, we have: Its message exchange pattern is simple: a client sends a request in one UDP packet, and a server responds with an answer in one UDP packet. I see no mention of what to do if the one UDP packet is lost. Resend? After how long? Exponentially backoff? - Mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Announcement of IAB member selection
Henrik Levkowetz wrote: I applaud the NomCom in this very appropriate choice -- at this particular time, I don't think there is any better choice they could possibly have made for the vacant IAB seat. Bert has impressed me with his ability to always perceive where he is most needed, and appear there as if by magic to assist in whatever needs to be done. I remember a thorny throughput issue we ran across some years ago at Casa de Bandini, when Bert came through as a trouper and helped us make headway with the problem [1]. With that taken care of, he also showed us his famous ability to make friends with the ladies [2]. We couldn't wish for a more well-rounded man of the world to step up to the plate and shoulder his responsibilities today. Henrik [1] http://tinyurl.com/jfsxm [2] http://tinyurl.com/zccdt Or... http://bert.secret-wg.org/Kisses/ on 2006-04-01 04:15 Ralph Droms said the following: I am pleased to announce that the 2005-2006 NomCom selection and confirmation process to fill the IAB seat vacated by Pekka Nikander's resignation is complete. At this time, on behalf of the NomCom, the new member of the IAB is: Bert, [EMAIL PROTECTED] Bert will complete the remainder of Pekka's term. The Nomcom considered Bert's extensive travel and acquaintances with leaders and personalities around the world. Although there was question about Bert's technical accomplishments, his other experience will materially help the IAB with its representational duties. The NomCom was also concerned about Bert's willingness to contribute to IAB activities as Bert is usually a silent participant in public events. However, we note the eloquence and clarity of reasoning Bert demonstrated on video at IETF 65 in his congratulation to the IETF on its 20th anniversary. A further consideration is whether Bert would be able to serve a full term, as it has been rumored he is a candidate to replace Vint Cerf as chair of ICANN when Vint's term expires. His photograph count is approaching Vint's and he has accumulated a similar number of frequent flyer miles. Bert was not able to commit, but indicated he has not yet been offered the ICANN role. The NomCom joins the rest of the IETF community in thanking Bert for volunteering his valuable time and extraordinary skills to the IAB, the IETF comunity and the Internet. - Ralph Droms (chair), for the 2005-2006 IETF Nominating Committee April 1, 2006 ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Softwires Interim Meeting
Marshall Eubanks wrote: March 19 - 30 days = Feb 17th. This date was chosen, understanding that it bends the rules a bit, to increase the greater goal of global participation by coinciding with the APRICOT conference the following week (so at least some of the non-asiapac members will be on the correct side of the globe). - Mark On Jan 24, 2006, at 4:19 PM, James M. Polk wrote: Mark I'm not an interested party here, and I don't mean to throw a monkey wrench into your plans, but I'm observing that this seems to be within the 30 days of moratorium of when we cannot have an interim, where (loosely) 'interims shall not be within 30 days of the next IETF meeting'. The Dallas IETF starts on March 19th, so I would think the cutoff would be Feb 19th for the last of an interim. What am I missing? At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote: The meeting will be Feb 23-24 in Hong Kong. Participants should plan to arrive Feb 22 for an early start on Feb 23. We will finish by 2pm on Feb 24. Accomodation information coming shortly (watch the [EMAIL PROTECTED] mailing list). Thank you, - Mark ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ 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
Softwires Interim Meeting
The meeting will be Feb 23-24 in Hong Kong. Participants should plan to arrive Feb 22 for an early start on Feb 23. We will finish by 2pm on Feb 24. Accomodation information coming shortly (watch the [EMAIL PROTECTED] mailing list). Thank you, - Mark ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Is there a per-wg chair email list maintained?
i.e., [EMAIL PROTECTED], [EMAIL PROTECTED], etc. in order to reach the current WG chairs for just that WG. Thanks, - Mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: (oops) Is there a per-wg chair email list maintained?
Sorry for spamming the world with this, I meant to just ask [EMAIL PROTECTED] - Mark W. Mark Townsley wrote: i.e., [EMAIL PROTECTED], [EMAIL PROTECTED], etc. in order to reach the current WG chairs for just that WG. Thanks, - Mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: L2TP Deployment Scenario?
Rohit Gupta wrote: Hi, L2TP is an encapsulation that allows multiplexing of multiple PPP sessions between two IP-connected endpoints, and a control protocol for dynamically Since L2TP is so strongly tied with PPP, can i assume that it will be *mostly* used when a user dials (ISDN/modem) into the ISP network (LAC) to contact the corporate network. It tends to be used rather often for PPPoA and PPPoE in DSL environments these days as well. Can I then connect a small branch office to the corporate network using L2TP? Does it make any sense doing that. Sure, in some cases. I am now talking of a deployment scenario. Do you ever have two branches connected via L2TP? A number of small routers on the market today have the ability to initiate an L2TP session from the router to an LNS. I searched the internet and found only scenarios wherein a remote access user dials into the ISP to access the corporate network using L2TP. Is the former possible? Look for L2TP voluntary tunneling or client-initiated L2TP Also, if you are going to be running L2TP over the Internet and you are worried about folks hacking the connection, you would want to secure the L2TP tunnel with IPsec transport mode as defined in RFC3193. In theory, one could have a small office with some 10 users connected to switch which in turn dials into the ISPs network. Is this possible? If you are using L2TP over IP to connect to an ISP to get IP access you likely have a bit of a chicken and egg problem. But, yes, if you already have IP connectivity from one ISP, but want to use L2TP to connect to another ISP (perhaps with some other value add on their network) it is *possible* if the ISP allows L2TP connections from your router. Typically, an ISP would accept L2TP connections only from a wholesale access provider (or in some cases from their own PC client). In any case, you'd probably have to find a very knowledgable person at your ISP to talk to this about as it likely isn't standard practice. - Mark With regards, Rohit P.S. And thanks to everybody for responding both on the list and offline! __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
Re: GRE and L2TP
Stewart Bryant wrote: W. Mark Townsley wrote: Rohit Gupta wrote: Hi, What is it in L2TP that i cant do with a simple GRE tunneling when implementing a remote access VPN for a mobile client to connect to the corporate network. In L2TP, since it uses PPP end-to-end, the LNS is able to supply dynamic IP address using IPCP to the remote client. LNS takes this IP address from a pool of IP addresses it has. If one were to use GRE, then the same can be done by using some out-of-band mechanism (or even have a fixed IP address which the mobile client is instructed to use). GRE will tunnel the data packet originated from the mobile client, the inner IP header will have the ip addresses as assigned by the corporate network. The outer IP header will contain the IP address of teh ISP and the gateway to reach the corporate network. GRE is an encapsulation. If you can manually provision or have some other out of band mechanism that does everything L2TP and PPP would otherwise do for you, then by all means use GRE - or IP in IP for that matter as your scenario with fixed IP addresses for all mobile clients (which I would think is a showstopper from the start) does not obviate the need for a GRE shim either. L2TP is an encapsulation that allows multiplexing of multiple PPP sessions between two IP-connected endpoints, and a control protocol for dynamically establishing and maintaining the emulation of these PPP sessions. This is very different than GRE (though there are some ways to deploy L2TP between two routers to make it look like it is doing what GRE typically does in a bit more of a dynamic manner, though this is really a subset of L2TP's overall functionality). Since you indicate that this is for a mobile environment, you might want to look at using Mobile IP. My whole point is that i want to know as to what is the burning need to have L2TP! This question probably has more to do with whether you need PPP. If you do, L2TP could work for you to transport that PPP session (or many PPP sessions) over an IP network. If not, I see no reason for you to be burning with need for L2TP! - Mark Mark I think that the correct comparison in Rohit's case is not between L2TP and GRE, but between L2TPv3 and GRE. As we both know L2TPv3 is better suited to VPN apps than GRE because of its highly functional control plane, and mild security enhancements. I was under the impression during this thread that Rohit was referring to L2TP as defined in RFC2661, not L2TPv3 (currently draft-ietf-l2tpext-l2tp-base-11.txt) which is certainly not so closely tied to PPP. Thanks, - Mark - Stewart Regards, Rohit P.S. Am not sure if this is indeed the right place to ask this question. But since there will be a lot of experienced people on this list who would have worked on both these protocols, replying to this one should be very easy. __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
Re: GRE and L2TP
Rohit Gupta wrote: Hi, What is it in L2TP that i cant do with a simple GRE tunneling when implementing a remote access VPN for a mobile client to connect to the corporate network. In L2TP, since it uses PPP end-to-end, the LNS is able to supply dynamic IP address using IPCP to the remote client. LNS takes this IP address from a pool of IP addresses it has. If one were to use GRE, then the same can be done by using some out-of-band mechanism (or even have a fixed IP address which the mobile client is instructed to use). GRE will tunnel the data packet originated from the mobile client, the inner IP header will have the ip addresses as assigned by the corporate network. The outer IP header will contain the IP address of teh ISP and the gateway to reach the corporate network. GRE is an encapsulation. If you can manually provision or have some other out of band mechanism that does everything L2TP and PPP would otherwise do for you, then by all means use GRE - or IP in IP for that matter as your scenario with fixed IP addresses for all mobile clients (which I would think is a showstopper from the start) does not obviate the need for a GRE shim either. L2TP is an encapsulation that allows multiplexing of multiple PPP sessions between two IP-connected endpoints, and a control protocol for dynamically establishing and maintaining the emulation of these PPP sessions. This is very different than GRE (though there are some ways to deploy L2TP between two routers to make it look like it is doing what GRE typically does in a bit more of a dynamic manner, though this is really a subset of L2TP's overall functionality). Since you indicate that this is for a mobile environment, you might want to look at using Mobile IP. My whole point is that i want to know as to what is the burning need to have L2TP! This question probably has more to do with whether you need PPP. If you do, L2TP could work for you to transport that PPP session (or many PPP sessions) over an IP network. If not, I see no reason for you to be burning with need for L2TP! - Mark Regards, Rohit P.S. Am not sure if this is indeed the right place to ask this question. But since there will be a lot of experienced people on this list who would have worked on both these protocols, replying to this one should be very easy. __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
Re: PPP
Brian Lloyd wrote: At 11:59 PM 3/6/2002, you wrote: sigh It has been many years since I argued this with Karl Fox back when he chaired the L2TP WG. Karl chaired only the pppext WG. Then at the time L2TP or the precursor discussions were done within the PPPEXT WG because the discussion was with Karl. At that time he agreed but also said that there was too much water under the bridge to fix L2TP at that time so it was going to go forward in its subtlely-broken form. I haven't looked at it since then. I don't even remember the lexicon so I will undoubtedly sound uninformed. The LCP negotiation should take place with the L2TP equivalent of the NAS. That is independent of anything else that happens and nothing associated with that needs to be communicated to the edge device at the target network. The authentication phase then takes place so you can do authorization and configuration. That would have been nice, but, the requirements were that it be possible for user authorization be completed at the LNS (the edge device at the target network), and at the LAC (NAS). Thank you for reminding me. LNS and LAC were the terms I was looking for. WRT authentication, there is no reason not to do it in both places. Let the protocol carry the information. In addition, we could not require the user to enter a username and password twice. You simply had to be able to drop in L2TP, and everything look the same as it did before to the end user. I agree that is the more desirable scenario. Once that is complete you can do the MLPPP and NCP negotiation(s) because then and only then do you know what the end system is authorized to do. Yup, that would have been nicer. Yes, it would. But MLPPP is negotiated during LCP, you say! Right. That is broken and I helped make it broken and, in retrospect, I am *really* sorry I did. That's OK, we'll forgive you ;-) Thank you. It may seem silly but that has really bugged me for a number of years. I hate the thought of having done flawed work. Barring redesign of PPP, getting around the wrong things being located in the LCP negotiation would have been made a little easier if we had been allowed to go through LCP negotiation twice. So, you could have LCP negotiated at the LAC, But you wouldn't have needed to do LCP negotiation twice. The LAC negotiates LCP because that is the terminus of the link. Not just that, the LAC may also need to get authentication information from the user so that it can know which LNS to forward to. The LAC communicates the options negotiated back to the LNS. That's what we do now. Please read section 4.4.5 of RFC2661. Remember, the LCP options negotiate only indicate what the client is willing to accept therefore it doesn't really matter what it negotiates. It is just there to prevent its peer from sending something it can't handle. But, if the LNS, say, want's to do some different authentication... Say, PAP with an OTP but the LAC negotiated CHAP, then, well... We have to start over PPP LCP, which should be OK except that it used to break a lot of PPP clients. forward any necessary link parameters to the LNS so that it could set them correctly during LCP round 2, and then renegotiate LCP at the LNS to get things like MLPPP and perhaps authentication type which should have been designed into the negotiation process later. Right. That is the crux of the problem. But -- and here is the point about broken PPP stacks -- at the time there were a lot of PPP stacks which would simply roll over and die if you tried to reneogtiate LCP after you had already begun (yes, in great violation to what it says in RFC 1661). This wasn't discovered until L2TP came along because before that, you really didn't see LCP renegotiation occur very much. sigh But we did know. The argument was that it took too long to negotiate PPP as it was so anything we did to speed it up was necessary. I have kicked myself for caving in to that argument for many years now. Then let me give you a collective kick from all of the l2tp developers out there ;-) I thought it was just a bug. I remember telling Robert Webster about this little problem at a pacbell bakeoff many years ago. His jaw dropped, and he went back and made an on-the-fly bugfix for it and afterwards it worked great. Note that Robert worked at Shiva then, and maintained code for the PPP stack that for a while was the original code base for much of the dialup client industry (e.g. Windows, OS/2, and probably some others...). But, it was way too late as there were so many clients in the field with this bug. So, we ended up with Proxy LCP and Proxy Authentication like you see them today. I know: add more ugliness in order to deal with other ugliness. I preferred the old days where people found problems, fixed them, and the fixes then found their ways into new versions,
Re: PPP
Brian Lloyd wrote: At 03:12 AM 3/4/2002, you wrote: I couldn't say it shorter and more clearly than Vint : PPP does NOT belong to the TCP/IP protocol suite. Other than it was designed for IP and the other stuff came along for the ride. PPP was a relatively early product of the IETF and specifically designed for IP. It's a Layer 2(*) protocol, intended to carry multiple Layer 3 protocols (like IP, IPX,...) over a point-to-point connection (like PSTN, ISDN,...). PPP succeeded SLIP by bringing extended features : SLIP could only encapsulate IP while PPP can encapsulate several protocols, PPP supports authentication while SLIP didn't, etc. Remember that TCP/IP only covers Layer 3 up to Layer 7 : it's designed to be implemented on existing lower layers (1 and 2) : LAN (Ethernet, Token Ring, Wireless Lans,...) or WAN (ISDN, ATM, Frame Relay,...). This is a common misconception. The lower layers (1 and 2) that you mention are often completely routable networks in and of themselves. You can even encapsulate IP within IP therefore IP is operating at layer 2 from that interpretation. Ethernet is regularly routed now (people call it switching but a rose by any other name ...). So all of these, including PPP, exist at layers 1-2 in the TCP/IP model (link, network, internetwork, transport, application) or layers 1-3b in the ISORM. This problem plagues developers working with PPP for the first time because they keep thinking in terms of PPP being only a link-layer protocol. If they would remember that PPP operates at the network layer then they would stop making stupid mistakes like a badly-designed L2TP. I don't see how classification of PPP as a layer 2, layer 3, or any other layer would have had an affect on how we designed L2TP (perhaps it would have affected the name of the protocol though). Layers aside, PPP was already deployed and it was pretty obvious what we wanted to do - make it run over IP without the installed base of PPP clients being made aware of it. How would you have done this that is substantially different than L2TP? (As an aside, of the list of obscene things we did have to do to make L2TP work, the worst were more due to badly implemented PPP stacks than anything else.) Tunneling, particularly L2 tunneling, is by its very definition a layer violation. The perfect world where this is not necessary or desirable does not exist beyond textbooks and laboratories. So here we are in the real world, tunneling not just PPP but a plethora of L2 or L2-like layers. - Mark E.T. (*) Those layers always refer to the OSI model. Think of a Layer 2 or 3 or 4 Switch : it doesn't depend on the protocol suite above, so we always refer to the vendor- technology- protocol-independent OSI reference model. I love watching people slavishly adhere to this or that model of layering. Layering is a convenience, not a religion. (Actually, I got that backwards.) With the widespread use of encapsulating one networking or internetworking protocol in another, the whole concept of rigid layering goes out the window. The cry of, its a network layer; its a link layer, should be right up there with, its a dessert topping; its a floor wax! --- The basic answer ends here --- Now a small yet technical recall : when data comes from an application to be transported on a physical medium (copper cable, fiber optics, radio waves, infra-red,...), on its way from Layer 7 to Layer 1 it reaches IP (Layer 3) ISO spent a lot of time trying to sell the 7-layer model and then didn't know how to backtrack when they discovered that there were really two network layers when you interconnect dissimilar networks using an internetworking protocol. ATM, FR, Ethernet, etc., are all routable layer-3 protocols in their own regard so they opted to break layer three into three sublayers. (It is really three layers by their reckoning but ISO already had so much invested in the ISO Seven Layer Reference Model [tm] that they couldn't really switch to the ISO Nine Layer Reference Model Formerly Known As The Seven Layer Reference Model [tm].) that encapsulates it in a datagram/packet and specifies the destination network+host address. Then it's forwarded to PPP (Layer 2) that encapsulates it in a frame and specifies the way bits are organized to travel through the physical medium. Then it's forwarded to some Layer 1 technology that converts the bits into a specific signal using a specific encoding scheme (V.90 on PSTN, I.430 on ISDN BRI,...) and finally reaches the physical medium to be physically transported through the network. To some extent you are right but your model needs to accommodate things like L2TP which tunnels traffic at layer 1|2 (depending on the model of the day) in a layer 4 (transport) protocol, or IP tunneled in IP. It is probably better to be able to keep the concept of duality in your mind, i.e. when you hold you tongue one way it
Re: PPP
Brian Lloyd wrote: At 02:42 AM 3/6/2002, you wrote: I don't see how classification of PPP as a layer 2, layer 3, or any other layer would have had an affect on how we designed L2TP (perhaps it would have affected the name of the protocol though). PPP actually consists of two distinct and separate sets of protocols. The LCP and its negotiation should be totally separate from the NCPs and their negotiation. Layers aside, PPP was already deployed and it was pretty obvious what we wanted to do - make it run over IP without the installed base of PPP clients being made aware of it. Do it right would not have changed that. How would you have done this that is substantially different than L2TP? (As an aside, of the list of obscene things we did have to do to make L2TP work, the worst were more due to badly implemented PPP stacks than anything else.) sigh It has been many years since I argued this with Karl Fox back when he chaired the L2TP WG. Karl chaired only the pppext WG. At that time he agreed but also said that there was too much water under the bridge to fix L2TP at that time so it was going to go forward in its subtlely-broken form. I haven't looked at it since then. I don't even remember the lexicon so I will undoubtedly sound uninformed. The LCP negotiation should take place with the L2TP equivalent of the NAS. That is independent of anything else that happens and nothing associated with that needs to be communicated to the edge device at the target network. The authentication phase then takes place so you can do authorization and configuration. That would have been nice, but, the requirements were that it be possible for user authorization be completed at the LNS (the edge device at the target network), and at the LAC (NAS). In addition, we could not require the user to enter a username and password twice. You simply had to be able to drop in L2TP, and everything look the same as it did before to the end user. Once that is complete you can do the MLPPP and NCP negotiation(s) because then and only then do you know what the end system is authorized to do. Yup, that would have been nicer. But MLPPP is negotiated during LCP, you say! Right. That is broken and I helped make it broken and, in retrospect, I am *really* sorry I did. That's OK, we'll forgive you ;-) Barring redesign of PPP, getting around the wrong things being located in the LCP negotiation would have been made a little easier if we had been allowed to go through LCP negotiation twice. So, you could have LCP negotiated at the LAC, forward any necessary link parameters to the LNS so that it could set them correctly during LCP round 2, and then renegotiate LCP at the LNS to get things like MLPPP and perhaps authentication type which should have been designed into the negotiation process later. But -- and here is the point about broken PPP stacks -- at the time there were a lot of PPP stacks which would simply roll over and die if you tried to reneogtiate LCP after you had already begun (yes, in great violation to what it says in RFC 1661). This wasn't discovered until L2TP came along because before that, you really didn't see LCP renegotiation occur very much. But, it was way too late as there were so many clients in the field with this bug. So, we ended up with Proxy LCP and Proxy Authentication like you see them today. There's not much else you can do if you want to complete PPP negotiation at the LNS, but *start* it at the LAC so that you can get the @domain portion of the username to determine where to tunnel the user. Sigh... Yes, if we had thought about running PPP over IP from the beginning, things might have looked very different in general... A more seperate link layer negotiation would have been one of them. But, PPP isn't nearly as difficult as, say, TDM over IP ;-) There are even other bugs in the field we have had to code around with IPCP negotiation, and don't even get me started on ACCM mapping So, as I said, this is water under the bridge and it isn't going to change. Any attempt to do so would be met with a barrage of but we have lots of systems in the field and this would break them arguments. Right. The same argument that led to some of the choices we had to make in L2TP. Tunneling, particularly L2 tunneling, is by its very definition a layer violation. The perfect world where this is not necessary or desirable does not exist beyond textbooks and laboratories. So here we are in the real world, tunneling not just PPP but a plethora of L2 or L2-like layers. There is nothing wrong with tunneling per-se. In fact, it solves many problems. IMHO tunneling is a good thing. My comments had only to do with the fallacy of rigid layering, how many people don't really understand layering, and as a side issue, how PPP was really a suite of protocols at different layers and how that affects MLPPP and L2TP. Then we agree more than we
Re: IETF #53 Schedule Stability
Pekka Savola wrote: On Mon, 25 Feb 2002, W. Mark Townsley wrote: What most people seem to be missing is the real work is done outside of the WG meetings. You can quite well participate in the IETF process without ever (or once or twice a year) being present. Personally, in some wg's I've been to, a lot of MIC time is used by people who 1) like their own voice, and/or 2) haven't read the drafts. You don't have to present works for them to be adopted as WG items. Presenting a work does, sometimes, help the WG chair(s) determine interest level and consensus of the WG, particularly if the issue is contentious and the right people are present at the meeting (e.g. people who have read the draft and care). So, while it can help the author's cause to present, it is not (nor ever has been that I know of) a requirement. Well, I haven't been around all that many years, but I don't recall a single case in a few WG's I'm participating that an unpresented work would have been adopted.. sure, it's not written down anywhere, but sometimes custom is stronger than law... It could certainly be the convention of the WG Chairs in those (or even most) groups. But, it is still not an IETF mandate. Cheers, - Mark -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Re: IETF #53 Schedule Stability
Pekka Savola wrote: On Sun, 24 Feb 2002, Eric Burger wrote: [snip] While it's true that one should try to see everything, it's hard to imagine, for example, how a junior engineer working on an implementation of wireless ad-hoc networks has much of an interest in ENUM. [snip] What most people seem to be missing is the real work is done outside of the WG meetings. You can quite well participate in the IETF process without ever (or once or twice a year) being present. Personally, in some wg's I've been to, a lot of MIC time is used by people who 1) like their own voice, and/or 2) haven't read the drafts. If you want a focused view, participation isn't necessary. (An IMO stupid remnant here is that you have to present the works if they're to be adopted as WG items.) You don't have to present works for them to be adopted as WG items. Presenting a work does, sometimes, help the WG chair(s) determine interest level and consensus of the WG, particularly if the issue is contentious and the right people are present at the meeting (e.g. people who have read the draft and care). So, while it can help the author's cause to present, it is not (nor ever has been that I know of) a requirement. If you want a general view (perhaps in addition to the focused one), coming to the meetings might help. -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
