RE: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt> (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

[Thomas Walsh <[e-mail]>]

I don’t see a problem with the  IETF process. We should however understand why the ITU-T process failed to reach a consensus or approval.

Draft-betts states  “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”.  This statement from draft-betts isn’t why ITU-T SG 15 failed to approve G.8113.1.  Consensus or approval in ITU-T is decided only by sector members and member states.


The referenced liaison in draft-betts mentions “One of the issues that prevented the approval in SG 15 was the lack of an ACh code point to support this Recommendation.”   One of the reasons?  I read that to mean there were other reasons as well.


IETF could ask SG 15, via liaison,  for more information as to the “other reasons” why the  ITU-T process failed to achieve to achieve a consensus around G.8113.1.



SG 15, admitting they failed in their process to reach approval on G.8113.1, states in the referenced liaison  “Unfortunately the Study Group could not approve this Recommendation so it was forwarded to the WTSA (20-29 November 2012) for approval.”



WTSA is different from SG 15.  I don’t know what will happen there, and whether approval will result.  As of now, consensus/approval was not achieved within the ITU-T process.



My view is IETF should wait at least until there is an approved Recommendation.

Tom Walsh