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

From: Loa Andersson <[email-masked]>
Date: Sat, 01 Mar 2003 16:36:07 +0100

Lyndon,

thanks - it looks like we are making progress - some questions/inline.

Ong, Lyndon wrote:

>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)
>
could you specify which path(s)

>
>
>-- there's some text mixed up in 2.2.1 regarding which mailing list
>should be used.
>
specific please - I intended to say the area list of the wg that 
specified the protocol,
can't see the mix up

>
>
>-- 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)
>
I clearly sympatize with this, but since all decisions in the change
process are taken by I*, with the exception of the initial of being
where ADs and wg chairs, decides on whether to request chartiering the
req evaluation, are controlled by the I*, I think it is outside scope of
draft to specify how and when. It has been my assumption that this is
within the I* domain

>
>
>-- 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.
>
OK, can see this - would this be feasible

   If IESG/IAB approves of a recommendation according to cases 1 & 2 the 
   IETF will not publish an RFC that attempts to get around the decision.

I complicates the flow chart a bit, but will be manageable, I can always
ask Bala to help ;)

>
>
>-- 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.
>
no I htink tht this is not a loop hole - there is no way ever where you can
"farm a problem out" and expect the wg to do your job for you,  ti requires
youra active participation, IETF  is a community of co-workers not an
agency that takes assignments - every time you bring something in to the
IETF youd don't say "Here is something YOU should do while I go about 
minding
my own business", instead you should say "Here is something I think WE 
should do".

>
>
>-- 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.
>

agreed - that is why all the 4 bullets were insluded, and yes I agree as
long as the architecural issues and the safe guarding of opertional aspects
the Inernet are respected, but on the other hand bringing something to the
IETF and not being prepared to work on it is likely to create a "bottleneck"

>Cheers,
>Lyndon

---

From: [email-masked]
Date: Sat, 01 Mar 2003 19:18:26 +0100

all,

some additional comments and input:

1) on 2.2.1. Initiating changes or extensions to
(G)MPLS protocols

imho it would be helpful that the requesting i-d 
provides a clear demarcation about the complexity
handling (in a sense this will help in evaluating
in case of interesting topic is this can be handled
in a timely manner) and would also avoid over-
engineering (gmpls doesn't mean "universal" mpls) 

2) what about the use of the summay I-d as proposed
two years ago see also:

ftp://subip.ietf.org/pub/lists/2001/idsummary.0105

i think that a re-use of this template may help in
the global process (in particular if this might be
used as first section of such a document, it may 
also happen that the topic may cross several working 
groups or even areas, wouldn't be thus useful to 
have an overview of the impact(ed) protocol wrt 
(g)mpls and related

3) this step should also include a clear evaluation 
of the impact on the global internet architecture -
and founder principles

imho the security issues (see 2.2.1) should be part 
of this (this would imho help in having responsible
ietf'ers and avoid the i-d dropping syndrom)

4) on 2.2.4 Point 1 might be useful for the requestor
to have a bit more insight here (not more than just
using a list of references)

5) when it is said 2.2.4 Point 2 "not a general 
enough one" what this "general" word means is it
in the "common" ccamp sense (so "generalized") or
is it in the sense "not widely used" for instance
or even both for instance using the above termino
"mp2mp" is a general problem not widely used (as
per today)

thanks,
- dimitri.

---

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491