I support the allocation of an ACH codepoint to G.8113.1.
For G.8113.1 had reached the technical and industry maturity to be assigned a code point, the codepoint allocation from IETF should allow the ITU-T to progress refinements to G.8113.1 such that it could satisfy all the functional requirements defined in RFC 5860.
-----????? ??????-----
???: ext Ross Callon
????: 13/03/2012, 19:27
??: Andrew G. Malis; Sprecher, Nurit (NSN - IL/Hod HaSharon)
????: ietf@xxxxxxxx
????: RE: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC
I agree that the allocation of a code point should be to a specific version of 8113.1, and specifically should be to the final version that is approved by the ITU-T (assuming that a final version of 8113.1 will be approved by the ITU-T). This would imply that draft-betts-itu-oam-ach-code-point should contain a normative reference to the final approved version of 8113.1.
???: ext Ross Callon
????: 13/03/2012, 19:27
??: Andrew G. Malis; Sprecher, Nurit (NSN - IL/Hod HaSharon)
????: ietf@xxxxxxxx
????: RE: Last Call:<draft-betts-itu-oam-ach-code-point-03.txt>(Allocationof an Associated Channel Code Point for Use byITU-T Ethernetbased OAM) to Informational RFC
I agree that the allocation of a code point should be to a specific version of 8113.1, and specifically should be to the final version that is approved by the ITU-T (assuming that a final version of 8113.1 will be approved by the ITU-T). This would imply that draft-betts-itu-oam-ach-code-point should contain a normative reference to the final approved version of 8113.1.
Given normal IETF processes, this implies that the final RFC resulting from draft-betts-itu-oam-ach-code-point could be published as soon as the final version of 8113.1 is approved (with the understanding that there will be a small normal delay between "approved" and "published" which gives time for coordination). Given that the final version of 8113.1 might need to reference the RFC resulting from draft-betts-itu-oam-ach-code-point, a bit of cooperation might be needed between editorial staff at the ITU and RFC editorial staff, but I don't see why this should be a problem (I am sure that they all have access to email).
Ross