Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-qdcount-is-one

[Suzanne Woolf]

Hi,

We're leaving this open a few more days to allow for any other comments. We'd 
like to submit it for publication before IETF 119.


Thanks,
Suzanne
For the chairs

On Feb 15, 2024, at 10:57 AM, Suzanne Woolf  wrote:

Hi,

The qdcount draft is brief and straightforward, and there have been no new 
changes proposed or issues introduced since the -01 version was posted. We 
think there’s likely consensus to advance it for publication.

This note starts a Working Group Last Call for draft-ietf-dnsop-qdcount-is-one.

Current version of the draft is available here: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/

The Current Intended Status of this document is: Proposed Standard

Please review the draft and offer relevant comments.

For WGLC, we need positive support and constructive comments; lack of objection 
is not enough. So if you think this draft should be published as an RFC, please 
say so.

If you feel 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:  29 
February, 2024.

thanks,
Suzanne (for the chairs)

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

[DNSOP] Working Group Last Call for draft-ietf-dnsop-qdcount-is-one

[Suzanne Woolf]

Hi,

The qdcount draft is brief and straightforward, and there have been no new 
changes proposed or issues introduced since the -01 version was posted. We 
think there’s likely consensus to advance it for publication.

This note starts a Working Group Last Call for draft-ietf-dnsop-qdcount-is-one.

Current version of the draft is available here: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qdcount-is-one/

The Current Intended Status of this document is: Proposed Standard

Please review the draft and offer relevant comments.

For WGLC, we need positive support and constructive comments; lack of objection 
is not enough. So if you think this draft should be published as an RFC, please 
say so.

If you feel 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:  29 
February, 2024.

thanks,
Suzanne (for the chairs)


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

Re: [DNSOP] [EXTERNAL] AD Review: draft-ietf-dnsop-zoneversion

[Suzanne Woolf]

Warren, authors, and WG:


Thanks Warren for being so clear about your concerns with this document.

Authors-- Please review Warren's comments. Tim won't be in Prague, but Benno or 
I would be happy to sit down with you (and Warren if you/he want) to discuss. 
Once you've had a chance to consider his comments we can put together a plan 
for when revisions can be done, or what issues might need more discussion 
before they can be addressed.

WG: If substantive revisions are needed, we'll have to do another WGLC so the 
WG can consider them. Even if the revisions are only editorial, however, we'll 
want some additional review before asking Warren to take it to the IESG and 
IETF Last Call. If you want to be part of that review cycle, please let the 
authors or chairs know.

Thanks everyone for your patience and some further effort to make sure we've 
got this right.


Best,
Suzanne
For the chairs

On Oct 23, 2023, at 11:30 AM, Warren Kumari  wrote:

Hi there, authors (and WG),

I support what the document is trying to accomplish — I think that ZONEVERSIONs 
will be really useful once standardized and deployed.

Unfortunately though, I believe that it needs revision and clarification before 
it is ready for last call.

I started performing my AD review, and found a bunch of nits (for which I have 
tried to suggest some fixes). I then ran into  the description of the 
LABELCOUNT parameter ("The LABELCOUNT number helps to disambiguate the name of 
the zone that this ZONEVERSION refers to.  For example if the response is a 
downward referral and the server is authoritative for some portion of the QNAME 
that differs from a server that is below the zone cut and is completely 
authoritative for a longer match of the labels in the QNAME.  Also, if the 
ANSWER section has more than one RR set with different zones (like a CNAME and 
a target name in another zone) the number of labels in the QNAME disambiguate 
such situation.") needs much more work than is appropriate for me to provide. 
Even if one starts with an understanding of what it is trying to say, this text 
is very very unclear.

The next few sentences don't really fix it either ("For example, a QNAME 
"www.example.com."
 or
  
"a.b.example.com"
 or 
"a.b.c.example.com"
 inside a 
"example.com."
 zone, that is not delegated not authoritative for those sub-zones in the same 
nameserver, has a LABELCOUNT field value of 2 for all such cases.") - what is 
"that is not delegated not authoritative" supposed to mean?

In addition to the LABELCOUNT issue, the rest of the document would also 
benefit from careful reading and cleanup, including of the Security 
Considerations section.


Nits:
1: Abstract
O: "This "ZONEVERSION" data allows to debug and diagnose problems by"
P: "This "ZONEVERSION" data allows for debugging and diagnosing problems by"
C: Grammar.

2: Introduction.
O: "The "ZONEVERSION" EDNS 
option
 
[RFC6891]
 allows a DNS querier to request to a DNS authoritative server to add an EDNS 
option in the answer of such query with a token field representing the version 
of the zone associated to the answered Resource Record (RR),"
P: "The "ZONEVERSION" EDNS 
option
 
[RFC6891]
 allows a DNS querier to request that a DNS authoritative server add an EDNS 
option containing a token field representing the version of the zone associated 
to the answered Resource Record (RR),"
C: Readability - the original seemed very long and complicated.

3:
O: "DNS data is of loose coherent nature,"
P: "DNS data is of loosely coherent nature,"
C: Grammar

4:
O: "Even when in zones where the SOA serial field have the meaning of zone 
version you could use a separate query to ask for the SOA RR of the zone and 
therefore know its SOA serial, but such separate query is performed in a 
different time and could arrive from another authoritative source (for example, 
in the case the server is anycasted as described in Section 
4.9
 of 
[RFC4786]),
 so it's not directly correlated with the original query."
C: This sentence needs a complete rewrite.

5:
O: "The ZONEVERSION EDNS extension can have different meaning depending on the 
semantics of the zone maintainer and implementation of nameservers."
P: "The 

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-generalized-dns-notify

[Suzanne Woolf]

Hi,

The chairs have reviewed the discussion on this draft and find support for 
adopting it as a Working Group document.

Thanks to everyone who commented and especially those who offered to review.

Authors, please submit a draft-ietf-dnsop version when you're ready.


Thanks,
Suzanne & Tim & Benno

On Sep 14, 2023, at 10:10 PM, Suzanne Woolf  wrote:

Dear colleagues,

This note starts a Call for Adoption for 
draft-thomassen-dnsop-generalized-dns-notify.

The draft is available here: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/

Some time in the next two weeks, please review this draft to see if you think 
it is suitable for adoption by DNSOP, and send any comments to the list, 
clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc. It’s 
particularly helpful if you can comment on whether you would implement or use 
this feature.

This call for adoption ends: 28 September 2023

Thanks,
Suzanne
For DNSOP co-chairs

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

[DNSOP] Call for Adoption: draft-thomassen-dnsop-generalized-dns-notify

[Suzanne Woolf]

Dear colleagues,

This note starts a Call for Adoption for 
draft-thomassen-dnsop-generalized-dns-notify.

The draft is available here: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/

Some time in the next two weeks, please review this draft to see if you think 
it is suitable for adoption by DNSOP, and send any comments to the list, 
clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc. It’s 
particularly helpful if you can comment on whether you would implement or use 
this feature.

This call for adoption ends: 28 September 2023

Thanks,
Suzanne
For DNSOP co-chairs



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

[DNSOP] Loose ends: closing WGLC on draft-ietf-dnsop-zoneversion-02

[Suzanne Woolf]

Dear colleagues,

Several weeks ago we opened a WGLC on draft-ietf-dnsop-zoneversion. There was 
not a huge volume of response, but what we heard was strongly positive. The 
chairs see consensus to move this document on to publication.

Thanks to everyone who worked on the draft and commented in the Last Call.


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

[DNSOP] WGLC for draft-ietf-dnsop-zoneversion

[Suzanne Woolf]

Colleagues,


This email begins a Working Group Last Call for draft-ietf-dnsop-zoneversion-02 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/).

If you've reviewed this document and think it's ready for publication, please 
let us and the WG know, by responding on-list to this message. We particularly 
need to hear from implementers and operators whether this EDNS option is 
implementable and useful.

If you don't think it's ready, and have specific concerns or suggestions, 
please let us know about those too.

The Last Call will be two weeks, ending on Thursday 11 May.

Thanks to everyone who's offered comments and suggestions on the draft to date.


Suzanne, Tim, and Benno



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

[DNSOP] Publication has been requested for draft-ietf-dnsop-glue-is-not-optional-08

[Suzanne Woolf via Datatracker]

Suzanne Woolf has requested publication of 
draft-ietf-dnsop-glue-is-not-optional-08 as Proposed Standard on behalf of the 
DNSOP working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/


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

[DNSOP] Working Group Last Call for "DNS Glue Requirements in Referral Responses" (draft-ietf-dnsop-glue-is-not-optional)

[Suzanne Woolf]

Dear DNSOP WG,

Following lengthy discussion, including the latest consultation with the. 
Working Group on bailiwick and in-domain/sibling name servers terminology, the 
authors and chairs believe this document is ready for Working Group Last Call.

As described earlier, draft-ietf-dnsop-rfc8499bis has a normative dependence on 
draft-ietf-dnsop-glue-is-not-optional, so we’re putting both in Working Group 
Last Call together.

This starts a Working Group Last Call for: 
draft-ietf-dnsop-glue-is-not-optional.

Current version of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional

The Current Intended Status of this document is: Proposed Standard.
Please review the draft and offer relevant comments, including review of 
whether the text in this document adequately supports the updated definitions 
offered in 8499bis.

As usual it’s helpful to have statements of support from those who believe this 
document is ready to advance. Also as usual, 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, ending on:
March 7, 2023

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

[DNSOP] WGLC for draft-ietf-dnsop-alt-tld

[Suzanne Woolf]

Dear colleagues,

After some discussion, the chairs have found we have rough consensus to advance 
draft-ietf-dnsop-alt-tld.

The authors have been considering the WGLC comments and will post a new draft 
shortly.

As we’ve mentioned before, the responsible AD for this draft will be Rob 
Wilton, as our usual AD (Warren) is a co-author on the draft.

Thanks to everyone who contributed to the discussion over the history of the 
draft.


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

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

[Suzanne Woolf]

Colleagues,

This WGLC is closed,  with many thanks to everyone who commented.

The chairs and editors are reviewing the comments and will summarize in the 
next few days.


Suzanne, for the chairs

From: Suzanne Woolf 
Date: Tuesday, December 13, 2022 at 3:26 PM
To: "dnsop@ietf.org" 
Cc: "dnsop-cha...@ietf.org" , "Rob Wilton (rwilton)" 

Subject: WGLC for draft-ietf-dnsop-alt-tld
Resent-From: 
Resent-To: , , 
Resent-Date: Tuesday, December 13, 2022 at 3:26 PM


Dear colleagues,


This message will serve to start a Working Group Last Call on “The ALT Special 
Use Top Level Domain” 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/<https://protect-us.mimecast.com/s/aTUqCjRNX8ilAwvtWUttq?domain=datatracker.ietf.org/>).
 Due to the end-of-year holidays, we’re starting it now and will give it four 
weeks.


As you’ve seen from Paul Hoffman’s email, the authors have updated to version 
19 based on the feedback they heard at IETF 115. Thanks Paul and Warren!


The WG is very familiar with this document by now, and the WGLC is to determine 
whether the document has rough consensus to progress. The chairs need to know 
whether you support it (which, for this purpose, includes “I can live with 
it”), or actively oppose publishing it.


Please also assume that any necessary liaison communications with ICANN will be 
undertaken if this document has WG consensus to move forward. Managing the 
potential for misunderstanding or differences of opinion among relevant 
organizations is the primary reason why the IETF has liaison relationships. The 
IETF liaison to the ICANN Board is Harald Alvestrand, who has been monitoring 
the conversations about alt-tld on the mailing list and has discussed the draft 
with the chairs and with Rob Wilton as the responsible AD.


Start date: 13 December 2022

End date:  10 January 2023


Many thanks,

Suzanne, Tim, and Benno



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

[DNSOP] WGLC for draft-ietf-dnsop-alt-tld

[Suzanne Woolf]

Dear colleagues,


This message will serve to start a Working Group Last Call on “The ALT Special 
Use Top Level Domain” 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/). Due to the 
end-of-year holidays, we’re starting it now and will give it four weeks.


As you’ve seen from Paul Hoffman’s email, the authors have updated to version 
19 based on the feedback they heard at IETF 115. Thanks Paul and Warren!


The WG is very familiar with this document by now, and the WGLC is to determine 
whether the document has rough consensus to progress. The chairs need to know 
whether you support it (which, for this purpose, includes “I can live with 
it”), or actively oppose publishing it.


Please also assume that any necessary liaison communications with ICANN will be 
undertaken if this document has WG consensus to move forward. Managing the 
potential for misunderstanding or differences of opinion among relevant 
organizations is the primary reason why the IETF has liaison relationships. The 
IETF liaison to the ICANN Board is Harald Alvestrand, who has been monitoring 
the conversations about alt-tld on the mailing list and has discussed the draft 
with the chairs and with Rob Wilton as the responsible AD.


Start date: 13 December 2022

End date:  10 January 2023



Many thanks,

Suzanne, Tim, and Benno



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

[DNSOP] Minute-taker Re: DNSOP at IETF 115: meeting details, scribe needed, etc.

[Suzanne Woolf]

And of course we need a minute-taker! Please let the chairs know if you’re 
available to do this.

Suzanne


On 11/7/22, 7:07 AM, "Suzanne Woolf" mailto:swo...@pir.org>> 
wrote:

Hi all,

DNSOP at IETF 115 will be meeting in the first slot on Tuesday, Nov. 7, at 
9:30-11:30 local time.

Location on-site is Kensington I, West Wing, Third Floor.

The IETF agenda at 
https://datatracker.ietf.org/meeting/115/agenda<https://protect-us.mimecast.com/s/21G9C1wP04s6rPvILw4bw?domain=datatracker.ietf.org>
 includes links to the WG meeting agenda and other materials, floor plans, and 
meetecho information for on-site and remote participation.

We also need a scribe—noting that the IETF has phased out jabber for zulip as 
the meeting chat. If you haven’t yet set up zulip, you can find details at 
https://www.ietf.org/how/meetings/groupchat/<https://protect-us.mimecast.com/s/Iv8YC2kQyWFVLBnU1FC6M?domain=ietf.org/>.

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

[DNSOP] DNSOP at IETF 115: meeting details, scribe needed, etc.

[Suzanne Woolf]

Hi all,

DNSOP at IETF 115 will be meeting in the first slot on Tuesday, Nov. 7, at 
9:30-11:30 local time.

Location on-site is Kensington I, West Wing, Third Floor.

The IETF agenda at https://datatracker.ietf.org/meeting/115/agenda includes 
links to the WG meeting agenda and other materials, floor plans, and meetecho 
information for on-site and remote participation.

We also need a scribe—noting that the IETF has phased out jabber for zulip as 
the meeting chat. If you haven’t yet set up zulip, you can find details at 
https://www.ietf.org/how/meetings/groupchat/.

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

[DNSOP] New agenda, and alt-tld draft at IETF 115

[Suzanne Woolf]

Dear colleagues,

Please note the new revision of our agenda for IETF 115 at 
https://datatracker.ietf.org/meeting/115/materials/agenda-115-dnsop-01.

The main change is that we've added some time for draft-ietf-dnsop-alt-tld. The 
chairs have discussed extensively what to do next with alt-tld, since we're 
hearing from all sides: those who think it's ready for Last Call, those who 
think it's basically OK but needs some more work, and those who oppose it 
heartily or simply want never to hear about it again. The question for us 
regarding the agenda at 115 has been how much we will accomplish with giving it 
meeting time. 

The chairs set out some comments on the -17 version, which appear to have been 
addressed in the -18 version. We agree with the editors that there are a couple 
of issues that may need further discussion.

The time set aside for alt-tld in our meeting next week is intended to let us 
we find out how far we might be from consensus on the current draft and whether 
people still feel there are new things to say. If they do, it seems to us 
unlikely that we'll resolve those issues in a few minutes at IETF 115, and 
we'll do an interim to resolve them. Otherwise, we expect to put it in the 
queue and move it to WGLC as soon as we've got a couple of other drafts through 
WGLC. 



Best,

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

Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

[Suzanne Woolf]

Eliot,

On Oct 23, 2022, at 2:15 AM, Eliot Lear mailto:l...@lear.ch>> 
wrote:


On 23.10.22 05:40, John Levine wrote:
It appears that Eliot Lear  mailto:l...@lear.ch>> said:
As a matter of practicality, a registry surely will be form.  It is
simply a matter of whether the IANA will host it.  If the IANA does not
host it, then by shifting it elsewhere this group is actually weakening
the IANA function, and that would be sad.
But trying to turn IANA and .alt into a junior version of ICANN would
be much worse than sad.

Nobody is trying to do that.


I believe the point is that it would happen if the IETF ran such a registry, 
regardless of intent: if the IETF is deciding who gets to use names that look 
like domain names, it's at high risk of walking directly into the conditions 
that led to the creation of ICANN in the first place. The exception is names 
under .arpa, which is explicitly under the administration of the IETF.
Personally, I agree with the comment that several people have now made, that 
such an attempt is likely to be fraught with legal and reputation risk. But for 
the WG's purposes those comments are somewhat speculative.
We've been told repeatedly that no one wants to engage legal analysis or 
liaison communications on a document that doesn't have WG consensus. Any member 
of the IAB might be able to correct or add to this assessment, but it's 
currently the chairs' understanding that we or the responsible AD should 
request any liaison communications and presumably legal review after the WG 
process concludes. (I understand frustration with this, but I also understand 
the reasoning: if a draft doesn't have at least WG consensus, that 
administrative machinery is not necessary.)

The chairs would like to hear it if anyone has anything new to say about such a 
registry on its technical merits, including specific registry policy and 
operational challenges with administering it if the non-technical risks could 
be managed.


Thanks,
Suzanne

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

[DNSOP] Speculations Re: [EXTERNAL] Possible alt-tld last call?

[Suzanne Woolf]

Not meaning to pick personally on Eliot or Paul, some of these issues are very 
difficult to separate.

> On Oct 17, 2022, at 11:53 AM, Paul Wouters  wrote:
> 
> 
> On Mon, 17 Oct 2022, Eliot Lear wrote:
> 
> > Let's please leave Internet lawyering to lawyers.  If people want a legal 
> > opinion on this draft, the IETF does have resources for that.
> 
> But it is to the core of the ICANN / IETF divide, so IETF shouldn't wade
> into ICANN territory.

We don't know what ICANN considers an attempt to "wade into ICANN territory," 
and there's nothing the WG can do to resolve this question. Such questions are 
why we have liaisons, which the IAB administers for the IETF.

There's a perfectly healthy liaison relationship between the IETF and ICANN, 
which we can ask to exercise when/if we have something specific from the WG to 
share. 

Our part is to stop speculating on the views of another independent body, and 
decide whether we need .alt from a technical (protocol and operations) point of 
view. Legal and liaison resources are available as needed, but none of those 
conversations will go anywhere without a concrete technical assessment. 

It would be helpful if we could focus on technical/operational impacts and on 
whether .alt would in fact solve the problems that the draft claims to address. 


Thanks,
Suzanne
(For the chairs)

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

Re: [DNSOP] [EXTERNAL] Possible alt-tld last call?

[Suzanne Woolf]

Hi,


> On Oct 16, 2022, at 10:20 PM, Paul Wouters  wrote:
> 
> On Sun, 16 Oct 2022, Suzanne Woolf wrote:
> 
> > 1. As far as I can tell, this draft does not comply with RFC 6761. This is 
> > a problem for two reasons.
> 
> One could advance the 6761bis proposal document first, which would
> remove these non-compliance items as those would be no longer needed
> (as the bis document proposal removes it as these were not consistently
> required in the past). Alternatively, ignoring it wouldn't be the first
> time these are ignored, so I guess there is a precedence of ignoring it.

I've read the 6761bis draft (draft-hoffman-rfc6761bis), and it struck me as a 
bit baffling that the proposed answer to a couple of cases of non-compliance 
with a MUST in a standards-track registry policy document is to throw out the 
MUST, rather than address a possible problem with approving or processing 
requests. 

More to the point, the questions are there to make sure that DNS operators (and 
others) know what is required of their configurations and protocols in order to 
interoperate between DNS and non-DNS operations and protocols that are using 
domain name conventions for their names. The draft appears to propose keeping 
the original registry policy ("Standards Action or IESG Approval") while 
reducing the amount of information required as a basis for a decision, which 
seems unlikely to make things any easier or more effective for the IESG, DNS 
operators and implementers, or anyone else.

Recall that the request for .onion (RFC 7686) was initiated under the same 
registry policy we have today, and the IESG could have offered its approval 
without DNSOP (or anyone else) providing a standards-track document taken 
through normal WG process. They preferred giving it to the IETF WG whose 
constituency is DNS operators and implementers.

In other words, I've always thought that all of Section 5, including the MUST, 
is there to support interoperability, and removing the requirement to provide 
relevant information seems like a step backwards for that goal. 

> I think it draft would be better if it said something along the lines
> of:
> 
> No code changes are required to properly handle leaked queries for .alt
> into the DNS, but:
> 
> 1) Implementations MAY handle .alt specially by (pre)fetching the proofs
> of non-existence of .alt and serve these for all .alt queries.
> 2) implementations MAY rely on their query minimalization to accomplish 1)
> 3) or MAY do nothing special, which should work fine but might leak SLD
> queries to the root if the implementation and its querier didn't do query
> minimalization)
> 4) MAY return FORMERR on .alt queries that in some ways violate the DNS
> specification (so that no code changes are mandatory to support the
> madness .alt queries could bring in, eg >63 SLD names)

This is the kind of detail I think is important to provide in a document that's 
essentially about interoperability, whether it's explicitly required or not. 
Thank you.


Suzanne

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

[DNSOP] Possible alt-tld last call?

[Suzanne Woolf]

Dear Colleagues,


The chairs have gotten a couple of requests, off-list and on, for a WGLC on 
draft-ietf-dnsop-alt-tld.

We’ve reviewed the current draft closely and have some concerns that we feel 
need to be resolved before any effort to move the draft forward. (Suzanne wrote 
this but it’s been discussed among all of the co-chairs.)

1. As far as I can tell, this draft does not comply with RFC 6761. This is a 
problem for two reasons.

First, this creates a process problem in that RFC 6761 is the standards-track 
document that specifies how the SUDN registry is to be administered, so a 
request that doesn’t meet the requirements in 6761 can’t (or at least 
shouldn’t) go into the registry.

RFC 6761 section 4 asserts:

The specification also MUST state, in each of the seven "Domain Name 
Reservation Considerations" categories
below, what special treatment, if any, is to be applied.

The alt-tld draft ignores this MUST, without explanation (unless I missed it).

The substantive issue is that the questions in Section 5 are there to make sure 
there’s a full description of the expected handling of a proposed name by the 
assorted components that take part in DNS operations and protocol. The draft 
answers at least some of the Section 5 questions, but the answers are largely 
implied.

For example, the draft says that DNS resolvers seeing .alt names "do not need 
to look them up in the DNS context”, but a big part of the point of codifying 
these names is the assumption that queries will leak and DNS servers will see 
them. (“Do not need to” isn’t even “SHOULD not”.) It’s implied that .alt is 
simply not in the public DNS root zone and the root servers (or better yet, any 
intermediate resolver) should answer “name error”/NXDOMAIN for such queries. 
But this should probably be said explicitly, because people who configure DNS 
servers and services shouldn’t have to guess what’s being implied here. (The WG 
discussed the possibility that such queries should be blackholed and not 
answered at all, which is in some ways an obvious answer. Clarification of why 
this was discarded might also be helpful.)

So, the current draft isn’t meeting the requirements for the registry, and also 
doesn’t clearly answer substantive questions about what DNS operators are 
expected to do. This makes me uncomfortable doing a WGLC without a new rev. It 
would be Rob Wilton’s call of course (as AD for this draft, substituting for 
Warren) but I’m really uneasy with a WGLC without those changes— they seem 
rather too large to punt for a post-WGLC version.

2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the basis 
that having the IETF “recognize” (if only by recording) such pseudo-delegations 
may serve to attract unwanted attention to the IETF’s supposed recognition of 
alternate (non-DNS) namespaces as reservations of the namespace from the 
shared, common DNS root. We’re still being denounced in certain corners for 
.onion. It might be good to have a paragraph calling out specifically why .alt 
is not a delegation of a TLD from the DNS root by the IETF, even though it 
looks like one. (We didn’t invent this problem, because we didn’t make the 
decision that top-level domain labels should be used by other protocols in a 
way that led to confusion. But let’s not propagate it.)

3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term 
“registered” differently than common usage. Judging from searches on RFC 6761 
and RFC 8499, it’s ambiguous for DNS naming and resolution, and “registered” 
can definitely mean something different to a registry or registrar than it does 
to a DNS operator. To people who operate TLD registries, a name can be 
“registered” and still may or may not be delegated. (“Label” is defined in 
8499, “register” and “delegate” are not.) And, in the reference to “TLD,” it 
feels strange to expand the acronym to “Top-level label” even if “label” is the 
right word for what you’re talking about.

Thanks to the editors and the WG for considering these comments.


Best,
Suzanne
(For the chairs)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] An Orderly Way Forward on Special Use Names (Yes, again)

[Suzanne Woolf]

Dear colleagues,


The chairs have been working for some time on a plan to address the ongoing 
issues around special use domain names (described in RFC 6761) and the domain 
namespace. These issues are described in RFC8244 - "Special-Use Domain Names 
Problem Statement".


WHAT, THIS AGAIN?



(TL;DR: skip to “WHAT NOW?” below.)


First what we need: a plan for the WG that will ensure, as best we can, that 
the WG has weighed in on domain namespace issues that affect the integrity and 
usefulness of the DNS, without getting entangled in issues that belong to other 
bodies (or to the users and developers of the Internet more generally). As our 
charter says, we agreed to “Publish documents that attempt to better define the 
overlapping area among the public DNS root, DNS-like names as used in local or 
restricted naming scopes, and the 'special names' registry that IETF manages, 
perhaps including how they might interact. This work must take into 
consideration issues that are strictly beyond the operation of the DNS itself, 
and the working group will consult with IETF liaisons to other organizations as 
appropriate.” (This language dates back to at least 2014.)


Why we need it: In addition to the commitment to the community from our 
charter, this area has continued to provide new drafts, new concerns, and new 
questions. As painful as it may be to attempt to deal with them, it does seem 
better for the WG to try than to ignore the questions and hope they’ll go away. 
At the very least, the IETF needs some guidance on how protocols developed 
within the IETF can implement special use names.


There is no requirement that a special use domain name be a single-label (or 
“TLD”) name, but as they have significant policy issues (as noted in RFC2860 - 
"Memorandum of Understanding Concerning the Technical Work of the Internet 
Assigned Numbers Authority") they 
generate the most discussion and get the most attention.


The primary value of the DNS protocol and naming conventions is serving as a 
useful and interoperable default for Internet naming. Ambiguity for 
applications in how to resolve domain names undermines interoperability across 
the namespace. The risks include not only explicit collisions but also a 
general erosion of confidence.


Protecting the usefulness of the DNS may require some kind of coordination 
mechanism so that future developers can avoid ambiguity of resolution for 
Internet names.


RFC 6761 establishes a registry for special use names, but its direct guidance 
on how to determine a name is appropriate to treat as “special use” is 
unscalable and potentially incomplete.  At one point we had six or seven 
different drafts, requesting a total of more than 40 single-label names, 
submitted for adoption by the WG, and any one of them seemed likely to result 
in controversy.


The .onion case (RFC 7686) was resolved by making the draft a standards-track 
work item in the WG, but this exposed the difficulty in applying RFC 6761 as 
written. As the IETF Chair wrote about the .onion special use registration, 
“However, subsequent to this action, the IESG believes RFC 6761 needs action, 
and substantial community input. It needs to be open for review and 
modification because the current process is unscalable. Several other names had 
also been submitted for consideration as special names, and the RFC may not 
give adequate guidance about when names should be identified as special names. 
Special names should also be, as the name implies – special and rare. The DNSOP 
working group is chartered to address this RFC 6761 review.” 
(https://www.ietf.org/blog/onion/)


We paused consideration of additional special-use names drafts until we could 
tackle an update to RFC 6761. RFC 8244 provided a survey of issues that had 
come up; however, attempts to address those issues haven’t been supported by 
the WG.


We understand that some WG participants are certain that anything touching on 
the use or the integrity of the domain namespace is ICANN’s problem and not the 
IETF’s. However, neither the IESG, nor the IAB, nor ICANN seem to agree (see 
https://www.icann.org/en/system/files/correspondence/marby-to-cooper-kuhlewind-22oct20-en.pdf,
 from the CEO of ICANN, and the reply from the IETF chair and IAB chair at 
https://www.icann.org/en/system/files/correspondence/cooper-kuhlewind-to-marby-12nov20-en.pdf).
 This correspondence leaves details undefined (which seems entirely 
appropriate) but both parties explicitly state they see the domain namespace as 
a shared responsibility. When ICANN received a recommendation involving a 
reserved name for private use from an internal technical advisory body, they 
reached out to the IETF for its views. This is a normal use of the liaison 
relationship the IETF and ICANN instituted more than 15 years ago.


NOW WHAT?


For the above reasons, it seems we have to make a 

[DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

[Suzanne Woolf]

Dear colleagues,


This message starts the Working Group Last Call for 
draft-ietf-dnsop-avoid-fragmentation 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). The 
requested status is BCP.

Since we're starting the Last Call during the IETF week, and many folks are on 
holidays in the next few weeks, the WGLC will end in three weeks (instead of 
the usual two), on August 16.

Substantive comments to the list, please. It’s fine for minor edits to go 
direct to the authors. We need to hear positive support to advance it, or your 
comments on what still needs to be done. 



Thanks,
Suzanne
For the chairs


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

[DNSOP] List conduct (was: Re: DNSSEC as a Best Current Practice)

[Suzanne Woolf]

Colleagues,

As some of you have noted,  the thread under the subject “DNSSEC as a Best 
Current Practice” has included some inappropriate posts, not consistent with 
the IETF Code of Conduct or guidance on keeping the WG mailing list 
professional and productive. A DNSOP mailing list participant has been warned 
about their posts and asked to stop.

As a reminder to the list: people here can be vigorous and intense in their 
arguments and tone, but generally stay to the civil and constructive side, and 
the chairs don’t like stepping into substantive technical discussions. However, 
we do monitor the list, do listen to complaints, and do have the ability to 
take action when list conversation turns into persistently repeating arguments 
that have already been addressed, ad hominem attacks, or other behavior that 
has no apparent purpose besides disruption.

It’s important to bring your best technical arguments to DNSOP, but just as 
important in getting our work done to bring civility and respect for everyone 
else. These things matter even more over the last couple of years of seeing 
each other only online.

In general, DNSOP has done pretty well at keeping things professional and 
productive. It’s part of the chairs’ job to keep it that way. Thanks everyone,


Your DNSOP chairs,
Tim, Suzanne, and Benno






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

[DNSOP] Prep for IETF 113

[Suzanne Woolf]

Dear Colleagues,

We've got a couple of notes to share in advance of IETF 113.

First, please get your requests for DNSOP agenda time to the chairs as soon as 
you can. Our preliminary agenda is due to the secretariat by 9 March (see 
https://datatracker.ietf.org/meeting/113/important-dates/).

Note that the drafts deadline is 7 March (two weeks from today). Please get new 
drafts you want the WG to consider submitted by then, or update earlier drafts 
if you've gotten feedback you haven't integrated yet. This helps us set 
priorities for agenda time.

The preliminary schedule is out (see 
https://datatracker.ietf.org/meeting/agenda/) but "preliminary" is "mostly 
final," since it represents a solution to a complex game of "calendar and hotel 
facility tetris".  You will note that this time, DNSOP has one time slot, 
Tuesday morning at 10am-noon (local time in Vienna).

We only requested one slot, partly to help the secretariat with the tetris 
problem (fewer slots than usual for the hybrid meeting) but mostly because we 
believe the interim meetings we’ve been holding have spread out the workload 
for the WG so we don't really need two. This is an experiment; if it turns out 
one isn't enough, we'll reconsider for the next IETF.

Finally, we found the poll we did late in 2021, asking WG participants for 
their views on various drafts we'd already adopted, was very helpful, so we 
expect to run another poll before IETF 113. We have a distinct process for 
deciding what drafts to adopt, but the poll provides us with some guidance on 
priorities among work items. We'll send details in another message soon.

Benno will be in Vienna, and is looking forward to seeing any of you who are 
there. Tim and Suzanne regret that they'll be participating remotely, but hope 
to see you at IETF 114.


Much thanks,
Suzanne, Benno, and Tim


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

[DNSOP] Some updates for IETF 112

[Suzanne Woolf]

Dear colleagues,


IETF 112 is coming up on us very soon, so we’ve summarized some recent 
activities here.

The draft cutoff for IETF 112 is Oct. 25, midnight UTC, so if you want to 
submit a new or updated draft, you have a little less than a week. 

DNSOP meeting slots are:
   
16:00-18:00 UTC on Thursday Nov. 11
14:30-15:30 UTC on Friday Nov. 12

You’ve seen the scheduling for the 2nd interim since IETF 111, planned for Oct. 
26. 

In the first interim, on Sept. 14, we were able to make significant progress on 
open issues in the drafts we discussed, avoid-fragmentation and 
glue-is-not-optional. We’d like to move these to Last Call once those issues 
are resolved.

Draft-ietf-dnsop-avoid-fragmentation:
- Some discussion of how to provide clear advice to operators even if 
recommending a range of values rather than a single value. Different values are 
appropriate for different situations, and it might work best to briefly discuss 
how to choose among possible values
- Some editorial issues
- Authors are working on revisions based on discussion

Draft-ietf-dnsop-glue-is-not-optional
- Is sibling glue optional or required? (MUST or SHOULD; is TC=1 
required if not all glue fits?)
- Suggestion to include more examples (both valid and invalid)
- clarification requested on truncation
- Authors submitted revised draft on Oct. 11, Duane summarized changes 
to the list

See you at IETF 112,


Benno, TIm, and Suzanne

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

Re: [DNSOP] [Ext] SHA-1 DS algo in arpa. :)

[Suzanne Woolf]

Hi,

(Wes and Warren— cc’d as IAB and IESG members, do you guys have any further 
guidance?)

> On Sep 9, 2021, at 12:12 PM, Joe Abley  wrote
> 
> The IETF (well, the IAB) has administrative control over the contents of the 
> ARPA zone. I do not know in practice whether this extends to the machinery of 
> how the zone is provisioned. 
> 
> The operation of the zone is carried out by PTI, I think. It is distributed 
> to its authoritative servers (which are also root servers) in a process that 
> is similar in some respects to the way the root zone is managed.
> 
> I would drop a note to Kim Davies and ask his advice if you want to make some 
> kind of progress. While it seems perfectly plausible to make this kind of 
> change by way of a published RFC with IAB review, it's not at all clear to me 
> that such a heavyweight approach is necessary. 

It might also be helpful to review RFC 3172 ("Management Guidelines & 
Operational Requirements for the Address and Routing Parameter Area Domain 
("arpa”)”).

It doesn’t directly address “the machinery of how the zone is provisioned” but 
it does make some guidelines clear. 

Personally, I’d start with the IAB or IESG, if only to find out how much 
process was required to get it signed in the first place (I don’t recall, and 
can’t immediately find a reference). Maintaining compliance with the evolving 
spec for DNSSEC and crypto algorithms should not be too difficult, but will 
probably have to be documented somewhere and approved by the IAB.


Suzanne

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

Re: [DNSOP] Dropping the draft "The DELEGATION_ONLY DNSKEY flag"

[Suzanne Woolf]

Hi,

The chairs have discussed the DELEGATION_ONLY draft extensively. It’s 
reasonable to ask how we reached the conclusions we did, so here’s what we were 
thinking.

> On Aug 9, 2021, at 4:34 PM, Paul Wouters  > wrote:
> 
> On Thu, 5 Aug 2021, Tim Wicinski wrote:
> 
>> Subject: [DNSOP] Dropping the draft "The DELEGATION_ONLY DNSKEY flag"
> 
>> This came up in the poll, but also the discussion on priorities.  There 
>> seems to be
>> strong feelings on dropping this draft.   We adopted with the idea that if 
>> we could
>> not find WG consensus, we were not going to advance it, and that seems to be 
>> the case.
> 
> We had several people in favour of the experiment, and Joe Abley against
> it. May I know how you determined the lack of consensus versus the in
> "in the rough" ? Especially since in this case, we are talking about
> something that is completely optional to implement and deploy, so that
> people who don't like it find zero negative effects from this.

Multiple people who are not Joe Abley have spoken up, in this thread and 
previously, to question the usefulness of the draft. 

As a relatively minor point, calling the flag allocation an “experiment” is a 
bit confusing without a hypothesis or a way to assess the outcome. In any case, 
a standards track RFC is required to modify the DNSKEY FLAGS registry 
(https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml#dnskey-flags-1
 
)—
 not Informational or Experimental. The DNSKEY FLAGS field is small and there’s 
no provision for calling back the code point delegation from IANA if the 
“experiment” fails.

The larger point is that it’s not clear what demand there is for this feature. 
The draft discusses TLDs almost exclusively, which is a limited use case. In 
previous discussion on the draft, more than one person asserted that some TLDs, 
including very large ones, may sometimes rely on the behavior this flag is 
designed to obstruct, so are extremely unlikely to ever deploy it. Others 
expressed skepticism regarding the costs and benefits the flag provides over 
other, higher-probability attacks. 

It’s always possible we overlooked something, but there’s no implementation 
status discussed in the current draft, and we also didn’t see anyone speaking 
up for a TLD that would deploy the DELEGATION_ONLY flag if they had it. 

It seems to us that consensus to support the draft would include substantial 
evidence that the feature would be implemented and used.

We’d be willing to re-open WG consideration of this draft if implementers or 
TLD operators speak up in support. 


Suzanne/Tim/Benno



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

[DNSOP] Fwd: Questions about the used of ISO 3166-1 user defined codes

[Suzanne Woolf]

Dear colleagues,


The internet-draft draft-ietf-dnsop-private-use-tld, adopted by the WG late 
last year, includes text that would create entries in the IANA Special-Use 
Domain Names registry for certain ISO 3166-1 two-letter codes that have been 
labeled by the appropriate ISO agency as “user-assigned”, formally "ISO 3166-1 
alpha-2 User-assigned Code Elements”. The chairs requested guidance on whether 
this was an appropriate use of another standards body’s work (not an unusual 
step when an IETF RFC proposes to include elements or properties of another 
organization’s standards, especially a standards-track RFC).

Liaison relationships are managed for the IETF by the IAB, which conveyed our 
questions to John Klensin as the liaison manager for the IETF’s relationship 
with the ISO-3166 maintenance agency.  Below we’ve forwarded his comments on 
the response to the IAB’s questions.

Please note that this communication is from the official IAB liaison to 
ISO/TC46. Please note also that in his view, based on lengthy experience and 
recent conversations, there will be no formal response from ISO regarding the 
questions the IAB posed on our behalf in the liaison communication at 
https://datatracker.ietf.org/liaison/1720/ 
, because there’s no mechanism for 
one to be created. (This explanation appears under item 1, starting with the 
second paragraph.)

However, even if we leave the question open of whether there will be further 
response to the liaison request from the IAB, it’s the case today that the note 
below from John is the response we have, and it does contain some guidance for 
the WG. We will discuss further in Thursday’s meeting.


Best,
Suzanne
For the DNSOP chairs

> Begin forwarded message:
> 
> From: John C Klensin 
> Subject: Questions about the used of ISO 3166-1 user defined codes
> Date: July 23, 2021 at 6:58:42 PM EDT
> To: dnsop-cha...@ietf.org
> Resent-From: 
> Resent-To: be...@nlnetlabs.nl, tjw.i...@gmail.com, suzworldw...@gmail.com
> 
> DNSOP Chairs,
> 
> I am writing in my capacity as liaison to ISO/TC 46, the
> Technical Committee responsible for the ISO 3166 Standard and,
> via its WG 2 and 3166/MA groups, the development and
> maintenance of that Standard. It is probably worth noting that
> I have additional perspectives on the use of the ISO 3166 (now
> 3166-1:2020 [1]) alpha-2 code space in the DNS having, among
> other things, been part of the original discussions leading to
> the decision to use those codes for DNS ccTLD purposes. I was
> then part of what became known as the IDNB when RFC 1591 was
> published and until the handoff of IANA DNS responsibility from
> USC-ISI to ICANN.
> 
> The IAB sent a liaison message to TC 46 about the questions
> raised by the proposal for use of user-assigned code points as
> suggested by draft-ietf-dnsop-private-use-tld (referred to as
> "the Arends et al.I-D" or just "the I-D" below). I was
> instructed by the IAB to follow up on that communication.  I
> have done so.  The notes below are a summary of discussions
> with ISO/TC 46 and ISO/TC 46/WG 2 leadership and the responses I
> received.   They also reflect my effort to put parts of those
> responses into a context that reflects similarities between ISO
> and IETF procedures.
> 
> The issues appear to me to come down to two key questions. In
> addition to those questions, which relate to the interpretation
> and use of ISO 3166-1, there are also some additional issues
> that involve long-established principles about the use of the
> two-letter DNS TLD space and the reasons for them; they are not
> addressed in this note. 
> 
> 
> (1) Is using the user-assigned code space of the 3166 alpha-2
>   namespace for this purpose consistent with the intent of the
>   standard?
> 
> Summary answer:  No.  Also terms that IETF considers equivalent
> may not be equivalent elsewhere.  Details follow.
> 
> My reading of the Standard, confirmed by discussions with the
> ISO Technical Program Manager for TC 46 and the Chair of 
> TC 46/WG 2, is that it is clear that both the user-assigned
> space and the various reserved lists are for use by countries
> and country-like entities in situations were country codes
> would be appropriate and needed and not for other purposes. I
> am guessing that the provisions in the Arends et al. I-D result
> from confusion that conflated "user-assigned" as used in ISO
> 3166-1 with "private-use". The IETF often uses the two terms
> interchangeably, both meaning that the relevant standard has
> nothing to say on the matter and that people are free to use
> code points thus designated for any purpose they consider
> suitable.  That is not the case with the definitions of ISO
> 3166-1: the private Internets contemplated by the I-D are, as
> that draft makes clear, not the country-like entities
> contemplated by the ISO Standard.
> 
> It is important to note that, like the IETF, ISO has no
> mechanisms to offer official 

[DNSOP] Publication has been requested for draft-ietf-dnsop-dns-tcp-requirements-11

[Suzanne Woolf via Datatracker]

Suzanne Woolf has requested publication of 
draft-ietf-dnsop-dns-tcp-requirements-11 as Best Current Practice on behalf of 
the DNSOP working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/


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

[DNSOP] Fwd: Third (and final) NomCom 2021-2022 Call for Volunteers

[Suzanne Woolf]

If you’ve got opinions about how the IETF is run, and want to influence its 
priorities and leaders, please consider adding your name to the pool of 
potential Nomcom members. 

The deadline to volunteer for the 2021-2022 Nomcom is next Wednesday.

See Gabriel’s email below for details, but for those of you who have 
volunteered before, it’s even easier now— go to the datatracker page, 
https://datatracker.ietf.org/nomcom/volunteer 
, or send email to the chair.


Suzanne

> Begin forwarded message:
> 
> From: NomCom Chair 2021 
> Subject: Third (and final) NomCom 2021-2022 Call for Volunteers
> Date: June 16, 2021 at 12:47:31 AM EDT
> To: "IETF Announcement List" 
> Cc: i...@ietf.org
> Reply-To: i...@ietf.org
> 
> Do you want to understand and influence how the IETF leadership is elected? 
> Discuss with the candidates their visions for the different roles, and vote 
> (yes, we vote) on those you believe will benefit the IETF and the Internet 
> the most? 
> 
> Volunteer for the NomCom 2021-2022!
> 
> This is the third and final call for volunteers for the 2021-2022 NomCom. 
> We are only one week away from the end of the volunteer period.
> 
> One click is all it takes to volunteer for NomCom 2021-2022:
> 
> https://datatracker.ietf.org/nomcom/volunteer
> 
> This "volunteer" page will let you volunteer for NomCom 2021-2022 or 
> show you if you have already volunteered.
> 
> It is also reachable via your profile page:
> https://datatracker.ietf.org/accounts/profile/
> 
> …where you will now see a button to volunteer (taking you to the "volunteer" 
> page above) or a message letting you know if you have already volunteered.
> 
> - Of course, you can volunteer by sending me a very short 3 line email 
>   (see below). 
> - Thanks to everyone who has volunteered so far. However, we currently 
>   only have 83 volunteers. 
> 
> We need many more. So, please, please volunteer.
> 
> 
> 
> The IETF NomCom appoints people to fill the open slots on the IETF LLC,
> IETF Trust, the IAB, and the IESG.
> 
> Ten voting members for the NomCom are selected in a verifiably random
> way from a pool of volunteers. The more volunteers, the better chance we
> have of choosing a random yet representative cross section of the IETF
> population.
> 
> The details of the operation of the NomCom can be found in BCP 10 (RFC
> 8713). RFC 3797 details the selection algorithm.
> 
> Special for this year RFC 8989 (one-off update to RFC 8713 / BCP 10)
> tells us who is eligible to volunteer as anyone who satisfies any of the
> three following conditions:
> 
>   Path 1: The person has attended 3 out of the last 5 IETF meetings,
>   including meetings held entirely online. For the 2021-2022 NomCom, 
>   the meetings concerned will be IETF 106, 107, 108, 109, and 110
> 
>   Path 2: The person has been a Working Group Chair or Secretary within
>   the 3 years prior to the day the first call for NomCom volunteers is 
> sent 
>   to the community
> 
>   Path 3: The person has been a listed author or editor (on the front
>   page) of at least two IETF Stream RFCs within the last 5 years prior to 
>   the day the call for NomCom volunteers is sent to the community. An 
>   Internet-Draft that has been approved by the IESG and is in the RFC 
>   Editor queue counts the same as a published RFC, with the relevant date 
> being
>   the date the draft was added to the RFC Editor queue. 
> 
> [Normative details are in RFC8989.]
> 
> 
> You can check your eligibility at: 
> https://datatracker.ietf.org/accounts/profile/ 
> …where you will now see a button to volunteer (taking you to the "volunteer" 
> page above) 
> or a message letting you know if you have already volunteered.
> 
> If you qualify, please volunteer by clicking on the volunteer button. 
> Alternatively,
> You can volunteer by sending me an email as explained below. However, please
> remember that anyone appointed to this NomCom will not be considered as
> a candidate for any of the positions that the 2021-2022 NomCom is
> responsible for filling.
> 
> Details of Positions to Be Filled (some details to be finalized)
> 
> An asterisk (*) next to a person's name indicates they do not intend to 
> accept renomination.
> 
> LLC Board (3-year term)
> • Jason Livingood
> 
> IETF Trust (3-year term)
> • Kathleen Moriarty
> 
> IAB (2-year term) 
> • Ben Campbell 
> • Cullen Jennings
> • Mirja Kühlewind
> • Jared Mauch
> • Tommy Pauly
> • Jiankang Yao 
> 
> IESG (2-year term)
> • Murray Kucherawy, ART AD
> • Erik Kline, INT AD
> • Robert Wilton, OPS AD
> • Martin Vigoureux, RTG AD
> • Benjamin Kaduk, SEC AD *
> • Martin Duke, TSV AD
>   
> The primary activity for this NomCom will begin in July 2021 and should
> be completed by January 2022.  The NomCom will have regularly scheduled
> conference calls to ensure progress. There will be activities to collect
> 

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Suzanne Woolf]

Hi,

The WGLC resulted in some good discussion of (mostly) small improvements to the 
text, which the authors are responding to. 

The chairs will be discussing advancement of this document in our next meeting. 
Thanks to everyone who commented.


Suzanne 
for the chairs

> On Apr 18, 2021, at 7:17 PM, Suzanne Woolf  wrote:
> 
> Dear colleagues,
> 
> 
> This message starts the Working Group Last Call for 
> draft-ietf-dnsop-tcp-requirements 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ 
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/>)
> 
> Since this draft has not been recently discussed in the WG, we figure people 
> might need to swap it back in, and we’re requesting BCP status. So the WGLC 
> will end in three weeks (instead of the usual two), on 3 May.
> 
> Substantive comments to the list, please. It’s fine for minor edits to go 
> direct to the authors.
> 
> We’d like to advance this but it needs some active support, so we need to 
> hear from folks who have found it useful, especially implementers.
> 
> 
> Thanks,
> Suzanne
> For the chairs
> 

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

[DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Suzanne Woolf]

Dear colleagues,


This message starts the Working Group Last Call for 
draft-ietf-dnsop-tcp-requirements 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ 
)

Since this draft has not been recently discussed in the WG, we figure people 
might need to swap it back in, and we’re requesting BCP status. So the WGLC 
will end in three weeks (instead of the usual two), on 3 May.

Substantive comments to the list, please. It’s fine for minor edits to go 
direct to the authors.

We’d like to advance this but it needs some active support, so we need to hear 
from folks who have found it useful, especially implementers.


Thanks,
Suzanne
For the chairs

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

[DNSOP] Reminders: IETF 108 DNSOP meeting Wednesday morning UTC

[Suzanne Woolf]

Hi all,

The DNSOP meeting at IETF 108 is Wednesday morning UTC:

Session 1: 11:00-12:40 UTC, Meetecho Room 3
Session 2: 13:00-13:50 UTC, Meetecho Room 2

URLs for the agenda, meetecho session, meeting materials, and other important 
resources are linked from the IETF 108 agenda page, 
https://datatracker.ietf.org/meeting/108/agenda/ 
. 

Please note:

Paul Hoffman has kindly agreed to act as our note-taker. We do still need a 
jabber scribe for jabber participants not joining meetecho directly.

* Meetecho will be a new tool for many of us for virtual IETF meetings. Please 
review the participant guide at 
https://www.ietf.org/how/meetings/108/session-participant-guide/ 
.

* We are still missing slides for several agenda items. Please post those to 
the meeting materials page 
(https://datatracker.ietf.org/meeting/108/session/dnsop 
 should allow this if 
you are logged in to the data tracker), or send to the chairs so we can. We can 
share your slides or you can, but please practice with meet echo if you want to 
share them yourself, and please upload them in any case so they are available 
to all participants.


Much thanks and see you soon,

Benno, Tim, and Suzanne


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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Suzanne Woolf]

Dear colleagues,


It will be helpful to the chairs in considering the future of this draft if 
folks could keep a few things in mind as we discuss it.

1. This draft as written takes no formal action to reserve anything for any 
particular purpose. It makes some observations about the administration of ISO 
3166 and its use in the ICANN context, and suggests to operators and 
implementers that the ISO3166 user-assigned 2-letter strings could be suitable 
for local use in domain names. It does not include any IANA actions to update 
any registry or protocol element. So claims that this draft reserves names or 
attempts to override ICANN policy about “TLDs” seem premature.

We’ve heard concerns that by encouraging people to use these strings in local 
DNS contexts, an RFC with no IANA actions could have the effect of constraining 
future ICANN policy. This brings us to:

2. If we want to know what ICANN-the-organization thinks of this proposal, 
there is a mechanism for asking that question. The IAB, on behalf of the IETF, 
maintains a liaison relationship with ICANN, in the form of a non-voting 
liaison to the ICANN Board of Directors, who can be asked to convey a question 
or statement about an issue of mutual interest. We’ve used this capability 
before, and intend to ask the IAB to make use of this liaison relationship 
again if the WG wants to proceed on this draft. 

As one of the draft authors already wrote to the list, the draft does not offer 
an official position or commitment by ICANN as an organization. (Under our 
process, affiliation of a draft author can’t be used to infer such statements, 
either.) That’s literally what liaisons are for: to allow the IETF to interact 
with a standards or policy body as an organization.

3. When several proposals came to the IETF more or less at once regarding 
“special use domain names”, which proponents were insisting had to be 
single-label names (“TLDs”), the DNSOP chairs — in consultation with the IAB 
and IESG — set those proposals aside in hopes of finding a less time-consuming, 
more scalable, and less dramatic way of considering changes to the special use 
names registry than having an open-ended IETF Last Call, since there’s almost 
no technical guidance in RFC 6761 to determine whether a specific request is 
useful or even valid. 

This did not happen. RFC 8244 was published in 2017, but several drafts 
attempting to solve parts of the problem it described met with very little 
interest from the WG.

The chairs are reluctant to spend WG time in this area unless there’s 
reasonably clear benefit.  If there is, we’re happy to work with the WG, the 
IAB, ICANN liaison, et. al. to manage any governance issues.


Best,
Suzanne, Tim, and Benno



> On Jun 12, 2020, at 11:12 AM, Tim Wicinski  wrote:
> 
> 
> All,
> 
> As we stated in the meeting and in our chairs actions, we're going to run 
> regular calls for adoptions over the next few months.   We are looking for 
> *explicit* support for adoption.
> 
> 
> This starts a Call for Adoption for draft-arends-private-use-tld
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ 
> 
> 
> 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: 26 June 2020
> 
> Thanks,
> tim wicinski
> DNSOP co-chair

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

[DNSOP] Fwd: Reminder: Survey on planning for possible online IETF meetings

[Suzanne Woolf]

Colleagues,

The IETF Executive Director and leadership need community input on how to 
handle the possibility that future IETF meetings will not be able to proceed in 
person. Please see below for details on a survey.


Thanks,
Suzanne 


> Begin forwarded message:
> 
> From: IETF Executive Director 
> Subject: Reminder: Survey on planning for possible online IETF meetings
> Date: May 4, 2020 at 3:03:35 AM EDT
> To: "IETF Announcement List" 
> Reply-To: ietf108plann...@ietf.org
> 
> This is a reminder that we need the IETF community to help us plan for the 
> possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 
> may not be able to go ahead in person.  You can help us with this by filling 
> out the following survey: 
> 
>   https://www.surveymonkey.com/r/5328FFJ
> 
> So far we have 114 responses and we would ideally like 500 or more.
> 
> The survey contains the following pages and will take 15-20 minutes to 
> complete:
> 
> 1. Welcome
> 2. Online IETF 107 and the subsequent virtual interims
> 3. Replacing a cancelled in-person meeting
> 4. Online meeting format and timezone
> 5. Replicating humming
> 6. Replicating the hallway environment
> 7. Fees
> 8. Thanks and anything else
> 
> We run the survey in anonymous mode which means that we only see data that 
> you explicitly provide.
> 
> Thank you in advance for your help.
> 
> -- 
> Alissa Cooper, IETF Chair
> Jay Daley, IETF Executive Director
> Colin Perkins, IRTF Chair
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

[DNSOP] Planning for DNSOP WG and virtual IETF 107

[Suzanne Woolf]

Dear Colleagues,


Like you, the DNSOP chairs have been adjusting to recent world events and 
considering how to continue our work as conditions change. We won’t be together 
in person in Vancouver this week for IETF 107, but we want to do what we can to 
provide the usual 3x/year opportunity for the WG to advance WG drafts, consider 
new work, and discuss the evolution of the DNS.

In order to do that, we will be holding at least some of the WG activities we 
planned for Vancouver in March and April.

This note covers:

Plans for upcoming virtual meetings
Possible DNSOP chairs office hours
Managing agenda requests (note that the internet-drafts uploads site has 
already re-opened)
Important links

It’s long but has a fair amount of information about our plans, and a couple of 
items we will be asking for input on before we commit to next steps, so please 
review carefully. In particular, we’re re-opening our call for agenda items 
(see below) so we can accommodate potential work items that weren’t proposed 
for Vancouver because people had canceled travel plans.

OVERVIEW

Some sessions originally intended for IETF 107 will be held virtually, in their 
original time slots, next week. The schedule for those sessions is at 
https://datatracker.ietf.org/meeting/agenda/ 
.

The IESG is giving priority in next week’s schedule to new WGs and BOFs, so 
established WGs such as DNSOP have been asked to review the recommended virtual 
interim schedule at: 
https://trac.ietf.org/trac/wgchairs/raw-attachment/wiki/WikiStart/April2020-RecommendedSchedule.pdf
  
and
 schedule interim WG meetings accordingly.

We have two suggested slots in the April proposed schedule, in accordance with 
our usual practice of two slots during a regular in-person IETF. Also as usual, 
we expect to use either or both, depending on how much work we have that would 
benefit from real-time interaction.


AGENDA

Note that the datatracker upload function for new internet-drafts was already 
re-opened shortly after the announcement that IETF 107 will be moving entirely 
on-line. We will ask that draft authors freeze drafts a week before any interim 
meeting, in order to allow people time to read and consider them before the 
virtual meeting.

In setting the agenda for the virtual, we will assume initial requests are 
still valid unless advised otherwise. We will also move calls for adoption 
which we might have considered in Vancouver to the mailing list, in advance of 
the interim. 

We’re hereby opening a new call for agenda items so we can accommodate any 
items that people want to discuss but didn’t propose for Vancouver because they 
had already canceled travel plans. 


ADMINISTRATIVE OBSERVATIONS

We will be preparing the usual Chairs’ Slides update of work that has advanced 
since IETF 106.  We’ve had several drafts advanced to the IESG and to the RFC 
Editor. We have a few current items, and will consider new ones, but we don't 
know how busy/engaged people are prepared to be, so will take our cues from you.

We are also planning to replace some of the “hallway track” we get with 
physical IETF meetings with “virtual office hours” for the chairs and anyone 
who wants to drop by on webex. We’ll be sending out a Doodle poll to help us 
set up a couple of slots in the next few weeks; at the very least we want to 
make sure there are reasonable time slots for both Americas/European timezones 
and Asia-Pacific ones. These will be open to anyone who wants to chat with the 
chairs-- much like the IETF lounge or any hotel bar-- but we’d particularly 
like to hear from current or prospective draft authors.


CURRENT WORKING AGENDA

See:
https://github.com/DNSOP/wg-materials/tree/master/dnsop-ietf107 

https://github.com/DNSOP/wg-materials/blob/master/dnsop-document-status.md 

https://github.com/DNSOP/wg-materials/ 

As always, please don’t hesitate to reach out with questions or concerns. 


Wishing the best to all of you and your loved ones,
Benno, Suzanne, and Tim

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

[DNSOP] DNSOP at IETF 107: call for agenda items and key dates

[Suzanne Woolf]

Hi,

We’re a few weeks away from IETF 107 in Vancouver, BC, so your chairs are 
starting to put together the DNSOP meeting. 

First, this note is our first call for agenda items. Send your requests to 
dnsop-cha...@ietf.org. 

The chairs will be reaching out to some draft authors about updates and open 
discussion items so we can use f2f meeting time to resolve issues and make 
decisions about advancing them (adoption, WGLC, etc.) But if you’ve got a draft 
that the WG is discussing or you’d like the WG to discuss, don’t be shy!

The drafts deadline for Vancouver is 9 March.

We only have a couple of days after the drafts deadline to post the WG agenda, 
so please: if you want your draft on the WG agenda, try to submit it early 
enough that the WG has time to start discussing it and we’ve got a little bit 
of time to gauge interest and direction.

A few key dates (the full list is at: 
https://datatracker.ietf.org/meeting/107/important-dates/)

2020-02-28 (Friday): Final agenda to be published.
2020-03-09 (Monday): Internet Draft submission cut-off (for all drafts, 
including -00) by UTC 23:59. Upload using the ID Submission Tool.
2020-03-11 (Wednesday): Draft Working Group agendas due by UTC 23:59. 
2020-03-16 (Monday): Revised Working Group agendas due by UTC 23:59. 


Thanks and see you in Vancouver,

Suzanne, Tim, and Benno

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

[DNSOP] Publication has been requested for draft-ietf-dnsop-7706bis-07

[Suzanne Woolf via Datatracker]

Suzanne Woolf has requested publication of draft-ietf-dnsop-7706bis-07 as 
Informational on behalf of the DNSOP working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Suzanne Woolf]

Hi,

I was reminded off-list that Warren is not in fact an author on this document— 
apologies for a bad cut-and-paste from the last WGLC I ran.

Warren is handling tcp-requirements as our AD, as usual.


Best,
Suzanne
(My mistake alone, co-chairs are blame-free!)

> On Jan 12, 2020, at 12:38 PM, Suzanne Woolf  wrote:
> 
> Dear colleagues,
> 
> 
> This message starts the Working Group Last Call for 
> draft-ietf-dnsop-tcp-requirements 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ 
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/>)
> 
> Since this draft has not been recently discussed in the WG, we figure people 
> might need to swap it back in, and we’re requesting BCP status. So the WGLC 
> will end in three weeks (instead of the usual two), on 2 February. We will 
> have agenda time in Vancouver, if needed, to go over any open issues.
> 
> Our AD (Warren Kumari) is an author on this document, so we’ll be following 
> the IETF convention that he won’t be shepherding it in the IESG. His co-AD, 
> Barry Leiba, will shepherd it
> 
> Substantive comments to the list, please. It’s fine for minor edits to go 
> direct to the authors.
> 
> 
> Best,
> Suzanne
> (For the chairs)

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

[DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[Suzanne Woolf]

Dear colleagues,


This message starts the Working Group Last Call for 
draft-ietf-dnsop-tcp-requirements 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ 
)

Since this draft has not been recently discussed in the WG, we figure people 
might need to swap it back in, and we’re requesting BCP status. So the WGLC 
will end in three weeks (instead of the usual two), on 2 February. We will have 
agenda time in Vancouver, if needed, to go over any open issues.

Our AD (Warren Kumari) is an author on this document, so we’ll be following the 
IETF convention that he won’t be shepherding it in the IESG. His co-AD, Barry 
Leiba, will shepherd it

Substantive comments to the list, please. It’s fine for minor edits to go 
direct to the authors.


Best,
Suzanne
(For the chairs)___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNSOP at IETF 106: Slides, jabber scribes

[Suzanne Woolf]

Hi all,

DNSOP has the usual two slots at IETF 106:

Tuesday Nov. 19, 17:10-18:40 local time, Canning Room
Thursday Nov. 21, 13:30-15:30 local time, Padang Room

We need jabber scribes for both sessions, so please reply to 
dnsop-cha...@ietf.org if you’re willing. We just ask jabber scribes to keep 
track of who’s speaking, where we are in a slide deck, etc.— not a lot of work 
but very helpful for remote attendees.

Also if you’re presenting and haven’t posted your slides (or sent them to us), 
please do— it’s helpful for the chairs to be able to review slides in advance, 
help edit a deck if it’s too long, etc.



Much thanks,

Suzanne & Benno & Tim


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

[DNSOP] Publication has been requested for draft-ietf-dnsop-serve-stale-06

[Suzanne Woolf via Datatracker]

Suzanne Woolf has requested publication of draft-ietf-dnsop-serve-stale-06 as 
Proposed Standard on behalf of the DNSOP working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/

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

Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext

[Suzanne Woolf]

(Draft author hat here, not WG chair)

> On Aug 10, 2019, at 11:36 AM, John Levine  wrote:
> 
> In article 
>  you 
> write:
>> Thank you Paul.
>> 
>> As an incentive to everyone else  -- there is an Easter Egg hidden in
>> this document: if you judiciously choose letters from the text (and
>> reorder them) you can create a very rude word.
> 
> I think that like everyone else I've read it, but I'm not sure what to say.
> 

Well, the document is intended as guidance to the IETF community and to the  
current/future IESG on what it’s reasonable for people to do with reservations 
for special use domain names, particularly in IETF protocols. This is only a 
piece of the larger space around the general idea of the special use names 
registry, but it seemed like a useful place to start.

So it would be helpful to know if you think the recommendations are in fact 
reasonable. 

In particular, there’s a couple of distinctions the draft makes in order to 
carve out what looks (to me, anyway) like a manageable piece of the larger 
issue of administration of domain names as a superset of DNS names: between 
TLDs and names elsewhere in the namespace, and between IETF protocols and other 
possible uses for SUDNs.

First, special use “TLDs” (single label domain names) present a hard case for 
the IETF because of the nexus with another body (ICANN) that has actual 
authority over what DNS names are delegated as TLDs in the public DNS. A 
failure to coordinate in such cases could result in poor outcomes for anyone 
who assumes that the reservation of a special use name under RFC 6761 comes 
with any assurances about the public DNS.

IMO the IETF has three choices here: refuse to reserve single label names as 
special use; agree to reserve such names, at least as a possibility, and assume 
coordination is unnecessary; or ask ICANN, through the established liaison 
relationship, to discuss a process for coordination on reservation of special 
use single label names outside of the public DNS.

No matter which course is chosen, however, a special use name under a TLD 
that’s already in existence and already under the policy control of the IETF 
presents a simpler path to approval with fewer risks, so the draft encourages 
IETF WGs to use such names in their protocols where possible, and the IESG to 
approve them. (This is the “home.arpa” case.)

Second, the other line the draft tries to draw is between IETF protocols, and 
requests for special use name registrations for use in protocols or code bases 
not developed in the IETF. 

This isn’t about excluding anyone else from access to some magical potion, and 
in fact I’d be happy to propose a more detailed set of guidelines for non-IETF 
protocols that it might be reasonable to approve special use names for. (The 
draft suggests “stable specification required,” but I’m not attached to it.) 
The rationale here is that an IETF registry should have clear policy around its 
administration, and this one doesn’t: approval of the next .onion is likely to 
be just as ad hoc as the previous one, because “standards track” has a clear 
meaning inside the IETF, but there’s no equivalent set of guidelines for 
requests not based in IETF process. This doesn’t scale in, for example, the 
case that a sponsor of a closed, non-IETF protocol wants to reserve a set of 
names: is there any limit to how many names the IETF is willing to reserve? 
Should there be a stable reference to their use? Is there any presumption that 
if an existing codebase that uses a reserved name is forked, the new codebase 
should be able to get a new special use name? RFC 6761 is silent on these 
questions, which are implicitly resolved for a protocol that’s on the standards 
track in the IETF, but not for anything else.

If a new organization of the contents would be less baffling, I’m definitely 
open to that, too.



Suzanne


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

[DNSOP] Admin note: Change in affiliation

[Suzanne Woolf]

Colleagues,


As some of you might have heard, I’ve started a new position with PIR, the 
operator of the .org TLD.

I’m noting this primarily in the interests of transparency, particularly on two 
points: First, I’m reporting to Joe Abley, CTO of PIR and a regular contributor 
to DNSOP. It happens frequently enough in the IETF that a WG contributor is a 
supervisor for a WG chair that the IETF has a convention about it, which we’ll 
be observing: I will not be acting as a shepherd, or participating in the 
chairs’ deliberations  about consensus, on any document for which Joe is an 
author or editor.

Second, as some of you know, PIR is essentially a subsidiary of the Internet 
Society (because both organizations are not-for-profit, the actual mechanism is 
that we’re a membership organization and ISOC is the sole member). The 
management of ISOC recently announced a policy respecting the participation of 
ISOC staff in the IETF, citing the special relationship between ISOC and the 
IETF LLC. (See 
https://mailarchive.ietf.org/arch/msg/ietf/Ugu6O_5tCnNzTUmVzIuhNFKPzbE) 
However, PIR is a separate company, with its own board, bylaws, management, and 
staff. We have no particular influence over ISOC or its relationship with the 
IETF LLC, and are not bound by its management or policies. There’s no issue for 
the Internet Society in my participation in the IETF, and PIR is happy to 
support it.


Looking forward to IETF 105,

Best,
Suzanne


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

Re: [DNSOP] [Ext] WGLC for draft-ietf-dnsop-serve-stale

[Suzanne Woolf]

> On Jul 2, 2019, at 10:01 AM, Paul Hoffman  wrote:
> 
> On Jul 2, 2019, at 6:36 AM, Suzanne Woolf  wrote:
>> First, there have been several IPR disclosures against this document. The 
>> chairs believe all have been resolved.
> 
> Please clarify what "The chairs believe all have been resolved" means in this 
> context. There are seven IPR statements on the document.

The seven IPR statements relate to disclosures regarding IP of three companies, 
Google, Akamai, and Cisco. In all three cases, those companies appear to have 
put licensing terms regarding the patents referred to into the data tracker; 
there are no disclosures that haven’t been acknowledged by the stated holders 
of the IP, or that the holder has promised to update later. 

Please see 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-dnsop-serve-stale
 for the details. 

Note also the boilerplate at https://datatracker.ietf.org/ipr/. Neither the 
chairs nor the IETF has any opinion on the content of any of those statements, 
we do however note they exist.


Suzanne
(For the chairs)



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

[DNSOP] WGLC for draft-ietf-dnsop-serve-stale

[Suzanne Woolf]

Dear colleagues,


This message starts the Working Group Last Call for 
draft-ietf-dnsop-serve-stale 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/).

Since this draft has not been recently discussed in the WG, we figure people 
might need to swap it back in, and we will be meeting soon in Montreal. So the 
WGLC will end in three weeks (instead of the usual two), on 23 July. We will 
have agenda time if needed to go over any open issues.

Two process points worth noting:

First, there have been several IPR disclosures against this document. The 
chairs believe all have been resolved.

Second, our AD (Warren) is an author on this document, so we’ll be following 
the IETF convention that he won’t be shepherding it in the IESG. His co-AD, 
Barry Leiba, will shepherd it.



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

[DNSOP] Deadlines for IETF 104 (Prague)

[Suzanne Woolf]

Hi,

Just an early reminder that IETF 104 is sooner than you think: the meeting 
starts on March 23, and we’ll be sending out the call for agenda items in the 
next few weeks.

In particular, note that the “early bird” registration cutoff is Feb. 4; the 
registration fee goes up after that. (This is earlier than it used to be. The 
IAOC changed the schedule for registration processing last year.)

The drafts deadline is Mar. 11, but if you’re planning to ask for agenda time 
it’s a good idea to submit the draft and have some mailing list activity on it 
before the this date (which is also the agenda deadline).

Meetings page is at https://www.ietf.org/how/meetings/104/, which includes the 
“Important Dates” page at 
https://datatracker.ietf.org/meeting/104/important-dates/.

Thanks and hoping to see you in Prague,

Suzanne
Benno
Tim


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

Re: [DNSOP] Brief addition to terminology-bis draft

[Suzanne Woolf]

All,

Thanks for the lively discussion on this point….after reviewing the thread, the 
editors, the chairs, and the AD (Warren) felt that there was consensus support 
for the new language proposed by the editors defining “class," but controversy 
about the additional language proposed by Paul.

Rather than re-open the document in the WG and pursue a new WGLC and IETF LC, 
we decided to forward the document on with the brief change proposed by the 
editors.

Personally, I figure the controversy over the use and meaning of “class” in the 
DNS won’t go away, and I wouldn’t oppose someone reviving Andrew’s draft or 
writing another one.


Suzanne

> On Sep 3, 2018, at 11:29 AM, Suzanne Woolf  wrote:
> 
> Hi all,
> 
> During the IESG review, Adam Roach noticed that 
> draft-ietf-dnsop-terminology-bis talked about “class" but never defined it. 
> This seemed to the authors and chairs like a reasonable thing to fix. It’s 
> also important enough that we want WG review, but not extensive enough to 
> require a new LC.
> 
> Here's the definition that the authors would like to add to the document: 
> 
> 
> Class:
> A class "identifies a protocol family or instance of a protocol" (Quoted from 
> [RFC1034], Section 3.6). "The DNS tags all data with a class as well as the 
> type, so that we can allow parallel use of different formats for data of type 
> address." (Quoted from [RFC1034], Section 2.2). In practice, the class for 
> nearly every query is "IN". There are some queries for "CH", but they are 
> usually for the purposes of information about the server itself rather than 
> for a different type of address.
> 
> Please let us know your opinions yea or nay by Monday, Sept. 10, midnight UTC.
> 
> 
> Thanks,
> Suzanne
> (For the chairs)
> 

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

Re: [DNSOP] Brief addition to terminology-bis draft

[Suzanne Woolf]

Hi,

> On Sep 10, 2018, at 12:48 PM, Paul Vixie  wrote:
> 
> Andrew Sullivan wrote:
>> ...
>> 
>> I agree with Paul Vixie that classes were never defined well enough to
>> be made to work properly, at least at Internet scale.
> 
> this thread has further cemented my prejudice against CLASS. however, it has 
> also motivated me to define it well enough that we can create a global 
> "CHAOS" system, with very different zone cuts, which seems like an idea bad 
> enough to be good.

Note that RFC 6895 ("Domain Name System (DNS) IANA Considerations”), Section 
3.2, has some observations about CLASS as well. 

> 
> for the terminology-bis draft, is it enough to use andrew's words above?

I think this discussion demonstrates that it would be controversial to attempt 
to go beyond the original proposed wording, and we can’t really do something 
controversial at this stage unless we’re willing to re-open the approval 
process for the document (pull it back to the WG, then re-run IETF LC).  I’m 
not inclined to do that.

Warren, anything to add?



Suzanne

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

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

[Suzanne Woolf]

> On Sep 10, 2018, at 1:13 PM, Lee Howard  wrote:
> 
> 
> 
> On 09/06/2018 03:14 AM, Shane Kerr wrote:
>> All,
>> 
>> On 2018-09-05 20:45, internet-dra...@ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Domain Name System Operations WG of the 
>>> IETF.
>>> 
>>>  Title   : Reverse DNS in IPv6 for Internet Service 
>>> Providers
>> 
>> I think that the WG chairs should move this document to WG last call.
> 
> It passed WGLC; this rev was in response to some nits from the AD. (Mostly, 
> he didn't like my choices in capitalization)


Lee’s correct. It’s something of a loose end, as that was some time ago, but 
this doc has been through the full WG cycle.


Suzanne

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

[DNSOP] Brief addition to terminology-bis draft

[Suzanne Woolf]

Hi all,

During the IESG review, Adam Roach noticed that 
draft-ietf-dnsop-terminology-bis talked about “class" but never defined it. 
This seemed to the authors and chairs like a reasonable thing to fix. It’s also 
important enough that we want WG review, but not extensive enough to require a 
new LC.

Here's the definition that the authors would like to add to the document: 


Class:
A class "identifies a protocol family or instance of a protocol" (Quoted from 
[RFC1034], Section 3.6). "The DNS tags all data with a class as well as the 
type, so that we can allow parallel use of different formats for data of type 
address." (Quoted from [RFC1034], Section 2.2). In practice, the class for 
nearly every query is "IN". There are some queries for "CH", but they are 
usually for the purposes of information about the server itself rather than for 
a different type of address.

Please let us know your opinions yea or nay by Monday, Sept. 10, midnight UTC.


Thanks,
Suzanne
(For the chairs)

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

[DNSOP] Publication has been requested for draft-ietf-dnsop-terminology-bis-11

[Suzanne Woolf]

Suzanne Woolf has requested publication of draft-ietf-dnsop-terminology-bis-11 
as Best Current Practice on behalf of the DNSOP working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/

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

[DNSOP] Logistics for DNSOP at IETF 102

[Suzanne Woolf]

Hi all, and welcome to IETF 102!

DNSOP has two slots: Wednesday morning 9:30-12:00 local time in Montreal (the 
Laurier room), and Thursday evening 18:10-19:10 (the Place du Canada room). 
NOTE DIFFERENT ROOMS.

Meeting materials, including agendas and drafts, are linked from the usual 
place: https://datatracker.ietf.org/meeting/102/materials (Look for dnsop under 
the “OPS” tab on the right)

We’re trying a couple of experiments with meeting management since we now have 
three chairs. Two of us will be on stage managing the room, and one will join 
the participants and act as note-taker.

We still need jabber scribes for both sessions.



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

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

[Suzanne Woolf]

Thanks to all who commented. The WGLC is over and the chairs have seen strong 
support for this document and lots of participation in getting it right, so 
we’ll be advancing it for publication.

The authors will be spinning up a new version, incorporating the last call 
comments, and we’ll submit that revision.


Best,
Suzanne
(For the chairs)

> On Jun 22, 2018, at 4:01 PM, Suzanne Woolf  wrote:
> 
> Colleagues,
> 
> This begins the working group last call for 
> draft-ietf-dnsop-terminology-bis-10, "DNS Terminology”. The document has 
> gotten significant feedback and the editors have worked hard to document 
> current terminology usage, both among practitioners and for broader 
> audiences; we’d like to advance it.
> 
> We’re seeking consensus to advance it to the IESG with an intended status of 
> Best Current Practice. Note that it’s intended to obsolete RFC 7719 ( the 
> earlier “DNS Terminology” document). 
> 
> If you support it, please say so. If you don’t, please say why.
> 
> The current version is at: 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/
> 
> Last Call will run for two weeks, closing on Friday July 6. This will allow 
> for discussion of any major outstanding issues at IETF 102.
> 
> 
> thanks,
> Suzanne, Tim, & Benno

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

[DNSOP] Agenda requests

[Suzanne Woolf]

Hi,

We’ve been building the draft agenda from current state on assorted drafts but 
have been remiss in getting the formal request out, so here it is: please send 
requests for agenda time in the DNSOP meeting at IETF 102 to 
dnsop-cha...@ietf.org at your earliest convenience. As usual, we need to give 
preference to drafts that the WG is already engaged on (as WG items or proposed 
for adoption), but we also want to make sure people have the chance to consider 
possible new work.

Currently we are scheduled for Wednesday morning (9:30-12:00) and Thursday 
evening (18:10-19:10).

Keep those cards and letters coming….


Suzanne
For the chairs

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

[DNSOP] Draft cutoff: July 2

[Suzanne Woolf]

Hi,

For those working to get new internet-drafts posted before IETF 102: the cutoff 
is 2018-07-02 (Monday), by UTC 23:59. Your chairs will be as available as 
possible to help with any last-minute glitches in submission, but there’s 
always a rush at the deadline, so please get your docs shipped when you can.

The ID submission tool will be available again starting on Monday during the 
meeting.


Thanks,
The chairs

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

[DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

[Suzanne Woolf]

Colleagues,

This begins the working group last call for 
draft-ietf-dnsop-terminology-bis-10, "DNS Terminology”. The document has gotten 
significant feedback and the editors have worked hard to document current 
terminology usage, both among practitioners and for broader audiences; we’d 
like to advance it.

We’re seeking consensus to advance it to the IESG with an intended status of 
Best Current Practice. Note that it’s intended to obsolete RFC 7719 ( the 
earlier “DNS Terminology” document). 

If you support it, please say so. If you don’t, please say why.

The current version is at: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/

Last Call will run for two weeks, closing on Friday July 6. This will allow for 
discussion of any major outstanding issues at IETF 102.


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

[DNSOP] Complexity and innovation in the DNS protocol: the work of DNSOP

[Suzanne Woolf]

Hi,

The chairs have been discussing next steps after IETF 101, particularly the 
very lively WG input on the complexity and stability of the DNS protocol.

There are many aspects to the questions that came up. Some are not going to be 
resolved within the IETF or the standards process, but it sounds to us like 
there are things the IETF and DNSOP can do that could improve the situation.

We heard significant support in the WG for slowing down on adoption of new 
work, with more attention by the chairs and in WG discussion for a couple of 
factors:

First, what's the applicability of this work? what problem does it solve, and 
for whom?

Second, does this work add significantly to the complexity of the DNS protocol, 
or the work of implementers and operators?

Finally, what implementation experience exists with the technology?

We're not trying to create unnecessary barriers to new work; previous 
generations of DNS working groups have arguably tried to preserve stability of 
the protocol at the expense of innovation, with the result that people simply 
proceeded to innovate outside of the standards process.

However, we want to see these issues discussed as part of WG consideration for 
adoption of new work in the future, and will explicitly consider them when 
deciding whether new work has adequate support to advance in the working group.



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

Re: [DNSOP] Responsible AD for KSK-Sentinel - Terry Manderson

[Suzanne Woolf]

Warren,

Thanks for clarifying this for the WG. 

For those who don’t like to worry about process, just note that Warren has done 
the right thing to head off any potential process issue with having the same 
person acting as both an editor of the document and the Area Director 
responsible for managing DNSOP documents in the IESG (running IETF Last Call, 
shepherding the document through discussion in the IESG). 

Thanks Terry for helping us out!


Suzanne

> On Apr 9, 2018, at 11:04 AM, Warren Kumari  wrote:
> 
> Hello all,
> 
> Obviously I cannot (nor would I want to) be the responsible AD for
> this document, and so I asked for volunteers - Terry Manderson (CCed)
> has kindly volunteered to carry the torch on this document.
> 
> Thanks Terry!
> W
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
> 
> ___
> 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

[Suzanne Woolf]

Hi,

Thanks all for vigorous discussion, but I think it would be helpful to separate 
comments on draft-ietf-dnsop-kskroll-sentinel from general comments on WG 
guidelines for future documents. 

> On Apr 6, 2018, at 9:45 AM, Job Snijders  wrote:
> 
> 
> On Fri, Apr 06, 2018 at 08:37:15AM -0400, Warren Kumari wrote:
>> I'm (of course) fine if the WG / chairs decide that DNSOP needs
>> implementations before progressing documents, but your wording makes
>> it sound like you believe this this is already the case, and not
>> simply your (strong) preference.
> 
> I am aware DNSOP does not have a policy of requiring implementations,
> and I find this lack of policy regrettable. I believe this document is
> not ready for WGLC, for the reasons I listed.

The fact that we don’t have a rule about all documents doesn’t mean an issue 
can’t be raised about a specific document.

While it’s often disappointing to editors when the WG raises significant issues 
in WGLC, that’s kind of what WGLC is for.

We’re hearing that having an RFC will be helpful to promoting implementation, 
and also that this draft may not be ready to be advanced for publication 
because it doesn’t include implementation experience. This is something the WG 
needs to comment on further, because it seems substantive to me so it will have 
to be addressed one way or another before we advance the document— but those 
inputs are somewhat in disagreement.

Editors: Please take “concern about a description of current implementation 
status” as WGLC input, and consider what you might be able to add to the draft 
to address it. 

WG vendors/implementers: Can folks who have implemented kskroll-sentinel, or 
considered implementing it, please speak up on your concerns/plans?


Thanks,
Suzanne ()


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

Re: [DNSOP] raising the bar: requiring implementations

[Suzanne Woolf]

On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman  wrote:

> On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote:
>> 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.
> 
> 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).

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.

Other documents we’ve considered on features or modifications to the protocol 
include refuse-any and, I believe, serve-stale, and the stated purpose of the 
localhost draft is to clarify the existing documentation on the reserved name 
“localhost”.

Should we refuse to document such things because they’re not in well-known open 
source codebases, or have otherwise not passed tests of goodness?

It’s not a rhetorical question. Given that people are extending the protocol 
outside of the IETF or any other formal process, in order to solve their own 
technical and business problems, it makes sense to ask ourselves periodically 
whether we should be encouraging them, trying to stop them, or something in 
between.


Suzanne

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

[DNSOP] New WG for document/protocol cleanup? Re: Current DNS standards, drafts & charter

[Suzanne Woolf]

Note this discussion has started to split into (at least) two: cleaning up the 
DNS standard (protocol, documents, or both), possibly in a new WG; and 
whether/how the existing DNSOP WG needs to adjust its efforts. 

> On Mar 27, 2018, at 3:49 AM, Ondřej Surý  wrote:
> 
> Hi Suzanne,
> 
>> If the WG feels that the previous view of how DNSOP should work has been 
>> overtaken by events, we can certainly work with our Area Director (hi 
>> Warren!) on a revised charter.
> 
> 
> I strongly believe that any work on cleaning up DNS protocol and/or rewriting 
> RFC1034/RFC1035 and associated document would need a new WG with tightly 
> defined charter.
> 
> Hence, I will not request or I won’t support adopting my 
> deprecating-obsolete-rr-types as a WG document - it might become one of the 
> first documents for new WG, or it might end up as individual submission. 
> While this work might be considered as “protocol maintenance”, I think it is 
> bigger then simple protocol maintenance.
> 
> 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.

This all makes sense to me. 

I have no opinion (yet) on what the desired output should be (some new RFCs? A 
reference implementation/RFC set? Something else?), but agree it doesn’t fit 
DNSOP.

Personally I think it’s within charter for DNSOP to facilitate this discussion, 
permit it to stay on the WG mailing list, etc. while people work out how they 
want to approach it, in substance and process. For instance, DNSOP helped get 
DPRIVE going by having a session at an IETF meeting on the DPRIVE drafts and 
adopting one of them (QNAME minimization). The important thing should be 
whether there’s an identifiable work item and whether the will exists to get it 
done, not how to charter a WG or otherwise work the process machinery. There 
are quite a few DNSOP (and IETF) regulars who are current or past WG chairs, 
ADs, and document editors, with experience of making the IETF machinery turn, 
who would be happy to advise proponents. This includes the current DNSOP chairs 
and AD.

I do have to say I support the warnings about getting bits committed to 
documents (and possibly code). As another anecdote to add to the stack, I 
remember (as I assume Paul Vixie, Matt Larson, Rob Austein, Ed Lewis, and Roy 
Arends do) the effort it took to get the DNSSEC RFCs done: a series of interop 
workshops, a couple of open source companies sponsoring development in 
well-known code bases, and money to support production of both code and 
documents. Resources committed as an afterthought were not getting it done. 

This is a different project, and I think it’s doable, but it’s not a weekend 
undertaking. 



Suzanne


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

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

[Suzanne Woolf]

Hi all,

First, thanks for running with this.

Top-posting a couple of process observations:

First, the chairs are always open to discussion of what documents belong in the 
WG, interpretation/revision of our charter, etc. There’s a certain amount of 
process to be observed, especially if we want to revise our charter, but 
nothing unmanageable; it’s the chairs’ job to make process work for the WG 
rather than the other way around.

The current DNSOP charter was deliberately written to be flexible in what we 
could work on. Normally an IETF WG is chartered to perform a fairly tightly 
constrained piece of work and then either re-charter to an equally specific 
next work item, or shut down. But part of the purpose of keeping DNSOP around 
in a slightly more open-ended fashion was that the community seemed to believe 
that major protocol work on DNS was done, but there would still be pressure to 
provide for small tweaks on the wire and review Informational documents on 
operational practice such as DNSSEC maintenance.

Since then, a couple of pieces of work with significant protocol implications 
have gotten some initial review in DNSOP, and then moved to new WGs such as 
DPRIVE. Most of the documents DNSOP publishes are standards track only for 
procedural reasons— implementing them is strictly optional for interoperability 
on the public internet— or are informational.

If the WG feels that the previous view of how DNSOP should work has been 
overtaken by events, we can certainly work with our Area Director (hi Warren!) 
on a revised charter.

Given the deliberately loose boundaries on the current charter, we can adjust 
what we’re doing instead of (or during) the formal process of revising it. The 
charter we have doesn’t obligate us to adopt any particular work item, or to 
pursue one that’s been adopted but that the WG finds it doesn’t want to pursue 
after all. 

In my own strictly subjective impression, some of what we’re publishing is 
first written as an internet-draft….but some is implemented first in the field 
and then brought back to the IETF to be documented in an informational RFC so 
other implementers can write compatible behavior into their software, or so 
operators who want to use a particular feature can figure out how (*lots* of 
DNSSEC docs), or operators who don’t want to use a particular feature can 
(relatively) easily find ways around it. 

The pressure to standardize extensions to the DNS actually seems lower in the 
last few years, because both the RRtype registry and the EDNS opt registry 
policies are expert review rather than standards action. However, the tendency 
to desire DNS-over-new-transport is recent. So is DPRIVE. So are the assorted 
optimizations used by CDN operators such as serve-stale and client-subnet.

It’s also worth noting that many WG participants (operators and implementers 
alike) have argued over the years that having the IETF refuse to publish an RFC 
does nothing to discourage people from inventing and fielding new features, it 
just makes it harder to find out what they’re doing— whether you want to 
interoperate with them or simply avoid them. So for novel uses of RRtypes or 
EDNS options, we’ve tended to encourage people who already had acquired code 
points in the registry to document what they’re doing with them (see RFC 7871 
on client-subnet, which had a code point and was in widespread use and *then* 
was brought to DNSOP).

Serious question: should we be encouraging people to document these optional 
extensions in RFCs?

A couple more points inline:


> On Mar 26, 2018, at 11:46 AM, bert hubert  wrote:
> 
> I am optimistic that if we had a better 'hello, and welcome to DNS' document
> we could point to, implementations would get better.  Or if they didn't, we
> could at least point at that document and blame them for not reading it. 
> This may prevent implementations that get confused if they get anything
> other than an A query.
> 
> So my first suggested action is: could we write a document that has a core
> introduction of DNS and then provides a recommended (not) reading list.

As discussed at the mic last Tuesday, I believe this is where DNSEXT got hung 
up, too: it’s likely to be hard work (given the effort that’s gone into just 
the terminology documents) and may not be considered the best use of people’s 
time by their assorted funding sources.

Earnest question, for discussion: should this document be an RFC, produced in 
the IETF? (I can see arguments both ways).

While we ponder this, there’s nothing to prevent anyone from posting a 
rudimentary internet-draft for consideration. 

> 
> Secondly, what we've been doing already, is grouping the various standards
> in categories.  Read this if you are doing X.  This could go in the first
> document.
> 
> Thirdly, this may lead to a category of RFCs that you might be better off
> not reading or implementing. I don't know if writing a draft that
> specifically 

[DNSOP] General status IETF 101

[Suzanne Woolf]

Hi all,

Thanks for several hours of useful discussion on the usual assortment of topics 
at IETF 101 last week!

We’ll have minutes posted (thanks Paul Hoffman for taking them, and turning 
them in promptly) and followup actions identified in the next few days.

I just talked to Tim— he’s home and recovering from his knee injury, and will 
be back online tonight or tomorrow. He and his partner appreciated all the 
concern and well wishes.

Thanks from both of us to Brian Haberman for stepping in to co-chair our 
Thursday afternoon session in Tim’s absence.

More to follow,


Suzanne (for Suzanne & Tim)



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

[DNSOP] DNSOP Session II at IETF 101: proxy co-chair, jabber scribe & slides

[Suzanne Woolf]

Hi all,

As you probably saw from Tim’s email overnight, he’s injured his knee and his 
priority today is getting medical attention for it. But Session II is under 
control and we’ll convene at 18:10-19:10 this evening in the Sandringham room, 
with a proxy Tim if needed.

We do still need a jabber scribe for this session.

If you’re on the agenda and you don’t see your slides on the meeting materials 
page (https://datatracker.ietf.org/meeting/materials/) please send them to me— 
even if you sent them to Tim, he may not have gotten to review them before he 
went offline.

(Feel better Tim!)


Suzanne

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Suzanne Woolf]

Hi all,

We’ve let the discussion continue because it’s been so active, but we also 
haven’t forgotten we need to review and determine next steps on this draft.

Thanks for the lively discussion, and we’ll have followup shortly.

Suzanne & Tim

> On Jan 22, 2018, at 11:18 AM, Suzanne Woolf <suzworldw...@gmail.com> wrote:
> 
> Hi all,
> 
> This is the opening of the Working Group Last Call for "Let 'localhost' be 
> localhost” 
> (https://www.ietf.org/id/draft-ietf-dnsop-let-localhost-be-localhost-02.txt).
> 
> We’ll end it in two weeks, on February 5, 2018.
> 
> Please focus feedback on: Is this draft ready to go to the IESG for approval 
> as an RFC? If not, can you suggest specific changes it needs?
> 
> The chairs need to see both positive and negative feedback, so please speak 
> up.
> 
> 
> Thanks,
> Suzanne & Tim
> 
> 

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

[DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Suzanne Woolf]

Hi all,

This is the opening of the Working Group Last Call for "Let 'localhost' be 
localhost” 
(https://www.ietf.org/id/draft-ietf-dnsop-let-localhost-be-localhost-02.txt).

We’ll end it in two weeks, on February 5, 2018.

Please focus feedback on: Is this draft ready to go to the IESG for approval as 
an RFC? If not, can you suggest specific changes it needs?

The chairs need to see both positive and negative feedback, so please speak up.


Thanks,
Suzanne & Tim


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

Re: [DNSOP] The DNSOP WG has placed draft-huston-kskroll-sentinel in state "Candidate for WG Adoption"

[Suzanne Woolf]

Dear colleagues,

In our meeting earlier today at IETF 100, Geoff presented on this draft. 
(Slides are at 
https://datatracker.ietf.org/meeting/100/materials/slides-100-dnsop-sessa-draft-huston-kskroll-sentinel/
 
)
 It seemed to have significant interest, and we were asked to consider it for 
adoption as soon as we could because it may be helpful in revising the schedule 
for the root KSK roll.

It’s still new so we think it needs review, but we’re attempting to move it 
forward if the WG supports it. So please read it, perhaps while you’re in 
Singapore for IETF100 and waiting for your next WG meeting to start, and look 
for the formal Call for Adoption on this list later in the week.


thanks,
Suzanne & Tim

> On Nov 13, 2017, at 4:11 AM, IETF Secretariat 
>  wrote:
> 
> 
> The DNSOP WG has placed draft-huston-kskroll-sentinel in state
> Candidate for WG Adoption (entered by Tim Wicinski)
> 
> The document is available at
> https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/
> 

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

Re: [DNSOP] Remarks about draft-wkumari-dnsop-internal-00

[Suzanne Woolf]

On Sep 7, 2017, at 10:32 AM, Stephane Bortzmeyer  wrote:

> draft-wkumari-dnsop-internal-00 proposes to reserve .internal for
> RFC1918-like domain names. There is clearly a strong demand for that.
> (There is also a strong demand for happy sex, great food, excellent
> wines and diamong rings, but let's ignore it for the moment).
> 
> The document clearly documents that it will not happen, since it
> requires an entire new process at ICANN.

As WG chair: no reason I know of to assume this. 

As long-time observer of IETF and ICANN process: no reason I know of to assume 
this; such a request from the IETF, however, would involve the IESG (presumably 
armed with IETF consensus), the IAB (which manages the IETF liaison 
relationship with ICANN on behalf of the IETF), and some patience, since it 
amounts to a request that the ICANN community do work to accommodate a need of 
the IETF. This doesn't mean it can't be done or even that it won't be done, 
only that the implications need to be considered as far as possible. 

At the very least, I'd like to see an extremely strong rationale for making 
such a request; we should be working towards a statement something like "doing 
this solves the following large class of problems for a really long time, in a 
demonstrably better way than any of the alternatives."

> Also, it may be a good idea to add an "Internationalization
> considerations" section. If people want a memorable domain name (and
> not, say, the TLD .693268ed5948276cb48c3f3339ac465d, which would work
> as well), it's because it is typable and rememberable), they may want
> it in other languages.

Agreed. This mechanism is intended, at least in part, to accommodate the common 
desire people seem to have for DNS names to act sort of like natural language 
objects and not just random strings. It seems to me that defining such a 
mechanism should consider the likelihood that not everyone who wants to use it 
will be native speakers of English who are happy to limit the available 
characters to US-ASCII.


Suzanne

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

Re: [DNSOP] ICANN Name collision framework

[Suzanne Woolf]

Hi,


On Aug 19, 2017, at 11:47 AM, Rubens Kuhl  wrote:

> (Sorry if you have received more than 1 copy of this e-mail, since this is 
> being sent to technical mailing lists focusing on DNS)
> 
> There is ongoing policy development effort within ICANN towards subsequent 
> procedures of new gTLDs releases; during the last round in 2012, one of the 
> last pieces of the program to be defined was the name collision framework, 
> detailed at 
> https://www.icann.org/resources/pages/name-collision-2013-12-06-en . 
> 
> The current thinking is to keep most of the framework as it was in that 
> round, with minor changes for low risk strings and some more detail for other 
> strings. The base principle is to use research-accessible trusted databases 
> such as DITL and ORDINAL to make decisions. 

It's very good to see this outreach regarding the ICANN gTLD policy process, 
and this specific topic may well be of interest to DNSOP participants.

However, it's also not a core topic for this group, and is likely to be of 
interest to others as well.  Is there a dedicated mailing list, wiki, or other 
venue for people to offer their comments or continue the discussion?

There is a reference in the text to "the WG" ("Some of the questions still to 
be answered by the WG include…") Could you expand the reference? Where can an 
interested DNSOP participant go to find out more about this WG and its work to 
date?


thanks,
Suzanne


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

Re: [DNSOP] EDNS0 clientID is a wider-internet question

[Suzanne Woolf]

George,

> On Jul 20, 2017, at 1:00 PM, George Michaelson  wrote:
> 
> I probably will not carry the WG with me on this, but I find myself
> thinking the PII aspect of client-ID makes it a wider-internet
> question and we might have views as a WG, and promote questions as a
> WG, but I think the "final call" on this is something which needs more
> than WG approval.

A couple of points of precision on this: first, I’m not sure “PII” is 
rigorously defined in our context, so we might need to be more specific on that 
(although I agree with the intuitive sense you seem to have about it).

Second, technically the WG doesn’t approve publication of a document anyway; a 
decision by the WG to advance a particular document along the process is 
neither necessary nor sufficient to get it published; there are several 
additional steps to publication approval.

With those things said, however:

> 
> Its a big question. I'd actually welcome adoption on many levels, but
> that isn't to pre-empt that it goes to WGLC. I think we need to
> formalize the issues and take them out of the WG for review and
> discussion.
> 
> documenting current practice is ok btw, but .. PII.
> 

Agreed there are some aspects here that need cross-area review, and making sure 
that happens is part of the chairs’ followup from discussion of the draft to 
date.


Suzanne


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

Re: [DNSOP] draft-ietf-dnsop-dns-rpz

[Suzanne Woolf]

Hi,


On 7/18/17 8:32 AM, Petr Špaček wrote:

I'm fine with Informational document describing the existing version of
RPZ. My hope that working on that as WG item will help to improve the
text so it is unambiguous. Improvements to the protocol can be done
later on.


Thank you-- this is exactly the intent.


Suzanne

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

[DNSOP] still need jabber scribe and minute taker

[Suzanne Woolf]

Hi,


We still need jabber scribe and minute taker volunteers for the DNSOP 
meeting in the next time slot, 15:50-17:50 today.


If you don't volunteer now, we'll just have to ask again in the meeting


much thanks,

your chairs

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

Re: [DNSOP] draft-ietf-dnsop-dns-rpz

[Suzanne Woolf]

Hi,

The working group does get to work on it. The specific suggested wording 
was about the scope of the document, which the chairs felt was 
consistent with what the WG had already decided about the document: that 
they were willing to work on it as an Informational description of the 
existing protocol.



This is why the original boilerplate wasn't acceptable for a WG 
document, and the authors have agreed to change it in order for it to be 
kept as a WG document.



Suzanne


On 7/18/17 8:30 AM, Ted Lemon wrote:
If the working group doesn't get to work on it, it seems more 
appropriate to publish it as an ISE document.   This is what has been 
done in similar cases in the past.


On Tue, Jul 18, 2017 at 2:13 PM, Suzanne Woolf <suzworldw...@gmail.com 
<mailto:suzworldw...@gmail.com>> wrote:


Dear colleagues,


As you might recall, we had a call for adoption
for draft-vixie-dns-rpz just before IETF 98 in March. We had a
lively discussion and decided to adopt the document for further
work in the WG as an Informational RFC.

However, the chairs then discovered we’d made a mistake in
adopting the draft with the copyright that reserved rights in
derivative works to the original authors. This isn’t allowed for a
Working Group document (see RFC5378, Section 3.3).

We’ve talked since then with the authors about how we might move
forward with the draft. They had concerns, which had already been
discussed on the list, about some of the views of the WG on the
applicability of RPZ.

We believe we’ve found a way forward that meets their concerns and
the needs of the WG. We propose that:

1. The draft adopts the following language in the Introduction:

This document describes an existing and widely deployed method
by which a security policy can be applied to DNS responses,
possibly causing an end system to receive responses that do
not correspond to actual DNS zone content. Such policy-based
responses might prevent access to selected HTTP servers, or
redirect users to "walled gardens", or block objectionable
email, or otherwise defend against DNS content deemed
malicious by the RDNS operator and the end-user.

This method describes its policy using a specially formatted
DNS Zone called a Response Policy Zone (RPZ), and is an
instance of a more general mechanism called a "DNS Firewall."
Like other mechanisms called "firewalls," response policy
zones (RPZ) can be used to block both wanted as well as
unwanted data.  RPZ ought not be used to interfere with data
desired by recipients. In other words, RPZ should be deployed
only with the permission of every affected RDNS end-users.

This document does not recommend the use of RPZ in any
particular situation or instead of other mechanisms including
those more commonly called "firewalls."  This document lacks
an applicability statement for that reason, and because it
merely describes a currently common practice, without
recommending or criticising that practice. By design and
expectation, response policy zones (RPZ) must be seen as a
defensive and virtuous tool, or it will either not be used, or
will be bypassed by end-users.


2. We had already limited the the scope of the document to
describing the current protocol, with any discussion of proposed
changes left to a later document if people want to do that work.
That limitation stands. The intended document status is Informational.

3. The copyright is changed to the standard boilerplate required
for a WG draft.


If this is acceptable to the WG, we’ll keep the new draft with
these changes as a WG draft.

If not, the draft will be dropped as a WG item. The authors can
seek publication of the document as an independent submission or
outside of the RFC series.

If you have a comment on this, please make it succinctly and soon.


thanks,
Suzanne & TIm

___
DNSOP mailing list
DNSOP@ietf.org <mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop
<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] draft-ietf-dnsop-dns-rpz

[Suzanne Woolf]

Dear colleagues,


As you might recall, we had a call for adoption for draft-vixie-dns-rpz 
just before IETF 98 in March. We had a lively discussion and decided to 
adopt the document for further work in the WG as an Informational RFC.


However, the chairs then discovered we’d made a mistake in adopting the 
draft with the copyright that reserved rights in derivative works to the 
original authors. This isn’t allowed for a Working Group document (see 
RFC5378, Section 3.3).


We’ve talked since then with the authors about how we might move forward 
with the draft. They had concerns, which had already been discussed on 
the list, about some of the views of the WG on the applicability of RPZ.


We believe we’ve found a way forward that meets their concerns and the 
needs of the WG. We propose that:


1. The draft adopts the following language in the Introduction:

   This document describes an existing and widely deployed method by
   which a security policy can be applied to DNS responses, possibly
   causing an end system to receive responses that do not correspond to
   actual DNS zone content. Such policy-based responses might prevent
   access to selected HTTP servers, or redirect users to "walled
   gardens", or block objectionable email, or otherwise defend against
   DNS content deemed malicious by the RDNS operator and the end-user.

   This method describes its policy using a specially formatted DNS
   Zone called a Response Policy Zone (RPZ), and is an instance of a
   more general mechanism called a "DNS Firewall." Like other
   mechanisms called "firewalls," response policy zones (RPZ) can be
   used to block both wanted as well as unwanted data.  RPZ ought not
   be used to interfere with data desired by recipients. In other
   words, RPZ should be deployed only with the permission of every
   affected RDNS end-users.

   This document does not recommend the use of RPZ in any particular
   situation or instead of other mechanisms including those more
   commonly called "firewalls."  This document lacks an applicability
   statement for that reason, and because it merely describes a
   currently common practice, without recommending or criticising that
   practice. By design and expectation, response policy zones (RPZ)
   must be seen as a defensive and virtuous tool, or it will either not
   be used, or will be bypassed by end-users.


2. We had already limited the the scope of the document to describing 
the current protocol, with any discussion of proposed changes left to a 
later document if people want to do that work. That limitation stands. 
The intended document status is Informational.


3. The copyright is changed to the standard boilerplate required for a 
WG draft.



If this is acceptable to the WG, we’ll keep the new draft with these 
changes as a WG draft.


If not, the draft will be dropped as a WG item. The authors can seek 
publication of the document as an independent submission or outside of 
the RFC series.


If you have a comment on this, please make it succinctly and soon.


thanks,
Suzanne & TIm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

[Suzanne Woolf]

(not sure which hat. Probably doc shepherd.)

> On Jul 4, 2017, at 9:23 AM, Ted Lemon  wrote:
> 
> On Jul 4, 2017, at 3:39 AM, Randy Bush  wrote:
>> is there a companion document with the list of benefits/advantages?  or
>> is thins just one of those ietf documents from on high meant to kill
>> something?

> 
> This is a very good question. We weren’t asked to answer that question, so we 
> didn’t.  It is assumed throughout the document that various proponents of 
> special use domains have good reasons for wanting them, and further that it 
> is already accepted in principle that if their reason for wanting them is 
> valid, they can have them (modulo technical constraints like delegation). So 
> we didn’t delve into that. But perhaps we should have. 

I’d go a step further: RFC 6761 alludes to some general reasons, but assumes 
people who’d go through the IETF standards process or an IESG approval process 
to get an entry in the special use names registry have good enough reasons that 
the special handling requested should be accepted as part of the DNS protocol. 
(I’m one of the people who isn’t comfortable with this assertion, but we’re 
living with what RFC 6761 says, not what I think it should have said.) 

That is, RFC 6761 leaves to other processes to assess the value of the request 
and the reasons offered, but strictly speaking doesn’t require them to be 
documented or evaluated; required documentation for the registry entry consists 
mostly of assessing how it interacts with the DNS, not its primary use. (Sec. 4 
starts by saying “If it is determined that special handling of a name is 
required in order to implement some desired new functionality,” the registry 
entry policy applies, but openly avoids describing how that determination 
should be made.)

This isn’t really strange— plenty of registries don’t require any particular 
discussion of the merits of an entry; ISTM that “standards action” presumes 
such evaluation as part of IETF consensus. But it does seem like a significant 
part of the observed problem— there are only subjective and ad hoc bases for 
evaluation for a request that’s not otherwise justified by a standards track 
document, leading to endless repetitions of discussions like whether a new 
CLASS would be a “better” way to solve a problem that isn’t actually documented 
in the request.

I think the observation that people aren’t really required to document what 
problem they are trying to solve with their special use name is in the draft, 
but perhaps could be more explicit. 

Some few people already have been convinced that there should be some general 
guidance available for making the determination that a domain name requires 
special handling in the DNS. But that also seems to be a different document.



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

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

[Suzanne Woolf]

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] extended deadline Re: WGLC for draft-ietf-dnsop-alt-tld

[Suzanne Woolf]

Hi,

We had initially scheduled the WGLC on this document to be over by now. 
However, the flurry of activity around the review we were asked to do on the 
homenet-dot draft, and the general traffic level on the list during IETF 98, 
suggested to the chairs that we should extend the WGLC.

We’re hereby formally extending it to next Wednesday, April 12.

As always for WGLC— we need to hear both support and opposition for taking this 
draft to the next step in the process.

thanks,
Suzanne  & TIm


> On Apr 1, 2017, at 4:17 PM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:
> 
> On Sun, Mar 12, 2017 at 07:20:55PM -0400,
> Suzanne Woolf <suzworldw...@gmail.com> wrote 
> a message of 92 lines which said:
> 
>> This message opens a Working Group Last Call for:
>> 
>> "The ALT Special Use Top Level Domain"
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
>> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/>
> 
> I've read -08 and I believe I understand this draft. I'm not convinced
> it's useful (most users of alternative resolution systems won't use it
> and, anyway, I'm not even sure it will be added in the Special-Use
> registry, which was wrongly frozen by the IESG) but I don't see big
> issues with the draft, it seems to me it correctly describes the new
> TLD.
> 
> Editorial :
> 
> Section 1:
> 
> "and that should not be resolved" I cannot parse it. Missing "it"?
> 
> Section 5 :
> 
> After "and anyone watching queries along the path", add a reference to
> RFC 7626?
> 
> Normative references:
> 
> Why is RFC 6303 a normative reference? It is no longer used.
> 
> Why is RFC 7686 a normative reference? It is just an example.
> 

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

Re: [DNSOP] .arpa

[Suzanne Woolf]

> On Mar 27, 2017, at 8:41 AM, Ray Bellis  wrote:
> 
> 
> 
> On 27/03/2017 02:52, Patrik Fältström wrote:
> 
>> One important part is in the letter from NTIA (Karen Rose) to ICANN 
>> (Louis Touton) in Appendix A.
>> 
>> A letter sent April 28, 2000.
> 
> Is it online?   I can't find it in the ICANN correspondence archive.

It’s Appendix A to RFC 3172.


Suzanne

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

Re: [DNSOP] .arpa

[Suzanne Woolf]

> On Mar 26, 2017, at 11:17 AM, Ozgur Karatas <okara...@yandex.com> wrote:
> 
> Hello,
> 
> 22.03.2017, 10:05, "Jim Reid" <j...@rfc1035.com>:
>>>  On 21 Mar 2017, at 14:53, Suzanne Woolf <suzworldw...@gmail.com> wrote:
>>> 
>>>  RFC 3172 was written in 2001…
> 
> the last updated was made in 2013, right?

The text of the document did not change. The date appears to be an artifact of 
a change to the datatracker database or tools, not the content or status of the 
underlying document.


Suzanne

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

[DNSOP] scribes, slides, and other logistics for DNSOP WG meeting at IETF 98

[Suzanne Woolf]

Hi all,

Our meeting is Monday this time:

DNSOP 13:00-15:00, room Zurich D

If you’re presenting, your slide deck should be visible at 
https://datatracker.ietf.org/meeting/98/materials. If you sent us slides and 
they’re not there, please remind us ASAP; if you didn’t send us slides, please 
do.

As always, we need a jabber scribe and a note-taker; volunteers in advance are 
appreciated.


See you there,
Suzanne & Tim

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

Re: [DNSOP] .arpa

[Suzanne Woolf]

> On Mar 23, 2017, at 1:40 PM, Ralph Droms <rdroms.i...@gmail.com> wrote:
> 
> 
>> On Mar 23, 2017, at 1:34 PM, Suzanne Woolf <suzworldw...@gmail.com> wrote:
>> 
>> Hi Ray,
>> 
>>> On Mar 23, 2017, at 1:24 PM, Ray Bellis <r...@bellis.me.uk> wrote:
>>> 
>>> I consider them to be _independent_.  The special use reservation
>>> mustn't be held up waiting for the requested insecure delegation.
>> 
>> I’m trying to make sure I understand what the special use reservation 
>> accomplishes in the absence of the insecure delegation.
>> 
>> If I read your comment correctly, I can infer two things about the protocol, 
>> whether the insecure delegation is delayed or refused, at least in the short 
>> term:
>> 
>> 1. The protocol is sufficiently functional for deployment without working 
>> capability for DNSSEC validation.
> 
> Clarification: does this mean "without DNSSEC validation initially but DNSSEC 
> validation is needed eventually" or  "even if DNSSEC validation is never 
> available”?

I meant the question to cover both cases. The second question may well be more 
important in the “never available” case, but that’s part of what I’m trying to 
understand.



thanks,
Suzanne

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

Re: [DNSOP] .arpa

[Suzanne Woolf]

Hi Ray,

> On Mar 23, 2017, at 1:24 PM, Ray Bellis  wrote:
> 
> I consider them to be _independent_.  The special use reservation
> mustn't be held up waiting for the requested insecure delegation.

I’m trying to make sure I understand what the special use reservation 
accomplishes in the absence of the insecure delegation.

If I read your comment correctly, I can infer two things about the protocol, 
whether the insecure delegation is delayed or refused, at least in the short 
term:

1. The protocol is sufficiently functional for deployment without working 
capability for DNSSEC validation.

2. Having a single-label name is more important for the functioning of the 
protocol than having DNSSEC validation work.
 
Is this a fair assessment of the WG’s view?


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

[DNSOP] draft-ietf-homenet-dot review limits Re: .arpa

[Suzanne Woolf]

Hi all, and not picking on John….

I think this subthread on process and policy has gone as far as we reasonably 
can in a DNSOP review of draft-ietf-homenet-dot. We’ve established that 
different constraints and expectations apply to policy for different portions 
of the namespace, and that the HOMENET WG believes those differences have been 
taken into account, and that not everyone in DNSOP agrees.

Please share any new thoughts on how the specified protocol in the draft 
interoperates with the global public DNS, particularly with regards to DNSSEC 
or possibly incompatible uses of the namespace, which seem to be within our 
chartered scope.

I believe the process and policy concerns we’ve raised here can be revisited in 
an additional request for review or an IETF Last Call, if needed.


thanks,
Suzanne

> On Mar 23, 2017, at 10:00 AM, John R Levine  wrote:
> 
>> The working group is aware of the "wait many years" part of this approach, 
>> and is willing to try and see.  If the working group sees no progress over 
>> the course of the next few years, we may shift to the latter approach.
> 
> Just out of curiosity, is there anyone in the homenet WG who regularly 
> engages with ICANN, through AC's or SO's or the like?
> 
> R's,
> John
> 
> ___
> 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] .arpa

[Suzanne Woolf]

> On Mar 22, 2017, at 3:05 AM, Jim Reid <j...@rfc1035.com> wrote:
> 
>> On 21 Mar 2017, at 14:53, Suzanne Woolf <suzworldw...@gmail.com> wrote:
>> 
>> RFC 3172 was written in 2001…
> 
> RFC 3172 was an attempt to rewrite history and contrive an acronym: Address 
> and Routing Parameter Area - really?

Well, no. I thought it wasn’t rewriting anything, but setting a future 
direction. (The backronym was cute or annoying, depending on your POV, but 
ultimately not that important.)

> 
>> Respectfully, I’ve always wondered who has this problem (US or non-US) 
>> besides network infrastructure geeks Of a Certain Age (yes, including 
>> myself, and many IETF participants).
> 
> It's a convenient tool for those hostile to USG "control" of the Internet: ie 
> the US military is responsible for everything under .arpa, the US military's 
> ARPA has still got some special status in the operation/development/control 
> of the Internet, etc, etc. 

So the answer to “Why not actually use it where it’s technically suitable” is 
essentially “installed base”? 

I don’t mean to sound flippant— I’m just trying to understand the view that 
there’s a bigger obstacle to using .arpa than there is to asking ICANN for a 
root zone entry and engaging with all of the resulting complexities.


thanks,
Suzanne

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

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Suzanne Woolf]

Jim,

In the interests of preserving a distinction here that I believe is important: 

> On Mar 21, 2017, at 10:01 AM, Jim Reid  wrote:
> 
> 
>> On 21 Mar 2017, at 13:54, Paul Wouters  wrote:
>> 
>> Suggesting we postpone .homenet while figuring out a new IETF/ICANN
>> process, something that can take years, would basically doom this rename
>> and install .home as the defacto standard.
> 
> At the risk of pouring petrol on the fire, .home *is* the defacto standard. 
> Queries for this TLD account for ~4% of the 2016 DITL root server traffic. 
> That's more than every delegated TLD except .com and .net. And the traffic 
> for .home has been increasing in both absolute and relative terms in recent 
> years. 3-4 years ago, it was ~3% of the DITL data set.

“Lots of queries for .home” doesn’t imply that it’s a “defacto standard” for 
anything in particular.

Is there any evidence connecting the use of the string “.home” in queries to 
the DNS with any particular protocol, type of equipment, network configuration, 
or software? 


thanks,
Suzanne

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

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Suzanne Woolf]

Paul,

I’d like to make sure I understand your comment, as I’m not completely sure it 
addresses mine.

As I read your response, you’re willing to forgo a root zone entry, and the 
DNSSEC behavior the WG has reached consensus it wants, in order to have an 
entry in the special use name registry for “homenet”. Is that correct?

