FW: IESG feedback on draft-ietf-ipo-framework

Fyi

-----Original Message-----
From: Alex Zinin [mailto:[email protected]] 
Sent: Thursday, May 08, 2003 1:00 PM
To: Daniel O . Awduche
Cc: Wijnen, Bert (Bert)
Subject: IESG feedback on draft-ietf-ipo-framework


Daniel-

  The IESG considered the document at the telechat last week and
  tentatively approved it subject to addressing of the concerns
  below (these are the last set of comments from the IESG, sorry
  we had to come back to you more than once, normally we try to
  bring all comments together first time.)

  I will put these into the ID tracker, so the comments are
  publicly visible. Also, feel free to forward this to the WG.

  Hopefully we can have the next (and last) rev out soon and
  will push it to the rfc-ed.

  Cheers.

Alex

Administrative:

   We should check with ITU and T1X1 folk if they are fine with this
   document, since there is L1 stuff in it. Please follow up with
   Steve Trowbridge and Deborah Brungard([email protected]).

Security:

   Section 9.1 says:

         1. Replay protection, which detects and rejects attempts to
            reorder, duplicate, truncate, or otherwise tamper with the
            proper sequence of messages, and

   This is not quite right.  Replay mechanisms do not provide
   connection-oriented data integrity.  Replay mechanisms allow reorder
within
   a window, and truncation protection is not provided.

   Section 9.1 also says:

         2. Non-repudiation, which may be desirable for accounting and
            billing purposes.

   Non-repudiation is an application layer security service.  I am
   surprised to see it in this document.

Routing (section 5.2.2.1)

   Please add some text considering the following potential negative
   effects:
   
    o amount of information that optical nodes will have to maintain
      will not be bound by the size of the optical network anymore,
      but will have to include external routes too

    o stability of the optical network's control plane system will
      not be solely driven by the dynamics within the optical network
      itself, but also by the dynamics within the external routing
      domains where external reachability information is received
      from.
   
Restoration part:

   the following text is terse:

      With out-of-band control, it is necessary to consider
      fast signaling over the control channel using very short IP
packets
      and prioritized processing. While it is possible to use RSVP or
CR-
      LDP for activating protection paths, these protocols do not
provide
      any means to give priority to restoration signaling as opposed to
      signaling for provisioning. For instance, it is possible for a
      restoration-related RSVP message to be queued behind a number of
      provisioning messages thereby delaying restoration. It is
therefore
      necessary to develop a definition of QoS for restoration signaling
      and incorporate mechanisms in existing signaling protocols to
      achieve this. Or, a new signaling protocol may be developed
      exclusively for activating protection paths during restoration.

   The last two sentences are a very brief reference to what would be a
   significant piece of work that needs more justification and a sharper
   (not detailed, but more specific, multi-sentence) characterization.
   Would the QoS term be a reference to be a new priority service for
   RSVP-TE?  Where/how would this work be developed?  It would do
   better service to the framework to briefly describe where the fast
   restoration directions have gone (and explain their rationale a
   bit), and what would be the characteristics of the new signalling
   protocol that might be needed.


ID-NITs:
-: 1 lines containing non-US-ASCII characters
-: 42 lines longer than 72 characters, max 369

Figure 1 is messed up.  For example, one of the lines is 370 characters
long.