[mpls] Unsubstantiated Assertions on this Mailing List

[Adrian Farrel <[e-mail]>]

Hi,

I have been discussing some of the emails on this list with the working group
chairs, and we have agreed that I should respond to a couple of points. Don't
feel bad if I didn't pick on something you said: my points apply to all similar
cases.

> Do you forgot that it is in IETF79 plenary in Beijing, the  meeting was closed
before 5
> minutes as it was planed though it was said that itu-t expert can present if
time is
> enough?

I don't think this refers to the plenary meeting, but to the second MPLS working
group meeting.

I don't think we have ITU-T experts attending IETF meetings except by special
invitation. I wasn't aware of any special invitations, so I think this refers to
an IETF participant.

It is worth noting that there were a number of people who asked to present on
their drafts in the IETF meeting, but for which there was not time on the
agenda. The working group chairs constructed the agenda according to the normal
principles focusing on the working group charter, the current working group
drafts, and the topics of discussion on the mailing list that they felt could
most profitably be resolved through face-to-face discussion. There was no
objection to the agenda when it was posted before the meeting; the only
objection came some ten or fifteen minutes into the first of the two sessions
that the WG held. Indeed, this period of objection and discussion of the agenda
used up a considerable amount of time that might have been better used
discussing drafts.

During the interval between the two meetings, I convinced the WG chairs that
they would allow an extra agenda item for one person from a service provider to
present his company's view of MPLS-TP deployment scenarios and requirements if
there was time. Although the meeting ran significantly behind schedule, it
caught up with itself very suddenly, and it is true that the meeting closed
almost exactly five minutes early without the additional presentation. The
chairs judged that by the time the presenter was installed and had his slides
up, he would have had less than four minutes to speak. That would clearly have
been pointless for him and the working group. Therefore, we moved this
presentation to the Routing Area working group where there was sufficient time -
in the end the presentation and questions took twelve minutes. The meeting was
attended by a good number of people who normally participate in the MPLS working
group, so the message was not lost. The presentation attracted a number of
useful questions from people who work at other service providers: something that
would not have been possible within the MPLS working group schedule.

> Do you forgot that IETF ignored ITU-T inputs on some RFCs before approving
 >them as RFCs such as RFC 5921 and draft-ietf-mpls-tp-survivability-framework
> etc?

This is quite a claim!

Let us look at the two documents named here.

== RFC 5921 was originally draft-ietf-mpls-tp-framework ==

2008-11-28 draft-ietf-mpls-tp-framework-00
2009-06-30 draft-ietf-mpls-tp-framework-01
2009-07-10 draft-ietf-mpls-tp-framework-02
2009-08-28 draft-ietf-mpls-tp-framework-03
2009-09-11 draft-ietf-mpls-tp-framework-04
2009-09-25 draft-ietf-mpls-tp-framework-05
2009-20-16 draft-ietf-mpls-tp-framework-06
2009-10-16 Sent to ITU-T for early review (deadline 2009-11-09)
2009-11-10 Review comments received from ITU-T (further
             comments promised by 2009-11-25) (For action deadline
             2010-01-02)
2009-12-22 draft-ietf-mpls-tp-framework-07
2010-01-12 Response to ITU-T noting that no specific action was
            requested, and that no further comments had been
            received. Promise to consider all review comments.
2010-01-22 draft-ietf-mpls-tp-framework-08
2010-01-29 draft-ietf-mpls-tp-framework-09
2010-02-04 draft-ietf-mpls-tp-framework-10
2010-02-04 Sent to ITU-T for review during WG last call.
           (deadline 2010-03-05 - twice the normal WG review period)  
2010-02-05 Response to 2009-11-10 comments sent to ITU-T
2010-03-05 Review comments received from ITU-T (For action
           deadline 2010-04-12)
2010-04-02 draft-ietf-mpls-tp-framework-11
2010-04-03 Sent to ITU-T for review during second WG last call.
           Last call strictly limited to discussion of resolution of issues
           raised in previous last call. (deadline 2010-04-17)s
2010-04-06 Response to 2010-04-12 comments sent to ITU-T
2010-04-07 IETF last call starts
2010-04-19 Review comments received from ITU-T (For action
           deadline 2010-05-27)
2010-04-21 IETF last call completes
2010-05-05 draft-ietf-mpls-tp-framework-12
2010-05-06 IESG evaluation starts
2010-05-20 IESG telechat
2010-05-24 Document approved for publication as RFC
2010-06-24 Spontaneous further review from ITU-T
           (For action deadline 2010-07-30)
2010-07-09 RFC 5921 published
2010-07-27 Response to 2010-07-27 review comments
           Minor comments that were previously communicated 
           informally had already been accepted during RFC Editing.
           Major comment were too late for acceptance.
           Correct way forward explained.
2010-08-31 draft-ietf-mpls-tp-nni-uni-00
2010-11-03 Sent to ITU-T for review during WG last call of
           draft-ietf-mpls-tp-uni-nni. (deadline 2010-11-23)
2010-11-26 draft-ietf-mpls-tp-nni-uni-01 (including change
          that will be requested in 2010-12-03 review)
2010-12-03 Review comments received from ITU-T. Only
           one minor typographical issue. (For action 2011-01-14)
2010-12-08 draft-ietf-mpls-tp-nni-uni-02
2010-12-09 IETF last call starts
2010-12-23 IETF last call ends
2011-01-07 draft-ietf-mpls-tp-nni-uni-03
2011-01-07 IESG evaluation starts
2011-01-15 Response to 2010-12-03 review comments.

Looking at the timeline and results here, I cannot say that either SDO was
absolutely perfect in its adherence to dates or provision of the most useful
information that is possible. However, it also appears to me that the right
technical result has been achieved to the agreement of all parties. I find it
simply ridiculous to suggest that the processing of this document somehow
constitutes an attempt by the IETF to disregard ITU-T input. Instead, it
suggests to me that the IETF is very willing to listen to the input and to make
the necessary changes. 

== draft-ietf-mpls-tp-survivability-framework ==

* Full disclosure: I am an author of this document

2009-04-06 draft-ietf-mpls-tp-survive-fwk-00
2009-10-25 draft-ietf-mpls-tp-survive-fwk-01
2009-10-25 draft-ietf-mpls-tp-survive-fwk-02
2009-10-26 Sent to ITU-T for early review (deadline 2010-11-21)
2009-11-09 draft-ietf-mpls-tp-survive-fwk-03
2009-11-18 Review comments received from ITU-T (For action
               deadline 2010-04-30)
2010-03-08 draft-ietf-mpls-tp-survive-fwk-04
2010-03-10 Sent to ITU-T for review during WG last call
              (deadline 2010-04-02)
2010-03-10 Disposition of 2009-11-18 review comments
2010-04-12 Review comments received from ITU-T (For action
               deadline 2010-04-25)
2010-04-19 draft-ietf-mpls-tp-survive-fwk-05
2010-04-21 Sent to ITU-T for review during WG last call
              (deadline 2010-05-05)
2010-04-22 IETF last call starts
2010-05-05 Review comments received from ITU-T (For action
               deadline 2010-05-28)
2010-05-06 IETF last call ends
2010-06-04 Disposition of 2010-05-05 review comments
2010-06-20 draft-ietf-mpls-tp-survive-fwk-06
2010-06-24 IESG evaluation starts
2010-06-30 Spontaneous further review from ITU-T
           (For action deadline 2010-07-30)
2010-07-01 Document approved for publication as RFC
2010-07-01 Publication held by Area Director pending 
           examination of 2010-06-30 review comments
2010-07-13 Document approved for publication as RFC
2010-07-16 Disposition of 2010-06-30 review comments
            Minor comments are largely already addressed or
            taken as changes in RFC Editor note. Major 
           changes are too late and advice on how to proceed
            is given.
