Subject: [Speermint] Review of Peering Architecture Draft

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Sep 2006 14:23:30 +0200

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.

(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.
"

I would suggest to search an delete all SPEERMINT occurrences.

* The draft lists the wrong working group in the template. It does not 
indicate the intended status. I assume informational.

If it is an informational document then the RFC 2119 language is not 
appropriate.

* I have never heard about the term "network context". What is it?

* 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?

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?

* I suggest not to copy-and-paste the BCP content from the requirements 
draft (as done in Section 5.4).

* 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.

* Delete the conclusion section since it does not say anything.

* Replace the term "reference architecture" with "architecture".
Just on my personal wish list.

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 5 Sep 2006 17:19:28 -0400

Thanks Hannes.

I will publish a new version before the workshop.

Thanks,

Reinaldo

> -----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,
>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 18 Sep 2006 12:31:21 -0400

Hello Hannes,

Thanks for the comments. Inline... 

> * 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:
> 
> "

done

> 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.

> indicate the intended status. I assume informational.

Done.

> If it is an informational document then the RFC 2119 language is not 

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... 

> decomposed and centralized / decentralized) seem to refer to the same 

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...

> 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.

> draft (as done in Section 5.4).

Agreed, removed.

> it. I am also not quite sure whether you need so many 

Done, Done

> * Delete the conclusion section since it does not say anything.

Done.

> Just on my personal wish list.

Done, except in the first occurrence.