[ippm] AD review: draft-ietf-ippm-twamp-06.txt

[Lars Eggert <[e-mail]>]

Hi,

I'm trying to to the AD review that normally happens after a WG  
requests publication early, such that it overlaps with WGLC. For this  
document, that hasn't happened, but at least I'm not very late,  
because it is still being discussed.

Summary: Not quite ready. My main concern is around the TWAMP light  
variant, and there are a number of small things where the document  
would be improved by a more careful description or some editorial  
changes.

Detailed comments:

INTRODUCTION, paragraph 10:
   Nit: s/Measurment/Measurement/ (everywhere in the footer)


INTRODUCTION, paragraph 11:
 >     The IP Performance Metrics (IPPM) working group's One-way Active
 >     Measurement Protocol [RFC4656] (OWAMP) provides a common protocol
 >     for measuring one-way metrics between network devices.

   Rephrase the first sentence to not talk about the IPPM WG - it's
   ephemeral and for the RFC it doesn't matter where OWAMP came from.
   (In other words, cut "IP Performance Metrics (IPPM) working  
group's".)


Section 1., paragraph 1:
 >     The IETF IP Performance Metrics (IPPM) working group has  
completed
 >     a draft standard for the round-trip delay [RFC2681] metric.  IPPM
 >     has also completed a protocol for the control and collection of
 >     one-way measurements, the One-way Active Measurement Protocol
 >     (OWAMP) [RFC4656].

   See above - rephrase to not talk about IPPM.


Section 1., paragraph 2:
 >     Two-way measurements are common in IP networks, primarily because
 >     time accuracy is less demanding for round-trip delay

   I don't quite understand what you mean by "time accuracy is less
   demanding".


Section 2., paragraph 0:
 >  2. Protocol Overview

   This section is almost word-by-word identical to a big chunk of
   section 1.2. Merge?


Section 3., paragraph 2:
 >     All OWAMP [RFC4656] Control messages except for the Fetch-Session
 >     command apply to TWAMP.

   Does "apply to" mean that TWAMP implementations MUST implement all
   these OWAMP control messages? If yes, say so with RFC2119 terms.


Section 3.5, paragraph 2:
 >     In order to distinguish the session as a two-way versus a one-way
 >     measurement session the first octet of the Request-Session  
command
 >     MUST be set to 5.  Value of 5 indicates that this is a
 >     Request-Session for a two-way metrics measurement session.

   That text is a bit misleading. An "OWAMP Request-Session" will always
   have 1 in that octet. What you're doing here is defining a
   "Request-TW-Session" command (this is how it's called in the IANA
   registry below) that looks and is mostly processed like an OWAMP
   message, but has a 5 in the first octet (because OWAMP uses first
   octet codes 2-4 for other commands.) You should make sure that you
   call the command "Request-TW-Session" everywhere in the document, to
   be consistent with the code allocated in the IANA registry.


Section 3.5, paragraph 3:
 >     In TWAMP, the first octet is referred to as the Command Number,  
and
 >     the Command Number is a recognized extension mechanism. Readers  
are
 >     encouraged to consult the TWAMP Command Number Registry to
 >     determine if there have been additional values assigned.

   I'd argue that because this document creates a registry that in
   addition to TWAMP also covers OWAMP, it should update RFC4656, if  
only
   to alert implementers of OWAMP that an IANA registry exists that
   matters for OWAMP but that RFC4656 doesn't descibe.


Section 3.5, paragraph 4:
 >     If a TWAMP server receives an unexpected command number, it  
SHOULD
 >     respond with the Accept field set to 3 (meaning "Some aspect of
 >     request is not supported") in the Server-Start message.

   s/SHOULD/MUST/ (or else explain in which cases the SHOULD may
   disregarded)


Section 3.5, paragraph 6:
 >     Both Conf-Sender field and Conf-Receiver field MUST be set to 0
 >     since the Session-Reflector will both receive and send packets,  
and
 >     the roles are established according to which host initiates the  
TCP
 >     connection for control.  The server MUST interpret any non-zero
 >     value as zero.

   If the field is not zero, something is clearly wrong with the peer -
   shouldn't the session be aborted?


Section 3.5, paragraph 10:
 >     They MAY be set to 0, in which case the IP addresses used for the
 >     Session-Sender to Session-Reflector Control Message exchange MUST
 >     be used in the test packets.

   This seems to be a difference to OWAMP. Any particular reason why?
   (For TWAMP Light?)


Section 3.5, paragraph 14:
 >     Point (DSCP) as defined in [RFC2474].  The same value of DCSP  
MUST

   Nit: s/DCSP/DSCP/


Section 3.9, paragraph 1:
 >     The purpose of TWAMP is measurement of two-way metrics.  Two-way
 >     measurements do not rely on packet level data collected by the
 >     Session-Reflector such as sequence number, timestamp, and TTL.   
As
 >     such the protocol does not require the retrieval of packet level
 >     data from the Server and the Fetch-Session command is not defined
 >     in TWAMP.

   Since Fetch-Session is defined in OWAMP and TWAMP is a variant of
   that, I'd be good to define what TWAMP should do if it somehow
   receives a Fetch-Session message. (Suggestion: stop fail.)


Section 4.2.1, paragraph 21:
 >     Implementation note: Naturally, the key schedule for each
 >     TWAMP-Test session MAY be set up only once per session, not once
 >     per packet.

   s/MAY/MUST/ (or lowercase, since it's about an implementation choice
   and not the specification)


Section 5.1, paragraph 3:
 >     The responder follows the Session-Reflctor behavior of TWAMP as

   Nit: s/Session-Reflctor/Session-Reflector/


Section 5.2, paragraph 0:
 >  5.2 TWAMP Light

   If I understand this correctly, TWAMP Light requires a different
   processing than Complete TWAMP. The "implementers guide" section is
   not the place to define specification variants, especially because
   it's not clear that Light and Complete imoplementations can
   interoperate without knowing which variant the other side is using.  
If
   the two variants are desired by the WG, they need to be described in
   the specification, and there needs to be a mechanism such that Light
   and Complete implementations can figure out what variant they're
   talking to at the other end.


Section 8.1, paragraph 1:
 >     IANA will create an TWAMP-Control Command registry.  TWAMP- 
Control
 >     commands are specified by the first octet in OWAMP-Control  
messages
 >     as shown in section 3.4 of [RFC4656], and modified by this
 >     document. Thus this registry may contain sixteen possible values.

   Elsewhere in this document, the term "command number" is used. Please
   use one term consistently throughout the document.


Section 8.4, paragraph 2:
 >     Value  Description             Semantics Definition
 >     0      Reserved
 >     1      Forbidden
 >     2      Start-Sessions          RFC4656, Section 3.7
 >     3      Stop-Sessions           RFC4656, Section 3.8
 >     4      Fetch-Session           RFC4656, Section 3.9
 >     5      Request-TW-Session      this document, Section 3.5
 >     6      Experimentation         undefined, see Section 8.3.

   This document doesn't specify how implementations shold react if
   Reserved or Forbidden values are received. (Is there a difference?)


Section 10.1, paragraph 1:
 >        [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
 >                   Zekauskas, M., "A One-way Active Measurement  
Protocol
 >                   (OWAMP)", draft-ietf-ippm-owdp-11.txt, October  
2004.

   s/draft-ietf-ippm-owdp-11.txt/RFC 4656/


Section 10.1, paragraph 5:
 >        [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing
 >                  an IANA Considerations Section in RFCs, RFC 2474,
 >                  October 1998.

   s/RFC 2474/RFC 2434/ (copy&paste error?)

_______________________________________________
ippm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ippm