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

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Nov 2020 09:16:49 -0800

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 9 Nov 2020 18:14:14 -0800

+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 <[email-masked]> wrote:
> 
> Hi,
> 
>       [I-D.ietf-netconf-notification-messages] describes the structure
>       notifications.
>    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.
>       space to be freely used for non standard encodings.

>     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
>       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-
>       sequence.
>  - It is not clear why the Message-ID field is present.  This seems to be all
>       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
>    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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]

---

From: Pierre Francois <[email-masked]>
Date: Tue, 10 Nov 2020 13:05:30 +0100

Andy,

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

Cheers,

Pierre.

---

From: Pierre Francois <[email-masked]>
Date: Tue, 10 Nov 2020 13:08:58 +0100

Mahesh,

Le mar. 10 nov. 2020 à 03:14, Mahesh Jethanandani <[email-masked]>
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.

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

> 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?

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Nov 2020 11:55:30 -0800

> I agree with everything, mostly. I'll cover your questions during the
thanks.

It appears that both Observation-Domain-ID and Message-ID are needed in the
header,
if Message-ID is only unique within a specific domain.

Andy