Subject: [Tsvwg] New ID: draft-polk-tsvwg-signaled-domain-id-00

From: "James M. Polk" <[email-masked]>
Date: Thu, 05 Jul 2007 17:02:01 -0500

TSVWG

Here is a new ID we just submitted, creating a new element to be used 
to make domain and/or subdomain CAC decisions based upon. These 
identifiers apply to individual reservation flows, as well as tunnels 
and aggregates.

Comments are appreciated

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-polk-tsvwg-signaled-domain-id-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Signaled Domain and Sub-domain Identification Element
	Author(s)	: J. Polk, S. Dhesikan
	Filename	: draft-polk-tsvwg-signaled-domain-id-00.txt
	Pages		: 10
	Date		: 2007-7-5
	
    This document defines a domain and a sub-domain identification
    element for use by signaled policy based admission protocols such as
    Resource ReSerVation Protocol (RSVP) and Common Open Policy Service
    (COPS).  This element identifies the domain and sub-domain to which
    the reservation belongs and is used, along with the PREEMPTION_PRI
    element, to make capacity-based admission control (CAC) decisions.

Thanks
James

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Jul 2007 19:34:16 +0100

Hi James,

I think it would be helpful if you added some text explaining what a 
"domain" is. This may be obvious to the cognoscenti, but coming from 
outside, I initially wondered if you were referring specifically to ASes. 
Then I saw the reference to 3181 and decided you meant "policy domain", and 
then I got to the IANA section and wondered if you are creating a whole new 
thing.

Thanks,
Adrian
----- Original Message ----- 
From: "James M. Polk" <[email-masked]>
To: "tsvwg" <[email-masked]>
Sent: Thursday, July 05, 2007 11:02 PM
Subject: [Tsvwg] New ID: draft-polk-tsvwg-signaled-domain-id-00

> TSVWG
>
> Here is a new ID we just submitted, creating a new element to be used to 
> make domain and/or subdomain CAC decisions based upon. These identifiers 
> apply to individual reservation flows, as well as tunnels and aggregates.
>
> Comments are appreciated
>

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 6 Jul 2007 17:37:08 -0400

Adrian,

As I understand it, it is analogous to the MLPP Service Domain in SS7. The 
"service domain" is a purely logical structure which identifies the 
"closed community" of calls which are permitted to preempt each other.  A 
high priority call can preempt a lower priority call IN THE SAME SERVICE 
DOMAIN, but cannot preempt a lower priority call which is part of a 
DIFFERENT SERVICE DOMAIN.

You can have multiple "service domains" within a single AS.  You can have 
multiple "service domains" within a single policy domain.

Janet

> > Here is a new ID we just submitted, creating a new element to be used 
to

---

From: ken carlberg <[email-masked]>
Date: Fri, 20 Jul 2007 14:35:43 -0400

James,

here are some comments and questions on the draft...

- to start off with, you definitely need a terminology section that  
clarifies Policy Domain, Domain identifier (which seems to equate to  
an AS), and sub-domain.  I think Janet suggested Service Domain, or  
maybe some other term that doesn't include "domain" so as to minimize  
confusion.

- and if the Domain Identifier == AS, then you'll want to bump up the  
size of the field to 32 bits so that it aligns with rfc-4893.

- section 1, 3'rd paragraph.  I'm paraphrasing what you are saying  
here, but when you speak of the risk of some domains arbitrarily  
using high priority values, hence the need for domain/sub-domain  
identifiers, it seems to me that you are speaking of apples and  
oranges.  The former is really a function of authorization and  
authentication, while the latter seems like an easier approach to  
accomplish access control lists (ie, domains versus source net  
prefixes).

And this brings up another point.  Would you want to accomplish some  
(maybe all?) of this work in the form of an extension to X.509v3 that  
would include the identifiers defined in this draft?

- is it your intention to use this domain ID element only in  
conjunction with rfc-3181?  Or could you envision it being applied to  
draft-ietf-tsvwg-emergency-rsvp-02?  If yes, you'll need to broaden  
some of the text in the draft so that it can be applied to more than  
one policy element.  This *may* also complicate things with respect  
to Error codes.

- Section 4.  You may want to give some thought to adding or changing  
the structures of the existing fields into a series of TLVs so that  
you have some additional flexibility in adding granularity to sub- 
domains and possibly domains.

- page 5 (top).  When you say that a domain and subdomain MAY be  
paired with a SIP RPH header NameSpace, a question arises as to which  
NameSpace?  (given the fact that rfc-4412 says that multiple  
different NameSpaces may exist in the SIP message.

- Section 5, Item 5.  if sub-domains are not to be registered, and  
are administered locally, how do achieve or help ensure  
interoperability if these sub-domains are added by one adminsitrative  
domain and examined by another?

- Section 5, Item 8.  The first sentence says "...entities SHOULD NOT  
change Domain-value field".  I assume you mean the Transit Domain- 
Value, since later on in Item 10 says the "Original-Domain-Value MUST  
NOT be changed..."

- I would disagree that your document introduces no additional  
security considerations above that found in rfc-3181.  to begin with,  
you'll need to update and clarify what is meant by a "trusted zone or  
at least a single zone (no zone boundaries are crossed)" as stated in  
the Security Considerations of rfc-3181.   Perhaps I've missed  
something, but the picture you have painted in this document would  
leave it open to being used across administrative boundaries that may  
not have a continual chain of trust.

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 20 Jul 2007 15:01:50 -0400

I'd be interested in having a better understanding about the relationship 
between 

the DOMAIN_SUBDOMAIN Element in draft-polk-tsvwg-signaled-domain-id-00

and

the Application-Level Resource Priority Policy Element in 
draft-ietf-tsvwg-emergency-rsvp-03, especially the ALRP Namespace.

Janet

---

From: ken carlberg <[email-masked]>
Date: Fri, 20 Jul 2007 15:22:47 -0400

At present, there is no relationship :-)

-ken

On Jul 20, 2007, at 3:01 PM, Janet P Gunn wrote:

>
>
>
> I'd be interested in having a better understanding about the  
> relationship between
>
> the Application-Level Resource Priority Policy Element in   draft- 
> ietf-tsvwg-emergency-rsvp-03, especially the ALRP Namespace.
>
> Janet
>
>