Subject: Re: [mpls-tp] updated process draft

From: "tom.petch" <[email-masked]>
Date: Fri, 8 May 2009 09:37:06 +0200

Loa

I believe that there are functional issues in this draft that should be
addressed before too much effort is put into the grammar and spelling (something
happy I would be to exercise my English on).

I) Step 1 of the flowchart is described as
"Normal IETF processes will be followed in such cases"
but the only way forward is into step 7 where the MEAD team decides whether or
not to accept the document as a WG item, regardless of which WG this is.  This
is not 'Normal IETF processes'.  Should step 1 lead to a completely separate
'normal' flow through the IETF processes?  I fail to see the point of 1) when
there is 2) where the MEAD team is involved albeit at step 2)

II) The definition of an MPLS-TP document seems to cover any document in which
the letters 'L' 'M' 'P' 'S' 'T' appear in:-) and since it appears to include
everything and anything that the IETF or ITU-T may produce is contradicted by
later sections which have a much narrower scope.  From the rest of this I-D, I
infer that an MPLS-TP document is an I-D which the MEAD team says is an MPLS-TP
document (note I-D, not Recommendation, not RFC nor up to the point of
publication request).  If so, that is fine, but this needs clarifying else this
I-D is not coherent.

III) Step 15 says that once the I-D has been submitted to the IESG for
publication then the ITU-T has no more influence.  I believe that this may
reflect an incomplete understanding of IETF processes.

I know that you know this but just to get on the same hymn sheet ...
After WG Last Call, the document shepherd submits the I-D to the AD with an
accompanying report; this clearly fits step 15).

a) after which, the AD can find fault and return it to the WG for revision and
WG Last Call

b ) after which, IETF Last Call can find fault and have the AD return it to the
WG for revision and WG Last Call

c) after which, the IESG can find fault (the dreaded DISCUSS) and have the AD
return it to the WG for revision and WG Last Call

d) even after which, while in the RFC Editor Queue, the I-D can be called back
for changes if further information comes to light (usually IPR at this stage).

So you are saying that these technical changes are outside the purview of the
ITU-T.  I bet that some of the ITU-T members on this list will want to challenge
this.

I note in this context that Huub said
"> In the ITU-T once a recommendation draft is consented (yes is
> received) then the draft is pre-published.
> The ITU-T editors will than bring the document in a shape
> that is can be officially published, but in this stage no
> technical changes can be made any more, only typographical"

This is not the IETF process; technical changes can occur any time prior to the
RFC appearing, as I have outlined above.  (Once it has appeared, then the
Erratum process takes over).

Do these processes matter?  Well, yes.  An old and wise consultant used to
remind me that there are management solutions to technical problems but never
technical solutions to management problems.  If we fail to agree on the
technicalities of AIS, TCM, E-NNI, MS-PW ...., then the way forward may depend
on a management solution, such as having a process in place.

Tom Petch

----- Original Message -----
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>
Sent: Monday, April 20, 2009 1:22 PM
Subject: [mpls-tp] updated process draft

> All,
>
> I've updated the MPLS-TP draft
>
> http://www.ietf.org/internet-drafts/draft-andersson-mpls-tp-process-01.txt
>
> This draft is still woek in progress, and I'm not sure I intend to
> progress it to wg draft or RFC, nevertheless this document is the
> document that guides how the MPLS-TP drafts are managed-
>
> The document is in need of a grammar and spelling review, anyone that
> wants to undertaken that task is welcome.
>
> /Loa
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Loa Andersson <[email-masked]>
Date: Fri, 15 May 2009 13:32:49 +0200

Tom,

> there is 2) where the MEAD team is involved albeit at step 2)

Well, no there is a a path starting with ind-00 (1) that goes through 
normal wg process and where the wg may poll for a document without
going through the mead team

On the other hand I'm not trying to describe to total process, just the
adaptations we have as a result accepting the proposal in the JWT
report.
> publication request).  If so, that is fine, but this needs clarifying else this

I put a few words to this effect in section 2.2.1
> reflect an incomplete understanding of IETF processes.

I can understand how you are reading the text and will clear it up,
what was intended was that this is the point in the adapted process
described in the where comments from the ITU-T will will considered
separately from other comments received as part of the normal IETF
processes.

I'll try to clarify this, but I won't try to give a description of the
IETF process outside the adaptations of the wg process that the ID
addresses.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
Ericsson ///                                 +46 767 72 92 13 

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]