Re: [radext] Proposed new charter text

[Alan DeKok <[e-mail]>]

On Mar 23, 2015, at 12:14 AM, Peter Deacon <[e-mail]> wrote:
> RFC5176 Section 2.3 explains atomicity requirements while CoA or DM requests match multiple sessions.

  OK… I hadn’t noticed that before.  It still doesn’t change my opinion of the charter changes, though,

> This an important reason why I believe state will be required in some cases to facilitate correlation in the event insufficient information is available to do so.

  Correlation of what?  I find that sentence so vague that I don’t know what it means.

  The draft implements CoA proxying based on Operator-Name.  This is sufficient for all proxies to get the packet to the visited domain, independent of anything else in the packet.  The Operator-Name *is* “sufficient information” for all proxies.  The proxies need no other information, and can safely ignore every single other attribute in the packet.

  The draft allows for the visited network to get the packet to the NAS based on Operator-NAS-Identifier.  This is sufficient for the visited network to get the packet to the correct NAS, independent of anything else in the packet.  The Operator-NAS-Identifier is “sufficient information” for the visited network.  It needs no other information, and can safely ignore every single other attribute in the packet.

  The rest of the information in the packet is interpreted by the NAS.

> I believe the mechanism to support can be fully opaque like Operator-NAS-Identifier and fully implementation dependant I advocate only enabling communication channel exist.

  To support… what?  You’re making some kind of assumption, and not explaining it here.

> I believe Operator-NAS-Identifier's constraints make it insufficient for this role otherwise it would be sufficient.  Section 3.1 20 octets language is insufficient and automatic removal of NAS identifying attributes may be counterproductive.

  Why?

> I do not advocate for fixing Dynamic authorization or session identifying attributes.  I do not advocate for fixing Proxy.  In previous remarks possible courses of action were enumerated to assist in demonstrating why state is needed by implementations.

  I read those remarks.  I still have no idea why you think state is needed.

> With regards to CoA draft I would support either a separate State attribute or loosening constraints of Operator-NAS-Identifier.

  A separate State attribute to do… what?

> Regardless of concerns specific to CoA draft appreciate any consideration of my recommendation.

  I have no idea what you’re recommending.  Please explain.  Your remarks are cryptic and unhelpful.

  Alan DeKok.