Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Wed, 26 Feb 2003 09:00:05 -0500

Loa> Could you do me a favor and have a look at:
Loa> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt

Scott> this ID was brought up in a meeting I am at in the ITU - there 
Scott> is some concern about it - I have asked that people with 
Scott> concerns please send their concerns in.

The requirements decision processes in the I-D should give some weight to the 'strength' of the requirements source and proponents.  

E.g., a concern was raised in a recent discussion on the [email-masked] email-list "RE: Last Call: CR-LDP extensions for ASON to Informational", where GMPLS/ASON requirements were put forward by ITU-T, with many SPs as proponents, but did not get adequate attention or evaluation, and were perhaps even rejected out of hand.  The unfortunate consequence of this outcome is that now 2 'GMPLS/ASON signaling' (RSVP-TE) standards have emerged, perhaps with interoperability issues.

The decision steps in the I-D are quite vague, and it is unclear that these will do much to rectify this concern, e.g.:

In Section 2.2.2 "The MPLS and CCAMP working group chairs in conjunction with the Area Directors will determine if the particular problems raised ... should be evaluated by a working group... based on the mailing list discussion."
In Section 2.2.4 "The rewg will evaluate the problem statement ID and based on the evaluation make a recommendation to the IESG/IAB."

Nothing is said as to criteria applied to the 'mailing list discussion' (could be dominated by one loud person with a particular view), or how the 'rewg will evaluate the problem statement'.  The decision process appears to remain the status quo, i.e., 'rough consensus', wherein a small oligarchy of ADs, WG chairs, and perhaps a few SMEs appear to decide (especially problematic in 'no response' decision, as stated above).

Additional teeth could put in place to give a more comprehensive review/decision process to overcome these identified problems, e.g.,:

a. for certain categories of problem statements/requirements, put a 'design team' in place to evaluate/recommend a course of action.
b. problem statements signed onto by a >threshold # of SPs/vendors could have such 'design team' evaluation.

Jerry Ash

---

From: "Lazer, Monica A, ALABS" <[email-masked]>
Date: Thu, 27 Feb 2003 08:22:31 -0500

Loa, Kireeti,
I agree with Malcolm. 
Since this draft proposes a process change specifically dealing with
requirements and problem statements, and since ITU uses the liaison
process for this reason, the liaison process is very relevant to the
changes proposed in this draft, and it is not an orthogonal problem.

Monica A. Lazer
Network Architecture and Reliability
 
908 234 8462
[email-masked]
 
