Subject: Re: [Dime] Status of draft-ietf-dime-capablities-update?

From: Sebastien Decugis <[email-masked]>
Date: Thu, 07 Jan 2010 16:14:30 +0900

Hi Hannes, Glen, and all,

Sorry to reply only now. I actually don't see how the latest comments
([1], [2]) were addressed in the new version... Can someone clarify?

Thank you,
Best regards,
Sebastien.
[1] http://www.ietf.org/mail-archive/web/dime/current/msg03827.html
[2] http://www.ietf.org/mail-archive/web/dime/current/msg03829.html

Le 17/12/2009 07:10, Glen Zorn a écrit :
> Tschofenig, Hannes (NSN - FI/Espoo) [mailto://[email-masked]]
> writes:
>
>   
>> Hi all,
>>
>> Glen has updated draft-ietf-dime-capablities-update as promised during
>> the IETF meeting.
>> Sebastien has provided some feedback on security aspects earlier.
>> Sebastien, have you looked at the most recent draft version?
>>
>> Glen, could you post a status update? 
>>     
> Sorry, I don't track the status of drafts, preferring to leave that to WG
> Chairs ;-).
>
>   
>> Are there open issues with the document?
>>     
> Can't think of any, no.
>
> ...
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>
>   

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 7 Jan 2010 11:00:36 +0200

Glen will explain how these comments have been incorporated. 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Sebastien Decugis
>Sent: 07 January, 2010 09:15
>To: [email-masked]
>Subject: Re: [Dime] Status of draft-ietf-dime-capablities-update?
>
>Sorry to reply only now. I actually don't see how the latest 
>comments ([1], [2]) were addressed in the new version... Can 
>someone clarify?
>
>Thank you,
>Best regards,
>Sebastien.
>>> Glen has updated draft-ietf-dime-capablities-update as promised 
>>> during the IETF meeting.
>> Sorry, I don't track the status of drafts, preferring to 
>leave that to 
>> WG Chairs ;-).
>>
>>

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 7 Jan 2010 17:30:41 +0700

> Glen will explain how these comments have been incorporated.

They haven't been.  I cannot understand how [1] makes any sense (how can you
change the IP address on a running IPsec SA and have it continue to run?).
[2] says “Now if during operation the Diameter server "retracts" one of its
applications the draft says that the client should disconnect the transport
layer connections. Unfortunately from the point of view of the application
it is not clear what to do because such a behavior was not anticipated
before the capabilities-update app.”  However, neither of these statements
is accurate, AFAICT.  The draft says that the transport connection should be
disconnected if two peers no longer share _any_ applications in common, not
if _one_ application disappears; furthermore, IIRC, Diameter was designed
precisely with the possibility that servers could disappear without warning
in mind.  If an application can’t handle that, there seems to me to be a
much bigger problem with the implementation.  I have no problem modifying
the draft in conformance with WG consensus, but these comments make no sense
to me so I’m not willing to make any changes unilaterally.  .  If they make
sense to the chairs, then they can instruct me to modify the text as they
see fit.

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 07 Jan 2010 19:53:18 +0900

Hi,

Le 07/01/2010 19:30, Glen Zorn a écrit :
> I cannot understand how [1] makes any sense (how can you
[1] also talks about the concerns with changing the Diameter Id (i.e.
content of the Origin-Host or Origin-Realm) in the CUR/CUA. I don't see
where it is explained in the new revision. Please point me to the
appropriate text if I am missing it.

(Not related to the discussion, but it is perfectly possible to change
the IP endpoints of a running SA... It is even mandatory in case of
mobile IPv6 for example...)

Best regards,
Sebastien.

---

From: "Andrea Moise" <[email-masked]>
Date: Fri, 8 Jan 2010 15:46:54 -0500

Hi Glen, Sebastien, and all,

I have been a silent reader of dime mailing list for a long time and would like to mingle on the discussion about http://tools.ietf.org/html/draft-ietf-dime-capablities-update-01. 

It would be interesting to know exactly what capabilities can be modified by a CUR message. The document says:

"This message allows the update of a peer's capabilities (protocol version number, supported Diameter applications, etc.)."

Yet, the only update that is described in detail mentions application id. Is an update of protocol version number really in the scope of the document? If protocol version number is the "version" field in the message header, it seems unlikely to me that an application can support a new protocol version without restarting connections.

Also, the previous draft mentioned an update of peer identity. The statement was removed. Does this mean that a CUR message does NOT allow updating the Origin-Host, Origin-Realm AVP, and Host-IP-Address?

==> What do you think about listing AVPs whose content MUST/MAY/MUST NOT be analyzed by the application to see what has changed? This would help applications know that to do in order to support Diameter Capabilities Updates.

Best regards,

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sebastien Decugis
Sent: Thursday, January 07, 2010 5:53 AM
Cc: [email-masked]
Subject: Re: [Dime] [SPAM] RE: Status of draft-ietf-dime-capablities-update?

Hi,

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 10 Jan 2010 11:22:29 +0700

Andrea Moise [mailto://[email-masked]] writes:

> I have been a silent reader of dime mailing list for a long time and
> would like to mingle on the discussion about
> http://tools.ietf.org/html/draft-ietf-dime-capablities-update-01.
> 
> It would be interesting to know exactly what capabilities can be
> modified by a CUR message. The document says:
> 
> "This message allows the update of a peer's capabilities (protocol
> version number, supported Diameter applications, etc.)."
> 
> Yet, the only update that is described in detail mentions application
> id. Is an update of protocol version number really in the scope of the
> document? If protocol version number is the "version" field in the
> message header, it seems unlikely to me that an application can support
> a new protocol version without restarting connections.

True; that should probably be removed.

> 
> Also, the previous draft mentioned an update of peer identity. The
> statement was removed. Does this mean that a CUR message does NOT allow
> updating the Origin-Host, Origin-Realm AVP, and Host-IP-Address?

Yes, though, it might be useful to be able to advertise changes in IP
address if SCTP is used as the transport.

> 
> ==> What do you think about listing AVPs whose content MUST/MAY/MUST NOT
> be analyzed by the application to see what has changed? This would help
> applications know that to do in order to support Diameter Capabilities
> Updates.

I think that the problem is that the set of AVPs is malleable: it can change
over time, so making this kind of list seems problematic.

...