[Gen-art] Last Call review of draft-ietf-dnsop-rfc6304bis-04

[Tom Taylor]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Document: draft-ietf-dnsop-rfc6304bis-04
Reviewer: Tom Taylor
Review Date: 15 August 2014
IETF LC End Date: 29 July 2014
IESG Telechat date: (if known)

Summary: This draft is ready to go.

Major issues: none.

Minor issues: none.

Nits/editorial comments: none.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-forces-model-extension-03

[Haleplidis Evangelos]

Greetings Ben,

I was slow to respond as I am currently on vacations.

Thank you very much for your extended review on the document. Please see
inline.

I have prepared all the necessary changes and the only thing that remains is
the boilerplate issue (and perhaps the security issues). When we resolve
this I can publish the new version.

Regards,
Evangelos Haleplidis.

> Summary: Nearly ready for publication as a proposed standard, but there
> are some issues that should be considered first, and some editorial
> issues that might also be worth consideration.
> 
> Note 1: I am not an expert in xml schema specifications. I hope assume
> others have reviewed the schema, and mechanically verified them.

[ΕΗ] I don't know if anyone else has verified the schema, but I have
verified it with verification tools and created sample xml libraries.

> Note 2: I notice that the Adrian's AD review commented about the lack
> of working group review, while the shepherd writeup comments that the
> working group had a solid consensus on this draft. On the surface,
> those comments seem to conflict. (I don't expect the author to take any
> action on this)
> 
> Major issues:
> 
> -- IDNits points out that this draft may need the pre-RFC5378
> boilerplate, due to content from RFC 5812. It does appear to include
> substantial amounts of XML schema from 5812. While the publication date
> of 5812 post-dates RFC5378, there were many revisions of the draft form
> that pre-date 5378 by some time. So unless the author has gotten
> permission from all 5812 authors (and I note that author list changed
> several times prior to publication), this draft and any resulting RFC
> may well need the boilerplate.
> 

[ΕΗ] Thank you for catching this as I have very little experience with this
kind of issues.
As I have not asked permission from the RFC5812 authors, what should be the
proper way to resolve this issue? 
Ask for permission or use a previous boilerplate?

> Minor issues:
> 
> -- section 2.3, 3rd paragraph:
> 
> The 2119 language in this paragraph seems more like description of
> procedures. You really only need 2119 language when you want to
> constrain some choice an implementor might make. Also, in the two cases
> of "MUST be ignored", please consider using active voice? (That is, who
> or what must ignore it?)
> 

[ΕΗ] In this specific case (I will reword it) the MUST is a constraint that
the implementer has to conform for interoperability. Otherwise the model
would mean something different from one implementer to the other, e.g. for
A's implementation the struct's component may have an access type of
"read-write" but for B it may mean "read-only". The MUST there defines that
when you define a struct component's access type, it MUST override the whole
struct's access type.

> -- section 2.4, 2nd paragraph:
> 
> This also seems like a description of general procedures that doesn't
> really need 2119 language.

[ΕΗ] Again I think that the MUST is something that is needed for
interoperability issues. The BecomesEqualTo MUST generate only one event
when the component reaches that specific value and not while it is there. 

> 
> -- section 2.4, bulleted paragraph:
> 
> Is this similar to saying that eventBecomesEqualTo effectively becomes
> an eventChanged after achieving the target value? Once the value
> changes from the target by V or more, does it reset the becomesEqualTo
> trigger?
> 

[ΕΗ] No, it does not effectively become an eventChanged. The difference is
that it will only be triggered ONCE when the value is changed and not
continuously.
And yes, it resets the BecomesEqualTo trigger.

> -- 2.6, 2nd paragraph: "... derivedFrom will always select the latest
> version."
> 
> What if a newer version of the parent is created after the child is
> defined? Can it cause backwards compatibility issues if the parent
> class changes out from under the child?
> 

[ΕΗ] Thank you for catching this. You're right, this may create backwards
compatibility issues.
This was an error on my part while writing the update of the draft. My
initial response was to use the first version (see
http://www.ietf.org/mail-archive/web/forces/current/msg04838.html) so it
would have been "select the first version".

I have made the necessary correction and made the text better. It now reads
as follows:
"However if the version is omitted then the derivedFrom will always specify
the first version of the parent LFB class, which usually is version 1.0."

Using always the first will mean something that is always there, and
resolves any ambiguities.

> -- section 6:
> 
> The assertion that the changes in this draft have no effect on security
> is a bit of a red flag. This draft introduces new kinds of properties
> and events that can be expressed, as well as a change to the
> inheritance model. Are you sure none of those have a security impact?
> It would at least be good to mention, for each of these changes, why
> you think it does not affect the prior model security

Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-appsawg-nullmx-08

[Barry Leiba]

Thanks, David, for the re-review.

> A draft has just been
> submitted to replace RFC 1846 (Experimental) with a Standards Track RFC:
>
> https://datatracker.ietf.org/doc/draft-klensin-rfc1846bis/
>
> The IESG should decide whether to proceed with the downref to RFC 1846bis
> vs. publish the 1846bis draft as a standards track RFC and reference it.
> That decision is the open issue in this review of the nullmx draft.

Right, and the decision has already been made, which is why the second
last-call notice says that the document has been "tentatively
approved":
The plan is to put the nullmx draft into the RFC Editor queue.  If we
can do the 1846bis processing quickly, so that when AUTH48 comes for
nullmx we see 1846bis as being essentially done, we will hold nullmx,
process the two documents together, and change the reference.  But if
it looks like 1846bis is getting hung up, we will proceed with
publication of nullmx with the downref.

That plan was discussed on the apps-discuss list a couple of weeks ago.

Barry

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art