Subject: [DNSOP] DNSOP minutes for Vancouver -- IETF 70

From: Peter Koch <[email-masked]>
Date: Fri, 4 Jan 2008 20:31:00 +0100

Dear WG,

best wishes and a happy and successful 2008 to all of you.

The minutes of our meeting in Vancouver are attached below and have also
been posted to the proceedings website, where they are available at
<http://www3.ietf.org/proceedings/07dec/minutes/dnsop.txt>.

Many thanks to Shane Kerr for taking notes and to Antoin Verschuren and
Andrew Sullivan for acting as jabber scribes.  Please send editorial nits
and comments to Rob and me, more substantial issues to the list. For
inclusion in the final IETF70 proceedings, the deadline is Friday, 18 Jan,
1800 UTC.

Regards,
   Peter

PS: Audio timestamps will be added for the final version.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Peter Koch <[email-masked]>
Date: Tue, 22 Jan 2008 23:32:36 +0100

Dear WG,

> PS: Audio timestamps will be added for the final version.

the minutes for the DNSOP meeting at IETF70 have been updated.
Please find the latest version at
<http://www3.ietf.org/proceedings/07dec/minutes/dnsop.txt> and a diff attached
below.

-Peter
--- ietf70-minutes.txt	2008/01/04 18:48:45	1.2
+++ ietf70-minutes.txt	2008/01/22 22:24:59
@@ -16,10 +16,10 @@
 WG URL:    http://www.dnsop.org
 Material:  https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num
 =70
-Version:   $Id: ietf70-minutes.txt,v 1.2 2008/01/04 18:48:45 pk Exp $
+Version:   $Id: ietf70-minutes.txt,v 1.3 2008/01/22 22:24:00 pk Exp $
 -----------------------------------------------------------------------------
 
-1) Administrivia                                     [ 09:02 {audio 0:XX:XX} ]
+1) Administrivia                                     [ 09:02 {audio 0:06:38} ]
    <http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf>
 
    Tools website for latest documents:
@@ -33,7 +33,7 @@
 
    Thanks to jabber scribes (Antoin, Andrew) and minute taker (Shane)!
 
-2) Status Update                                     [ 09:05 {audio 0:XX:XX} ]
+2) Status Update                                     [ 09:05 {audio 0:08:35} ]
    <http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf>
 
    - RFCs published
@@ -62,43 +62,40 @@
 	 of undefined term ("centrally assigned").
         Reason to have -04 is to submit clean document to IESG; typos and such.
 
-3) WG Charter
-   <http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf>
-
-   No progress, edited version to be WG Last Called
-
-4) Active Drafts                                     [ 09:12 {audio 0:XX:XX} ]
+4) Active Drafts                                     [ 09:12 {audio 0:15:40} ]
 
    4.1) AS112
         [draft-ietf-dnsop-as112-under-attack-help-help-01.txt]
         [draft-ietf-dnsop-as112-ops-01.txt]
         Resubmitted with only minor changes to revive expired drafts
 
-         Mohsen Souissi: Isn't it a good idea to make some dynamic
-           reference somewhere? In case of prefixes we don't know today?
-         Joe Abley: We had this conversation in Prague. There were
-           some complications adding/removing servers, and this
-           document explains what is done today. So changes to how it
-           would be done in another document.
-         Mark Andrews: My draft does create a registry, and does not
-           require coordination between different sites.
-         Peter: We decided to keep this issue separate, because the
-           properties of adding/deleting were subtly different.
-         Peter: Will issue WGLC on these soon.
+        Mohsen Souissi: Isn't it a good idea to make some dynamic
+          reference somewhere? In case of prefixes we don't know today?
+        Joe Abley: We had this conversation in Prague. There were
+          some complications adding/removing servers, and this
+          document explains what is done today. So changes to how it
+          would be done in another document.
+        Mark Andrews: My draft does create a registry, and does not
+          require coordination between different sites.
+        Peter: We decided to keep this issue separate, because the
+          properties of adding/deleting of new address ranges were subtly
+	  different.
+        Chairs will issue WGLC on these soon.
 
