nd the most was our first
encounter. He wrote me over email as we were arranging a time and place
to meet and ended it with "I'll be wearing a red shirt; you won't miss
me". I thought at the time that was quite a declaration. And indeed I
did not miss him that day. I do now,
Tony Hansen writes:
> I'm thinking the enhanced RFC format proposed below should be dubbed
> STEAM/PUNC.
And anyone that participates in said work would be "STEAMed".
--
Wes Hardaker
SPARTA, Inc.
Michael Richardson writes:
> There is .csv and obviously there is .ics too already.
Didn't know about the CSV; that'd be just fine. .ics is 'too much' in
general though.
--
Wes Hardaker
SPARTA, Inc.
out more pain (but who wants that) and it's "still perl"
(and who wants that?)
--
Wes Hardaker
SPARTA, Inc.
e it already and I just haven't learned of it.
--
Wes Hardaker
SPARTA, Inc.
?
[I know, we just *ended* a face-to-face meeting so why am I bringing up
face-to-face meeting topics so far before the next one? That's unheard
of! Call me crazy...]
--
Wes Hardaker
SPARTA, Inc.
Olafur Gudmundsson writes:
> If you agree with this petition please either comment on this posting,
With regret, if you still need more signatures, you can add my name to
the list and I am nomcom eligible.
--
Wes Hardaker
SPARTA, Inc.
storage while I'm here.
It's rare, these days, to see people with a clue appointed to important
positions where a difference can be made. I'm very happy that it
happens occasionally; your appointment proves it can.
--
Wes Hardaker
SPARTA, Inc.
Behcet Sarikaya writes:
> It was a natural event that happens rarely in Dallas, in fact since
> 2006, it has not happened again.
That's because we haven't been back yet.
--
Wes Hardaker
SPARTA, Inc.
version, then you may well end up in the state that
Mark is worried about: none of the answers have security considered.
I think the charter should definitely have a requirement indicating that
proposals must explain how security techniques would fit into
int, and
all sorts of other ones too". Yes, we could... but they're not nearly
as popular. But I'd argue .odp is certainly as popular in this crowd,
if not more so, than .ppt.
--
Wes Hardaker
SPARTA, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
>>>>> On Tue, 20 Sep 2011 09:09:52 -0800, Melinda Shore
>>>>> said:
MS> So, I'm looking at the results and see that -9 people skipped
MS> the birth year question.
It was worded poorly too. It should have read:
Do you have a Gray Beard?
A)
tion than trying to have 1000 people even share taxi rides.
--
Wes Hardaker
SPARTA, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
es are,
in fact, at least listed or presented in detail depending on what's best
for the meeting.
You can't hold a discussion half the participants have only half the
information. It doesn't matter who's fault it was. It only matters
that it's a problem.
--
Wes Ha
>>>>> On Mon, 18 Jul 2011 14:41:35 +0200, Harald Alvestrand
>>>>> said:
HA> Content-disposition: noise.
Or: Content-disposition: delete
--
Wes Hardaker
SPARTA, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ler" :-(
Obviously we need to take a typical step back first and determine the
scope of the problem. We need to commission a "requirements for noise"
ID first.
--
Wes Hardaker
SPARTA, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
nref list.
S> P.S. I am not asking for a third Last Call.
Heh. Yeah, I don't think that's required for an upref.
--
Wes Hardaker
Cobham Analytic Solutions
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
tart responding to your thought even before you finished
typing it.
--
Wes Hardaker
Cobham Analytic Solutions
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
agraph (which is one sentence) multiple times and I
only barely feel that I understand what it's saying. I'd suggest
rewording it for clarity and splitting it into multiple sentences.
I'd offer suggestive text, but then I'd prove that I really didn't
understand it.
G
uot;.
SD> If this is clear to those skilled in the art, no problem. I'm just
SD> telling you I can't parse it!
No, I'm sure it's confusing to anyone without a strong background in how
the SNMP-TARGET-MIB works in SNMP. We've tried to make it clean but I'm
more
WH: I agree, but this is functionally template text that is
required from the mib boiler plate. In fact it's so common
place that the exact phrasing above exists in 145 other
published RFCs ;-)
10 DONE 10. IANA Considerations
~
+ Spencer (minor): Is this a note to remind the editor (not the
RFC-Editor) to replace text during AUTH48? Not sure I've ever seen one
like it before :D
+ WH: Ha! Good point; thanks (and fixed).
--
Wes Hardaker
Cobham Analytic Solutions
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
SD> Summary: This specification is almost ready for publication as a
SD> Proposed Standard. I do have some (late Last Call) questions, almost
SD> all of which are around either 2119 language or clarity.
Thanks for the review Spencer! I'll look at addressing your comments
today.
--
BA> I reviewed the document draft-ietf-isms-dtls-tm-09.txt in general
BA> and for its operational impact.
Bernard,
Thanks for your review and comments on the draft!
--
Wes Hardaker
Cobham Analytic Solutions
___
Ietf mailing list
Ietf@ietf.org
rver can accept new connections.
Because this is already a closed issue I don't see a need to revisit the
discussion.
--
Wes Hardaker
Cobham Analytic Solutions
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
a twitter message to an email message and
seriously couldn't cut-n-paste a 140 character message into the email
body is certainly doing so to attract followers as there is certainly no
other motivation to make things more difficult for the reader.
--
Wes Hardaker
Cobham Analytic Solutions
>>>>> On Wed, 09 Dec 2009 17:38:51 +0100, Julian Reschke
>>>>> said:
JR> I would hope that the ID actually points out a specific IETF mailing
JR> list for comments, and the author is reading it.
I'd say most do not. Most just list author addresses and
estionable to your companies blocking algorithms.
I've found large numbers of companies, for example, that assume that all
their traffic is internal to their particular company and start running
spam assassin with very high scores against mail arriving from outside
their local bubble. This d
ments first, of course :-)
--
Wes Hardaker
Cobham Analytic Solutions
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
d we draw the line?
If we give up our normal level of free speech then we should expect darn
nice cookies in trade!
--
Wes Hardaker
Cobham Analytic Solutions
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
;shut down"
3) they wouldn't happen because of fear
The problem isn't just one of "can we have it". The mere existence of
the policy may prevent people from voicing a comment they might in
another venue. A single missing comment or discussion due to fear would
be a b
rently designed for use by single-operator systems".
(And it doesn't prevent an external version-control system for being the
master and pushing the config down. It just doesn't work on the device
itself).
--
Wes Hardaker
Cobham Analytic Solutions
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
as unsafe (unless you're only discarding your own changes).
AB> Only the global lock operation defined in RFC 4741
AB> can prevent this problem.
The global lock has different issues.
The problem isn't with the locking. Locking, and partial locking are
good. It's with the g
the allocated time to make it happen. (and it certainly
wouldn't be in TCL, as that's about my least preferred language of the
large number of languages I've written code in; no offense to TCL lovers).
--
Wes Hardaker
Cobham Analytic Solutions
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
icense-Policy.pdf
Thanks!
Does anyone else feel that the IETF likes to document things in ways
that reflect a maze of twisty passages? We're very good at making many
rooms (all 5686 of them) but not so good at marking the passageways
between them.
--
Wes Hardaker
Sparta, Inc.
* be guided by 5377 (which says
about the right thing: you can modify code extracts). IE, is it
actually possible to use code from RFCs beyond 5378? I think each
company/organization/author would need to personally ask the IETF trust
for a sublicense?
Footnotes:
[1] http
ave read and
understand the various documents than are weighing in on the subject.
Do we consider consensus based on "+1" comments or based on the opinions
of only the more informed readers. And what do we do when it becomes
impossible to determine who is who?
--
Wes Hardaker
Sparta, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
was to simple enter my address and
hit the unsubscribe button to have it mail me a confirmation URL.
Visiting the confirmation URL did seem to work, so I'd suggest people
try this method for unsubscribing if the login method fails for you like
it did me.
--
Wes Hardaker
Sparta, Inc.
___
cument in a list of documents that currently numbers more than 5400
and expecting that everyone will abide by it will solve the issue. But
what do I know? I'm not a layer so I don't understand the rules.
I'm just somehow supposed to abide by the rules I don't understand.
--
Wes Hardaker
Sparta, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
esign team is tasked
with doing the best they can but it is still up to working group
consensus to say "that'll do" or "that'll do with these modifications".
--
Wes Hardaker
Sparta, Inc.
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
> On Sat, 11 Feb 2006 10:13:53 +0900, Masataka Ohta <[EMAIL PROTECTED]>
> said:
>> Protocols and implementations should generally respond using the
>> address to which the request packet was sent. That being said, there
>> are sometimes protocol reasons not to do this and sometimes
>> im
specify the "legality" of what
address is used to respond to a request.
Thus, what should happen is what you want. In reality, as you
noticed, some implementations fail to do this.
--
Wes Hardaker
Sparta, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
hink we'd be idiots
not to at the very least leave room for it (but then, I think we're
not being wise for dropping the consideration of a UDP solution too, so...)
--
Wes Hardaker
Sparta, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
M in the first place. Yes, SNMPv3/USM/UDP will still be just
as usable as it was before. But it still won't be used as much as it
should be.
--
Wes Hardaker
Sparta, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
would be possible now or it would leave room for an easy
addition for support for it in the future. Obviously, the WG has
chosen not to make it their top priority but I doubt anyone would
complain about leaving room for it unless the suggestions dr
Obsoleted by RFC3700) (Also STD0001) (Status: STANDARD)
3700 Internet Official Protocol Standards. J. Reynolds, Ed., S.
Ginoza, Ed.. July 2004. (Format: TXT=148273 bytes) (Obsoletes
RFC3600) (Also STD0001) (Status: STANDARD)
So if you want to look for something n
ase. Sourceforge hosts > 51,700 projects most
of which have multiple mailing lists associated with them. We should
learn from their experiences.
--
Wes Hardaker
Network Associates Laboratories
question.
http://www.iana.org will let you register a "enterprise" number, which will
then give you the mib tree below .1.3.6.1.4.1.
--
Wes Hardaker
NAI Labs
Network Associates
ay implement it that way but its not specified by the
protocol to do so.
Trap reporting is implementation dependent as well, but typically the
list of trap destinations would be configured with the community
string they wish to use when sending traps to that destination.
--
Wes Hardaker
NAI Labs
Network Associates
48 matches
Mail list logo