[dnsext] ILNP RRTYPEs review - result [IANA #561079]

[Roy Arends <[e-mail]>]

Dear Colleagues,

This message ends the review process for the ILNP RRTYPEs. According to
my judgment the requests meet RFC6195 at both requirements of section
3.1.1 and none of section 3.1.2 and should be accepted.

I will work with the editors to address Tony Finch' editorial remarks.

Thank you,

Warmly,

Roy Arends

Best Regards,
On Jun 13, 2012, at 11:00 PM, Roy Arends wrote:

> Dear Colleagues,
> 
> Below is a completed template requesting new RRTYPE assignments under the procedures of RFC6195.
> 
> This message starts a 3 weeks period for an expert-review of the DNS RRTYPE parameter allocations for ILNP specified in http://www.ietf.org/id/draft-irtf-rrg-ilnp-dns-05.txt
> 
> If you have comments regarding this request please post them here before July 5th 18:00 UTC.
> 
> Best Regards,
> Roy Arends
> 
>          DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
> 
>      When ready for formal consideration, this template is
>      to be submitted to IANA for processing by emailing the
>      template to [e-mail].
> 
>      A.    Submission Date:  To be determined.
> 
>      B.    Submission Type:
>            [X] New RRTYPE
> 
>      C.    Contact Information for submitter:
>               Name:  R. Atkinson
>               Email Address: [e-mail]
>               International telephone number: unlisted
>               Other contact handles:
> 
>      D.    Motivation for the new RRTYPE application?
> 
>         Support for an experimental set of IP extensions
>         that replace the concept of an "IP Address" with
>         distinct "Locator" and "Identifier" values.
> 
>      E.    Description of the proposed RR type.
> 
>            Please see:
> 
>              http://tools.ietf.org/id/draft-irtf-rrg-ilnp-dns-05.txt
> 
>            for a full description.
> 
>      F.    What existing RRTYPE or RRTYPEs come closest to filling
>            that need and why are they unsatisfactory?
> 
>      There is no RRTYPE that fulfils the need due to the
>      new semantics of Locator and Identifier values.
> 
>         The AAAA record combines both Locator and Identifier,
>         so has significantly different semantics than having
>         separate L64 and NID record values.  The AAAA record also
>         lacks scalability and flexibility in the context of the
>         experimental protocol extensions that will use the NID
>         and L64 records, as any valid NID record value for a node
>         can be used on the wire with any valid L64 record value
>         for the same node.
> 
>         The CNAME record is closest conceptually to an LP
>         record, but a CNAME is a node name referral scheme,
>         while the LP record is indicating that the given node
>         has the same routing prefix as some other domain name,
>         but does not necessarily have any other values that are
>         the same.
> 
>     Lastly, the AAAA and CNAME RR Types lack a Preference
>     field to rank responses.  Such Preference information
>     is required for ILNP in order to support the use of multiple
>     instances of NID, L32, L64 and LP records.
> 
>      G.    What mnemonic is requested for the new RRTYPE (optional)?
> 
>         As described in this draft, "NID", "L32", "L64", and "LP".
> 
>      H.    Does the requested RRTYPE make use of any existing IANA
>            Registry or require the creation of a new IANA
>            sub-registry in DNS Parameters?
> 
>         Existing registry of DNS Resource Record (RR) data TYPE
>         values should be used.
> 
>      I.    Does the proposal require/expect any changes in DNS
>            servers/resolvers that prevent the new type from being
>            processed as an unknown RRTYPE (see [RFC3597]) ?
> 
>         No.
> 
>      J.    Comments:
>           This document defines "ILNP-aware" DNS servers
>           or DNS resolver as a DNS server (authoritative or recursive)
>           that MAY include other ILNP RRTypes in the Additional
>           section of a DNS response that match a QNAME (if
>           size permits). This is to reduce the number of
>           DNS stub resolver follow-up DNS queries. and only applies
>           when the QTYPE is either NID, L32, L64, or LP.  There is no
>           signalling mechanism for this Additional section
>           processing, and this is believed to be compatible
>           with existing non-ILNP-aware DNS servers and DNS stub
>           resolvers.
> 
>           No changes are required for existing deployed
>           DNS servers or DNS resolvers.
> 
> 

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext