headers
Livingood, Jason | 5 Jun 2008 21:44
Picon

Any More Comments / Changes:draft-ietf-speermint-architecture-06.txt

All --

We have not received many comments on this draft and we'd like to
continue to make progress with it.  Comments in the next couple of weeks
are appreciated so that we can review a very stable document at IETF-72.

Thanks
Jason 

> -----Original Message-----
> From: speermint-bounces@... 
> [mailto:speermint-bounces@...] On Behalf Of 
> Internet-Drafts@...
> Sent: Friday, May 02, 2008 2:00 PM
> To: i-d-announce@...
> Cc: speermint@...
> Subject: [Speermint] I-D 
> ACTION:draft-ietf-speermint-architecture-06.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session PEERing for 
> Multimedia INTerconnect Working Group of the IETF.
> 
> 	Title		: SPEERMINT Peering Architecture
> 	Author(s)	: R. Penno
> 	Filename	: draft-ietf-speermint-architecture-06.txt
> 	Pages		: 21
> 	Date		: 2008-5-2
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Livingood, Jason | 5 Jun 2008 21:51
Picon

WGLC #2: draft-ietf-speermint-voip-consolidated-usecases-08.txt

There were a few changes made from -07 so I would like to extend last
call a bit longer.

The intent of the last call is to solicit comments before submitting the
ID to the IESG.

The purpose of a working group last call is in the style of "speak now
or forever hold your peace" in case there are fundamental objections
which have not gotten previous or adequate discussion, or minor errors
which need correction.

The extended working group last call will extend for 1 week from today,
5 June 2008, until 13 June 2008.

Please post any comments in reply to the list, as well as to the
editor(s) of this draft.

Regards,

Jason  

> -----Original Message-----
> From: speermint-bounces@... 
> [mailto:speermint-bounces@...] On Behalf Of 
> Internet-Drafts@...
> Sent: Thursday, May 29, 2008 9:30 PM
> To: i-d-announce@...
> Cc: speermint@...
> Subject: [Speermint] I-D 
> Action:draft-ietf-speermint-voip-consolidated-usecases-08.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Mayrhofer | 16 Jun 2008 17:08
Picon
Favicon

NITS (and beyond) review of draft-ietf-speermint-voip-consolidated-usecases-08

Hi,

i did a review of the consolidated usecases draft, comments as follows:

- Generally, i'd appreciate if more eyes could check the draft. I think 
the language could be clearer, and there are also several (mostly small) 
technical issues. More reviewers would definitely help here (i suggest 
nominating at least one other formal reviewer for the document before we 
proceed)

Detailed comments follow:

- The automated idnits report doesn't yield any serious problems 
(complains about the spacing in some examples).

- Abstract: I think it should read "... many common VoIP use caseS .."

- ToC: Parts of the structure are inconsistent. For example, 5. "Use 
Cases" should probably be merged with 5.1 "Static Peering Use Cases", so 
that we have 5. "Static Peering Use Cases" and 6. "On-demand Peering Use 
Cases". Also, if "On-demand direct" is the only "on-demand" use case, a 
seperate section below that seems superflous (should have at least two 
sections at the same level, ihmo). Same for section 7 and 7.1

- There are numerous abbreviations that never get expanded in the draft. 
I do know that a lot of them are from the terminology draft, but that 
draft is not even referenced in the "Terminology" section. The 
abbreviations that are never expanded (i might have missed some, though) 
include: VoIP, (most of the SPEERMINT-Terms), ENUM, VLAN, SSPs, QoS, 
DSCP, URI, UAC, UAS, TN, R-URI, NAPTR, B2BUA, SBC/SBE, RTP, L5, BGP,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Uzelac, Adam | 16 Jun 2008 17:57

Re: NITS (and beyond) review of draft-ietf-speermint-voip-consolidated-usecases-08

Alex - Thank you very much for providing the detail below.  Yiu and I (the editors) will be addressing your
comments below in short order, but we will be holding off on submitting a new draft until such time that we
have a formal reviewer assigned to the document and get feedback from that person - provided the Chairs
want to go down that path.

