[Gen-art] Re: Gen-art review update for draft-ietf-simple-presence-data-model-06

[Jonathan Rosenberg <[e-mail]>]

Elwyn,

Sorry for the long delay here; I'm just now getting to this after the
holidays.

Thanks for your comments. Responses inline.

Elwyn Davies wrote:

> I was selected as General Area Review Team reviewer for this specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Document: draft-ietf-simple-presence-data-model-06
> Intended Status: Proposed Standard
> Shepherding AD: Ted Hardie
> Review Trigger: IESG Telechat, 12 December 2005
> 
> This is an update of my last call review detailing the editorial nits 
> which I found during the review plus a discussion of the intended status 
> of this document and the documents which it updates as identified by 
> Brian Carpenter.
> 
> Summary:
> Internally the document is ready to progress give or take a few 
> editorial nits.   However  it needs to be clarified how it relates to 
> the two documents which it asserts that it updates given that the 
> intended status of this document is PS and one of the two updated 
> documents is an Informational.
> 
> The introduction implies that this document updates RFC2778 and RFC3863; 
> this needs to be stated both in the abstract and the document header.  
> This gives rise to some concerns over the status of the document and the 
> references to the two documents which it updates.   There is no problem 
> with RFC3863 which is a  PS but RFC2778 is Informational and is 
> currently classified as an Informative reference.  So two questions:
> - Is this a legitimate way to update RFC2778, and
> - If so, should RFC2778 be a 'downref' Normative reference?

The specification actually only extends RFC3863. I've added a sentence
to the introduction explicitly stating this.

> 
> Editorial:
> s2, para 1:  s/new terms/ additional terms over and above those defined 
> in [RFC2778]/

added.

> 
> s2, definition of Occurrence: s/document/Presence Information Format 
> (PIDF) document/

fixed.

> 
> s2, definition of Status: On first reading I found the original 
> definition confusingly vague and apparently meaningless. After reading 
> the rest of the document it became clearer what was intended.  Maybe my 
> alternative would be clearer on first reading but it is now difficult to 
> tell.  s/Generally dynamic information about a service, person or
>      device./Information about the disposition of a service, person or 
> device which is generally expected to change with time (contrast with 
> Characteristic)./


> 
> s2, definition of Characteristic: s/Generally static information about a 
> service, person
>      or device./Information about the disposition of a service, person 
> or device which is generally static over time (contrast with Status)./

OK, how about this:

<t hangText="Status:">Presence information about a service, person
or device that typically changes over time, in contrast to
characteristics, which are generally static.</t>

<t hangText="Characteristics:">Presence information about a service,
person or device that is usually fixed over time, and descriptive in
nature. Characteristics are useful in providing context that identifies the
service or device as different from another service or device.
</t>


> 
> s3: 'They are the presentity URI...'  The labelling of the diagram seems 
> to better convey that the URI is (as I understand) it a label or 
> identifier for the presentity rather than the presentity URI itself 
> being a componen t of the model.  Maybe this should be 'They are the 
> presentity, identified by a URI,....'

OK, changed.

> 
> s3: s/description about the service/description of some aspect of the 
> service/

done.

> s3: s/affilitated/affiliated/

fixed

> 
> s3.1, para 1: 'pres URI' looks like a mistake: s/pres URI/URI from the 
> Presence (pres) scheme/

done

> 
> s3.1, para 3: s/Independent of its scheme/Irrespective of the scheme 
> feom which the URI is taken/

done

> 
> s3.3, para4: s/There is no central registry by which one goes finds the
>   identifiers for each service.  Consequently, each service does not
>   have a single "service" attribute that with values of "ptt" or
>   "telephony".  That does not mean that these consolidated monikers
>   are n't useful;/There is no central registry to which one goes finds the
>   identifiers for every service.  Consequently, each service does not
>   have a single "service" attribute with values such as "ptt" or
>   "telephony".  That does not mean that these consolidated monikers
>   are not useful;/

fixed; also cleaned up the first sentence which was awkward.

> 
> s3.3, para 4: s/is less meaningful to create a summarization/is less 
> meaningful as a way of creating a summarization/

done

> 
> s3.3.1, para 1: s/auomata/automaton/

done

> 
> s3.3.1, para 1: s/RFC2533, for example[11]/RFC2533[11], for example,/

fixed

> s3.3.1, para 1: s/(this service only does voice)/(e,g., this service 
> only does voice)/

fixed

> 
> s3.3.2, para 1: s/are the instructions/provides the instructions/

ok

> 
> s3.3.2, para 6: s/Because the reach information serves as an idenfifier 
> for a service, it also serves as a way to figure out whether something 
> is one service or two./Because the reach information serves as an 
> identifier for a service, it also serves as a way to figure out whether 
> a communications capability should be represented as one service or more./

done

> 
> s3.3.2, para 6: s/can do audio/is capable of audio/

fixed

> 
> s3.3.2, para 8: s/are most ideally/is most ideally/

ok

> s3.3.2, para 8: s/amount of presence/number of presence/

ok

> s3.3.2, para 8: s/bceome incresingly smal/decrease correspondingly/

changed

> 
> s3.3.2, para 9: 3 instances of enum s/b ENUM maybe?

it shows up in either form, but technically it is an acronym (sort of), 
so I changed it to capitals.

> 
> s3.3.2, para 9: I think some explanation of the dip indicator might 
> help.  This is very obscure to the casual reader.

Actually, this needs to be removed entirely. Much has transpired in the 
world of enum since this text was first written, and these days, the dip 
indicator is not a good indicator that the tel URI is a phone on the 
PSTN (for your own information, the dip indicator is attached to a tel 
URI to indicate that a previous entity tried to look that number up in 
the enum DB, and the lookup failed, so don't bother doing it again. This 
mirrors a similar flag in the ss7 networks to indicate that a telephone 
number had already been looked up in the number portability databases, 
and thus doesnt need to be looked up again). The same is true for its 
absence from the enum databases.


> s3.3.2, para 9: s/it means/it generally means/ perhaps?

the new text reads:

<t>
The tel URI <xref target="RFC3966"/> shares similar properties with a
URN, and the same considerations apply. If, for example, the telephone
number exists in ENUM <xref target="RFC3761"/> and multiple ENUM
services are defined, including voice and messaging, it is likely that
very little characteristic information can be included in that
service. If, however, a tel URI has only a single ENUM service
defined, and it refers to a telephone service on
the PSTN, more can be said about its characteristics, status,
and relative priority.
</t>


> 
> s3.3.2, para 10: s/reachable by potentially/reachable through, 
> potentially,/

changed to:

It is important to point out that there can be a many to one mapping
of reach information to a service. That is, a particular service can
potentially be reachable through an infinite number of reach
information sets.

> s3.3.2, para 10: s/infomation/information sets/

added.

> 
> s3.3.2, para 11: s/service URI/service URIs/

thats in para 10, fixed.

> 
> s3.3.4, para 1: s/either closed or open/either "closed" or "open"/

consistenly quoting both of them now.

> s3.3.4, para 1, last sentence: s/the communications/that communications/

done

> 
> s3.3.4, para 2: s/eventually get/eventually gets/

fixed

> 
> s3.3.4., para 4: s/s roaming/is roaming/

changed to, "it is roaming"

> 
> s3.4, para 3: s/compostitor/compositor/

fixed

> 
> s3.4, para 5: s/RECOMMEND/RECOMMENDED/

hmm, I don't see this problem...

> 
> s3.4, para 12 (I think): s/apriori/a priori/

fixed

> 
> s3.5, para 2 and para 5: s/automata/automaton/

fixed

> 
> s7: The introduction claims 'examples' but there is only one.

It doesn't, actually. It says:

This specification defines these concepts more fully by means of a
    presence data model, and concretely defines how to take real world
    systems and map them into presence documents using that model.


'concretely defines how to take' is not referring to specific examples, 
but rather to the set of procedures defined through the document that 
explain how to use the data model.

> 
> s7, next to last para: s/voip/VoIP/

fixed all instances.

Thanks for your comments!

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com



_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art