Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)
draft-ietf-rmonmib-raqmon-pdu-14

IANA Comments:
Upon approval of this document the IANA will assign a port for RAQMON Framework in the range above 5000 to accommodate port number allocation practice within the Unix operating system.  We understand this to be the only IANA Action.

Proto write-up for the record:

-----Original Message-----
From: rmonmib-bounces@ietf.org [mailto:rmonmib-bounces@ietf.org]On
Behalf Of Andy Bierman
Sent: Saturday, January 28, 2006 08:04
To: Bert Wijnen
Cc: rmonmib@ietf.org; David Kessens; iesg-secretary@ietf.org
Subject: [RMONMIB] I-D Publication Request:
draft-ietf-rmonmib-raqmon-pdu-12.txt


[Area] OPS-NM
[WG]  RMONMIB
[I-D]  draft-ietf-rmonmib-raqmon-pdu-12.txt
[Qver] draft-ietf-proto-wgchair-doc-shepherding-05.txt
[Shep] Andy Bierman

1.a) Yes, the WG Chair has reviewed this version of the document.

1.b) Yes it has had adequate review; no concerns about the review.

1.c) A security review of this document would be helpful.

1.d) There is a potential overlap between the RAQMON protocol and
      the IPFIX and/or RTCP-XR work, but there are enough differences
      in applicability and complexity that this should not be
      a significant issue.  RAQMON is a complete, distributed
      SNMP-based monitoring system, integrated with the RMON
      family of MIBs.  As such, it is intended to be applicable
      to many different types of protocols.  If a specialized
      protocol for VoIP monitoring is desired, then RTCP-XR
      should probably be used instead.  If SNMP and/or RMON
      integration are not desired, then IPFIX would be a
      suitable choice.

1.e) The WG initially attempted to avoid creating a new
    protocol, and tried to use RTCP as an application
    transport, but this turned out to be an inappropriate
    application for RTCP.  SNMP Notifications were also
    specified as a transport, and still remains in the
    document, although it is not clear how widely deployed
    this transport will become.  The WG finally created a
    TCP based transport for RAQMON PDUs, and after significant
    debate, there is strong WG consensus that this document
    meets the needs of the data source to data collector
    communications component of the RAQMON Framework.

1.f) No appeals have been threatened.

1.g) Yes, but there is one minor nit that will be fixed
      before RFC publication. (See ID-nit log below).

1.h) Yes, references are split.
    Yes, there are references to unpublished documents,
    (the other RAQMON drafts), but they are also ready
    for publication.

1.j) I-D Submission Summary

Technical Summary

    This memo specifies two transport mappings of the Real-time
    Application Quality of Service Monitoring (RAQMON) information model
    defined in [RAQMON-FRAMEWORK] using TCP as a native transport and the
    Simple Network Management Protocol (SNMP) to carry the RAQMON
    information from a RAQMON Data Source (RDS) to a RAQMON Report
    Collector (RRC).

Working Group Summary

  The RMONMIB Working Group has consensus to publish this document
  as a Proposed Standard.

Protocol Quality

  The RAQMON protocol is based on a a proprietary version of
  technology implemented and deployed in products by Avaya, Inc.
  This document has been reviewed by Andy Bierman, Alan Clark,
  and Randy Presuhn, and Steve Waldbusser.

----------------

idnits 1.85

tmp/draft-ietf-rmonmib-raqmon-pdu-12.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.

    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - It seems as if not all pages are separated by form feeds - found 0 form
    feeds but 38 pages

  Miscellaneous warnings:
    None.

    No nits found.

AD review of revision 11, as posted to WG list:

-----Original Message-----
From: rmonmib-bounces@ietf.org [mailto:rmonmib-bounces@ietf.org]On
Behalf Of Wijnen, Bert (Bert)
Sent: Tuesday, January 03, 2006 22:57
To: 'Siddiqui, Anwar A (Anwar)'; 'Romascanu, Dan (Dan)'; 'Golovinsky,
Eugene'; ybkim@broadcom.com; mahfuz@research.panasonic.com
Cc: RMON WG (E-mail)
Subject: [RMONMIB] AD review of draft-ietf-rmonmib-raqmon-pdu-11.txt


