Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Benoit,

On Jul 5, 2017 12:32 PM, "Benoit Claise"  wrote:

Hi,

Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon  wrote:

> Spencer, not to respond to all your comments right now, but just to point
> this out: the list of problems is not claimed to be correct.   It is
> claimed to be the list of problems that people have asserted exist.   I do
> not agree that all the problems listed are problems, nor I think does
> anyone else.   If that's not clear in the document, that's probably worth
> correcting.
>

I think my comments are more likely to be unclear than the way the document
describes the problem set. What you said, is what I think the document says.

I'm mostly sending comments about specific points that the document makes,
that I think I understand at a surface level, but I don't think I
understand the implications in a few cases, so, that's what I included in
my ballot.

I think the document is clear enough on "claimed to be the list of problems
that people have asserted exist", and even if I didn't think that was a
fine basis for this document, I wouldn't dream of suggesting that the
authors change the criteria for what's included.

Part of my AD review, I asked the text to clarified. Hopefully, it's
clarified.
>From the 04 to 05 diff:


That is clear (and clearer than -04).

Spencer



Regards, B.




On Jul 5, 2017 12:32 PM, "Benoit Claise"  wrote:

Hi,

Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon  wrote:

> Spencer, not to respond to all your comments right now, but just to point
> this out: the list of problems is not claimed to be correct.   It is
> claimed to be the list of problems that people have asserted exist.   I do
> not agree that all the problems listed are problems, nor I think does
> anyone else.   If that's not clear in the document, that's probably worth
> correcting.
>

I think my comments are more likely to be unclear than the way the document
describes the problem set. What you said, is what I think the document says.

I'm mostly sending comments about specific points that the document makes,
that I think I understand at a surface level, but I don't think I
understand the implications in a few cases, so, that's what I included in
my ballot.

I think the document is clear enough on "claimed to be the list of problems
that people have asserted exist", and even if I didn't think that was a
fine basis for this document, I wouldn't dream of suggesting that the
authors change the criteria for what's included.

Part of my AD review, I asked the text to clarified. Hopefully, it's
clarified.
>From the 04 to 05 diff:


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

Re: [DNSOP] new DNS classes

[Phillip Hallam-Baker]

There are changes to the DNS that are practical and those that are not. For
better or worse, I can't see any way that teaching DNS to use new classes
makes any sense at this point. The only point at which it would have made
sense was when internationalization happened. But the path chosen makes
more sense.

ICANN will manage whatever bits of the DNS consensus agrees it should
manage. The only events likely to break consensus would be an attempt by
some government to strong arm ICANN into a breach of faith with the
community and succeeding or some really spectacular peculation.

It seems to me that if people want to do anything new with DNS that they
should use prefixes, new RRs or both as the mechanism, not the class which
is limited anyway.

DNS is not a full service directory. Nor does it need to be. A UDP packet
is big enough for a link, a fingerprint and a digital signature. That is
all that you ever need.

The X.500 and UDDI models were broken because there is no point in putting
information into a directory if the service can return it in a service
handshake.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Terry Manderson's No Objection on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)

[Terry Manderson]

Terry Manderson has entered the following ballot position for
draft-ietf-dnsop-sutld-ps-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/



--
COMMENT:
--

Thanks for writing this document - I believe that having such a document makes
future discussions much easier, that said I am not a fan of publishing problem
statements in the RFC series. Given the document already lays out a level of
dissent in so far as some people don't see all these listed "problems" as
problems, (and I agree with them!) - they could however be universally
described as "issues", where any particular concern or issue doesn't
necessarily need to a response (irrespective of which forum or SDO holds the
baton for that discussion piece). My suggestion would be to reword language
portions to describe the information contained in this draft as "issues and
concerns" and further because the text provided covers more than just the
enumerated set of "issues" (was problems), may I also suggest a title change to
something like "Issues, Concerns, and information related to Special-Use Domain
Names".


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

Re: [DNSOP] requesting WGLC for 5011-security-considerations

[Wes Hardaker]

Michael StJohns  writes:

> That's not actually a plus you understand.   Mike

Sure it is.  We're down to the point where large changes aren't needed :-P
-- 
Wes Hardaker
USC/ISI

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

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

[Mark Andrews]

In message <765a15bf-8505-4470-9628-70ce9665b...@gbiv.com>, "Roy T. Fielding" 
writes:
> > On Jul 4, 2017, at 9:23 PM, Matthew Kerwin  =
> wrote:
> >=20
> > On 5 July 2017 at 13:19, Mark Andrews  wrote:
> >>=20
> >> In message =
> 

Re: [DNSOP] requesting WGLC for 5011-security-considerations

[Michael StJohns]

That's not actually a plus you understand.   Mike

On Wed, Jul 5, 2017 at 18:22 Wes Hardaker  wrote:

> Michael StJohns  writes:
>
> > Could you hold off on this for another week? The revised version
> > dropped last week and I've been on travel and enjoying the holiday and
> > haven't had a chance to review the changes.   Thanks - Mike
>
> FYI, the changes are very small:
>
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-rfc5011-security-considerations-01=draft-ietf-dnsop-rfc5011-security-considerations-02
>
>
> --
> Wes Hardaker
> USC/ISI
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] requesting WGLC for 5011-security-considerations

[Wes Hardaker]

Michael StJohns  writes:

> Could you hold off on this for another week? The revised version
> dropped last week and I've been on travel and enjoying the holiday and
> haven't had a chance to review the changes.   Thanks - Mike

FYI, the changes are very small:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-rfc5011-security-considerations-01=draft-ietf-dnsop-rfc5011-security-considerations-02


-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] requesting WGLC for 5011-security-considerations

[Wes Hardaker]

"Paul Hoffman"  writes:

> Just a note that the actual filename for the draft is
> draft-ietf-dnsop-rfc5011-security-considerations, and it can be found

Whoops; thanks Paul.
-- 
Wes Hardaker
USC/ISI

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

[DNSOP] Alissa Cooper's Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-dnsop-sutld-ps-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/



--
COMMENT:
--

In Section 4, "the IAB technical document" could use a reference.


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

Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)

[Benoit Claise]

Hi,

Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon > wrote:


Spencer, not to respond to all your comments right now, but just
to point this out: the list of problems is not claimed to be
correct.   It is claimed to be the list of problems that people
have asserted exist.   I do not agree that all the problems listed
are problems, nor I think does anyone else.   If that's not clear
in the document, that's probably worth correcting.


I think my comments are more likely to be unclear than the way the 
document describes the problem set. What you said, is what I think the 
document says.


I'm mostly sending comments about specific points that the document 
makes, that I think I understand at a surface level, but I don't think 
I understand the implications in a few cases, so, that's what I 
included in my ballot.


I think the document is clear enough on "claimed to be the list of 
problems that people have asserted exist", and even if I didn't think 
that was a fine basis for this document, I wouldn't dream of 
suggesting that the authors change the criteria for what's included.
Part of my AD review, I asked the text to clarified. Hopefully, it's 
clarified.

From the 04 to 05 diff:


Regards, B.

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

Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Ted,

On Wed, Jul 5, 2017 at 12:20 PM, Ted Lemon  wrote:

> Spencer, not to respond to all your comments right now, but just to point
> this out: the list of problems is not claimed to be correct.   It is
> claimed to be the list of problems that people have asserted exist.   I do
> not agree that all the problems listed are problems, nor I think does
> anyone else.   If that's not clear in the document, that's probably worth
> correcting.
>

I think my comments are more likely to be unclear than the way the document
describes the problem set. What you said, is what I think the document says.

I'm mostly sending comments about specific points that the document makes,
that I think I understand at a surface level, but I don't think I
understand the implications in a few cases, so, that's what I included in
my ballot.

I think the document is clear enough on "claimed to be the list of problems
that people have asserted exist", and even if I didn't think that was a
fine basis for this document, I wouldn't dream of suggesting that the
authors change the criteria for what's included.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Roy T. Fielding]

> On Jul 4, 2017, at 9:23 PM, Matthew Kerwin  wrote:
> 
> On 5 July 2017 at 13:19, Mark Andrews  wrote:
>> 
>> In message 
>> 

Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)

[Ted Lemon]

Spencer, not to respond to all your comments right now, but just to point this 
out: the list of problems is not claimed to be correct.   It is claimed to be 
the list of problems that people have asserted exist.   I do not agree that all 
the problems listed are problems, nor I think does anyone else.   If that's not 
clear in the document, that's probably worth correcting.

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

[DNSOP] requesting WGLC for 5011-security-considerations

[Wes Hardaker]

Folks,

We believe that the latest draft-rfc5011-security-considerations
document is ready for WGLC, and would like the chairs to start that
process unless anyone thinks it's not ready to go forward.  In
particular, we believe all outstanding issues with it have been
resolved.

Objections?

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt

[Richard Gibson]

On Wed, Jul 5, 2017 at 8:05 AM, Jim Hague  wrote:

> Timestamps, on the other hand, I always regarded as a basic data type,
> so naturally a structure. Plus, of course, there's one per
> query/response item, so in a block the size savings are in the 10-15k
> bytes region, which is rather more significant.
>

In that case, I'm even more convinced that all of them (block preamble
"earliest-time", Q/R data item "time" and "delay", malformed packet item
"time") should have the same structure—either variable-precision arrays or
{"seconds", "useconds", "pseconds"} maps.

> * In section 7.18, "and an unsigned key" appears to be meaningless and
> > should probably be removed.
>
> In most places where we are discussing a map, we've specified the type
> of the map key in the text, though I notice we're not 100% consistent
> with that.
>

All the keys in those maps (and in every map, as far as I can tell) are
strings, for which "unsigned" is a meaningless concept.


> Example use
> > cases:
> [...]
> > * Extend the block preamble (section 7.7) to override file preamble
> > fields like "host-id" and "server-addresses", enabling fleet-wide file
> > merges.
>
> I don't quite follow why you'd need to put this informational-only stuff
> into the block preamble rather than the file preamble/configuration. Can
> you expand on that a bit?
>

Some of our processing can benefit from merging telemetry (e.g., all hosts
at a site), which would produce files containing blocks that don't share
values for fields currently in the file preamble. In fact, we might even
decide to treat "block" as the only relevant unit, using block preamble
extension fields for *everything* in the standard file preamble except
version information.

> *Opt-in Lossyness*
> This raises a question about a tension between the background of C-DNS
> to date and the slightly different angle you are coming from. We've been
> very much focused on using C-DNS to record traffic in a form where the
> packets can be recreated in wire format (i.e. as PCAP). The optional
> data items mean that data may be missing from those packets, but the
> core query and response will still be present.
>

Agreed. But it's _so close_ that I felt these suggestions were worth
raising—not to water down the primary use case, but to cover a few more
with some tradeoffs.

moves the recording to a point where reconstructing wire format means
> that the application doing the reconstruction has to not just omit
> information not present in C-DNS, but must start generating values to
> fill in for the missing items. This feels a bit like a step that needs
> discussion; we need to think over the design from your point of view.
> Possibly those fields should be optional, but with recommendations for
> how to populate them when/if generating PCAP.
>

That sounds great.

We'll be doing a 10 minute slot on C-DNS in Prague, and would welcome
> discussion there.


I don't expect to be there personally, but we'll have a well-informed
representative.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Warren Kumari's Recuse on draft-ietf-dnsop-sutld-ps-07: (with COMMENT)

[Warren Kumari]

Warren Kumari has entered the following ballot position for
draft-ietf-dnsop-sutld-ps-07: Recuse

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/



--
COMMENT:
--

I am an author on this document, and so recusing myself from balloting.


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

[DNSOP] draft-sullivan-dns-class-useless (was Re: new DNS classes)

[Andrew Sullivan]

Hi Mark,

On Wed, Jul 05, 2017 at 09:33:15AM +1000, Mark Andrews wrote:
> 
> draft-sullivan-dns-class-useless has lots provably invalid assumptions
> in it that it is worthless in determining if new classes could be
> deployed.

What are the "lots of provably invalid assumptions in it"?  As far as
I know, I incorporated changes that were an attempt to address
comments you sent me; perhaps I didn't understand you at the time.
But this is the first time I've ever heard about provably invalid
assumptions.  

Anyway, I abandoned the effort because it became clear to me that
there wasn't going to be any consensus around this: there were too
many people too wedded to keeping classes around despite the obvious
problem that they haven't actually been used when the obvious
opportunities arose.

I cheerfully predict that the DNS will be replaced before we ever have
a significant deployment of a class that even remotely rivals the
deployment of IN.  But I'm not going to waste a lot of effort trying
to forge a consensus about that.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

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

[Warren Kumari]

Been trying to figure out where to insert this.

https://tools.ietf.org/html/draft-sullivan-dns-class-useless-03

Abstract

   Domain Name System Resource Records are identified in part by their
   class.  The class field is not effective, and it is not used the way
   it appears to have been intended.  This memo suspends additions to
   the DNS class registry pending greater clarity on how classes might
   be used, and until such clarification requires those defining new
   RRTYPEs to define them for all classes.


Answer wrote a draft about this a few months / years ago.
W

On Tue, Jul 4, 2017 at 10:36 PM, william manning
 wrote:
> Most of the other application (besides dns) presume a single class, IN,
> hence the URL presumption of "DNS name" will -always- be in the IN class.
> Technically imprecise and sloppy, but pragmatically it works...  until some
> loons come along and do something creative with classes.   Then all bets are
> off.
> RFC 1034 also uses IN in its examples and most folks forget inheritence
> rules.
>
> /Wm
>
> On Tue, Jul 4, 2017 at 7:23 PM, Matthew Kerwin 
> wrote:
>>
>> On 5 July 2017 at 10:02, Mark Andrews  wrote:
>> >
>> > Who owns a name is a different question to what machines serve the
>> >  tuple and how do you reach those machines.  There
>> > is absolutely no reason why the zones  and 
>> > need to be served by the same machines.  There is a argument for
>> > them both being under control of the same people.
>> >
>> > Mark
>> >
>>
>> Hi, I'm jumping in at a random time with a possibly dumb question, but
>> the talk of  and  tuples got me wondering
>> about representation in general, and URLs in particular.
>>
>> RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks
>> like a DNS name is a DNS name, and that they have to be resolved to IP
>> addresses if you want to fetch them, but they don't talk meaningfully
>> about how to do that resolution. Given that we always assume class=IN
>> (not to mention type=A| via happy eyeballs), how would we go about
>> practically presenting an alternative class in things like URLs?
>> (Registering a new "alt-http" URL scheme doesn't strike me as a great
>> idea.)
>>
>> Because it's all well and good setting up your own .org hierarchy
>> under class=FOO or whatever, but there's not much point if you can't
>> send people to www.not-icann.org using it. Unless you don't want to
>> expose your new hierarchy to the web ...?
>>
>> Cheers
>>
>>
>> [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 :
>>
>>"""A registered name intended for lookup in the DNS uses the syntax
>>defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]."""
>>
>> I read that as: "if it matches RFC1034 (and isn't overridden by the
>> specific URI scheme's rules) it's a DNS name."  It could be read the
>> other way, but that just adds more assumptions.
>>
>> --
>>   Matthew Kerwin
>>   http://matthew.kerwin.net.au/
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>



-- 
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

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

[John C Klensin]

--On Wednesday, July 05, 2017 8:01 AM -0400 Suzanne Woolf
 wrote:

> (not sure which hat. Probably doc shepherd.)
>...

>> 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.)
>...
> 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,

Independent of "general guidance", I think the combination of
the I-D, this thread to date, and your comments above make an
extremely strong case for updating RFC 6761 to require
documentation of the problem and discussion of other
alternatives and why they are unworkable.  Whatever else the
problem statement does, I think it makes it clear that yet
another special name should be viewed as a preference only if
there are no reasonable alternatives rather than, e.g., an
option for global vanity names.  

While "general guidance for making the determination" would be,
IMO, desirable, I can imagine months (or years) of quibbling
before agreement could be reached on such criteria.  In the
interim, I'd think a requirement for documentation and
explanation sufficient to satisfy the IETF would be in order if
only as an interim measure to prevent proposals whose main
justification is "because I want one of my very own".

Anyone in DNSOP want to write a one-page RFC?

   john
 

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt

[Jim Hague]

On 04/07/2017 00:22, Richard Gibson wrote:
> I looked over this draft in detail, and found a handful of ambiguous
> points ("Clarifications" and "Potentially Missing Data" below). But more
> importantly, it is very close to defining a format that could replace
> much of my organization's in-house technology. Would you consider some
> generalizations to take it over the finish line ("Extension Fields" and
> "Opt-in Lossyness")? Only the suggestions related to representing time
> and "classtype" items would change the representation of existing data
> in such a way that implementations already supporting the draft
> specification would require changes.
>
> *Clarifications*
> * Items in the "classtype" table (section 7.11) are missing data type
> documentation. Both "type" and "class" should be unsigned numbers.

