Jouni Korhonen wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please treat these comments just
> like any other last call comments.
>
> For more information, please
Hi Jouni,
>>> * The intoduction mentions that the block transfwer can be used for
>>> random access. This is not separately described anywhere in the
>>> documents. Although the operation is more or less trivial I would
>>> appreciate an example or some text there because the Block2 overloads
>>>
Jouni Korhonen wrote:
> Hi Jouni,
>
> Just saying.. the use of NUM was not crystal clear just by reading the
> draft and not having the followed the core block development &
> discussion past few years.
Right. I'm not sure I have fully addressed this one; all your other
comments should be addres
Hi Elwyn,
thank you for your review — that is a lot of good input.
Before I start thinking about fixes for the WG to consider, let me comment on a
few items:
> Summary:Not ready for publication. There a number of issues that need
> to be addressed as discussed below. In particular whether th
On Apr 26, 2017, at 19:12, Adam Roach wrote:
>
> This has the reciprocal problem that using quotes with (e.g.) sz and hreflang
> is a violation of the ABNF in RFC6690.
Yes. Using ABNF for the serialization of an item that should be described at
the data model level (as in 5988bis) is now gene
Hi Elwyn,
we tried one round at your comments.
We didn’t tackle the interaction with /.well-known/core — I continue to believe
what I said yesterday, but we still have to find a good way to put this into
the document.
We added a note that we need to decide whether there is an onus on a receivi
Hi Ines,
Thank you very much for the review and the slight embarrassment it causes to
the authors…
Comment 3 below we will pick up in the WG meeting today; I’ll report about that
later.
The other comments are now addressed in the editor’s copy:
https://github.com/cbor-wg/cddl/commits/master
(I
On Mar 09 2008, at 19:23, Henrik Levkowetz wrote:
> McGillin’s Olde Ale House
While enough (and justified) praise is heaped on the Tuesday social on
the 71attendees list, nobody has spoken up about the WG chairs' beer
evening, so let me be the first:
=== What a place! ===
For the next term
Hi Dan,
thanks for the review.
We will be looking into these points in more detail in the next few days.
One of your comments can be addressed immediately:
On Mar 27, 2013, at 14:33, "Romascanu, Dan (Dan)" wrote:
> 5. Section 12.6
>
>> IANA has assigned the port number 5683 and the service n
> reference if proper definitions can be found some place else.
A draft is nearing completion in LWIG that is defining these and other terms
relevant to this field.
"Terminology for Constrained Node Networks", Carsten Bormann, Mehmet
Ersue, 25-Feb-13,
We should reference this as a
Jari,
indeed, it seems we never replied to these two items.
>> 2 . The WG charter says:
>>
>>> 7) Consider operational and manageability aspects of the protocol and at
>>> a minimum provide a way to tell if a Device is powered on or not.
>>
>>
>> There is no mention in the protocol document (
Here is the reply to the ops-dir review I just talked about.
Grüße, Carsten
Begin forwarded message:
> Resent-From: draft-alias-boun...@tools.ietf.org
> From: Carsten Bormann
> Subject: Re: Operations Directorate Review of draft-ietf-core-coap-13.txt
> Date: March 11, 2013 22
On Jul 30, 2013, at 09:05, Martin Thomson wrote:
> What would cause this to be tragic, is if publication of this were
> used to prevent other work in this area from subsequently being
> published.
Indeed.
As Paul and I have repeatedly said, CBOR is not trying to be the final,
definitive, binar
On Aug 5, 2013, at 19:43, Joe Hildebrand (jhildebr) wrote:
> Sorry, my response is also correspondingly long.
The present message wraps up the more general comments sent by Joe
Hildebrand concerning CBOR. Lots of juicy comments. Thanks to all!
For these, we are not using the line-by-line st
On Aug 5, 2013, at 19:43, Joe Hildebrand (jhildebr) wrote:
> Sorry, my response is also correspondingly long. There are some original
> comments at the end
[...]
We have worked a bit on the detail remarks of your review.
(The previous message addressed the grander aspects).
Item-by-item repli
On Aug 12, 2013, at 23:41, "Joe Hildebrand (jhildebr)"
wrote:
> Having more than one way to encode +/- Infinity seems like a recipe for
> generating slightly different canonical output. For example, in my code
> right now, I think I'm always generating a half-precision Infinity, and
> I'm think
Hi Stewart,
Thank you for the review. We already communicated about fixing one of the
items, but it seems the rest of our response never made it out. Here goes…
> On Apr 6, 2019, at 11:26, Stewart Bryant via Datatracker
> wrote:
>
> Reviewer: Stewart Bryant
> Review result: Ready with Nits
Hi Elwyn,
thank you for these comments.
These are now addressed in the editor’s copy on github, specifically in
https://github.com/cbor-wg/array-tags/commit/f63c0301c481ab773c16b96a9b0eb63456554049
Details below.
> On Sep 6, 2019, at 21:33, Elwyn Davies via Datatracker
> wrote:
>
> Reviewer: E
Hi Linda,
thank you for this review.
> On Oct 31, 2019, at 17:41, Linda Dunbar via Datatracker
> wrote:
>
> Reviewer: Linda Dunbar
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
On Nov 8, 2019, at 16:34, Burleigh, Scott C (US 312B)
wrote:
>
> I disagree. From Wikipedia:
>
> Unix time (also known as Epoch time, POSIX time,[1] seconds since the
> Epoch,[2] or UNIX Epoch time[3]) is a system for describing a point in time.
> It is the number of seconds that have elaps
On Nov 27, 2019, at 02:56, Mark Nottingham wrote:
>
> Do we expect most readers to be comparing the documents so closely? This is
> an 'obsoletes', not an 'updates'.
Speaking for myself as a reader only: Yes.
Grüße, Carsten
___
Gen-art mailing list
On 2020-07-04, at 05:06, Donald Eastlake wrote:
>
>> Section 2: Please add a reference for the IANA registry. I think
>> you are pointing to here:
>>
>> https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-2
>
> Is IANA's URL structure and URL embedded nomenclature guara
On 2020-07-03, at 18:33, Russ Housley via Datatracker wrote:
>
> I assume that it is okay to use "[1] [2]" instead of
> "[RFC2119] [RFC8174]", but this is not the tradition.
Oh. Numeric references are not good style in RFCs (neither are they current
style, e.g., compare RFC 7322 — while sectio
Hi Linda,
> On 2021-03-16, at 18:34, Linda Dunbar via Datatracker
> wrote:
>
> Reviewer: Linda Dunbar
> Review result: Not Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF
Hi Elwyn,
thank you for this substantive review.
We’ll get to the details soon, but I’m intrigued by this:
> General: The RFC Editor preferes the US convention for quoting items using
> exclusively singe quote rather than double quote marks.
Last time I looked at this, I gained the impression t
On 2021-05-03, at 22:10, Elwyn Davies wrote:
>
> Hi, Carsten.
>
> My understanding is
>
> RFC editor position: use single quotes for everything.
Wasn’t that way for my first 42 RFCs :-)
> Standard US view apparently.
US view is actually rather unanimously double quotes (outside any out
Hi Elwyn,
I finally got around to process your review.
I have submitted a new version -03 based on this review.
I could make direct use of your text suggestions, but did edit them a little.
So you may want to have another look at the second paragraph of 1
(introduction) and the new section 2.2,
sent(fc) ⋅ 2").
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-versions-03.txt
>
> Ciao!
> --
> Jaime Jiménez
>
> On Sun, May 9, 2021, at 10:51 PM, Carsten Bormann wrote:
>> Hi Elwyn,
>>
>> I finally got around to process your review.
&
Hi Christer,
thank you for this review.
One interesting side note I have from reading the review is:
The CoRE WG, which produced this specification, is probably best known for
maintaining the CoAP protocol, but it also has some other specifications, in
particular with respect to data formats.
Hi Theresa,
thank you for your review, which highlights a number of needed improvements.
> Minor issues:
>
> Section 1:
> Please consider adding a brief description of what a control operator is, how
> it can be used, and what its components are.
I’m not so sure about that. This document reall
On 15. Feb 2022, at 22:25, Brian E Carpenter
wrote:
>
> Can somebody tell me how to insert that seriesNo="39" in kramdown?
Sure. As with the other https://www.ietf.org/mailman/listinfo/gen-art
On 15. Feb 2022, at 22:37, Carsten Bormann wrote:
>
> seriesno: 39
And now, the answer to the more important question: Where is that documented?
https://github.com/cabo/kramdown-rfc2629/wiki/Syntax#the-yaml-header
(Documented since 2016-02-16.)
Grüße, C
ection-2.45.10
Grüße, Carsten
> On 15. Feb 2022, at 22:47, Carsten Bormann wrote:
>
> On 15. Feb 2022, at 22:37, Carsten Bormann wrote:
>>
>> seriesno: 39
>
> And now, the answer to the more important question: Where is that documented?
>
> https://github.co
Hi Pete,
thank you for this review.
I have collected my proposed changes based on these and other comments in
https://github.com/cbor-wg/cbor-magic-number/pull/21
under the commit
https://github.com/cbor-wg/cbor-magic-number/pull/21/commits/e476afb
> Nits/editorial comments:
>
> Section 1 c
Hi Russ,
thank you for this review.
Two comments:
> Minor Concerns:
>
> Section 3: A reference to ABNF is needed. Since %s is being used,
> I believe that a reference to RFC 7405 is required. Alternatively,
> the paragraph in Section 1.1 could be moved to Section 3.
We generally write IETF d
Hi Robert,
Thank you for this review.
Please see my comments on individual issues below.
> On 2023-06-13, at 23:59, Robert Sparks via Datatracker
> wrote:
>
> Reviewer: Robert Sparks
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> R
On 2023-06-14, at 10:25, Edward Welbourne wrote:
>
> I note in passing that, while the 14-character limit is indeed
> documented in the IANA DB's rules for names,
[…]
Very good point.
Now issue
https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues/46
Grüße, Carsten
___
On 10. Aug 2023, at 20:18, Linda Dunbar via Datatracker
wrote:
>
> The major issue is that this document should not be “Standard Track” […]
Others have already gone into the details why this very much should be a
standards-track document.
Let me just add another data point:
We already have a
Hi Joel,
> On 2024-05-25, at 22:56, Joel Halpern via Datatracker
> wrote:
>
>It would be helpful if section 4.2 (IANA Considerations creating the
>Encoding Indications registry) said it was recording the assignments made
>in RFC 8949 section 8.1, and adding the _i indication. It wo
39 matches
Mail list logo
