Subject: Last Call on draft-ietf-pim-registry-03.txt

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 12 Jan 2011 11:24:33 +0200

Hello all,

I am writing to provide some review on the draft-ietf-pim-registry,
that is currently in Last Call,

Furstly, this document does not explain the abreviatures once they has
appeared in the title, abstract and main text.

Moreover, the initial contents of the regsitry does not mention that
values that are Unassigned.  What is more, the document does not have
clear regsitry format description, eg. Message Type - an integer,
values from 0 to 15 are assigned etc.  I propose to create the
separate section and name it 'Regsitry Description' and place a number
of sub-section tehre that would describe the regsutry as detailed as
possible.  And in this occasion out the follwoing IANA Considerations'
Section:

'IANA is asked to create the 'name' regsitry following Section 2 of
this document."

So I recommend not to publih this document in the current view, stop
the Last Call, if posible, and work on it a bit more.

All the best,
Mykyta Yevstifeyev

---

From: Adrian Farrel <[email-masked]>
Date: Wed, 12 Jan 2011 13:25:59 +0000

Hi Mykyta,

> that is currently in Last Call,

Many thanks for reviewing.

> appeared in the title, abstract and main text.

Good catch. It looks like a number of the acronyms we expected to be
"well-known" are not.
I find:
PIM
RFC (wow, that is a real surprise)

On the other hand, some *are* well-known and don't need to be expanded:
IANA
IGMP
IETF

For reference, see
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
 
> values that are Unassigned. 

Yeah, probably worth adding an entry...

11-14  Unassigned

>  What is more, the document does not have
> possible. 

You are right. The description of the Message Type should be included. In
particular the range is very important.
This should be added to the end of the paragraph in Section 3.

> And in this occasion out the follwoing IANA Considerations'
> Section:
> 

I am not sure what your suggestion is here. Section 3 begins with exactly this
request (using different words).
 
> So I recommend not to publih this document in the current view,

Agreed. Thanks for catching these issues which can be fixed.

> stop

No, I don't think so. 
The purpose of a last call is not necessarily to have everyone agree that a
document is perfect. The purpose is to catch exactly the type of issue you have
raised.

I do not believe that your input here (which *is* valuable) results in changes
to the I-D that make a fundamental difference to the document that would
necessitate a further last call.

Thanks,
Adrian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Jan 2011 14:58:04 +0100

On 12.01.2011 14:25, Adrian Farrel wrote:
> ...
> ...

My understanding was that if something isn't registered then it's 
unassigned. When did we start to list those in a registry?

 > ...

Best regards, Julian

---

From: Adrian Farrel <[email-masked]>
Date: Wed, 12 Jan 2011 14:22:44 +0000

Entirely at random I clicked on:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml
http://www.iana.org/assignments/calipso/calipso.xhtml
http://www.iana.org/assignments/lmp-parameters

Looks like IANA tries to fill up all the blanks with markers of "unassigned".

Is that harmful?

Adrian

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: 12 January 2011 13:58
> To: [email-masked]
> Cc: 'Mykyta Yevstifeyev'; 'The IETF'; [email-masked]
> Subject: Re: Last Call on draft-ietf-pim-registry-03.txt
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Jan 2011 15:35:52 +0100

> Looks like IANA tries to fill up all the blanks with markers of "unassigned".

Minimally, it's redundant. Also, it only makes sense on certain types of 
registries.

I just checked the XML version of the first registry, and, indeed, it 
contains entries for unassigned values. /me shakes head in disbelief.

What *should* be done is computing the unassigned ranges for 
*presentation*; that is, they should not be part of the actual registry. 
The way it's done currently defeats one of the reasons of having a 
machine-readable registry (consumers will have to hard-wire knowledge of 
the specific "unassigned" entry to make sense of the registry).

Best regards, Julian

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Jan 2011 09:34:42 -0800

> RFC (wow, that is a real surprise)

PIM is also in the list. The only one missing is RFC. Which indeed is
a surprise :) I can expand that if you want me to. Or we can leave it
to the RFC-Editor to decide?

> Yeah, probably worth adding an entry...

I find it a bit superfluous, but I can certainly do that. Just so it's
clear that nothing may have been omitted.

> This should be added to the end of the paragraph in Section 3.

I agree. The document notes in the introduction that its 4 bits, but it
should be as part of the registry. Once the last call is ended I'll
do a new version where I point this out.

Stig

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 12 Jan 2011 15:07:54 -0500

Almost all registries I'm familiar with explicitly list unassigned
ranges. In some cases, different unassigned subranges have different
allocation policies. For example, there may be a small unassigned
range of lower values requiring Standards Action with the bulk of the
unassigned values allocatable on a less stringent basis.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

On Wed, Jan 12, 2011 at 9:35 AM, Julian Reschke <[email-masked]> wrote:
> What *should* be done is computing the unassigned ranges for *presentation*;
> that is, they should not be part of the actual registry. The way it's done
> currently defeats one of the reasons of having a machine-readable registry
> (consumers will have to hard-wire knowledge of the specific "unassigned"
> entry to make sense of the registry).
>
> Best regards, Julian
>

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 13 Jan 2011 02:30:53 +0200

