Dear Brian, list,
On 3/6/10 12:28 AM, The IESG wrote:
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-04-02.
I support the introduction of the new attribute.
At
Dear colleagues,
On Wed, Mar 17, 2010 at 04:10:58PM -0700, Paul Hoffman wrote:
It is *fine* to have an RFC specify which algorithms must be
implemented / supported / whatever for compliance to the RFC; we do
that now just fine. When the community agrees on changes to what is
needed to
I'm American from Brazil we always use dd/mm/ :-)
Anyway, in a computer context I think that -mm-dd is a good design,
because I'ts easier to sort and organize by a script in a cronological
order.
As it may cause a lot of confusion, I assume that one way is to use a tag to
identify date
1. 3.1. MANDATORY
This is the strongest requirement and for an implementation to
ignore
it there MUST be a valid and serious reason.
That is also neither my, not my dictionary's (compulsory, admitting
no option) interpretation of the word in everyday use.
--On Thursday, March 18, 2010 09:25 -0400 Andrew Sullivan
a...@shinkuro.com wrote:
...
Moreover, it would be awfully nice if we captured somewhere,
This algorithm is still required, but it's on its way out,
and, That algorithm isn't required yet, but real soon now it
will be. That way,
John,
On Thu, Mar 18, 2010 at 10:01:26AM -0400, John C Klensin wrote:
Interestingly, a few mechanisms for handling that sort of
narrative and organizing information were extensively discussed
several years ago.
Thanks for this. Do you know whether any of this got as far as being
written in
--On Thursday, March 18, 2010 10:15 -0400 Andrew Sullivan
a...@shinkuro.com wrote:
John,
On Thu, Mar 18, 2010 at 10:01:26AM -0400, John C Klensin wrote:
Interestingly, a few mechanisms for handling that sort of
narrative and organizing information were extensively
discussed several
Vesna Manojlovic wrote:
Dear Brian, list,
On 3/6/10 12:28 AM, The IESG wrote:
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-04-02.
I support the introduction
# General Area O. Gudmundsson
# Internet-Draft Shinkuro Inc.
# Updates: 5226 (if approved) S. Rose
# Intended status: Standards Track
But the order on the stack is year, month, day!
On Wed, Mar 17, 2010 at 11:23 AM, Robert Kisteleki rob...@ripe.net wrote:
On 2010.03.13. 19:23, Stephane Bortzmeyer wrote:
On Sat, Mar 13, 2010 at 05:13:41PM +0100,
Arnt Gulbrandsena...@gulbrandsen.priv.no wrote
a message of 17 lines which
I agree with Iljitsch's earlier point: In this day and age, if one is
not sure how to interpret 2010-01-02 at first glance, he should have no
trouble figuring it out right away. We would expect people who are
interested in IETF material to have the curiosity to find out, wouldn't
we?
What I am
- Original Message -
From: HUANG, JERRY (ATTLABS) zh1...@att.com
To: Iljitsch van Beijnum iljit...@muada.com; memcn...@gmail.com
Cc: Yao Jiankang ya...@cnnic.cn; ietf@ietf.org
Sent: Thursday, March 18, 2010 12:51 AM
Subject: RE: What day is 2010-01-02
What I am not so sure about is
That would meet most of my issues, provided of course that the XML2RFC
format was published.
Zero time spent going to an editable format is better than any amount
of 'easy conversion'.
On Wed, Mar 17, 2010 at 9:03 PM, Tony Hansen t...@att.com wrote:
+1
On 3/17/2010 12:18 PM, John R. Levine
Well the US pint is 16 fluid oz which is 1 lb of water. The UK pint is
20 so a pint of water is a pound and a quarter. Go figure.
But since we are on the subject of time, why accept UTC as the basis
for Internet time? Leap seconds are unpredictable and lead to system
errors. The only group with a
Hi all
Based on the suggestion of Jerry we have written an example on matching
the initiator QSPEC to a local RMD-QSPEC, see below!
We would like to include this section in Appendix A.6 of the new version
of the RMD-QOSM draft.
-
A.6. Example on matching the initiator
On Thu Mar 18 03:27:30 2010, Phillip Hallam-Baker wrote:
That would meet most of my issues, provided of course that the
XML2RFC
format was published.
There's a rfc2629bis at/as
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html
Is there anything you feel that's not covering?
At 9:25 AM -0400 3/18/10, Andrew Sullivan wrote:
The DNSSEC algorithm registry has no slot in it to indicate the
support level appropriate to each algorithm.
True. What does support level apply to? RFC 4034? RFCs {4034 | others}?
DNSSEC-the-protocol? The IANA registry itself? Without a precise
If the real reason for this draft is to set conformance levels for
DNSSEC (something that I strongly support), then it should be a one-page
RFC that says This document defines DNSSEC as these RFCs, and
implementations
MUST support these elements of that IANA registry. Then, someone can
On Mar 18, 2010, at 12:00 AM, Phillip Hallam-Baker wrote:
Well the US pint is 16 fluid oz which is 1 lb of water. The UK pint is
20 so a pint of water is a pound and a quarter. Go figure.
But since we are on the subject of time, why accept UTC as the basis
for Internet time? Leap seconds are
YAO Jiankang ya...@cnnic.cn wrote:
HUANG, JERRY (ATTLABS) zh1...@att.com wrote:
What I am not so sure about is the sweeping statement that Americans
would likely have difficulties with the '-mm-dd' format. I walked
around the office and polled seven of my co-workers who happen to be
On 18 mar 2010, at 17.38, Marshall Eubanks wrote:
This is backwards. Most astronomers I know regard UTC as a nuisance. In their
calculations, astronomers use TAI (or, if they need to know the rotation of
the Earth, UT1). Solar system ephemeris work uses ephemeris time, for
historical
John R. Levine wrote:
between the XML and the final output. If we could agree that the final
XML was authoritative,
John,
What, precisely, do you mean here? Do you mean that there would be NO
text form of an RFC that was authoritative, or do you mean that BOTH the
xml2rfc form and some
2010/3/18 Alfredo Dal´Ava Júnior alfredo.dal...@gmail.com
I'm American from Brazil we always use dd/mm/ :-)
So, that's how Brazilians refer to themselves and each other: I'm an
American? And even if so (which I very much doubt), spelled that way as in
American [sic] English? Yeah, sure.
At 9:15 PM -0500 3/13/10, Phillip Hallam-Baker wrote:
So what has me annoyed about the IAB advice is that they gave advice
about a particular means where they should have instead specified a
requirement.
Phil,
I am not commenting on your proposal, but I do want to make a few
observations
At 06:25 18-03-10, Andrew Sullivan wrote:
I understand this objection, and I have some sympathy with it. At the
same time, there is a serious problem with at least one registry that
the draft aims to fix. I think that problem is worth taking on.
According to the draft, the problem is about
between the XML and the final output. If we could agree that the final XML
was authoritative,
What, precisely, do you mean here? Do you mean that there would be NO text
form of an RFC that was authoritative, or do you mean that BOTH the xml2rfc
form and some text-equivalent form (say, .txt
I'm very support of this draft and think it should move forward but I have a
NIT to pick with it.
It says the ABNF in 3261 is incorrect and this one corrects it. I don't believe
that is correct. I believe the ABNF in this draft is more specific than the one
in 3261 but they are both correct.
At 2:17 PM -0400 3/18/10, Phillip Hallam-Baker wrote:
Before declaring victory, lets see if anyone actually uses it to
validate any data.
fair enough. anything else is speculation by both of us, so lets
table the discussion for a year or so.
Steve
Given these observations, the public declaration last year by the NRO
that all 5 RIRs will offer RPKI service as of 1/1/11, and the
ongoing SIDR WG efforts, most of this discussion seems OBE at this
stage.
Steve,
Thanks for your comments here, not surprisingly, they're spot on...
On Mar 18, 2010, at 12:47 PM, Patrik Fältström wrote:
On 18 mar 2010, at 17.38, Marshall Eubanks wrote:
This is backwards. Most astronomers I know regard UTC as a
nuisance. In their calculations, astronomers use TAI (or, if they
need to know the rotation of the Earth, UT1). Solar system
On 18 mar 2010, at 20.04, Marshall Eubanks wrote:
Hmm...the signal for the GPS include the difference nowadays, right?
This is the internal time standard. GPS receivers report UTC.
That was exactly my point. The device get the internal time, and then correct
it according to the difference
On Thu, 18 Mar 2010, Phillip Hallam-Baker wrote:
Well the US pint is 16 fluid oz which is 1 lb of water.
Not quite, it's about 4% out.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.
On Thu, 18 Mar 2010, Marshall Eubanks wrote:
Now, it is true that Ken Seidelmann is an astronomer, and he is
against the change, but that is mostly in a if is isn't broke, don't
fix it mode, and also because he is thinking of the long term (in 500
to 600 years the UT1-TAI offset should be
On 18 mrt 2010, at 2:43, Richard Barnes wrote:
+1
Making the XML normative would be an abomination.
The XML in itself can't be interpreted by a human to the level needed to create
a compliant implementation, although it deceptively looks like maybe it could.
Of course human readability also
On Thu, 18 Mar 2010, Patrik Fältström wrote:
We should from IETF point of view review the ical spec, and try to push
timezone information away from the objects, and to a central repository.
The timezone offset should be calculated based on the geographical
location of the event.
Yes.
On 18.03.2010 20:24, Iljitsch van Beijnum wrote:
On 18 mrt 2010, at 2:43, Richard Barnes wrote:
+1
Making the XML normative would be an abomination.
The XML in itself can't be interpreted by a human to the level needed to create
a compliant implementation, although it deceptively looks
I was just referring about one of last posts were someone had a mistake
about American definition and South America is America too, not only
United States. :)
We call ourself as Brazillian, ou melhor, Brasileiros! :)
In portuguese, the best definition for United States people is
Estadosunidenses,
On 18 mrt 2010, at 20:59, Julian Reschke wrote:
The XML in itself can't be interpreted by a human to the level needed to
create a compliant implementation, although it deceptively looks like maybe
it could. Of course human readability also doesn't exist for pretty much
anything other than
On 18.03.2010 21:25, Iljitsch van Beijnum wrote:
...
That is simply incorrect, which can easily be checked by looking at the XML
source of a spec.
People make mistakes implementing today's text. If they have to implement from
XML source where they have to interpret things like escape codes
On 03/18/2010 09:37 PM, Julian Reschke wrote:
And how are numbered lists a problem?
I thought it was a pain because I got comments referring to x and the
file I edited contained no x. xml2rfc generated numbers, people used
them to me, I didn't see them in the source.
In general I think the
On Mar 18, 2010, at 3:05 PM, Phillip Hallam-Baker wrote:
Well quite, I said that it illustrated the mode of argument, not that
the arguments were valid.
The arguments made on behalf of 'astronomers' are of course made by
assertion without bothering to ask what astronomers might think. Every
Cullen,
I believe that the RFC 3261 ABNF *is* plain incorrect. It allows the
generation of text representations including ::: and that is
clearly not intended to be allowed by the description in RFC 4291.
(Being precise, it says The :: can only appear once in an address.
whereas I can find it
On 18.03.2010 21:41, Arnt Gulbrandsen wrote:
On 03/18/2010 09:37 PM, Julian Reschke wrote:
And how are numbered lists a problem?
I thought it was a pain because I got comments referring to x and the
file I edited contained no x. xml2rfc generated numbers, people used
them to me, I didn't see
Christian,
On 2010-03-19 05:31, Christian Huitema wrote:
If the real reason for this draft is to set conformance levels for
DNSSEC (something that I strongly support), then it should be a one-page
RFC that says This document defines DNSSEC as these RFCs, and
implementations
MUST support
On 03/18/2010 01:52 PM, Julian Reschke wrote:
On 18.03.2010 21:41, Arnt Gulbrandsen wrote:
On 03/18/2010 09:37 PM, Julian Reschke wrote:
And how are numbered lists a problem?
I thought it was a pain because I got comments referring to x and the
file I edited contained no x. xml2rfc generated
In message a123a5d61003170838s440bacddudb791a909cd5e...@mail.gmail.com, Phill
ip Hallam-Baker writes:
But the order on the stack is year, month, day!
And the month is *between* the day and the year. Nothing illogical with
this order.
On Wed, Mar 17, 2010 at 11:23 AM, Robert Kisteleki
--On Friday, March 19, 2010 09:55 +1300 Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
...
Third that. In fact, this exactly the purpose of
applicability statement standards track documents, as
defined in RFC 2026 for many years.
I have lingering sympathy for the ISD idea that John
On 18 Mar 2010, at 20:41, Arnt Gulbrandsen a...@gulbrandsen.priv.no
wrote:
On 03/18/2010 09:37 PM, Julian Reschke wrote:
And how are numbered lists a problem?
I thought it was a pain because I got comments referring to x and
the file I edited contained no x. xml2rfc generated numbers,
On Thu, Mar 18, 2010 at 12:24 PM, Iljitsch van Beijnum
iljit...@muada.com wrote:
If we really want to do something in this space first of all we need to agree
on the problem, then on the requirements and THEN we can have a useful
discussion. So far the only thing I hear is assertions offered
I don't have any problem editing the source in one window while
viewing the presentation document in another.
Window? My ASR-33 doesn't have any windows.
R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
If we really want to do something in this space first of all we
need to agree on the problem, then on the requirements and THEN we
can have a useful discussion.
I thought the waterfall model of software design was discredited in
about 1975.
Rough consensus and running code, throwing darts at
Total of 258 messages in the last 7 days.
script run at: Fri Mar 19 00:53:03 EDT 2010
Messages | Bytes| Who
+--++--+
10.47% | 27 | 9.15% | 156648 | julian.resc...@gmx.de
8.14% | 21 | 9.09% | 155588 |
Greetings All,
Please note that the RFC Editor will be hosting office hours at IETF
77. This is the first time we'll have all of the editor team present,
so please stop by if you have any questions or just to say hello.
The RFC Editor desk will be located in the IETF registration area and
will
77th IETF Meeting
Anaheim, CA, USA
March 21-26, 2010
Online Registration ends: Friday, 19 March, 2010 at 17:00 PT (24:00 UTC)
On-site Registration
You can register onsite at the meeting in Anaheim, CA, USA starting
Sunday, 21 March 2010 at 12:00 noon PT.
A new Request for Comments is now available in online RFC libraries.
RFC 5810
Title: Forwarding and Control Element Separation
(ForCES) Protocol Specification
Author: A. Doria, Ed.,
J. Hadi Salim, Ed.,
A new Request for Comments is now available in online RFC libraries.
RFC 5812
Title: Forwarding and Control Element Separation
(ForCES) Forwarding Element Model
Author: J. Halpern, J. Hadi Salim
Status: Standards Track
A new Request for Comments is now available in online RFC libraries.
RFC 5789
Title: PATCH Method for HTTP
Author: L. Dusseault, J. Snell
Status: Standards Track
Date: March 2010
Mailbox:lisa.dussea...@gmail.com,
A new Request for Comments is now available in online RFC libraries.
RFC 5795
Title: The RObust Header Compression (ROHC)
Framework
Author: K. Sandlund, G. Pelletier,
L-E. Jonsson
Status: Standards
A new Request for Comments is now available in online RFC libraries.
RFC 5796
Title: Authentication and Confidentiality in Protocol
Independent Multicast Sparse Mode (PIM-SM) Link-Local
Messages
Author: W.
A new Request for Comments is now available in online RFC libraries.
RFC 5814
Title: Label Switched Path (LSP) Dynamic
Provisioning Performance Metrics in Generalized MPLS
Networks
Author: W. Sun, Ed.,
A new Request for Comments is now available in online RFC libraries.
RFC 5820
Title: Extensions to OSPF to Support
Mobile Ad Hoc Networking
Author: A. Roy, Ed.,
M. Chandra, Ed.
Status: Experimental
61 matches
Mail list logo
