Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-01.txt

[神明達哉]

On Mon, Jan 9, 2017 at 4:43 AM, Ray Bellis  wrote:

> I've submitted a -01 revision to address most of the feedback received
> so far.

I have some minor comments on this version.

- Section 3.1

   IP Version: The IP protocol version number used by the client, as
   defined in the IANA IP Version Number Registry [IANA-IP].
   Implementations MUST support IPv4 (4) and IPv6 (6).

  I suspect "IANA-IP" is defined as a 4-bit field simply because the
  version field of the IPv4 (and therefore IPv6) header is 4 bits.
  But I don't think this specification necessarily has to inherit the
  restriction, and while it's probably quite unlikely to see the need
  for more than 15 values, I also don't see why we have to be more
  future proof (at least we know "IPv10" is coming, right? :-).
  Although there's an unused 4 more bits, I think it's even better to
  have a 16-bit field and use address family numbers:
  
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

- Section 3.2

   Proxies MUST append this option to each request packet received
   before sending it to the intended DNS server.

  This MUST sounds too strong to me as a general requirement.  Unless
  the upstream server needs the information provided in this option,
  there should be no interoperability problem even without this
  option.

- Section 3.3

   When this option is received from a white-listed client the DNS
   server MUST (SHOULD?) use the address from the option contained
   therein in preference to the client's source IP address for any data
   processing logic that would otherwise depend on the latter.

  I think this paragraph needs some more clarification.  I can easily
  imagine the server has an ACL that limits acceptable clients to
  those proxies.  But in that case the server should actually "use"
  the client's source IP address.  It's not a critical problem of the
  specification, but I think it's better to clarify the intended
  context to avoid such confusion of readers.

--
JINMEI, Tatuya

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

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-01.txt

[Mark Andrews]

TSIG and SIG(0) (not yet covered by the draft) require reversable
modifications of the message.  I would be appending a new additional
record (code TBA) and removing it which contains the addresses.  I
would not be modifying an existing OPT record.  Nor would I be
adding a new OPT record.  Modifying/adding a opt record requires a
lot more, error prone, work to add and reverse the changes to make
TSIG and SIG(0) work.

The additional section count would be increased by 1.

TSIG / SIG(0) may now be followed by this record.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-01.txt

[Ray Bellis]

I've submitted a -01 revision to address most of the feedback received
so far.

Ray

 Forwarded Message 
Subject: New Version Notification for draft-bellis-dnsop-xpf-01.txt
Date: Mon, 09 Jan 2017 04:41:53 -0800
From: internet-dra...@ietf.org
To: Ray Bellis 


A new version of I-D, draft-bellis-dnsop-xpf-01.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:   draft-bellis-dnsop-xpf
Revision:   01
Title:  EDNS X-Proxied-For
Document date:  2017-01-09
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-01.txt
Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/
Htmlized:   https://tools.ietf.org/html/draft-bellis-dnsop-xpf-01
Diff:   https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsop-xpf-01

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