Subject: Re: [drinks] DRAFT minutes of the most recent DRINKS design team call

From: David Schwartz <[email-masked]>
Date: Wed, 6 Jun 2012 11:25:30 +0300

As per our previous discussion, I started the renaming process of Route - SED and as I am re-reading the entire doc I have to questions/clarifications for the group.

1.) There are some naming inconsistencies, specifically as they relate to the two URI types:

    * NAPTRType, NSType and URIRteRecType
    * TNType, RNType, TNRType, TNPType and URIPubIdType

I understand the need for disambiguating the two URI types but this leads to lack of consistency with class members. What is wrong with always including the "abstract" parent in the name?

    * NAPTRSedRecType, NSSedRecType and URISedRecType
    * TNPubIdType, RNPubIdType, TNRPubIdType, TNPPubIdType and URIPubIdType

2.) RNType definition is as follows:

"A routing number is provisioned using the RNType, an extension of PubIDType. SSPs that possess the number portability data may be able to leverage the RN search key to discover the ingress routes for session establishment. Therefore, the registrant organization can add the RN and associate it with the appropriate destination group to share the route information.  Each RNType object is uniquely identified by the combination of its value inside the <rn> element, and the unique key of its parent Destination Group (dgName and rantId). In other words a given routing number string may exist within one or more destination Groups, but must not exist more than once within a Destination Group.

My specific question relates to this snippet...

Therefore, the registrant organization can add the RN and associate it with the appropriate destination group to share the route information.

The Public Identifiers represent the "subjects" or "keys" that are used to lookup the "attributes" or "values" specified as session establishment data. It is SED that is shared - not identifiers. In fact, isn't RN type information similar enough to LUF (i.e. "need another mechanism or lookup to find the actual LRF data") to be another SEDRecordType? We have NAPTRType, NSType and URIType. Should we have RNType as well as a child of SEDRecType? We already have a 1-1 association of a TNType to a SEDRecType so a number that is ported would be represented by a TNType and an associated SED record RNType. One could then take the RNType (which looks just like a TN anyway) and perform an LRF query on this to find the actual relevant ingress point.

Does any of this make sense?

Thoughts?

:D

---

From: "Bhatia, Vikas" <[email-masked]>
Date: Tue, 12 Jun 2012 17:33:29 -0400

For my action item on Egress Route - below is the schema element definition that we already discussed (and my proposed text) for the egress route association to Route Group (a.k.a SED Group..nomenclature change not included in my text..)

   <complexType name="EgrRteType">
     <complexContent>
           <extension base="sppfb:BasicObjType">
             <sequence>
                   <element name="egrRteName" type="sppfb:ObjNameType"/>
                   <element name="pref" type="unsignedShort"/>
                   <element name="regxRewriteRule"
                     type="sppfb:RegexParamType"/>
                   <element name="ingrRteGrp" type="sppfb:ObjKeyType"
                      minOccurs="0" maxOccurs="unbounded"/>
                   <element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
                   <element name="ext" type="sppfb:ExtAnyType"
                     minOccurs="0"/>
             </sequence>
           </extension>
     </complexContent>
   </complexType>

Changes are:

"ingrRteRec" changed to "ingrRteGrp" - Zero or more Route Group(s) to which an Egress Route applies.

 svcs: ENUM service(s) that are served by an Egress Route. This element is used to identify the ingress NAPTRs associated with the Route Group to which an Egress Route's regxRewriteRule should be applied. If no ENUM service(s) are associated with an Egress Route, then the Egress Route's regxRewriteRule should be applied to all the NAPTRs associated with the Route Group. This field's value must be of the form specified in [RFC6116] (e.g., E2U+pstn:sip+sip). The allowable values are a matter of policy and not limited by this protocol.

Thanks,
Vikas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Thursday, May 31, 2012 9:19 AM
To: [email-masked]
Subject: [drinks] DRAFT minutes of the DRINKS design team call on May 30 2012.

DRAFT minutes DRINKS design team call May 30 2012
=================================================

May 30 2012, 10am - 11am eastern

Participants
------------

- Vikas Bhatia
- Manjul Maharishi
- David Schwartz
- Alexander Mayrhofer
- Syed Ali
- Ken Cartwright
- Sumanth Channabasappa

ACTION ITEMS
------------

- continue discussion of open items

Agenda
------

1/ Work on documented open issues

Minutes
-------

Sumanth opens the call - runs through last week notes.

Alex summarizes decisions from last week.

Vikas mentions that the decision whether egress route was to be associated
with rte grp instead of rte rec was pending.

Alex asks whether the design team would be ok with chaing egr rte from
rte rec to rte grp.

Sumanth brings up the respective email from vikas, group is ok with the change,
including the svcs addition (alex mentions that the svcs field semantics
need to be clearly defined). The team agrees to the two changes.

-> Decision: change association of egress route from route record to route
group, add "svcs" field to egress route. Clarify svcs semantics.

Target vs. location (and rte to sed rename): Vikas said they are connected,
david comments he's not sure why.

David explains the Target/Location issue - sees a gap between SPEERMINT
terminology and the DRINKS documents.

Alex notes that an "identification" field in the base rte rec type (optional) would allow people to choose whether or not they want to
use the "split".

Sumanth brings up david's proposal (chart):
http://www.ietf.org/mail-archive/web/drinks/current/msg01152.html

Manjul: are we trying to solve an resolution protocol problem here?
David: no, just trying to add to the provisioning side a way to
differentiate whether the provisioned data is LUF or LRF.

Alex: concerned that people would be forced to categorize..
David: Want to force people to do it, in order to solve interopability nightmares.

Syed: Clarification that it's just *annotation*, there's no effect on the
resolution protocol side.

Ken: please summarize issue in two sentences?

David: Trying to force the SP into removing ambiguity from the provisioned
data. Resolution side is not affected. There's just a little bit of
extra data in the registry.

More discussion around whether that split is useful, and options to convey it
in resolution protocols (such as terminal flag in ENUM).

Discussion whether this is in scope or not - "S" in "drinks" stands for "SIP"?
Sumanth: Thinks we should be ok if that is annotation only.

Ken: Need to think that through, but would it be possible to make "colliding"
annotations, such as a "gspid:" URI scheme with a "Location" type?

Syed: All we're looking is adding an additional element for annotation, in
order to distinguish the types.

Sumanth: Call on Fri?
Group: Let's do Thur - new call tomorrow.

Discussion about whether sub-typing or attribute would be the easier way.
Alex feels that subtyping is pretty strict (Ken agrees), David thinks
being strict can be an advantage. No conclusion here.

Call concludes after an hour, next call on Thu, May 31.
_______________________________________________
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.