Re: [Gen-art] Gen-ART Review of draft-ietf-dnsop-edns-client-subnet-04

[Warren Kumari]

Hi all,

I think it is much easier for reviewers to always be able to see the latest
version of a draft, and so I'm trying to integrate changes and then publish
new version often.

On Tue, Dec 15, 2015 at 11:50 AM David C Lawrence  wrote:

> > > In Section 7.1.1, can you add a sentence or reference to explain "lame
> > > delegation"?  I recognize that this type of error results when a name
> > > server is designated as the authoritative server for a domain name and
> > > that server does not have authoritative data.
> >
> > [ AUTHORS: This was a term that was left out of the terminology draft. Do
> > you have any suggestions for how we can reword this to remove the need
> for
> > the term? ]
>
> "... to distinguish the respone from one where the Authoritative
> Nameserver is not responsible for the name, which is a common
> convention for the REFUSED status."
>

Nice.
Integrated.


>
> > > Section 7.4 says: "Several other implementations, however, do not
> > > support being able to mix positive and negative answers, and thus
> > > interoperability is a problem."  Then, the next paragraph says that
> > > this topic will be revisited in a future specification.  Is there any
> > > advice that the authors can share as a step toward interoperability
> > > that would be useful for implementers until the future specification
> > > comes about?
> >
> > [ AUTHORS: Any text for here? ]
>
> The current situation is such that I think it is best just to say only
> something like, "It is recommended that no specific behaviour
> regarding negative answers be relied upon."
>
>
Done.

Posted -06

W


> Personally my proposal is going to be that negative answers be allowed
> to be scoped the same way that positive answers can be, but I don't
> expect it to be without some controversy and it wouldn't be right for
> me to insert by own bias into this document -- especially since Wilmer
> is one of the people who has said that he doesn't think ECS should be
> able to be used with negative answers.
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart Telechat review draft-ietf-eppext-keyrelay-11

[Rik Ribbers]

Robert,

> 
> I also still think you would have a stronger document if it discussed the 
> SHOULD NOT in the security section as I suggest below. I think you read that 
> to be me suggesting you change it to MUST NOT. That was not the intent. I was 
> asking you to add to the document _why_ it wasn't MUST NOT.

I’ll take that into consideration, as I have explained it in the response the 
wording isn’t that difficult anymore. There are some more IESG review comment 
on this section so I assume there will another version to before publication. 

Current wording:

A server SHOULD NOT perform any transformation on data under server management 
when processing a \ command.

Proposed wording:

A server SHOULD NOT perform any transformation on data under server management 
when processing a \ command. The intent of this command is to 
put DNSSEC key material on the poll queue of another client. To make sure that 
this EPP extension is interoperable with the different server policies that 
already have implemented EPP this extension it is not classified as must not.

Please let me know what you think of this proposal (or send in text ;-))

Gr,
Rik 

smime.p7s
Description: S/MIME cryptographic signature
___
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-nfsv4-rpcsec-gssv3-13

[Adamson, Andy]

> On Dec 10, 2015, at 2:48 PM, Elwyn Davies  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 see the FAQ at
> 
> .
> 
> Document: draft-ietf-nfsv4-rpcsec-gssv3-13.txt
> Reviewer: Elwyn Davies
> Review Date: 2015-12-09
> IETF LC End Date: 2015-12-09
> IESG Telechat date: (if known) -
> 
> Summary: Almost Ready.  There are a couple of minor issues that just poke 
> above the editorial/nits level.  The downref issue probably needs to be 
> solved by incorporating the relevant descriptions from the requirements doc 
> (RFC 7204) into the NFS v4.2 draft and using that as the reference - the 
> relevant information is indeed needed by implementers to understand what is 
> going on in this protocol and in NFSv4.2 and referring back to the 
> requirements RFC is probably not a good way to go as the requirements may be 
> neither complete nor fully implemented, making the reference potentially 
> unreliable.
> 
> Major issues:
> None
> 

Hi

I have addressed the review issues in draft-14 which I submitted. Please see 
inline for comments on three of the issues.

> Minor issues:
> s1, para 5 and s6.2:  idnits points out that RFC 2401 has been obsoleted by 
> RFC 4301.  I suspect that RFC 4301 could be referenced instead.

No - RFC2401 section 8 describes Multi-level security - RFC 4301 does not.. 
draft-14 uses 4301 along with Bell-LaPadula, but this needs to be changed. See 
last comment on the Bell-LaPadula technical report.

> 
> s1.1, first bullet and last para:   ... both refer to RFC 7204 which is given 
> as a normative reference.  This is a downref to an informational document.  I 
> observe that (probably) the same material is referred to in [NFSv4.2] 
> although there it is given as informational.  My personal view is that it 
> would be better to extract the relevant info from RFC 7204 and add it into 
> [NFSv4.2] which is already referenced normatively in this draft.Requiring 
> implementers to plough through the requirements (no section pointers are 
> given) that may or may not have been executed in the standards seems 
> undesirable.

As I look at the GSSv3 use of RFC 7204, it is all informational. I moved the 
RFC 7204 referrence from normative to informational and give section pointers 
when the referrence is used in the document. I hope this clears it up.

> 
> s2.1 and s2.5: s2.5 states that 'RPCSEC_GSS_BIND_CHANNEL MUST NOT be used on 
> RPCSEC_GSS version 3 handles'.  This is rather more constraining than the 
> term 'deprecated' used in s2.1.  It would seem that:
> - s2.1 ought to say that RPCSEC_GSS_BIND_CHANNEL is *not supported* when 
> version 3 is in use.
> - s2.5 ought to specify how the target should respond if a client requests a 
> RPCSEC_GSS_BIND_CHANNEL operation on a v3  handle.
> 
> s2.6/s5: New auth_stat values are managed by IANA (on a first come first 
> served basis) [Better get your request in now if you want these numbers!]  
> See 
> http://www.iana.org/assignments/rpc-authentication-numbers/rpc-authentication-numbers.xhtml#status
>  and RFC 5531.  The request should be documented in s5.
> 
> Nits/editorial comments:
> Abstract: s/to server/to a server/
> 
> s1, para 3: s/A major motivation for RPCSEC_GSSv3/A major motivation for 
> version 3 of RPCSEC_GSS (RPCSEC_GSSv3)/ (This expansion is currently done 
> later on in s1.1).
> 
> s1, para 3: s/i.e. /i.e.,  /
> 
> s1, para 5: s/ Labeled NFS (see Section 8 of [NFSv4.2])/ Labeled NFS (see 
> Section 9 of [NFSv4.2]) (referring to -39)  It might be worth noting 
> explicitly that 'full-mode' is defined in s9.6.1 of [NFSv4.2]
> 
> s1, para 5: MAC needs to be expanded (at least on account of the multiple 
> possible expansions!)  Presumably this should be 'Mandatory Access Control 
> (MAC) systems (as defined in [RFC4949])' (quoting RFC7204, section 1).
> 
> s1, para 6: s/server-side copy (see Section 3.4.1 of [NFSv4.2])/server-side 
> copy (see Section 4 of [NFSv4.2])/
> 
> s1, para 7: It might be worth explicitly mentioning s9 of [AFS-RXGK] that 
> introduces cache poisoning issues.
> 
> s1.1: According to s2.7.1.2, the channel binding feature is OPTIONAL to 
> implement for servers.  It would be useful to note this in s1.1. Similarly 
> labeling is OPTIONAL according to s2.7.1.3.   Presumably the other features 
> MUST be supported by a RPSEC_GSSv3 implementation - this could also be noted.

> 
> s2, 2nd bullet: s/that uses the child handle./that use the child handle./
> 
> s2.3, para 1: Need to expand MIC on first occurrence (Message Integrity Code, 
> I assume)
> 
> s2.3, code fragment: s/* This code was derived from [RFC2203]./* This code 
> was derived from RFC 2203, RFC 5403 and RFC-to-be./ (presumably)

[Gen-art] A *new* batch of IETF LC reviews - 2015-12-15

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

Reviewer  LC end  Draft
-
Brian Carpenter   2015-12-24  draft-ietf-ippm-active-passive-04

Christer Holmberg 2015-12-30  draft-ietf-isis-te-metric-extensions-07

Dan Romascanu 2015-12-28  draft-ietf-hip-rfc6253-bis-06

Francis Dupont2015-12-28  draft-ietf-hip-rfc5203-bis-09

Joel Halpern  2015-12-28  draft-ietf-hip-rfc5204-bis-06

Jouni Korhonen2015-12-28  draft-ietf-hip-rfc5205-bis-08

Roni Even 2015-12-28  draft-ietf-abfab-aaa-saml-13 *

* 2nd LC


I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The /updated/ template is included below.

Thanks,

Jean

---

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 see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

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

[Gen-art] Genart Telechat review draft-ietf-p2psip-diagnostics-19

[Alexey Melnikov]

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-p2psip-diagnostics-19
Reviewer: Alexey Melnikov
Review Date: 2015-12-15
IETF LC End Date:
IESG Telechat date: 2015-12-17



Summary: Nearly ready for publication as Proposed Standard

I think this document has a list of issues, but they should be easy to fix:

In Section 5.3:

The dMFlags field described above is a 64 bit field that allows
   initiator nodes to identify up to 62 items of base information to
   request in a request message (the first and last flags being
   reserved).

But the IANA registration section uses flags 1 and doesn't seem to
reserve the highest bit either. If this text is now wrong, it should be
deleted. If the IANA section is wrong, please fix it. If I am wrong,
please tell me :-).

In Section 5.3:

SOFTWARE_VERSION: A single value element containing a US-ASCII
  string that identifies the manufacture, model, operating system
  information and the version of the software.  Given that there are
  very large number of peers in some networks, and no peer is likely
  to know all other peer’s software, this information may be very
  useful to help determine if the cause of certain groups of
  misbehaving peers is related to specific software versions.  While
  the format is peer-defined, a suggested format is as follows:
  "ApplicationProductToken (Platform; OS-or-CPU) VendorProductToken
  (VendorComment)".  For example: "MyReloadApp/1.0 (Unix; Linux
  x86_64) libreload-java/0.7.0 (Stonyfish Inc.)".  The string is a
  C-style string, and MUST be delimited by "\0".

Did you mean "terminated"? I don't see what can be delimited, as this
implies presence of multiple fields.

  "\0" MUST NOT be
  included in the string itself to prevent confusion with the
  delimiter.



EWMA_BYTES_SENT (32 bits): A single value element containing an
  unsigned 32-bit integer representing an exponential weighted
  average of bytes sent per second by this peer. sent = alpha x
  sent_present + (1 - alpha) x sent where sent_present represents
  the bytes sent per second since the last calculation and sent
  represents the last calculation of bytes sent per second.  A
  suitable value for alpha is 0.8.  This value is calculated every
  five seconds.


I don't understand the formula. What is "x"?
Should the formula be on its own line for ease of understanding?

BATTERY_STATUS

This flag doesn't seem to be defined in a useful fashion. You need to at
least provide some guidance here to insure interoperability.

In Sections 9.3-9.5: is RFC- this document or RFC 6940 (or something
else)?

Thank you,
Alexey

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

Re: [Gen-art] Genart Telechat review draft-ietf-p2psip-diagnostics-19

[Alexey Melnikov]

I deleted an incorrect recipient in my original review. Sorry about that.

> On 15 Dec 2015, at 11:19, Alexey Melnikov  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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-p2psip-diagnostics-19
> Reviewer: Alexey Melnikov
> Review Date: 2015-12-15
> IETF LC End Date:
> IESG Telechat date: 2015-12-17
> 
> 
> 
> Summary: Nearly ready for publication as Proposed Standard
> 
> I think this document has a list of issues, but they should be easy to fix:
> 
> In Section 5.3:
> 
> The dMFlags field described above is a 64 bit field that allows
>   initiator nodes to identify up to 62 items of base information to
>   request in a request message (the first and last flags being
>   reserved).
> 
> But the IANA registration section uses flags 1 and doesn't seem to
> reserve the highest bit either. If this text is now wrong, it should be
> deleted. If the IANA section is wrong, please fix it. If I am wrong,
> please tell me :-).
> 
> In Section 5.3:
> 
> SOFTWARE_VERSION: A single value element containing a US-ASCII
>  string that identifies the manufacture, model, operating system
>  information and the version of the software.  Given that there are
>  very large number of peers in some networks, and no peer is likely
>  to know all other peer’s software, this information may be very
>  useful to help determine if the cause of certain groups of
>  misbehaving peers is related to specific software versions.  While
>  the format is peer-defined, a suggested format is as follows:
>  "ApplicationProductToken (Platform; OS-or-CPU) VendorProductToken
>  (VendorComment)".  For example: "MyReloadApp/1.0 (Unix; Linux
>  x86_64) libreload-java/0.7.0 (Stonyfish Inc.)".  The string is a
>  C-style string, and MUST be delimited by "\0".
> 
> Did you mean "terminated"? I don't see what can be delimited, as this
> implies presence of multiple fields.
> 
>  "\0" MUST NOT be
>  included in the string itself to prevent confusion with the
>  delimiter.
> 
> 
> 
> EWMA_BYTES_SENT (32 bits): A single value element containing an
>  unsigned 32-bit integer representing an exponential weighted
>  average of bytes sent per second by this peer. sent = alpha x
>  sent_present + (1 - alpha) x sent where sent_present represents
>  the bytes sent per second since the last calculation and sent
>  represents the last calculation of bytes sent per second.  A
>  suitable value for alpha is 0.8.  This value is calculated every
>  five seconds.
> 
> 
> I don't understand the formula. What is "x"?
> Should the formula be on its own line for ease of understanding?
> 
> BATTERY_STATUS
> 
> This flag doesn't seem to be defined in a useful fashion. You need to at
> least provide some guidance here to insure interoperability.
> 
> In Sections 9.3-9.5: is RFC- this document or RFC 6940 (or something
> else)?
> 
> Thank you,
> Alexey
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[Gen-art] Gen-ART review of

[Ronald Bonica]

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

Document:  draft-ietf-pals-congcons-01
Reviewer:Ron Bonica
Review Date:  2015-12-15
IETF LC End Date:  2015-12-15
IETF Telechat Date:  TBD

Summary:  This document is ready for publication

In summary, draft-ietf-congcons-01:

- applies only to pseudowires that run over something other than MPLS (e.g., 
GRE)
- concludes that no additional mechanisms are needed for elastic pseudowires
- concludes that an inelastic pseudowire MAY shutdown when it experiences 
higher-than-acceptable loss, latency or jitter
- observes that that for TDM PWs, as loss rate increases, 
higher-than-acceptable loss generally occurs before the fixed-rate TDM PW could 
cause serious problems for competing congestion-responsive traffic
- Therefore, no additional mechanisms are needed for inelastic pseudowires, 
either

I see nothing objectionable in the draft. However, its scope is extremely 
limited and it conclusions are not earthshattering. Nonetheless, the work is 
sound and deserves publication.

Major Issues: None

Minor Issues: None

Editorial Issues: 

Ron Bonica


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

[Gen-art] Gen-ART Telechat Review of

[Romascanu, Dan (Dan)]

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 see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-appsawg-http-problem-02

Reviewer:  Dan Romascanu

Review Date: 12/15/15

IETF LC End Date: 12/4/15

IESG Telechat date: 12/17/15



Summary: Ready



A very useful, clear and well written document.



The only minor issue that I raised in my first review was clarified in an email 
exchange and no edits were required.



Major issues:



Minor issues:



Nits/editorial comments:


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

[Gen-art] Gen-ART Telechat Review of draft-ietf-appsawg-http-problem-02

[Romascanu, Dan (Dan)]

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 see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-appsawg-http-problem-02

Reviewer:  Dan Romascanu

Review Date: 12/15/15

IETF LC End Date: 12/4/15

IESG Telechat date: 12/17/15



Summary: Ready



A very useful, clear and well written document.



The only minor issue that I raised in my first review was clarified in an email 
exchange and no edits were required.



Major issues:



Minor issues:



Nits/editorial comments:


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

[Gen-art] Gen-ART Last Call review of draft-ietf-ippm-active-passive-04

[Brian E Carpenter]

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 see the FAQ at
.

Document: draft-ietf-ippm-active-passive-04.txt
Reviewer: Brian Carpenter
Review Date: 2015-12-16
IETF LC End Date: 2015-12-24
IESG Telechat date:

Summary: Almost ready


Minor Issue:


   We note that [I-D.chen-ippm-coloring-based-ipfpm-framework] proposes
   a method similar to [I-D.tempia-opsawg-p3m], and ippm-list discussion
   indicates [I-D.chen-ippm-coloring-based-ipfpm-framework] may be
   covered by the same IPR as [I-D.tempia-opsawg-p3m].

I suggest removing the IPR comment. It may be an issue, but not for this
draft. We generally avoid taking a position on IPR applicablity (in fact,
our lawyer tells us not to do so).

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