On 8/30/2011 2:30 PM, Ole Jacobsen wrote:
Dean,
Before you give up completely I would check out:
http://wikitravel.org/en/Taipei
Taxis are not expensive, the Metro even less so, and there are at
least some budget hotels nearby. I expect the local hosts to provide
more information soon --
The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'The RPKI Ghostbusters Record'
draft-ietf-sidr-ghostbusters-12.txt as a Proposed Standard
note that some apps-area fixes have caused me to revise to -13
randy
I notice that section 3, to which IANA are directed, contains many formulations
such as
Specification document(s): [[anchor14: this document]]
Would I be right in thinking that this is what other documents would refer to as
RFC
-- Note to RFC-Editor - replace RFC by the RFC Number
t.petch wrote:
I notice that section 3, to which IANA are directed, contains many formulations
such as
Specification document(s): [[anchor14: this document]]
Would I be right in thinking that this is what other documents would refer to as
RFC
-- Note to RFC-Editor - replace RFC by
14.09.2011 20:14, Simon Perreault wrote:
Mykyta Yevstifeyev wrote, on 09/14/2011 01:10 PM:
Of course, you should have changed all references to vCard 4 to vCard 5, and
reference to VCARDDAV WG draft to RFC 6350.
vCard 4 is the latest version, specified in RFC 6350. We'll make a note to the
RFC
15.09.2011 11:59, Alexey Melnikov wrote:
t.petch wrote:
I notice that section 3, to which IANA are directed, contains many
formulations
such as
Specification document(s): [[anchor14: this document]]
Would I be right in thinking that this is what other documents would
refer to as
Mykyta Yevstifeyev wrote:
15.09.2011 11:59, Alexey Melnikov wrote:
t.petch wrote:
I notice that section 3, to which IANA are directed, contains many
formulations
such as
Specification document(s): [[anchor14: this document]]
Would I be right in thinking that this is what other
So some small comments:
1) A nit in Change controller field for all the header fields: you
should either change it to IESG (i...@ietf.org) or IETF with subsequent
address ietf@ietf.org.
2) Also, it might be useful to point out in the sub-sections of Section
3 which ABNF productions do the
On 2011-09-15 18:46, Mykyta Yevstifeyev wrote:
...
9) I'd like you hereby disallowed further registration of header fields
beginning with MMHS, likewise RFC 5504 Downgraded prefix
(http://tools.ietf.org/html/rfc5504#page-18).
...
No. It's a bad idea in RFC 5504, and it would be a bad idea
Dear all,
I've recently received a message from Ronald Bonica, one of the ADs,
proposing undertaking an effort to reclassify many pre-IETF (pre-1000)
RFCs as Historic. However, I initially had a concern regarding
community consensus on such effort, and whether it will be accepted so
that
I do not have a strong opinion on historical vs. experimental but I want to say
that solutions based on RFC 6074 (so called BGP-AD) have been deployed in
multiple networks some of them with mixed vendor environment.
-Original Message-
From: pwe3-boun...@ietf.org
My recollection is that this has already been done to a large degree.
Also, focusing on this specific set of RFCs would be a lot of work, for very
little actual value to the community.
On the other hand, I'd be very much in favor of IETF periodically reviewing ALL
standards-track RFCs for
I'm fully supportive of reclassifying any RFCs that pose a risk to the Internet
to historic but fail to see the usefulness of doing so for RFCs that describe
unused but non-harmful technologies - seems like busywork and useless at best.
Scott
On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev
ps - as Keith points out - a round of this type of effort was undertaken by the
newtrk
working group a while back (I was the chair and did not see much reason to
do so at the time but there was consensus in the WG to proceed) - I will note
that it took quite a bit of work to ensure that
On 15 September 2011 20:39, Scott O Bradner wrote:
as Keith points out - a round of this type of effort was
undertaken by the newtrk working group a while back
About five years back, IIRC, and with some limiting parameters.
I think this clean up was brilliant, and a new round with new
On 9/15/11 11:11 AM, Julian Reschke wrote:
On 2011-09-15 18:46, Mykyta Yevstifeyev wrote:
...
9) I'd like you hereby disallowed further registration of header fields
beginning with MMHS, likewise RFC 5504 Downgraded prefix
(http://tools.ietf.org/html/rfc5504#page-18).
...
No. It's a bad
On Sep 15, 2011, at 3:17 PM, Frank Ellermann wrote:
On 15 September 2011 20:39, Scott O Bradner wrote:
as Keith points out - a round of this type of effort was
undertaken by the newtrk working group a while back
About five years back, IIRC, and with some limiting parameters.
I think this
On 9/15/11 11:45 AM, Mykyta Yevstifeyev wrote:
undertaking an effort to reclassify many pre-IETF (pre-1000)
RFCs as Historic.
Given that these are pre-IETF RFCs, I move that we create a new
designation of Pre-Historic.
/psa
___
Ietf mailing list
Keith Moore wrote:
Problem is, the IETF isn't really big enough to have a good idea
about whether some technologies are still used.
+1
Another example: TLS Transport Layer Security.
If you look at the approx. current usage of the existing protocol
revisions:
SSLv3 (1996): 5%
I'm speaking as an individual, albeit an individual who helped with the
decrufting effort in NEWTRK ... http://www.ietf.org/rfc/rfc4450.txt, for
those who missed it.
undertaking an effort to reclassify many pre-IETF (pre-1000)
RFCs as Historic.
Given that these are pre-IETF RFCs, I move
Indeed. In fact there is a conversation currently on the pppext WG list in
which certain people are claiming that PPP (?!) is obsolete, demonstrating
that even subject-matter experts are often clueless about what's happening in
the real world...
Sent from Samsung tablet
Keith Moore
Total of 155 messages in the last 7 days.
script run at: Fri Sep 16 00:53:02 EDT 2011
Messages | Bytes| Who
+--++--+
16.77% | 26 | 16.19% | 201369 | to...@isi.edu
12.90% | 20 | 15.71% | 195482 |
On Sep 15, 2011, at 6:44 PM, Spencer Dawkins wrote:
I was in the rough on that one in 2005, but since we're looking at another
bulk recategorization effort, I might make this suggestion again - perhaps we
could define a new level, which might be called something like Not
Maintained, with
I thought the counting of votes was finished on this topic but people seem to
keep emailing their support/lack-of, so naturally I will be a good lemming and
do the same.
1) I am in favor of the two-maturity-levels draft and change. I have consulted
a textbook on Euclidean geometry and
The IESG has approved the following document:
- 'Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)'
(draft-ietf-radext-crypto-agility-requirements-07.txt) as an
Informational RFC
This document is the product of the RADIUS EXTensions Working Group.
The IESG contact persons
25 matches
Mail list logo
