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

["Peterson, Jon" <[e-mail]>]

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.