Subject: [drinks] Updates to the public identity definition as the input ...

From: "Ali, Syed Wasim" <[email-masked]>
Date: Fri, 2 Apr 2010 11:45:04 -0400

Hi,
 
In our last discussion in Anaheim, one assigned task was to attempt to
re-work the generic public identity definition so that it is closer to the
data model. Attached files capture the results. Please, see the ...diff.html
file for difference between the last version (-02d) and the new (-02e)
schema. Along the way, I made a few other edits that I will try to briefly
go over below:

 * Public Identity is now an abstract type. It helps the provisioning server
to know what type of public identity is being provisioned. This makes it
easy to decipher b/w the TN and RN (US specific use case). Further, the TN
Range is simply an extension of TN with the only added attribute ³size² to
help identify the last TN in the range. All in all, TNType, RNType,
EmailType, and TNRType are the new concrete types that extend the abstract
PubIdType. 
 * In BasicObjType, ³activDate² has been renamed to ³effDate². While
³activDate² is meaning for Add operation, IMO, it is counter-intuitive for
the del operation. Further, OdelDate¹ element has been removed since
OeffDate¹ serves the same purpose.
 * With the Public Identity change above, the ³addTNRsRqst² and other
del/get operations are redundant at best and can safely be removed.
 * There is no use case for the TXT RR just yet, so we can remove its
definition from the schema for now.
 
Thoughts?
 
thanks,
 
-Syed Wasim

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 7 Apr 2010 14:32:02 -0400

Hi Syed,

Thanks for making this proposal.  My comments are as follows:

1) As indicated in Anaheim, I very much like this approach to abstracting the concept of what a Public Identity Type is.  It simplifies the interface nicely.
2) As indicated in my comments on the use cases, I think we need to do one of the following things with respect to the activeDate/effDate concept use cases, and then make the changes to the XSD that result.  I vote for (a), but can live with (b) assuming that the scope is narrow enough.
        a) Eliminate the requirement altogether.
        b) Dramatically reduce the scope of the use cases that suggests its necessity.
        c) imo, leaving the activeDate/effDate use cases and scope as they stand today is not a viable option.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali, Syed Wasim
Sent: Friday, April 02, 2010 11:45 AM
To: [email-masked]
Subject: [drinks] Updates to the public identity definition as the input ...

Hi,

Thoughts?

thanks,

-Syed Wasim

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.

---

From: Sumanth Channabasappa <[email-masked]>
Date: Wed, 7 Apr 2010 12:34:31 -0600

I thought we agreed to remove the effective date/time use case since no one had objections in Anaheim, no?

- S 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Kenneth
Sent: Wednesday, April 07, 2010 12:32 PM
To: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] Updates to the public identity definition as the input ...

Hi Syed,

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali, Syed Wasim
Sent: Friday, April 02, 2010 11:45 AM
To: [email-masked]
Subject: [drinks] Updates to the public identity definition as the input ...

Hi,

In our last discussion in Anaheim, one assigned task was to attempt to re-work the generic public identity definition so that it is closer to the data model. Attached files capture the results. Please, see the ...diff.html file for difference between the last version (-02d) and the new (-02e) schema. Along the way, I made a few other edits that I will try to briefly go over below:

 * Public Identity is now an abstract type. It helps the provisioning server to know what type of public identity is being provisioned. This makes it easy to decipher b/w the TN and RN (US specific use case). Further, the TN Range is simply an extension of TN with the only added attribute ³size² to help identify the last TN in the range. All in all, TNType, RNType, EmailType, and TNRType are the new concrete types that extend the abstract PubIdType.
 * In BasicObjType, ³activDate² has been renamed to ³effDate². While ³activDate² is meaning for Add operation, IMO, it is counter-intuitive for the del operation. Further, OdelDate¹ element has been removed since OeffDate¹ serves the same purpose.
 * With the Public Identity change above, the ³addTNRsRqst² and other del/get operations are redundant at best and can safely be removed.
 * There is no use case for the TXT RR just yet, so we can remove its definition from the schema for now.

Thoughts?

thanks,

-Syed Wasim

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.

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

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 7 Apr 2010 15:40:09 -0400

Right.

-----Original Message-----
From: Sumanth Channabasappa [mailto:[email-masked]]
Sent: Wednesday, April 07, 2010 2:35 PM
To: Cartwright, Kenneth; Ali, Syed Wasim; [email-masked]
Subject: RE: [drinks] Updates to the public identity definition as the input ...

- S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Kenneth
Sent: Wednesday, April 07, 2010 12:32 PM
To: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] Updates to the public identity definition as the input ...

Hi Syed,

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali, Syed Wasim
Sent: Friday, April 02, 2010 11:45 AM
To: [email-masked]
Subject: [drinks] Updates to the public identity definition as the input ...

Hi,

