approving minutes from May 13

new issues

Wu: describes issue
... Min supported should be subscribe/unsubscribe
... will make ws-eventing light weight and useful
... mandatory features should be the common denominator
... can't profile out required features

resolution: new issue accepted for
consideration

reviewer comments

back to 9781

Katy: what if they tried to use
Renew? would WSA fault be returned?

Wu: WSA would cover it and we'd add a
policy assertion

Katy: why were they made
mandatory?

Wu: explains why he thinks they
should be required
... makes impl harder to do timers - assuming expires is
supported

Dug: feel strongly that GetStatus
should remain - w/o it we have no way to know if a subscription is
still alive
... Renew, a little less strong but still leaning towards it since
its cheap to support

Rick Landau joined the call - from dmtf wsman
wg

continue on mailing list

WS-I BP WSDL issue

Gil: WSDL is now in its own
section
... we can update our ref to section 5

Bob: ETA on publication?
... need a board approved draft
... not completed profile, just board approved draft, to go to
CR
... for REC we need a completed profile

9609

Rick: talks about the requirement
... permit enumResponse to include the results of the first pull
operation
... w/o optimization then just the enumContext is returned

Bob: during f2f we talked about
this
... during Pull you specify a lot of options
... Enumerate() would want to have the same options
... so why not just merge Pull and Enumerate into one op
... fold Enum into Pull

Rick: would have done it the other
way but same end result

Tom: reaction was to the title "small
result sets", just an optimization which might mean everything, but
could just mean the first set
... didn't catch that it was for both, large and small result
sets

Rick: trying to reduce the network
traffic by one MEP

Bob: reaction?

Tom: pull has lots of parameters -
adding this might not be that bad

Dug: would prefer this to dup'ing
Pull parameters into the Enumeate

Gil: we talked about complexity
around dup'ing Enum params/faults.... in Enumerate
... the other way, getting rid of enumerate(), we lose the ability
to setup many enums w/o actually pulling anything
... we lose this bit of functionality

Bob: couldn't you just pull for zero
items

Gil: I recall people saying "blah"
:-)
... no strong advocate for the usecase
... during the f2f
... I'm concerned about the tie to CIM's notion of polymorphism

Rick: understood - that's why they
changed the focus to be on just reducing network traffic
... network traffic has been a bit issue for impls

Bob: if we proposed Pull+implicit
Enum, would that meet your needs?

Rick: yes

Ram: would prefer to have two
independent verbs
... there are things you do during Enum vs Pull
... but see the need for the optimization
... proposal from Dell is preferred

Dug: Gil can you elaborate on the
polymorphism thing?

Gil: don't worry about it
... just focus on network traffic

<gpilz> where is Rick's latest
proposal?

Tom: how often will the params
change?
... not a big change

Dug: duping everything across Enum
and Pull is going to be ugly and a pain for extensions who will
need to do the same thing

Bob: u ok with a Pull of zero
items?

Dug: yes

Bob: Ram, you?

Ram: need to examine the practical
implications of both
... no strong opposition at this time, but no final position

Bob: who will write up a
proposal?

Ram: I like Dell's proposal

Tom: adding params from Pull into
Enum might not be that bad

Bob: Ram are you willing to promote
Dell's proposal?

<Tom_Rutt> I think that if every
pull has the same size parameters, it would make sense to put the
params on the enum request, allowing the first pull and subsequent
pulls to use those size params.

Ram: wsa:Action is enough to know
what to do
... preference is to keep it separate
... if WG wants to merge into a pull I'll need more time

Bob: what about a Pull child to
Enum?
... basically batching
... all children of Pull can appear under Enumerate/Pull

Tom: pull child to enum might
work

Gil: interesting idea but it might
not be that easy
... what about maxTime?
... would the enumContext still be created during the waiting
time?
... probably

Bob: same issue if we merged pull and
enum

Gil: yes applies to all cases
... this is the complexity we were talking about

Bob: there is no escaping the
complexity :-)

Tom: leaning now towards CWNA
... keeping the http connection open isn't that expensive
... Rick, why do you see this as an important optimization when the
data on the enum is small and you can just keep the connection
open?

Rick: our experience is that the # of
turn-arounds is the problem
... not keeping the connections open makes it worse, but we do keep
them open today
... its the turn-around that's the issue
... its double in the current model
... its not the tear-down of the tcp/ip connection

9613

Bob: been involved in a ton of
discussions about persistence - how long? how is it done?
... across failure of persistence mechanisms
... is it impl specific ?
... subscription lasts until an unsubscribe, times out, any other
reason
... can we really define what "persistent" means?