Two lost SecureID tokens have been found at the Crown Plaza Hotel. One was
found on the second floor today (Thursday), and the other was found
Wednesday evening in the lounge. They have been given to lost and found in
the hotel.
Andy Malis and Bert Wijnen
Folks -
I want to make a further comment about tonight's discussion about the site
and site logistics. I'd like to ask all of you to listen to the discussion
less as a bashing of the local host and the city and people of Vienna, and
more as I think it was intended - a critique of the site and
Tim Chown wrote:
> The IPv6 has also been good when I've tried - less than 10ms
> to hop onto either 6NET (for my home NREN access) or GEANT
> (for example for Japan) from the venue :)
I heared a lot of complaints to anything outside 6net/geant/dante though.
Watching the looking glasses rev
we need a few good wg chairs. expertise in one of v6, radius, or
wireless necessary. experience with operations and ietf process
are major plusses. ability to catch me in corridors is also a
plus :-)
randy
Randy's comments on the Vienna wireless at the IESG tonight are spot on.
The network's been great all week.
Given the WLAN problems seen in so many other events (IETF and otherwise)
could I ask that the network be publicly documented as a guide for those
providing WLAN in the future? It would
Jonathan Hogg wrote:
On 17/7/03 8:30, bill wrote:
I would have a hard time taking an IP header bit and making it the "Do
not drop this packet in the presense of a bit error somewhere in the
frame from layer 2 - layer 3". Don't think it is a good idea.
What if that bit got corrupted?
Th
On donderdag, jul 17, 2003, at 14:24 Europe/Amsterdam, Keith Moore
wrote:
] I would have a hard time taking an IP header bit and making it the
"Do
] not drop this packet in the presense of a bit error somewhere in the
] frame from layer 2 - layer 3". Don't think it is a good idea.
I don't know
Perhaps a simple COTS product would have satisfied
the local public safety authorities:
http://www.cableorganizer.com/cord-protector-flexiduct/
Gruesse, Carsten;
> > How would an app know to set this bit? The problem is that different
> > L2s will have different likelihoods of corruption; you may decide that
> > it's safe to set the bit on Ethernet, but not on 802.11*.
>
> Aah, there's the confusion. The apps we have in mind would thi
On Thu, 17 Jul 2003 10:00:42 +0200 Randy Bush <[EMAIL PROTECTED]> wrote:
> i received 81.160.221.53 via dhcp. but
>
> Host 53.221.160.81.in-addr.arpa not found: 3(NXDOMAIN)
:-(
Yes, I got the same result first. However, after enabling
my dhcp client to send my hostname, I obviously got a dynDN
] What bit is needed ?
]
] Again, this is a layer 2 property. If you want to receive layer 2
] frames with errors in them just get a Layer 2 device and tell it to not
] do the checksum calculation (much like you put an ethernet nic into
] Promiscous mode so it doesn't drop all of the frames not
Betts, Brungard, Dotaro, Grammel, Kompella, Papadimitriou, Prattico,
Sadler, Vigoureux and Zinin got together to iron out the last few
issues in the document "Routing Extensions in Support of GMPLS".
In the interests of progressing this document in a timely fashion,
we examined these issues from t
-BEGIN PGP SIGNED MESSAGE-
For what it is worth, the wavesec network has a reverse map.
Put:
option oe-key code 159 = string;
option oe-gateway code 160 = ip-address;
send oe-key = "16896 4 1 ";
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain
Date:Wed, 16 Jul 2003 22:18:57 +0200
From:Harald Tveit Alvestrand <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| However, I find the criticisms raised against the process leading to the
| forwarding of these documents to the IESG to be very much off target.
On Thu, 17 Jul 2003, Leif Johansson wrote:
> Randy Bush wrote:
>
> >>If you think that is strange I got 81.160.251.0 just now
> >>
> >>
> >
> >given the netmask, that is a perfectly legitimate interface
> >address
> >
> >randy
> >
> >
> >
> True but I'm not getting any traffic through thoug
On Thu, 17 Jul 2003, Leif Johansson wrote:
> Randy Bush wrote:
>
> >i received 81.160.221.53 via dhcp. but
> >
> >Host 53.221.160.81.in-addr.arpa not found: 3(NXDOMAIN)
> >
> >randy
> >
> >
> >
> >
> If you think that is strange I got 81.160.251.0 just now (!) but I am not
> sure it isn't poc
On Thu, 17 Jul 2003, Randy Bush wrote:
> > If you think that is strange I got 81.160.251.0 just now
>
> given the netmask, that is a perfectly legitimate interface
> address
Be glad it didn't give you 81.260.250.255 because some filter out all
addresses that end up with .255 :-)
Even in ISP bac
Randy Bush wrote:
If you think that is strange I got 81.160.251.0 just now
given the netmask, that is a perfectly legitimate interface
address
randy
True but I'm not getting any traffic through though...
In message <[EMAIL PROTECTED]>, Iljitsch van Beijn
um writes:
>
>Interesting aspect: it should be possible to make this work with IPsec
>encryption but not authentication, but not so well with ciphers in CBC
>mode. A stream cipher would be better here.
>
>
Here is the Security Considerations tex
> If you think that is strange I got 81.160.251.0 just now
given the netmask, that is a perfectly legitimate interface
address
randy
Randy Bush wrote:
i received 81.160.221.53 via dhcp. but
Host 53.221.160.81.in-addr.arpa not found: 3(NXDOMAIN)
randy
If you think that is strange I got 81.160.251.0 just now (!) but I am not
sure it isn't pocketpc 200x thumbing its nose at me :-)
Cheers Leif
On woensdag, jul 16, 2003, at 21:59 Europe/Amsterdam, Keith Moore wrote:
I'm not sure what the problem is here:
- UDP checksums are optional
Not in IPv6. If this is the only thing we need at the transport layer
then we might want to change this back to the IPv4 behavior.
- IPv6 could define an
On 17/7/03 8:30, bill wrote:
> I would have a hard time taking an IP header bit and making it the "Do
> not drop this packet in the presense of a bit error somewhere in the
> frame from layer 2 - layer 3". Don't think it is a good idea.
What if that bit got corrupted?
Jonathan
How would an app know to set this bit? The problem is that different
L2s will have different likelihoods of corruption; you may decide that
it's safe to set the bit on Ethernet, but not on 802.11*.
Aah, there's the confusion. The apps we have in mind would think that
it is pointless (but harmle
i received 81.160.221.53 via dhcp. but
Host 53.221.160.81.in-addr.arpa not found: 3(NXDOMAIN)
randy
The biggest questions I have are:
- where to put this bit?
Right now, the *only* way an L2 with varied service levels can derive
what service levels to use for best-effort traffic is to perform a
layer violation. Continuing this tradition, the bit would be:
less_than_perfect_L2_error_detection
What bit is needed ?
Again, this is a layer 2 property. If you want to receive layer 2
frames with errors in them just get a Layer 2 device and tell it to not
do the checksum calculation (much like you put an ethernet nic into
Promiscous mode so it doesn't drop all of the frames not destined for
>> Why, oh WHY would I want to receive a known corrupted packet ?
> why oh why would you ever want to talk with someone over a phone that
> occasionally clicked or popped?
and why would i mind cheese with holes in it? i don't care about
cheese or voice phones. i care about internet data packets.
28 matches
Mail list logo
