-- Virus Warning Message (on ietf-mx)
Found virus WORM_NETSKY.B in file stuff.pif (in stuff.zip)
The file is deleted.
-
is that your name?
-- Virus Warning Message (on ietf-mx)
stuff.zip is removed from he
..
It's interesting what leaks out of some tools.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
em is to enforce Latin as the
> official language of the Internet. Lots of people already use the
> Latin character set!
It's about time we got rid of that pesky J and W, and we don't
*really *need both V and U, do uue?
:-)
Randy
_
trusts the tool suite to have no other date-dependent behaviour. From
a configuration management perspective, those are some huge "ifs".
I think one would be safer keeping both the source and
the submitted generated files under version control.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
spelling "Hotel" with accent
circonflexe, and revive the English letters thorn
and eth while we're at it?
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ate with deployed systems.
Be conservative in what you send...
Likewise, if your implementation checks those values in any situation other
than the situations spelled out in the specifications, you could also find
yourself explaining why your implementation doesn
e sender of the request, since
an over-zealous receiver might (incorrectly) reject the request.
What is truly unacceptable is for the responder to ignore the
elements of procedure and not fill in the values of error status
and error index required in the response by the standard.
Randy
__
> I'm concerned about the correlation between my MAC address and the
> hosts I communicate with.
and how and why would you suggest that be logged? i am not aware radius
does that.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.
s a dog
with wifi, a wifi fifi?
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
re.
i would assume not. we're not lawyers, even though many seem to play
one on the net.
> IANAL and I'm german, and the IETF meeting is in the Netherlands.
and we're practicing for beijing.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
resume want any authentication problems which they might have to be
debuggable.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ge its model of operation.
i presume you are referring to the problems people from most countries
of the world have even entering the united states, being jailed while
trying to do so legitimately, etc. very good point.
randy
___
Ietf mailing list
Ietf
> Perhaps the better question is, do some people not sign the blue
> sheets because of whatever they think the current privacy policy is?
or use bogus sig on blue sheet. yes. the rfid discussion pushed me
over the tolerance line on this class of issues in the ietf.
> I would have to assume it is the only forum in the world in which they
> expect that level of anonymity
aside from payment possibly uncloaking you, i am not aware of an ops
meeting that checks id or even considers the issue interesting.
will not be very respectful of any policy put in
place.
given the latter, i focus more on prudent personal net hygene and less
on prose.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
rge WLAN network, some others test their
> favorite tunneling technology with it, etc.
that is not gathering data on others' use of the network.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
erver
> experiment
those are not network traffic
i am specifically concerned about the allegation that network traffic
was captured and stored. either cite or retract.
randy, who thinks it is time to get back off this list
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
> Randy, we have had at least one "researcher" sniffing passwords in
> plenary WiFi traffic and posting them, to embarrass people into using
> more secure technology. I believe he was an Ops AD at the time :-)
>> o but i am sure there are wifi spies snooping and playing.
of those statements
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
>> Has "the IETF" been authorizing people to conduct human subjects
>> research without the informed consent of the subjects?
yes, we drag them into black helicopter and mess with their genitals.
you can be the first in maastricht.
sheesh!
___
Ietf mail
at end, and knowing that many folk's
laptops can not do wpa, there will be an alternative provided.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
le they pick up?
we'll probably never know. do you know which particular parts of your
traffic at&t gives to the nsa? modern police states are subtle.
the host provides terminal room security, not net ops.
randy
___
Ietf mailing list
Ietf@ietf.
iments, either with your
packets or with any of your network data, of which the net ops are
aware.
i guess it serves some layer nine purpose to play demogogue on this.
may your first born suffer the micro-management of being an unpaid
volunteer net op :)
randy
f network data were disclosed. or is this more wild hyperbole?
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
l known wide-ranging contributions to the internet.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
e happy to pay attention to private
> emails cricicizing me for this, but I _will_not_ participate in a
> public flame-war about how dreadful this practice is.)
I see $subject only as personal preference, nothing else.
(does that get retaliation?)
---
~Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
l and/or privileged information.
> If you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose or take any action based
> on this message or any information herein. If you have received this
> message in error, please advise
in when I trim.
>
> So its a combination of pathological behaviours, UI, and dominance behaviour
That should just be a function of where the UI software positions the cursor,
shouldn't it?
---
~Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On Fri, 24 Sep 2010 09:09:08 -0400 John C Klensin wrote:
>
>
> --On Thursday, September 23, 2010 10:43 -0700 Randy Dunlap
> wrote:
>
> >...
> >> the same people also complain when I trim.
> >>
> >> So its a combination of pathologi
any of the various flavours of v2,
and SNMPv3 has authentication, integrity, confidentiality, and access control.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
y of doing business has only a few wilted carrots
and no sticks to goad advancement efforts.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
quot;quality" of RFCs, the more
we reinforce the myth that all RFCs are standards. I higher percentage
of obviously immature, speculative, or even outright garbage documents
might help dispel the myth. :-) * 0.5
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi -
> From: "Julian Reschke"
> To: "Randy Presuhn"
> Cc: "IETF Discussion Mailing List"
> Sent: Tuesday, December 21, 2010 8:43 AM
> Subject: Re: Automatically updated Table of Contents with Nroff
...
> So, I do understand how generate the T
Hi -
> From: "Julian Reschke"
> To: "Randy Presuhn"
> Cc: "IETF Discussion Mailing List"
> Sent: Tuesday, December 21, 2010 1:17 PM
> Subject: Re: Automatically updated Table of Contents with Nroff
...
> > Here's one incarnation of what I
g those who think the replacement for sml2rfc.tcl should have
nroff format as its *only* output format. Good luck with your research!
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
er to control widows / orphans / page breaks with nroff, but I don't
usually worry about them because I know the RFC editor is going to
fine-tune the layout anyway.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
in selecting a tailor
...
Agreed, but if those analogies are correct, they also undermine the argument.
Neither the email sender nor the recipient (the ones to whom email is most
important) typically have any voice whatsoever in the selection of the DNSBL.
Randy
___
Hi -
> From: "David Romerstein" <[EMAIL PROTECTED]>
> To:
> Sent: Wednesday, November 12, 2008 11:18 AM
> Subject: Re: several messages
>
> On Wed, 12 Nov 2008, Randy Presuhn wrote:
>
> > Agreed, but if those analogies are correct, they also undermi
eeting in CA next year
> alone.
thank you for demonstrating so clearly the jingoistic prejudice at the
us government level that should preclude ietf being held in the united
states.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi -
> From: "Melinda Shore" <[EMAIL PROTECTED]>
> To: "Randy Bush" <[EMAIL PROTECTED]>; "Scott W Brim" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>;
> Sent: Tuesday, November 18, 2008 11:22 AM
> Subject: Re: [73attendees]
> How would you solve the problem?
hold the meetings in non-terrorist countries. i.e. not the united states.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
saster.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
f "self"
and how it's identified in the local and big internets is a difficulty
with any kind of NAT and cute DNS tricks. But weren't these the
kinds of problem HIP was intended to address?
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ore I begin the formal preparation of the
> Internet Drafts.
Have you considered taking this to Unicode?
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
l exchange, rather than
the next-layer-up request-for-info followed by response, the
real use case is distorted.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
e-incarnation of what
has long been the intent behind the NOTE WELL text.
One can easily imagine a situation in which a disgruntled party named
as a contributor in an early version of work might refuse to give permission
under some readings of an R
Hi -
> From: "John C Klensin"
> To: "Randy Presuhn" ; "IETF discussion list"
>
> Sent: Wednesday, December 17, 2008 2:40 PM
> Subject: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
...
> What gives your WG the ability to func
Hi -
(I trimmed the CC list, assuming that the WG chairs and Trustees that
care about this stuff are already listening to the IETF discussion.)
> From: "Ray Pelletier"
> To: "Sam Hartman"
> Cc: "Martin Duerst" ; "Randy Presuhn"
> ; &q
Hi -
> From: "Contreras, Jorge"
> To: "Randy Presuhn" ; "IETF Discussion"
>
> Sent: Thursday, December 18, 2008 2:37 PM
> Subject: RE: where to send RFC 5378 license forms
...
> The boilerplate text is owned by the IETF Trust. No author permiss
elf.
The multiple-entrance, multiple exit problem could also
be attacked with a variation on good ol' multi-link
procedure, but done just below (or as a sublayer of)
transport, but above (connectionless) network, and
not restrict it to datalink.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
claim authorship of,
e.g., RFC 3417, would be intellectually dishonest. For the IETF
to claim that I was its author, rather than merely an editor acting
on the instruction of a working group, is downright delusional.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
be done, then the document will sit in the
> queue until some work-around like the one being discussed on this
> thread is implemented.
...
In the particular case Doug mentions, there are *no* authors, only
editors working under the direction of a WG. Does this stil
lly, but that's what the discussion is
starting to sound like to me.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi -
Thanks for the clarification. Does this mean that if a WG
really has no concern that the documents it's working on would be
spun off to another organization, then it doesn't need to
worry about tracking down "contributors"?
Randy
> From: "Contreras, Jorge&
a statement of common sense.
However, "common sense" is notoriously difficult to state correctly
in formal terms, and a fear that the 2119 terms lack the fuzziness
needed for this kind of proposal. We *generally* don't want to spend
resources on things OBE, but there a
Hi -
It might be a bit more credible if they offered a plausible alternative
technology. Have they said when they'll post their I-D (meeting all
RFC 5378 requirements, of course)?
Randy
> From: "AJ Jaghori"
> To: "mshore" ; "Jeffrey Hankins" ;
>
ame "win friends and
influence people" checklist as the fsf campaign seems to be using. :-(
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
this method for unsubscribing if the login method fails for you like
> it did me.
...
When I finally did manage to unsubscribe, the list owner re-subscribed me.
I wonder whether he's doing this to all those FSF posters, too.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
that subtag with 'CS' (rather than
with BA, HR, ME, MK, RS, or SI) be correct, for Serbian, Croatian,
or any of the other languages of that region?
> Please eliminate this needless change that breaks applications
> relying on the relationship between YU and CS.
I would argue rat
u haven't posted to LTRU's mailing list, only ietf-languages@, yet.
Tex's message was posted to *both* lists.
> 2. Even if draft-4645bis is approved, the process for language tags
> (in either RFC 4646 or its proposed successor) allow you to register
> the information y
day by painstaking day by tedious
> day
> at a time. I can see no other more direct way.
The files at ftp://ftp.ietf.org/ietf-mail-archive/ are much better suited for
such searches, especially when the time frame is fuzzy.
Randy
___
Ietf
t/rec/T-REC-E.123-200102-I/e
Clause 2.8 hints at those annoying parenthesized things,
and 7.2 makes it clear it's not an appropriate notation
for international numbers.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
-all designation makes it clear that "Best"
only means "what we could more-or-less agree on" and "Current"
can mean "we really hope something better will come along, but aren't
going to hold our breath."
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
works well.
> Can emacs do that for you?
I don't know. I prefer vi.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
document, particularly a largish one, the availability of
.so is for me nroff's biggest advantage over xml2rfc.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi -
> From: "Julian Reschke"
> To: "Randy Presuhn"
> Cc: "IETF Discussion Mailing List"
> Sent: Wednesday, July 15, 2009 2:13 AM
> Subject: Re: Automatically updated Table of Contents with Nroff
...
> > For editing a document, particularly a
Hi -
> From: "Julian Reschke"
> To: "Randy Presuhn"
> Cc: "IETF Discussion Mailing List"
> Sent: Wednesday, July 15, 2009 10:13 AM
> Subject: Re: Automatically updated Table of Contents with Nroff
...
> Point is: nroff and xml2rfc share the adva
Hi -
> From: "Julian Reschke"
> To: "Randy Presuhn"
> Cc: "IETF Discussion Mailing List"
> Sent: Wednesday, July 15, 2009 10:13 AM
> Subject: Re: Automatically updated Table of Contents with Nroff
...
> And of course you can do that with
but, months later, where are actual shirts? you know, tangible results,
operational stuff, not fluff about boiling the ocean.
how typical of the ietf.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
but, if i remember aright, you would need one between xxl and xl, i.e.,
in xml
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
aspect of the quality of the 74 shirts was the
quality of the material.
randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
or decades. If we're
going to trample on sensitivities, we may as well be equal-opportunity
about it.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
murro-gsma-imei-urn
to be in full conformance with BCP 79,
it would seem the time for evaluating "an appropriate course of action"
was some time in the past.
This looks really bad to me, and I'm having a hard time figuring out what an
innocent explanation for this might be.
Rand
nd delete this information
> from your system. Use, dissemination, distribution, or reproduction
> of this transmission by unintended recipients is not authorized and
> may be unlawful.
...
This is just plain silly. Or is it willful ignorance of the "Note Well" terms?
Randy
_
publication of draft-housley-tls-authz-extns. Let's just
hand it over to the RFC editor and be done with it.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
idely implemented the specification in question is,
and whether that specification is clearer than or technically superior
to its "competition."
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
to the contrary, I would like to know about it.
...
Speculating...
A strict subset might be palatable. A superset (strict or not) probably
would not, since that would entail requirements beyond those in the
intended specification.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
References sections
> could get really unwieldy.
...
This was the practice in ISO / ITU work back in the days of JTC1/SC21,
where there were many standards that were either common text or
technically aligned.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
What's the relationship of all this to RFC 2564 and RFC 3729?
(For the phone case, the question would extend to RFC 4711.)
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
l "experiment" rather than one
> pretty much guaranteed to fail...
Sometimes the result of an experiment is a demonstration that something
doesn't always work, which can help prove that a theory is incorrect.
> d/
>
> ps. it has even o
right. It should use UN M.49 codes instead.
;-)
Randy
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf
f
this latest missive leave me more convinced than ever that "LB"
is indeed JFC Morphin, and that under the terms of RFC 3683
we are well justified in suspending the posting privileges for that
address.
Randy
ltru co-chair
> From: "LB" <[EMAIL PROTECTED]>
> To: &q
neihter JFC nor LB has ever offered a draft,
JFTR https://datatracker.ietf.org/drafts/draft-mltf-jfcm-cctags/
> or even outlined a
> comprehensible strategy.
...
No comment.
Randy
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
e Trustees in a formal manner?
...
If it's only a suggestion, what's the point of making it formal?
Randy
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
quot;. Clearly, that rules out anything requiring human
intervention. What do you have in mind that would allow the
spammer^H^H^H^H^H^H^H participant to post without subscribing
and without interacting with a chair or list administrator?
Randy
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
g. Particularly since the proposed/
draft/standard distinction has become so meaningless, it makes more
sense to just publish the spec and ignore the peanut gallery.
Randy
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
I do agree with the others regarding the charter proposal.
While it's probably not exactly what anyone wanted, it does represent
something just about everyone who is actually doing work in this
area could not just live with, but actually support.
Randy
_
*readable* standardized
data models for NETCONF.
Forgive my impatience. We went through this same debate twenty years ago
regarding ASN.1 and GDMO, and only slightly later in de-coupling SNMP SMI
from ASN.1 The acronyms may have changed, but the answers haven't.
Randy
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
have to stop waiting for something
better to magically appear and go with something that will be good
enough that has the support of implementors.
This work should have been undertaken five years ago. How much
longer?
Randy
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ed as a serial rather than having individual call numbers
> and individual catalog entries, but since the Library of Congress
> doesn't seem to be cataloging them today I guess to have them
> cataloged at all would be an improvement.
...
ntially applicable
BCP or standard doesn't imply that it MUST be used - the WG needs to
investigate it, and then make the engineering decision whether
that specification is the right tool for the job at hand.
Randy
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hi -
> From: "Chad Giffin" <[EMAIL PROTECTED]>
> To: "IETF"
> Sent: Saturday, June 21, 2008 11:38 AM
> Subject: 64bit time_t
...
> What do you think?
...
This has been addressed before.
See ITU Rec. X.743 http://www.itu.int/rec/T-REC-X.743/en
for one solution.
Randy
e corresponding instances
in a row, regardless of their MAX-ACCESS.
Randy
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
h should resolve the problem.
These are very distinct senses of the word - one indicating the
desirability of a course of action, the other indicating the likelihood
of a particular result. Only for the former does any kind of "normative"
semantic make sense.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
uld not be necessary, I've seen enough cases where
people failed to correctly disambiguate, and thus conclude that authors
and editors SHOULD employ the case distinction.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
hread (and from my own experience) is that
expectations of media accuracy are fairly low. If the only complaint is a
misleading headline, we're doing relatively well.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
depoints be assigned
> or registered. If assigned codepoints are desired, it is RECOMMENDED that
> the authors get approval from the current codepoint holder. Designers of
> new protocols SHOULD consider example usage and register or assign values
> for example usage.
Regards,
---
~Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
information access, such
as "what leases did I have in my table during time period X" are also
important. Sometimes it makes to have "shadow" tables that do
nothing but provide re-ordered access to the table with the "real"
data - but this requires careful thought about what the high-frequency
or high-value use cases are.
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
rence.
> > This depends on the design of the MIB module in general, and the
> > selection of the INDEX elements in particular.
>
> I don't see how any SNMP MIB design cleverness can get around "the
> SNMP way" of requiring strictly ord
t of "interesting" (for management purposes) leases?
Randy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
1 - 100 of 680 matches
Mail list logo
