At 03:09 PM 9/22/2011, Robert Sparks wrote:
>Hi James - Sorry for taking a few extra days to respond - responses inline.
>
>Why aren't we copying the list here?
sorry
>Unless there's a reason not to, would you add it to your next response?
done
>On Sep 14, 2011, at 10:18 PM, James M. Polk wrote:
>
> > At 02:40 PM 5/31/2011, Robert Sparks wrote:
> >> Summary: There are a few issues to address with a revised ID
> before moving to IETF LC
> >>
> >> 1) The definition of the LocationURI format in section 2.3 says
> that the definition
> >> of each LuriType field value will define the unit of measurement
> for the LuriLength
> >> field. The two LuriTypes defined in this document don't provide
> that definition.
> >
> > clarified the URI is in bytes, and Valid-for is in seconds.
> >
> >
> >> 2) It's not clear if a response containing a LuriType=2 frame,
> but no LuriType=1 frame
> >> is valid, and what a client should do if it recieves one.
> >
> > the second to last paragraph in Section 2.3 is
> >
> > The Valid-For (LuriType=2) is not mandated for use by this document.
> > However, its presence MUST NOT cause any error in handling the
> > location URI (i.e., if not understood, it MUST be ignored).
> >
> > Do you want more to it that this, or this to be rewritten because
> it is unclear?
> >
> > I could state that the Valid-for (LuriType=2) is OPTIONAL, or
> even 'SHOULD be there', for instance.
>
>I don't think you understood my question.
nope, I missed your meaning.
>Is it valid to get a response that has an LuriType 2 frame, but NOT
>a LuriType1 frame?
>I don't see how the text you quote or propose answers that - am I
>missing something?
I added
The Valid-For (LuriType=2) offers no meaningful information without
an accompanying Location URI (LuriType=1), therefore a Valid-For
(LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).
Does this cover what you had in mind?
> >
> >
> >> 3) The registration policy of section 4.3 is not clear. Are you
> aiming for one of the
> >> well-known policies in section 4.1 of RFC 5226?
> >
> > see point #4 below
> >
> >
> >> 4) That said, why is the registry in section 4.3 necessary at
> all? Prose in the RFC, rather
> >> than a registry, is going to be more useful to the implementer -
> the approach that
> >> sipcore-location-conveyance takes just under the BNF for
> Geolocation-header in section
> >> 4.1 of that document would work here just as well.
> >
> > I deleted the IANA registration in Section 4.3, and changed
> Section 3.3 to include the following paragraph to bring this
> document more in line with Location Conveyance:
> >
> > It is RECOMMENDED that implementers follow what is in ID-SIP-LOC
> > [ID-SIP-LOC] as guidance regarding which Location URI schemes to
> > provide in DHCP. That document discusses what a receiving entity
> > does when receiving a URI scheme that is not understood. Awareness
> > to the two URI types there is important for conveying location, if
> > SIP is used to convey a Location URI provided by DHCP.
> >
> > Let me know if this is ok...
> >
>[ID-SIP-LOC] would need to become a normative reference. And I think
>you point specifically to section 4.3.
already moved
>It might be easier to copy by value instead of by reference.
not sure I understand this what you're getting at with this last line
(though it is a Monday and I'm a bit slow ;-)
> >
> >> 5) Should the refresh recommendation in section 2.3 include some
> randomization? Without it,
> >> do we have all of the elements that got their location URI from
> this option at the same
> >> time during an avalance-restart attempting to refresh at the same time?
> >
> > I added this to the end of the 3rd to last paragraph:
> >
> > However, if every client on a network
> > were to attempt a refresh at the same time, say if power when out
> > and was brought back up at the same time, there would be an
> > avalanche of location requests or transmissions. This can be avoided
> > by varying the timers between the nodes on the same network. This
> > can be a good reason for not giving out the same Valid-for timer
> > (amount) with each Location URI sent.
> >
> > Let me know if this is ok...
>yes
cool
> >
> >
> >> 6) I can't parse the sentence in 2.3 that starts "A Location URI
> refresh SHOULD be done during
> >> the normal DHCP refresh rate,...". In particular, extracting the
> expected normative behavior
> >> out of that sentence is difficult. Here's an attempt at a
> rewrite - does it say what was
> >> intended?:
> >>
> >> A client will update is Location URI either as part of the
> normal DHCP lease renewal, or
> >> through a renewal request sent due to the Valid-For timer
> reaching the value described
> >> in this document. Note that in the second case, the request
> could ask only for the LocationURI
> >> option.
> >
> > yeah - it says the same thing. But if you're happier with the
> above, I am too (so I copied it into the doc).
> >
> > ;-)
> >
> >
> >> 7) In section 3.2's first bullet, why is this a SHOULD NOT and
> not a MUST NOT?
> >
> > changed
> >
> >> Would it be
> >> better if the sentence said "be automatically sent" rather than "be sent"?
> >
> > err, the word "automatically" isn't in this document, so I'm at a
> loss to know what you want changed here.
>I was suggesting _adding_ the word automatically.
ah, missed that too -- fixed now.
> >
> >> Similarly, why
> >> is the SHOULD NOT in the second bullet not a MUST NOT?
> >
> > changed
> >
> >
> >> 8) Why does section 3.3 rule out the use of XMPP with pres: URIs?
> >
> > huh... don't know...? What's the RFC I should point at for this?
> Is it 5122?
> >
>3922 I think, but I'll double check with SIMPLE/XMPP.
this is covered in a separate message that I'll send 1 minute after I
send this one.
> >
> >> It looks like -03 was the last version of this document reviewed
> by DHC. I'm requesting
> >> an updated review.
> >
> > ok
>I don't think I've received this yet - I repolled for it today.
ack
Based on the above, I'll finalize the mods and submit the new rev for
IESG consideration.
James
> >
> >
> >> Nits:
> >>
> >> * The one-sentence Abstract needs editing. Currently it talks
> about "a client's URI of a client".
> >> Please simplify the structure. Breaking it into multiple
> sentences would help.
> >
> > fixed
> >
> >
> >> * First paragraph of the introduction: Suggest s/associated
> by/associated with/
> >
> > fixed
> >
> >
> >> * In section 3, instead of "location URIs such as <...> are to
> be done, ... rather than <...>"
> >> I suggest "For example, creating a location URI such as
> <sips:...> is better than a location
> >> URI such as <sips:aliceisat...>. The username portion of the
> first example URI provides no
> >> direct identiy information."
> >
> > fixed
> >
> >
> >> * In section 3, I suggest either deleting the sentence that
> starts "The entity= discussion",
> >> or replacing it with something like "The considerations for
> populating the entity attribute
> >> value in a PIDF-LO document are independent from the
> considerations for avoiding exposing
> >> identification information in the username part of a location URI."
> >
> > replaced (as I still think this is an important point to make).
> >
> >
> >> * The end of Section 3.3 points forward to section 4.2, but it
> should point to 4.3 if we keep
> >> that registry.
> >
> > both're gone (the 'forward pointer' and the URI Schemes registry
> that was in section 4.3)
> >
> >
> >> * I suggest deleting the sentence that starts "Penetrating an LS
> is supposed to be hard". Its
> >> a good sentiment, but it's captured in the documents that define
> an LS, and it doesn't help
> >> the implementer of this document.
> >
> > done
> >
> > I'll hope off submitting this version until I hear back from one
> of you about my larger editorial inclusions above (to points #4 and
> #5 above). The doc is done if nothing more is asked for (save for
> DHC getting their greedy hands on it and having a problem ;-)
> >
> > James
> >
> >
> >> _______________________________________________
> >> 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
