Subject: [Gen-art] review of draft-ietf-roll-building-routing-reqs-07.txt

From: Francis Dupont <[email-masked]>
Date: Fri, 02 Oct 2009 10:45:26 +0200

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-roll-building-routing-reqs-07.txt
Reviewer: Francis Dupont
Review Date: 2009-09-29
IETF LC End Date: 2009-09-24
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues:
 - IMHO the document is a bit USA centric (but it is not a problem
  if it is stated in the document, for instance with a reference
  from the (US) building automation community, cf 8.2 comment below)

Nits/editorial comments: 
 - the language of the document is not at the usual level (but at it
  should be considered as better it is not a concern)
 - 2 page 4, 5.1 and 5.1.1 page 12, 5.3 page 13, 5.4.1 and 5.4.2 page 14.
  5.7.2 and 5.7.4 page 16, 5.7.7 page 17. 5.8.4 page 18, 9.2.1 page 20:
   e.g. -> e.g.,
 - 3.1 page 5: use the occasion to introduce the FMS abbrev, i.e.,
  add "(MS)" after "facility management system"
 - 4 page 10: the P in P2P (and MP2P / P2MP) is ambiguous:
  it can stand for point and the point-to-point term usually
  refers to link topology. I propose:
   P2P -> (peer-to-peer, P2P)
   (MP2P) -> (multi-peers-to-peer, MP2P)
   (P2MP) -> (peer-to-multi-peers, P2MP)
 - 4 page 10 and 5.4.3 page 14: acknowledgement -> acknowledgment
  (for uniformity with the section title where this spelling is
   enforced) (multiple occurrences)
 - 5.1 page 11: no network knowledge -> no communication network knowledge
 - 5.2.2 page 13: even it is also overloaded:
  point-to-point -> end-to-end
 - 5.4 page 14: i.e. -> i.e.,
 - 5.4.3 page 14: 2000mah -> 2000mAh
 - 5.7.6 page 17: msec -> ms
 - 7 page 19: J. P. -> JP.
 - 8.2 page 19: I'd really like to get a reference from the building
 automation community: explaining networking to them or an introduction
 for us (networking community) or both. I expect there are at least
 some framework standards.
 - 9.1.2 page 19: 2.4Ghz -> 2.4GHz
  (BTW the ISM band text is very USA centric :-)
 - 9.3.1 page 20: missing final '.'
 - Authors' Addresses page 22: unfinished (???), add +1 for USA phone
 number, -- -> - (and BTW try to use the same separator)

Regards 

[email-masked]

---

From: [email-masked]
Date: Fri, 2 Oct 2009 19:03:01 +0200

Hi Francis,

Can you precise a little bit more why you think draft 07 is USA centric? 
Mainly because of section 8.2 and section 9.1.2? other sections?

Regarding section 8.2, I don't fully understand your expectation... Do you 
expect a few words on LON / Echelon, ASHRAE... for instance?

Have a nice week-end & Best regards,
Nicolas

Francis Dupont <[email-masked]> 
Envoyé par : [email-masked]
02/10/2009 10:45

A
[email-masked]
cc
[email-masked], Nicolas Riou/FR/Schneider@Europe, 
[email-masked], [email-masked], [email-masked]
Objet
review of draft-ietf-roll-building-routing-reqs-07.txt

Summary: Ready

Major issues: None

Minor issues:

Nits/editorial comments: 

Regards 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________

---

From: [email-masked]
Date: Fri, 2 Oct 2009 13:37:58 -0500

Hi Nicolas,

I believe this comment has already been mitigated.  Peter was nice enough 
to review the draft quickly and noted HVAC, K-12 and Elevator as US 
centric terminology.  Adrian discussed this and I believe resolved the 
comment.

I have received some other comments in other areas of the draft that I 
will be working on with the commenters shortly.  If Francis has any other 
areas of concern, let me know and I will add them into the comment 
resolutions.

Thanks for the help.

Ciao,

Jerry

[email-masked] 
10/02/2009 12:13 PM

To
Francis Dupont <[email-masked]>
cc
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked]
Subject
RE review of draft-ietf-roll-building-routing-reqs-07.txt

Hi Francis, 

A
[email-masked] 
cc

Summary: Ready

Major issues: None

Minor issues:

Nits/editorial comments: 

Regards

---

From: Adrian Farrel <[email-masked]>
Date: Sat, 03 Oct 2009 00:27:10 +0100

Thanks Francois,

Good to have your review.

Coming as it does, after both IETF last call and IESG review, we will try to 
sort your comments by importance and pass them on as pointers to the RFC 
Editor.

Cheers,
Adrian

----- Original Message ----- 
From: "Francis Dupont" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Friday, October 02, 2009 9:45 AM
Subject: review of draft-ietf-roll-building-routing-reqs-07.txt

---

From: [email-masked]
Date: Sun, 4 Oct 2009 19:07:21 +0200

Hi Jerry,

