There are many Last Call comments that need to be resolved, so I have
removed the document from the agenda. I have been trying to schedule
some time with the authors to discuss the many Last Call comments. This
has been difficult. My schedule is overly tight right now, not the authors.
Note
I see that this (still the same version) is On agenda of 2010-05-06
IESG telechat, and I must say I'm a little surprised, since I counted
seven clear objections to the document and no strong supporting
comments. Also, IANA said IANA does not understand the implications
of the IANA Actions
On Thu, 18 Mar 2010, Brian E Carpenter wrote:
In my opinion this is not ready for prime time.
+1
I concur with Brian's points #1 and #2.
I'm further concerned about DISCOURAGED. Here it is defined as
Implementations SHOULD support this functionality, which seems very
counter-intuitive.
On Thu, 18 Mar 2010, Brian E Carpenter wrote:
In my opinion this is not ready for prime time.
+1
I concur with Brian's points #1 and #2.
I'm further concerned about DISCOURAGED. Here it is defined as
Implementations SHOULD support this functionality, which seems very
counter-intuitive.
On 18/03/2010 12:31 PM, 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 these elements
At 10:33 AM -0400 3/19/10, Olafur Gudmundsson wrote:
Well here a proposed problem statement for the requirement:
How does an implementer of a protocol X, find which ones of the many
features listed in registry Y, he/she needs to implement and which
ones are obsolete.
and
How does an
On 19/03/2010 12:14 PM, Paul Hoffman wrote:
At 10:33 AM -0400 3/19/10, Olafur Gudmundsson wrote:
Well here a proposed problem statement for the requirement:
How does an implementer of a protocol X, find which ones of the many
features listed in registry Y, he/she needs to implement and
Olafur,
In my mind there are basically three kinds of IETF working groups:
1) New protocols/protocol extensions frequently with limited
attention to operations.
2) Protocol maintainance groups
3) Operational groups
RFC2119 words are aimed at the first type, and can to
SM wrote:
One of the effects
of this proposal is that the programmer will be complying with the
IANA registry to cherry pick which protocol or algorithm to implement.
I don't understand what you mean by implementing an IANA registry.
I do
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
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
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
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
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 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
In my opinion this is not ready for prime time.
Basically: it's inconsistent with the requirements part of RFC 2026
and inconsistent with RFC 2119. I don't think we should create
confusion by such inconsistency.
There are three main aspects of this inconsistency:
1. 3.1. MANDATORY
This is
At 9:43 AM +1300 3/18/10, Brian E Carpenter wrote:
In my opinion this is not ready for prime time.
I agree with all of Brian's issues, and add another one that is equally, if not
more, significant. This document talks about an IANA registry having entries
for compliance, but does not describe
At 10:45 17-03-10, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Definitions for expressing standards requirements in IANA registries.'
draft-ogud-iana-protocol-maintenance-words-03.txt as a BCP
The IESG plans to make a
Ah, yes, Paul is quite correct. My implicit assumption was
that such keywords would be added to an IANA registry only
in as far as they echo IETF standards track documents (including
the deprecation or obsolescence of such documents). Of course,
IANA itself cannot add normative requirements - only
At 1:10 PM +1300 3/18/10, Brian E Carpenter wrote:
Ah, yes, Paul is quite correct. My implicit assumption was
that such keywords would be added to an IANA registry only
in as far as they echo IETF standards track documents (including
the deprecation or obsolescence of such documents). Of course,
24 matches
Mail list logo
