Cyrus,
Even the notion of "First Name" and "Last Name" is specific to a certain group
of cultures. "Family Name" and "Given Name" don't always go in the same order,
and it is not always the case that people are called by their given name in
informal situations, as you can see in the drafts o
Hi Mike,
On Apr 29, 2013, at 3:15 PM, Michael StJohns wrote:
> We have an IETF culture - like it or not. It changes over time, as the
> population changes. We can't and shouldn't expect to be able to change it by
> fiat, or to adopt as whole cloth a bias free culture (for some values of
> b
Hi Tom,
On Apr 19, 2013, at 6:03 AM, t.p. wrote:
> If we required the IETF to reflect the diversity of people who are,
> e.g., IT network professionals, then the IETF would fall apart for lack
> of ability.
[…]
> If the ADs of the IETF have to represent the diversity of the world -
> which could
Excellent post, Ted. I really like your suggestions, and I think these are the
types of things we should be doing to more widely leverage the talents of
people who are available to participate in the IETF.
Margaret
On Apr 19, 2013, at 2:13 PM, Ted Hardie wrote:
> Following a number of the
On Apr 6, 2013, at 5:58 PM, Abdussalam Baryun
wrote:
> If we read each document in the world we know the answer; who owns the
> copyright for these documents? so only owner can update it or to
> change category name as per proposed,
>
All of the (at least recent) RFCs have copyright notices i
On Mar 22, 2013, at 7:58 PM, Joe Touch wrote:
> On 3/22/2013 4:43 AM, Margaret Wasserman wrote:
> ...
>> Granted, it may be that the list of _qualified_ candidates is less
>> diverse than the set of all people who are willing to run. But, if so,
>> that isn't becau
On Mar 22, 2013, at 5:47 AM, Dave Cridland wrote:
>
> But I suspect the idea that there are fewer companies when the word "startup"
> seems to automatically imply something Internet related is wrong. There's
> plenty of small companies, but engagement in the IETF is either irrelevant -
> beca
Hi Stewart,
On Mar 20, 2013, at 2:04 AM, Stewart Bryant wrote:
> Age
> Disability
> Gender reassignment
> Marriage and civil partnership
> Pregnancy and maternity
> Race
> Religion and belief
> Sex
> Sexual orientation
The U.S. has a similar (although not identical) list, and it may vary a bit
On Mar 12, 2013, at 2:24 PM, Dan Harkins wrote:
>
> I'd love to get out of this rat hole. Perhaps the signatories of the
> open letter can restate the problem they see so it isn't made in terms of
> race and gender.
The letter specifically mentioned the axes of race, gender, geographic locatio
I have an extra social ticket I could sell if anyone wants it. I'll probably
try to be on one of the first buses, so contact me soon if you want it.
Margaret
On Mar 11, 2013, at 6:54 PM, Dan Harkins wrote:
> In other words, the statement that gender and racial diversity in
> groups makes them "smarter" has no basis in fact. Do you feel that
> an all-female group is stupider than a similarly sized group that is
> equal parts male and female? Really?
On Mar 10, 2013, at 10:20 PM, S Moonesamy wrote:
>
> Diversity of IETF Leadership begins at the bottom. It is challenging for
> reasons which I unfortunately cannot describe. I am supportive of the
> effort. I am not comfortable with quotas. My preference is to see that the
> IETF is acce
On Mar 7, 2013, at 3:01 PM, Dave Crocker wrote:
> Unfortunately, Sam, your model is simply wrong.
>
> The IESG defines the job requirements. The Nomcom selects according to those
> criteria.
>
> I'm been in a number of Nomcom's that wished for some flexibility concerning
> job requirements,
Hi Russ,
On Mar 5, 2013, at 11:18 AM, Russ Housley wrote:
> The rest of your question ought to be discussed at the TSVAREA meeting in
> Orlando.
I have looked at the agenda of the TSV Area Open Meeting (on Wednesday from
9:00am to 11:30am), and it includes the following item:
"- Open Mic abo
Hi Eric,
The IETF Chair (who also chairs the IESG) is not selected by the IESG members
from amongst themselves. The IETF Chair is chosen by the nomcom directly.
The IAB chair is chosen by the IAB as you have described.
Margaret
On Mar 6, 2013, at 9:29 AM, Eric Gray wrote:
> John,
>
>
On Mar 6, 2013, at 8:50 AM, Jari Arkko wrote:
>> I'd like to receive some explanation (privately or publicly) about why we
>> are doing this in the middle of the nomcom process that makes any sense to
>> me…
>
> I didn't want to imply that we necessarily couple the actions we take.
>
> I agre
Hi Jari,
On Mar 6, 2013, at 8:24 AM, Jari Arkko wrote:
>
> And I think we should have a broader view about this than just updating the
> requirements for the seat. There are a couple of other aspects to consider as
> well. First, perhaps the way that we have organised TSV is contributing to
Hi Russ,
On Mar 4, 2013, at 5:05 PM, Russ Housley wrote:
>> The problem with this argument is that it appears that we have a choice
>> between "limited knowledge of congestion control" and "an empty seat".
>> Which one is more likely to be able to learn about it?
>
> If that were the extent
The problem with this argument is that it appears that we have a choice between
"limited knowledge of congestion control" and "an empty seat". Which one is
more likely to be able to learn about it?
Margaret
On Mar 4, 2013, at 3:26 PM, Sam Hartman wrote:
>> "Mary" == Mary Barnes writes
On Feb 26, 2013, at 5:38 PM, Pete Resnick wrote:
> But more seriously: I agree with you both. The deadline is silly.
+1
The deadline originated because the secretariat needed time to post all of
those drafts (by hand) before the meeting. The notion of an automated tool
that blocks submissi
I think the problem is that if they said 0:00, it would be on Tuesday, February
26th, not Monday, February 25th, and people would submit a day late...
Margaret
On Feb 26, 2013, at 5:31 PM, Melinda Shore wrote:
> On 2/26/13 1:25 PM, Paul E. Jones wrote:
>> Seriously, what the heck is 24:00?
I am more concerned than disappointed about Marshall's disappearance from the
IETF. However, I agree that complete absence from an I* position for three
months without explanation should be grounds for recall. So, please consider
me to be one of the "signers" of this petition.
Marshall, if y
On Oct 26, 2012, at 3:11 AM, Brian E Carpenter wrote:
> On 26/10/2012 02:22, Richard Barnes wrote:
would be wrong. The idea here is that applying _punitive_ action (such
as removal from a position) retroactively is not "fair,"
>>> Oh, for heaven's sake. This is nothing to do with puni
On Oct 24, 2012, at 1:01 AM, Doug Barton wrote:
> I get what you're saying, but this is one of those times where (arguably
> for the better) we've created a difficult procedure that should be
> infrequently exercised. We should follow the procedure because it _is_
> the procedure. And then use the
Why do you want to rule out employees of those groups?
I don't think that most of them would have any interest in volunteering for the
nomcom, but why would it be a problem if they did? I mean, I could picture
someone who worked for the RFC Editor who was also technically involved in the
IET
+1
On Aug 6, 2012, at 4:32 PM, Richard Shockey wrote:
> [RS> ] +1 and no employer ever argued that going to Minneapolis was a
> boondoggle. The Hilton in Minneapolis of all the IETF meetings I’ve
> attended has the most optimal layout of meeting rooms etc.
>
> If we were to choose one place
On Apr 27, 2012, at 2:53 PM, SM wrote:
> Mary Barnes is the only participant who mentions the gender problem. As
> such, I gather that the IETF does not have a gender problem. :-)
The rest of us are too busy struggling to succeed in this male-dominated regime
to have time to read these threads
On Apr 23, 2012, at 1:23 PM, Samuel Weiler wrote:
>
> I would strongly prefer to see the blue sheets disappear entirely. Let's quit
> collecting data that we don't need. The collection of attendee lists does
> not directly support our technical work. To the extent that we need a
> headcount
On Apr 5, 2012, at 7:33 AM, Masataka Ohta wrote:
> Margaret Wasserman wrote:
>
>> Unfortunately, it is not clear that the market cares enough
>> about end-to-end transparency to fund the development of
>> NPTv6 or IPv4 NAT-aware end-nodes, because while end-to-end
>
Hi Robert,
Do you realize that NPTv6 _is_ an ID/LOC split solution? The external
addresses are locators, much like the outer header addresses in LISP, and the
internal addresses are IDs, much like the inner header addresses in LISP. The
tunnel is compressed away through the use of algorithmi
What is the value in publishing a living document as an RFC (which inherently a
static, archival document)? Wouldn't it make more sense to convert the
contents of this document to a Wiki page that we could jointly edit and
maintain going forward?
Margaret
On Dec 7, 2011, at 9:27 AM, Dave CRO
Hi SM,
On Nov 29, 2011, at 1:38 AM, SM wrote:
> There isn't any information about why an antitrust policy is needed except
> for a suggestion from an insurance agent.
It was mentioned that the IETF counsel indicated that such a policy is needed.
Addressing some of your point:
> As far as I kn
On Nov 28, 2011, at 2:06 PM, Russ Housley wrote:
> I looked at the antitrust policies of other SDOs. They state the things that
> are prohibited from discussion at their meetings and on their mail lists.
Oh, I've been involved in some industry SDOs that had something like this...
Rules agains
Hi Russ,
I don't know what an antitrust policy is... Could you explain?
Is this something like a conflict of interest policy? Or is it a policy to
avoid situations where we might be engaging in some sort of collusion?
Your plan sounds fine to me, on general principles, but I'd like to know
HI Spencer,
We are responsible for the tutorials, which includes deciding what new
tutorials are needed, and working with people in the community to deliver them.
Not all of the people who _teach_ the tutorials are on the EDU Team, although
there is some overlap.
There as been discussion of
Hi SM,
> Dear 2011-2012 nominating committee members,
>
> You requested feedback from the IETF community for positions on the IESG, IAB
> and IAOC. As none of the candidates shared their views about a simple
> question that was asked on the IETF mailing list, I gather that none of them
> are
+1
On Oct 27, 2011, at 6:04 PM, John C Klensin wrote:
>
>
> --On Thursday, October 27, 2011 14:08 -0700 Bob Hinden
> wrote:
>
>> ...
>> I request that the relevant authors and IETF working group
>> rename what it currently calls "LISP" to something else. To
>> put it politely, the IETF sho
Hi Fred,
On Oct 27, 2011, at 10:01 AM, Fred Baker wrote:
>> There isn't any requirement for a BoF to form a WG.
>
> I think you're saying that there shouldn't be; at this instant, there
> actually is such a requirement. What there isn't a requirement for is a Bar
> BOF (and I would argue that
I was not picturing everyone adding their own conflicts. However, I thought
this might help us avoid some of the issues we've had in the past, where
obvious group-level conflicts are omitted, and meetings have to be rescheduled
at the last moments.
Margaret
On Oct 12, 2011, at 1:06 PM, Dav
+1
It would also be good to expose the conflict lists that the chairs have
provided ahead of time, so that WG participants can point out (hopefully to the
chairs) potential conflicts that the chairs may have omitted.
Margaret
On Oct 11, 2011, at 10:41 PM, Mark Andrews wrote:
>
> In d
Hi Jari,
On Sep 9, 2011, at 1:47 PM, Jari Arkko wrote:
>
> The IESG discussed the situation with this draft on its call yesterday and
> decided to approve the document. A formal approval notice will be forthcoming
> in the next couple of days.
What did the IESG decide about when/how this draf
I greatly prefer the current meeting schedule to one that packs meetings in to
a shorter time period on Friday. As another poster mentioned, I too am tired by
Friday, and I'm unlikely to stay focused through 5 straight hours of meetings,
especially if I'm expected to keep going two hours past w
Hi All,
Within the IETF, it has become common to use the term a "A Modest Proposal..."
as a title for actual proposals for process change within the IETF. This
causes some cultural dissonance for me, personally, and I want to make sure
that people are aware of the origin of this term, and th
Hi David,
On Oct 6, 2009, at 3:30 PM, David Morris wrote:
To the best of my knowledge, in the countries you mention, there was
no contractual risk that normal activities of the IETF would result in
arbitrary cancelation of the remainder of the meeting.
That is a good point. The particul
While I do think that the IAOC should be aware of the potential legal
implications of where we hold our meetings, I wonder if we are
treating China unfairly in this discussion...
On Oct 5, 2009, at 2:30 PM, Cullen Jennings wrote:
The PGP Key signing is a good question - I have no idea - i
Dear Trustees,
I agree with the message from Thomas Narten, cc:ed below. I expected,
and request that you provide, a reply to John Klensin's appeal that is
more directly responsive to the issues that John raised.
Also, I agree with John's concerns about discussion of this appeal
being m
Hi Marshall and Bob,
Could you please let us know the current status of this appeal?
In the plenary in Stockholm, I understood you to say that you _do_
consider the decisions of the IAOC and the Trust to be subject to the
appeals procedure, which I think is a good decision. However, it has
Hi Lars,
Lars Eggert wrote:
On 2009-4-22, at 2:19, Christian Vogt wrote:
It seems that folks are considering two related, yet still orthogonal
topics for inclusion in the MIF charter:
- Conflicts between configuration parameters.
- Issues with address selection.
I agree that both of these
Christian Vogt wrote:
The second topic talks about a problem of applications: When initiating
a connection, which pair of source and destination address (and
consequently which pair of interfaces) should be used? Again, this
issue may come up independently of whether a host has one or multiple
Dean Willis wrote:
My shaman once said "For God, everything is just a question of
policy." But, we need to reduce this problem to a more mortal scope,
and I'm not quite certain that the proposed charter text accomplishes
this goal.
I agree with you that this is a complex problem. The purpo
Multiple InterFaces (mif)
Last Modified: 2009-04-20
I like this version of the charter very much. I think it does a good
job of capturing the area that we need to discuss within MIF. I am
hopeful that we can get our charter approved ASAP, so t
Hui Deng wrote:
Hi, Jari,
What I suggest is like the below:
Connections to Multiple Networks (mif)
Personally, I think that this sort of disconnect between WG name and
acronym would create long-lived confusion about the name of the g
George Tsirtsis wrote:
There is, however, significance in the presence of different
interfaces in a given non-router node...I do not think either of the
other two points (multiple IFs, multiple routes) should be lost
completely in the effort to widen/clarify the charter.
George
P.S.: It would be
Keith Moore wrote:
It seems to me that the general problem is not multiple interfaces, but
multiple addresses per host. It doesn't matter (much) whether those
addresses result from multiple physical interfaces, a combination of
physical and virtual network interfaces, multiple prefixes being
adv
I don't see any compelling reason to change the name of this group at
this point...
We obviously could change the name if we wanted to, but it would
significant cost -- setting up a new mailing list, getting everyone
subscribed there, renaming all of the drafts (and thus losing the edit
tra
On Mar 4, 2009, at 10:38 AM, Stewart Bryant wrote:
Will this break any official or unofficial ID processing tools?
Yes, they would need to be updated. But, I think we're due for
another round of IPR updates once we resolve the current mess. So,
perhaps we could queue this improvement a
I would like to propose that we re-format Internet-Drafts such that
the boilerplate (status and copyright) is moved to the back of the
draft, and the abstract moves up to page 1.
I don't believe that there are any legal implications to moving our
IPR information to the back of the documen
Hi Tony,
On Feb 12, 2009, at 7:45 AM, Tony Finch wrote:
On Thu, 12 Feb 2009, Jari Arkko wrote:
I agree that there are problematic case, but I believe I hope
everyone
realizes this is only the case if the RFC in question has code.
Otherwise it really does not matter. Only some RFCs have co
Hi Everyone,
I am sending this message to several large groups of people with
considerable overlap in an effort to reach everyone who has been
participating (actively or passively) in the NAT66 discussions.
PLEASE, PLEASE do not reply to this full list. Send any replies to
the new nat6
Hi Ned,
On Nov 26, 2008, at 2:47 PM, Ned Freed wrote:
Again, it seems clear that since I'm using it I don't regard it as
unacceptable... The real question is how it will compare to whatever
IPv6
automatic renumbering support ends up in SOHO routers. (Please note
that I am
entirely indiffere
On Nov 26, 2008, at 12:17 PM, [EMAIL PROTECTED] wrote:
In any case, I think getting renumbering right and getting it
deployed is an
essential step in minimizing the use of NAT66.
This seems to ignore the fact that we already have a widely deployed
solution to site renumbering: NAT.
IPv4
While most of the discussion about killing NAT66 is happening on the
IETF list, we have a much more constructive discussion going on in
behave regarding how to define an IPv6 NAT that will meet the needs of
network administrators and end-users, while being less destructive to
the Internet
On Nov 24, 2008, at 5:56 AM, Eric Klein wrote:
We need a team made up of both sides to sit down, spell out what are
the functions of NAT (using v4 as a basis) and then to see if:
1. If they are still relevant (like number shortage from v4 is not
the same issue under v6 for example)
2. Do t
rtering the work
one
> way or another at the moment, for now this is merely
"discussion"
> of the topic.
>
> - Mark
>
>
>
>
>
> Margaret Wasserman wrote:
>
>
> Hi Eric,
>
> According to the ADs and WG ch
Ray Pelletier wrote:
> The Trustees adopted the Non-Profit Open Software License 3.0 in
> September 2007 as the license it would use for open sourcing
> software done as work-for-hire and that contributed to it, at that
> time thinking of code contributed by IETF volunteers. See: http://
Since our main source of income is meeting fees, I wonder why you
think that financial issues would motivate us to hold fewer meetings...
Margaret
On Dec 6, 2007, at 3:27 PM, Hallam-Baker, Phillip wrote:
Well one reason is that it has never happened that way and this
institution finds it
Document Lifecycle
Presenters: Alice Hagens and Margaret Wasserman
This tutorial offers an overview of producing documents in the IETF,
from version 00 of an Internet-Draft to publication as an RFC. We
will cover the working group process, and the required and suggested
contents of an Internet
I strongly support this document for publication as a BCP.
IMO, it eliminates an extremely problematic mechanism described in
RFC 3683, and it provides a much more reasonable alternative through
its updates to RFC 2418 and 3934. I think that publishing this draft
would save the IESG and t
each other, and people who are interested
in this topic should probably read all three of them.
Margaret
> -Original Message-
> From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 11, 2006 12:23 PM
> To: Margaret Wasserman; 'Michael StJohns'
> Cc: [E
Hi Mike,
> For your quote let's insert a single word in the key sentence "for".
> "The Internet Society, on behalf of the IETF, has contracted [for]
> the RFC Editor function to the Networking Division of the USC Information
> Sciences Institute (ISI) in Marina del Rey, CA."
>
> See my point?
Hi Mike,
> Two organizations: IAB and RFC Editor
> Two document series: Internet Standards and RFCs
>
> The RFC Editor through agreement with the IAB and with funding
> from the ISOC publishes the Internet Standards series under the
> banner of the RFC Series.
I'll grant that you have a m
Hi Eliot,
> I disagree. Just as I expect you to use your judgment on the
> IESG I expect the IAB to use their judgment. Community
> oversight comes in the form of the NOMCOM. If you believe
> that oversight is not effective, then let's discuss that instead.
If an AD or the IESG makes a mi
Hi John,
I think I understand what you are saying, and I certainly wouldn't object to
some more explicit limitations on this experiment.
However the current draft does explicitly say that no suspensions can extend
past the end of this experimental period (18-months from when it starts), so
there
Hi Harald,
> The tracker tracks
Sorry, I didn't realize where I would find RFC Editor notes in the public
tracker. I have now been properly educated.
> the RFC Editor note was modified (by me) on July 24, 2004.
> The reason was a comment from Ted Hardie on July 21,
> augumenting a DISCU
current pressures, and I think that our efforts would be better spent on
working on a real BCP proposal along the lines you have described below.
Margaret
> -Original Message-
> From: Sam Hartman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 09, 2006 10:43 AM
> To: Margaret Wa
There is an interesting lesson to be learned from our mailing list
management situation...
The mailing list procedures draft currently under discussion
(draft-hartman-mailinglist-experiment-01.txt) contains the following correct
assessment of our current mailing list management situation:
"R
There are certainly some major weaknesses in the current IETF mailing list
management procedures, and those weaknesses are very well-described in this
document. I agree that we need to address those weaknesses. However, I am
not sure that I agree with the fix proposed in this document.
This doc
I know that these comments are late for IETF LC, but Brian Carpenter
indicated that I should share them here, anyway...
I generally support publication of this draft as an Experimental RFC, and I
hope that the IESG will use this mechanism to support more moderate and more
effective mailing list
Hi Jefsey,
In this post and in at least one other recent post you talk about
filibustering on various mailing lists. I would like to make sure that I
understand what you are talking about, because this is very important to my
assessment of the proposed PR-Action. Prior to these posts, I did not
Hi Eliot,
> RFC 3683 gives you broad discretion on the basis to make a
> decision, and gives WG chairs broad discretion on what
> actions they should take. As you had a hand in it, perhaps
> you can refresh my memory,
Just for the record... I was not involved in the publication of RFC 3683.
Hi Harald,
> - About five people send thank-you notes, and wonder whether
> the IESG will get off its butt and allow him to be suspended
> permanently, usually accompanied with ruminations about
> whether it makes any sense to participate in an organization
> that is so completely ineffective in
Hi Frank,
[Posting as an individual and the author of RFC 3934. My views do
not necessarily represent the views of any group, particularly the
IESG or my employer.]
At 3:33 PM +0200 10/6/05, Frank Ellermann wrote:
And so far I think that
3934 is better than 3683, and a hypothetical 3934bi
Hi Julien,
I think that there is some misunderstanding regarding what is
happening. Harald Alvestrand is not in charge of an IETF PR-action
process, and he has no official role in this process.
Harald is attempting to assemble information that he will use to
propose a PR-action (a "Posting
Just for the record...
At 12:14 PM -0700 9/21/05, David Kessens wrote:
Note that the next proposal for an additional area is just around the
corner: the Internet area has a very heavy load of working groups as
well and the next thing that could easily be imagined is a Mobility
Area which also s
At 12:14 PM -0700 9/21/05, David Kessens wrote:
I have never seen a senior manager in a commercial enterprise
to whom 26 subordinates, each responsible for completely distinct
disciplines, directly report.
[...]
Most Areas organize themselves in such a way that each AD manages
about half of
Sun, 18 Sep 2005 10:09:07 -0400
From: Margaret Wasserman <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
I am not going to comment on the substance of the issues, or the
doc in question, as I haven't been following what is happening with
it, nor have a read
Hi Bernard,
At 9:31 PM -0700 9/19/05, Bernard Aboba wrote:
a. Confusing DNS resolver behavior with the behavior of LLMNR
implementations. The sending of .local queries to the global DNS, while
potentially a serious problem, results from the behavior of existing DNS
resolver implementations. T
Hi Bernard,
I'll start with the process portion of your message and answer the
technical portion in my next note...
At 9:31 PM -0700 9/19/05, Bernard Aboba wrote:
Please remember, though, that most of my note was not meant to
express my own
technical opinion, it was an attempt to summarize
Hi Bernard,
[BA] Right. Margaret's message was technically wrong on a large number
of points, mischaracterizing mDNS, LLMNR and even DNS.
I would be very interested in understanding what technical errors I
made and I would appreciate if you would share the details with me,
perhaps off-line
At 3:55 PM -0700 9/18/05, Stuart Cheshire wrote:
mDNS takes the approach
that local lookups should be distinguishable from global lookups and
accomplishes this through the use of a special local domain (.local).
This claim is one of the bits of misinformation that seems to be spread
about mDNS
Hi All,
As I am sure many of you have noticed, there was extensive discussion
during the IETF Last Call for "Link Local Multicast Name Resolution
(LLMNR)" specification that is currently available as
draft-ietf-dnsext-mdns-43.txt. Thanks to all who participated! The
discussion appears to h
. Perhaps
an OPS area WG working on an optional SNMP call home mechanism is
another...? I don't see how the level of change/disruption to the
vendor community is substantially affected by whether these two
separate mechanisms are defined in one IETF working group or two.
Margaret
At 2:52
Hi Eliot,
At 9:44 AM +0200 9/12/05, Eliot Lear wrote:
Actually, depending on how the solution is developed it certainly CAN
help the problem with the manager being outside a NAT. But we are now
being somewhat loose with terms, so let me be more specific.
I am sorry that I attempted to state
Hi Eric,
At 12:04 PM -0700 9/7/05, Fleischman, Eric wrote:
At 12:26 AM +0200 9/7/05, Harald Tveit Alvestrand wrote:
I believe that the ISMS WG's proposal is about ADDING the
possibility of SNMP over TCP, not about CHANGING SNMP to use TCP.
UDP will still work.
From: Margaret Wass
Hi Ken,
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.
In those cases, the choices would be
Hi Mike,
At 8:41 AM -0700 9/7/05, Michael Thomas wrote:
In answer to Margaret's question about how it would know
where to "call home", it seems to me to be about the same
problem as with traps/informs. I haven't had anything to do
with this wg, but it seems pretty plausible that you'd
initiate
At 12:26 AM +0200 9/7/05, Harald Tveit Alvestrand wrote:
I believe that the ISMS WG's proposal is about ADDING the
possibility of SNMP over TCP, not about CHANGING SNMP to use TCP.
UDP will still work.
That is correct. UDP and the current SNMPv3 USM security mechanisms
will still work. The
Hi Eliot,
[I am writing as a participant in ISMS and other SNMP-related WGs.
This note is not intended to represent the reasoning that I would use
ot make a decision about the ISMS charter in an IESG context.]
As you know, I disagree with your opinion that call-home
functionality should be
Hi Brian,
I'm afraid I don't understand. As far as I can understand,
mDNS uses the .local pseudo-domain and LLMNR does not.
So how can LLMNR be blamed for bogus queries for *.local?
The .local doesn't come from either mDNS or LLMNR... The user types
it and/or an application includes it in t
Hi Stuart,
Somehow our discussion has gone awry, and I'm not quite sure why,
because I am not sure that we fundamentally disagree with each other.
At least, I think that we both see some of the same potential
problems, even if we disagree about what steps would be appropriate
to resolve them
1 - 100 of 265 matches
Mail list logo
