Subject: [drinks] FW: My review of SPPP-03, part 2 (was: Seeking volunteers for the protocol I-D)

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 2 Mar 2011 12:08:03 -0500

-----Original Message-----
From: Cartwright, Ken
Sent: Wednesday, March 02, 2011 12:07 PM
To: Cartwright, Ken; 'Ali, Syed Wasim'; 'Sumanth Channabasappa'; 'Alexander Mayrhofer'; 'David Schwartz'; [email-masked]; Maharishi, Manjul
Cc: [email-masked]'
Subject: RE: [drinks] My review of SPPP-03, part 2 (was: Seeking volunteers for the protocol I-D)

Hi Syed, et. al.

I've incorporated updates designed to address many of the comments from Otmar.  The document is attached.  The changes I made are as follows:

1) Re-ordered the "operations" sections.
2) Broke out the Public Identifier add and get operations into two separate sections to get it in line with the other operation sections.  Syed, I know you own this section, but I think you will be ok with this change.
3) Removed the optional IP addresses element from the NSType.  They are not really necessary.  And Otmar makes the valid point that it may not even be appropriate to have them in there.
4) Updated the Delete Operation section to define the data integrity rules that apply to each object type.  Syed, I know you own this section but I think you will be ok with this addition.  We had planned to have this in that section some time ago, but I think it got lost in the shuffle of to-dos.
5) Updated the Security Considerations section to discuss the question of Authorization that we've decided to leave as a matter of policy.  I at least identified the authorization rules that any SPPP implementation would be required to define and implement and stated explicitly that they are a matter of policy.
6) Made several word-smithing changes to the Public Identifier section and the Delete operation sections.  Syed, I hope you are ok with this.

Syed, as I was looking at the Public Identifier sections and the Delete operation sections I did not see the clear statement about how each Public Identifier object is uniquely identified.  These statements exist for each of the other object types.  I think that needs to be added.

Ken

I'm handling the token over to Syed now.

-----Original Message-----
From: Cartwright, Ken
Sent: Thursday, February 24, 2011 9:51 AM
To: 'Ali, Syed Wasim'; Sumanth Channabasappa; 'Alexander Mayrhofer'; David Schwartz; [email-masked]; Maharishi, Manjul
Cc: [email-masked]
Subject: RE: [drinks] My review of SPPP-03, part 2 (was: Seeking volunteers for the protocol I-D)

To add to Syed's review of Otmar's comments, here are mine, prefixed with "KJC".

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Otmar Lendl
Sent: Thursday, February 10, 2011 6:52 AM
To: [email-masked]
Subject: [drinks] My review of SPPP-03, part 2 (was: Seeking volunteers for the protocol I-D)

On 10.12.2010 10:31, Otmar Lendl wrote:
> On 03.11.2010 00:36, Sumanth Channabasappa wrote:
>>
>> Given this, we would like to request expert reviewers who can help the WG make progress on this I-D.
>
> .... to be continued.

I finally managed to read through the rest of the document.

Here are my comments:

Fist of all, the ordering in chapter 6 is messed up.

KJC:  I think if we were to improve the ordering it should be this, which differs somewhat from what Otmar is proposing, but I think achieves the general goal he implies.

      6.3.  Add Destination Group Operation  . . . . . . . . . . . . . 32
      6.4.  Get Destination Groups Operation . . . . . . . . . . . . . 33
      6.9.  Public Identifier Operations . . . . . . . . . . . . . . . 40
      6.1.  Add Route Group Operation  . . . . . . . . . . . . . . . . 27
      6.2.  Get Route Groups Operation . . . . . . . . . . . . . . . . 31
      6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 47
      6.12. Get Route Records Operation  . . . . . . . . . . . . . . . 52
      6.5.  Add Route Group Offer Operation  . . . . . . . . . . . . . 34
      6.6.  Accept Route Group Offer Operation . . . . . . . . . . . . 36
      6.7.  Reject Route Group Offer Operation . . . . . . . . . . . . 37
      6.8.  Get Route Group Offers Operation . . . . . . . . . . . . . 38
      6.10. Egress Route Operations  . . . . . . . . . . . . . . . . . 45
      6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . . 53

