Subject: RE: [Speermint] Review of Peering Architecture Draft

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 18 Sep 2006 14:49:25 -0400

Inline 

> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]] 
> Sent: Monday, September 18, 2006 12:31 PM
> To: Hannes Tschofenig; [email-masked]
> Subject: RE: [Speermint] Review of Peering Architecture Draft
> 
> Hello Hannes,
> 
> Thanks for the comments. Inline... 
> 
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:[email-masked]]
> > Sent: Tuesday, September 05, 2006 5:24 AM
> > To: [email-masked]
> > Subject: [Speermint] Review of Peering Architecture Draft
> > 
> > Hi all,
> > 
> > I went through the architecture draft. Here are a few questions and
> > comments:
> > 
> > * Like the other two documents avoid using the term SPEERMINT (or 
> > SPEERMINT working group) but instead indicate what exactly 
> you want to 
> > say. For example, let us consider the following paragraph:
> > 
> > "
> >    IP Layer peering is outside the scope of SPEERMINT at this time;
> >     thus, we do not include them in the SPEEMINT Peering 
> Architecture.
> >     Note that IP Routers are not shown in the subsequent figures so 
> > that
> >     the focus is on Layer 5 protocol aspects.
> > "
> > 
> > It has two bugs:
> > 
> > (a) Terminology: The terminology document uses the term "Layer 3 
> > Peering". You use IP Layer peering. Although they are 
> similar, as we 
> > all know, it destroy the benefit of agreed terminology.
> 
> done
> 
> > 
> > (b) It refers to the charter of a working group that is subject to 
> > change.
> > 
> > Instead, you might want to say:
> > 
> > "
> > Layer 3 peering is outside the scope of this document. Hence, the 
> > figures in this document do not show routers.
> > "
> > 
> 
> Done.
> 
> > I would suggest to search an delete all SPEERMINT occurrences.
> 
> 
> Will out this in the TODO list.
> 
> > 
> > * The draft lists the wrong working group in the template. 
> It does not 
> > indicate the intended status. I assume informational.
> 
> Done.
> 
> > 
> > If it is an informational document then the RFC 2119 
> language is not 
> > appropriate.
> 
> 
> Let's wait for the status and I will correct the text. Let's 
> put in the TBD for now, is this okay?
> 
> > 
> > * I have never heard about the term "network context". What is it?
> 
> 
> According to merriam-webster context is "the interrelated 
> conditions in which something exists or occurs". I could use 
> reference "scenario" or "diagram" but I think context is 
> better. Let me know your thoughts... 
> 
> > 
> > * Who executes these steps in Section 3?
> > 
> > * My impression of section 3, 4 and 5 was that they should 
> be better 
> > aligned. When I read the document for the first time I couldn't see 
> > how they relate to each other but then I noticed that they 
> in fact do.
> > 
> > I would do the following:
> >   - Give each procedure a short label.
> >   - Delete Section 3
> >   - Use the short labels as subsection heading in Section 5 with a 
> > reference to Figure 2.
> > 
> > * The architectural questions raised in Section 6 
> (regarding "composed 
> > / decomposed and centralized / decentralized) seem to refer to the 
> > same concept. Right?
> 
> 
> If you can still have SF and MF in the same location but 
> performed by different entities. I guess that could be 
> considered geographically separarated. Let me know...
> 
> > 
> > Does this aspect actually impact the peering concept at 
> all, i.e., why 
> > is it important whether you have a protocol running between 
> the SF and 
> > th MF or just an API call?
> 
> 
> Okay, this comment deserves a little bit if discussion. There 
> is an effort to standardize a protocol between SF and MF, so 
> IMO it is worth mentioning. Yes, you can use other methods, 
> but they are not standardized in any way.
> 
> As far as the fact that media and signaling do not traverse 
> to the "other domain" in the same location seems important. 
> QoS, Congestion control, transcoding, etc will be done in a 
> different geographic place than signaling. So, there is the 
> question of availability, message delay, etc. Let me know 
> your thoughts.

I would suspect that any SF-MF vertical device control interface would
not traverse from one domain to another, and thus would be out of scope
for SPEERMINT.

Mike

> 
> > 
> > * I suggest not to copy-and-paste the BCP content from the 
> > requirements draft (as done in Section 5.4).
> 
> Agreed, removed.
> 
> > 
> > * There is something wrong with the reference. The citation 
> style in 
> > the normative and the informative part is different. You 
> might want to 
> > align it. I am also not quite sure whether you need so many 
> references 
> > in the normative section.
> 
> Done, Done
> 
> 
> > 
> > * Delete the conclusion section since it does not say anything.
> 
> 
> Done.
> 
> > 
> > * Replace the term "reference architecture" with "architecture".
> > Just on my personal wish list.
> 
> Done, except in the first occurrence.
> 
> > 
> > As a high-level comment: I was expecting something 
> different from an 
> > architecture/framework document. I would to see different 
> alternatives 
> > being considered (if there are alternatives). Take a look at, for 
> > example, RFC 4080 for a nice written framework document.
> > 
> > Ciao
> > Hannes
> > 
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> > 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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