>
>
> >-----Original Message-----
> >From: geopriv-bounces@ietf.org
> >[mailto:geopriv-bounces@ietf.org] On Behalf Of ext James M. Polk
> >Sent: Tuesday, June 23, 2009 12:39 PM
> >To: geopriv@ietf.org
> >Subject: Re: [Geopriv] [geopriv] #10: Should not encourage
> >use of "old" encoding
> >
> >At 07:20 PM 6/22/2009, geopriv issue tracker wrote:
> >>#10: Should not encourage use of "old" encoding
> >>---------------------------------------+--------------------
> >-----------
> >>---------------------------------------+-----
> >> Reporter: martin.thomson@andrew.com | Owner:
> >>
> >> Type: enhancement | Status: new
> >>
> >> Priority: major | Milestone:
> >> draft-ietf-geopriv-3825bis
> >>Component: rfc3825bis | Version:
> >>
> >> Severity: - | Keywords:
> >>
> >>---------------------------------------+--------------------
> >-----------
> >>---------------------------------------+-----
> >> When creating a new version of 3825, we need to make a statement
> >> about how to interoperate with the old version.
> >>
> >> Suggestion: permit receipt of the old encoding, but (strongly)
> >> discourage the sending of it.
> >>
> >> That is:
> >>
> >> Implementations of this specification MUST support receipt of an
> >> option that includes a version of 0. Implementations of this
> >> specification MUST not create or send an option with a
> >version of 0.
> >
> >I strongly disagree with this goal. There may be
> >configurations that understand perfectly well what sending a
> >version 0 Option to a client means. This should be a local
> >configuration decision. I don't have an issue with adding
> >text providing guidance to prefer that the v1 Option be sent
> >(and why - and not just "cuz it's better"), but we cannot
> >prevent v0 from being sent, which Martin's "MUST" above
> >explicitly states.
>
>I also disagree with the proposed text.
>I'd like to see the first MUST be a MAY. I am ok with the second MUST.
The first MUST should be a SHOULD.
The second sentence is a matter of local configuration, which should
be consistent uniform throughout the local domain.
For example, Cisco San Jose (our main campus) should be RECOMMENDED
to have the same configuration, but not necessarily the same as the
Cisco Texas region, or the Cisco North Carolina region. This could be
a case of configuration migration (i.e., upgrading the config from
one campus to the next). This "configuration" by any local IT
department shouldn't violate an RFC, which is being suggested.
> >>--
> >>Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/10>
> >>geopriv <http://tools.ietf.org/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
