[Gen-art] Genart last call review of draft-ietf-detnet-flow-information-model-10

[Jouni Korhonen via Datatracker]

Reviewer: Jouni Korhonen
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-detnet-flow-information-model-??
Reviewer: Jouni Korhonen
Review Date: 2020-09-11
IETF LC End Date: 2020-09-11
IESG Telechat date: Not scheduled for a telechat

Summary:
This informational document is ready for publication with some editorial nits.

Major issues:
None.

Minor issues:
None.

Nits/editorial comments:

1) Line 210:   remove the excess full stop after "Section 6"
2) Section 1.1 lines 221 to 226. I do not see a reason to the intro text here..
It will read odd after a while when things move on. I recommend leaving only
the following text with some rewording:
  "Therefore, the DetNet flow and service
information models described in this document are based on
[IEEE8021Qcc], which is an amendment to [IEEE8021Q].
This document specifies flow and service information models only."
3) Line 853: YANG is referred without a reference. In general, the YANG model
gets mentioned for the first time in the summary as "These models are used as
input for the YANG model". That came a bit out of sudden here and a some more
context would be nice to have.


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

[Gen-art] Genart last call review of draft-ietf-isis-te-app-13

[Jouni Korhonen via Datatracker]

Reviewer: Jouni Korhonen
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-isis-te-app-??
Reviewer: Jouni Korhonen
Review Date: 2020-05-29
IETF LC End Date: 2020-05-29
IESG Telechat date: Not scheduled for a telechat

Summary:

Not really my area of expertise, however, I did not spot any issues during the
review. The document is ready for publication.

Major issues:

None.

Minor issues:

None.

Nits/editorial comments:

* There are spacing issues mostly with parenthesis in the text that the RFC
editor likely takes care of. * On line 165 SR is used without expanding it. The
expansion is obvious but the RFC has both "Segment Routing" and "Shared Risk"
used with SRxx.. * At least Section 5 has "is NOT" and "does NOT" emphasis
used. I would use just "is not" and "does not", since those with "NOT" are not
in listed in normal "Requirements Language".


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

[Gen-art] Genart last call review of draft-ietf-idr-bgp-ls-segment-routing-msd-16

[Jouni Korhonen via Datatracker]

Reviewer: Jouni Korhonen
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-idr-bgp-ls-segment-routing-msd-??
Reviewer: Jouni Korhonen
Review Date: 2020-04-16
IETF LC End Date: 2020-04-17
IESG Telechat date: Not scheduled for a telechat

Summary: The document is ready for publication as a standards track document.

Major issues: none.

Minor issues: none.

Nits/editorial comments: IDnits complain about lines too long i.e. the table in
the IANA considerations section. That should be corrected and I checked there
is enough space to cut the required 8 chars.



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

[Gen-art] Genart last call review of draft-nottingham-how-did-that-get-into-the-repo-01

[Jouni Korhonen via Datatracker]

Reviewer: Jouni Korhonen
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-nottingham-how-did-that-get-into-the-repo-??
Reviewer: Jouni Korhonen
Review Date: 2020-03-08
IETF LC End Date: 2020-03-12
IESG Telechat date: Not scheduled for a telechat

Summary:
This very needed document is ready for publication as an Informational RFC with
few minor nits.

Major issues:
None.

Minor issues:
1) Line 116-117 states "This document uses ABNF [RFC5234], including by
reference the  following rules: ALPHA, DIGIT." Why RFC5234 APLHA and DIGIT
rules need to be specifically called out?

Nits/editorial comments:
1) Line 106   s/ike/like
2) Line 106  Expand CSRF on the first use (and possibly give an informative
reference to it).



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

[Gen-art] Genart last call review of draft-ietf-dnsop-rfc2845bis-06

[Jouni Korhonen via Datatracker]

Reviewer: Jouni Korhonen
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-dnsop-rfc2845bis-??
Reviewer: Jouni Korhonen
Review Date: 2020-01-21
IETF LC End Date: 2020-01-21
IESG Telechat date: Not scheduled for a telechat

Summary:

This document was well written and easy read. I found no complaints. There are
bogus IDNits warnings for "non-RFC2606-compliant FQDNs".

Major issues:

None.

Minor issues:

None.

Nits/editorial comments:

1) The sentence in lines 248-250 was hard to parse in the first few reads. I
suggest rewording... somehow. It was like this in RFC2845 already, though.

248If hosts A.site.example and B.example.net share a key,
249  possibilities for the key name include .A.site.example,
250  .B.example.net, and .A.site.example.B.example.net.


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

[Gen-art] Genart last call review of draft-ietf-tokbind-protocol-16

[Jouni Korhonen]

Reviewer: Jouni Korhonen
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-tokbind-protocol-??
Reviewer: Jouni Korhonen
Review Date: 2017-11-30
IETF LC End Date: 2017-11-27
IESG Telechat date: Not scheduled for a telechat

Summary: Ready to go. I am not an expert on this field thus my review was
rather superficial. Reading the document through did not raise any alarms.

Major issues: None spotted.

Minor issues: None.

Nits/editorial comments:  IDnist result was good (outdated references are
non-issues).


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

[Gen-art] Genart telechat review of draft-ietf-ccamp-ospf-availability-extension-10

[Jouni Korhonen]

Reviewer: Jouni Korhonen
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-ccamp-ospf-availability-extension-??
Reviewer: Jouni Korhonen
Review Date: 2017-10-11
IETF LC End Date: 2016-10-24
IESG Telechat date: 2017-10-12

Summary: Ready to go. My earlier comments are reflected and I am happy with the
outcome (and resulted to publication of [GSCSI]).

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] Genart telechat review of draft-ietf-curdle-cms-eddsa-signatures-07

[Jouni Korhonen]

Reviewer: Jouni Korhonen
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-curdle-cms-eddsa-signatures-??
Reviewer: Jouni Korhonen
Review Date: 2017-10-10
IETF LC End Date: 2017-07-25
IESG Telechat date: 2017-10-12

Summary: Ready to go. My only editorial comment was even reflected. Thanks!

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] Genart telechat review of draft-ietf-ippm-6man-pdm-option-09

[Jouni Korhonen]

Reviewer: Jouni Korhonen
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-ippm-6man-pdm-option-??
Reviewer: Jouni Korhonen
Review Date: 2017-03-31
IETF LC End Date: 2016-09-28
IESG Telechat date: 2017-04-13

Summary: Ready for publication. I did review earlier version of the
document and the comments I raised back them have now been addressed
to an adequate level. 

Major issues: None.

Minor issues: None.

Nits/editorial comments:  None.


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

Re: [Gen-art] New Version Notification for draft-ietf-ippm-6man-pdm-option-09.txt

[jouni korhonen]

Thanks. I am OK with the new version. Thank you for going through this nits 
tweaking ;)

- Jouni

> On Mar 13, 2017, at 4:55 AM, nalini.elk...@insidethestack.com wrote:
> 
> All,
> 
> We believe that all comments have now been addressed with this new draft.   
> Please let us know if there are any other issues.
> 
> Thanks,
> 
> Nalini Elkins
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
> 
> 
> On Mon, 3/13/17, internet-dra...@ietf.org  wrote:
> 
> Subject: New Version Notification for draft-ietf-ippm-6man-pdm-option-09.txt
> To: "Rob Hamilton" , ippm-cha...@ietf.org, "Robert M. 
> Hamilton" , "mackerm...@bcbsm.com" , 
> "Nalini Elkins" , "Michael S. Ackermann" 
> 
> Date: Monday, March 13, 2017, 4:48 AM
> 
> 
> A new version of I-D,
> draft-ietf-ippm-6man-pdm-option-09.txt
> has been successfully submitted by Nalini Elkins and posted
> to the
> IETF repository.
> 
> Name:   
> draft-ietf-ippm-6man-pdm-option
> Revision:09
> Title:IPv6 Performance
> and Diagnostic Metrics (PDM) Destination Option
> Document date:2017-03-13
> Group:ippm
> Pages:31
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-ippm-6man-pdm-option-09.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-09
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-09
> 
> Abstract:
>To assess performance problems, 
> measurements based on optional
>sequence numbers and timing may be
> embedded in each packet.  Such
>measurements may be interpreted in
> real-time or after the fact. An
>implementation of the existing IPv6
> Destination Options extension
>header, the Performance and Diagnostic
> Metrics (PDM) Destination
>Options extension header as well as the
> field limits, calculations,
>and usage of the PDM in measurement are
> included in this document.
> 
>
>
>
>
>
>   
> 
> 
> Please note that it may take a couple of minutes from the
> time of submission
> until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> ___
> 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-ippm-6man-pdm-option: Minor and editorial

[jouni korhonen]

Hi,

The text with Al’s revisions are looking good. I did some further editing & 
proposals to it - see below. The text is not exactly to a precision I was 
hoping for but I guess that when PDM gets used the actual test setup/profile 
would define & mandate a certain observing location.

3.5.2  PDM Timestamps

The PDM timestamps are intended to isolate wire time from server or host time, 
but may necessarily attribute some
host processing time to network latency.

RFC2330 [RFC2330] "Framework for IP Performance Metrics” describes two notions 
of wire time in section 10.2.
These notions are only defined in terms of an Internet host H observing an 
Internet link L at a particular location:

 +For a given IP packet P, the 'wire arrival time' of P at H on L is
  the first time T at which any bit of P has appeared at H's
  observational position on L.

 +For a given IP packet P, the 'wire exit time’ of P at H on L is the
  first time T at which all the bits of P have appeared at H's
  observational position on L.”

This specification does not define the exact H’s observing position on L. That 
is left for the deployment setups to define. However, the position where PDM 
timestamps are taken SHOULD be as close to the physical network interface as 
possible.  Not all implementations will be able to achieve the ideal level of 
measurement.

- Jouni


> On Mar 10, 2017, at 7:13 AM, nalini.elk...@insidethestack.com wrote:
> 
> Al,
> 
> Love it!!!
> 
> Jouni?   Anyone else?
> 
> Thanks so much, Al.   What would I do without you?
> 
> Nalini Elkins
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
> 
> 
> On Fri, 3/10/17, MORTON, ALFRED C (AL)  wrote:
> 
> Subject: RE: Gen-ART review of draft-ietf-ippm-6man-pdm-option:  Minor and 
> editorial
> To: "nalini.elk...@insidethestack.com" , 
> "jouni.nospam" 
> Cc: "General Area Review Team" , 
> "draft-ietf-ippm-6man-pdm-option@ietf.org" 
> , "Michael Ackermann" 
> , "Robert Hamilton" 
> Date: Friday, March 10, 2017, 7:05 AM
> 
> Hi Nalini,
> 
> Let me suggest a few quick clarifications in a top-post:
> 
> I liked your original first sentence, with the SHOULD,
> that's really all we can ask. The last sentence was 
> quite practical, too.
> 
> Also, wiretime is a concept/notion, the ideal we try
> to get close to achieving in practice. And we need to 
> say what H and L are, so, here's my proposal...
> 
> Re-Revised Section 3.5.2
> 
> 
> 3.5.2  PDM Timestamps
> 
> The PDM timestamps SHOULD be taken as close to the
> network interface as possible.
> The PDM timestamps are intended to isolate wire time from
> server or host time, but may necessarily attribute some
> host processing time to network latency.
> 
> RFC2330 [RFC2330] "Framework for IP Performance Metrics"
> describes two notions of wire time in section 10.2.
> These notions are only defined in terms of an Internet host
> H 
> observing an Internet link L at a particular location:
> 
>  +For a given packet P, the 'wire arrival
> time' of P at H on L is
>   the first time T at which any bit of P
> has appeared at H's
>   observational position on L.
> 
>  +For a given packet P, the 'wire exit time'
> of P at H on L is the
>   first time T at which all the bits of P
> have appeared at H's
>   observational position on L."
> 
> Not all implementations will be able to achieve the
> ideal level of measurement.
> 
> Al
> 
>> -Original Message-
>> From: nalini.elk...@insidethestack.com
>> [mailto:nalini.elk...@insidethestack.com]
>> Sent: Friday, March 10, 2017 9:44 AM
>> To: nalini.elk...@insidethestack.com;
> jouni.nospam; MORTON, ALFRED C
>> (AL)
>> Cc: General Area Review Team;
> draft-ietf-ippm-6man-pdm-
>> option@ietf.org;
> Michael Ackermann; Robert Hamilton
>> Subject: RE: Gen-ART review of
> draft-ietf-ippm-6man-pdm-option: Minor
>> and editorial
>> 
>> Al,
>> 
>> I should have remembered that from RFC2330!
>> 
>> Thanks for pointing that out.  My revised wording
> inline.
>> 
>> Nalini
>> 
>> 
>> On Fri, 3/10/17, MORTON, ALFRED C (AL) 
> wrote:
>> 
>>   Subject: RE: Gen-ART review of
> draft-ietf-ippm-6man-pdm-option:  Minor
>> and editorial
>>   To: "nalini.elk...@insidethestack.com"
>> ,
> "jouni.nospam"
>> 
>>   Cc: "General Area Review Team" ,
> "draft-ietf-ippm-
>> 6man-pdm-option@ietf.org"
> > option@ietf.org>,
> "Michael Ackermann" ,
>> "Robert Hamilton" 
>>   Date: Friday, March 10, 2017, 6:21 AM
>> 
>>   > -Original Message-
>>   > From: nalini.elk...@insidethestack.com
>>   > 

[Gen-art] Review of draft-ietf-ccamp-ospf-availability-extension-09

[Jouni Korhonen]

Reviewer: Jouni Korhonen
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-ccamp-ospf-availability-extension-??
Reviewer: Jouni Korhonen
Review Date: 2017-02-21
IETF LC End Date: 2016-10-24
IESG Telechat date: 2017-03-16

Summary:

I have reviewed two earlier versions of this document. All my comments
have been addressed. I am also happy to see my earlier comments
generated (I believe) a draft addressing the generalized SCSI TLV
specification work in TEAS, and this draft referencing to that work.

Major issues:

none.

Minor issues:

none.

Nits/editorial comments: 

There are minor editorials here and there, but those will be picked up
by the RFC editor in any case.

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

[Gen-art] Review of draft-ietf-pals-mpls-tp-dual-homing-coordination-05

[Jouni Korhonen]

Reviewer: Jouni Korhonen
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-pals-mpls-tp-dual-homing-coordination-??
Reviewer: Jouni Korhonen
Review Date: 2017-02-13
IETF LC End Date: 2017-02-13
IESG Telechat date: 2017-03-02

Summary:

The document is ready. I have few questions, though, that most likely
are obvious to the document authors and to the WG.

Major issues:

None.

Minor issues:

Not really an issue, but more of thinking out loud. There is no text
in Section 3.2. what happens, say, when PE1 sends DHC+Status TLV and
PE2 sends DHC+Switching TLV both reporting a failure of PW1. I am not
sure if this is a relevant case, but I could expect there can be a
sequence of events that cause these DHC messages to cross between PE1
and PE2?

Nits/editorial comments: 

* The document uses few acronyms without expanding them. Those should
be checked.

* In Section 3.2.  s/table 1 ./Table 1.

*  There are multiple occurrences of "table 1" that should be "Table
1".
   There are multiple occurrences of "figure 5" that should be "Figure
5".
   There are multiple occurrences of "figure 1" that should be "Figure
1".

* Section 3.2. says "..using the DHC message above." Since the message
is quite a bit above I would rewrite this as "..using the DHC message
defined in Section 3.1."

* Section 3.2. protection procedures would greatly benefit
clarity/readability having one or two signaling flow figures assisting
the textual description how the PW failures are signaled between the
PEs (using the DHCs and sometimes assisted with OAM messaging).

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

[Gen-art] Review of draft-elie-nntp-tls-recommendations-04

[Jouni Korhonen]

Reviewer: Jouni Korhonen
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-elie-nntp-tls-recommendations-??
Reviewer: Jouni Korhonen
Review Date: 2017-01-15
IETF LC End Date: 2016-12-26
IESG Telechat date: 2017-01-19

Summary: ready

Major issues: None.

Minor issues: None.

Nits/editorial comments: 

I have reviewed earlier versions of this document and the comments I
had then have been addresses. I have no issues from my side.

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

[Gen-art] Review of draft-elie-nntp-tls-recommendations-03

[Jouni Korhonen]

Reviewer: Jouni Korhonen
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-elie-nntp-tls-recommendations-??
Reviewer: Jouni Korhonen
Review Date: 2017-01-04
IETF LC End Date: 2016-12-26
IESG Telechat date: 2017-01-19

Summary: Ready

(I did review the -00 version and my comment have been already
addressed in -01)

Major issues: None

Minor issues: None

Nits/editorial comments: 

For the consistency Section 1.2. Author's note should probably be also
tagged and explained how the RFC Editor is supposed to handle it. I
assume Section 1.2. will be removed from the final publication.





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

[Gen-art] Review of draft-ietf-ccamp-ospf-availability-extension-08

[Jouni Korhonen]

Reviewer: Jouni Korhonen
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-ccamp-ospf-availability-extension-??
Reviewer: Jouni Korhonen
Review Date: 2016-12-29
IETF LC End Date: 2016-10-24
IESG Telechat date: 2017-02-16

Summary: Ready for publication.

Major issues: None.

Minor issues: None.

Nits/editorial comments: 

I reviewed -07 version of the document. The issue I raised back then
has been addressed in an adequate level.
There are still editorial nits in the document like:

* Section 2:
   "include a< availability, bandwidth> information list in its OSPF"
   where the "a<" is somewhat confusing..
* Section 2:
   "node(s).The setup"
   which misses a space. 

However, these nits and alike can be corrected by the RFC Editor.


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

[Gen-art] Gen-ART review of

[jouni korhonen]

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>.

Document: draft-ietf-ippm-6man-pdm-option-05
Reviewer: Jouni Korhonen
Review Date: 9/23/2016
IETF LC End Date: 2016-09-28
IESG Telechat date: (if known)

Summary: The draft needs some work.

Major issues:

I have two technical issues here:

1) There is no mention of what is the time reference plane for internal
time stamping. All other timing and synchronization related documents I am
aware of (at least outside IETF) describe it very clearly where in the
processing/packet handling the time stamp is to be taken. Now the document
gives me no idea as an implementer where that should take place. At least
it makes it hard to calculate the *network* RTT precisely.

2) The PDM option relation to actual "server" time is somewhat confusing
and the 5-tuple does not allow me to detect the real relationship between
the server/application action that caused the generation of the packet and
the PDM within the packet. This is specifically an issue with
transport/application protocols that multiplex/interleave multiple
application streams into one transport. I have no idea of the actual
individual application time since the packets get generated independent of
the processing of a single thread. I would welcome some discussion around
here. Section 1.4 last paragraph is going to this direction but is not
sufficient IMHO.

Minor issues:

1) This is a larger editorial issue. The document is far too long with a
lot of repetition considering it describes only one IPv6 destination
option. It is a writing style issue and I am fully aware of that. I have
proposals how to cut text in the editorial comments section.

2) Section 1.2 3rd paragraph talks about IoT and that speed matters there.
I find this too generalized statement. There are many other things that
matter in this application domain and speed might not be that important as
being able to send/receive that one to two bytes of data in a given time
window. I suggest removing this paragraph.

Nits/editorial comments:

1) Section 1.4 numbered list: add missing full stops.

2) Section 3.2: remove
  "The 5-tuple consists of
   the source and destination IP addresses, the source and destination
   ports, and the upper layer protocol (ex. TCP, ICMP, etc)."
since this is unnecessary repetition.

3) Section 3.2: remove
  "Operating systems MUST NOT implement a single
   counter for all connections."
Seems again like unnecessary repetition to previous sentence.

4) Section 3.2 again unnecessary repetition of IPv6 basics that can be read
from RFC2460. Suggest strongly to remove:
  "This indicates the
   following processing requirements:

   00 - skip over this option and continue processing the header.

   RFC2460 [RFC2460] defines other values for the Option Type field.
   These MUST NOT be used in the PDM."

and

  "The
   possible values are as follows:

   0 - Option Data does not change en-route

   1 - Option Data may change en-route

   The three high-order bits described above are to be treated as part
   of the Option Type, not independent of the Option Type.  That is, a
   particular option is identified by a full 8-bit Option Type, not just
   the low-order 5 bits of an Option Type."

5) Section 3.3 same as in comment 4). Suggest strongly removing:
  "This follows the order defined in RFC2460 [RFC2460]
 IPv6 header

 Hop-by-Hop Options header

 Destination Options header  <

 Routing header

 Fragment header

 Authentication header

 Encapsulating Security Payload header

 Destination Options header <

 upper-layer header"

6) Suggest removing entire Section 3.4 and moving the following text to
Section 3.3:
  "PDM MUST be placed before the ESP header in
   order to work.  If placed before the ESP header, the PDM header will
   flow in the clear over the network thus allowing gathering of
   performance and diagnostic data without sacrificing security."

7) Section 3.6 suggest removing the following text. I see no value it would
add to what has already been said:
  "As with all other destination options extension headers, the PDM is
   for destination nodes only. As specified above, intermediate devices
   MUST neither set nor modify this field."

8) Section 3.6 suggest removing the following 5-tuple text as it has
already been described earlier in Section 2:
  "The 5-tuple is:

   SADDR : IP address of the sender SPORT : Port for sender DADDR : IP
 

Re: [Gen-art] Gen-Art review of draft-ietf-6man-ipv6-mibs-obsolete-01

[Jouni Korhonen]

see inline.

8/29/2016, 2:45 PM, Bill Fenner kirjoitti:

On Aug 29, 2016, at 4:25 PM, Jouni Korhonen <jouni.nos...@gmail.com> wrote:


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

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

Document: draft-ietf-6man-ipv6-mibs-obsolete-01
Reviewer: Jouni Korhonen
Review Date: 8/29/2016
IETF LC End Date: 2016-08-24
IESG Telechat date: 2016-09-01

Summary: Ready with nits. Note. I did not run these MIBs through
 any verification tools.

Major issues: None.

Minor issues:
* The document does not pass IDnits. The only complaint of IDnits that
 I am concerned of is:
 "** The document seems to lack an Introduction section."

 Anyway, if Motivation section is considered equivalent to
 Introduction section then I am fine and the IDnits complaints
 can be neglected all together.


That was my intention.


Ok. WFM if it also works for others in the publication process.


* Other MIB modules than IPV6-TC has in each their DESCRIPTIONs
 text saying by what it was obsoleted. Unless I am missing something
 here (that justifies the absence of disclaimers) I would like to see
 similar text in each IPV6-TC DESCRIPTION as well.


I overlooked that RFC2579 actually requires the same thing for textual 
conventions as RFC2578 requires for object revisions. Thanks for catching this.


Good.

- Jouni




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



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

[Gen-art] Gen-Art review of draft-ietf-6man-ipv6-mibs-obsolete-01

[Jouni Korhonen]

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>.

Document: draft-ietf-6man-ipv6-mibs-obsolete-01
Reviewer: Jouni Korhonen
Review Date: 8/29/2016
IETF LC End Date: 2016-08-24
IESG Telechat date: 2016-09-01

Summary: Ready with nits. Note. I did not run these MIBs through
  any verification tools.

Major issues: None.

Minor issues:
* The document does not pass IDnits. The only complaint of IDnits that
  I am concerned of is:
  "** The document seems to lack an Introduction section."

  Anyway, if Motivation section is considered equivalent to
  Introduction section then I am fine and the IDnits complaints
  can be neglected all together.

* Other MIB modules than IPV6-TC has in each their DESCRIPTIONs
  text saying by what it was obsoleted. Unless I am missing something
  here (that justifies the absence of disclaimers) I would like to see
  similar text in each IPV6-TC DESCRIPTION as well.

Nits/editorial comments:
* Line 2223 has unnecessary linefeed/empty line.

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

Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

[Jouni Korhonen]

bit odd discussing NATs in the specific context of 
IPv6. If
  you have a specific IPv6 NAT scenario in mind either spell it out or give a 
reference
  to a specification that describes the technology/use case.


Section 7.1 is not about NATs in general - it's about middlebox interactions 
with

UDP zero checksums for IPv6.   This discussion is necessitated by RFC 6936's
discussion of middleboxes, and needs to remain in about its current form for 
that
reason.

I mean the following here. Section 7.1 starts off:

  "IPv6 datagrams with a zero UDP..”

Then few lines later:

  "updates the UDP checksum field, such as NATs or firewalls."

I get really itchy bringing NAT even into examples in IPv6 context. We do have
RFC6296 NPTv6, which is checksum neutral. If there are other IPv6 NAT thingies 
in
mind here, I would be explicit or just leave the NAT out.




o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section 5 of RFC 6936
  How is this “MUST” enforced?


The same as any other "MUST" in this draft - those four are implementation

requirements for GRE-in-UDP implementations - the requirements have been
referenced instead of copied.

Ok. It seem I misunderstood this slightly wrong. I was more thinking middleboxes
on path that are not my implementations and how to enforce the MUST on those
e.g., cases where there is a middlebox that does not obey the MUST but still
seems to work ok.

One more question. How do I MUST a MAY requirement (RFC6936 Section 5 req.
#9)?




o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not known 
to be
  congestion-controlled.. I would be interested in knowing how to enforce this 
“MUST”
  specifically in the Internet case.


In contrast, this is effectively a rhetorical question - there is no plausible

protocol mechanism to enforce this, as a Congestion-Controlled header flag is
about as realistic as the Evil header flag - see RFC 3514, taking notion of its
publication date.   Hmm ... is this C-C header flag a candidate for next April 
;-) ??
Applicability restrictions on deployment/usage are generally not enforceable via
technical means - all we can say is that a deployment that does not comply with
the applicability restrictions is not compliant with the RFC.

Ok. Knowing this MUST has no meaning is real world I would then consider not
having the MUST here.. that would be a waste of precious capital letters ;)
Seriously, if one cannot control it or even know whether some traffic is
congestion controlled beyond a generic assumption state in previous sentence I
see no need for RFC2119 language here.

Thanks,
Jouni




Thanks, --David


-Original Message-
From: Jouni [mailto:jouni.nos...@gmail.com]
Sent: Friday, August 12, 2016 2:51 AM
To: gen-art@ietf.org (gen-art@ietf.org); draft-ietf-tsvwg-gre-in-udp-
encap@ietf.org
Subject: Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

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-tsvwg-gre-in-udp-encap-16
Reviewer: Jouni Korhonen
Review Date: 8/11/2016
IETF LC End Date: 2016-08-12
IESG Telechat date: (if known)

Summary:  Ready with minor nits.

Major issues: None.

Minor issues: Read on..

Editorials/nits:
o My “complaint” of this document is basically on the following.. these are
writing
  style things so feel free to neglect:
  - It repeats.. the same statements multiple times.
  - When reading the document I get the feeling it is actually two documents.

The

technical specification (which is very short) and the general deployment
considerations document. I would have split it to two but that is just me.

The other nits.

o There are bunch of acronyms that are not expanded either never or on their

first use.

  Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention

to these.

o In the Introduction give a reference to EtherType e.g., the repository where

they

  are maintained or by whom they are maintained.
o On line 129 is says:
   This document specifies GRE-in-UDP tunnel requirements for two
  Based on the earlier text I would suggest saying “..document also specifies..”
o On line 143 I would also (following the previous style in the paragraph)

capitalize

  “wide area networks” as well.
o In multiple places (lines 236, 887) the reference is after the full stop. 
Place

full

  stop after the reference.
o The document uses both tunnel ingress/egress and
encapsulator/decapsulator. Is there a
  specific reason to have this differentiation? If not use common terminology

throughout

  the document.
o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section

Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

[Jouni Korhonen]

Hi Lucy,

See inline ;)

8/12/2016, 2:10 PM, Lucy yong kirjoitti:

Hi Jouni,

OOPS, forget this one, sorry.

o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
Lucy: perhaps some can reference previous section.


See my response to Davin on this. Basically, when you say "this document 
specifies.." etc do not spread that to multiple paragraphs and sections. 
Keep them in one place and not in increamental style spread around.



   - When reading the document I get the feeling it is actually two documents. 
The
 technical specification (which is very short) and the general deployment
 considerations document. I would have split it to two but that is just me.
Lucy: When we were developing this document, we kindly became clear ourselves, 
we need to address two parts and want to do in one document.


There's definitely wordsmithing to do here. Now the "guidelines" and 
protocol specification (the very short one) and kind of mixed, which to 
me makes reading a bit confusing experience. If you want to keep all in 
one document, it is fine by me. I was just expressing my personal 
opinion on structuring.


- JOuni



Regards,
Lucy



-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni
Sent: Friday, August 12, 2016 1:51 AM
To: gen-art@ietf.org (gen-art@ietf.org); 
draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

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-tsvwg-gre-in-udp-encap-16
Reviewer: Jouni Korhonen
Review Date: 8/11/2016
IETF LC End Date: 2016-08-12
IESG Telechat date: (if known)

Summary:  Ready with minor nits.

Major issues: None.

Minor issues: Read on..

Editorials/nits:
 o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
   - When reading the document I get the feeling it is actually two documents. 
The
 technical specification (which is very short) and the general deployment
 considerations document. I would have split it to two but that is just me.

The other nits.

 o There are bunch of acronyms that are not expanded either never or on their 
first use.
   Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
these.
 o In the Introduction give a reference to EtherType e.g., the repository where 
they
   are maintained or by whom they are maintained.
 o On line 129 is says:
   This document specifies GRE-in-UDP tunnel requirements for two
   Based on the earlier text I would suggest saying “..document also 
specifies..”
 o On line 143 I would also (following the previous style in the paragraph) 
capitalize
   “wide area networks” as well.
 o In multiple places (lines 236, 887) the reference is after the full stop. 
Place full
   stop after the reference.
 o The document uses both tunnel ingress/egress and encapsulator/decapsulator. 
Is there a
   specific reason to have this differentiation? If not use common terminology 
throughout
   the document.
 o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section 5 of
   How is this “MUST” enforced?
 o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
of IPv6. If
   you have a specific IPv6 NAT scenario in mind either spell it out or give a 
reference
   to a specification that describes the technology/use case.
 o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not 
known to be
   congestion-controlled.. I would be interested in knowing how to enforce this 
“MUST”
   specifically in the Internet case.
 o Line 909 typo “ether” -> “either”.

___
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] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

[Jouni Korhonen]

Hi Lucy,

Thank you for the response. Sorry for my slow response. I tried to be on 
a vacation last week/weekend so my checking of emails was sparse at best 
;) See inline.


8/12/2016, 1:51 PM, Lucy yong kirjoitti:

Hi Jouni,

Thank you for the review and correction. Pls see inline below.

-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni
Sent: Friday, August 12, 2016 1:51 AM
To: gen-art@ietf.org (gen-art@ietf.org); 
draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

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-tsvwg-gre-in-udp-encap-16
Reviewer: Jouni Korhonen
Review Date: 8/11/2016
IETF LC End Date: 2016-08-12
IESG Telechat date: (if known)

Summary:  Ready with minor nits.

Major issues: None.

Minor issues: Read on..

Editorials/nits:
 o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
   - When reading the document I get the feeling it is actually two documents. 
The
 technical specification (which is very short) and the general deployment
 considerations document. I would have split it to two but that is just me.

The other nits.

 o There are bunch of acronyms that are not expanded either never or on their 
first use.
   Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
these.
[Lucy] I will check.
 o In the Introduction give a reference to EtherType e.g., the repository where 
they
   are maintained or by whom they are maintained.
[Lucy] I will put RFC7042 as the reference.


Or maybe  http://standards.ieee.org/regauth/ethertype/eth.txt
Either one works.


 o On line 129 is says:
   This document specifies GRE-in-UDP tunnel requirements for two
   Based on the earlier text I would suggest saying “..document also 
specifies..”
[Lucy] ack.
 o On line 143 I would also (following the previous style in the paragraph) 
capitalize
   “wide area networks” as well.
[Lucy] ack.
 o In multiple places (lines 236, 887) the reference is after the full stop. 
Place full
   stop after the reference.
[Lucy] My mistake. Will correct them.
 o The document uses both tunnel ingress/egress and encapsulator/decapsulator. 
Is there a
   specific reason to have this differentiation? If not use common terminology 
throughout
   the document.
[Lucy] I would prefer to use two teams in the document. Tunnel ingress and 
egress is the view from network perspective,
And encapsulator/decapsulator is the view at the ingress or egress. E.g. it is 
odd to say encapsulator IP address. I open to add a clarification if that 
causes a concern.


Maybe you should say this also in the draft?



 o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section 5 of
   How is this “MUST” enforced?
[Lucy] Do you concern on the wording or the implementation?


See the discussion I had with David.



 o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
of IPv6. If
   you have a specific IPv6 NAT scenario in mind either spell it out or give a 
reference
   to a specification that describes the technology/use case.
[Lucy] This section describes middlebox specialty on IPv6 traffic. Most UDP 
applications do not perform UDP checksum in IPv4 network; most UDP applications 
perform UDP checksum in IPv6 network because of IPv6 requirement [RFC2460]. 
Thus some middleboxes validate UDP checksum if it is in IPv6. [RFC6935] 
[RFC6936] relax the need to perform UDP checksum in some special cases, which 
is applicable to this draft. But we need to state out the potential impact that 
is specific in IPv6.


Here as well, see the discussion I had with David.


 o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not 
known to be
   congestion-controlled.. I would be interested in knowing how to enforce this 
“MUST”
   specifically in the Internet case.
[Lucy] By IETF standard. :)  How about replace "MUST NOT" with "are not 
appropriate"? (match the wording in requirement 3 of Section 2.1.1)


Again, we did some more elaborations with David. Anyway, one concern I 
had was on having MUSTs on things that you cannot really guard or 
control using some protocol.. they are more like deployment 
recommendations or good wishes at best then.. which I think do not 
belong to a protocol spec.


- JOuni


 o Line 909 typo “ether” -> “either”.
[Lucy] ack. Thx.

Regards,
Lucy

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

[Gen-art] Gen-Art review of draft-ietf-hip-rfc5205-bis-09

[Jouni Korhonen]

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>.

Document: draft-ietf-hip-rfc5205-bis-09
Reviewer: Jouni Korhonen
Review Date: 7/6/2016
IETF LC End Date: 15-12-28
IESG Telechat date: 7/7/2016

Summary: Ready for publication.

Major issues: None.

Minor issues: None.

Nits/editorial comments:  KI reviewed the -08 version of this document 
earlier. Comments raised then have been addressed.


___
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-dime-e2e-sec-req-04.txt

[Jouni Korhonen]

Thanks Christer,

And sorry for not responding earlier.. See my comments inline.

5/7/2016, 7:48 AM, Christer Holmberg kirjoitti:



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




Document: draft-ietf-dime-e2e-sec-req-04

Reviewer:Christer Holmberg

Review Date:7 May2016

IETF LC End Date:12 April 2016

IETF Telechat Date:N/A

Summary:  The document is well
written, and almost ready for publication is informational RFC. However,
I have a few editorial issues, related to the Introduction, that I ask
the authors to address.

Major Issues:None

Minor Issues:None

Editorial Issues:



Q_ABSTRACT_1:



The text says that the draft “discusses” requirements. In my opinion it
should say “defines” or “specifies”.


Ack. "specifies" sounds as a good choice.



Q_INTRODUCTION_1:

Please add references for TLS (for TCP) and DTLS (for SCTP).



Ack.



Q_INTRODUCTION_2:

The text says: “…or alternative security mechanisms independent of
Diameter (e.g., IPsec) is used.”

2A: I guess it should be “are used”?



Yes.. the whole sentence IMO reads badly, so I have some overall 
rewording proposals.


OLD:
   The Diameter base protocol specification [2] offers security
   protection between neighboring Diameter peers and mandates that peer
   connections must be protected by TLS (for TCP), DTLS (for SCTP) or
   alternative security mechanisms independent of Diameter (e.g., IPsec)
   is used.

NEW:
   The Diameter base protocol specification [RFC6733] defineds security
   protection between neighboring Diameter peers. The Diameter
   mandates that peer connections must be protected by TLS [RFC5246]
   (for TCP), DTLS [RFC6083] (for SCTP) or using security mechanisms
   that are independent of Diameter such as IPsec [RFC4301].


2B: I am not sure I understand what “independent of Diameter” means.



It is actually quite direct quotation from base protocol RFC6733 text. 
Basically meaning when using (D)TLS the Diameter node itself has to 
implement/terminate the security, while with IPsec it does not 
necessarily need to do anything (e.g., when site-to-site IPsec is in 
place).





Q_INTRODUCTION_3:

The text talks about security between non-neighbour nodes, while the
draft name includes “e2e”. However, when reading Section 4,
non-neighbour does not necessarily mean end-to-end. I think it would be
good to explicitly clarify that in the Introduction.



Ok. This terminology issue was brought up also in two other review 
afair. I would actually propose rewording the document name, since that 
seems to be the only place where "e2e" is really misplaced and the 
document name is goofy in any case.


OLD:
Diameter AVP Level Security End-to-End Security: Scenarios and
  Requirements
NEW:
AVP Level Security for Non-neighboring Diameter Nodes: Scenarios and
  Requirements

and also..

OLD:
Diameter End-to-End Security

NEW:
Diameter AVP Level Security



Q_INTRODUCTION_4:

The text says: “This document collects requirements for developing a
solution to protect Diameter AVPs.”

2A: It needs to be clear that it’s about protecting AVPs between
non-neighbour nodes.



Ok.


2B: Instead of “collect”, please use the same terminology as in the
Abstract.


Ok. That will be 'specifies' then.


Q_INTRODUCTION_5:

  Please enhance AVP on first occurrence. Currently it’s not
done until Section 3.



Ack.

Thanks,
Jouni



___
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-core-block-19

[Jouni Korhonen]

Hi Jouni,

Just saying.. the use of NUM was not crystal clear just by reading the 
draft and not having the followed the core block development & 
discussion past few years.


Thanks, 
Jouni

4/27/2016, 2:33 PM, Carsten Bormann kirjoitti:

Hi Jouni,


* The intoduction mentions that the block transfwer can be used for
random access. This is not separately described anywhere in the
documents. Although the operation is more or less trivial I would
appreciate an example or some text there because the Block2 overloads
the NUM value 0 with special meaning (for the cases where the first ever
accessed block is not the block number 0).


The random access operation is not described in this draft, but it is
indeed quite obvious how one would make use of such a capability.
Its use would require some previous understanding between client and
server (possibly gained by the client simply trying out random access).
I'm not sure how NUM=0 is special in this case.


NUM=0 is used in some cases to indicate the desired block size in the
initial request (as I read and understand from the draft.. if that is
not the case then it needs to stated more clearly that it is not the
case). I mean the text in 2.4 and 2.8 for example.


There is definitely a special case for NUM=0 in 2.8 (multicast), but
that is because, for discovery, the client will switch to unicast for
all other blocks.  It doesn't sound reasonable to "discover" a resource
while performing random access to it.

The text in 2.4 is more about the outcome of using Block2 options
properly; here we prefer the wording "first request"/"first response"
because indeed that might be for a block with NUM≠0.

(The special case for NUM≠0 in the last paragraph of 2.10 is about not
creating "holes".)

Grüße, Carsten



___
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-core-block-19

[Jouni Korhonen]

Carsten,

See inline.

4/20/2016, 11:26 PM, Carsten Bormann kirjoitti:



Jouni Korhonen wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

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

Document: draft-ietf-core-block-19
Reviewer: Jouni Korhonen
Review Date: 4/18/2016
IETF LC End Date: 4/12/2016
IESG Telechat date: 4/21/2016

Summary: Ready with nits

Major issues: none.

Minor issues:

* The intoduction mentions that the block transfwer can be used for
random access. This is not separately described anywhere in the
documents. Although the operation is more or less trivial I would
appreciate an example or some text there because the Block2 overloads
the NUM value 0 with special meaning (for the cases where the first ever
accessed block is not the block number 0).


The random access operation is not described in this draft, but it is
indeed quite obvious how one would make use of such a capability.
Its use would require some previous understanding between client and
server (possibly gained by the client simply trying out random access).
I'm not sure how NUM=0 is special in this case.


NUM=0 is used in some cases to indicate the desired block size in the 
initial request (as I read and understand from the draft.. if that is 
not the case then it needs to stated more clearly that it is not the 
case). I mean the text in 2.4 and 2.8 for example.


- Jouni


In any case, I would expect specifications that want to make use of
random access to flesh out any details that would be relevant in their
use case.


Nits/editorial comments:

* There are few issues with capitalization (e.g., section vs Section),
which I believe the RFC Editor will handle without me pointing at them.


They certainly will.  (Also addressed in editor's draft now.)


* The document has a tendency of using long portions of text inside
braces, sometimes even in a middle of a paragraph. I would strongly
suggest either making those part of the normal text flow or a separate
(intended) editor's note if they for some reason cannot be part of the
normal text flow.


Again, I expect the RFC editor to help with the cleanup here.

Grüße, Carsten



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

[Gen-art] Gen-Art review of draft-ietf-core-block-19

[Jouni Korhonen]

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-core-block-19
Reviewer: Jouni Korhonen
Review Date: 4/18/2016
IETF LC End Date: 4/12/2016
IESG Telechat date: 4/21/2016

Summary: Ready with nits

Major issues: none.

Minor issues:

* The intoduction mentions that the block transfwer can be used for 
random access. This is not separately described anywhere in the 
documents. Although the operation is more or less trivial I would 
appreciate an example or some text there because the Block2 overloads 
the NUM value 0 with special meaning (for the cases where the first ever 
accessed block is not the block number 0).


Nits/editorial comments:

* There are few issues with capitalization (e.g., section vs Section), 
which I believe the RFC Editor will handle without me pointing at them.


* The document has a tendency of using long portions of text inside 
braces, sometimes even in a middle of a paragraph. I would strongly 
suggest either making those part of the normal text flow or a separate 
(intended) editor's note if they for some reason cannot be part of the 
normal text flow.


___
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-bao-v6ops-rfc6145bis-05

[Jouni Korhonen]

Hi,

The proposed edits look good to me. Thanks.

- jouni

Sent from a smart phone.. Mind the typos..

On Mar 9, 2016, at 12:40 AM, Xing Li <x...@cernet.edu.cn> wrote:

Hi，Jouni,

Thanks. Please see inline.

Jouni Korhonen 写道:

Comments:

* Lines 480 and 928 have "advertised MTU", which not really immediately
  obvious what it means and where it comes from. I would suggest using
  the exactly same terminology as used in RFC4443 and RFC4884 when
  referring to values taken from those, for example.


Since this draft is a "bis" of RFC6145, which uses the same wording and the
formula is correct, I would perfer to keep the current terminology.



No doubts of the formula. I would still clarify where the “advertised
MTU” is taken from. It is not explicitly stated anywhere or referenced
to some other document.


Got the idea. How about:

474 Code 4 (Fragmentation Needed and DF was Set):  Translate to
475an ICMPv6 Packet Too Big message (Type 2) with Code set
476to 0.  The MTU field MUST be adjusted for the difference
477between the IPv4 and IPv6 header sizes, but MUST NOT be
478set to a value smaller than the minimum IPv6 MTU (1280
479bytes).  That is, it should be set to maximum(1280,
480minimum((MTU value in the Packet Too Big
Message)+20, MTU_of_IPv6_nexthop,
481(MTU_of_IPv4_nexthop)+20)).  Note that if the IPv4 router
482set the MTU field to zero, i.e., the router does not
483implement [RFC1191], then the translator MUST use the
484plateau values specified in [RFC1191] to determine a
485likely path MTU and include that path MTU in the ICMPv6
486packet.  (Use the greatest plateau value that is less
487than the returned Total Length field, but that is larger
488than or equal to 1280.)


922   Packet Too Big (Type 2):  Translate to an ICMPv4 Destination
923  Unreachable (Type 3) with Code 4, and adjust the ICMPv4
924  checksum both to take the type change into account and to
925  exclude the ICMPv6 pseudo-header.  The MTU field MUST be
926  adjusted for the difference between the IPv4 and IPv6 header
927  sizes, taking into account whether or not the packet in error
928  includes a Fragment Header, i.e.,
 minimum((MTU value in the Packet Too Big Message)-20,
929  MTU_of_IPv4_nexthop, (MTU_of_IPv6_nexthop)-20).

  * Line 367: what is the situation when SHOULD takes place i.e., a packet
  with "illegal" source address is not silently discarded? Clarify the
  case.


When translating ICMPv4 Error Messages into ICMPv6, the
"illegal" source address will be translated.



I suggest adding this clarification to the document.



OK.

Best regards,

xing
___
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-bao-v6ops-rfc6145bis-05

[Jouni Korhonen]

Hi,

> On 08 Mar 2016, at 16:27, Xing Li <x...@cernet.edu.cn> wrote:
> 
> Hi, Jouni,
> 
> Thank you very much for your review and comments. Please see inline.
> 
> Jouni Korhonen 写道:
>> 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>. 
>> 
>> General: 
>> 
>> This draft is ready for publication as a Standards Track RFC, but has few 
>> nits I 
>> would like to get clarification first. 
>> 
>> The IDnits throws complains that to me can be fixed by the RFC editor (or 
>> outdated references automatically when a new revision is generated) and the 
>> complaints regarding non-compliant RFC3849 & RFC5737 addresses seem to be 
>> bogus. 
>> 
>> Comments: 
>> 
>> * Lines 480 and 928 have "advertised MTU", which not really immediately 
>>   obvious what it means and where it comes from. I would suggest using 
>>   the exactly same terminology as used in RFC4443 and RFC4884 when 
>>   referring to values taken from those, for example. 
> 
> Since this draft is a "bis" of RFC6145, which uses the same wording and the 
> formula is correct, I would perfer to keep the current terminology.

No doubts of the formula. I would still clarify where the “advertised MTU” is 
taken from. It is not explicitly stated anywhere or referenced to some other 
document.


>> 
>> * Line 367: what is the situation when SHOULD takes place i.e., a packet 
>>   with "illegal" source address is not silently discarded? Clarify the 
>>   case. 
> 
> When translating ICMPv4 Error Messages into ICMPv6, the
> "illegal" source address will be translated.

I suggest adding this clarification to the document.

>  
>> 
>> * Line 367: s/siletly drop/silently discard 
> 
> OK.
> 
>> 
>> * Lines 350, 389-390: payload length is said here to include IPv4 options, 
>>   if present. However, earlier in lines 373-375 it says IPv4 options 
>>   MUST be ignored so options can never be "if present", right? Suggest 
>>   aligning the text for consistency if the options are never present in 
>>   the  translated messages. 
> 
> The IPv4 options cannot be translated to IPv6, but the length of the
> IPv4 options must be counted in order to calculate the correct IPv6 payload 
> length. We will add notes to clarify this in the next version of the document.
> 
>> 
>> * Line 588: what happens to translated IP packet with illegal source 
>>   addresses? Is this the case for SHOULD referred in line 367? 
> In this case, the "illegal" source address will be translated for trouble 
> shooting.
> Yes, this is the case for SHOULD. We will add notes to clarify this in the 
> next 
> version of the document.
>> 
>> - Jouni 
>> 
> Regards,

Looks good.

Thanks,
jouni


> 
> xing
> 

___
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-bao-v6ops-rfc6145bis-05

[Jouni Korhonen]

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>.

General:

This draft is ready for publication as a Standards Track RFC, but has 
few nits I

would like to get clarification first.

The IDnits throws complains that to me can be fixed by the RFC editor (or
outdated references automatically when a new revision is generated) and the
complaints regarding non-compliant RFC3849 & RFC5737 addresses seem to be
bogus.

Comments:

* Lines 480 and 928 have "advertised MTU", which not really immediately
  obvious what it means and where it comes from. I would suggest using
  the exactly same terminology as used in RFC4443 and RFC4884 when
  referring to values taken from those, for example.

* Line 367: what is the situation when SHOULD takes place i.e., a packet
  with "illegal" source address is not silently discarded? Clarify the
  case.

* Line 367: s/siletly drop/silently discard

* Lines 350, 389-390: payload length is said here to include IPv4 options,
  if present. However, earlier in lines 373-375 it says IPv4 options
  MUST be ignored so options can never be "if present", right? Suggest
  aligning the text for consistency if the options are never present in
  the  translated messages.

* Line 588: what happens to translated IP packet with illegal source
  addresses? Is this the case for SHOULD referred in line 367?

- Jouni

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

[Gen-art] Gen-RTP LC review of draft-ietf-hip-rfc5205-bis-08

[Jouni Korhonen]

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-hip-rfc5205-bis-08
Reviewer: Jouni Korhonen
Review Date:2015–12-21
IETF LC End Date: 2015–12-28
IESG Telechat date:

Summary: This draft is ready for publication as a standard track RFC 
with small nits to be corrected.


Major issues: None.

Minor issues:

* The document seems to imply/assume that a DNS query has multiple 
question sections with different QTYPEs. At least the exmaples in lines 
226 and 278 make me read so. I wonder whether this is actually the 
intention. If not, reword/edit accordingly to avoid the confusion. This 
is to avoid known issues when QDCOUNT>1 or have a justification to do so.


* Section 5 and the assiciated HIP RR figure mostly mentions public key 
but not HI anymore. For the clarity I would suggest adding text that the 
public key is the HI as well.



Nits/editorial comments:

* IDnits complains on outdated reference: draft-ietf-hip-rfc5204-bis-06 
but this can be corrected e.g., by the RFC Editor.


* Line 97: s/address\(es\)/addresses

* Line 162: s/obtain/obtains

* Line 163: s/initiate/initiates

* The document sometime uses "initiator" instead of "Initiator" e.g., in 
line 173. Suggest always using "Initiator" when meaning the HIP Initiator.


* API is never expanded.

* Sentence between lines 204-206 is somewhat hard to parse. Suggest 
rewording.


* Line 201: "HIP node (R)" probably means Responder. Suggest actually 
stating that.


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

[Gen-art] Gen_ART review of draft-santesson-auth-context-extension-10

[jouni korhonen]

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-santesson-auth-context-extension-10
Reviewer: Jouni Korhonen
Review Date: Oct-15-2015
IETF LC End Date: Oct-27-2015
IESG Telechat date: not yet


Summary:


Ready for publication as an Informational RFC.

Comments:
-

I do not have deep expertise on the area this I-D covers. Having read it
through and knowing the solution is already deployed for few years I have
no technical comments.

Minor issues/nits:
--

1) IDNits result that need to be addressed:
   ** The abstract seems to contain references ([RFC5280], [SAML]), which it
  shouldn't.  Please replace those with straight textual mentions of the
  documents in question.

2) == Unused Reference: 'RFC5322' is defined on line 416, but no explicit
  reference was found in the text

3) Since this targets Informational RFC I wouldn't mind seeing all references
   except RFC2119 as informational references and not normative. We could argue
   whether RFC2119 language is needed at all (but no strong opinion here).

4) Introduction third paragraph:

   * expand SAML on the first occurrence

   * I would welcome a reference for "SAML federation"

5) Introduction eight paragraph:

   * expand CA on the first occurrence

6) Section 3.1.2:

   * expand OID on the first occurrence (now it comes after the paragraph
 explaining "Ref")

   * three times  s/REF/Ref
___
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-dime-app-design-guide-19

[Jouni Korhonen]

Martin,

We'll check this again. Thanks.

- Jouni





On Jun 17, 2014, at 2:54 AM, Martin Thomson wrote:

 I just read through the diff of -24.  I'm assuming that my feedback
 was lost somewhere.
 
 On 14 September 2013 09:41, Jouni Korhonen jouni...@gmail.com wrote:
 Martin,
 
 Thanks for the detailed review. I'll let the authors respond to these if they
 have further questions or clarifications to ask.
 
 - Jouni
 
 
 
 On Sep 14, 2013, at 3:13 AM, Martin Thomson martin.thom...@gmail.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-dime-app-design-guide-19
 Reviewer: Martin Thomson
 Review Date: 2013-09-13
 IETF LC End Date: unknown, early review
 IESG Telechat date: (if known)
 
 Summary: This document is ready, with some minor issues and nits.
 
 Minor issues:
 I would find it a lot easier to read this document if it did as the
 goals state (the first objective from the introduction) and clarify
 what the extensibility rules in Diameter say with respect to each of
 the described extensions.  It's not easy to glean this information
 from RFC 6733, which makes reviewing this a little tricky.
 
 For instance, Section 4.1 doesn't really say what the expectations are
 with respect to implementations that receive unknown or unsupported
 commands.  I think that I could guess, but I'd rather not.  (I just
 read the relevant parts of 6733, and it turns out that my guess was
 wrong.)
 
 The same applies to Section 4.2, presumably through applying the same
 principles.  The question here is: what would be the expected behavior
 if a node was operating on the new application definition and that
 node received a deleted command?  (The old implementation presumably
 has no problem with the absence of the command if it's being removed.)
 
 The same applies to Section 5.
 
 Sections 4.4.2 and particularly 5.6 lead me to infer that the
 extensibility for enumerated types is fundamentally broken, so maybe
 those properties need to be expanded upon a little here too.
 
 The placement of the guidance in Section 5.6 seems fairly important
 for Section 4, lest that important information be lost to someone just
 looking to tweak a command.
 
 Section 4.3.1, perhaps add to the M-bit criteria: Would the presence
 or value of the AVP alter the interpretation of the command (or any
 other AVP) in any way?  (nit: s/AVPs/AVP on second bullet here.)
 
 I didn't find the list in  Section 6 particularly compelling.  It
 seemed a little like motherhood statements.  The description of what
 it was this was talking about: good; the description of how these
 often (always?) manifest is also useful.  I wonder though whether
 it's safe to generalize when you only see generic protocols extensions
 as optional AVPs.  Perhaps you need to refocus on exactly that, and
 leave the other forms of extension to speculation.
 
 Nits/editorial comments:
 The last paragraph of Section 3 is confusing to me.  Firstly, the
 subject of the reminder is missing from the first sentence.  I think
 that the intent of that sentence is to say that extending by adding
 applications or commands is to be avoided, but then subsequent
 sentences make it clear that doing so is easy.  The last sentence
 seems to be talking about something else entirely, which is the value
 that IANA registries provide.  I am going to have to suggest that this
 be reworded entirely.
 
 In Section 4.1, I'd like to see the note turned into real text.  The
 size and complexity of an application seems to be a fairly significant
 factor in determining whether a new application imports commands, or
 whether separate applications are defined.
 
 I read the first bullet in Section 4.3.2 as a sentence, several times,
 before realizing that it's a title.  Please reconsider the formatting
 of this list.  At a very minimum, remove the period.
 
 --Martin
 
 p.s., I'm on vacation starting approximately ...now, since I'm out of
 time for this review... so apologies for any slow responses to the
 review.
 

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

Re: [Gen-art] Gen-ART LC Review of draft-ietf-radext-ieee802ext-10

[Jouni Korhonen]

I don't think there is anything that needs to be done for 2.2. It is
a normal capability exchange type of mechanism.

The text is IMHO clear:
in situations where the Attribute is required to provision service..

Then the lack of EAP-Key-Name means the service cannot be provisioned
and the NAS can safely interpret that as an Access-Reject, when 
appropriate by the deployment.

NAS doesn't include the attribute if it is not needed. And if it does,
the current text allows still accepting the service regardless the
lack of the attribute in the Access-Accept.


- Jouni


On Mar 26, 2014, at 8:55 AM, Jari Arkko jari.ar...@piuha.net wrote:

 Thanks for the review. I did not see a response or change regarding 2.1 or 
 2.2. Does this need to be addressed? Authors?
 
 Jari
 
 On Feb 27, 2014, at 9:08 PM, Benoit Claise bcla...@cisco.com wrote:
 
 Dear authors,
 
 Can you please follow up on that one.
 
 Regards, Benoit
 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-radext-ieee802ext-10
 Reviewer: Ben Campbell
 Review Date: 2014-01-31
 IETF LC End Date: 2014-02-04
 
 Summary: This draft is almost ready for publication as a standards track 
 RFC. I have a small number of minor comments that may be worth considering 
 prior to publication.
 
 Major issues: None
 
 Minor issues:
 
 -- 2.1, last paragraph:
 
 Does the last sentence imply Allowed-Called-Station-Id actually should (or 
 SHOULD) not be used in non-wireless scenarios? (I note that the 
 Network-Id-Name section talks about how 802.1X NID-Names should not be 
 included in Called-Station-Id, but rather put in Network-Id-Name. Does that 
 apply here as well?
 
 -- 2.2, last paragraph: Since a NAS will typically only include a 
 EAP-Key-Name Attribute in an Access-Request in situations where the 
 Attribute is required to provision service, if an EAP-Key-Name Attribute is 
 included in an Access-Request but is not present in the Access-Accept, the 
 NAS SHOULD treat the Access-Accept as though it were an Access-Reject. 
 
 Is there a backwards compatibility issue? What if a NAS sends the field to 
 a server that doesn't implement this draft? Is there an assumption that a 
 NAS that supports this draft will only work with a server that also 
 supports it?
 
 Or more to the point, is the ...typically only include...where 
 required... strong enough to require a normative SHOULD? Seems like this 
 would discourage the inclusion of EAP-Key-Name in the non-typical case of 
 it _not_ being required. Is that the intent?
 
 Nits/editorial comments:
 
 -- section 2.8:
 
 It might be worth expanding EAPoL
 
 
 
 .
 
 
 ___
 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 Early Review of draft-ietf-radext-dtls-07

[Jouni Korhonen]

Thanks Ben for the review!

- JOuni

On Nov 19, 2013, at 1:38 AM, Ben Campbell b...@nostrum.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.
 
 This is an early review at WGLC last call.
 
 Document:   draft-ietf-radext-dtls-07
 Reviewer: Ben Campbell
 Review Date: 2013-11-18
 
 Summary: This draft is on the right track, but there are significant open 
 issues that should be resolved before it progresses.
 
 [Note: This review is different from the usual Gen-ART review due to the fact 
 that it's an early (as in prior to pubreq) review, and that the draft is 
 intended to become an experimental RFC. The gen-ART review process is tuned 
 for drafts at IETF last call or later. It's a little hard to figure out what 
 criteria should be used for drafts at an earlier point in the life-cycle. 
 That being said, I reviewed this as if it were near-final, and apologize if 
 that turns out to be too strict for an early review.
 
 I used similar review criteria as I would for a standards-track draft, since 
 this draft still specifies protocol with the hope of interoperable 
 implementations. The only difference comes from a few comments explicitly 
 about the experimental status of the draft.]
 
 
 *** Major issues:
 
 -- General:
 
 The draft needs an overhaul of it's use of normative language. There appears 
 to be redundant (and possibly contradictory) language for the same 
 requirements sprinkled throughout. There are also cases of normative language 
 being used for internal implementation guidance, which is not appropriate as 
 described by RFC 2119. (See the minor issues section for details--most of the 
 instances would not qualify as major issues by themselves, but I think they 
 constitute a major issue in the aggregate.)
 
 -- section 3, 2nd paragraph:  ... long-term use of RADIUS/UDP is NOT 
 RECOMMENDED. 
 
 While I agree with the sentiment, that's not an appropriate assertion for an 
 experimental RFC. It would either need to go into an standards-track update 
 to the RADIUS spec, or a BCP.
 
 (Also applies to the reiteration in 10.1)
 
 
 *** Minor issues:
 
 -- General:  It might be worth some text on why this is experimental rather 
 than informational. Is there any plan to evaluate the implementation results? 
 Is there an expectation that a future RADIUS/DTLS spec could become 
 standards-track? Is there any plan to evaluate the outcome of this document?
 
 -- Section 1, 2nd paragraph:
 
 Isn't this true for almost any use of IPSec? Is there some specific reason 
 this is worse for RADIUS than for other protocols?
 
 -- Section 1, 4th paragraph:
 
 The second sentence mentions that firewall rules do not need to be changed. 
 The following sentence recommends a change to firewall rules.
 
 The firewall rule recommendations in the 3rd sentence seems odd, since it 
 seems like any protocol over DTLS would pass. Also, does this imply a 
 recommendation that firewalls with DPI be used in the first place, since the 
 absence of such a firewall has the same effect as having one that doesn't 
 enforce the protocol? (Is there a reason a protocol spec should recommend 
 firewall rules in the first place, other than to mention places where certain 
 firewall rules might prevent interfere with operation?)
 
 -- section 2.1, 5th paragraph (3rd paragraph after bullet list) :  
 Implementations MUST support encapsulated RADIUS packets of 4096 in 
 length...
 
 Please be more precise than MUST support. Specifically, does MUST support 
 indicate you must support both sending and receiving of that size? (since 
 4096 would generally exceed PMTU even for RADIUS/UDP)
 
 -- 2.2 and children:
 
 I find this section confusing as to where to find the authoritative text. 
 Some, but not all, of the material from 6614 is repeated as normative text in 
 later sections.  The description of this draft as applying 'semantic 
 patches' to 6614 seems to imply you mean the 6114 text, with these patches 
 applied, to be normative, which creates some potential conflicts. If, on the 
 other hand, 2.2 (.x) is intended more as a informative description of the 
 differences, please say so.
 
 -- 3, 1st paragraph:
 
 Can you elaborate on the resulting timeouts, lost traffic, and network 
 instabilities?
 
 -- 3.1: 
 
 The section describes UDP/2083 as the default port. But later sections 
 describe port related behavior in a way that makes it it look like the 
 impementations must always use 2083, which makes it more than just a default. 
 Is the administrator allowed to choose some other port for any reason? If so, 
 it might make more sense to refer to the port by role rather than number when 
 discussing port related behavior. (I note that 6614 only mentions the port 
 number in the initial assignment, the IANA considerations, and the appendix.)
 
 
 -- 3.2, last paragraph:
 
 Can you elaborate on the bid 

Re: [Gen-art] Gen-ART review of draft-ietf-dime-overload-reqs-12

[Jouni Korhonen]

Thanks David.

- JOuni


On Sep 20, 2013, at 2:57 AM, Black, David david.bl...@emc.com wrote:

 And the -12 version is likewise ready for publication as an Informational RFC.
 
 Thanks,
 --David
 
 -Original Message-
 From: Black, David
 Sent: Tuesday, August 27, 2013 12:41 PM
 To: Ben Campbell
 Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org); i...@ietf.org;
 d...@ietf.org; bcla...@cisco.com; Black, David
 Subject: Gen-ART review of draft-ietf-dime-overload-reqs-11
 
 The -11 version of this draft addresses all of the nits and editorial 
 comments
 noted in the Gen-ART review of the -10 version.  It's ready for publication 
 as
 an Informational RFC.
 
 Thanks,
 --David
 
 -Original Message-
 From: Ben Campbell [mailto:b...@nostrum.com]
 Sent: Thursday, August 22, 2013 4:50 PM
 To: Black, David
 Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org);
 i...@ietf.org;
 d...@ietf.org; bcla...@cisco.com
 Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
 
 Hi David,
 
 We agree on all your points, and will make the updates in the next version,
 pending shepherd instructions.
 
 Thanks!
 
 Ben.
 
 On Aug 22, 2013, at 2:50 PM, Black, David david.bl...@emc.com wrote:
 
 Hi Eric,
 
 This looks good - comments follow ...
 
 a) I assume that overload control development work will derive more
 specific
 security requirements - e.g., as REQ 27 is stated at a rather high
 level.
 The discussion in security considerations section seems reasonable.
 
 We agree with this.  The thinking here was that we didn't want to specify
 this
 in a way that would be specific to a particular type of mechanism.  It
 might
 not hurt to state that assumption, either as a note on Req 27 or in the
 sec
 considerations.
 
 That would be good to add as a note on REQ 27.
 
 The intent was very much as you say, where requirements on individual
 node
 capabilities are hoped to result in better overall system behaviors.
 There are
 also some requirements that are stated more at the system level (e.g. 7
 and
 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
 insufficient server capacity at a cluster of servers behind a Diameter
 agent
 can be treated as if the agent itself was overloaded.
 
 On the other hand, any mechanism we design will have to focus on actions
 of
 individual nodes, so the numbered requirements tend to focus on that. I'm
 not
 sure where to change the balance here--do you have specific suggestions?
 
 I noted this as editorial rather than a minor issue, as I was mostly
 concerned
 that the actual design work will be informed by a sufficient architectural
 clue
 that the goal is better overall system behaviors, which your response
 indicates
 will definitely be the case ;-).
 
 Rather than edit individual requirements, how about adding the following
 sentence
 immediately following the introductory sentence in Section 7?:
 
These requirements are stated primarily in terms of individual node
behavior to inform the design of the improved mechanism;
that design effort should keep in mind that the overall goal is
improved overall system behavior across all the nodes involved,
not just improved behavior from specific individual nodes.
 
 This inadequacy may, in turn, contribute to broader congestion collapse
 
 collapse is not the right word here - I suggest issues, impacts,
 effects or problems.
 
 We are fine with any of those alternatives.  How about impacts.
 
 That's fine.  FWIW, congestion collapse has a specific (rather severe)
 meaning over in the Transport Area, and that meaning was not intended
 here.
 
 23.843 is the least stable reference.  I don't have any issue with
 pointing
 that out.  The part of it we are referencing is historical front matter
 though.
 
 I'd note the reference as work in progress, and put the statement about
 stable
 front matter (historical is a bad work to use here) in the body of the
 draft
 that cites the reference.
 
 I tried the web and downloaded versions of 2.12.17 and was not able to
 get the
 warnings you saw (about the references).  What did it say?
 
 Sorry, I didn't mean to send you on a wild goose chase :-).  The idnits
 confusion
 manifested right at the top of the output, where everyone ignores it ...
 
  Attempted to download rfc272 state...
  Failure fetching the file, proceeding without it.
 
 You didn't reference RFC 272, so that output's apparently courtesy of
 idnits
 misinterpreting this reference:
 
 1195  [TS29.272]
 1196 3GPP, Evolved Packet System (EPS); Mobility
 Management
 1197 Entity (MME) and Serving GPRS Support Node (SGSN)
 related
 1198 interfaces based on Diameter protocol, TS 29.272
 11.4.0,
 1199 September 2012.
 
 I was amused :-).
 
 Thanks,
 --David
 
 -Original Message-
 From: Eric McMurry [mailto:emcmu...@computer.org]
 Sent: Thursday, August 22, 2013 3:06 PM
 To: 

Re: [Gen-art] Gen-ART review of draft-ietf-dime-app-design-guide-19

[Jouni Korhonen]

Martin,

Thanks for the detailed review. I'll let the authors respond to these if they
have further questions or clarifications to ask.

- Jouni



On Sep 14, 2013, at 3:13 AM, Martin Thomson martin.thom...@gmail.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-dime-app-design-guide-19
 Reviewer: Martin Thomson
 Review Date: 2013-09-13
 IETF LC End Date: unknown, early review
 IESG Telechat date: (if known)
 
 Summary: This document is ready, with some minor issues and nits.
 
 Minor issues:
 I would find it a lot easier to read this document if it did as the
 goals state (the first objective from the introduction) and clarify
 what the extensibility rules in Diameter say with respect to each of
 the described extensions.  It's not easy to glean this information
 from RFC 6733, which makes reviewing this a little tricky.
 
 For instance, Section 4.1 doesn't really say what the expectations are
 with respect to implementations that receive unknown or unsupported
 commands.  I think that I could guess, but I'd rather not.  (I just
 read the relevant parts of 6733, and it turns out that my guess was
 wrong.)
 
 The same applies to Section 4.2, presumably through applying the same
 principles.  The question here is: what would be the expected behavior
 if a node was operating on the new application definition and that
 node received a deleted command?  (The old implementation presumably
 has no problem with the absence of the command if it's being removed.)
 
 The same applies to Section 5.
 
 Sections 4.4.2 and particularly 5.6 lead me to infer that the
 extensibility for enumerated types is fundamentally broken, so maybe
 those properties need to be expanded upon a little here too.
 
 The placement of the guidance in Section 5.6 seems fairly important
 for Section 4, lest that important information be lost to someone just
 looking to tweak a command.
 
 Section 4.3.1, perhaps add to the M-bit criteria: Would the presence
 or value of the AVP alter the interpretation of the command (or any
 other AVP) in any way?  (nit: s/AVPs/AVP on second bullet here.)
 
 I didn't find the list in  Section 6 particularly compelling.  It
 seemed a little like motherhood statements.  The description of what
 it was this was talking about: good; the description of how these
 often (always?) manifest is also useful.  I wonder though whether
 it's safe to generalize when you only see generic protocols extensions
 as optional AVPs.  Perhaps you need to refocus on exactly that, and
 leave the other forms of extension to speculation.
 
 Nits/editorial comments:
 The last paragraph of Section 3 is confusing to me.  Firstly, the
 subject of the reminder is missing from the first sentence.  I think
 that the intent of that sentence is to say that extending by adding
 applications or commands is to be avoided, but then subsequent
 sentences make it clear that doing so is easy.  The last sentence
 seems to be talking about something else entirely, which is the value
 that IANA registries provide.  I am going to have to suggest that this
 be reworded entirely.
 
 In Section 4.1, I'd like to see the note turned into real text.  The
 size and complexity of an application seems to be a fairly significant
 factor in determining whether a new application imports commands, or
 whether separate applications are defined.
 
 I read the first bullet in Section 4.3.2 as a sentence, several times,
 before realizing that it's a title.  Please reconsider the formatting
 of this list.  At a very minimum, remove the period.
 
 --Martin
 
 p.s., I'm on vacation starting approximately ...now, since I'm out of
 time for this review... so apologies for any slow responses to the
 review.

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

Re: [Gen-art] Gen-ART telechat review of draft-ietf-v6ops-rfc3316bis-04

[Jouni Korhonen]

Thanks Alexey.

- Jouni

On Sep 10, 2013, at 2:00 PM, Alexey Melnikov alexey.melni...@isode.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-v6ops-rfc3316bis-03
 Reviewer: Alexey Melnikov
 Review Date: 10 September 2013
 IETF LC End Date: 2 September 2013
 IESG Telechat date: 12 September 2013
 
 Summary: Ready.
 
 Major issues: None
 
 Minor issues: None
 
 Nits: None

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-v6ops-rfc3316bis-03

[Jouni Korhonen]

Alexey,

The review comments have been implemented and are visible in the github 
in-progress version:
https://github.com/jounikor/draft-ietf-v6ops-rfc3316bis/blob/master/draft-ietf-v6ops-rfc3316bis-04.txt

- Jouni


On Aug 30, 2013, at 2:31 PM, Alexey Melnikov alexey.melni...@isode.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-v6ops-rfc3316bis-03
 Reviewer: Alexey Melnikov
 Review Date: 30 August 2013
 IETF LC End Date: 2 September 2013
 IESG Telechat date: 12 September 2013
 
 Summary: Ready with nits.
 
 Major issues: None
 
 Minor issues: None
 
 Nits:
 
 In 1.1
 
 This document complements the IPv6 node requirements [RFC6434] in
   places where clarifications are needed the with discussion on the use
 
 Delete the before with?
 
   of these selected IPv6 specifications when operating over a cellular
   interface.
 
 In 2.2:
 
 RTP and SIP need Informative references.
 
 In 2.4:
 
 PPP needs an Informative reference.
 
 Also, where is IPv6CP defined?
 
 
 Appendix B.  Changes to RFC 3316
 
 I think that before publication this section needs to be reworked a bit to 
 have a single list of changes, referencing particular draft versions is not 
 going to be very useful in the final RFC.

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-v6ops-rfc3316bis-03

[Jouni Korhonen]

Thanks Alexey,

We'll take care of these comments asap.

- Jouni


On Aug 30, 2013, at 2:31 PM, Alexey Melnikov alexey.melni...@isode.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-v6ops-rfc3316bis-03
 Reviewer: Alexey Melnikov
 Review Date: 30 August 2013
 IETF LC End Date: 2 September 2013
 IESG Telechat date: 12 September 2013
 
 Summary: Ready with nits.
 
 Major issues: None
 
 Minor issues: None
 
 Nits:
 
 In 1.1
 
 This document complements the IPv6 node requirements [RFC6434] in
   places where clarifications are needed the with discussion on the use
 
 Delete the before with?
 
   of these selected IPv6 specifications when operating over a cellular
   interface.
 
 In 2.2:
 
 RTP and SIP need Informative references.
 
 In 2.4:
 
 PPP needs an Informative reference.
 
 Also, where is IPv6CP defined?
 
 
 Appendix B.  Changes to RFC 3316
 
 I think that before publication this section needs to be reworked a bit to 
 have a single list of changes, referencing particular draft versions is not 
 going to be very useful in the final RFC.

___
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-dime-overload-reqs-11

[Jouni Korhonen]

Great. Thanks!


- Jouni


On Aug 27, 2013, at 7:40 PM, Black, David david.bl...@emc.com wrote:

 The -11 version of this draft addresses all of the nits and editorial comments
 noted in the Gen-ART review of the -10 version.  It's ready for publication as
 an Informational RFC.
 
 Thanks,
 --David
 
 -Original Message-
 From: Ben Campbell [mailto:b...@nostrum.com]
 Sent: Thursday, August 22, 2013 4:50 PM
 To: Black, David
 Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org); i...@ietf.org;
 d...@ietf.org; bcla...@cisco.com
 Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
 
 Hi David,
 
 We agree on all your points, and will make the updates in the next version,
 pending shepherd instructions.  
 
 Thanks!
 
 Ben.
 
 On Aug 22, 2013, at 2:50 PM, Black, David david.bl...@emc.com wrote:
 
 Hi Eric,
 
 This looks good - comments follow ...
 
 a) I assume that overload control development work will derive more
 specific
 security requirements - e.g., as REQ 27 is stated at a rather high level.
 The discussion in security considerations section seems reasonable.
 
 We agree with this.  The thinking here was that we didn't want to specify 
 this
 in a way that would be specific to a particular type of mechanism.  It 
 might
 not hurt to state that assumption, either as a note on Req 27 or in the sec
 considerations.
 
 That would be good to add as a note on REQ 27.
 
 The intent was very much as you say, where requirements on individual node
 capabilities are hoped to result in better overall system behaviors. There 
 are
 also some requirements that are stated more at the system level (e.g. 7 and
 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
 insufficient server capacity at a cluster of servers behind a Diameter 
 agent
 can be treated as if the agent itself was overloaded.
 
 On the other hand, any mechanism we design will have to focus on actions of
 individual nodes, so the numbered requirements tend to focus on that. I'm 
 not
 sure where to change the balance here--do you have specific suggestions?
 
 I noted this as editorial rather than a minor issue, as I was mostly 
 concerned
 that the actual design work will be informed by a sufficient architectural 
 clue
 that the goal is better overall system behaviors, which your response 
 indicates
 will definitely be the case ;-).
 
 Rather than edit individual requirements, how about adding the following 
 sentence
 immediately following the introductory sentence in Section 7?:
 
 These requirements are stated primarily in terms of individual node
 behavior to inform the design of the improved mechanism;
 that design effort should keep in mind that the overall goal is
 improved overall system behavior across all the nodes involved,
 not just improved behavior from specific individual nodes.
 
 This inadequacy may, in turn, contribute to broader congestion collapse
 
 collapse is not the right word here - I suggest issues, impacts,
 effects or problems.
 
 We are fine with any of those alternatives.  How about impacts.
 
 That's fine.  FWIW, congestion collapse has a specific (rather severe)
 meaning over in the Transport Area, and that meaning was not intended here.
 
 23.843 is the least stable reference.  I don't have any issue with pointing
 that out.  The part of it we are referencing is historical front matter
 though.
 
 I'd note the reference as work in progress, and put the statement about 
 stable
 front matter (historical is a bad work to use here) in the body of the draft
 that cites the reference.
 
 I tried the web and downloaded versions of 2.12.17 and was not able to get 
 the
 warnings you saw (about the references).  What did it say?
 
 Sorry, I didn't mean to send you on a wild goose chase :-).  The idnits 
 confusion
 manifested right at the top of the output, where everyone ignores it ...
 
  Attempted to download rfc272 state...
  Failure fetching the file, proceeding without it.
 
 You didn't reference RFC 272, so that output's apparently courtesy of idnits
 misinterpreting this reference:
 
 1195   [TS29.272]
 1196  3GPP, Evolved Packet System (EPS); Mobility 
 Management
 1197  Entity (MME) and Serving GPRS Support Node (SGSN) 
 related
 1198  interfaces based on Diameter protocol, TS 29.272 
 11.4.0,
 1199  September 2012.
 
 I was amused :-).
 
 Thanks,
 --David
 
 -Original Message-
 From: Eric McMurry [mailto:emcmu...@computer.org]
 Sent: Thursday, August 22, 2013 3:06 PM
 To: Black, David
 Cc: b...@nostrum.com; General Area Review Team (gen-art@ietf.org);
 i...@ietf.org; d...@ietf.org; bcla...@cisco.com
 Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
 
 Hi David,
 
 Thank you for the review.  Your time and comments are appreciated!
 
 comments/questions inline.
 
 
 Eric
 
 
 
 On Aug 17, 2013, at 9:18 , Black, David david.bl...@emc.com 

Re: [Gen-art] Gen-Art review of draft-ietf-netext-access-network-option-10.txt

[jouni korhonen]

Alexey,

Thanks for the review. See some initial comments inline.


On May 5, 2012, at 8:58 PM, Alexey Melnikov 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-netext-access-network-option-10.txt
 Reviewer: Alexey Melnikov
 Review Date: 5 May 2012
 IETF LC End Date: 9 May 2012
 IESG Telechat date: Unknown
 
 Summary: This draft is ready as a Proposed Standard
 
 Major issues: none
 
 Minor issues:
 
 Minor: [ANI] and [TS23003] seem to be Normative (as per their use in 3.1.1)

If it is OK from the RFC process point of view, we can put these
non-IETF references into the normative section.

 
 Nits/editorials:
 
 1.  Introduction
 
This document defines a new mobility option, the Access Network
Identifier (ANI) option and its sub-options for Proxy Mobile IPv6,
that can be used by the mobile access gateway to signal the access
network information to the local mobility anchor.  The specific
details on how the local mobility anchor uses this information are
out-of-scope for this document.  These mobility options are optional
and are not mandatory for the Proxy Mobile IPv6 protocol.
 
 Nit: Last sentence: optional and not mandatory are the same thing on my 
 book.

Proposal for new text:

   These mobility options are optional for the Proxy Mobile IPv6 protocol.

 
 Strictly speaking PEN numbers are not limited to 4 bytes. However you have a 
 registry for types of identifiers, so a new value can be allocated for 
 bigger-than-4-bytes PENs.

Right. So we could just remove the 4 octet length requirement and use a 
natural length indicated octet coding for the PENs. For example

ANI Length = 1 - PENs 0-255
ANI Length = 2 - PENs 0-65535
ANI Length = 3 - PENs 0-16777216
...

That would be ok?


- Jouni


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

Re: [Gen-art] GenART last call review of draft-ietf-behave-nat64-learn-analysis-03

[jouni korhonen]

Roni,

Thanks for the review. We'll take care of the editorials.

- Jouni

On Mar 13, 2012, at 1:24 PM, Roni Even 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-behave-nat64-learn-analysis-03
 Reviewer: Roni Even
 Review Date:2012–3–13
 IETF LC End Date: 2012–3–22
 IESG Telechat date:
  
 Summary: This draft is ready for publication as an Informational RFC.
  
 Major issues:
  
 Minor issues:
  
 Nits/editorial comments:
  
 Section 5.1.1 third paragraph change to  “provided by some”
  
 

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

Re: [Gen-art] Gen-ART LC/Telechat review of draft-ietf-mext-mip6-tls-03

[Jouni Korhonen]

Thanks Ben for a thorough review. Very good comments indeed. We'll come back
to this in a bit.. you know -00 deadline approaching and such ;)

- Jouni


On 2/29/12 1:34 AM, ext Ben Campbell b...@nostrum.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 wait for direction from your document shepherd
 or AD before posting a new version of the draft.
 
 Document: draft-ietf-mext-mip6-tls-03
 Reviewer: Ben Campbell
 Review Date: 2012-02-28
 IETF LC End Date: 2012-02-29
 IESG Telechat date: 2012-03-01
 
 Note: Since the Telechat review deadline is a day before the end of the IETF
 last call, this review serves both as a Telechat review and an IETF Last Call
 review.
 
 Summary: This draft is basically ready for publication as an experimental RFC.
 There are some clarification issues that might should be addressed prior to
 publication.
 
 Major issues:
 
 None
 
 
 Minor issues:
 
 -- general: 
 
 The draft seems to be missing information on how to match TLS certificates to
 identities for HAC authentication.
 
 -- section 1, paragraph 1, last sentence: Client implementation experience
 has shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex.
 
 It might be worth elaborating on why this is true. Could this be solved with a
 cleaner software architecture rather than a protocol change?
 
 -- section 5.4:  The actual domain name used in queries is up to the
 deployment to decide and out of scope of this specification.
  
 This seems under specified for SRV
 
 -- 5.7.4:
 
 Are more than one DNS server allowed for each protocol?
 
 -- 5.8:
 
 I find this section confusing,as the first and second paragraphs seem to make
 contradictory statements about the authentication, particularly about the use
 of PSK. I think you are talking about authentication of the HAC in the TLS
 handshake vs an higher level authentication of the MN using PSK or EAP. I
 think this could use some clarification, as both paragraphs talks about
 authentication between the MN and HAC without mentioning direction.
 
 Note that this is more clear in the security considerations section, but it
 would help for it to be more clear here.
 
 -- 5.9, 2nd to last paragraph:
 
 How do the first and last sentences relate? It seems to say set it to 1,
 except for this case in which you set it to 1.
 
 -- 8.1:
 
 Is this registry only for TLS based MIPv6? If so, does it need to be
 explicitly constrained to not used for MIPv6 in general?
 
 
 
 
 Nits/editorial comments:
 
 -- section 4.1: 
 
 A picture showing the element and key relationships could be helpful here.
 
 -- section 4.3, third paragraph:
 
 Please expand BA on first mention
 
 --section 4.3, Security association validity times, : hours or weeks
 
 Hours _to_ weeks?
 
 -- section 4.3, selected cyphersuite:  The selected algorithms SHOULD be
 one of the mutually supported ciphersuites
 
 How could it be otherwise? (i.e. why the SHOULD, and is this really normative
 vs descriptive?)
 
 -- section 4.4: Home Agent IP Address : Concerns both IPv6 and IPv4 home
 agent addresses.
 
 Dual stack only?  (same applies to Home Address section)
 
 -- section 5.1, second paragraph: All data inside the Content portion of the
 message container MUST be encoded using octets.
 
 I suspect I'm missing a subtlety here--but how else could you do it? Is this
 intended to imply a byte-field, or to imply no additional encoding is used?
 
 -- section 5.2: From now on, we use TypeValue header (TV-header) term to
 refer request-response message content HTTP-like headers.
  
 Maybe that should be moved to the terminology section?
 
 -- section 5.3, 2nd paragraph: The MN is also the peer that always sends only
 request messages and the HAC only sends response messages.
 
 I'm having trouble parsing. Is their a spurious always?
 
 -- section 5.5 : same to that used by HTTP
 
 same _as_?
 
 -- section 5.5.5
 
 s/till/until
 
 -- 5.5.8, 1st sentence:
 
 Sentence fragment. Missing words?
 
 -- 5.9, first paragraph:
 
 Sentence fragment.
 
 -- 5.9, 2nd to last paragraph:
 
 s/In case the/In the case that the
 
 -- 9:
 
 A general discussion of threats would be helpful. Some aspects are scattered
 in the subsections, but a summary in one place would be nice.
 
 -- 9.2: 
 
 It's not clear to me if the text in the Dictionary Attack section is
 actually related to dictionary attacks.
 
 
 -- 6.1:
 
 A picture of the general packet format would be nice. You've got them later
 for specific packet types, but no general picture.
 
 --6.2: 
 
 Section seems mostly redundant to 6.1
 
 -- 6.3:
 
 Please expand HoTI on first use.
 
 -- 7:
 
 Please expand CoTI/CoT on first use
 
 -- 8.3:
 
 I'm not sure I understand the mnemonic relevance of HALTSEC
 
 
 
 
 

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

Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-dhc-pd-exclude-04

[jouni korhonen]

Pete,

Thanks for the review. Agree that in general having a hole in otherwise 
continuous prefix is guaranteed to cause always some undesired side effects.

Regarding sending RAs I don't this it will be much of an issue, though.
Assuming SLAAC is used, then the requesting router would anyway be sending
a /64 in each RA on its downstream interfaces, thus chopping the delegated
prefix into a number of smaller prefixes. And if each downstream interface
have their own /64 prefix, then including a summary prefix shorter than /64
does not really work.

- Jouni

On Feb 15, 2012, at 9:35 PM, Pete McCann 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 wait for direction from your document shepherd
 or AD before posting a new version of the draft.
 
 Document: draft-ietf-dhc-pd-exclude-04
 Reviewer: Peter McCann
 Review Date: 2012-02-15
 IETF LC End Date:
 IESG Telechat date: 2012-02-16
 
 Summary: Ready
 
 Major issues: None
 
 Minor issues:
 
 Might want to point out that when the requesting router sends router
 advertisements downstream,
 it cannot simply advertise the whole delegated prefix but must instead
 advertise chunks of it that
 do not include the excluded prefix.  This may introduce complications
 and extra overhead.
 
 Nits/editorial comments: None

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

Re: [Gen-art] Gen-art: Last call review of draft-ietf-netext-radius-pmip6-06

[jouni korhonen]

Hi Elwyn,

Thanks you for you detailed review. See my comments/answers inline.


On Jan 16, 2012, at 3:44 PM, Elwyn Davies 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-netext-radius-pmip6-06
 Reviewer: Elwyn Davies
 Review Date: 16 January 2012
 IETF LC End Date: 19 January 2012
 IESG Telechat date: (if known) -
 
 Summary: Almost ready with just some minor nits.
 
 Major issues: -
 
 Minor issues:
 s4.1, IP4_HOA_ONLY_SUPPORTED: Is there need to discuss what happens  if
 the MUST/MUST NOT conditions are not satisfied? 

If you mean this part of the MUST/MUST NOT:

When this bit is set the PMIP6_SUPPORTED flag MUST also be set,
and the IP4_HOA_SUPPORTED flag MUST NOT be set.

If these conditions are not met, then e.g. AAA end points are misbehaving.
I could clarify that in case of client receiving a wrong combination it
treats the Access-Accept as an Access-Reject and in a case the AAA server
received a wrong combination answers with an Access-Reject.

Would this be ok?



 
 Nits/editorial comments:
 s1, last para: s/visitor/visited/
 
 s2, Home AAA: s/to  mobile/to the mobile/
 
 s3: Expand acronym PBU on first use.
 
 s3, para 7 (before numbered list): s/Following/The following/
 
 s3, para below figure 2: s/illustrates topology where MAG/illustrates a
 topologywhere the MAG/
 
 s4, general: It might be helpful to replace the text 'to be defined by
 IANA' in the Type specification fields with the relevant '(TBDxx)' if
 that is the format that is wanted eventually.
 
 s4.1, para 1: reserves a new capability bit - I think two new bits are
 reserved in this section.
 
 s4.1, IP4_HOA_ONLY_SUPPORTED: Expand acronym HNP on first use.
 
 s4.2: Expand acronyms NAI, PBA on first use.
 
 s4.2, et seq, Length fields: The formula '= 3 octets' is confusing.
 Suggest 'In octets, including Type and Length fields (= 3)'
 
 s4.2: The abbreviated name used for this field is inconsistent:
 MN-Identifier in para 1, MN-ID in last para.
 
 s4.5, para 2 and s4.7, para 2: s/If included by VAAA/If included by the
 VAAA/

Ack for all the above.

 
 s4.8/s4.9/s4.12/s4.13: Is the all-zeroes case specified by prefix length
 zero or 16 octets of zeroes?  Not sure if an actual prefix of zero
 length is meaningful here.

Actually the prefix length should be 128 in this case. Thanks for 
spotting this.


 
 s4.8/s4.9: Need to specify how PrefixLength is represented (unsigned
 integer).

See above.

 
 s4.10: s/conveys 64 bits interface identifier/conveys an 8 octet long
 interface identifier/ (for consistency with field definition in last
 para.)
 
 s4.11: s/contains 64 bits interface identifier/contains an 8 octet long
 interface identifier/ (for consistency with field definition in last
 para.)

I would say:

   ... conveys 64 bits (8 octets) interface identifier representing a
   particular MN's interface.

since IIDs are always discussed as 64 bits interface ids.


 
 s4.16, last line of figure: s/LMA IPv6/DHCP v6 server/
 
 s5.1, bullet 1: s/Home-/Home/

Ack.

 
 s7: I am not sure if the various must's and may's ought to be MUST's and
 MAY's.
 

Any specific example?

- Jouni

___
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-v6ops-3gpp-eps-03

[jouni korhonen]

Hi,

On Aug 11, 2011, at 4:27 AM, Thomson, Martin wrote:

 On 2011-08-09 at 18:28:05, jouni korhonen wrote:
 It's easy to infer from reading further that layer-2 implies pre-
 IP, but that view is at odds with the view that other nodes 
 necessarily have: signaling is distinctly layer-7 to those that 
 operate upon it.  Is this accurate?
 
 Right.. maybe we should also say that PDP context/EPS bearer setup 
 procedures equals setting up the layer-2 link and the address 
 configuration can be part of that signaling?
 
 I notice that you use the term bearer fairly frequently to refer to both 
 PDP context/EPS bearer.  When you say layer-2 signaling you could be more 
 specific and say bearer setup.

Right.. how about:

   specifications, but is not used in wide scale.  The mobile host must
   always support address configuration as part of the bearer setup signaling,
   since DHCPv4 is optional for both mobile hosts and networks.

 
 
  the 'delegated prefix' [I-D.ietf-dhc-pd-exclude].
 
 In its 3rd WGLC as we speak.
 
 Great.  MISREF wont keep this in the editors queue long then.
 
 The pd-exclude is referenced from 3GPP. How about:
 
   is not part of the 'delegated prefix'.  IETF defined solution to
   exclude a specific prefix from the 'delegated prefix' is used to
   enable this [I-D.ietf-dhc-pd-exclude].
 
 Or just:
  An option to exclude a prefix from delegation [I-Dpd-exclude] 
  prevents this problem.

Ok. Sounds much better.

 There are more than the usual quantity of acronyms in this document.
 Welcome to 3GPP ;)
 
 Oh, it's not my first time, trust me.  Incidentally, I have to note that 
 you've done an excellent job with the acronyms on the whole.  I didn't 
 encounter any that I didn't know, and only a few that weren't expanded.
 
 Ok. I'll try fitting clouds there.
 
 BTW, nice clouds, and some of the nicest ASCII art that I've seen.
 
 Do you have a suggestion for better wording? The statement is here 
 because it is possible and rather easy to deploy a network that allow 
 other types of handovers. However, in that case the outcome is 
 unpredictable, especially when the network has equipment from multiple 
 vendors.. and those cases and recovery procedures are not even 
 documented.
 
 I understand that it _is_ unfortunate.  As you say, it has other more 
 concrete consequences.  In some cases, simply removing the Unfortunately, 
 would work.  Maybe something like:
 
 OLD:
   Unfortunately, it is not mandatory to implement/deploy 3GPP standards
   based solution to selectively prohibit IPv6 roaming without also
   prohibiting other packet services (such as IPv4 roaming).  However,
   there are few possibilities how this can be done in real deployments.
   The examples given below are either optional and/or vendor specific
   features to the 3GPP EPC:
 NEW:
 3GPP does not specify a mechanism whereby IPv6 roaming is prohibited without 
 also disabling IPv4 access and other packet services.  The following options 
 for disabling IPv6 access for roaming subscribers could be available in some 
 network deployments:

Thanks. I'll use this.

 Don't feel beholden to me on this one though.  Use your discretion.  The 
 first sentence didn't parse particularly well, but I'm not sure whether my 
 suggestion retains the whole of your original intent.
 
 - Jouni
 
 --Martin

- JOuni


 
 

___
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-v6ops-3gpp-eps-03

[jouni korhonen]

Hi Martin,

Thank you for a thorough review! I have few comments/answers inline.

On Aug 9, 2011, at 8:53 AM, Thomson, Martin 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.
 
 Document: draft-ietf-v6ops-3gpp-eps-03
 Reviewer: Martin Thomson
 Review Date: 2011-08-10
 IETF LC End Date: 2011-08-12
 IESG Telechat date:
 
 Summary: This draft is ready for publication as an informational RFC.
 
 The document does a reasonable job of summarizing the state of IPv6 
 deployment for 3GPP access.  There are a number of editorial issues that 
 affect readability, but nothing that should prevent this from going to the 
 RFC editor.  
 
 Major issues: none
 
 Minor issues: none
 
 Nits/editorial:
 
 The draft relies on a definition of layer-2 that is implied.  For instance, 
 from Section 5:
 
   [...] The mobile host must
   always support layer-2 based address configuration, [...]
 
 It's easy to infer from reading further that layer-2 implies pre-IP, but 
 that view is at odds with the view that other nodes necessarily have: 
 signaling is distinctly layer-7 to those that operate upon it.  Is this 
 accurate?

Right.. maybe we should also say that PDP context/EPS bearer setup procedures 
equals setting up the layer-2 link and the address configuration can be part of 
that signaling?

 
   The mobile host must always support address configuration using signaling 
 during bearer setup, ...
 
 Idnits picked up two warnings, one of which is a false alarm, the other of 
 which is a downref to draft-ietf-dhc-pd-exclude.  What is the publication 
 status of the prefix delegation exclusion draft?
 
   [...]  IETF is working on a solution
   for DHCPv6-based prefix delegation to exclude a specific prefix from
   the 'delegated prefix' [I-D.ietf-dhc-pd-exclude].

In its 3rd WGLC as we speak.


 Rather than make this statement, which wont be of any value once pd-exclude 
 is published or not.  Could you make a statement that is less temporary?  
 Does 3GPP reference the mechanism in pd-exclude?

The pd-exclude is referenced from 3GPP. How about:

   is not part of the 'delegated prefix'.  IETF defined solution to
   exclude a specific prefix from the 'delegated prefix' is used to
   enable this [I-D.ietf-dhc-pd-exclude].

 
 There are more than the usual quantity of acronyms in this document.  I 
 encourage you to do a final pass to check that 

Welcome to 3GPP ;)

 each is expanded on first use.  There were a few that I encountered, but I 
 probably missed a few instances.  PDN, PDP Type (as opposed to context), 
 NAT44.  Fortunately [*], the target audience should have sufficient context 
 to wade through the dense thicket of acronyms and terms without needing this; 
 I pity the reader who is unfamiliar with the 3GPP architecture.

Ok. I'll check for these.

 Also missing: user plane.

Ok.


 The decision to interchangeably use UE, MN, Mobile, etc... is greatly 
 confusing to a reader.  My experience with 3GPP specifications shows a 
 consistent use of UE, can you not also choose one form and consistently use 
 that?

Ok. Will consistently change everything to UE.


 In addition to the above, I didn't see any reason to make a distinction 
 between TE+MT and UE.

Ok. If you refer to Figure 2 I can change that to the UE.

 Section 2, Terminal Equipment: s/to the use./to the user./

Ok.

 Figure 2 shows the UTRAN and BSS as nodes (boxes) rather than composite 
 systems (clouds).  That might be misleading.

Ok. I'll try fitting clouds there.


 Sections 3 and 4 duplicate some of the information that is provided in 
 Section 2.  For instance, the definition of the eNodeB and MME is duplicated 
 at the end of Section 4.1.

Ok. Will remove duplicates.


 Section 5.2 includes a citation for DHCPv6 that is placed in a way that 
 implies more than I think is intended.  RFC 3315 supports the definition 
 rather than the statement.
   Stateful DHCPv6-based address configuration is not supported by 3GPP
   specifications [RFC3315].  
 Suggest:
   Stateful DHCPv6-based address configuration [RFC3315] is not supported 
   by 3GPP specifications.

Sounds better. Will change this.


 Section 5.2 needs a citation for RFC 4861.

Ok.

 Section 5.2 uses must and may several times.  Since these statements are 
 not prescriptive, they could probably use other forms, for instance:
 
   This implies that the M-bit _is_ always clear in the Router Advertisement 
 (RA) [RFC4861] sent to the UE.

Ok.

 Section 8.1, Point 3: s/be build on IPv6/be built on IPv6/

Ok.

 The language in Section 8.5 is hard to parse.  Consider breaking the first 
 paragraph (the list structure).  Re-consider the use of colloquialisms like 
 basically and the use of parenthetical statements.

Right.. I'll try to reword this section.


 Section 8.6:
   Other types of configurations are considered network planning
   mistakes.  
 Seems like a value 

Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-netext-redirect-07

[jouni korhonen]

Thanks Pete for extensive review. I'll come back to your major issues in a bit.

- Jouni


On Apr 14, 2011, at 10:23 PM, Pete McCann 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-netext-redirect-07
 Reviewer: Pete McCann
 Review Date: 2011-04-14
 IETF LC End Date: 2011-04-10 (sorry this is late)
 IESG Telechat date: (unknown)
 
 Summary: Has Issues
 
 Major issues:
 
 Section 5.4:
 You should add a paragraph on the possibility of loops in the
 LMA assignment operation and specify that the MAG must
 take some action to detect and terminate such loops, such
 as a maximum redirection count or tracking the IP addresses
 of the LMAs it has been assigned so far and looking for duplicates.
 
 Section 6: (Multi-Homing)
 This section makes a major assumption that all of the MN's
 sessions are somehow able to be correlated and that all MAGs
 will direct their tunnels back to the same LMA.  In fact this may
 not be possible when the MN has interfaces on multiple different
 technologies with multiple different network operators and different
 subscriber credentials.  There is no way to enforce that all sessions
 go to the same LMA.  Besides, why is this even necessary?  The
 section does not give a concrete justification for why all the sessions
 need to go through the same LMA.
 
 Minor issues:
 
 Section 5.2:
   Otherwise, the rfLMA MUST act as a normal RFC 5213
   defined LMA for the MAG.
 The sentence just prior talks about rejecting the PBU with
 a PBA 130 Insufficient resources.  I think you need an extra
 if clause here:
   If the rfLMA is able to make the assignment to an r2LMA,
   it returns a PBA with the Redirect extension as defined
   below.  Otherwise, the rfLMA MUST act as a normal RFC 5213
   defined LMA for the MAG.
 
 You need a paragraph at the end of Section 5.2 that describes
 what is about to happen in the document:
   We next describe two models for the runtime assignment of
   the LMA.  In Section 5.3, we describe a model where the
   assignment by the rfLMA and the binding at the r2LMA are
   created at the same time.  This scenario is optimized for
   the case where the rfLMA and r2LMA are co-located or
   integrated by a proxy MAG protocol which is described
   in Section 5.3.4.  In Section 5.4, we describe a mode where
   the assignment by the rfLMA takes place first, and then the
   binding at the r2LMA is created by a separate PBU/PBA
   exchange that happens in a second round-trip.
 When I first read Section 5.3 I thought it was the only model
 being supported and was quite concerned.
 
 
 Nits/editorial comments:
 
 Section 1:
   reasons, why
 SHOULD BE:
   reasons why
 
   practise
 SHOULD BE:
   practice
 
   in-line what
 SHOULD BE:
   in-line with what
 
 Section 3:
   domain, is not
 SHOULD BE:
   domain is not
 
   assignment, unless
 SHOULD BE:
   assignment unless
 
 Section 4.1:
   There can zero
 SHOULD BE:
   There can be zero
 
 Section 5.1:
   the of the
 SHOULD BE:
   the
 
 Section 5.2:
   a reason or other
 SHOULD BE:
   some reason
 
   The rfLMA MUST only assign the MAG with a new r2LMA that it knows the
   MAG has a SA with or the MAG and the r2LMA are able to create it
   dynamically.
 SHOULD BE:
   The rfLMA MUST only assign the MAG to a new r2LMA with which it knows
   the MAG has an SA or with which it knows the MAG can establish an SA
   dynamically.
 
   and the r2LMA, are again deployment
 SHOULD BE:
   and the r2LMA are again deployment
 
   transport, if the MAG
 SHOULD BE:
   transport if the MAG
 
 Section 5.3.1:
   Address where the PBU was sent to
 SHOULD BE:
   Address to which the PBU was sent
 
 Section 5.3.2:
   considerations has to taken
 SHOULD BE:
   considerations have to be taken
 
   BUL to correspond the r2LMA address
 SHOULD BE:
   BUL to contain the r2LMA address
 
 Section 5.3.4:
   then the proceeds as mentioned in Section 5.2),
 SHOULD BE:
   then the PBU is processed as described in Section 5.2,
 
 Section 5.4.1:
   Address where the PBU was sent to
 SHOULD BE:
   Address to which the PBU was sent

___
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-netext-redirect-07

[jouni korhonen]

Pete,

See my comments inline:


On Apr 14, 2011, at 10:23 PM, Pete McCann wrote:

 Major issues:
 
 Section 5.4:
 You should add a paragraph on the possibility of loops in the
 LMA assignment operation and specify that the MAG must
 take some action to detect and terminate such loops, such
 as a maximum redirection count or tracking the IP addresses
 of the LMAs it has been assigned so far and looking for duplicates.

Section 3 says:

   ...
   functionality.  MAGs and LMAs implementing the runtime LMA assignment
   functionality MUST support the runtime LMA assignment during the
   initial PBU/PBA exchange which creates a new mobility session.  A
   mid-session LMA assignment may make use of [RFC5142]

I thought this was clear enough already. However, I am OK to add a new 
configuration knob for maximum number of consecutive assignments. How about:

In Section 5.4.2:

   Each time the MAG receives a PBA with the Status Value set to
   Rejected_but_Redirected, it MUST check whether the 
   maximum runtime assignment count value (initialized to the
   MaxRedirectCount when a new mobility session establishment
   starts) is greater than zero. If the counter value is greater
   than zero, it is decreased by one and the MAG can proceed with
   the runtime assignment. If the counter value is zero, then the
   MAG MUST treat the PBU was rejected by the LMA and log the event.

In Section 7:

   MaxRedirectCount

  This configuration variable is available in a MAG and tells
  the maximum number of allowed consecutive runtime assignments.
  When the EnableLMARedirectFunction is TRUE, the MaxRedirectCount
  MUST be set to one or more. When the EnableLMARedirectFunction
  is FALSE, the MaxRedirectCount MUST be zero.


 
 Section 6: (Multi-Homing)
 This section makes a major assumption that all of the MN's
 sessions are somehow able to be correlated and that all MAGs
 will direct their tunnels back to the same LMA.  In fact this may

This is how real deployments plan to do stuff..

 not be possible when the MN has interfaces on multiple different
 technologies with multiple different network operators and different
 subscriber credentials.  There is no way to enforce that all sessions

Ok. My assumption was that there is one subscriber identity (but possibly 
multiply credentials) that maps/leads to a single home network. This would be 
e.g. how things get done in real world.

 go to the same LMA.  Besides, why is this even necessary?  The
 section does not give a concrete justification for why all the sessions
 need to go through the same LMA.

Justification is rather simple. Inter-technology handovers become impossible if 
different accesses are hosted in different LMAs. 

How about the following clarification to Section 6:

Old text:

   A MN can be multi-homed.  A single LMA entity should have the control
   over all possible multi-homed mobility sessions the MN has.  All
   mobility sessions a multi-homed MN may have SHOULD be anchored in the
   single LMA entity.  Therefore, once the MN has established one
   mobility session with one LMA, the subsequent mobility sessions of
   the same MN SHOULD be anchored to the LMA that was initially
   assigned.

   One possible solution already supported by this specification is
   applying the runtime LMA assignment only for the very first initial
   attach a multi-homed MN does towards a PMIPv6 domain.  After the
   initial attach, the assigned r2LMA Address has been stored in the
   policy profile.  For the subsequent mobility sessions of the multi-
   homed MN, the same assigned r2LMA Address would be used and there is
   no need to contact the rfLMA.


New text:

   A MN can be multi-homed i.e. have network connectivity over multiple
   interfaces connected one or more accesses).  A single LMA entity SHOULD
   have the control over all possible multi-homed mobility sessions the MN
   has or otherwise handovers between different accesses and interfaces
   become challenged, if not impossible.  All mobility sessions a
   multi-homed MN may have SHOULD be anchored in the single LMA entity.
   Therefore, once the MN has established one mobility session with one LMA,
   the subsequent mobility sessions of the same MN SHOULD be anchored to the
   LMA that was initially assigned.

   One possible solution already supported by this specification is
   applying the runtime LMA assignment only for the very first initial
   attach a multi-homed MN does towards a PMIPv6 domain.  After the
   initial attach, the assigned r2LMA Address has been stored in the
   policy profile.  For the subsequent mobility sessions of the multi-
   homed MN, the same assigned r2LMA Address would be used and there is
   no need to contact the rfLMA. Discovering the same r2LMA each time
   has an assumption that the MN has an identity that can always point
   to the same policy profile independent of the used access.
   


 
 Minor issues:
 
 Section 5.2:
   Otherwise, the rfLMA 

Re: [Gen-art] Gen-ART LC telechat review of draft-ietf-netlmm-lma-discovery-07.txt

[jouni korhonen]

Hi Brian,

On Oct 21, 2010, at 1:27 AM, Brian E Carpenter wrote:

 Hi Jouni,
 
 SLP often seems to be forgotten, but it was designed for this
 sort of use, as far as I can see. I've also been told (and I
 don't know if this is true) that SLP code is present in many systems,
 although normally used for printer discovery.
 
 However, perhaps the real gap in the draft is that you don't explain
 where the list of candidate solutions comes from. Maybe you can add

Good point. Sometimes we expect people to be familiar with all the history 
related to some topic ;)

 another sentence in the Introduction along the lines of
 
 The approaches discussed do not include all possible discovery mechanisms,
 but are limited to those considered to fit most simply into the PMIPv6
 environment.

Thanks. The above text looks good and I am fine adding it.

- Jouni

 
 Regards
   Brian Carpenter
 
 On 2010-10-21 10:36, jouni korhonen wrote:
 Hi Brian,
 
 Thank you for the review. Regarding the issues see inline:
 
 1. There is no discussion of using Service Location Protocol (RFC 2165).
 Maybe it is unsuitable, but that should be explained if so.
 
 SLP has never been brought up in any discussion regarding the I-D or LMA 
 discovery in forums I am familiar with. There are many other protocols out 
 there that could be used for discovery purposes but we are not describing 
 their possible use or why they did not get selected as a solution proposal 
 in this I-D. I do not see any reason to mention SLP within the context of 
 this I-D.
 
 2. There is no discussion of whether the chosen solution should preferably
 return an IP address or an FQDN. Since there is a general architectural
 recommendation to use FQDNs (RFC 1958) this draft should, IMHO, either
 follow that recommendation or give a good reason why not.
 
 Good point. I would be fine to reword the Section 5 last paragraph as:
 
   ...
   heterogeneous environments.  Therefore, using AAA based LMA discovery
   solutions are recommended by this document. Furthermore, following the
   guidance in Section 4.1 of [RFC1958] the use of FQDNs should be preferred
   over IP addresses in the context of AAA based LMA discovery solutions.
 
 - Jouni
 
 
 On Oct 16, 2010, at 11:14 PM, Brian E Carpenter wrote:
 
 Due to time-compression this is both a Last Call and pre-telechat review.
 
   Brian
 
 
 
 draft-ietf-netlmm-lma-discovery-07-carpenter.txt
 
 

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

Re: [Gen-art] Gen-ART LC telechat review of draft-ietf-netlmm-lma-discovery-07.txt

[jouni korhonen]

Hi Brian,

Thank you for the review. Regarding the issues see inline:


1. There is no discussion of using Service Location Protocol (RFC 2165).
Maybe it is unsuitable, but that should be explained if so.

SLP has never been brought up in any discussion regarding the I-D or LMA 
discovery in forums I am familiar with. There are many other protocols out 
there that could be used for discovery purposes but we are not describing their 
possible use or why they did not get selected as a solution proposal in this 
I-D. I do not see any reason to mention SLP within the context of this I-D.

2. There is no discussion of whether the chosen solution should preferably
return an IP address or an FQDN. Since there is a general architectural
recommendation to use FQDNs (RFC 1958) this draft should, IMHO, either
follow that recommendation or give a good reason why not.

Good point. I would be fine to reword the Section 5 last paragraph as:

   ...
   heterogeneous environments.  Therefore, using AAA based LMA discovery
   solutions are recommended by this document. Furthermore, following the
   guidance in Section 4.1 of [RFC1958] the use of FQDNs should be preferred
   over IP addresses in the context of AAA based LMA discovery solutions.

- Jouni


On Oct 16, 2010, at 11:14 PM, Brian E Carpenter wrote:

 Due to time-compression this is both a Last Call and pre-telechat review.
 
Brian
 
 
 
 draft-ietf-netlmm-lma-discovery-07-carpenter.txt

___
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-dime-nai-routing-02

[jouni korhonen]

Hi Pete,

I have updated the I-D based on your comments. The -03 version should  
be available readily in draft repositories.


Cheers,
Jouni



On Aug 4, 2009, at 8:41 PM, McCann Peter-A001034 wrote:


Hi, Jouni,

Thanks, I went back and re-read Section 2.8 of RFC 3588 and
refreshed my understanding of Diameter Answer routing.  You are
correct that the reverse path routing is taken care of by the
transaction state.  Perhaps you could add one sentence about
the Answer routing with a reference to Section 2.8 of RFC 3588?

I suppose using the Application ID for expressing support for
the feature is ok if that is the will of the working group.

-Pete

jouni korhonen wrote:

Hi Peter,

Thanks for the review. See my comments inline.


On Aug 3, 2009, at 9:17 PM, McCann Peter-A001034 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 resolve these comments along with any other Last Call
comments you may receive.

Document: draft-ietf-dime-nai-routing-02
Reviewer: Pete McCann
Review Date: 2009-08-03
IETF LC End Date: 2009-08-04
IESG Telechat date: unknown

Summary: Two major issues need discussion


Major issues:

The draft seems to address only routing of Request commands.  What
about Answers?  Are Diameter proxies required to re-write the


Answers follow the reverse path the request traversed. The answers
are processed according to base RFC3588.


Origin-Realm and Origin-Host AVPs as the request gets routed?


No. Both Origin-Realm and Origin-Host correspond to the entity that
originated the request.

Are they required then to maintain state to map the responses back  
to

the originating realm?  The processing rules seem to strip off


Not really. Intermediating agents only need to maintain a transaction
state. This is the same as required for normal RFC3588 request-answer
processing.


the decoration from the NAI; there might be a need for the home AAA
server to know the path that was taken through the network (routing
the Answer commands is only one possible reason).  Maybe the  
solution

is to provide a decorated Origin-Realm that is recomputed by each
hop.


RFC3588 Route-Record AVP already provides this information. I see no
reason to go any further here regarding to changes/enhancements to
RFC3588 answer processing.




4.2. Ensuring Backwards Compatibility

Implementations compliant to this specification MUST define a new
Diameter application.  This requirement is set to guarantee
backwards compatibility with existing Diameter implementations,
applications and deployments.  Diameter agents not compliant with
this specification will not advertise support for these new
applications that implement the enhanced routing solution based on
Decorated NAIs and will therefore be bypassed.


This requirement troubles me; does this mean that every Diameter
application will need to define a whole set of Application-IDs,  
based

on the cross-product of every feature that gets introduced?  Maybe
this is a general problem with Diameter application versioning, and
it's too late to fix it.  Is there a better way to somehow indicate
support for this feature?


It indeed is a general issue with Diameter application versioning
(some SDOs have introduced their own versioning schemes to avoid
defining new applications for e.g. every new release). There was
lengthy discussion of possible choices how to solve it for this I-D.
Requiring a new application seemed to be the easiest way to get
forward. Generally, one application can/should include several new
features so the explosion on applications should not become a
problem..



Minor issues:


Nits/editorial comments:

End of Section 3:


[RFC5113] Section 2.3. also discusses NAI decoration related issues
with EAP [RFC3748] in general.
Seems there is an extra period after Section 2.3.  Suggest  
changing

the reference pointer to text, i.e.,

Section 2.3 of RFC5113 also discusses NAI decoration related issues
with EAP [RFC3748] in general.


Section 4.1:


an uniform

SHOULD BE:

a uniform


Section 6:

In this case the NAS to the Diameter server AAA communication rely

on
SHOULD BE:

In this case the NAS to Diameter server AAA communication relies on


Thanks. Will fix these.

Cheers,
Jouni




___
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-dime-pmip6-02.txt

[jouni korhonen]

Sounds OK to me.

cheers,
Jouni

On Aug 17, 2009, at 3:05 PM, Spencer Dawkins wrote:


Hi, Julian,

If this is a concern, I would be FINE with text that says

Whenever the MAG sends a Diameter request message to the HAAA, the  
User-Name SHOULD contain the MN's identity unless the identity is  
being suppressed for policy reasons - for example, when identity  
hiding is in effect.


Does that help?

Thanks,

Spencer

- Original Message - From: julien.bourne...@orange-ftgroup.com 


To: spen...@wonderhamster.org; jouni.nos...@gmail.com
Cc: draft-ietf-dime-pm...@tools.ietf.org; gen-art@ietf.org
Sent: Monday, August 17, 2009 7:57 AM
Subject: RE: Gen-ART Review of draft-ietf-dime-pmip6-02.txt


Hello,

thanks for your Gen-ART review... one comment below:


-Message d'origine-
De : Spencer Dawkins [mailto:spen...@wonderhamster.org]
Envoyé : lundi 10 août 2009 00:31
À : jouni korhonen
Cc : draft-ietf-dime-pm...@tools.ietf.org; General Area Review Team
Objet : Re: Gen-ART Review of draft-ietf-dime-pmip6-02.txt

i think we're down to one item...

 5.1.  MAG-to-HAAA Interface

 Whenever the MAG sends a Diameter request message to the
HAAA the
 User-Name AVP SHOULD contain the MN's identity.  The MN
identity,
 if

 Spencer (minor): what is this SHOULD conditional on?

 In case of identity hiding is applied, the User-Name can
be absent.

 Ah - if my understanding is correct, the text might be clearer as
 Whenever the MAG sends a Diameter request message to the HAAA and
 identity hiding is not in effect, the User-Name MUST contain the
 MN's identity.

 I am still a bit hesitant with the MUST here. Anyway, if
other authors
 don't disagree I am ok with the proposed change.

I would be OK with a SHOULD - you've provided at least one
reason why it's not an unconditional MUST - but please check
with other authors and doc shepherd.



I'm ok with the proposed text. I just hope there's no other case  
where the User-Name may not be available.


Regards,

Julien



thanks for the quick responses!

spencer

 available, MUST be in Network Access Identifier (NAI) [RFC4282]
 format.  At minimum the home realm of the MN MUST be
available at
 the MAG when the network access authentication takes place.
 Otherwise the MAG is not able to route the Diameter request
 messages towards the correct HAAA.  The MN identity used on the
 MAG-to-HAAA interface and in the User-Name AVP MAY entirely be
 related to the network access authentication, and therefore not
 suitable to be used as the MN-ID mobility option value in the
 subsequent PBU/PBA messages.  See the related discussion on MN's
 identities in Section 4.6 and in Section 5.2.1





___
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-dime-pmip6-02.txt

[jouni korhonen]

Hi Spencer,

Sorry for the lag.. sometimes holidays interfere working ;) See more  
comments inline.



On Aug 6, 2009, at 8:02 PM, Spencer Dawkins wrote:


Hi, Jouni,

Thanks for the quick response. If I wasn't still jet-lagged, I could  
remember what I was thinking when I did the review :-)


Responses inline... and I deleted stuff we already agreed on.


Ack.



Spencer


1.  Introduction

This specification defines the Diameter support for PMIPv6.  In the
context of this specification the location of the subscriber policy
profile equals to the home Diameter server, which is also referred  
as


Spencer (clarity): this sentence is difficult to parse - is it   
saying In this specification, the home Diameter server, which is   
also referred to as the home AAA server (HAAA), contains the   
subscriber policy profile? If it doesn't, I'm too confused to  
make  a suggestion...


How about:

In the context of this specification the home AAA server (HAAA)
functionality is co-located with the subscriber policy profile.



Much clearer - thanks!


Ok. Will change the text according to this.






the home AAA server (HAAA).  The NAS functionality of the MAG may be
co-located or an integral part of the MAG.

4.5.  MIP6-Feature-Vector AVP

LOCAL_MAG_ROUTING_SUPPORTED (0x0400)

   Direct routing of IP packets between MNs anchored to the same MAG
   is supported.  When a MAG sets this bit in the MIP6-Feature-
   Vector, it indicates that routing IP packets between MNs anchored
   to the same MAG is supported, without reverse tunneling packets
   via the LMA or requiring any Route Optimization related signaling
   (e.g. the Return Routability Procedure in [RFC3775]) prior direct
   routing.  If this bit is unset in the returned MIP6-Feature- 
Vector


Spencer (clarity): I'd say if this bit is cleared.


OK.


   AVP, the HAAA does not authorize direct routing of packets  
between

   MNs anchored to the same MAG.  This policy feature SHOULD be
   supported per MN and subscription basis.

Spencer (minor): it's not clear who SHOULD be supporting this   
feature - who does the 2119 SHOULD apply to? I would guess it   
applies to the MAG, but I'm guessing. Is this supported on a per- 
MN  and per-subscription basis? And I'm not sure why this SHOULD  
isn't  a MUST.


supported on a per-MN and per-subscription basis is what the  
text  tries to say.


If people think it's clear enough, that's fine. I was just getting  
lost.


I'll change the text according to supported per-MN and per- 
subscription basis as it definitely clearer.





It is SHOULD as the RFC5213 does not mandate whether the local  
routing  is per-MN (uses MAY in RFC5213) or applies to whole MAG.  
Therefore, we  felt SHOULD is enough and final decision is then  
left for the deployment/system.


That's fine.

Sorry for asking three questions back-to-back.

The question that may have gotten lost is who is required to  
support this? - the MAG, or the HAAA, or both? This statement  
occurs in text that describes the message flow. I'm understanding  
your response as saying that the requirement applies to the MAG, but  
one reasonable interpretation is that it applies to both the MAG and  
HAAA (since they exchange messages with this AVP).


Suggest The MAG SHOULD support this policy feature on a per MN and  
subscription basis.


This is OK.






5.1.  MAG-to-HAAA Interface

Whenever the MAG sends a Diameter request message to the HAAA the
User-Name AVP SHOULD contain the MN's identity.  The MN identity, if

Spencer (minor): what is this SHOULD conditional on?


In case of identity hiding is applied, the User-Name can be absent.


Ah - if my understanding is correct, the text might be clearer as  
Whenever the MAG sends a Diameter request message to the HAAA and  
identity hiding is not in effect, the User-Name MUST contain the  
MN's identity.


I am still a bit hesitant with the MUST here. Anyway, if other authors  
don't disagree I am ok with the proposed change.






available, MUST be in Network Access Identifier (NAI) [RFC4282]
format.  At minimum the home realm of the MN MUST be available at  
the

MAG when the network access authentication takes place.  Otherwise
the MAG is not able to route the Diameter request messages towards
the correct HAAA.  The MN identity used on the MAG-to-HAAA interface
and in the User-Name AVP MAY entirely be related to the network
access authentication, and therefore not suitable to be used as the
MN-ID mobility option value in the subsequent PBU/PBA messages.  See
the related discussion on MN's identities in Section 4.6 and in
Section 5.2.1





Cheers,
Jouni

___
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-dime-pmip6-02.txt

[jouni korhonen]

Hi Spencer,

Thanks for the review. See my responses inline.


On Aug 4, 2009, at 10:45 PM, Spencer Dawkins 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-dime-pmip6-02.txt
Reviewer: Spencer Dawkins
IETF LC End Date: 2009-08-05
Review Date: 2009-08-03
IESG Telechat date: (not known)

Summary: This specification is almost ready for publication as a  
Proposed Standard. I have some minor comments, mostly involving 2119  
language.


1.  Introduction

 This specification defines the Diameter support for PMIPv6.  In the
 context of this specification the location of the subscriber policy
 profile equals to the home Diameter server, which is also referred as

Spencer (clarity): this sentence is difficult to parse - is it  
saying In this specification, the home Diameter server, which is  
also referred to as the home AAA server (HAAA), contains the  
subscriber policy profile? If it doesn't, I'm too confused to make  
a suggestion...


How about:

In the context of this specification the home AAA server (HAAA)
functionality is co-located with the subscriber policy profile.




 the home AAA server (HAAA).  The NAS functionality of the MAG may be
 co-located or an integral part of the MAG.

4.5.  MIP6-Feature-Vector AVP

 LOCAL_MAG_ROUTING_SUPPORTED (0x0400)

Direct routing of IP packets between MNs anchored to the same MAG
is supported.  When a MAG sets this bit in the MIP6-Feature-
Vector, it indicates that routing IP packets between MNs anchored
to the same MAG is supported, without reverse tunneling packets
via the LMA or requiring any Route Optimization related signaling
(e.g. the Return Routability Procedure in [RFC3775]) prior direct
routing.  If this bit is unset in the returned MIP6-Feature-Vector

Spencer (clarity): I'd say if this bit is cleared.


OK.




AVP, the HAAA does not authorize direct routing of packets between
MNs anchored to the same MAG.  This policy feature SHOULD be
supported per MN and subscription basis.

Spencer (minor): it's not clear who SHOULD be supporting this  
feature - who does the 2119 SHOULD apply to? I would guess it  
applies to the MAG, but I'm guessing. Is this supported on a per-MN  
and per-subscription basis? And I'm not sure why this SHOULD isn't  
a MUST.


supported on a per-MN and per-subscription basis is what the text  
tries to say.


It is SHOULD as the RFC5213 does not mandate whether the local routing  
is per-MN (uses MAY in RFC5213) or applies to whole MAG. Therefore, we  
felt SHOULD is enough and final decision is then left for the  
deployment/system.





4.8.  Service-Selection AVP

 It is also possible that the MAG receives the service selection
 information from the MN, for example, via some lower layer mechanism.
 In this case the MAG SHOULD include the Service-Selection AVP also in

Spencer (minor): why is this a SHOULD, and not a MUST?


I would be fine with MUST here.




 the MAG-to-HAAA request messages.  In absence of the Service-
 Selection AVP in the MAG-to-HAAA request messages, the HAAA may want
 to inform the MAG of the default service provisioned to the MN and
 include the Service-Selection AVP in the response message.

5.1.  MAG-to-HAAA Interface

 Whenever the MAG sends a Diameter request message to the HAAA the
 User-Name AVP SHOULD contain the MN's identity.  The MN identity, if

Spencer (minor): what is this SHOULD conditional on?


In case of identity hiding is applied, the User-Name can be absent.



 available, MUST be in Network Access Identifier (NAI) [RFC4282]
 format.  At minimum the home realm of the MN MUST be available at the
 MAG when the network access authentication takes place.  Otherwise
 the MAG is not able to route the Diameter request messages towards
 the correct HAAA.  The MN identity used on the MAG-to-HAAA interface
 and in the User-Name AVP MAY entirely be related to the network
 access authentication, and therefore not suitable to be used as the
 MN-ID mobility option value in the subsequent PBU/PBA messages.  See
 the related discussion on MN's identities in Section 4.6 and in
 Section 5.2.1

Spencer (nit): missing period here.


OK.



5.2.1.  Authorization of the Proxy Binding Update

 Whenever the LMA sends a Diameter request message to the HAAA, the
 User-Name AVP SHOULD contain the MN's identity.  The LMA MAY retrieve

Spencer (minor): what is this SHOULD conditional on?


The profile for LMA-HAAA proposed in this specification is going to  
be used on top of some other application. That some other application  
may not use User-Name, thus we felt SHOULD is strong enough to give  
guidance to do so..




 the MN's identity information from the PBU MN-ID 

Re: [Gen-art] Gen-ART Review of draft-ietf-dime-nai-routing-02

[jouni korhonen]

Hi Peter,

Thanks for the review. See my comments inline.


On Aug 3, 2009, at 9:17 PM, McCann Peter-A001034 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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dime-nai-routing-02
Reviewer: Pete McCann
Review Date: 2009-08-03
IETF LC End Date: 2009-08-04
IESG Telechat date: unknown

Summary: Two major issues need discussion


Major issues:

The draft seems to address only routing of Request commands.  What
about Answers?  Are Diameter proxies required to re-write the


Answers follow the reverse path the request traversed. The answers are  
processed according to base RFC3588.



Origin-Realm and Origin-Host AVPs as the request gets routed?


No. Both Origin-Realm and Origin-Host correspond to the entity that  
originated the request.



Are they required then to maintain state to map the responses back
to the originating realm?  The processing rules seem to strip off


Not really. Intermediating agents only need to maintain a transaction  
state. This is the same as required for normal RFC3588 request-answer  
processing.



the decoration from the NAI; there might be a need for the home AAA
server to know the path that was taken through the network (routing
the Answer commands is only one possible reason).  Maybe the solution
is to provide a decorated Origin-Realm that is recomputed by each
hop.


RFC3588 Route-Record AVP already provides this information. I see no  
reason to go any further here regarding to changes/enhancements to  
RFC3588 answer processing.





4.2. Ensuring Backwards Compatibility

 Implementations compliant to this specification MUST define a new
 Diameter application.  This requirement is set to guarantee

backwards

 compatibility with existing Diameter implementations, applications
 and deployments.  Diameter agents not compliant with this
 specification will not advertise support for these new applications
 that implement the enhanced routing solution based on Decorated NAIs
 and will therefore be bypassed.


This requirement troubles me; does this mean that every Diameter
application
will need to define a whole set of Application-IDs, based on the
cross-product
of every feature that gets introduced?  Maybe this is a general  
problem

with
Diameter application versioning, and it's too late to fix it.  Is  
there

a
better way to somehow indicate support for this feature?


It indeed is a general issue with Diameter application versioning  
(some SDOs have introduced their own versioning schemes to avoid  
defining new applications for e.g. every new release). There was  
lengthy discussion of possible choices how to solve it for this I-D.  
Requiring a new application seemed to be the easiest way to get  
forward. Generally, one application can/should include several new  
features so the explosion on applications should not become a problem..




Minor issues:


Nits/editorial comments:

End of Section 3:


 [RFC5113] Section 2.3. also discusses NAI decoration related issues
 with EAP [RFC3748] in general.

Seems there is an extra period after Section 2.3.  Suggest changing
the reference pointer to text, i.e.,

 Section 2.3 of RFC5113 also discusses NAI decoration related issues
 with EAP [RFC3748] in general.


Section 4.1:


 an uniform

SHOULD BE:

 a uniform


Section 6:

 In this case the NAS to the Diameter server AAA communication rely

on
SHOULD BE:

 In this case the NAS to Diameter server AAA communication relies on


Thanks. Will fix these.

Cheers,
Jouni



___
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-dime-nai-routing-02

[jouni korhonen]

Hi Peter,

On Aug 4, 2009, at 8:41 PM, McCann Peter-A001034 wrote:


Hi, Jouni,

Thanks, I went back and re-read Section 2.8 of RFC 3588 and
refreshed my understanding of Diameter Answer routing.  You are
correct that the reverse path routing is taken care of by the
transaction state.  Perhaps you could add one sentence about
the Answer routing with a reference to Section 2.8 of RFC 3588?


Will add this.



I suppose using the Application ID for expressing support for
the feature is ok if that is the will of the working group.


I would say it fulfilled the description of a rough consensus.  
Everybody was equally unhappy ;)


Cheers,
Jouni




-Pete

jouni korhonen wrote:

Hi Peter,

Thanks for the review. See my comments inline.


On Aug 3, 2009, at 9:17 PM, McCann Peter-A001034 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 resolve these comments along with any other Last Call
comments you may receive.

Document: draft-ietf-dime-nai-routing-02
Reviewer: Pete McCann
Review Date: 2009-08-03
IETF LC End Date: 2009-08-04
IESG Telechat date: unknown

Summary: Two major issues need discussion


Major issues:

The draft seems to address only routing of Request commands.  What
about Answers?  Are Diameter proxies required to re-write the


Answers follow the reverse path the request traversed. The answers
are processed according to base RFC3588.


Origin-Realm and Origin-Host AVPs as the request gets routed?


No. Both Origin-Realm and Origin-Host correspond to the entity that
originated the request.

Are they required then to maintain state to map the responses back  
to

the originating realm?  The processing rules seem to strip off


Not really. Intermediating agents only need to maintain a transaction
state. This is the same as required for normal RFC3588 request-answer
processing.


the decoration from the NAI; there might be a need for the home AAA
server to know the path that was taken through the network (routing
the Answer commands is only one possible reason).  Maybe the  
solution

is to provide a decorated Origin-Realm that is recomputed by each
hop.


RFC3588 Route-Record AVP already provides this information. I see no
reason to go any further here regarding to changes/enhancements to
RFC3588 answer processing.




4.2. Ensuring Backwards Compatibility

Implementations compliant to this specification MUST define a new
Diameter application.  This requirement is set to guarantee
backwards compatibility with existing Diameter implementations,
applications and deployments.  Diameter agents not compliant with
this specification will not advertise support for these new
applications that implement the enhanced routing solution based on
Decorated NAIs and will therefore be bypassed.


This requirement troubles me; does this mean that every Diameter
application will need to define a whole set of Application-IDs,  
based

on the cross-product of every feature that gets introduced?  Maybe
this is a general problem with Diameter application versioning, and
it's too late to fix it.  Is there a better way to somehow indicate
support for this feature?


It indeed is a general issue with Diameter application versioning
(some SDOs have introduced their own versioning schemes to avoid
defining new applications for e.g. every new release). There was
lengthy discussion of possible choices how to solve it for this I-D.
Requiring a new application seemed to be the easiest way to get
forward. Generally, one application can/should include several new
features so the explosion on applications should not become a
problem..



Minor issues:


Nits/editorial comments:

End of Section 3:


[RFC5113] Section 2.3. also discusses NAI decoration related issues
with EAP [RFC3748] in general.
Seems there is an extra period after Section 2.3.  Suggest  
changing

the reference pointer to text, i.e.,

Section 2.3 of RFC5113 also discusses NAI decoration related issues
with EAP [RFC3748] in general.


Section 4.1:


an uniform

SHOULD BE:

a uniform


Section 6:

In this case the NAS to the Diameter server AAA communication rely

on
SHOULD BE:

In this case the NAS to Diameter server AAA communication relies on


Thanks. Will fix these.

Cheers,
Jouni




___
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-korhonen-mip4-service-06

[jouni korhonen]

Hi Spencer,


On Dec 29, 2008, at 6:13 PM, Spencer Dawkins wrote:


Hi, Jouni,

Thanks for your quick response - I'm OK with most of your proposed  
changes.


I should emphasize that my comments here are Last Call comments that  
you (and the document shepherd, and the AD) can decide to ignore -  
I'm just telling you what I'm seeing when I read the text.


Just to finish up:


Some of the potential use-cases were listed earlier in this section.
The general aim is better manageability of services and service
provisioning from both operators and service providers point of  
view.

However, it should be understood that there are potential deployment
possibilities where selecting a certain service may restrict
simultaneous access to other services from an user point of view.
For example, services may be located in different administrative
domains or external customer networks that practice excessive
filtering of inbound and outbound traffic.

Spencer: I wasn't clear on who this understanding is directed to -  
it almost reads like you're warning users that bad things might  
happen if you use a specific service, but surely the user  
specifies the service because an operator requires this?


We had this discussion earlier on RFC5149.. and concerns were raised
whether the Service Selection is a potential tool for enabling walled
gardens etc. Thus this note here was added to emphasize that point.


I understand your point from your explanation, but can't get that  
understanding from the draft text. If you said


s/from a user point of view/from a user point of view (for example,  
a walled garden)/


that would be as clear as your explanation.


Ok. Thanks. Will add this.






3.  Service Selection Extension

At most one Service Selection extension MAY be included in any  
Mobile
IPv4 Registration Request message.  It SHOULD be included at least  
in


Spencer: seems to be missing a qualifier: When a non-default  
service is selected, the Service Selection extension SHOULD be  
included ...?


Spencer: If this is qualified, could the SHOULD be a MUST?


Hmm.. right. New text would be:

 At most one Service Selection extension MAY be included in any  
Mobile
 IPv4 Registration Request message.  When a non-default service is  
selected,

 the Service Selection extension SHOULD be included at least in
 the Registration Request message that is sent for the initial  
binding

 registration when the mobile node and the home agent do not have an
 existing binding.  The Service Selection extension MUST be placed in
 the Registration Request message as follows:



Spencer: If it remains as SHOULD, what happens if the Service  
Selection extension is not included in the initial binding  
registration, but is included in subsequent binding registrations?


The first RRQ would be treated as the selection of the default
service. The subsequent RRQs with the service selection would cause
reauthorization  evaluation of the requested service. If the newly
requested service conflicts with the default service from the HA
point of view, then an appropriate error is returned and the binding
is dropped.


I'm still confused by


When a non-default service is selected,
 the Service Selection extension SHOULD be included at least in
 the Registration Request message that is sent for the initial  
binding

 registration when the mobile node and the home agent do not have an
 existing binding.


My understanding from your explanation is that, by definition, if  
you don't include the Service Selection extension, you aren't  
selecting a non-default service until you DO send an RRQ that  
includes the Service Selection extension - right? If I'm tracking  
you, you're talking about two cases at the same time - what happens  
if you DO include the extension in the first RRQ, and what happens  
if you DON'T include the extension in the first RRQ, then switch to  
a non-default service by including the Service Selection extension  
in a subsequent RRQ - that would be why I was confused.


I think your explanation is way clearer than the draft text -  
perhaps you could insert it into the draft text?


A new try:

   At most one Service Selection extension MAY be included in any  
Mobile

   IPv4 Registration Request message.  The Service Selection extension
   SHOULD be included at least in the Registration Request message that
   is sent for the initial binding registration when the mobile node  
and

   the home agent do not have an existing binding. In absence of a
   specifically indicated service in the Registration Request for the
   initial binding registration, the home agent MUST act as if the  
default
   service, such as plain Internet access had been requested. The  
absence

   of the Service Selection extension in a Registration Request that
   refreshes an existing binding MUST be treated as if the existing  
service
   selection is maintained. The Service Selection extension MUST be  
placed

   in the Registration