Subject: RE: [midcom] Comments on Framework 03 draft

From: [email-masked]
Date: Thu, 26 Jul 2001 19:24:00 +0100

Hi,

Thanks for the status update:-

> > 1. The In-path and out-of-path issue doesn't seem to have 
> closed and there
> > is plenty of reference to it in the document. 
> 
> I dont believe so. The In-path vs OOP issue is closed.
> The document does not refer OOP agents other than simply stating 
> that the discussion is out of scope.
> 

I think this needs discussing further then as I'm getting a lot of
discussion on the subject off the list.

> Richard - The framework cannot be described in a vacuum. The section 
> simply talks about the phases in a MIDCOM connection setup. While some
> overlap is inevitable, it is important to note that (a) the 
> reader is not
> required to have two documents (i.e., framework and 
> requriements document)
> in order to understand this document, (b) the requirements 
> and framework
> document should be in sync.

Unfortuantely this is precisely the reason the requirements should not be in
the framework document - both documents should do one job only. If we
produce a framework document which implies requirements which have been
neither agreed nor aligned with the requirements document we will invariably
have people implementing to assumed and therefore incorrect requirements.
End result will be two solutions, neither of which will interwork
necessarily.

> > Section 5 seems to have a lot of common text with section 
> 2.8. Could these
> > be merged?
> > 
> 2.8 is term definition for MIDCOM agent. 
> 5.0 is description and discussion on MIDCOM agents.
> Some overlap is inevitable. I wouldnt want to merge the two.
> 
> > Section 6.1 seems to have a lot of embedded requirements 
> > 
> > Section 6.2 also seems to have a lot of embedded requirements

> > nits
> > ===
> > Page 1 and elsewhere. NetMeeting V3.x isn't always a 
> peer-peer application
> > so it is a bit misleading to cite it. It can be - but not always.
> > 
> I dont know about specific versions. I dont find this misleading.

Or to be blunt what you have said is factually inaccurate. It is simply an
true statement.

> > Section 8.6 makes reference to Q.931 which technically 
> isn't correct and
> > should probably read H.225.0 call signalling.
> > 
> 
> Q.931 is the packet format exchanged over H.323 TCP connection. 
> The Intel document that describes H.323 also refers the Q.931
> and H.323 connections interchangeably. So, I suggest,
> we leave this as is.
> 

Sorry - H.323 is an ITU-T specification not an Intel one! H.323 call
signalling is defined in H.225.0 which contains a profile of Q.931 (it uses
the balanced mode of operation). Therefore the call signalling in H.323 is
defined in H.225.0 and not Q.931 - that is a different document and
specification all together. I suggest we change it to make it factually
acurate.

regards

Richard 

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 26 Jul 2001 17:59:18 -0700 (PDT)

> End result will be two solutions, neither of which will interwork
We have had lot of feedback from folks on the list about wording in
these sections - 4 (MIDCOm protocol), 6.1(authentication, integrity
and confidentiality) and 6.2 (registration and deregistration of 
MIDCOM agents). Some of the text made it to the draft precisely 
because of the input from list. There is consensus for the text.
I dont see why the requirements would differ from this agreed upon
text. 

Framework and Requirement drafts should move forward independently,
without one dragging down the other. It can happen, so long as
it is the same forum (ie, the MIDCOM list and ultimately the IESG) 
that reviews both drafts.

regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 26 Jul 2001 20:02:37 -0700 (PDT)

> Or to be blunt what you have said is factually inaccurate. It is simply an

Why is NetMeeting not a peer-to-peer application? Please explain.
NetMeeting includes audio/video conferencing, chat, file tarnsfer
and so forth.

> specification all together. I suggest we change it to make it factually
Will do. Thanks.

> Richard 

=====