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: Last Call: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed Standard (draft-ietf-crisp-iris-lwz)
Mark == Mark Townsley [EMAIL PROTECTED] writes: Mark 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. s/reflection/amplification sorry Mark 1. If a request requires authentication, confidentiality, Mark or other security, use another transfer protocol. Mark It seems to me that the intent is to not provide Mark authentication here. This seems more fundamental than a fix Mark by reference. Sure. What I'm asking for is that they explain what the consequences of providing no authentication are. I'll then evaluate those consequences and either conclude that authentication is not required for this data for an Internet deployment or come back with another comment that the security is inadequate. But the first step of determining whether the security is adequate is to determine the risk. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: L2VPNs must not be IP(v4)-only
Pekka, This topic has come up in the past -- the last time I recall it being a significant issue was IETF 63 in Paris, France. On multiple occasions since then we have asked for volunteers with IPv6 expertise to help complete the IPv6 bits of this I-D. Unfortunately, we have gotten little to no response. Do you wish to help out with this? Or, can you provide a pointer to folks in the IPv6 world that can take a look at this doc and help out? Thanks, -shane Pekka Savola wrote: On Wed, 16 Aug 2006, [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title: ARP Mediation for IP Interworking of Layer 2 VPN Author(s): H. Shah, et al. Filename: draft-ietf-l2vpn-arp-mediation-07.txt Pages: 21 Date: 2006-8-16 ... The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as ARP Mediation. ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. The document says, 10. IPV6 Considerations The support for IPV6 is not addressed in this draft and is for future study. This needs to be addressed throughout the document. The whole point of L2VPNs (IMHO) is that it's agnostic of what protocols users run above L2. Users depend on a transparent L2 service model and this model breaks that assumption. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'A Lightweight UDP Transfer Protocol for the the I nternet Registry Information Service' to Proposed Standard (draft-ietf-cr isp-iris-lwz)
Sam, I thought the Security Area Directorate was limited to determining if the description of security risks is adequate and that determination of whether security is adequate - for adequately described security risks - would be up to the end consumer. Is that not correct? Certainly it will be the case that - if product consumers disagree with a finding within the IETF - they may very well go ahead and buy products that the IETF has determined not to have adequate security. In that case, what the IETF has rejected on the basis of security concerns, will become a defacto standard without the blessing of the IETF. I'm sure this is an old, often rehashed, argument - but I just wanted to be sure about your comments... -- Eric -- -Original Message- -- From: Sam Hartman [mailto:[EMAIL PROTECTED] -- Sent: Thursday, August 17, 2006 11:03 AM -- To: Mark Townsley -- Cc: ietf@ietf.org; iesg@ietf.org -- Subject: Re: Last Call: 'A Lightweight UDP Transfer -- Protocol for the the Internet Registry Information Service' -- to Proposed Standard (draft-ietf-crisp-iris-lwz) -- -- Mark == Mark Townsley [EMAIL PROTECTED] writes: -- -- Mark 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. -- -- s/reflection/amplification sorry -- -- Mark 1. If a request requires authentication, -- confidentiality, -- Mark or other security, use another transfer protocol. -- -- Mark It seems to me that the intent is to not provide -- Mark authentication here. This seems more fundamental -- than a fix -- Mark by reference. -- -- Sure. What I'm asking for is that they explain what the -- consequences -- of providing no authentication are. I'll then evaluate those -- consequences and either conclude that authentication is not required -- for this data for an Internet deployment or come back with another -- comment that the security is inadequate. But the first step of -- determining whether the security is adequate is to -- determine the risk. -- -- ___ -- 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: L2VPNs must not be IP(v4)-only
IMHO, there's something fundamentally wrong with any IETF working group that's not willing to learn about IPv6. IPv6 is not a specialized topic, it's the layer common to all parts of the emerging Internet. And there's little point in standardizing anything new that only works on IPv4. I'd go so far as to say that any new protocol that doesn't support IPv6 has significant known technical omissions that should make its approval as a Proposed Standard seriously in doubt. Keith This topic has come up in the past -- the last time I recall it being a significant issue was IETF 63 in Paris, France. On multiple occasions since then we have asked for volunteers with IPv6 expertise to help complete the IPv6 bits of this I-D. Unfortunately, we have gotten little to no response. Do you wish to help out with this? Or, can you provide a pointer to folks in the IPv6 world that can take a look at this doc and help out? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'A Lightweight UDP Transfer Protocol for the the I nternet Registry Information Service' to Proposed Standard (draft-ietf-cr isp-iris-lwz)
Gray, == Gray, Eric [EMAIL PROTECTED] writes: Gray, Sam, I thought the Security Area Directorate was limited to Gray, determining if the description of security risks is Gray, adequate and that determination of whether security is Gray, adequate - for adequately described security risks - would Gray, be up to the end consumer. first, this document is in last call. It's very clear to me that I can make a last call comment as an IETf contributor that I think the security is inadequate. I don't have time right now to come up with text I believe to be formally correct that describes when I would feel comfortable entering a security discuss. I refer you to the IESG discuss criteria document as a good starting point. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: L2VPNs must not be IP(v4)-only
From: Keith Moore moore@cs.utk.edu IMHO, there's something fundamentally wrong with any IETF working group that's not willing to learn about IPv6. On the other hand, maybe they are just recognizing reality - something much of the rest of the IETF seems stubbornly determined to ignore. IPv6 is not a specialized topic, it's the layer common to all parts of the emerging Internet. Case in point I ought to adopt a .sig: Number of decades since formal adoption of IPv6: N, where of course currently N=1.2 (since SIPP was selected as IPng at the July, 1994, IETF). So, exactly how large does N have to get before the ludicrousness level gets high enough to overwhelm the refusal to admit reality? If IPv6 were a drug, it would likely have been outlawed, it's (seemingly) so mind-altering and addictive. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Announcement of mailing list for pre-congestion notification (PCN)
There has been discussion of a number of drafts related to pre- congestion notification (PCN) for admission control and flow pre- emption in the TSVWG for the last couple of IETF meetings. We are hoping to hold a BOF on PCN at the next IETF meeting, and to that end a mailing list has been created. You can subscribe to the PCN mailing list at http://www1.ietf.org/mailman/listinfo/pcn If you are wondering what PCN is, you could take a look at the following drafts to get an idea: draft-briscoe-tsvwg-cl-architecture-03.txt and draft-briscoe-tsvwg-cl- phb-02.txt Bruce Davie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: L2VPNs must not be IP(v4)-only
From: Keith Moore moore@cs.utk.edu IMHO, there's something fundamentally wrong with any IETF working group that's not willing to learn about IPv6. On the other hand, maybe they are just recognizing reality - something much of the rest of the IETF seems stubbornly determined to ignore. it's generally been my experience that when people cite reality that it is more accurate to substitute my belief/superstition/prejudice that I cannot defend the problem with citing reality in support of a design decision to make a protocol less flexible is that it tends to be self-fulfilling. to support only IPv4 is to build in obsolescence. are we designing standards for the past, or for the future? Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'A Lightweight UDP Transfer Protocol for the the I nternet Registry Information Service' to Proposed Standard (draft-ietf-cr isp-iris-lwz)
Sam Hartman wrote: Gray, == Gray, Eric [EMAIL PROTECTED] writes: Gray, Sam, I thought the Security Area Directorate was limited to Gray, determining if the description of security risks is Gray, adequate and that determination of whether security is Gray, adequate - for adequately described security risks - would Gray, be up to the end consumer. first, this document is in last call. It's very clear to me that I can make a last call comment as an IETf contributor that I think the security is inadequate. To be quite honest, I was unsure which hat you were wearing when you made your statement. I'm also unsure if it matters. All that being said, I agree that the security considerations section is missing quite a bit. It should explain the consequences of using this protocol from a security point of view. And the big thing it left out, is that not only should it mention that there are alternatives, but it should explicitly state what they are. In this case, the security considerations section ought to specifically point to XPC, which is also from the CRISP wg and being IETF last called at the moment. That draft is draft-ietf-crisp-iris-xpc-04.txt; a review of it would be helpful. -andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: L2VPNs must not be IP(v4)-only
Hi. Maybe I wasn't paying attention but I don't recall seeing messages about this on either the ipv6 or v6ops mailing list. I guess you may have asked around but I'm sure somebody in the wg's could have helped if a public request was made (especially the ndproxy authors). Be that as it may, I agree with Pekka that this document should not proceed without the IPv6 case being addressed. As regards what needs to be done, I guess that RFC4389 provides most of the information - note that RFC4389 is classified as experimental and there may be some discussion as to whether the same arguments that lead to this classification apply to the whole of the arp mediation draft. Both any proposed IPv6 support and the existing IPv4 proposals MUST ensure that they have satisfactorily addressed the architectural issues in draft-thaler-intarea-multilink-subnet-issues-00.txt. Regards, Elwyn Shane Amante wrote: Pekka, This topic has come up in the past -- the last time I recall it being a significant issue was IETF 63 in Paris, France. On multiple occasions since then we have asked for volunteers with IPv6 expertise to help complete the IPv6 bits of this I-D. Unfortunately, we have gotten little to no response. Do you wish to help out with this? Or, can you provide a pointer to folks in the IPv6 world that can take a look at this doc and help out? Thanks, -shane Pekka Savola wrote: On Wed, 16 Aug 2006, [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title: ARP Mediation for IP Interworking of Layer 2 VPN Author(s): H. Shah, et al. Filename: draft-ietf-l2vpn-arp-mediation-07.txt Pages: 21 Date: 2006-8-16 ... The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as ARP Mediation. ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. The document says, 10. IPV6 Considerations The support for IPV6 is not addressed in this draft and is for future study. This needs to be addressed throughout the document. The whole point of L2VPNs (IMHO) is that it's agnostic of what protocols users run above L2. Users depend on a transparent L2 service model and this model breaks that assumption. ___ 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: Meetings in other regions
At 6:46 AM -0700 7/17/06, Andy Bierman wrote: Marshall Eubanks wrote: Nobody flies from LAX to San Diego because it ends up taking twice as long as driving for 10 times as much, so don't expect lots of flights from LA. I fly between LAX and San Diego fairly often. There are two airlines that offer flights at least every hour throughout the day. During some periods the flights are every half hour. You can generally connect in LAX without going through security again (unless arriving into LAX on an international flight). It doesn't really work to apply typical logic to airline fares. That is, you can't predict a fare based on distance or number of connections. While it can be expensive to purchase a separate ticket between SAN and LAX, this is rarely done. Usually a the fare is from point A to SAN and back. In some cases it is slightly more than from point A to LAX and back, but often it is less. Sometimes it is a lot less. I'd be willing to believe that there are cases where it is a lot more, but I haven't personally seen them. I'm a great believer in the train between SAN and LA, by the way. I've taken it a number of times and always prefer it to driving. Note that for a slight extra charge you can get an upgrade to 'custom class' where you get a larger seat, a power outlet, and something called a snack. There are terrific views of the pacific ocean and beaches during the latter half of the trip, and for much of it the train is right on the sand. The immigration checkpoint seems to be dormant for a year or so now. The electronic pass lanes have been turned off, the signs warning you to be prepared to stop have been removed, the officers standing in the lanes inspecting cars are gone. The main structure is still there, and there are still border patrol cars at the sides, but that's it. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly-selected tag: --- As you know, any depiction of nasal mucus brings with it problems for our sales division. --ABC's Broadcast Standards Practices board, to producers of the cartoon Bump in the Night ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC 4612 - historic status
Frank, No, it does not. It's simply an alternative representation of the fax data. The receiver could receive it and print it, create audio tones (if it desired), produce a TIFF image and e-mail it, or whatever else it wished to do. Paul -Original Message- From: Frank Ellermann [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 2:55 AM To: ietf@ietf.org Subject: Re: RFC 4612 - historic status Dave Crocker wrote: | audio -- audio data. Audio requires an audio output | device (such as a speaker or a telephone) to | display the contents. An initial subtype | basic is defined in this document. [...] In what way does this not satisfy *exactly* the requirements for the audio top-level MIME type? The final receiver isn't supposed to hear a fax arriving as phone call, whistling the replies. Seriously, does this media type require a modem somewhere on the receiver's side ? Frank ___ 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: Meetings in other regions
At 3:54 PM +0100 7/19/06, Dave Cridland wrote: I seem to remember that at one point, Randall Gellens was actually providing the entire room with unblemished, albeit slow, internet access over his mobile. It was much worse then that. I used the single outside phone jack to get dial up connectivity, then made that available via 802.11 to the room. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly-selected tag: --- The well-bred contradict other people. The wise contradict themselves. --Oscar Wilde ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Taxi LAX-SAN (was 'Meetings in other regions')
At 12:06 PM +0300 7/18/06, [EMAIL PROTECTED] wrote: (BTW, how much would a taxi from LAX to San Diego cost? And would you expect taxis willing to do it?) This is a fairly common service. There are taxis, shuttles, and car services that offer this for fixed prices. Prices start around $200 for a car service. A shuttle would be less. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly-selected tag: --- Yesterday it worked Today it is not working Windows is like that --Error Haiku ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 87 messages in the last 7 days. script run at: Fri Aug 18 00:03:01 EDT 2006 Messages | Bytes| Who +--++--+ 10.34% |9 | 15.24% |78348 | [EMAIL PROTECTED] 5.75% |5 | 8.33% |42814 | [EMAIL PROTECTED] 6.90% |6 | 5.83% |29994 | [EMAIL PROTECTED] 6.90% |6 | 5.38% |27669 | [EMAIL PROTECTED] 5.75% |5 | 6.51% |33474 | [EMAIL PROTECTED] 5.75% |5 | 6.13% |31494 | [EMAIL PROTECTED] 4.60% |4 | 3.95% |20322 | [EMAIL PROTECTED] 4.60% |4 | 3.22% |16555 | [EMAIL PROTECTED] 3.45% |3 | 3.91% |20096 | [EMAIL PROTECTED] 3.45% |3 | 2.93% |15081 | [EMAIL PROTECTED] 3.45% |3 | 2.89% |14869 | [EMAIL PROTECTED] 2.30% |2 | 2.26% |11629 | [EMAIL PROTECTED] 2.30% |2 | 2.21% |11376 | [EMAIL PROTECTED] 2.30% |2 | 2.01% |10345 | [EMAIL PROTECTED] 2.30% |2 | 1.75% | 9006 | [EMAIL PROTECTED] 2.30% |2 | 1.74% | 8940 | moore@cs.utk.edu 1.15% |1 | 2.52% |12946 | [EMAIL PROTECTED] 2.30% |2 | 1.34% | 6881 | [EMAIL PROTECTED] 1.15% |1 | 1.46% | 7518 | [EMAIL PROTECTED] 1.15% |1 | 1.40% | 7211 | [EMAIL PROTECTED] 1.15% |1 | 1.25% | 6437 | [EMAIL PROTECTED] 1.15% |1 | 1.22% | 6250 | [EMAIL PROTECTED] 1.15% |1 | 1.19% | 6096 | [EMAIL PROTECTED] 1.15% |1 | 1.18% | 6086 | [EMAIL PROTECTED] 1.15% |1 | 1.18% | 6052 | [EMAIL PROTECTED] 1.15% |1 | 1.16% | 5965 | [EMAIL PROTECTED] 1.15% |1 | 1.05% | 5382 | [EMAIL PROTECTED] 1.15% |1 | 1.05% | 5374 | [EMAIL PROTECTED] 1.15% |1 | 1.02% | 5233 | [EMAIL PROTECTED] 1.15% |1 | 1.01% | 5186 | [EMAIL PROTECTED] 1.15% |1 | 1.01% | 5172 | [EMAIL PROTECTED] 1.15% |1 | 0.92% | 4724 | [EMAIL PROTECTED] 1.15% |1 | 0.90% | 4633 | [EMAIL PROTECTED] 1.15% |1 | 0.84% | 4319 | [EMAIL PROTECTED] 1.15% |1 | 0.82% | 4231 | [EMAIL PROTECTED] 1.15% |1 | 0.82% | 4205 | [EMAIL PROTECTED] 1.15% |1 | 0.81% | 4181 | [EMAIL PROTECTED] 1.15% |1 | 0.79% | 4040 | [EMAIL PROTECTED] 1.15% |1 | 0.77% | 3979 | [EMAIL PROTECTED] +--++--+ 100.00% | 87 |100.00% | 514113 | Total ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
Hello; On Aug 17, 2006, at 8:44 PM, Randall Gellens wrote: At 6:46 AM -0700 7/17/06, Andy Bierman wrote: Marshall Eubanks wrote: Nobody flies from LAX to San Diego because it ends up taking twice as long as driving for 10 times as much, so don't expect lots of flights from LA. I fly between LAX and San Diego fairly often. There are two airlines that offer flights at least every hour throughout the day. During some periods the flights are every half hour. You can generally connect in LAX without going through security again (unless arriving into LAX on an international flight). It doesn't really work to apply typical logic to airline fares. That is, you can't predict a fare based on Truer words were never typed. distance or number of connections. While it can be expensive to purchase a separate ticket between SAN and LAX, this is rarely done. Usually a the fare is from point A to SAN and back. In some cases it is slightly more than from point A to LAX and back, but often it is less. Sometimes it is a lot less. I'd be willing to believe that there are cases where it is a lot more, but I haven't personally seen them. When I have seen be a lot more is at the last minute from the East Coast (alas, the form of much of my business travel). All I am saying is, if the last minute fare to San Diego is too pricey, try LAX or Long Beach or John Wayne and consider the drive. Of course, no one who lives in the LA basin is likely to need our help on how to get to San Diego, so I was thinking about people flying in from far away. I'm a great believer in the train between SAN and LA, by the way. I've taken it a number of times and always prefer it to driving. Note that for a slight extra charge you can get an upgrade to 'custom class' where you get a larger seat, a power outlet, and something called a snack. There are terrific views of the pacific ocean and beaches during the latter half of the trip, and for much of it the train is right on the sand. I have heard that this is one of the best train trips in the US, and I have always wanted to take it, especially at Sunset. Can you get it near the coast (more specifically, near one of the 3 coastal airports), or do you have to go all the way to Union Station ? The immigration checkpoint seems to be dormant for a year or so now. The electronic pass lanes have been turned off, the signs warning you to be prepared to stop have been removed, the officers standing in the lanes inspecting cars are gone. The main structure is still there, and there are still border patrol cars at the sides, but that's it. Interesting, given other news. -- Randall Gellens Regards Marshall Opinions are personal;facts are suspect;I speak for myself only -- Randomly-selected tag: --- As you know, any depiction of nasal mucus brings with it problems for our sales division. --ABC's Broadcast Standards Practices board, to producers of the cartoon Bump in the Night ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: L2VPNs must not be IP(v4)-only
[followup to a reply that wasn't cc'ed to the IETF list, but I think it's relevant for the broader audience ] Two of the fundamental tenets of education is: a) a willingness to learn; and, more importantly, b) a willingness to teach/lead/show others. No one in the L2VPN WG has expressed an unwillingness to learn about IPv6; instead, no one within the WG (modulo Giles; thanks Giles!), or elsewhere, has expressed a willingness to lead the group in developing the requisite features required to support IPv6 wrt ARP-MED. Unfortunately, your impudent message has not demonstrated a willingness to help lead the group wrt IPv6 support, leaving us no further ahead than where we were before. It would be much more productive if you could help contribute to the solution, rather than cast broad criticism against the WG. My message was not directed specifically to L2VPN. Really it was a statement about IETF and the qualifications to do engineering in this space. Several years ago when I was an AD I was shocked to find that the principal participants in one of my working groups really didn't know what IP was and only had the vaguest understanding of TCP. They didn't know about the limitations of remote procedure calls or the idiosyncrasies of slow-start and congestion control; they didn't know anything about security or scalability. Based on this lack of knowledge, they had somehow decided that it was okay to run all of their traffic over HTTP, using a remote procedure call paradigm, to use port 80 as a default port, to not have any authentication in their protocol and to expect network administrators to filter traffic for their protocol at firewalls (because in their minds nobody would ever want to use their protocol across administrative domains, nothing wrong with using IP addresses as authentication tokens, and no reason why a network admin wouldn't want to enumerate every one of the devices running this protocol and block each one's address individually). In other words, they were completely (and aggressively) clueless about the field of endeavor they had adopted - and furthermore they thought it was someone else's job to teach them how to do the engineering that they had agreed to do. Frankly, I found this unacceptable, and I still do. I'm not accusing L2VPN of being that bad or anywhere nearly that bad. I am not familiar with the work that you've done and don't expect to take the time to review it. But the fact that you didn't consider IPv6 in your initial design certainly raises a red flag (didn't this come up in the problem definition phase?), as does the apparent expectation that IPv6 experts should help you design that part of the protocol. If I were still an AD I would be making a mental note that your documents should receive extra scrutiny during review, as such statements cast doubt on the group's competency. On the other hand if the group had said to IESG, well before Last Call, we understand that IPv6 is important, and we have this draft spec for how to do L2VPN for IPv6, based on our imperfect understanding of the IPv6 and RD/ND protocols, and we have some questions about whether we did it right, and we want someone to check it for sanity before we invest too much into it, I'd be thinking that the group really had its act together. IETF is not an educational organization, it is an engineering organization. Among the fundamental aspects of the discipline of engineering are ability to define requirements, perform analysis, read component specifications, synthesize designs, and predict the behavior of those designs. When I went to school to learn electrical engineering I wasn't given a tremendous amount of help in how to use specific components like transistors or transformers; rather I was taught how to do circuit analysis, and given circuits that modeled the behavior of those components. I was then expected to use circuit analysis skills to model how a more complex circuit using those components would function, and finally, to design circuits according to certain specifications and using those components. Similar processes were used by my friends in other engineering disciplines, and I don't see why network protocol engineers should not at least attempt to analyze the effects of using combinations of network protocols and to predict the behavior of new combinations of network protocols. In this case, there are specifications for IPv6 and router/neighbor discovery that are freely available for anyone to read. Perhaps they're not basic reading material for just anyone, but they are not overly complex. I don't see why people who are qualified to be IETF participants shouldn't be able to read and understand them and at least tentatively base designs on them. There might be some aspects of the v6 protocols that are hard to understand, but surely it is easier to find IPv6 experts to answer specific questions than
IETF 2006/07 NomCom Volunteers
A total of 69 noble and eligible souls volunteered this year. Thanks in advance to all those who volunteered! Andrew -- Brian Haberman Brian Rosen Carl Williams Cengiz Alaettinoglu Dan Li Dan Wing Dave Crocker Dave Meyer Derek Atkins Dimitri Papadimitriou Donald Eastlake Dorothy Gellert Eliot Lear Enrico Marocco Eric Gray Gargi Nalawade George Swallow Glen Zorn Hao Zhou Henk Uijterwaal Henrik Levkowetz JP Vasseur Jaap Akkerhuis Jani Hautakorpi Jim Martin Joel Halpern John Drake Juergen Quittek Kari Laihonen Kurt Zeilenga Liqiang Zhu Luca Martini Madjid Nakhjiri Mahalingam Mani Marcelo Bagnulo Braun Mark Allman Markus Isomaki Martin Stiemerling Mary Barnes Maximilian Riegel Michael Richardson Miguel Garcia Monique Morrow Ole Jacobsen Olle Viktorsson Pete Resnick Petri Jokela Randall Gellens Richard Shockey Robert Hinden Robert Jaksa Russ White Scott Brim Shinta Sugimoto Simon Leinen Spencer Dawkins Stefano Previdi Stephen Farrell Stephen Kent Stephen Nadas Suresh Krishnan Ted Seely Thomas Nadeau Tom Taylor Vidya Narayanan Vijay Devarapalli Wassim Haddad Yakov Rekhter Yi Zhao ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Selection of 2006/07 NomCom Members
The following volunteers have been selected as voting members of NomCom2006/07: Derek Atkins Ole Jacobsen Richard Shockey John Drake Maximilian Riegel Stefano Previdi Miguel Garcia Juergen Quittek Jaap Akkerhuis Randall Gellens The non-voting members are: Andrew Lange (Chair) Olaf Kolkman (IAB Liaison) Cullen Jennings (IESG Liaison) TBD (ISOC Liaison) Ralph Droms (Previous Chair/Advisor) I will post a call for nominees for the positions to be filled by NomCom06 shortly. If you have any questions or comments, please post them to [EMAIL PROTECTED] or to [EMAIL PROTECTED] Thank you, Andrew -- Numbered List of Volunteers === 1 Brian Haberman 2 Brian Rosen 3 Carl Williams 4 Cengiz Alaettinoglu 5 Dan Li 6 Dan Wing 7 Dave Crocker 8 Dave Meyer 9 Derek Atkins 10 Dimitri Papadimitriou 11 Donald Eastlake 12 Dorothy Gellert 13 Eliot Lear 14 Enrico Marocco 15 Eric Gray 16 Gargi Nalawade 17 George Swallow 18 Glen Zorn 19 Hao Zhou 20 Henk Uijterwaal 21 Henrik Levkowetz 22 JP Vasseur 23 Jaap Akkerhuis 24 Jani Hautakorpi 25 Jim Martin 26 Joel Halpern 27 John Drake 28 Juergen Quittek 29 Kari Laihonen 30 Kurt Zeilenga 31 Liqiang Zhu 32 Luca Martini 33 Madjid Nakhjiri 34 Mahalingam Mani 35 Marcelo Bagnulo Braun 36 Mark Allman 37 Markus Isomaki 38 Martin Stiemerling 39 Mary Barnes 40 Maximilian Riegel 41 Michael Richardson 42 Miguel Garcia 43 Monique Morrow 44 Ole Jacobsen 45 Olle Viktorsson 46 Pete Resnick 47 Petri Jokela 48 Randall Gellens 49 Richard Shockey 50 Robert Hinden 51 Robert Jaksa 52 Russ White 53 Scott Brim 54 Shinta Sugimoto 55 Simon Leinen 56 Spencer Dawkins 57 Stefano Previdi 58 Stephen Farrell 59 Stephen Kent 60 Stephen Nadas 61 Suresh Krishnan 62 Ted Seely 63 Thomas Nadeau 64 Tom Taylor 65 Vidya Narayanan 66 Vijay Devarapalli 67 Wassim Haddad 68 Yakov Rekhter 69 Yi Zhao Shares traded on 2006-08-15 (as reported in Wall Street Journal, 2006-08-16) Listing Volume Rounded (100s) (1000s) American Greetings (AM) 4094 409 Canon ADR (CAJ) 945 95 Clorox (CLX) 9868 987 Ingram Micro (IM) 5861 586 Monsanto (MON) 14511 1451 NY Times (NYT) 12336 1234 Office Depot (ODP) 23837 2384 Steinway (LVB) 225 23 Electronic Arts (ERTS) 35604 3560 Gilead Sciences (GILD) 38944 3894 Papa Johns (PZZA) 1962 196 Ryanair ADR (RYAAY) 1048 105 Publicly Verifiable Random Selection Based on RFC3797 [EMAIL PROTECTED] nomcom2006]$ ./selection Type size of pool: (or 'exit' to exit) 69 Type number of items to be selected: (or 'exit' to exit) 16 Approximately 50.9 bits of entropy needed. Type #1 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 409 409 Type #2 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 95 95 Type #3 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 987 987 Type #4 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 586 586 Type #5 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 1451 1451 Type #6 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 1234 1234 Type #7 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 2384 2384 Type #8 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 23 23 Type #9 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 3560 3560 Type #10 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 3894 3894 Type #11 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 196 196 Type #12 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. 105 105 Type #13 randomness or 'end' followed by new line. Up to 16 integers or the word 'float' followed by up to 16 x.y format reals. end Key is: 409./95./987./586./1451./1234./2384./23./3560./3894./196./105./ index hex value of MD5 div selected 1 6CCBF0D8B6A7D69A4104745E202A2F6E 69 - 9 - 2 9487A9845C3A1572C8D0299239422C5E 68 - 44 - 3 3083B4057D51E21CF90E49B28318ADF0 67 - 49 - 4 EB5FE1AC8815C437F3D8FFBCE284258F 66 - 27 - 5 14F1A256D1DAAE59EC5A6302C12709FA 65 - 40 - 6 F094D776EDEDA05E61EB0D4D0B54D333 64 - 57 - 7 5A6EF71A4E5D999C311186574F936EB5 63 - 42 - 8 38EADFB4306A5C84ECC3F9D37391EA69 62 - 28 - 9 7F1289CD734B46743CF8F8C2C12517F6 61 - 23 - 10 897F6B106F6BF15F1AB2CF70466E955C 60 - 48 - 11 592C59FE60877B63BB96EB768F567913 59
WG Action: Conclusion of New IETF Standards Track Discussion (newtrk)
The New IETF Standards Track Discussion WG (newtrk) in the General Area has concluded. The IESG contact person is Brian Carpenter. The mailing list will remain active. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4649 on Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option
A new Request for Comments is now available in online RFC libraries. RFC 4649 Title: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option Author: B. Volz Status: Standards Track Date: August 2006 Mailbox:[EMAIL PROTECTED] Pages: 6 Characters: 10940 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-dhc-dhcpv6-remoteid-01.txt URL:http://www.rfc-editor.org/rfc/rfc4649.txt This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. [STANDARDS TRACK] This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
