Re: Tsvart last call review of draft-ietf-netconf-restconf-notif-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Wesley,

Thank you for the review, please see inline.


On 2019-04-02, 12:43 PM, "Wesley Eddy via Datatracker" <noreply@xxxxxxxx> wrote:

    Reviewer: Wesley Eddy
    Review result: Ready with Issues
    
    This document has been reviewed as part of the transport area review team's
    ongoing effort to review key IETF documents. These comments were written
    primarily for the transport area directors, but are copied to the document's
    authors and WG to allow them to address any issues raised and also to the IETF
    discussion list for information.
    
    When done at the time of IETF Last Call, the authors should consider this
    review as part of the last-call comments they receive. Please always CC
    tsv-art@xxxxxxxx if you reply to or forward this review.
    
    I reviewed this in conjunction with the set of related WG documents on
    NETCONF/RESTCONF subscriptions and event notifications.   I have comments that
    will be sent on other documents in the set, some of which may influence this
    once, since they are closely related.
    
    Figure 3 shows a DSCP value of 10, but it isn't clear what the number base is
    supposed to be, and this should be specified for this protocol, since many
    examples can be found in other material of DSCP values indicated in binary,
    decimal, or hexadecimal.
The leaf "dscp" is from https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-23#page-45, and inet:dscp is a uint8 range "0..63". The example in Figure 3 uses JSON encoding, we're following rules from https://tools.ietf.org/html/rfc7951#page-11 so this means that 10 is decimal.
    
    In section 4, the first bullet discusses taking a "priority" and copying it
    into a "weighting" field.  Since priority and weight can be different, though
    are closely related, this seems a bit confusing.  I think the intention here
    for HTTP2 effects that are trying to be achieved should be discussed more so
    that it is clear to implementers and users what more specific effects this
    should have.
As mentioned in the 2nd paragraph, that text is specific to http2. So the intention here is to explain how the weighting/dependency nodes (from subscribed-notifications) are used for http2. If I understood your comment properly, you find bullet 1 confusing since it mentions priority and weight in the same vein? Would this be better:
take the "weighting" leaf node in  [I-D.draft-ietf-netconf-subscribed-notifications], and copy it into the HTTP2 stream weight, [RFC7540] section 5.3,...

Regards,
Reshad. 
    
    





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux