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

Hi,

Thanks for addressing my comments.  See inline:

Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> Hi Martin,
> 
> > On Feb 23, 2021, at 12:59 AM, Martin Björklund <mbj+ietf@4668.se> wrote:
> > 
> > Hi,
> > 
> > I have read this version, and most of my comments for -07 are
> > addressed.  However, I still have some comments:

[...]

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

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

/martin

> 
> > 
> > 
> > 
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> Mahesh & Kent (as co-authors)
> 
> 
> 
> 
> 