Thanks for the new revision.
Looks a lot better to me. Now I see much better consistency
within this document and also between this document and the
Framework document.

Of course it will also be good if other WG members take
another look at this (and the other 2 RAQMON) document(s)
as your WG chair Andy has asked.

Pls read the following and let me know if you agree that
probably one more rev makes sense?

In the MIB module I find these concerns:

- SMICng reports:
    E: f(raqmon-rds.mi2), (119,19) Index item "raqmonDsDSRC"
      must be defined with sntax that includes a range
  I had noted (in my handscribbles): "is zero a valid value?
  and if so what does it mean?". This SMICng warning asks
  implicitly the same I think.
    W: f(raqmon-rds.mi2), (110,7) Row "raqmonDsNotificationEntry"
      has indexing that may create variables with more than 128
      sub-ids
  That is OK, you have explained why it will never happen.
  But in we normally do then add something in the Conformance
  section, and in case of INDEX objects, we do so in DESCRITPION
  clause. So somthing like (updated your MODULE-COMPLIANCE; pls not
  I made it singular too):

    raqmonDsBasicCompliance MODULE-COMPLIANCE
        STATUS current
        DESCRIPTION
          "The compliance statement for SNMP entities which
            implement this MIB module.

            There are a number of INDEX objects that cannot be
            represented in the form of OBJECT clauses in SMIv2, but
            for which we have the following compliance requirements,
            expressed in OBJECT clause form in this description
            clause:

            -- OBJECT      raqmonDsPeerAddrType
            -- SYNTAX      InetAddressType { ipv4(1), ipv6(2) }
            -- DESCRIPTION
            --    This MIB requires support for only global IPv4
            --    and IPv6 address types.
            --
            -- OBJECT      raqmonDsPeerAddr
            -- SYNTAX      InetAddress (SIZE(4|16))
            -- DESCRIPTION
            --    This MIB requires support for only global IPv4
            --    and IPv6 address types.
            --
          "
        MODULE  -- this module
            MANDATORY-GROUPS { raqmonDsNotificationGroup,
                              raqmonDsPayloadGroup }
        ::= { raqmonDsCompliances 1 }

- I see a list of REVISION clauses. But I think we normally do
  just one REVISION clause aka (taking same dat as LAST-UPDATED)

    REVISION      "200512220000Z"    -- December 22, 2005
    DESCRIPTION  "First version, published as RFC yyyy"
    -- RFC editor, pls fill in yyyy

- I am still a bit concerned about the use of Counter32.
  Specifically since your DESCRIPTION says:
              "The number of packets transmitted within a communication
              session by the receiver from the begining of the sub-
              session until the time this RAQMON PDU was generated.
              "
  I.e. the "from the beginning... untill" sort of states that there
  can never be a wrap, and such is just not true for a Counter32.
  It seems to have semenatics of a ZeroBasedCounter32, does it not?

- I see
      -- It is RECOMMENDED to keep the size of a notification within
      -- the MTU size limits in order to avoid fragmentation
      --
  And I would suggest to move that text into the DESCRIPTION clause
  of each NOTIFICATION-TYPE so that MIB extraction tools keep it
  included.

- In the CONFORMANCE part I see:

      --
      -- conformance information
      -- These don't show up on the wire, so they only need to be
      -- unique

  That comment seems a bit weird to me. But I can live with it.
  Not sure what you mean to convey with "so theu only need to be unique"


Nits (if you do an update anyway, then pls consider these):

- I still wonder a bit about text on page 9:
    ........                                              The text MUST
    NOT be longer than 255 octets.  The text is encoded according to the
    UTF-2 encoding specified in Annex F of ISO standard 10646
    [ISO10646],[UNICODE]. This encoding is also known as UTF-8 or UTF-
    FSS. 

  Would it not be better to just speak of UTF-8 and cite/reference RFC3629?

- I think I would move section 8 "Appendix" to later in the doc, i.e.
  make it a real appendix (and non-normative.

  In the code of sect 8, I think you want to change
  OLD:
          } RRC:
          listen on raqmon port
  NEW:
          }

    RRC:
          listen on raqmon port


- In the Security COnsiderations section I see:
    This memo also defines an RDS SNMP MIB module with the purpose of
    mapping the RAQMON PDUs into SNMP Notifications.  To attain end-to-
    end security the following measures have been taken in RDS MIB module
    design:
  I think I would be more precise and
  s/an RDS SNMP MIB/the RAQMON-RDS-MIB/
  s/in RDS MIB/in RAQMON-RDS-MIB/

- Section 6 is (still, in my view) redundant with the back matter of the
  document, and I propose to remove section 6.

- In IANA Considerations Section.

  - make a statement about the MIB OID assignment (as per RFC3737), so that
    they have one central place to look for the work they need to do.

  - So has a port for 7xxx been requested already? Or are you requesting it
    per this IANA Considerations section? Not 100% (at least not to me).

Then an admin topic, references and citations.

- Those documents from which you IMPORT must be listed as normative
  references. And they need citations. A good way to do ciatations is
  to do a para just prior to the MIB module itself that says something
  aka:

    The following MIB module IMPORTS definitions from the folling:
      DIFFSERV-DSCP-TC [RFC3289]
      SNMP-FRAMEWORK-MIB [RFC3411]
      INET-ADDRESS-MIB [RFC4001]
      ...
    It also uses REFERENCE clauses to refer to [RAQMON-FRAMEWORK].
   
  Or some such.

- I believe you have RFC3550 listed twice in your references.

- I believe you still have RFC3291 listed in your references, which has been
  obsoleted by 4001, which you also do have in your references.

- Reference/Citation checking reports:
    !! Contains embedded space:
    P033 L028:                [ANSI/IEEE Std 802.1D, 1998 Edition]

    !! Contains embedded space:
    P033 L028:                [ANSI/IEEE Std 802.1D, 1998 Edition]

    !! Contains embedded space:
    P010 L018:    seconds [RFC 1305]. The full resolution NTP timestamp is a 64-bit

    !! Contains embedded space:
    P015 L052:          User-Based Security Model (USM) defined by [RFC 3414].

  Those then also cause (since they do not have an embedded blank):
    !! Missing citation for Informative reference:
    P033 L024:    [IEEE802.1D] Information technology-Telecommunications and

    !! Missing citation for Informative reference:
    P032 L031:    [RFC1305]  Mills, D., "Network Time Protocol Version 3", RFC 1305,

    !! Missing citation for Informative reference:
    P033 L048:    [RFC3414]  Blumenthal U., and B. Wijnen, "User-based Security Model

  Since this is the case for many of your citations, I find it difficult (or better time
  consuming) to do a complete check. Pls check this list of listed issues (some may be
  false warnings):

*** matchref -- match citations and references.
    Input file: draft-ietf-rmonmib-raqmon-pdu-11.txt

!! Contains embedded space:
  P033 L028:                [ANSI/IEEE Std 802.1D, 1998 Edition]

!! Contains embedded space:
  P033 L028:                [ANSI/IEEE Std 802.1D, 1998 Edition]

!! Contains embedded space:
  P010 L018:    seconds [RFC 1305]. The full resolution NTP timestamp is a 64-bit

!! Contains embedded space:
  P015 L052:          User-Based Security Model (USM) defined by [RFC 3414].

!! Bad reference -- !MISSING.[
  P009 L018:    FRAMEWORK].  IP version 6 addresses are incorporated in Data Source

!! Bad reference -- !MISSING.[
  P009 L030:    FRAMEWORK].  The Data Source Name field starts with an 8-bit octet

!! Bad reference -- !MISSING.[
  P012 L028:    FRAMEWORK] is a 8-bit field associated to source's IEEE 802.1D

!! Bad reference -- !MISSING.[
  P012 L035:    FRAMEWORK] is a 8-bit field which represents the layer 3 QoS marking

!! Bad reference -- !MISSING.[
  P012 L040:    FRAMEWORK] is a 8-bit field which represents layer 2 IEEE 802.1D

!! Bad reference -- !MISSING.[
  P012 L048:    FRAMEWORK] is a 8-bit field which represents the layer 3 QoS marking

!! Bad reference -- !MISSING.[
  P014 L048:    after IANA allocates the number, and this note will be removed]

!! Bad reference -- !MISSING.]
  P009 L017:    representation - This parameter is defined in section 5.1 of [RAQMON-

!! Bad reference -- !MISSING.]
  P009 L029:    Data Source Name (DN): - defined in section 5.3 of [RAQMON-

!! Bad reference -- !MISSING.]
  P012 L027:    S_Layer2: 8 bits - This parameter defined in section 5.26 of [RAQMON-

!! Bad reference -- !MISSING.]
  P012 L034:    S_Layer3: 8 bits - This parameter defined in section 5.27 of [RAQMON-

!! Bad reference -- !MISSING.]
  P012 L039:    D_Layer2: 8 bits - This parameter defined in section 5.28 of [RAQMON-

!! Bad reference -- !MISSING.]
  P012 L047:    D_Layer3: 8 bits - This parameter defined in section 5.29 of [RAQMON-

!! Bad reference -- !MISSING.]
  P014 L047:    [editor note - 7XXX will be completely specified at RFC release,


Informative reference:
  P034 L010:    [3DES]    American National Standards Institute, ANSI X9.52-1998,
Citations to it:
  P036 L023:      Encryption Standard), 3-DES [3DES], and AES (Advanced Encryption

Informative reference:
  P034 L014:    [AES]    Federal Information Processing Standard (FIPS),
Citations to it:
  P036 L024:      Standard) [AES].

!! Missing citation for Informative reference:
  P033 L024:    [IEEE802.1D] Information technology-Telecommunications and

Informative reference:
  P033 L016:    [ISO10646]  International Standards Organization, "ISO/IEC DIS
Citations to it:
  P009 L036:    [ISO10646],[UNICODE]. This encoding is also known as UTF-8 or UTF-

!! Missing Reference for citation: [RAQMON-FRAMEWOK]
  P016 L019:    [RAQMON-FRAMEWOK] as well as the Notifications themselves.  In order
  P016 L021:    (APP) part of RAQMON PDU as defined in [RAQMON-FRAMEWOK], additional

!! Duplicate reference:
  P035 L054:    [RAQMON-FRAMEWORK] outlines a threat model associated with RAQMON and
  P032 L018:    [RAQMON-FRAMEWORK] Siddiqui, A., Romascanu, D. and E. Golovinsky,

Informative reference:
  P035 L054:    [RAQMON-FRAMEWORK] outlines a threat model associated with RAQMON and
Citations to it:
  P001 L050:    defined in [RAQMON-FRAMEWORK] using TCP as a native transport and the
  P003 L013:    outlined by [RAQMON-FRAMEWORK] extends the Remote Monitoring family
  P003 L016:    application monitoring in real time.  [RAQMON-FRAMEWORK] defines the
  P004 L012:    [RAQMON-FRAMEWORK]. Both functional parts trail a field carrying a
  P004 L020:    defined in section 5 of [RAQMON-FRAMEWORK].
  P009 L023:    in section 5.2 of [RAQMON-FRAMEWORK]. Follows exact same syntax as
  P009 L043:    [RAQMON-FRAMEWORK].  Like Data Source Name, the Receiver Name field
  P009 L054:    section 5.5 of [RAQMON-FRAMEWORK]and describes the port Number used
  P010 L011:    section 5.6 of [RAQMON-FRAMEWORK], and describes the receiver port
  P010 L016:    defined in section 5.7 of [RAQMON-FRAMEWORK] represented using the
  P010 L030:    metric is defined in section 5.8 of [RAQMON-FRAMEWORK] and expressed
  P010 L034:    is defined in section 5.9 of [RAQMON-FRAMEWORK]. Session Duration is
  P010 L038:    defined in section 5.10 of [RAQMON-FRAMEWORK]. This field starts with
  P010 L043:    End Network Delay is defined in section 5.11 of [RAQMON-FRAMEWORK].
  P010 L048:    Network Delay is defined in section 5.12 of [RAQMON-FRAMEWORK]. This
  P010 L053:    section 5.13 of [RAQMON-FRAMEWORK] and is represented as an unsigned
  P010 L057:    in section 5.14 of [RAQMON-FRAMEWORK] and is represented as an
  P011 L013:    defined in section 5.15 of [RAQMON-FRAMEWORK] and is represented as
  P011 L017:    parameter is defined in section 5.16 of [RAQMON-FRAMEWORK] and is
  P011 L022:    defined in section 5.17 of [RAQMON-FRAMEWORK] as an unsigned integer,
  P011 L027:    is defined in section 5.18 of [RAQMON-FRAMEWORK] as an unsigned
  P011 L033:    defined in section 5.19 of [RAQMON-FRAMEWORK] as an unsigned integer,
  P011 L039:    defined in section 5.20 of [RAQMON-FRAMEWORK] as an unsigned integer,
  P011 L044:    section 5.21 of [RAQMON-FRAMEWORK] expressed as a fixed-point number,
  P011 L054:    in section 5.22 of [RAQMON-FRAMEWORK] as an unsigned integer
  P012 L011:    section 5.23 of [RAQMON-FRAMEWORK] expressed as a fixed point number
  P012 L018:    5.24 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the
  P012 L023:    5.25 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the
  P012 L053:    [RAQMON-FRAMEWORK] represents the percentage of CPU used during
  P013 L014:    of [RAQMON-FRAMEWORK] represents the percentage of total memory used
  P013 L023:    [RAQMON-FRAMEWORK].  The Application Name field starts with an 8-bit
  P018 L046:                Section 3.5. According to [RAQMON-FRAMEWORK], Section
  P020 L034:              "Section 5.2 of [RAQMON-FRAMEWORK]"
  P020 L045:              "Section 5.2 of [RAQMON-FRAMEWORK]"
  P020 L057:              "Section 5.28 of [RAQMON-FRAMEWORK]"
  P021 L020:              "Section 5.5 of [RAQMON-FRAMEWORK]"
  P021 L031:              "Section 5.6 of [RAQMON-FRAMEWORK]"
  P021 L041:            "Section 5.7 of [RAQMON-FRAMEWORK]"
  P021 L052:              "Section 5.8 of [RAQMON-FRAMEWORK]"
  P022 L017:              "Section 5.9 of [RAQMON-FRAMEWORK]"
  P022 L029:              "Section 5.10 of [RAQMON-FRAMEWORK]"
  P022 L041:              "Section 5.11 of [RAQMON-FRAMEWORK]"
  P022 L053:              "Section 5.12 of [RAQMON-FRAMEWORK]"
  P023 L017:              "Section 5.13 of [RAQMON-FRAMEWORK]"
  P023 L028:              "Section 5.14 of [RAQMON-FRAMEWORK]"
  P023 L039:              "Section 5.15 of [RAQMON-FRAMEWORK]"
  P023 L053:              "Section 5.16 of [RAQMON-FRAMEWORK]"
  P024 L019:              "Section 5.17 of [RAQMON-FRAMEWORK]"
  P024 L035:              "Section 5.18 of [RAQMON-FRAMEWORK]"
  P024 L050:              "Section 5.19 of [RAQMON-FRAMEWORK]"
  P025 L015:                "Section 5.20 of [RAQMON-FRAMEWORK]"
  P025 L029:            "Section 5.21 of [RAQMON-FRAMEWORK]"
  P025 L041:                "Section 5.22 of [RAQMON-FRAMEWORK]"
  P025 L054:            "Section 5.23 of [RAQMON-FRAMEWORK]"
  P026 L016:            "RFC 1890, Section 5.24 of [RAQMON-FRAMEWORK] "
  P026 L026:              "RFC 1890, Section 5.25 of [RAQMON-FRAMEWORK] "
  P026 L039:              "Section 5.26 of [RAQMON-FRAMEWORK]"
  P026 L050:              "Section 5.27 of [RAQMON-FRAMEWORK]"
  P027 L015:              "Section 5.28 of [RAQMON-FRAMEWORK]"
  P027 L027:              "Section 5.29 of [RAQMON-FRAMEWORK]"
  P027 L039:              "Section 5.30 of [RAQMON-FRAMEWORK]"
  P027 L051:              "Section 5.31 of [RAQMON-FRAMEWORK]"
  P031 L020:    section 3.0 of [RAQMON-FRAMEWORK] guidelines that outlines measures
  P031 L022:    Congestion safety requirements in section 3.0 of [RAQMON-FRAMEWORK]

!! Missing citation for Informative reference:
  P032 L034:    [RFC1034]  Mockapetris, P., "Domain Names - Concepts and

!! Missing citation for Informative reference:
  P032 L037:    [RFC1035]  Mockapetris, P., "Domain Names - Implementation and

!! Missing citation for Informative reference:
  P032 L040:    [RFC1123] Braden, R., "Requirements for Internet Hosts - Application

!! Missing citation for Informative reference:
  P032 L031:    [RFC1305]  Mills, D., "Network Time Protocol Version 3", RFC 1305,

!! Missing citation for Informative reference:
  P032 L025:    [RFC1321]  Rivest, R., "Message Digest Algorithm MD5", RFC 1321,

!! Missing citation for Informative reference:
  P033 L030:    [RFC1349] P. Almquist, "Type of Service in the Internet Protocol

!! Missing citation for Informative reference:
  P032 L043:    [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de

!! Missing citation for Informative reference:
  P033 L033:    [RFC1812] F. Baker, "Requirements for IP Version 4 Routers" RFC1812,

Normative reference:
  P031 L034:    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
Citations to it:
  P003 L027:    document are to be interpreted as described in [RFC2119].

!! Missing citation for Informative reference:
  P033 L036:    [RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition

Normative reference:
  P031 L037:    [RFC2578]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Citations to it:
  P016 L035:    RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC

Normative reference:
  P031 L042:    [RFC2579]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Citations to it:
  P016 L035:    RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC

Normative reference:
  P031 L046:    [RFC2580]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Citations to it:
  P016 L036:    2580[RFC2580].

!! Missing citation for Informative reference:
  P032 L047:    [RFC2679] G. Almes, S.Kalidindi and M.Zekauskas, "A One-way Delay

!! Missing citation for Informative reference:
  P032 L050:    [RFC2680] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Packet

!! Missing citation for Informative reference:
  P032 L053:    [RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay

!! Missing citation for Normative reference:
  P031 L050:    [RFC2819]  Waldbusser, S., "Remote Network Monitoring Management

!! Missing citation for Normative reference:
  P031 L053:    [RFC3289]  Baker, F., Chan, K. and A. Smith, "Management Information

!! Missing citation for Informative reference:
  P033 L040:    [RFC3291]  Daniele, M., Haberman, B., Routhier, S., and J.

Informative reference:
  P033 L044:    [RFC3410]  Case, J., Mundy, R., Partain, D. and B. Stewart,
Citations to it:
  P016 L027:    RFC 3410 [RFC3410].
  P037 L030:    provided by the SNMPv3 framework (see [RFC3410], section 8),

!! Missing citation for Normative reference:
  P031 L057:    [RFC3411]  Harrington, D., Preshun, R. and B. Wijnen, "An

!! Missing citation for Informative reference:
  P033 L048:    [RFC3414]  Blumenthal U., and B. Wijnen, "User-based Security Model

!! Duplicate reference:
  P032 L028:    [RFC3550]  H. Schulzrinne, "RTP Profile for Audio and Video
  P032 L056:    [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.

Informative reference:
  P032 L028:    [RFC3550]  H. Schulzrinne, "RTP Profile for Audio and Video
Citations to it:
  P007 L030:    the one defined in Appendix A.6 in [RFC3550] to create a DSRC.

Informative reference:
  P033 L012:    [RFC3551]    Schulzrinne, H. and S. Casner, "RTP Profile for Audio
Citations to it:
  P012 L020:    as defined in [RFC3551].
  P012 L025:    defined in [RFC3551].

Informative reference:
  P033 L052:    [RFC3737]  Wijnen B., and A.Bierman "IANA Guidelines for the
Citations to it:
  P018 L028:    -- This OID allocation conforms to [RFC3737]

!! Missing citation for Normative reference:
  P032 L014:    [RFC4001]  Daniele, M., Haberman, B., Routhier, S. And J.

Normative reference:
  P031 L028:    [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
Citations to it:
  P014 L030:    [RFC791]. Unless otherwise noted, numeric constants are in decimal

!! Missing citation for Normative reference:
  P031 L031:    [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,

Informative reference:
  P033 L021:    [UNICODE]  The Unicode Consortium, The Unicode Standard New York,
Citations to it:
  P009 L036:    [ISO10646],[UNICODE]. This encoding is also known as UTF-8 or UTF-

Bert

_______________________________________________
RMONMIB mailing list
RMONMIB@ietf.org
https://www1.ietf.org/mailman/listinfo/rmonmib

State Change Notice email list have been change to ietf@andybierman.com, ; anwars@avaya.com; dromasca@avaya.com; eugene_golovinsky@bmc.com; mahfuz@research.panasonic.com; ybkim@broadcom.com from ietf@andybierman.com>, ; anwars@avaya.com; dromasca@avaya.com; eugene_golovinsky@bmc.com; mahfuz@research.panasonic.com; ybkim@broadcom.com

AD review summary posted to mailing list, editing session
with authors/editors at IETF64. See below.

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Thursday, November 10, 2005 22:53
To: 'Romascanu, Dan (Dan)'; 'Siddiqui, Anwar A (Anwar)';
'Eugene_Golovinsky@bmc.com'; 'ietf@andybierman.com'
Cc: RMON WG (E-mail)
Subject: RE: RAQMON I-Ds Status


For the WG:

As a follow up, the authors/editors and I spend approx 2 hours during
IETF 64 going over my handscribbled comments/notes. They took a copy
of those and will do a revision based on that. So for now I have put
the documents in "Revised ID needed" in the I-D tracker.

Bert

> -----Original Message-----
> From: Wijnen, Bert (Bert)
> Sent: Sunday, November 06, 2005 17:33
> To: 'Romascanu, Dan (Dan)'; 'Siddiqui, Anwar A (Anwar)';
> 'Eugene_Golovinsky@bmc.com'; 'ietf@andybierman.com'
> Cc: RMON WG (E-mail)
> Subject: RE: RAQMON I-Ds Status
>
>
> On my plane-ride from NL to Vancouver I did review all 3
> RAQMON documents. I have hoped that I would have just
> minor comments and that I could request IETF Last Call.
>
> However, I have found a lot of things that I want clarified
> - inconsistencies between the 3 documents
> - questions about "how one can implement from the specs and
>  assume to be interoperable"
>
> So I wonder... who in the rmonmib WG has actually seriously
> reviewed those documents? I must admit that I did not read
> the I-Ds in detail for a long time. But fro my AD-review I
> did, and I now really wonder. I'll try to speak with the
> authors during this IETF week, and then I hope to find
> time to type-up my comments/concerns at the end of IETF64.
>
> Futher I have lots of nitpicking that could be fixed.
> Since I suspect that we may need new revisions because of the
> above 2 major points, the nist may get fixed as well.
>
> Bert

State Change Notice email list have been change to ietf@andybierman.com>, ; anwars@avaya.com; dromasca@avaya.com; eugene_golovinsky@bmc.com; mahfuz@research.panasonic.com; ybkim@broadcom.com from , ; anwars@avaya.com; dromasca@avaya.com; eugene_golovinsky@bmc.com; mahfuz@research.panasonic.com; ybkim@broadcom.com