Re: [Mpls-interop] moving mpls-tp documents - you are supposed torespond

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

> draft-andersson-mpls-tp-oam-def       (accept as a MEAD team doc?)

Yes. But will need significantly more work once accepted.

> draft-beller-mpls-tp-gach-dcn       (accept as a MEAD team doc?)

Yes. Addresses a requirement. But will need some more details once accepted.
(I am a co-author)

> draft-boutros-mpls-tp-cv              (accept as a MEAD team doc?)

Not oposed.
I have some confusion about the control plane aspects of this draft.

> draft-boutros-mpls-tp-fault           (accept as a MEAD team doc?)

No, not yet.
This I-D is quite significantly different from the way faults are handled 
and notified in GMPLS (the candidate control plane) and some convergence is 
desirable.

> draft-boutros-mpls-tp-loopback       (comments and review need!)

No, not yet.
I do not see that the requirements for this work are present in the OAM 
requirements.

> draft-boutros-mpls-tp-performance     (accept as a MEAD team doc?)

No, not yet.
The OAM requirements for performance measurement and reporting do not have 
consensus (IMHO).

> draft-bryant-mpls-tp-ach-tlv          (accept as a MEAD team doc?)

I am wary of a document that defines specific TLVs without describing their 
use. Indeed this use is defered to other documents without reference. This 
means that specific TLVs may be being created without a valid use, or in a 
format that cannot be used.

Better to move the definition of the TLV structure, the IANA registry, and 
the Null TLV into [GAL-GACH] and to move the definition of the specific TLVs 
into their own I-Ds.

If that happens, this I-D should be deleted.

> draft-busi-mpls-tp-oam-framework (update based on Ipswich discussion!)

Yes, but only after updates are submitted.

> draft-gray-mpls-tp-nm-req (accept as a wg doc!)

Yes, but only after Ipswich updates are submitted.

> draft-ietf-mpls-tp-framework
> (prepare for a wg last call, after the
>   tp-requirements are wg last called)

Believe this would be very premature.
The f/w cannot describe many of the MPLS-TP functions as they have not been 
developed yet.
We should keep updating this document until the MPLS-TP scenery is in focus.

> draft-ietf-mpls-tp-oam-requirements   (we need to get existing comments
>                                        written down, we will allow until
>                                        Friday Jan 30 to do this, after
>                                        that we'll prepare the doc for wg
>                                        last call)

Sorry, is this a last call for comments that need to be in before a last 
call for comments can be issued?

> draft-ietf-mpls-tp-requirements       (prepare for wg last call)

Agree, but will need substantial input from ITU before last call.

> draft-martinotti-mpls-tp-interworking (accept as a MEAD team doc?)

No, not yet.
I do not believe that many of these scenarios are within scope.
We are (still!) waiting for a set of deployment scenarios from the ITU.

> draft-sprecher-mpls-tp-oam-analysis   (update as soon as the
>                                        oam-requirements are stable)

Agreed. Work in progress.

> draft-sprecher-mpls-tp-survive-fwk    (document has expired and should
>                                        be republished)

In hand.

> draft-yang-mpls-tp-ring-protection-analysis
>                             (accept as a MEAD team doc?)

No.
Useful background material and input to draft-sprecher-mpls-tp-survive-fwk, 
but not needed as an RFC.

> As a member of the MEAD team you are expected to respond to the
> "accept as a MEAD team doc"?

I did.

> As a a MEAD team member you are expected to supply your comments on
> draft-ietf-mpls-tp-oam-requirements on Fri Jan 30, the latest.

I will.

> As an editor you are supposed to take the action (when the time is
> right) for the other document.

I plan to.

Adrian 

_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop