Subject: [MBONED] WGLC on SSMPING

From: Marshall Eubanks <[email-masked]>
Date: Wed, 8 Oct 2008 12:47:30 -0400

We have been asked by Stig about this and feel that SSMPING is ready  
for WGLC. Please comment on this draft

http://www.ietf.org/internet-drafts/draft-ietf-mboned-ssmping-05.txt

by October 24, 2008. Please be sure to indicate whether you support  
advancing it,
advancing it after changes, or do not support its advancement.

Regards
Marshall Eubanks
Hiroshi Ohta
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Stig Venaas <[email-masked]>
Date: Tue, 21 Oct 2008 15:12:34 +0200

Marshall Eubanks wrote:
> We have been asked by Stig about this and feel that SSMPING is ready for 
> WGLC. Please comment on this draft
> 

There are 3 days left and so far I haven't seen a single response.

It would be great if you could read the latest draft and comment on this
list. It's good to have your responses independent of support or not,

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 21 Oct 2008 15:12:34 +0200

Stig

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 21 Oct 2008 22:11:56 +0530

Marshall/Hiroshi,

> advancing it after changes, or do not support its advancement.

I propose to advance this draft to the next stage as it is.

Thanks,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right tFrom [email-masked]  Tue Oct 21 09:40:50 2008
From: Bharat Joshi <[email-masked]>
To: Marshall Eubanks <[email-masked]>, "[email-masked]"
	<[email-masked]>
Date: Tue, 21 Oct 2008 22:11:56 +0530
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [MBONED] WGLC on SSMPING
Sender: [email-masked]

Marshall/Hiroshi,

> advancing it after changes, or do not support its advancement.

I propose to advance this draft to the next stage as it is.

Thanks,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

o monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: "Tony Ballardie" <[email-masked]>
Date: Tue, 21 Oct 2008 17:51:34 +0100

Generally I'm in support of this, but I haven't been over the fine
detail yet. I'll try and do this by the deadline.

Just as a side - but important - note...
I'm all in favour of more multicast management tools - BUT they NEED
developing across platforms so they are widely available. Whilst a good
few have been implemented in the past, they've been implemented on unix
or flavours thereof which renders them as good as useless for the mass
market. PLEASE LET'S NOT CONTINUE TO MAKE THIS MISTAKE. If we want
multicast mass adopted we have to make all things multicast work on
Microsoft and Mac platforms. 

A couple of initial comments:

The draft says:
   failure to receive
   multicast indicates either a multicast problem or a multicast
   administrative restriction.  If it does receive multicast, it knows
   not only that it can receive; it may also estimate the amount of time
   it took to establish the multicast tree (at least if it is in the
   range of seconds),

I can't see how it estimates the time taken to establish the tree. Since
the client joins the tree after sending the initial pings, all you can
guage is whether the join was successful, but not how long it took.

I also can't see how it knows whether ASM multicasts are recieved via
the RP-tree or SPT. What information is it using, and conveying back to
the client, that establishes that? 

Another useful piece of information would be streaming formats and
containers supported by the server.

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stig Venaas
> Sent: 21 October 2008 14:13
> To: Marshall Eubanks
> Cc: [email-masked]

---

From: "Tony Ballardie" <[email-masked]>
Date: Tue, 21 Oct 2008 17:51:34 +0100

The draft says:
   failure to receive

Tony

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 21 Oct 2008 19:31:53 +0100

I have read version -05 of the ssmping spec, and see the following:

1) I think this protocol is a useful tool and is one that I would 
encourage deployment of in the networks that I use. It is useful for 
multicast service provision, where it can be used to determine if the 
network is still working and to monitor to determine whether the routing 
infrastructure is stable and consistent.

2) I have commented in detail on earlier versions of the spec. and these 
comments seem to have been reflected in changes that appeared as the 
protocol evolved (although some could be repeated below). The protocol 
seems mature and simple. I suggest that this document is ready for 
publication, subject to WG approval on the final text.

3) I wonder why an IETF WG chooses to advance a protocol of this sort as 
Informational, rather than EXP or STD. Could the Chairs please clarify 
this, as I would expect this to be something that would anyway need to 
be written in the document write-up?

Best wishes,

Gorry
----

Comments:

Abstract:
/multicast related/
               ^
- should this be hyphenated?
---
Abstract:
/related information like/
                                ^^^
- I think it would be better English to say /including/ or /for 
example/, since this isn't a similie.
---
Page 3:
/information like multicast tree setup time/
                    ^^^^
- I think it would be better English to say /including/ or /for 
example/, see abstract comment.
---
Page 3:
/based on the actual implementation /
                     ^^^^^
- I think RFCs need to adopt a more time-independent wording. 
Implementations will change. The document would therefore be better to 
use the words /current/ to describe an implementation, or /current 
actual/ if you feel the need to differentiate it from IETF  documents 
based on fake implementations (which doesn't seem helpful).
---
Page 4:
/By use of the TTL option specifying the TTL of the
   replies when they are originated, the client can also determine the
   number of router hops it is from the source./
- This is true, but is there some form of language here that can alert a 
reader to the effect of tunnels. Tunnels and encapsulation are common, 
and it would be nice to highlight upfront that the reported values are 
network-layer hops (not necessarily all routers that forward the packets).
---
Page 4: 3.  Protocol specification
- This section does not say the port number that the protocol uses, that 
would be helpful to say right up front, e.g.:

This protocol uses the UDP port [tbd].
---
Page 5:
- I would have found it helpful to have included a table of the four 
message types and their corresponding code points.
- I also think you SHOULD say that there is an IANA registry, e.g.:

Message types 0-191 are reserved and available for allocation in an 
IANARegistry. Message types 192-255 are not allocated by IANA and are 
freely available for experimental, private or vendor specifc use.
---
Page 5:
- I would have liked to have seen a statement about other code-points, 
specifically what you expect clients to do with unknown message types - 
MUST discard, SHOULD discard?
---
Page 6:
/Values 7 and 8 are reserved. /
                                             ^
- At this point it is not clear that there is a registry defined, and 
what to do with other option values. A sentence here that explains:

Other option types in the range 0-49151 are currently reserved, but are 
available for allocation by IANA (see section 10). Option
types in the range 49152-65535 are not allocated by IANA and are 
therefore freely available for experimental, private or
vendor specific use.
---
Page 6: Version, type 0
/and the value MUST be set to 2 (in decimal)./
      ^
- for the current specified protocol this value MUST be set to 2 (in 
decimal).
---
Page 6: Sequence Number, type 2
- The sequence number starts at 1. This does not attempt to defeat 
off-path attacks on the protocol. While I can see this is not a primary 
concern of a ping protocol,  recommending a random initial value could 
have merit in making the protocol more robust. Has this been considered?
---
Page 7: Option Request Option, type 5
- The current text seems confusing, and I think should be clarified.
- I found the RFC2119 language rather hard to parse in this option. Here 
is what I think I understand:
This option MAY be used in client Init messages and server response 
messages. It MUST NOT be used in other messages.

- I assume the server must retain the same ordering as submitted by the 
client when it omits options?
- It also says that /Support for this option is optional for both 
clients and servers./, but then it mandates the server to respond when 
the client uses this, which to me seems implementation is required by 
servers?
---
Page 9: Multicast Prefix, type 10
/It MUST NOT be used in Request/Reply messages. /
- I guess also not in init messages. I would prefer to say it MUST NOT 
be used in other types of message.
---
Page 11: Server Response, type 83
The text says the Version number MUST be included in server response and 
echo reply (which I think is right), but the table shows this value as 
ECHO, these will of course be the same if the version is the same -  I 
think the table should be updated to say MUST?
---
Page 14: Section 6:
/Note that a client may pick a multicast group and send Request/
- Fine, but it would be nice to note that this is not the recommended 
way. I see a SHOULD require the use of Init later in the spec.

/By default, a server should perform rate limiting/
                                 ^^^^^
- This seems to  me to be a protocol mechanism, and should use an 
RFC2119 keyword?
- But section 8 says /Servers must perform rate limiting/
- Consistency is needed, and I'd prefer MUST, but would be interested in 
other arguments.

---
10.  IANA Considerations

/The registry should include the messages defined in Section 5/
                                                                                                 
^
- Insert full stop at end.

/private or vendor specifc use/
                                      ^
- insert 'i'

- You may like to provide an example of the initial Registry layout, 
this would be helpful for IANA.

- The document does not tell IANA to replace [tbd] with the assigned 
port number. A note saying this would ensure that the RFC-Ed does the 
right thing.

---
11.  Security Considerations

- This section describes an attack on a remote host, inflicting it with 
SSMPING packets. One of the reasons this attack is mostly harmless is 
that it responses are directed to ssmping port. This needs to be stated.

/discussed in Section 8)./
                                   ^
- please delete bracket.
---

P.S. Since this is a WG draft in WGLC, the port number can be allocated 
by IANA immediately, and this number could be inserted in the revised draft.
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 21 Oct 2008 19:31:53 +0100

Best wishes,

Gorry
----

Comments:

Abstract:
/multicast related/
               ^

---
10.  IANA Considerations

^

---

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 21 Oct 2008 16:16:08 -0400

Will do. But you gave up the group too early !

Refresh my memory - did we have discussions about the PS versus  
Informational issue ?

Marshall

On Oct 21, 2008, at 9:12 AM, Stig Venaas wrote:

> Marshall Eubanks wrote:
>> We have been asked by Stig about this and feel that SSMPING is  
>> ready for WGLC. Please comment on this draft

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 21 Oct 2008 16:16:08 -0400

Marshall

---

From: Stig Venaas <[email-masked]>
Date: Wed, 22 Oct 2008 10:31:32 +0200

> Microsoft and Mac platforms. 

Just want to point out that the ssmping/asmping tools I've implemented
using this protocol do work cross platform, including Microsoft and Mac,
although sadly (as I'm sure you know) there is no SSM support on Mac.
> guage is whether the join was successful, but not how long it took.

My client implementation does a join right before sending the first
ping. It can then measure the number of seconds taken. Normally it
should of course take less than a second and the protocol is not suited
to measure it more exactly (this would require pinging at higher rates).

> the client, that establishes that? 

You may see this my seeing a change in number of hops. You cannot know
for sure what is going on unless you know the topology though. And in
some cases the hop count may be the same on RPT and SPT. Perhaps the
draft need to explain this, or do you think it promises too much.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 22 Oct 2008 10:31:32 +0200

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 22 Oct 2008 11:03:00 +0200

> Refresh my memory - did we have discussions about the PS versus 

Not sure we did. My main objective has been to openly document the
protocol I'm using and also to get input from the wg to improve it.
For documentation purposes Informational is fine. However, with the
amount of input I've got from several wg members and several
improvements of the protocol I guess we should consider Standards
Track. I'm also hoping to see other implementations of the protocol,
in which case Standards Track is better.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 22 Oct 2008 11:03:00 +0200

Stig

---

From: Brian Haberman <[email-masked]>
Date: Wed, 22 Oct 2008 09:24:10 -0400

> be written in the document write-up?

At a minimum, this should be Experimental.  I would have no problem with 
it being Proposed Standard.  And modulo the comments already provided, I 
think it is ready to send to the IESG.

Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 22 Oct 2008 09:24:10 -0400

Brian

---

From: "Tony Ballardie" <[email-masked]>
Date: Wed, 22 Oct 2008 17:44:07 +0100

> to measure it more exactly (this would require pinging at higher

Right. So the measure is strictly RTT and packet loss. You can't infer
more than that, but that's ok. 

> draft need to explain this, or do you think it promises too much.

Agreed - the draft should explain it, or just leave it out as it's hard
to definitively distinguish between SPT and RPT. 

If there are independent implementations which have been tested across
vendors and (host)platforms then it should move to proposed standard.

Tony

---

From: "Tony Ballardie" <[email-masked]>
Date: Wed, 22 Oct 2008 17:44:07 +0100

Tony

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Oct 2008 14:52:21 +0300 (EEST)

> http://www.ietf.org/internet-drafts/draft-ietf-mboned-ssmping-05.txt

I support advancing this with changes (the substantial ones below).

I suggest Proposed Standard.  There is already an implementation (the 
latest version doesn't yet support this spec I think, but I'd guess 
the mods in SVN tree do), and it has been found to be useful; for 
example, we're using this in our multicast monitoring systems. 
Proposed Standard does not require multiple implementations.  If this 
were Experimental, it would need to be justified, and I don't see 
RFC2026 Section 4.2.1 or Section 3.3(d) being quite right with this 
spec.

Substantial comments:

* the document does not mention fragmentation, PMTUD or packet size.
   I think this deserves some text.  Specifically, as the server may
   add options to the payload it is required to echo, the size of the
   response will grow.  In addition, the multicast return path may have
   lower path MTU than the unicast forward path.  Is the server
   expected to set the DF bit (ipv4) in the header?  Copy it from the
   request?  Respond to ICMP Packet too Bigs by fragmenting?  Is there
   anything special to do if the packet size (after adding the options)
   exceeds the server's MTU?

   One reason why I raise this is because I believe this tool could
   probably also easily be used or exFrom [email-masked]  Thu Oct 23 04:51:23 2008
Date: Thu, 23 Oct 2008 14:52:21 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: Re: [MBONED] WGLC on SSMPING
Sender: [email-masked]

> http://www.ietf.org/internet-drafts/draft-ietf-mboned-ssmping-05.txt

I support advancing this with changes (the substantial ones below).

I suggest Proposed Standard.  There is already an implementation (the 
latest version doesn't yet support this spec I think, but I'd guess 
the mods in SVN tree do), and it has been found to be useful; for 
example, we're using this in our multicast monitoring systems. 
Proposed Standard does not require multiple implementations.  If this 
were Experimental, it would need to be justified, and I don't see 
RFC2026 Section 4.2.1 or Section 3.3(d) being quite right with this 
spec.

Substantial comments:

* the document does not mention fragmentation, PMTUD or packet size.
   I think this deserves some text.  Specifically, as the server may
   add options to the payload it is required to echo, the size of the
   response will grow.  In addition, the multicast return path may have
   lower path MTU than the unicast forward path.  Is the server
   expected to set the DF bit (ipv4) in the header?  Copy it from the
   request?  Respond to ICMP Packet too Bigs by fragmenting?  Is there
   anything special to do if the packet size (after adding the options)
   exceeds the server's MTU?

   One reason why I raise this is because I believe this tool could
   probably also easily be used or extetended to figure out multicast
   path MTU, but I'm not sure if the current spec is fleshed enough
   with this respect to support this.

     By default, clients should send at most
     one request per second, and servers should perform rate limiting
     if a client sends more frequent requests.

* I don't agree with the latter recommendation.  I believe it's useful
   to be able to use a higher than 1pps rate without having to agree
   beforehand to waive rate-limits.  Based on security considerations
   text, a suitable compromise would be that the above would apply if
   INIT messages were not used (providing return routability).  If Init
   is used, a rate-limit, if in place, should not be lower than
   ~100pps.

Editorial comments:

  mechanism, but uses UDP (RFC 768 [2] and RFC 2460 [3]) and requires

* I don't see why RFC 2460 is referred to here; clarify or remove.

   IANA is requested to provide a UDP port number for use by this
    protocol, and also to provide registries for message and option
    types.

* are you looking for a "user" or "well-known" port number?  Probably
   the latter; it should be mentioned here.

   There should be a message types registry.  Message types are in the
    range 0-255.  Message types 0-191 can be assigned referencing an RFC
    (it may be Informational), while types 192-255 are freely available
    for experimental, private or vendor specifc use.  The registry should
    include the messages defined in Section 5

* missing dot at the end.  Are there any requirements for new message
   types?  In S 5, the matrix is quite detailed which message types can
   include what options.  Do you expect that a similar trend might
   continue?  It might be useful to set some ground rules for future
   message types (default option behaviour for example).

    There should also be an option type registry.  Option types 0-49151
    can be assigned referencing an RFC (it may be Informational), while
    types 49152-65535 are freely available for experimental, private or
    vendor specifc use.  The registry should include the options defined
    in Section 3.2.

* s/specifc/specific/.  Per above comment, if someone reserves an 
option type, is (s)he required to specify anything about its 
handling with various message types (e.g. OK with init?)?

With both of these proposed IANA registries, it could be nice for you 
to write a table or list here that IANA could copy-paste to its web 
page so the registration would be smooth and without 
misunderstandings.

    discussed in Section 8).

* s/)//

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

nded to figure out multicast
   path MTU, but I'm not sure if the current spec is fleshed enough
   with this respect to support this.

     By default, clients should send at most
     one request per second, and servers should perform rate limiting
     if a client sends more frequent requests.

* I don't agree with the latter recommendation.  I believe it's useful
   to be able to use a higher than 1pps rate without having to agree
   beforehand to waive rate-limits.  Based on security considerations
   text, a suitable compromise would be that the above would apply if
   INIT messages were not used (providing return routability).  If Init
   is used, a rate-limit, if in place, should not be lower than
   ~100pps.

Editorial comments:

  mechanism, but uses UDP (RFC 768 [2] and RFC 2460 [3]) and requires

* I don't see why RFC 2460 is referred to here; clarify or remove.

   IANA is requested to provide a UDP port number for use by this
    protocol, and also to provide registries for message and option
    types.

* are you looking for a "user" or "well-known" port number?  Probably
   the latter; it should be mentioned here.

   There should be a message types registry.  Message types are in the
    range 0-255.  Message types 0-191 can be assigned referencing an RFC
    (it may be Informational), while types 192-255 are freely available
    for experimental, private or vendor specifc use.  The registry should
    include the messages defined in Section 5

* missing dot at the end.  Are there any requirements for new message
   types?  In S 5, the matrix is quite detailed which message types can
   include what options.  Do you expect that a similar trend might
   continue?  It might be useful to set some ground rules for future
   message types (default option behaviour for example).

    There should also be an option type registry.  Option types 0-49151
    can be assigned referencing an RFC (it may be Informational), while
    types 49152-65535 are freely available for experimental, private or
    vendor specifc use.  The registry should include the options defined
    in Section 3.2.

* s/specifc/specific/.  Per above comment, if someone reserves an 
option type, is (s)he required to specify anything about its 
handling with various message types (e.g. OK with init?)?

With both of these proposed IANA registries, it could be nice for you 
to write a table or list here that IANA could copy-paste to its web 
page so the registration would be smooth and without 
misunderstandings.

    discussed in Section 8).

* s/)//

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Oct 2008 17:27:57 +0100

Pekka Savola wrote:
> RFC2026 Section 4.2.1 or Section 3.3(d) being quite right with this spec.
>
> Substantial comments:
>
I'd have expected the responses to be small enough to fit in typical 
deployed tunnels, etc.
>   probably also easily be used or extended to figure out multicast
I agree that the current Spec does  not address the issues needed to do 
this.
>   is used, a rate-limit, if in place, should not be lower than
<snip>

Do you mean 100 pps per server or per session - i.e. are you suggesting 
this rate to each destination (ip,port}? This seems very high for this 
sort of application. I don't really understand this.

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Oct 2008 17:27:57 +0100

<snip>

Gorry

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Oct 2008 20:06:30 +0300 (EEST)

On Thu, 23 Oct 2008, Gorry Fairhurst wrote:
> I'd have expected the responses to be small enough to fit in typical deployed 
> tunnels, etc.

I'd expect one would be able to set the packet size in a similar 
manner as with ping (FWIW, ping also allows setting PMTUD and DF 
options).  The data would be padded to the desired length e.g. by 
including the necessary amount of TLVs with zero length.  The spec 
says that an option must not be repeated, but unknown options must be 
echoed.  (It's not clear whether an unknown option may be repeated; 
I'd guess so, otherwise the protocol would not be extensible in that 
respect). So, by sending either 250 different or 250 times the same 
TLV with zero length you could pad the packets to the length you want. 
Or there could be a specific padding option for this purpose; this 
might be the cleanest.

Earlier versions of the spec had a reply size option but with an 
approach like above there is no amplification factor if the client is 
required to send essentially the same amount of data as the server is 
echoing back.

>> ~ 100pps.
> Do you mean 100 pps per server or per session - i.e. are you suggesting this 
> rate to each destination (ip,port}? This seems very high for this sort of 
> application. I don't really understand this.

Yes.  IMHO, this is similar to ICMP or UDP echo protocol.  If the 
client sends at 10pps or 100pps (and consumes that much bandwidth), it 
shouldn't be a problem that the server uses the same amount of 
bandwidth.  Compared to unicast, the potential amplification factor of 
2 should not be a security problem.

What I'm saying that it would be fine that an administrator sets the 
rate-limit to a value (s)he thinks is appropriate if (s)he thinks one 
is needed.  But what I'm really saying is that the _protocol itself_ 
should specify such rate-limiters unless there's a very good reason 
for that (and I don't see it here).  ICMP echo reply/request etc specs 
have no defined rate-limit, and that's a good thing.  To debug fast 
convergence, I often ping with 10pps or 100pps frequency, and the same 
thing should be possible with multicast as well.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Oct 2008 20:06:30 +0300 (EEST)

---

From: Stig Venaas <[email-masked]>
Date: Fri, 24 Oct 2008 12:53:02 +0200

>> I'd have expected the responses to be small enough to fit in typical 

They usually will. Several new options could be defined and used and the
size would still be sufficiently small.
> 
> I'd expect one would be able to set the packet size in a similar manner 
> as with ping (FWIW, ping also allows setting PMTUD and DF options).  The 
> data would be padded to the desired length e.g. by including the 
> necessary amount of TLVs with zero length.  The spec says that an option 
> must not be repeated, but unknown options must be echoed.  (It's not 
> clear whether an unknown option may be repeated; I'd guess so, otherwise 
> the protocol would not be extensible in that respect). So, by sending 
> either 250 different or 250 times the same TLV with zero length you 
> could pad the packets to the length you want. Or there could be a 
> specific padding option for this purpose; this might be the cleanest.

A client could use an unknown option as you suggest, but need then just
use one option, setting the desired option length. Anyway, a better
way would be for a client implementation to just extend the client id.
The client id length can be whatever the client needs.

> required to send essentially the same amount of data as the server is 

Given that with normal use there should be no MTU issues, I haven't
tried to specify this. However with the currently defined options a
client implementation could allow for setting the packet size (and
extending client id as I noted above). Whether PMTUD is done is
another matter. For IPv4, multicast PMTUD would AFAIK not work. With
IPv6 I believe it is supposed to work, but not all router
implementations send ICMP Packet Too Big to the source.

One possible future extension could be an option for the server to
report the PMTUD perhaps.

Anyway, do you really think this draft should discuss this?

>>>    is used, a rate-limit, if in place, should not be lower than

Note that is says per default. As is written another place in the draft
a server implementation could have configuration options allowing higher
rates for certain IP addresses (which should then use INIT for return
routability). In my implementation I might allow this from say 0.0.0.0/0
to get this for all clients if you want. I think 1pps is a reasonable
default, but I'm happy to set this to whatever the wg wants.
>>
>> Do you mean 100 pps per server or per session - i.e. are you 
>> suggesting this rate to each destination (ip,port}? This seems very 
>> high for this sort of application. I don't really understand this.
> 
> Yes.  IMHO, this is similar to ICMP or UDP echo protocol.  If the client 
> sends at 10pps or 100pps (and consumes that much bandwidth), it 
> bandwidth.  Compared to unicast, the potential amplification factor of 2 
> should not be a security problem.

Agree.

> rate-limit to a value (s)he thinks is appropriate if (s)he thinks one is 
> needed.  But what I'm really saying is that the _protocol itself_ should 
> specify such rate-limiters unless there's a very good reason for that 
> (and I don't see it here).  ICMP echo reply/request etc specs have no 

It's only a recommendation. It's not written in normative language. I
guess I could take it out of the Server Behaviour section and just
suggest rate limiting in the Recommendations for Implementers section.

> defined rate-limit, and that's a good thing.  To debug fast convergence, 
> I often ping with 10pps or 100pps frequency, and the same thing should 
> be possible with multicast as well.

Yes, this may be useful, especially for more fine grained measurements
of tree setup, switch to SPT etc. I think a reasonable implementation
should allow this by configuration, but not by default. I'm trying to
keep the protocol flexible, e.g., it may be used both on the Internet
with public servers and in closed networks where the requirements are
quite different. If you use it for measurements in a more controlled
network, then you would also probably be able to configure you server
to accept this.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 24 Oct 2008 12:53:02 +0200

Agree.

Stig

---

From: Pekka Savola <[email-masked]>
Date: Fri, 24 Oct 2008 14:20:15 +0300 (EEST)

> Anyway, do you really think this draft should discuss this?

I don't think the draft needs to specified MTU probing mechanisms as 
long as it isn't ruled out in the spec.  They can be included if we 
ever revise this spec based on implementation experience.

But wrt packet sizes, MTU etc in general -- in IPv4, the minimum IP 
MTU is 68 bytes and this could use more than that.  So some discussion 
about DF set/clear and fragmentation might be useful.  Wrt. IPv6, this 
is even shorter due to 1280 minimum length and always fragmenting at 
the source.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 24 Oct 2008 14:20:15 +0300 (EEST)

---

From: Stig Venaas <[email-masked]>
Date: Fri, 24 Oct 2008 13:51:05 +0200

Pekka Savola wrote:
> long as it isn't ruled out in the spec.  They can be included if we ever 
> revise this spec based on implementation experience.
> 
> But wrt packet sizes, MTU etc in general -- in IPv4, the minimum IP MTU 
> is 68 bytes and this could use more than that.  So some discussion about 

OK, but in practice it would not be an issue. I don't see much value in
it, but I can always add a couple of sentences.

> DF set/clear and fragmentation might be useful.  Wrt. IPv6, this is even 
> shorter due to 1280 minimum length and always fragmenting at the source.
> 

Yes. Although there are some interesting things, e.g. whether Packet too
Big is sent when too large for PIM register etc... Anyway, I don't want
to dig into that :)

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 24 Oct 2008 13:51:05 +0200

Stig

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 24 Oct 2008 14:43:04 +0100

Stig Venaas wrote:
>> options).  The data would be padded to the desired length e.g. From [email-masked]  Fri Oct 24 06:41:52 2008
Date: Fri, 24 Oct 2008 14:43:04 +0100
From: Gorry Fairhurst <[email-masked]>
Organization: The University of Aberdeen is a charity registered in Scotland, 
	No SC013683. 
To: Stig Venaas <[email-masked]>
Cc: [email-masked]
Subject: Re: [MBONED] WGLC on SSMPING
Reply-To: [email-masked]
Sender: [email-masked]

Stig Venaas wrote:
>> options).  The data would be padded to the desired length e.g. byby 
>> have no 
>> defined rate-limit, and that's a good thing.  To debug fast 
>> thing should be possible w 
>> have no 
>> defined rate-limit, and that's a good thing.  To debug fast 
>> thing should be possible witith multicast as well.
> 
I was also thinking that a default rate limit for Internet-wide
deployment of 1 pps seems acceptable for many uses and is mostly 
harmless, (unlikely to result in  any negative effects). This even seems 
safe to use for groups that carry other actual user traffic on the same 
group address (which I thought was a nice property).

Internal to networks, people can tweak this as they need, but that 
doesn't seem like an IETF decision to me.

Gorry

h multicast as well.
> network, then you would also probably be able to configure you server
I was also thinking that a default rate limit for Internet-wide
deployment of 1 pps seems acceptable for many uses and is mostly 
harmless, (unlikely to result in  any negative effects). This even seems 
safe to use for groups that carry other actual user traffic on the same 
group address (which I thought was a nice property).

Internal to networks, people can tweak this as they need, but that 
doesn't seem like an IETF decision to me.

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 24 Oct 2008 14:44:00 +0100

Stig Venaas wrote:
>> about 
I've lost the note of the proposed change... Is it to specify a client 
*can* fragment UDP datagrams at the IP layer when sending to a server 
and vice versa? - I am not sure what this adds.

Defining how to handle DF in IPv4 or PTB in IPv6 would need some PMTUD 
awareness - especially since the test ICMP messages in response to the 
request go back to the server, and I guess the client would really like 
to know what happened. This seems like a new bit of machinery. I think 
you're agreeing to leave this out of this version of the spec.?

>> DF set/clear and fragmentation might be useful.  Wrt. IPv6, this is 
>> even shorter due to 1280 minimum length and always fragmenting at the 
>> source.
>>
> 

For IPv6, we *could* mandate the packet size is never greater than 1280 
less some (unknown)
value for tunnel headers. My choice would also be not do this in the Spec.

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 24 Oct 2008 14:44:00 +0100

Gorry

---

From: Stig Venaas <[email-masked]>
Date: Fri, 24 Oct 2008 16:08:02 +0200

Gorry Fairhurst wrote:
>>> MTU is 68 bytes and this could use more than that.  So some 
>>> discussion about 
>>

My suggestion is to not change the protocol, but I could add a couple
of sentences of text discussing this if people want.

> and vice versa? - I am not sure what this adds.

My thinking on this is simply that the client sends a datagram. If it
is too large, then it is fragmented (by the source or on the path, I
don't really think we should discuss or require the use of DF and
PMTUD). I think this can be fully left to the client implementation and
host system. Provided the datagram is successfully reassembled at the
server system, the server responds. Similarly, I don't think we need to
say whether the server should set DF or not...

I think perhaps I want to add a sentence emphasising that it is ok for
the datagram size to exceed the MTU. In general fragmentation is a bad
thing, but it is useful for a tool like this to do tests with fragmented
multicast datagrams.

> you're agreeing to leave this out of this version of the spec.?

At least I am agreeing :)

> value for tunnel headers. My choice would also be not do this in the Spec.

Yes, I don't want to mandate it, since it would make it impossible to
perform fragmentation tests.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 24 Oct 2008 16:08:02 +0200

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 28 Oct 2008 15:35:22 +0100

I'll make another response to this one. Thanks for good input Pekka,
even though I don't agree with all of it. I'm now working on a new
revision based on your comments, see below.

Pekka Savola wrote:
> latest version doesn't yet support this spec I think, but I'd guess the
> mods in SVN tree do), and it has been found to be useful; for example,

Yes, the implementation in SVN is according to this revision. I'll make
a release soon.

> we're using this in our multicast monitoring systems. Proposed Standard
> does not require multiple implementations.  If this were Experimental,
> it would need to be justified, and I don't see RFC2026 Section 4.2.1 or
> Section 3.3(d) being quite right with this spec.

We'll see by Monday what people think. I plan to submit a new revision
before the deadline on Monday.

>   with this respect to support this.

I've added some text on this, you may see the changes below. Basically I
don't want to define or enforce anything here. But I believe Path MTU
Discovery could easily be defined in the future. Basically a client
could request a "Path MTU" option from the server. If the server sees
this, it should perform Path MTU discovery if possible, and for each
reply it can include the option with the current Path MTU. A server
not supporting this can just ignore the request and not include it in
the reply. But I think this can be considered later on.

There are other wishes as well. E.g. an option for requesting a
specific DSCP for replies.

>   is used, a rate-limit, if in place, should not be lower than

I've now removed this from the "server behaviour" section, and rewritten
the text in the "Recommendations for Implementers" section. Let me know
if this is OK.

> * I don't see why RFC 2460 is referred to here; clarify or remove.

Not sure why I did, removed 2460.

>   the latter; it should be mentioned here.

Yes

>   message types (default option behaviour for example).

Don't think I want to add any ground rules. I don't have any plans for
new message types, but want to have the possibility.

> * s/specifc/specific/.  Per above comment, if someone reserves an option
> type, is (s)he required to specify anything about its handling with
> various message types (e.g. OK with init?)?

Not sure I want to put that here, but I would expect an option
specification to note how/where the option can be used. I expect most
options would only be used in echo request/reply.

> With both of these proposed IANA registries, it could be nice for you to
> write a table or list here that IANA could copy-paste to its web page so
> the registration would be smooth and without misunderstandings.

Done. See below.
> * s/)//

Below are the non-editorial changes I've made so far,

Stig

Section 3., paragraph 3 (between old paragraph 2 and 3):
NEW:
    The size of the protocol messages is generally smaller than the Path
    MTU and fragmentation is not a concern.  There may however be cases
    where the Path MTU is really small, or that a client sends large
    requests in order to verify that it can receive fragmented multicast
    datagrams.  This document does not specify whether Path MTU Discovery
    should be performed, etc.  A possible extension could be an option
    where a client requests Path MTU Discovery and receives the current
    Path MTU from the server.

OLD (Removed from end of section 7):
    By default, a server should perform rate limiting and for a given
    client, respond to at most one Request message per second.  A leaky
    bucket algorithm is suggested, where the rate can be higher for a few
    seconds, but the average rate should by default be limited to a
    message per client per second.

Section 8., paragraph 3:
OLD:

    Servers must perform rate limiting, to guard against this protocol
    being used for DoS attacks.  By default, clients should send at most
    one request per second, and servers should perform rate limiting if a
    client sends more frequent requests.  Server implementations should
    provide administrative control of which client IP addresses to serve,
    and may also allow certain clients to perform more rapid requests.
    Implementers of applications/tools using this protocol should
    consider the UDP guidelines [6], in particular if clients are to
    send, or servers are to accept, requests at rates exceeding one per
    second.

NEW:

    Clients should by default send at most one request per second.
    Servers should perform rate limiting, to guard against this protocol
    being used for DoS attacks.  The server should for a given client,
    respond to at most one Request message per second.  A leaky bucket
    algorithm is suggested, where the rate can be higher for a few
    seconds, but the average rate should by default be limited to a
    message per client per second.  Server implementations should provide
    administrative control of which client IP addresses to serve, and may
    also allow certain clients to perform more rapid requests.
    Implementers of applications/tools using this protocol should
    consider the UDP guidelines [5], in particular if clients are to
    send, or servers are to accept, requests at rates exceeding one per
    second.  If higher rates are allowed for specific IP addresses, then
    Init messages and the Session ID option should be used to help
    prevent spoofing.  See Section 11.

Section 10., paragraph 3:
OLD:

NEW:

    There should also be an option type registry.  Option types 0-49151
    require specification (an RFC or other permanent and readily
    available reference), while types 49152-65535 are freely available
    for experimental, private or vendor specifc use.  The registry should
    include the options defined in Section 3.2.

    The registry definition could be as follows:

    Multicast Ping Protocol Parameters:

    Registry Name: Multicast Ping Protocol Message Types
    Reference: [this doc]
    Registration Procedures: Specification Required

    Registry:
    Type         Name                                  Reference
    -----------  ------------------------------------  ----------
    65           Echo Reply                            [this doc]
    73           Init                                  [this doc]
    81           Echo Request                          [this doc]
    83           Server Response                       [this doc]
    192-255      Experimental/Private/Vendor Specific

    Registry Name: Multicast Ping Protocol Option Types
    Reference: [this doc]
    Registration Procedures: Specification Required

    Registry:
    Type         Name                                  Reference
    -----------  ------------------------------------  ----------
    0            Version                               [this doc]
    1            Client ID                             [this doc]
    2            Sequence Number                       [this doc]
    3            Client Timestamp                      [this doc]
    4            Multicast Group                       [this doc]
    5            Option Request Option                 [this doc]
    6            Server Information                    [this doc]
    7            Reserved                              [this doc]
    8            Reserved                              [this doc]
    9            TTL                                   [this doc]
    10           Multicast Prefix                      [this doc]
    11           Session ID                            [this doc]
    12           Server Timestamp                      [this doc]
    49152-65535  Experimental/Private/Vendor Specific
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Stig Venaas <[email-masked]>
Date: Tue, 28 Oct 2008 15:35:22 +0100

Yes

Done. See below.

Stig

Section 8., paragraph 3:
OLD:

NEW:

NEW:

    Registry:
    Type         Name                                  Reference

    Registry:
    Type         Name                                  Reference

---

From: Stig Venaas <[email-masked]>
Date: Tue, 28 Oct 2008 15:42:22 +0100

> to definitively distinguish between SPT and RPT. 

I had another look at this now, and I think the draft does explain it in
sufficient detail.

It says in section 2:

   differences in the number of hops, RTT, etc.  The number of multicast
   hops and changes in the number of hops over time, may also reveal
   details about the multicast tree and multicast tree changes.  E.g.,
   with PIM-SM one may be able to tell whether the forwarding is on a
   shared or source-specific tree and when an eventual switch occurs.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 28 Oct 2008 15:42:22 +0100

It says in section 2:

Stig

---

From: Pekka Savola <[email-masked]>
Date: Tue, 28 Oct 2008 17:52:21 +0200 (EET)

> the text in the "Recommendations for Implementers" section. Let me know

I'm somewhat uncomfortable with this text.  It reads as if this is a 
security concern, while it seems this is really a concern about 
congestion and compliance to draft-ietf-tsvwg-udp-guidelines-11.txt 
(In RFC Ed queue).  My suggestions for this below:

>    respond to at most one Request message per second.

Replace with:

Clients should by default send at most one request per second. Servers 
should perform rate limiting, to avoid congestion and to comply with 
the UDP usage guidelines [5].  For example, the server should for a 
given client, respond to at most one Request message per second.

>    Init messages and the SeFrom [email-masked]  Tue Oct 28 08:52:33 2008
Date: Tue, 28 Oct 2008 17:52:21 +0200 (EET)

> the text in the "Recommendations for Implementers" section. Let me know

I'm somewhat uncomfortable with this text.  It reads as if this is a 
security concern, while it seems this is really a concern about 
congestion and compliance to draft-ietf-tsvwg-udp-guidelines-11.txt 
(In RFC Ed queue).  My suggestions for this below:

>    respond to at most one Request message per second.

Replace with:

Clients should by default send at most one request per second. Servers 
should perform rate limiting, to avoid congestion and to comply with 
the UDP usage guidelines [5].  For example, the server should for a 
given client, respond to at most one Request message per second.

>    Init messages and the Sessssion ID option should be used to help

Maybe this could be broken out to a separate paragraph. (Note that the 
above suggestion slightly overlaps with this.)

>options would only be used in echo request/reply.

If you would expect the option specification to include information 
where it must be used, why not specify this as a heads-up in IANA 
considerations section so the specs will at least say so.  For 
example: "A specification must describe the behaviour with known 
message types and option types, and should describe the default 
behaviour with unknown message types and option types".

>....

Do you expect that to get an experimental/private/vendor specific 
Message Type or Option Type, the user should register it with IANA, or 
just more or less randomly pick one from these ranges?  The draft 
isn't clear.  For experimentation purposes, it's typical to reserve 
some (let's say 2-3 for Message types, 16-100 for option types) values 
which have been separately called out in the IANA registry, and the 
user of these values is not expected to report IANA about it.

I think the draft needs to be clearer on the registration of these 
values (or lack of it).  Preferably policies should be ones described 
in RFC 5226.

I assume that if a vendor request a vendor specific option or message 
type, they don't need to provide a reference to any documentation, 
right?

ion ID option should be used to help
>    prevent spoofing.  See Section 11.

Maybe this could be broken out to a separate paragraph. (Note that the 
above suggestion slightly overlaps with this.)

>options would only be used in echo request/reply.

If you would expect the option specification to include information 
where it must be used, why not specify this as a heads-up in IANA 
considerations section so the specs will at least say so.  For 
example: "A specification must describe the behaviour with known 
message types and option types, and should describe the default 
behaviour with unknown message types and option types".

>....

Do you expect that to get an experimental/private/vendor specific 
Message Type or Option Type, the user should register it with IANA, or 
just more or less randomly pick one from these ranges?  The draft 
isn't clear.  For experimentation purposes, it's typical to reserve 
some (let's say 2-3 for Message types, 16-100 for option types) values 
which have been separately called out in the IANA registry, and the 
user of these values is not expected to report IANA about it.

I think the draft needs to be clearer on the registration of these 
values (or lack of it).  Preferably policies should be ones described 
in RFC 5226.

I assume that if a vendor request a vendor specific option or message 
type, they don't need to provide a reference to any documentation, 
right?

---

From: Stig Venaas <[email-masked]>
Date: Wed, 29 Oct 2008 09:06:09 +0100

Pekka Savola wrote:
> congestion and compliance to draft-ietf-tsvwg-udp-guidelines-11.txt (In
> RFC Ed queue).  My suggestions for this below:

IMO it is also a security concern. If a server allows pinging to
arbitrary groups, there is a risk that some client uses this server to
send large amounts of data to a group that is used for something else.
Of course a client could more easily do this by sending directly to the
group itself, but still, I think having a default low rate limit reduces
the risk.

> should perform rate limiting, to avoid congestion and to comply with the
> UDP usage guidelines [5].  For example, the server should for a given
> client, respond to at most one Request message per second.
> 
> considerations section so the specs will at least say so.  For example:
> "A specification must describe the behaviour with known message types
> and option types, and should describe the default behaviour with unknown
> message types and option types".

OK, I think this is obvious and superfluous, but I guess I can add it.

> just more or less randomly pick one from these ranges?  The draft isn't
> clear.  For experimentation purposes, it's typical to reserve some
> (let's say 2-3 for Message types, 16-100 for option types) values which
> have been separately called out in the IANA registry, and the user of
> these values is not expected to report IANA about it.
> 
> values (or lack of it).  Preferably policies should be ones described in
> RFC 5226.

You're right, I should be clear on this. I also realise that for what I
want, experimental seems right. If something is used "permanently", then
I think it should be in the registry, even if kind of vendor specific.

> type, they don't need to provide a reference to any documentation, right?

Well, I now think it's better that they do. Else you risk some bad
interoperability problems. I'm hoping that people can use clients
and servers from different vendors (e.g. a public server on the Internet
that can be used with different client implementations). I should have
given this more thought earlier.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 29 Oct 2008 09:06:09 +0100

Stig

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2008 14:41:40 +0200 (EET)

> group itself, but still, I think having a default low rate limit reduces

This problem is not described in Security Considerations section.  I 
agree this is not a big deal.  The main 'benefit' is that if you send 
the traffic yourself, you cannot spoof the IP address (as RPF checks 
prevent that).  By using an mping server, to be able to trace the 
attack to you, the attack first needs to be traced to the mping server 
(and possibly its logs, if any).

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2008 14:41:40 +0200 (EET)

---

From: Stig Venaas <[email-masked]>
Date: Wed, 29 Oct 2008 14:18:01 +0100

Pekka Savola wrote:
> prevent that).  By using an mping server, to be able to trace the attack
> to you, the attack first needs to be traced to the mping server (and
> possibly its logs, if any).

I now added this paragraph under security considerations:

For ASM (Any-Source Multicast) a host could also make a multicast
ping server send multicast packets to a group that is used for
something else, possibly disturbing other uses of that group. The
main concern is bandwidth. Since there is a well-known port, it
should not be received by other applications. Due to this, a server
on the Internet SHOULD perform rate limiting.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 29 Oct 2008 14:18:01 +0100

Stig

---

From: "Tony Ballardie" <[email-masked]>
Date: Thu, 30 Oct 2008 10:40:50 -0000

>  shared or source-specific tree and when an eventual switch occurs.

I still think this needs tightening up. You can't necessarily infer a
change from RPT to SPT just from a change in the number of hops.
Topologies change. Unless there's some other mechanism for explicitly
detecting RPT-to-SPT the reference should be left out.

Tony

---

From: "Tony Ballardie" <[email-masked]>
Date: Thu, 30 Oct 2008 10:40:50 -0000

Tony

---

From: Stig Venaas <[email-masked]>
Date: Thu, 30 Oct 2008 11:54:48 +0100

> detecting RPT-to-SPT the reference should be left out.

Yes, you can't necessarily infer, but it says "one may be able to",
which is true. I think it's worth pointing out that knowing the hop
count is useful. Someone still needs to interpret the output. Depending
on topology, when it happens etc. one may be able to make an educated
guess at what it means.

Anyway, if you really feel that is too strong, I could remove the
last sentence (one starting with E.g.).

The hop count may also in some cases show that forwarding is via
registers or MSDP as well, which I'm not noting in the draft.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 30 Oct 2008 11:54:48 +0100

Stig

---

From: "Tony Ballardie" <[email-masked]>
Date: Thu, 30 Oct 2008 11:23:04 -0000

> last sentence (one starting with E.g.).

Without specifying *how* you could achieve it, since it would be a "nice
to have" it may leave people scratching their heads as to how on earth
you could derive the RPT-SPT distinction, and imply there's something
out there that does it. It just avoids that
confusion/mis-interpretation.

Tony

---

From: "Tony Ballardie" <[email-masked]>
Date: Thu, 30 Oct 2008 11:23:04 -0000

Tony

---

From: Stig Venaas <[email-masked]>
Date: Thu, 30 Oct 2008 12:50:53 +0100

> confusion/mis-interpretation.

OK, I can see that. I've removed that sentence then.

I plan to submit a new version by Monday. That is the deadline for draft
submissions, and by then we hopefully know whether to go for standards
track (seems everyone in favour so far).

_______________________________________________
MBFrom [email-masked]  Thu Oct 30 04:51:03 2008
Date: Thu, 30 Oct 2008 12:50:53 +0100
From: Stig Venaas <[email-masked]>
To: Tony Ballardie <[email-masked]>
Cc: [email-masked]
Subject: Re: [MBONED] WGLC on SSMPING
Sender: [email-masked]

> confusion/mis-interpretation.

OK, I can see that. I've removed that sentence then.

I plan to submit a new version by Monday. That is the deadline for draft
submissions, and by then we hopefully know whether to go for standards
track (seems everyone in favour so far).

MBONONED mailing list

ED mailing list
[email-masked]