Re: [DNSOP] [dns-privacy] [core] WGA call for draft-lenders-dns-over-coap

2022-09-11 Thread Alexander Mayrhofer
Hello everyone, Speking as the author of RFC 7830 – there was some discussion whether the document should say “SHOULD NOT” or “MUST NOT” when padding DNS packets over unencrypted packets. We couldn’t come up with any other use case (maybe except testing of the feature over unencrypted transport

[DNSOP] On .ZZ

2019-11-20 Thread Alexander Mayrhofer
Setting the basic issue aside (I'm still a bit torn) I agree with Warren that it would need a string that has a meaning. ..ZZ would remind me of long beards and loud motorcycles for the rest of my life.. https://de.wikipedia.org/wiki/ZZ_Top best, Alex

[DNSOP] NSEC3 Guidance - zone size impact of opt-out

2021-09-03 Thread Alexander Mayrhofer
Wes, all, thanks for putting together draft-ietf-dnsop-nsec3-guidance. I have one small comment regarding section 2.2 (Flags): In some deployments of larger (eg TLD), in-memory zone size on the authoritative servers is a significant issue, particularly if the total memory size required is multipl

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

2017-11-14 Thread Alexander Mayrhofer
On Wed, Nov 15, 2017 at 9:57 AM, Dave Lawrence wrote: > I personally am of the belief that yes, if the request has an OPT then > a responder can include an option code that was not in the request. > At least I don't see anything in 6891 to prohibit it. This is > behaviour that draft-ietf-dnsop-ex

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

2017-11-14 Thread Alexander Mayrhofer
> I'm not particularly arguing either way on this question of signalling, > but do we have any feel for how many stubs ever send EDNS? > > libresolv can do it, and getdns does, but I don't think glibc's resolver > routinely sends EDNS. Ray, i do agree - having figures "from the field" about this

[DNSOP] Fwd: New Version Notification for draft-mayrhofer-did-dns-00.txt

2018-08-06 Thread Alexander Mayrhofer
ion Notification for draft-mayrhofer-did-dns-00.txt To: Dimitrij Klesev , Alexander Mayrhofer , Markus Sabadello A new version of I-D, draft-mayrhofer-did-dns-00.txt has been successfully submitted by Alexander Mayrhofer and posted to the IETF repository. Name: draft-mayrhofer-did-dn

Re: [DNSOP] IETF 103: Call for agenda items

2018-10-03 Thread Alexander Mayrhofer
Hello Benno, I'd like to talk about https://tools.ietf.org/html/draft-mayrhofer-did-dns-00. I think i should be good with 5 minutes. much appreciated! Alex On Tue, Oct 2, 2018 at 11:15 PM Benno Overeinder wrote: > > Hi all, > > We have requested one DNSOP session of 2 hours for the IETF 103. T

[DNSOP] draft-ietf-dnsop-attrleaf vs. RFC7553

2019-02-07 Thread Alexander Mayrhofer
Hello everyone, I'm turning my head around an issue around the attrleaf draft, and its connection with RFC7553 (the URI RRType). Im specifically wondering what the connection between the "service parameter" in RFC 7553 and the "Global Underscore Node Names" in draft-ietf-dnsop-attrleaf is. I'm

Re: [DNSOP] [Ext] draft-ietf-dnsop-attrleaf vs. RFC7553

2019-02-08 Thread Alexander Mayrhofer
Hi, > Von: Paul Hoffman > Gesendet: Donnerstag, 7. Februar 2019 22:45 [..] > > Dave moved the duct tape patching up all the places that defined > > underscored names to draft-ietf-dnsop-attrleaf-fix. > > > > See sections 2.3 and 2.3 for URI records. > > Oh, i should have looked at the attrleaf

[DNSOP] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

2019-02-08 Thread Alexander Mayrhofer
2019 at 2:52 PM Subject: New Version Notification for draft-mayrhofer-did-dns-01.txt To: Dimitrij Klesev , Alexander Mayrhofer , Markus Sabadello A new version of I-D, draft-mayrhofer-did-dns-01.txt has been successfully submitted by Alexander Mayrhofer and posted to the IETF repository. Name:

Re: [DNSOP] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

2019-02-18 Thread Alexander Mayrhofer
Stephane, all, [I feel cautious about continuing to cross-post this to dnsop as well as dinrg - however, it does apply to both areas, so i'll keep both groups in for now] On Fri, Feb 15, 2019 at 10:37 AM Stephane Bortzmeyer wrote: > I think that it is an important work because it brings the powe

Re: [DNSOP] [Din] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

2019-02-18 Thread Alexander Mayrhofer
Paul, On Fri, Feb 15, 2019 at 7:47 PM Paul Wouters wrote: > I think this document should be Experimental and not Standards Track? I was torn when i did the first revision of this. I think it depends on the stability of Decentralized Identifiers themselves. Once that schema becomes widely used, i

Re: [DNSOP] [Din] Fwd: New Version Notification for draft-mayrhofer-did-dns-01.txt

2019-02-18 Thread Alexander Mayrhofer
On Fri, Feb 15, 2019 at 8:47 PM Melinda Shore wrote: > I think the question of whether or not to provide > decentralized identifiers and whether or not this proposal > delivers on the "decentralized" claim is out of our hands, > as the core spec (which has a lot of additional problems) > comes out

[DNSOP] ROOM CHANGE to TYROLKA - Security/Registry Lock Side Meeting: Wed, 14:00 - 15:00

2019-03-26 Thread Alexander Mayrhofer
lex Von: Alexander Mayrhofer Gesendet: Dienstag, 26. März 2019 11:13 An: reg...@ietf.org Betreff: Security/Registry Lock Side Meeting: Wed, 14:00 - 15:00, Room Paris Hello everyone, as mentioned during the regext WG session, i've organized a "SecurityLock / RegistryLock" side meeting

[DNSOP] draft-mayrhofer-edns0-padding

2015-07-23 Thread Alexander Mayrhofer
Hi, I had a discussion with Daniel Khan Gillmor today, and we talked about his proposal to specify a padding option in TLS so that message-size based correlation attacks on encrypted DNS packets could be prevented. We continued discussing other options (such as "artificial" RRs in the addition

Re: [DNSOP] draft-mayrhofer-edns0-padding

2015-07-23 Thread Alexander Mayrhofer
George, i certainly agree. Noted for a revision. Alex Von: George Michaelson [mailto:g...@algebras.org] Gesendet: Donnerstag, 23. Juli 2015 18:52 An: Alexander Mayrhofer Cc: dns-priv...@ietf.org; dnsop@ietf.org Betreff: Re: [DNSOP] draft-mayrhofer-edns0-padding What does it mean to exceed the

[DNSOP] DNS text in Enumservices guide...

2008-03-11 Thread Alexander Mayrhofer
As mentioned in the session today, the Enumservices Guide contains some text on DNS Considerations in section 5.7: http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide The original reason for this text was the "unused" Enumservice, which conveyed assumptions about the DNS space "below"

[DNSOP] Review of draft-ietf-dnsop-respsize-10

2008-03-19 Thread Alexander Mayrhofer
Hi, I've volunteered in Philly to do a review of the response size drafts - i have seperated my comments into "content" and "nits" issues. content --- - The first sentence in 2.1 should probably start with "A positive delegation response.." because a negative response could for example als

Re: [DNSOP] Review of draft-ietf-dnsop-respsize-10

2008-03-19 Thread Alexander Mayrhofer
> that's all i found -- hm. i knew i forgot something: References: I guess that most of the "Normative" References in the draft could be made "Informative". The only normative ones i see are RFC1034, RFC1035, and RFC2181. The others should be moved to an Informative References section. thanks,

Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt

2009-03-04 Thread Alexander Mayrhofer
> You may be quite right about that. It's one of the things that I want > to have a discussion about. I started out with a somewhat conservative > specification, to see where the discussion will take us. > > More voices? I would keep the ABNF to purely *technical* limits as well. Don't let the AB

[DNSOP] DS without NS in a delegation?

2013-02-27 Thread Alexander Mayrhofer
Hi, We've been discussing internally whether or not including DS records into a zone without respective NS record(s) makes any sense (assuming that there are no other RRSETs for the respective label in the zone itself - pure "delegation" scenario)... My personal assumption is that it does not,

Re: [DNSOP] Second Session to discuss DNS Privacy et. al.

2014-03-05 Thread Alexander Mayrhofer
Tim, > We have decided after much discussion (and little negative feedback) to hold > a seperate session Thursday Evening at 16:40 to discuss DNS privacy and all > the things that come with it. Is that the correct time? The Agenda does list time slots starting at either 17:00 or 18:40 - are you

[DNSOP] Review of edns-tcp-keepalive-01

2015-01-22 Thread Alexander Mayrhofer
Hi, I've reviewed the keepalive draft. Generally, i do like the concept a lot because: a) there's certainly a use case that covers real operational issues b) it's a space-efficient and c) unobstrusive. However, i think the document could improve on clarity in certain aspects - see below for d

Re: [DNSOP] Review of edns-tcp-keepalive-01

2015-01-22 Thread Alexander Mayrhofer
> * PROTOCOL: Is the expected behaviour (MUST) from both client and server > that they should add the Option to every single request / response during a > keepalive session? Please clarify the intended behaviour.. Two final comments, sorry: * EDITORIAL/PROTOCOL: Shouldn't the option (as well as t