Skip to main content

Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization
RFC 8443

Yes

(Adam Roach)
(Spencer Dawkins)

No Objection

Alvaro Retana
(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Eric Rescorla)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)
(Terry Manderson)

No Record


Note: This ballot was opened for revision 03 and is now closed.

Alvaro Retana No Objection

(Adam Roach; former steering group member) Yes

Yes (for -03)

                            

(Ben Campbell; former steering group member) (was Discuss) Yes

Yes (2018-05-17 for -05)
Thank you for addressing my first discussion point and comments. I still have a concern on the second discuss point:

§7.2: 
   o  The verification of the signature MUST include means of verifying
      that the signer is authoritative for the signed content of the
      resource priority namespace in the PASSporT."

The authors explained via email that they expect this to depend on some ATIS work. I understand that such work is in progress, but has not reached the point of being citable. I don't want to see this document blocked on that work, so I cleared my discuss. However, I still think it would be a good idea to add some scoping text early in the document to the effect that this mechanism is intended for environments where some means of verifying that the signer is authoritative is available. (In addition to keeping the normative text in §7.2)

(Spencer Dawkins; former steering group member) Yes

Yes (for -03)

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -03)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -03)

                            

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2018-04-18 for -03)
I support Ben's discuss.

Thank you for working with the secdir reviewer to address those
comments; I think it will really improve the document.

In a similar vein, I wonder if this document would be easier to read
if it used less formal description terms for protocol elements that
are currently referred to by using the actual protocol element (with
quotes around the name).  For example, "SIP resource priority
header" instead of "'Resource-Priority' header field", or "priority
indicator" instead of "'namespace"."priority value"'.

I'm a little confused why the new registry created in Section 6.2 is
tied to the "resource priority header" (rph) name, when the discussion
in Section 5 has some potential envisioned use cases that are
broader than resource priority.

As Ben notes, there are some stale references.  Please double-check
the referred section numbers as well; in particular "Section 10.1 of
[4474bis]" does not exist in the only February-2017 verions of that
draft.

Section 7.2 uses "authority" in a couple of different senses; it
might be easier on the reader to refer to the authority (protocol
participant) as being "authoritative for the content of [stuff] that
it signs".

(Deborah Brungard; former steering group member) No Objection

No Objection (for -03)

                            

(Eric Rescorla; former steering group member) No Objection

No Objection (for -03)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -03)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -03)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -03)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -03)

                            

(Ignas Bagdonas; former steering group member) No Record

No Record (2018-04-19 for -03)
NO RECORD, ran out of time for reviewing this document.