-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 8:11 AM
To: 'Loa Andersson'
Cc: Stephen Trowbridge; Kireeti Kompella; [email-masked];
[email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
 
Loa, the from the outside looking in the liaison process and the change
process are closely coupled.  The liaison process is described in ITU-T
Recommendation A.4 and A.5 and in RFC 3356.  
The coupling occurs because the ITU uses the agreed liaison process to
communicate requests to modify IETF protocols based on requirements
agreed by the members of the Study Group (that originated the liaison).
The change process being proposed requires that this official request
from a SDO is converted into an individuals ID.  The level of agreement
in the SDO is therefore obscured, this process appears to be in conflict
with RFC 3356.  The problem is particularly acute when the requirements
are to enable (or enhance) the management of a non IP network to support
a non IP client.  If my understanding of the draft is correct such
requests would be rejected by the IETF.
It is clearly beneficial to the industry if the basic IETF protocols can
be extended to address such applications.  The IETF plays a key role in
ensuring that the integrity of the base protocols is not compromised.
Malcolm Betts 
Phone: +1 613 763 7860 (ESN 393) 
FAX:   +1 613 763 6608 (ESN 393) 
email: [email-masked] 
 
-----Original Message----- 
From: Loa Andersson [ mailto:[email-masked]] 
Sent: Thursday, February 27, 2003 7:33 AM 
To: Kireeti Kompella 
Cc: Stephen Trowbridge; [email-masked]; [email-masked] 
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
<snip> 
I think I've clearly pointed out the limited scope of the change
process, recognized that there is a orthogonal problem on how we treats
liasions coming into the ietf, that the liasion process needs to be
documented, and that we will add text to address the limited
intersection of the change-process and liasion process in order to
promote the cooperation with other SDOs.
/Loa 
<snip>

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 27 Feb 2003 12:21:57 -0500

Just putting in my two cents.  I'd like to support aspects of the liaison process being included in the draft.  Given the close coupling between the
change and liaison processes, and the issues that triggered generation of the draft, I believe we should bite the bullet and work to establish a cohesive process now.
It will be well worth the effort.  In my view, not expending the time now will result in far more time spent later.
 
I'd also like to express support for the proposed revisions provided by Steve Trowbridge,  as I believe they increase the value of the draft by adding necessary clarifications and promoting a cooperative spirit to the entire endeavor.
 
Eve Varma

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 8:11 AM
To: 'Loa Andersson'
Cc: Stephen Trowbridge; Kireeti Kompella; [email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
 
Loa, the from the outside looking in the liaison process and the change process are closely coupled.  The liaison process is described in ITU-T Recommendation A.4 and A.5 and in RFC 3356.  
The coupling occurs because the ITU uses the agreed liaison process to communicate requests to modify IETF protocols based on requirements agreed by the members of the Study Group (that originated the liaison).  The change process being proposed requires that this official request from a SDO is converted into an individuals ID.  The level of agreement in the SDO is therefore obscured, this process appears to be in conflict with RFC 3356.  The problem is particularly acute when the requirements are to enable (or enhance) the management of a non IP network to support a non IP client.  If my understanding of the draft is correct such requests would be rejected by the IETF.
It is clearly beneficial to the industry if the basic IETF protocols can be extended to address such applications.  The IETF plays a key role in ensuring that the integrity of the base protocols is not compromised.
Malcolm Betts 
Phone: +1 613 763 7860 (ESN 393) 
FAX:   +1 613 763 6608 (ESN 393) 
email: [email-masked] 
 
-----Original Message----- 
From: Loa Andersson [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, February 27, 2003 7:33 AM 
To: Kireeti Kompella 
Cc: Stephen Trowbridge; [email-masked]; [email-masked] 
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
<snip> 
I think I've clearly pointed out the limited scope of the change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation with other SDOs.
/Loa 
<snip>

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 27 Feb 2003 13:44:35 -0500

Hi,

The conversation that's being stimulated from the draft gets to the crux of
the issue I see with its current wording.  The draft is being
interpreted as simply describing the present IETF mode of operation.  I didn't
think that was supposed to be the intent.

Eve

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 1:23 PM
To: Loa Andersson
Cc: Kireeti Kompella; Stephen Trowbridge; [email-masked];
[email-masked]

It seems to me that Loa's  document simply describes how the IETF works.  As
such, I'm not sure it is even necessary. 

True, many people have  noticed that the IETF is free to  ignore the work of
other standard organizations.  True, the  fact that a particular proposal is
made by another  standards organization does not even  give the proposal any
special weight in the IETF.

I think these are  good things, and the IETF should not  make any changes in
this respect.  Hence I don't think  Loa's draft (if it needs to exist) needs
to change.

Certainly  the  fact  that  some  position  is  articulated  in  a  "liaison
statement"  should not  give  it any  special  weight.  The  fact that  some
position is supported  by "a threshold number of  vendors and SPs" shouldn't
give it any special weight either.

---

From: John Drake <[email-masked]>
Date: Fri, 28 Feb 2003 06:52:50 -0800

Stephen,

This is the note I sent yesterday, which I thought was fairly clear.

Thanks,

John
============================================================================
====================================
Kireeti,

Extremely well reasoned and thoughtful.  As I understand it, this document
is intended to prevent the situation that just occured, in which the IETF
published an RFC which detailed some changes to RSVP-TE (which had technical
issues) without any review by the CCAMP or MPLS working groups, thereby
explicitly appearing to endorse these changes.

The minutes of the Yokohama CCAMP meeting (see below) seem to indicate that
the CCAMP working group wanted to work on the ASON extensions, so I am still
puzzled as to why the authors of the ASON draft decided, after the Yokohama
meeting, to progress the draft as an informational RFC rather than as a
normal working group draft.

Thanks,

John

> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 6:22 AM
> To: John Drake
> Cc: Kireeti Kompella; [email-masked]; [email-masked]
> John,
> > JD:  Is that a threat or a promise?  BTW, call & connection 
> separation
> > doesn't exist in PNNI either, at least up to the point that 
> I stopped
> > attending the ATM Forum.
> Interesting that you should mention this.
> 
> We sent liaisons to the ATM forum, just as we did to IETF ccamp.
> The reaction we got from the ATM forum was a great deal of help to
> extend the PNNI protocols to meet our requirements. They provided
> us numerous, helpful comments all through the process of development
> of G.7713.1.
> 
> What we got from IETF ccamp was ignored (until we finally did the
> work somewhere else and tried to get code points assigned).
> 
> We seem to have different understandings of what the problem is that
> needs to be solved. My belief is that the problem is that we don't
> have a good process for dealing with liaisons in IETF, and this
> inhibits the kinds of productive relationships between IETF and other
> SDOs that exist between many other (non-IETF) SDOs.
> 
> Some others on this thread seem to think that the problem is those
> other pesky SDOs: after all, how could there possibly be a valid
> problem statement or requirement that wasn't conceived of and 
> developed
> entirely within IETF? Every possible measure should be taken to
> prevent that any work is done to address such requirements.
> 
> What is your perception of the problem?
> Steve
>

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Fri, 28 Feb 2003 10:00:38 -0500

One of the reasons I believe it to be critical to address the liaison aspects
up front is that the issue actually goes well beyond specification
of an administrative process.  I.e., as can be seen from the email threads, it
brings up the whole discussion of how requirements for non-IP applications
originating from other SDOs are addressed.  One train of thought expressed
on the email list appears to take the view that such requirements should
have no extra weight than an individual than that of an individual; there
is no concept of a peer SDO.

Eve  

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 5:20 PM
To: Loa Andersson
Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim;
[email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

agree...

I suggest the liaison process should be a separate document. And update this if it needs updating. For people outside of IETF or new to IETF, it is useful to have these process descriptions. And they are two different subjects (with common links).

For Steve, Eve, etc, I think there are two (at least) discussions on-going (1) the liaison process (which will have the "hooks" to this document and vice versa), and (2) the "what if scenario" (for non-USA, this is our new shuttle terminology): how this document relates to if an sdo (or individual) works outside this process (info rfcs). It would be good (considering the discussion level) to add some clarification text to the chng proc draft.

One option suggested by Kireeti "this is where the SDO can decide, as you point out, that it can do it on its own, but changes the name of the protocol so that innocent bystanders can tell the difference." The SDO protocol is not IETF (as this chng proc draft states) and not (G)MPLS. And as Kireeti suggested the assignments by IANA should distinguish. Another option, suggested by Steve, is that IETF should be a clearinghouse. And discussion is on-going on the interpretation of clearinghouse. 

Steve, your email may be mis-interpreted, e.g.:
"A better approach would be for the IETF to PROMOTE the use of its
protocols for new applications, and, when another Standards Development
Organization wishes to apply (G)MPLS protocols to an application domain
outside of the scope of IETF, that IETF will (1) assist with the development
of any necessary extensions; and (2) to facilitate documentation of
such new applications and extensions in a central place (e.g., by
informational RFC, even for extensions that are developed outside of
IETF) and to insure that code points are assigned in a coherent manner
through IANA to avoid collisions where different extensions may use
the same code points to indicate different things."

I don't think you are requesting IETF to simply endorse another sdo's work without review (unless the interpretation of assist=review), and I am not so sure about the promotion either. In T1X1/ITU, just at this last meeting, many have voiced concern with new applications (suggested within the group) for GFP: PON, switched layer. The concern is on extending GFP beyond what it was designed. What if another forum decided to do switched GFP? And they liaisoned to ITU to incorporate the necessary extensions? Remember the difficulties we have with IEEE 10G WAN. It calls itself SDH, but it is not SDH (as we know SDH is more than just G.707). And it is already causing confusion among the innocent. And remember "SONET Lite". Here, in IETF, they have the same concern if the name GMPLS is used. GMPLS is more than just extensions.

Some possibilities: at minimum, if IANA assignment is requested by a sdo, the name should at least distinguish it as non-IETF. And in the scope clarify it is outside of the IETF process. Or change the rfc name "informational" as it can be mis-interpreted. In ITU rec'ds, we have appendices which are informational, but they are part of the "ITU process" i.e. reviewed/agreed.

Deborah

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 11:59 AM
To: Brungard, Deborah A, ALABS
Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim;
[email-masked]; [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Deborah,

I suggested earlier that we describe (short) in the draft how we will 
handle liasions
comeing into the IETF with request for changes or requirments related to 
the (g)mpls
protocols. It needs to be understood that the internal IETF process is 
specified for
IDs, and in some way we need bridge that gap. IETF and its working 
groups modifies IDs,
and I don't think it is good idea to start modifying liasions from other 
SDOs.

That we define the liasion process so it becoes crips and clear, and if 
when we are doing
find that it has an impact on the change process, we updte or 
re-organize the the
documents at that time.

Would that work? I guess that the answer is - yes, but only as much 
(little) as needed.

/Loa

Brungard, Deborah A, ALABS wrote:

>Maybe lets go back to my hopefully simple question, will the liaison process be included in this draft or not? I (thought) the answer was no. Maybe best to clarify. And not that it is not important, all the mail agrees it is important. Then we can work from this draft with comments, recognizing the liaison process will be separate, e.g. where the draft discusses other sdos, we can add text to clarify.
>
>One comment on all of this from an ITU/T1X1 history, it is difficult to say apriori how a liaison will be processed. We do not have such a process either. Several ways exist to respond:
>1. simple thank you for the information
>2. here's the answer/clarification based on current work
>3. for a quick answer, at the meeting, have a breakout group to address a proposal
>4. for new work, send a response saying we invite contributions to our future meetings to progress
>   - if no contributions, not anything is done (yes we have done this too)
>   - at the next meeting, send several proposals to the other group for their review
>
>I had understood this draft as including option 4. Other mails are raising the concern, as in the past, if no response to the other sdo, the other sdo can not determine the status of the work. That can be part of the liaison process.
>
>Let's first clarify, do we want this draft to include the liaison process or should we do it separate (in parallel?)?
>
>Deborah
>
>
>
>From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>Sent: Thursday, February 27, 2003 10:47 AM
>To: Kireeti Kompella; Wijnen, Bert (Bert)
>Cc: Scott W Brim; [email-masked]; [email-masked]
>Inline
>>From: Kireeti Kompella [mailto:[email-masked]]
>>Sent: donderdag 27 februari 2003 10:09
>>To: Wijnen, Bert (Bert)
>>Cc: Scott W Brim; [email-masked]; [email-masked]
>>Hi Bert,
>>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote:
>>
>>    
>>
>>>No of course NOT. Many Liasons will want an answer.
>>>So we need a process to follow up and to track if a timely
>>>response has been (or will be) send.
>>>      
>>>
>>Is the IETF process for replying to liaison statements (and of
>>generating them) written down, say in some RFC?  If so, could you
>>send me a pointer?
>>
>>    
>>
>Unfortunately, I don't think the process for that has been defined.
>That is why I said that "we need a process..."
>We do not have it yet (I think... at least I do not know it either).
>I think we were all just hoping people would take responsibility and
>do the right things... but as we know that is how things fall through
>the cracks.
>
>  
>
>>>But the Liasons communication between ITU and CCAMP/MPLS has not
>>>been going smoothly so far (even though we had good intentions).
>>>Responses have not gone out in time (or in some cases at all).
>>>      
>>>
>>I'll take full responsibility for that.
>>
>>    
>>
>W.r.t. CCAMP I will share some of the responsibility too. I should 
>also have kept a better eye on it.
>
>Bert
>  
>
>>Thanks,
>>Kireeti.
>>
>>    
>>
>
>
>
>
>  
>

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Fri, 28 Feb 2003 12:03:25 -0500

Hi,

Very helpful email.  I concur with points 1-6.  Re points (a) and
(b), perhaps the best approach would be to first generate the
material itself.  Discussion of its subsequent subdivision would
be far easier, if there were actual content to work with.

Eve

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Friday, February 28, 2003 11:11 AM
To: [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

All,

I might be stupid, but I actually see some commonality forming on this
thread, though there is much smoke

I think we agree on the following:

1. and most important - we want a productive, trustful and comprehensive
   co-operatiom between IETF and other SDOs
2. the process that describes how this co-operation is handled needs to
   be described
3. we need to have a known, reliable and open (g)mpls technology area
   process for how extend and change the (g)mpls protocols
4. this process also needs to be descirbed
5. that the (g)mpls working groups in the IETF (or maybe the IETF in
   general) [sometimes, often, regulary, a few times] have mismanaged
   incoming liasions from other SDOs

Note 1:
I know that some voices has been raised saying that "the general process
for c-operation between IETF and other SDOs" are not a subject matter for
for the mpls-list. I tend to agree, however one of our ADs made it
appropriate as long as we discuss the coupling between the to processes
above.

We disagree on:

a. whether the two processes needs to go into the same document or not
b. whether documents generated in one process could go seemlessly
   into the other process

I hope we agree on this:

6. that the relationship between IETF and other SDOs are by nature a
   relationship    between equal parties
7. that each organization are entitled to define it own processes,
   methodology and document types

Some personal reflections

- Kireeti and Bert has recognized that here has been less than satifactory
  performanse by the IETF in handling liasions in the past, we will not be
  any wiser if that aregument is repeated
- I don't think it is agood idea to describe the two process in the same
  document. the chnage-process is for our internal use, the liasion process
  is for our commuinication with other SDOs
  (I understand that from the other side this might look pretty much the
   same, but if the only problem is that of how some type of info sent
   from one organisation is received by another, let us solve that problem)
  It must be fairly easy for the sending organization say to the IETF 
"Please,
  handle the content of this liasion as an Internet Draft!" Based on that
  we can publish is as an ID, and include it in our work.
  But if there is written in stone that a liasion is a liasion is a liasion,
  then we will require that other SDOs send us IDs.
- in our internal processes we need documents ofer which we have change 
control
  and therefore it is unsatifactory to use non-IETF documents

Would be good if we could agree on points 1-6 and on a and b, would be far
easier to continue the disucssion.

/Loa

---

From: John Drake <[email-masked]>
Date: Fri, 28 Feb 2003 13:14:31 -0800

I agree with Eric.

As an example, we have call/connection separation, which has been kicking
around since the early days of ISDN.  In discussions as to why it is needed,
the first reason is always "because".  Once past that, I have consistently
heard four or five examples cited.  What is interesting is that all of them
can be handled with the existing Make Before Break component of RSVP-TE. 

Thanks,

John

> Sent: Friday, February 28, 2003 12:54 PM
> To: Varma, Eve L (Eve)
> Cc: [email-masked]'; George Newsome; Stephen Trowbridge; Loa
> Andersson; [email-masked]
> Eve> For individual contributor drafts  coming in, it's quite 
> appropriate to
> Eve> evaluate  requirements and determine  if they  are 
> legitimate.   It's a
> Eve> different case when another  SDO, responsible for a 
> non-IP applications
> Eve> domain, has established a set of requirements related to 
> that domain.
> 
> I'd certainly  disagree with  that.  Many of  the 
> "requirements" I  see from
> other  organizations  are  not   requirements  at  all,  but  
> just  dogmatic
> statements  of connection-oriented  religion.  If  the IETF  
> were  to accept
> requirements from  other organizations, it  would quickly be  
> inundated with
> "requirements"  to make IP  behave exactly  like ATM.   In 
> fact,  anyone who
> works in the PWE3 group can testify that such "requirements" 
> come in all the
> time. 
> 
> 
>

---

From: Scott Bradner <[email-masked]>
Date: Fri, 28 Feb 2003 15:56:59 -0500 (EST)

yipe - go off-line for a long plane flight and kablooe the world 
explodes

You may rest assured that the intention of the ID (and the one that came
out today about change control for RSVP) is positive.

The basic concept is the same as RFC 3427 does for SIP - be sure that the
IETF is "in the loop" on extensions to IETF protocols.  Note that these two
IDs are 1st drafts and are meant to be discussed (that part seems to have
worked :-) )

We have had recent experience with the OIF UNI and ITU ASON documents that
it is easy to get into sort of a mess (and we are not accusing anyone
specific here). There were many reasons.  Including neglected liaison
statements from ITU and documents from ITU folk.  Clearly the IETF needs to
figure out a better way to deal with such messages (This was a topic at the
ITU-T TSAG (their sort of IESG) meeting this past week in geneva.)

So in order to try to regularize the change process with RSVP and (G)MPLS
the SUB-IP ADs with a few WG chairs prepared this document. The idea is
that we define the process so that it is clear how and when various steps
need to be taken and by whom. The doc is far from complete we suspect and
so comments (certainly ones with recommended wording) will be very welcome.
As noted above, these are first drafts and we expect that there will be
quite a few changes before these get adopted.

We also need to evaluate the issues w.r.t. to liaison statements. We think
we have seen quite a set of opinions on the usefulness and function of
liaison statements.  These opinions need to be evaluated and revised text
needs to be put in these documents to deal with them, but maybe this should
be done as a comprehensive IETF review of how we deal with liaison
statements.

It would be good to tone down the "discussion" a bit. We do not think that
making accusations etc helps the discussion.  The idea was to try and
prevent that from happening in the future. 
  
So now that you all have been able to blow of some steam, can you please
start to post constructive text proposals as how to do things in these
documents and relative to how the IETF deals with working with other SDOs
that want to use and extend IETF protocols.  

(BTW - it is not a bad thing that multiple SDOs want to make use of the
same protocols, it seems that it should be considered a good thing and we
should work out ways that using existing protocols or working together on
ways to extend current protocols is encouraged rather than making it more
likely that competing protocols doing the same function get developed.)

Thanks,
Bert and Scott

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 28 Feb 2003 16:10:05 -0800

Hi Folks,

I support the request to stick to constructive comments.

Of course that means avoiding statements like "The
ITU has stepped out of bounds (again).  They deserve to be ignored."
(Last I heard, SDH/OTN networks were within bounds of ITU ;o)

Or "dogmatic statements of connection-oriented  religion" (these
are, for gmpls, connection-oriented networks we're talking about ;0)

Seriously, though, I do have some comments on the draft:

-- the figure shows the only path outside of the IETF process to
be a dustbin.  Hopefully that's not intentional, although a lot
of folks on the list probably believe this ;o)

-- there's some text mixed up in 2.2.1 regarding which mailing list
should be used.

-- we should incorporate Deborah's suggestion for 2.2.2 about having
the decision posted to the mailing list within a specified period  (the
posting of a decision could apply to liaisons, and might have helped
avoid the confusion with the ITU liaison)

-- in 2.2.4, the paragraph after item (2) seems a little premature - 
the recommendation by the rewg presumably must be approved by IESG/IAB
before a decision is made.

-- there is a bit of a loophole in that the problem could be accepted
and farmed off to a WG but there's no check to see if anything is ever
done, and items could easily fall through a crack given the large 
numbers of work items usually in CCAMP and MPLS.  There could be a 
procedure to revisit the decision in case no progress is being made
within some specified timeframe.

-- in general, I hope people keep in mind that the scope of interest
and the resources available in IETF are limited, and should not become a
bottleneck - if work can be or is already being done in other bodies and 
there is a process for IETF to review this work and identify potential
problems or simpler/more general ways to do the desired function,
this should be viewed as a generally positive thing.

Cheers,

Lyndon