Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10: Comments that shouldn't be controversial

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 16 Oct 2013 11:59:07 +0200

Hi Barbara,

On 07/31/2013 07:10 PM, STARK, BARBARA H wrote:
> I've grouped all of my comments that I don't expect to be controversial (or to require much discussion) in this email.
> I also provided the authors with a set of spelling errors that I'm not going to send to the list.
>
> ----------
> 2. Terminology
>     'Conditional':  means they must be present unless the specified
>     condition is met, in which case the they may be present.
>
> Comment 23: "unless the specified condition is met" is not right. One possibility would be "if the specific condition is met".

James changed the writeup of the terminology section to:

-----

   In the data block definitions, see Section 3, the values for the
    "Use:" label are specified as one of:

    'Required':  means they MUST be present in the data structure.

    'Conditional':  means they MUST be present if the specified
       condition(s) is met.  They MAY be present if the condition(s) is
       not met.

    'Optional':  means they MAY be present.

-----
> -----------
> 3.1.2.  Data Provider ID
>
>     Use :  Conditional.  Must be provided if the service provider is
>        located in a jurisdiction that maintains such ids .  Devices are
>        not required to provide it.
>
>     Description:  A jurisdiction specific code for the provider  shown in
>        the <DataProvidedBy> element that created the structure of the
>        call.  This data SHOULD be provided if the local jurisdiction
>        maintains such an ID list.  For example, in North America, this
>        would be a "NENA Company ID".  Devices SHOULD NOT use this
>        element.
>
> Comment 24: Normative language from Description belongs in Use

Text changed to:

-----

3.1.2.  Data Provider ID

    Data Element:  Data Provider ID

    Use:  Conditional.  This data SHOULD be provided if the service
       provider or access provider is located in a jurisdiction that
       maintains such ids.  For example, in North America, this would be
       a "NENA Company ID".

    XML Element:  <ProviderID>

    Description:  A jurisdiction specific code for the access provider or
       service provider shown in the <DataProvidedBy> element that
       created the structure of the call.  NOTE: In the US, the NENA
       Company ID must appear here.  Additional information can be found
       at http://www.nena.org/nena-company-id.  The NENA Company ID MUST
       be in the form of a URI in the following format:
       urn:nena:companyid:<NENA Company ID>

    Reason for Need:  Inform the call taker of the identity of the entity
       providing the additional call data structure.

    How Used by Call Taker:  Where jurisdictions have lists of providers
       the Data Provider ID provides useful information about the data
       source.

-----

> ------------
> 3.1.6.  Data Provider Languages(s) Supported
>
>     Use:  Conditional
>
>     Description:  The language used by the entity at the Data Provider
>        Contact URI as an alpha 2-character code as defined in ISO
>        639-1:2002 Codes for the representation of names of languages --
>        Part 1: Alpha-2 code Multiple instances of this element may occur.
>        Order is significant; preferred language should appear first.
>        This data is required if a Data Provider Contact URI is provided.
>        The content must reflect the languages supported at the contact
>        URI.
>
> Comment 25: Conditional on what? Should the conditional sentence in Description (penultimate sentence) be moved to Use to be consistent with other Use fields?
> Comment 26: Since Contact URI is required, and this field is conditional upon a required field, doesn't that make this required?

Fixed. Turned into 'required'.

> ------------
> 3.3.6.  Device/Service Specific Additional Data Structure
> VEDs / VEDS
> Comment 26: I don't know this acronym. Can you spell it out? And use it consistently (VEDs or VEDS)?

Done.

> ------------
> 7.  Security Considerations
> PKI
> Comment 27: Spell this out.

Done.

Ciao
Hannes

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>