2010-07-22 ITU-T states no plan for further review and no
            plans to review disposition of 2010-07-16. (For action
            deadline 2010-08-31 but no action requested in the
            liaison)

Again, the process was long, and the flow of information detailed. Again, the
majority of input came very late in the process (some of it too late). Again,
the IETF did what it could to speed the process as requested. Again, the IETF
took on board review comments that would normally have been considered to have
arrived too late.

In these two cases, I have done the leg-work to collect the data and supply the
details around the claims that were made. I find the necessity to "prove
innocence" irksome, and the presence of unsubstantiated allegations on the
mailing list offensive. Next time anyone wants to make a claim like this, could
they please supply the details to back up their claims.

Please note that the ITU-T experts participating in the reviews in the ITU-T did
not bring their comments to the IETF as individuals for discussion on the
mailing list despite many of them being subscribed. One might draw the
conclusion that, rather than participating in the development of MPLS-TP within
the IETF using the normal IETF process, these individuals were waiting until the
last possible minute to raise their concerns and attempting to do so using the
weight of the ITU-T rather than their own technical arguments - of course, I do
not draw any such conclusions.

>  I am wondering whether IETF have already break the JWT agreement or not?

If anyone wants to "wonder" this in public, they have an absolute responsibility
to provide examples. IMHO the IETF has "gone the extra mile" by allowing
comments outside the normal process, accepting comments via liaison from people
who are normal WG participants, and by attempting to speed up the IETF process
in order to achieve more rapid delivery as requested. As yet, I have seen no
credible evidence provided that the IETF has broken the JWT agreement, and I
find unsubstantiated suggestions that this has happen to be misleading.

> It is right to accuse ITU-T on standardize G.tpoam in the liaison text with
agreement. 

I have trouble parsing this sentence, but I think it is objecting to liaison
text that says that the inclusion of protocol-specific text in a draft MPLS-TP
Recommendation appears to be in violation of an agreement to carry out all
MPLS-TP development within the IETF using normal IETF processes. To evaluate
this, we must observe that SG15 agreed in plenary session (
http://www.itu.int/md/T09-SG15-R-0004/en) to accept the recommendations of the
JWT that IETF development would be done in the IETF following normal IETF
process. There may be many different personal opinions about where protocol
development should be done, but it is hard to argue with the fact of the
agreement.

> We have already violated our commitments under the JWT agreement
> multiple times

This is an opinion, but there is no substance provided. I note that the author
counts himself as part of the problem, but does not say exactly what he did
wrong. This type of statement is not helpful to reasoned discussion.
  
> The LS is now stating that although the IETF is not commited to 
> deliver to ITU-T what it was promised in the JWT agreement

This is also an opinion, but I can find nothing in the LS that makes any such
statement. Instead of the assertion, it would have been really helpful if the
poster had pointed to the specific text that was a problem.  To the contrary,
the liaison makes a specific statement of commitment to the development of
MPLS-TP.

- - - - - -

Now, I am quite happy that people should discuss the workings of the MPLS
working group and the IETF in general (so far as it impacts on the MPLS working
group) on either of the MPLS working group's mailing lists (mpls or mpls-tp).
But I am not happy that history and facts are misrepresented by accident or on
purpose. 

Therefore, I call on everyone on the mailing list to carefully check their facts
and substantiate their arguments before posting to the list. There is no reason
why discussions of process should be subject to any less technical rigour than
discussions of technical issues.

Likewise, I call on all people with an interest in MPLS-TP to participate in the
technical discussions on the mailing list. Objections to working group documents
are valid and welcome, but they must be reasoned technical discussions: there is
no point in saying "I prefer X", you need to say "Y is broken because..." I also
request that these discussions take place as early in the cycle as possible:
coming with a technical opinion at the time of working group last call is at
best a frustration to everyone concerned, but may also be interpreted poorly
when the comments come from someone who is subscribed to the mailing list and
has a known strong interest in the technology.

Thank you,
Adrian (as AD)