Snipped, comments inline.
3. There seems to be quite a feeling on the mailing lists that this document
should be run through the MPLS working group. The write-up makes a case for
progressing it as AD sponsored. As far as I can see, the main assertions to
answer are as follows. Do you have a view on these points before I make a
decision on what to do?
a. This is a proposal to use an MPLS code point and so is part of MPLS by
definition.
b. The type of network being managed by the OAM described in G.8113.1 is an MPLS
network. Therefore, this is clearly relevant to the MPLS working .
Do you object to this going through the MPLS on principle, or were you just
hoping to save the WG the work? If the latter, and if the WG wants to look at
the draft, the easiest approach seems to be to redirect the work to the working
group.
[MB] G.8113.1 supports a subset of the functions defined in
draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the
draft was presented at several meetings in 2009 and early 2010 and had
extensive discussion on the MPLS mailing list. However, the MPLS WG have, by
rough consensus, adopted a different approach. Therefore, further review by
the MPLS WG is of little value.
[JD] Um, I don't think so.
Since, as you state above, G.8113.1 is effectively draft-bhh and since
draft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a
code point for G.8113.1, is basically an attempt to subvert the decision by the
MPLS WG to reject draft-bhh by attempting to bypass the WG with an individual
submission.
So, I think it is clear that your draft belongs in the MPLS WG.
Incidentally, the MPLS/GMPLS change process was put in place in reaction to the
publication of another individual submission, RFC3474, which was completely
non-interoperable with standard RSVP, a surprisingly similar situation.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf