Subject: RE: [PWE3] PWE3 IANA policy

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 18 Jul 2005 18:05:46 +0300

Scott,
Lots of thanks!

Regards,
			Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 18, 2005 5:03 PM
> To: [email-masked]; Sasha Vainshtein; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [PWE3] PWE3 IANA policy
> 
> 
> > Can anybody point to a real-life example of codepoints 
> allocation using the
> > Expert Review policy?
> 
> MIME types
> 
> Scott
> 

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

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 19 Jul 2005 11:54:16 -0400

Yakov,

	We play with words.  :-)

	The IESG is certainly explicitly "empowered" to reject 
a draft - for whatever reason they might choose.

	The issue is that - if the IESG starts wielding that 
power a lot - then they will soon find that everyone simply
waits to see what they're going to say before doing anything.
This is particularly true if they start dictating specific
content that they would like to see in specific drafts.

	At some point - assuming that continues unabated - many 
of the people who attend the IETF, subscribe to the mailing 
lists or participate in working group activities will simply 
pack their brief cases and go home.

	That - I strongly suspect - is not what the IESG wants
to happen.

	Consequently, what I suspect you're going to see is
that most IESG members will simply want to make sure that 
the rest of us are behaving like adults - but otherwise we
should be given a reasonably free hand.

--
Eric Gray

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On Behalf Of
--> Yakov Rekhter
--> Sent: Tuesday, July 19, 2005 11:41 AM
--> To: Stewart Bryant
--> Cc: pwe3
--> Subject: Re: [PWE3] PWE3 IANA policy 
--> 
--> 
--> Stewart,
--> 
--> > > One annoying aspect of this entire discussion is that it 
--> > > is largely a repeat of the discussion at the meeting.  We
--> > > should settle this problem once and for all - either on
--> > > this mailing list or at the meeting.
--> > 
--> > The IANA document as it stands reflects the outcome of the
--> > last IETF.
--> > 
--> > Mark may care to comment, but as I understand it, the issue
--> > of IANA codepoints and access to them by other SDOs has
--> > been the subject of considerable IESG thought since the last
--> > IETF. Against this background, the views of various IESG
--> > members were sought WRT our IANA draft, and the conclusion
--> > was that if we submitted the draft unmodified it would be
--> > rejected.
--> > 
--> > I note that the WG members that have so far expressed a
--> > view have stated that we should take the draft to the IESG
--> > unmodified and manage the consequences. Do other WG members
--> > agree?
--> 
--> In deciding on whether to "take the draft to the IESG unmodified and
--> manage the consequences" it would help to find out whether the IESG
--> is empowered to  reject something  just because they would have
--> preferred the WG to have done something different.
--> 
--> With this in mind, I'd like to hear the IESG's position on whether
--> it is empowered to  reject something  just because the IESG would
--> have preferred the WG to have done something different.
--> 
--> Yakov.
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
-->

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 19 Jul 2005 13:04:51 -0400

In fact, all I was looking for IANA to do was include a
reference to some document - preferably either an ID or
an RFC - claimed to be a description of the planned use 
for a code point.

In an ideal world, this would be the case even for FCFS 
- with the exception that IANA could insert "None" if a
code point request included no reference - while, with
a document required, IANA should never insert "None".

I'm not sure that it consistently works either way. In 
fact, I am not certain that any references are recorded
by IANA even with expert review.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On Behalf Of
--> Eric Rosen
--> Sent: Tuesday, July 19, 2005 12:24 PM
--> To: Stewart Bryant
--> Cc: pwe3
--> Subject: Re: [PWE3] PWE3 IANA policy 
--> 
--> 
--> Stewart> I would  find it easier to argue  their case if I  
--> could quote what
--> Stewart> happened. 
--> 
--> I don't  believe that  there is  any part of  the document  
--> approval process
--> which requires the WG chair to argue the WG's case before the IESG.
--> 
--> Stewart> the conclusion  was that  if we submitted  the 
--> draft  unmodified it
--> Stewart> would be rejected.
--> 
--> The only "technical"  objection was that IANA must not  be 
--> required to judge
--> the truth of a requester's claim  that a particular i-d 
--> describes the use of
--> a particular proposed  codepoint.  This could be solved  by 
--> making the field
--> FCFS, or  even by stating explicitly  that IANA's only  
--> responsibility is to
--> include the draft name in the registry along with the 
--> codepoint assignment.
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
-->

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 19 Jul 2005 13:50:56 -0400

