Subject: RE: [Softwires] WG LC Problem Statement

From: "BAUDOT Alain RD-CORE-CAE" <[email-masked]>
Date: Tue, 20 Dec 2005 08:52:13 +0100

Folks,

I just reviewed the problem statement draft. I am fine with the overall document, that sounds pretty good to me.

My only point is about logging regarding the Hub and Spoke problem: the ability to clearly make a link between a user and the part of any AF it is allocated is very important and should be part of the problem statement, I think. This is a requirement an ISP has to meet within EU.

So, please find my few comments inline below.

Regards,
Alain.

General comments:

2.1. Terminology

Address Family: should reference AF used also in the document

SAF (section 4.4) should be referenced here as Softwire Address Family ?

Section 3.5. Sofwire initiator

The last sentence (nomadic case) is a bit confusing regarding different address families it refers to: should it be clarified through an example ?

Section 3.12. Operations and Managment

Usage accounting is quite generic. It should refer also to logging (does it include logging ?) and to the possibility to explicitly make a link between a user and the part of various AF it is allocated.

3.13. Encapsulations

Notation IPv6/IPv4 or IPv6/UDP/IPv4 maybe ambiguous, since it can be read as a packet data sequence (IPv6 header/IPv4 header and finally IPv4 in IPv6).  Should use IPv6-in-IPv4 and IPv6-in-UDP-in-IPv4 here ?

Editorial comments and typos:

The document refers to "Hub and Spoke", "Hubs and Spokes" and "Hub and Spokes" : is there a need for a unique generic name ?

Section 2, pragraphe 3: "Hub and Spoke" refers to section 3 and "Mesh" to section 4.

Section 3.4.: s/netwroks/networks/

Section 4: scheme referenced as Diagram 2 and Figure 2

Section 4.1.: refers to Figure 1 that is actually Figure 2

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de David Ward
Envoyé : mercredi 14 décembre 2005 20:37
À : [email-masked]; David Ward; Durand, Alain
Objet : [Softwires] WG LC Problem Statement

All -
    We are staring the WG last call on the problem statement draft:

http://www.ietf.org/internet-drafts/draft-ietf-softwire-problem-statement-00
.txt

We will close the Last Call period December 31, 2005.

Many thanks

-DWard

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

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 29 Dec 2005 16:50:34 -0600

Just working through comments  - my feedback begins with "Spencer:"

Thanks,

Spencer

----- Original Message ----- 
From: "BAUDOT Alain RD-CORE-CAE" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 20, 2005 1:52 AM
Subject: RE: [Softwires] WG LC Problem Statement

Folks,

I just reviewed the problem statement draft. I am fine with the overall 
document, that sounds pretty good to me.

My only point is about logging regarding the Hub and Spoke problem: the 
ability to clearly make a link between a user and the part of any AF it is 
allocated is very important and should be part of the problem statement, I 
think. This is a requirement an ISP has to meet within EU.

Regards,
Alain.

General comments:

2.1. Terminology

Spencer: The changes suggested for this section were added in the v4 
draft...

The last sentence (nomadic case) is a bit confusing regarding different 
address families it refers to: should it be clarified through an example ?

Spencer: I agree that the wording is confusing. I suspect that it would 
improve things if we had agreed-upon terms for 
"tunnel-endpoint-address-family" and "tunneled-address-family" - the current 
text is "one address family"/"the other address family", treating the 
address families as if they were interchangeable (instead of one address 
family being used to tunnel the other). Are my suggested terms helpful?

Usage accounting is quite generic. It should refer also to logging (does it 
include logging ?) and to the possibility to explicitly make a link between 
a user and the part of various AF it is allocated.

Spencer: I would like to hear other opinions about including logging - I 
agree, but I'm just the editor. If I understand your comment, you are asking 
for something like, "logging, including the ability to correlate tunnel 
endpoint source and destination addresses with tunneled source and 
destination addresses" - did I get this right?

3.13. Encapsulations

Notation IPv6/IPv4 or IPv6/UDP/IPv4 maybe ambiguous, since it can be read as 
a packet data sequence (IPv6 header/IPv4 header and finally IPv4 in IPv6). 
Should use IPv6-in-IPv4 and IPv6-in-UDP-in-IPv4 here ?

Spencer: This matches Jordi's recommendation in 
draft-palet-v6ops-6in4-vs-6over4-00.txt. Any opposed?

Spencer: I agree with the remaining comments - a couple have already been 
changed in v4, I will make the remaining updates...

The document refers to "Hub and Spoke", "Hubs and Spokes" and "Hub and 
Spokes" : is there a need for a unique generic name ?

Section 2, pragraphe 3: "Hub and Spoke" refers to section 3 and "Mesh" to 
section 4.