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

From: Ted Hardie <[email-masked]>
Date: Tue, 10 Jul 2007 11:56:41 -0700

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?
	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"?
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?
	Thanks for any insight,
			regards,
				Ted Hardie

At 1:43 PM -0400 7/10/07, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>
>- 'TRIP Attribute for Resource Priority '
>   <draft-carlberg-trip-attribute-rp-02.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the
>[email-masked] mailing lists by 2007-08-17. Exceptionally,
>comments may be sent to [email-masked] instead. In either case, please
>retain the beginning of the Subject line to allow automated sorting.
>
>The file can be obtained via
>http://www.ietf.org/internet-drafts/draft-carlberg-trip-attribute-rp-02.txt
>
>
>IESG discussion can be tracked via
>https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13669&rfc_flag=0
>
>
>_______________________________________________
>IETF-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: ken carlberg <[email-masked]>
Date: Wed, 11 Jul 2007 06:57:13 -0400

Ted,

> 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.

> 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.

> flag has been set by Location Server that does not recognize the  

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