1 / 13

RFC 3761bis

RFC 3761bis. IETF 66 Montréal. Issues. Collected in the ticket system Idea for Next Generation ENUM…. #838: ORDER/PRIORITY locality. ORDER and PRIORITY is significant only within the current domain. This is not clear in RFC 3761.

kail
Download Presentation

RFC 3761bis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RFC 3761bis IETF 66 Montréal ENUM - RFC 3761bis

  2. Issues • Collected in the ticket system • Idea for Next Generation ENUM… ENUM - RFC 3761bis

  3. #838: ORDER/PRIORITY locality • ORDER and PRIORITY is significant only within the current domain. This is not clear in RFC 3761. • This matters for NTN processing, where the ORDER and PRIORITY values are only considered within a single zone. The ORDER and PRIORITY value for a NTN and is not relevant in the zone targeted by that NTN. ENUM - RFC 3761bis

  4. #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. • This is derived from a similar approach proposed in draft-ietf-dnsext-2929bis-02.txt "DNS IANA Considerations) for registration of DNS RR. • If this can be done for DNS RR, it also is feasible for Enumservices ENUM - RFC 3761bis

  5. #870: DDDS - RFC3404 reserves ALL flag characters • RFC 3404 specifies that all flag characters are reserved "for future versions of this document". • This is wrong, IMHO. It reflects a problem with the way flag characters (and the expected output these imply) are specified. [i.e. within DDDS Applications, with behaviour that must not be redefined in other DDDS Application documents] ENUM - RFC 3761bis

  6. #871: DDDS - RFC3403/RFC3404 generation of target FQDN for Non-Terminal NAPTR • RFC 3403 section 4.1 (and RFC 3404) imply that the REGEXP field can be used to generate a FQDN as the target for a non-terminal rule. RFC 3404 in particular suggests that one can choose which to use, and that one should look in both fields to see which one is not empty. • I have problems with this "look at both and then use whatever is there" policy. AFAICT, the only ENUM clients that DO handle NTNs expect the target FQDN only to be in the replacement field. The other DDDS Applications that use non-terminal NAPTRs ALL put the target FQDN in the replacement field. ENUM - RFC 3761bis

  7. #873: Character Set, Case Sensitivity, and NAPTR fields • [a] use of non-ASCII (and non-printable characters) in SED/POSIX REGEXP field. • [b] Does allowing characters with multi-byte UTF-8 encoding in the services and flags fields help? • [c] Case Sensitivity is unclear for the flags and service field. We have **Assumed** that the flags and services field content is US-ASCII equivalent, and so we can choose whether or not these fields are case sensitive or not. ENUM - RFC 3761bis

  8. #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. ENUM - RFC 3761bis

  9. #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 '+’. • (i) this function is rareley used at all • (ii) it is feasable only for Enumservices resulting in the same URI, so it may even be used wrongly. • It is therefor proposed to use only one Enumservice per NAPTR. • To which I counter-propose: over my dead and smoking body! ENUM - RFC 3761bis

  10. #878: experimental ENUM services - clash prevention • Because 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. ENUM - RFC 3761bis

  11. RFC 3761 $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" . NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" . NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" . ENUM - RFC 3761bis

  12. ENUM Next Generation $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" . NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" . NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" . $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. _sip._enum URI 10 10 "sip:info@example.com" _h323._enum URI 10 10 "h323:info@example.com" _msg._enum URI 10 10 "mailto:info@example.com" ENUM - RFC 3761bis

  13. ENUM Next generation • Today, query for NAPTR and get back every URI “connected” to the domain • Should we separate between • What services exists for this domain? • What URI should I use for this service? • Will this at the same time make delegation possible of separate URI specifications to different organisations? • Backward compatibility? ENUM - RFC 3761bis

More Related