Hi Jürgen,
I think we both agree with the proposal to immediately proceed with an erratum
and handle the bis separately.
I'm more optimist here if we agree on the scope I proposed below (existing
errata, no changes to the existing guidelines, add guidelines for writing
IANA-maintained module
I am a pessimist when it comes to IETF time plans and the ability to
limit discussions to certain issues once a document goes through a
working group process. I also recall surprises during the final stages
of the IESG review, some wonderful issues came up on things we did not
intent to touch in th
Hi Rob,
My prior response to you focused on what the draft specifies (not the liaison),
since you wrote:
"Fundamentally, I generally interpret this draft as saying: NETCONF/YANG
doesn't really match the existing management model/API in 3GPP and hence we
want to make non-backwards compatible c
Trying to catch up on the thread (and possibly I failed...).
A -bis *obsoleting* a previous version is probably easier for outsiders. More
pain for us at the IETF, but the end goal is better for SDO/organizations
outside of the IETF. (not to mention the trust issue).
Having written the above, I
Hi Rob, all,
I also think an errata is pragmatic here.
On the bis, I think that this can be handled separately. If we scope the bis to
be ** limited to very few items ** to cover areas where we don’t have
guidelines (e.g., add “Guidelines for IANA-Maintained Modules”), and in
addition to the f
> On Apr 5, 2023, at 08:17, Rob Wilton (rwilton)
> wrote:
>
>
> Hi Kathleen,
>
> The short answer to your question is maybe.
I do hope we will do something as I agree with your problem statement and would
like to see a fix. Perhaps a topic for the retreat.
> The longer answer is my ema
Hi Kathleen,
The short answer to your question is maybe. The longer answer is my email
reply to Stephan and Joel below.
But if you are also okay, or at least don’t object, to the errata path, then I
will kick off a proposed errata so that it can reviewed/discussed.
Regards,
Rob
From: Kathle
Hi Kent,
Some of my concern stems from the fact that during the NMDA architecture
discussions there was a strong desire to make the configuration data stored in
to be owned by the client. I.e., the server has the right to accept
or reject a particular configuration but ultimately it is the cl
