Subject: [Netconf] Fwd: Peter Saint-Andre's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT)

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 03 Mar 2011 11:25:46 +0100

FYI and comment

-------- Original Message --------
Subject: 	Peter Saint-Andre's No Objection on draft-ietf-netconf-4741bis-09: (with COMMENT)
Date: 	Wed, 02 Mar 2011 16:20:34 -0800
From: 	Peter Saint-Andre <[email-masked]>
To: 	The IESG <[email-masked]>
CC: 	[email-masked], [email-masked]

Peter Saint-Andre has entered the following ballot position for
draft-ietf-netconf-4741bis-09: 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 http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. DTDs are forbidden (presumably you mean internal or external DTD subsets in accordance with section 2.8 of the XML specification). What about comments, processing instructions, and internal or external entity references?

2. In Section 6.2.5, 'for which the<name>  element is equal to "fred"' is more precisely expressed as 'for which XML character data of the<name>  element is equal to "fred"'. (The same text occurs in Section 6.4.5.)

3. Section 6.4.3 states:

    In a real data model, the<company-info>  would not
    likely be returned with the list of users for a particular host or
    network.

Why not?

4. In Section 7.5, is the server allowed to terminate a lock for reasons other than session closure? If not, it appears than an entity could maintain a lock indefinitely.

5. In Appendix B, it seems that some of the enumerated datatypes could be changed from xs:string to something more restrictive, such as xs:NMTOKEN (e.g., error types, error tags, error severity, edit operation type).

---

From: Kent Watsen <[email-masked]>
Date: Thu, 3 Mar 2011 12:05:05 -0800

> 5. In Appendix B, it seems that some of the enumerated datatypes could be
> changed from xs:string to something more restrictive, such as xs:NMTOKEN
> (e.g., error types, error tags, error severity, edit operation type).

I started doing this to all my XSDs.  I even take it a step further 
By defining a type that cannot be empty, as XSD otherwise allows empty
content.  For instance:

   <xs:simpleType name="non-empty-token">
      <xs:restriction base="xs:token">
         <xs:minLength value="1"/>
      </xs:restriction>
   </xs:simpleType>

Thanks,
Kent

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf