Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06

2018-02-28 Thread Paul Wouters 

On Wed, 28 Feb 2018, Tommy Pauly wrote:


I’ve updated the draft with your comments as version -07: 
https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt


Thanks for doing this. I would make one change (but it can be done after 
IETF-LC)

[...] the content SHOULD be considered untrusted and handled 
accordingly.

You changed should to SHOULD, but in this case it really is a MUST.

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06

2018-02-28 Thread Tommy Pauly 
Hi David,

I’ve updated the draft with your comments as version -07: 
https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt 


Thanks,
Tommy

> On Feb 28, 2018, at 9:38 AM, Tommy Pauly  wrote:
> 
> Hi David,
> 
> Thanks! I’ll work on this today and send an update.
> 
> Tommy
> 
>> On Feb 26, 2018, at 4:51 PM, Waltermire, David A. (Fed) 
>>  wrote:
>> 
>> Authors,
>> 
>> Overall the draft is almost ready to submit to the IESG once the following 
>> few small issues are resolved. 
>> 
>> Section 1.1:
>> 
>> There are a few lowercase instances of must, may, and should in the 
>> document. You should use text from RFC8174 to indicate that lowercase 
>> versions of the keywords are not normative.
>> 
>> Something like the following would work:
>> 
>>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>  "OPTIONAL" in this document are to be interpreted as described in BCP
>>  14 [RFC2119] [RFC8174] when, and only when, they appear in all
>>  capitals, as shown here.
>> 
>> Please double check the lowercase "must", "should", and "may" instances to 
>> be sure they are properly non-capitalized.
>> 
>> In section 3.1 the document states:
>> 
>> If an INTERNAL_DNSSEC_TA attriute is included
>>  in the CFG_REQUEST, the initiator SHOULD also include one or more
>>  INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST.
>> 
>> The behavior for the responder is not defined in section 3.2 if this 
>> "SHOULD" is violated. Would it be desireable for the responder to ignore the 
>> INTERNAL_DNSSEC_TA attribute? This behavior should be defined either way.
>> 
>> (nit) s/attriute/attribute/ (I think Tero already found this and we are 
>> waiting to handle this in AD review/IETF LC.)
>> 
>> Section 3.4.2:
>> 
>> (nit) s/attributes/attributes/
>> 
>> (nit) s/received in the CFG_REPLY/received in the CFG_REPLY./
>> 
>> "In this example, the initiator has no existing DNSSEC trust anchors would 
>> the requested domain." Should this be 'for the requested domain 
>> "example.com."'? The following sentence should start with a capitalized 
>> letter. The paragraph should end with a period.
>> 
>> How about the following as a replacement:
>> 
>> In this example, the initiator has no existing DNSSEC trust anchors
>>  for the requested domain "example.com". The responder provides DNSSEC
>>  trust anchors for the "example.com" domain, but does not configure trust 
>> anchors for the "city.other.com" domain.
>> 
>> Section 5:
>> 
>> The first sentence of the 6th paragraph contains a lowercase "must", which I 
>> believe should be capitalized.
>> 
>> (nit) s/be be/be/
>> 
>> Once this is all fixed I will send the draft to the IESG. I'll complete the 
>> writeup using your text as a starting point in the interim.
>> 
>> Regards,
>> Dave
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] I-D Action: draft-ietf-ipsecme-split-dns-07.txt

2018-02-28 Thread internet-drafts 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions WG of 
the IETF.

Title   : Split DNS Configuration for IKEv2
Authors : Tommy Pauly
  Paul Wouters
Filename: draft-ietf-ipsecme-split-dns-07.txt
Pages   : 12
Date: 2018-02-28

Abstract:
   This document defines two Configuration Payload Attribute Types for
   the IKEv2 protocol that add support for private DNS domains.  These
   domains are intended to be resolved using DNS servers reachable
   through an IPsec connection, while leaving all other DNS resolution
   unchanged.  This approach of resolving a subset of domains using non-
   public DNS servers is referred to as "Split DNS".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-07
https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06

2018-02-28 Thread Tommy Pauly 
Hi David,

Thanks! I’ll work on this today and send an update.

Tommy

> On Feb 26, 2018, at 4:51 PM, Waltermire, David A. (Fed) 
>  wrote:
> 
> Authors,
> 
> Overall the draft is almost ready to submit to the IESG once the following 
> few small issues are resolved. 
> 
> Section 1.1:
> 
> There are a few lowercase instances of must, may, and should in the document. 
> You should use text from RFC8174 to indicate that lowercase versions of the 
> keywords are not normative.
> 
> Something like the following would work:
> 
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>   "OPTIONAL" in this document are to be interpreted as described in BCP
>   14 [RFC2119] [RFC8174] when, and only when, they appear in all
>   capitals, as shown here.
> 
> Please double check the lowercase "must", "should", and "may" instances to be 
> sure they are properly non-capitalized.
> 
> In section 3.1 the document states:
> 
> If an INTERNAL_DNSSEC_TA attriute is included
>   in the CFG_REQUEST, the initiator SHOULD also include one or more
>   INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST.
> 
> The behavior for the responder is not defined in section 3.2 if this "SHOULD" 
> is violated. Would it be desireable for the responder to ignore the 
> INTERNAL_DNSSEC_TA attribute? This behavior should be defined either way.
> 
> (nit) s/attriute/attribute/ (I think Tero already found this and we are 
> waiting to handle this in AD review/IETF LC.)
> 
> Section 3.4.2:
> 
> (nit) s/attributes/attributes/
> 
> (nit) s/received in the CFG_REPLY/received in the CFG_REPLY./
> 
> "In this example, the initiator has no existing DNSSEC trust anchors would 
> the requested domain." Should this be 'for the requested domain 
> "example.com."'? The following sentence should start with a capitalized 
> letter. The paragraph should end with a period.
> 
> How about the following as a replacement:
> 
> In this example, the initiator has no existing DNSSEC trust anchors
>   for the requested domain "example.com". The responder provides DNSSEC
>   trust anchors for the "example.com" domain, but does not configure trust 
> anchors for the "city.other.com" domain.
> 
> Section 5:
> 
> The first sentence of the 6th paragraph contains a lowercase "must", which I 
> believe should be capitalized.
> 
> (nit) s/be be/be/
> 
> Once this is all fixed I will send the draft to the IESG. I'll complete the 
> writeup using your text as a starting point in the interim.
> 
> Regards,
> Dave
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec