Subject: RE: List Last Call On draft-rosen-megaco-namepatterns-00.txt

From: "Rosen, Brian" <[email-masked]>
Date: Sat, 14 Apr 2001 21:33:01 -0400

Peter

These are useful comments.  I believe you are right, and the best
way forward is for me to roll a new version of the document and
request a short WGLC on it.  If Tom is okay with that, I'll
get the draft out in a day or two.

Brian

> -----Original Message-----
> From: Blatherwick, Peter [mailto:[email-masked]]
> Sent: Thursday, April 12, 2001 1:58 PM
> To: 'Rosen, Brian'; 'Megaco (E-mail)
> Subject: RE: List Last Call On draft-rosen-megaco-namepatterns-00.txt
> 
> 
> Brian, list:
> 
> This is a highly useful package to define.  Thanks!  
> 
> Given potential for confusion on how to use this package 
> (Modify/Audit looks good), where it is implemented (ROOT 
> only), I suggest a bit of descriptive text in the package 
> document would go a long way.  Suggest a quick re-spin and 
> short re-last-call would probably be worth the effort.  
> 
> Additional to points in the thread so far: what happens if 
> MGC attempts to set PatternNum out of range?  Error = 455 - 
> Parameter illegal in this Descriptor? PatternNum remains 
> unchanged from previous value?  Just need to decide and spell out.  
> 
> Agree with Dave Sclarsky's minor points 1 & 2 , earlier in 
> thread.  Useful nits to add.  
> 
> Agree, the package should not spell out how to define name 
> patterns or correlation of names to packages implemented by a 
> termination (that's a potential job for Profiles, to define 
> "well known names" if the application warrants).  Might even 
> be worth saying that explicitly, i.e. what the namepatterns 
> package does not define, Brian's word from earlier in the 
> thread in reply to Nurit.  
> 
> -- Peter
> 
> PS: Sorry for the long time lag...
> 
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2001 08:15
> To: 'Nurit Shenhar'; 'Megaco (E-mail)
> Subject: RE: List Last Call On draft-rosen-megaco-namepatterns-00.txt
> 
> 
> You might want Modify to return Pattern and AuditValue to
> return MaxPatterns, but that's not what the protocol does.
> The protocol defines when descriptors are returned, and it says
> that
> "  Whenever 
>    a parameter is underspecified or overspecified, the descriptor 
>    containing the value chosen by the responder is included as output 
>    from the command. "
> plus the wording on how Media, Audit, Subtract (statistics) and 
> ServiceChange.
> 
> As well, AuditValue is defined to return all the properties of
> a descriptor, not just the ones you want.
> 
> HOWEVER, I did note the following wording under the Audit
> Descriptor: 
>   "Audit may be used in any command to force the return of a 
>    descriptor even if the descriptor in the command was not 
> present, or 
>    had no underspecified parameters.  "
> 
> So you can say:
> Modify=ROOT{TerminationState{PatternNum=1},Audit{Media}}
> 
> This discussion reminds me that I do think in V2 we should allow 
> TerminationState, Stream, Local, Remote and LocalControl as Audit 
> keywords.
> 
> Brian
> 
> > -----Original Message-----
> > From: Nurit Shenhar [mailto:[email-masked]]
> > Sent: Wednesday, April 04, 2001 3:37 AM
> > To: 'Rosen, Brian'; 'Megaco (E-mail)
> > Subject: RE: List Last Call On 
> draft-rosen-megaco-namepatterns-00.txt
> > 
> > 
> > Brian
> > 
> > I think that using both Modify and Audit is not necessary. We 
> > could say that
> > when you send
> > ..Modify=ROOT{TerminationState{PatternNum=1}}
> > 
> > The reply for this should be
> > ..Modify=ROOT{TerminationState{MaxPatterns=2, Pattern="term*",
> > PatternNum=1}}
> > 
> > Because that is what you ask for, so we can consider it as 
> a specific
> > CHOOSE. I think that AuditValue of Media for the ROOT 
> > termination should
> > return only MaxPatterns and AuditCapabilities shouldn't 
> > return anything
> > about the patterns.
> > 
> > Nurit
> > 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Monday, April 02, 2001 11:44 PM
> > To: 'Dave Sclarsky'; 'Nurit Shenhar'; 'Megaco (E-mail)
> > Subject: RE: List Last Call On 
> draft-rosen-megaco-namepatterns-00.txt
> > 
> > 
> > Oh bother, the example I gave should have used Root as the 
> > terminationId
> > for the Modify, and you wouldn't get a reply unless you 
> used CHOOSE :(
> > Try
> > ..Modify=ROOT{TerminationState{PatternNum=1}}, 
> > AuditValue=ROOT{Audit{Media}}
> > 
> > Hmmm, I wonder what AuditCapabilities of Media would return :)
> > 
> > I would think, no, NamePattern is ONLY implemented on root, 
> as is the
> > root package.
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Dave Sclarsky [mailto:[email-masked]]
> > > Sent: Monday, April 02, 2001 4:36 PM
> > > To: 'Rosen, Brian'; 'Nurit Shenhar'; 'Megaco (E-mail)
> > > Subject: RE: List Last Call On 
> > draft-rosen-megaco-namepatterns-00.txt
> > > 
> > > 
> > > Brian,
> > > 
> > > Looking at your example brings up a few questions. 
> > > 
> > > Should namepat be implemented on terminations other than 
> > > ROOT?  Now that I
> > > think about it, should 'root' be implemented on terminations 
> > > other than
> > > ROOT?  It doesn't say so in the spec, but I would have 
> > > expected that 'root'
> > > and any package that extends it should only appear on ROOT.
> > > 
> > > Why does the Modify reply contain values?  I thought that the 
> > > MGC had to
> > > audit to retrieve the current values of properties.
> > > 
> > > A couple of minor points with the draft:
> > > 1. For property 'PatternNum', should 'Characteristics: read/write'
> > >    be specified?
> > > 2. Also for property 'PatternNum', should the 'Possible Value:'
> > >    be 'any integer less than or equal to MaxPatterns' (or maybe
> > >    'any integer from one to MaxPatterns inclusive')?
> > > 
> > > 
> > > DaveS.
> > > S-Link Corporation
> > > 
> > > 
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Monday, April 02, 2001 11:24 AM
> > > To: 'Nurit Shenhar'; 'Megaco (E-mail)
> > > Subject: RE: List Last Call On 
> > draft-rosen-megaco-namepatterns-00.txt
> > > 
> > > 
> > > You SET the value of PatternNum with a Modify.
> > > It returns the entire TerminationState descriptor, which
> > > includes the value of Pattern.  You do it again,
> > > with the next sequential PatternNum
> > > 
> > > So
> > > Modify=termA{TerminationState{PatternNum=1}}
> > > replies
> > > Modify=termA{TerminationState{MaxPatterns=2, Pattern="term*", 
> > > PatternNum=1}
> > > 
> > > Then
> > > Modify=termA{TerminationState{PatternNum=2}}
> > > replies
> > > Modify=termA{TerminationState{MaxPatterns=2, Pattern="rtp/*", 
> > > PatternNum=2}
> > > 
> > > Get it?
> > > 
> > > Brian
> > > 
> > > > -----Original Message-----
> > > > From: Nurit Shenhar [mailto:[email-masked]]
> > > > Sent: Monday, April 02, 2001 10:33 AM
> > > > To: 'Rosen, Brian'; 'Megaco (E-mail)
> > > > Subject: RE: List Last Call On 
> > > draft-rosen-megaco-namepatterns-00.txt
> > > > 
> > > > 
> > > > Hi Brian
> > > > 
> > > > Now I am really confused. In which command will the MGC use 
> > > > the 'PatternNum'
> > > > property? As I recall, an Audit request only has tokens in 
> > > > it. I thought
> > > > that the MGC sends AuditValue to the ROOT termination, and 
> > > > gets a reply with
> > > > all the patterns. Can you describe the mechanism more 
> > specifically?
> > > > 
> > > > Nurit
> > > > 
> > > > -----Original Message-----
> > > > From: Rosen, Brian [mailto:[email-masked]]
> > > > Sent: Monday, April 02, 2001 3:44 PM
> > > > To: 'Nurit Shenhar'; 'Megaco (E-mail)'
> > > > Subject: RE: List Last Call On 
> > > draft-rosen-megaco-namepatterns-00.txt
> > > > 
> > > > 
> > > > Thanks for your comments:
> > > > 1. Yes, the text following 2.1.1 is leftovers and should 
> > be deleted.
> > > > 2. What is a "termination type"?  We don't have such a 
> > > > concept, at least
> > > > explicitly, and we definitely don't have any kind of 
> > identifier that
> > > > could be used as a "termination type".  What would be nice 
> > > > about use of
> > > > name pattern is that the packages implemented by one pattern 
> > > > are the same,
> > > > but of course, two patterns could have the same packages 
> > > > implemented on
> > > > them.  However, that is NOT a requirement.  Name Pattern 
> > is strictly
> > > > a way for the MG to tell the MG how to construct efficient 
> > > wildcards.
> > > > 3. If you audit TerminationState, you would see:
> > > > 	TerminationState{...,MaxPatterns=..., Pattern=...,
> > > > PatternNum=...,...}
> > > > You get ONE Pattern for each audit.  Presumably, you will change
> > > > PatternNum, then audit, change it again, audit 
> again,... until you
> > > > get all the patterns.
> > > > 
> > > > Brian
> > > > 
> > > > > -----Original Message-----
> > > > > From: Nurit Shenhar [mailto:[email-masked]]
> > > > > Sent: Monday, April 02, 2001 2:23 AM
> > > > > To: 'Megaco (E-mail)
> > > > > Subject: RE: List Last Call On 
> > > > draft-rosen-megaco-namepatterns-00.txt
> > > > > 
> > > > > 
> > > > > Tom, Brian, List
> > > > > 
> > > > > I read the draft, (from November 2000, in the internet-drafts 
> > > > > directory) and
> > > > > I have some comments.
> > > > > 
> > > > > 1. The text that follows section 2.1.1 looks out of place:
> > > > > 
> > > > > 
> > > > > ..   2.1.1 Properties  
> > > > > ..        
> > > > > ..        
> > > > > ..  
> > > > > ..Rosen              Informational  Expires May 2001          
> > > > >         1 
> > > > > 
> > > > > ..                   Name Pattern Package for Megaco          
> > > > > Oct. 2000 
> > > > > .. 
> > > > > .. 
> > > > > ..     Type: Double  
> > > > > ..      
> > > > > ..      Possible values: 1 and up  
> > > > > ..        
> > > > > ..      Defined in: TerminationState  
> > > > > 
> > > > > 2. There is no parameter that connects the pattern with the 
> > > > > termination
> > > > > type, and there should be one. I would say that the 'pattern' 
> > > > > property has
> > > > > two parameters: One is the string itself, and the other is 
> > > > > the termination
> > > > > type. Maybe a third one should be added, that gives a 
> > > > > sequential number to
> > > > > the pattern, so that the MGC can ask for it specifically 
> > > > > (even though I
> > > > > can't see why it should do so...).
> > > > > 
> > > > > 3. What will the MG send in the TerminationState:
> > > > > 
> > > > > MaxPatterns
> > > > > Pattern, Pattern....
> > > > > 
> > > > > or 
> > > > > 
> > > > > Pattern, Pattern....
> > > > > 
> > > > > 
> > > > > Nurit
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Tom-PT Taylor [mailto:[email-masked]]
> > > > > Sent: Friday, March 30, 2001 8:45 PM
> > > > > To: 'megaco'
> > > > > Subject: List Last Call On 
> > draft-rosen-megaco-namepatterns-00.txt
> > > > > 
> > > > > 
> > > > > I would like to make an official Last Call for
> > > > > draft-rosen-megaco-namepatterns-00.txt, to expire Friday, 
> > > > > April 15.  After
> > > > > that I will forward it to the IESG and register the package 
> > > > > with IANA.  I do
> > > > > need list direction on whether it should be Informational 
> > > > or Standards
> > > > > Track.
> > > > > 
> > > > > Tom Taylor
> > > > > Multimedia Control and Applications Standards
> > > > > Ph.  +1 613 736 0961
> > > > > [email-masked] 
> > > > > 
> > > > 
> > > 
> > 
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 17 Apr 2001 13:53:47 -0400

Yes, we can handle it in the usual way for Last Calls: resolve comments, then
pass it on.  I will also pass it to SG 16 for comments.