from:"Ralph Droms"

[Gen-art] Review of draft-ietf-nfsv4-rfc5666bis-10

2017-02-23 Thread Ralph Droms

Reviewer: Ralph Droms
Review result: Ready

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-nfsv4-rfc5666bis-10
Reviewer: Ralph Droms
Review Date: 2017-02-23
IETF LC End Date: 2017-02-07
IESG Telechat date: 2017-03-02

Summary: Ready

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

[Gen-art] Review of draft-ietf-nfsv4-rfc5666bis-09

2017-02-06 Thread Ralph Droms

Reviewer: Ralph Droms
Review result: Ready

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-nfsv4-rfc5666bis-09
Reviewer: Ralph Droms
Review Date: 2017-02-06
IETF LC End Date: 2017-02-07
IESG Telechat date: Not scheduled for a telechat

Summary: draft-ietf-nfsv4-rfc5666bis-09 is ready for publication; it
is a well-written document that I found readable and understandable
based on my basic (and, likely, quite out of date!) knowledge of ONS
RPC, XDR and NFS.

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

[Gen-art] Review of draft-ietf-nvo3-use-case-15

2017-01-06 Thread Ralph Droms

Reviewer: Ralph Droms
Review result: Ready with Nits

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-nvo3-use-case-??
Reviewer: Ralph Droms
Review Date: 2017-01-06
IETF LC End Date: 2017-01-11
IESG Telechat date: 2017-01-19

Summary: This draft is ready for publication as an Informational RFC.

Major issues: None

Minor issues: None

Nits/editorial comments: 

I found several acronyms that did not have expansions.  I recommend a
pass over the document for unexpanded acronyms..

Section 2: What is "broadcast/unknown" traffic (spec. "unknown"?);
please expand the acronym "BUM".
  The paragraph that begins with "One NVO3 network [...]" is indented
differently from the rest of the text.  Intentional or a typo?

Section 3.2: An illustrating figure for the use case described in this
section would be helpful.
  Expand acronyms "PE" and "ABSR".
  I found the text using "Option A" and "Option B" confusing.  Exactly
what are those options?

Section 5: I didn't understand the references to IaaS, PaaS and SaaS
in the summary - there are no references to those services in the body
of the document, or back pointers from the summary to relevant
preceding text.

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

[Gen-art] Review of draft-ietf-sidr-origin-validation-signaling-10

2016-12-10 Thread Ralph Droms

Reviewer: Ralph Droms
Review result: Ready

Document: draft-ietf-sidr-origin-validation-signaling-10
Reviewer: Ralph Droms
Review Date: 2016-12-10
IETF LC End Date: 2016-12-07
IESG Telechat date: 2016-12-15

Summary: This draft is ready for publication as a Proposed Standard
RFC
Note: My review of -09 is unchanged for -10

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

[Gen-art] IESG Evaluation review of draft-ietf-stox-7248bis-13

2016-11-01 Thread Ralph Droms

(Correcting revision number of reviewed document)

I am the assigned Gen-ART reviewer for draft-ietf-stox-7248bis-13.

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 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-stox-7248bis-13
Reviewer: Ralph Droms
Review Date: 2016-11-01
IETF LC End Date: 2016-10-06
IESG Telechat date: 2016-11-03

Summary: This draft is ready for publication as a Proposed Standard RFC.

Major issues: None

Minor issues: None

Nits/editorial comments: None
Thanks to the authors for addressing my editorial comments from my earlier 
review.



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

[Gen-art] IESG Evaluation review of draft-ietf-stox-7248bis-11

2016-11-01 Thread Ralph Droms

I am the assigned Gen-ART reviewer for draft-ietf-stox-7248bis-11.

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 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-stox-7248bis-11
Reviewer: Ralph Droms
Review Date: 2016-11-01
IETF LC End Date: 2016-10-06
IESG Telechat date: 2016-11-03

Summary: This draft is ready for publication as a Proposed Standard RFC.

Major issues: None

Minor issues: None

Nits/editorial comments: None
Thanks to the authors for addressing my editorial comments from my earlier 
review.



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

[Gen-art] Review of draft-ietf-stir-certificates-10

2016-11-01 Thread Ralph Droms

I am the assigned Gen-ART reviewer for draft-ietf-stir-certificates-10.
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-stir-certificates-10
Reviewer: Ralph Droms
Review Date: 2016-11-01
IETF LC End Date: 2016-11-01
IESG Telechat date: N/A

Summary: This draft is ready for publication as a Proposed Standard RFC.

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

[Gen-art] Gen-ART IETF Last Call review for draft-ietf-stox-7248bis-12

2016-10-21 Thread Ralph Droms

I am the assigned Gen-ART reviewer for draft-ietf-stox-7248bis-12. 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-stox-7248bis-12
Reviewer: Ralph Droms
Review Date: 2016-10-21
IETF LC End Date:  2016-10-06
IESG Telechat date: 2016-11-03

Summary: Ready for publication as a Proposed Standard

I apologize for the late submission of this review.

I am not well-versed in either SIP or XMPP, so I could only give the
technical content of the document a cursory review.  I found no
issues to report in that review.

I'll make two small editorial suggestions:

1) There are possibly anachronistic references to "this series" of
documents.  The members of that "series" will be less obvious with the
publication of rfc7248bis.  It would likely be helpful to list the
members of the document series explicitly.

2) It might be useful to add a short section on the history of the
document, to give readers of this document an understanding of the
motivation for the publication of 7248bis.

- Ralph Droms

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

[Gen-art] Review of draft-ietf-pals-rfc4447bis-05.txt

2016-09-28 Thread Ralph Droms

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 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Each review must include a summary statement chosen from or adapted from the 
following list:

This draft is ready for publication as a Standards Track RFC.

I have only two small editorial comments:

Figure 2 appears to be missing a couple of backslashes in the ASCII art drawing.

The sentence "This document has been written to address errata in a previous 
version of this standard.” probably ought to be moved to section 2.  A broader 
statement in the Abstract to the effect that this document is a rewrite of RFC 
4447 for publication as an Internet Standard might be more helpful.

- Ralph

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

Re: [Gen-art] Review of draft-ietf-tram-turn-server-discovery-08

2016-09-01 Thread Ralph Droms

RI just completed a quick review of draft-ietf-tram-turn-server-discovery-08.  
The DNS Service Discovery section is much improved.  I have a couple of 
comments on the revised text:

I suggest adding a reference to the IANa "Service Name and Transport Protocol 
Port Number Registry", 
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=Turn,
 as the source of the service  names "turn" and "turns".

While the example DNS records for "exampleco TURN Server" are technically 
correct, they would most likely be generated by the DNS-SD/mDNS library in a 
server, rather than appearing in a DNS server zone file somewhere.  For 
clarity, it might be better to use the unicast DNS versions of the DNS-SD 
records by substituting "example.com" for "local".

In my opinion, the details in section 5.1 are redundant with and (possibly) not 
identical to the specification in RFC 6762 and RFC 6763.  Specifically, Figure 
1 includes a typo; there should be separate A/ query and reply messages.  
More generally, DNS-SD/mDNS servers may return the SRV, TXT, A and  records 
in the first reply, as an optimization.  I think it would be better, in this 
document, to specify simply that TURN servers and clients use the message 
exchanges specified in those RFCs for TURN server discovery.  

- Ralph

> On Sep 1, 2016, at 4:05 AM, Jari Arkko  wrote:
> 
> Ralph, Tiru — thanks for the updates and the review. I’ve looked at the 
> change draft and I think it is fine now.
> 
> Jari
> 
> 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-tram-turn-server-discovery-08

2016-08-17 Thread Ralph Droms

Tiru - thanks for advising me of your responses to the points in my review.

Do you and the other authors have any thoughts about my recommendations for 
section 5?

- Ralph

> On Aug 17, 2016, at 11:24 AM 8/17/16, Tirumaleswar Reddy (tireddy) 
> <tire...@cisco.com> wrote:
> 
> Hi Ralph,
> 
> Thanks for the review. Please see inline.
> 
>> -----Original Message-
>> From: Ralph Droms [mailto:rdroms.i...@gmail.com 
>> <mailto:rdroms.i...@gmail.com>]
>> Sent: Wednesday, August 10, 2016 2:58 AM
>> To: Review Area gen-art@ietf.org <mailto:gen-art@ietf.org> Team 
>> <gen-art@ietf.org <mailto:gen-art@ietf.org>>
>> Cc: draft-ietf-tram-turn-server-discovery@ietf.org 
>> <mailto:draft-ietf-tram-turn-server-discovery@ietf.org>; IETF discussion 
>> list
>> <i...@ietf.org <mailto:i...@ietf.org>>
>> Subject: Review of draft-ietf-tram-turn-server-discovery-08
>> 
>> 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 resolve these comments along with any other Last Call
>> comments you may receive.
>> 
>> For more information, please see the FAQ at
>> 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Document: draft-ietf-tram-turn-server-discovery-08
>> Reviewer: Ralph Droms
>> Review Date: 2016-08-09
>> IETF LC End Date: 2016-08-11
>> IESG Telechat date: unknown
>> 
>> 
>> Summary:
>> 
>> This draft is on the right track but has open issues, described in the 
>> review.
>> 
>> The draft is well-written and appears to be ready for publication, except as
>> noted below.
>> 
>> Major issues:
>> 
>> Section 5, DNS Service Discovery, includes more details about DNS Service
>> Discovery (DNS-SD) than is necessary for this specification.
>> While it can be useful to repeat some specific details of another 
>> specification
>> for, there is a danger in writing too many details that may not be entirely 
>> in
>> agreement with the published specification.  In the case of this document, I
>> suggest that section 5 be rewritten to just refer to DNS Service discovery, 
>> with
>> a minimum of explanation.
>> The example is useful ... although I think some of the details in the example
>> ought to be changed.  The use of DNS-SD over unicast DNS and multicast DNS
>> can be mentioned in a sentence somewhere in section 5, as the use of DNS-SD
>> is otherwise identical.  I would leave out section 5.1 altogether.
>> 
>> Looking at the IANA "Service Name and Transport Protocol Port Number
>> Registry"
>> > port-numbers.xhtml>,
>> I see that TURN is registered as using service name "turn", rather than
>> "turnserver" as in the example.  Also in the example, the instance name
>> "example.com" might be problematic, as the instance is usually just a single
>> label.  In fact, I interpret the text in the document to describe the 
>> instance
>> name as a single label.  It might be worth experimenting to see how DNS-SD
>> libraries deal with a label like "example.com", or perhaps simply change
>> instance in the example to something like "exampleco TURN Server"
> 
> Changed to "exampleco TURN Server" and used service names "turn" and "turns".
> 
>> 
>> Minor issues:
>> 
>> Section 5 mentions the use of a TXT record to carry additional information
>> about the TURN service instance.  Are there any conventions for the
>> name/value pairs carried in the TXT record?
> 
> No conventions.
> 
>> If not, I think there should be a
>> note that any name/value pairs in the TXT record are left to local 
>> definition.
> 
> Okay, added following line:
> The TXT record can contain any key/value pairs left to the local definition.
> 
>> 
>> Editorial issues:
>> 
>> I suggest using the example.com <http://example.com/> domain rather than 
>> local in the example for
>> clarity.  Perhaps also change the intro sentence for the example:
>> 
>> OLD:
>> For example, TURN server advertises the following DNS records :
>> NEW:
>> For example, the following DNS records would be used for a TURN server with
>> instance name "exampleco TURN Server" providing TURN service over UDP on
>> port 5030:
> 
> Updated.
> 
>> 
>> 
>> It would help readability if the columns in the

[Gen-art] Review of draft-ietf-tram-turn-server-discovery-08

2016-08-09 Thread Ralph Droms

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 resolve these comments along with
any other Last Call comments you may receive.

For more information, please see the FAQ at

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

Document: draft-ietf-tram-turn-server-discovery-08
Reviewer: Ralph Droms
Review Date: 2016-08-09
IETF LC End Date: 2016-08-11
IESG Telechat date: unknown


Summary:

This draft is on the right track but has open issues, described in the
review.

The draft is well-written and appears to be ready for publication,
except as noted below.

Major issues:

Section 5, DNS Service Discovery, includes more details about DNS
Service Discovery (DNS-SD) than is necessary for this specification.
While it can be useful to repeat some specific details of another
specification for, there is a danger in writing too many details that
may not be entirely in agreement with the published specification.  In
the case of this document, I suggest that section 5 be rewritten to
just refer to DNS Service discovery, with a minimum of explanation.
The example is useful ... although I think some of the details in the
example ought to be changed.  The use of DNS-SD over unicast DNS and
multicast DNS can be mentioned in a sentence somewhere in section 5,
as the use of DNS-SD is otherwise identical.  I would leave out
section 5.1 altogether.

Looking at the IANA "Service Name and Transport Protocol Port Number
Registry"
,
I see that TURN is registered as using service name "turn", rather
than "turnserver" as in the example.  Also in the example, the
instance name "example.com" might be problematic, as the instance is
usually just a single label.  In fact, I interpret the text in the
document to describe the instance name as a single label.  It might be
worth experimenting to see how DNS-SD libraries deal with a label like
"example.com", or perhaps simply change instance in the example to
something like "exampleco TURN Server"

Minor issues:

Section 5 mentions the use of a TXT record to carry additional information 
about the TURN service instance.  Are there any conventions for the name/value 
pairs carried in the TXT record?  If not, I think there should be a note that 
any name/value pairs in the TXT record are left to local definition.

Editorial issues:

I suggest using the example.com domain rather than local in the example for 
clarity.  Perhaps also change the intro sentence for the example:

OLD:
 For example, TURN server advertises the following DNS records :
NEW:
 For example, the following DNS records would be used for a TURN server with 
instance name "exampleco TURN Server" providing TURN service over UDP on port 
5030:


It would help readability if the columns in the DNS records in the example 
could be lined up; something like (apologies if your mail reader changes the 
column alignments and if I don't have the quoting right):

_turnserver._udp.local.
PTR "exampleco TURN Server"._turn._udp.local.

"exampleco TURN Server"._turn._udp.local.
SRV 0 0 5030 example-turn-server.local.

example-turn-server.local.
A   198.51.100.2

example-turn-server.local.
2001:db8:8:4::2

Similarly, it would help readability if the list of DNS records for S-NAPTR 
resolution were formatted in aligned columns.

In section 3, does "on top of" mean "in addition to" or "instead of"?



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-Art review of draft-holmberg-dispatch-rfc7315-updates

2016-07-12 Thread Ralph Droms


> On Jul 12, 2016, at 7:41 AM 7/12/16, Christer Holmberg 
>  wrote:
> 
> Hi Ralph,
> 
> Thanks for your comments! Please see inline.
> 
> Minor issues:
> 
> > I had some difficulty unraveling the relationship among the text in section 
> > 3.3.2, 3.3.3, 4 and RFC 7315.  Section 3.3.2 specifies the
> > inclusion of the NPLI option in the P-Access-Network-Info header field.  
> > Section 4 does not include text about the NPLI option in the
> > updates to RFC 7315, and I can't find any reference to the NPLI option in 
> > RFC 7315.  Is the intention that the text in section 3.3.2
> > constitutes new Internet Standard behavior, not reflected in the update to 
> > RFC 7315, am I missing something or am I completely confused?
> 
> Sections 3.3.2 and 3.3.3 describe the 3GPP use-cases which justify the 
> changes to RFC 7315. Section 4 defines those changes.
> 
> Section 4 then defines the changes to RFC 7315, in order to support those 
> use-cases.
> 
> RFC 7315 (Annex A) does talk about the possibility for network provided 
> location information, and the ABNF supports it, but the details of the 
> network provided location information (and the other types of location 
> information) are defined in the 3GPP specification.
> 
> > Section 3.3.3 specifies the inclusion of the IOI option in the 
> > P-Charging-Vector header field.  In this case, I am not sure if this 
> > specification represents a change to  existing text in RFC 7315 or new 
> > behavior.
> 
> Section 3.3.3 (and 3.3.2) does not update RFC 7315. Section 3.3.3 only 
> provides the use-case/justification for the update. The update to RFC 7315 is 
> specified in section 4.
> 
> > I would be happy to hear that I am completely confused; otherwise, I 
> > suggest some text be added to clarify that sections 3.3.2 and 3.3.3 also 
> > specify some behaviors in addition to explaining the text in section 4.
> 
> Does my clarification above clarify?

Yes.  I had missed that 3.3.2 and 3.3.3 come from 3GPP.  The doc makes perfect 
sense to me now.

Thanks for the clarification and I think the doc is ready for publication 
considering our agreement on the editorial nits.

- Ralph

> 
> 
> Nits/editorial comments:
> 
> > In section 3.2, it would reduce potential confusion to consistently name 
> > the header field referenced in each bullet; e.g.:
> >
> > OLD:
> >
> > o  P-Called-Party-ID: Delete statement that the header field can
> >appear in SIP responses.  Add statement that the P-Called-Party-ID
> >header field can appear in the SIP REFER method.
> >
> > NEW:
> >
> > o  P-Called-Party-ID: Delete statement that the P-Called-Party-ID
> >header field can appear in SIP responses.  Add statement that
> >the P-Called-Party-ID header field can appear in the SIP REFER method.
> 
> I’ll fix as suggested.
> 
> >Section 3.3.1:
> >
> >OLD:
> >
> >This following sections describe, for individual P- header fields,
> > the 3GPP use-cases that are base for the updates.
> >
> >NEW:
> >
> > The following sections describe, for individual P- header fields,
> > the 3GPP use-cases that are the basis for the updates.
> 
> I’ll fix as suggested.
> 
> > Section 3.3.2: uniformly capitalize "Network Provided Location Information".
> 
> I’ll fix as suggested.
> 
> > Section 3.3.2: 3GPP TS 23.228 needs a citation of the referenced document.
> 
> I’ll add the reference.
> 
> 
> Thanks!
> 
> Regards,
> 
> Christer
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-Art review of draft-holmberg-dispatch-rfc7315-updates

2016-07-05 Thread Ralph Droms

I am the assigned Gen-ART reviewer for this draft. The General AreaReview Team (Gen-ART) reviews all IETF documents being processedby the IESG for the IETF Chair.  Please treat these comments justlike any other last call comments.For more information, please see the FAQ at.Document: draft-holmberg-dispatch-rfc7315-updates-07Reviewer: Ralph DromsReview Date: 2016-07-05IETF LC End Date: 2016-07-18IESG Telechat date: Summary: This draft is basically ready for publication, but has nits that should be fixed before publication.Major issues: NoneMinor issues:I had some difficulty unraveling the relationship among the text in section 3.3.2, 3.3.3, 4 and RFC 7315.  Section 3.3.2 specifies the inclusion of the NPLI option in the P-Access-Network-Info header field.  Section 4 does not include text about the NPLI option in the updates to RFC 7315, and I can't find any reference to the NPLI option in RFC 7315.  Is the intention that the text in section 3.3.2 constitutes new Internet Standard behavior, not reflected in the update to RFC 7315, am I missing something or am I completely confused?Section 3.3.3 specifies the inclusion of the IOI option in the P-Charging-Vector header field.  In this case, I am not sure if this specification represents a change to  existing text in RFC 7315 or new behavior.I would be happy to hear that I am completely confused; otherwise, I suggest some text be added to clarify that sections 3.3.2 and 3.3.3 also specify some behaviors in addition to explaining the text in section 4.Nits/editorial comments:In section 3.2, it would reduce potential confusion to consistently name the header field referenced in each bullet; e.g.:OLD:  o  P-Called-Party-ID: Delete statement that the header field can appear in SIP responses.  Add statement that the P-Called-Party-ID header field can appear in the SIP REFER method.NEW:  o  P-Called-Party-ID: Delete statement that the P-Called-Party-ID header field can appear in SIP responses.  Add statement that the P-Called-Party-ID header field can appear in the SIP REFER method.Section 3.3.1:OLD:  This following sections describe, for individual P- header fields,  the 3GPP use-cases that are base for the updates.NEW:  The following sections describe, for individual P- header fields,  the 3GPP use-cases that are the basis for the updates.Section 3.3.2: uniformly capitalize "Network Provided Location Information".Section 3.3.2: 3GPP TS 23.228 needs a citation of the referenced document.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-idr-ix-bgp-route-server-10

2016-06-08 Thread Ralph Droms

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 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>>.

Document: draft-ietf-idr-ix-bgp-route-server-10
Reviewer: Ralph Droms
Review Date: 2016-06-08
IETF LC End Date: ?
IESG Telechat date: 2016-06-16

Summary: This draft is ready for publication as a Proposed Standard RFC.

Major issues: None

Minor issues: None

Nits/editorial comments: None




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-aqm-eval-guidelines-11

2016-05-21 Thread Ralph Droms (rdroms)


> On May 18, 2016, at 9:29 PM 5/18/16, Jari Arkko  wrote:
> 
> Thanks for your review, Ralph!

You're welcome.  I'm glad to hear you found the review valuable.

Responses in line...

> 
> I do think some of the points you raised need to be addressed. Inline:
> 
>> 
>> #
>> 
>> I often react to the use of RFC 2119 language in an Informational document 
>> by asking is that language really necessary?  I'll ask the question here: in 
>> the context of this Informational document, which appears to be entirely 
>> advisory in providing guidelines, what does the use of RFC 2119 
>> "requirements language" add to the meaning of the document.
>> 
 Authors: Indeed, the use of RFC 2119 language is not mandatory for such 
 information document. However, using it enables us to introduce weight in 
 the different parameterizations of the tests. Even though, it is not 
 mandatory, we believe that it eases the reading of the document, for 
 someone familiar with the IETF wording.
> 
> I think that’s right.

OK.

>> #
>> 
>> Figure 1 is not clear to me.  Where are the physical links and interfaces?  
>> Are there multiple physical senders and receivers or are "senders A" 
>> instantiated on a single host (does it make a difference)?  Are there 
>> static-sized buffers for each interface or do all the buffers share one 
>> memory space?
>> 
 Authors: We acknowledge that Figure 1 is not very clear. We have 
 voluntarily omitted precisions on the amount of senders, receivers and 
 traffic classes since the instantiation on a specific testbed would remove 
 the generality of the figure and the described architecture. We believe 
 that the text helps in reading the figure. Also, the rationale of this 
 figure is to explain the notation more than going deeper in the topology 
 that is anyway very generic.
> 
> My opinion is that Figure 1 was very hard to read, even with reading the 
> text. I’d like to see some improvement in either the text or the figure.

I can understand that the figure might be an illustrative abstraction, but I 
still think it would be helpful to have more detail in the text and some 
restructuring of the figure.

>> #
>> 
>> In section 3.1, is there a need to say something about the relative 
>> capacities of the various links and the rates at which the various flows 
>> generate traffic?
>> 
 Authors: These capacities are described in a later section when needed, 
 and to remain high level and not focus on any applicability context 
 (wi-fi, rural satellite access, fibber access, etc.) they are not 
 specified for the whole document. The rates at which the flows generate 
 traffic is specified for each further described scenario.
> 
> OK

OK

>> #
>> 
>> I would have trouble following the guidelines set out in section 4.3.1.  I 
>> can understand the need for consideration of the tunable control parameters 
>> when comparing different AQM schemes.  However, I don't know what 
>> "comparable" means for control parameters that are likely quite different 
>> between AQM schemes.  I also think one would want to compare optimal control 
>> settings for the different schemes, to compare best-case performance.  Or, 
>> for AQM schemes whose performance is highly dependent on operational 
>> conditions, one might want to compare settings that are sub-optimal for any 
>> particular test condition but that give better performance over a wide range 
>> of conditions.
>> 
 Authors: The intent of the first recommendation is to make testers be 
 aware of which control points control which behavior and be conscious to 
 make apples to apples comparison.
>> To further precise this, we could change the text is section 4.3.1 as 
>> follows :
>> "1. Similar control parameters and implications: Testers should be aware of 
>> the control parameters of the different schemes that control similar 
>> behavior. Testers should also be aware of the input value ranges and 
>> corresponding implications. For example, consider two different schemes - 
>> (A) queue-length based AQM scheme, and (B) queueing-delay based scheme. A 
>> and B are likely to have different kinds of control inputs to control the 
>> target delay - target queue length in A vs. target queuing delay in B, for 
>> example. Setting parameter values such as 100MB for A vs. 10ms for B will 
>> have different implications depending on evaluation context.  Such 
>> context-dependent implications must be considered before drawing conclusions 
>> on performance comparisons. Also, it would be preferable if an AQM proposal 
>> listed such parameters and discussed how each relates to network 
>> characteristics such as capacity, average RTT etc.”
> 
> OK for me

I think the suggested text is OK, too.

>> #
>> 
>> Section 4.4 seems to give advice to the AQM designer rather than describe 
>> guidelines for characterization.  Section 4.4 should either be

[Gen-art] Gen-ART review of draft-ietf-aqm-eval-guidelines-11

2016-04-28 Thread Ralph Droms (rdroms)

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-aqm-eval-guidelines-11
Reviewer: Ralph Droms
Review Date: 2016-04-28
IETF LC End Date: 2016-05-04
IESG Telechat date: 2016-05-19

Summary: This draft is on the right track but has open issues, described in the 
review.

In general, I think the document could be read, implemented and used to 
generate useful characterizations of AQM schemes.  However, the motivations for 
some of the measurements and scenarios seems weak to me, which might compromise 
the weight given to the conclusions drawn from the guidelines.

Major issues:

None.  However, the list of minor issues and nits, taken together, could be 
considered a major issue to be resolved before publication.

Minor issues:

I often react to the use of RFC 2119 language in an Informational document by 
asking is that language really necessary?  I'll ask the question here: in the 
context of this Informational document, which appears to be entirely advisory 
in providing guidelines, what does the use of RFC 2119 "requirements language" 
add to the meaning of the document.

Figure 1 is not clear to me.  Where are the physical links and interfaces?  Are 
there multiple physical senders and receivers or are "senders A" instantiated 
on a single host (does it make a difference)?  Are there static-sized buffers 
for each interface or do all the buffers share one memory space?

In section 3.1, is there a need to say something about the relative capacities 
of the various links and the rates at which the various flows generate traffic?

I would have trouble following the guidelines set out in section 4.3.1.  I can 
understand the need for consideration of the tunable control parameters when 
comparing different AQM schemes.  However, I don't know what "comparable" means 
for control parameters that are likely quite different between AQM schemes.  I 
also think one would want to compare optimal control settings for the different 
schemes, to compare best-case performance.  Or, for AQM schemes whose 
performance is highly dependent on operational conditions, one might want to 
compare settings that are sub-optimal for any particular test condition but 
that give better performance over a wide range of conditions.

Section 4.4 seems to give advice to the AQM designer rather than describe 
guidelines for characterization.  Section 4.4 should either be rewritten to 
give guidelines for structuring measurements to account for varying packet 
sizes or the section should be elided.

In section 4.5, what is the motivation for giving the advice about ECN to AQM 
designers?  I can understand that ECN will have affect the impact of AQM, but 
for this document I think the section should focus on measurement guidlines 
that account for that impact.

The specific topology in section 10 does not seem well-motivated to me.  Why is 
router R with no AQM included in the topology?  The choice of measurements is 
similarly not well-motivated.  Why would it not be of interest to run all the 
tests described earlier in the document?

Nits/editorial comments:

There are several instances of the word "advice" which should be replaced with 
"advise"; e.g., in section 2.3.

Last sentence of the abstract: I don't get the meaning of "precautionary 
characterizations of AQM schemes".  I recommend that the phrase be reworded

Section 1, first paragraph: The last sentence doesn't follow the rest of the 
paragraph and I recommend that it be elided.

Section 1, third paragraph: This text is redundant with the text in the 
Glossary section:

   When speaking of a specific queue in this
   document, "buffer occupancy" refers to the amount of data (measured
   in bytes or packets) that are in the queue, and the "maximum buffer
   size" refers to the maximum buffer occupancy.

Section 1, third paragraph:

OLD:

   In real
   implementations of switches, a global memory is often shared between
   the available devices, and thus, the maximum buffer size may vary
   over the time.

NEW:

   In switches and routers, a global memory space is often shared
   between the available interfaces, and thus, the maximum buffer size
   for any given interface may vary over the time.

Section 1, fifth paragraph, last sentence: Is this document just concerned with 
"deployability" or more generally with "applicability, performance and 
deployability"?

Section 1.1, first paragraph: Would it be helpful to qualify "goodput" as 
"goodput in individual flows", to contrast with "goodput at a router"?  If 
"goodput"

[Gen-art] Gem-Art review of draft-ietf-lager-specification-11

2016-04-19 Thread Ralph Droms (rdroms)

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 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>>.

Document: draft-ietf-lager-specification-11
Reviewer: Ralph Droms
Review Date: 2016-04-19
IETF LC End Date: 2016-04-11
IESG Telechat date: (if known) 2016-04-21

Summary: This draft is ready for publication as a Standards Track RFC.

Major issues: None

Minor issues: None

Nits/editorial comments: While this document is long and detailed, I found it 
to be clear and well-written.  I can't say I fully understand all the details 
and nuances after my review, but I'm confident that an implementor could gain 
the necessary understanding from careful reading of the document.  I did find 
what I considered to be a couple of small typos, which I'm confident the RFC 
Editor will find and correct if necessary.






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review of draft-sparks-genarea-mailarch-improvements-02

2016-03-10 Thread Ralph Droms

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

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

Document: draft-sparks-genarea-mailarch-improvements-02
Reviewer: Ralph Droms
Review Date: 2016-03-09
IETF LC End Date: 2016-02-18
IESG Telechat date: (if known): 2016-03-03

Summary: Ready for publication

Major issues: None

Minor issues: None

Nits/editorial comments: Reviewer's tardiness
I recognize I am late with this review; in fact, not just late, but I'm posting 
this review after it has been accepted for publication.  I was confused about 
the due date.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review of draft-ietf-netmod-yang-json-08

2016-03-10 Thread Ralph Droms

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 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>>.

Document: draft-ietf-netmod-yang-json-08
Reviewer: Ralph Droms
Review Date: 2016-03-10
IETF LC End Date: 2016-03-10
IESG Telechat date: (if known)

Summary: This draft is ready for publication as a Standards Track RFC


Major issues: None

Minor issues: None

Nits/editorial comments: None


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gem-Art review for draft-ietf-httpauth-scram-auth-14

2016-01-05 Thread Ralph Droms (rdroms)

Confirming that rev -15 addresses my Gen-ART review comments...

- Ralph

> On Dec 16, 2015, at 11:19 AM 12/16/15, Ralph Droms (rdroms) 
> <rdr...@cisco.com> wrote:
> 
> 
>> On Dec 16, 2015, at 10:47 AM 12/16/15, Alexey Melnikov 
>> <alexey.melni...@isode.com> wrote:
>> 
>> Hi Ralph,
>> Thank you for your review. Sorry I missed it earlier.
> 
> You're welcome.  Looks like we have agreement on my editorial comments and 
> suggestions.  Will the edits you mention below appear in rev -15?
> 
> - Ralph
> 
>> 
>> On 09/12/2015 20:47, Ralph Droms (rdroms) wrote:
>>> Nits/editorial comments:
>>> 
>>> Nicely written, very clear document.
>> Thank you.
>>> idnits reports some lines too long and an unused reference.
>> I fixed the reference in my copy. I hope RFC Editor can help with lines 
>> which are too long.
>>> In the third paragraph of the Introduction, I suggest removing the 
>>> parentheses and editing the second sentence for clarity; specifically, what 
>>> is "SCRAM data"?
>> I meant SCRAM requests and responses.
>>> You could probably omit the parentheses in the second paragraph of Setion 
>>> 3, as well, I'm likely just arguing style.
>> Barry picked on this as well, so this was rewritten for clarity.
>>> The last sentence of the last paragraph of sectino 3 was unclear to me: 
>>> which messages are referred to?
>> Message is the same as 'decoded "data" attribute' in the previous sentence. 
>> I clarified that.
>>> I think, in the phrase "fail the authentication" in the fifth paragraph of 
>>> section 8, you are using "fail" as a transitive verb, as in "the client 
>>> considers the authentication of the message to have failed"
>> ... and does whatever is appropriate in this case. Which might be closing 
>> the connection, retrying or trying another (non SCRAM) mechanism.
>>> .  If I have that write, I suggest rewriting the containing sentence to 
>>> improve the clarity.
>> 
>> Best Regards,
>> Alexey
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

2015-12-16 Thread Ralph Droms (rdroms)


> On Dec 7, 2015, at 1:31 PM 12/7/15, Stephane Bortzmeyer <bortzme...@nic.fr> 
> wrote:
> 
> On Tue, Dec 01, 2015 at 01:55:46PM +0000,
> Ralph Droms (rdroms) <rdr...@cisco.com> wrote
> a message of 128 lines which said:
> 
>> Would you consider adding a little text somewhere to make it clear
>> that the Appendix is intended as a guide to implementors?
> 
> Done,
> <https://github.com/bortzmeyer/my-IETF-work/commit/b768c43ab0624ec9cc8361d221a27058b64b19a2>
> 
>> My recommendation to improve the document would be the inclusion of
>> another appendix, describing the algorithm to use if zone cuts are
>> known.
> 
> It already exists, this is the second paragraph of section 2. (The
> ideal case.)

For the inexperienced implementor, a little more detail might be useful.

> But I do not find useful to add more text: for a real resolver, the
> algorithm in appendix A suffices (it works if the zone cuts are known,
> see step 1).
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gem-Art review for draft-ietf-httpauth-scram-auth-14

2015-12-16 Thread Ralph Droms (rdroms)


> On Dec 16, 2015, at 10:47 AM 12/16/15, Alexey Melnikov 
> <alexey.melni...@isode.com> wrote:
> 
> Hi Ralph,
> Thank you for your review. Sorry I missed it earlier.

You're welcome.  Looks like we have agreement on my editorial comments and 
suggestions.  Will the edits you mention below appear in rev -15?

- Ralph

> 
> On 09/12/2015 20:47, Ralph Droms (rdroms) wrote:
>> Nits/editorial comments:
>> 
>> Nicely written, very clear document.
> Thank you.
>> idnits reports some lines too long and an unused reference.
> I fixed the reference in my copy. I hope RFC Editor can help with lines which 
> are too long.
>> In the third paragraph of the Introduction, I suggest removing the 
>> parentheses and editing the second sentence for clarity; specifically, what 
>> is "SCRAM data"?
> I meant SCRAM requests and responses.
>> You could probably omit the parentheses in the second paragraph of Setion 3, 
>> as well, I'm likely just arguing style.
> Barry picked on this as well, so this was rewritten for clarity.
>> The last sentence of the last paragraph of sectino 3 was unclear to me: 
>> which messages are referred to?
> Message is the same as 'decoded "data" attribute' in the previous sentence. I 
> clarified that.
>> I think, in the phrase "fail the authentication" in the fifth paragraph of 
>> section 8, you are using "fail" as a transitive verb, as in "the client 
>> considers the authentication of the message to have failed"
> ... and does whatever is appropriate in this case. Which might be closing the 
> connection, retrying or trying another (non SCRAM) mechanism.
>> .  If I have that write, I suggest rewriting the containing sentence to 
>> improve the clarity.
> 
> Best Regards,
> Alexey
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gem-Art review for draft-ietf-httpauth-scram-auth-14

2015-12-09 Thread Ralph Droms (rdroms)

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-httpauth-scram-auth-14
Reviewer: Ralph Droms
Review Date: 2015-13-9
IETF LC End Date: 2015-12-16
IESG Telechat date: (if known)

Summary: This draft is ready for publication as an Experimental RFC.

Major issues: None.

Minor issues: None.

Nits/editorial comments:

Nicely written, very clear document.

idnits reports some lines too long and an unused reference.

In the third paragraph of the Introduction, I suggest removing the parentheses 
and editing the second sentence for clarity; specifically, what is "SCRAM data"?

You could probably omit the parentheses in the second paragraph of Setion 3, as 
well, I'm likely just arguing style.

The last sentence of the last paragraph of sectino 3 was unclear to me: which 
messages are referred to?

I think, in the phrase "fail the authentication" in the fifth paragraph of 
section 8, you are using "fail" as a transitive verb, as in "the client 
considers the authentication of the message to have failed".  If I have that 
write, I suggest rewriting the containing sentence to improve the clarity.






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

2015-12-01 Thread Ralph Droms (rdroms)


> On Nov 26, 2015, at 7:41 AM 11/26/15, Stephane Bortzmeyer <bortzme...@nic.fr> 
> wrote:
> 
> On Fri, Nov 20, 2015 at 04:22:21PM +0000,
> Ralph Droms (rdroms) <rdr...@cisco.com> wrote
> a message of 97 lines which said:
> 
>> I am the assigned Gen-ART reviewer for
>> draft-ietf-dnsop-qname-minimisation-07.txt.
> 
> Hello. Glad to have reviewers.

This document is well-written and easy to read.  It's a pleasure to do the 
review.

> 
>> Has the working group considered publishing this document as
>> "Informational" rather than "Experimental"?  If the document is
>> published as "Experimental", is the intention to publish a
>> subsequent proposed standard or BCP?
> 
> [See Tim's answer.]

OK.

> 
>> I found the descriptions in the document understandable, but not
>> quite detailed enough to build an interoperable implementation.
> 
> There is something very important about qname minimisation: it is a
> local technique, not a protocol. It works with unmodified authoritative
> name servers. So "interoperability" is not a concern because it does
> not change the DNS protocol. Consequence: each resolver MAY implement
> it slightly differently (see appendix B).

OK, I understand this is a local technique and does not represent a change to 
the DNS protocols.  Even so, in my opinion there are some details that are not 
provided in the document (see below).

>> Is Appendix A intended as the specification for the QNAME
>> minimization techniques described in this document?
> 
> No. That's why it's in an appendix. Most resolvers already can find
> the zone cuts (they need it to do DNSSEC), this appendix is to give
> ideas to developers of the other resolvers.

Would you consider adding a little text somewhere to make it clear that the 
Appendix is intended as a guide to implementors?

>> The appendix is titled "An algorithm to find the zone cut" and the
>> introductory text indicates the algorithm is intended for locating
>> the zone cut.  However, as I read the algorithm, it finds and
>> traverses all zone cuts until the original QNAME can be resolved.
> 
> The title may be misleading. What about "An algorithm to perform QNAME
> minimisation in presence of zone cuts?"

Perhaps "unknown zone cuts"?  Otherwise, that title sounds good.

My recommendation to improve the document would be the inclusion of another 
appendix, describing the algorithm to use if zone cuts are known.  In my 
opinion, what's missing from the document for an inexperienced implementor is a 
summary of how to build the resolver you refer to in section 2: "The minimising 
resolver works perfectly when it knows the zone cut"

>> In section 2, is the phrase "closest known parent of the original
>> QNAME" something that most DNS developers would understand?
> 
> Well, "parent" could be misleading because it is rather "ancestor"
> (the example in the draft show a grand-parent).
> 
>> Would the phrase "closest enclosing NS RRset" from Appendix A be
>> more precise?
> 
> "Known" is very important here. What about "closest known enclosing NS
> RRset"?

OK, that text would be good.

>> I wasn't sure at first whether "(section 6)" in the 4th paragraph of
>> section 2 referred to section 6 of RFC 2181 or section 6 of this
>> document.
> 
> OK, fixed in my local copy.

Great.

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

2015-11-23 Thread Ralph Droms


> On Nov 23, 2015, at 9:01 AM 11/23/15, Tim Wicinski <tjw.i...@gmail.com> wrote:
> 
> Ralph
> 
> Thanks for the detailed review. Commeinline
> 
> On 11/20/15 11:22 AM, Ralph Droms (rdroms) wrote:
>> 
>> I am the assigned Gen-ART reviewer for 
>> draft-ietf-dnsop-qname-minimisation-07.txt.
>> 
>> For background on Gen-ART, please see the FAQ at 
>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>> 
>> Please resolve these comments along with any other Last Call comments you 
>> may receive.
>> 
>> 
>> Document: draft-ietf-dnsop-qname-minimisation-07
>> Reviewer: Ralph Droms
>> Review Date: 2015-11-20
>> IETF LC End Date: 2015-11-23
>> IESG Telechat date: unknown
>> 
>> Summary:
>> 
>> This draft is on the right track but has open issues, described in the 
>> review.
>> 
>> Major issues:
>> 
>> The document is well-written and easy to understand.  Thank you.
>> 
>> Has the working group considered publishing this document as "Informational" 
>> rather than "Experimental"?  If the document is published as "Experimental", 
>> is the intention to publish a subsequent proposed standard or BCP?
>> 
> 
> The WG has considered several options. I believe we settled on "Experimental" 
> because passing the entire QNAME all the way to the root servers has always 
> existed, and it was unclear what unintended consequences would happen if this 
> was deployed.
> 
> We do plan  on producing a Standards Track document.

OK, glad to hear the WG thought through the alternatives.
> 
>> In my opinion, the document needs a little more work if it is to be 
>> published as "Experimental", especially if the intention is to publish a 
>> proposed standard based on the results of experiments with the techniques 
>> described in this document.  I found the descriptions in the document 
>> understandable, but not quite detailed enough to build an interoperable 
>> implementation.
>> 
> 
> Do you have anything in particular on details?  I can revisit with the 
> authors on this.

In my opinion, the document provides a collection of techniques but doesn't 
explicitly define a specific, testable mechanism to implement.  (continued 
below)

>> Is Appendix A intended as the specification for the QNAME minimization 
>> techniques described in this document?  The appendix is titled "An algorithm 
>> to find the zone cut" and the introductory text indicates the algorithm is 
>> intended for locating the zone cut.  However, as I read the algorithm, it 
>> finds and traverses all zone cuts until the original QNAME can be resolved.

   Here is the text I would focus on if I were writing an implementation:

   A resolver which implements QNAME minimisation, [...],
   sends a request to the name
   server authoritative for the closest known parent of the original
   QNAME.

   [...]

   The minimising resolver works perfectly when it knows the zone cut
   [RFC2181] (section 6). [...] (Appendix A describes this algorithm
   in deeper details.)

As I wrote in my review, it appears to me that Appendix A gives a specification 
of the resolver behavior.  If that's the case, it would be helpful to make that 
explicit statement in section 2.

>> If Appendix A is not the specification for the QNAME minimization 
>> techniques, then I don't know exactly what specific behavior or algorithm is 
>> referred to by "minimising resolver" in this sentence from section 2: "The 
>> minimising resolver works perfectly when it knows the zone cut [...]".
>> 
>> My suggestion would be to include another algorithm description, similar to 
>> that in Appendix A, but that describes how to use knowledge of zone cuts.
>> 
> 
> OK
> 
>> Editorial
>> -
>> 
>> In section 2, is the phrase "closest known parent of the original QNAME" 
>> something that most DNS developers would understand?  Would the phrase 
>> "closest enclosing NS RRset" from Appendix A be more precise?
>> 
> 
> "closest enclosing NS RRset" may be more relevant.

OK.

> 
>> I wasn't sure at first whether "(section 6)" in the 4th paragraph of section 
>> 2 referred to section 6 of RFC 2181 or section 6 of this document.
>> 
> 
> This is RFC2181, so perhaps it can be reworded like this:
> 
>   The minimising resolver works perfectly when it knows the zone
>   cut, as described in section 6 of [RFC2181].

That wording would eliminate the confusion.

> 
> thanks
> tim



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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-dnsop-qname-minimisation-07

2015-11-20 Thread Ralph Droms (rdroms)


I am the assigned Gen-ART reviewer for 
draft-ietf-dnsop-qname-minimisation-07.txt.

For background on Gen-ART, please see the FAQ at 
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments you may 
receive.


Document: draft-ietf-dnsop-qname-minimisation-07
Reviewer: Ralph Droms
Review Date: 2015-11-20
IETF LC End Date: 2015-11-23
IESG Telechat date: unknown

Summary:

This draft is on the right track but has open issues, described in the review.

Major issues:

The document is well-written and easy to understand.  Thank you.

Has the working group considered publishing this document as "Informational" 
rather than "Experimental"?  If the document is published as "Experimental", is 
the intention to publish a subsequent proposed standard or BCP?

In my opinion, the document needs a little more work if it is to be published 
as "Experimental", especially if the intention is to publish a proposed 
standard based on the results of experiments with the techniques described in 
this document.  I found the descriptions in the document understandable, but 
not quite detailed enough to build an interoperable implementation.

Is Appendix A intended as the specification for the QNAME minimization 
techniques described in this document?  The appendix is titled "An algorithm to 
find the zone cut" and the introductory text indicates the algorithm is 
intended for locating the zone cut.  However, as I read the algorithm, it finds 
and traverses all zone cuts until the original QNAME can be resolved.

If Appendix A is not the specification for the QNAME minimization techniques, 
then I don't know exactly what specific behavior or algorithm is referred to by 
"minimising resolver" in this sentence from section 2:  "The minimising 
resolver works perfectly when it knows the zone cut [...]".

My suggestion would be to include another algorithm description, similar to 
that in Appendix A, but that describes how to use knowledge of zone cuts.

Editorial
-

In section 2, is the phrase "closest known parent of the original QNAME" 
something that most DNS developers would understand?  Would the phrase "closest 
enclosing NS RRset" from Appendix A be more precise?

I wasn't sure at first whether "(section 6)" in the 4th paragraph of section 2 
referred to section 6 of RFC 2181 or section 6 of this document.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gem-Art Last Call review of draft-ietf-dnsop-qname-minimisation-07

2015-11-20 Thread Ralph Droms (rdroms)


I am the assigned Gen-ART reviewer for 
draft-ietf-dnsop-qname-minimisation-07.txt.

For background on Gen-ART, please see the FAQ at 
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments you may 
receive.


Document: draft-ietf-dnsop-qname-minimisation-07
Reviewer: Ralph Droms
Review Date: 2015-11-20
IETF LC End Date: 2015-11-23
IESG Telechat date: unknown

Summary:

This draft is on the right track but has open issues, described in the review.

Major issues:

The document is well-written and easy to understand.  Thank you.

Has the working group considered publishing this document as "Informational" 
rather than "Experimental"?  If the document is published as "Experimental", is 
the intention to publish a subsequent proposed standard or BCP?

In my opinion, the document needs a little more work if it is to be published 
as "Experimental", especially if the intention is to publish a proposed 
standard based on the results of experiments with the techniques described in 
this document.  I found the descriptions in the document understandable, but 
not quite detailed enough to build an interoperable implementation.

Is Appendix A intended as the specification for the QNAME minimization 
techniques described in this document?  The appendix is titled "An algorithm to 
find the zone cut" and the introductory text indicates the algorithm is 
intended for locating the zone cut.  However, as I read the algorithm, it finds 
and traverses all zone cuts until the original QNAME can be resolved.

If Appendix A is not the specification for the QNAME minimization techniques, 
then I don't know exactly what specific behavior or algorithm is referred to by 
"minimising resolver" in this sentence from section 2:  "The minimising 
resolver works perfectly when it knows the zone cut [...]".

My suggestion would be to include another algorithm description, similar to 
that in Appendix A, but that describes how to use knowledge of zone cuts.

Editorial
-

In section 2, is the phrase "closest known parent of the original QNAME" 
something that most DNS developers would understand?  Would the phrase "closest 
enclosing NS RRset" from Appendix A be more precise?

I wasn't sure at first whether "(section 6)" in the 4th paragraph of section 2 
referred to section 6 of RFC 2181 or section 6 of this document.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-26 Thread Ralph Droms (rdroms)

Himanshu - I've been tied up in meetings most of the day today and am about to 
go into more meetings that will last until the end of the day.

I reviewed your revised draft briefly and it mostly looks OK.  I have one 
substantive comment, which is about an issue I didn't notice until now:

How is the Mac Withdraw sub-TLV registry from which the "Sequence Number" code 
point is taken differentiated from the LDP Parameters sub-TLV registry from 
which the "MAC List" and "MAC Flush Parameter" code points are taken?  In other 
words, how does the receciver know to interpret the code point on the Sequence 
Number TLV as a code point in the Mac Withdraw sub-TLV registry while the code 
points on the MAC List TLV and the MAC Flush Paramter TLV are interpreted as 
code points in the LDP Paramteres sub-TLV?  Shouldn't all the code points on 
the TLVs in this message come from a single registry?

I also have an editorial comment from my earlier review: the ifrst paragraph of 
section 3 is mostly redundant with section 4.1 and that text in section 3 
should be merged into the text in section 4.1

- Ralph

> On Oct 26, 2015, at 2:09 PM 10/26/15, Shah, Himanshu <hs...@ciena.com> wrote:
> 
> Thanks Andy.
> He did re-send the email without MIME and I was able to read and reply.
>  
> Thanks,
> Himanshu
>  
> From: Andrew G. Malis [mailto:agma...@gmail.com] 
> Sent: Monday, October 26, 2015 2:08 PM
> To: Shah, Himanshu
> Cc: Ralph Droms (rdroms); A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
>  
> Himanshu,
>  
> Ralph said:
>  
> Himanshu - I've received your revised draft.  I've been stuck in a variety of 
> meetings Monday and haven't had time to review it.  I should be able to look 
> at it before the end of the day.
> 
> - Ralph
>  
> On Mon, Oct 26, 2015 at 1:04 PM, Shah, Himanshu <hs...@ciena.com> wrote:
> Can you send the email without MIME signature?
>  
> Thanks,
> Himanshu
>  
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com] 
> Sent: Monday, October 26, 2015 1:02 PM
> To: Shah, Himanshu
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

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

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-26 Thread Ralph Droms (rdroms)

Himanshu - I've received your revised draft.  I've been stuck in a variety of 
meetings Monday and haven't had time to review it.  I should be able to look at 
it before the end of the day.

- Ralph

> On Oct 24, 2015, at 5:56 PM 10/24/15, Shah, Himanshu <hs...@ciena.com> wrote:
> 
> Now with the draft..
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu 
> Sent: Saturday, October 24, 2015 5:52 PM
> To: 'Ralph Droms (rdroms)'
> Cc: 'A. Jean Mahoney'; 'General Area Review Team'; 
> 'draft-ietf-pals-mpls-tp-mac-wd@ietf.org'; 'The IESG'
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> One more update that was discussed in previous emails but not included in 
> your last email -
> 
> Original text: 
>  Only half of the sequence number space is used.  Modular arithmetic
>  is used to detect wrapping of sequence number.  When sequence number
>  wraps, all MAC addresses are flushed and the sequence number is
>  reset.  The 16-bit sequence number handling is described in
>  [RFC4385]. This document uses 32-bits sequence numbers and hence
>  sequence number in half the number space (i.e. 31-bits or ~2billion)
>  is considered in the valid receive range.
> 
> [Ralph]
> This paragraph is not at all clear to me. Reading section 4 of RFC 4385 
> helped but left me unsure about how my understanding of how to extend the 
> sequence number mechanism to 32 bits corresponds to the expectations of this 
> document.
> 
> 
> [Himanshu>] 
> 
> New text:
> 
>   The lack of reliable transport protocol for the in-band OAM
>   necessitates a presence of sequencing and acknowledgement
>   scheme so that the receiver can recognize newer message from
>   retransmitted older messages. The [RFC4385] describes the details
>   of sequence number handling which includes overflow detection for
>   sequence number field of size 16-bits. This document leverages
>   the same scheme with the two exemptions
>   - sequence number field is of size 32-bits
>   - overflow detection is simplified such that sequence
> number exceed 2,147,483,647 (0x7FFF) is considered
>  overflow and reset to 1.
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu
> Sent: Saturday, October 24, 2015 4:00 PM
> To: 'Ralph Droms (rdroms)'
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> I am updating the drafts to address your comments where relevant.
> 
> Since there is too many indentations below, I am bringing you latest comments 
> here, and respond.
> 
> ---
> [ralph] What I think would improve this specification is clarification that 
> trims redundant specification details from draft-ietf-pals-mpls-tp-mac-wd and 
> cites, concisely and exactly, the other documents from which the 
> specifications are copied.
> 
> [Himanshu] Trimming where relevant.
> ---
> 
> [ralph] It wasn't obvious to me what is intended as a protocol specification 
> and what is intended as a description of the protocol.  I see that RFC 4762 
> includes text that describes how to process an empty MAC List TLV, so perhaps 
> removal of the text altogether would be best.
> 
> [Himanshu] removed the reference to empty MAC List TLV
> 
> 
> [ralph]
>> The PW OAM message header is exactly the same as what is defined in 
>> [RFC6478].
>> 
> Is this statement really true?  The MAC Address Withdraw header seems to 
> replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
> flag.  The statement might be misleading to an implementor.
> 
> [Himanshu] replaced with following text:
> "The MAC withdraw PW OAM message follows the same guidelines used in  
> [RFC6478], whereby first 4-bytes of OAM message header is followed by  
> message specific field and a set of TLVs relevant for the message"
> 
> -
> [ralph]
> I think it would be helpful to state explicitly that the Sequence Number TLV 
> MUST be the first TLV in the message.
> 
> [Himanshu] added.
> 
> [Ralph] I apologize if I appear to be finicky, again, but the sentence I 
> quoted simply wasn't clear to me.  Common sense interpretation of 
> specifications is, of course, expected, but in my experience a simple 
> sentence like:
> 
> A MAC Address Withdraw OAM message with the A-bit set is sent by a receiver 
> to acknowledge receipt and processing of a MAC Address Withdraw OAM message
> 
> [Himanshu]  Modified description of A-bit as follows -
> 
>   A single bit (called A-bit) is

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-22 Thread Ralph Droms (rdroms)

Himanshu - I have one clarification to my review: I should have written "Is 
there a reason this document does not use RFC 2119 terminology throughout?"

...and even that is likely an unfair assessment, as RFC 2119 language more or 
less everywhere needed for clarity.

My apologies for the inaccuracy.

- Ralph

> On Oct 22, 2015, at 11:31 AM 10/22/15, Shah, Himanshu <hs...@ciena.com> wrote:
> 
> Aahh! Finally got it with content!!..
> 
> Let me go through your email..
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com] 
> Sent: Thursday, October 22, 2015 11:29 AM
> To: Shah, Himanshu
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> (originally sent 10/16; second try)
> 
> Hi, Himanshu - responses in line...
> 
>> On Oct 15, 2015, at 7:44 PM 10/15/15, Shah, Himanshu <hs...@ciena.com> wrote:
>> 
>> Hi Ralph -
>> Thanks for your thorough review.
>> 
>> Let me first address your major concern.
>> 
>> As you point out, this draft builds on existing standards.
>> We (authors and WG) had to carefully balance between the right amount 
>> of information and wanting to describe details of methods described in other 
>> RFCs.
>> 
>> This is frustrating to implementer (including myself) having to go 
>> back and forth between the documents. So I share that concern.
>> 
>> But we would like to refrain from indulging in beefing up the doc and 
>> risk deviating from other base standards. However, for certain, if 
>> there is any conflict or lack of clarity, we would prefer to rectify.
> 
> I agree that, in general, duplicating specifications from other documents 
> increases the possibility that the respective documents unintentionally 
> conflict with each other or are not updated in parallel.
>> 
>> To that end, I would rather prefer, trimming by removing 
>> conflicting/confusing text.
> 
> I wasn't clear in my review - I think making the references to other 
> documents concise and clear, along with trimming unnecessary text from 
> draft-ietf-pals-mpls-tp-mac-wd, will result in the best document.
> 
>> For example, sequence number processing - I rather would ask reader to 
>> get all details from relevant RFC, and point to only delta (which is 
>> to apply same logic that is used for 16-bit sequence number field to 
>> 32-bit field sequence number field that is used in this document).
> 
> This example is sort of an interesting one to consider, as I was thinking 
> more of the examples in which the format and semantics of the MAC TLVs are 
> exactly the same as in the cited defining documents.
> 
>> 
>> More comments in line.. and I look forward to your further guidance so 
>> we can wrap this up in time.
>> 
>> As a data point, there are two implementations of this draft deployed 
>> in a Telco network in Asia.
> 
> Noted.
> 
>> 
>> 
>> Thanks,
>> Himanshu
>> 
>> 
>> -Original Message-
>> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
>> Sent: Wednesday, October 14, 2015 4:02 PM
>> To: A. Jean Mahoney; General Area Review Team; 
>> draft-ietf-pals-mpls-tp-mac-wd@ietf.org
>> Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
>> 
>> 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-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
>> Static Pseudowire"
>> Reviewer: Ralph Droms
>> Review Date: 2015-10-14
>> IETF LC End Date: 2015-10-19
>> IESG Telechat date: (if known) N/A
>> 
>> Summary:
>> 
>> This draft is on the right track but has open issues, described in the 
>> review.
>> 
>> 
>> Major issues:
>> 
>> While this document is describing a straightforward adaptation of previously 
>> defined standards to statically provisioned PWs, in my opinion an 
>> implementor would not necessarily be able to construct a fully interoperable 
>> implementation from this document.  There are several sections of the 
>> document that are not clear in their description of how to use mechanisms

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-22 Thread Ralph Droms (rdroms)

The archived message in the gen-art list is available here: 
http://www.ietf.org/mail-archive/web/gen-art/current/msg12413.html

> On Oct 22, 2015, at 11:22 AM 10/22/15, Shah, Himanshu <hs...@ciena.com> wrote:
> 
> Can not see your message content.
> PLEASE send without MIME…
> 
> Thanks,
> Himanshu
> 
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> Sent: Thursday, October 22, 2015 11:20 AM
> To: Shah, Himanshu
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-22 Thread Ralph Droms (rdroms)

(originally sent 10/16)

Hi, Himanshu - responses in line...

> On Oct 15, 2015, at 7:44 PM 10/15/15, Shah, Himanshu <hs...@ciena.com> wrote:
> 
> Hi Ralph -
> Thanks for your thorough review.
> 
> Let me first address your major concern.
> 
> As you point out, this draft builds on existing standards.
> We (authors and WG) had to carefully balance between the right amount of 
> information
> and wanting to describe details of methods described in other RFCs.
> 
> This is frustrating to implementer (including myself) having to go back and 
> forth
> between the documents. So I share that concern.
> 
> But we would like to refrain from indulging in beefing up the doc and risk 
> deviating
> from other base standards. However, for certain, if there is any conflict or 
> lack of
> clarity, we would prefer to rectify.

