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 the
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 reques
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.
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
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 which
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 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 o
--On Friday, March 19, 2010 09:55 +1300 Brian E Carpenter
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 Klensin
> referred t
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
>> MUS
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 ho
> 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
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 precis
--On Thursday, March 18, 2010 10:15 -0400 Andrew Sullivan
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 years ago.
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
--On Thursday, March 18, 2010 09:25 -0400 Andrew Sullivan
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, when a devel
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 c
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
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 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.'
as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final
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 w
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
21 matches
Mail list logo