Re: [DNSOP] Last Call: Change the status of GOST Signature Algorithms in DNSSEC in the IETF stream to Historic

[tjw ietf]

I agree new code points should gave new RFCs. 

I am ok with OBSOLETE or DEPRECATED

Sent from my iPhone

On Nov 29, 2023, at 17:18, Paul Wouters  wrote:

On Wed, 29 Nov 2023, Warren Kumari wrote:

> So, the IANA has a question:
> IANA Question --> What about the registrations that currently reference 
> RFC5933?
> Should the registrations currently referencing RFC5933 be marked "OBSOLETE," 
> "DEPRECATED," changed in
> some other way, or left alone?

> If IANA is asked to make changes to these registrations, IANA will add a link 
> to the status change
> document to the registrations."

> Seeing as GOST R34.10-2001 and GOST R 34.11-94. GOST 34.10-2001 and GOST 
> 34.11-94 were deprecated by
> the Orders of the Federal Agency for Technical Regulation and Metrology of 
> Russia (Rosstandart) in
> August 2012, and RFC5933 is being made historic (replaced by 
> draft-makarenko-gost2012-dnssec which
> describes how to use the GOST 2012 algs), I think that "OBSOLETE, see  RFC number>" is best, but I
> wanted the WG's input…

I don't think a pointer to the new RFC should be used, because we are not
re-assigning the code points. Let new code points point to the new RFC.

So just "DEPRECATED" I think ?

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IETF117 Chairs Actions

[tjw ietf]

I need to double checkBut also stip on avoid fragmentation. I missed somethingTim Sent from my iPhoneOn Aug 18, 2023, at 13:07, Warren Kumari  wrote:Heyya,Just confirming that I can start IESG Eval on draft-ietf-dnsop-caching-resolution-failures?I'm assuming so, but…WOn Wed, Aug 16, 2023 at 6:57 PM, Tim Wicinski  wrote:All,Thanks for another productive session of DNSOP.  Paul's minutes have been uploaded. If you made comments at the microphone, please confirm everything is accurate. https://datatracker.ietf.org/doc/minutes-117-dnsop/https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-ietf117/dnsop-ietf117-minutes.txtActions draft-ietf-dnsop-caching-resolution-failuresWork to resolve questions on caching timeout value text. Good Discussions, let's have more:draft-ietf-dnsop-cds-consistencydraft-ietf-dnsop-compact-denial-of-existenceCall For Adoptions:draft-thomassen-dnsop-generalized-dns-notifywas going to do this after 116, ended up with the discussion on two NOTIFY draftsdraft-bash-rfc7958bisThis appears straightforward.draft-bellis-dnsop-qdcount-is-oneRay will move Historical Text to appendix,then will send out Call Current ordered list of Working Group Last Call documents:draft-ietf-dnsop-dnssec-bootstrapping draft-ietf-dnsop-rfc8109bisdraft-ietf-dnsop-svcb-daneMore Discussion:draft-grubto-dnsop-dns-out-of-protocol-signalingmaybe ready for adoption?draft-johani-tld-zone-pipelinedraft-dnsop-multi-alg-rules

___

DNSOP mailing list

DNSOP@ietf.org

https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for "Domain Verification Techniques using DNS"

[tjw ietf]

John

Paul is right. As an operator one thing I always obsess on in is the data in my 
zones.  Why is it there , should it be, etc. Another example you may understand 
is “who created this incorrect DMARC record?”

I’ve given them much much feedback. I am eager for others to sound off. 

And Brian, I appreciate your comments but i do wish you read the drafts as 
well. 

Tim 

Sent from my iPhone

> On Feb 17, 2023, at 18:47, Paul Wouters  wrote:
> 
> On Fri, 17 Feb 2023, John R Levine wrote:
> 
>> Surely we know people who run services that use DNS validation.  How about 
>> talking to some of them and finding out what kind of user errors they run 
>> into?
> 
> The insinuation here is that we didn't talk to them. One of the authors
> is at salesforce, who is a big deployer of this. We talked at a number
> of IETFs to various people and listened to them. One of the dnsop chairs
> also has quite some experience in this field and read previous drafts
> and gave us advise from their viewpoint.
> 
> But also, the pain is not felt at the people who dictate how to use
> their DNS validation scheme. It is with the DNS administrators finding
> a bunch of unrecognisable DNS records and not knowing what the hell
> they are for and whether they can or should be deleted. Or those admins
> that now see their APEX going back to TCP (yes dig txt cnn.com gets TC
> and falls back to TCP)
> 
>>> (Caveat, I'm responding to this thread, not to the actual draft since I
>>> haven't recently read it.)
>> 
>> It's not very long, should take about 5 mins to read.
> 
> Its a feature. We try to keep it simple and clear and easy to follow.
> 
> And not present people with a number of mostly equivalent ways of
> doing the same thing. In the end, it is a BCP. If you want to insist
> on using randomized prefixes with CNAMEs, make your day.
> 
> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-02.txt

[tjw ietf]

Peter

There is no undesirable consequences in pushing new versions before they expire 
without changes. 

Actually i have an action item to review some of the discussion on this draft 
which is now on my short list as we push several of these other documents 
forward. 

Tim

Sent from my iPhone

> On Feb 17, 2023, at 16:16, Peter Thomassen  wrote:
> 
> Hi Joe, all,
> 
>> On 2/17/23 21:48, Joe Abley wrote:
>>> On Fri, Feb 17, 2023 at 15:03, Peter Thomassen >> > wrote:
>>> I am not sure whether draft expiry impacts the WG document handling process 
>>> in any way.
>> I would not worry. You can always reset the timer by bumping the version and 
>> the date and resubmitting, if it bothers you. The particular lifetime of an 
>> I-D is somewhat arbitrary; the main thing is that it is finite.
> 
> Thank you for explaining! I wasn't sure whether expiry would imply that a 
> draft would have to be (e.g.) re-adopted etc.pp. I'm relieved to know that's 
> not the case.
> 
> I nevertheless pushed a new revision (-03) to reflect the implementation 
> updates that have happened since -02.
> 
>>> Regardless, I had thought that the WG would generally process adopted 
>>> drafts within their expiration window (which is why a process hiccup had 
>>> come to my mind). I'm not sure if there is some policy about this or not.
>> I obviously do not speak for the chairs. However, in my experience are all 
>> volunteers here, and we all do our best. Sometimes things take longer than 
>> we expect and life goes on.
> 
> Yes, and it's indeed a great gift to the community that the chairs (and other 
> leadership, for that matter), are putting in their time volunteering. (Thank 
> you!)
> 
> I had no intentions to be pushy, and was simply concerned that expiration may 
> have undesirable consequences. I'd like to apologize in case anything I wrote 
> came across in any other way. Obviously, if there's no adverse consequences, 
> then there's no rush. :-)
> 
> Best,
> Peter
> 
> -- 
> https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping

[tjw ietf]

(No hats)

I’ve read this draft and support adoption 

Tim 

Sent from my iPhone

> On Mar 25, 2022, at 11:28, Benno Overeinder  wrote:
> 
> As announced during the DNSOP meeting this week at the IETF 113, we are 
> starting a Call for Adoption for the 
> draft-thomassen-dnsop-dnssec-bootstrapping.  With the survey we conducted 
> before the last IETF 112, this draft was a clear candidate.
> 
> With this email we start a period of two weeks for the call for adoption of 
> draft-thomassen-dnsop-dnssec-bootstrapping on the mailing list.
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/
> 
> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 8 April 2022
> 
> Thanks,
> 
> Suzanne, Tim and Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question regarding RFC 8499

[tjw ietf]

I’ve had several conversations with one of the 8499 authors a few months back 
and said that we need to adjust this. I let it drop but the topic was going to 
be part two f our chairs slides next week. 

The chairs did some reviewing of all Currently adopted documents as well. 

Thanks 
Tim 



Sent from my iPhone

> On Jul 23, 2020, at 05:02, Paul Vixie  wrote:
> 
> On Thursday, 23 July 2020 08:47:42 UTC libor.peltan wrote:
>> Hi,
>> 
>> just a factual comment.
>> 
>> While primary/secondary = master/slave is indeed a recent transition of
>> terms among DNS community, and I agree that this should be handled
>> carefully when writing new RFCs,
> 
> i introduced the master/slave terminology in rfc 2136, because i needed names 
> for the roles in an AXFR/IXFR transaction, and the zone transfer hierarchy 
> could be more than one layer deep, such that a server might initiate some 
> AXFR/IXFR's to the "primary master" but then respond to AXFR/IXFR's from 
> other 
> servers. in retrospect i should have chosen the terms, "transfer initiator" 
> and "transfer responder". however, the hydraulic brake and clutch systems in 
> my car had "master cylinders" and "slave cylinders", and so i did not think i 
> was either inventing a new use for the words "master" and "slave", or that my 
> use of them for this purpose would be controversial. i was naive, and i 
> suggest that we revisit the terminology we use in all our distributed 
> systems, 
> starting with DNS zone transfer roles.
> 
>> ...
>> 
>> BR,
>> 
>> Libor
> 
> -- 
> Paul
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Deprecating the status opcode

[tjw ietf]

Can we like this draft *and* a RFC cleanup of 1034/1035?

Though watching tcpm do this for 793 has been disheartening 

From my high tech gadget

> On May 16, 2019, at 11:46, Michael J. Sheldon  wrote:
> 
>> On 5/16/19 3:23 AM, Petr Špaček wrote:
>> Notice: This email is from an external sender.
>> 
>> 
>> 
>>> On 15. 05. 19 19:57, Bob Harold wrote:
>>> 
>>> On Wed, May 15, 2019 at 1:00 PM John Levine >> > wrote:
>>> 
>>>In article <064ba295-f3dd-46e4-86a9-e03cf68eb...@sinodun.com
>>>> you write:
 -=-=-=-=-=-
 
 Hi,
 
 In the spirit of deprecating things I have submitted a draft to
>>>deprecate the status opcode.
>>> 
>>>RFC 1034 says it's "To be defined" so this seems a little premature.
>>> 
>>>Other than that, go for it.
>>> 
>>> 
>>> Does this increase or decrease the 'camel' page count?
>> 
>> Personally I think it is not worth the effort, it will just add one more
>> RFC to read and does not help the protocol maintenance.
>> 
>> I would say that it is better to have one "cleanup" RFC instead of
>> one-off doc with one useful paragraph in it. With one bigger document we
>> could say to newcommers "this is list of things you can ignore when you
>> encounter them in pile of DNS RFCs".
>> 
> 
> In a perfect world, we'd have occasional complete rewrites like what
> happened with RFCs 821, 2821, 5321 and RFCs 822, 2822, 5322
> 
> 
> 
> -- 
> Michael Sheldon
> Dev-DNS Services
> GoDaddy.com
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Minimum viable ANAME

[tjw ietf]

No

I said I want to reset and work toward an interim. 

>From my high tech gadget

> On Mar 26, 2019, at 15:35, Olli Vanhoja  wrote:
> 
> Did someone say that there will be a side meeting about mvp ANAME
> during this week? If so, I couldn't find that from the calendar.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

[tjw ietf]

From my high tech gadget

> On Nov 8, 2018, at 06:30, Ray Bellis  wrote:
> 
>> On 08/11/2018 04:13, Tim Wicinski wrote:
>> 
>> I can't stress this enough - when you see ALIAS records at zone cuts
>> that point to a database server, already, then we've missed the
>> "server specific" ball.
> 
> This sounds like it ought to be a very unusual configuration.
> 
> Even with a zone cut, couldn't those DB servers have been addressed as 
> 'db.' instead?

Sure but as more than one engineer whose been using this for several years asks 
“why should I change? This works now and you’re just cramping engineering 
velocity. “

And saying “it’s not standard” doesn’t hold water. Sure there are migration 
issues but if folks stay in their vendor ecosystem

These are the questions we as operators are asked regularly. These are the 
questions  DNSOP need to look forward on. 



> 
>> And can someone show a significant number of SRV examples outside of
>> SIP and some gaming servers?
> 
> Kerberos and AD both use SRV records.  Bonjour uses SRV extensively.

I forgot about AD. Those are set up by admins right?

Doesn’t Bonjour create those records behind the scenes? 

People are saying a domain owner is going to log into godaddy and configure a 
SRV record. 

If you want to convince me SRV will work get the vendors to support it 
seamlessly. 


> Either way, SRV is only one of three different ways that services are 
> differentiated (per 5507).
> 
> Ray
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[tjw ietf]

Oh folks like my employer where half of the security teams scream and say no, 
and the other half want to see to collect threat intelligence information. 

