Subject: Re: [drinks] Some comments/nits on latest SPProv doc

From: "Bhatia, Vikas" <[email-masked]>
Date: Fri, 30 Dec 2011 14:43:36 -0500

Please note the responses below prefixed with my initials.

Other than the couple of nits, most of the these comments apply historically to the earlier versions of the spprov document.
I am giving a shot at answering all comments below. Others from the design team,  please review from a historical perspective (especially the ones suffixed with "Design Team?") and provide comments.

Thanks,
Vikas

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Schwartz
Sent: Thursday, November 17, 2011 10:22 AM
To: [email-masked]
Subject: [drinks] Some comments/nits on latest SPProv doc

Hi guys

I reviewed the SPProv doc and have a few comments.

I will start with the little nits...

* Throughout the doc there is reference to "Modify" operation when in reality it does not exist (only ADD/DEL/GET/ACCEPT/REJECT)
* Page 12 -  An an organization...[VB:] Ok, needs to be fixed in next rev.
* Page 30 - missing SourceIdentRegex in the schema of SourceIdentType[VB:]  Seems a valid comment.  There is  a "sourceIdentLabel" in the actual schema and then there is a "sourceIdentRegex" in the  description. Design Team?
* Page 38 - egrRte missing from arc diagram on page 10[VB:]  Ok, can be added. May be the diagram was intended to be an overview. Will add in next rev.
* 5.2.1 - the enumeration value --> not vaue[VB:]  Ok, will correct the typo with next rev.
* 5.2.2 - Is this a contradiction? --> ObjKeyType MUST contain the following attribute . . . DG . . . This is an optional attribute.[VB:]  No, not a contradiction. This is a typo again. Should be "PubIdKeyType" instead of "ObjKeyType". Will correct in next rev.
* 7.6 - double "." at end of sentence[VB:]  Ok, will correct in next rev.

Moving on to comments...

4.3 -> why isn't this a MUST?
[VB:] My understanding on this is that this is more of a performance optimization aspects for large datasets or constant small updates. Hence, it seems appropriate to be a SHOULD and not MUST.

4.8 -> why isn't this a MUST?
[VB:] This could be a MUST imo. Design Team?

And some questions/opinions...

Destination Groups
6.1 -> I think that DG should have priority field as well. This allows to differentiate based on a a parameter other than route (e.g. cost)
[VB:] Can you please elaborate on this a bit more on what is the scenario? I thought the "priority" attribute on the RG determines the route to be used in situations where same DG is associated with multiple RGs.

Page 40 - When DG removed - it says PIs removed -> not references by PIs (see next comment about PIs)

PIs
Page 23 - why is a PI associated with only 1 DG? why not more? What if I have some TNRange and I want to have both "gold" and "silver" routes associated with it - how would I do this without having this TNR referencing more than one DG?
[VB:] A PIs association with its DG forms its primary key. There is a "priority" attribute in the RG definition. For "gold" and "silver" routes, same TNRange would be  created in two DGs with one of the DG associated to the "gold" route (with a higher priority) and other to the "silver" route (with a lower priority value).

6.2 -> what happened to the URI type? Why can't an identifier be a URI (e.g. AOR)? Why can't my gmail address be the lookup identity without requiring "gmail.com<http://gmail.com>" to me anything more than an opaque string.
[VB:] An identifier could be an email address. It seems there should be a Pub Id type than can take in something like an email address. I am not sure of the historical perspective on why this is not there. Design Team?

Page 24 -> isn't the idea of a RouteGroup to "group" route records"? Why then in the definition of a TN do we refer to an rrRef instead of an rgRef? The description does say "one or more" rrRefs which would imply to me that this could be a rgRef
[VB:] Sorry, but two parts of this comment seem unrelated.  Yes, the idea of RG is to associate a set of Pub Ids (DG) that share a common routing information, to the set of Route Records that form that routing information.  TN association to RG is via the DG. TN also refers to rrRef for situations where the routing information may be unique to a particular TN. We need to correct the description however to say "zero or more" and not "one or more". May be that caused the confusion.

Page 25 - why is RNType associated with DG and not RG or RR? what is logic of grouping RN's? I would assume that RN's have a closer relationship to RGs than DGs
Why isn't corinfo part of the base PI type
[VB:] RNs are grouped into a DG for situations where many RNs share the same routing information. On the corInfo element, as it currently stands, corInfo could be part of the base type.  I had that thought myself when making the last set of updates. May be the idea was that there could be other Pub Id types where "corinfo" does not apply (like an email address per your earlier comment). Design Team?

SourceID
Page 30 - Why not simply a URI instead of enumeration as regex can deal with parts of URI. We all know that in the end the source information will be represented in the DNS request using a URI.
[VB:] Source information match can be done via the IP where the request is coming from (which may not be in the URI), root domain or the URI itself. In that sense having source identity scheme as one of "uri", "ipaddress", or "rootDomain" seems valid. Can you elaborate further? Design Team?

Page 38 - why isn't egrRte associated with RG?
[VB:] It probably was just a design decision. Having egrRte associated with a RG would mean that egrRte definition would also need to have an optional "svcs" element to defines the type of ENUM service(s) supported by the route. For situations where many ingress routes share the same egress route, right now there will be an association between egress route object and all RRs  that are part of the RG. Design Team?

Page 38 - why not associated with RteRecType instead of obj?
[VB:] The association egrRte with RteRec object is using the RteRec's key which is common element "ObjKeyType" (even before the latest changes). That is why this association.

:D

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