Ok. I thought the issue had been re-activated.
Best regards,
Nicolas.

[email-masked] 
02/10/2009 20:37

A
Nicolas Riou/FR/Schneider@Europe
cc
[email-masked], Francis Dupont <[email-masked]>, 
[email-masked], [email-masked], [email-masked]
Objet
Re: RE review of draft-ietf-roll-building-routing-reqs-07.txt

Hi Nicolas, 

Thanks for the help. 

Ciao, 

Jerry 

To

Hi Francis, 

A
[email-masked] 
cc

Summary: Ready

Major issues: None

Minor issues:

Nits/editorial comments: 

Regards

---

From: [email-masked]
Date: Wed, 7 Oct 2009 09:55:50 -0500

Hi Francis,

Thanks for your review and comments.  In discussing the comment resolution 
process with Adrian, he suggests that I work directly with the commenter 
to resolve any issues.  Please note my in-line comments below and let me 
know your thoughts. 

BTW, I am not sure if I will be drafting a -08 version.  I will discuss 
with Adrian how best to integrate your comments into the draft going 
forward.

Best Regards,

Jerry

Francis Dupont <[email-masked]> 
Sent by: [email-masked]
10/02/2009 03:47 AM

To
[email-masked]
cc
[email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked]
Subject
review of draft-ietf-roll-building-routing-reqs-07.txt

Summary: Ready

Major issues: None

Minor issues:

I have received a similar comment before from another reviewer.  The other 
ID authors, as well as the WG chair and Adrian  are all European .  They 
have recommended a few terminology changes (e.g. elevator, K-12, HVAC) 
that might be US focused.  

Nits/editorial comments: 
o.k. 

 - 2 page 4, 5.1 and 5.1.1 page 12, 5.3 page 13, 5.4.1 and 5.4.2 page 14.
  5.7.2 and 5.7.4 page 16, 5.7.7 page 17. 5.8.4 page 18, 9.2.1 page 20:
   e.g. -> e.g.,
o.k.   If I draft a version -08, I will make these changes, otherwise, I 
will ask Adrian to forward these changes to the editors.

 - 3.1 page 5: use the occasion to introduce the FMS abbrev, i.e.,
  add "(MS)" after "facility management system"
Not sure of your comment.  The term FMS is actually introduced on p4. 
Here, the abbreviation is spelled out. FMS is also documented in the 
'terminology' ID.

 - 4 page 10: the P in P2P (and MP2P / P2MP) is ambiguous:
  it can stand for point and the point-to-point term usually
  refers to link topology. I propose:
   P2P -> (peer-to-peer, P2P)
   (MP2P) -> (multi-peers-to-peer, MP2P)
   (P2MP) -> (peer-to-multi-peers, P2MP)
I am ambivalent about the change; however will defer to the WG Chair (JP 
Vasseur).  I believe JP has the opposite view of these terms being adamant 
that the abbreviations mean point-to-point, multipoint-to-point and 
point-to-multipoint respectively. 

 - 4 page 10 and 5.4.3 page 14: acknowledgement -> acknowledgment
  (for uniformity with the section title where this spelling is
   enforced) (multiple occurrences)
o.k.   If I draft a version -08, I will make these changes, otherwise, I 
will ask Adrian to forward these changes to the editors.

agreed.

 - 5.2.2 page 13: even it is also overloaded:
  point-to-point -> end-to-end
Yes.  As noted in your comment above (4 page 10), I will discuss with JP. 
You are correct that I have used 'point-to-point' and 'peer-to-peer' 
interchangably in this draft.  Now you suggest 'end-to-end'.  In this 
instance, I think 'end-to-end' is a good choice.  However, with mesh 
networks we should be clear and consistent in our terms.  I will forward a 
separate email to JP to ask him to clearly state the appropriate 
nomenclature we should be using.  Once defined, I will make the changes 
throughout the specification accordingly and suggest these terms get added 
to the 'terminology' ID.

Yep. ok.

ok.

ok.

ok.

 - 8.2 page 19: I'd really like to get a reference from the building
 automation community: explaining networking to them or an introduction
 for us (networking community) or both. I expect there are at least
 some framework standards.
BACnet (Building Automation Control Network) is an ISO Standard protocol 
defined and used world-wide for commercial building use.  It fully 
describes six different data link implementations (including UDP IP) with 
full timing, transport, fragmentation and routing support, as well as a 
complete object model.  I'd suggest this be the Standard you might be 
looking for.  I had BACnet defined as an informative reference in earlier 
versions of the draft, but was asked to delete it while in review.  Maybe 
this should be added back into the draft.

 - 9.1.2 page 19: 2.4Ghz -> 2.4GHz
  (BTW the ISM band text is very USA centric :-)
ok.  I thought the 2.4GHz ISM band was defined world-wide.  I agree that 
the 900 ISM band is U.S. Centric. I will delete 'ISM' and '900' from the 
requirement.

ok.
ok.
Regards