Hi Tom, Jeff,
Thanks for the comments.
Yes, we will address these comments, and also the comments raised by the
other reviews. I'll also do a pass through the document in an attempt
to improve the prose.
One slightly difficultly is that I have learned today that we are
loosing the primary editor, but gaining a replacement. I'm also about to
be on holiday for a few weeks, so the majority of my updates will
probably need to be deferred until September.
For clarification, are you saying that we should post an updated version
before a final adoption call, or for these comments to be addressed
immediately after it is adopted (if that is the outcome).
Thanks,
Rob
On 31/07/2018 22:27, Jeff Tantsura wrote:
Tom,
Many thanks for your comments!
Authors - I'd expect you to address them while the document is in adoption
state.
Tom - specifically to "flaky English" comment - your help to making the
document better would be highly appreacited.
Cheers,
Jeff
On 7/31/18, 02:01, "tom petch" <[email protected]> wrote:
<rant>
This I-D has some of the usual things wrong with it that need fixing at
some state and, as ever, I like to see the editors fix at least some of
them before adoption rather than leaving them until later, since they
then seem to linger, perhaps until WG Last Call or IETF Last Call (yes,
I am thinking of WG such as MPLS:-)
There is a fundamental (to me) principle in engineering of get it right
first time, or at least as early as possible; later means more
expensive, more time consuming for everyone involved. I link this to
the discussion on the main IETF list of the difficulty of finding ADs
because so much time is involved in being an AD; yes, and part of that
is us giving them poor quality documents with defects that could have
been fixed even before adoption..
</rant>
This I-D
- fails to mention whether or not it is NMDA compliant in the Abstract
and Introduction
- fails to use the current definitions of terminology from RFC8342
- references the old version of RFC2119 key words
- has no Note to the RFC Editor asking them to replace the YANG module
dates with date of publication. I suggest a Note asking them to replace
XXXX with the number assigned to this I-D at the start of the I-D rather
than asking them to replace 'draft-ding-rtgwg-arp-yang-model-02 ' which,
should this I-D be adopted, will be wrong
- has no Copyright statement in the YANG module
- lacks references for several imported modules.
- starts Section 4 well with a good sentence but fails to mention most
imports
- has serious formatting problems with the text in the YANG module with
lines being way too long for an RFC (it is probably not a coincidence
that other I-Ds have had the same problem - the right options in pyang
fix this AFAIK)
- has no IANA Considerations; no IANA Considerations means that you are
not producing a YANG module no matter what it looks like.
- Security Considerations are much better than usual but lack detail of
sensitive nodes
- Tree diagrams has the right reference but then spoils it by including
text about the symbols
- has out of date references
[I-D.ietf-netmod-rfc7223bis]
[I-D.ietf-netmod-rfc7277bis]
which belie the claimed date of June 28, 2018 for this I-D; 2018-01-27
looks more like it:-)
- has arp as a Informative Reference - Normative I think.
I note that there is no IPV6 in the examples but that seems right since
ARP is IPv4.
The English is flaky in places but I am fine with that; that can be
fixed once the text has been discussed and agreed - in fact there is no
point in producing perfect English if we are then going to discuss and
change it - whereas the points above can mostly be fixed before now.
Tom Petch
----- Original Message -----
From: "Jeff Tantsura" <[email protected]>
To: "RTGWG" <[email protected]>
Cc: "rtgwg-chairs" <[email protected]>;
<[email protected]>
Sent: Thursday, July 26, 2018 2:04 AM
> Dear RTGWG,
>
>
>
> The authors have requested the RTGWG to adopt
draft-ding-rtgwg-arp-yang-model as the working group document.
>
> The draft has been stable and provides all the additional arp pieces
that are not in RFC8344, it has been presented at IETF 102 and no
substantial comments have been received.
>
>
>
> Please indicate support or no-support by August 09, 2018
>
>
>
> If you are listed as a document author or contributor please respond
to this
>
> email stating of whether or not you are aware of any relevant IPR.
>
> The response needs to be sent to the RTGWG mailing list. The document
will not
>
> advance to the next stage until a response has been received from each
>
> author and each individual that has contributed to the document.
>
>
>
> Cheers,
>
> Jeff & Chris
>> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