Thomas,

	This is fine, but increases the potential for abuse.
With out a dead-line, the expert could delay progress for 
an indefinite period of time.  That could happen simply
because the expert has time pressures for other tasks and
not for this one.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On Behalf Of
--> Thomas Narten
--> Sent: Tuesday, July 19, 2005 1:39 PM
--> To: [email-masked]
--> Cc: Mark Townsley; Yaakov Stein; pwe3
--> Subject: Re: [PWE3] PWE3 IANA policy 
--> 
--> 
--> > That's not  what I was  questioning.  I don't  think they 
--> have a  process in
--> > place for  timing out the request  to the expert and  
--> granting the codepoint
--> > automatically if the timer expires before the expert responds. 
--> 
--> That's right. Because some people (myself included) think it's bad
--> policy to approve something by default when an artifical deadline
--> can't be met (e.g., while, say, an expert is on vacation.)
--> 
--> Thomas
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
-->

---

From: [email-masked]
Date: Wed, 20 Jul 2005 11:44:34 +0100

Colleagues,

I have been following this discussion with interest.  I have no real
opinion as to what allocation policy should be used (frankly I don't
care).  Anyway here's my 2p (or my 3c at current exchange rates).

I sense a certain level of paranoia that some 'company X' will
potentially launch a DoS attack on the PW type code point space.

Playing Devil's advocate can I ask if this paranoia is justified?  Has
there been an actual case where a 'company X' has launched such a DoS
attack on an IANA assigned code point space?  If there hasn't been such
a case, what makes folks think that PWE3 code points will be different
to all the other IANA code point spaces/assigments where FCFS has been
used and no DoS attack launched?

To me the real crux of the debate is one of the following:

1) The group consensus is that code points do not need to be reviewed
before being allocated and therefore the code point space should be
FCFS.
2) The group consensus is that code points should be reviewed before
being allocated and therefore the code point space should be Expert
Review.
3) The group cannot reach consensus, and therefore the code space should
be split (by some ratio that is not necessarily 50:50) between FCFS and
Expert Review.

I don't see any value in discussing hypothetical future situations that
no-one can predict and for which there is no historical basis/evidence
that they may happen at some unknown and undetermined point in the
future.

Ben

---

From: [email-masked]
Date: Wed, 20 Jul 2005 12:51:13 +0100

I understand the intention, however, I personally don't think expert review is aligned with the spirit of the IETF. How can the WG guarantee that the expert is completely unbiased and is qualified to evaluate all proposals, i.e. why mandate 'rough consensus' for decisions about PWE3 drafts, but allow an 'expert' to accept/reject a PW type request?

I don't think that having a vendor specific range will help either. What's to stop someone claiming to be from "Ronald's Reliable Routers" or "Steve's Slick Switches" from requesting PW types? You could put vendor rules in place, but what could they be based on without being biased against small start-up companies, e.g. existence of a working product, number of employees, number of customers? In addition, how would conformance to the rules be proven, e.g. lab demos of the working product, customer order books?

Why not make the whole range FCFS but reserve say 30% of the values for 'future use' as an insurance policy? That way if there is a DoS attack and we run out of values then we can release the reserved values but use WG consensus to protect them against another DoS attack. If on the other hand we don't run out of values then everyone's happy anyway, regardless of whether or not all the values are being used for useful purposes or indeed being used at all.

Regards,
Richard

> From: Thomas Narten [mailto:[email-masked]]
> Sent: 20 July 2005 12:20
> To: Spencer,R,Richard,XDE73 R
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [PWE3] PWE3 IANA policy 
> 
> 
> <[email-masked]> writes:
> 
> > Unless the use/implementation of PW types is also regulated, then I
> > see little value in regulating the allocation.
> 
> Clearly, we are not the protocol police and will not be able to
> prevent intentional misuse. But where an expert review is indeed
> helpful is in (the not uncommon case) of someone making a proposal
> that is not well thought out and that has gotten absolutely no review
> from someone with expertise in the field. Often, such review alerts
> the proposer to the reality that "things are more complicated than I
> thought" and they then modify their proposal, get additional review,
> etc.
> 
> This is goodness and is something that we should be striving for, as
> it helps reduce the introduction/deployment of poorly thought out
> extensions.
> 
> Thomas
> 
>

