Subject: Re: [Tsvwg] WG last call of draft-ietf-tsvwg-emergency-rsvp-02

From: ken carlberg <[email-masked]>
Date: Mon, 16 Apr 2007 09:54:46 -0400

Lou,

Thanks a lot for the fresh look at things.

> One general comment is that it seems that the objective could also  
> have been reached introducing just APP_RESOURCE and a minor  
> semantic change to Preemption Priority when the new element is  
> present.  That said, the cost of  ADMISSION element is pretty low  
> and to some degree it is a cleaner solution.

Bingo.  You hit it on the head in that we wanted something clean and  
separate from the pre-existing Preemption Priority element.

> Section 2/Section 2.1:
>
> Some (not too many) words on how you see this document impacting  
> the relationship of policy control and admission control would  
> probably be worthwhile.

Unless Francois sees it differently, I don't see any change in the  
relationship of policy control with this new element in contrast to  
other policy elements like that of rfc-3181.  However, we can state  
this explicitly in the section and perhaps stress its importance in  
selection of the form of admission control given the various models  
one can choose from.

> Section 2.1:
>    bandwidth allocation model that we term the Priority Bypass Model
>    (PBM). It is important to note that the models described and
>
> PBM is typically used for Policy Based Management.  Given that  
> you're defining a Policy object redefinition of this acronym in  
> this context is bound to lead to some confusion.

ok, we can change it from PBM to PRBM.

> Section 3.1:
>
>          +-------------+-------------+-------------+-------------+
>          |     Length                | P-Type = ADMISSION_PRI    |
>          +-------------+-------------+-------------+-------------+
>          | Flags       | M. Strategy | Error Code  | Reserved    |
>          +-------------+-------------+-------------+-------------+
>          |Adm. Priority|            Reserved                     |
>          +---------------------------+---------------------------+
>
> why 4 bytes of Reserved fields? Consistency with other policy data  
> objects isn't a requirement.

agreed, but it gives us some wiggle room in case something else  
emerges that we didn't anticipate.  I've recently seen some odd stuff  
in the Land Mobile Radio arena, via project-25, that may prompt them  
to play with one of the reserved octets on an experimental basis but  
without disrupting an existing implementation of the new policy  
element.  So, I'd rather burn the bytes now.

> Section 3.1.1:
>
> I think it would be valuable to have some words on handing of (and  
> comparability with) merge nodes that are PINs or RFC2750 enabled  
> but don't support this document.

good point.  we'll sit down and add some text to talk about this.

> Section 3.2:
>
>        ALRP Namespace (Application-Level Resource Priority Namespace):
>            16 bits (unsigned)
>
> While 16 bits seems like a big number, we have lots of examples  
> where we run out of bits.  Have you thought how you'd handle this  
> if this very turned into a real issue?  Perhaps realigning the  
> element so that Reserved precedes ALRP Namespace would be a good  
> idea to allow for future flexibility.

I have no qualms in moving the reserved field to precede the ALRP  
NameSpace (James or Francois may feel differently, so they may speak  
up on their own and provide a different perspective).  However, I  
don't think we'll have a problem with a limit of 16 bits because of  
the administrative constraints placed by [SIP-PRIORITY] to register a  
new NameSpace.  The process requires expert review, so its not a  
rubber stamp for any request.

In addition, we aligned the size to coincide with a similar field  
defined in the QSPEC document being advanced in the NSIS working  
group -- one of those rare occasions where one aligns/coordinates  
work with another working group :-).  We could have stated this  
explicitly, but I feel uncomfortable doing this in section 3 given  
that the QSPEC is still in draft form.

>            represents the position of the namespace in the "Resource-
>            Priority Namespace" IANA registry, starting with 0.  
> Creation
>            of this registry has been requested to IANA in [SIP-
>            PRIORITY].
>
> Section 3.2 and Section 5:
>
> As [SIP-PRIORITY] has been issued and IANA has completed their  
> assignments, the document should be consistent with the actual IANA  
> registry.  Also, I think you should explicitly request that IANA  
> number the namespace so there is no ambiguity or possible numbering  
> issues if the namespace were to be reordered.

ok, we'll update the sentence to indicate that IANA has already set  
up the registry.

thanks,

-ken

---

From: Lou Berger <[email-masked]>
Date: Mon, 16 Apr 2007 10:13:33 -0400

Ken,
         See in-line responses below.

Lou
At 09:54 AM 4/16/2007, ken carlberg wrote:

>other policy elements like that of rfc-3181.

I think there is subtle difference in that now allocation is being 
made based on policy.  Preemption would trigger (policy based) 
removal and then normal allocation.  Also, I think it would have been 
good for 3181 to address this point as well.

>  However, we can state

I think a few sentences is all that's needed.

>emerges that we didn't anticipate.

humm.  Don't really love this approach as a new element could be 
defined then, but this isn't a big deal.  If you do keep the 4 bytes 
of reserved space, I think you should align them to give you maximum 
future flexibility.

>  I've recently seen some odd stuff
>new NameSpace.

again, this is about future flexibility...

>The process requires expert review, so its not a

This was a trick question/comment!  Unless I missed it, the IANA 
registry doesn't match what was requested in [SIP-PRIORITY].

Lou

---

From: ken carlberg <[email-masked]>
Date: Mon, 16 Apr 2007 10:34:30 -0400

> removal and then normal allocation.  Also, I think it would have  
> been good for 3181 to address this point as well.

ok, understood.

> registry doesn't match what was requested in [SIP-PRIORITY].

that will teach me to assume things have been done :-).  I can only  
imagine that the registry hasn't been set up yet because there have  
been no requests for new NameSpaces.  However, one would think that  
the registry would exist to reflect existing values defined in  
RFC-4412.  Perhaps James (as the co-author of this draft and  
rfc-4412) needs to chase this down.  One way or another, the registry  
based on rfc-4412 needs to exist.

As a side note, and probably something that needs a comment from the  
Chairs/ADs, is that our IANA Considerations does not request a  
registry for a numeric representation of a NameSpace correlating to  
that requested rfc-4412.  This request is in the QSPEC, which has  
been in draft form for a while (they are on version 16 at present) as  
well as on Last Call for months.  Do we wait for the QSPEC or do we  
make the request ourselves and see who finishes first?

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 16 Apr 2007 10:52:51 -0400

> based on rfc-4412 needs to exist.
James has an ID which will request a number of new namespaces.
draft-polk-sip-rph-new-namespaces-00
So if it has not been addressed yet, it soon will be. 

Janet

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 23 Apr 2007 12:41:36 +0200

Lou, Ken,

> good point.  we'll sit down and add some text to talk about this.

I think both the case of a (i) Policy-Ignorant-Node (PIN) and of a  
(ii) policy-capable-node that is not aware of a new Policy Element,  
are already covered appropriately in section " 4.2 Default Handling  
for PIN nodes" of RFC2750. (ie forward as is, concatenate upstream  
with multicast, copy downstream with multicast).

BTW, this would also apply to the ALRP Policy Element defined in 3.2,  
right?

So how about we add a section "3.3 Default Handling" that says  
something like:
"
As specified in section 4.2 of RFC2750, Policy Ignorant Nodes (PINs)  
implement a default handling of POLICY_DATA objects ensuring that  
those objects can traverse PIN nodes in transit from one PEP to  
another. This applies to the situations where POLICY_DATA objects  
contain the Admission Priority Policy Element and the ALRP Policy  
Element specified in this document, so that those can traverse PIN  
nodes.

Section 4.2 of RFC2750 also defines a similar default behavior for  
policy-capable nodes that do not recognized a particular Policy  
Element. This applies to the Admission Priority Policy Element and  
the ALRP Policy Element specified in this document, so that those can  
traverse policy-capable nodes that do not support this document.
"

Does that work?

Francois

---

From: Lou Berger <[email-masked]>
Date: Mon, 23 Apr 2007 12:11:40 -0400

Francois,

         See below.

>with multicast, copy downstream with multicast).

agree, the general case is covered.

>BTW, this would also apply to the ALRP Policy Element defined in 3.2,

yes, but Application-Level Resource Priority Policy Element has 
semantics that allow for/address multiple elements.

>traverse policy-capable nodes that do not support this document.

yes, but also need to state how multiple Admission Priority Policy 
Elements in the same message are to be handled. (presumably the 
downstream node does the merge, but perhaps not...)

Lou