.
The allocation of address space to registries (and Class A assignments) is
available at:
http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space
Thank you!
-pl
http://ipv4space.TopLayer.Com/ has some information
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
ppropriate for anything related to
efficient multimedia carriage (real-time multimedia over TCP isn't
exactly a great option).
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
://www.cs.columbia.edu/~hgs/internet
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
problem affecting core IETF
contributors, and assuming that this is indeed more than a peripheral
problem, at least let the IETF scheduling folks know about it. Thus,
please let me know if you are or have been affected by this scheduling
conflict. Thanks for your help.
Henning
--
Henning
multicast), but
rather the previously published and slightly non-obvious results.
Henning
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
telephony or event-based
protocols (IM and generalizations) unless they maintain an outbound
connection with a server acting as their representative to the globally
routed Internet. The latter obviously does not address the media stream
addressing problems.
--
Henning Schulzrinne http://www.cs.co
To combine the two long-running threads: The solution to the NAT problem
is obvious - we need a submarine patent where somebody claims rights to
NATs and then charges so much for licensing that it makes technically
more sound solutions, say, IPv6, economically attractive. Indeed, I
think we
http://www.cs.columbia.edu/sip has a FAQ addressing this topic.
messages are passed.
Decisions on what to pass are made solely by Harald Alvestrand.
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
geographic distance.
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
Depending on the assumptions, it seems that either capability discovery
integrated with the actual protocol or a separate protocol (as in
rescap) makes sense. (Among other considerations, this depends on
requirements for setup delay, number of message exchanges or
restrictions on information
tion" is not very helpful or honest, either. Authors
can't wait until I-Ds become RFCs to publish technical work.
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
on date that restricts
publication after that is, as far as I can tell, a concept not found
anywhere else.
Henning
--
Henning Schulzrinne http://www.cs.columbia.edu/~hgs
"Just because you're paranoid doesn't mean they are not after you... "
Apparently, Pillsbury is on a bigger crusade, as the editorial change at
http://cacheoff.ircache.net/ is indeed due to lawyer pressure, based on
reports from the owners of the site.
This would need to be integrated with the general registration mechanism
to have any chance of being representative. Or you can hand out yellow
badges to those who filled out the form. If the room is full, the white
badges get kicked out
Harald Alvestrand wrote:
At 13:30 13/12/2000 -0800,
Workshops with restricted attendance often seem to have a two-tiered
policy: authors/panelists first, rest later on a space-available basis.
This unfortunately, for the IETF, has obvious gaming potential which the
I-D editor is not likely to appreciate. Relying on drafts to be
discussed at a WG
Is there a way to still do zone-transfers? No, I don't want .com, just
.edu. None of the root servers seem to allow it.
Thanks.
ftp://rs.internic.net/domain/ was provided and seems to be current.
com/net/org zones apparently require a license, but the commercially
unattractive edu/mil/etc. are there.
Fred Baker wrote:
At 08:17 AM 1/12/01 -0800, Randy Bush wrote:
The root servers MAY put
the root zone up
There are two somewhat separable issues:
- Unless you only want to make outbound calls, SIP user agents have to
be "servers" as well as "clients". Without per-application hacks, NATs
don't work with inbound connections, so SIP gets bitten by that. (There
are kludges around that, such as a
Before handing out awards: one of my colleagues here, living in
Westchester County, got a nice 10.x.x.x address (net A alright...) and
couldn't figure out why Exceed wasn't working.
However, I think it's high time to establish a "Good Housekeeping" seal
for "real" (pure, unadultared, GM-free,
I would suggest stone tablets. This encourages conciseness and simpler
protocols. Plus, it has more effect when you hit an implementor that
doesn't adhere to the spec with the tablet.
Jon Crowcroft wrote:
In message [EMAIL PROTECTED], Taylor Salman typed:
ASCII text shouldn't be accepted
IEEE Spectrum, Sept. 1996 has a fairly comprehensive discussion of this
topic.
http://www.spectrum.ieee.org/spectrum/sep96/features/air1.html
Accessible on-line to IEEE members only, I believe, but available in any
technical library.
Ken Hornstein wrote:
I expect we will see some lessening
Thanks to a number of people that have contributed links, I have put
together an initial page on specification tools, verifiers, and such at
http://www.cs.columbia.edu/~hgs/internet/formal.html
Additions and corrections are appreciated.
Thanks.
The Mormon Tabernacle Choir in Salt Lake City had a pretty good system
for checking tickets: wireless bar code scanners. Can't be more
expensive than having somebody type in thousands of names, from barely
legible writing.
John Stracke wrote:
Is there anything official that can be done to
Also, as efforts become more interconnected, working groups have
customers even within the IETF. It's not good if working group A can't
proceed in publishing a spec because of normative references from
working group B that can't get its act together. In that sense,
milestones are a contract
Dissolving a dysfunctional working group also allows for a reset, e.g.,
telling the first group that was waiting for a solution to develop a
more narrowly focused solution itself when the attempt at a broad
solution has failed.
Dave Crocker wrote:
At 03:18 PM 4/15/2002 +0700, Robert Elz
RFC-2026, section 4.1.2 (Draft Standard):
If patented or otherwise controlled technology is required for
implementation, the separate implementations must also have resulted
from separate exercise of the licensing process.
The problem is that very few standards make it to Draft. As the
We have been using LaTeX for some of the SIP and RTP specs, together
with a Tcl program that converts LaTeX to nroff (ms macros). The set of
scripts requires a bit of expertise to set up, so I've made them
available by request only.
Jari Arkko wrote:
Hi,
Can someone point me to instructions
Based on suggestions by Brian Rosen, I'd like to propose three
additional civic location elements for this document:
- BLDG (building), e.g., Empire State Building
- UNIT (unit), e.g, APT 42 or SUITE 123
- ROOM (room number), e.g., 1234
Henning
___
James M. Polk wrote:
I agree it is related. Perhaps the pidf-lo document should only
reference the civil doc for the chart? In other words, have the civil ID
be the creator of the chart, and not have it in both documents (fearing
inconsistency), but have the pidf-lo document reference *to* the
James M. Polk wrote:
I think LMK covers this (which is already defined), and is different
than the occupant the building (which would be NAM I believe).
In many cases, yes. In other cases, LMK would be a larger complex (The
Mews), comprising more than one building.
- UNIT (unit), e.g, APT 42
There has been a fair amount of effort in accelerating the tail end
of the document process, i.e., after IETF last call. It is unclear
whether this has succeeded (as there don't seem to be any published
measurements), but I believe that the main problem with timeliness is
now in the WG
to address the problems I
mentioned, in my opinion.
Lucy E. Lynch Academic User Services
Computing CenterUniversity of Oregon
llynch @darkwing.uoregon.edu (541) 346-1774
On Tue, 14 Jun 2005, Henning Schulzrinne wrote:
There has
Keith,
I think there are two stages of chartering:
- the early we don't quite know what we're doing and what shape this
will take, just the general direction
and the
- most work items have drafts associated with them
In my suggestion, a WG would amend the charter with additional detail
Spencer Dawkins wrote:
Whether the main problem with timeliness is now in the WG process
itself is true or not, it is worth removing systemic sources of delay
in the WG process.
You can also read it as we've tried to reform the tail end of the
process and we have either succeeded or run out
Henrik Levkowetz wrote:
Sounds like a good idea. However it requires direct integration with the
tracker, which means that the tools team can't just put up a prototype,
Not really - one could associate the WGLC with just the draft name, and
use that name as the key into the tracker. A
Spencer Dawkins wrote:
(3) Exhaustion: Far too many drafts linger years in 90%-completed
state, while the authors or the WG has moved on to other things. It
would be interesting to take a look at long-delayed drafts and see how
much they have really changed as a function of time. My guess is
I hope you don't mean a term limit. Making chair appointments annually
renewable might work - but limiting the pool of talent by imposing
term limits would be self-inflicted damage, IMHO.
At least in the WGs that I know, there are a fairly large number of
people who would be capable of
How about limiting the term of working groups, instead? If a working
group stretches beyond about 2 years, there is a lot of value in
limiting its scope, shunting new work/extensions into a new working
group or groups, and trying to shut it down in the next 12-18 months.
I think this goes
It does have standing; section 6.2 of RFC 2418 (BCP 25). They can be listed
on the charter page. But I agree it's little used.
Creating a culture of grooming secretaries to become WG chairs will
help, in my opinion, to deal with the chair supply problem and will
allow evaluation of possible
Brian E Carpenter wrote:
To be blunt, I believe this is a direct consequence of our open door,
individual participation ethic. If you want firm resource commitments,
you have to ask corporations and other organizations, not individuals,
to make the commitment. When you have firm corporate
No, lack of action by the community to request moving documents to
Historic.
There seem to be a number of these housekeeping tasks that have almost
no benefit to the individual, have increasing costs and ever longer-term
commitments and thus, not surprisingly, don't get done on a regular
Yes, this seems pretty close to the IETF DPW. Unfortunately, the draft
has expired (I saw the report on the experiment, but even that seems
rather preliminary, in that no actual action to HISTORIC has been
taken). Is there a plan to act on the recommendation of
draft-ietf-newtrk-cruft-00 in
I would never suggest adopting a 4-year project schedule, but would
suggest a number of simple project management techniques and goals:
- As part of WG chair training, train WG chairs in basic project
management techniques and indicate that driving progress is an important
role.
- For large
I doubt that this is going to solve anything. All basic project management
techniques assume that a project has a deadline and that the people working
We do have deadlines: charters, and external customers (implementors,
other SDOs).
on it have some incentive to get the work done. This is
I haven't counted the number of times were deadlines were missed this
week alone with no consequences.
For example, in a WG I attended this morning, the chair asked a person
about a document he promised to write. The person answered that he'd do
this in the next month. The chair replied that
the I-D tracker, although it's not immediately obvious to me exactly what
kind of integration with the I-D tracker would be beneficial here. Could
you expand on this?
Not much linkage: any I-D automatically has an issue tracker associated
with it and there is a link from the I-D tracker to
I think it would be useful to analyze the nature of current DISCUSS
comments before drawing conclusions from the 70% figure. They apparently
range from simple typos (expand acronyms) to differences of opinion
(WG chose X, AD prefers Y; both X and Y are at least plausible) to
adding various
But that's specifically what proposed is for (currently). Here's
something we think we want to make a standard -- now test it.
The problem with this notion is two-fold:
(1) Almost all protocols stay at Proposed.
(2) The impact is particularly profound if there are multiple candidate
The next SIPit event is in about a month; see http://www.sipit.net/
There was a GIMPS (now GIST) + NSIS NSLP interop event just before the
IETF meeting (pre-RFC).
I wish there were more, but there are some.
C Wegrzyn wrote:
Perhaps they are more regionalized. I know there are some labs like
Maybe something like a Service Location Protocol, so that one could
query by a combination of properties, not just name?
Keith Moore wrote:
Dave Singer wrote:
The whole idea that 'real DNS' can arbitrarily pre-empt local name
resolution seems, well, wrong, and needs serious study for
- Good architecture and good design. Placement of
functionality in the right place. I suspect that we
don't do enough work in this area. Almost all
of our activities are related to specific protocol
pieces, not so much on how they work together,
what the whole needs to do, what etc.
It would be nice if these WG closure announcements had a bit more
detail, as this might provide some hints for future efforts and the fate
of the technology discussed. No specifically for this group, but in
genera: Did the group conclude its chartered items? Did they run out of
steam? Was
I'd like commend Nortel for having IP phones in the help area.
Particularly when traveling internationally, it avoids the nasty cell
roaming charge surprises or the extortionate hotel phone charges. I hope
future hosts make that part of their installation and that this feature
is added as a
This seems to be a recurring problem at every recent IETF, regardless of
host and AP vendor. Maybe 802.11b is just not suitable for our STA
density. Is there a way to VLAN these MAC addresses into the get a
clue web page redirector?
One would hope that none of these adhoc mode laptops have
Maybe we can at least try to validate this theory by asking at the
plenary as to which operating system people are running.
Carsten Bormann wrote:
Guidelines would be nice, but wouldn't help here:
The evidence seems to identify systems as the culprits with operating
systems that have not
Let me try a concrete proposal:
- All document editors MUST submit XML format to the RFC editor.
(Mostly) semantic markup makes a lot more sense than presentation
mark-up as it makes it possible to translate the format into a variety
of output formats. This format is the long-term archival
I personally would welcome any pragmatic approach that maximizes the
long-term usefulness of our output. I hope we have general agreement
that a structured document format is better long-term than any
unstructured, presentation-oriented format, be it ASCII, Word or PDF.
The latter all lose
has anyone proved by demonstration that this is possible?
It doesn't have to be part of the rules...
I don't think translating any Word style that kind of looks like an I-D
is likely to be feasible.
A slightly different question is whether we can come up with a Word
template that makes
That's helpful - maybe the tools team can start a more centralized
collection. As I noted in another context, the problem today is that
changes during AUTH48 often don't make it into the author (XML) version
since the editing is based on the RFC editor's ASCII and the OLD/NEW
batch editor. It
(NOTE: I'm still unconvinced of the utility of this
exercise; at the end of the day, most of what I need
a document to do I get out of .txt, .html, and .doc,
including access to databases of BibTex references
via
Wijnen, Bert (Bert) wrote:
But one of the reasons for EARLY submission deadline is to ensure that
the IETF participants actually get some time to READ/STUDY the documents
that need f2f time in IETF WG meetings!
Indeed. The idea is that since XML-RFC-formatted drafts can be vetted
Just as a rough data point and to second Tony's note, I count about 120
active Internet drafts that are labeled '*bis*'. There are probably many
more that don't follow this naming convention. All of these are
presumably based on earlier published documents.
Tony Hansen wrote:
Making the xml
It seems from a quick glance through it that draft-ietf-simple-
rpid-08 gives context.
The initial list of locations seems entirely arbitrary, and most of
the definitions seem woolly and imprecise. Maybe the arbitrariness
is intentional, though, and maybe the quality of definitions
So, I'me a receiver. I receieve a location that I'm unfamiliar with.
How do I render it in my native locale?
I don't think there is any way to accomplish this in general. You
have two unpleasant choices:
- render the token as-is, hoping that it makes sense to the recipient;
-
Thanks for your comments. I generally agree with your feedback and we'll
revise the document accordingly.
Harald Tveit Alvestrand wrote:
I oppose approval of this document as-is.
Four reasons:
1) FCFS is inappropriate
2) The document gives inadequate context for use
3) The document gives
list a mile long if there are lots of extensions.
Henning Schulzrinne wrote:
Some additional comments on closer reading and a general comment:
This registry intentionally (if you look at the RPID document) is
not meant to directly extend the RPID schema. I suppose that one
could add that any
I think that in order for a vocabulary like this to be useful, it has to
fit its purpose. A vocabulary that is made to fit multiple purposes will
in the end fit neither - for one recent example, see the discussion
between the mail folks and the RTP folks over the proper
registration and
This directly relates to the Skype discussion during the plenary. Skype
will, if necessary, tunnel media on port 80 and port 443.
To some extent, the debate also highlights a lack of usable protocol
tools: One reason, albeit likely not the only one, that there is talk
about per-source
Indeed. Not only is it small, it isn't where corporate bean counters
put their attention, which is air fare, hotel, and per diem.
Brian,
this is not universally true. With cheaper air fares and not staying
in the overpriced Hilton hotel rooms, my IETF65 meeting fee was
almost exactly the
Traditionally, it was sufficient for the IETF to publish an RFC
specifying requirements or behavior; the purchasing process, through
RFIs and RFPs, then cited the long list of RFCs, essentially creating
the protocol police force that the IETF doesn't have.
That list-of-RFC-numbers approach is
For what it's worth, this approach seemed to work reasonably well for
the SIP P2P BOF + ad-hoc (or interim) meeting. The former was on
Tuesday, the latter on Friday afternoon.
Dave Crocker wrote:
(IMO, BOFs should be early in the week, not on Friday.
Cross-area review of new ideas is just
We could ask the IEEE, since the relationship between the WiFi folks and
IEEE 802.11 seems to be somewhat similar.
One of the problems I see is that many of the industry associations (SIP
Forum, IPv6 forum, to name two I'm somewhat familiar with) tend to focus
on service providers, not
However, it seems that rather than having each individual chase after
authors, at least one of whom is unfortunately no longer with us,
wouldn't it make sense to have the Trust sent a release form to the
authors so that they can grant retroactive permission equivalent to the
modern RFCs?
Authorship discussions have a long history in the sciences. I'm not
aware of any other scientific or technical publication that limits the
number of authors. (Indeed, I have had to extend the maximum author
count on a largish conference management system I run [edas.info] a few
times.) The
My perception is that often in the IETF, protocol and process design
works best that codifies and regularizes what is already being deployed.
The model that seems to be emerging is that we now have a lot of
revisions of first-generation protocols, with the recent slew of LDAP
announcements
One of the persistent problem today is that bis drafts are harder to
write than they should be. Rather than being able to work from the final
source, there are often only almost-final, pre-RFC-editor versions in
XML (or Word), where one then has to make sure that no late-stage
changes are
Having a more formal description of state machines is a natural next
step from having, say, a good syntax description in ABNF.
Unfortunately, unlike ABNF, none of these (except SDL) have a long-
term stable reference. If we worry about PDF not being around for
future RFC readers, I am a bit
Has this been exercised in the past, say, 5 years?
At least for widely-implemented protocols, such as SIP, there is no
reasonable way to say there is only one implementation that does X,
as there is no plausible way to catalog all such implementations.
Most of the implementors don't show
I interpreted the microphone and hand-raising in Montreal that people
were tired of interminable process discussions that consume lots of
resources and in the end accomplish nothing.
One way to ensure that there are no such discussions is to make all such
discussions fruitless and
Phillip,
you might want to look at the SIP design, which offers most of the
functionality you describe already. The notion of a common address
(prefixed to generate a URL by the communication scheme, be it sip:
or, more generically, pres: or im:) were part of the design, although
there
See
http://www.softarmor.com/wgdb/docs/draft-schulzrinne-sipping-id-relationships-00.txt
for an expired draft on this topic.
There is an architectural 'trick' here, that I suspect is the key for
making thing homogenize in a way that is tractable:
The underlying specifications permit
Judging from the email addresses where I received solicitations for
comments, either every RFC author or every I-D author received an
invitation to comment. (I suspect the latter, since the invitations
seemed to be tailored by working group, i.e., an I-D in a Transport
working group earned
I think it is helpful to distinguish at least three types of IETF
work products:
(1) fully new protocols, at the level of (say) MPLS or NSIS
(2) extensions of existing protocols, such as a new DHCP option or a
new RTP payload type (another huge fraction of our current activities)
(3) bis
It seems like most other SDOs use formalized issue trackers for the
equivalent of last call (ballot) comments, making it easy to see
what has been going on. Some WG do this, but each usually picking
their own peculiar tracker.
The problem with any substantial IETF LC or WGLC comments is
While not harmful, I'm not sure this is necessary if the more-or-less
standard naming convention for drafts is followed for non-WG drafts:
draft-conroy-sipping-foo-bar
indicates that the author Conroy believes the sipping WG to be the
appropriate place for discussion, just like
I don't think these have to be either-or propositions. A mixture of
both, combined with pre-scheduled breakout sessions that
parallelize some of the lower-interest drafts, might offer value to
all participants. Naturally, details depend on the state and size of
the working group. SPEECHSC,
The table of mappings constitutes an on-going administrative
challenge. Also as noted, not all I-Ds are tied to working groups.
But every draft should be able to fit into one of the IETF areas; all
areas have, as far as I know, area-wide mailing lists. At least for
TSV, the list
We built a prototype for ACM Multimedia 2004, using credit-card sized
RFID badges and SIP event notification, shown on a separate
projector. It worked reasonably well. I'm hoping to improve on the
prototype as part of a student project, but may not make IETF 69.
On Mar 27, 2007, at 10:24
Please consult RFC 2131:
DHCP uses UDP as its transport protocol. DHCP messages from a client
to a server are sent to the 'DHCP server' port (67), and DHCP
messages from a server to a client are sent to the 'DHCP client'
port
(68). A server with multiple network address (e.g., a
The current process doesn't work very well when voting is required,
after hum-style consensus has been inconclusive.
I think a fair vote requires
- a clear definition of who can vote
- a vote that is announced well in advance to all parties, not just a
select few
- some process that
In many cases, we do this in any event, just via a more heavy-weight
process, namely by requiring working groups to go through a process
of requirements, frameworks, architecture and other meta-documents.
One can discuss how successful these have been compared to the effort
expended, but
The problem is incentive alignment. For example, for CNP (card not
present) fraud, the merchant eats the loss, so the credit card
company has limited incentive to make the system more secure. After
all, they still get their cut even on charge-backs.
Same problem here: everybody might
Part of the problem may be historical: Requirement documents are a
relatively recent phenomena and likely postdate 2026. I suspect the
original intent of informational documents was to document non-IETF
protocols for the benefit of implementors, as well as record various
other
I'm confused by this part of the discussion. How can a standard be
encumbered by GPL? As far as I know, GPL does not prevent anyone from
implementing a standard without any restrictions or fees, just
possibly from using somebody else's code under certain conditions. I
don't think that
I admit to finding the discussion about Draft standards a bit
theoretical, given how few RFCs ever make it there. As a rough estimate,
http://www.rfc-editor.org/rfcxx00.html#Draft
shows a rate of 20 out of a 1000.
On Oct 29, 2007, at 3:20 PM, James M. Polk wrote:
I think this whole discussion would benefit from some concrete examples.
What wholly new protocols has the IETF developed in the past decade?
Which ones would you consider successful or not?
Almost by necessity, newer protocols tend to cover niches, relatively
speaking, as opposed to broad
Thanks for the list; the cut-off point is probably somewhat
subjective, but I see at least several protocols on the list that one
can consider reasonably successful, as in having several well-known
implementations, shipping as part of common desktop or server
operating systems, references
Dave,
RTP is implemented and used in millions of devices, including just
about all enterprise VoIP systems and H.323. Not as widely used for
streaming, from what I can tell.
There are obviously other IETF streaming and VoIP technologies with
RFC # 2500 that are seeing large-scale use,
I'm looking for a reasonably recent presentation on the state of IP
address allocation that would be suitable for a class I'm teaching.
Thanks.
Henning
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf
1 - 100 of 147 matches
Mail list logo
