[mpls-tp] Uncoordinated Protocl Development Considered Harmful Draft

["Adrian Farrel" <[e-mail]>]

Hi,

The correct place for this discussion is not here.

draft-iab-mpls-tp-uncoord-harmful is an IAB document and if you want to 
change what it says you need to discuss it with the IAB. Discussions on this 
list will have zero impact on the document.

I believe (having discussed this work with the IAB) that the issue they are 
trying to address is about the future. They want to ensure that future 
protocol development of overlapping or identical protocol families is 
coordinated between SDOs. Part of ensuring that is to show what might go 
wrong. Another part is to show how the issue can be avoided.

Adrian
----- Original Message ----- 
From: "Rolf Winter" <[e-mail]>
To: "tom.petch" <[e-mail]>; "Adrian Farrel" 
<[e-mail]>; "Loa Andersson" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, July 23, 2009 8:15 AM
Subject: RE: [mpls-tp] poll to makedraft-andersson-mpls-tp-process-03.txt 
aworking group document


Hi,

There is an alternative for this draft I believe, at least for its content. 
The IAB seems to be in love with how the whole MPLS-TP process is working 
(http://tools.ietf.org/html/draft-iab-mpls-tp-uncoord-harmful). Good for 
them but they fail to mention how the overall process is working in 
practice. I'd propose to merge the two. I fail to see why we need a document 
that praises the process and another one describing it.

Best,

Rolf


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London 
W3 6BL | Registered in England 2832014


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of tom.petch
> Sent: Mittwoch, 22. Juli 2009 18:23
> To: Adrian Farrel; Loa Andersson
> Cc: [e-mail]
> Subject: Re: [mpls-tp] poll to makedraft-andersson-mpls-tp-process-
> 03.txt aworking group document
>
> ----- Original Message -----
> From: "Adrian Farrel" <[e-mail]>
> To: "tom.petch" <[e-mail]>; "Loa Andersson" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Saturday, July 18, 2009 10:59 PM
> Subject: Re: poll to makedraft-andersson-mpls-tp-process-03.txt a
> working group
> document
>
> > Since the thread appears to have died down (with the consensus call
> for
> > adoption) I just wanted to chime in on a couple of matters of process.
> >
> > Tom responded to Loa...
> >
> > >> My take has been (and still is) that we (as a working group or
> group of
> > >> working groups)
> > >
> > > Um.  mpls-tp has a mailing list for discussion but is not a Working
> Group,
> > > of
> > > the IETF or anything else; yes?
> > >
> > > I had thought that mpls-tp was a Working Group, looked for a
> Charter,
> > > found
> > > there wasn't one, looked for a slot in an IETF agenda, no joy and
> have now
> > > worked out that it is not a Working Group per se.
> > >
> > > This does make a difference to the interpretation of this process
> draft,
> > > which
> > > makes many references to Working Groups so I think that this point
> needs
> > > spelling out in it.
> >
> > So, what is happening is that it has been recognised that MPLS-TP is
> a topic
> > that spans multiple working groups. It was decided to not charter a
> separate
> > working group because the overlap was considerable. However, a
> separate
> > mailing list was created because:
> > - It meant that all of the work could be followed in one place
> >   without having to monitor three mailing lists.
> > - It allows people in the relevant WGs who are not
> >   interested in MPLS-TP to avoind being swamped.
> >
> > We (the ADs and chairs) agreed that consensus calls should be made
> across
> > all of the relevant working groups, but judged only on the MPLS-TP
> mailing
> > list.
> >
> > When an I-D is adtoped as a working group document, it is adopted by
> a
> > specific working group (in this case by the MPLS working group).
>
> I think that more of this needs spelling out in the process document
> (once the
> process allows updates to occur:-).
>
> I had gathered most of it but only at the time of IETF74, despite
> having joined this list at the start (and being already on, eg, MPLS
> and CCAMP
> lists). I had failed to understand parts of the process document - as
> some of my
> comments showed - through ignorance of the nature of 'mpls-tp' within
> the IETF.
>
> And ...
>
> >
> > Tom also wrote:
> >
> > > After Working Group Last Call, in most IETF Working Groups, a
> document
> > > is produced by a Document Shepherd, which may provoke further WG
> > > discussion and perhaps another WG Last Call, an AD review, which
> may
> > > provoke further discussion etc, an IETF Last Call, which may
> provoke
> > > further
> > > discussion etc and only then does it go to the IESG, which may
> provoke
> > > further discussion etc.
> >
> > I think you are slightly out with this.
> > After WG last call, the I-D is updated to address the WG comments.The
> WG
> > chiars then make a judgement on whether a further WG last call is
> needed.
> > Only once this cycle has completed does the Document Shepherd get
> involved.
> > Her job is simply to perform the write-up for the AD.
>
> ... yes; and I have seen the write-up by a Document Shepherd posted to
> a list
> and cause a discussion that questioned whether or not the I-D should
> proceed to
> become an RFC at all: these things happen:-)
>
> The generic issue, which the process I-D does not seem to be clear on,
> is
> whether, when an I-D is returned to a WG for further revision, perhaps
> further
> Working Last Calls, the ITU-T still receives the same liaisons and
> opportunities
> to accept or reject the changes.
>
> Again, something to raise when the I-D re-appears.
>
> Tom Petch
>
>  > Cheers,
> > Adrian
>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp