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

[Pierre Francois <[e-mail]>]

Andy,

Thank you for the thorough review.
I agree with everything, mostly. I'll cover your questions during the
meeting.

Cheers,

Pierre.




Le lun. 9 nov. 2020 à 18:17, Andy Bierman <[e-mail]> a écrit :

> 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
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>