Adam

> -----Original Message-----
> From: speermint-bounces@...
[mailto:speermint-bounces@...] On
> Behalf Of Alexander Mayrhofer
> Sent: Monday, June 16, 2008 11:09 AM
> To: speermint@...
> Subject: [Speermint] NITS (and beyond) review of draft-ietf-speermint-
> voip-consolidated-usecases-08
>
> Hi,
>
> i did a review of the consolidated usecases draft, comments as follows:
>
> - Generally, i'd appreciate if more eyes could check the draft. I think
> the language could be clearer, and there are also several (mostly
> small)
> technical issues. More reviewers would definitely help here (i suggest
> nominating at least one other formal reviewer for the document before
> we
> proceed)
>
> Detailed comments follow:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Livingood, Jason | 18 Jun 2008 14:30
Picon

FW: SPEERMINT - Requested session has been scheduled for IETF 72

Looks like we are TENTATIVELY scheduled for Monday afternoon in
Dublin... 

-----Original Message-----
From: IETF Secretariat [mailto:agenda@...] 

SPEERMINT Session 1 (2 hours)
Monday, Afternoon Session I 1300-1500
Room Name: Convention 3
Permalink | Reply | 0 comments |
headers
Elwell, John | 24 Jun 2008 22:10
Picon

Partial review of draft-ietf-speermint-consolidated-usecases-08

This is not a full review, because of lack of time. Also I will not
re-iterate the many points that Alexander Mayrhofer has already raised:
http://www.ietf.org/mail-archive/web/speermint/current/msg02396.html

In general, I think the document assumes too much prior knowledge from
the reader.

1. Figure 1 is not self-explanatory. Even if all the acronyms are
defined (as Alexander requested), what is the relationship between the
three domains (are they all peers of each other)? What is the meaning of
the lines connecting some of the inner boxes together, and what is to
the meaning when inner boxes are not interconnected (as within the
middle domain)? In particular there is no line between O-SBE and O-LRF,
yet the first example shows O-SBE querying O-LRF. Indeed there is a line
between those two entities in figure 2. What is the meaning of "LUF/LRF
Provider Domain Indirect SSP Domain" - should there be an "and" or an
"or" here?

2. "Each use-case must specify a
   basic set of required operations to be performed by each member when
   peering."
Is this supposed to be saying that this document specifies a basic set
of required operations....for each use case? If so, then these are hard
to find in the different use cases later in the document. For example, I
cannot find anywhere later in the document that mentions "peer
discovery" or "location determination" or "next hop determination"....

3. " Peer Discovery - Peer discovery via a Look-Up Function (LUF) to
      determine the administrative domain of the target.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lee, Yiu | 24 Jun 2008 22:47
Picon

Re: Partial review ofdraft-ietf-speermint-consolidated-usecases-08

Alex and John,

Thanks for taking the time to review the draft. The comments are great. Adam and I will address your comments
and target to release a new version next week.

Thanks,
Yiu

----- Original Message -----
From: speermint-bounces@... <speermint-bounces@...>
To: speermint@... <speermint@...>
Sent: Tue Jun 24 16:10:58 2008
Subject: [Speermint] Partial review ofdraft-ietf-speermint-consolidated-usecases-08

This is not a full review, because of lack of time. Also I will not
re-iterate the many points that Alexander Mayrhofer has already raised:
http://www.ietf.org/mail-archive/web/speermint/current/msg02396.html

In general, I think the document assumes too much prior knowledge from
the reader.

1. Figure 1 is not self-explanatory. Even if all the acronyms are
defined (as Alexander requested), what is the relationship between the
three domains (are they all peers of each other)? What is the meaning of
the lines connecting some of the inner boxes together, and what is to
the meaning when inner boxes are not interconnected (as within the
middle domain)? In particular there is no line between O-SBE and O-LRF,
yet the first example shows O-SBE querying O-LRF. Indeed there is a line
between those two entities in figure 2. What is the meaning of "LUF/LRF
Provider Domain Indirect SSP Domain" - should there be an "and" or an
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jean-Francois Mule | 27 Jun 2008 11:18
Favicon

