Subject: [BLISS] Minutes from IETF 68 available

From: Shida Schubert <[email-masked]>
Date: Wed, 21 Mar 2007 09:25:15 +0100

here you have the draft minutes from the BoF session.

 http://www.bliss-ietf.org/meetings.html

 Comments are welcome.

 Thanks to Vijay and Spencer for writing minutes.

 Regards
  Shida 

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 21 Mar 2007 15:59:56 +0100

I have no one to blame but myself, of course...

> http://www.bliss-ietf.org/meetings.html

I may not have said this clearly at the mike, but I agreed pretty strongly 
with Ben that organizing by service sends a message, and organizing by 
something technical, including text that says "we have seen the following 
services implementing using this header/whatever:" followed by a list.

I am fine with doing the analysis a service at a time. That seems very 
natural.

I also believe that the technical orientation, with "includes the following 
service", may make it easier for implementers to explain to marketing people 
what they get if they fund development (since it's likely that you'd have 
more than one feature listed, if we're really using SIP in a building-block 
approach).

One comment I heard after the meeting was, "gee, those documents will be 
revised a bunch of times, if they're organized by something technical". I'm 
not sure that SIP services are as broken as NAT behavior, but I note that 
(quoting Cullen) we have discovered new NAT behaviors every time we tested, 
and we have no expectation that we've seen all the possibilities now. If we 
keep seeing new implementations, the service-based docs would have to be 
revised, too.

If we don't see any new implementations after we publish a service-based 
doc, I'd argue that we have successfully "defined the service", which is 
exactly what we said we don't want to do (and I agreed with this). But 
forget I said anything :-)

Thanks,

Spencer

---

From: [email-masked]
Date: Wed, 21 Mar 2007 20:37:22 -0500

From: Spencer Dawkins <[email-masked]>

Uh, what?  "organizing by service sends a message, and organizing by
something technical" does what?

Dale

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 22 Mar 2007 08:47:06 +0100

Sigh. Buffer overrun while typing... Thanks for asking, Dale.

> something technical" does what?

Organizing by something technical sends a different message.

My point is TRYING to be that if we have a BCP spec that's called DND, 
that's going to be more (semi-)normative than we would like for it to be, 
but if we have a spec that says "this is how you support method X, and we've 
seen people using method X to do DND (along with these other services", that 
will probably be less "normative".

Ben - am I totally misunderstanding you on this?

Spencer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 22 Mar 2007 09:36:24 +0100

On Mar 22, 2007, at 8:47 AM, Spencer Dawkins wrote:

> My point is TRYING to be that if we have a BCP spec that's called  
> DND, that's going to be more (semi-)normative than we would like  
> for it to be, but if we have a spec that says "this is how you  
> support method X, and we've seen people using method X to do DND  
> (along with these other services", that will probably be less  
> "normative".
>

I think you understand me perfectly :-)

I think the idea is that DND et al are _examples_ of common things  
that use the various SIP stuff. The important message is what SIP  
stuff you need to implement for general interoperability in a certain  
context. If we organize by service, we are putting the focus on the  
examples rather than the "what stuff I need to worry about as an  
implementer" info.

---

From: Shida Schubert <[email-masked]>
Date: Thu, 22 Mar 2007 16:22:16 +0100

I agree on the value of having a draft which lists the benefit of
implementing a specific SIP primitive such that document
describes

 "If you implement A right, you can use it for XYZ.".

 and this may be a bi-product of work in BLISS.

 But this doesn't cover the whole set of primitives one would
need to implement to accomplish interoperability, it may but
more than one primitives are generally needed thus a single
document specifying "This is useful if you want to implement
XYZ" is not sufficient to solve the problem we are trying to
solve. I believe...

 With the approach mentioned, implementors would need to
find number of documents equal to that of primitives needed
to implement the feature desired.

 If you want to implement A and this A needs XYZ, one
needs to somehow find this XYZ. If each primitive has a
document then you would somehow find XYZ, if you miss
one then you would probably not achieve interoperability..

 Anyhow, I see the output to be very valuable in a similar
fashion that Hitch Hiker's Guide is useful to the whole SIP.

 Regards
  Shida

Ben Campbell wrote:
>> DND, that's going to be more (semi-)normative than we would like for 
>> it to be, but if we have a spec that says "this is how you support 
>> method X, and we've seen people using method X to do DND (along with 
>> these other services", that will probably be less "normative".
>>