Subject: Re: Last Call: draft-ogud-iana-protocol-maintenance-words (Definitions for expressing standards requirements in IANA registries.) to BCP

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Mar 2010 09:43:34 +1300

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 the strongest requirement and for an implementation to ignore
   it there MUST be a valid and serious reason."

That is in effect the meaning of SHOULD as defined in RFC 2119:

"3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

There is no way we can reasonably equate MANDATORY as defined in
the new draft with SHOULD as defined for the last 13 years (and
very widely used by other SDOs; RFC 2119 is, I believe, by far
the most widely cited RFC).

MANDATORY can only resonably be equated with MUST, which is defined
in RFC 2119 thus:

"1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification."

There is no escape clause. It is quite clear there must be no escape
clause for MANDATORY. However, the RFC 2119 adjective that maps
MUST is REQUIRED, and that should be used to map MUST into an IANA
registry. There's no need to confuse people with a new word.

2. With that fixed, the draft doesn't contain a term equivalent to SHOULD.
There's a perfectly good adjective for that in RFC 2119: RECOMMENDED.

3. The draft adds confusion by attempting to map the very dubious
terms SHOULD+, MUST- and SHOULD-. These are not defined in our
standards process and have been used in a very debatable way (IMHO),
both in a handful of IETF documents and elsewhere.

I simply cannot see the value of deviating from REQUIRED, RECOMMENDED
and OPTIONAL. These are clear, self-defining and widely used words.

There is value in adding OBSOLETE and RESERVED for use in IANA registries.

There is value in the concept behind the proposed AVAILABLE:

"3.7.  AVAILABLE

   This is a value that can be allocated by IANA at any time.
   Implementations:  Implementations SHOULD NOT use these values..."

However, the choice of keyword is poor. An outsider seeing that
protocol number 143 is AVAILABLE might be delighted to start using it.
The current word used by IANA is UNASSIGNED and that is much better.

Bottom line, I am completely against this draft in its current form.
It will create nothing but confusion.

Regards
   Brian Carpenter

On 2010-03-18 06:45, 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 decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2010-04-14. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ogud-iana-protocol-maintenance-words-03.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19259&rfc_flag=0
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Mar 2010 16:10:58 -0700

>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 what the compliance is applied to.

>3.1.  MANDATORY
>   it there MUST be a valid and serious reason.
>
>   Implementations:  To be considered compliant, all implementations
>      MUST support this registry entry.
>   Operations:  To be considered compliant, operations MUST use at least
>      one of the mandatory entries.
>   Note 1:  There can be more than one MANDATORY requirement.
>   Note 2:  The requirement applies only to new or future
>      implementations on the day the requirement is released.  In many
>      cases existing implementations can become compliant via software
>      upgrade or point release.

Look at an IANA registry such as the one that prompted this draft, <http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>. If there is an algorithm that is now marked "MANDATORY", and your implementation did not have it, you would not be in compliance with the registry.

The IETF has never had a concept of compliance to an IANA registry, which is a good thing. Suggesting that we should start doing that now is just plain wrong.

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 comply with an RFC, you update the RFC; we now do that just fine as well.

Putting new words in an IANA registry will make things more confusing, not less.

--Paul Hoffman, Director
--VPN Consortium

---

From: SM <[email-masked]>
Date: Wed, 17 Mar 2010 16:11:27 -0700

>final comments on this action.  Please send substantive comments to the

The Intended Status is listed as "Standards Track" whereas the 
announcement says BCP.

Quoting Section 1:

   "The DNSEXT working group decided to try to decrease the number of
    algorithms listed in the registry and add a column to the registry
    listing the requirements level for each one.  Upon reading that
    HMAC-MD5 was tagged as "OBSOLETE" a firestorm started."

Do we really have to call a duck by another name to quell a firestorm? :-)

   "A now expired draft (draft-hoffman-additional-key-words) attempted
    to establish these additions as new keywords but was never fully
    adopted."

That's "Work in Progress".

Section 2 defines terminology.  Are the RFC 2119 keywords really 
necessary?  For example, MANDATORY (Section 3.1) is defined as:

   "This is the strongest requirement and for an implementation to ignore
    it there MUST be a valid and serious reason."

Based on my reading, this means that I can ignore a mandatory 
requirement if I can find a valid reason to do so.

I take it that DISCRETIONARY means that we don't care whether you do 
or don't do it.  A MAY in RFC 2119 terms means optional.

