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 <https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt>
Thanks, Tommy > On Feb 28, 2018, at 9:38 AM, Tommy Pauly <[email protected]> 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) >> <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
