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

[Andy Bierman <[e-mail]>]

On Tue, Nov 10, 2020 at 4:05 AM Pierre Francois <
[e-mail]> wrote:

> Andy,
>
> Thank you for the thorough review.
> I agree with everything, mostly. I'll cover your questions during the
> meeting.
>
>
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



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