If so….I see your point and I hope the IESG  is listening, as I don’t think 
it’s the HOMENET WG consensus; as written, this draft asks for both a 
single-label name and certain behavior with respect to DNSSEC, which means 
asking for an entry in the root zone.

A little more, below.

> On Mar 21, 2017, at 9:54 AM, Paul Wouters <p...@nohats.ca> wrote:
> 
> On Tue, 21 Mar 2017, Suzanne Woolf wrote:
> 
> [also speaking as individual only]
> 
>> I see no justification in draft-ietf-homenet-dot for a single-label name, 
>> except an implicit suggestion in
>> Sec. 2 para. 2 that the specific string was chosen to be memorable in cases 
>> where homenet names are exposed to
>> users. 
> 
> That seems good enough for me. The problem of DNS being the only
> real name space for endusers is very well understood. And I still
> regularly have to refind my printer based on checking my dhcp server
> logs, something not available to regular endusers. The requirement
> is very real.

The requirement for a name that will resolve in the DNS? Sure.

The requirement for a single label/TLD that will resolve in the DNS root zone? 
Dramatically less clear to me, and nothing you say above is specific to the 
root.

From the perspective of the DNS protocol, which string is used to fill a domain 
name slot is mostly immaterial as long as strings are generated and parsed 
according to the recognized rules; they’re interchangeable— what matters is 
that they’re unique within the relevant namespace. The root of a hierarchical 
namespace is mathematically special in a few ways, but I haven’t seen a case 
that the name used by HNCP requires any of them. At the same time, the root of 
the DNS namespace is quite clearly special in the administrative sense; I’m 
trying to separate the two sets of considerations.

>> I *strongly* suggest that if this document is to be used as justification to 
>> create an entirely new process
>> for updating the root zone, coordinated between the IETF and the external 
>> body that controls the root zone,
>> the justification should be *much* more explicit.
> 
> This .home / .homenet issue has already been going on for a very long
> time. The longer we wait with resolving this issue, the worse the
> deployment situation will be of software mixing .home vs .homenet.

For the purpose of the question I’m asking, I’m indifferent between the strings 
“.home" and “.homenet”. The policy problems with “.home" are significantly 
larger than with “.homenet”, but asking for a root zone entry at all is a 
significant problem for the current draft, no matter what string is involved.

> Suggesting we postpone .homenet while figuring out a new IETF/ICANN
> process, something that can take years, would basically doom this rename
> and install .home as the defacto standard. Once this new process
> would be completed, it would lead to new breakage, and the new
> software would be forced to look into both domains, or if the
> install base is big enough for .home, would be better of ignoring
> a new .homenet altogether.

Again, I’d like to make sure the problem I was trying to address is clear.

Asking for a delegation in the root zone, particularly an unsigned one, as this 
document currently does, *will* essentially require "figuring out a new 
IETF/ICANN process, something that can take years.” This is true no matter what 
string is being requested. 

It’s simple fact that a name elsewhere in the tree does not have the same 
obstacle.