In Section 3.3, OBSOLETE (for operations) is defined as MUST be 
phased out.  For implementations, it means SHOULD NOT support this 
functionality.  I could use RFC 4892 and RFC 5001 as examples. :-)

In Section 3.7, the term AVAILABLE is defined.  Any implementation 
claiming to know the meaning of this unallocated code MUST NOT be 
used.  If I am not mistaken, there was such a case last year.  Some 
people will read "AVAILABLE" as free for use.

I unfortunately cannot support this document as it would only 
encourage the usual discussions about keywords and I doubt that 
introducing new terms would have the intended effect.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Mar 2010 13:10:02 +1300

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 an IETF
standards action can do that.

Regards
   Brian

On 2010-03-18 12:10, Paul Hoffman wrote:
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Mar 2010 17:34:10 -0700

>standards action can do that.

But even then, there are problems. Most IANA registries can apply to more than one RFC. If Registry A is created by RFC X, and RFC X is updated by RFC Y, everyone understands that the registry applies to both RFC X and RFC Y. But if Y introduces different "mandatoryness", what does it mean for compliance to RFC X? Does one clone Registry A into Ax and Ay?

The basic idea of this draft puts the compliance wording in IANA registries instead of in the RFCs themselves. This is fine for single-RFC registries, but falls apart completely for registries that apply to more than one. There is no need for this: let RFCs continue to define compliance to the RFC.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Mar 2010 09:25:23 -0400

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 comply with an RFC, you update the RFC; we now do that
> just fine as well.
> 

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.

The DNSSEC algorithm registry has no slot in it to indicate the
support level appropriate to each algorithm.  As we saw in recent
debates, there is considerable feeling among IETF participants that
some algorithms need to be supported by everybody, and some are likely
only to be required in particular situations.

Today, if you want to find out whether an algorithm is mandatory to
implement, or optional to implement, you have to go and read through
every RFC for every algorithm, as well as some other RFCs that don't
actually specify an algorithm but instead specify the protocol.  This
is a trivial task for someone familiar with the ways of the IETF.  For
someone unfamiliar with those ways, it is a convoluted mess that is
hard to navigate.  Not every programmer is as diligent as we might
like, and so if we put this sort of barrier in the way of proper
implementation, what we'll get is lousy interoperability.  

So I think it is very important that registries have _some_ way of
indicating which algorithms are needed by everyone, and which ones
not.

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 developer of code is trying to decide what to do, there is
a useful guide not only of what the state of affairs is today, but
what it likely will be in six months, one year, &c.  (I'm aware of the
amusement likely to be caused by the idea that DNSEXT could actually
plan what work will really be done in the next 6-12 months.)

If we accept that broad outline, then we quickly drive towards
something like the distinctions currently made in the draft under
consideration.

Now, there's no reason that this has to entail "conformance with a
registry".  The registry could surely have some way of noting what RFC
set the level, thereby returning us to the state Paul is asking for
(conformance with RFCs, not registries).

Does anyone else think that the distinctions we're talking about are
indeed worth indicating somehow in a registry?  If so, I think the
current draft is a good basis for that work, even if we determine that
the current text is not quite what we want.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 18 Mar 2010 13:49:04 -0000

>   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.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Mar 2010 10:01:26 -0400

--On Thursday, March 18, 2010 09:25 -0400 Andrew Sullivan
<[email-masked]> 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 developer of code is trying to
> decide what to do, there is a useful guide not only of what
> the state of affairs is today, but what it likely will be in
> six months, one year, &c.  (I'm aware of the amusement likely
> to be caused by the idea that DNSEXT could actually plan what
> work will really be done in the next 6-12 months.)
>...
> Does anyone else think that the distinctions we're talking
> about are indeed worth indicating somehow in a registry?  If
> so, I think the current draft is a good basis for that work,
> even if we determine that the current text is not quite what
> we want.

Andrew, it would be awfully nice if narrative information about
the status of a wide variety of standards, and possibly even
contemporary conformance information, were captured and readily
available somewhere, along with information about the
relationships among the various documents that made up those
standards.  What is less clear to me is whether overloading that
information onto IANA registries is the right solution.  I have
my doubts for at least two reasons:

	(1) Many protocols don't have associated IANA registries
	for the critical information.  Creating an incentive to
	create registries to provide this type of information is
	probably not a good idea.
	
	(2) Remember that IANA is technically a separate
	organization.  While the relationship is close and
	cooperative and they have generally been very
	responsive, it seems to me that information about the
	relative status and plans for IETF protocols or pieces
	of them ought to be in a place under the direct control
	of the IETF/IESG, not off in an IANA registry somewhere.

Interestingly, a few mechanisms for handling that sort of
narrative and organizing information were extensively discussed
several years ago.  At the time, the IESG effectively decided
that keeping and organizing that information would be more
trouble than it was worth, at least in part because reviewing
those narrative documents for accuracy would add extra work -- a
problem that would not change if one put the information into
IANA registries instead.  In the ensuing years, the IETF has
changed, the IESG has changed, and situations have changed.
Perhaps it is time to ask the question again -- but to ask the
real question about the importance of that information and how
to organize it, not how to slip some arbitrary subset of it into
a few IANA registries.

If your "broad outline" describes the problem you and Olafur are
trying to solve, I suggest that overloading the information into
IANA registries is the wrong solution, independent of whether
the particular choices of words, etc., are correct.

     john

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Mar 2010 10:15:19 -0400

John,

On Thu, Mar 18, 2010 at 10:01:26AM -0400, John C Klensin wrote:

> several years ago. 

Thanks for this.  Do you know whether any of this got as far as being
written in an I-D, or was it just a discussion?  I'll go trolling for
expired I-Ds if I know they might be out there.

Another idea that's been floating around has simply been to put up a
wiki to support all of this, and do it all as a kind of non-normative
support function.  What worries me about that is the (IMO strong)
chance that such a wiki would be badly maintained, but would gain
currency because of its convenience.  But maybe that doesn't matter
too much: if we can't be bothered to maintain such a resource, then
either making our stuff easy to use isn't important to us, or we don't
actually care about conformance as much as we say we do, or both.

> the particular choices of words, etc., are correct.

Just to be clear, I'm responding to all of this without a hat.  I had
no input to the writing of the draft, though I've read it.  I do have
a problem in the WG I co-chair with Olafur, though, so I'm primarily
interested in solving that.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Mar 2010 10:26:45 -0400

--On Thursday, March 18, 2010 10:15 -0400 Andrew Sullivan
<[email-masked]> wrote:

>> 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 an I-D, or was it just a discussion?  I'll
> go trolling for expired I-Ds if I know they might be out there.

