[drinks] WGLC comments from Andrew Sullivan on draft-ietf-drinks-spp-framework-02

[Alexander Mayrhofer <[e-mail]>]

Andrew has sent these comments privately to me - i'm forwarding these to the list - see below..

Alex

-----Ursprüngliche Nachricht-----
Von: [e-mail] [mailto:[e-mail]] 
Gesendet: Donnerstag, 20. September 2012 18:39
An: Alexander Mayrhofer
Betreff: spp-framework (was: Ping :-))

Hi,

I'm not going to subscribe to the DRINKS list to do this review (sorry), so I'll send it to you to forward appropriately.

I have reviewed draft-ietf-drinks-spp-framework-02.  I have some comments.  I haven't included nits I discovered; I'm relying on the RFC Editor for that.  I also did not check the XML examples at all.  I trust someone has been through those carefully.

Section 3.2:  I don't understand this section at all.  The draft says that unqualified local time is discouraged, then says you MUST use UTC, then says that perfectly valid UTC time formats are not allowed.
Why not just state how time is permitted to be expressed, period?

Section 4.6: 

   In some deployments, the SPPF objects that an SPPF registry manages
   can be private in nature.  As a result it MAY NOT be appropriate to
   for transmission in plain text over a connection to the SPPF

That "MAY NOT" is wrong.  It's not actually a 2119 key word, which means "you're not allowed to do this".

Section 5.1: "OrgIdType instances SHOULD follow".  Ok, what if they don't?  That seems like a potential serious interop problem to me.

Section 5.2: 
   
   "Name" attributes that are used as components of object key types
   MUST be treated case insensitive.

Section 8 says that input may be in UTF-8, and section 10 says you can use any language you like.  What is the case-insensitive treatment of the string "Ecole Polytechnique"?  Because where I come from, the lower case is "école polytechnique", but that's not what Unicode case fold does.  This requirement in 5.2 needs a _lot_ more detail.  One thing you could do is what IDNA did, and say that any character that is not stable under caseFold(caseFold(NFKC(cp))) is not acceptable for use in a Name attribute where used as a component of object key types.  That's gonna be some work, though.  Section 12 didn't seem to tell me more about what I wanted to know, but if I overlooked it a forward reference in the doc would be enough.

Section 5.3:

I find it pretty strange that the message types are not actually part of the framework.  One of them is particularly strange: "Version not supported".  Leaving that to the protocol definition feels wrong, because a client with an old version of the protocol might not be able to understand the new server's response.

Also, why are these SHOULDs:

   o    Response type "Attribute value invalid" SHOULD be used whenever
        an element value does not adhere to data validation rules.

   o    Response types "Attribute value invalid" and "Object does not
        exist" MUST NOT be used interchangeably.  Response type "Object
        does not exist" SHOULD be returned by an Add/Del/Accept/Reject
        operation when the data element(s) used to uniquely identify a
        pre-existing object do not exist.  If the data elements used to
        uniquely identify an object are malformed, then response type
        "Attribute value invalid" SHOULD be returned.
?

Section 6.4:

   o    hostName: Fully qualified host name of the name server.

Really fully-qualified, or root-relative qualified?  (Lots of specs get this wrong, and it's my new crusade.)  That is, is hostName "ns1.example.com" or "ns1.example.com."?

   o    ipAddr: Zero or more objects of type IpAddrType.  Each object
        holds an IP Address and the IP Address type, IPv4 or IP v6.

Why is the IP address needed?  Shouldn't you just look the name up in the DNS?

Section 7.2: This section appears in effect to cause any deletion to cascade, so that if an object is deleted all references to it get deleted.  Doesn't this have the potential for a denial of service?  (I genuinely don't know -- I think I don't understand enough about the relationships among various actors to understand whether they can have
cross-dependencies.)  

--
Andrew Sullivan
Dyn Labs
[e-mail]