Joseph, See my feedback below.
-- JG [cid:image001.png@01D255E2.EB933A30] James Gould Distinguished 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/> From: Joseph Yee <j...@afilias.info> Date: Wednesday, September 25, 2019 at 4:31 PM To: James Gould <jgo...@verisign.com> Cc: regext <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Document Shepherd Write Up of Login-Security Hi Jim and all, comments inline On Tue, Sep 24, 2019 at 5:01 PM Gould, James <jgo...@verisign.com<mailto:jgo...@verisign.com>> wrote: Joseph, Thank you for performing the document shepherd review and creating the writeup. You brought up 2 points in your comments, that I provide thoughts on below: 1. Section 3.1 - the paragraph that specifies when “name” must be mandatory. The text needs more work to be precise. The current text only specifies “name” is required when “type”==“custom”, where “name” is mandatory too when “type”==“stat”. a. When the “type” is “stat”, then the use of the “name” is mandatory to define the “stat” sub-type, per the definition of the “stat” type and the definition of the “name” attribute. I include both below for reference: i. "stat": Provides a login security statistical warning that MUST set the "name" attribute to the name of the statistic. 1. How about updating this description to highlight that the “name” is used to define the statistic sub-type, such as “Provides a login security statistical warning that MUST set the "name" attribute to the name of the statistic sub-type.”? When using the “stat” type, the use of the sub-type is required by using the “name” attribute. ii. "name": Used to define a sub-type when the "type" attribute is not "custom" or the full type name when the "type" attribute is "custom". 1. This description is accurate for the “stat” type, since the “name” attribute is used to define the sub-type. I have a bit of hard time reading your comment due to the numbering. As long as the the description "name" paragraph in some way specifies that both "stat" and "custom" MUST define "name" it will be fine IMHO. JG – The “stat” and “custom” types already define that the “name” attribute is required, so why would the “name” attribute need to include the reverse statement? The change that I proposed was to ensure that the definition of the “stat” type used the appropriate language by referring to the use of the “name” attribute to define the statistic sub-type. The definition of the “stat” type would read “Provides a login security statistical warning that MUST set the "name" attribute to the name of the statistic sub-type.” The “name” attribute defines either the sub-type or the full type name when the type is “custom”. The requirement for the inclusion of the “name” attribute is defined by the type. 1. 2. In Section 4.1, <loginSec:userAgent> specifies that one of the child element must be included if the request contained <loginSec:userAgent>. In the Formal Syntax section, the XML does not enforce it. If the XML syntax uses what XML Schema offers, then editors should check on <choice> element. a. I’m unaware of a clean method to enforce having at least one of the sub-elements (app, tech, and os) via the XML schema, since there can be one to three of the elements that is not well suited for the use of a <choice>. We need to ensure that there are no duplicates and maintaining the order would be preferred. Do you or anyone else have a proposal that can be used? My recommendation is to keep the XML schema as is and to have the server validate the existence of at least one sub-element after the XML parser, per the language of the specification. The original schema can maintain order, but can't maintain the presence. The following could work (in XML schema, <choice> can contain <sequence>, not just <element>, I haven't build any code to confirm it): *** <choice> <sequence> <element name="app" /> <element name="tech" minOccurs="0" /> <element name="os" minOccurs="0" /> </sequence> <sequence> <element name="tech" /> <element name="os" minOccurs="0" /> <sequence> <element name="os" /> </choice> *** JG – Yes, your proposal should work fine with the inclusion of the type=”token” for each of the elements and fixing the last <sequence> with </sequence>, as in: <complexType name="userAgentType"> <choice> <sequence> <element name="app" type="token" /> <element name="tech" type="token" minOccurs="0" /> <element name="os" type="token" minOccurs="0" /> </sequence> <sequence> <element name="tech" type="token" /> <element name="os" type="token" minOccurs="0" /> </sequence> <element name="os" type="token"/> </choice> </complexType> I can modify the XML schema in the draft to include this. Best, Joseph 1. a. Thanks, -- JG [cid:image001.png@01D255E2.EB933A30] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on behalf of Joseph Yee <j...@afilias.info<mailto:j...@afilias.info>> Date: Tuesday, September 24, 2019 at 3:09 PM To: regext <regext@ietf.org<mailto:regext@ietf.org>> Subject: [EXTERNAL] [regext] Document Shepherd Write Up of Login-Security All, I had uploaded the document shepherd write up of login-security and available at the link below for your reference: https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/shepherdwriteup/ Best, Joseph
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
