Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)
draft-betts-itu-oam-ach-code-point-04
Yes
(Adrian Farrel)
No Objection
(Barry Leiba)
Abstain
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
Note: This ballot was opened for revision 04 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
()
Unknown
Benoît Claise Former IESG member
Abstain
Abstain
(2012-05-10)
Unknown
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.
Brian Haberman Former IESG member
(was No Record, No Objection)
Abstain
Abstain
()
Unknown
Gonzalo Camarillo Former IESG member
Abstain
Abstain
()
Unknown
Martin Stiemerling Former IESG member
Abstain
Abstain
()
Unknown
Pete Resnick Former IESG member
Abstain
Abstain
(2012-05-08)
Unknown
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.
Ralph Droms Former IESG member
Abstain
Abstain
(2012-05-09)
Unknown
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.
Robert Sparks Former IESG member
Abstain
Abstain
(2012-05-09)
Unknown
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.
Ron Bonica Former IESG member
Abstain
Abstain
(2012-05-09)
Unknown
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.
Russ Housley Former IESG member
Abstain
Abstain
(2012-05-07)
Unknown
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.
Sean Turner Former IESG member
Abstain
Abstain
(2012-05-07)
Unknown
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.
Stephen Farrell Former IESG member
Abstain
Abstain
(2012-05-08)
Unknown
(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.
Stewart Bryant Former IESG member
(was Discuss)
Abstain
Abstain
(2012-05-10)
Unknown
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.
Wesley Eddy Former IESG member
Abstain
Abstain
(2012-05-09)
Unknown
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.