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

[Mahesh Jethanandani <[e-mail]>]

+1 most of these comments. Also please fix all the indentation and max length of 72 in the YANG model.

> On Nov 9, 2020, at 9:16 AM, Andy Bierman <[e-mail]> 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.

> 
>    *  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.

> 
>    *  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.

Thanks.

> 
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[e-mail]