> Christian Huitema wrote:
> It is just as easy to deploy IPv6 using Teredo now.
Yeah right. Find me a Teredo client (not to mention any IPv6 in the
first place) for
Grandstream:
http://www.grandstream.com/y-product.htm
Or Sipura:
http://www.sipura.com/products/spa2000.htm
The internet is _not_
> Christian Huitema wrote:
> STUN is indeed a great protocol, with all the right
> authors, but it makes a couple of assumptions about the
> type of NATs and about the structure of the network.
Indeed, but its assumptions are well in line with the predicted
clientele: home/soho.
We were talking a
> Yes indeed. Probably the #1 biggest use for STUN short term is going
to be
> SIP. It seems like not too much information has to go thru the known
> reachable machine. Maybe just about the same loading as a DNS server?
>
> So, although its kind of a work around, its probably going to do the
job.
> Mark Smith wrote:
> Does SIP with STUN use similar techniques to Skype
> to get around two NATted VoIP peers ?
I have to confess that I have not read STUN in much detail, but I
understand that one of the "novelties" is that the STUN server replies
to the originating SIP client what its public ad
>> Dan Kolis wrote:
>> Yes indeed. Probably the #1 biggest use for STUN short
>> term is going to be SIP. It seems like not too much
>> information has to go thru the known reachable machine.
>> Maybe just about the same loading as a DNS server?
> Masataka Ohta wrote:
> Wrong.
No. _you_ are wrong
- Original Message -
From: "Bob Braden" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, January 19, 2004 1:01 PM
Subject: Re: The IETF Mission
> *> Is the standard for Informational currently that onerous?
>
> Certainly not. But the community (and especia
On Tue, 20 Jan 2004, Iljitsch van Beijnum wrote:
> On 19-jan-04, at 23:55, Dean Anderson wrote:
>
> > As Kazaa, Napster, Groove, and other protocols have demonstrated, its
> > quite easy to create peer-to-peer applications without either expensive
> > external infrastructure or fixed, unique IP a
Vernon Schryver wrote:
>
> > From: grenville armitage <[EMAIL PROTECTED]>
>
> > ...
> > then that's a problem we can fix without creating an indestructable I-Ds.
> > ...
[..]
> I have never failed to find copies somewhere
> on the net. Today the only aspect of an I-D that expires after
Dan Kolis;
Yes indeed. Probably the #1 biggest use for STUN short term is going to be
SIP. It seems like not too much information has to go thru the known
reachable machine. Maybe just about the same loading as a DNS server?
Wrong. For a host to receive external calls, the binding on a
NAT box mus
> From: grenville armitage <[EMAIL PROTECTED]>
> ...
> then that's a problem we can fix without creating an indestructable I-Ds.
> ...
IETF rules to the contrary, I-Ds are indestructable for anyone who
cares to look for them. Every several months I'm moved to point to
classic I-Ds that should ha
Michel said:
>This is not true. Kaaza does not require to open any ports nor configure
>anything in the NAT box. The latest versions of SIP using STUN don't
>either.
Dan asks:
Yes indeed. Probably the #1 biggest use for STUN short term is going to be
SIP. It seems like not too much information ha
On Mon, 19 Jan 2004 16:17:55 -0800
"Michel Py" <[EMAIL PROTECTED]> wrote:
> > Iljitsch van Beijnum wrote:
> > These protocols require that at least one
> > side in each transfer is capable of
> > receiving inbound sessions.
>
> This is not true. Kaaza does not require to open any ports nor
> conf
> Iljitsch van Beijnum wrote:
> These protocols require that at least one
> side in each transfer is capable of
> receiving inbound sessions.
This is not true. Kaaza does not require to open any ports nor configure
anything in the NAT box. The latest versions of SIP using STUN don't
either.
Miche
On Mon, 19 Jan 2004 18:50:30 -0500
[EMAIL PROTECTED] (Dan Kolis) wrote:
> >This really doesn't say much about the scalability of the
> >solution. What it indicates is how much effort people are
> >willing to go to to commit what is perceived as victimless
> >crime.
>
> Two things.
> First, here i
On 19 Jan 2004, at 16:36, Dean Anderson wrote:
No, its not at all like saying that. Its like saying that residential
phone users don't need a globally unique circuit facilities assignment
(CFA) number.
They do if you want them to be able to receive phone calls from anybody
else in the world wit
>This really doesn't say much about the scalability of the
>solution. What it indicates is how much effort people are
>willing to go to to commit what is perceived as victimless crime.
Two things.
First, here in Canada there is a new tax on "media" like writable CD's;
(extendable to Memory cards,
On 19-jan-04, at 23:55, Dean Anderson wrote:
As Kazaa, Napster, Groove, and other protocols have demonstrated, its
quite easy to create peer-to-peer applications without either expensive
external infrastructure or fixed, unique IP addresses.
These protocols require that at least one side in each t
Bob Braden wrote:
>
> *>
> *> If it is important, it'll progress the work of some group in the
> *> IETF and be archived as an RFC. If it (the I-D) doesn't capture work
> *> well enough to be archived as an RFC then it ought to fade from IETF
> *> I-D storage.
>
> Grenville,
>
> Not a
On 1/19/2004 3:47 PM, Vernon Schryver wrote:
>>> Not all important ideas enter the working group process and emerge
>>> as standards, and the fact that some working group chooses not to
>>> "capture" an document does not make it necessarily unworthy of
>>> preservation. ...
>
>> Another appr
On Mon, 19 Jan 2004 17:55:28 -0500 (EST)
Dean Anderson <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Jan 2004, Keith Moore wrote:
>
> > >>> The residential users don't need to have a globaly unique
> > >IP address.>
> > >> That's like saying residential telephone users don't need
> > >to have a> phone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Good grief.
I don't know that we're changing anything in what the IETF does. What is
happening is that the IETF is growing up and taking control of its own
destiny in a variety of ways, and trying to clean up its own processes. In
all the *other*
On Mon, 19 Jan 2004, Keith Moore wrote:
> >>> The residential users don't need to have a globaly unique IP address.
> >>
> >> That's like saying residential telephone users don't need to have a
> >> phone number at which they can be reached. (after all, the purpose of
> >> their residential phone
What are your thoughts?
RFC 2821 obsoletes 821, 974, 1869 and updates 1123. Maybe you find some
answers there?
jaap
> > Not all important ideas enter the working group process and emerge
> > as standards, and the fact that some working group chooses not to
> > "capture" an document does not make it necessarily unworthy of
> > preservation. ...
> Another approach here is to allow for the creation of ad-hoc WGs.
The residential users don't need to have a globaly unique IP address.
That's like saying residential telephone users don't need to have a
phone number at which they can be reached. (after all, the purpose of
their residential phones is to call businesses for the purpose of
obtaining services, righ
On Mon, 19 Jan 2004, Eric A. Hall wrote:
> Another approach here is to allow for the creation of ad-hoc WGs. That
> would provide a cleaner path for tangential documents that don't fit
> within existing charters, and would facilitate broader group review of
> independent submissions. Speaking for m
Hi people,
For STD 10, RFC 1869, SMTP Service Extensions, it is not made clear,
except possibly in a pair of examples provided by that memo, exactly
whether or not the commands defined as optional and not required for a
minimum implementation of SMTP (RFC 821), should or should not be
advertis
On Sat, 17 Jan 2004, Keith Moore wrote:
> > The residential users don't need to have a globaly unique IP address.
>
> That's like saying residential telephone users don't need to have a
> phone number at which they can be reached. (after all, the purpose of
> their residential phones is to cal
On 1/19/2004 1:01 PM, Bob Braden wrote:
> Not all important ideas enter the working group process and emerge
> as standards, and the fact that some working group chooses not to
> "capture" an document does not make it necessarily unworthy of
> preservation. After all, the technical problems evol
*>
*> If it is important, it'll progress the work of some group in the
*> IETF and be archived as an RFC. If it (the I-D) doesn't capture work
*> well enough to be archived as an RFC then it ought to fade from IETF
*> I-D storage.
Grenville,
Not all important ideas enter the working gr
*> This means drastically lowering the standards for what can be published
*> as an RFC. (Note that this brings us closer to what RFCs used to be 15
*> years or so ago.) Another way to do it would be to simply archive all
I do not believe that it means lowering the standards at all, in
g
On Mon, Jan 19, 2004 at 10:53:18AM -0500, Noel Chiappa wrote:
> > From: John Stracke <[EMAIL PROTECTED]>
>
> > I didn't write that; the return address was faked.
>
> So much for mailing list "security" by only allowing posts from subscribers.
Security is not a binary condition.
> This
On Mon, 19 Jan 2004 10:53:18 EST, Noel Chiappa said:
> This virus/worm is actually mildly interested in the way it operates. I'm
> seeing lots of email from people with whom I would have corresponded long ago
>From http://www.viruslist.com/eng/alert.html?id=783050:
The worm searches disk drives
> From: John Stracke <[EMAIL PROTECTED]>
> I didn't write that; the return address was faked.
So much for mailing list "security" by only allowing posts from subscribers.
This virus/worm is actually mildly interested in the way it operates. I'm
seeing lots of email from people with whom
>> o If one is revisiting the old ideas, they will most likely prefer
>> mailing list archives (due to its descriptive nature) than RFC.
>
> Ummm, no. Most IETF mailing lists are pretty inaccessible to non-WG
> participants because no one ever summarizes ideas before WG last call.
...
> (not
[EMAIL PROTECTED] wrote:
Test =)
qxbavnirg
--
Test, yep.
I didn't write that; the return address was faked. The Received: lines
show it was from an IP address assigned to the University of Sydney.
--
/==\
|John Stracke |[EMAIL PROTECTED] |
|Princip
- Original Message -
From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[EMAIL PROTECTED]>
To: "Bob Braden" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 19, 2004 1:42 AM
Subject: RE: The IETF Mission
> Let's now consider usability grounds. The "pet" i
> let's consciously endeavor to ensure that sigificant non-standards
> documents -- responsible position papers, white papers, new ideas,
> etc. -- become RFCs.
i.e. something like IPng white paper series?
On considering the feasibility ground, it is hard to standardize all
possible pet id
> Having your idea published isn't equivalent to having your idea heard.
of course not. most new documents in any series are ignored. very few
people other than professional propeller-heads in ivory tower actually
read every article in acm-sigcomm or every rfc that comes out or whatever.
(comput
39 matches
Mail list logo
