Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf-fix

2018-06-27 Thread Paul Hoffman
Due to its nature, the document is a bit difficult to read, but I don't 
have any suggestion about how to make it better. The only problem I have 
with the document is that there are lots of informational references 
that are not referred to in the body of the text; they are not even 
listed in the Updates list at the top of the document. This should 
either be explained clearly in the body of the document or removed.


--Paul Hoffman

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


[DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf-fix

2018-06-27 Thread Benno Overeinder
A number of reviewers of the accompanying draft-ietf-dnsop-attrleaf
suggested to have both drafts WG Last Call reviewed in one go.  We think
this makes sense and the last version of the
draft-ietf-dnsop-attrleaf-fix-01 is good for WG Last Call.

This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf-fix

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

The Current Intended Status of this document is: Best Current Practice

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

This starts a two week Working Group Last Call process, and ends on:
Wednesday 11 July 2018.

Thanks,

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

2018-06-27 Thread Dick Franks
The document appears to be in good shape.

However, I have some difficulty with the wording of these two paragraphs in
section 2.

  The basic wire format for names in the global DNS is a list of
  labels ordered by decreasing distance from the root, with the root
  label last.  Each label is preceded by a length octet.  [RFC1035]
  also defines a compression scheme that modifies this format.

  The presentation format for names in the global DNS is a list of
  labels ordered by decreasing distance from the root, encoded as
  ASCII, with a "." character between each label.  In presentation
  format, a fully-qualified domain name includes the root label and
  the associated separator dot.  For example, in presentation
  format, a fully-qualified domain name with two non-root labels is
  always shown as "example.tld." instead of "example.tld".
  [RFC1035] defines a method for showing octets that do not display
  in ASCII.

The character encoding of "presentation format" depends on the context in
which it is used. The protocol mandates ASCII encoding of labels on the
wire.
It cannot say anything about the internal character encoding conventions of
application programs or related master files, which can, in the general
case,
be different.

Consider the following perl fragment:

use Net::DNS 1.11;

my $resolver = new Net::DNS::Resolver();

my ($rr) = $resolver->query( 'www.example.com.', 'A' )->answer;

$rr->print;
print unpack( 'H*', $rr->string ), "\n";

executed in an ASCII-based environment:

  www.example.com.600INA93.184.216.34

772e6578616d706c652e636f6d2e0936303009494e09410939332e3138342e3231362e3334

in an OS390 EBCDIC environment:

  www.example.com.600INA93.184.216.34

a6a6a64b85a781949793854b8396944b05f6f0f005c9d505c105f9f34bf1f8f44bf2f1f64bf3f4

(output converted to ASCII to preserve your sanity)


Suggested replacement text:

  The basic wire format for names in the global DNS is a list of
  labels ordered by decreasing distance from the root, with the root
  label last.  Each label is ASCII encoded and preceded by a single
length octet.  [RFC1035]
  also defines a compression scheme that modifies this format.

  The presentation format for names in the global DNS is a list of
  labels ordered by decreasing distance from the root, represented by
  printable characters from the ASCII repertoire, irrespective of the
local
  character encoding used to represent them.
  The component labels are separated by a single "." character.
  In presentation format, a fully-qualified domain name includes the
root label and
  the associated separator dot.  For example, in presentation
  format, a fully-qualified domain name with two non-root labels is
  always shown as "example.tld." instead of "example.tld".
  [RFC1035] defines a numerical representation that may be used to
display
  octets for which there is no corresponding ASCII printable character.





Dick Franks



On 22 June 2018 at 21:01, 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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop