Re: ITU-T SG15 comments on draft-ietf-ccamp-transport-lmp-00.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Ben,

[Some gratuitous snipping, throughout]

> > You are right. The liaison appears to state that there were some
> > comments on the draft made at the meeting which have not been
> > included in the liaison. I wonder why this would be?

> The liaison was submitted late to the SG15 meeting, 2 working days
> instead of the normal 7 (note the IETF's limit is 10), not giving
> participants sufficient time to read/review it.  Thus it was not
> possible to provide a liaison with a complete set of comments.  It was
> decided that there would be value in discussing the draft and
> communicating some comments nonetheless.

Agreed. It came late, and that made it hard for folks to read it. All
comments partial or full are welcome.

> > You say that...
> > > Just trying to answer the comments/questions that were recorded
> > > in the liaison would seem to be inadequate to meet the stated goal
> > > of the draft.
> >
> > Well, what can I say?
> > The intention of liaising this draft to SG15 was to allow people who
> > had not previously seen the draft (which has been around for a while
> > in the public domain)
>
> Yes, since September as a WG draft.

That's true.
And as a personal draft for about 18 months before that.

> > Had the liaison said "We are very concerned that there is a
> > significant mismatch in terminology in this draft and believe
> > that it should not be published without further face-to-face
> > discussions", this would have been a very significant issue. I
> > would, of course, have asked for some examples so that we
> > could qualify the problem. If the liaison had said "There
> > appears to be a major disconnect on the following terms..."
> > we would obviously have worked to resolve the disconnect
> > and welcomed face-to-face meetings as necessary.

> Well, I think the liaison was meant to convey something along
> those lines, albeit not in those words.

That's helpful. Thanks.

Would you say that the list of terms over which there is a disconnect is
limited to those explicitly mentioned in the liaison, or are there other
terms that we should bring into the discussion? Although other things
might come up in the course of discussions, it would be good to get as
much into the open now as is possible.

> > But the liaison hints (as you say) that there may be other issues that
> > are not mentioned in the liaison. So perhaps I can ask everyone to
> > think very hard and let me (or preferably the CCAMP mailing list)
> > know what those issues are.
>
> I presume the reason for providing a liaison to the ITU is that not all
> members of the ITU participate in the CCAMP mailing list, and if
> they do they cannot speak for the ITU, so there may be a problem
> with this process.

You're right that the purpose of the liaison is to give individuals who
participate in the ITU-T but not CCAMP to see the material and comment on
it. There are several ways that they can return their comments, one of
which is a return liaison, but this is not the only way - comments may be
returned to the authors, to the CCAMP chairs or to the CCAMP mailing list.
I believe I explained these options in Geneva.

In fact, what we really want is a host of contributions from everyone who
has an opinion. It is certainly useful to have "the view of the ITU", but
we are just as concerned to have individual contributions. So no-one
should hold up or mitigate their views waiting for ITU-T consensus.

> > The liaison also suggests that time at a future Q14/15 meeting
> > could be given over to align the views on terminology to facilitate
> > future progress. This certainly does not imply to me that there are
> > any issues in the current draft (beyond those raised in the current
> > liaison) that need to be addressed before the draft is published.

> Well, if the I-D purports to provide "an
>  overview of LMP in the context of the ITU-T Automatically Switched
>  Optical Networks (ASON) and transport network terminology and
>  relates it to the ITU-T discovery work to promote a common
>   understanding for progressing the work of IETF and ITU-T."
> then I would think that publishing it before reaching a common
> understanding would be counter to the purpose.

I agree on the your representation of the aims.
So back to my previous question, are there any specific issues beyond
those raised in the current liaison that need to be addressed? It's fine
if the answer is "None have been identified, but we're feeling really
uneasy about the draft."

> > I hope you don't think I'm being difficult, but when communications
> > are reduced to formal liaisons we must take the liaisons at face
value.
> > So I would urge (again) that anyone who has any issues with the
current
> > draft (or any CCAMP draft) should bring those issues to me or
> > (preferably) to the CCAMP mailing list without delay. If issues are
> > raised I will do my best to ensure that they are resolved.

> I am not trying to be difficult either.

Accepted.

> I think the difficulty arises
> from attempting to rush to publish the I-D.  If the liaison had been
> sent with sufficient time to review, a more complete response could
> have been given.

One man's rush is another man's delay, but I accept that greater time
might have generated a more thorough response.

> Even so, the need for further discussion has been
> identified, and I agree that a face-to-face meeting would be much more
> efficient than limiting the exchange to formal liaisons.  (In fact
> achieving common understanding may be more in the process than in the
> paper.)

Two points here.
1. The need for further discussion has not really been identified. I would
like to push for further details of what it is that needs discussion.
Let's look at this as "setting the agenda for the meeting."
2. I agree that face-to-face meetings are much more productive: this is
one of the reasons why I have attended all of the Q14/15 meetings in the
last year. On the other hand, turning up unprepared at an unplanned and
free-ranging discussion is also not hugely efficient. So let's expose the
issues for discussion now.

Happy Christmas,
Adrian