Re: [Geopriv] AD review: draft-ietf-geopriv-dhcp-lbyr-uri-option-11

Robert

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