Re: [regext] Document Shepherd Write Up of Login-Security

["Gould, James" <[e-mail]>]

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”.
     *   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.

           *   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".

           *   This description is accurate for the “stat” type, since the “name” attribute is used to define the sub-type.
  1.  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.
     *   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.
Thanks,

--

JG

[cid:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]> on behalf of Joseph Yee <[e-mail]>
Date: Tuesday, September 24, 2019 at 3:09 PM
To: regext <[e-mail]>
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