See also: IRC log
Frederick going through some of things covered in workshop
<fjh> http://www.w3.org/2007/xmlsec/ws/slides/06-zhang-ximpleware/
Essence is "Think bottom-up, rather than top-down"
klanz: staying close to current spec language forced applications to be overly complex
fjh: is it a tree model issue?
bal: perhaps use case analysis would show a better way
klanz: xpath accomodation is what makes c14n so expensive
fjh: pre-xpath model might be what we look at
bal: new c14n with not full compatibility with current might be strawman
<fjh> might want to consider looking at original canonicalization before infoset version
<klanz2> distibuting namespace declarations across the data model (i.e. the xpath data model)
<klanz2> .. is the expensive part
<fjh> klanz: XPath data model makes it expensive
<fjh> klanz: one issue is spec language that forces more complexity of implementation
<fjh> csolc: expensive to create copy of input data set
fjh: EXI may need to enter discussion
<fjh> issue - is there requirement to canonicalize/sign exi representation
<fjh> issue - can exi be used by xmlsec wg as part of solution
<fjh> issue - can spec be written to not rely on XPath data model and achieve same functionality
<fjh> e.g. maintain context information for tree nodes using stacks
looking at Ed Simon's position paper now
perhaps should wait and see if Ed will join call later
bal/klanz: family of c14n levels, select what is needed
bal: could do at least a simple one and a more complicated one
klanz: need to consider schema and non-schema aware as well
fjh: does "infoset" introduce unnecessary complexity
tlr: or is it only a vocabulary to talk about things
bal: xpath selections were
perceived as important
... xpath2 introduced more complexity?
... subsetting selection potential may help
<fjh> issue: can we limit the generality of subsetting to reduce complexity, e.g. XPath 2.0
<trackbot> Created ISSUE-3 - Can we limit the generality of subsetting to reduce complexity, e.g. XPath 2.0 ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/3/edit .
klanz: c14n will still be slow if still accomodating full xpath2
<fjh> asking about infoset generality, shorthand for need to create full model representing xml in memory and for processing
hal: do some benchmarks with representative sample documents?
<hal> specifically hotspot various implementations to see what is not worth optimizing
<fjh> issue: need to allow transforms to go between octets and nodeset
<trackbot> Created ISSUE-4 - Need to allow transforms to go between octets and nodeset ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/4/edit .
<fjh> issue: which selections from subtree are required
<trackbot> Created ISSUE-5 - Which selections from subtree are required ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/5/edit .
fjh: postpone streamable nodeset discussion until afternoon
bal, fjh, tlr: minimal c14n from early dsig work...old working draft?
sean: some perf issues are really best practices issues
fjh: ...discussion of xpath2
filter additions?
... ...propose a guest gives us more background on this?
<klanz2> Minimal Canoniclaization: http://tools.ietf.org/html/rfc3075#section-6.5.1
<klanz2> Old XMLDSIG Drafts: http://tools.ietf.org/html/draft-ietf-xmldsig-core-11
<scribe> ACTION: fjh to ask for XPath 2.0 presentation to group [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action01]
<trackbot> Created ACTION-11 - Ask for XPath 2.0 presentation to group [on Frederick Hirsch - due 2008-07-24].
<bal> this is the first WD on C14N I could find: http://www.w3.org/1999/07/WD-xml-c14n-19990729.html
ISSUE: is there requirement to canonicalize/sign exi representation
<trackbot> Created ISSUE-6 - Is there requirement to canonicalize/sign exi representation ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/6/edit .
ISSUE: can exi be used by xmlsec wg as part of solution
<trackbot> Created ISSUE-7 - Can exi be used by xmlsec wg as part of solution ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/7/edit .
ISSUE: can spec be written to not rely on XPath data model and achieve same functionality
<trackbot> Created ISSUE-8 - Can spec be written to not rely on XPath data model and achieve same functionality ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/8/edit .
<fjh> konrad: what context is there besides namespaces
jcc: ...look at XAdES for best practices ideas
<fjh> jcc: please do not redefine existing work
bal: may be asked to do timestamps, should do like XAdES did
<bal> XAdES defines some particular signed attributes that can be added to an XMLDSIG signature, along with a standard mechanism for adding signed & unsigned attributes
jcc: presenting some XAdEs slides now in workgroup
<bal> if we want to include a timestamp attribute, for example, might make sense to do it in an XAdES-compatible way
jcc: XAdES defines containers for
timestamps, not timestamps themselves
... no rqmts out of XAdES on DSig at this point
<scribe> ACTION: jcc review archive from maint. group to revisit type issue [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-12 - Review archive from maint. group to revisit type issue [on Juan Carlos Cruellas - due 2008-07-24].
fjh: look at what BSP says about DSig
ISSUE: Review WS-I BSP constraints on DSig
<trackbot> Created ISSUE-9 - Review WS-I BSP constraints on DSig ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/9/edit .
ISSUE: Perform c14n with a tree-walk rather than a nodeset
<trackbot> Created ISSUE-10 - Perform c14n with a tree-walk rather than a nodeset ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/10/edit .
<fjh> issue what would it take for XML Signature to be usable for Mail
<fjh> issue: what would it take for XML Signature to be usable for Mail
<trackbot> Created ISSUE-12 - What would it take for XML Signature to be usable for Mail ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/12/edit .
<fjh> issue: what would it take to use XML Signature for structured non-XML content
<trackbot> Created ISSUE-13 - What would it take to use XML Signature for structured non-XML content ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/13/edit .
<scribe> ACTION: klanz2 Review streaming using 2nd edition Signature [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-13 - Review streaming using 2nd edition Signature [on Konrad Lanz - due 2008-07-24].
<tlr> ACTION-1 (new WG) closed
<fjh> schema appears ok with existing interop tests
<tlr> tlr: one of the test cases turns out to have an illegitimate xml:space value
<tlr> ACTION-3 (new WG) closed
<tlr> tlr: we heard back from the OOXML folks, and they don't like the style of the schema
<tlr> http://lists.w3.org/Archives/Member/member-xmlsec/2008Jul/0020.html
<klanz2> I recalled there was an Issue around SignedInfo not having a chain of transforms it cannot be made robust against indention, besides using a custom canonicalization
<tlr> trackbot, close ACTION-169
<trackbot> ACTION-169 Produce updated cheat sheet closed
<tlr> trackbot, close ACTION-8
<trackbot> ACTION-8 Read this action's number closed
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jun/0004.html
fjh: working group members are welcome to review and comment
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2008Jun/0002.html
<fjh> tlr: XML 1.0 5th edition AC review has closed
<fjh> klanz: implication, support for character sets for element and attribute names
<tlr> status update: http://lists.w3.org/Archives/Member/w3c-ac-members/2008AprJun/0065.html
<fjh> tlr: XML 1.1 changes may be provided to XML 1.0
<fjh> tlr: namespace undeclarations will have an impact - XML Core
<fjh> issue: need to understand plans and impact of namespace undeclarations
<trackbot> Created ISSUE-14 - Need to understand plans and impact of namespace undeclarations ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/14/edit .
<fjh> need to know plan, timing for xml namespaces to effect 1.1
<fjh> what will happen to namespaces going forward
<fjh> ACTION: frederick to ask about namespaces/undeclarations in xml coordination group [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-14 - Ask about namespaces/undeclarations in xml coordination group [on Frederick Hirsch - due 2008-07-24].
<rdmiller> I just hung up and will not be participating this afternoon because of a prior commitment
<csolc> Scribe: Chris Solc
RESOLUTION: Thanks to Juan Carlos for hosting, providing excellent meals and logistics help.
fjh: use issues to track requirements for now
<fjh> Created ISSUE-15 - Minimal caching to support streaming ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/15/edit .
<fjh> Created ISSUE-16 - Backward reference for streaming - don't know what is referenced, algs ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/16/edit .
<fjh> Created ISSUE-17 - Placement of KeyInfo relative to SIgnedInfo ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/17/edit .
<fjh> Created ISSUE-18 - Data between algorithm info and digest? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/18/edit .
<fjh> Created ISSUE-19 - Placement of signature relative to signing or verification, different placement? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/19/edit .
<fjh> Created ISSUE-20 - Transform model should support streaming, filtering model ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/20/edit .
<fjh> Created ISSUE-21 - Arbitrary selection from nodeset vs XPath expressions without backward references, traversal and navigation; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/21/edit .
<fjh> Created ISSUE-22 - Requirement to validate xml before application processing, signature processing, thus need to read entire document before processing, thus not true streaming ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/22/edit .
pratik: ok to have whole doc in memory as byte array, enable validation. but avoid building DOM
<EdS> Actually, I think it may be possible to create a streaming hash function (where one does NOT have to validate an entire document to have confidence in a portion of it) if one treats the document as an authenticated dictionary. This could be quite an intersting area for XML Signature. More on authenticated dictionaries here: http://citeseer.ist.psu.edu/anagnostopoulos01persistent.html
pratik: can verify document until the whole doc is streamed
klanz: may need a streaming hash function.
pratik: hard to-do nodesets
without an XML DOM
... streaming doesn't provide much benefit for small docs
... can use two passes with streaming to collect data then
verify.
klanz: what is the advantage of two pass over using a dom
<fjh> Created ISSUE-24 - Requirement for NodeSets ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/24/edit .
<fjh> Created ISSUE-25 - Web services profile ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/25/edit .
<fjh> pratik streaming presentation http://www.w3.org/2007/xmlsec/ws/slides/12-mishra-oracle/Overview.pdf
pratik: nodesets imply dom, difficulty
pratik: could an event stream be
used instead
... example would be beginElement(...),,, text(..)
endElement(...)
... problem1. some nodesets can't be represented by xml
streams
fjh: why are these problems: why do do we need these type of nodesets
bal: XML Encryption WG had discussion - decided it did not make sense to encrypt attributes
klanz: could require well formed XML between transforms
<fjh> Created ISSUE-26 - Require well formed XML between transforms ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/26/edit .
sean: this is related to compatibility
<fjh> Created ISSUE-27 - Profile XML Signature spec to disallow removal of used namespace nodes from nodesets ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/27/edit .
klanz: does this imply exclusive canonicalization?
<fjh> Created ISSUE-28 - QNames? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/28/edit .
pratik: exclusive c14n doesnt solve anything, can get namespace declarations multiple times
pratik: shouldn't allow removal of used namespace nodes
<fjh> knowing it is used requires more work and look-ahead
klanz: how nan you tell if a namespace is used if you are streaming, you need to look ahead
pratik: would have to restrict xpath filtering to only look self and ancestors
<klanz> I'm wondering whether we want a joint work on this with others doing XPath
<fjh> xpath filter 2.0 easier to write since starting from root but need constraints and possible conversion
sean: could define 3.0
klanz: would others be interested to simplify xpath to work only on the current node instead of the whole doc.
klanz: may need separate rec to gain visibility/adoption
<fjh> Created ISSUE-29 - Able to run transforms in parallel (in general parallelism related to pipelining) ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/29/edit .
<fjh> hard to anticipate use reason for multiple transforms, e.g. like unix pipes
<fjh> Created ISSUE-30 - Limit XPath Filter transform to be first transform or to not use parent axis ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/30/edit .
pratik: summary: can we get away without an dom?
pratik: goal, not require DOM, hence with constraints/profile and events
need an identifier to allow streaming
<fjh> Created ISSUE-31 - Role for XML processing instruction, if any ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/31/edit .
<fjh> Created ISSUE-32 - How to identify profile, when, where. Not in signature but earlier? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/32/edit .
pratik: profile based on current assumptions for streaming implementations?
<EdS> profile identifier would have to be signed, right?
bal: may only support streaming for enveloping signatures
<fjh> Created ISSUE-33 - Schema not validating when enveloped signature added and not included in original doc schema ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/33/edit .
tlr: put some information early in the document -- maybe some XML tags
bal: generic hint attributes in a Signature namespace?
fjh: is this idea to have an additional atttribute in document start?
klanz: processing instruction?
bal: not a first class object
klanz: well, maybe.......
bal: want to look closely
klanz: then various hack!
sean: don't need an identifier for streaming if you use a two pass method
<fjh> if element has attribute in xmlsec namespace to indicate that it needs to be included in signature
<fjh> could be in xml namespace or xmlsec namespace (see xmlink)
<fjh> ACTION: brian to provide proposal on xmlsec namespace approach to identify elements to be processed [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action05]
<fjh> ACTION: bal to provide proposal on xmlsec namespace approach to identify elements to be processed [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action06]
<tlr> ACTION: frederick to make bal to provide proposal on xmlsec namespace approach to identify elements to be processed [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-15 - Make bal to provide proposal on xmlsec namespace approach to identify elements to be processed [on Frederick Hirsch - due 2008-07-24].
klanz: processing instructions have the advantage of not invalidating schema's
<tlr> ick, we don't have an extension point for adding attributes to ds:Signature
fjh: need to contact thomas to get access to cvs
jfh: could have Editorial
teams
... members of that team don't have edit every doc
each member of that team get credit even if some one on that team didn't work on a specific doc
scribe: editor teams would have
their own meetings.
... may want to have two versions of each doc. draft/working
and WG approved
... wiki is an option for the working/draft doc
klanz: could use inline editing
tlr: rather not, and certainly not using "per-person tags"
fjh: can make use of the mailing list to exchange text proposals if we make use of clear product and section indicators
fjh: Please think about products that you want to define.
http://www.w3.org/2008/xmlsec/Group/Overview.html
fjh: re editing, hope to maintain process so we get a proper issues list that's atctually tied to what editors do.
<tlr> ScribeNick: tlr
fjh: "The Working Group is asked to consider the benefits of compatibility with the existing specification environment. If the Working Group decides to make breaking changes to one of the XML Security specifications, it will communicate such a decision broadly and early."
klanz: progress vs maintenance --
breaking chagnes or not?
... charter says "please communicate changes early" ...
... think about criticism that there is need to rethink overall
approach ...
... Peter Gutmann ...
bal: Any breaking change is going
to impact a large set of spec
... some of these consumers won't adopt a breaking change
...
cruellas: there is a perception
that Signature is more open, that leads to complexity ...
... profiling? ...
<scribe> ... "new great thing" may not fly ...
UNKNOWN_SPEAKER: compatibility is critical ...
klanz: sell a basic profile as a profile, as a subset?
bal: "Take your implementation,
take these things out, and it's more lightweight" -- using
extension points
... there's probably a bunch of features for which this works
...
... or a more radical break ...
... might have the more radical new version, or a variant that
we rip some options out from ...
klanz: synchronize into one document, not call it a profile
bal: don't care
klanz: when we constrain xpath,
xslt... -- say "this enables us to do safer signatures"
...
tlr: let's talk about the substance firrst, the perception then
csolc: need benefit for adopters
fhirsch: Feed-back at the
workshop that people want simplification
... there's also no question that algorithm stuff is important
...
bal: can do either a profile or a
minor revision that doesn't breka back-compat
... straight forward ...
csolc: referencing model without breaking backward compatibility?
bal: That won't be all
... bundling question -- how to deliver certain features?
... smaller change, or bundle new features
tlr: I suspect changes to the reference model will be breaking changes
csolc: adoption by
corporation
... couple new algorithms might not be enough ...
klanz: inline data in certain places?
klanz: xinclude use etc
bal: Don't include dependencies on xml stack?
klanz: also taking advantage of web archicture?
bal: not everything in it!
... as few dependencies as possible ...
tlr: XML Signature processors do not need to be xinclude aware at this point
fjh: anything else useful that this leads us to?
cruellas: what's the general leaning in terms of compatibility?
fjh: what precisely does it
mean?
... not sure we're there quite yet to understand that ...
... generation vs verification ...
... not sure we need to change schema?
sean: Change namespace anyway?
<fhirsch> Created ISSUE-34 - Review namespace versioning policy, define going forward ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/34/edit .
tlr: I think ds:Reference is most brittle in terms of extensions; I think we need to look at that first in order to understand whether we have a breaking change on our hands.
klanz: @@
cruellas: don't chagne the
namespace every time you need a new schema
... we're doing that in XADES ...
klanz: new elements in new
namespace?
... maintain some elements in old namespace?
... e.g. keyInfo ...
<fhirsch> jcc: what is granularity of namespacing, can use old elements in old namespace
klanz: avoid duplication of implementation code ...
sean: That's radically different schema. Redesigning Java API is not going to happen.
fhirsch: Move things around?
sean: that might be ok
... add another method to return that element ...
fhirsch: Change order of elements?
<klanz> sean: would we have a new namespace for streaming nodesets?
sean: the schema comes out in the API quite a bit
fhirsch: API change?
klanz: @sean: I think the namespace could remain the same as long as we can deal with only being able to dereference Nodesetdata/Octetstream data only.
<fhirsch> tlr: to repeat what sean said, changes that are not exposed at api might be acceptable, but if apps that use API it might be an issue
sean: Really change structure of Signature -- APIs would be a problem
tlr: So change of namespace ok, if API addition is modular?
sean: yeah keyInfo2 would be ok
fhirsch: What if one couldn't use certain arguments?
brian: Implementation approach
would be to have flag associated with it "generate in
constrained mode"
... so newer code could take advantage of constraints ...
... default might be getting the old, unprofiled version
...
... agree with sentiment that we're in relatively good place if
we can do things without breaking API ...
... suspect that between the implementations here, we're very
constrained in what we can do without breaking at least one of
us ...
klanz: I think the APIs are
pretty similar
... JSR 105 rules ...
brian: [we may not be able to make changes without breaking at least one implementation]
klanz: ds2:Reference?
... just as a thought experiment ...
... anybody got a feeling?
tlr: so you're talking about a change to the content model for ds:Signature that would not match the existing schema?
fhirsch: I think I hear that most
people in the room don't want to go more extreme
... I also wonder whether the nodeset stuff wouldn't be
breaking APIs?
... this doesn't seem to actually be consistent
brian: well, yeah
bruce: I want to have cake and eat it too.
fhirsch: Can we do that? /TR/REC-cake, /TR/REC-eating?
brian: We might end up there,
with two things
... Look at the algorithm issue ...
... there are plenty of folks there who are content (not happy)
with dsig today
... except for algorithm ...
... they want things sooner than later ...
... existing implementations can rev with minor, non-breaking
fixes relatively easily, ...
... hit marketplace ...
... if we go for new schema or new namespace, we're back to
square one in terms of interop and work ...
... longer time, and you still have the existing stuff
...
... I saw that with TLS, and with S/MIME ...
... push for suite B -- demand was, just get the algos in there
...
... TLS went through baby step process ...
... guess what, we hardcoded MD5/SHA1 into pre-master secret
...
... we can't get rid of that ...
... suite B in 1.0, rev-ed 1.1, got rid of 1.2 which is
breaking ...
... 1.0 and 1.1 out, everybody goes out to work on 1.2
... immediate need is on algorithms ...
... we might have to bite that bullet
fhirsch: Risk is good enough to
stop with first one?
... a lot of people wanted the maint WG do this
klanz: Useful to formulate this
into strategy?
... 1.1 and 1.2?
<EdS> or 1.1 and 2.0
fhirsch: If strategy is "just go for big thing" it might end up not getting deployed
klanz: if there is a 1.1, 1.2 --
and a 2.0 where people will ask about compatibility
... why call it xml dsig 2.0 instead of foobar
fhirsch: looking at milestones...
brian: Keep going on requirements and identify what can be done in 1.1 and what in 2.0
fhirsch: So we can go through streaming and see where that can go
cruellas: Feeling about
market?
... or is this an implementors' issue ...
fhirsch: Lots of input that sig
is too expensive
... e.g. simpleSign ...
cruellas: profiling?
fhirsch, sean: their own thing
cruellas: Try to determine what to target?
brian: Look at what is
addressible.
... we got a bunch of input, will get more ...
... some things will be easy ...
klanz: If we want to do new XMLDSig it should have a new name be disruptive a proper substitution and quickly implemented.
<klanz> Maybe have a processing instruction <?startdigest someAlgostuff?>
<klanz> ... xml goes here
fhirsch: Performance, canonicalization, algorithms, keyInfo
<klanz> as a child of the same parent as of the starting PI: <?stopdigest disgestvalue .... ?>
<fhirsch> looks like we should review requirements, note which could be implemented in 1.1 versus 2.0 change, public review of what is not in 1.1, get feedback
<fhirsch> maybe note that we can decide next step based on feedback
<fhirsch> tlr: open content model allows updates to KeyInfo, also Transform model can use existing extension points to enforce properties
<fhirsch> tlr: e.g. assertion transform (fails if assertion not true)
<fhirsch> fjh: algs, performance/c14n, keyinfo clarity/usable
fhirsch: Get rid of a bunch of
junk, transforms, c14n -- that's one story
... c14n is actually a separate one ...
subu: security -- DOS
... you get transformations that run out of control
fhirsch: This relates to complexity and simplification
tlr: Wrapping attacks? Sounds like References.
fhirsch: Workaround from Mike? Transform assertions?
bruce: You pay a price in complexity.
fhirsch: Use profile for
that?
... might also want a SOAP signature profile
... could include that point in this profile
... some stuff in minimalist profile
<subu> WS - BSP was mentioned by Hal
fhirsch: Evolving environment?
tlr: maybe part of the success story there is keeping part of the environment from evolving
fjh: next meeting in two
weeks
... thanks for attending the face-to-face ...
... thanks to Juan Carlos for excellent hosting ...
tlr: I think strawman proposals would be useful
klanz: I'll be happy to write up
an idea about reference
... URI is optional!
... pass stuff as parameter to a transform
... could do some enveloping signature
brian: well that's not what it's
meant for
... my object model would have a hard time with that ...
... need to be able to extract that ...
<fhirsch> ACTION: klanz to write up proposal regarding use of transform that has parameter for passing xml model [recorded in http://www.w3.org/2008/07/17-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-16 - Write up proposal regarding use of transform that has parameter for passing xml model [on Konrad Lanz - due 2008-07-24].
fhirsch: Help with requirements would also be helpful
adjourned
<EdS> Thanks everyone.
<anil> good evening all
<anil> RRSAgent: miutes