Subject: Re: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29

From: Randall Gellens <[email-masked]>
Date: Sun, 28 Jun 2015 18:53:06 -0700

At 3:56 PM -0700 4/30/15, Alissa Cooper wrote:

>  I have reviewed 
> draft-ietf-ecrit-additional-data-29 in 
> preparation for IETF last call. There are a 
> number of issues that need to be resolved 
> before the IETF LC can be issued, which IÕve 
> included below as substantive comments and 
> questions. There is a list of nits at the end 
> that also need to be fixed.

Thank you very much, I appreciate it.  I've 
addressed them below and the -30 has the changes.

>
>  Substantive comments and questions:
>
>  General:
>  I've asked the shepherd to validate all of the 
> XML in the document and am waiting to hear back 
> on that.

This is in progress; several small errors have 
been identified and fixed so far.

>
>  Section 1:
>  I would suggest adding this text from Section 9 
> or something like it at the end of the 
> introduction:
>
>  "Much of the information supplied by service providers and devices is
>     private and confidential; service providers and devices generally go
>     to lengths to protect this information; disclosing it in the context
>     of an emergency call is a trade-off to protect the greater interest
>     of the customer in an emergency."

I agree, done.

>
>  Section 4.1:
>  I am a little confused about how this section 
> applies when the data is being provided by the 
> device. First, this text seems to consider the 
> device to be a "service provider":
>
>  "This block is intended to be supplied by any service provider in the
>     path of the call or the access network provider.  It includes
>     identification and contact information.  This block SHOULD be
>     supplied by every service provider in the call path, and by the
>     access network provider.  Devices MAY use this block to provide
>     identifying information."
>
>  I think this would be clearer if the first 
> sentence said "any service provider in the path 
> of the call, the access network provider, or 
> the device."

I agree, done.

>
>  Then later in the section Data Provider ID, 
> Data Provider ID Series, and Type of Data 
> Provider are defined. None of these seem to 
> apply when the data is provided by the device, 
> and yet they are all listed as required. What 
> are these elements supposed to contain when the 
> data is provided by the device? I see in the 
> example in Section 6 that only Type of Data 
> Provider is included, and is listed as ÒOther,Ó 
> which seems less specific than it ideally could 
> be.

In reviewing the various elements in this block, 
I saw that in some cases there was text 
explaining how the element is set by the device 
but not in all cases.  I have added text where it 
was missing and clarified some of the other text. 
In the Type of Data Provider registry, I expanded 
the description of the "client" value to be 
"Originating client/device" to make it clear that 
this is the appropriate value when set by the 
device.

>  Section 4.1.2:
>  Is there an EENA equivalent of the NENA company 
> ID? If so, it should be mentioned here.

I am not aware that EENA has yet established such 
a registry, but the 'EENA' value is present in 
anticipation.

>  Is it the case that where a 
> jurisdiction-specific ID exists, it is 
> preferred over an FQDN? If so, that should be 
> stated explicitly.

Thanks, I have clarified the text to try to make this very clear.

>
>  Section 4.1.5:
>  "If the call is from a device, this SHOULD be the contact
>        information of the owner of the device."
>
>  What are the exception cases for this SHOULD? 
> What should this element be if it is not the 
> owner's contact info?

Normally, the device owner and user are the same, 
but when they are different, the contact info 
SHOULD be for the user, but MAY be for the owner. 
I have clarified the text to make this more clear.

>
>  Section 4.1.6:
>  By saying the other language tags are 
> independent of this language element, does that 
> mean they should be ignored? If so, that should 
> be stated explicitly.

It's not that anything is being ignored, it's 
that these are entirely separate things.  The 
field in 4.1.6 is for information to a human: it 
informs the PSAP person who needs to contact the 
data provider as to the language(s) used by the 
data provider.  If the PSAP needs to contact the 
data provider, it can be helpful to know in 
advance the language(s).  If the PSAP uses a 
communication protocol to reach the data 
provider, that protocol may have language 
facilities of its own, and if so, those are 
independent of this field.  I've clarified the 
text.

>
>  Section 4.1.9:
>  "This element is required if the Data Provider
>        type is set to "Subcontractor"."
>
>  Subcontractor is not listed as a data provider 
> type in section 4.1.4, so this doesn't quite 
> make sense.

This is supposed to say "This data is required if 
the entity providing the data is a 
subcontractor."  Thanks.

>
>  Section 4.2.1:
>  Shouldn't "use" be listed as conditional?

Yes, I agree it is more clear that way.

>  Section 4.2.3:
>  s/MUST NOT/ought not to/

Yes, I agree.

>
>  Section 4.3.4:
>  I'm curious about the kinds of "investigations" 
> that PSAPs do and how they have used unique 
> device IDs in those investigations -- could you 
> explain? At first blush this seems to require 
> over-sharing of sensitive data.

The most common situation that I'm aware of is 
repeated false/accidental calls.  If there is no 
callback number or it isn't usable, the PSAP may 
need to try and track down the device by 
contacting the service providers in the area.  In 
the case of handsets without current service, 
they may be able to determine who last had 
service.  There could be other situations where 
this might be useful (e.g., a disconnected call 
where the call taker believes there is a need for 
assistance but was not able to obtain a location 
or other information).

>
>  Section 4.4.1:
>  Are there any jurisdiction-specific rules you 
> can point to that would indicate that having a 
> single boolean "privacy" value will actually be 
> interpretable and of use by any PSAP? I find it 
> a little hard to believe that PSAPs will know 
> what actions this value is supposed to apply to 
> (e.g., display, logging, display and logging, 
> etc.) and what data fields it is supposed to 
> apply to. Without further definition (or some 
> compelling evidence that PSAPs in at least some 
> places have well-specified rules for what to do 
> when they receive this value), this indicator 
> seems pretty hand-wavy.

I know it's messy to have a single 'privacy' flag 
whose interpretation is left to each 
jurisdiction, but this exactly matches the 
semantics of the equivalent privacy indicator 
provided in some legacy emergency call systems. 
I've added some text to this effect.

>
>  Section 4.4.2:
>  Are there any xCard fields you would recommend 
> not sending for lack of relevance (e.g., 
> anniversary)?

That's a good question.  The answer is that name, 
address, and phone number(s) are the minimum, but 
anything else might potentially be useful in some 
circumstances.  I've added text to this effect.

>
>  Depending on what the answer is to my question 
> in 4.1.6 about interaction between Data 
> Provider Language(s) and language tags, there 
> might need to be text in this section as well 
> about expected behavior when both are present 
> and when the data provider is the device.

Since these are entirely separate and don't 
interact, and I've added clarifying text in 
4.1.6, I don't think anything here is needed, 
although I'm open to adding additional clarifying 
text here if you think it helpful.

>  Section 5.1:
>  The last paragraph here makes it sound as 
> though additional data is required to be sent 
> on every emergency call (i.e., every call with 
> an emergency service URN in the route header). 
> Is that the intention? If so, that needs to be 
> made more clear and should be explained earlier 
> in the document, preferably in the 
> introduction. If not, the normative language in 
> the last paragraph here needs to be fixed.

The intent is that every emergency call carry the 
information described here using the mechanisms 
described here.  I've added text to this effect 
in both the Abstract and the Introduction. 
Thanks for pointing out that it wasn't clear that 
this is the intent.

>
>  Section 6:
>  The owner/subscriber of this laptop is Hannes 
> Tschofenig. His contact tel URI is in North 
> America but his work and home are in Finland. 
> He is using a VoIP provider that provides its 
> NENA ProviderID, which I assume indicates that 
> the service is being provided in North America? 
> The VoIP provider contact person is located in 
> the UK, however. And then when the access 
> network provides the location, it is in 
> Australia.
>
>  The last bit just seems wrong to me, for a 
> plausible emergency call. The other bits seem 
> to amount to a possible (but not likely?) 
> example scenario but the details require more 
> narrative explanation in the text. 
> Alternatively, a simpler or more plausible 
> example might help readers out more.

Wow, I'm quite impressed that you went to this 
much work!  I never expected anyone to pull out 
each of these parts from an example, put them 
together, and see if they were internally 
consistent.  The least I can do is try to improve 
it, so I added 'home' entries to the xCard for 
<addr>, <tel>, and <geo> for a location within 
the U.S. to the device-provided info, moved the 
VoIP provider from London to Iowa (with 
appropriate address and time zone information), 
switched the PIDF-LO from the access network to 
be a U.S. address, and switched the access 
network provider to be an Access Network type 
rather than "other".

>
>  Section 8:
>  "Mechanisms that
>     protect against eavesdropping (such as Transport Layer Security
>     (TLS)) SHOULD be preferentially used whenever feasible."
>
>  This needs a sentence about the existing 
> deployed base of clear text SIP to explain why 
> this requirement is not a MUST.
>
>  s/HTTPS is specified/HTTPS is REQUIRED/
>
>  "Data provided by devices by reference have similar credential
>     validation issues as for service providers, and the solutions are the
>     same."
>
>  Maybe the solutions are the same, but aren't 
> the challenges of doing this for every device 
> much more significant? That seems worth mention.
>
>  s/Service providers SHOULD choose the 
> latter/Service providers ought to choose the 
> latter/
>  (otherwise this reads like a normative requirement on IMS functionality)

Thanks very much for these comments, I've made 
corrections to section 8 for all of them.

>
>  Section 10.1.1:
>  "Private entities issuing and using internally-generated IDs are
>     encouraged to register and use a unique identifier."
>
>  What is meant by "use a unique identifier"?

The idea is that some organizations, such as 
NENA, issue IDs that are unique among all IDs 
they issue, so a combination of the NENA ID and 
the fact that it is from NENA is globally unique. 
Other entities may not have an ID issued by an 
organization such as NENA, so they are permitted 
to use their domain name.  I've reworded the text 
to try and make this more clear.

>
>  Section 10.1.8:
>  It might be useful to give the experts some 
> additional criteria around weighing privacy vs. 
> utility trade-offs. E.g., if someone wants to 
> register the biometric fingerprint used to 
> authenticate a device as a device ID and few or 
> no PSAPs can actually make use of it, that may 
> argue against registering it.

I think the text "The expert should ascertain 
that ... the information [is] useful to PSAPs and 
responders to uniquely identify a device" would 
disallow a biometric fingerprint (since it isn't 
useful for a PSAP, but I'm happy to add more 
clarifying text here.

>
>  Section 12.2:
>  I think RFC 3966 should be a normative reference.

OK.

>
>
>  Nits:
>
>  General:
>  Why are some of the registry tables in the main 
> sections of the document and others are in the 
> IANA Considerations section? Seems like they 
> should all be one or the other.

I moved all the tables to be in the block definitions.

>
>  Section 2:
>  Citations for vCard and xCard should be added to the last paragraph.

Agreed, done.

>
>  Section 4.1.7:
>  This sentence seems redundant: "For encoding of the xCard this
>        specification uses the XML-based encoding specified in [RFC6351],
>        referred to in this document as "xCard"."

Yes, it should say "For encoding of the vCard."

>   ÊÊÊÊ
>  Section 4.2.1:
>  s/therefore this is/this is/

Done

>
>  s/Figure 22/Section 10.1.2/

Done

>
>  Section 4.2.2:
>  s/Figure 3/Section 10.1.3/

Done

>
>  Section 4.2.3:
>  s/Figure 23/Section 10.1.4/

Done

>
>  Section 4.3.6:
>  A reference to the IEEE 1512 spec should be included.

Done

>
>  Section 4.3.7:
>  s/which allow/that allow/

Done

>
>  "Some standards being developed by other 
> organizations" -- would be good to provide 
> citations.

I reworded the text to be simpler and avoid the reference.

>
>  Section 4.4.2:
>  Given that 4.4 says the location provided here 
> is the contact address and not necessarily the 
> location of the caller, it seems like this 
> section needs to explain a little more why a 
> call taker would use the location provided here.

I agree, and added some additional text.

>
>  Section 5.1:
>  OLD
>  A Call-info header with a purpose value starting with
>     'EmergencyCallData' MUST only be sent on an emergency call
>  NEW
>  A Call-info header with a purpose value starting with
>     'EmergencyCallData' MUST NOT be sent unless the call is an emergency call

Edited per Keith's reply to your comment.

>   Ê
>  Section 9:
>  s/The functionality defined in this document, 
> however/The functionality defined in this 
> document/

Done.

>
>  Section 10.1.2:
>  s/A s[RFC4119]hort/A short/

Previously fixed.

>
>  Section 10.1.5:
>  Seems like this section and Figure 1 should 
> both use "Token" rather than "Tokenproviderid."

Yes, done.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Few people think more than two or three times a year; I have made an
international reputation for myself by thinking once a week.
    --George Bernard Shaw

---

From: Randall Gellens <[email-masked]>
Date: Sun, 28 Jun 2015 18:55:41 -0700

Hi Keith,

Thanks for your comments.  I've addressed them in-line below, and 
changes are in -30.

At 11:45 AM +0000 5/1/15, Keith (Keith) DRAGE wrote:

>  This part of Alissa's review caught my eye because I think the 
> original intent is wrong, and therefore so is the rewrite:
>
>>  Section 5.1:
>>  OLD
>>  NEW A Call-info header with a purpose value starting with
>  Unless this document updates RFC 3261, which it does not, it cannot 
> preclude any string being sent in the purpose value.
>
>  This is nothing in the original text that is to do with 
> interoperability, after all the recipient knows from other 
> information that this is an emergency call, or not an emergency 
> call. There is therefore no need to protect for wrong usage outside 
> an emergency call.
>
>  So I believe that there is no need for any normative language here 
> and rather what is meant is:
>
>  NEW TEXT
>
>     'EmergencyCallData' only has meaning in the context of an 
> emergency call, which can
>     be ascertained by the presence of an emergency service urn in a Route
>     header of a SIP message. It has no meaning outside the context 
> of an emergency call."

The intent is not interoperability per se but rather protection.  The 
original text was trying to say "It's a really bad idea to send this 
data in anything other than an emergency call."  It's also true that 
a purpose value starting with 'EmergencyCallData.' is only defined 
for use within an emergency call; use outside this context is a Bad 
Idea as well as undefined.  Although there is an exception, which is 
private emergency call, e.g., the call leg between a vehicle and a 
service provider call center, but that's a private use between 
endpoints by prior agreement.  Another exception to Keith's proposed 
text is a test call.

I added a modified form of Keith's text:

     A Call-info header with a purpose value starting with
     'EmergencyCallData' only has meaning in the context of an
     emergency call (including test emergency calls); use in other
     contexts is undefined and is likely to unnecessarily expose
     confidential data

>
>  As a result of opening the document again I also noted the 
> following that would be worthy of comment.
>
>  Section 4.2.3:
>
>  OLD TEXT
>  ----------
>  The URI, when dereferenced, MUST
>        yield a data structure defined by the Device/service specific
>        additional data type value. 
>
>  The normative requirement here is nothing to do with the 
> dereferencing. It appears this is a requirement to keep the link 
> between the URI and the data for a period of time; the period of 
> time is not specified, but from the subsequent text would appear to 
> be for the duration a responder might be involved in the emergency 
> call.
>
>  What is the real requirement here, does it apply to something 
> within the scope of this document, and can it be tested.

The intent of the text is to specify that dereferencing results in a 
standardized data structure, which is necessary for interoperability; 
it wasn't intended to require that the reference remain valid for 
some period of time, although since you bring it up, it would be 
reasonable to require that it remain valid for a specific period of 
time after termination of the call.

>
>  Section 5
>  -----------
>
>  OLD TEXT
>
>  Every block must be
>     one of the types in the registry.
>
>  As specified this can be confused with a normative requirement. The 
> registry is transient data and therefore cannot be tested against. 
> It is also unclear what is meant by "type" as multiple types exist 
> in the document. I assume "service type". I would suggest.
>
>  "All service types used in blocks are expected to be registered"

It means the type of data block, that is, which data block, as 
registered in the Emergency Call Data Types Registry.  The document 
defines a set of data blocks and establishes a registry so that the 
set can be expanded.  The text is trying to say that any of the set 
of data blocks may be sent, and only registered blocks can be sent, 
for interoperability (the receiver must know how to interpret the 
blocks).

>
>  But it is dubious whether we need any sentence at all rather than 
> the implicit one that says "If a registry is provided for an 
> element then all values are expected to be registered".

It's the corollary of the previous sentence; that is: "One or more 
blocks [of the registered set of blocks] may be sent.  Every block 
must be [a member of the set]"

I've reworded the text to be:

    One or more blocks of data registered in the Emergency Call
    Additional Data registry, as defined in Section 10.1.9, can be
    included or referenced in the SIP signaling (using the Call-Info
    header field) or in the <provided-by> element of a PIDF-LO.  For
    interoperability, only blocks in the registry are permitted to be
    sent using the mechanisms specified in this document.

>
>  Section 9
>  ----------
>
>  OLD TEXT
>
>  Local regulations
>     may govern what data must be provided in emergency calls, but in
>     general, the emergency call system is aided by the information
>     described in this document.
>
>  /must be/is/

Agreed.

>
>  Section 10.1.9
>  --------------
>
>  OLD TEXT
>
>  This document creates a new sub-registry called 'Device/Service Data
>     Type Registry'.  As defined in [RFC5226], this registry operates
>     under "Expert Review" and "Specification Required" rules.
>
>  Expert review and Specification required are two distinct 
> categories of IANA policy. As written it might be assumed that 
> either can be used. It is sufficient to say "Specification 
> required" and then go into details about what the implicit expert 
> review associated with this policy requires.
>
>  Similar comments apply elsewhere e.g. 10.1.10

Agreed, done.

>
>  Like Alissa I would prefer that all the material that IANA has to 
> deal with is within the IANA considerations sections, and not 
> referenced back to other parts of the document (even if that means 
> duplication of text).

Alissa asked that the initial values all be in one place, either all 
in the block definitions, or all in the IANA section.  After 
discussing with my coauthors, we decided the best approach is to have 
all tables in the block definitions.

>
>  Section 10.2
>  ------------
>
>  TEXT
>
>  Note that 'EmergencyCallData'
>     is a compound value; when used as a value of the 'purpose' parameter
>     of the Call-Info header, 'EmergencyCallData' is immediately followed
>     by a dot ('.') and a value from the 'Emergency Call Data Types'
>     registry Section 10.1.10.
>
>  This text would appear to be nothing to do with the registry or the 
> values placed in the registry.

The text is adding a new value to the 'purpose' parameter value 
registry.  The fact that the new value is compound is significant.

>
>  Other comment
>  -------------
>
>  RFC 3261 contains the statement in section 16.6.
>
>  The proxy MUST NOT add to, modify,
>           or remove the message body.
>
>  As this document does not update RFC 3261, I assume any 
> intermediate SIP entity acting as a proxy can only alter the 
> Call-Info header and not add to the body. In order to add to the 
> body it must be a B2BUA. This should be identified somewhere in the 
> document.

I've added text to this effect in section 5.1

>
>>  -----Original Message-----
>>  From: Ecrit [mailto:[email-masked]] On Behalf Of Alissa Cooper
>>  Sent: 30 April 2015 23:57
>>  To: [email-masked]
>>  Subject: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29
>>
>>  I have reviewed draft-ietf-ecrit-additional-data-29 in
>>  preparation for IETF last call. There are a number of issues
>>  that need to be resolved before the IETF LC can be issued,
>>  which I've included below as substantive comments and
>>  questions. There is a list of nits at the end that also need
>>  to be fixed.
>>
>>  I've asked the shepherd to validate all of the XML in the
>>  document and am waiting to hear back on that.
>>
>>  Section 1:
>>  I would suggest adding this text from Section 9 or something
>>  like it at the end of the introduction:
>>
>>  I am a little confused about how this section applies when
>>  the data is being provided by the device. First, this text
>>  seems to consider the device to be a "service provider":
>   >
>>  I think this would be clearer if the first sentence said "any
>>  service provider in the path of the call, the access network
>>  provider, or the device."
>>
>>  Then later in the section Data Provider ID, Data Provider ID
>>  Series, and Type of Data Provider are defined. None of these
>>  seem to apply when the data is provided by the device, and
>>  yet they are all listed as required. What are these elements
>>  supposed to contain when the data is provided by the device?
>>  I see in the example in Section 6 that only Type of Data
>>  Provider is included, and is listed as "Other," which seems
>>  less specific than it ideally could be.
>>
>>  Section 4.1.2:
>>  Is there an EENA equivalent of the NENA company ID? If so, it
>>  should be mentioned here.
>>
>>  Is it the case that where a jurisdiction-specific ID exists,
>>  it is preferred over an FQDN? If so, that should be stated explicitly.
>   >
>>  Section 4.1.5:
>>  What are the exception cases for this SHOULD? What should
>>  this element be if it is not the owner's contact info?
>>
>>  Section 4.1.6:
>>  By saying the other language tags are independent of this
>>  language element, does that mean they should be ignored? If
>>  so, that should be stated explicitly.
>>
>>  Section 4.1.9:
>>  Subcontractor is not listed as a data provider type in
>>  section 4.1.4, so this doesn't quite make sense.
>>
>>  Section 4.2.1:
>>  I'm curious about the kinds of "investigations" that PSAPs do
>>  and how they have used unique device IDs in those
>>  investigations -- could you explain? At first blush this
>>  seems to require over-sharing of sensitive data.
>>
>>  Section 4.4.1:
>>  Are there any jurisdiction-specific rules you can point to
>>  that would indicate that having a single boolean "privacy"
>>  value will actually be interpretable and of use by any PSAP?
>>  I find it a little hard to believe that PSAPs will know what
>>  actions this value is supposed to apply to (e.g., display,
>>  logging, display and logging, etc.) and what data fields it
>>  is supposed to apply to. Without further definition (or some
>>  compelling evidence that PSAPs in at least some places have
>>  well-specified rules for what to do when they receive this
>>  value), this indicator seems pretty hand-wavy.
>>
>>  Section 4.4.2:
>>  Are there any xCard fields you would recommend not sending
>>  for lack of relevance (e.g., anniversary)?
>>
>>  Depending on what the answer is to my question in 4.1.6 about
>>  interaction between Data Provider Language(s) and language
>>  tags, there might need to be text in this section as well
>>  about expected behavior when both are present and when the
>>  data provider is the device.
>>
>>  Section 5.1:
>>  The last paragraph here makes it sound as though additional
>   > data is required to be sent on every emergency call (i.e.,
>>  every call with an emergency service URN in the route
>>  header). Is that the intention? If so, that needs to be made
>>  more clear and should be explained earlier in the document,
>>  preferably in the introduction. If not, the normative
>>  language in the last paragraph here needs to be fixed.
>>
>>  Section 6:
>>  The owner/subscriber of this laptop is Hannes Tschofenig. His
>>  contact tel URI is in North America but his work and home are
>   > in Finland. He is using a VoIP provider that provides its
>>  NENA ProviderID, which I assume indicates that the service is
>>  being provided in North America? The VoIP provider contact
>>  person is located in the UK, however. And then when the
>   > access network provides the location, it is in Australia.
>>
>>  The last bit just seems wrong to me, for a plausible
>>  emergency call. The other bits seem to amount to a possible
>>  (but not likely?) example scenario but the details require
>>  more narrative explanation in the text. Alternatively, a
>>  simpler or more plausible example might help readers out more.
>>
>>  Section 8:
>>  "Mechanisms that
>>  This needs a sentence about the existing deployed base of
>>  clear text SIP to explain why this requirement is not a MUST.
>>
>>  Maybe the solutions are the same, but aren't the challenges
>>  of doing this for every device much more significant? That
>>  seems worth mention.
>>
>>  s/Service providers SHOULD choose the latter/Service
>>  providers ought to choose the latter/ (otherwise this reads
>>  like a normative requirement on IMS functionality)
>>
>>  Section 10.1.1:
>>  It might be useful to give the experts some additional
>>  criteria around weighing privacy vs. utility trade-offs.
>>  E.g., if someone wants to register the biometric fingerprint
>>  used to authenticate a device as a device ID and few or no
>>  PSAPs can actually make use of it, that may argue against
>>  registering it.
>>
>>  Section 12.2:
>>  Why are some of the registry tables in the main sections of
>>  the document and others are in the IANA Considerations
>>  section? Seems like they should all be one or the other.
>>
>>  Section 2:
>>  "Some standards being developed by other organizations" --
>>  would be good to provide citations.
>>
>>  Section 4.4.2:
>>  Given that 4.4 says the location provided here is the contact
>>  address and not necessarily the location of the caller, it
>>  seems like this section needs to explain a little more why a
>>  NEW A Call-info header with a purpose value starting with
>>  s/The functionality defined in this document, however/The
>>  functionality defined in this document/
>>
>>  Section 10.1.2:
>>  Seems like this section and Figure 1 should both use "Token"
>>  rather than "Tokenproviderid."
>>  _______________________________________________
>>  Ecrit mailing list
>>  [email-masked]
>>  https://www.ietf.org/mailman/listinfo/ecrit
>>
>  _______________________________________________
>  Ecrit mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ecrit

-------------- Randomly selected tag: ---------------
Any given program costs more and takes longer.