From my high tech gadget

> On Jul 28, 2018, at 15:43, Ondřej Surý  wrote:
> 
> @ISC, we have been discussing this since we started implementing RZ local 
> copy and it’s not that simple.
> 
> There are at least two problems with BitTorrent:
> 
> a) the hash has to be independent to zone, so either the hash has to reside 
> outside of the root zone, or the root zone file would have to be 
> reconstructed with “the torrent hash” and “the torrent data”; generally you 
> would want the hash to be signed, so the TORRENT RR + RRSIG would have to be 
> distributed outside of the data received via BitTorrent
> 
> b) to be effective, most of the peers would have to seed, and I am not sure 
> if the places that would benefit the most would be the places where operators 
> would be willing to seed
> 
> Ondrej
> --
> Ondřej Surý — ISC
> 
>> On 27 Jul 2018, at 16:57, Bob Harold  wrote:
>> 
>> 
>>> On Thu, Jul 26, 2018 at 11:07 PM Mark Andrews  wrote:
>>> 
>>> 
>>> > On 27 Jul 2018, at 12:39 pm, Steve Crocker  wrote:
>>> > 
>>> > The passage below puzzles me.  Why do you want servers to get the root 
>>> > zone from less trusted sources?
>>> 
>>> 1) to spread load.
>>> 2) not all recursive servers have direct access to authoritative sources..  
>>> Some times they need to go through intermediaries.  The same will be true 
>>> with transfers of the root zone.
>> 
>> Maybe I am wrong, but having lots of servers all around the world asking for 
>> the same update at the same time looks like a good place to use bittorrent.  
>> (Is that reasonable?)  So the 'sources' will be untrusted, and we do need 
>> some way to verify the resulting file that we get..
>> 
>> I like the XHASH idea, it seems to reduce the work required on each update.  
>> But I would be ok with ZONEMD also.
>> 
>> -- 
>> Bob Harold
>>  
>>> >  And why does the source matter if the zone entries are DNSSEC-signed?
>>> 
>>> Steve please go and re-read the parts you cut out when quoting the previous 
>>> message.  It gave several reasons.
>>> 
>>> Also please look at what is and isn’t signed in a zone and think about what 
>>> can be done when you can change the unsigned parts.
>>> 
>>> Also think about what can be done when you change the signed parts but 
>>> don’t individually verify the RRsets but rather just trust the zone content.
>>> 
>>> I have a local copy of the root zone.  It lives in a seperate view which is 
>>> not accessed directly by clients  The name server validate its contents 
>>> when performing recursive lookups on behalf of clients.  Such 
>>> configurations are complicated and error prone.  It also doesn’t remove 
>>> potential privacy leaks.
>>> 
>>> Having a way to verify the entire zone’s contents without having to verify 
>>> every RRset individually after each zone transfer would make running such 
>>> configurations easier.  It also removes threats that DNSSEC alone does not 
>>> remove. 
>>> 
>>> > Thanks,
>>> > 
>>> > Steve
>>> > 
>>> > Sent from my iPhone
>>> > 
>>> >> On Jul 26, 2018, at 7:33 PM, Mark Andrews  wrote:
>>> >> 
>>> >> Additionally most nameservers treat zone data as fully trusted.  This is 
>>> >> reasonable when you are getting data from a “trusted" source.  For the 
>>> >> root zone we want servers to be able to get a copy of the zone from a 
>>> >> untrusted / less trusted source.
>>> 
>>> -- 
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] QNAME minimisation on the standards track?

[tjw ietf]

I’d like to see a more fleshed out operational considerations section.  

Tim
As chair 

From my high tech gadget

> On Jul 17, 2018, at 08:14, Stephane Bortzmeyer  wrote:
> 
> Greetings. With more resolvers implementing QNAME minimisation, and
> even turning it on by default, we thought that this is a good time to
> update RFC 7816 and make it a standard. In order to get things moving,
> we have published a very early draft draft-bortzmeyer-rfc7816bis-00
> that is mostly the original RFC but with a few questions and holes
> added (see the text near the strings "TODO"). If folks in the WG is
> interested, feel free to comment in the non-GitHub repo listed in the
> draft, or here on the list.
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[tjw ietf]

With all of you here. 

As an Operator who gets these requests regularly (just 10 minutes ago!) when 
you tell users the  world of BIND/PowerDNS/NSD/Knot do not support such a 
mechanism they say “we’re off to use route 53. okthxbai “

I find it personally appalling we can spend so many cycles injecting dns into 
http but we can’t be bothered to fix what end users want. 

Tim
Just an infrastructure operations person. 
From my high tech gadget

> On Jun 19, 2018, at 10:20, Tony Finch  wrote:
> 
> Petr Špaček  wrote:
>> 
>> Given that resolver side somehow works already ...
>> could we standardize this obvious violation of RFC 1035?
> 
> The feature I would like is CNAME and other data (typically CNAME + MX +
> TXT), because I have a lot of deeply hierarchial subdomains in my main
> zone. CNAME at apex does not need to be (and I think should not be treated
> as) a special case.
> 
> As I understand it, in the RFC 883 era, CNAME was allowed to coexist with
> other records, but that led to consistency problems. eg, if you have a
> CNAME cached for a particular name, and you get a query for MX at the same
> name, do you go and ask the CNAME's owner or its target for the MX? And do
> you get a different answer to the MX query when you don't have a CNAME
> cached?
> 
> My guess is that it was hard to fix this at the time because the semantics
> of negative cache entries was not well developed (e.g. RFC 1034 section
> 4.3.4 says it was still a new and experimental feature). For
> CNAME-with-siblings to work, a resolver needs to remember whether it
> already asked for the other data, for each RR type. 1980s caches couldn't
> do this, so CNAMEs were made exclusive instead.
> 
> I think the resolver's algorithm for handling CNAMEs can be updated to
> allow CNAME-with-siblings and preserve compatibility. There will be some
> latency cost for later queries that can no longer immediately follow the
> CNAME shortcut. NSEC/NSEC3 records could be used to eliminate this cost.
> 
> I'm much less sure about whether it's possible to publish
> CNAME-with-siblings in a reliably compatible way. I would feel a lot more
> comfortable with an ANAME implementation that copies the sibling records
> from the target to the owner when the zone is published or signed.
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Trafalgar: Cyclonic, mainly northeasterly in northwest, 5 to 7. Slight or
> moderate until later in southeast, otherwise moderate or rough. Thundery
> showers, fog patches later. Moderate or good, occasionally very poor later.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for Adoption: draft-dupont-dnsop-rfc2845bis

[tjw ietf]

This draft was widely accepted in Singapore, and the chairs were waiting for
a revision before starting a call for adoption. That revision took a few
months
but it has been done and DNSOP is ready to start a call for adoption.

This draft addresess the bug found in the existing RFC.

This starts a Call for Adoption for draft-dupont-dnsop-rfc2845bis

The draft is available here:
https://datatracker.ietf.org/doc/draft-dupont-dnsop-rfc2845bis/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 23:59 24 April 2018

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] raising the bar: requiring implementations

[tjw ietf]

What is work: An "informational" document being used as standard is people
taking a submitted (expired) draft as "standard"?

Tim





On Thu, Apr 5, 2018 at 1:39 PM, 神明達哉  wrote:

> At Wed, 4 Apr 2018 11:22:33 +0200,
> Petr Špaček  wrote:
>
> > >> This is actually quite a good example of another problem:
> > >> Client-subnet was documented for Informational purposes; it was
> > >> already in wide use in the public internet and had an EDNS opt code
> > >> codepoint allocated from the IANA registry.
> > >>
> > >> Nothing that happened in DNSOP or the IETF changed that, and I
> > >> strongly suspect nothing that happened in DNSOP or the IETF could have
> > >> changed it.
> > >
> > > We found issues in the client-subnet description (in the draft stages)
> > > that were corrected before it became RFC - this involved some
> behavioral
> > > changes. However, the opportunity was not given to address fundamental
> > > design issues, so what's in the RFC largely documents the
> > > implementations preceding it and still has issues. I didn't think
> > > client-subnet was in wide use when it came to dnsop. Even today it
> > > doesn't look like it's in wide use.
>
> [...]
>
> > I tend to agree with Mukund. What's the point of doing standards, if
> > there is nothing to test against?
>
> I also agree here.  Especially in the case of client-subnet, I
> observed another (IMO) bad practice that seems to be abused quite
> often recently: use the word of "informational" as an excuse for
> dismissing suggestions.  The commonly seen logic is "this is just
> intended to be an information document, just describing an existing
> deployment in case that may be useful for others (and so any
> significant changes should be rejected)".  But in actuality such a
> spec is often used as a standard protocol spec that should be
> interoperable among various different implementations.  And, IMO, that
> was actually the case for ECS.
>
> Another rhetoric often (ab)used in such a case is to say "a more
> complete full standard will follow this informational document; we can
> make significant changes at that point."  But in reality such a
> followup task often doesn't even start.  Again, that's also the case
> for ECS after nearly two years since the publication of RFC7871.
>
> In the context of the camel discussion, I think we should use this
> lesson for rejecting this kind of abusing the "informational" status.
> We should not pretend it's really just for information when we
> actually expect it will be used a "de facto" standard that is likely
> to be implemented by various vendors.
>
> --
> JINMEI, Tatuya
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

[tjw ietf]

Thanks Job for keeping *me* straight.

Tim

On Thu, Apr 5, 2018 at 1:15 PM, Job Snijders <j...@ntt.net> wrote:

> Hi all,
>
> While the chair notes awareness of the point I raised, I’d like the be
> explicit to avoid any confusion.
>
> This document is *not* ready for publication. There is no implementation
> report available for review and consideration.
>
> Should the working group produce an implementation report and demonstrate
> multiple implementations before April 15th, I’d ofcourse be willing to
> reconsider my position.
>
> Kind regards,
>
> Job
>
> On Thu, 5 Apr 2018 at 18:36, tjw ietf <tjw.i...@gmail.com> wrote:
>
>>
>> After walking through the 168 emails on this draft in the inbox, I feel
>> we're ready to take this to WGLC.
>>
>> (We are aware of the two points raised my Job and Paul)
>>
>>
>> This starts a Working Group Last Call for:  draft-ietf-dnsop-kskroll-
>> sentinel
>>
>> Current versions of the draft is available here:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
>>
>> The Current Intended Status of this document is: Proposed Standard
>>
>> In the brushing of the camel, the draft is focused on determining if
>> a particular root key has been loaded into resolvers.
>>
>> Please review the draft and offer relevant comments.
>> If this does not seem appropriate please speak out.
>> if someone feels the document is *not* ready for publication, please
>> speak out with your reasons.
>>
>> This starts a two week Working Group Last Call process, and ends on:
>>  23:59 19 April 2018
>>
>> thanks
>> tim
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

[tjw ietf]

After walking through the 168 emails on this draft in the inbox, I feel
we're ready to take this to WGLC.

(We are aware of the two points raised my Job and Paul)


This starts a Working Group Last Call for:  draft-ietf-dnsop-kskroll-
sentinel

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

The Current Intended Status of this document is: Proposed Standard

In the brushing of the camel, the draft is focused on determining if
a particular root key has been loaded into resolvers.

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
if someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  23:59
19 April 2018

thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNSOP Minutes IETF101

[tjw ietf]

Hi

I uploaded the minutes the other day and failed to send the email

Big props to Paul Hoffman on taking notes.

Take a look and make sure you were quoted fairly

https://datatracker.ietf.org/meeting/101/materials/minutes-101-dnsop-00

I left a copy here for the git-inclined

https://github.com/DNSOP/wg-materials/blob/master/dnsop-ietf101/dnsop-ietf101-minutes.txt

The chairs want to thank everyone for making the two sessions pretty
awesome.  We love the energy and enthusiasm and ideas which came out of the
sessions.   I know I enjoyed meeting folks I had not met before, and
running into a few old faces.   What we do want is people focusing on the
content and the presentation.   Don't feel constrained by process, real or
imagined.  My normal way of handling 'process' discussions is to fling them
at our Area Directors, who are paid the big bucks to sort them out (my
co-chair does not fling).

and we'll have a camel naming contest

thanks again. y'all are the best.

Tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] raising the bar: requiring implementations

[tjw ietf]

An enterprise company with rather large zone which update often are "highly
interested" in MIXFR.
But we may be the exception rather than the rule.

Tim

On Wed, Mar 28, 2018 at 11:24 AM, bert hubert 
wrote:

> On Wed, Mar 28, 2018 at 08:49:39PM +0530, Mukund Sivaraman wrote:
> > I'd raise the bar even higher, to see complete implementation in a major
> > open source DNS implementation when it applies. Sometimes implementation
> > problems are very revealing (client-subnet should have gone through
> > this).
>
> Well to allow the one remaining closed source DNS implementation some room,
> I think we could live with a 'demo' from them if they'd want to. This would
> lead to an implementation report, much like is customary in the BGP WGs.
>
> But otherwise, +100.
>
> This might go for MIXFR which we are discussing now btw.  It looks nice in
> theory, but I wonder about the practice, and if the people who want this
> (TLD operators I guess) would be willing to test it in simulated production
> to see if it fits their needs.
>
> Bert
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] raising the bar: requiring implementations

[tjw ietf]

I would say that most things we have adopted in the past few years do have
some implementations to reference.
Not when drafts are adopted, but generally before we head to WGLC I've
always wanted to see someone
who implemented the option in some manner.

But yes, agree.

On Wed, Mar 28, 2018 at 10:52 AM, Willem Toorop  wrote:

> I would love to see a hard requirement for implementations &
> implementation reports (like IDR has) in the charter or in the working
> group house rules.  Early implementations (perhaps even during the
> hackathon) can reveal implications that might have been missed while
> designing the draft.  In addition it is a good way to see if everybody
> interprets a draft the same way, by interoperability testing.
>
>
> Op 24-03-18 om 12:07 schreef Job Snijders:
> > Dear DNSOP,
> >
> > I'd like to share some pointers from the working group that governs the
> > BGP protocol, IDR, on requiring implementations before drafts can
> > advance towards RFC publication. Raising the bar for publication will
> > take weight off the camel's back.
> >
> > The IDR policy and rationale is outlined here:
> https://trac.ietf.org/trac/idr/wiki
> >
> > An example of an implementation report is available here:
> > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-large-
> community%20implementations
> > Every normative (RFC 2119 / RFC 8174) term should expand into a
> > compliance test, and it is particularly good to document where
> > implementations deviate from what is required or suggested in the
> > proposed specification. The work listed on this wikipage was done
> > _before_ the draft was submitted to the IESG, and we intentionally
> > sought to create more than the minimum amount of implementations
> > required.
> >
> > In the case of the BGP large communities project the working group was
> > particularly lucky because Pier Carlo Chiodi created an open 'regression
> > testing'-style environment into which BGP speakers could be plugged in
> > to assess their compliance:
> > https://github.com/pierky/bgp-large-communities-playground
> > https://github.com/pierky/bgp-large-communities-playground/
> blob/master/tests/README.md
> >
> > The DNS world would benefit from such environments and automated
> > compliance testing. Manual testing for a specification (that is still
> > being worked on) can be tedious, having a 'playground' can pay huge
> > dividend. We did catch bugs in implementations thanks to this
> > environment, so it not only helped the specification, but increased the
> > quality of the participating implementations.
> >
> > RFC 7942 suggest that During the development of a draft people are
> > encouraged to document what implementations exist, an example is here:
> > https://tools.ietf.org/html/draft-ietf-idr-large-community-12#section-7
> >
> > Closed source implementations as part of such a list is not an issue
> > (just a little bit more work), at IETF meetings we'd meet up, plug
> > laptops with virtual machines into each other and run compliance tests.
> > Sidenote: when IANA codepoints are needed but not yet assigned, don't
> > forget to keep everything on separate beta/feature branches; don't ship
> > software with squatted codepoints :-)
> >
> > The DNSOP working group will have to figure out what constitutes a
> > meaningful implementation in what context. For example, a tcpdump or
> > wireshark decoder would hardly count as an implementation of a proposed
> > DNS feature, but those decoders are _incredibly_ useful to have
> > alongside real implementations, especially during development. DNS
> > people will probably want to see multiple implementation reports in
> > context of packet decoding, stub, resolver, and authoritative.
> >
> > Kind regards,
> >
> > Job
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Current DNS standards, drafts & charter

[tjw ietf]

I should qualify my comments on Route 53 - I don't think they are something
we should emulate, more of an example of how 3rd party vendors get away
with an overly-minimal set of resource records.   The words I have to
describe them are generally not polite.

Tim


On Wed, Mar 28, 2018 at 4:38 AM, Tim Wicinski  wrote:

>
> I have looked at the same problem Bert has, but he did present it much
> better than I could.  When I started thinking about this, I approached it
> from the point of view of "If I have to give a co-worker a document on how
> to build a DNS Server (Authoritative or Resolver), what would I need to
> give them".   I also have spent a lot of time watching the 793bis work in
> TCPM, which has been moving along slowly and methodically.  I felt what we
> would come up with would be
> 1. a DNSOP document which would be an implementation list for building
> an Authoritative or Resolver
> 2. a roadmap to work on 1034bis and 1035bis, which would be a new WG.
>
> I also realized that the second item would be brutal, painstaking, not
> "sexy" for most IETF standard types.
>
> I've had lots of experience dealing with the concept of "technical debt"
> and a lot of this is very similar.  But we also need someone who has the
> skill set of a project manager, who knows how to lay out workflows.  That's
> not something a bunch of programmers always have.
>
> Summary - Paul is on the right track here.A good example is looking at
> what Route 53 implements (for better or for worse) and realize they
> implement some real minimal subset.   I think it's too small, but it's an
> interesting argument.
>
> tim
>
>
>
>
> On 3/27/18 17:33, Paul Vixie wrote:
>
>> i see no purpose in change documents, which would add to the set of
>> things a new implementer would have to know to read, and then to read.
>>
>> rather, we should focus on a DNSOP document set that specifies a minimum
>> subset of DNS which is considered by the operational community to be
>> mandatory to implement. any implementer can remove anything else and still
>> be checklist-compatible when customers are baking things off.
>>
>> if someone wants to implement iquery or WKS let that be crazy rather than
>> broken -- on-the-wire patterns still described, code points still reserved,
>> but unlikely to find anybody to actually interoperate with.
>>
>> vixie
>>
>> re:
>>
>> Matthew Pounsett wrote:
>>
>>>
>>>
>>> On 27 March 2018 at 03:49, Ondřej Surý >> > wrote:
>>>
>>>
>>> Again, from experience from dnsext, I would strongly suggest that
>>> any work in this area is split into CHANGE documents and REWRITE
>>> documents, with strict scope. Documents rewriting existing RFCs
>>> while adding more stuff at the same time tend to not reach the
>>> finish line.
>>>
>>> Does this include combining documents?  For example, it would probably
>>> make sense to combine some of the clarifications documents into any
>>> rewrite of 1034/1035.
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Current Document status,

[tjw ietf]

All

In advance of today's meeting, here's where we have our current document
status.  Comments, etc to the chairs

Tim




# DNSOP Chairs Status
 Updated: 20 March 2018

# Done

## WG chairs Work

* [draft-ietf-dnsop-rfc5011-security-considerations]
- update to reflect Victor's comments
- Write up and move forward

* [draft-ietf-dnsop-isp-ip6rdns]
- 1 week WGLC

* [draft-ietf-dnsop-refuse-any]
- will confirm authors resolved issues, 1 Week WGLC

* [draft-ietf-dnsop-alt-tld](
https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-09)
- W-T-F

## In WGLC

* [draft-ietf-dnsop-session-signal]
- Updates addressed during WGLC

* [draft-ietf-dnsop-let-localhost-be-localhost]
- WGLC over waiting on Authors...

## current WGLC Order

* [draft-ietf-dnsop-dns-capture-format]
- version 06 appears ready for WGLC

* [draft-ietf-dnsop-kskroll-sentinel]
- Updates since last version, ready for WGLC

* [draft-ietf-dnsop-terminology-bis]
- tentatively mid-April 2018 for WGLC

## Adopted

* [draft-ietf-dnsop-attrleaf]
- Authors published update, splitting document

* [draft-ietf-dnsop-aname](
https://tools.ietf.org/html/draft-ietf-dnsop-aname-01)
- Authors want to split into 2 drafts (per talk)

* [draft-ietf-dnsop-extended-error]
- Authors owe an update, and ready for WGLC

* [draft-ietf-dnsop-serve-stale]
- May be too contentious?

* [draft-ietf-dnsop-dns-tcp-requirements]
- Section 4 and 5.3 TODOs

## Call for Adoption

* [draft-dupont-dnsop-rfc2845bis
- Yes

## What Happened

* [draft-wouters-sury-dnsop-algorithm-update
- Adopted by WG 2017-03-16, but no new version

## Candidates For Adoption

## Documents Worth Considering

* [draft-bellis-dnsop-xpf

* [draft-huque-dnsop-multi-provider-dnssec

* [draft-gavrichenkov-dnsop-dnssapi

* [draft-muks-dnsop-dns-catalog-zones
- stronger drive

* [draft-pwouters-powerbind

* [draft-jabley-dnsop-bootstrap-validator

* [draft-woodworth-bulk-rr

## Needs more Review

## Expired

* [draft-song-dns-wireformat-http
- new version, should push forward and/or why

* [draft-ietf-dnsop-no-response-issue
- author will upload new version
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

[tjw ietf]

Dave

First, thanks for resurrecting this for us.   I think splitting draft into
two parts probably makes sense after that last round of comments.

However, we need to go find those App Area folks (hence cc'ing Murray here)
and run this past them.

If the group likes this split, we can progress attrleaf first and give you
time to work on the second document.

Tim


On Tue, Mar 20, 2018 at 12:35 AM, Dave Crocker  wrote:

> Folks,
>
> I'll limit what should be an extensive and elaborate apology to just this:
> I'm sorry for the year of inactivity.
>
> The -03 version should provide some useful substance of progress.
>
> I've gone over last summer's comments and the -03 version should reflect
> what the wg agreed to.  Basically, it has been significantly streamlined,
> essentially to reflect a clean-sheet model of the world. That is, it
> doesn't deal with the ugliness that SRV, et al, created.  It merely
> establishes the two registries we need, long term, and populates them.
> This document should have continuing utility.
>
> -03 defines two registries, 'global' and 'second-level'.  I'm suspicious
> of how short the global one is, though it does make sense.
>
> As noted in the document, absent major concerns with the substance of the
> document, please send me or the list s/old/new/ types of change
> suggestions, and if the change is for a reference, I'd love the suggestion
> to be  xml...
>
>
> A second document will attempt to fix up the uglinesses in some existing
> documents, to get them to align with a world that has these registries. It
> should be viewed as a transitional document, though we all know how glacial
> 'transitions' are in the Internet...
>
> Deciding how to pursue that reasonably has been the effort.  The changes
> this 'fixes' document defines will be to documentation, but not to existing
> operation.  Existing uses in the field will be preserved.
>
>
> Here's the approach I'm taking:
>
>
> 1. Simple underscore usage
>
>For many/most specifications that use underscore naming, the text
> merely says to use it.  They are straightforward.
>
>These specifications need to be listed in this document, explicitly, so
> that later updates to them will know to deal with the revisions called for
> by this document.
>
>But this document doesn't really need s/old/new kinds of precise detail
> for them. Rather than provide precise language for changing each of these,
> I propose to provide some generic text, and generic IANA Considerations.
> This will permit this Fixes document to be cited as Updating those RFCs.
>
>
> 2. SRV and URI
>
>These need more detailed text, very much in the s/old/new style.
>
>The current text in them does a use-by-reference of existing tables
> defined for other purposes.  The Update text will, instead, specify a
> requirement for adding entries in the Global or Common Second-Level
> registries.
>
>
> d/
>
>
>  Forwarded Message 
>
> Name:   draft-ietf-dnsop-attrleaf
> Revision:   03
> Title:  DNS Scoped Data Through '_Underscore' Naming of Attribute
> Leaves
> Document date:  2018-03-19
> Group:  dnsop
> Pages:  14
> URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-03.txt
> Status: https://datatracker.ietf.org/
> doc/draft-ietf-dnsop-attrleaf/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-03
> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-03
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNSOP Presentation "The Camel"

[tjw ietf]

All

At the end of Tuesday's session we're having Bert Hubert from Power DNS
give a talk on what he views "The Camel".   He sent us a short abstract:


"In past years, DNS has been enhanced with DNSSEC, QName Minimization, EDNS
Client Subnet and in-band key provisioning through magic record types.  It
is now also seeing work on 'DNS Stateful Operations', XPF, ANAME (ALIAS),
resolver/client encryption, resolver/authoritative encryption & KSK
signalling/rollovers.
Each of these features interacts with all the others. Every addition
therefore causes a further combinatorial explosion in complexity.
Up to now, the increase in DNS complexity (mostly driven by DNSSEC) has been
made possible by the huge pool of programming talent, mostly in the open
source world.
This presentation sets out, with examples, how innoccuous features
contribute
to the combinatorial rise of complexity, and how we might ponder thinking
twice before loading up this camel further."



https://datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-00

Now, before everyone jumps into the deep end here, we suggest one read RFC
8324, published February of this year https://tools.ietf.org/html/rfc8324 by
John Klensin.   John discusses very similar subject matter. Bert's talk has
a more "operational" focus, which is what caught this chair's eye (since
many in the WG worry about operational issues).  I believe the authors
would agree they are complementary in nature.

(If I am incorrect, the authors are free to castigate me)

thanks
Tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-bootstrap-validator-00.txt

[tjw ietf]

I will say that I tolerate Joe's hand waving, I can't speak for my
co-chair.



On Mon, Mar 19, 2018 at 3:14 PM, Joe Abley  wrote:

> Hi all,
>
> This draft from 2011 emerged blinking into the sunlight from the grave
> where it expired, growling something about KSK rollovers and brains. Dave
> and I promptly wrestled it to the ground and locked it in the datatracker
> where we can safely poke sticks at it through the reinforced metal bars.
>
> The original draft contained this prescient language:
>
>The possibility remains, however, that [RFC5011] signalling will not
>be available to a validator: e.g. certain classes of emergency KSK
>rollover may require a compromised KSK to be discarded more quickly
>than [RFC5011] specifies, or a validator might be off-line over the
>whole key-roll event.
>
>This document provides guidance on how DNSSEC Validators might
>determine an appropriate set of trust anchors to use at start-up, or
>when other mechanisms intended to allow key rollover to be tolerated
>gracefully are not available.
>
> Dave and I imagine this kind of thinking might be relevant and timely. Tim
> and Suz have kindly tolerated my increasingly frantic handwaving on this
> subject and have offered me some minutes in the dnsop meeting tomorrow,
> where I intend to suggest that a specification along these lines is
> necessary and that the working group should take this on.
>
>
> Joe
>
> Begin forwarded message:
>
> *From: *internet-dra...@ietf.org
> *Subject: **New Version Notification for
> draft-jabley-dnsop-bootstrap-validator-00.txt*
> *Date: *19 March 2018 at 14:59:53 GMT
> *To: *"Joe Abley" , "Dave Knight" <
> dave.knight@team.neustar>
>
>
> A new version of I-D, draft-jabley-dnsop-bootstrap-validator-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
>
> Name: draft-jabley-dnsop-bootstrap-validator
> Revision: 00
> Title: Establishing an Appropriate Root Zone DNSSEC Trust Anchor at
> Startup
> Document date: 2018-03-19
> Group: Individual Submission
> Pages: 9
> URL:https://www.ietf.org/internet-drafts/draft-
> jabley-dnsop-bootstrap-validator-00.txt
> Status: https://datatracker.ietf.org/doc/draft-jabley-
> dnsop-bootstrap-validator/
> Htmlized:   https://tools.ietf.org/html/draft-jabley-dnsop-
> bootstrap-validator-00
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-
> jabley-dnsop-bootstrap-validator
>
>
> Abstract:
>   Domain Name System Security Extensions (DNSSEC) allow cryptographic
>   signatures to be used to validate responses received from the Domain
>   Name System (DNS).  A DNS client which validates such signatures is
>   known as a validator.
>
>   The choice of appropriate root zone trust anchor for a validator is
>   expected to vary over time as the corresponding cryptographic keys
>   used in DNSSEC are changed.
>
>   This document provides guidance on how validators might determine an
>   appropriate trust anchor for the root zone to use at start-up, or
>   when other mechanisms intended to allow key rollover to be tolerated
>   gracefully are not available.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for minute takers and jabber scribes

[tjw ietf]

Hi

As we get closer to Tuesday, I'd like to put out a call for minute takers
and jabber scribes for DNSOP session.  (We'll worry about thursday on
Wednesday).

thanks
Tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Agenda for DNSOP, IETF101

[tjw ietf]

Hi

Here is the agenda we had just posted.  Rough drafts will been sitting in
the
DNSOP GitHub repo as well.

Final edits will happen over the weekend.
We expect slides by Monday afternoon.


# DNS Operations (DNSOP) Working Group
## IETF 101, London
### Session I

* Date: 20 March 2018
* Time: 15:50-18:20 (GMT)
* Room: Sandringham

* Chairs: Tim Wicinski 
* Chairs: Suzanne Woolf 

* Secretary: Paul Hoffman 

* IESG Overlord: Warren Kumari 

* [DocList](https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html)
* [DataTracker](https://datatracker.ietf.org/wg/dnsop/documents/)

---
## Agenda

### Administrivia

* Agenda Bashing, Blue Sheets, etc,  10 min

* Updates of Old Work, Chairs, 10 min

---
### Current Working Group Business

* draft-ietf-dnsop-terminology-bis, 15 min

* draft-ietf-dnsop-session-signal, 10 min

* draft-ietf-dnsop-refuse-any,   10 min

* draft-ietf-5011-security-considerations, 10 min
(if needed)

* draft-ietf-dnsop-aname15

* draft-ietf-dnsop-kskroll-sentinel 10

* draft-ietf-dnsop-dns-capture-format   10


---
### New Working Group Business

* The DNS Camel, Hubert, 15


### Session II
* Date: 22 March 2018
* Time: 18:10-19:10
* Room: Sandringham


* draft-huque-dnsop-multi-provider-dnssec

* draft-gavrichenkov-dnsop-dnssapi

* draft-muks-dnsop-dns-catalog-zones

(others)
---
###  List of Drafts

* draft-gavrichenkov-dnsop-dnssapi
https://datatracker.ietf.org/doc/draft-gavrichenkov-dnsop-dnssapi/

* draft-ietf-dnsop-refuse-any
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

* draft-ietf-dnsop-session-signal
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/

* draft-ietf-dnsop-terminology-bis
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/

* draft-ietf-dnsop-dns-capture-format
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/

* draft-ietf-dnsop-aname
https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/

* draft-ietf-dnsop-kskroll-sentinel
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

* draft-huque-dnsop-multi-provider-dnssec
https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/


* Date: 22 March 2018
* Time: 18:10-19:10
* Room: Sandringham
# DNS Operations (DNSOP) Working Group
## IETF 101, London
### Session I 

* Date: 20 March 2018
* Time: 15:50-18:20 (GMT)
* Room: Sandringham

* Chairs: Tim Wicinski 
* Chairs: Suzanne Woolf 

* Secretary: Paul Hoffman 

* IESG Overlord: Warren Kumari 

* [DocList](https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html)
* [DataTracker](https://datatracker.ietf.org/wg/dnsop/documents/)

---
## Agenda

### Administrivia 

* Agenda Bashing, Blue Sheets, etc,  10 min

* Updates of Old Work, Chairs, 10 min

---
### Current Working Group Business

* draft-ietf-dnsop-terminology-bis, 15 min

* draft-ietf-dnsop-session-signal, 10 min 

* draft-ietf-dnsop-refuse-any,   10 min 

* draft-ietf-5011-security-considerations, 10 min
(if needed) 

* draft-ietf-dnsop-aname15

* draft-ietf-dnsop-kskroll-sentinel 10

* draft-ietf-dnsop-dns-capture-format   10
 

---
### New Working Group Business

* The DNS Camel, Hubert, 15


### Session II
* Date: 22 March 2018
* Time: 18:10-19:10
* Room: Sandringham 


* draft-huque-dnsop-multi-provider-dnssec

* draft-gavrichenkov-dnsop-dnssapi


* draft-muks-dnsop-dns-catalog-zones

(others)
---
###  List of Drafts

* draft-gavrichenkov-dnsop-dnssapi
https://datatracker.ietf.org/doc/draft-gavrichenkov-dnsop-dnssapi/

* draft-ietf-dnsop-refuse-any
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

* draft-ietf-dnsop-session-signal
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/

* draft-ietf-dnsop-terminology-bis
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/

* draft-ietf-dnsop-dns-capture-format
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/

* draft-ietf-dnsop-aname
https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/

* draft-ietf-dnsop-kskroll-sentinel
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

* draft-huque-dnsop-multi-provider-dnssec
https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/


* Date: 22 March 2018
* Time: 18:10-19:10
* Room: Sandringham 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

[tjw ietf]

(speaking not as chair but DNS operator)

At the last OARC, my co-worker did a lightning talk on his deployment of
MetaZones
(
https://indico.dns-oarc.net/event/27/session/7/contribution/39/material/slides/0.pdf
)

He attempted to contact the authors of the catalog-zones draft (as did I)
to talk about why this draft has some
deficiencies. but never heard back.   I felt this metazone work (which we
are efforting to open source through our employer)
should be given a deeper look.

The main problem I see is your exmaples always talk of "1 Primary DNS
Server and 1 (or more) DNS Secondary servers"
I would argue this is a severely outdated operational view, and to me feels
that you are out of touch with what
operators are actually deploying these days.

Tim
(again as myself)

On Sat, Mar 10, 2018 at 1:46 PM, Tony Finch  wrote:

> Mukund Sivaraman  wrote:
>
> > We settled on using a zone representation as it used existing zone
> > transfer protocol (and authorizations) and would involve minimal changes
> > for both implementations and operations vs. inventing a new protocol.
>
> I want to emphasize this point.
>
> In my previous job running MXs it was amazingly easy to do in-band SMTP
> call-forward address verification - one configuration was able to verify
> addresses at dozens of departmental mail servers with all sorts of
> different configurations. Trying to talk to each department's LDAP service
> (if they had one) would have been a nightmare.
>
> In my current job, I can provide a catalog zone and a bit of configuration
> advice to make it much simpler for my colleagues to run stealth
> secondaries - no need for them to adjust firewalls or scripts etc.
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
> punycode
> Fair Isle, Faeroes, Southeast Iceland: Easterly or northeasterly 5 to 7,
> occasionally gale 8 in Fair Isle. Moderate or rough, occasionally very
> rough
> later. Rain or showers. Good, occasionally poor.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Second Call for Agenda Time in London and Submission Reminder

[tjw ietf]

All

Just another call for those looking for Agenda time to drop the chairs a
note (and a thank you to those who have done so, follow ups shortly).

Also a reminder the draft cutoff is this Monday, March 5th at 2359 UTC
(1859 EST, 1559 PST and 0859 JST March 6th).   Please get your drafts in
before then.

thanks, and see you in London

Tim
Suzanne
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal

[tjw ietf]

The WGLC last call for session-signal has ended. I was on a conference call
with the Authors yesterday, and they were addressing all open items, with
the plan of releasing an updated version in the next day or so.

Once this version is published, we'll ask all who submitted comments to
confirm they have been addressed adequately, before moving on.

thanks

Tim


On Thu, Feb 1, 2018 at 2:14 PM, tjw ietf <tjw.i...@gmail.com> wrote:

>
> This starts a Working Group Last Call for draft-ietf-dnsop-session-signal
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/
>
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons.
>
> We are doing a three week Working Group Last Call process, and we're cross
> posting to a few groups where we hope to receive some strong reviews.
>
> This WGLC ends at midnight, 22 February 2018.
>
> thanks
> Tim/suzanne
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Pinging the Attribute Leaf

[tjw ietf]

I'm adding Dave as we have been in contact with him.   He had taken the
last set of responses and was
working on how to integrate them into the draft.   We keep hoping he will
have something soon, or will
reach out for assistance.

Dave?

Tim



On Tue, Feb 20, 2018 at 9:41 AM, Stephane Bortzmeyer 
wrote:

> Any news of adopted draft draft-ietf-dnsop-attrleaf? It seems there
> was a wide agreement, but it expired four months ago.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any

[tjw ietf]

The Badgering will continue!

We're waiting because the chairs feel we can do a short WGLC and have this
ready to go before London.

Thank you all for adding pressure.

Tim

On Mon, Feb 12, 2018 at 10:41 AM, Joe Abley  wrote:

> On 12 Feb 2018, at 06:30, Tony Finch  wrote:
>
> > Paul Wouters  wrote:
> >>> On Feb 9, 2018, at 20:22, Joe Abley  wrote:
> >>>
> >>> I aim to get it done before next week.
> >>
> >> Awesome! Thanks!
> >
> > And from me too - I was wondering about this draft the other day,
> > so thanks Paul for prodding before I got a round tuit.
>
> For various reasons I didn't in fact get it done before this week, but
> it's definitely on the to-do list.
>
>
> Joe
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal

[tjw ietf]

This starts a Working Group Last Call for draft-ietf-dnsop-session-signal

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/

Please review the draft and offer relevant comments. Also, if someone feels
the document is *not* ready for publication, please speak out with your
reasons.

We are doing a three week Working Group Last Call process, and we're cross
posting to a few groups where we hope to receive some strong reviews.

This WGLC ends at midnight, 22 February 2018.

thanks
Tim/suzanne
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

[tjw ietf]

Hi

The call for adoption for this has ended and the groups has requested
adoption.  I will contact the authors about updating their draft with the
new name as well as addressing open issues during the call.

tim


On Thu, Nov 16, 2017 at 3:23 AM, tjw ietf <tjw.i...@gmail.com> wrote:

> All
>
> The author has rolled out a new version addressing comments from the
> meeting on Monday, and we feel it’s ready to move this along.
>
> This starts a Call for Adoption for draft-huston-kskroll-sentinel
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 30 November 2017 23:59
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

[tjw ietf]

FYI,  I'm taking notes of all the issues raised by folks in this thread
(thank you!) and will hold the authors accountable in addressing them.

tim


On Fri, Nov 24, 2017 at 11:41 AM, Paul Hoffman 
wrote:

> I would like to see this draft adopted and worked on by the WG. Some of
> Ed's observations ring true for me as well, but I can see ways forward for
> all the ones that concern me.
>
> --Paul Hoffman
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

[tjw ietf]

All

The author has rolled out a new version addressing comments from the
meeting on Monday, and we feel it’s ready to move this along.

This starts a Call for Adoption for draft-huston-kskroll-sentinel

The draft is available here:
https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 30 November 2017 23:59

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Draft Minutes from IETF100

[tjw ietf]

Thanks again to Paul Hoffman for taking the minutes.  please take a look to
see if there are any updates that need to be made and let the chairs know.

https://datatracker.ietf.org/meeting/100/materials/minutes-100-dnsop/

You can also just submit a pull request:

https://github.com/DNSOP/wg-materials/blob/master/ietf100/dnsop-ietf100-minutes.txt

Thanks again.  We'll send out a chairs note on we see direction and
outcomes from the meeting today/tomorrow.

tim
DNSOP WG minutes
IETF 100, Singapore
2017-11-13
Tim Wicinski and Suzanne Woolf, chairs
Minutes taken by Paul Hoffman
Material from the slides not reproduced here

Agenda Bashing, Blue Sheets

Updates of Old Work - Chairs

draft-ietf-dnsop-terminology-bis - Paul Hoffman
Consider getting your assitants / colleagues / bosses who should 
understand the DNS more to review
Alex Meyerhofer: Volunteers to review the whole document
Maybe define "local anycast"
Stéphane Bortzmeyer: Disagrees with how Paul discussed QNAME in the 
slides
We need to decice whether to roll back to old definition, or 
acknowledge that there are two definitions
Paul: Do we acknowledge that some people are using the new one 
but most people are using the old one
Suzanne: We should have a raffle: adopt-a-term
Bill Manning: Terminology is not static
People will come up with new terms over time
Andrew Sullivan:
No one thinks we're pouring concrete
This is just like normal dictionaries
Tim: This will be Standards Track whereas RFC 7719 was Informational

draft-ietf-dnsop-rfc5011-security-considerations - Wes Hardaker
A bunch of comments from a few people
New version coming out this week
Should this be published at all?
Need more opinions?
George Michaelson: Disagrees with Ed about it's the wrong authors
Struggles with the complexity of the math
It's days, not seconds
David Lawrence: Should be advanced, suprised that there is even a 
question
Focus on the words being said
Joe Abley: Should be published, even though there is probably just one 
zone important
Took something that was complicated, and made it more 
complicated
Hasn't heard anyone say intervals is important, likes wall time 
better
David Conrad: Thinks Ed meant that there should be more operator input
Supports publication
Prefers interval
Mike StJohns: Root did two things he didn't contemplate
Single trust anchor steady state
Early signatures of things that make it in the wild
Eric Osterweil: Good to publish because it is good to show perspectives
More discussion on the list on interval vs. wall time

draft-ietf-dnsop-extended-error - Wes Hardaker
Four choices for how to create the full error code
Paul Hoffman: This didn't work well in HTTP, use choice 4
Stephane: There might be errors that would cross mulitple 
categories
Joe: First three need additional processing, so fourth is the 
only reasonable one
Ralf Weber: Copying information we already have in the packet 
isn't a good idea
Alex: IANA registry could also have the list of which RCODEs 
could be used together
Stefan: For security, use DNS-over-TLS
Eric: Security concern: it's OK as long as you think about what will 
cause an action based on error
Don't use transport security
Robert Story: Maybe use flags instead of code
Wes: It could get really long
Joe: This is definitely transport, not objects
Codes are about transport
Wes: Are we only doing things that are transport-specific?
Stephane: Open question about whether to have informational messages

draft-ietf-dnsop-let-localhost-be-localhost - Tim
Major issue is DNSSEC
Suzanne: if the name needs to be signed, we would need to get it in the 
root
Warren Kumari: Thinks that NXDOMAIN is a fine answer for what this needs
Wes: We know that there are multiple naming systems, so NXDOMAIN is a 
good answer here
This is outside the DNS, so fall back to one of your local 
resolution system
Willem Toroop: FreeBSD jails need individual loopback addresses

draft-bellis-dnsop-xpf - Ray Bellis
(No slides)
Lots of feeback from last meeting, updated draft
Already have one implementation: dns-dist
Many have read the draft
Sara Dickenson had raised privacy objections earlier

draft-fujiwara-dnsop-additional-answers - Kazunori Fujiwara
Wes: This and mulitple-responses could be combined.
Benno Overeinder: Good chart.
Mukund Sivaraman: In BIND, moving away from large 

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

[tjw ietf]

Actually Wes, it was absolutely bad for me making the poor assumption on
the choices aligned between the email and the slide.

You are correct the preferred option we hear as the 16 bit value.

On Wed, Nov 15, 2017 at 8:40 AM, Wes Hardaker  wrote:

> Geoff Huston  writes:
>
> >> I think the number 4 on the slide was different from the one in the
> mail.
> >
> >
> > I thought so too, but I wasn’t sure if it was me not paying attention
> > in the WG meeting or not!
>
> Yes, you're both right.  And absolutely my bad for writing the
> presentation without looking at the mail I sent and synchronizing the
> numbering.
>
> The preferred option in the room was the 16-bit value that would be used
> in combination with the rcode to indicate the full meaning of the
> extension value.
> --
> Wes Hardaker
> USC/ISI
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

[tjw ietf]

To follow up from the meeting this morning,  it sounded from the room that
in the case of these
four options, #4 was the one which makes the most sense.

tim

On Tue, Oct 17, 2017 at 6:39 AM, Wes Hardaker  wrote:

>
> Folks,
>
> We were given feedback during the call for adoption to "use numeric
> range codes like those in HTTP".  Following that, Warren and I sat down
> and came up with some possibilities and would like your feedback about
> which of these options you would prefer:
>
>   1. Individual codes assigned one at a time, per the existing doc
>
>   2. HTTP like: integer ranges where NNYY indicates the NN integer rcode
>  and YY indicates the sub-code.  Note that this needs a 32 bit error
>  code field.
>
>   3. Use a 16 bit error code field, with the 16 bits differ per rcode.
>  Thus, clients would need to use the combination of rcode and error
>  code to determine the error.
>
>   4. 32 bit code field, repeating rcode from elsewhere in the packet
>  Like #2, but copies the rcode directly into the error code header
>  within the extended-error component of the packet.  Redundant but
>  clear that the entire 32 bits are needed.
>
> Thoughts?
>
> --
> Wes Hardaker
> USC/ISI
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Jabber Scribes and Minute takers for DNSOP on Monday

[tjw ietf]

Hi

We're sending out the note requesting jabber scribes and minute takers for
DNSOP.

Also, there are a few laggards who need to send slides in.  You know whom
you are.

See you bright and early Monday Morning!

thanks,
tim/suzanne
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Agenda for IETF100

[tjw ietf]

Great question Paul and thanks for getting that on record.

On Sat, Nov 11, 2017 at 2:59 AM, David Conrad  wrote:

> Can confirm, as can anyone willing to go to an Adobe Connect archive. For
> the curious:
>
> https://participate.icann.org/p6u03rimy92/?launcher=false;
> fcsContent=true=normal
>
> The discussion on Ethereum by Leonard Tan, an Ethereum developer, starts
> at 00:31:00. Paul’s question is at 00:42:16. From the transcript:
>
> >> PAUL:  PAUL, IETF.  LET'S SAY IETF GETS THE DOMAINS IETF IN THIS NAMING
> SYSTEM AND WE PAY OUR FEES FOR A COUPLE OF YEARS.  EVERYBODY USES THE
> SITE.  AND THEN AT SOME POINT WE FORGET TO PAY AND THE DOMAIN FALLS BACK
> INTO THE POOL AND SOMEBODY ELSE REGISTERS IT AND WE DON'T KNOW WHERE THEY
> ARE OR WHO THEY ARE.  NOW I GO TO A COURT SYSTEM.  I GET SOME LEGAL OPINION
> SAYING I OWN THIS TRADEMARK AND NOW I WANT TO GET THIS DOMAIN BACK.  IS
> THERE ANY WAY FOR ME TO GET THIS DOMAIN BACK?
> >>LEONARD TAN:  SO RIGHT NOW, THE ENS INDUSTRY, YOU CAN CHANGE IT BECAUSE
> IT REQUIRES FOUR OUT OF SEVEN PEOPLE.  MOST OF THEM ARE ETHEREUM
> DEVELOPERS.  AND IT IS A CONSENSUS OF THEM TO MAKE ANY CHANGES.  SO IT IS
> POSSIBLE, BUT IT IS GOING TO BE A VERY DIFFICULT THING TO DO.
>
> Regards,
> -drc
>
> On Nov 10, 2017, 10:47 PM +0800, Paul Wouters , wrote:
>
> The ENS developer said so in response to my question.
>
> Sent from my iPhone
>
> On Nov 10, 2017, at 19:55, Stephane Bortzmeyer  wrote:
>
> On Fri, Nov 10, 2017 at 05:58:13PM +0530,
> Paul Wouters  wrote
> a message of 29 lines which said:
>
> It takes 4 out of 7 geeks to bypass the blockchain in case of
> emergency, court orders or kneecaps.
>
> According to the presentation held at ICANN60
>
>
> Well, if someone at ICANN said so, someone is wrong (or, at the
> minimum, over-simplificator).
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations

[tjw ietf]

All

The Working Group Last Call has ended on this draft two days ago, with two
problems.   First, there was not enough comments from folks calling it
ready for publication, and second, there are two strong voices against
publishing this document.  With one against, we could work some rough
consensus, though the second  set of comments need to be addressed.

The authors are addressing the issues, and hopefully have a new version
before the meeting, and we can revisit this.

thanks
tim




On Thu, Oct 26, 2017 at 1:42 PM, Michael StJohns 
wrote:

> On 10/26/2017 11:11 AM, Warren Kumari wrote:
>
> Wes and I do believe that this is an important document - getting
> these timers wrong potentially has really bad security implications;
>
>
> So, pretty please, review this document and send feedback. We've tried
> hard to make it readable, but the topic is unfortunately complex and
> can only be simplified so far - it is also really hard to talk about
> sliding windows of time.
>
>
> *sigh*
>
>
> It's really not complex and its neither a timer nor an interval nor a
> window - but a fixed point in time given the input data:
>
> earliest date when its safe to revoke ALL old trust anchor keys ::= latest
> expiration date of any RRSet containing the key(s) to be revoked +
> queryInterval (from 5011) + holdDownTime (from 5011) + queryInterval (from
> 5011)
>
>
> earliest date when the zone owner thinks its safe to revoke all the old
> keys ::= the above + safetyFactor
>
> The first query time is the maximum time it takes for all resolvers to
> make their first query (assuming no retries).  The second query time is the
> time for all resolvers to make the "next query after the hold down time
> expires" (again assuming no retries).
>
> The safety factor is there primarily to deal with network outages AT THE
> RESOLVER and is a SWAG that should represent a value that captures the
> answer to the question "given the retry interval and a 99% network uptime
> and N resolvers, how long until 99.99% of the resolvers have completed all
> necessary retries at both the beginning and the end of the process?"  Like
> most retry questions, this has a bi-modal answer - given a reliable
> network, the vast majority of resolvers will be successful in small
> multiples of the retry interval.   A very tiny few will not be successful
> even after 100s of retries.  The SWAG should pick a number of retries that
> balances the operational need to complete the process with the possibility
> of a few resolvers not getting the word.
>
> so:  safetyFactor ::= retryInterval (from 5011) * (5 + func(N))  - 5 is a
> SWAG to set a minimum for even a small group of resolvers.
>
>
> I was thinking Log2(N) - which would give 23 for 10 million resolvers or
> 28*retryInterval.   Or something suitably non-linear
>
>
> Note that "latest expiration date of any RRSet containing the key(s) to be
> revoked" makes a worst case assumption:  that the pre-signed RRSets are not
> necessarily protected from disclosure.If this is not true, then this
> reduces down to "the latest expiration date of any RRSet containing the
> keys to be revoked that has been seen publicly".  The document SHOULD
> assume that any signed RRSet may be available to an attacker whether it's
> been published in the DNS or not.
>
> 5011 was a timer based document because it applied to each resolver in
> each resolver's time domain.  When a timer fired on resolver A, it had no
> impact on the behavior of resolver B nor on the DNS server that was being
> queried.
>
> With this document, the 5011 timer intervals are useful only to figure out
> an earliest possible safe date given the previous live data set.  When
> that  (those) data set become irrelevant for the purposes of Wes' attack is
> pretty straight forward: when it expires!   The 5011 intervals can be used
> to calculate forward from that DATE and TIME to get an idea of when most
> well-behaving resolvers will have accepted new trust anchors even if they
> were being attacked.  Note "most".  There is no guarantee that even if you
> waited 6 years that all resolvers would get the new trust anchors and you
> just need to accept that the fall back is for the resolver owner to fix the
> problem when it occurs.
>
> This discussion has been helpful because it forced me to consider two
> things the root does that I never contemplated in 5011:  1) A steady state
> of a single trust anchor and 2) pre-signing RRSets.  Neither of these
> affects the resolver implementation, but both make the publishing/signing
> schedules more security sensitive - hence this document.
>
> Later, Mike
>
>
>
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Agenda topics for IETF100

[tjw ietf]

All

Please submit any request for presenting at IETF100 to the chairs.  We'll
be working on a draft agenda in the interim.

thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

[tjw ietf]

The Call For Adoption ended some time ago, and I spent some time reading
the comments.

There is consensus to adopt this, *but* there is also a enough of an
concern that some of the issues raised be addressed.   We'll want to make
sure all issues are addressed.

tim

On Tue, Oct 10, 2017 at 5:12 AM, Petr Špaček  wrote:

>
>
> On 9.10.2017 22:20, Jacob Hoffman-Andrews wrote:
> > On 10/09/2017 01:16 PM, Warren Kumari wrote:
> >> So, that's my (new) views, and the thread seemed to have stalled. I
> >> believe that the security implications of having  localhost queries
> >> leak into the DNS is bad, and there is significant evidence that this
> >> is happening. I get that there is no answer that will make everyone
> >> happy, but now that we've had some time to mull over this, where did
> >> we end up?
> > My feeling of the list is that your view matches the rough consensus:
> > stub resolvers are responsible for resolving localhost to 127.0.0.1, and
> > queries for localhost should not hit the network, as described in the
> draft.
>
> I agree, consider it as one data point in your "rough consensus"
> estimation.
>
> --
> Petr Špaček  @  CZ.NIC
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

[tjw ietf]

The adoption period finished sone time ago with strong consensus to adopt.
  Authors will want to upload their latest version.

tim


On Mon, Sep 11, 2017 at 2:52 PM, Marek Vavruša 
wrote:

> I support the adoption of this document. Was there a discussion of any
> actual downsides besides "I'd like to know if it's stale" and
> monitoring?
>
> On Mon, Sep 11, 2017 at 11:11 AM, Bob Harold  wrote:
> >
> > On Thu, Sep 7, 2017 at 10:07 PM, Mark Andrews  wrote:
> >>
> >>
> >> Part of the problem is that we have one TTL value for both freshness
> >> and don't use beyond.
> >>
> >> This is fixable.  It is possible to specify two timer values.  It
> >> does require adding signaling between recursive servers and
> >> authoritative servers, on zone transfers and update requests.
> >>
> >> You basically add a additional timer field to every record immediately
> >> after the TTL field.  This is only returned if the client has
> >> signalled support for the extended field, I suggest using the last
> >> DNS header bit for this as you can determine how you will parse the
> >> response base on whether the bit is set in the response or not.
> >> This field is used to expire records from the cache and its value
> >> is set to the TTL field if the server has learnt the record from
> >> server that doesn't support the extension.
> >>
> >> The existing TTL field is used for freshness checking.  When a query
> >> comes in after that value has expired a freshness check is performed
> >> similar to the existing prefetches that happen today.  A TTL of 1
> >> is returned unless the original TTL was 0 in which case 0 is returned.
> >>
> >> New client - new recursive server - new authservers
> >>
> >> example.com. 300 86400 IN A 1.2.3.4
> >>
> >> +300 seconds
> >>
> >> example.com. 1 86100 IN A 1.2.3.4
> >>  (background query is in process)
> >>
> >> Old client - new recursive server - new authservers
> >>
> >> example.com. 300 IN A 1.2.3.4
> >>
> >> +300 seconds
> >>
> >> example.com. 1 IN A 1.2.3.4
> >>  (background query is in process)
> >>
> >> New client - new recusive server - old auth servers
> >>
> >> example.com. 300 300 IN A 1.2.3.4
> >>
> >> +300 seconds
> >>  (record has expired from cache,
> >>   new query is performed)
> >>
> >> example.com. 300 300 IN A 1.2.3.4
> >>
> >> For UPDATE a replacement opcode would be cleanest way to signal the
> >> new format is being used.  NOTIMP should be returned by servers
> >> that don't support the new opcode.
> >>
> >> There will be a few broken servers that just echo back the new
> >> header bit.
> >>
> >> This way the authoritative servers still control how long records
> >> are stored for.  Dead servers will get a little bit of traffic until
> >> the the refresh completes.  If the authorative servers are under
> >> attack the clients still see a answer.
> >>
> >> The alternative is to perform the refresh query and if it fails to
> >> complete within X milliseconds return the cached data rather than
> >> returning the cached data and doing the refresh in the background.
> >>
> >> Mark
> >>
> >> --
> >> Mark Andrews, ISC
> >> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> >
> >
> > While I like the idea of a  "don't use beyond" timer, I think it will be
> a
> > very long time before it is widely deployed (and actually configured by
> zone
> > owners), and therefore won't solve our immediate need.  It would be
> great if
> > clients could opt-in, but again I don't see that happening anytime
> soon.  So
> > I would start with resolver-operators deciding what seems best for their
> > clients (which is hat is happening whether we like it or not).  Adding
> > client opt-out/opt-in would be good.   Signalling to say that a response
> is
> > stale would be good.  Adding the second timer (both per-RR and as a zone
> > default value, like TTL is handled) would be good.
> >
> > On a related note - the SOA "expire" timer tells a slave how long to keep
> > serving "stale" zone data when the master cannot be reached.  Would that
> be
> > a reasonable default value for how long a resolver should serve "stale"
> data
> > when the authoritative servers cannot be reached?   (Currently I think
> most
> > people set a very high value compared to the TTL.)
> >
> > --
> > Bob Harold
> >
> >
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] IETF 100 Meeting slots

[tjw ietf]

All

We've been given two slots for IETF100, and currently more time then we
requested.  Our slots are:

Monday 09:30 - 12:00
Thursday 15:50 - 17:50

We'll want to start thinking of agenda items, keeping in mind we have some
curent drafts to get updated.

tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations

[tjw ietf]

>From talking with the authors and reading all the comments on the mailing
lists, it appears that all outstanding issues have been addressed.

This starts a Working Group Last Call for:
draft-ietf-dnsop-rfc5011-security-considerations

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/

Please review the draft and offer relevant comments. Also, if someone feels
the document is *not* ready for publication, please speak out with your
reasons.

This starts a two week Working Group Last Call process, and ends on  1
November 2017

thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

[tjw ietf]

Ted

Thanks.  The document still waffles, but it 'waffles less' than it did
initially.  But Mike is committed to working that and any other issue which
may arise.

tim

On Wed, Sep 6, 2017 at 10:29 AM, Ted Lemon  wrote:

> The document as written still waffles between insecure delegation and
> secure denial of existence.   I think that if the document were published
> with the recommendation of an insecure delegation, this would be actively
> harmful.   If it's published with the secure denial of existence, it would
> probably improve the state of the art.
>
> Unfortunately I don't think that calls for adoption really give us a basis
> for stating such preferences.   But that's basically where I land on this.
>  I would be perfectly happy to support this document if it does the right
> thing, but I'm dead set against it if it doesn't.   I am of course willing
> to participate in working on the document if adopted—I've already sent some
> text, and am grateful to the author for having for the most part accepted
> my proposed changes.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNSOP Call for Adoption - draft-west-let-localhost-be-localhost

[tjw ietf]

When the idea of having a Call for Adoption for this document came up, we
thought long and hard about this one.  However, the comments from the
working group focused this document to address the specific issue of the
local hostname.

This starts a formal Call for Adoption for
draft-west-let-localhost-be-localhost

The draft is available here:
https://datatracker.ietf.org/doc/draft-west-let-localhost-be-localhost/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 20 September 2017

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

[tjw ietf]

August is over and my self-imposed holiday is over, so it's time to get
busy again. We have this document marked as a candidate for adoption.

This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale

The draft is available here:
https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

*If You have already stated your position for or against adoption, we are
counting those so you do not need to repeat yourself. *

This call for adoption ends: 19 September 2017

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

[tjw ietf]

This draft was the only one which seemed to have broad support in some form
during the meeting last week.

This starts a Call for Adoption for draft-wkumari-dnsop-extended-error

The draft is available here:
https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 8 August 2017, 23:59

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Minutes from Thursday Meeting

[tjw ietf]

Thanks again to Mr, Hoffman from keeping copious notes.  They are uploaded
here:
Minutes IETF99: dnsop


and I included them below for the time-constrained.   Please send any
corrections to the chairs.

thanks again

tim




dnsop-ietf99-minutes-2.txt


DNSOP WG
Thursday 20 July 2017Tim Wicinski , Suzanne Woolf <
suzworldw...@gmail.com>
Minutes taken by Paul Hoffman
Text from the slides is not reproduced here

DPRIVE on IETF network: Warren Kumari
Pretty picture of the IETF use
Open errata on RFC 8078, needs feedback

draft-bellis-dnsext-multi-qtypes and
draft-wkumari-dnsop-multiple-responses: Wes Hardaker
If the client knows it has multiple questions:
draft-bellis-dnsext-multi-qtypes
If the server has a better idea of what you want than you do:
draft-wkumari-dnsop-multiple-responses
Happy eyeballs applies to both drafts
Paul Hoffman: Likes both
Shane Kerr: Likes multi-qtypes, both are OK
Ralph Weber: Questions on multi-qtypes
There is no need for either
David Lawrence: Likes multiple-responses
Ondrej Surey: Missing description of smart attackers
Olafur Gundmunsson: If we open the question, there will be other
ideas coming
Has an experiment that will result in a draft
Andrew Sullivan: Disagrees that these are optimizations
Change the architectural assumptions of the DNS
We need a focused discussion on that
Paul Wouters: Likes both
Simplify the ANAME with special processing
Kazunori Fujiwara: Wants to compare all of proposals
Ray Bellis: Objects to Olafur's comment
Wants to hear more from Andrew
Mukund S: Prefers smart clients to smart servers
Jim Reid: Would like objective data to indicate whether it is worth
the effort
Warren promised data
Matt Pounsett: Likes both drafts
Maybe can do both changes in a single draft
Wes: They depend on who has the knowledge

draft-bellis-dnsop-xpf: Peter van Dijk
Substantial changes since previous version
Ondrej S: Why not EDNS0?
If there is a TSIG over the query, that will break
Sara Dickenson: Client subnet is informational
Violates basic principals
Directly injects metadata into questions
Needs more privacy concerns
Say we're going to violate privacy
Maybe consider encryption between trusted parties
Daniel Kahn Gilmore: Agreed with Sara
Warren Kumari: Wouldn't have done client subnet if they had thought
about privacy

draft-wkumari-dnsop-extended-error: David Lawrence
Paul W: The signaling bits are not protected by crypto
Olafur: People have wanted this forever; should do it
Jim: Great ideas
Maybe lightweight codepoint allocation
Be careful of codes that will cause further action of
recursive servers
David: Talking to IANA how expert review happens
Petr Špaček: Needs implementation in clients or it is useless
Andres Schultz: Need vendor values
Ralf: Can be used for many things

draft-tale-dnsop-edns0-clientid: David Lawrence
This is obviously PII
Everything that Sara said about XPF applies here
Customer will do this regardless of whether or not this is adopted
Paul W: Doesn't like people coming to the WG and saying "we'll do
it anyway"
We should stop accepting these
Sara: Likes documenting what we are do
Do as informational
Likes the way the draft is organized
Need to be careful about where we draw the line of
documentng things we don't like
Peter VD: People are squatting on points; please do it
Ralph: This needs to be done
Stephane: Has too many privacy issues, doesn't want it adopted
Won't review
Privacy should be in control of the user, not the
administrator
David: Wants to see people make more conscious decisions in
the life
Daniel: Appreciates desire to document privacy violations
Doesn't like the flexibility of the suboptions
Where do we draw the line on which info do we not transmit
on the DNS?
Paul W: No one knows the difference of Informational RFCs
David: There are actually DNS full standards
We should be better about pushing to full standards

draft-edmonds-dnsop-capabilities: Robert Edmonds

draft-huque-dnssec-alg-nego: Shumon Huque
Francis Dupont: Not clear which is stronger: use "preferred"
Shumon: Either have client preference, or zone operator
specifies

Re: [DNSOP] IETF 99: Call for agenda items, and draft cutoff reminder

[tjw ietf]

Reminder on the deadline for submitting drafts is Monday 3 July at Midnight
UTC. If you wish to have a slot and have not contacted us please drop
an email to the chairs.

I'm done with my NomCom commitments which have taken me away, and will be
working on a draft agenda this weekend.

thanks
tim


On Mon, Jun 19, 2017 at 11:22 PM, Suzanne Woolf 
wrote:

> Hi all,
>
> IETF 99 is advancing rapidly upon us….
>
> DNSOP has two sessions scheduled in the preliminary agenda, Tuesday
> 15:50-17:50 and Thursday 18:10-19:10. In the interests of managing that
> time well, we’d like to hear from you ASAP if you’re asking for agenda time.
>
> As always— we’ll prioritize work that will advance WG drafts, and new work
> that’s already gained some interest on the mailing list.
>
> Note also that the draft cutoff is in two weeks, on July 3. If you’ve got
> a WG draft with pending changes, or a draft you’d like the WG to consider
> for adoption, please have the latest and greatest version submitted by then.
>
>
> thanks,
> your faithful chairs
> (Tim & Suzanne)
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname

[tjw ietf]

All

The Call for Adoption ended last night, and there was strong consensus to
adopt this document.  We did hear the concerns about DNSSEC and we do not
take them lightly.  The chairs are confident that the authors can work out
these issues.

The authors can resubmit their document with the format

Thanks
tim


On Thu, May 11, 2017 at 6:55 AM, tjw ietf <tjw.i...@gmail.com> wrote:

> I'm caught up with my day job, and the discussion on this has died down,
> but it looks like the work is moving along smoothly, it's time to kick off
> a Call for Adoption on this document. (well, maybe late).
>
> This starts a Call for Adoption for: draft-hunt-dnsop-aname
>
> The draft is available here: https://datatracker.
> ietf.org/doc/draft-hunt-dnsop-aname/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: Midnight 25 May 2017
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname

[tjw ietf]

JINMEI

I've noted your previous remarks as something I would take up with the
authors.  But thanks for the reminder.

tim

On Thu, May 11, 2017 at 3:15 PM, Mark Scholten <m...@streamservice.nl>
wrote:

> > From: tjw ietf [mailto:tjw.i...@gmail.com]
> > Sent: Thursday, May 11, 2017 12:56
> >
> > This starts a Call for Adoption for: draft-hunt-dnsop-aname
> >
> > The draft is available here: https://datatracker.ietf.org/
> doc/draft-hunt-dnsop-aname/
> >
> > Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> I support adoption of this draft.
>
> > Please also indicate if you are willing to contribute text, review, etc.
>
> I'm willing to review.
>
> Kind regards,
>
> Mark
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

[tjw ietf]

There was a lot of consensus during our last meeting in Chicago that this
should move forward, so it's time that we do so.

This starts a Call for Adoption for:
draft-kristoff-dnsop-dns-tcp-requirements

The draft is available here:
https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: Midnight 25 May 2017

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for Adoption draft-hunt-dnsop-aname

[tjw ietf]

I'm caught up with my day job, and the discussion on this has died down,
but it looks like the work is moving along smoothly, it's time to kick off
a Call for Adoption on this document. (well, maybe late).

This starts a Call for Adoption for: draft-hunt-dnsop-aname

The draft is available here:
https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: Midnight 25 May 2017

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft for ALIAS/ANAME type

[tjw ietf]

Thank You to Evan and Peter for working with Anthony on a merged draft.



On Thu, Mar 30, 2017 at 6:13 PM, Evan Hunt  wrote:

> On Thu, Mar 30, 2017 at 11:08:06PM -, John Levine wrote:
> > though ANAME is vastly less complex.  It requires that an
> > authoritative server include a recursive client and do online signing,
> > both of which would be rather large additions to the mandatory set of
> > server features.
>
> It can outsource resolution to an external recursive resolver. Depending
> on the implementation details, signing could also be handed by an external
> bump-in-the-wire signer.
>
> (Incidentally, I'm working on a somewhat more ambitious ANAME draft with
> Peter van Dijk and Anthony Eden, who has kindly agreed to merge his efforts
> with ours. I expect to post it in a few days, stay tuned.)
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

[tjw ietf]

Hi

The Call for Adoption has ended and there was support to adopt this
document and work out the handful of issues brought up.  Thanks everyone
for comments, etc.

If the authors can upload a new version we;ll get that one squared away.

thanks
tim/suzanne

On Thu, Mar 16, 2017 at 2:16 AM, tjw ietf <tjw.i...@gmail.com> wrote:

> All
>
> We've had a lot of WG discussion on this, and it seems relevant to do a
> formal call for adoption.   If there are outstanding issues raised during
> the CfA, time in Chicago will be set aside to have those discussions.
>
>
> This starts a Call for Adoption for:  draft-hardaker-rfc5011-
> security-considerations
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-
> security-considerations/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> If there are
>
> This call for adoption ends: 30 March 2017
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-tale-dnsop-edns-clientid

[tjw ietf]

Catching up with the discussion

I like having two, well documented options.   I do see where the option in
David's draft has too many moving parts.

On Thu, Mar 30, 2017 at 11:20 AM, Dave Lawrence  wrote:

> On 30/03/2017 09:52, Bob Harold wrote:
> >> Just a thought - would it be better to have two different EDNS0 options
> >> that carry an IP, or to have one EDNS0 option that carries both an IP
> >> and a 'type', and allow multiples of that option in a packet?
>
> Ray Bellis writes:
> > IMHO, two options is better.
>
> I'm with Ray on this, both because of his earlier observation re: TXT,
> and also because this complicates the option design and adds yet<
> another number registry.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Updates from Monday Meeting

[tjw ietf]

All

We know we ran out of time, which is a regular problem for us.  A
combination of being too optimistic in our scheduling and too many people
with interesting things to discuss.   In the past we've tried to ask for
multiple sessions,  but with the pressure on slots we've always backed
down.  We feel in Prague we're going to try for two slots, even if one is
an hour that we can talk about new work (for example)

But I don't want people to skip these presentations we've uploaded.

David Lawrence has two drafts (which he has mentioned since the meeting):

https://datatracker.ietf.org/doc/html/draft-tale-dnsop-serve-stale
https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/

slides:

https://www.ietf.org/proceedings/98/slides/slides-98-dnsop-stale-server-and-extended-error-code-00.pdf

Warren and Wes have a draft on extended error codes that this operator
(not wearing any hats) finds completely interesting and would like to see
more of:

https://datatracker.ietf.org/doc/draft-wkumari-dnsop-extended-error/

slides:

https://www.ietf.org/proceedings/98/slides/slides-98-dnsop-dns-extended-error-codes-00.pdf

Ondrej is looking for feedback on adding new algorithsm to nsec3:

https://www.ietf.org/proceedings/98/slides/slides-98-dnsop-adding-new-algorithms-to-nsec3-00.pdf

Thanks again for a productive meeting.  We'll take to the mailing list any
votes, etc.

tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

[tjw ietf]

Hi

The Call for Adoption ended some time ago with very little discussion in
that period, but a significant and fruitful discussions since.

Considering the strong hum of the room in Seoul and the conversations on
this version, the chairs consider the draft adopted,  If there are items
that wish to be raised during Chicago, the chairs will set aside time in
the meeting to bring these up.

thanks
tim


On Thu, Jan 5, 2017 at 4:28 PM, Tim Wicinski  wrote:

> All
>
> Since we're having so much fun on adopting work, let's have another one.
> We discussed this work in Seoul, and there was a solid hum on adopting this
> work.
>
> This starts a Call for Adoption for:
> draft-wouters-sury-dnsop-algorithm-update
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-al
> gorithm-update/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 19 January 2017
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

[tjw ietf]

All

We've had a lot of WG discussion on this, and it seems relevant to do a
formal call for adoption.   If there are outstanding issues raised during
the CfA, time in Chicago will be set aside to have those discussions.


This starts a Call for Adoption for:
 draft-hardaker-rfc5011-security-considerations

The draft is available here:
https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

If there are

This call for adoption ends: 30 March 2017

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

[tjw ietf]

All

During the first WGLC of draft-ietf-dnsop-refuse-any, several issues were
raised by the working group that needed to be addressed. The Authors
addressed the issues, but the changes are enough that there should be a
second Working Group Last Call on the changes.

This begins a Second WGLC for draft-ietf-dnsop-refuse-any.  The Document is
located here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

However, the changes that were made since the last WGLC can be found here:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-refuse-any-03=draft-ietf-dnsop-refuse-any-04

Please take a few moments to refer the changes and let the working group
know if the document is ready to move forward.   We're mostly looking for
remaining issues that have not been addressed.

This WGLC ends on Thursday 30 March 2017.

Thanks

tim/suzanne
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[tjw ietf]

All

The Call for Adoption on draft-vixie-dns-rpz ended some time ago, and the
results were a solid in favor of adoption.  However, the legitmacy of the
argument in opposition to adopting seems fairly significant about certain
parts of the draft.

In discussing this with our AD, the opinion is that if this same
opposition  manifests in the IETF last call there would have
reservations about advancing it.

So if we consider this rough consensus for  the purposes of adoption
it means we believe we will be better off with an improved, working-
group-owned document then this one.

We’re going to go ahead and adopt it for DNSOP, with the intention of
resolving the concerns people expressed by keeping the status as
informational (not standards track) and making sure the cautions and
limitations the WG discussed on the use of RPZ are clear in the document.

thanks
tim
suzanne


On Tue, Dec 20, 2016 at 10:16 AM, tjw ietf <tjw.i...@gmail.com> wrote:

> Why not just wade into this discussion...
>
> The draft is being present as "Informational", and the point here is to
> document current working behavior in the DNS (for the past several years).
>   It is obvious that some feel this draft is a large mistake, but like
> edns-client-subnet, more operators are deploying this than one is aware of.
>
> This starts a Call for Adoption for draft-vixie-dns-rpz
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> With the holiday period upon us, we'll make this a three week call for
> adoption. This call for adoption ends on 10 January 2017
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt

[tjw ietf]

Thanks Paul, and double thanks to Matthijs for his diligence in wisely
forcing this.

The new version is minor, but significant.  I don't feel that it needs a
new WGLC, but I want to put the diff between the two versions here so folks
may take a second look.


https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintai
n-ds-06.txt=draft-ietf-dnsop-maintain-ds-04.txt

I'm going back over all the emails I have during the IETF LC process, just
to make sure everything has been addressed.

However, I think it's ready to move forward

thanks
tim



On Tue, Jan 10, 2017 at 7:02 PM, Paul Wouters  wrote:

> On Tue, 10 Jan 2017, Paul Wouters wrote:
>
> Ohh, I think Matthijs actually found a bug:
>>
>
> Fixed in 06 (I forgot the text update in 05). Thanks to Matthijs
> for being so persistent in bringing this up. My apologies that
> I did not understand your concern before.
>
> Chairs, it is up to you to decide on redoing a LC on this or not.
>
> The diff between 04 and 06 that contains all changes since IETF LC:
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintai
> n-ds-06.txt=draft-ietf-dnsop-maintain-ds-04.txt
>
>
> Paul
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt

[tjw ietf]

Mukund,

While I agree with you, Joel has the right guidance on this; but also
knowing the authors fairly well,
I feel they would not send us down a road that will box the work into a
corner.

On Fri, Jan 6, 2017 at 1:25 PM, Mukund Sivaraman  wrote:

> On Fri, Jan 06, 2017 at 09:47:41AM -0800, joel jaeggli wrote:
> > On 1/6/17 9:25 AM, Mukund Sivaraman wrote:
> > > On Fri, Jan 06, 2017 at 01:48:59AM +, Warren Kumari wrote:
> > >>> (2) In a feature implemented for Unbound:
> > >>>
> > >>> - Unbound first checks cache
> > >>>
> > >>> - If a stale answer is found, its TTL is set to 0, and the cache
> entry
> > >>>   is served
> > >>>
> > >>> - If a stale answer is found, Unbound starts something similar to
> > >>>   prefetch/HAMMER.
> > >>>
> >  NOTE: I believe that there may be (non-Google) IP associated with
> >  this. A lawyer will be filing the IPR disclosure later today (time
> >  zone differences, etc).
> > >>> The two approaches are somewhat different, and so at least one of
> them
> > >>> may not be covered by this patent.
> > >>>
> > >> Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole
> was
> > >> acquired by Akamai in March 2015. I believe that David will discuss
> the IPR
> > >> with his employer.
> > > Please explore if this patent can be circumvented without affecting the
> > > goal of the draft, so that it does not apply. It would be better than
> > > licensing it under some legal terms.
> > IMHO this can be better expressed as a preference for unencumbered
> > technology.
> >
> > the working group should not as far as I am concerned get buried in how
> > precisely to achieve that.
>
> There's nothing wrong in exploring unencumbered technology. It isn't too
> much of a diversion to check if the patent can be avoided.
>
> IETF has had several drafts that avoid patented methods by documenting
> something else (compress vs. deflate/gzip, gif vs png, MPEG video vs
> vpx, MPEG audio vs vorbis, opus, etc.) that usually turned out to be
> better.
>
> One of the authors of this draft works at the company that owns the
> patent. As he is introducing this draft and implementations such as mine
> are concerned about the use of this patent, it would be good to attempt
> to discover if the patented method can be avoided.
>
> Mukund
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[tjw ietf]

Why not just wade into this discussion...

The draft is being present as "Informational", and the point here is to
document current working behavior in the DNS (for the past several years).
  It is obvious that some feel this draft is a large mistake, but like
edns-client-subnet, more operators are deploying this than one is aware of.

This starts a Call for Adoption for draft-vixie-dns-rpz

The draft is available here:
https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

With the holiday period upon us, we'll make this a three week call for
adoption. This call for adoption ends on 10 January 2017

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse

[tjw ietf]

Sigh, I did.

Thank you Matthijs for keeping me honest.

tim


On Wed, Dec 14, 2016 at 7:46 AM, Matthijs Mekking <matth...@pletterpet.nl>
wrote:

> Tim,
>
> On 13-12-16 20:13, tjw ietf wrote:
>
>> All
>>
>> The process of WGLC for this document engaged the working group and
>> there was much discussion and several different versions.  It seems that
>> the authors have addressed everything that has been brought up.
>>
>> We felt another formal Working Group Last call was needed, though
>> hopefully shorter.
>>
>> This starts a Working Group Last Call for:
>> "Aggressive use of NSEC/NSEC3"
>>   draft-ietf-dnsop-nsec-aggressiveuse
>>
>> Current versions of the draft is available here:
>>https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/
>> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-aggressiveuse/>
>>
>> For those looking for the differences, these are the differences between
>> the document submitted, and the current one:
>>
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggr
>> essiveuse-02=draft-ietf-dnsop-nsec-aggressiveuse-03
>>
>
>
> I think you meant:
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-nsec-aggr
> essiveuse-02=draft-ietf-dnsop-nsec-aggressiveuse-07
>
> Best regards,
>   Matthijs
>
>
>
>> Please review the draft and offer relevant comments. Also, if someone
>> feels the document is *not* ready for publication, please speak out with
>> your reasons.
>>
>>
>> This starts a *one* week Working Group Last Call process, and ends at
>> midnight 20  December  2016 UTC.
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-dickinson-dnsop-dns-capture-format

[tjw ietf]

All

The Call for Adoption has ended with expected results, and the draft has
been adopted. Thanks to everyone for comments, both in the meeting in Seoul
and on the list.  Now the real work begins.

Authors, if you be so kind as toupload the new version with the appropriate
nomenclature,

thanks
tim
suzanne

On Tue, Nov 15, 2016 at 3:09 AM, tjw ietf <tjw.i...@gmail.com> wrote:

> All
>
> The response from the room today was pretty positive this draft was worth
> adopting and pursuing.  We felt their was little benefit in waiting to
> begin this Call for Adoption.
>
> This starts a Call for Adoption for  draft-dickinson-dnsop-dns-
> capture-format
>
> The draft is available here:
>
> https://datatracker.ietf.org/doc/draft-dickinson-dnsop-dns-capture-format/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 1 December 2016.
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

[tjw ietf]

All

The authors have addressed all the outstanding issues with this draft, and
the chairs feel this is ready for Working Group Last Call.

There has been one issue raised which we feel the working group may have
some opinion on this.

Ondrej Sury raised this point:


There's a small procedural thing - the last name of the draft
appears on both datatracker.i.o and tools.i.o.  I believe it
would be better to reupload the draft with name changed to

draft-ietf-dnsop-minimal-any

to prevent the people who might thing the name of the draft
bears any significance.  As this requires almost no effort
I think it would be better to this now than fend of the
questions "why is this refuse-any while it doesn't refuse
ANY" later.



The authors and the Chairs support this in principle, but the working group
should comment on this during the WGLC process.

-
This starts a Working Group Last Call for
draft-ietf-dnsop-refuse-any

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

Please review the draft and offer relevant comments. Also, if someone feels
the document is *not* ready for publication, please speak out with your
reasons.

*Also*, if you have any opinion on changing the document named from
'refuse-any' to 'minimal-any', please speak out.


This starts a two week Working Group Last Call process, and ends on 10
December, 2016

thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for Adoption: draft-dickinson-dnsop-dns-capture-format

[tjw ietf]

All

The response from the room today was pretty positive this draft was worth
adopting and pursuing.  We felt their was little benefit in waiting to
begin this Call for Adoption.

This starts a Call for Adoption for
 draft-dickinson-dnsop-dns-capture-format

The draft is available here:

https://datatracker.ietf.org/doc/draft-dickinson-dnsop-dns-capture-format/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 1 December 2016.

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 6781 and double signature KSK rollover

[tjw ietf]

I agree with Matthijs.  Looking at 6781 that makes the most sense.

tim

On Tue, Oct 25, 2016 at 8:17 AM, Matthijs Mekking 
wrote:

>
>
> On 25-10-16 15:15, Marcos Sanz wrote:
>
>> Matthijs,
>>
>> my attention has been brought to the KSK rollover double-signature

>>> style
>>
>>> described in 6781 and what I think is a mistake/oblivion there.

>>> Section
>>
>>> 4.1.2 states

>>>
>> [...]
>>
>> You are right: DS_K_2 may only be provided to the parent *after* the TTL
>>>
>>
>> of DNSKEY_K_1 has passed. RFC 7583 has more accurate timings for
>>> rollovers. The corresponding timeline is described in section 3.3.1.
>>>
>>
>> thanks for the pointer. RFC 7583 does it right.
>>
>> That begs for the question: how to deal with the wrong information
>> propagated in 6781? Submit errata? Label it "Updated by 7583"?
>>
>
> I think an errata is appropriate.
>
> Best regards,
>   Matthijs
>
>
>
>
>> Best,
>> Marcos
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Update on Current Work

[tjw ietf]

All

I wanted to give a quick update to the group on what work I have lined
up in our process queue, and to get people start thinking about
agenda items for Seoul, which is coming up in the next two months.

I will state right now that I've made the decision that we will *not*
be allowing any agenda time for the Special Names discussion (Unless,
of course there is no other work going on).  We should be able to work
this out (or not work this out) on the mailing list, and if need be,
have a virtual interim on it.

We have several drafts that are working toward Working Group Last
Call.   Currently, the drafts (and the general order) are:

# WGLC order

* draft-ietf-dnsop-refuse-any

* draft-ietf-dnsop-nsec-aggressiveuse

* draft-ietf-dnsop-edns-key-tag
(I need to double check with the authors)

* draft-ietf-dnsop-attrleaf
(Dave needs to deliver a new version and perhaps
another iteration.)

* draft-ietf-dnsop-no-response-issue
(We still outstanding issues)

# Other drafts

* draft-ietf-dnsop-session-signal

We had some good initial discussion right before adoption but we
should revisit if there is interest. Mainly, I don't want the
authors waiting until the document deadline to push changes...

* draft-ietf-dnsop-dns-wireformat-http

This draft stirred up discussion in other groups, for better or
worse.  A new mailing list was spun up to discuss the general idea
of dns over http:

https://www.ietf.org/mailman/listinfo/dnsoverhttp

Though my opinions are that this discussion (and possible work)
should not interfere too much this draft moving forward.

(and all of this precludes the fact I'm not covering the Special Names
documents)

# New Work

We have a few requests to have drafts adopted, and I have not
spent any time looking at them. I will do that, and get
back to the authors.

questions, comments, complaints, etc are welcome

thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-bellis-dnsop-session-signal

[tjw ietf]

All

Thanks for all the comments on this draft, the authors have even pushed out
a new version during the process.

The chairs consider this draft adopted. but it still needs some work.

The authors should upload their new version to the data tracker

thanks
tim


On Fri, Jul 22, 2016 at 9:39 PM, Tim Wicinski  wrote:

> I know we've just started talking about this, and the authors are still
> sorting out a few things, but the sense of the room we received was to
> adopt it, work on it, etc.
>
> It appears they have simplified it in the -01 version.
>
>
> This starts a Call for Adoption for draft-bellis-dnsop-session-signal
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> With this being the summer, we're going to run a 3 week call for adoption.
>
> This call for adoption ends: Thursday, 12 August 2016
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-02.txt

[tjw ietf]

(speaking for myself only)

In 5.1, I would think that I'd prefer a standard size, but that doesn't
mean I should rely on it.

For the moment on 5.3.1 . Maybe some text that "an implementer SHOULD sort
their tags" but that mean that one can expect them that way.

tim

On Thu, Jul 14, 2016 at 10:02 PM, Paul Hoffman 
wrote:

> On 11 Jul 2016, at 7:50, Bob Harold wrote:
>
> 5.1. Query Format
>> What if the key tag is less than 0x1000 hex or 4096 decimal - Should the
>> resulting hex have leading zeros (always 4 characters?) or not?
>> For example, would 4095 decimal be _ta-0fff or _ta-fff  ?  (I prefer
>> always
>> 4 characters hex, but it is your doc.)
>>
>
> It is a WG doc, not our doc. Do others have a preference on this?
>
> 5.3.1. Interaction With Aggressive Negative Caching
>> I would prefer that the tags always be sorted.  No big deal for two tags,
>> but if there was a compromise or mistake during a rollover, there might be
>> three keys and the savings in records might be significant.  If you decide
>> to specify sorting, I think it would go in section 5.1 and not in 5.3.1.
>>
>
> Would the "savings in records" really be significant? The problems caused
> by people not consistently sorting could make things worse, not better.
> Related: there might be other reasons for three tags, such as during an
> algorithm rollover.
>
> --Paul Hoffman
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-06.txt

[tjw ietf]

Thanks Donald,

I'm going to work on the Shepherd writeup and have it out by Thursday.

tim


On Mon, Nov 2, 2015 at 2:33 PM, Donald Eastlake  wrote:

> Revised version has been uploaded.
>
> Thanks,
> Donald
> =
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
>
> On Thu, Oct 29, 2015 at 2:17 AM, Tim Wicinski  wrote:
> >
> >
> > On 10/28/15 7:03 AM, Donald Eastlake wrote:
> >>
> >> OK.  I could produce an updated draft with fixes for those typos to
> >> upload during IETF meeting week but I'm not sure if other changes are
> >> desired.
> >>
> >> Thanks,
> >> Donald
> >
> >
> > Please feel free.  We've been through WGLC some time back and we've
> gotten
> > strong consensus, with the editorial caveats that you have addressed. The
> > chairs feel it's ready to be moved along, unless something major appears
> > from this last update.
> >
> > tim
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop