AUTH48 [SG]: RFC 5357 <draft-ietf-ippm-twamp-09.txt>

[Al Morton]

At 05:30 PM 9/12/2008, RFC Editor wrote:
>Al,
>
>We have corrected the text as requested and posted the revised version
>of the document at:
>
>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5357.txt
>...

IPPM WG,

In the final phase of TWAMP editing, we identified a case
that is important enough to fix now, with your agreement.

Adding a short phrase will solve a small issue with the
connection/session "liveliness" timeouts, SERVWAIT and REFWAIT.
These timeouts are not mandatory in the Server/Reflector.

If we can obtain WG consensus to fix this now, it would be a
good thing.

Please review this ASAP and reply to the list.

Background

The host acting as the responder has two "liveliness" timers:
SERVWAIT is for monitoring activity on the TWAMP-Control connection
(see par. 3 of section 3.1)
REFWAIT is for monitoring activity on each TWAMP-Test session
(see last par. of section 4.2)

     controller                              responder
+-----------------+                   +-------------------+
| Control-Client  |<--TWAMP-Control-->| Server  (SERVWAIT)|
|                 |                   |                  |
| Session-Sender  |<--TWAMP-Test----->| Session-Reflector |(REFWAIT)
+-----------------+                   +-------------------+

When we added these timers in the TWAMP memo, we
decided that the responder should suspend monitoring the
TWAMP-Control connection while any TWAMP-Test session is in
progress and the REFWAIT timer is in force. However, the transfer
back to monitoring the Control connection with the SERVWAIT timer
is not as straightforward as we thought.

The relevant sentence from section 3.1 is:

         ...The Server SHALL suspend monitoring control
       connection activity after receiving a Start-Sessions command, and
       SHALL resume after receiving a Stop-Sessions command (IF the
       SERVWAIT option is supported).  Note that the REFWAIT timeout
       (described below) covers failures during test sessions.

The issue occurs when there is a failure while test sessions are
in-progress and the Server in the responder never receives a
Stop-Sessions command. As a result, the Server leaves its
TWAMP-Control connection open because it does not resume
monitoring for connection liveliness with the SERVWAIT timer.
This is exactly what we were trying to avoid.

We think the simplest way to fix this is to add a phrase in
paragraph 3, section 3.1:

OLD
...The Server SHALL suspend monitoring control
connection activity after receiving a Start-Sessions command, and
SHALL resume after receiving a Stop-Sessions command (IF the
SERVWAIT option is supported).  Note that the REFWAIT timeout
(described below) covers failures during test sessions.

NEW
...The Server SHALL suspend monitoring control
connection activity after receiving a Start-Sessions command, and
SHALL resume after receiving a Stop-Sessions command (IF the
SERVWAIT option is supported).  Note that the REFWAIT timeout
(described below) covers failures during test sessions,
and if REFWAIT expires on ALL test sessions initiated by a
TWAMP-Control connection, then the SERVWAIT monitoring SHALL
resume (as though a Stop-Sessions command had been received).

(last 3 lines above are new)

Comments?

Al


_______________________________________________
ippm mailing list
ippm@...
https://www.ietf.org/mailman/listinfo/ippm

[Murtaza Chiba (mchiba)]

The proposed change sounds correct.

Thanks,
_murtaza  

> -----Original Message-----
> From: ippm-bounces@... [mailto:ippm-bounces@...] On
> Behalf Of Al Morton
> Sent: Tuesday, September 16, 2008 6:04 AM
> To: ippm@...
> Cc: ippm-chairs@...; ippm-ads@...
> Subject: [ippm] AUTH48 [SG]: RFC 5357 <draft-ietf-ippm-twamp-09.txt>
>
> At 05:30 PM 9/12/2008, RFC Editor wrote:
> >Al,
> >
> >We have corrected the text as requested and posted the
> revised version
> >of the document at:
> >
> >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5357.txt
> >...
>
> IPPM WG,
>
> In the final phase of TWAMP editing, we identified a case
> that is important enough to fix now, with your agreement.
>
> Adding a short phrase will solve a small issue with the
> connection/session "liveliness" timeouts, SERVWAIT and REFWAIT.
> These timeouts are not mandatory in the Server/Reflector.
>
> If we can obtain WG consensus to fix this now, it would be a
> good thing.
>
> Please review this ASAP and reply to the list.
>
> Background
>
> The host acting as the responder has two "liveliness" timers:
> SERVWAIT is for monitoring activity on the TWAMP-Control
> connection (see par. 3 of section 3.1) REFWAIT is for
> monitoring activity on each TWAMP-Test session (see last par.
> of section 4.2)
>
>      controller                              responder
> +-----------------+                   +-------------------+
> | Control-Client  |<--TWAMP-Control-->| Server  (SERVWAIT)|
> |                 |                   |                  |
> | Session-Sender  |<--TWAMP-Test----->| Session-Reflector |(REFWAIT)
> +-----------------+                   +-------------------+
>
> When we added these timers in the TWAMP memo, we decided that
> the responder should suspend monitoring the TWAMP-Control
> connection while any TWAMP-Test session is in progress and
> the REFWAIT timer is in force. However, the transfer back to
> monitoring the Control connection with the SERVWAIT timer is
> not as straightforward as we thought.
>
> The relevant sentence from section 3.1 is:
>
>          ...The Server SHALL suspend monitoring control
>        connection activity after receiving a Start-Sessions
> command, and
>        SHALL resume after receiving a Stop-Sessions command (IF the
>        SERVWAIT option is supported).  Note that the REFWAIT timeout
>        (described below) covers failures during test sessions.
>
> The issue occurs when there is a failure while test sessions
> are in-progress and the Server in the responder never
> receives a Stop-Sessions command. As a result, the Server
> leaves its TWAMP-Control connection open because it does not
> resume monitoring for connection liveliness with the SERVWAIT timer.
> This is exactly what we were trying to avoid.
>
> We think the simplest way to fix this is to add a phrase in
> paragraph 3, section 3.1:
>
> OLD
> ...The Server SHALL suspend monitoring control connection
> activity after receiving a Start-Sessions command, and SHALL
> resume after receiving a Stop-Sessions command (IF the
> SERVWAIT option is supported).  Note that the REFWAIT timeout
> (described below) covers failures during test sessions.
>
> NEW
> ...The Server SHALL suspend monitoring control connection
> activity after receiving a Start-Sessions command, and SHALL
> resume after receiving a Stop-Sessions command (IF the
> SERVWAIT option is supported).  Note that the REFWAIT timeout
> (described below) covers failures during test sessions, and
> if REFWAIT expires on ALL test sessions initiated by a
> TWAMP-Control connection, then the SERVWAIT monitoring SHALL
> resume (as though a Stop-Sessions command had been received).
>
> (last 3 lines above are new)
>
> Comments?
>
> Al
>
>
> _______________________________________________
> ippm mailing list
> ippm@...
> https://www.ietf.org/mailman/listinfo/ippm
>

_______________________________________________
ippm mailing list
ippm@...
https://www.ietf.org/mailman/listinfo/ippm

[Henk Uijterwaal]

IPPM Group,

Al Morton wrote:
> IPPM WG,
>
> In the final phase of TWAMP editing, we identified a case
> that is important enough to fix now, with your agreement.
[...]
> Comments?

In order to keep things moving, I suggest that comments should be
submitted before Wednesday Sept 24, 8:00am CEST, that is, in
a week from now.

Henk


--
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: [phone]
1001 EB Amsterdam      1016 AB Amsterdam  Fax: [phone]
The Netherlands        The Netherlands    Mobile: [phone]
------------------------------------------------------------------------------

Is one of the choices leaving the office open?
                                       Alan Greenspan on the next elections

_______________________________________________
ippm mailing list
ippm@...
https://www.ietf.org/mailman/listinfo/ippm

[Henk Uijterwaal]

IPPM group,

> Al Morton wrote:
>> IPPM WG,
>>
>> In the final phase of TWAMP editing, we identified a case
>> that is important enough to fix now, with your agreement.
> [...]
>> Comments?
>
> In order to keep things moving, I suggest that comments should be
> submitted before Wednesday Sept 24, 8:00am CEST, that is, in
> a week from now.

There was one comment in support and no comments who disagreed,
so the authors can make this fix and proceed with the document.

Henk

--
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: [phone]
1001 EB Amsterdam      1016 AB Amsterdam  Fax: [phone]
The Netherlands        The Netherlands    Mobile: [phone]
------------------------------------------------------------------------------

Ceterum censeo Asplain esse delendam  (Cato & Henk)
_______________________________________________
ippm mailing list
ippm@...
https://www.ietf.org/mailman/listinfo/ippm

[Al Morton]

Henk and all,

Apparently, this thread from last week was never posted
to the list (see below).

Emile simply points out that an implementation of SERVWAIT
should also implement REFWAIT to work as recommended.
There's another sentence to add (below) to accomplish this.

NEW
...The Server SHALL suspend monitoring control
connection activity after receiving a Start-Sessions command, and
SHALL resume after receiving a Stop-Sessions command (IF the
SERVWAIT option is supported).  Note that the REFWAIT timeout
(described below) covers failures during test sessions,
and if REFWAIT expires on ALL test sessions initiated by a
TWAMP-Control connection, then the SERVWAIT monitoring SHALL
resume (as though a Stop-Sessions command had been received).
An implementation which supports the SERVWAIT timeout
SHOULD also implement the REFWAIT timeout.

(now, last 5 lines above are new)

I think that does it,
Al


At 07:41 AM 9/17/2008, Al Morton wrote:

>Because I didn't look at the addresses carefully,
>I thought this exchange *already* included IPPM.
>
>Feel free to send the entire thread to the list
>(indicating your opinion).
>
>thanks,
>Al
>
>At 03:26 AM 9/17/2008, emile.stephan@... wrote:
>>Hi Al
>>
>>Exactly, TWAMP-Control and TWAMP-test must work
>>consistently when this option is selected.
>>
>>Does it help to push it to the ML?
>>
>>Regards
>>Emile
>>
>> > -----Message d'origine-----
>> > De : Al Morton [mailto:acmorton@...]
>> > Envoyé : mardi 16 septembre 2008 15:56
>> > À : STEPHAN Emile RD-CORE-LAN
>> > Objet : RE: [ippm] AUTH48 [SG]: RFC 5357 <draft-ietf-ippm-twamp-09.txt>
>> >
>> > Emile,
>> >
>> > Changing that MAY to a MUST would mandate the REFWAIT timer,
>> > which we're not seeking to do.
>> >
>> > If you are saying that:
>> > An implementation which supports the SERVWAIT timeout option
>> > SHOULD also implement the REFWAIT timeout option.
>> >
>> > I think that's reasonable to add.
>> >
>> > Al
>> >
>> > At 09:36 AM 9/16/2008, emile.stephan@... wrote:
>> > >...
>> > > From my understanding we have to change the following too:
>> > >
>> > >Old:
>> > >"The Session-Reflector MAY
>> > >    discontinue any session that has been started when no packet
>> > >    associated with that session has been received for REFWAIT seconds."
>> > >
>> > >New:
>> > >"The Session-Reflector MUST
>> > >    discontinue any session that has been started when no packet
>> > >    associated with that session has been received for REFWAIT seconds."
>> > >
>> > >Regards
>> > >emile
>> > >
>> > >
>> > > > -----Message d'origine-----
>> > > > De : ippm-bounces@... [mailto:ippm-bounces@...] De la part
>> > de Al
>> > > > Morton
>> > > > Envoyé : mardi 16 septembre 2008 15:04
>> > > > À : ippm@...
>> > > > Cc : ippm-chairs@...; ippm-ads@...
>> > > > Objet : [ippm] AUTH48 [SG]: RFC 5357 <draft-ietf-ippm-twamp-09.txt>
>> > > >
>> > > > At 05:30 PM 9/12/2008, RFC Editor wrote:
>> > > > >Al,
>> > > > >
>> > > > >We have corrected the text as requested and posted the revised
>> > version
>> > > > >of the document at:
>> > > > >
>> > > > >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5357.txt
>> > > > >...
>> > > >
>> > > > IPPM WG,
>> > > >
>> > > > In the final phase of TWAMP editing, we identified a case
>> > > > that is important enough to fix now, with your agreement.
>> > > >
>> > > > Adding a short phrase will solve a small issue with the
>> > > > connection/session "liveliness" timeouts, SERVWAIT and REFWAIT.
>> > > > These timeouts are not mandatory in the Server/Reflector.
>> > > >
>> > > > If we can obtain WG consensus to fix this now, it would be a
>> > > > good thing.
>> > > >
>> > > > Please review this ASAP and reply to the list.
>> > > >
>> > > > Background
>> > > >
>> > > > The host acting as the responder has two "liveliness" timers:
>> > > > SERVWAIT is for monitoring activity on the TWAMP-Control connection
>> > > > (see par. 3 of section 3.1)
>> > > > REFWAIT is for monitoring activity on each TWAMP-Test session
>> > > > (see last par. of section 4.2)
>> > > >
>> > > >      controller                              responder
>> > > > +-----------------+                   +-------------------+
>> > > > | Control-Client  |<--TWAMP-Control-->| Server  (SERVWAIT)|
>> > > > |                 |                   |                  |
>> > > > | Session-Sender  |<--TWAMP-Test----->| Session-Reflector |(REFWAIT)
>> > > > +-----------------+                   +-------------------+
>> > > >
>> > > > When we added these timers in the TWAMP memo, we
>> > > > decided that the responder should suspend monitoring the
>> > > > TWAMP-Control connection while any TWAMP-Test session is in
>> > > > progress and the REFWAIT timer is in force. However, the transfer
>> > > > back to monitoring the Control connection with the SERVWAIT timer
>> > > > is not as straightforward as we thought.
>> > > >
>> > > > The relevant sentence from section 3.1 is:
>> > > >
>> > > >          ...The Server SHALL suspend monitoring control
>> > > >        connection activity after receiving a Start-Sessions command,
>> > and
>> > > >        SHALL resume after receiving a Stop-Sessions command (IF the
>> > > >        SERVWAIT option is supported).  Note that the REFWAIT timeout
>> > > >        (described below) covers failures during test sessions.
>> > > >
>> > > > The issue occurs when there is a failure while test sessions are
>> > > > in-progress and the Server in the responder never receives a
>> > > > Stop-Sessions command. As a result, the Server leaves its
>> > > > TWAMP-Control connection open because it does not resume
>> > > > monitoring for connection liveliness with the SERVWAIT timer.
>> > > > This is exactly what we were trying to avoid.
>> > > >
>> > > > We think the simplest way to fix this is to add a phrase in
>> > > > paragraph 3, section 3.1:
>> > > >
>> > > > OLD
>> > > > ...The Server SHALL suspend monitoring control
>> > > > connection activity after receiving a Start-Sessions command, and
>> > > > SHALL resume after receiving a Stop-Sessions command (IF the
>> > > > SERVWAIT option is supported).  Note that the REFWAIT timeout
>> > > > (described below) covers failures during test sessions.
>> > > >
>> > > > NEW
>> > > > ...The Server SHALL suspend monitoring control
>> > > > connection activity after receiving a Start-Sessions command, and
>> > > > SHALL resume after receiving a Stop-Sessions command (IF the
>> > > > SERVWAIT option is supported).  Note that the REFWAIT timeout
>> > > > (described below) covers failures during test sessions,
>> > > > and if REFWAIT expires on ALL test sessions initiated by a
>> > > > TWAMP-Control connection, then the SERVWAIT monitoring SHALL
>> > > > resume (as though a Stop-Sessions command had been received).
>> > > >
>> > > > (last 3 lines above are new)
>> > > >
>> > > > Comments?
>> > > >
>> > > > Al
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > ippm mailing list
>> > > > ippm@...
>> > > > https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@...
https://www.ietf.org/mailman/listinfo/ippm

[Henk Uijterwaal]

Hi Al,

> Apparently, this thread from last week was never posted
> to the list (see below).

No, I didn't see this.  Let's have another week for comments :-)

Henk

