Oh, I didn't know there was a requirement for one to have IMPLEMENTED
and DEPLOYED proposed protocols before one can have any sort of
engineering insight into problems and their resolutions? I'm sure that
is not what you mean.
Sure, it helps, but keep in mind DKIM itself was engineered with
Hi,
I think there are far too many debates on RFC2119 semantics and I think
it can be reduced by focusing on better technical protocol writing
skills. A simple recommendation to always include (if possible) a
Minimum Requirements table or section can go a long way in removing
ambiguity.
There are a number of domains supporting ADSP, ATPS and ASL records.
There is a healthy set of world-wide usage at our ADSP Wizard [1].
The problem is I doubt anyone is ACTING on any strong policy rule.
That was one of the chief complaint among the policy advocates (vendors)
with the first
These are valid points. For a long time, I used a public forum support
reporter for our support process which categorized daily and hourly
messaging patterns, hottest threads and topics and reply efficiency
concepts. Basically to see how many messages were replied to in general
and how many
the Diversity Design Team.
Thank You
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
On 6/19/2013 11:15 AM, Dave Crocker wrote:
On 6/19/2013 8:08 AM, Peter Saint-Andre wrote:
On 6/19/13 8:32 AM, Dave Crocker wrote:
On 6/19/2013 5:35 AM, Dave Cridland wrote:
Phillip Hallam-Baker wrote
(RFC5585) informational publications. Perhaps some update in the future
can correct this design and market inconsistency and explicitly provide
knowledge of the alternative frameworks available for DKIM.
--
Hector Santos, CTO
Santronics Software, Inc
(RFC5585) informational publications. Perhaps some update in the future
can correct this design and market inconsistency and explicitly provide
knowledge of the alternative frameworks available for DKIM.
--
Hector Santos, CTO
Santronics Software, Inc.
On 5/5/2013 11:58 AM, S Moonesamy wrote:
Hi Mark,
At 15:57 04-05-2013, Mark Andrews wrote:
The publisher can choose to interoperate with everyone by publishing
both.
The client side can choose to interoperate with everyone by looking
for both.
Both side can choose their level of
, in their various IETF protocol interest areas.
The structure of this questionnaire will be important to be successful
and beneficial.
Sincerely,
Hector Santos
On 5/3/2013 10:32 AM, Thomas Narten wrote:
Adrian Farrel adr...@olddog.co.uk writes:
Well said, Thomas.
Two concrete suggestions:
1) have
apology.
Sincerely,
Hector Santos
On 5/1/2013 9:44 AM, Pete Resnick wrote:
On 4/30/13 7:45 PM, Sam Hartman wrote:
So my personal opinion is that this is a valid discussion to be having
even if we're having it again in IETF LC.
Folks,
This document is *not* in IETF LC. A particular WG member, who
The problem I have is not so much with the decision to deprecate SPF
rrtype, it will remove this particular SPF protocol dual SPF/TXT call
overhead in the network, but more so about what it says for future
applications.
There will no incentive to design DNS applications with specific types,
If anyone wishes to see one aspect of what is wrong with IETF Diversity,
then see whats going on in SPF BIS WG where a key IETF cog essentially
attempts to shutdown discussions and communications, attacks posters
which by my estimate were making progress.
Progress is a status quo - DON'T
On 4/19/2013 2:13 PM, Ted Hardie wrote:
...
There are other methods that may well be better than the two Suresh and I
discussed, but I put these forward as a potentially concrete step that may
help those struggling with this to understand that the end result of this
need not be quotas.
I don't have the same overall feeling that its less reliable.
I believe it is 100% reliable when it comes to the good
communications, the serious stuff, the work, business communications.
Those get through and more importantly, above all, when there is a
problem, good people complain, any
This is one of those DPEP (Diversity Problem Entry Point) arising from
globalization, April 1 HRC (Humor Recognition Culture) differences,
IETF stalization and the growth of I-D submissions. I suggest there
is a direct correlation among these factors with the end goal efficacy
of the
Hi Abdusalam,
You should consider all APRIL 1 published I-D as SPAM and the
electronic mail follow ups generated in the IETF list as more wasted
bandwidth, time and spam. We have too much time in our hands, boredom
for many, and even more wasted time if we spend time reading it - so in
On 4/6/2013 11:57 AM, Scott Brim wrote:
On 04/06/13 11:52, Hector Santos allegedly wrote:
Hi Abdusalam,
You should consider all APRIL 1 published I-D as SPAM and the
electronic mail follow ups generated in the IETF list as more wasted
bandwidth, time and spam. We have too much time in our
it should also offer its own membership
and provide IETF.ORG email accounts as well. :)
--
Hector Santos, CTO/CEO
Santronics Software, Inc.
http://www.santronics.com
- Original Message -
From: Ted Lemon ted.le...@nominum.com
To: Dean Willis dean.wil...@softarmor.com
Cc: ietf@ietf.org
Good points Dave.
However, I would suggest that having tighter controls on the transport
practice, e.g.; SMTP handshaking compliancy, following and honoring
exclusive domain published policies, does help minimize support cost.
--
HLS
On 3/30/2013 7:46 PM, Dave Crocker wrote:
On 3/30/2013
Hi Doug,
This sounds urgent. I am not seeing this urgency, but maybe we just
have it under control.
Another side question Doug, is this an application-level based
filtering? Can one be authenticated lets say for SMTP but not WEB?
Is the filtering applied across all protocols? Is it the IP
Hi Doug,
On 3/28/2013 2:13 PM, Douglas Otis wrote:
Dear IETF,
In response to various strategies to reject IPv6 email lacking either DKIM
or SPF, the non-negotiated approach suggests far greater review is needed.
Whats the difference with IPv6 connections? Should it matter? Does it
matter?
Our extant product supports AUTH-RES for DKIM and ADSP. Without a
thorough review again and confirmation, I feel, unfortunately, probably
not 100% according your specification. At the time it was implemented,
over a few years ago, I had found it inadequate to cover all bases. I do
recall it
+1. My view as well. I will add I think it generally means there will a
problem in a WG if an AUTHOR has issues with its WG participants, enough
to a point he/she begins to ignore them - despite all the input they
provided, included the indirect ones that help mold others to think and
chime
On 3/25/2013 12:17 PM, Scott Brim wrote:
On 03/25/13 11:54, John C Klensin john-i...@jck.com allegedly wrote:
So perhaps a little more guidance to authors and WGs about
acknowledgments would be in order.
or a statement that acknowledgments is not a required section and not
subject to IETF
Interesting proposal. I suggest perhaps a different Contributions
section related to IPR considerations, including also good for open
source/public domain information.
For me, this would be a quick/goto read item after reading a new I-D
abstract of interest.
Good idea.
--
HLS
On
On 3/20/2013 3:18 PM, Eric Burger wrote:
How much is the concentration of corporate participation in
the IETF a result of market forces, like consolidation and
bankruptcy, as opposed to nefarious forces, like a company
hiring all of the I* leadership? We have mechanisms to deal
with the
Anything along the lines of mentoring the virtual world of IETF
participants? :)
Mr. Klensin, if it wasn't for you, I would of probably lost interest in
the IETF long ago. You have reached out and assisted in more ways you
should be made aware it was very much needed and welcomed. Thank you.
Speaking as a successful by-product of the american Affirmative Action
and Equal Opportunities programs of the 70s and early 80s, I would
suggest the IETF needs to work two small baby steps:
- Improving its Marketing,
- What is its products?
- What will attract all/any groups?
As a minority raised thru the corporate rank, as stated below I think it
is offensive too and unfair to historical facts. But overall, I think it
is just the wrong choice of words. All it could suggest is that there
are more different views and experiences in the synergistic effect of
final
+1
There lies the fine line of conflict of interest that I believe the IETF
has done a tremendous job in keeping in control with diverse disciplines
and philosophies well considered. The RFC format by definition, its
style, the open WGs, is all geared towards diverse audiences.
On
One item to consider is to lower the work load of the AD, in particular
in reviewing docs towards of the end of projects. Issues and dilemmas
are piled on. I think one approach to lowering appeals, for example,
is to address unresolved delicate WG issues much faster, in particular
the
should
be reviewed. I believe Pete Resnick is touching base with how Rough
Consensus is used in his I-D.
That is it for now, if not done. Thank you for the opportunity to
provide my viewpoints on IETF matters and its future.
--
Hector Santos, CTO/CEO
Santronics Software, Inc.
On 3/2/2013 4
Its not really orthogonal if you are seeking a feature list. Will it be
out-sourced, open source or in-house developed?
That's the dilemma with most older establishments that do not wish to provide less
support for its long time customers but need to also migrate and provide
other methods as
of the tenets of the document,
in my view. Recognized ownership has a very vital effect on what a
protocol may|can|should offer or not offer as to not open Pandora's box.
--
HLS
On 2/24/2013 2:23 PM, Hannes Tschofenig wrote:
Hi Hector,
On Feb 23, 2013, at 9:51 PM, Hector Santos wrote:
Hi
Cooper wrote:
Hi Hector,
Just to clarify, do you mean ownership of personal data? Or something else?
Thanks,
Alissa
On Feb 25, 2013, at 2:55 PM, Hector Santos wrote:
Hi,
Related to your question, if it wasn't done already, I think there is one item to consider or define -
$Owner(s
down the slippery
rights vs. harms slope pretty quickly, and we've managed to avoid that
altogether in this document so far.
Alissa
On Feb 25, 2013, at 3:26 PM, Hector Santos wrote:
Hi, I would think both - ownership of the things and ownership of the medium moving,
transporting, storing
Hi, with a quick review, and many comments and points, I think the one
single part that I would have some questions about is in the intro:
The guidance provided in
this document is generic and can be used to inform the design of any
protocol to be used anywhere in the world, without
+1
I saw a small mission statement in this post, good start. Perhaps an
official mission statement for the new incoming chair. Take it slow.
Don't need to see a blog of the day!
On 2/22/2013 7:35 AM, IETF Chair wrote:
Jari has created a blog as an experiment to see if would be possible
Not to oversimplify the problem or the pursuit for a solution, I think
there are some possible simple, but perhaps not practical, solutions to
the concerns you cite.
- Faster Reviews, Resolutions by external people, i.e. IESG or a new
technical review group specifically for this purpose.
Notice 4144 has no acknowledgements except for the RFC editor sponsorship. :)
Most I see is common sense, but my view, in my somewhat limited work areas I
have participating in, it doesn't matter if the editor/author doesn't like you.
I guess that would be the exception. I think overall 4144
- Original Message -
From: Dave Crocker d...@dcrocker.net
To: Sam Hartman hartmans-i...@mit.edu
Cc: Abdussalam Baryun abdussalambar...@gmail.com; ietf ietf@ietf.org;
Lixia Zhang li...@cs.ucla.edu
Sent: Sunday, February 03, 2013 1:38 PM
Subject: Re: History of protocol discussion or
There was a mechancal reason for both and not just an EOL (End of Line)
concept. As you point out, it was the original way to get an emulation of BOLD
characters on print devices. You control the print head and when this
emulation moved to 80x25 screens, the cursor was the carriage head. Some
I have two concerns and comments:
- How will success or failure be measured? Number of appeal increases
or lesser amount? I have a concern that once this door is open, there
will be increase appeals and also apathy of outcomes. There should be
a statement of what sort of problems or issues
Maybe the survey to be done is a review of all the RFC, STD and see
which ones
- had a great abstract and introduction,
- had the better writing styles
- had the least endorsement resistance
- progress faster than most,
- had the most implementators,
- with least support/questions need to be
Thanks Carsten for your explanations. As having experience with both
styles of programming as you describe and also interpretive vs p-code
vs static compiler writing for our servers and clients, it would seem
to me that if the both syntaxes are possible, then the solution is
more
Keep in mind only a STD is a real standard. A RFC is still only a
recommendation, a guideline. What makes it a pseudo-standard is
the # of implementations, how wide spread it is and foremost IMO, how
much embedded it is so that a change has a negative impact. At that
point, an RFC not
+1.
I think it is important that we have communications tools for
documenting strong minimum protocol requirements and we only have
RFC2119 to make that possible.
Yet, we need to be careful where the lack of RFC2119 upper case
wordings can be used to leverage an argument for relaxation of
Scott Brim wrote:
It's a communication problem. If you want your audience to understand
exactly what you're saying, and implement along very specific lines, you
need to tell them in a way they understand.
+1
Personally I prefer a quieter approach, but I've been told that
these days one
Melinda Shore wrote:
On 12/9/12 10:43 AM, S Moonesamy wrote:
I would like to ask you to pick the three points from Section 2 (
http://tools.ietf.org/html/draft-moonesamy-mail-list-protocol-00 ) which
you consider as helpful to facilitate mailing list discussion and send
them to me off-list.
This proposal sounds interesting but couldn't it run into conflicts
when there are competition in running code? Who's running code do
you fast track? How does it apply in the protocol updates area, i.e.
BIS work?
This proposal and thread, similar to the recent others, all seem to be
Melinda Shore wrote:
On 12/1/12 2:21 PM, Stephen Farrell wrote:
My reluctance to get into this is based on an opinion that process
change proposals with more words attached tend to just not happen,
so fewer words is better.
I think that's actually a pretty terrible reason. The goal is
not to
+1
John C Klensin wrote:
--On Tuesday, November 27, 2012 13:00 -0500 Barry Leiba
barryle...@computer.org wrote:
...
So here's my question:
Does the community want us to push back on those situations?
Does the community believe that the real IETF work is done on
the mailing lists, and not in
The IETF should be leading the charge for easy to use, multi-device
readiness cyberspacing virtual meeting places, including better
electronic groupware collaboration tools, etc. It is undoubtedly and
inevitably the Achilles' Heel for the IETF Meeting. So the IETF
needs to embrace it now, big
The IETF should be leading the charge for easy to use, multi-device
readiness cyberspacing virtual meeting places, including better
electronic groupware collaboration tools, etc. It is undoubtedly and
inevitably the Achilles' Heel for the IETF Meeting. So the IETF
needs to embrace it now, big
Henning Schulzrinne wrote:
If we want to keep this in the spirit of long-established
(newspaper) traditions rather than a web page, we could use the
IETF Journal for recording the passing of members of the community.
This seems reasonable and fitting for all qualifications.
--
HLS
I find the archives very useful, especially when you have your own I-D
history and contribution to WG works perhaps. It helps to show
different views, the synergism, the competitive engineering views, the
history, etc behind the final development of WG work.
Whenever I do find a need to
Simon Perreault wrote:
Le 2012-08-08 12:34, Geoff Mulligan a écrit :
I also would vote to return to Minneapolis again and again even
permanently.
Does nobody care about going to new places so that new people are
exposed to the IETF and may start getting involved?
We've seen this positive
Martin Thomson wrote:
On 4 August 2012 08:52, Mark Nottingham m...@mnot.net wrote:
The other interesting case is where large amounts of data arrive in a stream.
SAX and SAX-like libraries makes this easy to implement with XML. I hope
there's an equivalent for Json; if not there needs to be.
Whose library? (rhetorical question).
In my experience, the issue is pretty straight forward and its what
this OAUTH fellow exemplified - technology leaders taking control of a
standard for their strategic benefit. This is not a phenomenon, its
par for the course and its a principle reason
Mr Baryun, the world was once flat! I commend your efforts. Who
knows? Maybe you have the seeds here for the development of a protocol
expert system, AI based protocol design-configuration systems using
SBPT Structured Block Protocol Technology as a language and tool to
make the world jump!
Murray S. Kucherawy wrote:
On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net wrote:
Here are two small tweaks that might correct things:
y This domain is testing DKIM. Verifiers MUST NOT treat messages
from Signers in testing mode differently from unsigned
Barry Leiba wrote:
That said, I'm inclined to agree with Mike T that input from the
reputation target is suspicious, so it's not clear how much value it
will have nor whether it might be gamed (by the reputation target) or
hacked (by someone wanting to hurt the target's reputation).
It
Murray S. Kucherawy wrote:
And you thought this list was dead.
I was asked to consult recently on some DKIM questions raised by a customer
of a former employer. The questions involved the meaning of t= in DKIM
keys and the text in RFC6376. The focus of this tag has always been, to
the
John R. Levine wrote:
I've opened a ticket to arrange that t=y suppresses any positive impact
domain reputation has in the next version of OpenDKIM, as an experiment.
I'm inclined to leave well enough alone. That wouldn't have been an
unreasonable interpretation six years ago when DKIM was
S Moonesamy wrote:
Brian Carpenter wrote:
Also, RFC4406 states that Sending domains MAY publish either or both
formats (i.e. spf1 or spf2.0). That being so, I would ideally expect to see
nine rows in the results table:
SPF RR only, spf1 only
SPF RR only, spf2.0 only
SPF RR only, spf1 and
Brian E Carpenter wrote:
On 2012-05-19 20:39, Ofer Inbar wrote:
...
But don't change the rules. 2119 works well as is IMO.
Just to be clear about the current rules, 2119 makes it clear that
upper case keywords are optional (These words are often capitalized).
Indeed, numerous standards
Lee Howard wrote:
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Dave Cridland
Consider:
An octet may contain 0-255.
An octet contains 0-255.
An octet might contain 0-255 - or it might not?
The Foo octet MUST lie between 0 and 127
+1
Randy Bush wrote:
can != may
one is ability, the other permission
randy
--
HLS
+1
My view that this is more about the specific issues of documents and
not just RFC2119 itself. Sometimes it falls through the cracks.
Sometimes a justification or argument is found to show the contrary of
what is stated, especially when its uses lower cases or even terms
like choose.
Brian E Carpenter wrote:
Fair enough. I can't agree with SM though - as for appeals under RFC 2026,
the person bringing up an issue really has to provide a factual summary,
exactly to avoid witch hunts. It can be very short:
Hi, I noticed that US Patent 12345 was filed in March 2010, and
a big part of the BCP79 related concerns. Sometimes these IP
things are not always obvious for I-D contributors.
--
Hector Santos
http://www.santronics.com
http://hector.wildcatblog.com
jabber: hec...@jabber.isdg.net
Hector Santos wrote:
Brian E Carpenter wrote:
Fair enough. I can't agree
Original Message
Subject: [Fwd: Re: [IETF] Re: IETF posting delays]
Date: Tue, 08 May 2012 07:31:13 -0400
From: Hector Santos sant9...@gmail.com
To: Warren Kumari war...@kumari.net
CC: SM s...@resistor.net, John C Klensin john-i...@jck.com,
ietf-act...@ietf.org
I'm giving up
status. I might just add this to
our list server. :)
--
Hector Santos
http://www.santronics.com
http://hector.wildcatblog.com
jabber: hec...@jabber.isdg.net
.
And perhaps, hire a PR, technical sales consultant who knows the
subtleties of what comes first; Marketing or Technology.
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hec...@jabber.isdg.net
seem to have any
weight. Whats odd is if this is indeed of case of specific
individuals moderation, its filtered on domains only and not the
person because I have no problem with gmail.com postings.
Thanks
--
Hector Santos
http://www.santronics.com
http://hector.wildcatblog.com
jabber: hec
Please pardon this submission processing test using a different account.
--
Hector Santos, CTO
http://www.santronics.com
http://hector.wildcatblog.com
Hector wrote:
Randy Bush wrote:
When I first begin to take notice a while back and last year I
decided to ask the list admin. He replied
life other than my own.
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hec...@jabber.isdg.net
be
resolved after following this session?
Yes. It was helpful in showing being involved goes a long way to be
part of the process.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according
not a plug and play consideration. Its
probably easier for the ISP Web-based managers since its more of an
add-on to there current DNS software, using command line tools to act
on GUI posted information.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hec...@jabber.isdg.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
worth pursuing as a new I-D for DNS servers?
Thanks
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Vixie wrote:
On 2012-02-28 12:27 AM, Edward Lewis wrote:
At 13:35 -0500 2/27/12, Hector Santos wrote:
If it doesn't already exist or not considered in the past as an
unfeasible concept, I am interest in seeing if this is something
worth pursuing.
One (not the only, Ohta replied
-side login form concept?
--
Hector Santos, CTO
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
philly
trip, I tried to log on and interestingly got a new login form where
it indicated I was at a different location. I had to verify who I was
again, if I recall via my email/login account at gmail.com.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
. In a recent philly
trip, I tried to log on and interestingly got a new login form where
it indicated I was at a different location. I had to verify who I was
again, if I recall via my email/login account at gmail.com.
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hec
technologies is ok to patent (not the method in combining) as long as
they submit an IPR claim at the same thing of the I-D submission?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
of member's submissions.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
. In the mean time, here is
our auto-responder email address:
dkim-autoresp...@isdg.net
And for those with OpenDKIM setups exploring this, we have a wizard at
this URL to help prepare your records:
http://www.winserver.com/public/wcadsp
--
Hector Santos, CTO
http://www.santronics.com
coming from there.
Hope this helps
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
dkim-ops mailing list
dkim-ops@mipassoc.org
http://mipassoc.org/mailman/listinfo/dkim-ops
Hi,
Obviously, the key evolution is greater competition and market of display
devices, i.e. lack of a standard perhaps and patent restrictions which
promotes the propensity to just use HTML and HTML5 with OS file association
shell launching. This is especially the case since the 2006/2007
piece of the total integration
with the main proposed standard RFC along with other documents and
integration engineering conflicts fall through the review cracks.
When its finally caught, goals are now less realistic and the proposed
standard now becomes stagnant.
--
Sincerely
Hector Santos
http
and Mr Klensin might also be able to comment on
the impediments given that they are listed as the authors of a soon to
be published STD.
Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
Sincerely
Hector
not equally
applied. e.g., I don't wish to honor that other protocol SHOULD but
you MUST follow my protocol SHOULD.
--
Sincerely
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
is welcome.
http://www.ietf.org/id/draft-saintandre-2119bis-01.txt
Peter
--
Sincerely
Hector Santos
http://www.santronics.com
I addition, even if it was added by a piece of software, it does not
mean the operator MUST enabled it or that the software prevent him
from turning it off. I venture most
?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
Sincerely
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
downgraded, in debt and can not be
trusted?
All rhetorical questions. After all, they did Invent it. It should
be free to the IETF. :)
Just consider there are some in the DKIM arena who wanted for the x=
expiration tag to be deprecated and removed.
--
Sincerely
Hector Santos
http
of reporting the theft as soon as it is discovered.
Adam Novak wrote:
On Fri, Aug 26, 2011 at 1:13 PM, Hector Santos hsan...@santronics.com wrote:
Makes you wonder. Why is the concept of expiration required? �Did the IETF
expire, die? �Did its value as an Organization go down and only valid
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
Sincerely
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to amaze me.
--
Sincerely
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
501 - 600 of 2144 matches
Mail list logo
