Re: [stir] Proposal for update of erratum #6519

["Gorman, Pierce" <[e-mail]>]

+1 on Alec’s 3 proposed changes.

 

Best regards,

 

 

Pierce Gorman
Principal Engineer Sys Arch

 

Direct 913.439.4368 |  [e-mail] <mailto:[e-mail]> 

 <http://www.t-mobile.com/> t-mobile.com  | Follow T-Mobile on  <https://twitter.com/tmobile> Twitter,  <https://www.facebook.com/TMobile> Facebook and  <http://instagram.com/tmobile> Instagram  



 

From: Alec Fenichel <[e-mail]> 
Sent: Tuesday, April 20, 2021 11:33 AM
To: Roman Shpount <[e-mail]>
Cc: Peterson, Jon <jon.peterson=[e-mail]>; Peterson, Jon <[e-mail]>; Marc Petit-Huguenin <[e-mail]>; IETF STIR Mail List <[e-mail]>; Russ Housley <[e-mail]>; Christer Holmberg <[e-mail]>
Subject: Re: [stir] Proposal for update of erratum #6519

 

Roman,

 

Makes sense. I think a new version would be great. Proposed changes:

 

1.	Require quotes around ppt param value
2.	Make info param optional when using full form PASSporTs to make OOB easier for transit providers
3.	Allow info param to match claims other than x5u (e.g., jku, etc.) to support DLT and other future PASSporT extensions that don’t use x5u

 

Sincerely,

 

Alec Fenichel

Senior Software Architect

[e-mail] <mailto:[e-mail]> 

[phone]

TransNexus

 

From: Roman Shpount <[e-mail] <mailto:[e-mail]> >
Date: Tuesday, April 20, 2021 at 12:02
To: Alec Fenichel <[e-mail] <mailto:[e-mail]> >
Cc: Peterson, Jon <jon.peterson=[e-mail] <mailto:jon.peterson=[e-mail]> >, Peterson, Jon <[e-mail] <mailto:[e-mail]> >, Marc Petit-Huguenin <[e-mail] <mailto:[e-mail]> >, IETF STIR Mail List <[e-mail] <mailto:[e-mail]> >, Russ Housley <[e-mail] <mailto:[e-mail]> >, Christer Holmberg <[e-mail] <mailto:[e-mail]> >
Subject: Re: [stir] Proposal for update of erratum #6519

Alec,

 

My personal opinion is that we should try to organize an open SipIt interop event for both STIR and SHAKEN implementations. Based on the interop results, it might be good to do a new version of RFC 8224.

 

Meanwhile, we really need this errata so that we can deal with current interop issues.

 

Best Regards,


_____________
Roman Shpount

 

 

On Tue, Apr 20, 2021 at 11:31 AM Alec Fenichel <[e-mail] <mailto:[e-mail]> > wrote:

Jon,

 

Understood. Then maybe we could just leave it as is until RFC 8224 is updated? Is there any implementation out there that doesn’t support receiving with or without quotes?

 

Sincerely,

 

Alec Fenichel

Senior Software Architect

[e-mail] <mailto:[e-mail]> 

[phone]

TransNexus

 

From: Peterson, Jon <jon.peterson=[e-mail] <mailto:[e-mail]> >
Date: Tuesday, April 20, 2021 at 11:05
To: Alec Fenichel <[e-mail] <mailto:[e-mail]> >, Peterson, Jon <[e-mail] <mailto:[e-mail]> >, Roman Shpount <[e-mail] <mailto:[e-mail]> >, Marc Petit-Huguenin <[e-mail] <mailto:[e-mail]> >
Cc: IETF STIR Mail List <[e-mail] <mailto:[e-mail]> >, Russ Housley <[e-mail] <mailto:[e-mail]> >, Christer Holmberg <[e-mail] <mailto:[e-mail]> >
Subject: Re: [stir] Proposal for update of erratum #6519

 

I mean, no, it’s just pushy. It’s the same reason we don’t propose that you MUST only accept quoted. Given that it was the ambiguity in the original spec that caused this problem, I’m a little hesitant to be that pushy.

 

Maybe for the errata we could be less pushy, but when we (inevitably, someday) do an actual update or bis to RFC8224, we could be more pushy about it. 

 

Jon Peterson

Neustar, Inc.

 

From: stir <[e-mail] <mailto:[e-mail]> > on behalf of Alec Fenichel <alec.fenichel=[e-mail] <mailto:[e-mail]> >
Date: Tuesday, April 20, 2021 at 7:59 AM
To: "Peterson, Jon" <jon.peterson=[e-mail] <mailto:[e-mail]> >, Roman Shpount <[e-mail] <mailto:[e-mail]> >, Marc Petit-Huguenin <[e-mail] <mailto:[e-mail]> >
Cc: IETF STIR Mail List <[e-mail] <mailto:[e-mail]> >, Russ Housley <[e-mail] <mailto:[e-mail]> >, Christer Holmberg <[e-mail] <mailto:[e-mail]> >
Subject: Re: [stir] Proposal for update of erratum #6519

 

Is it really a problem to just say that you must (or must not, either way) include quotes and be done? STI-AS and STI-VS implementations will need to be updated frequently over the next few years due to all of the new PASSporT extensions, so expecting implementations to add/remove quotes seems reasonable. Implementations could accept both values at their discretion, even if it violates the standard.

 

Sincerely,

 

Alec Fenichel

Senior Software Architect

[e-mail] <mailto:[e-mail]> 

[phone]

TransNexus

 

From: stir <[e-mail] <mailto:[e-mail]> > on behalf of Peterson, Jon <jon.peterson=[e-mail] <mailto:[e-mail]> >
Date: Tuesday, April 20, 2021 at 10:47
To: Roman Shpount <[e-mail] <mailto:[e-mail]> >, Marc Petit-Huguenin <[e-mail] <mailto:[e-mail]> >
Cc: IETF STIR Mail List <[e-mail] <mailto:[e-mail]> >, Russ Housley <[e-mail] <mailto:[e-mail]> >, Christer Holmberg <[e-mail] <mailto:[e-mail]> >
Subject: Re: [stir] Proposal for update of erratum #6519

 

Inline.

 

From: stir <[e-mail] <mailto:[e-mail]> > on behalf of Roman Shpount <[e-mail] <mailto:[e-mail]> >
Date: Monday, April 19, 2021 at 6:57 PM
To: Marc Petit-Huguenin <[e-mail] <mailto:[e-mail]> >
Cc: IETF STIR Mail List <[e-mail] <mailto:[e-mail]> >, Russ Housley <[e-mail] <mailto:[e-mail]> >, Christer Holmberg <[e-mail] <mailto:[e-mail]> >
Subject: Re: [stir] Proposal for update of erratum #6519

 

On Mon, Apr 19, 2021 at 7:56 PM Marc Petit-Huguenin <[e-mail] <mailto:[e-mail]> > wrote:

A literalist.  Fantastic.



That was not my understanding.

 

We can go back to the recording to check on the decision.

 

More importantly, what is the normative strength of "be tolerant to the absence of quotes when receiving"? Is this MUST accept quotes? SHOULD accept quotes?

 

In the sentence "Implementations SHOULD use quotes around the token when sending", what would be the valid use cases when implementations are allowed not to use quotes?

 

My understanding is that SHOULD implies well know exceptions.

 

The exception we are aware of is that implementations exhibiting this behavior exist. It is, in other words, for backwards compatibility reasons. 

 

Regardless of what the recording says (we were kinda all over the place, if I recall), I think I agree that the right semantics are that you MUST accept quoted and unquoted, and SHOUD send quotes (the exception to the SHOULD being backwards compatibility). If we said you MUST send quotes, well, then implementations that don’t are violating the spec. As you pointed out, it’s kind of a mixed bag at the moment out there in terms of where implementations are. 

 

Jon Peterson

Neustar, Inc.