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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]