Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)
RFC 6671

Note: This ballot was opened for revision 04 and is now closed.

(Adrian Farrel) Yes

Barry Leiba No Objection

(Ron Bonica) Abstain

Comment (2012-05-09)
No email
send info
As others have said, the specification of multiple OAM mechanisms for MPLS-TP does not benefit the community. However, I will not block publication of this draft.

(Stewart Bryant) (was Discuss) Abstain

Comment (2012-05-10)
No email
send info
This document states that:

"A number of experts in the IETF do not consider that the development or deployment of a second protocol solution within the same architectural problem space is necessary or advisable" and cites draft-sprecher-mpls-tp-oam-considerations.

draft-sprecher-mpls-tp-oam-considerations provides many engineering reasons why the deployment of a second MPLS-TP OAM is undesirable.

If  G.8113.1 were an IETF document I would have entered a Discuss on this enabling document. However, I believe that it is in the best interests of the IETF that this decision be deferred to the  government officials charged with the responsibility for the approval or rejection of ITU-T Recommendation G.8113.1 itself. I request that in applying their wisdom to this difficult problem, these government officials do due diligence to the engineering consequences of their actions. 

I have thus entered an abstain.

(Gonzalo Camarillo) Abstain

(Benoît Claise) Abstain

Comment (2012-05-10)
No email
send info
The experts believe that multiple OAM protocols for MPLS-TP is undesirable for interoperability, and I agree with that.
However, I do not think it is in the best interest of the IETF to  block the allocation of the code point for ITU-T Recommendation G.8113.1.

(Ralph Droms) Abstain

Comment (2012-05-09)
No email
send info
I agree with the experts in the IETF cited in this document and with
the conclusion reached in other documents that it would be desirable
to have only one MPLS-TP OAM protocol.  Therefore, in my opinion, a
new G-ACh Type should not be assigned for "G.8113.1 OAM" as requested
in this document.  However, I will not block its publication and I
have entered an Abstain position.

(Wesley Eddy) Abstain

Comment (2012-05-09)
No email
send info
In the IANA considerations where the value 0x8902 is suggested, it would probably be good to note that the rationale is to be consistent with the EtherType for Y.1731.  If that value does get assigned, I think it would be good to have record of why such a seemingly odd value was picked since there are several earlier blocks of unassigned values.

I agree with other ADs that the IETF participants have not expressed a favorable consensus for making an allocation permitting multiple OAM types.

(Stephen Farrell) Abstain

Comment (2012-05-08)
No email
send info
(This is an agreed text between the two security ADs, in case there's a concern
its a cut'n'paste error.)

While the IETF can't dictate the contents of G.8113.1, it appears that ITU SG15
did approve the contents of RFC 5586 and in that RFC it requires that relevant
associated channel type specification include security considerations.  The
latest version of G.8113.1 available to me does not include a security
considerations section.  It's unclear why G.8113.1 doesn't include the agreed to
section.

If G.8113.1 was an IETF draft, I would have entered this as a Discuss because
G.8113.1 does not meet the requirements of RFC 5586 (nor RFC 2223).  Further, as
there are two OAM solutions I consider the one that does address security
considerations to be the superior solution.  In addition, experience in the
Security Area has shown developing two standards for the same thing is damaging
and that that damage persists in the long term, so I believe that the current
situation with two OAM solutions represents a bad outcome.

However, I do not think it is in the best interest of the IETF to block the
allocation of the code point for ITU-T Recommendation G.8113.1 based on this
point.

(Brian Haberman) (was No Record, No Objection) Abstain

(Russ Housley) Abstain

Comment (2012-05-07)
No email
send info
  I believe that multiple OAM protocols for MPLS-TP is undesirable;
  however, I do not think it is in the best interest of the IETF to
  block the allocation of the code point for ITU-T Recommendation
  G.8113.1.

(Pete Resnick) Abstain

Comment (2012-05-08)
No email
send info
We have a situation here where we are being asked for IETF-wide approval of a code point allocation for a protocol that we have never seen, and a protocol that the present document says "a number of experts in the IETF" think is not "advisable". Though there was minimal objection during IETF Last Call, I'm not completely convinced we would have considered this "in the rough" part of the rough consensus under normal circumstances. However, I think calling it "rough consensus" can be justified, and therefore I'm uninclined to argue about it further. That said, I abstain.

(Robert Sparks) Abstain

Comment (2012-05-09)
No email
send info
I don't believe what this code point represents is in the best interest of the Internet, but also don't believe further changes to this document will improve the situation so I am abstaining.

(Martin Stiemerling) Abstain

(Sean Turner) Abstain

Comment (2012-05-07)
No email
send info
While the IETF can't dictate the contents of G.8113.1, it appears that ITU SG15 did approve the contents of RFC 5586 and in that RFC it requires that relevant associated channel type specification include security considerations.  The latest version of G.8113.1 available to me does not include a security considerations section.  It's unclear why G.8113.1 doesn't include the agreed to section.

If G.8113.1 was an IETF draft, I would have entered this as a Discuss because G.8113.1 does not meet the requirements of RFC 5586 (nor RFC 2223).  Further, as there are two OAM solutions I consider the one that does address security considerations to be the superior solution.  In addition, experience in the Security Area has shown developing two standards for the same thing is damaging and that that damage persists in the long term, so I believe that the current situation with two OAM solutions represents a bad outcome.

However, I do not think it is in the best interest of the IETF to block the allocation of the code point for ITU-T Recommendation G.8113.1 based on this point.