:-(  It was a whole WG, about four or five years ago, with many
drafts and a good deal of discussion both within the WG and on
the IETF list.  Search on "newtrk" generally and for
draft-ietf-newtrk-isd-repurposing for perhaps the best-developed
proposal that went in the "narrative and normative information"
rather than the "cataloging" one.  Disclaimer: I was an author
of that spec and have some biases about it and how it was
processed.

> Another idea that's been floating around has simply been to
> put up a wiki to support all of this, and do it all as a kind
> of non-normative support function.  What worries me about that
> is the (IMO strong) chance that such a wiki would be badly
> maintained, but would gain currency because of its
> convenience.

yes.

>  But maybe that doesn't matter too much: if we
> can't be bothered to maintain such a resource, then either
> making our stuff easy to use isn't important to us, or we don't

While that ("both") is close to my conclusion from the newtrk
meltdown, I assume others disagree.

    john

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 18 Mar 2010 09:24:19 -0700

At 9:25 AM -0400 3/18/10, Andrew Sullivan wrote:
>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 definition of the desired target for the conformance requirements, this draft is harmful because it dilutes the conformance requirement mechanisms we currently have.

An RFC can list conformance requirements for that RFC. This is already common.

A group of RFCs can list conformance requirements, but the linkage between the RFCs make this trickier.

- If RFC A, B, and C are issued simultaneously and each cross-references each other as normative references, RFC A can list the conformance requirements and everyone understands that those requirements apply to {A | B | C}.

- If RFC D has conformance requirements and RFC E updates RFC D but doesn't change the conformance requirements of D, then everyone understands that the conformance requirements in D apply to E.

- If RFC F has conformance requirements and RFC G updates RFC F and changes the conformance requirements of F, then the new conformance requirements only apply to RFC G, not F. This is where implementers often start to lose it. The misunderstanding often gets worse if G updates F, but F was part of a grouping of cross-linked RFCs.

As John Klensin made clear, the IETF has tried and failed miserably to allow the definition of Foo-The-Protocol in a way that can have clear conformance requirements that can later be updated. Just saying "newtrk" to some IETF regulars will cause them to swear reflexively.

Trying to say that an implementation conforms to a particular IANA registry is a new concept that is so badly under-defined in the draft that I assume that it was not intended even though it was strongly implied.

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 conform or not conform to that very concise RFC. As the conformance requirements change, the original RFC can be obsoleted by new ones. That's how the IETF has always done it; what is the problem with doing it here?

--Paul Hoffman, Director
--VPN Consortium

---

From: Christian Huitema <[email-masked]>
Date: Thu, 18 Mar 2010 16:31:35 +0000

> 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 conform 
> or not conform to that very concise RFC. As the conformance requirements 
> change, the original RFC can be obsoleted by new ones. That's how the IETF 
> has always done it; what is the problem with doing it here?

Second that. Let's not overload the registry. As Edward Lewis wrote in another message, "The job of a registry is to maintain the association of objects with identities." If the WG wants to specify mandatory-to-implement functions or algorithms, the proper tool is to write an RFC.

-- Christian Huitema

---

From: SM <[email-masked]>
Date: Thu, 18 Mar 2010 10:42:37 -0700

>the draft aims to fix.  I think that problem is worth taking on.

According to the draft, the problem is about how "to indicate 
emerging and retiring algorithms".  I agree that the problem is worth 
taking.  As the registries are used throughout the different areas, 
it would have been helpful if the proposal had more exposure.  It 
would have been good if the socializing, to use Olafur's words, was 
done before the Last Call.

>only to be required in particular situations.

I gather that the above refers to draft-ietf-dnsext-dnssec-registry-fixes-02.

>implementation, what we'll get is lousy interoperability.

Currently, IANA manages the namespace.  What we have, roughly, is a 
list of assignments and a reference, for example a RFC, to document 
the action.  The proposed fix, to save the programmers' time, is have 
a one-stop shop which lists the required algorithms, the ones that 
will be obsoleted and the ones planned for use in future.

On a tangent, it can be argued that the fix is about creating 
different classes of "Proposed Standard" RFCs.

To borrow words from Paul Hoffman, the "IETF has never had a concept 
of compliance to an IANA registry, which is a good thing" (I cannot 
provide a reference as the archive for this mailing list only lists 
messages up to March 15).  As Brian Carpenter mentioned, "IANA itself 
cannot add normative requirements - only an IETF standards action can 
do that".  John Klensin mentioned that putting critical information 
in an IANA registry is probably not a good idea.  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.

>plan what work will really be done in the next 6-12 months.)

That would be STD [1] except for the "which algorithm is on the way 
out or which algorithm will be in on the next iteration".  The begs 
the question as to why this new mechanism would be successful when 
the existing mechanism is a failure.

At 07:59 18-03-10, Edward Lewis wrote:
>A registry is a reference service.  It is best when consulted for information
>that can be used to make other judgements.  As with just about any other
>coordination function, the more (problem) domain intelligence that is built
>in, the less flexible the function will be.

Agreed.

>The problem with adding compliance requirements to the IANA registries is
>that this assumes all implementations are general purpose applications.  In
>as much as there is no "protocol police" there is no necessity to have
>every process listening on port 53 (DNS) to implement the full spectrum
>of the protocol's features.

The vendor can claim compliance.  It is not for the IETF to say what 
specifications to comply with.  However, the community can document 
what it agrees to be common practice.

At 09:24 18-03-10, Paul Hoffman wrote:
>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 conform or not conform to that very 
>concise RFC. As the conformance requirements change, the original 
>RFC can be obsoleted by new ones. That's how the IETF has always 
>done it; what is the problem with doing it here?

If that is the problem this proposal is attempting to solve, write 
the I-D as mentioned above.  Such a proposal should face less 
resistance than trying to come up with a generalized approach.

Regards,
-sm

1. http://www.rfc-editor.org/categories/rfc-standard.html

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Mar 2010 09:55:02 +1300

Christian,

> Second that. Let's not overload the registry. As Edward Lewis wrote in another message, "The job of a registry is to maintain the association of objects with identities." If the WG wants to specify…

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 to,
but without changing any of our rules or procedures, an applicability
statement Proposed Standard could be drafted immediately.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Mar 2010 18:13:13 -0400

--On Friday, March 19, 2010 09:55 +1300 Brian E Carpenter
<[email-masked]> 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 to, but without changing any of our rules or
> procedures, an applicability statement Proposed Standard could
> be drafted immediately.

+1

I suspect that, even if we had ISDs, a clearly-written
Applicability Statement would be the right way to deal with this
particular issue.   If we had ISDs, the applicability statement
might be built into one, but we'd presumably need to do the A/S
work regardless.

    john

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 19 Mar 2010 10:33:29 -0400