I agree that, in general, duplicating specifications from other documents 
increases the possibility that the respective documents unintentionally 
conflict with each other or are not updated in parallel.
> 
> To that end, I would rather prefer, trimming by removing 
> conflicting/confusing text.

I wasn't clear in my review - I think making the references to other documents 
concise and clear, along with trimming unnecessary text from 
draft-ietf-pals-mpls-tp-mac-wd, will result in the best document.

> For example, sequence number processing - I rather would ask reader to get 
> all details
> from relevant RFC, and point to only delta (which is to apply same logic that 
> is used
> for 16-bit sequence number field to 32-bit field sequence number field that 
> is used in
> this document).

This example is sort of an interesting one to consider, as I was thinking more 
of the examples in which the format and semantics of the MAC TLVs are exactly 
the same as in the cited defining documents.

> 
> More comments in line.. and I look forward to your further guidance so we can 
> wrap this
> up in time.
> 
> As a data point, there are two implementations of this draft deployed in a 
> Telco network
> in Asia.

Noted.

> 
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> Sent: Wednesday, October 14, 2015 4:02 PM
> To: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org
> Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> 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-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
> Static Pseudowire"
> Reviewer: Ralph Droms
> Review Date: 2015-10-14
> IETF LC End Date: 2015-10-19
> IESG Telechat date: (if known) N/A
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> 
> Major issues:
> 
> While this document is describing a straightforward adaptation of previously 
> defined standards to statically provisioned PWs, in my opinion an implementor 
> would not necessarily be able to construct a fully interoperable 
> implementation from this document.  There are several sections of the 
> document that are not clear in their description of how to use mechanisms 
> from referenced documents in this standard.
> 
> If it appears that some of my comments are overly finicky, I'll agree that 
> the correct implementation could probably be deduced from the text in most 
> cases.  That is, I didn't find many outright errors or inconsistencies.  Many 
> of my comments took a lot of paging back and forth, reading of referenced 
> documents and head-scratching, which, in my experience, can lead to 
> implementations that don't interoperate.
> 
> [Himanshu>] Please see above for the justification of this approach.

Again, I wasn't clear in my review - my paging back and forth was both within 
draft-ietf-pals-mpls-tp-mac-wd and between draft-ietf-pals-mpls-tp-mac-wd and 
cited documents.  What I think would improve this specification is 
clarification that trims redundant specification details from 
draft-ietf-pals-mpls-tp-mac-wd and cites, concisely and exactly, the other 
documents from which the specifications are copied.

> 
> Section 1:
> 
> When the number of MAC addresses to be
> removed is large, the empty MAC List TLV may be used.  The empty MAC
> List TLV signifies wildcard MAC Address withdrawl.
> 
> This text seems to be the only reference to the processing o

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-22 Thread Ralph Droms (rdroms)

(originally sent 10/16; second try)

Hi, Himanshu - responses in line...

> On Oct 15, 2015, at 7:44 PM 10/15/15, Shah, Himanshu <hs...@ciena.com> wrote:
> 
> Hi Ralph -
> Thanks for your thorough review.
> 
> Let me first address your major concern.
> 
> As you point out, this draft builds on existing standards.
> We (authors and WG) had to carefully balance between the right amount of 
> information
> and wanting to describe details of methods described in other RFCs.
> 
> This is frustrating to implementer (including myself) having to go back and 
> forth
> between the documents. So I share that concern.
> 
> But we would like to refrain from indulging in beefing up the doc and risk 
> deviating
> from other base standards. However, for certain, if there is any conflict or 
> lack of
> clarity, we would prefer to rectify.

I agree that, in general, duplicating specifications from other documents 
increases the possibility that the respective documents unintentionally 
conflict with each other or are not updated in parallel.
> 
> To that end, I would rather prefer, trimming by removing 
> conflicting/confusing text.

I wasn't clear in my review - I think making the references to other documents 
concise and clear, along with trimming unnecessary text from 
draft-ietf-pals-mpls-tp-mac-wd, will result in the best document.

> For example, sequence number processing - I rather would ask reader to get 
> all details
> from relevant RFC, and point to only delta (which is to apply same logic that 
> is used
> for 16-bit sequence number field to 32-bit field sequence number field that 
> is used in
> this document).

This example is sort of an interesting one to consider, as I was thinking more 
of the examples in which the format and semantics of the MAC TLVs are exactly 
the same as in the cited defining documents.

> 
> More comments in line.. and I look forward to your further guidance so we can 
> wrap this
> up in time.
> 
> As a data point, there are two implementations of this draft deployed in a 
> Telco network
> in Asia.

Noted.

> 
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> Sent: Wednesday, October 14, 2015 4:02 PM
> To: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org
> Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> 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-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
> Static Pseudowire"
> Reviewer: Ralph Droms
> Review Date: 2015-10-14
> IETF LC End Date: 2015-10-19
> IESG Telechat date: (if known) N/A
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> 
> Major issues:
> 
> While this document is describing a straightforward adaptation of previously 
> defined standards to statically provisioned PWs, in my opinion an implementor 
> would not necessarily be able to construct a fully interoperable 
> implementation from this document.  There are several sections of the 
> document that are not clear in their description of how to use mechanisms 
> from referenced documents in this standard.
> 
> If it appears that some of my comments are overly finicky, I'll agree that 
> the correct implementation could probably be deduced from the text in most 
> cases.  That is, I didn't find many outright errors or inconsistencies.  Many 
> of my comments took a lot of paging back and forth, reading of referenced 
> documents and head-scratching, which, in my experience, can lead to 
> implementations that don't interoperate.
> 
> [Himanshu>] Please see above for the justification of this approach.

Again, I wasn't clear in my review - my paging back and forth was both within 
draft-ietf-pals-mpls-tp-mac-wd and between draft-ietf-pals-mpls-tp-mac-wd and 
cited documents.  What I think would improve this specification is 
clarification that trims redundant specification details from 
draft-ietf-pals-mpls-tp-mac-wd and cites, concisely and exactly, the other 
documents from which the specifications are copied.

> 
> Section 1:
> 
> When the number of MAC addresses to be
> removed is large, the empty MAC List TLV may be used.  The empty MAC
> List TLV signifies wildcard MAC Address withdrawl.
> 
> This text seems to be the only reference to

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-16 Thread Ralph Droms (rdroms)

Hi, Himanshu - responses in line...

> On Oct 15, 2015, at 7:44 PM 10/15/15, Shah, Himanshu <hs...@ciena.com> wrote:
> 
> Hi Ralph -
> Thanks for your thorough review.
> 
> Let me first address your major concern.
> 
> As you point out, this draft builds on existing standards.
> We (authors and WG) had to carefully balance between the right amount of 
> information
> and wanting to describe details of methods described in other RFCs.
> 
> This is frustrating to implementer (including myself) having to go back and 
> forth
> between the documents. So I share that concern.
> 
> But we would like to refrain from indulging in beefing up the doc and risk 
> deviating
> from other base standards. However, for certain, if there is any conflict or 
> lack of
> clarity, we would prefer to rectify.

I agree that, in general, duplicating specifications from other documents 
increases the possibility that the respective documents unintentionally 
conflict with each other or are not updated in parallel.
> 
> To that end, I would rather prefer, trimming by removing 
> conflicting/confusing text.

I wasn't clear in my review - I think making the references to other documents 
concise and clear, along with trimming unnecessary text from 
draft-ietf-pals-mpls-tp-mac-wd, will result in the best document.

> For example, sequence number processing - I rather would ask reader to get 
> all details
> from relevant RFC, and point to only delta (which is to apply same logic that 
> is used
> for 16-bit sequence number field to 32-bit field sequence number field that 
> is used in
> this document).

This example is sort of an interesting one to consider, as I was thinking more 
of the examples in which the format and semantics of the MAC TLVs are exactly 
the same as in the cited defining documents.

> 
> More comments in line.. and I look forward to your further guidance so we can 
> wrap this
> up in time.
> 
> As a data point, there are two implementations of this draft deployed in a 
> Telco network
> in Asia.