---

From: "Florin Balus" <[email-masked]>
Date: Wed, 20 Jul 2005 08:05:11 -0400

I agree with Richard's point and proposal: how does IETF "rough
consensus" policy align with the expert review? 

What is stopping an expert from playing games with my request for a code
point? Are there any clear ways to limit his response time/power? How do
we go back after being delayed (& what is the definition of delay
anyhow?)? Or even worst after being denied access to a code point?

Florin

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of [email-masked]
>Sent: Wednesday, July 20, 2005 7:51 AM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]
>I understand the intention, however, I personally don't think 
>expert review is aligned with the spirit of the IETF. How can 
>the WG guarantee that the expert is completely unbiased and is 
>qualified to evaluate all proposals, i.e. why mandate 'rough 
>consensus' for decisions about PWE3 drafts, but allow an 
>'expert' to accept/reject a PW type request?
>
>I don't think that having a vendor specific range will help 
>either. What's to stop someone claiming to be from "Ronald's 
>Reliable Routers" or "Steve's Slick Switches" from requesting 
>PW types? You could put vendor rules in place, but what could 
>they be based on without being biased against small start-up 
>companies, e.g. existence of a working product, number of 
>employees, number of customers? In addition, how would 
>conformance to the rules be proven, e.g. lab demos of the 
>working product, customer order books?
>
>Why not make the whole range FCFS but reserve say 30% of the 
>values for 'future use' as an insurance policy? That way if 
>there is a DoS attack and we run out of values then we can 
>release the reserved values but use WG consensus to protect 
>them against another DoS attack. If on the other hand we don't 
>run out of values then everyone's happy anyway, regardless of 
>whether or not all the values are being used for useful 
>purposes or indeed being used at all.
>
>Regards,
>Richard
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 20 Jul 2005 07:16:21 -0700

Hi all,

What if instead of a draft we ask for an Informational or Experimental RFC.
Doing that would raise the bar more so that DoS attack would be very cumbersome.

Yours,
Shahram

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 20 Jul 2005 17:24:44 +0300

Shaharam and all,
I would strongly object to that.
Experimental RFCs are, to the best of my understanding, proposals that the
IETF intends to upgrade to the Standards Track one day.
And even pubishing Informational RFCs can take quite some time (as the
experience of this WG shows).

Regards,
			Sasha
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Wednesday, July 20, 2005 4:16 PM
> To: [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Wed, 20 Jul 2005 07:48:12 -0700

Sasha,

I am not sure what is wrong with the possibility of an Experimental RFC
becoming a standard track RFC one day. I don't see any relevance to this
discussion.

I think Informational RFC's are the best way to document any non-IETF protocol
in IETF that lasts more than 6 months life time of drafts. True, it takes longer time than draft, but that's the whole idea to raise the bar.

Yours,
Shahram

> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: Wednesday, July 20, 2005 10:25 AM
> To: Shahram Davari
> Cc: [email-masked]

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 20 Jul 2005 18:19:09 +0200

Shahram, 

I'm with Sasha on this one.

The RFC editor treats individual submissions
least preferentially, and your suggestion would
probably involve even longer delay than what Andy
has described.

Y(J)S

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 20 Jul 2005 11:27:56 -0400

Ben,

	The thing to realize is that - with finite resources (however
apparently abundant) - any resource use is a denial of that resource
to a future user.  This does not require paranoia, just a difference
in perspective.

--
Eric

--> -----Original Message-----
--> From: [email-masked] 
--> [mailto:[email-masked]]On Behalf Of
--> [email-masked]
--> Sent: Wednesday, July 20, 2005 6:45 AM
--> To: [email-masked]
--> Subject: RE: [PWE3] PWE3 IANA policy
--> 
--> 
--> Colleagues,
--> 
--> I have been following this discussion with interest.  I have no real
--> opinion as to what allocation policy should be used (frankly I don't
--> care).  Anyway here's my 2p (or my 3c at current exchange rates).
--> 
--> I sense a certain level of paranoia that some 'company X' will
--> potentially launch a DoS attack on the PW type code point space.
--> 
--> Playing Devil's advocate can I ask if this paranoia is 
--> justified?  Has
--> there been an actual case where a 'company X' has launched 
--> such a DoS
--> attack on an IANA assigned code point space?  If there 
--> hasn't been such
--> a case, what makes folks think that PWE3 code points will 
--> be different
--> to all the other IANA code point spaces/assigments where 
--> FCFS has been
--> used and no DoS attack launched?
--> 
--> To me the real crux of the debate is one of the following:
--> 
--> 1) The group consensus is that code points do not need to 
--> be reviewed
--> before being allocated and therefore the code point space should be
--> FCFS.
--> 2) The group consensus is that code points should be reviewed before
--> being allocated and therefore the code point space should be Expert
--> Review.
--> 3) The group cannot reach consensus, and therefore the code 
--> space should
--> be split (by some ratio that is not necessarily 50:50) 
--> between FCFS and
--> Expert Review.
--> 
--> I don't see any value in discussing hypothetical future 
--> situations that
--> no-one can predict and for which there is no historical 
--> basis/evidence
--> that they may happen at some unknown and undetermined point in the
--> future.
--> 
--> Ben
--> 
--> _______________________________________________
--> pwe3 mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/pwe3
-->

---

From: Shahram Davari <[email-masked]>
Date: Wed, 20 Jul 2005 09:10:19 -0700

All I meant by this example was that there is a precedence for requiring an RFC.
Informational/experimental RFC's don't need to be approved by IETF WGs.
That's my proposal. Please debate this if you like.

Yours,
Shahram

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Wednesday, July 20, 2005 12:03 PM
> To: Shahram Davari
> Cc: 'Sasha Vainshtein'; [email-masked]
> > I  could remind you  of the  MPLS OAM  Alert label  that 
> was  requested by
> > ITU. IETF's response  was to that an Informational RFC  is 
> needed in order
> > to get that label assigned.
> 
> RFC  3032 states  that IANA  may assign  such label  values, 
> "based  on IETF
> consensus".  RFC 2424  defines  "IETF  Consensus" in  this  
> context as  "new
> assignments  are made  via  RFCs approved  by  the IESG".   
> We could  debate
> whether the IESG acted properly  in allowing this particular 
> assignment, but
> clearly the IANA  considerations for this 4-bit space  call 
> for review.  And
> the  policy is  NOT  simply "publish  an  RFC and  you  
> automatically get  a
> number". 
> 
> So basically this  is irrelevant to the current discussion.   
> No one has yet
> suggested "IETF consensus" as the policy. 
>

---

From: Mark Townsley <[email-masked]>
Date: Thu, 21 Jul 2005 01:21:00 +0200

Gray, Eric wrote:

>Mark,
>
>	Did you happen to notice that the "offlist" message you 
>sent was on the list?  :-)
>  
>
Oh well! That was an accident (and now am cc'ing pwe3 on purpose so they 
know - sorry about that, Eric).

I've been making a number of goofs along these lines lately. I am in the 
midst of a PC to Mac transition, so some things aren't as second-nature 
to me right now.

Back to your regularly schedule thread...

- Mark

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 21 Jul 2005 12:45:20 +0300

Shahram and all,
Sorry for a belated response, but...

IMHO there is a substantial difference between allocation
of a new reserved label and allocation of a new PW Type:

- The former (especially so in the case of the Y.1711 OAM Label)
  potentailly affects ALL the LSRs receiving packets with the label 
  stack containing this label. The standard treatment
  of unknown looked at labels is to discard the packets so labeled,
  and since it is impossible to know whether some LSR on the LSP
  shall ever look at the OAM label or not, the result of
  placing such a label in the stack could be quite unexpected
  for the sender. Hence an explicit description of some alternative 
  action was justly required

- The latter only affects the Targeted LDP peers negotiating setup of
  a specific PW. If one of them does not recognize the PW type
  present in the PWId FEC distributed by the other, it will
  simply release the label bound to this FEC, and the PW shall
  not be ever set up. But then, you could hardly expect anything 
  else, right? I.e., the consequences here are fully predicatble
  and the effect limited. IMHO this means that the only thing
  you need in such a case is unique allocation. FCFS definitely
  meets this requirement.

Regards,
			Sasha
> Sent: Wednesday, July 20, 2005 6:10 PM
> To: [email-masked]'
> Cc: Sasha Vainshtein; [email-masked]