Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.txt

[Kent Watsen <[e-mail]>]

Hi Eric,

> (1) For ietf-https-notif.yang why did you choose "uses x509c2n:cert-to-name" rather than linking to ietf-truststore.yang's
>      grouping truststore-grouping
>        +-- certificate-bags! {certificates}?
>           +-- certificate-bag* [name]
>              +-- name?          string
>              +-- certificate* [name]
>                 +-- name?                            string

I’m unclear about the issue.  Cert-to-name performs a mapping that doesn't exist anywhere else...


> (2) Do you plan any functionality which inter-related with the receiver action 'reset' from SN?  Right now this SN action resets the subscription.  Whether this actually does anything to any underlying connection is undefined in SN.  So I think what you have is fine as you define no actions on receiver-instances.  But I figured I would ask: is there anything connection related which you might expose for the receiver as a whole?

No SN-relation is planned. I’m unsure exactly what the ask is.  Please advise.

 
> (3) I have a question on receiver capability discovery prior to sending notifications.  Section 2.1 says that a publisher 'can' issue an HTTP GET for the capabilities.  This also suggests that it can choose not to send such a request.  What is the required behavior for an HTTPS publisher and receiver when the targeted receiver doesn't support the expected capabilities?

IIRC, the encoding MAY be configured in the SN model.  If it is not *and* the publisher doesn’t probe the receiver’s capabilities, and thus blindly sends whatever it wants, it risks the receiver returning an HTTP 4xx error.  Makes sense?


>  (4) Extending the question (3), the  <subscription-started> notification from SN can be used for this functionality.   Looking at the example you have in pipelining Section 1.5.1, the second POST of a YANG notification occurs is shown before the "Send 204 (No Content) is returned" for the first notification.   Could you explicitly add the <subscription-started> notification to section 1.5.1 to disambiguate things?  For example:   
>  
>        -------------                               --------------
>        | Publisher |                               | Receiver   |
>        -------------                               --------------
>  
>        Establish TCP             ------>
>  
>        Establish TLS             ------>
>  
>        Send HTTPS POST message
>        with <subscription-       ------>
>        started> notification 
>                                                    Send 200 (OK)
>                                  <------           for <subscription-started>
>  
>  
>        Send HTTPS POST message
>        with YANG defined         ------>
>        notification #1
>  
>        Send HTTPS POST message
>        with YANG defined         ------>
>        notification #2
>                                                    Send 204 (No Content)
>                                  <------           for notification #1
>  
>                                                    Send 204 (No Content)
>                                  <------           for notification #2

I think that this is proper.  Guidance welcomed.  But not that, beyond HTTP [N}ACKs, this is a one-way flow of content, so whatever needs to fit into those HTTP responses.

Kent // as co-author



> There were some earlier discussions on these overall interactions in threads like:
> https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1LLqyvuivuRcA/ <https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1LLqyvuivuRcA/>
>  
> Thanks,
> Eric