島岡 政基 | 1 Jan 03:11 2008
Picon

RE: Gen-art review of draft-shimaoka-multidomain-pki-11.txt

Hi Elwyn,

Many thanks for your detailed reviews as Gen-ART.
I am going to check your comments deeply next week and update the I-D.

Thank you,
-- Shima

-----Original Message-----
From: Elwyn Davies [mailto:elwynd <at> dial.pipex.com]
Sent: 2008/01/01 (火) 0:41
To: General Area Review Team
Cc: Mary Barnes; 島岡 政基; nelson.hastings <at> nist.gov; nielsen_rebecca <at> bah.com; IETF
Discussion; Russ Housely
Subject: Gen-art review of draft-shimaoka-multidomain-pki-11.txt

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-shimaoka-multidomain-pki-11.txt
Reviewer: Elwyn Davies
Review Date: 28 December 2007
IETF LC End Date: 1 January 2008
IESG Telechat date: (if known) -

Summary:
(Continue reading)

Vijay K. Gurbani | 2 Jan 18:38 2008

Gen-ART review of draft-ietf-btns-core-05.txt

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-btns-core-05.txt
Reviewer: Vijay K. Gurbani
Review Date: 2 Jan 2008
IESG Telechat date: 9 Jan 2008

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

A couple of nits below.

- S1, fifth paragraph:
     s/and [RFC4301]'s concepts./and concepts discussed in [RFC4301]./

- In S3, nodes A, B, and SG-A are bracketed ([A], [SG-A], etc.)
  This makes them look like references, especially in case of [SG-A].
  A minor comment would be to not adorn the node names with square
  brackets, of if you really wanted to do so, use normal brackets (i.e.,
  (SG-A)) or curly braces (i.e., {SG-A}).

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
(Continue reading)

Mary Barnes | 4 Jan 05:34 2008

Assignments for 10 Jan 2008

Hi all,

Here's the link to the summary of assignments for the Jan 10, 2008 telechat:
http://www.alvestrand.no/ietf/gen/art/reviewers-080110.html

With the updated spreadsheets:
http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

For your convenience, the review boilerplate template is included below.

Mary.

-------------------------------------------------------------------

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:
Reviewer:
Review Date: 
IESG Telechat date: 10 Jan 2008

Summary:

Comments:



_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
Mary Barnes | 4 Jan 05:35 2008

A *new* batch of IETF LC reviews - 03 Jan 2007

Hi all,

Here's this week's LC assignments: 
http://www.alvestrand.no/ietf/gen/art/gen-art.html 
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html 

The standard template is included at the end of the assignments.  

Thanks, 
Mary. 

--------------------------- 
Reviewer: David Black

- 'Requirements from SIP (Session Initiation Protocol) Session Border 
   Control Deployments '
   <draft-ietf-sipping-sbc-funcs-04.txt> as an Informational RFC

IETF LC ends on 2008-01-16. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
15491&rfc_flag=0

--------------------------- 
Reviewer: Elwyn Davies

- 'Generalized MANET Packet/Message Format '
   <draft-ietf-manet-packetbb-11.txt> as a Proposed Standard

IETF LC ends on 2008-01-16. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-11.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
14431&rfc_flag=0

--------------------------- 
Reviewer: Eric Gray

- 'Representing multi-value time in MANETs '
   <draft-ietf-manet-timetlv-04.txt> as a Proposed Standard

IETF LC ends on 2008-01-16. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
15966&rfc_flag=0

--------------------------- 
Reviewer: Francis Dupont

- 'IMAP METADATA Extension '
   <draft-daboo-imap-annotatemore-12.txt> as a Proposed Standard

IETF LC ends on 2008-01-30. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-12.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
8469&rfc_flag=0

--------------------------- 
Reviewer: Gonzalo Camarillo

- 'Considerations for Having a Successful BOF '
   <draft-narten-successful-bof-03.txt> as an Informational RFC

IETF LC ends on 2008-01-30. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-narten-successful-bof-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
13931&rfc_flag=0

--------------------------- 
Reviewer: Harald Alvestrand

- 'IANA Ethernet Considerations '
   <draft-eastlake-ethernet-iana-considerations-05.txt> as a BCP

IETF LC ends on 2008-01-30. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-eastlake-ethernet-iana-conside
rations-05.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
16252&rfc_flag=0

--------------------------- 
Reviewer: Joel Halpern

- 'Diameter Policy Processing Application '
   <draft-brenner-dime-peem-01.txt> as an Informational RFC

IETF LC ends on 2008-01-31. 

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-brenner-dime-peem-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
16800&rfc_flag=

-------------------------------------------------------------------

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: 
Reviewer: 
Review Date:  
IETF LC End Date: 
IESG Telechat date: (if known)

Summary:

Comments:
Black_David | 4 Jan 16:47 2008

FW: Gen-ART review of draft-ietf-enum-calendar-service-03.txt

This draft has not been revised since it was reviewed in
August.  It is still basically ready for publication, but
has nits that should be fixed before publication.

An RFC Editor Note should be used to correct the bad section
reference (see below), and the IESG should ensure that this
correction is communicated to IANA, as it affects the
registration that IANA will perform.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: Black, David 
Sent: Friday, August 24, 2007 10:08 AM
To: Rohan Mahy; 'gen-art <at> ietf.org'
Cc: Black, David; 'Jon Peterson'; 'Richard Shockey'; 'Patrik Faltstrom';
'Alexander Mayrhofer'; 'ietf <at> ietf.org'
Subject: Gen-ART review of draft-ietf-enum-calendar-service-03.txt

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-enum-calendar-service-03.txt
Reviewer: David Black
Review Date: 24 August 2007
IETF LC End Date: 6 September 

Summary:
This draft is basically ready for publication, but has nits
that should be fixed before publication.

Comments:
This is a relatively straightforward registration of an ENUM
service, and the draft does a good job of explaining the
service that is being registered.  I found one minor
nit in the service registration (Section 2):

   Security considerations:
      See section 3.

That should be "See section 4." as section 3 contains examples
and section 4 is the Security Considerations.

idnits 2.04.14 did not find any issues.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
Peterson, Jon | 4 Jan 17:18 2008

RE: Gen-ART review of draft-ietf-enum-calendar-service-03.txt


I believe that the RFC-Editor note you request here was already in the tracker at the time that this document
was balloted for an IESG call.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Black_David <at> emc.com [mailto:Black_David <at> emc.com]
> Sent: Friday, January 04, 2008 7:47 AM
> To: rohan <at> ekabal.com; gen-art <at> ietf.org
> Cc: Black_David <at> emc.com; Peterson, Jon; Shockey, Richard; 
> paf <at> cisco.com;
> alexander.mayrhofer <at> enum.at; ietf <at> ietf.org; iesg <at> ietf.org
> Subject: FW: Gen-ART review of draft-ietf-enum-calendar-service-03.txt
> 
> 
> This draft has not been revised since it was reviewed in
> August.  It is still basically ready for publication, but
> has nits that should be fixed before publication.
> 
> An RFC Editor Note should be used to correct the bad section
> reference (see below), and the IESG should ensure that this
> correction is communicated to IANA, as it affects the
> registration that IANA will perform.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david <at> emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> -----Original Message-----
> From: Black, David 
> Sent: Friday, August 24, 2007 10:08 AM
> To: Rohan Mahy; 'gen-art <at> ietf.org'
> Cc: Black, David; 'Jon Peterson'; 'Richard Shockey'; 'Patrik 
> Faltstrom';
> 'Alexander Mayrhofer'; 'ietf <at> ietf.org'
> Subject: Gen-ART review of draft-ietf-enum-calendar-service-03.txt
> 
> 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-enum-calendar-service-03.txt
> Reviewer: David Black
> Review Date: 24 August 2007
> IETF LC End Date: 6 September 
> 
> Summary:
> This draft is basically ready for publication, but has nits
> that should be fixed before publication.
> 
> Comments:
> This is a relatively straightforward registration of an ENUM
> service, and the draft does a good job of explaining the
> service that is being registered.  I found one minor
> nit in the service registration (Section 2):
> 
>    Security considerations:
>       See section 3.
> 
> That should be "See section 4." as section 3 contains examples
> and section 4 is the Security Considerations.
> 
> idnits 2.04.14 did not find any issues.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david <at> emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
Joel M. Halpern | 6 Jan 22:32 2008

Re: LC reviews: draft-brenner-dime-peem

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: Diameter Polic Processing Application
Reviewer: Joel M. Halpern
Review Date:  6-January-2008
IETF LC End Date: 17-January-2008
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as an information 
  RFC.
	The first of the two comments below is probably primarily the IESG's 
concern, although it affects the IETF last call.
	The second comment is a more general issue.

Comments:
	This document requests assignment of a Diameter Command Code.
	As this requires "IETF Consensus" additional care may be needed to 
ensure that the Last Call produces clarity on the required consensus. 
It would seem appropriate for the last call announcement to have 
indicated this requirement.  It is difficult to claim "IETF Consensus" 
from the typical non-response to IETF last call for informational documents.

	It seems exceedingly unlikely that the protocol exchanges to support a 
separate policy processing application introduce no new security issues 
compared with the Diameter base protocol in the assumed Diameter 
deployment.  Obviously, as I am not performing a full review of the 
PEM-1 protocol, I can not assert that there are or are not security 
implications, but it would seem that there are likely to be such.  I 
would be less concerned, but examination of the PEM-1 specification did 
not show the existence of a security discussion which could be taken to 
serve in lieu of such a section.

RE: LC reviews: draft-brenner-dime-peem

Hi Joel,

Thanks for forwarding the below - it helps me in understanding the
process. I am not sure whether I am supposed to respond or not on the
comments you provided, but it cannot hurt - so I will do my best. If I
need to provide those comments to a larger forum, or in a different
forum - please advise.

On the 1st comments, regarding IETF consensus, this may be something
that others (e.g. Dan Romascanu maybe) can help with - I am not sure I
am familiar enough with the IETF processes to suggest any changes.

As per the 2nd comment - indeed there are no additional security
concerns with respect to the use of the Diameter protocol for the PEEM
specification.  What may help understanding why this is the case, is the
overall approach in OMA specifications. OMA develops granular
specifications, not end-to-end service specifications or solution
specifications. However, there are separate security specifications that
any vendor can bundle with any other enabler specifications, in order to
ensure any security concerns are addressed when a product is built. One
such mechanism is the use of security policies applied in a proxy
pattern (i.e. BEFORE any request reaches its target). Such security
poclieis (e.g. for authentication or authorization) may be applied on
the call carrying the PEM-1 request. A second mechanism is to use
specifications produced by another OMA group (OMA SECurity Working
Group) which produced a set of sepcifications called SECurity Common
Functions, that are used at different protocol layers to ensure
authentication, confidentiality, integrity of the exchange. OMA does
this on purpose to avoid the development of silo-specifications (i.e.
specifications where each functionality also addresses in a
silo-approach all security aspects).

The reason why we have honored the Diameter base protocol security
requirements is simply because we want to take advantage of
client-server implementations that vendors have produced so far, to
simlify adoption of the PEEM application. Any other security needs would
therefore be addressed in addition to, and outside the scope of the
Diameter application. They have therefore nothing to do with the
submitted IETF draft, and are not to be part of it.

I'll be glad to provide any additional clarifications, or point to
additional security specifications - although none of the latter will
give any indication of how one would integrate additional security with
PEEM specifications - that is on purpose left to vendors and service
providers, to allow for differentiation (again - OMA is NOT in the
business to provide specifications of end-to-end services or solutions).

Best regards,

Michael 

-----Original Message-----
From: Joel M. Halpern [mailto:jmh <at> joelhalpern.com] 
Sent: Sunday, January 06, 2008 4:33 PM
To: gen-art <at> ietf.org
Cc: Mary Barnes; ietf <at> ietf.org; Brenner, Michael Ralf (Michael);
dromasca <at> avaya.com
Subject: Re: LC reviews: draft-brenner-dime-peem

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: Diameter Polic Processing Application
Reviewer: Joel M. Halpern
Review Date:  6-January-2008
IETF LC End Date: 17-January-2008
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as an information
  RFC.
	The first of the two comments below is probably primarily the
IESG's concern, although it affects the IETF last call.
	The second comment is a more general issue.

Comments:
	This document requests assignment of a Diameter Command Code.
	As this requires "IETF Consensus" additional care may be needed
to ensure that the Last Call produces clarity on the required consensus.

It would seem appropriate for the last call announcement to have
indicated this requirement.  It is difficult to claim "IETF Consensus" 
from the typical non-response to IETF last call for informational
documents.

	It seems exceedingly unlikely that the protocol exchanges to
support a separate policy processing application introduce no new
security issues compared with the Diameter base protocol in the assumed
Diameter deployment.  Obviously, as I am not performing a full review of
the
PEM-1 protocol, I can not assert that there are or are not security
implications, but it would seem that there are likely to be such.  I
would be less concerned, but examination of the PEM-1 specification did
not show the existence of a security discussion which could be taken to
serve in lieu of such a section.
Brian E Carpenter | 7 Jan 03:31 2008
Picon

Gen-ART review of draft-ietf-v6ops-802-16-deployment-scenarios-06.txt


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-v6ops-802-16-deployment-scenarios-06.txt
Reviewer: Brian Carpenter
Review Date: 2008-01-07
IETF LC End Date: n/a
IESG Telechat date: 2008-01-10

Summary: Clarifications needed in discussions of mobility, QoS, AAA.

Comments: 

I have a little difficulty reviewing this since I think that the
802.16 model (with several alternative convergence sublayers instead of
simply emulating Ethernet service) is fundamentally misguided. So
I'm pessimistic about the success of WiMax in general. However,
this draft attempts to deal with the way 802.16 has been designed
and is not to blame for the defects in that design.

(I apologise for not making these comments during WG Last Call.)


> 2.2.1.5.  Mobility
>
>    As for mobility management, the movement between BSs is handled by
>    Mobile IPv6 [RFC3775], if it requires a subnet change.  

This is a bit confusing as it is followed by some references
to 802.16 layer 2 roaming. This whole discussion would be easier to
understand if reorganized to clearly separate the layer 2 and layer 3
issues. For example:

>    In addition, due to the problems caused by the existence of multiple
>    convergence sublayers [RFC4840], the mobile access scenarios need
>    solutions about how roaming will work when forced to move from one CS
>    to another (e.g., IPv6 CS to Ethernet CS).  Note that, at this phase
>    this issue is the out of scope of this document.  It should be also
>    discussed in the 16ng WG.

This is indeed the crucial defect in the 802.16 design - but are we discussing
the layer 2 problem (noticing that it's time to switch to a different
convergence sublayer) or the layer 3 problem (noticing that Mobile IPv6
needs to find a new router and c/o address)?

Under the fixed-access scenario we find:

>  2.2.2.5.  Mobility
>
>    No mobility functions are supported in the fixed access scenario.
>    However, mobility can be supported in the radio coverage without any
>    mobility protocol like WLAN technology.  Therefore, a user can access
>    Internet nomadically in the coverage.

I can't understand the 2nd and 3rd sentences of this paragraph. Also, I know
of no reason why Mobile IPv6 can't be supported in this scenario if desired.

> 2.4.  IPv6 QoS
>
>    In IEEE 802.16 networks, a connection is unidirectional and has a QoS
>    specification.  The 802.16 supported QoS has different semantics from
>    IP QoS (e.g., diffserv).  Mapping CID to Service Flow IDentifier
>    (SFID) defines QoS parameters of the service flow associated with
>    that connection.  In order to interwork with IP QoS, IP QoS (e.g.,
>    diffserv, or flow label for IPv6) mapping to IEEE 802.16 link
>    specifics should be provided.

This doesn't follow. IP-layer mechanisms for QoS are orthogonal to
layer 2 QoS, and are managed by layer 3 entities, which assume best-effort
QoS at layer 2. In any case, as noted in the draft, the semantics
are different at the different layers. So any attempt at mapping is
propably doomed. Also, the flow label has no semantics today...

> 2.5.  IPv6 Security
>
>    When initiating the connection, an MS is authenticated by the AAA

This is the first time that a connection mechanism is mentioned
in the draft. It seems to need more description or a reference.

>    server located at its service provider network.  All the parameters
>    related to authentication (username, password and etc.) are forwarded
>    by the BS to the AAA server.  The AAA server authenticates the MSs
>    and when an MS is once authenticated and associated successfully with
>    BS, IPv6 an address will be acquired by the MS through stateless
>    autoconfiguration or DHCPv6.  Note the initiation and authentication
>    process is the same as used in IPv4.

Does the AAA exchange run over IP? If so, what IP address is used? If not,
what packetization is used for the AAA exchange?



_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
Romascanu, Dan (Dan | 7 Jan 07:07 2008

RE: LC reviews: draft-brenner-dime-peem


> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh <at> joelhalpern.com] 

> 	The first of the two comments below is probably 
> primarily the IESG's concern, although it affects the IETF last call.
> 	The second comment is a more general issue.
> 
> Comments:
> 	This document requests assignment of a Diameter Command Code.
> 	As this requires "IETF Consensus" additional care may 
> be needed to ensure that the Last Call produces clarity on 
> the required consensus. 
> It would seem appropriate for the last call announcement to 
> have indicated this requirement.  It is difficult to claim 
> "IETF Consensus" 
> from the typical non-response to IETF last call for 
> informational documents.
> 

Hi Joel,

Thank you for catching this. I have required the Secretariat to re-issue
the Last Call with the clarification of the issue you are pointing to. 

Dan

Gmane