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

Mahesh,

Le mar. 10 nov. 2020 à 03:14, Mahesh Jethanandani <mjethanandani@gmail.com>
a écrit :

> +1 most of these comments.
>

Same :)

> Also please fix all the indentation and max length of 72 in the YANG model.
>

Done. Will be included in the -02.

>
> On Nov 9, 2020, at 9:16 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
> 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
>
>
> Would suggest that the version field start with a value which is non-zero.
> A zero does not indicate if the value was set or the field was
> uninitialized. Same for ET field.
>

ok.

>
>
>
>
>
> * *  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
>
>
> +1
>
> Is there a method by which the other end will learn the encoding that is
> going to be sent or does the publisher just start sending a given encoding
> whether the other end supports or not? Would suggest that you pick a
> default encoding that both ends have to support, and then come up with a
> method by which the other encodings can be learnt.
>

I think this requires a discussion. During the meeting ok?

>
>
>
>
> *   *  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
>
>
> Section 7
>
> The draft requests a port assignment for UDP notification. Not sure that
> it is needed. The YANG model already defines a way to configure a port, and
> it is mandatory.
>

Agreed.

Thank you,

Pierre.

>
> Thanks.
>
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>