-   4.2) Referral Response Size Issues
+   4.2) Referral Response Size Issues                [ 09:17 {audio 0:20:18} ]
 	[draft-ietf-dnsop-respsize-08.txt]
 
 	Editors updated/revived the draft.
-        Akira Kato: Most of comments have led to modification to
-          text. 92%+ of queries have EDNS0 at one of JP servers.
-          Multi-homed servers section updated.  Going to publish -09
+        Akira Kato: Most of comments have led to modification to text.
+	  After Chicago there was discussion around the deployment of EDNS0
+	  92%+ of queries have EDNS0 at one of JP servers.
+          IPv6 and multi-homed servers sections updated.  Going to publish -09
           just after IETF meeting, and then ready for WGLC. Will
           address comments received by 2007-12-10.
 
         Awaiting WGLC
 
-   4.3) Reverse Mapping Considerations
+   4.3) Reverse Mapping Considerations               [ 09:19 {audio 0:22:58} ]
 	[draft-ietf-dnsop-reverse-mapping-considerations-05.txt]
 
         Andrew Sullivan: feels draft is essentially ready - a few nits
@@ -106,20 +103,21 @@
 
         Awaiting WGLC
 
-   4.4) DNSSEC Trust Anchor Configuration and Maintenance
+   4.4) DNSSEC Trust Anchor Config and Maintenance   [ 09:21 {audio 0:25:03} ]
 	[draft-larson-dnsop-trust-anchor-02.txt]
 
         Formal adoption pending. Discussion and review needed.
 	10-15 people had read the draft and supported adoption as a WG item.
 	Confirmation to be requested on WG mailing list.
 
-   4.5) DNS Resolver Priming
+   4.5) DNS Resolver Priming                         [ 09:22 {audio 0:26:14} ]
 	[draft-ietf-dnsop-resolver-priming-00.txt]
 
-        No progress. Some offline comments to be incorporated.  No further
-	comments or discussion.
+        No progress. Some offline comments to be incorporated, some discussion
+	on the mailing list.
+        No further comments or discussion.
 
-   4.6) Recursive Nameservers in Reflector Attacks   [ 09:23 {audio 0:XX:XX} ]
+   4.6) Recursive Nameservers in Reflector Attacks   [ 09:23 {audio 0:27:18} ]
 	[draft-ietf-dnsop-reflectors-are-evil-04.txt]
 
 	The draft received 4 DISCUSSes during IESG review, including 2
@@ -129,10 +127,10 @@
 
 	<http://www3.ietf.org/proceedings/07dec/slides/dnsop-2.pdf>
 
-        {discussion of feedback from IETF Last Call}
+        {Discussion of feedback from IETF Last Call}
 
 	Issue 1: Need to rephrase description of the attack to avoid formal
-		 language and provide more prose.
+		 language and acronyms and provide more prose.
 		 Hopefully more understandable now.
 
 	Issue 2: Overemphasis of BCP 38, need to clarify role of BCP 38 vs.
@@ -163,28 +161,40 @@
 		Joao: Yesterday at the IEPG a presentation showed that there
 		  are 16 million open resolvers.
 		Dave Hankins: Another difference between DNS and SMTP open
-		  resolvers. In SMTP clients can identify themselves.
+		  resolvers. In SMTP clients can identify and authenticate
+		  themselves.
+		Peter: Document already mentions TSIG and SIG(0), but their
+		  availability was questioned.
 		Bill Manning: Concerned about the binary nature of open and
 		  closed. Resolver is only useful if open to some.
+		  Would suggest everyone ran their own caching entity. 
 		Joe Abley: If the question is: "Is it necessary to run an open
-		  recursive name server?" - clearly not!
+		  recursive name server to support roaming users?" - clearly
+		  not!
 		  If the question is: "Is it reasonable?", then it is a
-		  balance between utility and risk, which is what the draft
-		  is all about.
+		  balance between convenience and risk, which is what the draft
+		  is all about.  Maybe should focus on how the wrong conclusion
+		  could have been drawn from the draft.
 		Peter: If we recommend closing all open recursive name servers,
 		  then the option to use them for mobility would no longer
-		  exist. AD DISCUSS asks us to consider strength of
-		  recommendation.
+		  exist. Following the SHOULD to the letter would leave the
+		  opportunity to continue this support of roaming users.
+		  AD DISCUSS asks us to consider strength of recommendation.
 		Joe: IETF can't make a "MUST" when it comes to operational
 		  policy.
-		Rob: Agree that "SHOULD" is the right word.
+		Rob: Agree that "SHOULD" is the right word.  Also, RFC 3833
+		  already addresses the attack by the hotel provider.
 		Mark: With hotels it doesn't matter where you try to direct
 		 the DNS queries, because they'll intercept your packets anyway!
+
 		Frederico Neves: Two options:
-		 1) TSIG and SIG(0), 2) VPN (now in draft)
+		 1) local recursive name server
+		 2) addition of VPN (now new in draft)
 		Mohsen Souissi: Another option is to manually update the
 		 configuration during mobility.
 
+		Joao: IP address based access control is mentioned already.
+
 		Peter:  Anyone in support of the objection? - (No hands)
 			Who is not in support?		    - (Lots of hands)
 			Who did not care?		    - (Couple of hands)
@@ -192,19 +202,24 @@
 		Peter:  Who is in support of the VPN option? - (A few hands)
 			Who is opposed to it?		     - (No hands)
 
-	Peter asks the editors to incormorate the comments and resubmit
+	Peter asks the editors to incorporate the comments and resubmit
 	the draft as -05 in coordination with AD and PROTO shepherd.
 
 	Shane: What is the expected next status?
 	Peter: Shepherding AD responsible to make sure comments are
 	       addressed.
 
-5) Current & New Topics                              [ 09:51 {audio X:XX:XX} ]
+3) WG Charter					     [ 09:49 {audio 0:52:45} ]
+   <http://www3.ietf.org/proceedings/07dec/slides/dnsop-0.pdf>
+
+   No progress, edited version to be WG Last Called
+
+5) Current & New Topics                              [ 09:51 {audio 0:54:20} ]
 
    5.1) Design Team Report: Requirements for a Name Server Control
         and Configuration Protocol
 
-	In Chcago it was agreed upon to form a design team to draw
+	In Chicago it was agreed upon to form a design team to draw
 	a broader picture of name server management and to produce
 	a list of potential work areas and requirements and non-requirements.
         Jaap Akkerhuis volunteered to lead the team.
@@ -215,11 +230,11 @@
 
 	A mailing list has been set up with some initial discussion.
 
-   5.2) Input to the Design Team Discussion          [ 09:53 {audio X:XX:XX} ]
+   5.2) Input to the Design Team Discussion          [ 09:53 {audio 0:56:45} ]
 
 	Peter explained that due to the WG schduling the design team didn't
 	have the chance to meet yet, so instead of a report the time slot
-	would be used to provide input to the design team discussion.
+	would be used to provide public input to the design team discussion.
 	Nothing is yet to be considered for adoption as a WG item and this
 	should also not be considered design team output.
 
@@ -227,7 +242,8 @@
 	<http://www3.ietf.org/proceedings/07dec/slides/dnsop-1.pdf>
 
 	Alexander Mayrhofer: Would suggest user-level configuration of a name
-	  server also. Such as switching on and off caching functionality.
+	  server also. Such as switching on and off recursive or caching
+	  functionality.
 	Mohsen: Thought goal of design team was to work on requirements.
 	  This seems like a mixture of solution and requirements.
 	Roy: What you just saw is work we started with before. We have asked
@@ -259,7 +275,7 @@
 	No action required, the design team is supposed to meet during
 	the remaining IETF week.
 
-   5.3) DNS Search Path Issues                       [ 10:10 {audio 1:XX:XX} ]
+   5.3) DNS Search Path Issues                       [ 10:10 {audio 1:13:50} ]
         Peter Koch
 	<no slides>
 
@@ -287,7 +303,7 @@
 
 	ACTION: Rob & Peter to follow up and appoint editor(s)
 
-6) Other (non WG) Internet-Drafts                    [ 10:16 {audio 1:XX:XX} ]
+6) Other (non WG) Internet-Drafts                    [ 10:16 {audio 1:19:30} ]
 
    6.1) draft-licanhuang-dnsop-urnresolution-00.txt
 
@@ -303,7 +319,7 @@
 	Rob: Probably a good idea for people who have read it to explain
 	  to the author why they don't understand it.
 
-7) I/O with other WGs                                [ 10:18 {audio 1:XX:XX} ]
+7) I/O with other WGs                                [ 10:18 {audio 1:22:10} ]
 
    7.1) ENUM WG: Universal Deployment of EDNS0
 
@@ -315,6 +331,7 @@
 	George Michaelson: Tried to perform measurements on use of EDNS0.
 	  Occasionally get comments that it is almost universal, 90%,
 	  we can use this. I see 50% attempts specifying EDNS0.
+	  "EDNS0 is ubiquitous" is not operationally feasible.
 	  This must be borne in mind!
 	Peter: Intent was not to declare deployment of EDNS0 done, but
 	  rather to raise the awareness that EDNS0 has to be supported
@@ -323,8 +340,8 @@
 	  varying deployment, shows that our sampling techniques are not
 	  good. We don't really know what is going on yet. We need to do
 	  serious measurement work.
-	Olafur Guomundsson: dnsext has a document inm preparation that
-	  will address general DNS support in software.
+	Olafur Gudmundsson: dnsext has a document in preparation that
+	  will address general DNS support in software ("DNS profile").
 	  Will write that EDNS0 MUST be implemented.
 	Peter: So is there overlap?
 	Olafur: Middleboxes will have their own separate section (or
@@ -335,15 +352,16 @@
 	Olafur: Not optimistic about finishing it next year.
 	Peter: Chairs need to discuss.
 
-8) A.O.B.                                            [ 10:26 {audio 1:XX:XX} ]
+8) A.O.B.                                            [ 10:26 {audio 1:29:40} ]
 
   Antoin Verschuren reported that SIDN (NL TLD registry) sees small amounts
-  of /24 which are doing 10x rest of world in traffic (tens of thousands).
+  of /24 which are doing 10x rest of world in traffic (>10000 q/s).
   What can we do about it? How much traffic can we consider "abuse"?
   These are name grabbers. Long list of names that they are querying.
   This is a policy issue.
 
-  Rob: Do we want to work on developing guidance?
+  Rob: Seems not to affect only this name server operator. Do we want to
+	work on developing guidance?
   Liman: Suggest name holder or maybe server operator can set policy for their
 	 own zone. So, say, "this type of traffic we would consider an attack".
   Andrew: Gets us close to the idea of classifying certain domains as
@@ -370,5 +388,5 @@
   would need to write a draft first.
 
 -----------------------------------------------------------------------------
-Z) Meeting closed                                   [ 10:37 {audio X:XX:XX} ]
+Z) Meeting closed                                   [ 10:37 {audio 1:40:30} ]
 -----------------------------------------------------------------------------
_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Peter Koch <[email-masked]>
Date: Tue, 22 Jan 2008 23:32:36 +0100

Dear WG,

-Peter

 

    - RFCs published
@@ -62,43 +62,40 @@
 
-3) WG Charter
 
    4.1) AS112

 
 
         Awaiting WGLC

 
         Awaiting WGLC

 

 

 

 

 

 

@@ -227,7 +242,8 @@

 
@@ -287,7 +303,7 @@

 
 
@@ -303,7 +319,7 @@

 
@@ -315,6 +331,7 @@