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

From: Otmar Lendl <[email-masked]>
Date: Thu, 10 Feb 2011 12:52:25 +0100

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.

>    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.
----

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.
---

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.
---

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.
---

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?

---
   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."

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

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?

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.

* 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?

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.

---
  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.

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

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

I hope this helps.

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: Sumanth Channabasappa <[email-masked]>
Date: Thu, 17 Feb 2011 10:12:37 -0700

Thanks, Otmar. While the authors have been preoccupied, they hope to review and respond over the next few days. They did indicate that their current I-D updates (that they plan to submit) do not address your comments. 

- S

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

Here are my comments:

Page 29:

----

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

----------

---

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
---

Page 41
---

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?

---

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."

Page 43
---

Page 45
---

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?

Page 49
---

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

Page 51
---

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

use something like

---

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.

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

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

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