On 6/4/18 5:39 AM, Gorry Fairhurst wrote:
The document write-up describes the process that has been used with SCTP
updates, and this document follows this plan - this is information to
help the WG prepare a bis document, that we plan to populate with these
edits to the spec and adopt as a WG i
Hi Robert, thanks for checking.
Although I tend to agree with you about 2119 language, as I understand
the intent of the author (and of the community of practice that uses
national bibliography numbers) is for this document (as RFC 3188 before
it) to define how NBNs are used in the field.
Peter
Thanks Peter!
The editorial pass looks really good. It let me spot a nit I missed before:
at
" necessary, a resource in outdated file format is migrated into a more"
you probably want "in an outdated file format"
In that paragraph, you added some MAYs that go against my first original
point,
Just chiming in as AD ...
On Mon, Jun 4, 2018 at 7:18 AM Christer Holmberg <
christer.holmb...@ericsson.com> wrote:
> Hi,
>
> >>> The information in this document does not update RFC4640 or the Errata
> >>> to that specification. The document is instead provided as input to
> >>> preparation of
Robert, some fixes were posted over the weekend - if you have a chance,
please check the diff here:
https://tools.ietf.org/rfcdiff?url2=draft-hakala-urn-nbn-rfc3188bis-01.txt
Thanks!
Peter
On 5/1/18 12:35 PM, Robert Sparks wrote:
> Reviewer: Robert Sparks
> Review result: Ready with Issues
>
>
Hi,
>>> The information in this document does not update RFC4640 or the Errata
>>> to that specification. The document is instead provided as input to
>>> preparation of a new document that is expected to be a standards-track
>>> replacement for RFC4960. If approved, the replacement document will
Hi
On 04/06/2018 11:13, Christer Holmberg wrote:
Hi Gorry,
...
The information in this document does not update RFC4640 or the Errata
to that specification. The document is instead provided as input to
preparation of a new document that is expected to be a standards-track
replacement for RFC
Not a comment on the document, but a question/suggestion:
If you want to have a place holder for changes to be done in the bis
(which seems to be the main purpose of the errata document), why not
create a GitHub repo for the bis, and then document everything as GitHub
issues? Then, when you start
Hi Gorry,
...
>The information in this document does not update RFC4640 or the Errata
>to that specification. The document is instead provided as input to
>preparation of a new document that is expected to be a standards-track
>replacement for RFC4960. If approved, the replacement document will
Hi Christer,
As document shepherd for this SCTP process, I'll have a first go at
responding. I think that for RFC4960 the Errata as filed still apply.
See below. The document authors can of course also propose answers to
these questions
Gorry
On 04/06/2018 10:17, Christer Holmberg wrot
Re-sent due to wrong e-mail address.
>
>Hi,
>
>I have also looked at this document, and there are things that I have
>think are unclear:
>
>Q1: It is Informational, and it does not update RFC 4960. Instead, it just
>seems to list the erratas (but without even referencing them, as noted by
>Paul).
Hi,
I have also looked at this document, and there are things that I have
think are unclear:
Q1: It is Informational, and it does not update RFC 4960. Instead, it just
seems to list the erratas (but without even referencing them, as noted by
Paul). I think that it should be made very clear that
12 matches
Mail list logo
