>>
>> Thus, I think this is worth exploring, as an experiment, just like we
>> started the day-pass experiment a number of years ago.
>
> I don't know what "this" refers to in the above sentence, but I agree with
> everything else in your note.
Offer a "self-pay" rate, as suggested by Hadriel.
We already have a version of "self-pay", namely the very low student rate. For
that rate, you are supposed to show student ID (not sure how and whether this
is enforced), so it's not quite the same, but it's a "means-based" test, as
well as an attempt to increase the diversity of participants. N
What we tried for our experiment was simple: you turn in your RFID card at the
end of the meeting, and it is randomly re-used for the next one, i.e., a new
number is assigned each meeting. Unfortunately, we only got a relatively small
fraction of RFID badges back, if I recall correctly, as peopl
As far as I know, the simple metallically-coated anti-static plastic bag that's
provided with EZPass (and similar electronic toll systems) is quite effective
and very cheap. Aluminum foil will also do in a pinch.
On Aug 7, 2013, at 2:01 PM, Scott Kitterman wrote:
> On Wednesday, August 07, 201
recall that we had this
> working at an IETF sometime back in the RAI working groups. It was maybe 4 or
> 5 years ago and I think it may have been some student(s) under Henning
> Schulzrinne at Columbia... but I am not sure about that. I remember that
> when you went to the mic y
It seems likely that the VAT problem will affect all European (or at least EU)
meetings.
On Aug 2, 2013, at 7:04 AM, Yoav Nir wrote:
> There's the slight matter of $123.50 in VAT.
>
> To me personally that is minor compared with the much lower price of a flight
> to Germany as compared with
't really see any
> new standards there.
>
> --Richard
>
>
>
> On Mon, May 27, 2013 at 12:19 PM, Henning Schulzrinne
> wrote:
> The most difficult part for any emergency calling system is location
> delivery. WebRTC probably doesn't have much impact on e
The most difficult part for any emergency calling system is location delivery.
WebRTC probably doesn't have much impact on emergency calls if all the calls
traverse a server of some kind and if the caller location can be looked up
based on caller IP addresses, but once you have the end system in
For what it's worth, candidates in professional organizations (IEEE, ACM, say)
routinely publish basic information about themselves, typically of two kinds:
* what have they done before (both within the organization as well as other
roles)
* vision for their position and the organization itself
While the IETF is unique in many ways, the staff-volunteer issue isn't all that
unique. Many organizations face this. As one example, organizations like IEEE
and ACM struggle with this. (For example, they have, over the years, delegated
many functions in conference management that used to be don
It is quite common for technical societies (and, I assume, other professional
associations) to note the passing of their members and contributors to their
field. For many, the IETF is the closest thing they have to such a society and
it is a key part of their professional and sometimes personal
k going forward.
Henning
From: Warren Kumari [war...@kumari.net]
Sent: Monday, September 24, 2012 3:47 AM
To: Henning Schulzrinne
Cc: Warren Kumari; ietf@ietf.org; Walter Johnston; James Miller
Subject: Re: [IETF] Large-scale measurement effort (re)started
We just published an initial architecture and requirements draft on large-scale
performance measurement architectures at
http://datatracker.ietf.org/doc/draft-schulzrinne-lmap-requirements/
This is motivated by the FCC "Measuring Broadband America" effort [see
http://www.fcc.gov/measuring-broad
Lots of business records are never cryptographically signed (presumably, most
of them, actually), and they are just as valid as evidence in court, scanned or
on paper. Unless somebody can make a plausible argument that the IETF just made
them up, this seems a rather unlikely problem. If somebody
From: IETF Secretariat [ietf-secretar...@ietf.org]
Sent: Friday, April 13, 2012 10:40 AM
To: IETF Announcement List
Cc: l...@ietf.org; Henning Schulzrinne
Subject: New Non-WG Mailing List: lmap -- Large Scale Measurement of Access
network Performance
A new IETF non-working group email list h
You are assuming that the truth value of statements can be decided by an
impartial, technically-competent observer. In some of the recent discussions,
many of the claims were "X is (not) going to do Y in the future" or "Using X
may cause Y do to something". Unless the observer has a crystal ball
h, so
consider this a standing offer.
Henning
--
Henning Schulzrinne
CTO, FCC
7C252, (202) 418-1544
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
I think this is indeed all about economics. Role acting ISP for a minute: From
a consumer ISP perspective asked to weigh in here, there are two options beyond
the ones mentioned below:
(1) They can support the new /10, which doesn't cost them anything and reduces
the chance that existing NAT bo
Almost all residential customers will use a standard home router; as long as
that home router does not make the new space available to customers, it will
not be used. Almost all residential users get their home NAT box either from
the ISP (who obviously won't ship such a box) or from one of a ha
I run a fairly large service for reviewing conference submissions, almost all
in PDF, with several ten thousand submissions each year. You'd be amazed how
much broken PDF is out there, produced by all kinds of tools. Older versions of
Microsoft Office and various "free" PDF conversion tools rout
It can indeed be challenging, but in some circumstances, the active
participants of the working group don't quite span the globe. I've also found
that audio conferences seem most effective if they only last an hour or maybe
90 minutes, but are held more regularly, rather than marathon on-line in
Having organized (or tried to…) conferences at a US university, some caveats:
- You can get cheap housing, but only in the summer and some places. (I
recently stayed at the U. of Toronto for $38/night, albeit having showers down
the hall may not be everybody's cup of tea. Rates in Columbia summe
>
> A poster session sounds cool, but it works well when the presenters are
> companies, rather than individuals. To get a good A0 poster, you need access
> to printing services (which are not cheap, but doable) and graphic design
> talent, which is neither cheap nor common in IETF attendees.
I'm curious what the largest *successful* deployment has been (measured in
number of participants in a single room/hall/stadium/...) that anybody has
seen, within the IETF or beyond. The NYC article hints at the fact that the
limit may be hotel fiber, rather than wireless, in some cases. We seem
://www.comsoc.org/livepubs/ci1/info/sub_guidelines.html.
All articles to be considered for publication must be submitted
through the IEEE Manuscript Central
(http://commag-ieee.manuscriptcentral.com).
Guest Editors
=
Juergen Quittek, NEC Europe Ltd., quit...@neclab.eu
Henning Schul
It would be really nice to get one of the consumer PC rags to pick up this
story - an easy-to-interpret compliance label would be even better. If the
consumer rags would refuse to recommend a non-compliant box, maybe vendors have
some incentive to read the RFCs.
I assume IPv6 tests are planned?
>
> Right, but they're doing it for reg-events and presence, after the
> Registration. During an avalanche, for example, they're implicitly throttled
> by the effective registration rates. This config framework is reversing it,
> having subscriptions before the registrations. I'm not saying
http://edas.info/timer.php is a basic one. (EDAS is a site I run.)
Henning
On Mar 23, 2010, at 6:41 PM, Theodore Ts'o wrote:
>
> A while back, someone shared (I think on the IETF list) a little quick
> javascript hack that when loaded into the browser, would display a
> countdown timer of the r
Maybe I'm not enough of a amateur lawyer, but has "authoritative" been a
practical issue, i.e., has there been confusion or legal action because one
rendition (say, PDF) differed in some trivial aspect from another (e.g., ASCII)?
Pragmatically, one could simply state that one form (say, good-ol
While I'm all in favor of considering configurability and
manageability in designing protocols, I have some concern that this
document may have unintended side effects, namely more boiler plate
and more delays in protocol standardization.
The document does not seem to distinguish between th
As part of a research project, we are working on automated diagnostics
of network-related faults in residential, SOHO, conference/special
event, hotel and similar networks. If you have observed errors that
were hard for a lay person to diagnose, whether due to end system
problems, NATs, LAN
code difficult, it would probably eliminate a fair number
of active contributors in the IETF. I'm making no value judgement
whether that would be a good thing or not...
Henning
On Mar 4, 2009, at 6:01 PM, Pete Resnick wrote:
On 3/4/09 at 12:44 PM -0500, Henning Schulzrinne wrote:
We c
I think the developer should be acknowledged if they indeed
contributed to the spec development. (Many implementations are done
well outside the IETF, with essentially no feedback loop.) If they are
not, this seems like a behavior for the WG chair to encourage.
We need to recognize that
I admit that I'm no friend of additional I-D sections, as they easily
generate into boilerplate and "make work" projects. If the goal, which
does not seem stated, is to acknowledge the contributions of
implementations in improving a standards document, we already have a
mechanism for th
I'll also add that we have now many working groups closing in on their
ten-year anniversary, with a dozen RFCs to their credit. (DHC and AVT
are probably among the oldest, but there are many others not far
behind. AVT has about 90 RFCs listed.) I don't see how one can create
a model that pr
Wouldn't it have been nice if the de facto APIs in use today were more
along the lines of ConnectTo(DNS name, service/port).
This certainly seems to be the way that "modern" APIs are heading. If
I'm not mistaken, Java, PHP, Perl, Tcl, Python and most other
scripting languages have a socket
Thank you for your review. Can you point me to any standards track
IETF documents which might need normative reference to this document?
One example: draft-lee-sip-dns-sd-uri-03
Henning
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailm
We've thought about the blue sheet replacement, but wanted to start a
bit smaller and reduce the impact of failure. (With the current
experiment, presumably the worst-case outcome is no worse than what
we've had for the past 70+ IETFs, but losing blue sheet information
might make some lawye
Based on some very preliminary discussions in Dublin, I've set up a
new discussion list to talk about the intersection of Internet
protocols and energy management. The goal is NOT how to make
protocols, routers or servers more energy-efficient, but rather how to
use Internet (application) p
I used 802.11a (on a PowerBook Pro) in Dublin, and it didn't help with
the Jabber server flakiness. Otherwise (ssh, etc.), it was rock-solid.
On Aug 5, 2008, at 3:53 PM, David Kessens wrote:
Joel,
On Tue, Aug 05, 2008 at 10:53:08AM -0400, Joel M. Halpern wrote:
So I do not think that tell
I don't think the problems were related to the wireless network. My
ssh and IMAP session didn't blink, while the plenary jabber room would
periodically kick out a large fraction of the participants.
Having formal secretaries seems like a better long-term approach; it
also provides recogniti
On a side note: If we want something URN-like that actually has
traction outside the IETF, DOIs seem like the right approach. See
http://www.doi.org/
Articles in our closest technical disciplines, namely those
published by ACM and IEEE, already have DOIs, both for journal and
conference a
This decision raises a somewhat larger issue, namely whether deferring
to implementor desires is always the right thing to do. Compared to
implementers, there are many more users and system administrators. For
the reasons discussed earlier and alluded to below, they now lose in
having poore
The registration database for each IETF meeting already contains email
addresses of all attendees, presumably a superset of the blue-sheet
signers.
More technologically-advanced conferences and trade-shows use RFID or
(a few years ago) mag stripes to avoid deciphering handwriting. The
per-
Just publish an RFC that contains the names of popular celebrities,
and use Google ads. The IETF site should do well in link-rankings...
A number of non-IETF sites already make money off RFCs courtesy of
Google ads.
On Apr 1, 2008, at 2:53 PM, Richard Shockey wrote:
> Can this be extended to
I don't think this is a major issue, for two reasons: By the time that
IPv6 mail becomes common, mail clients (and MTAs) will have been
updated numerous times to deal with the security issue de jour.
Secondly, even if a mail client or MTA were to erroneously implement
this behavior, this ca
>
> If an incorrect domain name is in an author or return handling
> address, there are bigger problems to solve than /MX.
Indeed, this is the problem - the problem is that such
misconfiguration doesn't get detected since the address *seems* to
work just fine.
>
>> The mail is "received
One of the problems I have seen first-hand is "disappearing" mail.
Example: A webserver sends outbound email directly, but doesn't want
to receive inbound email. The hostname leaks and mail gets sent to
that address, based on the A(AAA) record. The mail is "received", but
disappears into s
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
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
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 b
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
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:
http://www.ietf.org/internet
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 anybo
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 non-standards
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 be
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 mo
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 avoid
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 mult
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 AM
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 has
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
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
draft-sippi
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 t
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"
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
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 you
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 is
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 interminable
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
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
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 bei
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
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 curr
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?
Th
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 consume
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
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
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 sa
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 "wholesa
i thought about the Geopriv working group or its designated
successor.
Okay, so you have the volunteers for expert review, one problem
solved. Makes me still wonder why "an entity" - I assume that
could be something I carry with me - should be so indiscreet as
telling that it's now in the "ca
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 mea
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
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 location types added automatically become XML elements
in the urn:ietf:para
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 inad
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;
- automatically
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
doesn't
http://www.nmrc.org/pub/present/shmoocon-2006-sn.ppt describes what
seems to explain the appearance of IETF6x named computer-to-computer
wireless networks at IETF meetings. Apparently, there is a feature
that has systems automatically advertise the last AP SSID after
(involuntary) disconnec
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 s
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
automatical
(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 EndNo
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 w
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 this
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 info
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 for
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 been
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 m
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 nic
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 there
- 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.
These
1 - 100 of 165 matches
Mail list logo
