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 <jgo...@verisign.com> 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 > > > [image: 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: *James Gould <jgo...@verisign.com> > *Date: *Wednesday, September 25, 2019 at 5:16 PM > *To: *Joseph Yee <j...@afilias.info> > *Cc: *regext <regext@ietf.org> > *Subject: *Re: [EXTERNAL] Re: [regext] Document Shepherd Write Up of > Login-Security > > > > Joseph, > > > > See my feedback below. > > > > -- > > > > JG > > > [image: 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: *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> 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 > > > [image: 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> on behalf of Joseph Yee < > j...@afilias.info> > *Date: *Tuesday, September 24, 2019 at 3:09 PM > *To: *regext <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
