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

From: Joseph Yee <[email-masked]>
Date: Mon, 21 Oct 2019 14:43:10 -0400

JIm and all,

Sorry for my late reply.  I reviewed the latest version and it looks good.
I had updated the writeup.  Thanks.

Best,
Joseph

On Mon, Sep 30, 2019 at 5:47 PM Gould, James <[email-masked]> wrote:

> Joseph,
>
>
>
> I went ahead and posted draft-ietf-regext-login-security-04 with the
> updates based on your review feedback.  Let me know if you find any other
> issues.
>
>
>
> Thanks,
>
>
>
> --
>
>
>
> JG
>
>
>
>
> *James Gould *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *James Gould <[email-masked]>
> *Date: *Wednesday, September 25, 2019 at 5:16 PM
> *To: *Joseph Yee <[email-masked]>
> *Cc: *regext <[email-masked]>
> *Subject: *Re: [EXTERNAL] Re: [regext] Document Shepherd Write Up of
> Login-Security
>
>
>
> Joseph,
>
>
>
> See my feedback below.
>
>
>
> --
>
>
>
> JG
>
>
>
>
> *James Gould *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *Joseph Yee <[email-masked]>
> *Date: *Wednesday, September 25, 2019 at 4:31 PM
> *To: *James Gould <[email-masked]>
> *Cc: *regext <[email-masked]>
> *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 <[email-masked]> 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
>
>
>
>
> *James Gould *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *regext <[email-masked]> on behalf of Joseph Yee <
> [email-masked]>
> *Date: *Tuesday, September 24, 2019 at 3:09 PM
> *To: *regext <[email-masked]>
> *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
>
>
>
>