On 2011-07-09 at 05:32:17, Richard L. Barnes wrote:
> +1
>
> On Jul 8, 2011, at 3:14 PM, Hannes Tschofenig wrote:
>
> > Fine for me.
> >
> > On Jul 8, 2011, at 8:31 PM, Alissa Cooper wrote:
> >
> >> draft-ietf-geopriv-arch-03 is in AUTH48 and the authors have
> suggested a slight change to some normative language in section 4.2.4.
> Here is the section:
> >>
> >> An LS that receives Rules exclusively through LOs MUST examine the
> >> Rules that accompany a given LO in order to determine how the LS
> >> may use the LO (if any Rules are included by reference, the LS
> >> SHOULD attempt to download them). If the LO includes no Rules that
> >> allow the LS to transmit the LO to another entity, then the LS MUST
> >> NOT transmit the LO. If the LO contains no Rules at all (if it is
> >> in a format with no Rules syntax, for example), then the LS MUST
> >> delete
> it
> >> (emergency services provide an exception in that Rules can be
> >> implicit; see [15]). If the LO included Rules by reference, but
> >> these Rules were not obtained for any reason, the LS MUST NOT
> >> transmit the LO and MUST delete it.
> >>
> >> Here is the suggested change:
> >>
> >> OLD:
> >> If the LO included Rules by reference, but these Rules were not
> >> obtained for any reason, the LS MUST NOT transmit the LO and MUST
> >> delete it.
> >>
> >> NEW:
> >> If the LO included Rules by reference, but these Rules were not
> >> obtained for any reason, the LS MUST NOT transmit the LO and MUST
> >> adere to the provided value in the retention-expires field.
> >>
> >> The change has been proposed to clarify that
> >> a) if the LS does not want to re-transmit location information then
> >> it does not immediately have to delete the received location object
> but instead looks at the retention-expires field only.
> >> b) if the LS wants to transmit location information it is not
> allowed to do so. The retention-expires field would also give guidance
> on how long it is permitted to keep the location.
> >>
> >> Since this is a change to normative language, if folks have
> objections to it we're requesting that they send them to the list by
> next Wednesday, July 13.
> >>
> >> Thanks,
> >> Alissa
> >>
> >>
> >>
> >> _______________________________________________
> >> Geopriv mailing list
> >> Geopriv@ietf.org
> >> https://www.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