Noted.

> 
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> Sent: Wednesday, October 14, 2015 4:02 PM
> To: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org
> Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> 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-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
> Static Pseudowire"
> Reviewer: Ralph Droms
> Review Date: 2015-10-14
> IETF LC End Date: 2015-10-19
> IESG Telechat date: (if known) N/A
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> 
> Major issues:
> 
> While this document is describing a straightforward adaptation of previously 
> defined standards to statically provisioned PWs, in my opinion an implementor 
> would not necessarily be able to construct a fully interoperable 
> implementation from this document.  There are several sections of the 
> document that are not clear in their description of how to use mechanisms 
> from referenced documents in this standard.
> 
> If it appears that some of my comments are overly finicky, I'll agree that 
> the correct implementation could probably be deduced from the text in most 
> cases.  That is, I didn't find many outright errors or inconsistencies.  Many 
> of my comments took a lot of paging back and forth, reading of referenced 
> documents and head-scratching, which, in my experience, can lead to 
> implementations that don't interoperate.
> 
> [Himanshu>] Please see above for the justification of this approach.

Again, I wasn't clear in my review - my paging back and forth was both within 
draft-ietf-pals-mpls-tp-mac-wd and between draft-ietf-pals-mpls-tp-mac-wd and 
cited documents.  What I think would improve this specification is 
clarification that trims redundant specification details from 
draft-ietf-pals-mpls-tp-mac-wd and cites, concisely and exactly, the other 
documents from which the specifications are copied.

> 
> Section 1:
> 
>  When the number of MAC addresses to be
>  removed is large, the empty MAC List TLV may be used.  The empty MAC
>  List TLV signifies wildcard MAC Address withdrawl.
> 
> This text seems to be the only reference to the processing of an empty MAC 
>

[Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-14 Thread Ralph Droms (rdroms)

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-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
Static Pseudowire"
Reviewer: Ralph Droms
Review Date: 2015-10-14
IETF LC End Date: 2015-10-19
IESG Telechat date: (if known) N/A

Summary:

This draft is on the right track but has open issues, described in the review.


Major issues:

While this document is describing a straightforward adaptation of previously 
defined standards to statically provisioned PWs, in my opinion an implementor 
would not necessarily be able to construct a fully interoperable implementation 
from this document.  There are several sections of the document that are not 
clear in their description of how to use mechanisms from referenced documents 
in this standard.

If it appears that some of my comments are overly finicky, I'll agree that the 
correct implementation could probably be deduced from the text in most cases.  
That is, I didn't find many outright errors or inconsistencies.  Many of my 
comments took a lot of paging back and forth, reading of referenced documents 
and head-scratching, which, in my experience, can lead to implementations that 
don't interoperate.

Section 1:

  When the number of MAC addresses to be
  removed is large, the empty MAC List TLV may be used.  The empty MAC
  List TLV signifies wildcard MAC Address withdrawl.

This text seems to be the only reference to the processing of an empty MAC List 
TLV.  Specification of how the protocol works doesn't belong in the 
Introduction, and "wildcard MAC Address withdrawal" could certainly use some 
more explanation.

Section 3:

  The PW OAM message header is exactly the same as what is
  defined in [RFC6478].

Is this statement really true?  The MAC Address Withdraw header seems to 
replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
flag.  The statement might be misleading to an implementor.

  a MAC address withdraw OAM message MUST contain a
  "Sequence Number TLV" otherwise the entire message is dropped.

Is the "Sequence Number TLV" required to be the first TLV in the message?  Are 
the TLVs required to appear in any particular order?

  A single bit (called A-bit) is set to indicate if a MAC withdraw
  message is for ACK.  Also, ACK does not include MAC TLV(s).

Does this mean that the message is an ACK if the A-bit is set?  Can an ACK 
contain a "Sequence Number" TLV?

  Only half of the sequence number space is used.  Modular arithmetic
  is used to detect wrapping of sequence number.  When sequence number
  wraps, all MAC addresses are flushed and the sequence number is
  reset.  The 16-bit sequence number handling is described in
  [RFC4385]. This document uses 32-bits sequence numbers and hence
  sequence number in half the number space (i.e. 31-bits or ~2billion)
  is considered in the valid receive range.

This paragraph is not at all clear to me. Reading section 4 of RFC 4385 helped 
but left me unsure about how my understanding of how to extend the sequence 
number mechanism to 32 bits corresponds to the expectations of this document.

Section 4.1:

  Each PW is associated with a counter to keep track of the sequence
  number of the transmitted MAC withdrawal messages.  Whenever a node
  sends a new set of MAC TLVs, it increments the transmitted sequence
  number counter, and include the new sequence number in the message.
  The transmit sequence number is initialized to 1 at the onset.

I'm pretty sure this is supposed to mean that the sequence number in the first 
message is 1.  The text could be interpreted to mean that the counter is 
initialized to 1 and then incremented to 2 when sending the first message.

  The retransmission MUST be
  ceased anytime when ACK is received or after three retries.  This
  avoids unended retransmissions in the absence of acknowledgements.
  Since retransmission time interval and the maximum number of retries
  is local configuration of the sender node, it is up to the
  implementers to pick a discipline.

Is the maximum number of retransmissions 3 or is it locally configured?  Is the 
default 3?

  The 'R' reset bit is set in the first MAC withdraw
  to notify the remote peer to reset the send and receive sequence
  numbers.  The 'R' bit must be cleared in subsequent MAC withdraw
  messages after the acknowledgement is received

"First" as in "first message after reset or restart or ???  Would it be better 
to say "The R-bit is set in a message when one peer needs to force the remote 
peer to reset its send and receive sequence numbers"?  Does the device se

[Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

2015-10-14 Thread Ralph Droms (rdroms)

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-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
Static Pseudowire"
Reviewer: Ralph Droms
Review Date: 2015-10-14
IETF LC End Date: 2015-10-19
IESG Telechat date: (if known) N/A

Summary:

This draft is on the right track but has open issues, described in the review.


Major issues:

While this document is describing a straightforward adaptation of previously 
defined standards to statically provisioned PWs, in my opinion an implementor 
would not necessarily be able to construct a fully interoperable implementation 
from this document.  There are several sections of the document that are not 
clear in their description of how to use mechanisms from referenced documents 
in this standard.

If it appears that some of my comments are overly finicky, I'll agree that the 
correct implementation could probably be deduced from the text in most cases.  
That is, I didn't find many outright errors or inconsistencies.  Many of my 
comments took a lot of paging back and forth, reading of referenced documents 
and head-scratching, which, in my experience, can lead to implementations that 
don't interoperate.

Section 1:

   When the number of MAC addresses to be
   removed is large, the empty MAC List TLV may be used.  The empty MAC
   List TLV signifies wildcard MAC Address withdrawl.

This text seems to be the only reference to the processing of an empty MAC List 
TLV.  Specification of how the protocol works doesn't belong in the 
Introduction, and "wildcard MAC Address withdrawal" could certainly use some 
more explanation.

Section 3:

   The PW OAM message header is exactly the same as what is
   defined in [RFC6478].

Is this statement really true?  The MAC Address Withdraw header seems to 
replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
flag.  The statement might be misleading to an implementor.

   a MAC address withdraw OAM message MUST contain a
   "Sequence Number TLV" otherwise the entire message is dropped.

Is the "Sequence Number TLV" required to be the first TLV in the message?  Are 
the TLVs required to appear in any particular order?

   A single bit (called A-bit) is set to indicate if a MAC withdraw
   message is for ACK.  Also, ACK does not include MAC TLV(s).

Does this mean that the message is an ACK if the A-bit is set?  Can an ACK 
contain a "Sequence Number" TLV?

   Only half of the sequence number space is used.  Modular arithmetic
   is used to detect wrapping of sequence number.  When sequence number
   wraps, all MAC addresses are flushed and the sequence number is
   reset.  The 16-bit sequence number handling is described in
   [RFC4385]. This document uses 32-bits sequence numbers and hence
   sequence number in half the number space (i.e. 31-bits or ~2billion)
   is considered in the valid receive range.

This paragraph is not at all clear to me. Reading section 4 of RFC 4385 helped 
but left me unsure about how my understanding of how to extend the sequence 
number mechanism to 32 bits corresponds to the expectations of this document.

Section 4.1:

   Each PW is associated with a counter to keep track of the sequence
   number of the transmitted MAC withdrawal messages.  Whenever a node
   sends a new set of MAC TLVs, it increments the transmitted sequence
   number counter, and include the new sequence number in the message.
   The transmit sequence number is initialized to 1 at the onset.

I'm pretty sure this is supposed to mean that the sequence number in the first 
message is 1.  The text could be interpreted to mean that the counter is 
initialized to 1 and then incremented to 2 when sending the first message.

   The retransmission MUST be
   ceased anytime when ACK is received or after three retries.  This
   avoids unended retransmissions in the absence of acknowledgements.
   Since retransmission time interval and the maximum number of retries
   is local configuration of the sender node, it is up to the
   implementers to pick a discipline.

Is the maximum number of retransmissions 3 or is it locally configured?  Is the 
default 3?

   The 'R' reset bit is set in the first MAC withdraw
   to notify the remote peer to reset the send and receive sequence
   numbers.  The 'R' bit must be cleared in subsequent MAC withdraw
   messages after the acknowledgement is received

"First" as in "first message after reset or restart or ???  Would it be better 
to say "The R-bit is set in a message when one peer needs to force the remote 
peer to reset its send and receive sequence

Re: [Gen-art] review of draft-ietf-6man-multicast-scopes-05.txt

2014-06-10 Thread Ralph Droms

Francis, Jari - thanks for your reviews.  I will address those editorial issues 
in the next revision of the draft.

- Ralph

On Jun 10, 2014, at 3:37 AM 6/10/14, Jari Arkko jari.ar...@ericsson.com wrote:

 Thanks for your review. I have also reviewed the document.
 
 Jari
 
 On 02 Jun 2014, at 15:46, Francis Dupont francis.dup...@fdupont.fr wrote:
 
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please resolve these comments along with any other Last Call comments
 you may receive.
 
 Document: draft-ietf-6man-multicast-scopes-05.txt
 Reviewer: Francis Dupont
 Review Date: 20140530
 IETF LC End Date: 20140530
 IESG Telechat date: unknown
 
 Summary: Ready
 
 Major issues: None
 
 Minor issues: None
 
 Nits/editorial comments:
 (only editorial stuff in the case they are not caught by the RFC Editor)
 
 - 2 NEW page 4: contraint - constraint
 
 - 7 page 5: missing final dot
 
 - Author's Address page 6: US - USA
 
 Thanks
 
 francis.dup...@fdupont.fr
 
 ___
 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

Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03

2013-09-13 Thread Ralph Droms (rdroms)

Dan - thanks for your review.  Responses in line; edits will appear in the -04 
rev.

- Ralph

On Aug 25, 2013, at 7:29 AM 8/25/13, Romascanu, Dan (Dan) 
droma...@avaya.com wrote:

 
 
 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
 please see the FAQ at
 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please resolve these comments along with any other Last Call comments you may 
 receive.
 
 Document: draft-ietf-dhc-dhcpv6-solmaxrt-update-03
 Reviewer: Dan Romascanu
 Review Date: 8/25/13
 IETF LC End Date: 9/3/13
 IESG Telechat date: (if known)
 
 Summary: Ready with minor issues
 
 Major issues: None
 
 Minor issues:
 
 1. My understanding is that although the default values of SOL_MAX_RT and 
 INF_MAX_RT were the same in RFC 3315, and now they are change to similar 
 values, there is no mandatory behavior defined for servers to set them at the 
 same values using the new override options. If this is the case then the 
 Abstract should say 
 
 OLD: 
 
 ... override the client's default value for SOL_MAX_RT
   and INF_MAX_RT with a new value.
 
 NEW: 
 
 ... override the client's default value for SOL_MAX_RT
   and INF_MAX_RT with new values.
 
 If I am wrong, and the values of the two parameters are always identical at 
 defalult or after changes, then something needs to be said on this respect in 
 Section 8 (DHCPv6 Server Behavior)

Good catch; left over text from adding INF_MAX_RT after the draft was initially 
written.  I will use your suggested text.

 
 2. This is not a document problem but a WG management issue. I could not find 
 anything in the dhc WG charter that corresponds to this document, so I cannot 
 say whether this document meets the conditions of the 'contract with the 
 IESG'. Actually the charter seems not to have been updated for five years, if 
 not more. I guess that with Ralph as an author all is OK, but an update of 
 the charter seems to be needed. 

In my opinion, this work falls under this WG work item:

  1. Develop extensions to the DHCPv6 infrastructure as required to meet
 new applications and deployments of DHCP.

Admittedly, there is no explicit entry in the list of current topics that 
covers this document.

I know either Bernie, Tomek or Ted has pointed out that the dhc WG is 
rechartering.

 
 
 Nits/editorial comments:
 
 Section 7: 
 
 OLD:
 
   a DHCPv6 client MUST silently ignore any SOL_MAX_RT or INF_MAX_RT
   values that are less than 60 or more than 86400.
 
 
 New:
 
   A DHCPv6 client MUST silently ignore any SOL_MAX_RT or INF_MAX_RT
   values that are less than 60 or more than 86400.

Fixed.

- Ralph


 
 
 Regards,
 
 Dan
 

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

Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03

2013-08-25 Thread Ralph Droms

Dan - thanks for your review.

On Aug 25, 2013, at 7:29 AM, Romascanu, Dan (Dan) droma...@avaya.com wrote:

 
 
 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
 please see the FAQ at
 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please resolve these comments along with any other Last Call comments you may 
 receive.
 
 Document: draft-ietf-dhc-dhcpv6-solmaxrt-update-03
 Reviewer: Dan Romascanu
 Review Date: 8/25/13
 IETF LC End Date: 9/3/13
 IESG Telechat date: (if known)
 
 Summary: Ready with minor issues
 
 Major issues: None
 
 Minor issues:
 
 1. My understanding is that although the default values of SOL_MAX_RT and 
 INF_MAX_RT were the same in RFC 3315, and now they are change to similar 
 values, there is no mandatory behavior defined for servers to set them at the 
 same values using the new override options. If this is the case then the 
 Abstract should say 
 
 OLD: 
 
 ... override the client's default value for SOL_MAX_RT
   and INF_MAX_RT with a new value.
 
 NEW: 
 
 ... override the client's default value for SOL_MAX_RT
   and INF_MAX_RT with new values.
 
 If I am wrong, and the values of the two parameters are always identical at 
 defalult or after changes, then something needs to be said on this respect in 
 Section 8 (DHCPv6 Server Behavior)

Dan, your understanding that SOL_MAX_RT and INF_MAX_RT are allowed to have 
independent values is correct.  The document originally addressed SOL_MAX_RT 
and I missed  the text you cite when I updated the doc to include INF_MAX_RT.  
I'll make your suggested changes in the next rev of the doc.



 
 2. This is not a document problem but a WG management issue. I could not find 
 anything in the dhc WG charter that corresponds to this document, so I cannot 
 say whether this document meets the conditions of the 'contract with the 
 IESG'. Actually the charter seems not to have been updated for five years, if 
 not more. I guess that with Ralph as an author all is OK, but an update of 
 the charter seems to be needed. 
 

In my opinion, this document falls under the following clause of the dhc WG 
charter:

   However, the DHC WG can in some cases develop its own options that 
relate to either maintenance of existing specifications or 
   improvements in the operation of the DHCP infrastructure itself.

Regarding the charter more generally, the WG is currently in the process of 
rechartering.

Tomek and Bernie can add detail or correct me...

 
 Nits/editorial comments:
 
 Section 7: 
 
 OLD:
 
   a DHCPv6 client MUST silently ignore any SOL_MAX_RT or INF_MAX_RT
   values that are less than 60 or more than 86400.
 
 
 New:
 
   A DHCPv6 client MUST silently ignore any SOL_MAX_RT or INF_MAX_RT
   values that are less than 60 or more than 86400.

Thanks for catching that typo.

 
 
 Regards,
 
 Dan

- Ralph

 
___
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-arkko-townsley-coexistence-04.txt

2010-09-17 Thread Ralph Droms

Thanks, Brian.

- Ralph

On Sep 17, 2010, at 6:09 AM 9/17/10, Brian E Carpenter wrote:

 
 draft-arkko-townsley-coexistence-04-carpenter.txt

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

Re: [Gen-art] draft-ietf-ntp-autokey-06.txt

2009-08-20 Thread Ralph Droms

Russ - I've added the RFC Editor comments.  I expect we'll need  
another rev before publication, which should incorporate those comments.


- Ralph

On Aug 19, 2009, at 4:58 PM 8/19/09, Russ Housley wrote:


Ralph:


Russ - would you be willing to clear your DISCUSS and capture Joel's
new issues in a COMMENT?

- Ralph

On Jul 27, 2009, at 4:56 AM 7/27/09, Joel M. Halpern wrote:

This document is nearly ready for publication as an Informational  
RFC.


While my comments have been resolved, some minor issues
apparently crept in during the editing process..  These are small
enough that they can probably be dealt with in notes to the RFC
Editor if no other issues are found.  However, they are sufficiently
ambiguous that they should not be left for rediscovery by the RFC
Editor.


Two individual sentences became truncated (Section 7, first
paragraph was created. = was. and section 8, third bullet the
server.=the.)


Can you post an RFC Editor note this one?  We have experience that  
shows RFC Editor notes are read, but comments are almost always  
ignored.



Section 8 on the Sign exchange previously said that the information
was signed using the private key.  Now it says that it is signed
using the public key.  As I understand it, the signature is
generated with the private key to be verified with the public key.
I am not sure what the right words in the paragraph would be.  (I
was happy with private key before since the signer used his own
private key.)


Again, I'd like to see an RFC Editor note for this one?


In the paragraph on the extension field parser length calculation,
with the text beginning:
If greater than 22 an extension field is present.  If the length
is ..
has two minor issues.  I believe it would be clearer if it said
If the remaining length is greater than 22 an extension field is
present.  If the remaining length is ...


I'm fine with a comment for this one.

Russ



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

Re: [Gen-art] draft-ietf-ntp-autokey-06.txt

2009-08-18 Thread Ralph Droms

Russ - would you be willing to clear your DISCUSS and capture Joel's  
new issues in a COMMENT?


- Ralph

On Jul 27, 2009, at 4:56 AM 7/27/09, Joel M. Halpern wrote:


This document is nearly ready for publication as an Informational RFC.

While my comments have been resolved, some minor issues
apparently crept in during the editing process..  These are small  
enough that they can probably be dealt with in notes to the RFC  
Editor if no other issues are found.  However, they are sufficiently  
ambiguous that they should not be left for rediscovery by the RFC  
Editor.



Two individual sentences became truncated (Section 7, first  
paragraph was created. = was. and section 8, third bullet the  
server.=the.)


Section 8 on the Sign exchange previously said that the information  
was signed using the private key.  Now it says that it is signed  
using the public key.  As I understand it, the signature is  
generated with the private key to be verified with the public key.   
I am not sure what the right words in the paragraph would be.  (I   
was happy with private key before since the signer used his own  
private key.)


In the paragraph on the extension field parser length calculation,  
with the text beginning:
If greater than 22 an extension field is present.  If the length  
is ..

has two minor issues.  I believe it would be clearer if it said
If the remaining length is greater than 22 an extension field is  
present.  If the remaining length is ...


Yours,
Joel M. Halpern

Russ Housley wrote:

Joel:
Please take a look at the updated document
*Discuss (2009-06-15)
*
 The Gen-ART Review by Joel Halpern on 5-June-2009 has
lead to some
 discussion with the authors.  Not all of the issues have
been
 resolved, but it is clear that some changes to the document are
 needed.  The following issues are still unresolved.
 The usage within Autokey of the extension field need description
early
 in the document.  Paragraph 3 of Section 10 reserves seven
values (1-7)
 Autokey. The Field Type field performs two roles:
identification as
 an Autokey extension and defining the type within Autokey.
 Section 11.1 includes a 16 bit Digest / Signature NID.  There
is no
 description of how this is used.
 The wording on hierarchy in section 5, paragraph 3 is the opposite
of
 what is shown in the figure.  (The figure matches
expectations, where
 a client of one group operates as the TH of a group operating at
a
 lower stratum.)
 In Section 10, the paragraph that begins [T]he extension
field parser   initializes a pointer... is incorrect.  The
length by which the
 pointer is increment is the length in the extension header, not
the
 length computed by subtracting the NTP header from the packet
length.
 In figure 5, it would help the reader if the groups and hosts had
 different names.  (Even just calling the groups Alice-Group
and
 Carol-Group would help.)
 In section 5, in the description of [t]he steps in hiking
the   certificate trails..., in step 1, in the second sentence,
please add
 language to make it clear that the server is exchanging host
names
 and negotiating... with is the server from whom it is
getting
 information.
 Section 8 should be moved earlier in the document.  Early
parts of the
 document assume an understanding of properties of the system
which
 have not been described yet.
 Section 11.6 (Security Considerations) is supposed to be a
top-level
 section.

X-Original-To: hous...@vigilsec.com
Delivered-To: hous...@vigilsec.com
X-Virus-Scanned: amavisd-new at smetech.net
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 required=3.5 tests=[BAYES_00=-2.599,
RCVD_IN_DNSWL_MED=-4]
From: internet-dr...@ietf.org
To: ntp-cha...@tools.ietf.org, draft-ietf-ntp- 
auto...@tools.ietf.org,rdr...@cisco.com,hous...@vigilsec.com,tim.p...@nist.gov 
,pasi.ero...@nokia.com,adrian.far...@huawei.com

Subject: New Version Notification - draft-ietf-ntp-autokey-06.txt
Date: Wed,  8 Jul 2009 05:00:02 -0700 (PDT)

New version (-06) has been submitted for draft-ietf-ntp- 
autokey-06.txt. http://www.ietf.org/internet-drafts/draft-ietf-ntp-autokey-06.txt

Sub state has been changed to AD Follow up from New Id Needed

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-ntp-autokey-06

IETF Secretariat.


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

Re: [Gen-art] [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00

2009-04-16 Thread Ralph Droms

Yup ... there is currently no way to provide authenticated, meaningful  
identification of the network(s) to which a host is attached.  Without  
that identification, it's pretty hard to write any reasonable policies.


- Ralph

On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote:


On 2009/4/13 Ralph Droms rdr...@cisco.com wrote:

For example, would a host process
information received from a Starbucks network over its 802.11
interface differently from information received a home network over  
the 802.11 interface?


It's even more fun than that.   How do we reliably know that we are  
at Starbucks, and not at home?   The SSID?   That's not an  
authenticated token.   Currently Windows makes security decisions  
based on the SSID.   You could call this the best answer they could  
come up with for a problem with no good answers.   Or you could say  
that it instills the user with a false sense of security.   Either  
way, it's not something I'd be comfortable seeing in a protocol  
spec, so if the client is in fact to make decisions as you've  
suggested, we'd need a secure way of doing this.   I don't know  
enough about WPA Enterprise to know if there's a bidirectional  
authentication going on there - from the UI perspective it looks  
like it's one-way.




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

Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

2009-04-14 Thread Ralph Droms

Ted - I think it's just as likely for the RG to get different  
information from different interfaces (or different administrative  
domains) as it is for a host to get get different information  
directly.  Traffic from the host, which is then forwarded by the RG to  
one of more than one possible interfaces or routers, might be affected  
by the configuration information from the administrative domain  
through which the traffic is forwarded.


Now, I admit I'm describing a hypothetical and abstract scenario.  I  
don't have a specific example of a situation in which a host might  
make decisions - either in the stack or in an application or ??? -  
about outbound traffic based on knowledge of how that traffic would be  
forwarded by the RG.


- Ralph

On Apr 13, 2009, at 5:11 PM 4/13/09, Ted Lemon wrote:

How realistic is it anyway that an RG would get different *relevant*  
options on its different interfaces?   This would seem to me to be  
an administrative error.   Of course the broadcast address and  
subnet mask options might be different, but it doesn't make sense to  
send the RG, e.g., different name servers for each interface.




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

Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

2009-04-13 Thread Ralph Droms

Hui - I think there is an issue for hosts with multiple interfaces  
triggered by Scott's comments about the container option: even if a  
host is physically aware that it has multiple interfaces, how does it  
take the characteristics of the networks behind those interfaces into  
account when it merges information?  For example, would a host process  
information received from a Starbucks network over its 802.11  
interface differently from information received a home network over  
the 802.11 interface?


- Ralph

On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote:


Hi, Scott,

Based on the current MIF charter proposal, it consider only host.
http://www.ietf.org/mail-archive/web/mif/current/msg00367.html
I am wondering whether RG is a kind of host?

Anyhow, this discussion benefit MIF for the future consideration how
to identify the source.

Many thanks

-Hui

2009/4/11 Scott Brim s...@employees.org:

Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400:

Scott raises an interesting point about identifying the source of
options when delivered to clients.

BTW, Scott - what is DHS?


Sorry, DHCP server

The usual case - almost the only case today - is that there is a  
single

upstream service provider and a single source of DHCP options to be
passed along to the client.  In this scenario, there's no need to  
pass

along any information identifying the source of the options.

To allow for a multihomed subscriber network, I can imagine adding  
a tag
that would be passed along with the options so the subscriber  
client can
identify the source of each option.  But, what would the client do  
with
that information?  How would the client interpret it?  What is the  
syntax

and semantics of the tagging?

Taken a step farther, sourcing information might be required even if
there is no intermediate RG and the contained option is not in  
use.  How

does a device with multiple interfaces make policy decisions about
information received on those multiple interfaces (which is pretty  
much

the question Scott asks about the container option)?

- Ralph


Well put.  It all comes down to where information is going to be
merged.  The case where a single RG client connected to multiple SP
servers is essentially already covered by MIF/6man, they just need to
document it.  If the information is merged at the RG server, then the
RG server should somehow know which interface which DHCP information
came from.  If all of the information is transparently passed to the
consumer device, then it needs the tags as well.

I don't know how the information could be usefully tagged -- the SP
server's IP address doesn't sound like a good idea.  The WG should
decide if tagging should be included in the container syntax or added
later (but documented now as needing study).

I'm CCing MIF in case people there aren't on the ietf list.

Thanks ... Scott



On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote:


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-dhc-container-00
Reviewer: Scott Brim
Review Date: 7 April 2009
IESG Telechat date: 14 April 2009

Summary:

This draft is on the right track but has open issues.

Comments:

More significant:

  I am concerned about multiple interface scenarios as are being
  discussed in MIF and 6MAN, where either the RG is multiply  
connected
  or the end device is.  For a discussion of the sort of problems  
that

  lead to this concern, see (for example) notes from the MIF BOF at
  IETF74.

  - There must be a way to associate options with a particular
upstream DHS they were obtained from, when the container is  
passed

to the RG server and perhaps to the end device.  This source
information may or may not be in the container itself --  
that's up
to the WG to decide.  If it is decided that the source  
information
will not be part of the container syntax, at least the fact  
that
it is necessary should be documented for people who  
ultimately do

specify how container options are passed.

  - The SP server may have its ideas of how a consumer device  
should

be configured, but it is not appropriate to say that the SP
server MUST be able to control which DHCP options are  
transmitted
to the consumer device.  The RG server may need to make  
decisions
about information from multiple DHCP servers.  Perhaps you  
could

say that the SP server MUST be able to provide information to
the RG server.

Less significant:

  5.1 and 5.2

Alignment between the v4 and v6 descriptions would be better.  
The
v4 description has code in the diagram and says that code  
is
OPTION_CONTAINER_V4.  The v6 description has  
OPTION_CONTAINER_V6
in the diagram and says

Re: [Gen-art] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

2009-04-13 Thread Ralph Droms

Mike - Can you give a little more detail?  I'm not sure I see how the  
RFC 3046 options - passed between a relay agent and a server - would  
interact with the container option.


BTW, please feel free to join the conversation at any time.  The SF  
meeting marked the 20th year anniversary of the first dhc WG meeting  
at IETF 13 in Cocoa Beach.  I was looking at the list of attendees ...  
and you were at that first meeting, so we welcome your input as a  
charter member.


Also, from the minutes of that first dhc WG meeting:

  We quickly decided to limit the scope of our discussion to Internet
  participants with only a single interface. This decision allowed us
  to avoid the host versus gateway and multi-homed host religious
  wars...

Guess we won't be able to duck the issue any more.

- Ralph

On Apr 11, 2009, at 4:00 PM 4/11/09, Michael StJohns wrote:

Sorry to stick my oar in, but does this or could this interact with  
the options specified in RFC3046 in an unexpected way?


At 01:41 PM 4/11/2009, Ralph Droms wrote:

Scott - even knowing which interface which DHCP information came
from may not be enough for a device with multiple interfaces.  Can
policies for merging information be written just based on the
characteristics of the interface - say, 3GPP versus 802.11, or IP
address of the interface - or does the device need to differentiate
between Verizon Wireless and Starbucks if I'm away from home?  Or
differentiate between my ATT femtocell and my home WiFi network?

- Ralph

On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote:


Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400:

Scott raises an interesting point about identifying the source of
options when delivered to clients.

BTW, Scott - what is DHS?


Sorry, DHCP server


The usual case - almost the only case today - is that there is a
single
upstream service provider and a single source of DHCP options to be
passed along to the client.  In this scenario, there's no need to
pass
along any information identifying the source of the options.

To allow for a multihomed subscriber network, I can imagine adding
a tag
that would be passed along with the options so the subscriber
client can
identify the source of each option.  But, what would the client do
with
that information?  How would the client interpret it?  What is the
syntax
and semantics of the tagging?

Taken a step farther, sourcing information might be required even  
if

there is no intermediate RG and the contained option is not in
use.  How
does a device with multiple interfaces make policy decisions about
information received on those multiple interfaces (which is pretty
much
the question Scott asks about the container option)?

- Ralph


Well put.  It all comes down to where information is going to be
merged.  The case where a single RG client connected to multiple SP
servers is essentially already covered by MIF/6man, they just need  
to
document it.  If the information is merged at the RG server, then  
the

RG server should somehow know which interface which DHCP information
came from.  If all of the information is transparently passed to the
consumer device, then it needs the tags as well.

I don't know how the information could be usefully tagged -- the SP
server's IP address doesn't sound like a good idea.  The WG should
decide if tagging should be included in the container syntax or  
added

later (but documented now as needing study).

I'm CCing MIF in case people there aren't on the ietf list.

Thanks ... Scott



On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote:


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-dhc-container-00
Reviewer: Scott Brim
Review Date: 7 April 2009
IESG Telechat date: 14 April 2009

Summary:

This draft is on the right track but has open issues.

Comments:

More significant:

I am concerned about multiple interface scenarios as are being
discussed in MIF and 6MAN, where either the RG is multiply
connected
or the end device is.  For a discussion of the sort of problems
that
lead to this concern, see (for example) notes from the MIF BOF at
IETF74.

- There must be a way to associate options with a particular
 upstream DHS they were obtained from, when the container is
passed
 to the RG server and perhaps to the end device.  This source
 information may or may not be in the container itself -- that's
up
 to the WG to decide.  If it is decided that the source
information
 will not be part of the container syntax, at least the fact that
 it is necessary should be documented for people who ultimately do
 specify how container options are passed.

- The SP server may have its ideas of how a consumer device should
 be configured, but it is not appropriate to say

Re: [Gen-art] Gen-ART review of draft-ietf-dhc-container-00

2009-04-11 Thread Ralph Droms

Scott - even knowing which interface which DHCP information came  
from may not be enough for a device with multiple interfaces.  Can  
policies for merging information be written just based on the  
characteristics of the interface - say, 3GPP versus 802.11, or IP  
address of the interface - or does the device need to differentiate  
between Verizon Wireless and Starbucks if I'm away from home?  Or  
differentiate between my ATT femtocell and my home WiFi network?


- Ralph

On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote:


Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400:

Scott raises an interesting point about identifying the source of
options when delivered to clients.

BTW, Scott - what is DHS?


Sorry, DHCP server

The usual case - almost the only case today - is that there is a  
single

upstream service provider and a single source of DHCP options to be
passed along to the client.  In this scenario, there's no need to  
pass

along any information identifying the source of the options.

To allow for a multihomed subscriber network, I can imagine adding  
a tag
that would be passed along with the options so the subscriber  
client can
identify the source of each option.  But, what would the client do  
with
that information?  How would the client interpret it?  What is the  
syntax

and semantics of the tagging?

Taken a step farther, sourcing information might be required even if
there is no intermediate RG and the contained option is not in  
use.  How

does a device with multiple interfaces make policy decisions about
information received on those multiple interfaces (which is pretty  
much

the question Scott asks about the container option)?

- Ralph


Well put.  It all comes down to where information is going to be
merged.  The case where a single RG client connected to multiple SP
servers is essentially already covered by MIF/6man, they just need to
document it.  If the information is merged at the RG server, then the
RG server should somehow know which interface which DHCP information
came from.  If all of the information is transparently passed to the
consumer device, then it needs the tags as well.

I don't know how the information could be usefully tagged -- the SP
server's IP address doesn't sound like a good idea.  The WG should
decide if tagging should be included in the container syntax or added
later (but documented now as needing study).

I'm CCing MIF in case people there aren't on the ietf list.

Thanks ... Scott



On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote:


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-dhc-container-00
Reviewer: Scott Brim
Review Date: 7 April 2009
IESG Telechat date: 14 April 2009

Summary:

This draft is on the right track but has open issues.

Comments:

More significant:

 I am concerned about multiple interface scenarios as are being
 discussed in MIF and 6MAN, where either the RG is multiply  
connected
 or the end device is.  For a discussion of the sort of problems  
that

 lead to this concern, see (for example) notes from the MIF BOF at
 IETF74.

 - There must be a way to associate options with a particular
   upstream DHS they were obtained from, when the container is  
passed

   to the RG server and perhaps to the end device.  This source
   information may or may not be in the container itself -- that's  
up
   to the WG to decide.  If it is decided that the source  
information

   will not be part of the container syntax, at least the fact that
   it is necessary should be documented for people who ultimately do
   specify how container options are passed.

 - The SP server may have its ideas of how a consumer device should
   be configured, but it is not appropriate to say that the SP
   server MUST be able to control which DHCP options are transmitted
   to the consumer device.  The RG server may need to make  
decisions

   about information from multiple DHCP servers.  Perhaps you could
   say that the SP server MUST be able to provide information to
   the RG server.

Less significant:

 5.1 and 5.2

   Alignment between the v4 and v6 descriptions would be better. The
   v4 description has code in the diagram and says that code is
   OPTION_CONTAINER_V4.  The v6 description has  
OPTION_CONTAINER_V6
   in the diagram and says that option-code is  
OPTION_CONTAINER_V6.


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

Re: [Gen-art] Re: gen-art review of draft-ietf-ipv6-2461bis-09.txt

2006-11-29 Thread Ralph Droms

Yeah.  I have to agree with James and Brian: in retrospect, the M/O bits are
useless and further discussion at this point is even more useless.

- Ralph


On 11/29/06 4:58 AM, Brian E Carpenter [EMAIL PROTECTED] wrote:

 The MO bits were
 defined long before we had DHCPv6 in place.
 
 And they were discussed to death in the WG before the draft reached
 WG consensus. I'm not inclined to reopen that discussion.
 
 (Somebody added ietf@ietf.org to this thread. I have removed it.)
 
 Brian

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

[Gen-art] Re: GEN-ART LC Review of draft-ietf-radext-delegated-prefix-01.txt

2006-05-31 Thread Ralph Droms

Spencer - thanks for your review and helpful comments.

You've correctly understood the Length and Prefix-Length fields; I'll update
those definitions.

Regarding Reserved - Always set to zero: I'll check the definition of the
Framed-IPv6-Prefix in RFC 3162 to understand the common practice (if any).

I'll add a box around the table and the final draft will have a citation for
RFC 3162 (def of Framed-IPv6-Prefix).

- Ralph


On 5/30/06 6:58 PM, Spencer Dawkins [EMAIL PROTECTED] wrote:

 Hi, Joe and Ralph,
 
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
 
 Summary - this draft is almost ready for publication as a Proposed Standard.
 It is short, and clearly written.
 
 I have four observations - there may be DHCP conventions I don't know about,
 but this is how things look to me.
 
 - The relationship between Length and Prefix-Length seems
 underspecified. If what you are saying is
 
Length - the length of the entire attribute, in bytes. At least 4 (to
 hold Type/Length/Reserved/Prefix-Length for a 0-bit prefix), and no larger
 than 20 (to hold Type/Length/Reserved/Prefix-Length for a 128-bit prefix)
 
   Prefix-Length - the length of the prefix being delegated, in bits. At
 least 0 and no larger than 128 bits (identifying a single IPv6 address).
 
 I'm guessing, and if you are actually saying something else, I don't know
 what it could be :-)
 
 - Does Reserved - Always set to zero ever get validated as zero by a
 receiver?
 
 - I completely missed the three-line, two-row table at the end of Section
 3. If you could at least indent it, and maybe even draw ASCII boxes around
 it, the specification would be much easier to grok.
 
 - It would also be nice to have a pointer to a reference for the definition
 of Framed-IPv6-Prefix in Section 3, but that's extremely minor.
 
 Please look at these comments along with any other Last Call comments you
 may  receive.
 
 Thanks,
 
 Spencer Dawkins 

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

[Gen-art] Re: Gen-ART review of draft-ietf-dhc-pxe-options-02.txt

2006-01-17 Thread Ralph Droms

Spencer - It turns out this draft has a *very* long history.  It is intended
to document the use of some optinos that date back to a time when IANA
handed out options codes for DHCP options *before* the defining RFC was
published.  The current process for assigning option codes is defined in RFC
2939.

The intention, then, for this draft (to be an Informational RFC) is to
document the use of several DHCP options that have been in common use
without a defining RFC for many years.

We could address one of your issues by explicitly telling IANA not to
reassign these codes elsewhere, but I think that issue might have been
addressed in RFC 3679,

And, the option codes that are listed by IANA as tentatively assigned are
in that state as part of the process for extending the DHCPoption code space
in RFC 3924.

I hope that information answers your high-level questions.

I agree with your editorial commentthat the sentence you cite could be more
clearly worded and I'll be happy to revise it.

- Ralph


On 1/14/06 1:40 AM, Spencer Dawkins [EMAIL PROTECTED] wrote:

 I was selected as General Area Review Team reviewer for this specification
 (for background on Gen-ART, please see
 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
 
 Summary: Huh?
 
 If I understand the draft and underlying working group mailing list traffic
 correctly, this is being published as an Informational RFC to say that PXE
 (and, for good measure, Etherboot?) are using DHCP options that aren't
 allocated by IANA. Some of the mailing list postings showed previous
 versions of the draft with IANA considerations, but the current version of
 the draft says there are no IANA considerations.
 
 So, the plan is to publish an Informational document that describes this
 practice, but does not tell IANA not to allocate the hijacked option codes
 for some other use? Oh-kay... although
 http://www.iana.org/assignments/bootp-dhcp-parameters shows the option codes
 as already tentatively allocated (one presumes this was based on version 01
 of this draft).
 
 If this is the plan, the document is close to OK for publication, although I
 expect the RFC Editor would expand acronyms, etc. I thought
 
As options 128-135 are not officially assigned for PXE use (previous
to November 2004 they were considered site-specific options, [6]),
use of these options may conflict with other uses of these options.
 
 was oddly phrased - perhaps the last line should have been something like
 
use of these option values for PXE may conflict with other uses of the
 same options on the same networks.
 
 Thanks,
 
 Spencer Dawkins 

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

51 matches

Mail list logo