Subject: [dnsext] draft-levine-dnsextlang-02

From: Miek Gieben <[email-masked]>
Date: Thu, 29 Mar 2012 13:18:37 +0200

Hello,

I've read the draft and it's a nice idea. I have a couple of questions/remarks though.

* Base32 should be supported in the rdata (for NSEC3).
* There probably should be an rdata type called BitMap (for NSEC/NSEC3).
* NSEC3 has a salt length which isn't used in the text representation of the
  record. How is this handled?
* The HIP record also has fields not used in the text representation: "PK length
  field".
* The HIP record ends with an array of domain names. How should that be encoded?
  Same holds true for TXT records.
* The HIP contains a base64 field that can not contain spaces in the
  presentation format (unlike all other b64 fields in other RRs). How to deal
  with that?
* The IPSECKEY RR uses some internal subtyping: if "gatewaytype" is 0 there is no
  gateway. If it is 1 or 2 its an IP address and if its 3 the gateway is a
  domain name. How to encode that?

Kind regards,

-- 
    Miek Gieben
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Thu, 29 Mar 2012 12:45:22 +0100

> * There probably should be an rdata type called BitMap (for NSEC/NSEC3).

Yes.

>   record. How is this handled?

There should probably be a qualifier for a length prefix on hex data, as
there is for base64.

>   presentation format (unlike all other b64 fields in other RRs). How to deal

HIP RDATA is horrible. It would be slightly easier if the length fields
prefixed the data they describe. The non-standard base64 restriction is
ugly. The rendezvois servers should probably be listed in separate RRs of
a different type, which would also solve the base64 problem. I think that
awkward RRtypes like this should have special case handling, e.g. describe
the RDATA as a single field of HIP type, or just leave it to RFC 3597
generic representation.

Ideally in the future RRDATA layouts will be simpler than this.

>   Same holds true for TXT records.

There are qualifiers to specify multi-field textual data.

>   domain name. How to encode that?

Again I think this has to be handled in special case code. Really they
should have used a different RR type for each layout.

Another awkward case is the variable-length IPv6 address field in A6
records, but that has been deprecated forcefully enough that it is no
problem to handle with RFC 3597 generic layout.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dogger: Northwesterly 5 or 6, occasionally 7 in northeast. Moderate or rough.
Fair. Moderate or good.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Miek Gieben <[email-masked]>
Date: Thu, 29 Mar 2012 13:55:30 +0200

[ Quoting <[email-masked]> in "Re: [dnsext] draft-levine-dnsextlan..." ]
> There should probably be a qualifier for a length prefix on hex data, as

Can you just say "this is length of the NEXT item"? Or does it need to be
generic "this is the length of item <NAME of ITEM>, which is more of a pointer.
 
> the RDATA as a single field of HIP type, or just leave it to RFC 3597

Agreed, using 3597 syntax for such ugly RRs is probably the best.

> Ideally in the future RRDATA layouts will be simpler than this.

Well, an idea I have floating in my mind is: if your (new) RR can not
be described in terms of dnsextlang, you should think of a different
syntax. Not supporting the HIP record would help in that regard.

> should have used a different RR type for each layout.

As you said, why not avoid this whole mess and use 3597?

> problem to handle with RFC 3597 generic layout.

Are we now creating a hall of shame for badly designed RRs? :)

 Regards,

---

From: Tony Finch <[email-masked]>
Date: Thu, 29 Mar 2012 13:01:33 +0100

> generic "this is the length of item <NAME of ITEM>, which is more of a pointer.

Maybe. At the moment there's a very nice one-to-one correspondence between
fields described by the language and as they appear in master files, and
on the wire if you regard a length prefix as part of the field.

> syntax. Not supporting the HIP record would help in that regard.

Yes :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: Northwesterly 5 to 7. Moderate or rough. Mainly fair. Good,
occasionally poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Florian Weimer <[email-masked]>
Date: Thu, 29 Mar 2012 21:43:15 +0200

> As you said, why not avoid this whole mess and use 3597?

You need to add a presentation layer somewhere.

We might better off to define a DOM and implement the encoding and
decoding in Javascript.  Honestly.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext