Elwyn, SM, Thank you for your reviews. Here is my current thinking: 1. There was probably some confusion in that we probably meant section 5.2 and not 5.3 in RFC 5226. Nevertheless, I find RFC 5226 difficult to apply here because of the way it is worded. Specifically, it is designed for assignment purposes and not for change purposes. Hence, I've removed most references to 5226. To be clear, the TZ coordinator should be given great deference, but that in limited circumstances appeals to the IESG must be allowed (one could imagine a designated expert who went crazy and took sides in a political fight, for instance). 2. Clearly there is a need for criteria for updating the database. We're going to take a swing at that. 3. The licensing terms listed in the current draft seem to satisfy almost nobody. Therefore they have to be redone. I have asked for opinions on this very subject from one or two knowledgeable people, and hope to have a new proposal before the draft cut-off date. 4. I've accepted your minor point and your nits. Eliot On 1/13/11 2:13 AM, SM wrote: > Hi Elwyn, > At 09:10 12-01-11, Elwyn Davies wrote: >> This document is not quite ready for the IESG. The appeals process (if >> there is to be one) needs to clarified as it currently points indirectly >> to a hole in RFC 5226. As explained below, I have a feeling that it >> would be wise to avoid tying the processes in this document to the >> Designated Expert processes in RFC 5226 despite the similarities. >> Making it clear what does apply and what doesn't is probably more work >> than doing it from scratch in this document, especially given the hole >> in RFC 5226. > > [snip] > >> I think the draft should make it explicit that it is referring to the >> 'Designated Expert' sections in RFC 5226 here if it continues to >> reference RFC 5226 - although there is a clear relationship with >> Designated Experts, the differences between the selection process and >> the operations of the TZ Coordinator and generic Deisgnated Experts may > > Yes, there are significant differences. According to RFC 5226: > > "The designated expert is responsible for initiating and coordinating > the appropriate review of an assignment request." > > It might be helpful to get some feedback from IANA and the IETF Trust > on this draft before it is evaluated by the IESG. > >> mean that citing RFC 5226 might lead to legalistic disputes about which >> set of rules applies. Also, I am unable to find statements in RFC 5226 >> backing up the sentence above. Regrettably, RFC 5226 appears >> effectively to have a 'dsngling reference' in this area. Section 3.2, >> para 3 of RFC 5226 points at Section 5.2 which (allegedly) discusses >> 'disputes and appeals in more detail'. However s5.2 is titled 'Updating >> Registrations' and says nothing about appeals and disputes. Section 7 >> of RFC 5226 covers appeals of IANA decisions but says nothing specific >> about appealing designated expert rulings. I think this area may need a >> little more work. Overall, my inclination would be to make this a >> standalone document that does not try to partially modify the RFC 5226 >> Designated Expert process and operations. Appeals... >*sigh*<. > > Section 7 of RFC 5226 states that: > > "Appeals of registration decisions made by IANA can be made using the > normal IETF appeals process as described in Section 6.5 of > [IETF-PROCESS]." > > Section 4 of mentions that: > > "In keeping with [RFC5226], the IESG selects the TZ > coordinator(s). The IESG will use rough consensus of the TZ mailing > list as their primary guide to further action, when it exists, and > whatever other means they have at their disposal, when rough > consensus cannot be found. As RFC-5226 states, the IESG is not a > normal avenue for appeals of specific decisions of the coordinator, > but rather a last resort when a coordinator is thought not to be > functioning in an appropriate way." > > That could be rewritten as: > > The IESG selects the TZ coordinator(s). The IESG will use the rough > consensus of the TZ mailing list as their primary guide for any > action, > when it exists, and whatever other means they have at their disposal, > when rough consensus cannot be found. > > The IESG is not an avenue for appeals of specific decisions of the > coordinator, but rather a last resort when a coordinator is thought > not > to be functioning in an appropriate way. An appeal can be made in > such > a case by using the normal IETF appeals process as described in > Section > 6.5 of RFC 2606. > > The following sentence in Section 1.1 might have to be removed then: > > "The TZ coordinatior is a Designated Expert, as defined in [RFC5226]" > > Regards, > -sm > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf