Subject: Re: [drinks] REMINDER: IETF DRINKS proto call (Thu, Feb 24th; 10:00a-11:00a ET)

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 22 Mar 2011 09:30:46 -0400

Hi Syed,

After considering your point about the possibility that having rarId in the protocol might be un-necessary, I think you are right.  It can be left up to the SPPP server implementations to internally track the registrar that created each object.  So it is not strictly necessary to have it in the protocol.  And taking it out will be easy.

Ken

-----Original Message-----
From: Ali, Syed Wasim [mailto:[email-masked]]
Sent: Thursday, March 17, 2011 1:01 PM
To: Cartwright, Ken
Subject: Re: REMINDER: IETF DRINKS proto call (Thu, Feb 24th; 10:00a-11:00a ET)

Thanks for the quick response. I will look into this more later later this
evening as I have a few fights lined up for this afternoon. Though a few
thoughts are inline.

On 3/17/11 9:48 AM, "Cartwright, Ken" <[email-masked]> wrote:

>Hi Syed,
>
>1) All objects extend BasicObjType, including PIs.  So the fact that PIs
>extend BasicObjType does not make them different from the other object
>types.  So, as with other object types, the rarId is not used as part of
>the unique key (you call this the "foreign key") that is used to identify
>a PI.  In the 05 version of the protocol I added into the document how
>each PI is uniquely identified.

[SYED] As long as the "the" unique key suffices for the CRUD operations,
presence of 'rar' won't be an issue. For instance, GetPubIdsRqstType
requires one or more PubIdTypes, which in turn makes 'rar' mandatory.

>2) If the registrar of a set of objects changes, because maybe a
>registrar goes out of business and the registrant wants to move to a new
>registrar, etc, then that would be a bulk administrative activity handled
>by the SPPP registry operator outside of the protocol.  So, imo, no
>statement needs to be made about that, just like no statement is made
>about it in EPP.

Agreed. I am just stuck at the presence of 'rar' in PubId operations. I
will look into it more later tonight and get back to you tomorrow.

>
>3) The question about more than one rar per rant?  What are the important
>implications of that with respect to the protocol and, what's the use
>case for that, and exactly what text do you feel should be added?  Sorry,
>I'm seeing the issue, but maybe I'm missing something.

This will be a good discussion item for the WG session. Here is the get
example from the section 7.13 of the document,

   <spppQueryRequest xmlns="urn:ietf:params:xml:ns:sppp:base:1">
     <rqstObj xsi:type="ns1:GetPubIdsRqstType">
       <pi xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
         xsi:type="ns1:TNType">
         <rant>iana-en:222</rant>
         <rar>iana-en:222</rar>
         <tn>+12025556666</tn>
       </pi>

Say the registrant has a relationship with more than one registrars. If
the intention is to leave it as a policy whether to dilute the access
permissions, or tighten the access where only the provision 'rar' has the
sole authority on PI that it manages on behalf the 'rant', then in this
case 'rar' may present an inter-op challenge.

>
>4) I guess we could possibly remove rar from the protocol, but it would
>certainly be required for any SPPP registry to internally maintain it for
>each object, as any EPP registry does (and, btw EPP registries also end
>up making the rar visible indirectly through WhoIs).

Agreed. The silent has worked well so far. I need to understand what we
gain by the presence of 'rar' "string" identifier.  :-)

>
>Thanks
>
>-----Original Message-----
>From: Ali, Syed Wasim [mailto:[email-masked]]
>Sent: Thursday, March 17, 2011 8:54 AM
>To: Cartwright, Ken
>Subject: Re: REMINDER: IETF DRINKS proto call (Thu, Feb 24th;
>10:00a-11:00a ET)
>
>
>Regarding the first part of your email, the ObjKeyType is the answer to
>how there is no dependency on 'rar'. Though this doesn't apply to PI since
>the PubIdType extends BasicObjType, which in turn requires both rant and
>rar:
>
>  <complexType name="BasicObjType" abstract="true">
>    <sequence>
>      <element name="rant" type="spppb:OrgIdType"/>
>      <element name="rar" type="spppb:OrgIdType"/>
>
>
>As Otmar (I think) pointed out, when the relationship of 'rar' changes
>with 'rant' or when there are more than one 'rar' per 'rant', there are
>consequences that may need to be addressed in the document.
>
>Why do we need the 'rar' to begin with if authz aspect is beyond the scope
>of this protocol?   :-)
>
>Perhaps I should give it some more thought as I could be missing a detail
>or two.
>
>-Syed
>
>On 2/24/11 5:20 PM, "Cartwright, Ken" <[email-masked]> wrote:
>
>>Hi Syed,
>>
>>The objects such as RouteGroup, DestGroup, etc are uniquely identified by
>>their Object Key (ObjKeyType).  This is a composite business key which is
>>comprised of the Registr*ant* ID and the object name.  Registr*ar* ID is
>>not a component of this business key.  If this fact is not clear from the
>>spec then we need to make it clear.  Please see sections 5.3, 6.1, 6.3,
>>6.11, etc.  This includes text in the spec such as this snippet from 6.1
>>"The AddRteGrpRqstType operation creates or overwrites a Route Group
>>object.  If a Route Group with the given name and registrant ID (which
>>together comprise the unique key or a Route Group) does not exist,
>>then..."
>>
>>So I'm not certain what you mean by "...look at the possibility of not
>>including the Registrar information as the foreign key for the
>>provisioning objects in favor of keeping only registrant information".  I
>>think that's already the case.
>>
>>And as far as the possibility of using a known source/namespace,
>>something like IANA's Enterprise Number, as the source/namespace for
>>organization IDs (registrant IDs, and registrar IDs), the spec proposes
>>that idea, in a subtle manner in section 5.3.  Section 5.3 describes the
>>rantId and rarId as organization IDs.  It then refers to an
>>example/possible name space for these organization IDs as "iana-en"
>>(which stands for IANA Enterprise Number), which your examples then use
>>as well.  The spec does not say that the source/namespace for these IDs
>>MUST be the IANA Enterprise Number because it was decided that this would
>>be a matter of policy.
>>
>>I hope this helps.  And given the above, do you still believe that the
>>spec should not make statements about how Authorization should be imposed
>>in a SPPP implementation?
>>
>>Ken
>>
>>
>>-----Original Message-----
>>From: Ali, Syed Wasim [mailto:[email-masked]]
>>Sent: Thursday, February 24, 2011 4:44 PM
>>To: Cartwright, Ken; Sumanth Channabasappa; Maharishi, Manjul
>>Cc: Zhang, Ning
>>Subject: Re: REMINDER: IETF DRINKS proto call (Thu, Feb 24th;
>>10:00a-11:00a ET)
>>
>>
>>Ken,
>>
>>Apologies for not getting back to you sooner, but it was a crazy day
>>today. I will read your comments more carefully and respond later today,
>>though there was the case of the authorization statement which I thought
>>I
>>should bring up sooner than later. In speaking with my partner in crime
>>(Ning) who has designed and implemented the Registry stuff on our end, we
>>would like to explore a way to avoid authz statement inclusion in the
>>SPPP
>>protocol. As an alternative, can we perhaps look at the possibility of
>>not
>>including the Registrar information as the foreign key for the
>>provisioning objects in favor of keeping "only" registrant information.
>>This appears to be a far simpler approach and it will then leave the
>>authz
>>mechanics out of the sppp spec and for the Registry operators to then
>>leverage existing standards for this need. Another option on the table is
>>to use an invariant (like Entr ID in ESPP) to refer to the registrant.
>>This way, in case one registrar falls out of favor and the registrant
>>wants to switch to a different entity, etc., mass updates can be avoided.
>>
>>Let me know what you think. I will try to look into this some more later
>>tonight and, if it helps to get on the phone and chat, depending on your
>>schedule tomorrow, we can do that.
>>
>>Thanks,
>>
>>Syed Wasim Ali: NeuStar  Advanced Services
>>Director & Member of Tech Staff
>>46000 Center Oak Plaza, Sterling, VA 20166
>>[ T ] +1(571)434-5579  [ M ] +1(571)420-0138 [ E ] [email-masked]
>><applewebdata://332C80E9-C4A1-40C5-9E1E-D2EF345C3C65/[email-masked]
>>>
>>________________________________________
>>The information contained in this e-mail message is intended only for the
>>use of the recipient(s) named above and may contain confidential and/or
>>privileged information. If you are not the intended recipient you have
>>received this e-mail message in error and any review, dissemination,
>>distribution, or copying of this message is strictly prohibited. If you
>>have received this communication in error, please notify us immediately
>>and delete the original message.
>>
>>
>>
>>
>>
>>On 2/24/11 11:06 AM, "Cartwright, Ken" <[email-masked]> wrote:
>>
>>>
>>>Hi Syed,
>>>
>>>Please scan through my comments below and see if you have any issues
>>>with
>>>them.  If not I can incorporate them into the document (except for the
>>>one that I say "Syed would be best to address"),  Per our agreement, I
>>>will also include authorization and data integrity statements into the
>>>doc as well.
>>>
>>>Let me know if you want me to take the token first or if you want to.
>>>
>>>Thanks.
>>>
>>>-----Original Message-----
>>>From: Ali, Syed Wasim [mailto:[email-masked]]
>>>Sent: Thursday, February 24, 2011 3:09 AM
>>>To: Sumanth Channabasappa; 'Alexander Mayrhofer'; David Schwartz;
>>>[email-masked]; Cartwright, Ken; Maharishi, Manjul
>>>Cc: [email-masked]
>>>Subject: Re: REMINDER: IETF DRINKS proto call (Thu, Feb 24th;
>>>10:00a-11:00a ET)
>>>
>>>
>>>Hi,
>>>
>>>I went through Otmar's comments from his review of the sppp specs and we
>>>should discuss them at our weekly meeting tomorrow before posting
>>>replies
>>>on the reflector. I am trying to provide a few references below for
>>>starters:
>>>
>>>==============
>>>In,
>>>
>>>http://www.ietf.org/mail-archive/web/drinks/current/msg00848.html
>>>
>>>there is a thought that perhaps ONP indicator is "sufficient" for
>>>TNPType.
>>>When looking at the numbering plans around the globe, there are examples
>>>within contiguous TN ranges where there is a shift in the max national
>>>significant number length. For consistency, I think the ONP indicator
>>>option should be available for TNRType as well. To understand a possible
>>>use of the TNRType, please see the original discussion and the response
>>>from Alex in the following link:
>>>
>>>http://www.ietf.org/mail-archive/web/drinks/current/msg00768.html
>>>
>>>==============
>>>
>>>http://www.ietf.org/mail-archive/web/drinks/current/msg00840.html
>>>
>>>The text in the spec may need to be improved. Otmar doesn't really
>>>suggest
>>>alternative text.
>>>
>>>==============
>>>
>>>http://www.ietf.org/mail-archive/web/drinks/current/msg00832.html
>>>
>>>This thread was never closed. Sohel Khan is asking if we can accommodate
>>>"CNAM" provisioning.
>>>
>>>==============
>>>
>>>Otmar is waiting for a response on the following message:
>>>
>>>http://www.ietf.org/mail-archive/web/drinks/current/msg00766.html
>>>
>>>==============
>>>
>>>More comments and suggestions from Otmar:
>>>
>>>http://www.ietf.org/mail-archive/web/drinks/current/msg00844.html
>>>
>>>==============
>>>
>>>The following needs to be addressed in the protocol doc:
>>>
>>>I've been asked to have a look at the the protocol doc as well, and ...
>>>
>>>On 01.11.2010 20:30, Alexander Mayrhofer wrote:
>>>>
>>>> #9
>>>>>   SED is typically created by the terminating SSP and consumed by the
>>>>>   originating SSP.  To avoid a multitude of bilateral exchanges, SED
>>>>> is
>>>>
>>>> "terminating" is perhaps the wrong word for the transit case, as the
>>>> it's the transit SSP, and not the final, terminating SSP that creates
>>>> the SED entries.
>>>>
>>>> ===************
>>>> [S] That's true. Design Team: any suggestions on how to word this
>>>>better
>>>> for direct and transit cases?
>>>> ===************
>>>>
>>>> ==> Alex: I have changed this to "... created by the terminating or
>>>> next-hop SSP..." - Is this
>>>> a way forward?
>>>>
>>>> [Sumanth] Yes! :)
>>>>
>>>
>>>
>>>
>>>
>>>
>>>On 2/22/11 8:18 PM, "Sumanth Channabasappa" <[email-masked]>
>>>wrote:
>>>
>>>>Folks,
>>>>Here's the reminder for the call this week, and the AIs from the last
>>>>call.
>>>>
>>>>Authors,
>>>>I am assuming you will be able to respond to Otmar's review comments
>>>>pretty soon? In addition, I'd like to request you to copy/paste your
>>>>comments regarding the updates that were incorporated in the latest
>>>>revision to the I-Ds.
>>>>
>>>>Thanks!
>>>>- S
>>>>
>>>>AIs:
>>>>
>>>>[Ken, 2/15] Present an update t the I-D
>>>>[Authors, 2/15] Review and respond to Otmar's comments
>>>>
>>>>===============
>>>>Conference Info
>>>>===============
>>>>Conference # : 415-363-0070
>>>>Access Code  : 295-243-433
>>>>Web link     : https://www1.gotomeeting.com/join/295243433
>>>>Meeting ID   : 295-243-433
>>>>
>>>>
>>>>=================
>>>>AGENDA (proposed)
>>>>=================
>>>>1. Status update from the authors (use cases, protocol I-Ds) 2. Agenda
>>>>for the next IETF 3. Other topics (e.g., open source project)
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>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.
>>>
>>
>>
>>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.
>>
>
>
>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.
>

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.