Suzanne



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

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Suzanne Woolf]

Hi,

No hats, except DNS/names geek who has spent a lot of time talking with policy 
people about why and how the root zone is (and isn’t) special.

> On Mar 20, 2017, at 3:38 PM, Russ Housley  wrote:
> 
> Ted:
> 
>> There are other processes for adding names to the root zone.  In my opinion, 
>> using the special-use TLD registry as a means of putting a name, even one 
>> that has a different scope and use case, is an end run around that process.
>> 
>> So it seems to me that your position is not that it's inappropriate for a 
>> name to both be registered in the root zone and in the special-use names 
>> registry, but rather that two processes would have to be followed in order 
>> for this to happen.   Is that a reasonable interpretation of what you have 
>> said?
> 
> No.  In my opinion, the special-use TLD registry is not appropriate for the 
> assignment of any name that will appear in the root zone.  As I said in my 
> first note, my view is that TLDs assigned through the special-use registry 
> MUST NOT be published in the root zone.
> 
> If you have a domain names that is to appear in the root zone, then the 
> existing process ought to be used for that to happen.

I’d probably state my version of this argument slightly differently: I think 
Russ is interpreting draft-ietf-homenet-dot-03 as unilaterally imposing a 
requirement on another body, possibly in violation of that body's own policies 
and processes, or at least creating a need for them to respond outside of 
established process.

In this case, “the existing process” simply doesn’t cover what’s being asked 
for, and extending the existing process to cover what’s being asked for cannot 
unilaterally be done by the IETF as a body. This creates an external dependency 
and a need for the IETF to attempt to resolve it— an attempt that may well end 
in disappointment.

A “special use name” is NOT necessarily a single label name. There is *no* 
necessary connection between “special use name” and “TLD,” any more than 
there’s a necessary connection between “special use name” and “the string has 
the letters of my pony’s name in it". One hypothetical string may be better for 
a specific use than another, but the characteristics of the string required are 
protocol-specific (including the significance of the dot), not intrinsic to the 
registry or to domain names generally. 

To add some color to the problem being created here, I’ll suggest looking at 
the question we’d be asking if the request were not for “.homenet,” but for 
“.homenet.arpa” or “.homenet.foo” (where “foo” is a TLD in the current DNS root 
zone).

If the request were for “homenet.arpa,” we wouldn’t be having this conversation 
at all. The “.arpa” TLD is under the administrative control of the IAB, there’s 
existing process for asking the IAB to add a name to .arpa (signed or not, 
delegated or not), and there’s existing process within the IETF community for 
providing input to IAB decisions on the subject (see RFC 3172). Personally I’d 
be happy to advocate for the IAB to approve adding an unsigned delegation for 
.homenet.arpa to the .arpa zone; it seems to me it wouldn’t even require much 
change to the draft to satisfy RFC 3172, Sec. 3.

If the request were for “homenet.foo,” we’d be having a different conversation 
about the implications, but we still wouldn’t be creating a new external 
process dependency. Operationally speaking, there are literally hundreds of 
TLDs whose existing policies would allow for the registration of “homenet” as a 
second level name. In my view it would be unwise to use one when the .arpa 
alternative is available, because future changes to the rules for such domains 
are outside of the control of the IETF and the standards process, but at least 
we wouldn’t be asking for an entirely new process from an external actor under 
no obligation to give us one.

I see no justification in draft-ietf-homenet-dot for a single-label name, 
except an implicit suggestion in Sec. 2 para. 2 that the specific string was 
chosen to be memorable in cases where homenet names are exposed to users. 

I *strongly* suggest that if this document is to be used as justification to 
create an entirely new process for updating the root zone, coordinated between 
the IETF and the external body that controls the root zone, the justification 
should be *much* more explicit.


Suzanne

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

[DNSOP] WG review of draft-ietf-homenet-dot-03

[Suzanne Woolf]

Hi,

The INT Area Director who oversees the homenet WG, Terry Manderson, has asked 
DNSOP participants to review 
https://www.ietf.org/id/draft-ietf-homenet-dot-03.txt 
, "Special Use Top Level 
Domain '.homenet’”, with the following aspects in mind:

1) in terms of RFC6761

2) in terms of the _operational_ position of an unsigned entry in the root zone 
as requested in this document, to break the chain of trust for local DNS 
resolution of .homenet names.

This document is the product of the homenet WG, which has asked the IESG to 
approve it for publication, so our comments are strictly advisory to the IESG. 
There was some discussion of the draft on this list shortly after it appeared, 
in November 2016, but it’s always the AD’s prerogative to ask for additional 
review.



thanks,
Suzanne & Tim___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Suzanne Woolf]

Hi,

Per assorted comments in this thread….a couple of observations from one WG 
chair.

It’s my sense at least that the WG was clear that there’s some interest in 
publishing an informational document about RPZ, given that it’s widely deployed 
and considered useful by certain admins in certain situations, but that such a 
potential RFC should have more detailed discussion than the initial draft of 
drawbacks and cautions regarding the use of this technology.

It also seemed to me that the usual rules apply: authors on a WG document are 
committed to working through WG discussion to consensus. If that doesn’t work 
out, the authors can be replaced or the document abandoned.

I still think there’s a possible consensus view that will allow a version of 
this document to proceed, if it meets the constraints we’ve discussed. If not, 
we will not have consensus to advance it, and an eventual WGLC will tell us so. 
As our AD pointed out, that’s awkward but hardly unprecedented.

Finally, folks should feel free to offer the cautions they think the document 
should include, but as Andrew already noted, text that claims to speak for the 
IAB or ISOC or other organizations is out of scope for us as an IETF WG and 
will not be added to the document.


thanks,
Suzanne


> On Mar 13, 2017, at 3:46 AM, Ray Bellis  wrote:
> 
> On 13/03/2017 05:35, william manning wrote:
>> Joel,
>> 
>> I'd be happy to see the document proceed under two conditions:  1) it
>> becomes a WG document, subject to IETF change control, and 2) that the
>> disclaimer requested back on 20170103 be added to the document. To
>> refresh the collective mind, here is the missing text:
>> 
>> applicability statement.
>> 
>> This draft is documents a process and method for intercepting DNS
>> queries and fabricating responses to redirect the querier into a walled
>> garden or enclave that is NOT part of the open Internet. Adoption and
>> acceptance of this draft is an acknowledgement that the IETF, the IAB
>> and ISOC reject the principles espoused
>> at https://open-stand.org/about-us/principles/
>> , in particular article 3. 
>> Collective Empowerment insofar as the evolution of the DNS is concerned.
> 
> Very strong -1 against that text, here!
> 
> RPZ is already in very widespread use on the open Internet, especially
> as a means to protect end users against botnet C hosts.
> 
> Ray
> 
> ob. disclaimer - I work for a DNS vendor that implements RPZ
> 
> 
> ___
> 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] WGLC for draft-ietf-dnsop-alt-tld

[Suzanne Woolf]

This message opens a Working Group Last Call for:

"The ALT Special Use Top Level Domain"
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 

Intended status: Proposed Standard

Per the discussion in our interim meeting a couple of weeks ago, the editors 
have revised this document and the chairs are opening a Working Group Last 
Call. 

Please let us know, on the list, whether you support advancing 
draft-dnsop-alt-tld-08 to the IESG for publication.

The document has been stable for awhile except for one significant change in 
the new version. As discussed in the interim, it now clarifies that “.alt” is 
intended for use with domain names intended to be resolved outside of the DNS 
protocol. 

With IETF 98 upon us, we’re giving this a little extra time (3 weeks).

Starts: 13 March 2017
Ends:  3 April 2017


thanks,
Suzanne & Tim




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

Re: [DNSOP] call for agenda items, IETF 98

[Suzanne Woolf]

Hi,

This is a good point, thanks Paul.

If you’re an editor on a WG document, please consider what you need from the WG 
to get it ready for a Working Group Last Call.  If you’re missing 
reviews/reviewers, the chairs/secretary are happy to help you find some. If you 
need input from the WG, please ask for it.

If you’ve been meaning to review a Working Group document, why not make it part 
of your prep for IETF 98?

And if you want to propose new work, please remember you’ll need reviewers and 
editors, and pay it forward by reviewing a current draft or two :-)


Suzanne



> On Mar 1, 2017, at 10:51 AM, Paul Hoffman  wrote:
> 
> 
> 
> 
> As you are thinking of agenda requests, please look at
>   https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html
> There are a lot of WG documents for which we haven't heard much discussion 
> *on the list*. Instead, we seem to hear more about documents that are 
> "Candidate for WG adoption" or document that people want in that category.
> 
> It would be grand if we could have more discussion about any of the WG 
> documents on the list before having presentations in the face-to-face 
> meeting: that makes the meeting time more useful.
> 
> --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] summary: virtual interim meeting, 16 Feb. 2017

[Suzanne Woolf]

Hi,

The chairs’ summary from the WG virtual interim meeting last week appears below.

Recording of the webex session: 

https://ietf.webex.com/ietf/ldr.php?RCID=09e87536cf71661d1e4e7339abcf001e 



Chairs’ summary of the discussion

1. sutld-ps WGLC:
* editors are resolving issues, quite a few have been raised and most 
are straightforward to resolve
* distinction between special use names generally and “TLDs” needs to 
be clear, also distinction between names to be resolved with DNS and names to 
be resolved otherwise
* Question came up of where we stand process-wise, particularly if the 
IETF or IESG change or don't publish the problem statement. There's been no 
commitment to publish it, but the roadmap that blocked other action on having 
one was discussed multiple times with our AD; and even if we don’t publish it, 
the exercise has been useful for the WG
* Future action may not occur in DNSOP at all; that’s largely up to the 
IESG.

2. alt-tld:
* mostly done; we know what it will and won’t do, and there was 
agreement that more distinction needs to be made in the document
* as discussed on the list, consensus seems to be against asking for a 
signed delegation in the root for .alt
* open issue discussed here was whether to add .alt to the 
locally-served zones registry; consensus on the call seemed to be not to do 
that either; editors will propose text to wrap up both issues. Some people felt 
the justification for the latter should be in a “Security Considerations,” 
others felt it should be in a “Privacy Considerations”.

3. next steps
* no one is ready to propose concrete next steps beyond “find out what 
the IESG thinks”
* some people feel this topic isn’t DNSOP WG business, because there 
are technical issues but they won’t be resolved within the scope of the WG 
charter; a few feel it’s a “layer violation” that has nothing to do with the 
IETF, because it’s intrinsically and entirely political.
* some confusion on the scope limitation put in place for the problem 
statement that we/the IESG might want to relax for DNSOP (or anyone else) to 
consider solutions

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

Re: [DNSOP] Ed's comment s on Re: WGLC for draft-ietf-dnsop-sutld-ps

[Suzanne Woolf]

> On Feb 16, 2017, at 11:46 AM, Russ Housley  wrote:
> 
> Ed:
> 
>> #Special-Use Domain Names [RFC6761] created an IANA registry for
>> #special-use Domain Names [SDO-IANA-SUDR], defined policies for adding
>> #to the registry, and made some suggestions about how that policy
>> #might be implemented.  Since the publication of RFC 6761, the IETF
>> #has been asked to designate several new special-use Domain Names in
>> #this registry.  During the evaluation process for these special-use
>> 
>> It would be good to provide a list of requests for new special use names.
>> Especially for a problem statement, this provides a way to estimate the 
>> "size and shape" of the problem and the urgency.
> 
> No matter how you count, the volume will remain small if this is done 
> properly.  However, the special name requests can still be important and 
> urgent.

I also note it’s fairly difficult to estimate. 

At one point DNSOP had been asked to consider several drafts asking for various 
things (and some asking for more than one name). We didn’t adopt the 
.home/.corp/.mail draft. The .onion request went to the IESG and eventual 
acceptance. We adopted the .alt draft because it claimed to solve a significant 
chunk of the problem, and then parked it pending agreement on what problem we 
actually have. The HOMENET WG currently has a draft requesting .homenet as both 
a special use name and a root zone entry.

All of the drafts besides those for .onion, .alt, and .homenet have expired, 
which tells us nothing about whether or how they might come back. There’s also 
limited empirical data about what names people are simply appropriating for 
uses outside of the global public DNS, or how widely used they might be; leaked 
traffic to large recursors and the root servers is probably a proxy for some of 
it but how much we don’t know.


Suzanne

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

Re: [DNSOP] Webex details Re: correction Re: virtual interim DNSOP WG meeting and current status, special use names

[Suzanne Woolf]

The intent is to conduct the session as much like an ordinary IETF WG meeting 
as possible.

So yes, we’ll monitor the jabber room and record the session.

This also means we’ll need a note-taker, any volunteers??



Suzanne

> On Feb 16, 2017, at 7:40 AM, Hollenbeck, Scott <shollenb...@verisign.com> 
> wrote:
> 
> Will the jabber room at  <>dn...@jabber.ietf.org 
> <mailto:dn...@jabber.ietf.org> also be used?
>  
> Scott
>  
> From: DNSOP [mailto:dnsop-boun...@ietf.org <mailto:dnsop-boun...@ietf.org>] 
> On Behalf Of Suzanne Woolf
> Sent: Wednesday, February 15, 2017 6:50 PM
> To: dnsop <dnsop@ietf.org <mailto:dnsop@ietf.org>>
> Subject: [EXTERNAL] [DNSOP] Webex details Re: correction Re: virtual interim 
> DNSOP WG meeting and current status, special use names
>  
> Hi,
>  
> The secretariat has graciously given us access to a webex login for the WG, 
> so the setup details for the virtual interim tomorrow are:
>  
>   Meeting number: 644 850 881
>   Meeting password: special
>  
>   Meeting link: 
> https://ietf.webex.com/ietf/j.php?MTID=m420b562577eec300c73de2e3c9b7d49f 
> <https://ietf.webex.com/ietf/j.php?MTID=m420b562577eec300c73de2e3c9b7d49f>
>  
>   Audio connection:
>  
>   1-877-668-4493 Call-in toll free number (US/Canada)
>  
>   1-650-479-3208 Call-in toll number (US/Canada)
>  
>   Access code: 644 850 881
>  
> Agenda:
>  
> 0. Intro/note well/agenda bash (chairs)
>  
> 1. Issues from WGLC on the problem statement 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps 
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps>) (authors)
>  
> 2. Update on alt-tld 
> ((https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/>) (authors)
>  
> 3. Proposals for moving forward:
>  
> * alt-tld to WGLC?
>  
> * stop here? (leave RFC 6761 as-is, continue to process registry changes 
> case-by-case)
>  
> * proposals for process revision/update?
>  
> * any drafts to write?
>  
> * any input or liaison that DNSOP should request from the IAB? (regarding 
> either namespace architecture or relationships of the IETF with other groups)
>  
> 4. AOB: your I-D or proposed action for the WG/IESG/IAB here
>  
> On Feb 2, 2017, at 4:48 PM, Suzanne Woolf <suzworldw...@gmail.com 
> <mailto:suzworldw...@gmail.com>> wrote:
>  
> And because it’s been that day….
>  
> Thanks for the off-list nudge, that’s ***Thursday 16 February*** for most of 
> the world, Friday 17 February for the AP region.
>  
> We’ve blocked two hours for the meeting.
>  
> Apologies for the error.
>  
>  
> Suzanne
>  
>  
> On Feb 2, 2017, at 3:52 PM, Suzanne Woolf <suzworldw...@gmail.com 
> <mailto:suzworldw...@gmail.com>> wrote:
> 3. We still want (and have time) to do a virtual interim WG meeting before 
> Chicago. We’ve picked a date:
>  
> Thursday 17 February, 19:00 UTC, which is:
>  
> 19:00 UTC
> 20:00 CEST (Frankfurt, Stockholm)
> 14:00 EST (North American Eastern)
> 11:00 PST (North American Western)
> 06:00 AEDT (Sydney, Melbourne)
>  
> (Webex details will follow)
>  
> As usual, scheduling isn’t perfect for anyone but we tried to cover the 
> largest possible area of the globe adequately.
> 
> Preliminary agenda for the meeting is:
> 
>   1. Issues from WGLC on the problem statement 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ 
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/>)
>   2. Proposals for moving forward:
>   * reviews of alt-tld; ready for WGLC? will it help? 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/>)
>   * stop here? (leave RFC 6761 as-is, continue to process 
> registry changes case-by-case)
>   * proposals for process revision/update?
>   3. Next steps: 
>   * any drafts to write?
>   * any input or liaison to request from the IAB? 
> (regarding either namespace architecture or relationships of the IETF with 
> other groups)
>   4. AOB: your I-D or proposed action for the WG/IESG/IAB here
>  
>  
> thanks,
> Suzanne & Tim

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

[DNSOP] Webex details Re: correction Re: virtual interim DNSOP WG meeting and current status, special use names

[Suzanne Woolf]

Hi,

The secretariat has graciously given us access to a webex login for the WG, so 
the setup details for the virtual interim tomorrow are:

Meeting number: 644 850 881
Meeting password: special

Meeting link: 
https://ietf.webex.com/ietf/j.php?MTID=m420b562577eec300c73de2e3c9b7d49f

 Audio connection:

 1-877-668-4493 Call-in toll free number (US/Canada)

 1-650-479-3208 Call-in toll number (US/Canada)

 Access code: 644 850 881

Agenda:

0. Intro/note well/agenda bash (chairs)

1. Issues from WGLC on the problem statement 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps) (authors)

2. Update on alt-tld 
((https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/) (authors)

3. Proposals for moving forward:

* alt-tld to WGLC?

* stop here? (leave RFC 6761 as-is, continue to process registry changes 
case-by-case)

* proposals for process revision/update?

* any drafts to write?

* any input or liaison that DNSOP should request from the IAB? (regarding 
either namespace architecture or relationships of the IETF with other groups)

4. AOB: your I-D or proposed action for the WG/IESG/IAB here

> On Feb 2, 2017, at 4:48 PM, Suzanne Woolf <suzworldw...@gmail.com> wrote:
> 
> And because it’s been that day….
> 
> Thanks for the off-list nudge, that’s ***Thursday 16 February*** for most of 
> the world, Friday 17 February for the AP region.
> 
> We’ve blocked two hours for the meeting.
> 
> Apologies for the error.
> 
> 
> Suzanne
> 
> 
>> On Feb 2, 2017, at 3:52 PM, Suzanne Woolf <suzworldw...@gmail.com 
>> <mailto:suzworldw...@gmail.com>> wrote:
>> 3. We still want (and have time) to do a virtual interim WG meeting before 
>> Chicago. We’ve picked a date:
>> 
>> Thursday 17 February, 19:00 UTC, which is:
>> 
>> 19:00 UTC
>> 20:00 CEST (Frankfurt, Stockholm)
>> 14:00 EST (North American Eastern)
>> 11:00 PST (North American Western)
>> 06:00 AEDT (Sydney, Melbourne)
>> 
>> (Webex details will follow)
>> 
>> As usual, scheduling isn’t perfect for anyone but we tried to cover the 
>> largest possible area of the globe adequately.
>> 
>> Preliminary agenda for the meeting is:
>> 
>>  1. Issues from WGLC on the problem statement 
>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ 
>> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/>)
>>  2. Proposals for moving forward:
>>  * reviews of alt-tld; ready for WGLC? will it help? 
>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
>> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/>)
>>  * stop here? (leave RFC 6761 as-is, continue to process 
>> registry changes case-by-case)
>>  * proposals for process revision/update?
>>  3. Next steps: 
>>  * any drafts to write?
>>  * any input or liaison to request from the IAB? (regarding 
>> either namespace architecture or relationships of the IETF with other groups)
>>  4. AOB: your I-D or proposed action for the WG/IESG/IAB here
>> 
>> 
>> thanks,
>> Suzanne & Tim
>> 
> 

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

Re: [DNSOP] solving a problem by creating a worse problem, ALT-TLD and (insecure) delgations.

[Suzanne Woolf]

Hi,

The editors hold the token on text for this, but it seems to me that the 
discussion has started going in circles.

A number of arguments have been made, and in some cases repeated. Let’s assume 
the editors have heard them and try to restrict followups to new observations, 
questions, or arguments.

> On Feb 10, 2017, at 1:25 PM, John Levine  wrote:
> 
>> This is part of why I don't want to extend alt this way, and the more
>> I think about it the less desirable it seems to me.  We have a
>> particular problem: non-DNS-protocol switching for applications that
>> want to use a DNS-compatible domain name slot (see RFC 5890).
> 
> Agreed.  Say that you can do anything you want with .ALT (duh) but you
> SHOULD NOT resolve .ALT names via the DNS protocol because of the
> DNSSEC problems.  To minimize leakage, we can use the tools we already
> have: qname minimization, local mirrors of the root, and special
> casing in DNS caches as many now do for .onion.

This sounds reasonable to me.


Suzanne

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

[Suzanne Woolf]

Hi Stephane,

Thanks for the review, it’s helpful.

I’ll leave it to the editors to take the first pass at integrating your 
comments, but:

> On Feb 8, 2017, at 4:15 AM, Stephane Bortzmeyer  wrote:
> 
> Biggest problem with the draft: it fails to mention the only real
> technical problem with RFC 6761, the lack of a formal language for the
> registry, thus preventing the programmers of resolving software to
> compile automatically the code for the various cases.
> 

If you have a specific suggestion on how to improve the registry, please 
consider posting an internet-draft. 

The roadmap for DNSOP on special use names has for some time included the 
expectation that a problem statement would precede solutions, but that problem 
statement is in WGLC after extensive development, and we’ve returned the 
alt-tld draft to active status as well. 

We didn’t encourage proposed changes until we had some level of agreement on 
what problem(s) we might be attempting to solve. However, it seems we’ve now 
gotten that far.


thanks,
Suzanne

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Suzanne Woolf]

> On Feb 6, 2017, at 11:15 AM, Ray Bellis  wrote:
> 
>> For now, let’s keep it relevant to the decision this WG has to make,
>> about what to do with .alt and whether it’s important to us to
>> accommodate cases like .homenet. So far, it seems that the .homenet case
>> is much like “locally-served zones”.
> 
> Yes, that's right, with the caveat that all existing locally served
> zones are in the reverse space - there's no forward zones registered (yet).

Could you clarify why that’s relevant?

Does it just come down to the assumption that reverse zones are not supposed to 
have human-visible/human-friendly names? Or is there some other characteristic 
of how those names are used that’s important here?


thanks,
Suzanne

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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Suzanne Woolf]

Hi,

Before this goes any further, I’m not sure an incomplete rehashing of the 
consensus in another WG is a good use of our time.

For now, let’s keep it relevant to the decision this WG has to make, about what 
to do with .alt and whether it’s important to us to accommodate cases like 
.homenet. So far, it seems that the .homenet case is much like “locally-served 
zones”.


thanks,
Suzanne

> On Feb 6, 2017, at 10:57 AM, Ólafur Gudmundsson  wrote:
> 
> 
> Ralph, 
> A WG can come to a consensus on a topic without all information available.
> Now go back and see if reality changes consensus.
> 
> Just my .02 cents.
> 
> 
> Ólafur
> 
> On February 6, 2017 9:52:53 AM CST, Ralph Droms  wrote:
> 
> 
> On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson  > wrote:
> 
>> Ted,
>> 
>> What RFC are you referring to?
>> 
>> Why do you think .ARPA is for services?
>> It's for infrastructure and homenet wants to join the infrastructure.
>> 
>> It is waste of time arguing if name A or B is better take the one you can 
>> get faster.
> 
> The WG has considered the alternatives, and WG consensus is to specify 
> ".homenet"
> 
> - Ralph
> 
>> 
>> Ólafur
>> 
>> 
>> On February 5, 2017 10:22:35 PM CST, Ted Lemon > > wrote:
>> The working group has consensus to give it a try.  We may change our minds 
>> of it takes too long, but it seems worth exploring from a process 
>> perspective anyway. 
>> 
>> On Feb 5, 2017 11:18 PM, "John R Levine" > > wrote:
>> I'm pretty sure I've explained it enough times on this mailing list and in
>> the relevant documents by now. If you don't agree, maybe we should just
>> accept that. If you don't remember the explanation, it's in the homenet
>> naming architecture doc I wrote.
>> 
>> Well, OK, I took another look, and from what I can see, it's a belief that 
>> people will find toaster.homenet.arpa harder or more confusing to type than 
>> toaster.homenet.
>> 
>> Just out of curiosity, how long is it worth waiting to get .homenet rather 
>> than .homenet.arpa?  If it took five more years, which at the current rate 
>> seems optimistic, would homenet still be relevant?
>> 
>> R's,
>> John
>> 
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org 
>> https://www.ietf.org/mailman/listinfo/dnsop 
>> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> 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] ALT-TLD and (insecure) delgations.

[Suzanne Woolf]

> On Feb 4, 2017, at 4:46 AM, Ray Bellis  wrote:
> 
> 
> 
> On 04/02/2017 02:13, Andrew Sullivan wrote:
>> Right, that's always been the problem with using this _for the DNS_.
>> Homenet has no choice in that, because the whole point of the homenet
>> name is precisely to enable in-homenet DNS without reference to the
>> global DNS.  I think you're quite correct that we need to decide
>> whether alt is to be used for those purposes.  I'm not convinced
>> that's so useful.
> 
> If it turns out that we can't get the insecure delegation that we need
> for .homenet, then I'd (personally) be reasonably happy with
> .homenet.alt, except that the current proposals for the use of .alt
> wouldn't seem to permit that.

The other question to keep in mind, perhaps particularly for HOMENET, is how 
long are you/we willing to wait?

The IETF has no process for requesting a change to the root zone (it’s not one 
of the protocol parameter registries under the change control of the IETF) and 
ICANN has no process for evaluating such a request..

Generallly when iCANN is asked to do something for which they have no process, 
their answer is Yes; No; or “We have to think about that,” and it often takes 
years, particularly in the last case.

(no hats, just lots of experience.)


Suzanne

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