Thoughts?

thanks,

-Syed Wasim

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Thu, 8 Apr 2010 08:38:41 -0400

Ken,

We are in agreement. Choice (a) would be desirable but we do have situations
where future activations are in use. And in line with choice (b) "effDate"
is optional. Choice 'c' has been executed.

thanks,
-Syed

On 4/7/10 2:32 PM, "Cartwright, Kenneth" <[email-masked]> wrote:

> 1) As indicated in Anaheim, I very much like this approach to abstracting the
> concept of what a Public Identity Type is.  It simplifies the interface
> nicely.
> 2) As indicated in my comments on the use cases, I think we need to do one of
> the following things with respect to the activeDate/effDate concept use cases,
> and then make the changes to the XSD that result.  I vote for (a), but can
> live with (b) assuming that the scope is narrow enough.
> are not the intended recipient, please contact the sender by reply e-mail and
> destroy all copies of the original message.
>

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 8 Apr 2010 09:37:09 -0400

Ok.  That's reasonable.  So I think the actions we need to take are: (1) tighten up the use cases to precisely specify where the concept of effective date is necessary.  As described in previous comments, the current use cases are completely open ended and confused on the matter of effective date and related concepts, and (2) based on those use cases decide were in the XML data structures where effective date should reside because the BaseObJType may not be the best place.

Ken

-----Original Message-----
From: Ali, Syed Wasim [mailto:[email-masked]]
Sent: Thursday, April 08, 2010 8:39 AM
To: Cartwright, Kenneth; [email-masked]
Subject: Re: Updates to the public identity definition as the input ...

Ken,

thanks,
-Syed

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 15 Apr 2010 10:02:01 -0400

Hi Syed,

One additional comment to consider on the changes to the XSD is:

The "RDType" "complex abstract base type" has been introduced just for the purpose of holding the TTL attribute.  I'd prefer that we simplify this approach a tad and define "simple element type".  As in something like this:

        <simpleType name="TTLType">
                <restriction base="positiveInteger"/>
        </simpleType>

Then each RteRecType that needs a TTL would just declare an element of type TTLType.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cartwright, Kenneth
Sent: Wednesday, April 07, 2010 2:32 PM
To: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] Updates to the public identity definition as the input ...

Hi Syed,

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali, Syed Wasim
Sent: Friday, April 02, 2010 11:45 AM
To: [email-masked]
Subject: [drinks] Updates to the public identity definition as the input ...

Hi,

Thoughts?

thanks,

-Syed Wasim

---

From: "Ali, Syed Wasim" <[email-masked]>
Date: Thu, 22 Apr 2010 02:20:57 -0400

Ken,

Thanks for the feedback.

RDType was added to limit the use of "ttl" to the resource records. In doing
so, all resource records that extend RDType automatically inherit this
attribute. This approach closely follows the DNS message encoding format.

<simpleType name="TTLType"> will do the job as well. In this case,

<element name="ttl" type="spppb:TTLType" minOccurs="0"/>

has to be explicitly added to each resource record type. Also, in my
opinion, since "ttl" is a special purpose attribute with limited use in only
resource records, I like the constrained definition within RDType and not a
simpleType entry in the global schema space.

thoughts?

-Syed

On 4/15/10 10:02 AM, "Cartwright, Kenneth" <[email-masked]> wrote:

> The "RDType" "complex abstract base type" has been introduced just for the
> purpose of holding the TTL attribute.  I'd prefer that we simplify this
> approach a tad and define "simple element type".  As in something like this:
>

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 22 Apr 2010 09:46:02 -0400

Hi Syed,

Your points are of course valid.  This may come down to style, but I prefer to keep the inheritance hierarchy simpler, when the choice to add in another level to the inheritance hierarchy is not clear.  In this case we already have the RRType base type and now we are adding in another base type just below that, but above the concrete types, just to hold a single attribute (and not for polymorphism).  And now that the attribute is optional, out of necessity, we are introducing an additional level of inheritance hierarchy just for an *optional* attribute, which some installations are likely to not even use.  It seems overkill to me.

I think I'm also reacting a bit to the fact that the provisioning protocol is becoming more and more closely tied to DNS RRs, which I do not see as a good thing.  So, again, adding in an additional level of inheritance hierarchy, just for an optional data element, that will often not even be used, that ties us even more tightly to DNS, does not seem optimal to me.  There seems to be no practical gain, but clear new complexity in the XSD.

That's the way I see it anyway.

Thanks for considering this.
Ken

-----Original Message-----
From: Ali, Syed Wasim [mailto:[email-masked]]
Sent: Thursday, April 22, 2010 2:21 AM
To: Cartwright, Kenneth; [email-masked]
Subject: Re: [drinks] Updates to the public identity definition as the input ...

Ken,

Thanks for the feedback.

thoughts?

-Syed