> Second that. Let's not overload the registry. As Edward Lewis wrote in another message, "The job of a registry is to maintain the association of objects with identities." If the WG wants to specify…

But the document requires an RFC to change the 'requirements level', but
it can be done in more fine grain level than republishing the whole
registry, and the RFC can dictate changes to the registry in the future.

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 "evaluator" of an implementations assess if
   implementation Z is compliant with current recommended state
   of protocol X.

The second problem my draft is addressing is:
   How to express the implementation and operational level of support.
   RFC2119 words only apply to IMPLEMENTATIONS.

As how things have been done I think that process is broken thus I want
people to figure out a better way to provide this information.

In my mind there are two options:
a) add this to the registry as this is relevant information for anyone
    that cares about doing the right thing.
b) Add a reference to the registry to a location to a SINGLE RFC that
    lists the compliance levels.

I'm big on the SINGLE argument, allowing multiple will cause a mess that
looks like spaghetti code.

The proposal is a change as what is the role of registries, but
that is not a good enough reason to reject this approach.

The question is how do we make the system more user friendly, remember
we have over 5700 RFC's published so far and we are generating almost
an RFC/day. It is not unlikely that we will have RFC 9000
published before 2020!

	Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Mar 2010 09:14:46 -0700

>  RFC2119 words only apply to IMPLEMENTATIONS.

This problem statement does not match the one in the draft. The one here is a better problem statement, and it already has a simple solution: write an RFC that say "This RFC defines X; a sending implementation must be able emit A and SHOULD be able to emit B; a receiving implementation must be able to process A and SHOULD be able to process B". This has nothing to do with the IANA registry other than A and B had better be listed there.

Further, there is nothing in your draft that says that X is a protocol. The draft is completely vague as to what is being conformed to.

>people to figure out a better way to provide this information.

So do many of us, but it is not from lack of many well-intentioned people trying to fix it: it is from a lack of consensus.

>an RFC/day. It is not unlikely that we will have RFC 9000

Why is this any more true now that a few years ago when the newtrk work failed?

--Paul Hoffman, Director
--VPN Consortium

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 19 Mar 2010 13:58:36 -0400

> This problem statement does not match the one in the draft. The one here is a better problem statement, and it already has a simple solution: write an RFC that say "This RFC defines X; a sending im…

Well it benefits from comments from the many good people that have 
commented on the draft after the LC started :-)

I still do not believe that "Publish a new RFC" is the solution.
It still leaves the issue of matching operations to current best
practices, your statements only reflect "interoperability" out of the
box, not what we recommend that people operate/disable/plan-for/etc.

The +- words are on the right track but I think they do not go far
enough.

> Further, there is nothing in your draft that says that X is a protocol. The draft is completely vague as to what is being conformed to.
Because the definitions are trying to cover both implementations and
operations.

> Why is this any more true now that a few years ago when the newtrk work failed?
The pain is greater than it was, proposals for changes seem to
get traction when certain pain threshold is reached.
Have we reached it?

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 limited extend
be used by the third type, in the case the recommendations are
"static".
As the second and third types of groups will become more common and
contentious it is important to think about how to clearly allow
these groups to express "guidance" in selecting "options".

	Olafur

---

From: Sam Hartman <[email-masked]>
Date: Fri, 19 Mar 2010 14:48:21 -0400

I have been assigned this draft as part of the secdir review process.  I
see no security issues with the draft that are really within the scope
of a secdir review.

I do have significant concerns I'd like to raise as last call comments.

In general, I agree with most of the concerns raised about this draft.
I believe that an applicability statement is the appropriate way to
address what this draft is trying to do.  If you're looking to make a
process change how about writing a simple proposal for allowing IANA
registries to reference applicability statements that describe protocols
they cover.  You might have a note like "For current status of the
implementation requirements for these algorithms in dnssec, se RFC
xyzzy."

The applicability statement could say which registries it links to, and
could remove the links of statements it obsoletes.

I realize that's somewhat going down the path of including unnecessary
information in a registry, but I think it is a reasonable compromise
until/unless something broader like ISDs come along.  Also, by all means
try to put together an ISD-like proposal if you have the energy.  I'm
one of the people who thought that the last ISD proposal was not
sufficiently specified and might run into fundamental problems, but
thought there were some really good ideas there, so if you do go down
that route I'd be happy to share some concerns while remaining
constructive.

Stunningly, given the concerns raised so far, I think I have some new
ones.

First, this draft attempts to establish operational requirements.  The
term operational requirements is not well defined.  In the context of
DNSsec, we can imagine what that might mean: zone operators need to use
one of the mandatory algorithms to sign their zones in order to
guarantee that others can validate it.

Especially for Internet-wide protocols it is often appropriate to have
best-current-practice recommendations for the operational deployment of
those protocols.  We have groups like gro and dnsop that develop such
recommendations.

For other protocols this makes no sense at all.  In the past I've worked
on VPN deployments for clients.  Those clients chose algorithms that
were right for their environments.  IF within that environment they
happened to choose a protocol that was not labeled as MANDATORY by an
IANA registry, that's totally fine.  Neither the IETF nor the IANA has a
good reason to tell people what IPsec algorithms they need to use in
their operational environment, nor even what algorithms must be enabled
in a given configuration.  If we try, we will be ignored.

This draft conflates implementation requirements with operations
requirements.  In many cases we SHOULD NOT specify operations
requirements.  In other cases, there is no reason to be sure that the
implementation and operations requirements will be the same.

Others have pointed out the broken definition of mandatory.  The
definition at the top of 3.1 provides an escape and makes MANDATORY much
like SHOULD.  However the explanation for what it means for
implementations and operations provides no such escape.

There is a lack of alignment between the implementation requirement and
operations requirement for obsolete: if I'm starting to phase something
out, it is too early to say SHOULD NOT implement.

This draft fails to adequately describe its relationship to RFC 2119.
When should I use MUST?  When should I use MANDATORY?  Why do I need
both?  If you're going to introduce new terms, you need to clearly
specify their applicability.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Mar 2010 08:05:48 +1300

Olafur,

> these groups to express "guidance" in selecting "options".

I'm all in favour of making things easier for people trying to use
our standards. I don't believe that adding duplicative terminology
to the IANA registries is the right way to do it; I believe that will
only *increase* confusion and the risk of ambiguity.

Something like draft-ietf-newtrk-repurposing-isd seems much more
hopeful but never reached IETF consensus.

Meanwhile, to repeat myself, why don't WG's write Applicability
Statements as defined in 1996 by BCP 9 (RFC 2026) section 3.2? We've had
this mechanism for 14 years, maybe it's time to test it.

Regards
   Brian Carpenter

On 2010-03-20 06:58, Olafur Gudmundsson wrote:
>> This problem statement does not match the one in the draft. The one
>> here is a better problem statement, and it already has a simple
>> solution: write an RFC that say "This RFC defines X; a sending
>> implementation must be able emit A and SHOULD be able to emit B; a
>> receiving implementation must be able to process A and SHOULD be able
>> to process B". This has nothing to do with the IANA registry other
>> than A and B had better be listed there.
>>
> 
>> Further, there is nothing in your draft that says that X is a
>> protocol. The draft is completely vague as to what is being conformed to.
>>
>> So do many of us, but it is not from lack of many well-intentioned
>> people trying to fix it: it is from a lack of consensus.
>>

---

From: Martin Rex <[email-masked]>
Date: Fri, 19 Mar 2010 23:03:34 +0100 (MET)

SM wrote:
>                                                   One of the effects 

I don't understand what you mean by "implementing an IANA registry".

I do understand the idea of implementing an RFC, and for this purpose,
RFCs are supposed to attribute "requirements" levels to implementation
options/alternatives and to optional features.

Although there are some RFCs (PKIX documents come to mind) that label
myriads of bells and whistles as "requirements", so that they provide
little clue about which features are likely available in implementations
within the installed base.

Normally, RFCs contain requirements for _implementations_, leaving
the decision about what features to actually use entirely to the
consumers of the technology.

For DNSsec, when it is deployed on the internet, there also ought to
be a set of requirements for the DNSsec zones for the purpose of
interoperability, because DNS is, and DNSsec should be at some point
in the future, an integral part of the internet.

-Martin

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 19 Mar 2010 00:49:47 -0400 (EDT)

+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.  (It was worse in version -02, where the 2119 MUST 
was used, making DISCOURAGED a stronger statement than MANDATORY.) 
There's too much potential for confusion here.

With that said, I am sympathetic to need Andrew describes, of wanting 
to collect this requirement information in one place (for DNSSEC, in 
particular).  Putting this in the IANA registry is a grand idea.

But the terms in this doc still need work.

-- Sam