Sam,
As the person who most recently complained, let me elaborate on my
comments. The problem I believe we all are facing is that the
distinction between Proposed, Draft, and Internet Standard has been lost.
I agree with you 100% that...
The point of proposed standard is to throw things out t
While in general I agree with what Scott Michel there is one point of
controversy no-so-hidden in his message:
Scott Michel wrote:
The article also mentioned something along the lines of "Redesign The
Seven Layer Model!" Frankly, I've always preferred the four layer IETF
model because it didn'
Keith,
Okay, I read draft-iesg-rfced-documents-00.txt regarding a proposed
change in IESG policy regarding RFC-Ed documents.
I'm opposed to the change, because I believe it would make it too easy
for harmful documents to be published as RFCs.
As I'm sure you well know, the RFC Editor takes very
Personally, I'm more concerned by WGs demanding their right to
have their half-baked specifications published as RFCs, and the
for IESG to approve them without any IETF review or other
community review, or (as has happened in the past) even when
substantial oversights or design flaws in those spec
Keith,
These days, for a protocol specification to be of "reasonable use" on a
wide scale it needs to avoid causing harm.
First, something can be of reasonable use while still causing harm.
Fossil based fuels prove that. And while I agree that there are certain
areas where causing harm to ot
In theory there's no reason multicast SYSLOG shouldn't work. The packet
format doesn't need to change and you just need to bind to a multicast
socket. I haven't any idea how implementations will currently behave.
But you're addressing two separate problems- distribution and
reliability. Reli
[EMAIL PROTECTED] wrote:
All,
My two cents worth...
5. Section 3.1 of Carl's Report ( Page 20 ) states "Evaluation of
applicants might consist of a search committee appointed by the IETF
Chair." Isn't the appointment of committee members what the IETF
empowers the Nomcom for ?
Not any committe
Dave Crocker wrote:
The IETF is choosing ISOC to do a job. The IETF is specifying
the job. If the IETF does not like the job that ISOC is doing,
the IETF will get someone else to do it.
And you think that isn't called "contractor"?
See below.
What label would you use? And how does it describ
Harald Tveit Alvestrand wrote:
John,
what I expected when I caused this poll to be created was that there
would be a significant number of people choosing "No, I do not wish to
state an opinion". For multiple reasons - "I trust the leadership to
decide better than I can" was one that people tal
Hi Margaret,
My reading of the situation is that the differences between scenarios 0
& M revolve around contract and corporate law, potentially in multiple
jurisdictions. I'm not a subject matter expert in this area. If you're
asking that I run this by lawyers, I'd reluctantly do so. But I wo
Kai Henningsen wrote:
Only Harald disagrees with that, because that is certainly not the
question his poll asked - there was no "neither" option.
Nor need there be. If the leadership is down to these two choices and
one of them is going to be The One, then you might as well run with
those two
ute around the damage. It's happened before. That's
how W3C came to be.
Eliot
John C Klensin wrote:
--On Friday, 01 October, 2004 20:09 +0200 Eliot Lear
<[EMAIL PROTECTED]> wrote:
Kai Henningsen wrote:
Only Harald disagrees with that, because that is certainly
not the question
Spencer Dawkins wrote:
Erk!
I haven't been involved with W3C since 2000, but I WAS involved in W3C
during the late 1990s. It's worth pointing out that the "alternate
routing" mechanism _did_ include a king - at that time, Tim was doing
final endorsement for all "recommendations", and it looks l
Hi Dave,
I am trying to imagine any sort of serious protocol development
process that used that sort of logic and then had acceptance
and/or success.
Here-in lies the rub. If you try to use our rules of protocol
development to develop an organization we'll never get there. And you
and I agree
Eric,
We're not out to rid the world of patent-laden work, nor are we out to
make patent owners rich. The IETF exists to promulgate relevant and
correct standards to the Internet Community, and educate people on their
intended safe use. There is a fine balance to be had between the two
extrem
Simon,
What is your goal, here? What is it you want to do that you can't do
because of either RFC 3667 or RFC 2026?
Eliot
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
On my way to the dust bin of history, I happened to notice this posting
from Eric S. Raymond:
In what way? Microsoft now knows that with the mere threat of a patent
it either can shut down IETF standards work it dislikes or seize control
of the results through the patent system. The IETF has d
Right. While I didn't want to continue this discussion on the IETF
list, as I understand it this is precisely what prefix delegation was
meant to be able to handle.
Eliot
Fred Baker wrote:
At 12:35 PM 11/22/04 -0500, Eric A. Hall wrote:
One potentially technical hurdle here is the way that the
Eric S. Raymond wrote:
Indeed. I think this is true. Several people on this list have tried to tell
me that I don't really want the IP address space on my local net to be
decoupled from the server address.
They are wrong. I want to be able to change ISPs by fixing *one* IP
address in *one* p
Mike,
As the other co-author to
http://www.ietf.org/internet-drafts/draft-ietf-newtrk-cruft-00.txt,
[...]Its unclear that either the work in progress or the cited drafts
will ever be published as RFCs. Its also unclear that this
(restructuring etc) will be resolved within the 6 month lifetime
Hello,
This is an update from the Old Standards experiment. Below are a list
of proposed standards that are candidates to be obsoleted. The old
standards mailing list has vetted out a good number, but still a good
number remains. We are looking for experts who can say affirmatively
whether a
Margaret,
Thanks for your note. Please see below for responses:
Margaret Wasserman wrote:
RFC0885 Telnet end of record option
This option was, at least at one time, used for telnet clients that
connected to IBM mainframes... It was used to indicate the end of a
3270 datastream. I don't
Bert,
I'll remove it from the list with the expectation that the new MIB will
obsolete the old one. However, I note that is currently not stated in
the header of the draft.
Eliot
Wijnen, Bert (Bert) wrote:
W.r.t.
RFC1269 Definitions of Managed Objects for the Border Gateway
P
at if you did the update and in the process then obsoleted RFC 1618.
Eliot
Carsten Bormann wrote:
On Dec 16 2004, at 12:46 Uhr, Eliot Lear wrote:
RFC1618 PPP over ISDN
We had a short discussion about this in pppext.
The gist was: The document is pretty bad (partly because things were
mur
Eric Rosen wrote:
Let me echo Bob Braden's "if it's not broken, why break it?" query.
Because maybe it is broke. Even if someone *has* implemented the telnet
TACACS user option, would a user really want to use it? The process is
broke. We say in 2026 that proposed standards should hang aroun
Eric Rosen wrote:
Even if someone *has* implemented the telnet TACACS user option, would a
user really want to use it?
I don't know. Do you?
Yes, I do. Many of us do. And that's the point.
How do we go about answering a question like that?
We will spend less time discussing that option
John,
Harald, while I agree in principle, I would suggest that some of
the comments Eric, Bill, and others have pointed out call for
the beginnings of an evaluation of your experiment. I further
suggest that evaluation is appropriate at almost any time, once
data start to come in.
First a remin
Elwyn Davies wrote:
Oh, and BTW I can go there on an (air-conditioned) train in only 3 hours.
The USA should invest in a few high speed trains.. they are the world's
best way to travel.
There's a slightly bigger pond between the U.S. and France...
Eliot
___
Hello,
Does anyone have an archive of the IETF list prior to 1991? I am
specifically looking for 88-90 incl.
Thanks,
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Dave,
You make an assumption here that there is some relationship between the
usefulness of a standard done from a working group and those individual
submissions. Is that assumption borne out in truth?
Just asking. I haven't checked too much.
Eliot
Dave Crocker wrote:
On Fri, 07 Jan 2005 10:46
On administrative decision the board of directors of non-profit ought to
have final say and we should trust that they're not going to overturn a
decision that causes us to break a contract or otherwise subject us to
liability without VERY good cause.
In short we can't do this stuff without some
Keith Moore wrote:
IMHO, charters should not be bound to specific documents. It's one
thing to say "WG X will produce a document describing protocol Y", quite
another to say "WG X shall publish
draft-ietf-x-joe's-specification-for-y". It's up to the WG, not the
ADs, to decide which specific
Bruce Lilly wrote:
Such as line breaks in the middle of words, followed by loss of
indentation?
N.B. no smiley.
So what? The nice thing about an XML format is that if you don't like
the representation you can change it without changing the source. Isn't
that nice?!
Eliot
_
Bruce Lilly wrote:
Not if the primary output is unusable. But maybe I missed your point...
Yes. Don't like the software? Write your own...
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Scott W Brim wrote:
I wonder how many of those have actually written a draft using both?
Isn't it sufficient for one to have to have suffered *roff in other
contexts?
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Yakov,
Perhaps the IETF traditional motto, "rough consensus and working
code" should be revised to make it clear that the "rough consensus"
goes only up to a certain point, but after that point the IETF
operates solely by a decree from the IESG.
You and I were both in the room when the Ethernet-MIB
other words, at least this part "ain't broke".
Eliot
william(at)elan.net wrote:
On Tue, 19 Apr 2005, Eliot Lear wrote:
Yakov,
Perhaps the IETF traditional motto, "rough consensus and working
code" should be revised to make it clear that the "rough consensus"
g
Dave Crocker wrote:
the current ietf's track is quite poor, both with respect to timeliness and
quality. quite simply we are taking a long time to turn out lots of
specifications that tend not to get used very much.
I think we can each find examples on either side of this assertion.
MIME took
Margaret,
The words I hate most when I am in a WG meeting are these:
"take it to the mailing list"
That is usually short for "we can't agree in person so we'll now
continue to disagree by email". Debate has been shut off, and usually
prematurely because there is something else on the agenda.
Working groups are expensive. Very expensive.
To me this discussion shows that documents are as expensive as working
groups, and maybe more so. Unless the document is relatively straight
forward, it's easier for someone doing an individual draft to be
funneled to a working group so that t
Dave,
You described the charter as a contract between the WG and the rest of
the IETF. I'll argue an alternative below, but let's stick with
contracts for the moment. My basic understanding of contract law tells
me that there are certain real world and legal limitations on contracts
that mu
Hi Dave,
Dave Crocker wrote:
interesting note. it is always provocative to challenge long-standing precepts,
in this case as per section 2.2 of RFC 2418, Working Group Guidelines, first
published as RFC 1603, in 1994. That does not guarantee that your challenge is
mis-placed but rather that
Rob,
| is whether the proposed mechanism will interfere
| with existing or other proposed mechanisms.
This is totally irrelevant. We're talking about an option. Options,
by their very nature are optional. If use of an option interferes
with some other processing that you require, then
John,
This message is a point of information. I'll continue the discussion in
the other thread.
John C Klensin wrote:
Eliot,
There are at least two things that are wrong with the model you describe
below,...
(1) The assignment of address space, and the whole
notion of private net
Please see below:
> Whether that discussion amounted to consensus or not
I wouldn't like to say after all of this time, but it certainly occurred.
Not publicly. Certainly there was a problem. Indeed someone (I forget
who) had made a request for a /8, which forced the issue.
| What hap
Joe,
>
> It seems like such [IANA] considerations are, by definition, relevant only for
> standards-track RFCs. It is not useful to require it for other documents.
I think you're correct in general but this is not always the case.
Consider URI schemes. I think they're often informational, and in
I would point out that it is historically useful to be able to track
changes between draft and full or proposed and draft and we don't list
status information in the RFCs...
Eliot
[EMAIL PROTECTED] wrote:
> Hi,
>
> I was wondering if someone could help me out on this one. I was doing a bit
> of
For the daring, there is http://www.ofcourseimright.com/~lear/ietf63.ics.
I claim no competence in any of this. No responsibility if you miss
your meetings. No promises to update it. But it works for me.
Eliot
___
Ietf mailing list
Ietf@ietf.org
htt
>
> Thanks for the file. Unfortunately it is not a valid iCalendar file
> To fix this, just add the following line below the 'BEGIN:VCALENDAR' line:
>
> VERSION:2.0
Done!
>
> In addition, each VEVENT component needs to have a UID property with a
> unique identifier in each one.
Done!
> Als
An additional update reflecting yesterdays changes is now available at
http://www.ofcourseimright.com/~lear/ietf63.ics.
Additional stuff:
- UIDs *should* be stable across changes.
- An attempt has been made to make proper use of SEQUENCE
- An attempt has been made to parse out LOCATION informa
Bill,
I couldn't agree with you more regarding multiple overlapping events.
They're all designed for the case where one might double-book, and even
on occasion triple book, but 8 or 9 events? None of them deal with that
correctly. I could go on and on about what these Calendar programs
don't do
Same location:
http://www.ofcourseimright.com/~lear/ietf63.ics
This one has the following changes:
- proper quoting (RFC 2445).
- published agendas are now included
- URLs to WG Charters are now included
- several schedule changes
- room numbers are now included
Again, use at own risk. Th
Spencer,
I agree that it takes time to learn the job. That is one reason to have
staggered terms with two ADs per area. But I have major problems with
other portions of the draft.
For one, a major reason the NOMCOM sees a dirth of candidates is the
major commitment required to do the job (be t
Danny,
I asserted at one point that we have a problem getting good people to do
the jobs the IETF needs getting done (e.g., IESG, IAB). I only have
anecdotal experience of people I know who have in the past turned down
consideration. Fundamentally the NOMCOM process can only work if you
have a s
Hallam-Baker, Phillip wrote:
> No matter how good an incumbent they are much less likely to ask
> questions of the form 'why has this WG existed for over a decade?', 'why
> isn't it finished?', 'why is nobody using it?'
If an AD isn't asking those questions it's probably because it's not
taking
Hallam-Baker, Phillip wrote:
> What if you were planning to use the output of the Working Group?
Sorry, I thought you were aiming toward the age old "this working group
has existed too long" debate. On the usefulness question, I actually
think an experienced AD is going to know what works and w
Pete Resnick wrote:
> I personally would like to see more people get experience on the
> IESG and get some IESG brain cells back into the community before
> they're completely burned out, so I kind of like the proposal.
Why discourage the NOMCOM from picking the best person for the job?
It's easy
Iljitsch van Beijnum wrote:
> It would be an interesting experiment to make an easy-to-use DNS
> implementation for local use that runs on a residential gateway. But to
> be part of the global DNS requires delegation pointers from elsewhere,
> and most residential/SOHO users don't have address
Dear Communities,
I need your help to correct for an impending mistake by the ISMS
working group in the IETF.
Short Version
The ISMS working group is chartered to find a way for SNMP to make use
of existing authentication mechanisms. The current proposed
approaches will make use of TCP.
I seek
Daniel,
All solutions will use a different SSH port as part of the standard just
so that firewall administrators have the ability to block.
Eliot
Daniel Senie wrote:
> At 02:00 PM 9/6/2005, Dave Crocker wrote:
>
>
>> Eliot,
>>
>>> I need your help to correct for an impending mistake by the IS
Hi Iljitsch,
> On 6-sep-2005, at 19:37, Eliot Lear wrote:
>
>> I seek a change to the proposed ISMS charter that requests the working
>> group pay attention to firewall and NAT concerns. The current
>> envisioned approach will not work through firewalls
>
>
>
Hi Pekka,
Pekka Savola wrote:
> Are you saying some of the following:
>
> 1) ISMS specs should specify that the monitored hosts can/should
> certainly keep open a TCP session so the network management (in both
> ways) can happen over that session. (This seems pretty trivial..)
>
> 2) We shoul
Hi Steve,
> I agree that the functionality you suggest is useful. The trick is to
> permit that without permitting misbehavior. (I'll note here that the
> interests of vendors and the interests of users are not identical.
> More and more, vendors like subscription-based models, where users k
Randy,
> Regardless of whether "call home functionality" as you defined it is
> desirable, I disagree with the claim that it wouldn't represent a
> major architectural change to SNMP. For notification originators, it
> is a quite natural extension, and I have no problem with it. For command
> r
Tom,
> I think that there is subtext that is missing here.
>
> Call Home was declared out of scope, more or less, for isms before the
> decision
> to use SSH was taken (the suggestion was made on the isms list to set up a BOF
> in the Operations Area to explore Call Home).\
CH was declared out
Margaret,
My apologies for my delayed response. I've been away. The timing of
this charter review was unfortunate.
> (1) I don't think that call home fits within the scope of the ISMS
> group. I am not necessarily saying that we shouldn't do this somewhere
> in the IETF, just not in this WG.
Juergen,
> 1) I see lots of people using tools like MIB browsers, snmp command line
>tools called from fancy scripts, monitoring packages such as cacti
>and nagios (these were even used on the IETF network in Paris if I
>recall correctly) and all these packages share the feature that t
Margaret,
> The call home solution doesn't help with the problem of the _manager_
> being behind a NAT. It only applies to situations where the manager is
> at a fixed location on a globally-addressable network and the managed
> device is behind a NAT or firewall.
Actually, depending on how the s
Hi David,
Nelson, David wrote:
> Let's assume, for the sake of discussion, that SNMP must always work
> across Firewalls and NATs. The original objection to the proposed
> charter was that it did not include support for "Call Home"
> functionality.
First, let's be clear that nobody is suggesting
Just to clarify:
> The option
> of SSH is mentioned in the architectural document, even though we did
> not went to the glory details of all the options that were on the
> table back then (TLS, SASL, DTLS, SSH). In fact, I fail to see how you
> get the conclusion that we went down to zero drafts by
Brian,
> "Call home" is IMHO a fairly radical departure for SNMP and
> raises trust model questions that I don't find easy to get
> hold of. It seems quite distinct from both firewall traversal
> and NAT traversal, conceptually, even if they might be
> a side-effect of calling home.
I do not beli
Margaret Wasserman wrote:
> If you really believe that this solution is needed, I think you would do
> best to write a draft and _then_ try to get it adopted by an appropriate
> WG.
I (amongst others) *did*. draft-kaushik-isms-btsm-01.txt. What had
been missing up until this point was an SSH d
Juergen Schoenwaelder wrote:
>>The four I had in mind were TLSM, EUSM, SBSM, and SNMP/BEEP. Prior to
>>the meeting the WG had ruled out the first three and during the meeting
>>the fourth was also shelved, leaving none.
>
>
> This does not match my recollection. My understanding was that the
Margaret,
I find myself repeating statements I've made recently, and so I'd
propose that you catch up on my other messages. But for the record...
>
> Hi Eliot,
>
> I have, of course, read the draft that you cited below, but the term
> "call home" is not defined or used in that draft...
Becaus
Uch... I wrote:
Eliot Lear wrote:
> And I've repeatedly responded with
> two reasons why this work should continue in a single working group:
>
> 1. [security considerations]
>
> 2. [security considerations].
>
The second reason is the reason mentioned elsewhere in
to your imagination for long. I will attempt this
week to post a derivative of the draft that Dave is working on to give
people an idea of what the changes would be.
Again it's difficult to diff an incomplete specification.
Eliot
>>>>>>>>>>> "Eliot&qu
Brian,
> Let me be clear about what you mean here. You mean that getting through
> firewalls and NATs is equally possible with SSH or BEEP (or TLS or HTTP
> for that matter)?
Yes, pretty much. The key useful function is an substrate that allows
for multiple channels.
>
> I'd also observe in ter
relevance of the problem and discuss
> requirements for potential solutions. Also there we can identify
> which working group would be the right one to deal with the issue.
>
> But until then, I propose that we let the ISMS group work on solving
> its original problem.
>
> Th
Hello everyone,
I'd like to announce the creation of a new mailing list,
[EMAIL PROTECTED] The purpose of this list is to discuss firewall
"call home" functionality and firewall traversal issues. When I say
"call home" I mean the case where connections/communications are
initiated by application
Bob Braden wrote:
*>
*> X.400 tried that. So did X.25.
*>
*> I think one of the less-appreciated reasons the Internet succeedd was that
*> its unique identifiers were *memorable*.
*>
*>
*> Harald
*>
*>
And unlike X.500, the DNS was *conceptual
Randy.Dunlap wrote:
I don't know if they are related, but your point seems very valid
to me. IOW, from watching and reading over many years, the recent
(2?) years seems like a "crying" wish to get back to a successful
IETF, back to its hayday (or glory days), instead of what it has
become lately
Avri Doria wrote:
Hi,
I can agree with SHOULD and SHOULD NOT, the only problem i had in
writing it that way is i could not meet the specification requirement
for specifying the conditions under which the requirement would not
apply. I did not want to careless create loopholes.
My main conc
John,
I've talked to quite a few folks that have been unable to attend meetings in the US because of visa issues.
Is it your or other people's position that we should no longer have
meetings in the U.S.? If not, what's the practical benefit of the
guidance? If so, we should go back to the
We have in my opinion had a consistently low operator turnout. I wonder
if it would be possible for us to align our conference dates in such a
way as to overlap with NANOG, RIPE, USENIX, LISA, and other appropriate
conferences so that we can get some crossover?
Eliot
__
There are two choices:
With breaks: http://www.ofcourseimright.com/ietf64-breaks.ics
or
Without breaks: http://www.ofcourseimright.com/ietf64.ics
Each is current as of this evening, CEDT, based on the October 21st
version of the IETF 64 agenda. The astute will notice that rooms are
not yet
Would it not be sufficient for the venue to comply with the Americans
with Disabilities Act (regardless of whether it's in the U.S.)?
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
These contain the schedule changes as well as room information based on
information released by the secretariat yesterday. Again, there are two
versions:
Without refreshment breaks and breakfast:
http://www.ofcourseimright.com/ietf64.ics
With refreshment breaks and breakfast:
Roland,
Looking at the snippet of the RFC queue you provided, the draft blocked
on a normative reference to draft-ietf-ipsec-rfc2401bis, which entered
the queue in April. It references a bunch of other stuff, but they're
all earlier in the queue, and I don't think they're blocked. I think
purpose, or nothing.
Agenda bashing - 1 minute
Applicability, solution methods, examples (Eliot Lear) 15 minutes
Generic Architectural Approaches, ICE, STUN, MIDCOM (Jonathan Rosenberg)
10 min
General Architectural Approaches to tunneling (Pekka Nikander) 10 min
Application to SNMP and open areas
David, as usual your message is thought provoking and skirts the limit
of our understanding. Here, however, I am concerned about knowing what
we don't know, to coin a phrase ;-)
I agree, and I see others who seem to concur, that human behavior is of
legitimate concern in systems design, and
JFC (Jefsey) Morfin wrote:
The problem is when these views conflict with the motivation behind the
technical proposition. Who is to arbiter the conflict since by
definition of the case there is no human factor IETF expert in the area?
It would seem to me that the market as always will be the u
Eliot Lear wrote:
Sometimes written opinions from CHI experts might also help to prevent
networking Edsels, if you would.
It has been pointed out that my reference above to the Edsel may not be
well understood by some. The Edsel was a car made by Ford that was
generally found to be
I actually think the bar is too high for other reasons. Those same 20
people are not allowed to serve as jury, and that makes sense. but
we're not a large community, and while I understand the need to prevent
DOS attacks on the IESG, I would still halve the number. As it is now
it's just abo
Dondeti, Lakshminath wrote:
Hi Eliot,
The most recent number of nomcom eligible folks is 849, please see
https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=446. 20
people out of that isn't all that high. I think I might easily find 10
like-minded people.
Prove it. If you can'
Dondeti, Lakshminath wrote:
Perhaps that's one way to prove that the bar is high/low. Another way
is to ask around with this in mind and see if we all run into old rumors
of what has been tried and with what results :-).
My other point is that we are trying to fix the wrong problem. I think
Yep. No good dead ever goes unpunished.
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
In the cart before the horse department Phillip wrote:
> But there is a teensy inconsistency in an argument that goes 'we must
> have plaintext for accessibility' then ignores the language and
> character set issues as unimportant.
>
> The real reason to change the RFC format is that the IETF nee
Henning Schulzrinne wrote:
> 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 o
Dave,
> It is pretty much never a good idea to have the mechanics of a process
> contain artificial constraints, as a means of implementing higher-level
> policies.
>
> If a working group is worried about documents getting read, they will
> impose their own deadlines or they will constrain their
But the problem, Dave, is that everyone already churns their drafts
right before the deadline. It's not like SOME groups would go till the
last possible minute- nearly everybody would, and the plane ride's not
THAT long... ;-)
___
Ietf mailing list
Ietf
1 - 100 of 484 matches
Mail list logo
