[netconf] Re: [IANA #1353870] expert review for draft-ietf-netconf-http-client-server (xml-registry)

[Tim Bray <[e-mail]>]

On Aug 20, 2024 at 10:20:50 AM, Amanda Baber via RT <
[e-mail]> wrote:

> Hi Tim,
>
> This is on Thursday's telechat agenda. Can you let us know before then
> whether we should ask an AD to hold DISCUSS?
>

My comments are on the record.  I suspect not, it’s just slight awkwardness
in the description, very XML-specific. But not my call to make.


> thanks,
> Amanda
>
> On Fri Aug 16 16:19:51 2024, [e-mail] wrote:
>
> [moving Amanda and Martin to BCC]
>
>
> Hi Tim,
>
>
> >> Whether IETF should publish YANG modules enabling the configuration
>
> >> of unsecure protocols has been discussed before.  I don’t know if a
>
> >> definitive resolution came out of it, but my understanding is that
>
> >> IETF YANG modules should support widely-deployed infrastructure.  In
>
> >> particular, protocols that are current or deprecated, but never
>
> >> protocols that are obsolete.
>
> >
>
> > This implies that YANG is frequently interchanged on insecure plain-
>
> > text channels? Eek, didn’t know that. If I were on the IESG I’d be
>
> > very negative about this, but I’m not. I’ve made my point, if nobody
>
> > else is upset then you’re probably fine.
>
>
> This draft specifies YANG for just the HTTP protocol layer.  This
>
> config can be mixed-n-matched with the YANG from other protocol layers
>
> to create the configuration for a protocol stack.
>
>
> FWIW, the RESTCONF protocol sits on top of HTTP, but profiles it by
>
> mandating mutual authentication.  So whilst this YANG allows “http” in
>
> the general case, it is not allowed in the specific case.
>
>
>
>
> >>> <!-- The outermost element below doesn't exist in the data model.
>
> >>> -->
>
> >>> <!--  It simulates if the "grouping" were a "container" instead.
>
> >>> -->
>
> >>>
>
> >>> I totally don’t understand this, but maybe someone who’s a YANG
>
> >>> expert would?  I note that, in the example, if the outer “http-
>
> >>> client” element didn’t exist, the default namespace wouldn’t be
>
> >>> declared, and the “uri” element wouldn’t be in any namespace at
>
> >>> all. So maybe the namespace declaration would be better right there
>
> >>> on the “uri” element?
>
> >>
>
> >> This is a fair comment.   There are four examples in the draft that
>
> >> follow this convention.   FWIW, in other drafts I sometimes create a
>
> >> dummy “usage” YANG module to wrap “grouping” statements into
>
> >> containers.  What I’m doing here could be characterized as a
>
> >> shortcut.
>
> >
>
> > First of all you’re using the words “grouping” and “container” and I
>
> > don’t understand what they mean in this context. Is this standard
>
> > YANG terminology? If so, then OK I guess.
>
>
> Yes, “grouping” and “container” are standard statements in YANG.
>
>
>
> > If not, please explain what you mean.  I guess the only purpose of
>
> > the outer element is to carry the namespace declaration? If so, you
>
> > could either:
>
> >
>
> > Say “Assume that the default namespace has been mapped to XXX in some
>
> > containing element”, or
>
> > Put the namespace declaration right on the contained <uri> element
>
> > then you don’t need any extra apparatus.
>
> >
>
> > Or maybe something else.
>
>
> Suggestion #1 is doable.  Anyone on the list have ideas?  Is the
>
> existing text bad?
>
>
> Suggestion #2 is not so doable, because the other examples have many
>
> more lines than just the “uri” line.  Yes, the namespace could appear
>
> in each, but it wouldn’t be not nice.
>
>
>
> Kent
>
>
>