Hi Eric, Thanks for your prompt reply,
See replies below at <de>, deleting some of the areas where we already agree or you found my response adequate. In the cases where you didn't respond to my response, I assume my response was adequate. On Wed, Sep 13, 2023 at 10:37 AM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > Hello Donald, > > Thanks for your prompt reply. > > Look below for EV> (my outlook is broken for IETF traffic) > > TL;DR we agree on most point(barring some points that are merely a matter > of taste), but before requesting the IETF Last Call, I want to clarify the > CBOR tag section 2.4 with CBOR WG & ADs. > > Regard > -éric > > PS: Please note that I will be on holidays from this WE for 10 days. > > On 13/09/2023, 06:54, "Donald Eastlake" <d3e...@gmail.com <mailto: > d3e...@gmail.com>> wrote: > > Hi Eric > > Thanks for the review. See responses below. > > On Mon, Sep 11, 2023 at 8:43 AM Eric Vyncke (evyncke) <evyn...@cisco.com > <mailto:evyn...@cisco.com>> wrote: > > Dear authors, dear shepherd, dear WG, > > > > As the Int-area WG chairs have requested the publication of this IETF > draft, I have done my usual AD review of it. Before processing with the > publication (i.e., the IETF Last Call), I am requesting a reply or an > action on all the points below. > > > > ... > > > > Regards > > -éric > > > > ... > > > > # Section 1.2 > > > > Should this section be removed by the RFC editor upon publication ? Or > moved to an appendix ? > > I do not think it should be removed. > > The list of changes from RFC 5342 to RFC 7042 appeared up front in RFC > 7042 but I wouldn't have a problem moving this to an appendix for > rfc7042bis. > > EV> thanks for moving it in the appendix (usual place for this section) or > let the RFC editor do it later ? > <de> Since it's going to be edited based on your review, might as well move it to an appendix now. > > # Section 1.3 > > > > If there is a stable URL for " IEEE Registration Authority site", should > it be added as a reference ? > > The reference at the end of the first sentence of 1.3 is to their web > site. When I click on it in the HTMLized version, it takes me there. > > EV> not optimum, but ok > <de> Thanks. > > # Section 2.1 > > > > I find " 4 1/2 octets (36 bits)" not easy to parse, what about "4.5 > octets (36 bits)" ? > > Hummm, well, I think "4.5 octets" is just as odd. Would "four and a > half octets" be OK (also replacing the subsequent "1 1/2" with "one > and a half")? > > EV> "one and a half" & "four and a half" sound OK for me > <de> OK. > > # Section 2.1.1 > > > > How can the reader check whether " the IEEE 802 Structured Local Address > Plan (SLAP) is in effect" ? > > There isn't any automated way, that I am aware of, to determine if or > to what extent a local network is configured for and/or operating > according to SLAP. If you meant more generally adopted as a standard, > it has been in the 802 standards for some years but remains an > optional choice and is not mandatory. > > EV> I meant the former (not the standard part). A variation of your first > sentence would help the reader. > <de> Will add such a sentence. > > # Section 2.1.3 > > > > s/Currently/In 2023/ ? > > Sure, How about "As of 2023"? I think "in 2023" has some implication > that they were assigned in the year 2023 when some were assigned > earlier. > > EV> "As of 2023" seems perfect indeed > <de> Thanks. > > # Section 2.2.1 > > > > AFAIK, EUI-64 based IPv6 addresses are not officially deprecated (only > recommended not to be used by RFC 8064). > > I think "recommended not to be used" is exactly the definition of > "deprecated". (This change was requested by and the wording OKed by > Bob Hinden.) > > EV> (just read again the WGLC discussion with Bob), Bob suggested "no > longer recommended" but he has agreed on "deprecated". Personally, I still > prefer "no longer recommended", but I will leave it to you. > <de> Thanks, will leave as is. > > ... > > > # Section 2.4 and section 5.9 > > > > I am really puzzled by this section: what is the purpose of it? It seems > to be a CBOR encoding of IEEE OUI/address/identifier so really a CBOR > document. > > I don't understand what's puzzling about this section. Its purpose is > to specify a CBOR encoding of some IEEE identifiers. This was > discussed on the CBOR WG mailing list. See the thread beginning with > https://mailarchive.ietf.org/arch/msg/cbor/I49hlrHka1BUPAq8oCtO77xElvc/ < > https://mailarchive.ietf.org/arch/msg/cbor/I49hlrHka1BUPAq8oCtO77xElvc/> > This thread includes the message at > https://mailarchive.ietf.org/arch/msg/cbor/I49hlrHka1BUPAq8oCtO77xElvc/ < > https://mailarchive.ietf.org/arch/msg/cbor/I49hlrHka1BUPAq8oCtO77xElvc/> > <de> The above URL, duplicating the one further above, is wrong. It should have been https://mailarchive.ietf.org/arch/msg/cbor/h2FGrQ7Uw0PX4NdHO7Rn07rCbtI/ <https://mailarchive.ietf.org/arch/msg/cbor/h2FGrQ7Uw0PX4NdHO7Rn07rCbtI/> > in which a CBOR WG decision to "leave Ethernet tags for Donald's > rfc7042bis." was announced. There was also some consultation with > Carsten Boreman, who in my opinion is a CBOR expert, on the wording of > this section. > > EV> Carsten is indeed "the" CBOR guy among many others. > EV> But my major concern is that this I-D is about the use of IEEE 'code > points' by IETF protocols and not about representation/serialization of > IEEE 'code points'. The abstract is pretty clear about this focus and the > one-liner in the introduction about CBOR feels odd. > <de> It seems to me that the "representation/serialization of IEEE 'code points'" is a part of their use by IETF protocols. <de> "aspects of such parameters and their use in IETF protocols" in the abstract seems pretty general to me although the wording could be further generalized. EV> E.g., this I-D does not specify how IEEE 'code points' are represented > in XML or in JSON, so why CBOR ? > EV> I will shortly send an email about this to CBOR & INT-AREA WGs + > responsible ADs as I want to prevent any issue as early as possible in the > publication process. > EV> My preferred way would be to have a separate, very short, I-D just > about the CBOR encoding of IEEE 'code points'. Could be in INT-AREA if CBOR > does not want to work on it, could even be AD sponsored. > <de> I guess we will see what the response to your email is. <de> Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com ... > > > Which document specifies the TBD1 and TBD2 in this section ? > > Just like most "tbd"s in an Internet Draft, they are specified in the > IANA Considerations, in this case Section 5.9. > > EV> I was concerned that this could be a CBOR draft yet to be published. > OK, but see above. > > > ... > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e...@gmail.com <mailto:d3e...@gmail.com> >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
