Subject: RE: [PWE3] PWE3 IANA policy

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 14 Jul 2005 19:41:54 +0200

Stewart and all, 

I understand your wanting to make the IANA allocation go through
as smoothly as possible, but find it hard to accept that the IESG
is forcing us to accept "expert review" or consensus instead of 
presenting an ID.

The idea behind having an ID written was to force the requester
to plainly state what he wants the code point for.
With all the requirements to get an ID published today,
writing an ID is not a simple matter, and it is not expected
to be done in quantities to create denial of service attacks on
our code points. A more devious kind of attack would be
to carefully word an ID to look sensible, but to hide the
true intent. I believe that if someone goes to all this effort,
he deserves the code point. 

On the other hand allocating "vendor specific" ranges
basically removes code points from ever being used
for truly valuable purposes. This amounts to the PWE WG
doing the denial of service attack on its own registry.

If we do go for a compromise, it should be along the lines
of the WG (or some other group after PWE closes)
being able to decide that the ID is not frivolous.
I purposely set a low threshold here - we don't want
an expert to decide whether the ID is "complete"
or accurate or ready to be advanced to standards-track RFC
status.

Y(J)S

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Mark Townsley <[email-masked]>
Date: Thu, 14 Jul 2005 13:43:10 -0400

Hello Yaakov, please see inline...

>he deserves the code point. 

Such an "Internet Draft Exists" policy is a problem as it chews up IETF 
resources for little benefit, and as Stewart mentions is open to abuse. 
Since IDs have no review associated with them, one could simply submit a 
single word (or less) with biolerplate, never to be updated again. Since 
there is no review process defined for the IANA allocation, IANA can't 
say whether the draft does or does not describe the use of the code. In 
fact, forget submitting a draft at all, there really is no one to stand 
in the way of simply pointing IANA to any existing draft in the current 
directory, whether it has anything to do with the code or not. Since IDs 
expire, there may be no permanent historical record of why the value was 
assigned in the first place. This only increases orphaned documents and 
links, fosters confusion, and in the end is simply bad management.

>doing the denial of service attack on its own registry.
The "vendor specific" range is functionally equivalent to the "expert 
review" range. The idea is not to render half the registry useless, but 
to designate which half was obtained after some level of review, and 
which half was FCFS from a single vendor. I suppose IANA could include a 
checkbox for each value allocated within a single range, e.g.,  - 
"Expert Review y/n" - "Vendor Specific y/n" - but that's not how the 
process is currently designed. For the PW Type, given that we would have 
32K values in each registry, I don't think it is realistically necessary 
to have something like this.

>or accurate or ready to be advanced to standards-track RFC
You have essentially defined the Expert Review process, but with the 
addition that there be an ID for the Expert to refer to rather than some 
other type of document.

- Mark

---

From: Eric Rosen <[email-masked]>
Date: Thu, 14 Jul 2005 15:14:27 -0400

Mark> Such an "Internet Draft Exists" policy is a problem as it chews up IETF 
Mark> resources for little benefit, and as Stewart mentions is open to abuse. 
Mark> Since IDs have no review associated with them, one could simply submit a 
Mark> single word (or less) with biolerplate, never to be updated again. Since 
Mark> there is no review process defined for the IANA allocation, IANA can't 
Mark> say whether the draft does or does not describe the use of the code. In 
Mark> fact, forget submitting a draft at all, there really is no one to stand 
Mark> in the way of simply pointing IANA to any existing draft in the current 
Mark> directory, whether it has anything to do with the code or not. Since IDs 
Mark> expire, there may be no permanent historical record of why the value was 
Mark> assigned in the first place. This only increases orphaned documents and 
Mark> links, fosters confusion, and in the end is simply bad management.

Note that  the "First Come  First Served" policy  doesn't have any  of these
problems. 

I  think Mark is  right to  say that  IANA cannot  be expected  to determine
whether a  particular draft is  or is  not a description  of the use  of the
proposed codepoint.  So  the requirement as it is written  is really FCFS in
effect, with  the requester encouraged but  not really required  to at least
write a draft.  Since I like  the FCFS policy anyway, I'm not very concerned
about the possibility of someone failing to write a draft.

Yaakov> If we do go for a compromise, it should be along the lines
Yaakov> of the WG (or some other group after PWE closes)
Yaakov> being able to decide that the ID is not frivolous.
Yaakov> I purposely set a low threshold here - we don't want
Yaakov> an expert to decide whether the ID is "complete"
Yaakov> or accurate or ready to be advanced to standards-track RFC
Yaakov> status.

I think there  was a pretty clear consensus that we  didn't want any process
which would allow for mischief and  delays on the part of the "expert".  The
problem is that  once you make the approval a  matter of someone's judgment,
you've opened the door to abuse.  We can say that the bar should be low, but
we have no way to enforce the position of the bar.