on
RFC1372 Telnet Remote Flow Control Option
Since the requirement for moving to historic under the cruft draft is
that it is not widely implemented, all of these options must remain.
If there is desire to move these options to historic, then the guideline
must be altered.
Jeffrey Altman
should have an attribute specifying the byte order used.
My biggest concern is that this format is not general enough. I fear
that because the uses the authors were considering are not spelled out
that there are underlying assumptions embedded in the document which
will hamper its usefulness.
Jeffr
My personal opinion is that if there is a protocol that has been widely
deployed but which for whatever reason the IETF does not want to
encourage its adoption, the RFC should be published immediately as
HISTORIC.
Jeffrey Altman
Sam Hartman wrote:
>
> Hi. I believe the following requ
someone can serve.
Jeffrey Altman
P.S. - being curious:
what are the max terms for the IESG and IAB in their history?
what are the average terms for the IESG and IAB in their history?
what are the average and max terms of the current participants?
smime.p7s
Description: S/MIME Cryptographic
order to get
served.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
to hold a technical discussion were the four floating
microphones. Participants are more than capable of turning their heads
but when holding a technical discussion those extra mics make a
significant difference.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic
Lucy E. Lynch wrote:
> All -
>
> Information on the audio from the rooms can be found at:
> http://videolab.uoregon.edu/events/ietf/
>
> or you can go th http://www.ietf65.org and find a link to
> the audio services on the top level page.
>
Could someone please place a link to this info on
h
this warrants general discussion and possibly a
> document on stuffing vulnerabilities. Perhaps the same is also true of
> the address skew vulnerabilities, I need to think about it some more. I
> remember an IAB document on DOS vulnerabilities from a while ago, what
> is the status of
Does anyone have any recommendations for methods
of travel from the airport to the Delta Hotel?
I do not see any information on either the IETF66
or Delta Hotel web sites.
Thanks.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
travel at 17:20 in rush hour took
approximately 20 minutes in the taxi.
At the Delta Hotel there is no wireless in my room. There is a
wired connection for CDN$9.95 per 24 hours which has a reasonable
bandwidth at the current load.
Jeffrey Altman
Miao Fuyou wrote:
> The following informat
one piece of evidence that might change my opinion would be this.
Show me evidence that first time attendees at a local meeting results
in those attendees editing a document and becoming repeat attendees
in the future.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic
secondary benefits are things such as
making their campus more attractive for students, faculty, and staff to
join the university community and in the case of alumni to provide a
stronger bond to the university in order to increase alumni
contributions during fund raising efforts.
Jeffrey Altma
Robert Sayre wrote:
> On 9/19/06, Harald Alvestrand <[EMAIL PROTECTED]> wrote:
>> Robert Sayre wrote:
>> >
>> > I don't disagree. The IETF might first try to design an authentication
>> > feature worth requiring. None of the current options are at all
>> > satisfactory.
>>
>> In fact TLS + HTTP Bas
o believe that presenters should for the benefit
of the audio stream state the slide number they are on
as they give their presentation. This is important not
only for those listening live but also for those who listen
to the archive later on.
Jeffrey Altman
Kitten Chair
smime.p7s
Descriptio
ieve the registration procedure should be implemented as described
in the draft.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Sam Hartman wrote:
>>>>>> "Jeffrey" == Jeffrey Altman <[EMAIL PROTECTED]> writes:
>
> Jeffrey> Sam Hartman wrote:
> >> Unless there is strong support for the more complex
> >> registration process in the draft, we'd li
Joel Jaeggli wrote:
> The webpage for the streaming has been updated to reflect the schedule
> for monday and tuesday.
>
> http://videolab.uoregon.edu/events/ietf/
>
> One addition is that we intend to record and broadcast the Sunday IEPG
> meeting located in the crystal ballroom from 1000-1200 C
Marc Manthey wrote:
>
> On Jul 24, 2007, at 8:24 PM, Jeffrey Altman wrote:
>
>> Joel Jaeggli wrote:
>>> The webpage for the streaming has been updated to reflect the schedule
>>> for monday and tuesday.
>>>
>>> http://videolab.uoregon.edu/eve
Brian E Carpenter wrote:
> The financial fallacy in that is failing to note that about half the
> meeting fee isn't used to fund meeting expenses, but to fund continuing
> operations of the IETF as a whole (secretariat, RFC Editor, etc.) So
> restructuring the meetings would have to be done in a wa
7;t think this document
> should move forward.
That is your opinion and you are welcome to hold it.
However, it is clear to me that this problem area cannot be addressed by
organizations such as W3C without the support and collaboration
of the IETF.
Jeffrey
Marriott's announcement was that they had signed an agreement with
T-Mobile to provide the 802.11b network services. This is the same
company that provides the services at Starbucks in the U.S. My personal
opinion is that the service is pretty poor.
The available subscription plans are enumer
Peers
JXTA and Web Services
JXTA and IPv6
Performance enhancements
Please contact Jeffrey Altman <[EMAIL PROTECTED]> if you wish to
speak on one of the listed topics. A final agenda will be posted on
Monday, March 17th on the JXTA.ORG website.
We hope you will join us.
- The Project
hought the work was worthwhile.)
I realize that this e-mail is mostly just rambling thoughts but there
are no obvious answers jumping out to solve the funding problems of the
IETF.
- Jeffrey Altman
lease contact Jeffrey Altman <[EMAIL PROTECTED]> if you have
questions.
We hope you will join us.
- The Project JXTA Board
(*) This meeting is not an IETF event. The meeting is being held in
conjunction with IETF 56
to provide an opportunity for cross-participation between the Project
JX
believe detrimental to everyone if the various protocols which must
manipulate user identities did not have a common way of representing them.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
be requires to convert to Unicode before passing the
strings the various protocol libraries. This would allow us to develop
the network infrastructure independent of the user interface
infrastructure. It is unfortunate that this separation cannot be
maintained.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
le key info.
When using the current Kerberos implementations there is only enough
key info a single DES key which is used in both directions. Other
authentication methods provide enough key info for the 3DES to use
6 different DES keys with a Triple DES implementation (3 in each
direction).
> Jeffrey Altman <[EMAIL PROTECTED]> writes:
>
> > You are questioning the use of Triple DES but not the use of
> > CAST-128.
>
> I'm questioning the use of DES3 in anything but EDE on outer CBC
> mode. There is a paper by Eli Biham about other combination
d the net for almost eight years
with many implementations. Its time for them to move on.
- Jeff
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
UTH is currently RFC 1416. We are removing the
man in the middle attack that is possible with that RFC.
Please see my other postings to this thread for a discussion of TLS
and Telnet.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columb
ng in Telnet that is
ready to go standards track to replace telnet encryption it would be
inappropriate to issue it as Historical. When Telnet over TLS is
Proposed Standard we can re-examine the issue.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Ker
n has a part to play.
>
> #g
>
>
> Graham Klyne
> ([EMAIL PROTECTED])
>
FQDN's cause problems with security. DNS is not secure and it
is desireable to avoid contacting the DNS to establish whether or
not a given set of credentials are reliable for a
take and connect someone new at our NATed address.
>
> There are not enough Private Addresses to go around.
This sounds to me like more of an argument why private addresses
should be used on networks connected to public networks. It is not
an argument for more private networks but for the mov
e range of Internet access is severely limited.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
This leads me to question why the working group is in fact a working
group in the IETF.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://ww
areas where further research is required where the necessary
research is not difficult to perform.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
> At 09:59 AM 4/20/00 -0400, Jeffrey Altman wrote:
> >This draft is very incomplete and in my opinion not ready for prime
> >time. The working group has in the past requested lists of protocols
> >and applications which do not work with NATs. I have replied
> >discuss
> > From: Jeffrey Altman <[EMAIL PROTECTED]>
>
> > All of the energy and money being spent on NATs could and should be
> > spent to begin the migration to IPv6 instead.
>
> Oh, goody, another round of wasted time and energy arguing about IPv6
rections you need to follow. Stating that the
a problem in one context is described in the described in another
context is not useful in this document. It is exactly because of this
approach that the document comes across sounding as if the problems
described are trivial and inconsequential.
nge address bindings
> > during the lifetime of a ticket.
>
> True. However, the same problem applies without NAT if the client
> changes address bindings, so I wouldn't say this is really a
> NAT-related problem.
>
Under what conditions transparent to the user does a client
ctually accessible to the remote. So what you do is look at the
IP address on the local end of the socket that is being used to
connect to the remote system and insert that IP address into the
exported DISPLAY variable. This has of course worked for 20 years and
fails when a NAT is in the m
7.eclipse.co.uk != 212.104.136.138
Granted this is hardly a scientific study. But we see this from
approximately a dozen new addresses every day.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612
The premise is not true. When planning parties or even
volleyball tournaments I frequently send out e-mail to several hundred
friends. This is not spam. Arbitrary limits are not the answer.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
T
trust the
wireless provider's security and their promise not to look at my
data. I'm sorry, but this is not a system that I will rely on.
Since WAP is not end to end, it is of no use to me.
Jeffrey Altman * Sr.Software Designer
The Kermit Project *
hey need, not force
them to understand the subtle problems that are caused by the use of
NATs.
You have no idea how many students complain that they can't access
campus services due to the fact that Kerberos can't work through a
NAT.
Jeffrey Altman * Sr.Software Designer C-Kermit
eetings of other
> WGs. we need to encourage cross-pollenation between groups.
>
> but we don't need to encourage non-participants to attend IETF meetings.
>
> > In addition, turning away people who wish to attend seems counter to the
> > IETF spirit.
>
> the IETF spi
Sorry for the wasted bandwidth. But could someone please post the
lyrics to the IETF Christmas song, the video that was shown at the
Plenary.
Thanks.
Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available
The Kermit Project @ Columbia University includes Secure Telnet
eeting
time reading the drafts. Don't just go to the meeting. If you are
going to go to the meeting be prepared to speak. If you can't speak
to the subject, don't go to the meeting.
Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available
The Kermit Project @
> > We *should* worry about people who come to the IETF once and never come
> > back - because they probably came to the wrong meeting, and went home
> > unhappy.
>
> interesting idea.
>
> so assuming that a lot of folks come to the IETF expecting something
> different than it is, and going ho
already known in one of the WG communities;
and you came with an I-D that you were trying to build support for.
In other words, you were a participant rather than a lurker.
You are exactly the type of first timers that should come to IETF
meetings.
Jeffrey Altman * Sr.Software Designer C-K
el. We
might find that we have more attendees of higher quality with a
smaller space requirement. Not to mention fewer lurkers and fewer
newbies feeling dejected.
Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available
The Kermit Project @ Columbia University includes
I have days without wearing mine especially
now that the wireless networks are in place. I never even walk
into the terminal room unless I have to print something. With
single day attendance we will be forced to hire staff to check
badges to ensure compliance.
Jeffrey
"Anthony Atkielski" <[EMAIL PROTECTED]> wrote:
> > I'm really not interested in the opinions of people
> > who continuously rant and spam off-topic posts and
> > it seems that opinion is shared by a lot of
> > people on the list.
> That's what killfiles and filters are for.
> I _am_ interested
gt; > times the number of residental customers served.
> >
> > So they use flat-rate, per-residence pricing to attract the largest
> > number of residential customers. But they get annoyed when the
> > service is shared over multiple residences. They'd get just
Just to add my experience. I find that in order to get better airline
rates I am forced to travel into town on Saturday. So I'm in town on
Sunday with little to do other than catch up on work that really
should have been done before I arrived. So maybe doing more on Sunday
would be a possibilit
Can someone fix the X.509 certificate that is used to protect the TLS
sessions with conference.ietf.jabber.org ?
The hostname is wrong so verification fails.
On 2/4/2010 12:02 PM, Jeffrey Hutzelman wrote:
> --On Wednesday, February 03, 2010 03:27:01 PM -0800 Russ Allbery
> wrote:
>
>> SM writes:
>>> At 17:03 01-02-10, Russ Allbery wrote:
>>
Ah, thank you. Changed to SHOULD on the assumption that the
(pre-2119)
language in RFC 1034 was
On 2/4/2010 2:05 PM, Jeffrey Hutzelman wrote:
> That's not the text we're talking about.
>
Sure. Context was lost in the thread as the message-ids are not consistent.
The text I think is being discussed is not actually in the draft, it is
proposed
text that Russ put forward on 1 Feb 2010.
DNS
On 2/4/2010 2:30 PM, Jeffrey Hutzelman wrote:
> --On Thursday, February 04, 2010 02:20:27 PM -0500 Jeffrey Altman
> wrote:
>
>> On 2/4/2010 2:05 PM, Jeffrey Hutzelman wrote:
>>> That's not the text we're talking about.
>>>
>> Sure. Context
59 matches
Mail list logo
