Thanks for the quick response.
>Hannes
>
>Thanks for the review
>
>comments in-line
>
>At 01:26 AM 7/20/2009, Hannes Tschofenig wrote:
>
>>Hi James,
>>
>>Thanks for the update. I have compiled my comments into the MS word
>>with track changes and turned it into a PDF. <<...>>
>
>thanks for this format
I could also send you the word document, if that makes things easier.
It is very difficult to type these editorial suggestions into a mail.
>
>
>>There are a bunch of editorial suggestions; maybe they are useful.
>
>I'm frustrated by some of the comments and suggestions because
>- in some cases - they hack apart text that's been
>(unmodified) in the document since the individual -00 was
>submitted way more than 2 years ago, and no comments were made
>until now. Makes me think I continually have to hit a moving target...
If you think that the editorial comments do not help then leave it as is.
Why do I send editorial comments so late? Well, for me it makes a lot of
sense to provide them with a stable version rather than with an early
version. Early document versions tend to change a lot making any previous
editorial comments irrelevant.
>
>another frustration is with the "entity= attribute" vs.
>"device ID element" discussion - which several on this list
>don't seem to want to separate - and they are separate topics.
> The entity= attribute is equivalent to an AOR in SIP (i.e.,
>it is the presentity's URI), but the <deviceID> element is
>equivalent to a MAC address. Both are identifiers, but one can
>change and the other is fixed for the life of that device.
>
>When Hannes logs onto two devices, the two devices each have
>unique identifiers (i.e., unique MAC addresses), but Hannes'
>presentity URI is the same for both devices, unless the URI
>has a host part embedded within the URI (analogous to a SIP
>AOR vs. a Contact Address). The user part and the domain part
>of the URIs are still the same. The two identifiers should
>never be considered the same - and all the discussion about
>interchanging the meanings of entity= and device should never happen.
>
>but it still does...
I didn't see a discussion of 'entity' attribute vs. <deviceID> element in
draft-ietf-geopriv-dhcp-lbyr-uri-option-05.txt.
>
>That said - some comments, however, seem to be fine and I'll
>modify the text accordingly.
>
>
>>There is only one major comment: It is good that you describe the
>>security model you focus on. It seems that you settled with the
>>authorization model in comparison to the possession model. That's
>>fine with me given the lack of confidentiality protection in DHCP.
>
>ok, glad you think this is ok moving forward...
>
>
>>Now, in order to get it to work in an interoperable fashion you
>>would have to make Geolocation Policy and XCAP a normative reference
>>(mandatory to implement).
>
>I have Geolocation Policy as informative now (and have had it in
>there for a while), and I can make this normative, but I don't yet
>see how making XCAP explicitly normative is necessary.
My thinking was the following:
http://www.ietf.org/id/draft-ietf-geopriv-policy-21.txt does not define a
mandatory-to-implement transport to uploading the policy.
If we do not define one in this document then we end up with the situation
where the end host and the DHCP server understand the same authorization
policy format but the policies cannot be uploaded.
That's why I was suggesting to add XCAP to the normative references. Maybe
XCAP needs to be normatively referenced in the geolocation policy document?!
I don't know what would be more appropriate.
> If you
>believe it is to get Geolocation Policy to work, then making
>Geolocation Policy normative ought to be enough, don't you think? If
>not, exactly which piece of text in this ID do I place the XCAP
>reference directly next to?
>
Ciao
Hannes
>>I cannot see it would work otherwise.
>>
>>Ciao
>>Hannes
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
