Re: [stir] draft-asveren-stir-p-charge-info

[Christer Holmberg <[e-mail]>]

Hi,

Q1: As the purpose of draft-york-p-charge-info is document existing implementations and usage of the PCI header field, the first question is whether we should define “enhancements” and new usages of the PCI header field?
[TOLGA] draft-asveren-stir-p-charge-info does not add new functionality for P-Charge-Info per se. It merely add verification capability for it.

True, but it is not documenting existing implementations anymore.

Q2: You should describe in what kind of environments this is needed.
[TOLGA]Noted and will add it in the next version -among other things-.

Q3: As draft-york-p-charge-info is to be published as an Informational RFC, should draft-asveren-stir-p-charge-info also be Informational? A PASSporT extension is “Specification Required”, so I assume an Informational RFC qualifies.
[TOLGA]thanks for the feedback. I don’t have a problem with that and would follow what is required from procedures perspective and will change it to “Informational”.

I was also going to comment on the fact that you don’t reference the york draft, but Keith already brought that up :)

Q4: The text in Section 4.3 says:


   "An entity dropping P-Charge-Info MUST drop the corresponding Identity

   header with "ppt" parameter value of "pci”."

        First, I assume you mean “an entity supporting the pci PASSporT”?

        Second, entities that only support the PCI header field, but not the pci PASSporT, will not remove the corresponding Identity header field. I think you need some text about that.
 [TOLGA] I think this depends on what is meant by “supporting pci PASSPortT”. An entity can still remove it if it is aware of “pci” but does not support it in terms of adding/verifying pci Identity. OTOH, an entity completely unaware of “pci” wouldn’t be able to do so.

Correct – that is the use-case I had in mind.

Regards,

Christer