Comments on draft-ietf-speermint-voip-consolidated-usecases-08

Hi Adam and Yiu Lee,

   Here are some comments based on the draft-08 revision.

Jean-François

1. Technical comments

- page 5, Next Hop Determination:
  s/IP-address/hostname
Hopefully, the result of a query to the Location Routing Function is a sip uri with either a hostname or
domain name, not an IP address.  If some folks prefer to use IP, it's their problem but the document must use
hostnames (the DNS resolver on the originating host should do the domain/hostname->IP add resolution).

- page 5: "[RFC3263] in a federation private DNS."
This is just an example but it is contrary to the conclusion we had with Patrick Falstrom in the beginning of
the wg terminology document.  The issue is "private DNS" in this sentence: it tends to leak the "private"
boundaries and is difficult to manage to avoid conflicts.  You can achieve the same results by registering
domain names to have them in the public DNS, yet the resolution of the DNS name give you DNS records that are
only meaningful in the federation (e.g. IP address not publicly routable).
s/[RFC3263] in a federation private DNS/[RFC3263] in a private federation (where DNS names may be
registered but the accessibility of the DNS responses may be restricted to federation members)

-  p18, 5.1.4. Static Indirect Peering Use Case:
This section should be updated to keep the text in scope of speermint, clear from any considerations around
provisioning or IP/telephony routing considerations. Specifically, in this paragraph:
"The challenge for O-SSP is to decide which I-SSP should be
 used to reach T-SSP.  O-SSP could manually enter I-SSP information in
 the routing database.  However, when O-SSP peers to multiple I-SSP,
 O-SSP may have multiple routes to reach the same T-SSP.  If we
(Continue reading)

Permalink | Reply | 501 comments |
headers
Otmar Lendl | 27 Jun 2008 13:54
Picon
Favicon

Re: Comments on draft-ietf-speermint-voip-consolidated-usecases-08

Jean-Francois Mule wrote:
>    Here are some comments based on the draft-08 revision.
 >
> 1. Technical comments
> 

Jean-Francois,

Your comments question the technical soundness of some the scenarios 
described in this document. That's a valid point, if this were a document 
which describes how speermint envisions peerings to happen in the future.

As I see the purpose of this document (see Abstract), it is just supposed 
to just document what's out there, including warts, kludges and stupidities.

Thus: whatever conclusions we reached with paf (concerning private DNS) 
doesn't affect what's deployed right now and that's what this document is 
about.

So if I'm not mistaken about the purpose of this document, then we don't 
need reviews saying "this is a stupid way to peer", but "nobody is doing
it this way today."

/ol
--

-- 
// Otmar Lendl <lendl@...>, T: +43 1 5056416 - 33, F: - 933 //
Permalink | Reply | 503 comments |
headers
Jean-Francois Mule | 27 Jun 2008 14:19
Favicon

Re: Comments on draft-ietf-speermint-voip-consolidated-usecases-08

Otmar wrote:

> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@...]
> Sent: Friday, June 27, 2008 5:54 AM
> To: Jean-Francois Mule
> Cc: speermint@...; adam.uzelac@...;
> yiu_lee@...
> Subject: Re: [Speermint] Comments on draft-ietf-speermint-voip-
> consolidated-usecases-08
> 
> Jean-Francois Mule wrote:
> >    Here are some comments based on the draft-08 revision.
>  >
> > 1. Technical comments
> >
> 
> Jean-Francois,
> 
> Your comments question the technical soundness of some the
> scenarios
> described in this document. That's a valid point, if this were a
> document
> which describes how speermint envisions peerings to happen in the
> future.
> 
> As I see the purpose of this document (see Abstract), it is just
> supposed
> to just document what's out there, including warts, kludges and
> stupidities.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane