Randy Presuhn wrote: > Could you point me to the specific text that was proposed? "Missing definition of conflict" was discussed in the thread <http://mid.gmane.org/42829109.2E72 at xyzzy.claranet.de> > The best way to ensure that an i-d addresses your concerns > is to propose specific text. An agreement with the editors about the underlying issue is also okay, but obviously I forgot to check the outcome, sorry. Specific text proposed in my parallel message for #1026, see also <http://mid.gmane.org/42AB3D9E.46C8 at xyzzy.claranet.de> >> Could we please run a simulation, Doug plays tag reviewer [...] > This would go faster if you'd just list each of the scenarios Now I did this, 1st scenario, let's assume TL manages to get a new code XX, what happens in the registry (after date-B) ? 2nd scenario, UN M.49 assigns number 888 to Somaliland. What happens in the registry ? Later ISO 3166-1 assigns code SX for the new Somaliland. What happens in the registry ? > where you think the outcome specified by the current i-d I'd expect that TL is deprecated with new Preferred-Value XX in the 1st scenario. And I proposed text that would allow to update Preferred-Value: TL (in the old TP record) to XX. In the 2nd scenario I expect 888 to be added. I proposed text that idetifies UN M.49 as input source. At the moment that's not the case in 2.2.4 number 3. points A..D, especially C. We would need a new case "region with a number but not in 3166-1". In 3.3 it's (as already proposed) the addition of "UN M.49" to "bullet 8". This is also my third (?) request to replace the bullet-lists by numbered lists if there are too many bullets. And finally in the 2nd scenario after 888 got SX I'd expect that SX is added to the registry. Preferred-Value: 888 isn't optimal, but waiting for the Duke of Normandy or whatever the problem with GG, IM, and JE might be is no option. Bye, Frank _______________________________________________ Ltru mailing list Ltru at lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.