Re: [stir] AD Review: draft-ietf-stir-passport-divert

[Adam Roach <[e-mail]>]

Thanks for the new draft. This looks good, and I'll be requesting IETF 
last call momentarily.

Please treat this as a last call comment, and address it with any other 
feedback you receive during last call:

>     The same "div" PASSporT would result if the "dest" object of the
>     original PASSporT contained an array value, such as
>     {"tn":["12155551213"],["19995551234"]}

This should be {"tn":["12155551213","19995551234"]}  (note: no brackets 
around the comma)

/a

On 11/5/19 06:07, Peterson, Jon wrote:
> Hey Adam,
>
> I do apologize, I did know the examples in here were broken when we sent out the last version, and I promised the chairs I'd patch them, but hadn't gotten around to it. The examples in the new version were generated by our implementation, I did check them against jwt.io, so hopefully everything is in order now. Also, the "div" example that showed the value of the object as an array has been fixed; that was just hasty pasting on my part.
>
> In addition to your welcome nits and clarity fixes (which are in the new version), you found a couple other good substantive ones here...
>      
>      §3:
>      
>       >  A "div" PASSporT claims set is populated with elements drawn from the
>       >  PASSporT(s) received for a call by the retargeting entity: at a high
>       >  level, the original identifier for the called party in the "dest"
>       >  array will become the "div" claim in the new PASSporT.  If the "dest"
>       >  array of the original PASSporT contains multiple identifiers, the
>       >  retargeting entity MUST select only one them to occupy the "div"
>       >  field in the new PASSporT...
>      
>      This is confusing, for a couple of reasons. While the language in RFC 8225
>      gets objects and arrays mixed up (and I need to file an errata on this), the
>      intention is clear enough to implement. However, the preceding text is
>      actually
>      ambiguous due to the confusion between "array" and "object".
>
> I did try to repair this ambiguity where the text was careless about "object", "value" and "array", and included an example showing how you select just one value from any "dest" array to be the one you are redirecting from.
>          
>      §4.1:
>      
>       >  Furthermore note that a request may also be retargeted a
>       >  second time, at which point the subsequent retargeting entity SHOULD
>       >  generate one "div" PASSporT for each previous "div" PASSporT in the
>       >  request.  This can create multiple chains of "div" PASSporTs in a
>       >  single request, which complicates the procedures that need to be
>       >  performed at verification services.
>      
>      Read literally, this doesn't just create multiple chains; it creates
>      a exponential explosion of Identity header fields. Consider a request
>      that contains two non-"div" Identity header fields that gets redirected
>      four times.
>      
> This is a good catch. I put in some text to clarify that on each redirection there is one "div" PASSporT per baseline non-div PASSporT that does not have a common "orig" and "dest". Well, I put it better than that in the text. Hopefully it's clear now, let me know if it isn't.
>
> Thanks again,
>
> Jon Peterson
> Neustar, inc.
>      
>      
>      
>