It was mentioned in the plenary this morning the ticket system I use for creation of RFC 3761bis. The issues are so far: [Please don't respond to this email, respond to the original email that describes the ticket that was sent to the ENUM wg in the IETF, or add issues to the ticket system directly...instructions I can send on request] What I have in the tracker are the following issues: #838 ORDER/PRIORITY locality ORDER and PRIORITY is significant only within the current domain. This is not clear in RFC 3761. #861 Fast lane for Enumservice IANA registration It is proposed to establish a fast lane for rIANA egistration of non- essential Enumservices using only expert review and not the full RFC cycle. #870 DDDS - RFC3404 reserves ALL flag characters RFC 3404 specifies that all flag characters are reserved "for future versions of this document". #873 Character Set, Case Sensitivity, and NAPTR fields Character Set, Case Sensitivity, and NAPTR fields. NOTE - This is really three inter-related topics. As they are so closely tied together I have requested a single ticket. #874 REGEXP 'i' flag considered harmful RFC 3402 specifies an 'i' flag that can be applied to the REGEXP field. This flag is intended to make AUS matching case insensitive. For ENUM, this is not appropriate, as the allowed characters within an AUS are all case insensitive. #875 Only one Enumservice per NAPTR the syntax for Enumservices given in RFC3761 allows for more then one Enumservice to be given, by addiing them with a '+' #878 experimental ENUM services - clash prevention ecause of the cumbersome process of ENUMservice registration, more and more experimental services are popping up. Contrary to it's intended purpose, more and more of those services are used "de facto" not only internally, but between different parties. This increases the risk of collisions between several different implementations of "experimental" ENUMservices, hence creating the need for preventing collisions between those services. Patrik