Subject: [Nea] IANA Considerations for NEA Protocols

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 23 Sep 2008 11:33:14 -0400

In the NEA WG meeting at IETF 72, we had lots of
discussion about IANA considerations but we didn't
reach consensus for any one approach. I'd like to
raise this issue for discussion on the email list
in hopes that we can discuss the pros and cons of
various approaches and agree on one.

I think the main question is:

* What process should we use for adding new
  assigned numbers ("codepoints") to the IANA
  registries created by the NEA protocol specs?

The registries in question (described in PB-TNC
and PA-TNC) are:

IETF Standard PB-TNC Message Types
IETF Standard PB-TNC Remediation Parameters Types
IETF Standard PB-TNC Error Codes
IETF Standard PA Subtypes
IETF Standard PA-TNC Attribute Types
IETF Standard PA-TNC Error Codes

The PB-TNC and PA-TNC drafts currently say that
codepoints can be added to these registries only by
IETF Consensus, as defined in RFC 2434. This would
require an RFC approved by the IESG. Note that
RFC 2434 has been obsoleted by RFC 5226 so that
RFC is more relevant to our discussion now.

During the discussion at IETF 72, it was suggested
that requiring an RFC for each new codepoint will be
too slow and cumbersome. People will instead just
use the vendor-specific values allowed by the specs.
The suggestion was to instead use Expert Review to
decide on adding new codepoints to the registries.

It was strongly suggested that we require that a
specification for each codepoint be archived in a
permanently accessible location. In fact, we had
a quick straw poll on this question:

Should we require some sort of permanent documentation
in order to get an identifier from the vendor id 0 namespace?

The result was unanimous agreement that we should.

I suspect there may be consensus now on this proposition:

To add assigned values ("codepoints") to the IANA registries
created by the NEA specs, we should require Expert Review
with a permanently archived Specification Required.

Please consider this proposition and send email with any
comments, including statements of support or non-support.

BTW, I have consulted with IANA about how we can ensure that
the "permanently archived" specifications for codepoints are
actually permanently archived. IANA said that they can archive
a spec and make it available from their site if needed. They
will need to get permission from the copyright holder but
they can do so. Another option would be to use the RFC series
as our permanent archive but that involves a lot more process,
delay, reformatting, and general overhead than just archiving
a copy of the spec.

One related topic that was discussed at the meeting was
how to handle vendor-specific codepoints (vendor ID > 0)
that become popular and widely implemented. Some people
felt that it's best to create an IETF standard codepoint
(vendor ID = 0) that corresponds to these codepoints and
ask implementers to transition to the new codepoint. Others
said that once a vendor-specific codepoint is widely
implemented, it's unlikely that people will leave it.
Doing so would cause pain and expense with little value.
These folks seemed to suggest that we should allow vendors
to document their vendor-specific codepoints to increase
clarity and interoperability. It was not clear whether
this documentation should be done via an Expert Review
process with permanently archived Specification Required
or via an Informational RFC or via some other mechanism.
I'd like to invite discussion on this topic also.

I hope that we can reach consensus on these two topics
(how to approve Vendor 0 codepoints and how/whether to
document vendor-specific codepoints) in the next two weeks
so that our document editors can include the consensus
in the next versions of the NEA specs. So please think
about these topics and respond promptly. I will declare
WG consensus once we seem to have reached it.

Thanks,

Steve
_______________________________________________
Nea mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nea