>    6.  Protocol Commands  . . . . . . . . . . . . . . . . . . . . . . 27
>      6.1.  Add Route Group Operation  . . . . . . . . . . . . . . . . 27
>      6.2.  Get Route Groups Operation . . . . . . . . . . . . . . . . 31
>      6.3.  Add Destination Group Operation  . . . . . . . . . . . . . 32
>      6.4.  Get Destination Groups Operation . . . . . . . . . . . . . 33
>      6.5.  Add Route Group Offer Operation  . . . . . . . . . . . . . 34
>      6.6.  Accept Route Group Offer Operation . . . . . . . . . . . . 36
>      6.7.  Reject Route Group Offer Operation . . . . . . . . . . . . 37
>      6.8.  Get Route Group Offers Operation . . . . . . . . . . . . . 38
>      6.9.  Public Identifier Operations . . . . . . . . . . . . . . . 40
>      6.10. Egress Route Operations  . . . . . . . . . . . . . . . . . 45
>      6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 47
>      6.12. Get Route Records Operation  . . . . . . . . . . . . . . . 52
>      6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . . 53

I'd go for:

>      6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . . 53
>      6.3.  Add Destination Group Operation  . . . . . . . . . . . . . 32
>      6.4.  Get Destination Groups Operation . . . . . . . . . . . . . 33
>      6.9.  Public Identifier Operations . . . . . . . . . . . . . . . 40
>      6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 47
>      6.12. Get Route Records Operation  . . . . . . . . . . . . . . . 52
>      6.5.  Add Route Group Offer Operation  . . . . . . . . . . . . . 34
>      6.1.  Add Route Group Operation  . . . . . . . . . . . . . . . . 27
>      6.2.  Get Route Groups Operation . . . . . . . . . . . . . . . . 31
>      6.6.  Accept Route Group Offer Operation . . . . . . . . . . . . 36
>      6.7.  Reject Route Group Offer Operation . . . . . . . . . . . . 37
>      6.8.  Get Route Group Offers Operation . . . . . . . . . . . . . 38
>      6.10. Egress Route Operations  . . . . . . . . . . . . . . . . . 45

(or the order used in the example section 7)

Page 29:

----
   o    peeringOrg: Set of zero or more peering organization IDs that
        have accepted an offer to receive this Route Group's
        information.
----

KJC:  The protocol provides the ability to get the list of peering orgs that a RouteGrp has been offered to by using the GetRteGrpOffers operation.

Would there be a point in also offering the list of peering orgs that you
have offered the route-group to?

----------

A more general question regarding all Add* requests:

---
   The AddDestGrpRqstType operation creates or overwrites a Destination
   Group object.  If a Destination Group with the given name and
   registrant ID (which together comprise the unique key for a
   Destination Group) does not exist, then the server MUST create the
   Destination Group.
---

KJC:  As you've stated, the constructs for SPPP implementations to impose authorization logic are in the SPPP protocol.  However, we intentionally left out the statements that define what that authorization logic must be.  If it is not ok to leave the authorization logic as a matter of policy then we would need to add that into the doc.  And the phrase "...querying registrar has the authority to view." shows up in the description of *all* of the "get" operations, at least it is supposed to (and if it does not we should fix that).

What does SPPP say about the write permissions in the registry? The the EPP
world, registrars can only modify/delete objects that they themselves have
created. The only exception is the domain transfer operation.

While the BasicObjType guarantees that the registry keeps track of who
generated what, I'm a bit at loss on where that information is relevant.

As I read the SPPP document, all registrars can enter data for all
registrants. There is no protection against malicious registrars changing
object submitted by another registrar. This, of course, makes the
"registrant A is now handled by registrar B instead of C" operation
unnecessary.

The phrase "...querying registrar has the authority to view." shows up a
few times, but I find nothing on visibility rules or permissions to change
objects.

Page 40
---
   SPPP identifies three types of Public Identifiers: telephone number
   (TN), email address, and the routing number (RN).  SPPP provides
   structures to manage a single TN, a contiguous range of TNs, and a TN
   prefix.
---

KJC:  Right.  This needs to be removed.

Please get rid of "email address". Use SIP URIs as examples.

Page 41
---
             If there is a conflict and a Public Identifier already
   exists in the Registry, the old entry will be replaced with the newly
   provisioned entry.  For the add or update operation, the destination
   group name is a mandatory parameter.  Not including a valid
   destination group name in the update request will cause the Registry
   to return an appropriate error.
