> From: Michael Richardson
> Sent: Montag, 5. Juli 2021 00:17
> Fries, Steffen wrote:
> >> I thought I wrote a really nice ASCII art version of what documents
> inherit
> from
> >> RFC8366. I can't find it in my outbox... I wonder if I nuked the
> draft by
> mistake.
> >>
> >>
Michael Richardson wrote:
> I propose that the WG adopt this as the -00, and then we change the
document
> to change this into an RFC7224-style IANA-maintained YANG module.
> (In DHC WG, when we did RFC3315bis to make RFC8415 we did a -00 which was
> whitespace equivalent to
Fries, Steffen wrote:
>> I thought I wrote a really nice ASCII art version of what documents
inherit from
>> RFC8366. I can't find it in my outbox... I wonder if I nuked the draft
by mistake.
>>
>> The short of it:
>> RFC8366 -> RFC8995 (voucher-request)
->
Hi, I have converted RFC8366.xml to Markdown, and switched to the latest MT
makefile, and after a bit of small massage to remove "8366" from the page,
and point to RFCs which are published, the result is at:
https://www.ietf.org/rfcdiff?url1=rfc8366=draft-richardson-anima-rfc8366bis.txt
Rob
Hi Michael,
> -Original Message-
> From: Michael Richardson
> Sent: Mittwoch, 30. Juni 2021 02:37
> I thought I wrote a really nice ASCII art version of what documents inherit
> from
> RFC8366. I can't find it in my outbox... I wonder if I nuked the draft by
> mistake.
>
> The
Kent Watsen wrote:
>> Rob Wilton (rwilton) wrote:
>>> An RFC8366bis is the right option. If the changes are minor then I may
>>> be able to ease the passage through the IESG, but I can't do much to
>>> affect the elapsed time.
> If considering a bis, can we consider
> On Jun 29, 2021, at 8:36 PM, Michael Richardson wrote:
>
>
> Rob Wilton (rwilton) wrote:
>> An RFC8366bis is the right option. If the changes are minor then I may
>> be able to ease the passage through the IESG, but I can't do much to
>> affect the elapsed time.
If considering a bis, can
Rob Wilton (rwilton) wrote:
> An RFC8366bis is the right option. If the changes are minor then I may
> be able to ease the passage through the IESG, but I can't do much to
> affect the elapsed time.
I will prepare a draft for this week.
I thought I wrote a really nice ASCII art
Hi Michael,
> -Original Message-
> From: Anima On Behalf Of Michael Richardson
> Sent: 25 June 2021 21:41
> To: Toerless Eckert ; Fries, Steffen
> ; anima@ietf.org; net...@ietf.org; Kent
> Watsen ; Rob Wilton (rwilton)
> Subject: [Anima] revising RFC8366 -- Re
Toerless Eckert wrote:
> Lets hear from yang doctors or yang friends. Right now i bet that if
> the only change for yang vouchers is this enum, then its probably
> easiest to do b), e.g.: make AE be a formal update. I think c) is
> appropriate if we have a larger critical mass of
I was first asking about the encoding ;-)
Would be good to understand if this "empty" encoding would result in a
- same of different degree of "backward compatibility" as an extended enum
- same or different size of ascii and binary encoding ?
I am also not quite clear what difference it really
Toerless Eckert wrote:
tte> https://trac.ietf.org/trac/netmod/wiki/YANG_FAQ#when-use-empty
tte> Is this the solution we are looking for ?
here it the relevant text:
} The second situation is when you want to define an extensible enumeration,
} as an alternative to the type
12 matches
Mail list logo
