Re: Last Call: draft-carlberg-trip-attribute-rp (TRIP Attribute for Resource Priority) to Proposed Standard

[ken carlberg <carlberg at g11.org.uk>]

Ted,

> Howdy,
> 	A couple of things about this specification confuse me, and
> I'd appreciate enlightenment from the authors.  The first is that the
> document spends a fair amount of time setting up the context in
> which GETS or other services might use resource priority and how
> this mechanism relates to the SIP resource-priority header.  In  
> Section
> 4.2.3, though, the documents says:
>
> An LS MAY add the ResourcePriority attribute when propagating routing
>    objects   to   an  LS  in  another  domain.   The  inclusion   
> of  the
>    ResourcePriority  attribute  is  a  matter  of  local   
> administrative
>    policy.
>
> Should the reader assume that this local administrative policy will  
> follow one of the
> policy approaches discussed in Section 2?  If so, should this be  
> stated explicitly?  If
> not, is the text in Section 2 appropriate?

Section 2 just provides context and a pointer for additional reading  
to the casual reader.  I wouldn't characterize the systems discussed  
in Section 2 as "policy approaches", and the word "policy" is also  
not mentioned in that section.  However, the section does point the  
reader to rfc-3689, which in turn discusses the term of "local  
policy", thus complimenting its usage further on in this draft.

> 	The second is that relatively sparseness of the Security  
> Considerations,
> which at the moment read:
>
>    The document defines a new attribute for the TRIP protocol and  
> has no
>    direct  security considerations applied to it.  However, the  
> security
>    considerations for TRIP and its messages  remain  the  same   
> and  are
>    articulated in Section 14 of [rfc3219].
>
> Are there no security considerations for the removal of this header  
> by LSes which fail
> to honor the requirement that an LS "MUST  propagate the  
> ResourcePriority attribute"?

I would say no.  Taking the text in its entirety....

     If received from a peer LS in another domain, an LS   MUST   
propagate
     the ResourcePriority attribute to other LSs within its domain.

....the document conveys the need for consistent information  
propagated *within* a domain.  A broken implementation that fails to  
propagate the information simply reduces the filter/criteria used to  
select a gateway.

> Are there any specific considerations (security or reliability)  
> that apply when the Partial
> flag has been set by Location Server that does not recognize the  
> attribute?

Nothing beyond what is stated in rfc-3219.  Keep in mind while this  
draft defines a new attribute, it shares the same following  
characteristics of the  Communities attribute defined in rfc-3219:

   Conditional Mandatory: False.
   Required Flags: Not Well-Known, Independent Transitive.
   Potential Flags: None.

If one determines that an additional consideration (security or  
reliability) does apply when the Partial flag is set, we'll need to  
update rfc-3219 as well.

cheers,

-ken



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf