RE: FW: LastCall:draft-betts-itu-oam-ach-code-point-03.txt(Allocationofan Associated Channel Code Point for Use byITU-T Ethernetbased OAM) toInformational RFC
We certainly have running code, widely deployed (although my request on the MPLS list as to which manufacturers' boxes were involved never did get answered:-( Hope these help: http://tools.ietf.org/html/draft-fang-mpls-tp-oam-considerations http://www.eantc.com/fileadmin/eantc/downloads/events/2007-2010/CEWC09/EANTC-CEWC2009-WhitePaper-v1_2.pdf Regards, Rui -Original Message- From: t.petch [mailto:daedu...@btconnect.com] Sent: sexta-feira, 23 de Março de 2012 09:58 To: Alia Atlas; Rui Costa Cc: ietf@ietf.org Subject: Re: FW: LastCall:draft-betts-itu-oam-ach-code-point-03.txt(Allocationofan Associated Channel Code Point for Use byITU-T Ethernetbased OAM) toInformational RFC - Original Message - From: Alia Atlas akat...@gmail.com To: Rui Costa rco...@ptinovacao.pt Cc: ietf@ietf.org Sent: Thursday, March 22, 2012 10:07 PM Rui, Perhaps more familiarity with the related history over the last several years would help? I can recommend the MPLS list archives. Otherwise, I find this remarkably disingenuous. This is a case of a second solution that was clearly rejected by the MPLS working group (despite in-person histrionics causing the ADs to have to threaten to close down the WG meeting). Then the solution was taken to the ITU study group - where it could also not get enough traction for their normal process. It is still not approved as a recommendation. tp Alia Were the roles reversed and the second solution be a product of the IETF that the IETF were trying to get more widely approved, would the IETF allocate a code point? I think that it would. We certainly have running code, widely deployed (although my request on the MPLS list as to which manufacturers' boxes were involved never did get answered:-(. We have a rough consensus; not unanimity, and not enough of a consensus to satisfy the processes of the ITU-T but I think enough to satisfy the consensus-judgers of the IETF (as ever, we do not vote, a majority of e-mails for one point of view may be discounted, it is the quality of the views expressed that matters as much or more). So applying the standards to which we work, I think this is another reason why we should approve this I-D. Tom Petch /tp To imply that the IETF should simply trust the allocated ACH code point to not be abused both seems optimistic and sets a dreadful precedent. Making an allocation available for an approved recommendation version is a tolerable way of reducing the deliberate use of an experimental value. Handing the keys over for any conceivable use, or even just the uses in the OAM RFC that have been adequately met by IETF WG-consensus based technology, does not seem appropriate. Alia On Thu, Mar 22, 2012 at 10:42 AM, Rui Costa rco...@ptinovacao.pt wrote: I fail to understand the issue under discussion. Can't imagine IEEE denying to grant Ethertype 0x86DD. If, however, from absurd that had happened, would the world stop or would we take the same information from the IP header version field? Regards, Rui -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alia Atlas Sent: quarta-feira, 21 de Março de 2012 15:30 To: D'Alessandro Alessandro Gerardo Cc: ietf@ietf.org Subject: Re: הנדון: 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 Considering that the need for this code point is a result of the ITU not fully complying with the IETF agreement, I cannot agree that we should simply allocate a code point for whatever the ITU wants to do in the future. It seems the best of the options to allocate a code point (much better than squatting) - but tie it to a stable reference. If the ITU can't provide a stable reference, then perhaps an RFC is the best way. There are lots of folks with opinions on the best procedure, but I certainly don't support the idea of not restricting the usage to what is clearly defined. Alia
Re: FW: LastCall:draft-betts-itu-oam-ach-code-point-03.txt(Allocationofan Associated Channel Code Point for Use byITU-T Ethernetbased OAM) toInformational RFC
- Original Message - From: Alia Atlas akat...@gmail.com To: Rui Costa rco...@ptinovacao.pt Cc: ietf@ietf.org Sent: Thursday, March 22, 2012 10:07 PM Rui, Perhaps more familiarity with the related history over the last several years would help? I can recommend the MPLS list archives. Otherwise, I find this remarkably disingenuous. This is a case of a second solution that was clearly rejected by the MPLS working group (despite in-person histrionics causing the ADs to have to threaten to close down the WG meeting). Then the solution was taken to the ITU study group - where it could also not get enough traction for their normal process. It is still not approved as a recommendation. tp Alia Were the roles reversed and the second solution be a product of the IETF that the IETF were trying to get more widely approved, would the IETF allocate a code point? I think that it would. We certainly have running code, widely deployed (although my request on the MPLS list as to which manufacturers' boxes were involved never did get answered:-(. We have a rough consensus; not unanimity, and not enough of a consensus to satisfy the processes of the ITU-T but I think enough to satisfy the consensus-judgers of the IETF (as ever, we do not vote, a majority of e-mails for one point of view may be discounted, it is the quality of the views expressed that matters as much or more). So applying the standards to which we work, I think this is another reason why we should approve this I-D. Tom Petch /tp To imply that the IETF should simply trust the allocated ACH code point to not be abused both seems optimistic and sets a dreadful precedent. Making an allocation available for an approved recommendation version is a tolerable way of reducing the deliberate use of an experimental value. Handing the keys over for any conceivable use, or even just the uses in the OAM RFC that have been adequately met by IETF WG-consensus based technology, does not seem appropriate. Alia On Thu, Mar 22, 2012 at 10:42 AM, Rui Costa rco...@ptinovacao.pt wrote: I fail to understand the issue under discussion. Can't imagine IEEE denying to grant Ethertype 0x86DD. If, however, from absurd that had happened, would the world stop or would we take the same information from the IP header version field? Regards, Rui -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alia Atlas Sent: quarta-feira, 21 de Março de 2012 15:30 To: D'Alessandro Alessandro Gerardo Cc: ietf@ietf.org Subject: Re: הנדון: 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 Considering that the need for this code point is a result of the ITU not fully complying with the IETF agreement, I cannot agree that we should simply allocate a code point for whatever the ITU wants to do in the future. It seems the best of the options to allocate a code point (much better than squatting) - but tie it to a stable reference. If the ITU can't provide a stable reference, then perhaps an RFC is the best way. There are lots of folks with opinions on the best procedure, but I certainly don't support the idea of not restricting the usage to what is clearly defined. Alia
Re: FW: LastCall:draft-betts-itu-oam-ach-code-point-03.txt(Allocationofan Associated Channel Code Point for Use byITU-T Ethernetbased OAM) toInformational RFC
Tom, Thank you for both judging consensus (the IESG's job) and instructing me on how it is done in the IETF (quite useful to me as a WG chair). Thanks also for cutting my email where I agreed that allocating a code-point for this particular use was the most tolerable option (I know the email thread had gotten long). Here it is again: Making an allocation available for an approved recommendation version is a tolerable way of reducing the deliberate use of an experimental value. Handing the keys over for any conceivable use, or even just the uses in the OAM RFC that have been adequately met by IETF WG-consensus based technology, does not seem appropriate. There are 2 separate points on which discussion is occurring. 1) Should an ACH code-point be allocated? 2) If so, should it be (a) restricted to a particular approved version of the recommendation or (b) available for whatever the ITU wants or (c) slightly restricted to uses to meet the relevant OAM RFC? On the second question, the IETF doesn't do 2b - but rather ties allocations to published RFCs. Option 2a matches both IETF process and avoids setting a dreadful precedent. Alia On Fri, Mar 23, 2012 at 5:58 AM, t.petch daedu...@btconnect.com wrote: - Original Message - From: Alia Atlas akat...@gmail.com To: Rui Costa rco...@ptinovacao.pt Cc: ietf@ietf.org Sent: Thursday, March 22, 2012 10:07 PM Rui, Perhaps more familiarity with the related history over the last several years would help? I can recommend the MPLS list archives. Otherwise, I find this remarkably disingenuous. This is a case of a second solution that was clearly rejected by the MPLS working group (despite in-person histrionics causing the ADs to have to threaten to close down the WG meeting). Then the solution was taken to the ITU study group - where it could also not get enough traction for their normal process. It is still not approved as a recommendation. tp Alia Were the roles reversed and the second solution be a product of the IETF that the IETF were trying to get more widely approved, would the IETF allocate a code point? I think that it would. We certainly have running code, widely deployed (although my request on the MPLS list as to which manufacturers' boxes were involved never did get answered:-(. We have a rough consensus; not unanimity, and not enough of a consensus to satisfy the processes of the ITU-T but I think enough to satisfy the consensus-judgers of the IETF (as ever, we do not vote, a majority of e-mails for one point of view may be discounted, it is the quality of the views expressed that matters as much or more). So applying the standards to which we work, I think this is another reason why we should approve this I-D. Tom Petch /tp To imply that the IETF should simply trust the allocated ACH code point to not be abused both seems optimistic and sets a dreadful precedent. Making an allocation available for an approved recommendation version is a tolerable way of reducing the deliberate use of an experimental value. Handing the keys over for any conceivable use, or even just the uses in the OAM RFC that have been adequately met by IETF WG-consensus based technology, does not seem appropriate. Alia On Thu, Mar 22, 2012 at 10:42 AM, Rui Costa rco...@ptinovacao.pt wrote: I fail to understand the issue under discussion. Can't imagine IEEE denying to grant Ethertype 0x86DD. If, however, from absurd that had happened, would the world stop or would we take the same information from the IP header version field? Regards, Rui -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alia Atlas Sent: quarta-feira, 21 de Março de 2012 15:30 To: D'Alessandro Alessandro Gerardo Cc: ietf@ietf.org Subject: Re: הנדון: 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 Considering that the need for this code point is a result of the ITU not fully complying with the IETF agreement, I cannot agree that we should simply allocate a code point for whatever the ITU wants to do in the future. It seems the best of the options to allocate a code point (much better than squatting) - but tie it to a stable reference. If the ITU can't provide a stable reference, then perhaps an RFC is the best way. There are lots of folks with opinions on the best procedure, but I certainly don't support the idea of not restricting the usage to what is clearly defined. Alia
