Christian Huitema wrote:
For the IETF, there is a tension between two goals: protocols that are
reviewed and documented, so there can be multiple implementations; and
protocols that have a high quality so they run very well on the
Internet. If the IETF focuses a lot on quality and makes it too
Peter Dambier wrote:
Still they have nameservers and they happily communicate with
each other without ICANN even nowing about their existence.
Out of touch with reality.
regards
joe
Cheers
Peter and Karin
At 16:06 15/02/2006, Brian E Carpenter wrote:
When considering some recent
On Feb 17, 2006, at 11:14, Tom.Petch wrote:
Elsewhere - dictionaries, encyclopaedia, text books - I see it
defined so that when applied to a sequence of numbers, then each
number is not
less than its predecessor, so that
That's non-decreasing. As far as I've ever heard (math classes as
The phrase 'monotonic increasing' seems to be a Humpty-Dumpty one, used with a
different sense within RFC to that which I see defined elsewhere; and this
could lead to a reduction in security.
Elsewhere - dictionaries, encyclopaedia, text books - I see it
defined so that when applied to a
At 09:35 17/02/2006, IETF Chair wrote:
The IESG today makes the following statement, but will welcome
community feedback on it.
Dear Brian,
Comments embedded.
According to RFC 2418 as updated by RFC 3934, WG chairs have
the power to suspend disruptive posters on WG mailing lists for
periods
Ken Raeburn wrote:
I'd be surprised to see sources for the other usage.
A Dictionary of mathematics offers both definitions, first
what you found f(x) f(y) for x y. Followed by the other
definition f(x) = f(y), where the first case would be called
strictly monotone. I vaguely recall that
Hi Ken,
on 2006-02-17 18:46 Ken Raeburn said the following:
On Feb 17, 2006, at 11:14, Tom.Petch wrote:
Elsewhere - dictionaries, encyclopaedia, text books - I see it
defined so that when applied to a sequence of numbers, then each
number is not
less than its predecessor, so that
Hi.
Tom.Petch wrote:
The phrase 'monotonic increasing' seems to be a Humpty-Dumpty one, used with a
different sense within RFC to that which I see defined elsewhere; and this
could lead to a reduction in security.
Elsewhere - dictionaries, encyclopaedia, text books - I see it
defined so that
JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes:
JFC I understand the lack of definition of the Area. I suggest
JFC that decisions name the consulted Area Director. This
JFC decision is not complete. It should define who are to be on
JFC the appeal cycle.
I actually think
Elwyn
To be more concrete, I have some 1800 RFC readily available and find monotonic
in 54 of them from RFC677 (1975) to RFC4303.
Plucking a few at random, RFC3412 (SNMP) suggests that monotonic increasing
would avoid reuse while RFC2406 (IPsec) suggests monotonic increasing can be
used in the
In your previous mail you wrote:
A Dictionary of mathematics offers both definitions, first
what you found f(x) f(y) for x y. Followed by the other
definition f(x) = f(y), where the first case would be called
strictly monotone. I vaguely recall that strict (in the
German
On Thu, 16 Feb 2006, The IESG wrote:
The IESG has received a request from the Point-to-Point Protocol
Extensions WG to consider the following document:
- 'Accommodating an MTU/MRU greater than 1492 in PPPoE '
draft-arberg-pppoe-mtu-gt1492-02.txt as an Informational RFC
I think this is
Hmm! I don't think I see your problem with any of the usages in the
RFCs mentioned. In all cases monotonically is used to express that the
sequence is non-decreasing which is in line both with the mathematical
definition and the Merriam-Webster online dictionary #2 sense. In some
of the cases
On Fri, 17 Feb 2006, James Carlson wrote:
Pekka Savola writes:
This doc seems to define a PPPoE option 'PPP-Max-Payload'. It talks
of using PPP MRU option. There is no PPP MTU option that I could see.
My question here is, should there be a PPP MTU option instead of a
PPPoE option? This
I agree that there is no clear cut case where security will be compromised, but
as long as RFC eg RFC1510 (kerberos) tie the concept of nonce to a monotonic
increasing sequence, I think the risk is there and could easily be avoided if we
started using the term 'strictly increasing' instead.
Of
Huh. You learn somethin' new every day...
On Feb 17, 2006, at 16:06, Tom.Petch wrote:
I agree that there is no clear cut case where security will be
compromised, but
as long as RFC eg RFC1510 (kerberos) tie the concept of nonce to a
monotonic
increasing sequence, I think the risk is there
I think we disagree significantly on the level of formality needed
here.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Jefsey == Jefsey Morfin [EMAIL PROTECTED] writes:
Jefsey At 03:19 18/02/2006, Sam Hartman wrote:
I think we disagree significantly on the level of formality
needed here.
Jefsey yes. But I know future will turn me right
Jefsey unfortunately. You cannot fight disruption
Hi All,
NeuStar Secretariat Services will be migrating the IETF to new servers in
accordance with the schedule below. All work will be done on the weekends to
minimize disruptions, but there are periods when services will be down.
As the second part of the IETF server migration, we will be
There are two (2) Internet-Draft cutoff dates for the 65th
IETF Meeting in Dallas, TX, USA:
February 27th: Cutoff Date for Initial (i.e., version -00)
Internet-Draft Submissions
All initial Internet-Drafts (version -00) must be submitted by Monday,
February 27th at 9:00 AM ET. As always,
The IESG today makes the following statement, but will welcome
community feedback on it.
According to RFC 2418 as updated by RFC 3934, WG chairs have
the power to suspend disruptive posters on WG mailing lists for
periods of 30 days. However, this power is not documented
for the moderators or
The IESG has received a request from an individual submitter to consider the
following document:
- 'TLS User Mapping Extension'
draft-santesson-tls-ume-02.txt as a Proposed Standard
The TLS User Mapping extension enables a client to send a name hint to
a server during a TLS handshake,
The IESG has received a request from the Session Initiation Proposal
Investigation WG to consider the following document:
- 'Framework and Security Considerations for Session Initiation Protocol (SIP)
Uniform Resource Identifier (URI)-List Services '
draft-ietf-sipping-uri-services-05.txt
A new Request for Comments is now available in online RFC libraries.
RFC 4349
Title: High-Level Data Link Control (HDLC)
Frames over Layer 2 Tunneling Protocol,
Version 3 (L2TPv3)
Author: C. Pignataro, M.
A new Request for Comments is now available in online RFC libraries.
RFC 4291
Title: IP Version 6 Addressing Architecture
Author: R. Hinden, S. Deering
Status: Standards Track
Date: February 2006
Mailbox:[EMAIL
A new Request for Comments is now available in online RFC libraries.
RFC 4396
Title: RTP Payload Format for 3rd
Generation Partnership Project (3GPP) Timed Text
Author: J. Rey, Y. Matsui
Status: Standards Track
26 matches
Mail list logo
