Hi James, On Thu, Feb 18, 2021 at 09:34:40PM +0000, Gould, James wrote: > Ben, > > Thank you for your review and feedback. I provide answers to your feedback > below. The referenced updates will be included in the posting of > draft-ietf-regext-unhandled-namespaces-08 along with addressing the other > feedback.
Thanks! A couple further remarks inline... > -- > > JG > > > James Gould > Fellow Engineer > jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 2/18/21, 3:04 AM, "Benjamin Kaduk via Datatracker" <nore...@ietf.org> > wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-regext-unhandled-namespaces-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://secure-web.cisco.com/1yPQYI1c9tXSEoYfkadjJdqXcBm9wmFYjvHBdyXg8gl7UfX3tyGPiT_vPr2PLWg6lpuqG_V8dwvTQ5B5bnQLDmzOOkJbSUkjMaC20YuIdBwKFZFh0NdSt-Ds-i0ykvPdf0mHHvGv5ILUyMbr6CBdiaXdi7Fydwx2LuUPOhTA9yAWLpfFdOGu7J3LSy0wrN32oh_kx2dwP5BVBZx5hFqZsr2SACtCukV8jme46DwTWh9zZiUCvPyM8gwKDkGb-1VzI/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://secure-web.cisco.com/1wy2ArcqQe3Zq40eI7HaKnaXuR0vvqzH838JvnmQrBzHjnb2jRMy-2ApZ8e2EzlE3g44OC9QVBYI6346OQjxknh2Aq062BriBH6Cwt-BhsNU99N9KroO0lFYdYvFgnShD44GJjSISOtJmmolVNmHfDeiGgVHjM18gyIK90rBbzwZAQ5kv3XcQrqN51wrd_VkLalpHzhOo7iBySvB6CgbR9veCq1QpnKyfBIxctIMZwnGXZEylNu3PBQlsWFg86d-3/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-unhandled-namespaces%2F > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > If both object-level and command-response extensions end up in the > <extValue> element, is it possible to determine whether a given > <extValue> is due to an object extension or a command-response > extension? > > JG - The way that a client would do this is by mapping the XML namespace to > the namespaces included in the original EPP Greeting > (https://tools.ietf.org/html/rfc5730#section-2.4), which splits out > object-level extensions, using the <objURI> elements, from command-response > extensions, using the <svcExtension> elements. Ah, I see; thanks for the extra explanation. It's perhaps not the prettiest mechanism, but given the constraints that this document has to work under, it will do just fine. > Section 2 > > The services > supported by the server are included in the <objURI> and <extURI> > elements of the [RFC5730] EPP <greeting>, which should be a superset > of the login services included in the EPP <login> command. [...] > > Where is this "should be a superset" specified? AFAICT it seems a bit > challenging for graceful deployment of new functionality, as it would > require servers to be updated before clients. If it was intended to be > a *sub*set, that might make more sense, but text elsewhere in the > document is not consistent with "subset". > > JG - The use of the superset language is based on an interpretation of RFC > 5730, where the EPP Greeting includes the set of services "supported by the > server", and the EPP Login includes the set of services "to be used during > the session". If the client includes more services than the server supports > in the EPP Greeting then the negotiated services in the EPP session would be > invalid. Therefore, the EPP Greeting services needs to be a superset of the > EPP Login services or conversely the EPP Login services needs to be a subset > of the EPP Greeting services, since the EPP Login services specify what will > be used. Superset is the appropriate term when defining it from the > perspective of the EPP Greeting. Ah, I think I see now (I was looking in the wrong part of 5730). (It does still sound like servers have to be updated before clients, but that's not anything that this document changes.) > Section 3 > > This document supports handling of unsupported namespaces for > [RFC3735] object-level extensions and command-response extensions. > This document does not support [RFC3735] protocol-level extensions or > authentication information extensions. [...] > > (editorial) I might consider a different word than "support"; perhaps > "utilize" or "instantiate". > > JG - The use of the "apply" may be more appropriate than "support", as in > "This document applies to the handling of unsupported namespaces for..." and > "This document does not apply to the handling of unsupported namespaces > for...". Do you agree? Yes. > Section 3.1 > > Should we mention that the example <transfer> query response from RFC > 5731 is in section 3.1.3 of that RFC? > > JG - Sure the section reference can be added, as in "...example in Section > 3.1.3 of [RFC5731]...". > > [RFC5731] example <transfer> query response converted into an > unhandled namespace response. > > S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> > [...] > S: <value> > S: <domain:trnData > S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > S: <domain:name>example.com</domain:name> > S: <domain:trStatus>pending</domain:trStatus> > S: <domain:reID>ClientX</domain:reID> > S: <domain:reDate>2020-06-06T22:00:00.0Z</domain:reDate> > S: <domain:acID>ClientY</domain:acID> > S: <domain:acDate>2020-06-11T22:00:00.0Z</domain:acDate> > S: <domain:exDate>2021-09-08T22:00:00.0Z</domain:exDate> > > Why did the dates (years) get updated compared to the RFC 5731 example? > (And it's not just a matter of uniformly adding 20 years, as the exDate > is only 19 years different.) > > JG - It was meant to update the dates to something more current, so 20 years > was added. I don't remember the logic beyond use of 19 years for the exDate. > Updating of the examples to match their source RFC XML and reference them by > section of the RFC will be addressed throughout the draft. Thanks. (It would also be fine to have new examples and say only that they use the XML elements of the referenced RFCs; I was just commenting since there was a note that it was supposed to be "the example from [the referenced RFC]" with just the single modification.) -Ben > Section 3.2 > > [RFC5910] DS Data Interface <info> response converted into an > unhandled namespace response. > > I couldn't actually find which example this corresponds to. It seems > like Section 5.1.2 of RFC 5910 would be the section in question, but the > first example there has a <secDNS:keyData> element that's not present > here, and the second example there doesn't have a <secDNS:keyTag>. > (Also, algorithm 3 and digest type 1 corresponds to DSA/SHA1 and SHA1, > IIRC, which are not exactly current best practice values. But the focus > here is on the XML, so I would not fault us for using the RFC 5910 > example verbatim ... if that was what we were actually doing.) > > JG - The example is taken from the first example in Section 5.1.2 of RFC > 5910. The second example in Section 5.1.2 of RFC 5910 includes the optional > <secDNS:keyTag> element. Updating of the examples to match their source RFC > XML and reference them by section of the RFC will be addressed throughout the > draft. > > Section 5 > > I had the same question as Murray. (And shouldn't that be something > specified in RFC 5730 anyway, not here?) > > JG - I provided a similar response to Murray. This is set as a SHOULD and > SHOULD NOT since it's based on an interpretation of RFC 5730 that the server > only accepts object-level commands based on the negotiated services in the > EPP session. Since this draft is focused on unhandled namespaces it was felt > to make it a recommendation with the SHOULD and the SHOULD NOT. RFC 5730 > doesn't explicitly state it, which is the basis for the SHOULD and SHOULD NOT > instead of the MUST and MUST NOT. > > S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> > S: <rgp:rgpStatus s="redemptionPeriod"/> > S: </rgp:infData> > > It looks like the corresponding RFC 3915 example also had an > xsi:schemaLocation attribute here. Though I guess maybe we are not > strictly claiming that this example is taken from RFC 3915, so it's okay > (as well as the following few nits)... > > S: <domain:upID>ClientX</domain:upID> > S: <domain:upDate>2020-12-03T09:00:00.0Z</domain:upDate> > S: <domain:exDate>2021-04-03T22:00:00.0Z</domain:exDate> > S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> > > These dates seem to have been changed from the RFC 3915 example as well. > > S: <domain:authInfo> > S: <domain:pw>2fooBAR</domain:pw> > S: </domain:authInfo> > > I did not see the authInfo in the RFC 3915 example. > > JG - Good eye. Updating of the examples to match their source RFC XML and > reference them by section of the RFC will be addressed throughout the draft. > > Section 10 > > I'd recommend just "SHOULD validate" rather than the (not exactly > actionable) "SHOULD consider validating". > > Also, there are arguably security considerations in the risk of the > client not actually processing the data from unhandled namespaces, > especially if it is "needed" for some purpose (we don't seem to go into > much detail as to if/when that might happen). > > JG - Agreed on the use of "SHOULD validate" instead of "SHOULD consider > validating". The only security consideration would be associated with the > processing of poll messages. But in thinking about it this doesn't really > represent a security consideration in implementing the draft since inclusion > of the information in the standard location is no different from inclusion > under the <extValue> element, since the client doesn't support it. The only > solution is for the client to support all of the namespaces supported by the > server and use the unhandled namespaces approach as a signal to add that > support. > > Section 12.1 > > The RFC 3915 content seems to only be used in an example, so it could > probably be classified as informative. Likewise for RFC 5910 and RFC > 8590. > > JG - Agreed, that change will be made. > > > > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
