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

[Mahesh Jethanandani <[e-mail]>]

[Trimming it down to open issues]

Hi Martin,

> 
>>> o  3.3.
>>> 
>>>    leaf-list receiver-capability {
>>>      type "inet:uri";
>>>      description
>>>        "A capability supported by the receiver.  A full list of
>>>         capabilities is defined in the 'Capabilities for HTTPS
>>>         Notification Receivers' registry (see RFC XXXX).";
>>>    }
>>>  }
>>> 
>>>  As it is possible that the receiver may return custom capability
>>>  URIs, the publisher MUST ignore any capabilities that it does not
>>>  recognize.
>>> 
>>> 
>>> This seems contradictory - how can the server return custom
>>> capabilities if there is a full list of capabilities available in an
>>> IANA registry?
>>> 
>>> 
>> 
>> Here is the updated text for the description statement:
>> 
>>    description
>>      "A capability supported by the receiver.  A partial list of
>>       capabilities is defined in the 'Capabilities for HTTPS
>>       Notification Receivers' registry (see RFC XXXX). Additional
>>       custom capabilities MAY be defined.”;
> 
> Ok, but is it correct to say that the IANA registry is a "partial
> list"?  I would say just "list" or perhaps "standard list".

How about this?

description
     "A capability supported by the receiver.  A list of standard
      capabilities is defined in the 'Capabilities for HTTPS
      Notification Receivers' registry (see RFC XXXX). Additional
      custom capabilities MAY be defined.”;

> 
>>> o  3 and 8.3
>>> 
>>> There's a new capability defined:
>>> 
>>>  Name:        urn:ietf:capability:https-notif-receiver:encoding:rfc8639-enabled
>>>  Reference:   RFC XXXX
>>>  Description: Identifies support for RFC 8639 state machine.
>>> 
>>> This is the only description of this capability in this document.
>>> How is it supposed to work?  What should a publisher do with this
>>> information?  Which state machine is referred to?
>>> 
>>> (And, the name of the capability should be more descriptive, and not
>>> contain the RFC number.  What if there's a bis version published with
>>> some errors fixed?)
>> 
>> How about this for an updated name and description?
>> 
>> Record:
>>   Name:        urn:ietf:capability:https-notif-receiver:encoding:sub-notif
>>   Reference:   RFC XXXX
>>   Description: Identifies support for state machine described in RFC 8639,
>>                enabling the publisher to send, e.g., the
>>                "subscription-started" notification.
> 
> 
> I'm sorry but I still don't understand.  What is the purpose of this
> capability?  Does it mean that if the reciever advertises this
> capability then the publisher MUST send e.g. "subscription-started"?
> This seems a bit odd; if this protocol is used as a configured
> subscription, then the publisher will send "subscription-started"
> regardless of any receiver capabilities, right?

That is correct. This capability advertised by the receiver says that it support RFC 8639 based state machine. Only if the receiver advertises this capability  a “subscription-started” has to be sent before sending a notification. See Section 2, Overview of Publisher to Receiver Interaction. You will notice that in the figure, there is no requirement (by default) that a “subscription-started” has to be sent. 

HTH.

Mahesh & Kent (as co-authors)