Re: jabber logs into working group mailing list archives?
Dave CROCKER wrote: > IETF meeting jabber sessions often hold some very useful gems. And at > their worst, each one isn't all that big. > > It occurs to me that we should try to fold them into the regular email > archive, perhaps simply by sending the wg mailing list a copy afterwards? makes sense to me... provided the participants are informed in advance. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber logs into working group mailing list archives?
On Apr 1, 2009, at 2:43 AM, Dave CROCKER wrote: IETF meeting jabber sessions often hold some very useful gems. And at their worst, each one isn't all that big. It occurs to me that we should try to fold them into the regular email archive, perhaps simply by sending the wg mailing list a copy afterwards? Some groups make heavy use of their jabber account - the MMOX BOF comes to mind - not just during a formal meeting. It would make sense to archive this on a daily basis; I would suggest sending the daily archive to the mail list like a mail archive, at least as an option. Regards Marshall d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
End to end NAT
Dear All; Attached is a draft internet draft on end to end NAT. As is discussed in draft-iab-ipv6-nat-00.txt: If the translation is reversible, and the translation is indeed reversed by the time it reaches the other end of communication, then end- to-end transparency can be provided. However if the two translators involved are owned by different organizations, then solutions are harder to incrementally deploy due to the incentive and coordination issues involved. NAT can be end to end and an ISP and its customer do have the incentive to coordinate two translators: an ISP's NAT gateway and a costomer's end. Have a happy april fools day. Masataka Ohta . INTERNET DRAFT M. Ohta draft-ohta-e2e-nat-00.txt Tokyo Institute of Technology April 2009 End to End NAT Status of this Memo This memo is a draft Internet Draft. Redistribution of this memo is unlimited. Abstract By making NAT visible to ends and let the ends help NAT gateways, NAT can be correct, complete, and fully transparent at the transport layer and above. 1. Introduction NAT (Network Address Translation) is a technique to suppress address space consumption by sharing an IP address by multiple hosts at different times or, more practically, at the same time with different port numbers. According to the end to end argument [SALTZER], The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) NAT can completely and correctly be implemented only with the knowledge and help of ends. However, legacy NAT was designed to be transparent to ends that the ends can not help NAT gateways. As a result, legacy NAT is incomplete and incorrect in various ways. E2ENAT (End to end NAT) is a NAT, configuration of which is visible to ends so that the ends can, with their knowledge, help NAT gateways by reversing address translation at the ends and maintain state of NAT gateways, which makes NAT operations complete and correct. 2. Operation of End to End NAT M. OhtaExpires on October 1, 2009 [Page 1] INTERNET DRAFT End to End NAT April 2009 Dependeing on how port numbers are shared, there are static and dynamic E2ENAT or combinations of them. With static E2ENAT, an end is assigned port numbers statically, which is necessary for a server with a stable IP address and a port number. With dynamic E2ENAT, ends dynamically share port numbers, which is useful if a small number of port numbers are shared by many ends, which could be the case with nested E2ENAT. With E2ENAT, an end and a NAT gateway share knowledge of NAT configuration: a private IP address, a public IP addresses and public port numbers assigned to the end. DHCP and PPP options may be useful to give the ends NAT configuration information. A private IP address and a UDP port number of a NAT gateway for dynamic NAT control may also be given. As for incoming packets, a NAT gateway translates a public unicast destination address of the packets to private destination addresses based on the destination port number assigned to ends, without modifying transport information such as port numbers and checksums. An end translates private destination addresses of incoming packets to public destination addresses, unless the source addresses of the packets are not within address ranged used by a private network, which restores correctness of transport checksum. Multicast addresses should be shared unmodified between a public and a private networks. As for outgoing packets, after transport processing including checksum calculation, an end translates a public source address of outgoing unicast packets to a private address of the end. A NAT gateway translates private source addresses of the outgoing packets to a public source address (if the gateway manages multiple public addresses, the one corresponding to the private source address), unless destination address of the packets are private address of the NAT gateway, regardless of whether the source port number actually belongs to an end of the private address. Validity of the source port is expected to be, if necessary, verified end to end with a three wa
Re: jabber logs into working group mailing list archives?
Dave CROCKER wrote: IETF meeting jabber sessions often hold some very useful gems. And at their worst, each one isn't all that big. When I've chaired working groups I've found the Jabber logs to be invaluable for help putting together minutes, and occasionally for clarifying post-meeting questions. However, at their worst they barely exist - not all sessions have been successful at finding volunteers to help with scribing, and not all chairs have been paying attention to it, frankly. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NAT Behavior Discovery Using STUN) to Experimental RFC
Cullen, I will respond to your comment on a high level. I think the applicability statement on this document is correct and clear that this will not work all the time. You seem to want to press the point that there is no meaning for a mechanism unless it is always correct. I don't agree with that view, and because of that I found is suitable to last call. The uncertainty in its usefulness is why it is labeled experimental. I do like to see input from more individuals before determining consensus if this document should be moving forward or be blocked. I would also like to see the authors comment on the individual points. It seems likely that document changes are needed if we are progressing this to IESG review. Best Regards Magnus Cullen Jennings skrev: > > I was somewhat shocked to see the draft in IETF Last Call. The last time > this draft was discussed at the microphone in Behave, many people were > very concerned that it id not possible to correctly characterize a NAT > without using more than one address behind the NAT. The tests done on on > NATs by the researches at MIT did that, so did the the stuff from > Cornell, as did draft-jennings-behave-test-results. The reason why this > was needed is largely the reason why the IETF invented ICE. Initially > folks thought that STUN alone would be enough to do NAT traversal. This > turned out not to be true, STUN deprecated those parts and ICE was > started. This draft fails to describe the types of test that have > actually been found to work and just reinstates the stuff that was > deployed and failed and then deprecated out of STUN. > > Now this draft pays some lip service to the fact that it basically won't > work. You can read section 1 and get the full idea. The first and 2'nd > par basically say this won't work. Then para 3 proposes this is > experiment to find out something we already know the answer to. When > this work was chartered, it was about making a way to characterize NATs > and describe them in a controlled lab like environment. It was not about > resurrecting exactly the part of STUN that had been tried, failed , and > deprecated. > > Specific problems with the draft > > 2.2 - this just won't work. The test described in this draft will not > find out if the node is behind an endpoint independent nat. I have > specific nats where it won't work. I have explained to the authors why > it won't work. The answer I get back is "it might work some of the > time". It true it might work some of the time but we all agree there are > many NATs for which it will not work. > > Other section that don't work are 3.1, 3.2, 3.3, 3.4, 3.5, 3.5 - uh all > of them actually. I'm glad to provide details on why they don't work but > I have in the past and we not really debating if they work or not. The > authors believe there is sufficient text at the beginning of the draft > in section 1 that it is OK that these fail in many cases and don't need > to be mentioned again. We not debating these work some of the but not > all the time - everyone agrees on that. > > Section 4.1 - The results in here will be just wrong for ports different > than the one the test was run on. The response to this was to add "use > same port when possible". That's not going to exactly cause applications > to work. > > Section 4.2 - Can't really separate the topic from if UDP is blocked > from if the STUN server is down. > > Section 4.4 - this fails if the port was recently used for similar tests > from same stun server. There no way to know this as an application. This > type of test can work in lab condition where all traffic on NAT is > controlled but it operational networks it will fail. > > It is possible to do timing testing using just the change ip flag. The > REPSONSE-TARGET stuff is not needed and open up the possibility to have > a STUN server send packets to places that it should not which causes IDS > system to black list all traffic from the STUN server thus making it > unusable for other clients. The ability to tell the STUN server to send > packets to arbitrary locations would be fine for a system in a lab used > to characterize a NAT but is not a good idea for internet deployed STUN > servers. > > The bulk of these issues were sent Aug 28 to behave list during the 2nd > WGLC. I requested agenda time during IETF 74 to discuss these issues but > it was denied. > > In summary -The approaches described in this draft are known to fail > with many NATs. I don't see any evidence of the WG actually having read > this draft much less have consensus on the approach in it. I think the > WG should spend meeting time to discuss the topic and decide what to do. > The key topic in my mind is we are defining a document that allows us to > characterize a NAT in a lab or if we are trying to make something that > works in field and can be used to aid NAT traversal in applications. > > Cullen > > > > > > On Mar 10, 2009, at 8:44 AM, The IESG wrote: > >> The IESG h
Re: jabber logs into working group mailing list archives?
Excerpts from Dave CROCKER on Tue, Mar 31, 2009 11:43:29PM -0700: > IETF meeting jabber sessions often hold some very useful gems. And > at their worst, each one isn't all that big. > > It occurs to me that we should try to fold them into the regular > email archive, perhaps simply by sending the wg mailing list a copy > afterwards? +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber logs into working group mailing list archives?
IETF meeting jabber sessions often hold some very useful gems. And at their worst, each one isn't all that big. It occurs to me that we should try to fold them into the regular email archive, perhaps simply by sending the wg mailing list a copy afterwards? I would like to see this, and if we expect it to happen, I'd suggest automating it. Should be simple enough (assume IETF Plenary goes to ietf@ietf.org, and there probably are some other corner cases to consider before implementing). My only caveat is that the current jabber logs include entries for days where nothing happened - both zero-byte entries and "Dan York entered the room", to mention one entry in recent mediactrl logs. I'd suggest a minimum size for this - not huge, maybe 1000 bytes? - if we get serious about doing it. Ripping out the "entered"/"left" entries would be nice, but that's the next level. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: End to end NAT
Dear profesionals, You may be just proposing a social security hole, I think.?An idea of End-to-end is too primitive like monkey world. I recommend an idea of family-to-family. At first, a nation should be considered as a set of home, right? In other words, as you may know, according to the theorem of Social Contract by Jean-Jacques Rousseau, fundamental unit of a nation is a set of an idea of family. Specifications of any information system must be based upon such kinds of fundamental insight of civilization, even if it is related to military usage, I think. There is no need to say, the solution of where the legs of table are located under the board of table could be an element of a patent, similar to this, the resolution where authorities for controlling, modifying, observing and distributing information should be located could be a kind of invention about social science. Without considering such point of view, any specification could be a kind of delusion or fantasy, I think. Considering the differences between Traditional Newspaper and Internet News, deliverer of newspaper know who are reading this according to "family register" or "KOSEKI", on the other hand, deliverer of internet news know nothing about readers. That's the fundamental question to solve, I think. We should remember the faces of our local politicians and what their saying, I think. Abraham TaddyHatty taddyhatty at acm dot org Dear All; Attached is a draft internet draft on end to end NAT. As is discussed in draft-iab-ipv6-nat-00.txt: If the translation is reversible, and the translation is indeed reversed by the time it reaches the other end of communication, then end- to-end transparency can be provided. However if the two translators involved are owned by different organizations, then solutions are harder to incrementally deploy due to the incentive and coordination issues involved. NAT can be end to end and an ISP and its customer do have the incentive to coordinate two translators: an ISP's NAT gateway and a costomer's end. Have a happy april fools day. Masataka Ohta . INTERNET DRAFT M. Ohta draft-ohta-e2e-nat-00.txt Tokyo Institute of Technology April 2009 End to End NAT Status of this Memo This memo is a draft Internet Draft. Redistribution of this memo is unlimited. Abstract By making NAT visible to ends and let the ends help NAT gateways, NAT can be correct, complete, and fully transparent at the transport layer and above. 1. Introduction NAT (Network Address Translation) is a technique to suppress address space consumption by sharing an IP address by multiple hosts at different times or, more practically, at the same time with different port numbers. According to the end to end argument [SALTZER], The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) NAT can completely and correctly be implemented only with the knowledge and help of ends. However, legacy NAT was designed to be transparent to ends that the ends can not help NAT gateways. As a result, legacy NAT is incomplete and incorrect in various ways. E2ENAT (End to end NAT) is a NAT, configuration of which is visible to ends so that the ends can, with their knowledge, help NAT gateways by reversing address translation at the ends and maintain state of NAT gateways, which makes NAT operations complete and correct. 2. Operation of End to End NAT M. OhtaExpires on October 1, 2009 [Page 1] INTERNET DRAFT End to End NAT April 2009 Dependeing on how port numbers are shared, there are static and dynamic E2ENAT or combinations of them. With static E2ENAT, an end is assigned port numbers statically, which is necessary for a server with a stable IP address and a port number. With dynamic E2ENAT, ends dynamically share port numbers, which is useful if a small number of port numbers are shared by many ends, which could be the case with nested E2ENAT. With E2ENAT, an end and a NAT gateway share knowledge of NAT configuration: a private IP address, a public IP addresses and public port numbers assigned to the end. DHCP and PPP options may be useful to give the ends NAT configuration information. A private IP address and a UDP port number of a NAT gateway for dynamic NAT control may also be given.
Re: jabber logs into working group mailing list archives?
Scott Brim - le (m/j/a) 4/1/09 2:37 PM: Excerpts from Dave CROCKER on Tue, Mar 31, 2009 11:43:29PM -0700: IETF meeting jabber sessions often hold some very useful gems. And at their worst, each one isn't all that big. It occurs to me that we should try to fold them into the regular email archive, perhaps simply by sending the wg mailing list a copy afterwards? +1 +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber logs into working group mailing list archives?
Spencer Dawkins wrote: It occurs to me that we should try to fold them into the regular email archive, perhaps simply by sending the wg mailing list a copy afterwards? I would like to see this, and if we expect it to happen, I'd suggest automating it. Should be simple enough (assume IETF Plenary goes to ietf@ietf.org, and there probably are some other corner cases to consider before implementing). Having it be fully automated would indeed be very nice. My only caveat is that the current jabber logs include entries for days where nothing happened - both zero-byte entries and "Dan York entered the room", to mention one entry in recent mediactrl logs. If there is a tradeoff between having the submission be automated versus having a submission per day, with all but one being empty, I'd prefer the automation: 1. This is about reliability and it's a lot better to take humans out of the action sequence. 2. The overhead to the mailing list recipients of getting an IETF week daily posting of empty jabber scripts would be a lot lower than the postings from some active mailing list participants with far less positive value add... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber logs into working group mailing list archives?
Good point. If we are serious about this, automating it is the only reasonable path. I like the idea of a minimum size for automatic submission. If it is short but really important (e.g., "The AD closed the wg."), then we can always manually submit the jabber log. On Apr 1, 2009, at 9:48 AM, Spencer Dawkins wrote: IETF meeting jabber sessions often hold some very useful gems. And at their worst, each one isn't all that big. It occurs to me that we should try to fold them into the regular email archive, perhaps simply by sending the wg mailing list a copy afterwards? I would like to see this, and if we expect it to happen, I'd suggest automating it. Should be simple enough (assume IETF Plenary goes to ietf@ietf.org , and there probably are some other corner cases to consider before implementing). My only caveat is that the current jabber logs include entries for days where nothing happened - both zero-byte entries and "Dan York entered the room", to mention one entry in recent mediactrl logs. I'd suggest a minimum size for this - not huge, maybe 1000 bytes? - if we get serious about doing it. Ripping out the "entered"/"left" entries would be nice, but that's the next level. Thanks, Spencer ___ 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
jabber URL at the bottom of mailing list traffic?
while we're on the subject of better integration between mailing lists and jabber, how about having the trailer at the bottom of every message that is posted to an IETF WG list, include a URL that points to the jabber chat room for that WG? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber URL at the bottom of mailing list traffic?
Keith Moore writes: > while we're on the subject of better integration between mailing lists > and jabber, how about having the trailer at the bottom of every message > that is posted to an IETF WG list, include a URL that points to the > jabber chat room for that WG? Is more boiler plate texts the answer to everything? I believe Jabber comments are legally IETF contributions, so posting the jabber log to every WG after the IETF week (or more often) seems like a good thing to make jabber statements archived and searchable in a better way. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF NomCom Changes Discussion
Several changes to the NomCom process were discussed during the plenary session last Wednesday. The minutes have been posted so that anyone that was not at the plenary session can catch up. The minutes can be found here: http://www.ietf.org/proceedings/09mar/minutes/plenaryw.txt The discussion will continue on the ietf-nom...@ietf.org mail list. Thanks, Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber logs into working group mailing list archives?
Excerpts from Tim Polk on Wed, Apr 01, 2009 10:53:38AM -0400: > Good point. If we are serious about this, automating it is the only > reasonable path. but to start with maybe the chairs could send it out by hand? They submit the meeting notes by hand. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: End to end NAT
Tadayuki Abraham HATTORI wrote: Dear profesionals, You may be just proposing a social security hole, I think.?An idea of End-to-end is too primitive like monkey world. I recommend an idea of family-to-family. At first, a nation should be considered as a set of home, right? In other words, as you may know, according to the theorem of Social Contract by Jean-Jacques Rousseau, fundamental unit of a nation is a set of an idea of family. Specifications of any information system must be based upon such kinds of fundamental insight of civilization, even if it is related to military usage, I think. Reminds me of that classic riff from "In the Beginning" by the Moody Blues: "I think. I think I am. Therefore I am. I think." ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber logs into working group mailing list archives?
if `egrep -v 'joins the room|leaves the room' log | wc -l` > 0 post log Translation: if, after removing the "joins the room" and "leaves the room" messages are removed, you wind up with anything left, post the log. This would eliminate almost all of the logs that have no substantive information. Tony Hansen t...@att.com Spencer Dawkins wrote: >> IETF meeting jabber sessions often hold some very useful gems. And at >> their >> worst, each one isn't all that big. >> >> It occurs to me that we should try to fold them into the regular email >> archive, >> perhaps simply by sending the wg mailing list a copy afterwards? > > I would like to see this, and if we expect it to happen, I'd suggest > automating it. Should be simple enough (assume IETF Plenary goes to > ietf@ietf.org, and there probably are some other corner cases to > consider before implementing). > > My only caveat is that the current jabber logs include entries for days > where nothing happened - both zero-byte entries and "Dan York entered > the room", to mention one entry in recent mediactrl logs. > > I'd suggest a minimum size for this - not huge, maybe 1000 bytes? - if > we get serious about doing it. > > Ripping out the "entered"/"left" entries would be nice, but that's the > next level. > > Thanks, > > Spencer > > ___ > 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: IETF NomCom Changes Discussion
Hi, Russ, I may have misunderstood (I was presenting, so not taking good notes during the NomCom discussions), but I'm looking at Russ asks who believes that we need to do anything that describes what is acceptable NomCom behaviour. many hums Russ asks who doesn't believe this is necessary? a few more hums and remembering that this part of the conversation was about behavior beyond the NomCom (lobbying, etc) - behavior of nominees, behavior of people who have opinions about the people on the nominee list, etc. This was certainly my understanding from Leslie's post on "openlist", on the NomCom mailing list. Should I go listen to the audio? Thanks, Spencer Several changes to the NomCom process were discussed during the plenary session last Wednesday. The minutes have been posted so that anyone that was not at the plenary session can catch up. The minutes can be found here: http://www.ietf.org/proceedings/09mar/minutes/plenaryw.txt The discussion will continue on the ietf-nom...@ietf.org mail list. Thanks, Russ ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF NomCom Changes Discussion
I believe the hum was about "lobbying" behavior of the candidates on the open list toward NomCom and the rest of the community. Russ At 12:38 PM 4/1/2009, Spencer Dawkins wrote: Hi, Russ, I may have misunderstood (I was presenting, so not taking good notes during the NomCom discussions), but I'm looking at Russ asks who believes that we need to do anything that describes what is acceptable NomCom behaviour. many hums Russ asks who doesn't believe this is necessary? a few more hums and remembering that this part of the conversation was about behavior beyond the NomCom (lobbying, etc) - behavior of nominees, behavior of people who have opinions about the people on the nominee list, etc. This was certainly my understanding from Leslie's post on "openlist", on the NomCom mailing list. Should I go listen to the audio? Thanks, Spencer Several changes to the NomCom process were discussed during the plenary session last Wednesday. The minutes have been posted so that anyone that was not at the plenary session can catch up. The minutes can be found here: http://www.ietf.org/proceedings/09mar/minutes/plenaryw.txt The discussion will continue on the ietf-nom...@ietf.org mail list. Thanks, Russ ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber URL at the bottom of mailing list traffic?
Simon Josefsson wrote: > Keith Moore writes: > >> while we're on the subject of better integration between mailing lists >> and jabber, how about having the trailer at the bottom of every message >> that is posted to an IETF WG list, include a URL that points to the >> jabber chat room for that WG? > > Is more boiler plate texts the answer to everything? of course not. but I wasn't trying to answer "everything". I was suggesting a way to make it easier for WG participants who are exchanging messages via email to drop into a Jabber chat to get better interaction. do you really have a problem with that? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF NomCom Changes Discussion
Your memory matches mine. Do the notes need to reflect "nominee" behavior, instead of "NomCom" behavior? Just to make sure we're on the same page ... Joel reminded me after I'd already submitted a couple of versions of openlist that you're a nominee if NomCom is considering you, a candidate if NomCom is submitting you to a confirming body, and a successful candidate if the confirming body confirms you - so I'm assuming that you meant "nominee" in your post. Please let me know if you meant "candidate", of course. From 3777 Section 2: candidate: A nominee who has been selected to be considered for confirmation by a confirming body. confirmed candidate: A candidate that has been reviewed and approved by a confirming body. nominee: A person who is being or has been considered for one or more open positions of the IESG or IAB. Thanks, Spencer I believe the hum was about "lobbying" behavior of the candidates on the open list toward NomCom and the rest of the community. Russ At 12:38 PM 4/1/2009, Spencer Dawkins wrote: Hi, Russ, I may have misunderstood (I was presenting, so not taking good notes during the NomCom discussions), but I'm looking at Russ asks who believes that we need to do anything that describes what is acceptable NomCom behaviour. many hums Russ asks who doesn't believe this is necessary? a few more hums and remembering that this part of the conversation was about behavior beyond the NomCom (lobbying, etc) - behavior of nominees, behavior of people who have opinions about the people on the nominee list, etc. This was certainly my understanding from Leslie's post on "openlist", on the NomCom mailing list. Should I go listen to the audio? Thanks, Spencer Several changes to the NomCom process were discussed during the plenary session last Wednesday. The minutes have been posted so that anyone that was not at the plenary session can catch up. The minutes can be found here: http://www.ietf.org/proceedings/09mar/minutes/plenaryw.txt The discussion will continue on the ietf-nom...@ietf.org mail list. Thanks, Russ ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber logs into working group mailing list archives?
Jabber logs are already part of the proceedings. For example, this URL provides the jabber logs for the IETF 73 in Minneapolis: http://www.ietf.org/proceedings/08nov/index.html The Secretariat is looking at some changes to the proceedings, and I have asked them to put the jabber log and the audio stream for the session in the same place as the minutes and slides. I think this will make them easier to locate. Hopefully this reorganization will happen in time for IETF 75's proceedings. Russ On Apr 1, 2009, at 9:48 AM, Spencer Dawkins wrote: IETF meeting jabber sessions often hold some very useful gems. And at their worst, each one isn't all that big. It occurs to me that we should try to fold them into the regular email archive, perhaps simply by sending the wg mailing list a copy afterwards? I would like to see this, and if we expect it to happen, I'd suggest automating it. Should be simple enough (assume IETF Plenary goes to ietf@ietf.org , and there probably are some other corner cases to consider before implementing). My only caveat is that the current jabber logs include entries for days where nothing happened - both zero-byte entries and "Dan York entered the room", to mention one entry in recent mediactrl logs. I'd suggest a minimum size for this - not huge, maybe 1000 bytes? - if we get serious about doing it. Ripping out the "entered"/"left" entries would be nice, but that's the next level. Thanks, Spencer ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: jabber logs into working group mailing list archives?
Please note that some groups use jabber more or less continuously, not just during a meeting. Regards Marshall On Apr 1, 2009, at 2:29 PM, Russ Housley wrote: Jabber logs are already part of the proceedings. For example, this URL provides the jabber logs for the IETF 73 in Minneapolis: http://www.ietf.org/proceedings/08nov/index.html The Secretariat is looking at some changes to the proceedings, and I have asked them to put the jabber log and the audio stream for the session in the same place as the minutes and slides. I think this will make them easier to locate. Hopefully this reorganization will happen in time for IETF 75's proceedings. Russ On Apr 1, 2009, at 9:48 AM, Spencer Dawkins wrote: IETF meeting jabber sessions often hold some very useful gems. And at their worst, each one isn't all that big. It occurs to me that we should try to fold them into the regular email archive, perhaps simply by sending the wg mailing list a copy afterwards? I would like to see this, and if we expect it to happen, I'd suggest automating it. Should be simple enough (assume IETF Plenary goes to ietf@ietf.org , and there probably are some other corner cases to consider before implementing). My only caveat is that the current jabber logs include entries for days where nothing happened - both zero-byte entries and "Dan York entered the room", to mention one entry in recent mediactrl logs. I'd suggest a minimum size for this - not huge, maybe 1000 bytes? - if we get serious about doing it. Ripping out the "entered"/"left" entries would be nice, but that's the next level. Thanks, Spencer ___ 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 ___ 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: IETF NomCom Changes Discussion
Spencer: I made the suggested change to the minutes. Russ At 01:34 PM 4/1/2009, Spencer Dawkins wrote: Your memory matches mine. Do the notes need to reflect "nominee" behavior, instead of "NomCom" behavior? Just to make sure we're on the same page ... Joel reminded me after I'd already submitted a couple of versions of openlist that you're a nominee if NomCom is considering you, a candidate if NomCom is submitting you to a confirming body, and a successful candidate if the confirming body confirms you - so I'm assuming that you meant "nominee" in your post. Please let me know if you meant "candidate", of course. From 3777 Section 2: candidate: A nominee who has been selected to be considered for confirmation by a confirming body. confirmed candidate: A candidate that has been reviewed and approved by a confirming body. nominee: A person who is being or has been considered for one or more open positions of the IESG or IAB. Thanks, Spencer I believe the hum was about "lobbying" behavior of the candidates on the open list toward NomCom and the rest of the community. Russ At 12:38 PM 4/1/2009, Spencer Dawkins wrote: Hi, Russ, I may have misunderstood (I was presenting, so not taking good notes during the NomCom discussions), but I'm looking at Russ asks who believes that we need to do anything that describes what is acceptable NomCom behaviour. many hums Russ asks who doesn't believe this is necessary? a few more hums and remembering that this part of the conversation was about behavior beyond the NomCom (lobbying, etc) - behavior of nominees, behavior of people who have opinions about the people on the nominee list, etc. This was certainly my understanding from Leslie's post on "openlist", on the NomCom mailing list. Should I go listen to the audio? Thanks, Spencer Several changes to the NomCom process were discussed during the plenary session last Wednesday. The minutes have been posted so that anyone that was not at the plenary session can catch up. The minutes can be found here: http://www.ietf.org/proceedings/09mar/minutes/plenaryw.txt The discussion will continue on the ietf-nom...@ietf.org mail list. Thanks, Russ ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: End to end NAT
Robert Moskowitz wrote: > Reminds me of that classic riff from "In the Beginning" by the Moody Blues: > > "I think. I think I am. Therefore I am. I think." I'm afraid he is just joking, though not very elegantly. :-) Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: End to end NAT
The repetition of "Eye-Think" is just a cultural humbleness. Everyone is my load. Let's sing a songs of democratic communication protocols. Robert Moskowitz wrote: Reminds me of that classic riff from "In the Beginning" by the Moody Blues: "I think. I think I am. Therefore I am. I think." I'm afraid he is just joking, though not very elegantly. :-) Masataka Ohta Abraham TaddyHatty ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF NomCom Changes Discussion
On Apr 1, 2009, at 10:34 AM, ext Spencer Dawkins wrote: Your memory matches mine. Do the notes need to reflect "nominee" behavior, instead of "NomCom" behavior? Just to make sure we're on the same page ... Joel reminded me after I'd already submitted a couple of versions of openlist that you're a nominee if NomCom is considering you, a candidate if NomCom is submitting you to a confirming body, and a successful candidate if the confirming body confirms you - so I'm assuming that you meant "nominee" in your post. Please let me know if you meant "candidate", of course. From 3777 Section 2: candidate: A nominee who has been selected to be considered for confirmation by a confirming body. confirmed candidate: A candidate that has been reviewed and approved by a confirming body. nominee: A person who is being or has been considered for one or more open positions of the IESG or IAB. or IAOC. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF NomCom Changes Discussion
yeah, that's the 3777bis-ish change ;-) Spencer On Apr 1, 2009, at 10:34 AM, ext Spencer Dawkins wrote: Your memory matches mine. Do the notes need to reflect "nominee" behavior, instead of "NomCom" behavior? Just to make sure we're on the same page ... Joel reminded me after I'd already submitted a couple of versions of openlist that you're a nominee if NomCom is considering you, a candidate if NomCom is submitting you to a confirming body, and a successful candidate if the confirming body confirms you - so I'm assuming that you meant "nominee" in your post. Please let me know if you meant "candidate", of course. From 3777 Section 2: candidate: A nominee who has been selected to be considered for confirmation by a confirming body. confirmed candidate: A candidate that has been reviewed and approved by a confirming body. nominee: A person who is being or has been considered for one or more open positions of the IESG or IAB. or IAOC. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: designate an email address for testing at any provider
Nick Levinson wrote: > I think you didn't mean domain. In that case, the catchall address > encourages delivery. I'm looking for a guaranteed bounce, for test > purposes, at any email service provider. Well know addresses tend to create opportunities for DOS. Two other issues, such an approach would make it easier to evaluate what criterion a system is using to accept mail, which many people obviously are reluctant to do. Secondly forging to sender produces the opportunity to DOS a third-party. > If you did mean domain, domains like example.com would give a > different result than sending to a real domain. > > The same address at any provider would be better. > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
