Subject: [PWE3] PWE3 IANA policy

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Jul 2005 11:38:34 +0100

I have been talking to Mark about the PWE3 IANA draft.
Mark has been informally talking to other IESG members
about this draft and his view is that if we submit it
to the IESG it is likely to be rejected.

The issue is with the criteria for the allocation of a
codepoint by IANA. The PWE3 IANA draft reflects the
discussion that we had at IETF-62, and only requires the
existence of an ID for IANA to allocate a codepoint.
The IESG are concerned that this is open to abuse. As
things stand, authors could submit an incomplete or
inaccurate draft with no intention of taking it
further simply in order to get a codepoint allocated.

A compromise proposal that is more likely to gain IESG
acceptance would be for us to partition the codepoints
into two ranges.

1) Expert review or IETF consensus (to be decided)

2) Vendor Specific.

Values from the first range would be used to support
work items from the IETF (either WG draft or individual
drafts taken to completion) and work items from other
SDOs.

Values from the second range would be used to support
proprietary and experimental work which, at the time
of allocation, was not intended to be taken to the IETF.

I am seeking the views of the PWE3 WG on these
proposed changes to the IANA allocation policy in our
IANA draft.

It is important that we agree a mutually acceptable
solution with the IESG ASAP, because the IANA draft
blocks all of the other work that we have completed.

- Stewart

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

---

From: Eric Rosen <[email-masked]>
Date: Thu, 14 Jul 2005 10:23:59 -0400

> The PWE3  IANA draft reflects the  discussion that we had  at IETF-62, and
> only requires the existence of an ID for IANA to allocate a codepoint. 

Already too strong a condition, in my opinion, it should just be FCFS. 

> The  IESG are  concerned that  this  is open  to abuse.  As things  stand,
> authors could submit  an incomplete or inaccurate draft  with no intention
> of taking it further simply in order to get a codepoint allocated.

If it were FCFS,  this issue would not arise ;-) But  as things stand, there
is this consequence, and the WG has accepted it.

> his view is that if we submit it to the IESG it is likely to be rejected. 

I do not see any reasonable grounds  by which the IESG can reject this.  The
IETF processes make it the responsibility  of the WG to make this call.  The
IESG  is not  empowered to  reject something  just because  they  would have
preferred the WG to have done something different.

> acceptance 

I strongly believe that the IESG  should be presented with the WG consensus.
If the IESG attempts to substitute its  own judgment for that of the WG, the
appeals process can (and will) be invoked. 

> It is important that we agree a mutually acceptable solution with the IESG
> ASAP 

Then how about  we submit the doc and follow the  process, instead of making
"backroom deals" and reopening issues that have already been settled?

---

From: Thomas Narten <[email-masked]>
Date: Fri, 15 Jul 2005 14:26:16 +0200

Hi Stewart.

> of allocation, was not intended to be taken to the IETF.

To clarify, what are the IANA considerations for vendor-specific? Are
they FCFS, or are they something more stringent?

If the policy is FCFS, those arguing that they want to get code points
no question asked can do so, but they will at least be clearly labeled
as being vendor specific and not an IETF standard of any sort.

Thomas

---

From: Eric Rosen <[email-masked]>
Date: Fri, 15 Jul 2005 09:44:55 -0400

> as being vendor specific and not an IETF standard of any sort. 

I  don't  think it  is  appropriate  to have  one  range  of codepoints  for
standards and  another for non-standards.  If a  deployed non-standard later
becomes a standard, you end up with a codepoint in the "wrong" range.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 18 Jul 2005 15:12:20 +0100

> they FCFS, or are they something more stringent?

FCFS

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 19 Jul 2005 08:28:52 -0700

Eric,

> preferred the WG to have done something different.

I would like to hear from the IESG folks who are on this list whether
the IESG agrees with the last statement above, namely that "the IESG  is
not  empowered to  reject something  just because  they  would have
preferred the WG to have done something different". 

Yakov.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 19 Jul 2005 13:32:16 -0400

> standards and  another for non-standards.

Why not?

I see nothing wrong with having a range that is clearly marked "IETF
reviewed and approved" and a different  range for "Vendor specific".

If what folk care about is being able to get a code point FCFS, no
questions asked, you get it with this range.

What you don't get is being able to claim that it is an IETF-approved
extension. That is a very good thing!

> If a  deployed non-standard later

Big deal. If folk care, they allocate a second code point and require
that implementations of the standard support both for backwards
compatability. This is not a problem.

Thomas

---

From: Eric Rosen <[email-masked]>
Date: Tue, 19 Jul 2005 13:50:01 -0400

Eric> If a deployed non-standard later becomes a standard, you end up with a
Eric> codepoint in the "wrong" range.

Thomas> Big deal. If folk care, they allocate a second code point and require
Thomas> that implementations of the standard support both for backwards
Thomas> compatibility. 

Nobody  in his  right mind  would do  that.  However,  it will  certainly be
proposed by folks who  don't implement the standard, as it is  a good way to
make life difficult for those who do.

Thomas> This is not a problem. 

On  the contrary,  the  existence of  a  standard with  a "vendor  specific"
codepoint will be a fertile source for lots of FUD. 

Thomas> What you don't get is being able to claim that it is an IETF-approved
Thomas> extension. That is a very good thing! 

Allocations by  IANA from  the FCFS  space are neutral  with respect  to the
issue  of whether the  codepoint is  used by  an IETF-approved  extension or
not. 

While  anyone  can  of  course  claim  anything at  any  time,  the  way  to
demonstrate that you are using  an IETF-approved extension it to reference a
standards track RFC.  The procedures  used by IANA to allocate the codepoint
have nothing to do with it, nor should they.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 21 Jul 2005 13:37:25 -0700

Couldn't help playing with Yakov's bait ;)

Tuesday, July 19, 2005, 8:28:52 AM, Yakov Rekhter wrote:
...
> preferred the WG to have done something different". 

What exactly do you mean by "just because they would have preferred the WG
to have done something different"?

;-)

--
Alex

---

From: Luca Martini <[email-masked]>
Date: Mon, 25 Jul 2005 12:11:14 -0600

>compatability. This is not a problem.
Maybe not for the IETF , but it will cost the Service providers,  real 
money!
Changing a protocol in a deployed network , just because the allocation 
body was too slow to allocate the value requires  significant time and 
effort.
More likely the market will accept the established value.

Luca

---

From: Luca Martini <[email-masked]>
Date: Tue, 26 Jul 2005 15:37:02 -0600

Ok after reading this long long thread ... on a trivial issue ....

The fact is that there is no protocol enforcement, therefore the IETF 
will not be deciding what a pw type in a specific range is used for.
If we have a small IETF consensus , and a larger FCFS range we should be 
able to move on.
Let's not make up hypothetical future fictional DOS situations that will 
never happen. There is no money involved in this allocation , therefore 
there will be no DOS.

My 2c ;-)

Luca