>
> Emile simply points out that an implementation of SERVWAIT
> should also implement REFWAIT to work as recommended.
> There's another sentence to add (below) to accomplish this.
>
> NEW
> ...The Server SHALL suspend monitoring control
> connection activity after receiving a Start-Sessions command, and
> SHALL resume after receiving a Stop-Sessions command (IF the
> SERVWAIT option is supported).  Note that the REFWAIT timeout
> (described below) covers failures during test sessions,
> and if REFWAIT expires on ALL test sessions initiated by a
> TWAMP-Control connection, then the SERVWAIT monitoring SHALL
> resume (as though a Stop-Sessions command had been received).
> An implementation which supports the SERVWAIT timeout
> SHOULD also implement the REFWAIT timeout.
>
> (now, last 5 lines above are new)
>
> I think that does it,
> Al
>
>
> At 07:41 AM 9/17/2008, Al Morton wrote:
>> Because I didn't look at the addresses carefully,
>> I thought this exchange *already* included IPPM.
>>
>> Feel free to send the entire thread to the list
>> (indicating your opinion).
>>
>> thanks,
>> Al
>>
>> At 03:26 AM 9/17/2008, emile.stephan@... wrote:
>>> Hi Al
>>>
>>> Exactly, TWAMP-Control and TWAMP-test must work consistently when
>>> this option is selected.
>>>
>>> Does it help to push it to the ML?
>>>
>>> Regards
>>> Emile
>>>
>>> > -----Message d'origine-----
>>> > De : Al Morton [mailto:acmorton@...]
>>> > Envoyé : mardi 16 septembre 2008 15:56
>>> > À : STEPHAN Emile RD-CORE-LAN
>>> > Objet : RE: [ippm] AUTH48 [SG]: RFC 5357
>>> <draft-ietf-ippm-twamp-09.txt>
>>> >
>>> > Emile,
>>> >
>>> > Changing that MAY to a MUST would mandate the REFWAIT timer,
>>> > which we're not seeking to do.
>>> >
>>> > If you are saying that:
>>> > An implementation which supports the SERVWAIT timeout option
>>> > SHOULD also implement the REFWAIT timeout option.
>>> >
>>> > I think that's reasonable to add.
>>> >
>>> > Al
>>> >
>>> > At 09:36 AM 9/16/2008, emile.stephan@... wrote:
>>> > >...
>>> > > From my understanding we have to change the following too:
>>> > >
>>> > >Old:
>>> > >"The Session-Reflector MAY
>>> > >    discontinue any session that has been started when no packet
>>> > >    associated with that session has been received for REFWAIT
>>> seconds."
>>> > >
>>> > >New:
>>> > >"The Session-Reflector MUST
>>> > >    discontinue any session that has been started when no packet
>>> > >    associated with that session has been received for REFWAIT
>>> seconds."
>>> > >
>>> > >Regards
>>> > >emile
>>> > >
>>> > >
>>> > > > -----Message d'origine-----
>>> > > > De : ippm-bounces@... [mailto:ippm-bounces@...] De la
>>> part
>>> > de Al
>>> > > > Morton
>>> > > > Envoyé : mardi 16 septembre 2008 15:04
>>> > > > À : ippm@...
>>> > > > Cc : ippm-chairs@...; ippm-ads@...
>>> > > > Objet : [ippm] AUTH48 [SG]: RFC 5357
>>> <draft-ietf-ippm-twamp-09.txt>
>>> > > >
>>> > > > At 05:30 PM 9/12/2008, RFC Editor wrote:
>>> > > > >Al,
>>> > > > >
>>> > > > >We have corrected the text as requested and posted the revised
>>> > version
>>> > > > >of the document at:
>>> > > > >
>>> > > > >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5357.txt
>>> > > > >...
>>> > > >
>>> > > > IPPM WG,
>>> > > >
>>> > > > In the final phase of TWAMP editing, we identified a case
>>> > > > that is important enough to fix now, with your agreement.
>>> > > >
>>> > > > Adding a short phrase will solve a small issue with the
>>> > > > connection/session "liveliness" timeouts, SERVWAIT and REFWAIT.
>>> > > > These timeouts are not mandatory in the Server/Reflector.
>>> > > >
>>> > > > If we can obtain WG consensus to fix this now, it would be a
>>> > > > good thing.
>>> > > >
>>> > > > Please review this ASAP and reply to the list.
>>> > > >
>>> > > > Background
>>> > > >
>>> > > > The host acting as the responder has two "liveliness" timers:
>>> > > > SERVWAIT is for monitoring activity on the TWAMP-Control
>>> connection
>>> > > > (see par. 3 of section 3.1)
>>> > > > REFWAIT is for monitoring activity on each TWAMP-Test session
>>> > > > (see last par. of section 4.2)
>>> > > >
>>> > > >      controller                              responder
>>> > > > +-----------------+                   +-------------------+
>>> > > > | Control-Client  |<--TWAMP-Control-->| Server  (SERVWAIT)|
>>> > > > |                 |                   |                  |
>>> > > > | Session-Sender  |<--TWAMP-Test----->| Session-Reflector
>>> |(REFWAIT)
>>> > > > +-----------------+                   +-------------------+
>>> > > >
>>> > > > When we added these timers in the TWAMP memo, we
>>> > > > decided that the responder should suspend monitoring the
>>> > > > TWAMP-Control connection while any TWAMP-Test session is in
>>> > > > progress and the REFWAIT timer is in force. However, the transfer
>>> > > > back to monitoring the Control connection with the SERVWAIT timer
>>> > > > is not as straightforward as we thought.
>>> > > >
>>> > > > The relevant sentence from section 3.1 is:
>>> > > >
>>> > > >          ...The Server SHALL suspend monitoring control
>>> > > >        connection activity after receiving a Start-Sessions
>>> command,
>>> > and
>>> > > >        SHALL resume after receiving a Stop-Sessions command (IF
>>> the
>>> > > >        SERVWAIT option is supported).  Note that the REFWAIT
>>> timeout
>>> > > >        (described below) covers failures during test sessions.
>>> > > >
>>> > > > The issue occurs when there is a failure while test sessions are
>>> > > > in-progress and the Server in the responder never receives a
>>> > > > Stop-Sessions command. As a result, the Server leaves its
>>> > > > TWAMP-Control connection open because it does not resume
>>> > > > monitoring for connection liveliness with the SERVWAIT timer.
>>> > > > This is exactly what we were trying to avoid.
>>> > > >
>>> > > > We think the simplest way to fix this is to add a phrase in
>>> > > > paragraph 3, section 3.1:
>>> > > >
>>> > > > OLD
>>> > > > ...The Server SHALL suspend monitoring control
>>> > > > connection activity after receiving a Start-Sessions command, and
>>> > > > SHALL resume after receiving a Stop-Sessions command (IF the
>>> > > > SERVWAIT option is supported).  Note that the REFWAIT timeout
>>> > > > (described below) covers failures during test sessions.
>>> > > >
>>> > > > NEW
>>> > > > ...The Server SHALL suspend monitoring control
>>> > > > connection activity after receiving a Start-Sessions command, and
>>> > > > SHALL resume after receiving a Stop-Sessions command (IF the
>>> > > > SERVWAIT option is supported).  Note that the REFWAIT timeout
>>> > > > (described below) covers failures during test sessions,
>>> > > > and if REFWAIT expires on ALL test sessions initiated by a
>>> > > > TWAMP-Control connection, then the SERVWAIT monitoring SHALL
>>> > > > resume (as though a Stop-Sessions command had been received).
>>> > > >
>>> > > > (last 3 lines above are new)
>>> > > >
>>> > > > Comments?
>>> > > >
>>> > > > Al
>>> > > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > ippm mailing list
>>> > > > ippm@...
>>> > > > https://www.ietf.org/mailman/listinfo/ippm
>
>

--
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: [phone]
1001 EB Amsterdam      1016 AB Amsterdam  Fax: [phone]
The Netherlands        The Netherlands    Mobile: [phone]
------------------------------------------------------------------------------

Ceterum censeo Asplain esse delendam  (Cato & Henk)
_______________________________________________
ippm mailing list
ippm@...
https://www.ietf.org/mailman/listinfo/ippm

[Henk Uijterwaal]

Al, others,

Henk Uijterwaal wrote:

>> Apparently, this thread from last week was never posted
>> to the list (see below).
>
> No, I didn't see this.  Let's have another week for comments :-)

There were no further comments on this, so please make the changes and let's
finish this document.

Henk

--
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: [phone]
1001 EB Amsterdam      1016 AB Amsterdam  Fax: [phone]
The Netherlands        The Netherlands    Mobile: [phone]
------------------------------------------------------------------------------

Ceterum censeo Asplain esse delendam  (Cato & Henk)

_______________________________________________
ippm mailing list
ippm@...
https://www.ietf.org/mailman/listinfo/ippm