[netconf] comments on draft-ietf-netconf-udp-notif-01

[Andy Bierman <[e-mail]>]

Hi,

I have some comments and questions about this draft.

sec 3.1:



*      [I-D.ietf-netconf-notification-messages] describes the structure
  of the Notification Message for single notifications and bundled
notifications.*

 - The new notification header is very complex, not implemented by anybody,
   and therefore unproven. The RFC 5277 notification message is widely
deployed
   and should be supported.


sec 3.2





* *  S represents the space of encoding type specified in the ET field.
  When S is unset, ET represents the standard encoding types as
defined in this document.  When S is set, ET represents a private
space to be freely used for non standard encodings.*
 - This new "S bit" payload encoding is not interoperable
    A) different vendors can pick whatever values they want for the ET field
    B) There is no reliable way to identify the vendor (or publisher
software details)
    in this protocol



*   *  Observation-Domain-ID is a 32-bit identifier of the Observation
Domain that led to the production of the notification message, as
defined in [I-D.ietf-netconf-notification-messages]. *

 - Why is this field needed if it is already in the new notification
message?




*  *  The Message ID is generated continuously by the sender of UDP-
Notif messages.  Different subscribers share the same Message ID
sequence.*
 - It is not clear why the Message-ID field is present.  This seems to be
all
   the text about it.  The field is OK, but needs clarification

   A) What is the receiver supposed to do to validate a Message-ID?
      This implies that some state is maintained by the receiver
   B) Does this field increment by 1 for every message? Or increment by 1
      for every message from the same Observation-Domain-ID?
   C) How is this field used if the Segmentation Option is used?
      Suggest: all multi-PDU messages MUST have the same Message-ID in each
PDU.
   D) The 2nd sentence is confusing (subscribers?) Maybe you mean that
different
      subscriptions supported by the same Observation-Domain-ID share
      the same Message-ID

sec 3.3.1:





*   An implementation of this specification MUST NOT rely on IP
 fragmentation by default to carry large messages.  An implementation   of
this specification MUST either restrict the size of individual   messages
carried over this protocol, or support the segmentation   option.*

 - This appears to be the only normative text about the application-level
fragmentation
   and reassembly procedures.
   A) Is the sender required to finish a multi-PDU message (i.e. send
      segment 0 through N, in order) before sending a different Message-ID?
   B) Is it legal to use the option if only 1 segment is sent (i.e., L bit
      set for Segment 0)
   C) Is it illegal to send any more segments for the same Message-ID after
      the L bit has been sent?


Andy