> unassigned values allocatable on a less stringent basis.
RFC 5226 has an exact rule: Unassigned values shall be mentioned while 
creating registries.

And another (not from 5226): it is RECOMMENDED to explain all 
abbreviation, even well-known once they occur.

I do not know what is the problem here.

Mykyta
> On Wed, Jan 12, 2011 at 9:35 AM, Julian Reschke<[email-masked]>  wrote:

---

From: "Doug Ewell" <[email-masked]>
Date: Wed, 12 Jan 2011 19:56:58 -0700

Donald Eastlake wrote:

> ranges.

The IANA Language Subtag Registry doesn't:

http://www.iana.org/assignments/language-subtag-registry

--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jan 2011 09:02:29 +0100

> http://www.iana.org/assignments/language-subtag-registry

Obviously it depends on the datatype whether saying what's unassigned is 
useful or feasible.

Back to ma point: for registries where it *can* be done, the unassigned 
values can be *computed*. Thus, they shouldn't be part of the registry 
data, but simply be displayed as such. That would ensure that the 
information always is up-to-date.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 13 Jan 2011 11:21:54 +0200

Hello all,

Let me cite RFC 5226, that says:

<...>
Documents that create a new namespace (or modify the definition of an
existing space) and that expect IANA to play a role in maintaining
that space (e.g., serving as a repository for registered values) MUST
provide clear instructions on details of the namespace.  In
particular, instructions *MUST* include:
<...>
5) Initial assignments and reservations.  Clear instructions should be
provided to identify any initial assignments or registrations.  In
addition, any ranges that are to be reserved  for "Private Use",
"Reserved", *"Unassigned"*, etc. should be *clearly indicated*.
<...>

So the document specifying the regsitry MUST mention what are
Unassigned.  Moreover, IMO, it would be useful to assign one value for
Experimentation.

Mykyta

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jan 2011 12:31:51 +0100

> "Reserved", *"Unassigned"*, etc. should be *clearly indicated*.

That sounds like an editorial error to me.

"any ranges to be *reserved* for .... "Unassigned"..."

doesn't make any sense at all. They are not reserved.

This should probably be raised as erratum.

> Unassigned.  Moreover, IMO, it would be useful to assign one value for

No. should != must.

There are tons of registries where this is not the case; namely all or 
most of those where the values are strings, not numbers.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 13 Jan 2011 17:51:43 +0200

> doesn't make any sense at all. They are not reserved.
Yes, that is a type of error, but the meaning is that unassigned and 
reserved values MUST (yes, must, that is in RFC 5226; see citation 
below) be mentioned.
>> Unassigned.  Moreover, IMO, it would be useful to assign one value for
See below.
> most of those where the values are strings, not numbers.
The strings registries are rather exceptions from the rule I cited above.

Mykyta

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jan 2011 16:58:22 +0100

> reserved values MUST (yes, must, that is in RFC 5226; see citation

I do not see a citation "below".

>>> Unassigned. Moreover, IMO, it would be useful to assign one value for

Even further? :-)

> The strings registries are rather exceptions from the rule I cited above.

Well, we have many of them. The rules should takes those into account.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 13 Jan 2011 18:08:37 +0200

> I do not see a citation "below".
I meant in the previous message.
>>>> Unassigned. Moreover, IMO, it would be useful to assign one value for
The same.
> Well, we have many of them. The rules should takes those into account.
That, IMO, was the mistake of authors of RFC 5226 that didn't take the 
text registries into considerations.  We have no way to correct that now.

Mykyta

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jan 2011 17:10:42 +0100

> I meant in the previous message.

Please cite where the spec says "must" or "MUST".

> text registries into considerations. We have no way to correct that now.

We can raise errata, and have the authors and the IESG approve them. We 
can also use common sense, and note that IANA apparently doesn't enforce 
these rules when they do not make sense.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 13 Jan 2011 18:14:20 +0200

> Please cite where the spec says "must" or "MUST".
That is a citation of RFC 5226

<...>
"Reserved", **"Unassigned"**, etc. should be *clearly indicated*.
<...>
> We can raise errata, and have the authors and the IESG approve them. 
> We can also use common sense, and note that IANA apparently doesn't 
> enforce these rules when they do not make sense.
>
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jan 2011 17:19:38 +0100

> "Reserved", **"Unassigned"**, etc. should be *clearly indicated*.

Yes.

There's still no "MUST" applying to unassigned code points. Note the "In 
addition" and "should".

Best regards, Julian

---

From: Michelle Cotton <[email-masked]>
Date: Thu, 13 Jan 2011 12:43:11 -0800

Many believe it makes it very clear to the users of the registry what is
available for assignment.  Something we will be rolling out soon (for those
registries with a finite space) will be small charts showing how much of the
registry space is unassigned, assigned and reserved (utilizing the
unassigned entries).
--Michelle

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Jan 2011 22:14:01 +0100

> registry space is unassigned, assigned and reserved (utilizing the

Exactly my point -- we should distinguish between the actual registry 
contents (assigned / reserved), and how it's presented.

Best regards, Julian

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Jan 2011 10:23:26 +0200

Hi,

> registry space is unassigned, assigned and reserved (utilizing the

I mentioned in the past that the term "unassigned" to me at least doesn't make it sufficiently clear that IANA assignment is often needed before codepoints may be taken into use. We have several cases (the many different squats on TCP option numbers, for example) were people pick unassigned codepoints during development and only later realize that they should have registered them.

If you want to explicitly list unassigned codepoints in the registries, I'm wondering if we can find a short phrase that makes it more clear that an IANA action is normally required - maybe "available for IANA assignment"?

Lars

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 14 Jan 2011 09:59:09 -0000

RFC 5226 (BCP 26) says

   IANA must be given a set of
   guidelines that allow it to make allocation decisions with minimal
   subjectivity and without requiring any technical expertise with
   respect to the protocols that make use of a registry.
 
and goes on to discuss categories of unassigned code points (though
it does also define the unqualified word Unassigned). We were thus
advised, when publishing RFC 5444, to specify this clearly and
so we had tables such as

       +---------+-----------------------+------------------------+
       |   Type  | Description           | Allocation Policy      |
       +---------+-----------------------+------------------------+
       |  0-127  | Unassigned            | Expert Review          |
       | 128-223 | Message-Type-specific | Reserved, see Table 11 |
       | 224-255 | Unassigned            | Experimental Use       |
       +---------+-----------------------+------------------------+

(For the purposes of this discussion I suggest ignoring the 128 to
223 line above.)

This seemed to keep everyone (IESG, IANA, RFC Editor) happy.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars Eggert
Sent: 14 January 2011 08:23
To: Michelle Cotton
Cc: Julian Reschke; [email-masked]; Adrian Farrel; 'The IETF'
Subject: Re: Last Call on draft-ietf-pim-registry-03.txt

Hi,

> registry space is unassigned, assigned and reserved (utilizing the

I mentioned in the past that the term "unassigned" to me at least
doesn't make it sufficiently clear that IANA assignment is often needed
before codepoints may be taken into use. We have several cases (the many
different squats on TCP option numbers, for example) were people pick
unassigned codepoints during development and only later realize that
they should have registered them.

If you want to explicitly list unassigned codepoints in the registries,
I'm wondering if we can find a short phrase that makes it more clear
that an IANA action is normally required - maybe "available for IANA
assignment"?

Lars

********************************************************************
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: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 14 Jan 2011 16:04:54 +0200

13.01.2011 18:19, Julian Reschke wrote:
> There's still no "MUST" applying to unassigned code points. Note the 
> "In addition" and "should".
There is MUST before the list of the criteria for the documents defining 
the registry.  This MUST applies to everything mentioned in this list.

Mykyta

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Jan 2011 15:07:01 +0100

> the registry. This MUST applies to everything mentioned in this list.

Well, we can go on repeating this exchange over and over, or just stop. 
I'll stop.

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 14 Jan 2011 07:25:47 -0800

On 1/14/11 12:23 AM, Lars Eggert wrote:
>> Many believe it makes it very clear to the users of the registry
>> what is available for assignment.  Something we will be rolling out
>> soon (for those registries with a finite space) will be small
>> charts showing how much of the registry space is unassigned,
>> assigned and reserved (utilizing the unassigned entries).
>
> doesn't make it sufficiently clear that IANA assignment is often
> needed before codepoints may be taken into use. We have several cases
> (the many different squats on TCP option numbers, for example) were
> people pick unassigned codepoints during development and only later
> realize that they should have registered them.
>
> If you want to explicitly list unassigned codepoints in the
> registries, I'm wondering if we can find a short phrase that makes it
> more clear that an IANA action is normally required - maybe
> "available for IANA assignment"?

If IANA *doesn't* explicitly list unassigned codepoints in the 
registries, do you think that would make the problem of unintentional 
squatting better or worse? I can see it going either way, but you have 
probably thought about this more than I.

The unintentional squatting problem might be reduced by a note in every 
registry that says "unassigned code points must be assigned by IANA" or 
some such wording.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 14 Jan 2011 11:44:01 -0500

The first law of the Internet is

   'You are so not in charge (for all values of you).'

The illusion of control is comforting to some but it is an illusion. At the
end of the day the IETF has roughly 2000 people involved. Nobody elected us.
We are accountable to no-one.

The Internet has 2 billion users. We do not accept accountability to those
users. We cannot even understand what their requirements might be. And even
if we did, we may well reject them out of hand.

At certain levels in the protocol stack the use of registries is
unavoidable. We have to have compact representations at the IP level. At the
application layer, they really don't matter at all.

The illusion of control is comforting, but it comes with costs.

The first cost is the cost of maintaining the registry. Assigning code
points requires an administrator, it frequently requires expert review. That
incurs time and money.

The second cost is that where there is control, the granting of a code point
will inescapably imply approval. I have no problems with the Russian
government using GOST but I do have serious problems with the fact that the
IETF has assigned code points for GOST.

The third (and in practice minor) cost is the confusion that can arise when
folk decide to freeboot themselves a code point. That could cause real
problems at the IP layer, but the risk is really rather marginal at all at
the application layer. We have remarkably few problems from collisions of
file name extensions and we have far more than three characters.

I suggest that the IAB consider a policy for registries that requires all
cryptographic and application layer code points to make use of an approved
extensible identifier format, with the two approved forms being URIs and
ASN.1 OIDs.

Such registries as are then maintained would be strictly limited to tracking
identifiers to be used for mandatory and preferred algorithms. Such
registries might assign abbreviated identifiers for such algorithms.

The main impact of this would be felt in cryptographic protocols. Instead of
having separate private use code spaces being maintained for IPSEC, DNSSEC,
TLS and PKIX, each of the protocols would be extended to allow the use of
ASN.1 OIDs (where these are not already used) for private code space. It
would be up to the developer of the algorithm to assign the OID.

(yes, yes, TLS suites, blah, its fixable)

[There is a small issue to do with URIs in XML based protocols. I think we
should collapse that registry into the ASN.1 format by using the OID URN
form]

The IETF would then cease considering requests to add code points for
non-recommended algorithms for those protocols. The only question that would
be considered in IETF space would be whether we want to add a new protocol
to the approved list.

The advantage of this approach would be that the 'vanity crypto' problem
would largely disappear. Particularly if the IETF/SAAG took the approach
that it would only recommend algorithms after it was demonstrated that a
very substantial community were either using them or planing to do so and
there were clear advantages over existing options.

The same principles would apply across the IETF. Anything that touches an
application has to have an extensible registry of OIDs or URIs for code
points that affect the application layer.

Removing the barriers to proliferation has the counterintuitive effect of
making it harder to establish a new algorithm. There being no barriers,
there are more candidates to choose from and the IETF is not available as a
forum to promote the proposal. Proposals have to win on their own merits.

Let a hundred flowers bloom and then Darwin can take care from that point
on.

This approach would not save people from themselves. But that is a futile
effort in an Internet of two billion people where we are not in charge
anyway (and neither is anyone else).

On Fri, Jan 14, 2011 at 10:25 AM, Paul Hoffman <[email-masked]>wrote:

> If IANA *doesn't* explicitly list unassigned codepoints in the registries,
> do you think that would make the problem of unintentional squatting better
> or worse? I can see it going either way, but you have probably thought about
> this more than I.
>
> registry that says "unassigned code points must be assigned by IANA" or some
> such wording.

-- 
Website: http://hallambaker.com/

---

From: Paul Wouters <[email-masked]>
Date: Fri, 14 Jan 2011 12:57:19 -0500 (EST)

On Fri, 14 Jan 2011, Phillip Hallam-Baker wrote:

> I suggest that the IAB consider a policy for registries that requires all cryptographic and application layer code
> points to make use of an approved extensible identifier format, with the two approved forms being URIs and ASN.1 OIDs.

-1

Not technology agnostic. 
Variable length instead of fixed length

A single byte or two bytes can work for anyone with any technology, now and 50 years from now.

> The main impact of this would be felt in cryptographic protocols. Instead of having separate private use code spaces
> being maintained for IPSEC, DNSSEC, TLS and PKIX, each of the protocols would be extended to allow the use of ASN.1 OIDs
> (where these are not already used) for private code space. It would be up to the developer of the algorithm to assign
> the OID.

It's too late for that now anyway isn't it. The code path is there, and if you want to be compatible
you have to implement it. Adding a second (complicated!) code path isn't going to help anyone make it
easier.

> The advantage of this approach would be that the 'vanity crypto' problem would largely disappear. Particularly if the
> IETF/SAAG took the approach that it would only recommend algorithms after it was demonstrated that a very substantial
> community were either using

catch-22. How can a substantial community use them before it has become a real standard?

> Let a hundred flowers bloom and then Darwin can take care from that point on.

I prefer my crypto more intelligently designed.

Paul

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 Jan 2011 23:06:33 +0100 (MET)

> We are accountable to no-one.

I assume the number of IETF contributors is more like 5000-10000.

> if we did, we may well reject them out of hand.

Everybody can get involved with the IETF and although some working groups
may have superseded rough consensus by voting these days, there are still
significant numbers of contributors involved in the IETF with non-marginal
levels of dignity about the technologies they are creating.

> points requires an administrator, it frequently requires expert review.
> That incurs time and money.

You are asserting here that by _not_ using an IANA registry, but instead
relying on ASN.1 OIDs, suddenly the use of DSA with MD4 for a digital
signature obiviates expert review and becomes technically sound?

The assignment of a code point itself is a cost infinitesimal close to
zero.  No matter how you look at it, at the abstract level there is
no difference between an IANA code point assignment for something
and the assignment of an ASN.1 OID or an URIs by some organization.

But building and implementing protocols with small fixed-size integer
IANA-assiged values is magnitudes easier than messing around with
ASN.1 OIDs and URIs in terms of code, CPU cycles, storage requirements
and network bandwidth.  But the IANA assignment has the clear advantage
that it is a well-known single location that keeps track of all
assignments and associated specifications, while with ASN.1 OIDs
and URIs you might find yourself lost where no google/bing/whatever
heuristics can help you.

I know of a colleague who is struggling trying to move an RSA keypair
created on an IPhone to a Windows machine, but the default RSA CSP in
MS CryptoAPI rejects the keypair on PKCS#12 input (Firefox and OpenSSL
don't have a problem).  I'm suspecting it might be due to a primality test
suggested by X9.31, but that document is available at $$$ only.

With an IANA registry, the IETF can (and should) enforce free availability
of the relevant specifications plus at least availability of RAND conditions
for the surrounding (known) IPR claims.

> IETF has assigned code points for GOST.

I have no problem whatsoever with _code_points_ being assigned for GOST
by the IETF as long as there is a specification that describes the
exact semantics for the specific protocol context where this assignment
applies.

Attributing a recommendation level to the _use_ of GOST algorithms
for specific purposes is an entirely different matter.

There are code points assigned for cryptographic algorithms
like RC4-40 and MD4 for use with IETF protocols.  I'm much more
concerned about those than I am concerned about GOST.

Frankly, I'm actually more concerned about code assignments for
severely IPR-impaired algorithms (e.g. Elliptic Curve related)
than about GOST.  (Admittedly, the GOST 34.10-2001 signature
algorithm appears to use Elliptic curve math, and it's entirely
unclear to me whether and how existing EC-related IPR claims might
apply.)

> (yes, yes, TLS suites, blah, its fixable)

The most appreciable part of TLS is, that it did not add any new
ASN.1 nonsense to the existing mess of X.509/PKIX.

-Martin

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 15 Jan 2011 03:31:16 +0200

Hello all,

Summarizing all LC comments received so far, I'd like to propose the 
author of draft-ietf-pim-registry-03.txt the following changes to his 
document:

1. Abstract

Explain the abbreviations.

2. Introduction

Explain the abbreviations.

3. Add a new section directly after Introduction named '2. Registry 
Description' with the following content:

   2.1. The Name of the Registry

    The name of created registry is 'Protocol Independent Multicast 
(PIM) Message Types'.

2.2. The Format of the Registry

    The 'Protocol Independent Multicast (PIM) Message Types' registry
    consists of 3 values: Packet Type, Description and Reference. They
    are described below:

      Packet Type - an integer; values form 0 to 15 are assigned.

      Description - a brief decryption of packet type.

      Reference - the reference document, that defines the packet type.

2.3. Registration Procedures

    New assignments to 'Protocol Independent Multicast (PIM) Message Types'
    registry SHALL be made following the 'IETF Consensus' policies.
    [RFC5226]

2.4. The Initial Contents of the Registry

    This section contains the initial contents of the 'Protocol 
Independent Multicast (PIM)
  Message Types' registry.

   +---------+-------------------------------------+------------------+
    |  Type  | Description                         | Reference         |
    +--------+-------------------------------------+-------------------+
    |0       | Hello                               |[RFC3973] [RFC4601]|
    |1       | Register                            |[RFC4601]          |
    |2       | Register Stop                       |[RFC4601]          |
    |3       | Join/Prune                          |[RFC3973] [RFC4601]|
    |4       | Bootstrap                           |[RFC4601]          |
    |5       | Assert                              |[RFC3973] [RFC4601]|
    |6       | Graft                               |[RFC3973]          |
    |7       | Graft-Ack                           |[RFC3973]          |
    |8       | Candidate RP Advertisement          |[RFC4601]          |
    |9       | State Refresh                       |[RFC3973]          |
    |10      | DF Election                         |[RFC5015]          |
    |11-14   | Unassigned                          |this document      |
    |15      | Reserved                            |this document      |
    +--------+-------------------------------------+-------------------+

2.5. Sub-Registries

    No sub-registries are currently defined in 'Protocol Independent 
Multicast (PIM)
  Message Types' registry.

4. Security Consideration: renumber

5. IANA Considerations: renumber, modify in the following way:

IANA is asked to create the Protocol Independent Multicast (PIM)
  Message Types' registry following Section 2 of this document.

6. Other sections: renumber.

I suppose the author will accept my proposal that makes the registry 
description more clear.

All the best,
Mykyta Yevstifeyev

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 14 Jan 2011 22:16:45 -0500

> levels of dignity about the technologies they are creating.

It is hard to imagine any structure that could provide for significantly
more than one person in a million being involved in the IETF.

We can face that fact or we can pretend that it doesn't matter and that we
can have power without accountability, I believe Rudyard Kippling's quote on
that topic was on point.

> signature obiviates expert review and becomes technically sound?

No, the proliferation of cryptographic algorithms is a bad thing in and of
itself.

In the past it was believed that having a backup algorithm was a good thing.
Then we discovered that in fact the security of a scheme is usually
determined by the least secure algorithm supported rather than the best and
that adding a backup algorithm merely created additional opportunities to
crack the system.

We should not therefore be in the business of expertly reviewing any crypto
unless we believe it to be a significant improvement on the existing
algorithms.

Your straw man case of DSA with MD4 is easy to reject. But what would be the
acceptance conditions?

>From a protocol standpoint the correct response is arguably to reject every
application. But doing that is impossible as the GOST case demonstrates. If
the IETF had not assigned the code points then they would have been assigned
by the GRU.

We cannot stop people from shooting themselves in the foot and we should not
try either.

>From a political standpoint it is totally different. Assignment of an IANA
code point is an IETF endorsement no matter how many caveats we attempt to
apply.

The cost of expert review is non zero.

> for the surrounding (known) IPR claims

Nonsense.

If the IETF refuses to issue code points people will issue them themselves.
That was the original observation at the start of this thread.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 16 Jan 2011 23:30:28 +0100

> unclear to me whether and how existing EC-related IPR claims might

Withholding registration just means that people are going to pick an unregistered number with all the problems that that entails. In cases where there are no scarcity issues registration should happen as long as there is a reasonable expectation of non-negligible use, regardless of whether the registered protocol is endorsed by the IETF (whatever that means) or IANA.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Jan 2011 18:23:49 -0500

On Sun, Jan 16, 2011 at 5:30 PM, Iljitsch van Beijnum <[email-masked]>wrote:

> Withholding registration just means that people are going to pick an
> unregistered number with all the problems that that entails. In cases where
> there are no scarcity issues registration should happen as long as there is
> a reasonable expectation of non-negligible use, regardless of whether the
> registered protocol is endorsed by the IETF (whatever that means) or IANA.

+1

If people think that IANA is a tool they can use to impose their own
personal political agenda on the Internet, they are mistaken.

Here we have a proposal to enforce a particular royalty free agenda. Some
Internet users might support such an agenda but most don't even understand
what the argument would be about.

It is very easy to accept the idea of someone imposing a political agenda
you agree with. But what if the agenda turned out to be something else? What
happens if the representation from authoritarian leaning countries increases
and there is a group of people who agree on the need to fight 'information
terrorism' as defined in the SCO treaty.

All that is necessary to keep the Internet open is to prevent any party from
gaining control.

And the best way to prevent that is to ensure that there is no control
point.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 17 Jan 2011 19:53:36 +0200

Dear all,

The isues discussed here is the use of unassigned values in IANA 
registries.  And I really agree with the authors of RFC5226 that sets 
MUST criterion for mentioning these values.  Not mentioning them will 
lead to misunderstanding by IANA and other people whether the values are 
available for assignment, reserved or not used et al.  So I think that 
there is just no need to discuss what is clearly set by the document.

All the best,
Mykyta Yevstifeyev

17.01.2011 1:23, Phillip Hallam-Baker wrote:
>
>
> On Sun, Jan 16, 2011 at 5:30 PM, Iljitsch van Beijnum 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Withholding registration just means that people are going to pick
>     an unregistered number with all the problems that that entails. In
>     cases where there are no scarcity issues registration should
>     happen as long as there is a reasonable expectation of
>     non-negligible use, regardless of whether the registered protocol
>     is endorsed by the IETF (whatever that means) or IANA.
>
>
> +1
>
> Here we have a proposal to enforce a particular royalty free agenda. 
> Some Internet users might support such an agenda but most don't even 
> understand what the argument would be about.
>
> It is very easy to accept the idea of someone imposing a political 
> agenda you agree with. But what if the agenda turned out to be 
> something else? What happens if the representation from authoritarian 
> leaning countries increases and there is a group of people who agree 
> on the need to fight 'information terrorism' as defined in the SCO treaty.
>
> All that is necessary to keep the Internet open is to prevent any 
> party from gaining control.
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Jan 2011 23:49:35 +0100

> there is just no need to discuss what is clearly set by the document.

Maybe you should ask the authors of RFC 5226 whether they agree with 
your interpretation of the spec.

Best regards, Julian

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 Jan 2011 09:46:54 +0200

Hi,

> personal political agenda on the Internet, they are mistaken.

that isn't the point of this thread.

The point of IANA assignment is to avoid conflicting codepoint usage. Squatting on codepoints defeats this goal.

For example, see the TCP option number registry at http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xml#tcp-parameters-1. The highest IANA-assigned option number is currently 29. IANA assigns in-order. I happen to know that option number 32 is being squatted on. If IANA assigns number 32 to some other option, conflicts *will* arise. (There are several TCP options being developed in the IETF at the moment, so this is not a constructed argument.)

I know of about 5 or so TCP option numbers that are being squatted on at the moment (there are likely more). I've been in discussion with the folks who are squatting, and in all cases the story was either "we were going to ask for assignment but it got forgotten" or "oh, you mean unassigned doesn't mean it's free for the taking?"

Using a term other than "unassigned" might prevent some instances of the latter.

Lars

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 Jan 2011 08:51:55 -0500

On Tue, Jan 18, 2011 at 2:46 AM, Lars Eggert <[email-masked]> wrote:

> The point of IANA assignment is to avoid conflicting codepoint usage.
> Squatting on codepoints defeats this goal.
>

But it meets the goal of the people squatting. Is there any reason to think
that changing the name of the code points is going to make a difference?

I know of about 5 or so TCP option numbers that are being squatted on at the
> moment (there are likely more). I've been in discussion with the folks who
> are squatting, and in all cases the story was either "we were going to ask
> for assignment but it got forgotten" or "oh, you mean unassigned doesn't
> mean it's free for the taking?"
>

Those sound like excuses to me rather than reasons.

I am currently applying for a DNS RR code assignment. More than one person
involved suggested that we should just assign the RR code ourselves by fiat
because they didn't want to wait six weeks for a review.

My name is on the draft so we have applied for an assignment. But now that
six weeks have passed we have a major industry meeting next week that is to
discuss the proposal (amongst others) as part of a DNSSEC deployment effort
and there has been no response.

Using a term other than "unassigned" might prevent some instances of the
> latter.

I don't see how changing the name is going to affect behavior for the
positive here. If you do succeed in confusing people as to which numbers are
unassigned and which are not it is going to increase the risk of a
collision.

If five people are experimenting with TCP options and this is not causing
collisions, what is the problem?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 18 Jan 2011 07:58:25 -0600

Phillip,

Lars can speak for himself, but what I THOUGHT he was talking was changing the phrase "unassigned" to something like "reserved for future assignment". 

That made sense to me...

Spencer
  ----- Original Message ----- 
  From: Phillip Hallam-Baker 
  To: Lars Eggert 
  Cc: Iljitsch van Beijnum ; [email-masked] ; [email-masked] 
  Sent: Tuesday, January 18, 2011 7:51 AM
  Subject: Re: Use of "unassigned" in IANA registries

    Hi,

  But it meets the goal of the people squatting. Is there any reason to think that changing the name of the code points is going to make a difference?

  I am currently applying for a DNS RR code assignment. More than one person involved suggested that we should just assign the RR code ourselves by fiat because they didn't want to wait six weeks for a review.

  My name is on the draft so we have applied for an assignment. But now that six weeks have passed we have a major industry meeting next week that is to discuss the proposal (amongst others) as part of a DNSSEC deployment effort and there has been no response.

  I don't see how changing the name is going to affect behavior for the positive here. If you do succeed in confusing people as to which numbers are unassigned and which are not it is going to increase the risk of a collision.

  If five people are experimenting with TCP options and this is not causing collisions, what is the problem?

------------------------------------------------------------------------------

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 Jan 2011 16:02:10 +0200

Hi,

> I don't see how changing the name is going to affect behavior for the positive here. If you do succeed in confusing people as to which numbers are unassigned and which are not it is going to increa…

huh? The purpose here is to make it *clearer* that assignment is needed.

> If five people are experimenting with TCP options and this is not causing collisions, what is the problem?

Have you read my original email? It *is* going to cause collisions.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 Jan 2011 16:02:31 +0200

> Lars can speak for himself, but what I THOUGHT he was talking was changing the phrase "unassigned" to something like "reserved for future assignment". 

Exactly.

Lars

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 Jan 2011 09:32:16 -0500

On Tue, Jan 18, 2011 at 8:58 AM, Spencer Dawkins
<[email-masked]>wrote:

>  Phillip,
>
> Lars can speak for himself, but what I THOUGHT he was talking was changing
> the phrase "unassigned" to something like "reserved for future assignment".
>
> That made sense to me...
>

That would work IF the reason this is happening is that people don't
understand that unassigned means reserved for future assignment.

But I rather suspect that the reason that this is happening is that people
know full well that there is a process and choose to ignore it because they
either can't be bothered to put up with the hassle or don't think that the
application will be accepted.

At the moment we do in fact have code points that are reserved as distinct
from being 'unassigned' and this is done because it is known that use of
that code point will cause a collision. Often because the code point was
hijacked.

For example the DNS code points for Apple's Bonjour protocol are reserved
rather than assigned.

SRV code points are an even bigger mess because there isn't even a proper
registry to enter them in.

I think it is rather more likely that the root cause here goes back to the
fact that the old three track standard process has broken down and the
criteria for acceptance as a PROPOSED standard are now essentially those for
DRAFT.

One of the reasons for having a low bar for initial drafts was that they
were necessary to get the required code point assignments.

>Have you read my original email? It *is* going to cause collisions.

This type of behavior certainly could cause collisions. But that seems to be
a risk that the people who engage in that behavior prefer to take rather
than apply for an assignment.

What I am saying here is that people need to be very clear as to what the
objectives they are trying to achieve here and make sure that they do not
overstep the mark.

If the only priority is to prevent collisions, then it is really easy to
avoid problems, just open the registry first come first served.

For many lower level registries that is not an option because there is a
real risk of code point exhaustion. That is particularly true with some of
the deep down one byte codes. But that is relatively manageable.

What creates real problems and puts those objectives at risk is when control
of the registry is seen as a means of ensuring that nobody can deploy
proprietary code or encumbered technology or something that someone feels
should really be built on the basis of their little pet project so that it
gets deployed and used.

There are plenty of cliques who try to engage in that particular type of
behavior and far too few people who have the courage to stand up to them and
call them out when they do so.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 Jan 2011 16:44:13 +0200

Hi,

> understand that unassigned means reserved for future assignment.

that *is* the reason, for at least those cases that I have been involved in.

> application will be accepted.

Suspect all you want, but it doesn't match my experience.

> registry to enter them in.

We're very close to fixing this: http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports

> criteria for acceptance as a PROPOSED standard are now essentially those for

RFC2026 has almost nothing to do with IANA allocation procedures. (The only relation is that some registries require a Standards Action, but even then it is irrelevant which level of the standards track the RFC is on. And yes, it's somewhat more difficult to have a Standards Action occur than passing the bar for the other RFC5226 policies, but then again, few registries actually need a Standards Action.)

Lars

---

From: Eric Rosen <[email-masked]>
Date: Tue, 18 Jan 2011 10:15:29 -0500

Phillip> But I rather suspect that the reason that this is happening is that
Phillip> people know full well that there is a process and choose to ignore
Phillip> it because they either can't be bothered to put up with the hassle
Phillip> or don't think that the application will be accepted.

Lars> Suspect all you want, but it doesn't match my experience.

Phillip's suspicion certainly matches my experience over the past 15 years,
and I've even done my own share of codepoint squatting.  He is also correct
to state that many folks try to use control over the codepoint space as part
of their competitive marketing strategy.  The only way to avoid collisions
due to "squatting" is to adopt a policy that all codepoint fields be large
enough so that a significant number of codepoints are available for FCFS
allocations.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 18 Jan 2011 18:25:44 +0200

On 2011-1-18, at 17:15, Eric Rosen wrote:
> The only way to avoid collisions

That's certainly a suggestion we should follow for new registries, but unfortunately doesn't help us with existing ones.

Lars

---

From: Martin Rex <[email-masked]>
Date: Tue, 18 Jan 2011 18:08:53 +0100 (MET)

Lars Eggert wrote:
> > due to "squatting" is to adopt a policy that all codepoint fields
> > be large enough so that a significant number of codepoints are
> > available for FCFS allocations.
> 
> That's certainly a suggestion we should follow for new registries, but
> unfortunately doesn't help us with existing ones.

A possibility for existing registries would be to allow for optimistic
reservation.  e.g. allow WG conensus to request a reservation of a code
point for registries that require standards action, which would cause
IANA to change a code point from "unassigned" to "reserved" (or "tentative")
for a certain amount of time.

It depends on the priorities: is it better to have a clean and strictly
sequential official assignments of code points (with collisions created
by those who do not want to wait), or is it better to prevent
collisions at the risk of somewhat scattered final assignments appearing
in the registry, and potential collisions with abandoned proposals when
the pool of available code points is getting exhausted.

-Martin

---

From: "t.petch" <[email-masked]>
Date: Tue, 18 Jan 2011 17:37:02 +0100

----- Original Message -----
From: "Lars Eggert" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: "Iljitsch van Beijnum" <[email-masked]>; "Phillip Hallam-Baker"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 18, 2011 3:02 PM

On 2011-1-18, at 15:58, Spencer Dawkins wrote:
> Lars can speak for himself, but what I THOUGHT he was talking was changing the
phrase "unassigned" to something like "reserved for future assignment".

Exactly.

<tp>
Which, presumably, would be in a BCP updating RFC5226 which only allows for

  Private Use:
  Experimental:
  Reserved:  Not to be assigned.
  Unassigned: Unused and available for assignment via documented  procedures.

Tom Petch

</tp>

Lars

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 Jan 2011 23:10:10 -0500

> enough so that a significant number of codepoints are available for FCFS

One rather critical consideration here is that the lack of control provides
the IETF with some rather important protection against this type of attack
and is one of the reasons that the loose organizational structures are
relatively stable.

If the registry was a control point there would be far more people
attempting to capture it.

---

From: "t.petch" <[email-masked]>
Date: Wed, 19 Jan 2011 12:14:40 +0100

Perhaps what we should do is to ask IANA to amend their web page so that when
you go to the protocol registry, that massive page with hundreds of entries with
a brief explanation at the top, the top includes the definition of 'unassigned'
from RFC5226, with a reference to RFC5226 and a note to the effect that obscure
terms like FCFS, Standards Action are also defined there.  Then noone could
claim ignorance if they squatted on an unassigned code point, their behaviour
would be knowingly malicious.

A bit like 'Note Well' which means that noone can claim that they did not know
what they were doing when they were granting us the right to use their text.

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "Lars Eggert" <[email-masked]>; "Spencer Dawkins"
<[email-masked]>
Cc: "Iljitsch van Beijnum" <[email-masked]>; "Phillip Hallam-Baker"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 18, 2011 5:37 PM
Subject: Re: Use of "unassigned" in IANA registries

> > Lars can speak for himself, but what I THOUGHT he was talking was changing
the

---

From: Stig Venaas <[email-masked]>
Date: Mon, 31 Jan 2011 12:38:02 -0800

I have now submitted version 04 which I believe addresses the last
call comments. The changes are as follows:

Added the sentence:
The message type is a 4-bit integer with possible values from 0 to 15.

Listing 11-14 as Unassigned.

The references are now all Informational (there was a down reference
to experimental).

There was a comment about expanding the term PIM. PIM has now been
added to the list of well-known abbreviations that don't need to be
expanded. Hence I chose not to expand it.

Stig

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 01 Feb 2011 08:16:59 +0200

> Listing 11-14 as Unassigned.
Stig,

Thank you very much for your changes.  Now the registry definition seems 
to be clear.

> The references are now all Informational (there was a down reference
Maybe RFC 5226 should be referenced normatively, as well as some docs. 
connected to PIMv2.  Moreover, the reference to IANA registry should read:

Internet Assigned Numbers Authority (IANA) Registry, "IGMP Type 
Numbers", per RFC 3228, as for <registry update date, for this - 
November 2010>

All the best,
Mykyta Yevstifeyev