Subject: [drinks] I-D ACTION:draft-ietf-drinks-spprov-00.txt

From: [email-masked]
Date: Wed, 7 Jul 2010 16:15:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Data for Reachability of Inter/tra-NetworK SIP Working Group of the IETF.

	Title		: Session Peering Provisioning Protocol
	Author(s)	: J. Mule, K. Cartwright, S. Ali, A. Mayrhofer
	Filename	: draft-ietf-drinks-spprov-00.txt
	Pages		: 72
	Date		: 2010-7-7
	
This document defines a protocol for provisioning session
   establishment data into Session Data Registries and SIP Service
   Provider data stores.  The provisioned data is typically used by
   various network elements for session peering.

   This document describes the Session Peering Provisioning Protocol
   used by clients to provision registries.  The document provides a set
   of guiding principles for the design of this protocol including
   extensibility and independent transport definitions, a basic data
   model and an XML Schema Document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-drinks-spprov-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Thu, 8 Jul 2010 16:30:27 -0400

Thanks to the authors for pulling this draft together

A few comments and questions:
1. In Figure 1 the Organization object contains "peerPrefs" but I don't
see that term used elsewhere in the document. Was "peeringOrg" intended?

2. Likewise, since peeringOrg can be associated with Route Records, I
think it would be useful to show it in that object in the Figure

3. DNAMEType and CNAMEType need to be added to the set of RR types

4. Can you elaborate on the use of the URIType as opposed to the
NAPTRType?

5. The NSType record can contain an IPAddressType element. Is this is to
ultimately generate an A "glue" DNS RR?

6. The source identity object regular expression can be matched against
a resolver IP address which I understand but also a root domain name or
a calling party URI. Are the latter two options intended for a SIP
redirect (ugh) scenario?

Thanks,

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, July 07, 2010 7:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: [drinks] I-D ACTION:draft-ietf-drinks-spprov-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Data for Reachability of
Inter/tra-NetworK SIP Working Group of the IETF.

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 12 Jul 2010 15:16:34 -0600

Penn,

  Thank you for your comments.  

  We just posted draft-01 and it contains some corrections based on your comments.
http://www.ietf.org/id/draft-ietf-drinks-spprov-01.txt 

  More inline

> see that term used elsewhere in the document. Was "peeringOrg" intended?
good catch, as you guessed the data model diagram had not been entirely updated.  See draft-01

> think it would be useful to show it in that object in the Figure
yes, done.

> 3. DNAMEType and CNAMEType need to be added to the set of RR types
we can certainly add new concrete types for route records and those you mention.  Any specific use cases that we should try and capture to justify those additions?  (whether or not we have valid use cases, we can certainly add them in the proto, just curious).

> 4. Can you elaborate on the use of the URIType as opposed to the
This dates back from Jon's comments at the last IETF re: "target domains".
Jon proposed we just used URIs as opposed to a targetdomain or NAPTR as you can deduce both from the URI.  So, as far as I understand the intended usage, one can use a URI for LUF or a NAPTR for a registry that is ENUM protocol-specific and want to do LUF+LRF.

> ultimately generate an A "glue" DNS RR?
possibly.  Syed can elaborate I think.

> a calling party URI. Are the latter two options intended for a SIP

Good question, certainly not something we have discussed.  The text should be more specific here.
It seems to me that matching a source identity object to a URI parameter does not convey the same source property as an intermediary could relay or proxy the message without having the same "source identity".
Do you see any use cases for allowing source identity matching based on the root domain name of calling party part of the URI?

Regards,
Jean-Francois. 
---
Jean-François Mulé
CableLabs
mailto:[email-masked]

On Jul8 2010, at 22:30, PFAUTZ, PENN L (ATTCORP) wrote:

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