---

==========
KJC:  I think the above text, that speaks to doing a replace of objects that already exist with the same unique key, needs to be made the same as the text we use in all the other operation descriptions to make the same point.  So it should use the following text imo:

" The AddPubIdRqstType operation creates or overwrites a PubIdType
   object.  If a Public Identifier with the given name and registrant ID
   (which together comprise the unique key or a Public Identifier) does not
   exist, then the server MUST create the Public Identifier.  If a Public Identifier
   with the given name and registrant ID does exist, then the server
   MUST replace the current properties of the Public Identifier with the
   properties passed into the AddPubIdRqstType operation."
==============
This basically implies some sort of database integrity check (i.e. a
foreign key) on Add. This is good.

But: what about deletes? Can I remove an object that is referenced by some
other object? What if the referencing object is owned by another registrar?

Will the delete be rejected?
Will the delete cascade?
Will the system allow for inconsistencies in such a case?

========
KJC:  The statements that describe how an ESPP server can/should maintain data integrity between related objects is intentionally not defined in the document.  This was left up to an implementation decision.  It is assumed that an SPPP implementer would understand that that needs to be done.  As far as deleting object that other registrars have registered, no this is not possible in a good SPPP implementation.
========

---
   o    corInfo: corInfo is an optional parameter of type CORInfoType
        that allows the registrant organization to set forth a claim to
        be the carrier-of-record [see RFC 5067].
---

Does SPPP allow for any filtering on received routes based on the CORInfo
data? e.g.: "Please return only then Routes for a query if the TN is tagged
as COR in the matching DestGrp."

KJC:  Not sure if this is talking about filtering at resolution time or via a provisioning query.

Page 43
---
   o    prefix: Optional attribute, when set to "true", indicates that
        the Open Number Plan applies to a given TN Range
---

As mentioned before: Range and ONPs don't mix.

See also http://www.ietf.org/mail-archive/web/drinks/current/msg00803.html

KJC:  Syed would be best to speak to this.

Page 45
---
6.10.  Egress Route Operations
---

WHY?

I can't remember whether I wrote about this before, but there is absolutely
no need to bother the registry with this.

This is something you might tell your resolution service. Egress routes are
only relevant to one registrant, so why put it in a shared database?

KJC:  This is a requirement in the Use Case document.  The shared DB is where the peer's ingress routes are located and Egress routes are related to ingress routes.

Page 49
---
                       The NSType object is comprised of the data
   elements necessary for a Name Server that points to another DNS
   server that contains the desired routing information.
---

I'm missing here two things:

* It's completely unstated that one should use ENUM to query the
nameservers returned here. Please make that explicit.

KJC:  Ok,  that guidance can be added.

* It might be helpful to also include the ENUM Apex to be used. "e164.arpa"
is fine as the default, but why not add the option here to use something else?

KJC:  Not clear why specifying the ENUM Apex is necessary or good in this document.  Can you explain further?

Page 51
---
        <element name="type" type="spppb:IPType"/>
---

Wouldn't that be cleaner as an attribute and not a element?

i.e. instead of
  <ipAddr>
    <addr>1.2.3.4</addr>
    <type>IPv4<7type>
  </ipAddr>

use something like

  <ipAddr type="IPv4">1.2.3.4</ipAddr>

Yes, this is purely cosmetic.

KJC:  Understand your point, but across the whole SPPP XSD properties of objects are housed in elements rather than mixing them across attributes and elements.  I'd prefer to not make this an un-necessary exception to that general approach.  But I do agree that moving the "type" element before the "addr" element would be better.

---
  The NSType object is composed of the following elements:

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

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

I don't like this. Either you give just the FQDN and let the DNS resolve
the rest, or just return the IP-Addresses. Doing both will lead to
inconsistencies with the real world DNS, generating confusion and debugging
hell.

KJC:  The optional IP Addresses are there as optional glue, to avoid the need to again resolve for the IP addresses.  But we can remove them if that is deemed un-necessary.

On a more general level regarding route entries, I'm still waiting for
feedback on my proposal from
http://www.ietf.org/mail-archive/web/drinks/current/msg00766.html .

Page 62

junk 7.8

KJC:  Syed would be best to speak to this.

-------------

I hope this helps.

otmar
--
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //
_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.