Thanks. Yes, the type needs adding.

>   * And speaking of 7.11, why are CLASS/TYPE pairs represented as CBOR
> maps instead of more efficient two-item arrays? If it was an intentional
> decision for clarity, then maybe the section 7.7 block preamble
> "earliest-time" field should also be promoted to a map ("time-seconds",
> "time-useconds", "time-pseconds", mirroring Q/R items) for the same
reason.

All the tables in the BlockTables section that are multi-valued are
maps. I did consider making the Class/Type pairs an array, but decided
to go for consistency with the other block tables containing composite
data and make it a map. Yes, two-item arrays would be more
space-efficient, saving two bytes per item. However, in the data we've
observed, the number of entries in the Class/Type table is, as you'd
expect, small, typically 15-20 entries. So we're looking at a saving of
maybe 40 bytes per block. By the time you've run through compression,
that advantage will be further eroded, so I ended up deciding that the
cost of consistency here was worth paying.

We've also considered specifying an implicit Class entry of IN (i.e. if
the Class items isn't present in the map, assume IN), but as, again, the
space saving is negligible prefer to keep the values explicit.

Timestamps, on the other hand, I always regarded as a basic data type,
so naturally a structure. Plus, of course, there's one per
query/response item, so in a block the size savings are in the 10-15k
bytes region, which is rather more significant.

> * In "query-sig" table items (section 7.13) "transport-flags" field, the
> bit corresponding to "trailing bytes" shouldn't be limited to UDP.

Interesting point. We haven't to date observed trailing data over TCP,
but that's not to say that somebody won't try it.

> * In section 7.18, "and an unsigned key" appears to be meaningless and
> should probably be removed.

In most places where we are discussing a map, we've specified the type
of the map key in the text, though I notice we're not 100% consistent
with that.

> *Potentially Missing Data*
> * In "query-sig" table items (section 7.13), "transport-flags" should
> probably be extended to include a TLS bit (cf. RFC 7858).

Agreed. We should also look at indicators for DNS-over-HTTP,
DNS-over-QUIC and any other exotica.

> *Extension Fields*
> Of the many potentially open-ended key-value maps (file preamble, file
> preamble configuration, block preamble, block statistics, query
> signatures, Q/R data), only block statistics allows for
> "implementation-specific fields", and no further guidance is provided. I
> think all maps should allow such fields, with a recommendation that they
> use an implementation-specific prefix to avoid collisions with fields
> added by other implementations or later versions of C-DNS.

You are right that extensibility of the tables is not something we have
considered deeply up to now, and it's definitely something that should
be done. FWIW, my initial inclination is to designate as
implementation-specific all key values above a threshold that allows
plenty of growth space for standardised fields, as long as we can be
sure that generic readers can safely skip over the fields they don't
understand.

This is a topic we need to discuss and flesh out.

 Example use
> cases:
[...]
> * Extend the block preamble (section 7.7) to override file preamble
> fields like "host-id" and "server-addresses", enabling fleet-wide file
> merges.

I don't quite follow why you'd need to put this informational-only stuff
into the block preamble rather than the file preamble/configuration. Can
you expand on that a bit?

> *Opt-in Lossyness*
> The format is generally quite good about allowing for detail without
> requiring it. However, there are some areas where more space savings
> could be had:
> * Communicate aggregation of IP addresses into prefixes (i.e., the
> irrelevance of least-significant bits in ip-address values) with new
> "client-prefix-length-ipv4" and "client-prefix-length-ipv6" and
> "server-prefix-length-ipv4" and "server-prefix-length-ipv6" file
> preamble configuration options.
> * Communicate case-normalizing aggregation of 

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

Re: [DNSOP] new DNS classes

[Randy Bush]

i think avoiding icann is a red herring.  if the draft in question had
done a decent job of exploring the taxa of needs for name resolution
outside of the 'normal' topology, we would have the start of a base on
which to discuss this.

randy

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